Node Night + Advanced NodeSchool Recap

This past February 26, Fluencia hosted Node Night + Advanced NodeSchool as part of NovaNode and NodeDC. The community of people working with node in the DC area is strong and growing, and we love to learn together. We had a great turn out.

We had a number of newcomers dive into the NodeSchool Core workshops lead by Dan and Aaron. We tackled the LearnYouNode workshop, which proved to be a challenge for even the more experienced developers. This workshop reminds me that you can never be too much of an expert to go back to the basics.

Others broke into small groups focused on specific NodeSchool electives. Topics included but were not limited to:

  • Functional Javascript
  • ExpressWorks
  • Promise It Won't Hurt
  • Async You
  • Browserify Adventures

It was great to see everyone. NodeSchool provided a great framework to allow people to quickly learn something new. Check out all of the NodeSchool workshops.

Thanks to all who attended! We are looking forward to the next event.

Beyond the Classroom: Lessons from a Real World Software Engineering Internship

I’ve heard the complaint from more than one full time developer, recruiter, or classmate: modern computer science degrees don’t fully prepare students for a job as a software engineer. This is partly by design; especially at large research universities like UVa, a BS program emphasizes theory and broad exposure to different subdisciplines in the field. In an academic setting, it’s difficult to keep up with the latest trends in a fast-changing industry, so sticking to tried-and-true curriculum is a safer bet for equipping students with a foundation to succeed.

However, many CS students are seeking software developer positions but lack experience developing outside of the academic sandbox. This is where internships can train students in the practical skills needed to become an effective software developer.

So what is there to be learned beyond the classroom? This post only skims the surface of some real-world lessons I learned at Fluencia this past summer.

1. Use agile development to facilitate teamwork and take small bites out of a big project

The mere mention of group work at school can elicit exasperated sighs when each group member has to balance a full course load, multiple extracurricular responsibilities, part time job(s), job searches, and more. In the real world, the whole team is located in the same room all day and readily available to work toward a common goal. Using scrum at Fluencia has made working in a team even more effective, by breaking our large goals down into manageable tickets and keeping the team flexible to respond to user or product owner feedback.

2. Learn with one-on-one attention from experienced full time developers

With a whole class of students vying for the attention of a much smaller group of instructors and TAs, getting frequent one-on-one attention is often not possible at a big university. During my internship on Fluencia’s small team, I was been able to receive individual mentoring to hone my coding skills. With code reviews required for every pull request, I improved my ability to think through a problem end-to-end, execute my solution cleanly, and prove that it works with thorough test coverage, thanks to feedback from full time engineers. The opportunity to pair program with more experienced developers also exposed me to useful workflow tips and approaches to solving problems.

3. Develop good habits to make life easier down the road

Unlike at school, where a project’s lifespan is usually a couple weeks to months and the result can be abandoned at the end of the semester, in the real world, you’re committed to your code. Both getting oriented in the team’s existing code and returning to code written by myself earlier in the summer drove home the importance of writing code that is meant to be read. To produce code that is maintainable and easy to understand, I learned to favor clarity over ‘clever’ syntax and write useful names and comments for my branches and commits.

4. Stop reinventing the wheel

Some assignments require students to code classic data structures in order to learn how they work, their strengths, and their limitations. In a real world project, the goal is to spend less time creating things that others have already created, and instead leverage the plethora of libraries and APIs that already exist to build something new. Working with a full time team has given me insight into the decision process of whether to add dependencies and which libraries to use, and forced me to get comfortable learning how to integrate those libraries into my own work.

5. You’re not alone! Join the community

My college habit of lonely, late nights sifting through StackOverflow have given way to a much more exciting method of learning from other programmers: getting involved in the community. The team at Fluencia encouraged me to attend local meetups and hackathons, and set an example to aspire to by presenting talks in front of the DC community of developers. They pointed me to some great online resources for learning and continue to grow the Fluencia engineering online presence. One aspect of software engineering that keeps me engaged is that it is constantly evolving, and keeping pace with other developers using the same languages and tools makes the job exciting - and often easier!


6. Make an impact

Many school projects involve an imaginary client or user; but the work I did at Fluencia this summer has reached millions of real people. For me, one of the most rewarding parts of taking on a real world development internship is being able to take all the theory and practice from school and turn it into something valuable. At Fluencia, I’ve developed a sense of accountability for my work, because I know that what I’m working on matters beyond a school assignment’s deadline.

Are you a student or recent grad making your first forays into software development in the real world? What kinds of things have you learned off campus?

How We Redesigned SpanishDict is the world’s largest Spanish-English reference website, rated by Quantcast as a top 250 most-trafficked site in the US, growing at a healthy 10-20% per year, and reaching more than 10 million people per month. You can even Google "spanish" and find it as the first result. So why did we decide to radically overhaul the design?

SpanishDict Rankings

"Plain. Boring. Busy."

