The Insider News

JavaWorld[^]:

Left unchecked, certain developer personality types can sink your project -- or, worse, make themselves no fun to work with. In my long and storied career, I've personally encountered all 14 of these personality types. In fact, I have been several of these people to some degree or another; I've also knowingly hired them. You know who you are.

bryce.vc[^]:

I see the value of writing clearly and concisely becoming an increasingly important skill for digital workers. Partly for the reasons outlined above, but also because we’re moving into a massive wave of distributed work and self selected customers. This means our voice, and the voice of our companies, are often going to be discovered and engaged with via the copy of our services, the content of our social media channels and the clarity of our emails.

Encosia[^]:

Though it does serve a useful purpose in some compiled languages, I think switch is a clunky eyesore in most code. Its structure is prone to taking root and only growing larger and more cumbersome over time. If you’re coming to JavaScript from a background in procedural languages like C#, Java, or PHP, it’s natural to reach for the same tools, like switch, that you’re accustomed to using in those languages. However, JavaScript’s flexible object literal syntax and first-class functions offer alternatives to switch that I believe are cleaner, more extensible, and more maintainable.

F# for fun and profit[^]:

So we have a lot of these "one input -> Success/Failure output" functions -- how do we connect them together? What we want to do is connect the Success output of one to the input of the next, but somehow bypass the second function in case of a Failure output.... There is a great analogy for doing this -- something you are probably already familiar with. Railways! Railways have switches ("points" in the UK) for directing trains onto a different track. We can think of these "Success/Failure" functions as railway switches.

ReadWrite[^]:

The debate about app design largely centers around screen size. What if designers worried about digit size instead? Luke Wroblewski, a respected designer... thinks it's time to reconsider mobile design principles. Instead of worrying about questions like whether to upsize smartphone apps for tablets, designers should start by asking how their users will physically interact with their devices when using an app. The technical term for this is input type—keyboard versus touchscreen, one-handed or two-handed interactions, and the like. This requires designers to think about how a device is held, which fingers are used, and how the app in question can optimize the experience for users' dexterity.