I'm the CTO of a small analytics platform startup called 

. Previously I've worked as a senior consultant in 

. Technology and specifically anything related to the internet matters a big deal to me, but when I log off I have a small family with a baby girl 👶 and a husky 🐾. Some times I publish some open source software and some rare times I blog on this space or Medium.com.

Raymond Julin | Technology and thoughts

As a big surprise I found a new version of the iTerm2 macOS terminal replacement waiting for me when I returned from my summer holiday. The release packed a number of big features, like a minimal UI theme, a magic global status bar and finally a 

The UI looks a lot more modern now. Bezels and borders tuned down and an experience that is even more content centric. I mean, tell me this doesn't look quite good!?

The rainbow colored line is the status bar that displays the current working directory, git status, process info and finally CPU + mem usage. You can tweak it with a number of ready-to-go components, this is just the stuff I decided to throw in there to start with. You can also build your own components by utilising the new API.

Anyway, enough free advertisment of iTerm2, lets get to briefly exploring that API.

If you do much of your work in a terminal, like me, you likely have some steps to take to start working on a project. I like to close everything up after work as I'm a one-laptop type of person and thus use it for different purposes after work. So every morning I go through a number of steps to get started: Open a terminal with some splits and run different processes in each. Open a few tabs for different services that I work on in conjunction. Its not that the steps are long, but from time to time I forget to start one service for example.

Lets see how we can automate these steps quite succinctly. I'll use what I believe is a common scenario as an example:

Split a tab vertically and run an API on one side and a frontend on the other side

Open one tab in the API directory and one in the frontend directory

Run git status in both to give me a glimpse of any unfinished work

When the frontend is ready, open my preferred working browser on the correct page

I also run some databases on a docker host with random ports and my real life script polls docker for the management ports to open that interface in a browser as well, but for brevity I'll skip those steps. There is a docker-py package that is fairly straight forward to use for this scenario.

iTerm2 has a tutorial you should check out as well

, and you might want to use the built-in functionality to generate the script file, which will place it inside the Application Data for iTerm2 and also make it accessible through the iTerm2 menu. I prefer to keep my scripts 

 and version controlled there, so I opted to install the required dependencies from pip and just create it myself. If you do so as well, first install the dependencies using 

I'll leave you with the code with comments as its fairly clear and understandable:

In order to run this you can stuff the file anywhere and just run it (

) or you can store it where iTerm2 wants you to and run it through the menu.

I always have an open terminal so I just run the script by hand at the start of the day. However, you can also register script functions with iTerm2 itself and actually add a button to that new status bar that will call the function. For a number of scripts that might be the right approach to take.

Explore the full API docs to get a grasp of what you can do with this toolbelt. One neat thing I can imagine is being able to configure an output matcher on a session that has a running script. You might have started this long running job you can't really stop midway and its producing a lot of garbage that you now want to filter but its too late to pipe it to a logfile via grep. You could write a function that does this with arguments for what to grep that will actually connect to the session and filter the text output as iTerm2 renders it.

I'm just happy that I could whip this up fairly quickly and save myself a few key strokes every day. Happy hacking!

Exploring the iTerm2 Python API

Design is a hotter subject than ever before. Apple is the most successful company in history, fuelled by design, and the subsequent “design thinking” philosophy.
The concept of “design” is far too important to be left to just the designer.

The design practice is often misunderstood. Many of our clients contact us because they want a UX revamp or some design touches on their applications, websites or other visual properties.
It is often assumed that the visual expression created five years ago is a replaceable skin with few ties into the underlying processes. This is a misunderstanding.

This belief has little grasp in reality. Design is not the act of painting, or picking, pretty colours on a house, an application, a brochure or a website.The act of design stretches from the top to the very bottom of everything you do as a team, as a company.

Design is an activity equally dependant on you — on everyone. Design is in everything, and design is a process used by people you would never label as designers.
Would you consider Elon Musk, the CEO of SpaceX and Tesla, a designer?What about the engineer that elaborately places electronic components onto a breadboard?

