Zepto 1.0

Party like it’s one-oh! Zepto, the jQuery-compatible JavaScript micro-library for modern browsers, is now available in version 1.0.

Looking back at the first release, back in October 2010, Zepto has come a long way. It’s now compatible with all modern browsers (except Internet Explorer, and yes, it’s easy to fall back to jQuery) and supports complex frameworks like Twitter Bootstrap.

You can grab Zepto at zeptojs.com, and contribute via the GitHub repository.

Notable additions and changes in V1.0

• Zepto is now compatible with Twitter Bootstrap
• Portable, completely new node.js-based build system
• Fully automated tests with PhantomJS and Travis CI
• Removed touch module from default distribution (you can add with our easy-to-use build system, or just load it in addition)

There’s many more additions and bug fixes—see the detailed change log on the Zepto site.

We’re already planning V1.1, for which we will look mostly into code refinements and performance improvements (Zepto is already pretty speedy, as it keeps the loading and parsing time of your site low, especially on mobile devices).

Super-special thanks to all our contributors. You’re the best!

Episode 38: Standing out from the pack

Episode 38: Standing out from the pack:

This week Ben Orenstein is joined by Jeremy McAnally, employee at GitHub, author of Ruby in Practice, Rails 3 Upgrade Handbook, MacRuby in Action, and more. Jeremy and Ben discuss teaching and organizing conferences, remote working for GitHub, the and the company summits, GitHub workflows, their internal tools team. They also talk about standing out from the pack in work, life, and getting accepted to conferences, selecting people to speak at conferences, self-publishing, Jeremy’s writing process and future writing plans, work-life balance, how to get a job at GitHub, and much more.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

The Apprentice Programmer

I dropped out of school when I was 16 years old. School was not for me. To me, computers were so much more interesting. Right or wrong, I felt like I wasted my time there and my real education was starting when I came home. I lost respect for the institution and of course this meant that I no longer bothered to put any effort into it. They diagnosed me with all sorts of learning disabilities and started to medicate me. I wanted to leave it all behind.

I decided the best thing to do was to drop out and start an apprenticeship as a Fachinformatiker - computer programmer. This might sound like a stupid decision to people in North America, who often go to College or University to get a degree in something like computer science, but in Germany leaving high-school for an apprenticeship is not out of the ordinary. It is called the dual education system, and it is likely one of the main reasons for Germany's success.

The system has its roots in history of the region. Carpenters and a number of other important craftsman trades have used an apprenticeship system to teach and build expertise for hundreds, if not thousands of years. The underlying idea is that there are professions that profit more from experience then theoretical understanding and that education time is far better spent doing the actual work by watching or listening.

Many companies in Germany take on apprentices, much like North American companies accept interns and co-op students. If a company decides to take you on as an apprentice, the position is guaranteed by the state. Should the company go bust, you are placed with another company the next day. There is a web of companies guaranteeing the positions for each other, spread all across the country.

Unlike interns in North American companies, apprentices in Germany are treated like normal junior employees except they are cheaper, (700 marks per month or $400USD when I went), often younger and misses about 60 work days a year to attend classes at their vocational school. The schools teach the theory behind each chosen trade and certify the students at the end of 3 years with an exit exam which concludes the program. Student apprentices, (they called us “Stift” = Pen), who successfully complete the program and pass the exam earn the vocational title.

I landed an apprenticeship with a company in my hometown called BOG Koblenz - a subsidiary of Siemens - a company with a history of taking on apprentices. For some reason I vividly remember this one question from my interview:

The number of lilies in a pond double every day. So, on the first day of the month there is one lily. On the second day, two lilies, the next day four lilies, then eight, sixteen, thirty two, etc. If the pond is full on the 30th day of the month, what day is it half full?

That was not exactly difficult.

Three other Stifts started with me at the same time. On our first day we got a tour of the 150 person company, which seemed massive to me at the time. The first year was about paying our dues: 3 months running the cafeteria, 3 helping in accounting, three more working in inventory, and then three months at reception. It was a rite of passage, they told us.

