As JavaScript applications continue to grow in size and complexity, the teams that develop and support them often find themselves looking for ways to help increase productivity and reduce errors. A well-known practice for reducing coding errors is to employ unit testing. A more recent approach is to add static typing to JavaScript by utilizing technologies like Microsoft's TypeScript or Facebook's Flow.
Adding static types to JavaScript helps developers to detect errors in their code at design time, without having to execute their code. Static typing dramatically improves the overall development experience by adding support for symbol-based navigation, statement completion, and code refactoring.
In this talk, we'll walk through a series of demos showcasing how TypeScript and Flow bring static typing to JavaScript. We'll look at how they are similar, how they differ, how they can help you write better code, and how they won't. By the end of this talk, you'll be on your way to answering the question "are static types a good fit for my JavaScript project?"
Topics include:
- Comparing static and dynamic typing
- Reviewing the benefits and disadvantages of static dynamic
- Leveraging TypeScript and Flow in your projects
- Comparing TypeScript and Flow
Let’s face it, you’re only human.
Nobody sets out to make mistakes. But as human beings, we’re inherently flawed, so mistakes are inevitable. As a software developer, it can feel like the odds are increased exponentially. There are countless ways for projects to go awry.
In my 17+ years of development experience, I’ve worked on small and large projects, solo and on teams, utilizing a wide variety of technologies and platforms, across many different industries. If there’s a way to mess something up, I’ve probably done it.
In this talk, I’ll share with you some of the software development traps and pitfalls that I’ve encountered in my career. I’ll tell you how they happened and what we did to get out of them. We’ll look at ways to identify these problems as early as possible. Or better yet, how to avoid them altogether. Learn from my mistakes.
Topics include:
- Poor or missing requirements
- Boiling the ocean
- Gold plating
- Failing to track changes to the project
- Not writing unit tests
- Not documenting decisions
- Not supporting new team members
- Not tracking or triaging new features or change requests
- Failing to use realistic test data
- Failing to automate at the beginning of a project
- Not tracking all of your source code
- Failing to communicate across the entire organization
- Not being realistic with estimates
- Not regularly reporting progress
- Creating silos of responsibilities or knowledge
- Not adopting a coding style
- Fixing another developer’s code instead giving them feedback
James is a self-confessed geek, who enjoys talking about programming and learning new technologies. At the beginning of 2016, he joined the Treehouse team as a teacher and is excited to have the opportunity to help beginners become developers. In addition to his teaching responsibilities at Treehouse, James hosts a biweekly show called the Dev Team Show (https://teamtreehouse.com/library/dev-team-show) where he leads conversations about development with a guest. James also recently presented two live streamed training sessions as part of Microsoft's Visual Studio 2017 Launch event and enjoys participating in the developer community, presenting talks in Oregon, Washington, Idaho, Utah, Tennessee, and Kentucky.