Nodevember 2015 Day 1 - Sessions attended and observations made

Today was the first day of the Nodevember conference - and it was fantastic. I thought I'd take some time to go through the sessions I attended and what I got out of and/or experienced at each one.

Opening Keynote: Yehuda Katz

Yehuda started off talking about how there is so much pessimism in the technical community. So many people complaining about the problems we face, rather than being positive about what has already been accomplished and what amazing things we have yet to do. This, to me, was the highlight of the talk.

He then went on to talk about how one such positive is frameworks and that they free up a developer, or team, to focus on the specifics of the specific problem domain(s) they are trying to solve. This part of the talk then went into more of a "pitch" on Ember, which I feel was a bit of a missed opportunity that could have been put towards some more 'keynote-ish' topics. However, I'll choose to focus on the positive and accept the Ember focus as being in the spirit of how frameworks in general are a positive thing :)

From Node N00B to not so Node N00B - Rey Bango

Firstly, I'd like to say that this was my first time hearing Rey speak and I found him to be both a bit of a class act and a class clown :) He's good humored, witty, and a naturally good presenter. Before I go over what I found interesting about his talk, I'd like to talk about an experience I had during the first several minutes of his talk.

As all presenters do, Rey had spoken directly into the mic to kick off his talk and make it clear to everyone he was starting. Everyone, or nearly everyone, understood and became quiet to let things proceed as they are supposed to - with 1 person talking and all other people listening... Except for this guy right behind me that decided he could "whisper" and continue the conversation he was having.

At first, I just ignored it and tried to listen to the presenter over the loud whispers in my left ear. After giving it a couple minutes, in the hopes he would stop talking, I turned around and asked him if it would be ok if I just listened to the presenter. I wasn't a jerk about it, but made it clear that he wasn't whispering as quietly as he obviously thought he was.

I only mention this situation for this one point: Please be respectful to the other 2 types of people in the room - which are 1) the person trying to speak on a topic and 2) the person(s) who are actually interested in hearing what the speaker is saying. Now, back to the points of the talk that I found meaningful :)

Rey took an interesting approach to his talk. He essentially went over the pain-points he's hit while learning NodeJS. What I found cool about this is that he's a seasoned developer who has established a solid reputation in the industry, but he had no problem openly admitting that this has been difficult for him and he nearly threw in the towel a couple of times.

I know that I've found learning new technologies/concepts difficult at times, and had assumed that the problem was me - maybe I'm not as good as all the other devs who seemed to easily grok the concept, or maybe I haven't put in enough time studying, etc... But, maybe this line of thinking is incorrect. Here's the advice that Rey gave based on his experiences with learning Node:

Find a mentor - just because you're already strong in one technology doesn't mean you get a free pass to just jump into a new technology at senior status.
Real-world examples are of utmost importance - many Node tutorials are building a real-time stock-ticker or chat application. What about tutorials showing session management, or building node services? While some do exist, they are harder to find.
Immediately start working with some abstractions like Express - while you may eventually need to know how to handle routing and parsing route params yourself, there's no need to be that close to the metal when first starting out.
Learn the debugging story immediately - he went quite a while before he found that you can use node-inspector to debug node apps. Being able to debug your application makes the building process much better - whether you're N00B or expert...

Redux: Simplifying Application State - Tim Griesser

This talk was about the amazing things you can do with a little library called Redux. Tim's talk was pretty fast-moving (30 minute duration on all the talks), and he covered a ton of ground. Admittedly, much of it was over my head as I've not worked with flux (which redux is based on) and didn't know a lot of the terms he was mentioning. However, I can confidently say that looking into using more unidirectional data flows is something that is hot on my radar now :)

Building Microservices with Hapi and Redis - Jeff Barczewski

This talk was loaded with so much info - but presented in a way that was easy to follow and digest. I really love the approach Jeff took with presenting the pros and risks of microservices, as well as some strategy points for moving towards them. I appreciate an honest review that lists the hurdles you'll have to jump rather than ignoring them as if the architecture pattern is full of magical unicorns that simple solve all your problems :p Here are some high points:

Pros

Disperate hosts for programs and different languages/technologies for each service
Composability - think how you can pipe output from one thing to another in linux
Rapid change cycles - only the service(s) that relate to the problem area(s) need updated