These are outlier examples, but they exemplify how our current idea of what a designer is, and isn’t, is broken. What we need is a better way to think and talk about design.

In the new market where segments converge and old distinctions as business-to-consumer / business-to-business are made irrelevant, design moves from being merely a procedural step in the work process to the very core methodology of all work.

Design is the process of deliberate planning and production of a system.

You cannot afford not to be a designer any more.
You cannot afford to hire an employee who doesn’t design.

I would argue that most of our clients are in dire need of changing into design-driven organisations, and we are often merely hired to help bridging the gap between them and the markets expectations. Putting lipstick on a pig. In order for our clients to catch up they need to internalise this mindset. It’s not something that can be patched up properly from the outside.

If your organisation’s success relies on selling an application, you’ll need your product managers, your customer liaisons, your system developers, your CTO and your CEO to be designers!

The CEO and CTO need to think in terms of design for every choice they make. Either they operate under false protection of a good revenue stream, or they are under pressure to resurface a sinking ship.

The customer liaison need to be a designer in order to transfer the customer domain knowledge and feedback into valuable design parameters for the further product development.
The system developers can not implement a design-driven system if they themselves does not speak design. Every micro interaction, every path a background process takes is part of the overall design that makes up the sum of the product.

The product managers need to think in terms of design in order to make the right choices for the product to compete in a market that is increasingly driven by design.

In fact, it’s very likely that you will need to redo the entire organisation chart as well.
Design-driven organisations need interdisciplinary teams to function properly. Departments cannot be split into silos anymore.

The informed reader have perhaps noticed that all of this sounds an awful like digital strategy. In fact, any strategy for business digitalization requires a shift in mindset towards that of the design thinker. It could be argued that this bloats the role of the designer and makes the title useless because it’s sounds all-encompassing, but this fuzziness is part of the digitalization shift.

When the entire organisation morph into “designers”, what happen to those with that job description in the first place? Are they out of business? Given that design is now even more important, their jobs also got more crucial. And the fact that the rest of the organisation are learning to design, the designers both have a big role in teaching how to think in design, and also to mediate the design processes.
Some designers might find it hard to open up and share the creative processes. They might feel they are giving up control of something that is “theirs”. As with any transformation there will be growing pains and frustrations, but these will be symptoms of the existing knowledge gap.

— There will be a personal computer on every desk running Microsoft software.
Bill Gates, Microsoft

In order to create exceptional products and services — which should be the aim of every company — one of the most important tools will be a shared vision of the future. We are not talking about the mumbo jumbo vision you already have. The vision needs to be a shared understanding of an attainable purpose, and the uniqueness you will possess that make you stand out amongst the crowd. It has to become a compass that guides you in making sure everyone pulls in the same direction.

A shared vision is a synthesis weaved together from conversations, discussions and analyses of the decisions you make as an organization. You need to drill the way of thinking so that every employee is comfortable that when making micro decisions, they choose the option that moves towards the shared vision of the future.
Building this intuitive shared mindset is the biggest investment you have to make. It’s important to not have a fixed idea at the beginning of this process, because the process itself is what shapes the end result.

The next time you consider purchasing a design project, or employing a designer, take a look at yourself — your organisation — and ask if that is what you actually need. And ask yourself if “just hiring a designer” is actually going to be the solution to your problem. The answer is very likely to be a solid no. At least not by itself.
The next time you consider purchasing a design project, you should reevaluate your expected outcome of the project. You should reevaluate how you approach the project, what types of people you allocate to it, and if your project team has the mandate to affect your organisation in a substantial way.
The next time you purchase a design project you should give it the attention and headroom it needs in order to reshape your organisation to better solve real problems.
And if you are a designer, rejoice, the next time you are hired it will probably be with more responsibility and more understanding for your expertise.

http://iallenkelhet.no/2015/10/20/kill-the-designer/

