Good code is boring.

There is a quality of great code that most developers never talk about: good code--really great code too--is shockingly boring.

If you want exciting code, write no tests. You'll find all kinds of cool stuff in your application later. And you'll have job security.

Also, name your stuff-your variables, objects, functions, files-using all manner of abbreviated words, word order, capitalization, dashes, underscores. And you know, 'x' is the perfect identifier, everyone knows what that means, right? Just use that, and maybe i, j, and k.

And just let all the devs express themselves. Let all the devs use their own dialect. Diversity is a value, right? Some writers write novels, some narrate short stories, some theorize in essays, some compose poems. So some devs write really long modules. Some devs are concise. Some devs enjoy being clever. Let them all be who they are. It will make supporting your project really heart-pumping, fast-paced for some Saturday morning release.

To keep it real exciting, never pick controlling patterns. For the fun and adventure of it, allow future engineers to discover just which pattern was used for that particular service or set of modules. If they don't know whether the module exports an object or a function or a class, they'll have fun. It will be a learning experience! That's what we want our devs to have, right?

And endlessly debate emerging technologies, packages, and approaches. We must be learners and stay up on the edge or we will be left behind. Try a new package when you feel like it. Throw it in the project, give it a whirl! Refactor a few modules to use it. It will make the project a nice, diverse mix of packages. Something for everybody.

For the most fun, leave jewels buried somewhere in the rough. You know, like, `project/server/src/routes/stuffGet/helpers/utils/project_config.json`. Bury those key files and scatter them out. Half the fun is the expectation, right?

Or not.

I'm starting to believe that the best gift I can give to other engineers, or my future self, is really boring, predictable code.

It seems we all obsess about which language, framework, library, syntax, pattern, standard, and approach to use or apply.

All that matters, for sure, but I would much rather have to pick up code and work on a legacy app where the older stuff is organized and written well, rather than pick up code on your bleeding edge app that is under-engineered (or over), too clever by half, and a labyrinthine nest of developer trials-by-fire.

So, right now, how exciting or boring is your code?

Can I open up your project and see where everything is located quickly?

Can I peak inside a folder and see consistently named files?

Can I peak inside a folder and see all the contents in a list that completely fits on the screen?

Can I open 3 or 4 modules and see a nice, ordered sequence of code that fits inside just a couple of scrolls (or less) down?
Is the sequence of stuff consistent?
Do the modules return the same kind of thing?
Is there a file right next to that module called 'myModule.test.js'? Or something similar. Or maybe in a folder `tests`?

Can I read through one of those modules and know what the "things" are?
Are the variable identifiers clear?
Are the function names verbal and descriptive?

Can I open your main README and quickly learn everything I need to know what this thing is, where the key files are, how to start and run the thing, how to run the tests, and where to look for more detailed documentation?

I used to live a very exciting life as a coder. But now I say, "no thank you," to exciting code. Adventures are fun, but let's keep them in the movies. I want to do my coding and leave on Friday at 5 with the confidence that on Saturday morning I won't have to debug a recent release with adrenaline pumping and heart racing like Indiana Jones outrunning a giant rock.
 

EmberConf 2016: Talks Mashup

In two days, I attended 15 talks. I've already blogged about two of the talks: the opening keynote by Tom and Yehuda, and the talk on cross-pollinating communities by Chris Ball.

I may not get the time to go into the same level of detail with the other talks I attended, but I want to briefly mention each of them and link to any related resources.

Using Service Workers in Ember

John Kleinschmidt works with hospitalrun.io providing systems for hospitals in developing countries. In attempting to build web apps where Internet connections are spotty, He has turned to service workers as a solution for handling offline issues in their app. For instance, if their app can't reach the web, then their service worker will fetch data from a local CouchDB instance. Lots more too this, see the resources below.

Resources:

<select>ing Good Ember Patterns

A great talk by Brenna O'Brien. Particularly good for it's flow, the exposition of the "Data down, actions up" maxim, and explanation of newer template syntax, such as dynamic attributes, closure actions, {{ get }}, {{ mut }}, etc. And of course, she showed us how to build our own, great select component!

Resources:

How I Learned to Love Ember

Ju Liu told a sort-of rambling story from being a PhD student to working on JavaScript applications with all of the usual cast of characters and some supporting actors: jQuery, Backbone.js, marionette.js, batman.js, AngularJS, and then, finally, to Ember. A very humorous talk, engaging us with a story probably real for many of us.

