One of Agathon’s core values is a commitment to learning. Because of that, we encourage (and sponsor) employees to attend conferences that suit them. Jeff recently attended JSConfHI and shared these insights from the sessions he attended:
JSConfHI was held in Honolulu, Hawai’i, just 30 minutes from my home. The talks ranged from using the browser as a networked video synthesizer to debugging asynchronous activity for Node.js.
Here are a few of the the takeaways that stood out to me:
Building up the Electron project by Jessica Lord
Jessica is a former engineer at Github. She was part of the Atom team, where Electron was a dependency used in the creation of Atom. And that’s all Electron was supposed to be—a dependency. (In fact, it’s original name was simply atom-shell). However, Jessica saw the huge potential in Electron.
When building native desktop applications, you generally need to hire three teams to build the same application for three different operating systems: Mac, Windows, and Linux; hiring just one team and focusing on one operating system means you’ll only reach a fraction of your potential users. What Jessica saw in atom-shell was the ability to create desktop applications with web technologies—JavaScript, HTML, and CSS—enabling one team to create an application for all three operating systems.
The majority of Jessica’s team didn’t really care for atom-shell. But nevertheless, she persisted. Eventually, she was able to gather up a team to convert that dependency—atom-shell—into the full-blown library we now know as Electron!
Adopting TypeScript at scale by Brie Bunge
Brie is a software developer at AirBnB who helped convince her whole team to gradually adopt TypeScript, a superset of JavaScript. TypeScript adds static typing to what is otherwise a dynamically typed language.
Key points from her presentation:
- An AirBnB postmortem analysis showed that 38 percent of bugs would have been preventable with Typescript
- The project had 15 percent total fewer bugs after adopting Typescript
- Both had roughly the same build times
In the end, Brie is happy to report that AirBnB is in the process of migrating into TypeScript across all of their products!
How to not fail at accessibility by Trish Ang
Trish Ang is currently a front-end engineer working on an app we all know and love: Slack. She had just submitted her first big feature, a huge moment for her. And then her coworker pinged her to let her know the feature was not screen reader-accessible.
“Accessibility bugs are broken functionality and product blockers.”
According to Trish and her team at Slack, if your website is inaccessible, that means that real humans on the internet cannot use it.
Thankfully, there are the WCAG (Web Content Accessibility Guidelines). These guidelines explain how to make web content more accessible to people with disabilities.
Briefly, here are the four things Trish covered regarding accessibility:
- Color Contrast: the information and interactive elements are perceivable and understandable.
- Support User Interface Zoom: the site reacts properly at various browser zoom settings.
- Keyboard Navigation: the site is fully accessible with just the keyboard.
- Screen Reader Support: screen readers can properly read the content. (To easily test this out, turn on VoiceOver in accessibility settings on a Mac.)
How to make your website not ugly: basic UX for programmers by Hilary Stohs-Krause
Hilary is a former journalist, now a full-stack developer at Ten Forward Consulting. According to Hilary, design is about usability, credibility, and interest.
Here is a brief summary of what she covered:
- Words: Make speech visible.
- Let your text breathe. 60-100 characters per line, about 1.4 line-height and at least 15px for padding.
- Make your text legible.
- Make your text scannable. Highlight key content, subheads, and bulleted lists.
- Make speech visual. Usually 2-3 typefaces and 2-3 colors. Complex fonts for headers, more basic for content
- Images: Use appropriately.
- Icons: Labels are the rule, not the exception. Icons work best in navigation/menus. Avoid icons with conflicting meanings.
- Photos and graphics: Only use relevant images and integrate with your content. Image overload turns into banner blindness.
- Design: Think logically.
- User patterns: Alternate between small, medium, and wide. Find something that works and use it as a model.
- Progressive disclosure: Maintain the focus of the user’s attention—more specifically, the F-shaped reading pattern. Avoid putting key content in traditional ad areas.
- Be consistent with location and design.
- Functionality is part of design: Bugs trump beauty.
As a remote developer, I really look forward to our bi-annual retreats and the opportunity to be in the same room as our talented developers and soak up their knowledge! A tech conference is similar but at a bigger scale. The hardest part is trying to retain everything you’ve learned, and taking notes is invaluable! (Not every talk is going to have their slides available online. 😁)
Not all tech conferences are the same, and it’s hard to say which ones are actually worth going to. But if it’s an economical option for you, or if you’re lucky enough to have your company sponsor you, be sure to take advantage of the opportunity for the chance to interact with and learn from others!
What conferences do you find most valuable?
We’d love to hear about the conferences you attend!
Jeff enjoys writing clean, readable code, reviewing and refining existing code, and collaborating with other developers to solve problems. He loves finding new, efficient ways to code and solving issues that seem sticky at first.