We’ve all been sold the tale that with one codebase we can support almost any platform you can imagine. After years of using these tools, nothing has really seemed to solve this problem well. Even when applications are built with tools like Phonegap, they never really “feel” right and fail to live up to native user experience expectations. Is this a fundamental failure of the idea “Write Once, Run Everywhere” or a failure of tooling?
In this talk I will discuss the future of building real mobile applications using web technologies, and the alternate idea “Learn Once, Write Everywhere”. You will hear about react-native, UX, Phonegap, Titanium, Trigger.io, and the future of mobile web applications.
The formula for a Bezier curve is beautiful. Using sine and cosine to create orbiting objects is dazzling. L-systems create fractals through elegant simplicity. Developers, as a group, may be losing site of the beauty that code can create. Designers by the bunch are picking up a keyboard and creating amazing pieces, but it’s happening the other way very slowly. That’s a shame, because the computer lets otherwise unexpressed ideas go unexplored.
Specific topics that will be covered throughout include:
Brokerless / brokered messaging
Designing for a generic compute note architecture
Using non-blocking io to speed up large jobs
When and how to split long running tasks
Using metrics to improve architecture and performance
The JS world is rich in gradually typed programming languages (TypeScript, Flow, and even ActionScript (sort of)). This talk will give some motivation for gradual typing and a brief history. Also a comparison of the kind of errors TypeScript and Flow will catch.
If you’re a front-end developer and you hate learning, you’re going to have a bad time. Over the past few years I’ve taught hundreds of people to learn to code. Along the way I’ve gathered invaluable insights into the way we learn and what helps us to learn most effectively. In this talk I’ll be discussing these insights and how you can more effectively keep up with the quickly changing front-end developer landscape.
The belief that design and development have competing interests can stand in the way of successful collaboration. In reality, the principles of good design often mirror those of good development.
In this talk, we’ll take a look at design skills that translate well into development, encouraging effective communication among members of both teams. By throwing away stereotypes and working together, we can harness the unique skillsets of designers and developers to push the boundaries of technology.
We need to turn the page on the idea that kids should learn programming by building flow charts. But this will typically be their first exposure if they start out in robotics.
Robotics is an exciting place to try out a programming idea because the surface area of your app, the part that interacts with the world, becomes immense. An idea that could be written off as passable UI or workable modeling might literally crash and burn when faced with interacting in an unforgiving world.
Social coding revolutionized how we share useful code with others. Bundler, npm, and Github made publishing and consuming code so convenient that our dependencies have become smaller and more numerous. Nowadays, most projects quickly resemble a Jenga tower, with layer upon layer of poorly understood single points of failure.
Despite our progress, we’d benefit from pausing to reflect on our relationship with open source. Convenience and ego drive most open source adoption, but these shortsighted motivations raise long-term problems we need to clearly identify if we can ever hope to solve them.
The web as a platform has historically made sharing code very difficult. However, thanks to ES6 modules this is a problem of the past allowing us to combine toolsets in ways we never could before. What happens when you take Backbone’s Models, Angular 2’s DI, React, maybe even some Ember Router then leverage them together in a project? The Frankenstein Framework. The time of “choosing a framework” is dead, compose your own frameworks today thanks to the power of ES6. (Webpack until ES6 is around for reals.)
React is heralded for its use in beautiful and intuitive user interfaces. It’s most commonly invoked as a pure view layer, where data management and business logic is handled by other means. However, when React is extended to encompass the facets of both the client-side model and controller, the result can be faster and more scalable than using React for the view layer alone.
One of the main reasons native apps are often chosen over web apps is that the web totally sucks in providing a decent offline experience. Come learn about the next step forward in the evolution of web app development where I will introduce the service worker and cache APIs which allow for creating robust offline (and concurrent) web applications.
In the early days of my career, things were simple. When it came to streaming media, real-time communications, and all things peer-to-peer, there was really only one choice: Flash. And as someone who knew how to wield Flash, life was pretty good! That is until HTML5, and its’ little buddy CSS3 came around. Suddenly there were options. Options that allowed developers to create a single application that would run on multiple devices. The whispers started. Flash is dying. Flash is dead. And then came WebRTC…
In this retrospective, we’ll look back at the beginnings of real-time communications on the web. We’ll discuss HTML5, and how it took Flash from being the King of the interactive web to near extinction. Finally, and most importantly, we’ll take a look at WebRTC, getting you up to speed on the very tools that put the final nail in Flash’s coffin, and ensuring you’re ready for whatever comes next!
Any team looking to improve its code should attend this presentation. Making a leap from object-oriented approach to reactive programming is too difficult, but you can make it step by step.
Web development pushes us to our limits, not only of cognition, but, perhaps surprisingly, of character. Using the cardinal virtues as a framework, we can see that developers need courage to learn, temperance to prioritize goals, a sense of justice by which to discern, and wisdom to act. By being honest about where we lack virtue, implementing steps to develop character, and resisting shame, we can perform TDD on ourselves. This process can help us grow not only as coders, but as human beings.