CodeMash and Sparkbox make for a fantastic cocktail, and 2015 was no exception. Our fourth year attending as a team brought a motley crew of 12 Sparkboxers, including first timers Katie Kovalcin, Daniel Flynn, Divya Sasidharan, and Marshall Norman. No doubt we had lots of fun, but CodeMash 2015 had possibly its best session schedule as well.
The crew behind CodeMash deserves an incredible round of applause for putting on a great event with more sessions than ever before, and we were thankful to get to unveil our new Build Right: Frontend Testing workshop. We couldn’t attend them all—wish as we may—but here’s a roundup of our favorite events, talks, and takeaways, along with a challenge for organizers next year.
NodeBots
(writeup by Rob Tarr)
On the second day of CodeMash, Divya, Mike, Ryan, and I spent the day building NodeJS powered robots. Each pair (Mike & Divya, Rob & Ryan) was given a small kit: a platform, simple wooden wheels, two servos, an arduino, a battery, and some other small parts. We jumped right into building our robots. The goal of these robots was to push another robot out of the ring or control the center. We spent the next several hours designing, prototyping, and experimenting. We had no plans, only a handful of tools and limited materials. The task quickly became about sharing our ideas and concepts with each other. This proved to not be an easy thing to do, since it largely revolved around us holding up pieces of balsa wood and trying to explain the visions that we had in our heads. The experience made me appreciate the tools and experience that we have in our day-to-day work that helps us to communicate with each other.
In the end, we had some awesome robots that fought valiantly to the end. We may not have won, but we had a ton of fun doing it. It has also sparked talks of a Sparkbox-hosted Dayton NodeBots event for the summer of 2015—so stay posted.
“HTTPS in 2015” by Eric Lawrence
(writeup by Ryan Cromwell)
There are no shortage of reasons to use SSL for nearly all our web sites and services. Unfortunately for most of us developers, setting up and evaluating SSL configuration is fairly opaque. On Thursday morning, Eric Lawrence, creator of the famed Fiddler toolchain, gave a fantastic rundown of HTTPS in 2015. Of the resources and tips Eric mentioned, here are the ones I’m most excited to start leaning on at Sparkbox:
SSLLabs Server Test is my new go-to tool for validating the SSL configuration of our products. As you can see with test results for codemash.org, I suspect it’s going to open some eyes for the better.
LetsEncrypt.org is the result of efforts by Mozilla, EFF, and others. Though it won’t be available until Summer of 2015, it aims to simplify the configuration of SSL. Pair this with SSLLabs’ Server Test, and we have a great feedback loop.
HSTS is a Header that can be sent asking browsers to connect to the specified domain over SSL even if the user doesn’t specify HTTPS. With this in place, you can avoid obscure bugs like this one.
“Ethics and Effective A/B Testing” by Dusty Burwell
(writeup by Katie Kovalcin)
I have never formally done any A/B testing with my designs, so I was enlightened to see what the actual process was like for Groupon. It also made me think harder about specific things to test, and why. Dusty pointed out that some battles aren’t worth fighting (do you REALLY need to test border thickness?) and also just because something tests well does not necessarily mean it will achieve your long-term goals. I also found the idea of “layering” tests to be interesting—where you test one hypothesis on a user but have multiple tests layered on top of each other and gradually roll the favorable result out to more users.
I found the ethics portion of testing to be especially interesting, as it’s something I haven’t even considered. As Dusty pointed out with Facebook’s mood experiments, users don’t want to be manipulated. It made me realize I have to carefully consider how I work with users to ensure accurate results while still maintaining honesty.
“Modeling Your Applications Based on Airport Operations. Yes, Even the TSA Part.” by William Klos
(writeup by Mike Yockey)
It’s a difficult task to make queues sound interesting, but William Klos got us loving queues and even empathizing with the TSA a little bit Wednesday morning. William endeavored to get us to embrace queueing our inputs through the various parts of our systems, with the intention of reducing wait times. I am particularly interested in his suggestion to remove errors and exceptions from normal processing areas and use error-specific queues to both keep the happy path flowing and to not lose track of problems that have already occurred. William likened this to being shuffled between gate agents. Perhaps understanding this makes my next visit to the airport a little easier.
“Refactoring in Ruby: Finding the Right Job for the Tool” by Coraline Ada Ehmke
(writeup by Divya Sasidharan)
Most of us in the programming world are familiar with the dogma of Test Driven Development (TDD) and how important it is to write clean code. Coraline Ada Ehmke took this concept one step further in her talk and highlighted the role of testing in refactoring existing code—Test Driven Refactoring (TDR). Tools that run through code and check for code smells are plentiful; examples include static analysis tools like Code Climate and Coverity and continuous integrations services like CircleCI and Travis CI. Coraline argued that though these services offer feedback on our code, results are often cryptic and not as useful as they should be. In response to this complexity, she offered up her alternative, Fukuzatsu, a tool she built for measuring code complexity in Ruby class files.
Fukuzatsu runs through your code and checks for “cyclomatic complexity,” which is a fancy way of saying that it checks for the number of execution paths in your code. It runs through your code, removes lines of code line-by-line and checks to see if the program fails completely each time. She also added in her talk that code quality is largely dependent on code coverage, so looking out for code coverage is key to ensuring your code tests well. Covernor is a wonderful gem that allows you to test this.
A key take away from Coraline’s talk was that oftentimes, testing your own assumptions about how a method or a function works (especially if you’re using an external library or gem) is the simplest and most crucial step in the refactoring process.
“Docker” by Don Taylor
(writeup by Daniel Flynn)
Managing builds and deployments can be a scary, daunting task. With developers using a flurry of frontend and backend package managers, it is easy for servers to get out of sync. Don Taylor gave a great, logical walkthrough on how he came to use Docker at his job and the uses he has found for it. The workshop gave me good exposure to using Docker images and gave me a lot of great ideas how I can be using Docker here at Sparkbox.
I use npm for most of my projects and have seen a lack in version consistency bite me when bringing others into work, but using Docker’s distributed images may present a different way to handling dependency flaws. Having a distributed image that could easily be shared and managed both by frontend and backend dependencies (Ruby, Node modules, Gulp, etc.) could save me a lot of searching through npm cache and every version of anything on two servers. It is an exciting concept, and it will be great to start toying with it for my personal deployments!
“Building with Web Accessibility in Mind” by Bobby Whitman
(writeup by Adam Simpson)
Web accessibility is one of those topics that you can’t learn enough about. It changes just like the rest of the web, and it’s vital to stay up to date with the best options to connect with disabled or impaired users. A session on accessibility is hopefully not a talk where every slide is new information, but there are always new nuggets or wrinkles to take away. Here are a few of the things I took away that I want to incorporate into our work:
I need to remember to utilize the `alert` role on error messages and notifications throughout a site or app. Nothing super difficult here, but it is something that can slip through the cracks.
Bobby Whitman, the session speaker, brought up an interesting point that several disabled users have told him they often pull up the sitemap of a site to get a sense of the scope of a site. This just reiterated to me the importance of a good sitemap.
Along with having a good sitemap, Bobby proposed adding links at the very top of every page; one to skip to content and one to the sitemap.
Accessibility sessions aren’t going to revolutionize web development, but they are important, and I can’t wait to start incorporating these takeaways into our work at Sparkbox.
“Front-End Style Guides from 0 to 60” by Cameron Wardzala
(writeup by Marshall Norman)
As a frontend developer attending a conference with attendees largely in the backend camp, this session was a bit of an eye opener for me. Cameron Wardzala made me realize that something I think of all the time may not be on everyone’s mind. I should take into consideration when approaching a project that not every dev knows what I’m talking about when it comes to what I as a frontend dev, consider to be fairly basic frontend ideas.
A Frontender’s Thoughts on CodeMash
(writeup by Philip Zastrow)
I think I’m under-qualified to attend CodeMash. I have attended twice now, and each year I felt like I was drowning in a sea of computer science. Maybe I just hit up the wrong sessions. While there were sessions that touched on non-JS frontend topics, they seemed largely written for a deeper-level developer who needed a refresher on styling and UI techniques, instead of a person whose core competencies are the visual languages of the web—CSS and HTML. When it came to sessions that covered more language-centric topics, it seemed a degree in programming was a prerequisite, which left folks like me overwhelmed and burned out.
In a time where we are seeing the lines blur between designer and programmer, it was difficult feeling like such an outsider. If anything, I realized just how far the divide is between designer and programmer, and how much frontend developer is a synonym with designer.
Developer Spectrum
2015 CodeMash was an absolute blast. Our team had a great time learning, hanging out after the sessions, mini-bowling, waterparking, and all that we have come to love about this event.
A big realization from the week is that the Sparkbox view on the roles we play in building the web is not a common one. We tend to see all developers fitting into a place on the designer-to-programmer spectrum. While we recognize that CodeMash was created as a programmer-y developer conference, the one thing we’d love to see is more topics covered throughout the spectrum. The industry needs an opportunity to get all roles in the same room, discuss the challenges we all face, and realize how our decisions throughout the process impact the rest of our team. What better place to do this than an indoor waterpark in Sandusky, Ohio?
A huge thank you to all the organizers and volunteers for this year’s event. It was a great time, and we’re looking forward to 2016!
(opening by Ryan Cromwell and closing by Ben Callahan)
