#Rust2018 – Exploring New Contribution and Feedback Models

Since I’m coming pretty late to the #Rust2018 party, most of the things I wanted to say have already been said!

Ashley’s kick-off post was kind of a meta-#Rust2018 for me, calling for us to experiment with new ways to get community feedback in Rust. I personally really enjoyed all of the energy in #Rust2018, and hope that we continue to experiment on this front.

I really loved Julia’s post, both for enumerating so many ways that Rust has become easier to use since last year, but also for showing that marketing Rust to people who have never written low-level code before need not conflict with marketing Rust to people who want a better C++ (and other audiences too!).

I liked both Steve’s post and Nick’s post for showing that we’re already on track to have a great 2018, as long as we stay focused on shipping and Continue reading “#Rust2018 – Exploring New Contribution and Feedback Models”

The Facebook Patent License Punishes You For Suing Facebook, But Lets Them Sue You

There’s been a lot of discussion recently about the Facebook patent clause (“PATENTS” in Facebook repositories).

While most of the objections to the license have focused on the patent revocation provisions, most of the defense focuses on the patent grant. This has meant that both sides are talking past each other, and casual readers are getting confused about what this is all about.


The Facebook patent grant comes with a revocation clause. It is meant to protect Facebook from patent lawsuits in general. It applies to Facebook’s patents, and therefore the revocation clause does not apply to Facebook itself (by definition). Your license to Facebook’s patents in order to use the OSS is revoked if:

  • You sue Facebook for patent infringement, or
  • You sue someone for patent infringement for using a Facebook product or service, or
  • You sue someone for using the OSS software

Notably, it does nothing to punish Continue reading “The Facebook Patent License Punishes You For Suing Facebook, But Lets Them Sue You”

The Facebook Patent License Punishes You For Suing Facebook, But Lets Them Sue You

There’s been a lot of discussion recently about the Facebook patent clause ("PATENTS" in Facebook repositories).

While most of the objections to the license have focused on the patent revocation provisions, most of the defense focuses on the patent grant. This has meant that both sides are talking past each other, and casual readers are getting confused about what this is all about.


The Facebook patent grant comes with a revocation clause. It is meant to protect Facebook from patent lawsuits in general. It applies to Facebook’s patents, and therefore the revocation clause does not apply to Facebook itself (by definition). Your license to Facebook’s patents in order to use the OSS is revoked if:

  • You sue Facebook for patent infringement, or
  • You sue someone for patent infringement for using a Facebook product or service, or
  • You sue someone for using the OSS software

Notably, it does nothing to punish Continue reading “The Facebook Patent License Punishes You For Suing Facebook, But Lets Them Sue You”

The Glimmer VM: Boots Fast and Stays Fast

Great web applications boot up fast and stay silky smooth once they’ve started.

In other contexts, applications can choose quick loading or responsiveness once they’ve loaded. Great games can get away with a long loading bar as long as they react instantly once the gamer gets going. In contrast, scripting languages like Ruby, Python or Bash optimize for instant boot, but run their programs more slowly.

To optimize for boot time, scripting languages use interpreters and avoid expensive compilation steps. To optimize for responsiveness, games pre-fill their caches and do as much work up front as they can get away with. The web demands that we do both at the same time: users coming from search results pages must see content within a second on modern devices, but also demand 60fps once the application gets going.

Over the years, web browsers have responded to this requirements with more JIT tiers

Fast Updates in Ember

Continue reading “The Glimmer VM: Boots Fast and Stays Fast”

The Glimmer VM: Boots Fast and Stays Fast

Great web applications boot up fast and stay silky smooth once they’ve started.

In other contexts, applications can choose quick loading or responsiveness once they’ve loaded. Great games can get away with a long loading bar as long as they react instantly once the gamer gets going. In contrast, scripting languages like Ruby, Python or Bash optimize for instant boot, but run their programs more slowly.

To optimize for boot time, scripting languages use interpreters and avoid expensive compilation steps. To optimize for responsiveness, games pre-fill their caches and do as much work up front as they can get away with. The web demands that we do both at the same time: users coming from search results pages must see content within a second on modern devices, but also demand 60fps once the application gets going.

Over the years, web browsers have responded to this requirements with more JIT tiers

Fast Updates in Ember

Continue reading “The Glimmer VM: Boots Fast and Stays Fast”

Why I’m Working on Yarn

(This post is about Yarn, a new JS package manager that was announced today.)

I work with Node and npm packages almost every day, on Tilde’s main app, Skylight, or on one of Ember’s many packages.

Many have remarked upon how fast the npm registry has grown, and it’s hard to imagine working on any of my packages without the npm ecosystem.

I’ve also worked on a couple of application-level package managers (Bundler for Ruby and Cargo for Rust), so it’s no surprise that people have routinely asked me whether I’d consider writing a “bundler for node”.

