Everything Else at Fluent Conf

In Pursuit of the Holy Grail: Building Isomorphic JavaScript Apps

Spike Brehm, @spikebrehm

Isomorphic JavaScript is code that can run on both the browser and the server. This can be achieved by writing code that is either environment agnostic (e.g. Handlebars.js) or uses environment shims (e.g. SuperAgent).

There are a lot of use cases where using isomorphic code can reduce code duplication:

• Templating
• Routing
• i18n
• Date & Currency formatting
• Model validation
• Web API interactions

There are already a lot of libraries that are isomorphic:

• Underscore.js
• Backbone.js
• Handlebars.js
• jQuery, believe it or not (there's even an npm jQuery module)
• Moment.js
• React
• Polyglot (i18n)

In addition to reducing code duplication, using isomorphic libraries can be used to increase performance by moving certain computations to the server (or to the client). This can even be done on the fly to adapt to varying performance constraints.

Programming Diversity

Ashe Dryden @ashedryden

This talk is especially relevant given recent revalations about Julie Ann Horvath's departure from GitHub. It was also one of my favorite talks at the conference.

So what is diversity? It's a lot more than just gender. It is about people of various backgrounds, experience, and lifestyles.

For example, we have often heard that women only make 80% of what men make, but how many people have heard that Latino women only make 59% of what white men make? This is after accounting for differences in job position, experience, geography, etc.

We also know that the unemployment rate in the US is around 8%, but did you know the unemployment rate for the blind is between 70 and 75%?

What is privilege, exactly? As Ashe puts it: privilege is the "unearned advantages for a perceived trait that puts that person in the "normal" or "default" group. Everyone has privilege in some areas, and not in others. It's nothing to be ashamed of, but it is something we should all be cognizant of.

A few other important terms:

• Stereotype Threat - concern where a person has the potential to confirm a negative stereotype about their social group
  • Internalization of the fear from stereotype threat can actually cause people act that way, even if they aren't predisposed to
• Impostor syndrome - a psychological phenomenon in which people are unable to internalize their accomplishments
  • Especially pronounced when combined with stereotype threat
  • This makes people less likely to apply for certain jobs, submit talks to conferences, or even just attend conferences
• Marginalized - a minority or sub-group being excluded, their needs or desires ignored
  • See: Moss-Racusin - Science faculty’s subtle gender biases favor male students
  • Even marginalized people do this to each other

Why is there a lack of diversity in tech? For example, women make up 24% of the industry, but only represent 3% of commits to OSS projects.

• Access to technology at an early age
  • On average, boys get their first computer at age 11, but girls don't get their first computer until age 14
• Computer ownership and internet access is much lower among minorities
• Access to quality of education, which is one of the greatest indicator of earning potential
  • Schools in poor neighborhoods have lower quality math and science programs
• Access to quality healthcare
  • People are generally unwilling to switch jobs if there is a greater risk of loss of healthcare
  • People of color, people with disabilities, and LGBTQ people generally have less access to health care
  • Women are more likely to be caregivers than men
• Attraction (people wanting to do it)
  • Geek stereotype (unpopular, white, skinny, glasses, beard, unsocial, etc) is hindering us
  • A person being being exposed to a single example of geek stereotype in school caused them to be 25% less likely to go into STEM
• Attrition
  • Women leave the tech industry at twice the rate men do
  • 56% of women leave tech within 10 years
• Harassment
  • People in marginalized groups are significantly more likely to be harrased at work
• Discrimination - differences in pay, career advancement, job offers, etc

As individuals, what can we do to help improve diversity?

• Education about diversity (such as this talk)
• Get to know people different from you
• Be vigilante about yourself and when you are marginalizing someone else
  • We all do it and it's rarely a conscious action
• Learn to apologize
• Talk about these issues openly
• Have the hard conversations when they are necessary, don’t shy away
• Change jobs, if necessary
• Strive to create open and welcoming company cultures
• Make sure companies are compensating equaly through use of statistical analysis of all employees within the company

On a final note: there are a lot of claims presented in this talk. Almost every single claim was backed up with a reference to a scientific study proving the claim. To find out more, check out the presentation.

Embedded JavaScript

Jon McKay @jonmckay

Jon McKay is a cofounder of Technical Machine, the group that created the Tessel, a competitor to the Arduino. The Tessel is a wifi enabled micro controller running JavaScript. Technical Machine believes that JavaScript is the ideal embedded language because of it's asynchronous nature. I'm inclined to agree with them, as evidenced by my own JavaScript powered aquarium.

The Tessel does some intersting things with JavaScript. They map JavaScript code to Lua and run it on a Lua interpreter on the device. They don't run JavaScript directly because all of the existing JavaScript engines are memory hogs compared to the Lua runtime, which matters when your device may only have 8 or 16 MB of RAM. They also do something clever by mapping processor interrupts directly to callbacks in the engine. This makes callbacks blindingly fast.

Unpacking Technical Decisions

Sarah Mei @sarahmei

The million dollar question when starting a new web project is: what JS framework should I use? There is abundant, often conflicting information out there, and picking the wrong framework can be disastrous for the project.

One of the most powerful ways that we learn as human beings is through repetition, but making these decisions is rare occurance. So we don't really learn how to make these decisions.

We can break down the decision into separate decisions that we do make more frequently. As it turns out, most technical decisions are not based on technical data, but social data (GitHub, Stack Overflow, Twitter, etc)

Each of these areas can be categorized as:

• Interface (prototyping code, README, tutorials, etc)
• Activity (commits, issues, PRs, etc)
• Popularity
• Familiarity (emotional compatibility with code/style)

The first three categories are pretty generic and universal, but familiarity is the odd one out. It is also (arguably) most important. The first three are pretty empirical and usually can lead to "the solution." It's the fourth one that muddies the waters, but also is what ultimately leads us to choose between Angular, Backbone, and Ember.

Familiarity is heavily influenced by current skill set and background, and, all things being equalied, familiarity means less risk.