We recently had the opportunity to share on CSS-Tricks about Cboard! Check it out to learn more about how the open-source ecosystem and modern browser developments are making Cboard possible. We discuss the Web Speech API, React, the Internationalization API, and the “progressive web app” concept. Read the post.
Finally, finally, I have time to hit up local events and meetups again, and Austin has not disappointed. (See what I was up to the first half of the 2016.)
First up, Emberitas. I found out about this event through the Women Who Code – Austin network. Three awesome women in the Austin Ember community decided to organize this free one-day workshop to introduce women to Ember.js. (All bootcamp grads, by the way — two from MakerSquare and one from CodeUp).
Given our understanding of what async is, how the callback pattern manages async, and some of the deficiencies of the callback pattern, let’s dive into another, newer pattern — promises.
As with callbacks, for a new developer, it can be difficult to sift through the massive amount of information available online. For the benefit of anyone else newly exposed to promises, in this post I’ve attempted to cull the resources and posts that I have found most enlightening through my own learning.
Imagine you walk into a coffee shop to get a latte. If they’re busy, perhaps you wait in line. When it’s your turn, you place your order with the cashier, and pay for the drink. The cashier writes your order — maybe even your name — on a coffee cup, and places it behind the empty (not yet fulfilled) cup of the person who ordered before you. Perhaps the shop is quite busy and there are ten cups ahead of yours. That queue of yet-unfilled coffee cups allows for the separation of the cashier (processing and queuing orders) and the barista (fulfilling orders based on the information supplied by the cashier). This queuing process results in increased efficiency and output. (The original source expands on the metaphor and is quite interesting). This is an example of asynchronous, non-blocking behavior.
In the last week, the subject of the Dvorak keyboard has come up more than usual. (‘Usual’ being not at all.) The Dvorak keyboard is an alternative to the widely-adopted QWERTY keyboard, and was patented in 1936 by Dr. August Dvorak and his brother-in-law, Dr. William Dealey. There are a couple of devotees among my coworkers at MakerSquare, and at some point in one of our discussions, I became inspired — how quickly could I pick it up? Or further, how long would it take to achieve at least half of my QWERTY speed? So I tested, to get my baseline, coming in at 120 WPM.
Through presenting at bootcamps, I’ve so far had the chance to expose over 100 devs- and engineers-in-training to web accessibility —- what are we really talking about when we say ‘web accessibility’, who does it affect, and what are some very initial considerations to take into account? This is a short blog recap, including the deck.
‘Just break things.’ ‘Get your hands dirty.’ ‘Just dive in.’
A simple, and infuriating piece of advice that I’ve been given, and given to others. So surprisingly difficult to carry out sometimes. I was reminded by this bit of advice while working on a project last week.
The best way I have ever heard to capture my insecurity at being a generalist:
When someone says they want “designers who can code”, what I hear them saying is that they want a Swiss Army knife. The screwdriver, scissors, knife, toothpick and saw. The problem is that a Swiss Army knife doesn’t do anything particularly well. You aren’t going to see a carpenter driving screws with that little nub of a screwdriver, or a seamstress using those tiny scissors to cut fabric. The Swiss Army knife has tools that work on the most basic level, but they would never be considered replacements for the real thing. Worse still, because it tries to do so much, it’s not even that great at being a knife.