Risks

Siloed knowledge - a service that's built in technology X will require someone knowledgeable in technology X, and since microservices are independent and can be written in entirely different stacks, this can become more pronounced than in monoliths
More difficult deployments and versioning (monolith first is good idea)
Difficult to know where boundaries are at first (i.e. what should be split into a separate service - again, monolith first may be the way to go)

I also learned that Redis is capable of far, far more than just a cache storage - it can handle message queues (think RabbitMQ, but "easier to set up" according to Jeff)

Offline Webapps - Mike Nitchie

Mike gave a really solid talk about how we have the power right now to give as good an offline experience as we want to put the effort into providing. He talked about some of the (many) pitfalls you'll run into when working with HTML5 Application Cache and how to handle them. He also gave a great breakdown of the different sections of the Cache Manifest file. I have used app cache a bit, so I didn't learn any new concepts - but it was a fantastic refresher :)

Username/Password are DEAD - Mobile all teh thingz! - Jacques Woodcock

This was a gem of a talk. Not so much due to the overall topic or presentation style, but one thing that Jacques said that struck me as quite special - I'll share it after these high points :p

Username and Password are cumbersome on mobile
Applications (whether it be banking sites or retail shop sites) implement policies that actually make it harder to set a secure password
Computational power has increased such that brute-forcing isn't hard or as lengthy a process at it was yesteryear
Wearables are the future and they are orders of magnitude harder to hack - can't exactly socially engineer them the same way you can to gain a network login, etc...
2-factor auth is the way to go - a phone # (each one being unique) that you can use to get a pin code to use to access a site - the code only being good for a set amount of time after it is issued

While all of this sounds spot on and 'easy enough' - I appreciate that he gave some real-world things you have to think about when implementing this, such as:

What if a person switches numbers or their phone is stolen?
If person A switches numbers and person B gets that number, how to keep person B from ever trying to access the site, getting a pin code sent to what once was person A's number and logging into person A's account?
Fallback - do not rely on this information of phone number and email address alone! Capture some other info that the customer can use to change the number on their acct, etc... but this should be more stringent than normal password recovery.

And here's the thing that he said that I thought was just great:

You ought to have a "can I do it while driving" policy when it comes to UX. If you can't do it while driving, then it is likely too complex/cumbersome. However, don't actually go try it while driving...

I paraphrased that - but you get the idea. This will stick with me.

Scaling Best Practices with Syntax Trees - Will Klein

This talk was the one where I feel I learned the most today. I loved several of the talks today, as you can likely tell by this writing, but I think that what I learned in this talk will have some pretty significant impact on my workflow in very short order.

Firstly, I went into this talk thinking it would be about best practices around scaling an application; after all, the title starts out as "Scaling Best Practices"... But, I was pleasantly surprised at how it turned out! He actually talked about how you can scale the way you communicate the "best practices" for a project or team!

I'm big on communication - I try to study people and learn their communication styles, make sure I communicate effectively, and make sure my communication style is easily understood. I like the details - not just that something was done a certain way, but why that way versus another way - this is just how I'm wired and how I learn best. So, when he started talking about strengthening how you communicate the best practices to follow on a project - it really hit home with me. I've been the new guy on an established project before, and found out in code review that there was a "known" best practice for something like structure, method positioning, naming convention, etc.... that I wasn't following - except I wasn't following it b/c those "known" things were never made known to me...

The way to do this is to use a pluggable linter that allows you to define your own rules - and this linter is ESLint. ESLint essentially looks for patterns you provide it, and it runs functions on items matching that pattern - but gives you the nodes in the form of syntax trees. These trees are easily traversed, so you can look for things like if blocks that are nested and could be combined, such as this:

if (firstCondition === true) {
  if (secondCondition === true) {
    doSomething();
  }
}
// should be written as:
if (firstCondition === true && secondCondition === true) {
  doSomething();
}

Oh, and dig this, you can then create unit tests that show passing and failing cases so it's crystal clear what the "best practice" in that situation is for the given project. It's just awesome, and it's highly likely to be the next thing I dig into during my off hours :p

Did you attend Nodevember and have any feedback on my observations? Feel free to comment or hit me up on twitter!

-Bradley