Building Mobile Apps with Ember

Alex Bloom gave a usefully dense talk about using Ember and Apache Cordova to build mobile apps. One of the key takeaways was his statement that, 

"Much of making effective mobile apps is simply writing good code."

Imagine that! 

Resources:

Dissecting an Ember Build

Estelle DeBlois, a developer at DockYard, walked through the process for using Ember CLI add-ons, creating your own add-ons, understanding Broccoli, and the build process. Her opening line was, 

"Ember without Ember CLI is like Peanut Butter without Jelly."

She covered a lot of territory, particularly because the build process does a ton of work for you. 

Resources:

Ember CLI: The Next Generation

Stefan Penner, from Yahoo!,  gave a history of JavaScript build tools, the origins of Ember CLI, and hints towards the future of Ember CLI. 

Stefan made a number of great points:

  • Imagine if we could improve build time by just 20%? Improving build time can save saves days of time over the course of a project.
  • "Developers are productive 4 to 5 hours a day, if they are not pulled into too many meetings."
  • "If it takes 4 years of experience on dev tools to be a good web developer, what does that tell you?"
"Developers are productive 4 to 5 hours a day, if they are not pulled into too many meetings."

And he indicated some of the future direction for ember-cli:

  • ember-cli will now have it's own core team.
  • they will migrate away from bower, transition to npm.
  • engines and support bundling will be enabled.
  • possibly, a first class API for packaging bundles with HTTP2 enabled.
  • a linker with support for importing  only the Ember files you need. 

Compose Yourself with Ember and D3

Ivan Vanderbyl covered a topic very near to me right now, the use of D3 within an Ember app. He encouraged us to think in terms of graphing and data, instead of charts and libraries. I can relate very much to this point he made:

import {
  technicalDebt
} from "charting-library"

He argued for a classic software design principle of separating the concerns of data and presentation. And he made a case for using an expressive tool like D3 instead of a library that simply implements ready-made charts for you.

"You can't exaggerate the presentation without disregarding the underlying data." 
"All sufficiently ambitious applications will eventually require data visualisation."

Resources:

Idiomatic Ember: Sweet Spot of Performance and Productivity

Lauren Tan gave a talk on the Ember "way" as a path out of the confusing and fragmented JavaScript world today. In particular, she addressed the Ember approach to data and actions ("data down, actions up"), the near demise of controllers, and writing good templates. This was a good talk that touched on a number of things: components, hooks, bindings, actions, helpers, computed properties, and observers.

Resources:

Immutability is for UI, You, and Me

Charles Lowell gave an absolutely excellent tech talk on the why and how of using immutable models in Ember. It was obviously an alternative perspective than most are taking, but he did a great job, in as plain o' language you can get on this, of describing his approach. He described his frustrations with Backbone,  and how he fell in love with Ember's Object.  And then how he took concepts from Om and applied their unique way of handling state to his Ember apps.

Resources:

How to Build a Compiler

I got to admit that by the time I sat in on James Kyle's talk about building a compiler, my brain was pretty mushy. I got a decent overview of what a compiler does at the beginning, but I couldn't follow the rest very well from my distant seat. He did throw some books at the outset, which was pretty cool!  He began by covering the various kinds of code (machine, assembly, source), parsing, transformation, and generation. He then proceeded to discuss his experience of attempting to build the world's smallest compiler.

"Handlebars is a variety of lisp." - @wycats

Resources:

Ember between Design and Development

This was a joint talk by Lisa Gringl and Francesco Novy about the ways designers and developers can work together for a better software life cycle. They made a case for why designers should code, and why developers should understand design. They proposed that every project should have the following documents to guide this process:

  • Code documentation - describes all the code objects and methods, generated from the javadoc style comments in the code itself.
  • Living style guide - describes all the CSS classes and generated automatically from comments in the .css files.
  • Component guide - describes what each component does, not how it does it, provides the attributes, a demo, and the code for each component.

Resources:

 

EmberConf 2016: Cross-Pollinating Communities - We All Win

Chris Ball, of echobind,  gave a really great talk on Tuesday about the fusion and spread of great ideas among today's competing JavaScript frameworks. 

I just want to give a flyover of his big ideas here. My own observations are liberally mixed in.

The Quote

"Good artists copy; great artist steal."

