Lately at work I have been writing a lot of Javascript. As a consequence I have also been reading lots of Javascript examples and documentation. Javascript is a highly useful language that also happens to not look so great. However it has improved in recent years. The introduction of arrow functions has greatly increased the readability of Javascript code, which is often polluted with nested function calls. Along with the introduction of promises, async/await, and string interpolation using backticks, modern Javascript code is now more readable and easier to reason about than ever.
Unfortunately the documentation has not caught up. In looking for examples and explanations I often find code written in the older syntax. Even worse it usually follows its own style guide. The first thing I do with a new example is to reformat it using the AirBnb style via ESLint. A friend turned me on to eslint --fix as a tool to automate this a bit. Then I often have to refactor it to use the newer let and const style variables over var. This usually means thinking about and dealing with scoping issues. Once I have completed these steps I am usually in one of two states: joy or frustration. Reformatting the code usually makes it more comprehensible. If something fails to translate well to my style then I usually have to spend a lot of time figuring out the nuances of that problem.
The most painful disconnect in developing Javascript is it is not quite as universal as it should be. Different browsers support different features and versions of the language. The general solution is to use a tool called Babel that converts your new style Javascript into the syntax that works with older browsers. The other solution would be to learn about the feature variations among browsers via the Mozilla Developer Network and caniuse.com documentation.
Yesterday I learned that GMail, Google’s e-mail product, was spam boxing replies to e-mails that I have sent to other people. As a software developer I find this behavior strange. If I was designing a spam filter I would assume that e-mail replies that have knowledge of that e-mail were not spam. That is an easy conditional to test for. Yet the evidence suggests that Google’s sophisticated artificial intelligence algorithms do not do this. Their support simply said to check my filters and mark the replies as not spam. They did not even offer to send a towel to wipe the egg I got on my face from thinking folks were not responding to my queries.
This does not mean I will abandon GMail. For better or worse they have figured out e-mail better than anyone else. Sadly some mail senders have not figured out some of the newer e-mail rules or technologies and I have had to create a bunch of filters to keep them out of my spam box. Yet overall I do not get spam in my regular inbox. Their interface and ability to manage my email is superior to any other solution I have tried. My biggest complaint used to be the lack of functional keyboard shortcuts in their iPad app and they even fixed that. I have long been waiting for someone to beat them at this game, but no sign of that exists. Therefore, I am stuck.
When I first learned what we call web software development I was in middle school. I remember going to Barnes & Noble with my parents where I picked up a book called HTML Goodies by Joe Burns. HTML was magical. It took little effort to write a few lines of code that changes the presentation of your text on the screen. As I hit the limit of what I could do with HTML the arrival of Javascript let me sprinkle some magic into the site. A little learning lead to lots of magic.
In 2014 we got the arrival of HTML5. There were lots of great new features but a main difference is that HTML5 focuses on using semantic markup, tags that annotate the type of content, instead of presentational markup. Responsibility for presentation of the content was largely moved to CSS. Unlike the way the typical user formats their Word documents where they try to make it “look” the way they want, web developers are now responsible for thinking about annotating the content of the type of document and then styling it in a separate language.
The good news about CSS is it is powerful and well documented. It generally improves over time, but as the number of features grows so does the learning curve. The W3C posts its drafts on GitHub. If you want you can read over 20,000 commit messages about how the CSS specification has changed over the years. As you use CSS you need to think not only about what features to use, but whether those features are available on other web browsers. Documentation like the Mozilla Developer Network can help you understand this. MDN documents around 600 keywords you might need to know to style your document, not including pseudo-classes, and 12 pseudo-elements you might need to know to fully understand CSS.
A big movement in web development is accessibility. When I started building websites we did not think about accessibility. Companies like Apple developed screen reading technology and other amazing tools and techniques to make websites more accessible to folks with disabilities and then software developers came up with new ways to break them. Now many developers think about how to make their websites work better with these technologies. This zeal is a boon to folks being able to read websites (and follow the law) but it has created a new tax on development. A developer must not only learn how to make their website accessible but they might need to familiarize themselves with a new series of attributes and develop appropriate content and information to populate them based on content. People used to worry computers would steal the jobs of people, but web accessibility has demonstrated the opposite. Where the machine previously did work to translate simple markup into text that is read aloud, the complexity of websites and this technology has created a new field of work.
While no particular thing may be challenging to learn on its own, the multiplying features of software increases the gap of knowledge between experienced and inexperienced developers. Becoming a developer becomes more challenging, and inequality between top software firms and other organizations grows. I worry that as we innovate our way out of one set of problems we are either creating new challenges or shifting the work from one group of people to another.
Yesterday I was looking for an easy way to take a bunch of data and geocode it. In the past I used to either write a basic Ruby script to manipulate a CSV (which is not hard but more tedious than my late afternoon brain enjoys). I remembered I used to use Google Fusion tables to do this sort of thing and after some searching I learned you can now write Javascript functions for your Google spreadsheet. Now instead of writing a full script I could write a four line function that accepted the address from another cell as an argument and return a latitude or longitude. I can imagine this feature being not only useful for me, but my colleagues as well.
Over the weekend I worked to upload the distribute the Code for Boston Web Application Security Workshop video we took this past Tuesday. In the process of pulling together the video I ended up refactoring Code for Boston’s Social Media presence. To better manage it I discovered a new tool and developed a content strategy.
The most cumbersome part of social media is using each application’s user interface and the mechanical process of taking one piece of content and translating it into multiple platforms. The biggest problem was Instagram which seemed to only have a mobile application. I was not excited to need to use my phone to push content. However, I know Instagram is popular and want to start building an account for Code for Boston. Fortunately I discovered Buffer. I chose Buffer because of its user interface and free plan. In addition to a web interface Buffer provides a mobile app and web browser extension. I can now easily queue up content and have it post to Facebook, Twitter, and Instagram without much extra effort.
With the tool figured out the next step was to begin finding and deciding what stories to share. This is both the hard and fun part. Fortunately, besides the workshop video, I have a backlog of material I have been trying to push out. We projects from our recent hackathon at Jobcase that I promised to share stories about. These are all queued up. If you follow our Instagram you will get to read them this week. I will also share a bit about them on Facebook and Twitter. Over the next few months I hope to find and share more stories about what our members at Code for Boston are doing since every time I learn about them, they are good ones.