Tags: programming

173

sparkline

Readable Code without Prescription Glasses | Ocasta

I saw Daniel give a talk at Async where he compared linguistic rules with code style:

We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.

Thus began some thorough research into trying to uncover a universal grammar for readable code:

I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.

I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).

Programming Fonts - Test Drive

Monospaced fonts you can use in your text editor. Most of them are …not good. But then there are gems like Mark Simonson’s Anonymous Pro, David Jonathan Ross’s Input, and Erik Spiekerman’s Fira Mono. And there’s always good ol’ Droid Sans.

The Elements of UI Engineering - Overreacted

These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:

It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?

Stop Learning Frameworks – Lifehacks for Developers by Eduards Sizovs

It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:

  • Programming languages are different, but design smells are alike.
  • Frameworks are different, but the same design patterns shine through.
  • Developers are different, but rules of dealing with people are uniform.

How Readable? | Clearleft

Cassie and I went to a great Async talk last night all about code readability, which was well-timed because it’s been on our minds all week. Cassie explains more in this post.

Big ol’ Ball o’ JavaScript | Brad Frost

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”

Reluctant Gatekeeping: The Problem With Full Stack | HeydonWorks

The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.

Absolutely spot on! And it cuts both ways:

Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

Tutorial Markdown

Tim recently gave an excellent talk at FFConf. He mentioned this variation of Markdown, specifically for writing coding tutorials that update as you scroll. You can see it in action on his Generative Artistry site.

Kind of reminds of some of Bret Viktor’s work.

Programming Sucks

There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.

33 Concepts Every JavaScript Developer Should Know

Please ignore the hyperbolic linkbaity title designed to stress you out and make you feel inadequate. This is a handy listing of links to lots of JavaScript resources, grouped by topic …some of which you could know.

I, Maintainer

Maintaining an open source project is a rollercoaster ride with high peaks and very low troughs.

Release frequency is down. Questions increasingly go unanswered. Issues remain in a triage, unresolved state. Uncertainty and frustration brew within the community room.

Brian’s experience with Pattern Lab very much mirrors Mark’s experience with Fractal. The pressure. The stress. But there’s also the community.

A maintainer must keep the needs of their project, their community, and their own needs in constant harmony.

This is hard!

Understanding why Semantic HTML is important, as told by TypeScript.

Oh, this is such a good analogy from Mandy! Choosing the right HTML element is like choosing the right data type in a strongly typed programming language.

Get to know the HTML elements available to you, and use the appropriate one for your content. Make the most it, like you would any language you choose to code with.

Manual Aspire

If only all documentation was as great as this old manual for the ZX Spectrum that Remy uncovered:

The manual is an instruction book on how to program the Spectrum. It’s a full book, with detailed directions and information on how the machine works, how the programming language works, includes human readable sentences explaining logic and even goes so far as touching on what hex values perform which assembly functions.

When we talk about things being “inspiring”, it’s rarely in regards to computer manuals. But, damn, if this isn’t inspiring!

This book stirs a passion inside of me that tells me that I can make something new from an existing thing. It reminds me of the 80s Lego boxes: unlike today’s Lego, the back of a Lego box would include pictures of creations that you could make with your Lego set. It didn’t include any instructions to do so, but it always made me think to myself: “I can make something more with these bricks”.

CSS and Markup in Javascript is an Evolutionary Dead End

The bet to make is that we’re going to see more use of specialized languages. And HTML and CSS are the grandaddy specialized languages that have enough social consensus and capital investment to be the seeds of the next generation.

Coding with kids

James shares his experience of teaching a class of 9 and 10 year old children how to code, and offers some advice:

  • Don’t dumb it down
  • Use real-world examples
  • Make it hands on
  • Set clear expectations
  • Award certificates and/or stickers

As members of the web community we have a responsibility to share what we have learned. I can’t think of a better way of doing that then helping kids get started.

Hear, hear!

Pair Programming

Amber gave a lightning talk about pair programming at the Beyond Tellerrand Düsseldorf side event. Here is the transcript of that presentation.

The fact that everyone has different personalities, means pairing with others shouldn’t be forced upon anyone, and even if people do pair, there is no set time limit or a set way to do so.

So, there’s no roadmap. There’s no step-by-step guide in a readme file to successfully install pair programming

You are not your tools

The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

clean-code-javascript

Opinionated ideas on writing JavaScript. I like it when people share their approaches like this.

Async + Await

Slides from a conference talk with a really clear explanation of how async + await works with promises.

Learn JavaScript with Zell

This JavaScript training course looks like it’s really well planned to take you from zero to hero—there’s a whole module on progressive enhancement.