- CS 61AS — Berkeley self-directed Structure and Interpretation of Computer Programs course.
- Harbingers of Failure (PDF) — We show that some customers, whom we call ‘Harbingers’ of failure, systematically purchase new products that flop. Their early adoption of a new product is a strong signal that a product will fail – the more they buy, the less likely the product will succeed. Firms can identify these customers either through past purchases of new products that failed, or through past purchases of existing products that few other customers purchase.
- Google Material Design Lite — A library of Material Design components in CSS, JS, and HTML.
Enabling the creation of maintainable sites and apps that look great across a variety of different devices and contexts.
Choose your Learning Path. Our new Learning Paths will help you get where you want to go, whether it’s learning a programming language, developing new skills, or getting started with something entirely new.
CSS’ declarative model can be uniquely efficient, but requires an understanding not only of the features you want to use but the approach you want to take in decorating a document tree. That means understanding the document tree (and there may be many variations as you apply the same style sheet to multiple documents), the selectors used to identify points on the tree, the cascade that resolves conflicts among selectors, and the properties applied to that tree. Of course, the properties interact with each other and a shared model, so you’ll need to understand how the properties how to make those interactions produce your vision.
Bringing some of the benefits of face-to-face learning to millions of people without access to an in-person tutor.
Millions of people around the world — from aspiring software engineers to data scientists — now want to learn programming. One of the best ways to learn is by working side-by-side with a personal tutor. A good tutor can watch you as you code, help you debug, explain tricky concepts on demand, and provide encouragement to keep you motivated. However, very few of us are lucky enough to have a tutor by our side. If we take a class, there might be 25 to 50 students for every teacher. If we take a MOOC (Massive Open Online Course), there might be 1,000 to 10,000 students for every professor or TA. And if we’re learning on our own from books or online tutorials, there’s no tutor or even fellow learners in sight. Given this reality, how can computer-based tools potentially bring some of the benefits of face-to-face learning to millions of people around the world who do not have access to an in-person tutor?
I’ve begun to address this question by building open-source tools to help people overcome a fundamental barrier to learning programming: understanding what happens as the computer runs each line of a program’s source code. Without this basic skill, it is impossible to start becoming fluent in any programming language. For example, if you’re learning Python, it might be hard to understand why running the code below produces the following three lines of output:
A tutor can explain why this code prints what it does by drawing the variables, data structures, and pointers at each execution step. However, what if you don’t have a personal tutor?
Anytime is a good time to refactor your code.
Java 8 has a few new features which should help you write more dynamic code. Of course one of the big features was the addition of a lambda syntax. But what about some of the other features that were added? Here are a couple of things that I tell people to do in order to make their code more dynamic and more functional.
WebAssembly – wasm – skips that final step, producing a binary format, technically a compressed AST encoding. Unless you’re going to be building compilers, you can compare wasm to a bytecode system. There is a text format for debugging, but the binary emphasis yields substantial extra speed as it skips parsing and minimizes decompression.
Learning from the Fluent Conference.
At Fluent 2015, we brought together a variety of stories about front-end engineering – some technical, some social, some more intricately intertwined.
From the very first day, it was clear that React was the big technical story of the conference, taking the place that Angular (which is still clearly important!) had had the previous year. Tutorials and sessions were busy, and I kept hearing conversation about React. Sometimes it was “what is React supposed to do?” but other times people were talking about exciting corners of React Native or techniques for integrating React with a variety of frameworks.
React makes me happy because it solves the problem a lot of people didn’t quite realize they had. Suddenly they are very enthusiastic about stuff that used to be really annoying. The Document Object Model (DOM) has been the foundation of most of the interactive work on the web since 1998, but it wasn’t very much fun then. As developers really get deeper into these things, the DOM has not exactly been a crowd-pleaser. In some ways React is a wrapper for the DOM, and in many ways it’s a just a better way to interact with the document tree.