Kill the designer

There are two approaches to handling asynchronous control flow in JavaScript at the moment: Callbacks and Promises. Node.js core APIs, and thus most things written for Node, are callback based. I’m not claiming that callbacks should never used, but I believe Promises simply are a better solution to the same problem. Whereas callbacks are “the simplest solution that would work”, Promises is a thought-out solid solution that, we will see, don’t break your code!

Node.js core APIs uses callbacks to allow your to write code that executes after an I/O operation is either finished or erred. The case for callbacks is that adhering to Node.js APIs brings familiarity for other developers. The function(err, data) pattern will not raise eyebrows for other JavaScript developers. The case against callbacks is that they break the exception system, it brings 

 it requires you to write your functions wholly differently that you’d do if they weren’t async. 

argument? And they even break language (any language) standards such as Exceptions!

The Callback Hell argument is weak as there is nothing in the pattern forcing you to write ten levels of callbacks nested as anonymous functions inline, but the pattern does make it easy for you as a developer to do so.

Promises is a coming ECMAScript 6 specification that’s extracted from open source libraries providing this functional approach to solving control flow for async code. The concept behind promises is that when returning a Promise you are returning an object that promises to either successfully resolve with a value or to reject with a reason.

referring to one of the most important parts of the specification stating that every Promise must have a method 

that takes one or two functions as arguments, a resolvedHandler and a rejectedHandler. Every such handler must then return a new Promise — often handled by the library for you as well — thus achieving chaining: 

promiseMe().then().then().then(resolved).

Some of the important benefits promises brings to the callback-table are that they

… don’t force me to rewrite all of my code

The nice thing about promises is that they don’t interfere with a functions arguments but rather strictly adheres to arguments as input and return values as output. Callbacks are notoriously bad because they conflate inputs and outputs for a function. Promises are also interchangeable so instead of passing a callback 5 levels deeper you can just return the promise in every function — even changing it on the way — before you grab it from the entry point.

It is true that some code at some point has to change to create the promises, but most changes can be kept at wrapping function calls.

Promises are composable so you can achieve g(f(x)), an impossible feat using callbacks. The syntax changes so this isn’t perfect either, but supporting square(square(2)) would require more cruft in the square function.

Lets compare this with how we would solve this out of the box with callbacks:

Lets take the Promise composition example and adapt it to use an existing sync square method to prove that we can wrap existing code into promises/thenables:

Promises correctly bubbles exception upwards, aligning Promise based code with its synchronous counterpart. Look at this callback implementation, it’s obviously convoluted and brittle:

Promises uses plain normal exceptions for its error handling, meaning we automatically can work with built-ins like JSON.parse in this example.

Unfortunately we need to fight Node.js when going pure Promises. It introduces some complexity but promises libraries help us out with wrapper methods:

I’m in a romantic relationship with async.js

You’re in luck! Most things you thought async kicked ass at, Promises pretty much one-ups! Lets take something a little “complex” — the 

example for async.js and the same written using Promises:

Having said so, async.js is still an awesome library with a ton of great control flow helpers.

This used to be a valid argument but with the Bluebird Promise library the arguments moot. 

Gorgi Kosev shared an analysis of async patterns where Bluebird is almost as fast as plain callbacks

, and over twice as fast as async.js. The same is the case for memory usage.

There’s a lot of Promises implementations popping up, but I will recommend three concrete ones:

 — One of the older and more mature libraries. Heavily used and feature rich

 — My favourite library. Unmatched performance

I would also recommend you to learn more from people smarter than me who has written about Promises:

Gorgi Kosev — Why I am switching to promises

Domenic Denicola — You’re Missing the Point of Promises

Jake Archibald — JavaScript Promises – There and back again

Matt Greer — JavaScript Promises … In Wicked Detail

👋🏼 I'm Raymond.

Featured blog posts

Exploring the iTerm2 Python API

Kill the designer

Writing solid asynchronous code using Promises