While it’s something I considered idly from time to time, the truth is that for all of the complaints people have about the official client, it does a whole lot that people rely on, and the npm team has done a lot to improve it over the years. I genuinely respect Continue reading “Why I’m Working on Yarn”

Why I’m Working on Yarn

(This post is about Yarn, a new JS package manager that was announced today.)

I work with Node and npm packages almost every day, on Tilde’s main app, Skylight, or on one of Ember’s many packages.

Many have remarked upon how fast the npm registry has grown, and it’s hard to imagine working on any of my packages without the npm ecosystem.

I’ve also worked on a couple of application-level package managers (Bundler for Ruby and Cargo for Rust), so it’s no surprise that people have routinely asked me whether I’d consider writing a "bundler for node".

While it’s something I considered idly from time to time, the truth is that for all of the complaints people have about the official client, it does a whole lot that people rely on, and the npm team has done a lot to improve it over the years. I genuinely respect Continue reading “Why I’m Working on Yarn”

An Extensible Approach to Browser Security Policy

Alex Russell posted some thoughts today about how he wishes the W3C would architect the next version of the Content Security Policy.

I agree with Alex that designing CSP as a “library” that uses other browser primitives would increase its long-term utility and make it compose better with other platform features.

Alex is advocating the use of extensible web principles in the design of this API, and I wholeheartedly support his approach.

Background

You can skip this section if you already understand CSP.

For the uninitiated, Content Security Policy is a feature that allows web sites to opt into stricter security than what the web platform offers by default. For example, it can restrict which domains to execute scripts from, prevent inline scripts from running altogether, and control which domains the network stack is allowed to make HTTP requests to.

To opt into stricter security using the current version of Continue reading “An Extensible Approach to Browser Security Policy”

An Extensible Approach to Browser Security Policy

Alex Russell posted some thoughts today about how he wishes the W3C would architect the next version of the Content Security Policy.

I agree with Alex that designing CSP as a “library” that uses other browser primitives would increase its long-term utility and make it compose better with other platform features.

Alex is advocating the use of extensible web principles in the design of this API, and I wholeheartedly support his approach.

Background

You can skip this section if you already understand CSP.

For the uninitiated, Content Security Policy is a feature that allows web sites to opt into stricter security than what the web platform offers by default. For example, it can restrict which domains to execute scripts from, prevent inline scripts from running altogether, and control which domains the network stack is allowed to make HTTP requests to.

To opt into stricter security using the current version of Continue reading “An Extensible Approach to Browser Security Policy”

Extend the Web Forward

If we want to move the web forward, we must increase our ability as web developers to extend it with new features.

For years, we’ve grabbed the browsers extension points with two hands, not waiting for the browser vendors to gift us with new features. We built selector engines, a better DOM API, cross-domain requests, cross-frame APIs.

When the browser has good extension points (or any extension points, really), we live in a virtuous cycle:

  • Web developers build new APIs ourselves, based on use-cases we have
  • We compete with each other, refining our libraries to meet use cases we didn’t think of
  • The process of competition makes the libraries converge towards each other, focusing the competition on sharp use-case distinctions
  • Common primitives emerge, which browser vendors can implement. This improves performance and shrinks the amount of library code necessary.
  • Rinse, repeat.

We’ve seen this time and time again. When it Continue reading “Extend the Web Forward”

Extend the Web Forward

If we want to move the web forward, we must increase our ability as web developers to extend it with new features.

For years, we’ve grabbed the browsers extension points with two hands, not waiting for the browser vendors to gift us with new features. We built selector engines, a better DOM API, cross-domain requests, cross-frame APIs.

When the browser has good extension points (or any extension points, really), we live in a virtuous cycle:

  • Web developers build new APIs ourselves, based on use-cases we have
  • We compete with each other, refining our libraries to meet use cases we didn’t think of
  • The process of competition makes the libraries converge towards each other, focusing the competition on sharp use-case distinctions
  • Common primitives emerge, which browser vendors can implement. This improves performance and shrinks the amount of library code necessary.
  • Rinse, repeat.

We’ve seen this time and time again. When it Continue reading “Extend the Web Forward”

I’m Running to Reform the W3C’s TAG

Elections for the W3C’s Technical Architecture Group are underway, and I’m running!

There are nine candidates for four open seats. Among the nine candidates, Alex Russell, Anne van Kesteren, Peter Linss, and Marcos Cáceres are running on a reform platform. What is the TAG, and what do I mean by reform?

What is the TAG?

According to the TAG’s charter, it has several roles:

  • to document and build consensus around principles of Web architecture
  • to interpret and clarify these principles when necessary
  • to resolve issues involving general Web architecture brought to the TAG
  • to help coordinate cross-technology architecture developments inside and outside W3C

