- Where Do All The Women Go? — Inclusion of at least one woman among the conveners increased the proportion of female speakers by 72% compared with those convened by men alone.
- The Ultimate Electronics Hobbyists Guide to Shenzhen — by OSCON legend and Kiwi Foo alum, Jon Oxer.
- Bitcoin’s Uncomfortable Similarity to Some Shady Episodes in Financial History (Casey Research) — Bitcoin itself need serious work if it is to find a place in that movement long term. It lacks community governance, certification, accountability, regulatory tension, and insurance—all of which are necessary for a currency to be successful in the long run. (via Jim Stogdill)
Web technologies have become the default, and are spreading
A few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:
Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.
That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).
Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.
On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.
Look beyond jQuery to an MV* approach
You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.
Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.
A solid foundation on which more meaningful learning can happen
As someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”
Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”
The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).
On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.
6 highlights from Axel Rauschmayer's webcast
- Layer 1, Single object. [at 3:55]
- Layer 2, Prototype chain. [at 14:52]
Layers 1 and 2 together form a simple core, which you can refer back to if confusion sets in. This way you can re-ground yourself at any point in the foundations of the course.
Using closures in a different way
this references can often be totally unrelated to the lexical scope of a function. To work around that we often see tricks like:
var that = this;
this. Sounds crazy? Let’s see.
Disposable robot assassins and spreadsheets
Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.
Bowkett explored many options and iterations of his automation ideas,
- The roots: Martin Fowler’s classic Refactoring. [at 00:50]
- “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
- Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
- “More complex information… surfacing an implicit object model.” [at 7:45]
- Filter scripts and text streams [at 14:45]
- “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
- Building on JSLint [at 20:10]
- “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
- Grepping through git history [at 32:53]
- “Automatic refactoring will let you get to better code much faster.” [at 36:25]
It’s an amazing mix of capabilities that let you build your own robot (code) assassins.
Some key parts of Todd’s talk include:
- What is TypeScript? [at 01:48]
- A demo of TypeScript [at 05:14]
- A look at how typing helps [at 06:40]
- How classes in TypeScript work [at 16:20]
- The TypeScript ecosystem / community [at 21:53]
- TypeScript 0.9 [at 25:48]
- A look at generics support [at 29:18]
- TypeScript in the context of a full app [at 34:40]