The maxim above is oft quoted to correct what is commonly assumed about creativity. It is, as Chris stated, commonly ascribed to Steve Jobs, but there's a detective story to be told about the origins of this proverb.

Jobs did say this, but he was quoting Picasso when he did so. But Picasso may have been borrowing from a good friend he once painted, the composer Igor Stravinsky. The composer had said, "a good composer does not imitate; he steals."

But there's more. The great novelist of the South, William Faulkner said, "Immature artists copy, great artists steal."

"Steal good ideas and make them your own." - Chris Ball

The historical origins aside, these parallel proverbs remind us that we build on what has been built before us. We learn from the past. And the Ember project is no different.

Communities Ember has stolen from

There are a number of them. 

SproutCore was the original JavaScript MVC library. It had bindings, observers, get, setand computed properties. Yehuda liked that a lot. Nevertheless, Yehuda and Tom wanted to do more with it, and set out to make SproutCore 2.0. But it was decided that it would be a totally new thing, so it got a new name, Amber.js. But this named was used elsewhere, so it got a change of spelling.  Anyways, that was the moment.

From Rails , Ember borrowed the strong preference for convention over configuration, powerful tooling,  and very importantly, the concept of router.

From React, Ember has stolen and run with the axiom for components of, "data down, actions up." React also provided the concept of a virtual DOM.

From Backbone.jsEmber polished up its own API, making it more lightweight and descriptive, with names for hooks such as model, afterModel, and didRender. 

Communities that have stolen from Ember

But Ember lives among a community of thieves, and its own pearls have been stolen.

The React community is now building its own router, but one that is directly inspired by the Ember router.

And the AngularJS community is going to implement its own CLI based explicitly on Ember CLI.

Ways Ember has pushed great ideas

More than stealing, the Ember team and community have used the framework to bet on and propel some of the best JavaScript ideas forward.

Ember went big on JSON.

Ember embraced promises

Ember picked up the idea of web components and completely re-oriented the framework from 1.0 to 2.0 towards this concept.

Ember was the first major framework to utilize Babel and easily allow for building your apps with ES6 modules.

And Ember core team members now sit on the TC39 task group for ECMAScript, helping to guide the future of JavaScript and the Web.

We All Win

Chris segued to the end by quoting Yehuda that: 

"Successful communities toggle between 2 modes on the path to greatness." - Yehuda Katz

The 2 modes are (1) experimentation; and (2) sharing solutions. And this is true not just of communities, but developers, designers, engineers, companies, and products. I.e., everyone creating stuff and solving problems.

The truth is, Ember resides proudly in the open source world. It's not that we are stealing from each other to our detriment, rather we are borrowing, improving, and evolving the whole ecosystem. This means we developers win, our customers win, and our users win.

In conclusion, Chris exhorted all to take the following action:

  • Build on what has come before you.
  • Look at other communities.
  • Look at other industries.
  • Be shameless about "stealing" good ideas.

My own thoughts

I was excited to see Chris's talk listed when I first saw the schedule because the title captured my own feelings toward frameworks and libraries. I like Ember and enjoy using it. But we're open-source, and the best ideas deserve to win. 

What excites me about Ember is its openness to the best ideas. The Ember community is not afraid to steal, and besides tomsters, it doesn't hoard its own treasure. And that's a good thing.

Thanks to Chris for the great presentation! You can find his slide deck here.

EmberConf 2016 - Opening Keynote by Tom Dale and Yehuda Katz

Tom Dale (@tomdale) and Yehuda Katz (@wycatz), the Batman and Superman of Ember, did a stand-up job proclaiming the state of the union in Ember land.

They covered a lot of ground! Here I want to highlight the stuff that excited me. and capture some of the big ideas for my colleagues back home actually working! Note, my own observations and paraphrasing are liberally mixed in. 

The Growth of Ember

The community, influence, and use of Ember is growing significantly. Last year there were 600ish in attendance at EmberConf, and this year that number has grown to 950+. Last month, there were nearly 340K downloads of ember-cli. There are now 70.8K users of the Ember Chrome extension.

Of note, is the surging adoption of Ember 2.0+ and Ember CLI. Through survey, the Ember team learned that ~75% of the Ember community has moved to Ember 2.0+.

There are some notable companies that are betting big on Ember, including LinkedIn, the Dollar Shave Club, and PlayStation. Of course, you can also look at the list of EmberConf sponsors and see more big names. And just walking around I've met devs from recognized names in varying industries, such as Microsoft and American Eagle. 