As Alex has said before, the existing web architecture needs reform that would make it more layered. We should be able to explain the declarative parts of the spec (like markup) in terms of lower level primitives that compose well and that developers can use for Continue reading “I’m Running to Reform the W3C’s TAG”

I’m Running to Reform the W3C’s TAG

Elections for the W3C’s Technical Architecture Group are underway, and I’m running!

There are nine candidates for four open seats. Among the nine candidates, Alex Russell, Anne van Kesteren, Peter Linss, and Marcos Cáceres are running on a reform platform. What is the TAG, and what do I mean by reform?

What is the TAG?

According to the TAG’s charter, it has several roles:

  • to document and build consensus around principles of Web architecture
  • to interpret and clarify these principles when necessary
  • to resolve issues involving general Web architecture brought to the TAG
  • to help coordinate cross-technology architecture developments inside and outside W3C

As Alex has said before, the existing web architecture needs reform that would make it more layered. We should be able to explain the declarative parts of the spec (like markup) in terms of lower level primitives that compose well and that developers can use for Continue reading “I’m Running to Reform the W3C’s TAG”

Follow Me to Google+

I wrote my first post on this blog in January 2007.

In 2007, this blog was the easiest way I had to write my thoughts down for people who cared to read them. I wrote long posts and short post (but mostly long posts). I wrote deeply technical posts. I wrote proposals. I wrote introductory posts.

I did not post often.

In 2012, there are many more ways to write and reach an audience. I write whimsically on Twitter. I write personally on Facebook. More and more, I find that I write casually on Google+.

Without the 140-character constraint of Twitter, I can start writing and stop when I reach the end of a thought. Unlike the long-form nature of my blog, I find myself writing often, whenever something is on my mind. If you’re interested in reading that sort of thing, follow my Google+ profile. Because I never remember Continue reading “Follow Me to Google+”

Follow Me to Google+

I wrote my first post on this blog in January 2007.

In 2007, this blog was the easiest way I had to write my thoughts down for people who cared to read them. I wrote long posts and short post (but mostly long posts). I wrote deeply technical posts. I wrote proposals. I wrote introductory posts.

I did not post often.

In 2012, there are many more ways to write and reach an audience. I write whimsically on Twitter. I write personally on Facebook. More and more, I find that I write casually on Google+.

Without the 140-character constraint of Twitter, I can start writing and stop when I reach the end of a thought. Unlike the long-form nature of my blog, I find myself writing often, whenever something is on my mind. If you’re interested in reading that sort of thing, follow my Google+ profile. Because I never remember Continue reading “Follow Me to Google+”

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

Tokaido Status Update: Implementation Details

Hey guys!

Since my last update, Tokaido was fully funded, and I’ve been hard at work planning, researching and working on Tokaido.

So far, we have a working binary build of Ruby, but no setup chrome. Because the binary build already exists, Terence Lee was able to experiment with it at a recent Rails Girls event, with great success:

Great thanks to Terence to put together a simple installer script that we could use to test whether the core build worked on a wide variety of OSX systems.

One thing that I mentioned in my original proposal was a desire to work closely with others working on related projects. Very soon after my project was announced, I teamed up with Michal Papis Continue reading “Tokaido Status Update: Implementation Details”

Tokaido Status Update: Implementation Details

Hey guys!

Since my last update, Tokaido was fully funded, and I’ve been hard at work planning, researching and working on Tokaido.

So far, we have a working binary build of Ruby, but no setup chrome. Because the binary build already exists, Terence Lee was able to experiment with it at a recent Rails Girls event, with great success:

Great thanks to Terence to put together a simple installer script that we could use to test whether the core build worked on a wide variety of OSX systems.

One thing that I mentioned in my original proposal was a desire to work closely with others working on related projects. Very soon after my project was announced, I teamed up with Michal Papis Continue reading “Tokaido Status Update: Implementation Details”

Tokaido: My Hopes and Dreams

A few weeks ago, I started a kickstarter project to fund work on a project to make a long-term, sustainable binary build of Ruby. The outpouring of support was great, and I have far exceeded my original funding goal. First, I’d like to thank everyone in the community who contributed large and small donations. This kickstarter couldn’t have been as successful as it has been without the hundreds (650 at latest count!) of individual donations by interested Rubyists.

In this post, I want to talk about what my goals are for this project, and why I think it will be a tool that everyone, myself included, will use.

What is Tokaido

The name “Tokaido” (東海道 in Japanese) comes from the Tōkaidō Shinkansen bullet train line in Japan.

Precompiled, Static Ruby

At its core, Tokaido is a binary distribution of Ruby without any external dependencies on your system. This means that Continue reading “Tokaido: My Hopes and Dreams”