We had conducted user testing sessions where people said things like, "I love the content on the site, but it's too busy and kinda plain." Here's a short clip illustrating the problem:

Data from our site surveys reinforced these anecdotes. People loved our content and lamented the design. Users knew the site design was sub par, and frankly, so did we.

Why a Full Redesign?

The site wasn't built to be complicated. But in the years since our previous redesign, bit by bit, new features crept in. We added announcements for our learning platform, calls to action for our word of the day emails, pleas to follow us on social sites, and ads for our mobile apps. The site took on a Frankenstein look as we added more appendages. To go from complex and disjointed to elegant and simple, we had to make big changes.

The Goals

We designed our goals and metrics before we designed our mockups. Here's what we decided to shoot for:

Overall Goal:

  • Users react with “Wow - I love this site!”


  • Engagement - Pages per visit; Repeat visits
  • Wows - Survey data on our Net Promoter Score; Positive Comments in Usability Sessions
  • Revenue - No short term impact on ad impressions or revenue

We wanted to make a great first impression--the wow--and then deliver an experience that people loved. We'd look for evidence of success in people's comments--net promoter score, user testing videos--and in their behavior--more return visits and greater engagements. Finally, we'd aim to have no short term impact on revenue. Over time, a site with happier users will be a site with more users. We decided to play the long game on revenue.

Redesign Priorities

A design is an expression of priorities. We aimed to make it easy for users to accomplish their goals. But across 10 million unique visitors per month, people have different goals. So we used Google Analytics to figure out what features people actually use, and what they don't. We combined that with qualitative data from user support emails, usability testing, and conversations that we have with people that use the site.

For our site, one feature is more important than all others--people want fast, accurate, and easy-to-use Spanish-English translations. So that was our #1 priority. But we also find that people want verb conjugations, help with vocabulary, answers to grammar questions. These secondary actions needed to be easy to accomplish, but didn't need to take a starring role.

At the same time, we have actions that we'd like people to take when they are on our site. For example, we'd like them to learn Spanish with our new adaptive learning program, Fluencia. We like people to share content. We want people to download our mobile apps. We have a number of calls to action throughout the site. We decided to make these calls to action secondary to the user goals. Here's a summary of how our priorities shook out:

  • #1 - Simple, Easy Translations
  • #2 - Everything else

Design Brainstorm

The two most critical pages on the site are the homepage and the search results page. We needed to nail the design on these two pages first. We kicked off the process with a big brainstorm of possible layouts. Here's a look at a few early layout ideas for the homepage header:

They are rough! But that was intentional. We wanted to share concepts quickly, gathering feedback from our own team through InVision on the structure of the site.

Pixel-Perfect Designs

From there we converged on one layout, and started working to make it pixel-perfect. More mockups. More feedback. Each time we got closer to a final design.

We liked this design because we found it to be:

  • Easy - Big obvious search; fewer options in the menu.
  • Beautiful - Dictionaries aren't sexy, but places where people speak foreign languages are; the photo added pizzaz.
  • Different - No dictionary site looks like this; it stands out.

We took this design aesthetic and expanded it to the rest of the site, creating designs for dozens of pages:

We also wanted to inject some delightful details. We faded in the background image, added a geolocation icon with more information on the photo, and added a fun animation in the footer.


We worked on implementing the new design over the next couple months. In the process we replaced a legacy PHP application with a modern Node.js application to make it easier to develop enhancements in the future, provide better testing coverage, and bring the application inline with the tools that we use on Fluencia.

We wrote unit, front-end, and integration tests throughout the project, which we run on a Travis continuous integration server.

We also tested the front-end performance, using best practices recommended by Google Pagespeed and SpeedCurve, combined with Real User Monitoring from Pingdom.

We audited every key section of the site for SEO best practices, including targeted title tags, helpful H1, and rich relevant body content.

Finally, we conducted extensive cross-browser testing. SpanishDict reaches a broad swath of the Internet. We defined the browsers that we wanted to support based on our user analytics, and conducted tests using our mini in-house device lab.

User Testing

As the site came together, we conducted a number of hallway usability sessions, asking people in the office to try out new features and various UIs. We also conducted more than a dozen usability sessions using UserTesting. Some of the comments we heard were "It's beautiful. I really like the simplicity.", "I also like the sleek design of the website, it has a "clean" look to it that allows for a more enjoyable page view.", and "The site is really attractive. The layout, text, graphics, videos and navigation are great." Here's a short highlight video:

We learned we were heading in the right direction. We also found a number of areas that could make the site even better.

The Roll Out

With a change this big, affecting so many people, we decided to roll out the redesign gradually and turn the release into an opportunity to run an A/B experiment, comparing the old design to the new one.

We started by rolling out the site to just 1% of our traffic. We wanted to identify and squash bugs, ensure our analytics systems were working properly, and gauge the initial reaction. With the data showing positive early results, after the first week, we released the site to 10% of users, then 50%, then everyone. As an A/B experiment using random assignment, at each stage we could also measure the impact on the new design on metrics we set out to improve.