Ember is impacting the wider development ecosystem. The Angular project is now implementing a CLI that is based on Ember's CLI.

Support for Ember is Diverse

Ember is not the work of a single, large company. There are real resources behind Ember from multiple companies such as LinkedIn, Yahoo!, CardStack, and Bustle. 

The Ember Core Team is diverse, and growing through the creation of area-specific sub-teams for Ember Data, Ember CLI, and learning. Each of these sub-teams will be guided by a core team member. In particular, I'm thrilled to hear that a team will be dedicated to learning Ember! 

Lessons Learned from 1.13

In my opinion, though at times eye-rolling and head-spinning, the Ember progression from 1.0 to 2.0 was capably managed, and in my own work, the experience of moving my project app over time from 1.7 to 1.13 was good. 

"Stability without stagnation." - Yehuda & Tom

Nevertheless, as Yehuda mentioned, mistakes were made, and lessons were learned on their side in this process. So, of note, is that Ember has implemented a Long Term Support system of releases. 

  • LTS versions will be every fourth release, so new LTS released every 24 weeks.
  • LTS will have bug fixes for 36 weeks.
  • LTS will have security fixes for 60 weeks.
  • The first LTS release was 2.4.

Ember Add-Ons

It is becoming easier to contribute to Ember and to use the contributions others are making. The ember add-on system is making this possible. The plugin APIs are being improved significantly and it is possible to impact Ember from the outside rather than having to contribute directly to Ember itself.

emberobserver.com is the place to dive in to ember addons.

ember-concurrency is an example of the great add-ons now being built for Ember.

A "jsbin" for Ember has been given to the world, ember-twiddle,  so that you can write your Ember bins with ES6 modules. That's pretty cool (and handy)!!

Onwards to the Web!

After addressing the growth of Ember and lessons learned from the past, they turned to address the current state of the web, and the problems affecting all of us as we build our apps.

"The web has clearly won on the desktop." - Tom Dale

So the web is victorious on our desktops. However, mobile devices reside in unconquered territory ruled by native apps. And some of these chunky, beastly things are aggravating to install. They have a high number of steps and back-and-forth screens to get from first browse to actual use. Pride of place on the scale of annoyance goes to Pinterest. Just go try it.

It was quoted that according to a Google study, 69% of users quit mobile web apps at the interstitial page forcing users to install a native app. Nevertheless, native apps are still the preferred way we are building for mobile. Web on the mobile sucks, and so it goes. 

The question then is, what is the way forward? How to do we change the prevailing practice? And how do we do that without the same amount of space for our web apps that native apps are able to utilize (the Pinterest app is something like 40MB)?

"How do we deliver native caliber features without giving up 'instant'?" - Yehuda 

There are many features already in mobile web browsers that we can use to our advantage, but using them is challenging. Many developers don't have time to utilize them, let alone master them. Examples include service workers, geolocation, app cache, camera, WebGL, IndexedDB, etc.

Ember to the Rescue!

Ember wants to make that easy by responding with the following solutions.

FastBoot will allow your app to render initially on the server allowing users to see content before JavaScript loads. This will mitigate all but the largest payload sizes. Ember FastBoot 1.0 and Ember 2.7 will ship at the same time. The Ember team is working hard with Heroku to make a great experience of getting an Ember app up and running, fast and and easy.

Project Svelte (mentioned way bay here and here)  will focus on reducing the framework size by removing deprecated features, and shipping Ember as ES6 modules. This will allow for the removal of unused modules and the ability to use only the modules you need.

Engines will allow users to split up their application code into separate bundles, and only load code for the part of the app when required.

String loading will allow users to ship JavaScript modules as strings, and only pay the evaluation cost for modules that are actually used.

Service workers will allow users to make their application available offline, give precise control over network requests, and preemptively fetch resources.

Glimmer

The Glimmer rendering engine shipped with Ember 1.13, and greatly improved rendering stuff in large arrays. However, there was significant regression in the rendering of components. The Ember 2.x releases have been addressing that problem, but there is a lot more room for improvement.

Glimmer 2.0 attacks this problem of rendering components. Yehuda here gave several demos (created by others) to demonstrate the significant improvement. The first demonstrated that Glimmer 2 is about 2x faster than Glimmer. And the second demonstrated rather amazing improvements in speeds from ~15 fps in Glimmer 1, to ~35 fps in Glimmer 2. Compare this to React which is about ~25 fps.