The first 3 months in the cafeteria meant I quickly met everyone in the company and learned what kind of coffee or tea they liked. I made sure to keep them well caffeinated. My absolutely favourite group of people worked in a small room in the basement of a secondary building. I do not remember what their official titles were, but they were essentially doing Skunk Works down there.

They did things differently than everyone else. Most of the company used an esoteric programming environment called Rosie SQL - which seemed like death to my Demo Szene honed sensibilities (Assembler, Pascal or bust!) - these guys used Delphi. I fell in love with it! Here was a programming language that put humans before machines. It was built for instant gratification, experimentation and rapid prototyping. Its window management library called the VCL was so much greater than anything I had seen before. More importantly, it was run by Jürgen.

Jürgen was a long-haired, 50-something, grizzled rocker who would have been right at home in any Hell's Angels gang. He was a rebel. He refused to wear the company attire, refusing to use the formal language, called people out on bad ideas when he saw them in plain language. Despite of all this, everyone respected him. I tried my best to make it absolutely obvious that I wanted to work for him. I borrowed the Delphi manuals and committed them to memory in my downtime between coffee runs.

At the same time, I would attend my vocational school every Friday, and twice a year we would go for two straight weeks to study and take exams. This was a much better way for me to learn. It felt relevant. I learnt the fundamentals of things picked up from being around Jürgen's team. We learned about algorithms, Big O, etc - even some basic soldering and electrical work.

It turned out those learning disabilities were not real disabilities; I was simply a kinesthetic learner. I could not understand or come up with solutions to problems I have never had. At my vocational school, I knew the problems we were solving. I had been in those situations. It was great! My self esteem and confidence improved quickly.

My plan was working.

After the first year, Jürgen drafted me to be a part of his little basement-dwelling team. It was probably the most important thing that happened to me in my professional life. Jürgen was a master teacher. He created an environment in which it was not only possible but easy to move through 10 years of career development every year. It is a method and an environment which I am fiercely trying to replicate at Shopify.

Most days I came to work and found a printout of the code I wrote the day before annotated with red marker everywhere. I used poor idioms or could have chosen better abstractions or done a better job hinting at the architecture of the overall system. This taught me not to tangle my ego up in the code I write. There are always ways to improve it and getting this feedback is a gift.

I remember we made software for GM. One particular car dealership needed a faster system to estimate the value of incoming used cars. A big competitive advantage. Jürgen gave this project to me. Shipping it meant Jürgen and I had to drive to the dealership which was a day trip away. In preparation for it, the company gave me extra money so I could buy a suit. We work for Siemens after all. We had to look the part.

The day before the installation, Jürgen casually tells me he has somewhere else to be. I would be going by myself. I felt overwhelmed but somehow managed to make a good impression and got everything working regardless.

This pattern kept on repeating itself. Jürgen somehow knew the extent of my comfort zone and manufactured situations which were slightly outside it. I overcame them through trial and error, through doing, and immediately applying the theory I was learning at the vocational school to practice at my apprenticeship, I succeeded.

My degree is not recognized in North America so I am technically a high school dropout. My cofounder at Shopify has a PhD, so we always joke that together we average out to a bachelor's degree.

Not that degrees matter anymore. They do not. Experience does. That is one of the things my apprenticeship and the dual education system in general taught me: experiencing and learning things quickly is the ultimate life skill. If you can do that, you can conjure up impossible situations for yourself over and over again and succeed.

Perhaps most importantly, the apprenticeship program gave me a solid head start. If I had gone to a University and studied to get a PhD like my Cofounder, I might JUST be getting out of school. Instead, at 32 years old and I have been paid to build complex software for almost half my life.

That is a powerful concept and one within the reach of almost any German student thanks to the dual education system. At the last count, there are 356 different occupations or occupational categories which offer apprenticeships. From hair dressers to oven builders to various specializations of computer programming. For hands-on people or kinesthetic learners like me, the apprenticeship program created a legitimate path to success.