The Results

According to Google, pages per visit increased 7.5%, time on site rose by 5.24%.

We also ran our user survey again, and found that people's satisfaction with the site had increased significantly.

We were also happy to learn that even though we removed advertising inventory from the top of the homepage, the increased pageviews per visit more than compensated for the decrease in ads.

Continuous Improvement

By virtually all our metrics, the redesign was a success. But we built into the design systems that allow us to continuously improve. We added a simple feedback button that goes to our Desk customer service center. We read and respond to nearly all feedback within 24 hours. We also included a simple, one-click “Did we answer your question?” to gather data on search results that need improvements. Finally, we instrumented the site with analytics tools to measure user behavior. These sources provide feedback and inspiration for future updates.

Have any questions about the redesign or suggestions on ways we can improve? Let us know in the comments.

Making robots to do our bidding with Node.js

Node powers almost every piece of user-facing software we develop and we enjoy using it every day. But we also like to stretch our imagination and find applications for node that are outside the mainstream.

Enter Nodebots Day 2014, an annual event held around the world that brings together people who love node and are excited to use it to interact with the physical world and make robots do their bidding.

Fluencia hosted the DC edition of this year’s event at our headquarters. This post will serve as both an introduction to nodebots and the johnny-five framework, and a summary of the highlights from the day for those who couldn’t make it. Let’s go!

Getting started with johnny-five

The johnny-five framework – named after the robot protagonist of the 1986 film Short Circuit – is an open-source library and npm module that provides an interface for writing JavaScript that the microcontroller can understand. It works out of the box with Arduino, but plugins are available for Raspberry Pi, Spark Core, and many others.

npm install johnny-five

Now, create your first Hello World! Make sure you have Node.js and npm installed, and follow the instructions on the johnny-five README to get up and running. Write a file called helloworld.js:

var five = require(‘johnny-five’), // Here’s Johnny!
    board = new five.Board();

board.on(“ready”, function() { 
  var led = new five.Led(13);     // LED connected to pin 13

Connect your Arduino to any USB port and run the program with node helloworld.js. In a few seconds the program will connect to your board and the LED will start blinking. Hello World!

But that’s not all. You also have access to your very own REPL (read-eval-print loop) session, which allows you to interact with the board directly from the command line. Inject the REPL within the board “ready” handler, for example:

  led: led

Then you can run commands like led.on(),, and led.strobe() in real time.

We’re just getting started

This is all pretty cool already, but there’s much more you can do to harness the power of node for your bot.

Node is great for creating http servers quickly and easily. With the express framework, it’s even easier to write a simple server that listens for requests and do something when it receives a request. Imagine if we could remotely control our nodebot through a web browser from anywhere online.

Install the express framework with npm install express and use it to spin up a server and listen for GETs on the /turn route. For example,

var express = require('express');
var app = express();
app.get(‘/turn’, function(req, res) {


A program as simple as this allows you to control your robot by visiting http://localhost:3000/turn. This is awesome, but the app has to be running on the same machine that is connected to the Arduino to communicate with it. Not exactly remote control.

There is a solution to this, too. We can create a tunnel into localhost and expose the program to the internet. Several programs are out there to allow just such tunneling, and ngrok is exactly what I was looking for.

Install and run ./ngrok in the root folder of your project, and it will assign a randomly generated URL such as which tunnels directly into your localhost. Now anyone on the internet can visit this URL to get access to your locally running application. I wouldn’t recommend this for a production level app, but for testing and hobbying it works great!

Look at the awesome things we built

Here’s a sampling of some of the projects that came out of Nodebots Day DC 2014.

Morse code nodebot

This nodebot is a master morse code translator, taking in any string and converting it to a series of long and short buzzer beeps, by @mcwhittemore.

Button boxing game nodebot

Making use of only a few parts, this project used 7 LEDs, 2 pushbuttons, and a few wires and resistors, and quickly became the most addicting and exciting game of the day, by @daiweilu and @wind_memory.

Fork it and make your own!

Twitter nodebot

This nodebot connects to the Twitter Streaming API to blink and beep whenever anyone tweets @nodebotsday, by yours truly, @danielpazsoldan.

And many, many more!

There was an Xbox Kinect nodebot that mimics your arm movement, a nodebot that could tell you the traffic in your area, and there was the makings of a nodebot tank. But we just couldn’t capture all of the awesome projects.

We had a good turnout and everyone had a great time. The day was full of brilliant ideas, wonderful company, and the first steps toward JavaScript robot domination - a success in my book. Special thanks to Caroline Woods at Fluencia, and Matthew Whittemore and Chetan Shenoy at Social Tables for organizing a unique and awesome event.

What can you build using node and johnny-five? Show us what can you do, and see you at next year’s Nodebots Day!