However, render speeds can still be way better, according to Katz. And he demonstrated the use of a new optimization that yielded speeds of ~ 60 fps. 

These improvements have been made by optimizing object models, and l templates in Glimmer 2 that are 5x smaller than Glimmer 1.

And there is more to be done, as the team knows how to improve speeds yet another 2-3x, but the work just needs to be done. 

Erik Bryn has provided the Ember conference web app, a demonstration of much of the above.

Ember to Change the Web

As mentioned before, there are many great technologies available today on web and mobile web which are simply not utilized well. Ease of use is key, and that's why many of these technologies remain ignored.

"Ease of use is key." - Yehuda

The duo declared that the goal is to make Ember the MacGyver of the web. Of course, not for folks to build things to blow crap up (ember-toothpaste-bomb)  ;-). Rather,  to attack the existing problems in using web, particularly in mobile, and revolutionize their use the same way Ajax made XHR easy and rocked the web a decade ago.

Ember: "An SDK for the Web" - Tom & Yehuda

Underlying this approach is the Unix philosophy of having a system which allows developers to build small apps that do one thing really well. That is a great analogy, and I hope that happens.

Thanks to Yehuda and Tom for a great opening keynote. Their leadership is appreciated both for pushing Ember onwards and for listening to the community.

Thanks to DockYard for a running, live bulleted list here. Tom and Yehuda have provided their slide deck here.

 

Creating a Domain and DNS for an AWS EC2 Instance

Super easy! That's how I would describe creating a domain and setting up DNS for your Amazon Web Services EC2 server. I wanted to create a new domain for my app, and then create a subdomain-like name for my current server to function as a beta test server. For example, it means I had an existing EC2 server operating at 10.10.10.10, and I wanted to create a domain for myapp.com, and I wanted my server at 10.10.10.10 to function like a subdomain and respond to requests for beta.myapp.com or www.betamyapp.com.

This process assumes several things. For one, that you already have an EC2 instance running. Setting up a free tier EC2 is amazingly simple. For this, I performed the following for a free-tier EC2 server running a Node app. Secondly, this assumes that you want to route directly to your EC2 server, rather than, for say, some other AWS service. And last, this assumes usage of Amazon's Route 53 service for handling DNS.

This does not try to provide comprehensive detail, for that, see the excellent documentation for Amazon Route 53.

First, navigate to the Domains dashboard: from the AWS Console, under Networking, click on Route 53 to bring up the Route 53 dashboard. Then, on the left hand menu click on Registered Domains. Click the Register Domain button. Choose a domain name and complete the purchase process. This will initiate the process, and you will have to confirm via email. This process will register your domain and automatically set up the needed hosted zones. In this case, let's assume I've registered myapp.com.

Second, review your Route 53 hosted zones. After registering your domains, within a few minutes you will receive confirmation that your hosted zones are ready. Navigate back to the Route 53 dashboard and click on Hosted Zones. Click on the name of one your hosted zones (i.e. myapp.com) and you should see the hosted zone details with the list of 4 name servers. To see the records for that zone, click on the Go to Record Sets button.

At this point, you have an EC2 instance server and a domain, myapp.com. But what we want is to route beta.myapp.com to our EC2 instance.

Third, now create a record to route requests for beta.myapp.com to your server. From the list of record sets for your hosted zone, e.g. for myapp.com, click on the Create Record Set button. This will bring up a box/form for creating a record. Enter a name for the record. You should see a Name box that provides a prefix to your hosted zone name, in this case, myapp.com. To create a record for myapp.com simply leave the Name box empty. However, in this case, we want to route traffic to our server at beta.myapp.com. So for Name, enter 'beta' and this will create a record name of beta.myapp.com. For Type, select 'A - IPv4 address' to create an A record. For Alias click No (you can't alias an EC2 instance). Leave the default TTL time of 300. For Value, enter your public IP for your server. For Routing Policy leave the default dropdown selection of 'Simple'. Now click Create!

Now you should see the new record in the list. Do the same thing and create a record for the name www.beta.myapp.com. It would be just as easy to create a record for myapp.com and www.myapp.com, but that's not what I wanted in this case. In just minutes, the created records will propagate and you should be able to ping or resolve beta.myapp.com in your web browser.

 

Chadamoore.com · Copyright © · Caveat Lector