It was the perfect environment for me, I learned a lot, and I am eternally thankful to have chosen that path. If only more countries struggling with dropout rates and job creation would give their students a similar choice.

Ruby 1.9.3-p392

In this episode of The Ruby Show, Jason and Peter talk about the latest Ruby release, Rails security releases, and the usual round up of interesting projects.

Pow port forwarding with Vagrant

We’re experimenting with Vagrant virtual machines for development.

To access the guest machine’s web server, the host machine will typically forward a different port to port 80 on each virtual machine.

So on your host machine, you may use http://localhost:8001 for app1 and http://localhost:8002 for app2.

This avoids port conflicts, but it’s a bit rough.

If you have Pow installed on your OS X host machine, though, you can use its port proxying feature. Just do this:

1
2

echo 8001 > ~/.pow/app1
echo 8002 > ~/.pow/app2

You can now use http://app1.dev instead of http://localhost:8001, and http://app2.dev instead of http://localhost:8002.

Introducing Learn for iPhone

I’m very pleased to introduce our new iPhone app for Learn.

We’ve started with the very valuable Trail Maps, guided paths for learning modern development technologies and practices.

The Trail Maps are kept up to date within the app and accessible offline. This allows you to track your learning progress by checking off resources as you read them and validations as you learn.

Remember, our Trail Maps are open sourced on GitHub, so if you think something is a valuable resource, please do contribute.

The app is free on the App Store, so download it today.

Beyond Active Record merge

If you want maintainable, loosely coupled classes, you must mind what they know about one another.

For example, you don’t want one Active Record model to know a lot about the schema of another.

merge

Instead of this:

1
2
3
4

class User < ActiveRecord::Base
  has_one :subscription
  scope :with_active_subscription, joins(:subscription).where("subscriptions.active" => true)
end

1
2

class Subscription
end

You might use Active Record’s merge and do something like:

1
2
3
4

class User < ActiveRecord::Base
  has_one :subscription
  scope :with_active_subscription, joins(:subscription).merge(Subscription.active)
end

1
2
3

class Subscription
  scope :active, where(active: true)
end

We’re still coupled, of course, but to a higher and thus more stable abstraction.

Beyond merge

For more complex SQL, merge won’t cut it.

Today, I extracted columns like invoices.posted_at and contracts.emailed_at to a separate events table.

Now there are Event records which belong to a record (invoice or contract) and have an event name and a timestamp.

So a posted invoice may be represented by an Event record with these attributes:

1

{ record_id: 123, record_type: "Invoice", name: "posted", happened_at: "2013-02-28 16:00" }

Now, if you want a scope/method like Invoice.unposted (and perhaps Contract.not_emailed), how would you go about it?

You’ll need a join that involves events columns.

You could put the join SQL in Invoice, but then it would know a lot about the events table. And you’d have to duplicate much of that SQL if Contract adds a similar method.

Instead, you can simply have Event own that SQL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Event < ActiveRecord::Base
  belongs_to :record, polymorphic: true

  def self.scope_unevented(scoped, event)
    klass = scoped.klass

    query = [
      "LEFT JOIN events
        ON events.record_id = #{klass.table_name}.#{klass.primary_key}
        AND events.record_type = ?
        AND events.name = ?",
      klass.base_class.name,  # STI uses the base class.
      event
    ]

    scoped.
      joins(sanitize_sql(query)).
      where("events.id IS NULL")
  end
end

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Invoice
  POSTED_EVENT = "posted"

  scope :loving_it, where(loving_it: true)

  def self.unposted
    # `scoped` is `Invoice.scoped`; a scope of all records.
    Event.scope_unevented(scoped, POSTED_EVENT)
  end

  def self.unposted_and_loving_it
    Event.scope_unevented(loving_it, POSTED_EVENT)
  end
end

Now all Event needs to know is that its record has an id and a class; fairly stable assumptions.

Phusion Passenger 4.0 Release Candidate 2

