I’m a hacker, developer and lazy guy. So when I found myself in the kitchen cooking, just realizing that my Pioneer VSX 921 receiver was turned down too low I didn’t walk over to turn it up or find the remote; I instead remembered that it has a bad app for iOS, meaning that it accepts being controlled remote over the network. A little bit of google searching and I found a plugin for an I-dont-know-what containing an XML with some Lua code (XML with code — yay), and also a very nice mapping table for commands the same code runs against a VSX 1021.

So a quick telnet session later I had yanked the volume up without ever leaving the kitchen! These commands probably work for most of the VSX 921/1021 series and later. Enjoy:

26FN = HOME MEDIA GALLERY(Internet Radio)

If you want to change input to the iPod port and turn up the volume, given you’re using OS X or some Unix derivative, you would do this:

There is a tone of other commands you can use, I believe 

 is very much valid for other devices in the series.

Remote control your Pioneer VSX receiver over telnet

For our halloween party we went all out on decorating the flat. Why host a halloween party if you dont go the mile, eh? We of course had a jack-o-lantern, we cut a ton of small black bats that fly across our walls, and there were blood trails on the floors, and hand imprints in blood on the bathroom. The highlight for me however was creating an interactive Stranger Things lightning installation.

My initial plan was to use just components I had lying around from years back; Specifically a handful of Particle Core devices. The neat thing about the cores is that they are basically arduinos with onboard wifi, meaning it’s relatively easy to use the vault of resources and libraries that exist for arduino, while also making your component usable without cables for communication. Controlling individual leds are done with ease using these tiny computers; You simply plug a LED and a resistor to one of the 8 digital outputs and to ground, and then you can set HIGH/LOW to that port to flip the light on and off. But while I could get 8 LEDs this way with ease, I needed some new tricks to get up to the 29 LEDs I wanted. While there are techniques, like 

, and approaches, like using 4 particle cores, that would have worked, I found a local shop that sold 1 meter 

Before building the LED strip I got help in painting the letters on a big piece of paper from a paper roll. With the letters in place we would be able to measure and plan the wire lengths needed.

With the letters in place the next step was some hours of grunt work soldering everything together.

Neopixels only require 3 connections: 1 digital out, 5V power and ground. The strip works out of the box, but you can also cut it up into 60 individual LEDs just using scissors, and then re-solder all the LEDs with wires of your desired lengths. I cut of 29 LEDs and measured the distance between each letter and started soldering! Soldering short wires is a bit tedious work, and you probably need a pair of tweezers to get the work done. Clearly the neopixels are far easier to use if you don’t require readjusting the distance. I just had prototyping wires lying around, so I cut a bunch of them to suiting lengths and started soldering the 168 joints.

With the hardware seemingly under control I started looking into the code. I spend day in and out in JavaScript land, so I really wanted to do this using the excellent johnny-five library. While there is a really good option for controlling neopixels with an arduino using the node-pixel library, it did not support the particle core, or alternatively I would have had to use a secondary controller device running a custom firmware. In the end I accepted reality and decided on plain c/c++ with the 

 for each specific LED, and when you have set all the LEDs to the colour you want you call 

. One of the big selling points of the Particle devices are that they are cloud connected by default, and its really easy to register a function call that will be exposed through an API for remote control. We can set up a function to light up a specific LED quite easily:

I placed the LED strip under the paper alphabet in order to test a single LED to make sure it would look alright. The result was pleasing. Since this would be used for a party, the room would be quite dark, so the lights would really be visible.

With everything apparently working it was just a matter of mounting everything and writing the actual code for the project. The approach was rather straight forward: Register a cloud function in the particle cloud that would take in a word, or sentence. Loop over each character in the word, find the corresponding LED position in the strip, and add that number to a list while adding a 

 before and after the input. Then in the 

function I would pop the first item from the list of leds to be lit, and loop over all the LEDs in the strip and either set it to off, or if it matched the id to be lit call on a function that generated a random RGB colour. 

You can get the full source code on my Github

Using particle you get a simple — yet great— mobile application for controlling the cloud functions, and for accessing some general information about your core. In the end I didn’t have time to build the web app I planned for controlling the lights, but using the iOS app we could pass the phone around in order to type with the lights.

Here it is, on the wall, working great. It was a fun project and now I’m thinking about what other things I should do with the particle cores now that I’ve dusted them and peaked my interest.

Making a Stranger Things lights decoration

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

Remote control your Pioneer VSX receiver over telnet

Read also

Making a Stranger Things lights decoration

Kill the designer

Writing solid asynchronous code using Promises