Phusion Passenger is an Apache and Nginx module for deploying Ruby and Python web applications. It has a strong focus on ease of use, stability and performance. Phusion Passenger is built on top of tried-and-true, battle-hardened Unix technologies, yet at the same time introduces innovations not found in most traditional Unix servers. Since mid-2012, it aims to be the ultimate polyglot application server.

We know many users are eagerly awaiting the final release of Phusion Passenger 4.0. The 4.x series is a huge improvement over the 3.x series: during the development of 4.0, we’ve introduced a myriad of changes which we’ve covered in past beta preview articles:

• Beta 1: support for multiple Ruby versions, support for Python WSGI, multithreading (an Enterprise only feature), evented core similar to Nginx and Node.js, real-time response buffering, improved zero-copy architecture, better error diagnostics.
• Beta 2:
  • JRuby and Rubinius support.
  • Out-of-Band Work.
  • Support for the Rack socket hijacking API
  • Improved stability and test suite.

Today we are proud to announce Release Candidate 2 of Phusion Passenger 4.0. Release Candidate 1 has been skipped because a few bug fixes were applied right after RC 1 was tagged.

Changes in 4.0 RC 1 and RC 2

The focus of RC 1 and RC 2 have been on improving stability and on refining previously introduced features. We’ve closed over 100 issues in our issue tracker. We couldn’t have done this without the fantastic feedback from our users, especially those from many Phusion Passenger Enterprise customers who have beta tested the RC previews in their staging environments.

The changes in RC 1 and RC 2 are as follows:

• The Nginx version now supports the passenger_app_root configuration option.
• The Enterprise memory limiting feature has been extended to work with non-Ruby applications as well.
• Application processes that have been killed are now automatically detected within 5 seconds. Previously Phusion Passenger needed to send a request to the process before detecting that it’s gone. This change means that when you kill a process by sending it a signal, Phusion Passenger will automatically respawn it within 5 seconds (provided that the process limit settings allow respawning).
• Phusion Passenger Standalone’s HTTP client body limit has been raised from 50 MB to 1 GB.
• Python 3 support has been added.
• The build system has been made compatible with JRuby and Ruby 2.0. This does not mean that Phusion Passenger works on Ruby 2.0; please read on for more about this subject.
• The installers now print a lot more information about detected system settings so that the user can see whether something has been wrongly detected.
• Some performance optimizations. These involve further extending the zero-copy architecture, and the use of hash table maps instead of binary tree maps.
• Many potential crasher and freezer bugs have been fixed.
• Error diagnostics have been further improved.
• Many documentation improvements.

What about Ruby 2.0?

We are just as excited about Ruby 2.0 as many of you are. Since 2.0 was released a few days ago, we’ve been testing Phusion Passenger on it. We really wanted to release RC 2 with Ruby 2.0 support, but a few things stood in our way so we had to postpone this goal.

• We couldn’t get Ruby 2.0.0 installed on OS X Mountain Lion. The compiled Ruby crashes during Ruby 2.0.0′s build process with a low-level error ([BUG] Stack consistency error). Apparently we aren’t the only ones.
• We were able to get it installed on a Debian VM, but it does not pass all the Phusion Passenger unit tests. It fails on some tests with obscure errors that seem to indicate bugs in Ruby, e.g. errors in which Ruby cannot figure out where the exception came from.

We recommend sticking with 1.9.3 in the mean time until the next Ruby 2.0 patchlevel release.

Release Candidate 2 timeline & download

Phusion Passenger Enterprise customers are given priority access to Release Candidate 2. They can download RC 2 from the Customer Area immediately.

The release of the open source version will follow in one week, on March 5 2013. Of course, open source users who want to stay on the bleeding edge are free to obtain the latest sources from the open source Phusion Passenger git repository at any time.

When the open source version is released, users can install it by following the in-depth installation and upgrade instructions in the Installation section of the documentation. The manual also covers installation of beta releases.

• Apache manual
• Nginx manual

Final

We are excited about the final release. You can help us by testing RC 1 and reporting any bugs. Please submit bug reports to our bug tracker.