The Year of Types

If there's a theme to 2025, it's types. I've been pushing TypeScript for years, but only really started taking Python type hints seriously in 2024, prompted largely by Reactivated. We've done a lot of work at thelab to standardize our tooling around Reactivated and the Wagtail CMS. This combination lets us unify our templating—server-side and client-side—to just be React, eschewing weakly-typed Django templates entirely. Even better, it lets us type check our code, even data structures from Wagtail StreamFields and blocks, all the way from the database to the front-end templates.

That, combined with the improved generics in Python 3.12, triggered us to finally take Python type hints seriously. As a result, all but one of our Python projects now have full strict-mode type coverage via mypy.

The tooling caught up too. We migrated from black and flake8 to ruff across all Python projects. It's faster, it's simpler, and it does both formatting and linting in one tool. We also moved from Poetry to uv for Python package management. Poetry was a great tool and I still like it—uv is just a little better. The biggest subtle-benefit we found was the ability to use uv in your shebang line and define inline script dependencies. No more creating a virtualenv just to run a one-off script.

Another tool I came to love in 2025 is mise. It's already become our standard for defining tooling versions, replacing pyenv and nvm. And it's started replacing Make as a task runner on a few projects too.

On the TypeScript side, we continued using io-ts and fp-ts for runtime type validation. Zod gets more attention these days, but we've been so happy with io-ts that I've seen no reason to consider switching. We also forked and started maintaining ts-to-io, which converts TypeScript types into io-ts codecs. When your API responses are validated at the boundary, you can trust the types throughout the rest of your code.

Open Source Highlights

One new open-source library that I'm excited about right now: thelab-typing. thelab-typing includes some utilities for building strongly typed APIs in Django, inspired much by FastAPI. We've started replacing Django REST Framework with it and have been very happy with the results so far. DRF served us well for years, but the lack of proper typing made it increasingly painful as we increased type safety throughout the rest of our codebases. The new approach gives us a single source of truth for API contracts, for both the request and response data shapes. We can then generate TypeScript types, io-ts-codecs, etc from the same Pydantic models we use to validate/serialize the API data—true cross-network type-safe bliss.

Looking Forward to 2026

Some things I'd like to improve or see more of:

More newtypes, fewer primitives. We still pass around a lot of model IDs and other not-really-a-primitive types as plain integers and strings. We've started introducing newtypes and found it extremely useful for catching bugs related to mismatching these types. For example, accidentally pass a ProductID where an OrderID was expected. Even better would be making those newtypes traverse from Python to TypeScript automatically (which we've started to do by adding support for in ts-to-io).

More Result types. We have a Result type implementation in thelab-typing, but it's fairly new and not widely or consistently used across our projects. Encoding success and failure in the type system instead of relying on exceptions makes code easier to reason about.

More adoption of gradual typing in Python. The tooling is there—mypy, pyright, basedpyright—and the benefits compound over time. Every # type: ignore is tech debt. Every properly typed function is documentation that can't get out of date. Library authors especially—looking at you Django & Wagtail—should absolutely be adopting type hints at full-steam.

Less churn in JavaScript bundlers and meta-frameworks. I don't need a new build tool every six months. I need the current one to keep working.

Continued progress on AI tooling. Programming with LLMs gets most of the attention right now—they absolutely are amazingly powerful tools to pair program with. But they also have a ton real value in the realms of code review, research, and debugging. I'm hoping the tooling in these areas continues to improve.

I initially hated the way the DB was designed—that there was no ORM. I was a far more green developer than I realized at the time. But I was committed to the project, so I buckled down and tried to learn SQL. I read about relational algebra and about set theory. Eventually I was able to wrap my head around the data model. The more I understood the model the more beautiful it became. It mapped to peculiarities of the real world domain in ways that I previously didn't even know existed.

I've long since moved on from that project, but the love of well-designed relational databases stuck. I've used Redis, DynamoDB, Elasticsearch, et al in plenty of projects too—they have their place. But never has a key/value store inspired the kind of mathematical reverence as I had when I finally grokked JOINs. Or UNIONs. Or CTEs. Or window functions. And never has a NoSQL data store been as remarkably flexible as something like PostgreSQL or MySQL. Systems like DynamoDB requiring predicting exactly what your query patterns will be and baking that into the schema. With a relational DB, though, you can explore. You can join, filter, sort by, and group by any column. It's the ultimate admission that we don't know what the future holds; the ultimate agility. I have no idea what report the business will request tomorrow. But, I have absolutely no doubt that I can write a query, paste it into Graphana, and answer their question. Is the answer correct and up to date? Yes, because there is no ETL process involved to could fail or lag. It's just querying the actual canonical application data.

I have no real point in writing this besides saying, if you don't already know anything about set theory, you should learn. If you've only ever used an ORM, write some SQL. Then learn the basics of the math behind it. Learn about levels of normalization. Challenge yourself by asking your data questions that you hadn't thought about when you modeled it. Before you know it, you'll be astounded at the things you can do.

Goals

At a high-level, I I have a few goals for my backup strategy.

1. Avoid permanent data loss. Permanent data loss is the absolute worst case scenario and it must be avoided at all costs. I fully intended to never lose a single picture in my photo library, a note in my note archive, or any other file.
2. Avoid bit-rot. As happy as I am with the Apple ecosystem in general, I'm disappointed that APFS chose not to implement data checksumming, and that I can't buy a Macbook with ECC RAM. Thus, to avoid bit-rot, long-term data storage should be done on systems which do offer protection against corruption of data over time.
3. Maintain High-Availability. As an independent software contractor, I can't just run to the IT department and request a new workstation when the drive in my laptop dies—I am the IT department. So, in-order to uphold the expectations of my clients, there should never be a day where I unexpectedly can't work due to a hardware failure.
4. Maintain Security. I may choose to trust a vendor with storing data, but I don't want to have to trust them to not read it. All data should be encrypted with keys I manage before it leaves my control. Additionally, I'd rather not trust the vendor's bespoke backup client to perform this encryption or key management for me. This rules out most cloud backup providers.

Overview

Which brings me to my actual backup strategy:

Backup Strategy Data Flow

1. Galactica¹, my main workstation, does a daily SuperDuper clone to Atlantia, an external USB SSD.
2. Galactica and Prometheus (my wife's laptop) both automatically run network Time Machine backups to RAIDZ datasets on Gemini, a FreeNAS server.
3. Galactica uses Vorta to perform periodic Borg backups to another dataset on Gemini.
4. Gemini periodically performs Borg backups of Pegasus (general NAS volume) to a dataset on another ZFS pool.
5. After a Borg backup finishes, Gemini runs a cloud sync task to sync the Borg repository to a bucket on Backblaze B2.

Threat Model

All of this aims to fill the needs I described at the outset. Specifically, here are the failure modes I've thought through.

This strategy upholds my goals.

1. Security is upheld because no one gets both the data and the keys.
2. Bit-rot is mitigated by ZFS data checksumming.
3. Ransomware attacks are mitigated by multiple backups and ZFS snapshots.
4. Availability is upheld by bootable SuperDuper clones and by keeping around a last-gen laptop.
5. Data loss is mitigated by drive redundancy in Gemini; by using multiple types of backup software, at least one of which is open-source; and by moving some backups offsite.

So, barring nuclear war and/or some sort of Nation State attack on the Borg project, I don't plan on losing any data anytime soon.

1. Sometimes overtime is unavoidable. But if I'm working overtime, I do everything I can to make it invisible to my team: no email, notifications, pushed commits, etc. I want it to be invisible because I never want my team to feel implicitly pressured to work overtime just because I am. Working 80 hour weeks or being up at 3AM working isn't healthy and I never want anyone on my team to feel guilted into doing something that isn't healthy.
2. I have preferences on ways to write both documentation and code. Everyone does. But when I'm reviewing code, I try hard to only make suggestions that I have an objective reason for. In other words, if somebody wrote something in a way other than how I would have done it, I try harder to accept their way, rather than request my way. I'll only suggest my way if I can come up with definite reasons why my way is better in some important, non-subjective way.
3. Rewriting another developer's work as a form of code review is my absolute last resort. The only reason I'd do this is if the project is approaching a deadline and I see no redeeming value in what they've built so far. It's a last resort because it's utterly demoralizing to the other developer. Instead, I make every effort to work with the other developer and guide their implementation towards acceptance by comments and suggestions. This way (1) they aren't demoralized, feeling that their work had no value and (2) they learn from the process, so that next time their work is better from the outset.

Here is a list of open-source projects I own or actively contribute to, as of February 2017.

Asymmetric JWT Authentication

Asymmetric JWT Authentication is a library designed to aid in stateless authentication of server-to-server or app-to-server API requests in Django using RSA asymmetric RSA key pairs. It eliminates security issues like replay attacks and MitM credential snooping all while being as simple to use as HTTP Basic Auth.

Documentation on Read the Docs Gitlab: crgwbr/asymmetric-jwt-auth Github Mirror: crgwbr/asymmetric-jwt-auth

Instrumented Soap

Instrumented Soap is a wrapper around Suds-Jurko that improves a few aspects of it.

• Instrumentation and stat tracking using django_statsd.
• Improved HTTP proxy support for SOAP Transports.
• Useful SOAP API mocking and unit-testing tools.

Documentation on Read the Docs Gitlab: thelabnyc/instrumented-soap Github Mirror: thelabnyc/instrumented-soap

Version Tag

Version Tag is a lightweight library designed make version tracking of Python libraries and application simpler by making Git tags the sole source of truth.

Documentation on Read the Docs Gitlab: thelabnyc/python-versiontag Github Mirror: thelabnyc/python-versiontag

Django / Log Pipe

Log Pipe is a library for help Django apps get data in and out of Apache Kafka using Django ReST Framework serializers and pluggable serialization formats.

Documentation coming soon! Gitlab: thelabnyc/django-logpipe Github Mirror: thelabnyc/django-logpipe

Django / Exact Target

Django Exact Target is an a simple library for connecting to the SalesForce Marketing Cloud Exact Target REST API. Currently it only supports triggered sends, but may support more in the future.

Documentation coming soon! Gitlab: thelabnyc/django-exact-target Github Mirror: thelabnyc/django-exact-target

Oscar / API Checkout

Oscar API Checkout is a layer on top of django-oscar and django-oscar-api, adding support for more complex and multiple payment options during an API checkout.

Documentation coming soon! Gitlab: thelabnyc/django-oscar-api-checkout Github Mirror: thelabnyc/django-oscar-api-checkout

Oscar / Bundles

Oscar Bundles adds multi-product bundles to django-oscar.

Documentation coming soon! Gitlab: thelabnyc/django-oscar-bundles Github Mirror: thelabnyc/django-oscar-bundles

Oscar / Bluelight Specials

Bluelight Specials is a layer on-top of django-oscar that adds support for more complex offers and vouchers, including conjunctive and disjunctive compound conditions.

Documentation coming soon! Gitlab: thelabnyc/django-oscar-bluelight Github Mirror: thelabnyc/django-oscar-bluelight

Oscar / CCH Sales Tax Office Connector

Oscar CCH is a plugin for django-oscar adding support for calculating taxes using the Wolters Kluwer CCH Sales Tax Office SOAP API.

Documentation on Read the Docs Gitlab: thelabnyc/django-oscar-cch Github Mirror: thelabnyc/django-oscar-cch

Oscar / CyberSource Secure Acceptance Connector

Oscar CyberSource is a plugin for Oscar API Checkout that makes it possible to use CyberSource Secure Acceptance Silent Order Post as an order payment method.

Documentation coming soon! Gitlab: thelabnyc/django-oscar-cybersource Github Mirror: thelabnyc/django-oscar-cybersource

Oscar / Wells Fargo Retail Services Connector

Oscar WFRS is a plugin for Oscar API Checkout that makes it possible to use Wells Fargo Retail Services as an order payment method.

Documentation coming soon! Gitlab: thelabnyc/django-oscar-wfrs Github Mirror: thelabnyc/django-oscar-wfrs

For the first time, SpaceX successfully landed the first stage of their Falcon 9 rocket last night. Elon has said in the past that while a rocket costs $60 million to build from the ground up, it only costs $200,000 to fuel. We're yet to see how much refurbishment is required before this stage can fly again, but regardless, this is a huge achievement and a big step towards space travel becoming common. I couldn't be more excited.

The above scenario is fictional, but also entirely possible. How? An attacker sitting in the coffee shop was running a WiFi pineapple in their backpack. The pineapple impersonated Olivia's home network SSID, causing her laptop to auto-connect to it's network instead of the coffee shop's router. Now posing as a man-in-the-middle, the attacker used SSLStrip and Wireshark to intercept, record, and decrypt the traffic between Olivia's laptop and the webmail server. In seconds, without Olivia noticing a thing, the attacker had her username and password.

There's numerous issues here, but what I aim to illustrate is how sending long-lived credentials over-the-wire is dangerous. Each time you transmit a re-usable credential, especially over a non-trusted network, you risk having it intercepted and used by an unauthorized party. We can never entirely eliminate risk of compromise, but if we can devise a way to transmit secrets less often, we can reduce our possibility of attack. Using asymmetric cryptography, this very thing is possible.

What is asymmetric crypto?

In symmetric (or shared-key) cryptography, both parties share a piece of data which serves an an encryption key. This key is used to both encrypt and decrypt the messages sent between the two parties. Asymmetric (or public-key) cryptography is different in that two keys are used: a public and a private key. When used for encryption, the public key is capable of encrypting data that only the private key can decrypt. For example, Party-A could distribute their public key to anyone who wants it. Party-B, now that they have Party-A's public key, can use it to encrypt a message that only Party-A can read. Along with that message Party-B includes their own public key. Party-A then uses it to encrypt their response so that only Party-B can read it.

Asymmetric cryptography, in addition to encryption, has another interesting application: message signing. When used for message signing, a party can use their private key (the key not shared with anyone under any circumstance) to attach a signature to a message. Then, anyone holding the corresponding public key an verify (1) the sender of the message is actually the holder of the private key and (2) the contents of the message have not been tampered with or altered in anyway en route. While this isn't useful for hiding the contents of a message, this is very useful for establishing trust. Party-A can verify that a message claiming to be from Party-B is in-fact from Party-B (or at least someone holding Party-B's private key). Even better, Party-A can do this without ever asking for a password or any other secret to be sent over the wire.

Asymmetric crypto as authentication

To use asymmetric cryptography for authentication in the context of an HTTP API, we need to define a different things.

1. A message schema for a client to claim who they are
2. A message signature algorithm for the client to sign their claim with
3. A standard way to include the claim message and signature with each request
4. A way for the server to store public keys associated with the user's who own them
5. Some sort of request middleware on the server to verify authentication claims

Fortunately open-standards describing exactly what we need for points 1 and 2 already exist. A JSON Web Token (RFC7519) is a token comprised of a base64 encoded JSON document and an HMAC signature for verifying the messages contents. The algorithm used in the HMAC calculation isn't part of the standard — most often you'll see it being used with SHA — but in this case, since the creator and consumer of the token aren't the same system, we'll use RSA. As far as the data included in the JWT, we'll want to include at least three fields.

1. Unique user identifier: this tells the server who the client is claiming to be.
2. Issued timestamp: this tells the server when the token was created. The server should enforce that this be close to the current timestamp — the tolerance should be large enough to allow for some clock drift, but small enough to that we don't have to hold onto nonces forever.
3. Nonce: this should be an arbitrary value used to prevent replay attacks using the token. once a request is authenticated, the server should store this value for at least as long as the timestamp drift tolerance. Any request made within that rolling period of time must have a unique nonce.

Point 3, how we'll transmit the claim, is fairly arbitrary. All that really matters is that the server knowns where to look for the clients claim. Since we're talking about HTTP APIs, lets use the HTTP Authorization header.

Finally, points 4 and 5 will very based on your web framework of choice. I've written a Python/Django implementation with using django.contrib.auth and it's middleware system. Corresponding implementations could easily be ported to Node.js, Ruby, or any other language with an existing JWT library that supports RSA HMAC.

The proposed solution obviously isn't a great fit for web services primarily consumed by browsers. Browsers simply aren't setup to generate and send signed JWTs. An implementation could most likely be achieved in Javascript, but generating and storing private keys securely is still an issue. However if you're building an application around the idea of microservices, where server applications need to make authenticated requests to other server applications, or if your API is consumed by native desktop applications, asymmetric key JWT authentication could be a great design choice.

Links

1. WiFi pineapple
2. JSON Web Tokens
3. Hash-based message authentication code
4. Asymmetric JWT authentication for Django

Lightning Talk: Making JS better with Browserify from crgwbr

Runtime performance is something I've been thinking about a lot lately. Even by interpreted language standards PHP is a slow language — theres really no way to deny that. Javascript (Node.js) or even Python (PyPy) well out perform it. Historically I, along with thousands of other people, have been extremely critical of PHP's (lack of) design, philosophy, and it's performance. That said, some projects that I care about very much are committed to using PHP and are far to deep-in-the-stack to consider switching now. So, with switching language eliminated as an option, how can we make PHP fast enough to scale a website?

As it turns out, Facebook had the same issue a few years ago. Despite being one of the largest web apps on the internet, their core code is still written in PHP. Their solution to the scaling problem, rather than switch to a faster language, was to build a faster PHP interpreter: HHVM. Like the stock PHP interpreter (ZendPHP), HHVM starts by lexing and tokenizing your PHP source into bytecode. After the tokenizing step is where HHVM differs. ZendPHP immediately executes the generated bytecode and exits. HHVM, similar to the CLR or JVM, translates the bytecode into x64 machine code through the use a just-in-time (JIT) compiler. The resulting machine code is executed to fulfill the current web-request, but also cached into the SQLite database for re-use on the next request. Additionally, since HHVM is both compiling and running PHP source, it can use live variable type inspection to optimize generated code as it runs.

Sandbox mode

As great as the HHVM project is, documentation is not one of there strong points. Sandbox mode is mostly undocumented, but in a development environment, this is how you'll want to run HHVM. Sandbox mode allows a single HHVM daemon to simultaneously do page builds from a number of different source trees. This is ideal for a multi-developer setup, where each developer needs to have their own working copy of the application. Sandbox mode uses a regex match against the the HTTP host header to determine which build to use for a request.

Sandbox mode is enabled in the HHVM server config with the following entry in your server's hdf file:

Sandbox {
      SandboxMode = true
      Pattern = ([A-Za-z0-9]+).dev.example.com
      Home = /home
      ConfFile = .hphp
  }
  

This config tells HHVM to examine the Host header with the regex at Sandbox.Pattern. The first group extracted from the regex is assumed to be the username of the developer. Optionally, the regex could include another group to extract the sandbox name. When HHVM doesn't find a sandbox name — like in the above example — it uses the sandbox name default. This feature would be useful if a single developer needed to have multiple builds; for the sake of simplicity in this example we'll just the the default sandbox.

Once HHVM has extracted the developer's username, it appends it to the Sandbox.Home value to get the developers home directory. For example, if we request joe.dev.example.com it will construct the path /home/joe. Inside that path HHVM looks for the developer's sandbox configuration file, named by the value of Sandbox.ConfFile. In this example it would read /home/joe/.hphp.

Here is an example sandbox config file:

default.path = /home/joe/src
  default.log = /home/joe/logs/hhvm.log
  default.accesslog = /home/joe/logs/access.log
  

This config file tells HHVM where to find the source code for each of the developers sandboxes and where to write access and error logs (in addition to the global logging setup on the server). Since we're using the default sandbox, the source root for http://joe.dev.example.com/ becomes /home/joe/src/. Any number of additional sandboxes can be defined in this file if needed.

Debugging

There are plans to support XDebug in the future, but until then, HHVM uses a custom debugger called HPHPd. HPHPd supports debugging both local scripts and HTTP requests running on a remote server, but the HHVM Server must be running in Sandbox mode for the debugger to work.

Local Scripts

Assume we have the following script, test.php.

<?php
  
  function test($i) {
      for ($j = 0; $j < $i;  $j++) {
          var_dump("{$j} of {$i}");
      }
  }
  
  test(10);
  

To run the script we simply invoke hhvm in the cli, like we would php.

joe@dev.example.com:~$ hhvm test.php
  string(7) "0 of 10"
  string(7) "1 of 10"
  string(7) "2 of 10"
  string(7) "3 of 10"
  string(7) "4 of 10"
  string(7) "5 of 10"
  string(7) "6 of 10"
  string(7) "7 of 10"
  string(7) "8 of 10"
  string(7) "9 of 10"
  joe@dev.example.com:~$
  

HPHPd is a GDB-like shell debugger. To debug the script, change the hhvm mode to debug.

joe@dev.example.com:~$ hhvm -m debug test.php
  Welcome to HipHop Debugger!
  Type "help" or "?" for a complete list of commands.
  
  Program test.php loaded. Type '[r]un' or '[c]ontinue' to go.
  hphpd>
  

You can set breakpoints based on either line number or class/function definition.

hphpd> break test()
  Breakpoint 1 set upon entering test()
  hphpd> break test.php:5
  Breakpoint 2 set on line 5 of test.php
  hphpd> break list
    1	ALWAYS    upon entering test() (unbound)
    2	ALWAYS    on line 5 of test.php (unbound)
  hphpd>
  

With our breakpoints set, we're ready to run the actual script.

phpd> run
  Breakpoint 1 reached at test() on line 4 of /home/joe/test.php
     3 function test($i) {
     4*    for ($j = 0; $j < $i;  $j++) {
     5         var_dump("{$j} of {$i}");
  
  hphpd>
  

While at a breakpoint, we can view the state of locally defined variables.

hphpd> variable i
  i = 10
  hphpd>
  

Continue execution to the next breakpoint:

hphpd> continue
  Breakpoint 2 reached at test() on line 5 of /home/joe/test.php
     4     for ($j = 0; $j < $i;  $j++) {
     5*        var_dump("{$j} of {$i}");
     6     }
  
  hphpd> step
  Break at test() on line 4 of /home/joe/test.php
     3 function test($i) {
     4*    for ($j = 0; $j < $i;  $j++) {
     5         var_dump("{$j} of {$i}");
  
  hphpd>
  

HPHPd will inform you when execution completes.

hphpd> continue
  string(7) "9 of 10"
  Program test.php exited normally.
  hphpd>
  

At this point you can restart execution from the beginning:

hphpd> run
  Breakpoint 1 reached at test() on line 4 of /home/joe/test.php
     3 function test($i) {
     4*    for ($j = 0; $j < $i;  $j++) {
     5         var_dump("{$j} of {$i}");
  
  hphpd>
  

Remote Sandboxes

For web-requests, HHVM is already running as a daemon in server mode. Instead of running the web application directly, we'll start an instance of HPHPd in debug mode and connect to it remotely.

joe@dev.example.com:~$ hhvm -m debug -h localhost
  Welcome to HipHop Debugger!
  Type "help" or "?" for a complete list of commands.
  
  Connecting to localhost:8089...
  Attaching to joe's default sandbox and pre-loading, please wait...
  localhost>
  

Set a breakpoint, for example, anytime we increment a counter:

localhost> break Stats::increment()
  Breakpoint 1 set upon entering Stats::increment()
  But wont break until class Stats has been loaded.
  localhost>
  

Run continue to hang the debugger, waiting for a breakpoint to occur.

localhost> continue
  

As soon as a breakpoint it hit, the debugger will unhang.

Breakpoint 1 reached at Stats::increment() on line 64 of /home/joe/src/Stats.php
    63    public function increment($name, $amount = 1) {
    64*      $this->backend->increment($name, $amount);
    65    }
  
  localhost>
  

Show the locally defined variables:

localhost> variable
  $name = "connection_count"
  $amount = 1
  localhost>
  

When done debugging the request, unset your breakpoints and continue to finish execution:

localhost> break disable all
    1	DISABLED  upon entering Stats::increment()
    2	DISABLED  on line 64 of /home/joe/src/Stats.php
  localhost> continue
  

The HPHPd debugger is very powerful and, despite a bit of a learning curve and lack of documentation, can be a hugely valuable tool to gain insight into your code. More information can be gained from running the help command from within the HPHPd shell.

Links:

• Programming Language Performance Benchmarks

On a personal level, I love brands, logos, color, design, and, most of all, Adobe Illustrator. I think it’s one of the most incredible software packages ever made. I’m not a pro, but I know enough to be dangerous :)

So, one weekend this summer, I rolled up my sleeves and dove into the trenches with our logo design team: Bob Stohrer, Marc DeBartolomeis, Russ Khaydarov, and our intern Max Ma. We spent the majority of Saturday and Sunday designing the logo from start to finish, and we had a ton of fun weighing every minute detail.

Marissa Mayer is the President and CEO of Yahoo, and yet she spent a weekend wearing her "graphic artist" hat and designing Yahoo's new logo. Some would undoubtedly see this evidence of a "hands-on" CEO as a good thing, but I see it as a failure to delegate. Part of being a good leader is recognizing that other people are better at some things than you are—and to assign projects as such. A CEO – the top-level of all management – who insists on being involved at the implementation level of projects is a CEO who will limit what the company can do.

Microsoft is not an ideal company right now, but they're certainly doing better than Yahoo. Imagine though, that Ballmer spent half of every day writing C++ for new Microsoft products. What state would Microsoft be in compared to where they are now? Would they be launching Xbox One and pushing Windows 8 at the same time? Can one person be heavily involved with the implementation of both products? Most likely not. So, how is Microsoft managing to do both things? By delegating. A CEO's job isn't to write C++ for core products, just like their job isn't to design the company's logo. Certainly they should be involved in the process – the logo does help set the company's image and tone – but involved is not the same as implemented.

I have no doubt that Mayer wants Yahoo to succeed. Her acquisitions of companies like Tumblr show that she's desperately trying to get fresh, new developers on-board. If she's going to be successful, though, she needs to ditch the habit of micromanaging. She needs to be humble enough to realize that her job is to set Yahoo's direction, lead them into the future, and leave design, programming, and other sorts of implementation to the professionals that she's worked so hard to hire.

I should note that I hardly, if ever, watch television. My ADD has a hard time putting up with 20 minutes per hour of commercials for products I don't want and shouldn't buy. I do though enjoy an occasional movie courtesy of a friend's "borrowed" Netflix streaming account. My roommate, however, watches football. He did, I should say, until a certain Sunday last fall. I walked in the door that day and began to take off my shoes when my roommate asked, "What's up with the TV? I was watching the game and it just turned off. The standby light isn't even on." I walked over to look at it; the power supply was warmer than usual. I tried turning it on again. It obeyed for a few seconds and then promptly died again. "It's done." I said. "I think the transformer burned out."

I still have decent enough soldering skills that I could probably fix the transformer. I also thought about replacing the unit with something nicer. But then a more intriguing thought occurred to me, "What if this could be a breakpoint." Like, I suspect, most kids growing up in the States in the nineties, I can't remember not having access to a television. What an interesting experiment it would be to consciously decide to not have TV available. My goal, aside from curiosity and a desire to not spend a few hundred dollars, was to make other, more beneficial means of entertainment more appealing. I would start with reading more and follow with writing more. This experiment combined with my interests lead me to William Zinsser's phenomenal book, "On Writing Well."

I would highly recommend that anyone who ever plans to put at least three words into sequence should read this book. Not only is it relevant for long-form writing and essays but also public speaking and interoffice communication: two things I seem to do a lot of. What especially impacted me, though, was the final chapter. After just under 300 pages of discussing how to write well, he switches to a more philosophical subject. He begins to discuss why you should write well.

He had a passion for quality and had no patience with the second rate; he never went into a store looking for a bargain. He charged more for his product because he made it with the best ingredients, and his company prospered…

Only later did I realise that I took along on my journey another gift from my father: a bone-deep belief that quality is its own reward. I, too, have never gone into a store looking for a bargain. #

Ostensibly, those passages apply to writing. In reality, they apply to so much more. In reality, they represent a mitigation of so much of what's wrong with modern anti-culture. As much as I enjoyed working as a consulting web developer, the consistent disinterest in quality drove me from it. I love writing good software. I love working on teams with people who really care about building something the right way. The way that will last. The way that will make our inevitable successors understand and agree with the choices and tradeoffs we made. The way that, when you have a long view, makes sense. My current team is a great example of this: 7 other people who love doing things right.

Unfortunately this is not the prevailing trend. Not in the software industry or the automobile industry or the world. The prevailing attitude among so many people isn't, "I'd like to buy a really nice pair of shoes, take proper care of them, and wear them for the next 40 years." Instead people are raised to always want a new pair of shoes, a new house, a new car. Advertising indoctrinates them to believe that's ok. "You deserve a new pair of shoes", they hear, "and it's ok, they're mass produced and they're so cheap that everyone can afford them!" And so, instead of buying 2 pair of Allen Edmunds or Aldens, they buy 20 pairs of Nike and New Balance.

Not only is this wasteful and materialistic, but it robs one of the inherent joy that comes from good. Good is replaced by the cheap imitation that is new. Shiny. Gaudy. This isn't anymore sustainable in shoes than it is in software. As programmers and system architects, it's our job to emphasis this. Capitalism is capitalism. It will always prefer cheap to good and now to later. The only way to prevent that is to stop undercutting ourselves and stop minimising the costs that come with doing something wrong.

Sure, the application could be done in a month by an understaffed development team. It's going to be ugly, have a bad user experience, tarnish the company's name, and occasionally delete the user's entire home folder. Or…we could hire another developer, take 3 months to build it, and make record profits.

Some companies will never accept that. A bad application is good enough, they will say. Those companies will eventually fail. As a developer, though, it's still our job to try. "Several magazine editors have told me I'm the only writer they know who cares what happens to his piece after he gets paid for it…yet to defend what you've written is a sign that you are alive."# To defend quality is a sign that you're a good programmer. To defend quality is to have satisfaction is your work.

SilverStripe and a few other frameworks use a variant of standard HTML comments within their template engines. This enables the engine to easily strip out comments before sending the page to the client, but it does cause an issue for most syntax highlighting text editors. Since Sublime Text 2 is my editor of choice, heres a simple Gist to make it syntax highlight these comments correctly. Add the above excerpt to HTML/HTML.tmLanguage in your Sublime Text 2 Packages directory.

View with Gist

Don't misunderstand what I'm saying: I love my job and I love the people I work with. Like any programmer these days, recruiters contact me semi-frequently, yet they never receive anything more than "Thanks, but I'm content," from me. Besides, I love being busy. Like most other ADD inflicted introverts, there are few things I fear more than not being busy. Being busy with meaningful tasks gives someone's life purpose, direction, and satisfaction. So what's the issue?

The issue is that my backlog continues to grow and is quickly exceeding my capacity. I can keep up at work—but that's far from all I need to do in a day. Regularly, I'll decide I need to read a new book or I'll come up with a programming idea I'd like to try. Someone recently gave me a guitar, so now I need to learn how to play it. I have sticky notes everywhere reminding me to take more time to write, to go cycling for a few hours, to meditate, to learn to speak Mandarin. All of these are important tasks with specific (although not always obvious) reasons for their existence; all of them sitting in my backlog waiting to get done. At my current burn-rate that day will never come.

Something needs to change. But what? I can't work less—In all reality I should work more. I can't eliminate any of the projects above. But I can eliminate kipple. How much time do I spend on email every day? What about Twitter? Instagram? Facebook? RSS Feeds? Honestly, I don't know. I have absolutely no empirical data that says I'm wasting my time and cognitive energy reading Twitter, but I know it's taking a non-trivial chunk of time. Time that could be better spent finally reading the untouched books sitting on my shelf, becoming more physically fit, meditating and regaining perspective, or spending time with the people I care about.

I've decided to take action. I'm not getting rid of Twitter or Facebook or Reeder, but I'm cutting them off at the knees. I just cut my Twitter following count by 60%. I cut Facebook down to 30 friends that I really, actually know. In Reeder I now subscribe to 36 RSS feeds, down from a peak of over 150 a few years ago.

I'm keeping all of these services around because they do have value: they help me be aware of important news and keep in touch with good friends. I've simply trimmed the fat and raised the bar on the quality of the content I'm going to consume. Too much of the content I was spending time on was completely inconsequential and frighteningly shallow. Instead of content being a way to convey important information, it was a way to spend time and to distract myself from thinking about difficult problems. That's something I can no longer afford to do.

In short: time is the most valuable and exceedingly scarce resource in the Universe, so I've decided to treat it as such.

When you sit back and look at it web application development is a total disaster. If you tried to conceive of the "ideal" UI platform (or even a "good" one) you would never, in a million years, come up with what we've got now. It is a testament to the skills of everyone in the industry that things like google maps, Gmail etc. can be built on this sky-scraper of bananas. No wonder it is hard to learn.—josephcooney

I completely agree, yet despite being a skyscraper of bananas with a million moving parts, a well designed web app still has both better typography and a better user experience than the vast majority of desktop software—especially desktop software on Windows. What a great example of how tools matter a lot less than most people think. What really matters in building a great product isn't the language it's written in, but rather hard work and great attention to detail.

Hacker New—Why Codecademy is overrated and missing it's target audience

This couch doesn't have drop shadows and an unnecessary 'loading' animation, metaphorically speaking. This article is a great description of the product of what good designers do. It's cheap to manufacture. Easily deployed and assembled. Well suited to its primary purpose. Incorporates multiple additional uses without compromising the primary use. Flexible enough to be reconfigured easily for different locations. Best of all, it doesn't have any unnecessary 'design' frills. — HN Comment dicussing Ikea furnature

In otherwords, good design is discovering what you think is a new use case for a product and then realizing, "the designers obviously already thought about this." Good design is the complete lack of arbitrary decisions.

Design, Innovation and Hacking in a couch

The difference, I think, is our own fault. When's the last time you saw an online article that looked like page from The Hitchhiker's Guide to the Galaxy or Anathem? Don't be surprised if you can't think of one, because I can't either. Online reading is plagued by absolutely horribly designed flash ads and other sorts of chrome surrounding it. We're programmed to be drawn to motion, so if there's an invasive flash ad complete with video and animation sitting right next to a long-form article, who can blame our brain for tending to stare at it rather than focus on what we're reading?

The solution then, to online writing, is not to write ever shorter articles. Who wants to live in a world where the New York Times produces nothing but Twitter posts? Rather I think we need to bring back the long-form article and remove what has been slowly killing it: distractions, bad typography and noisy pages. Then, just maybe, we'll be able to regain the attention of the continually more distracted reader.

If you're using Node.js, you're doing life wrong

This morning, on a conference mailing list, I made some disparaging remarks about Node.js (the title of this post, in fact). A couple people asked me why I felt that way. Rather than respond individually, I'll just list my reasons here — codeslinger.posterous.com

I really don't understand all the hate for Node.js. It seems like many of the articles and rants against Node.js assume that Node.js was supposed to be good at everything. It's not. Just like every other framework and language in existence, it's good at some things and bad at others.

Node.js, at least from my understanding, was designed to be great at transporting small bits of information around the internet very quickly, and in real-time. Server-side events, instant messaging apps, real-time games, and collaboration tools are all great example of this. Take for example Trello. Trello is a real-time collaboration app that leverages Socket.io and Node.js to enable real-time propagation of events and state-changes between clients. You could do the same thing with long-polling ajax or even frequent polling, but those both come with the cost of tying up unnecessary worker threads on the server and dealing with extra requests. Node.js on the other hand is inherently great at this. It's asynchronous event based architecture makes receiving, processing, and sending real-time events simple, painless, and very fast.

At the same time, Node.js isn't isn't especially good at computation. If for example you were trying to build an API to return the nth number in the Fibonacci sequence, Node.js would almost certainly be a bad choice? Why? The whole reason to use Node.js is based around the idea of not waiting on things. Instead of waiting for a db query to return results, it just triggers a db query and sets a callback event. Then, while the query is processing, your program can be doing other things (like handling another request). This is what makes Node.js seem so fast, without actually using more than 1 CPU core. In our example of computing Fibonacci numbers, however, the program doesn't need to wait on anything. The speed at which such an API can return results is directly linked to how fast it can compute a result. So here it would be better to use another, computationally faster language like Haskell or Scala.

So what's the point of all this? The point is that it's silly and irrational to complain that a framework isn't good at completing task A, when it was only ever designed to do task B. Node.js is extraordinarily good at what it was designed to do- so don't rant that it's bad at something else.

You can discuss this post on Hacker News.

Makebelieve Help, Old Butchers, and Figuring Out Who You Are (For Now)

After moving to NY however, I've been able to more fully identify what bothered me about the pervasive culture of that area: people were too comfortable. Not materially comfortable, but mentally comfortable.

comfort considered harmful?

Perhaps the anti-quality I'm describing could be better called complacent or ambitionless, but regardless of the technical symantics, I think the word comfortable describes it well. So what is it exactly that I'm describing? The almost subconscious feeling of hopelessness; that there's nothing they can do about noticably subpar conditions. Instead of taking action and working towards making improvements, they decide that either 1) there's nothing they can do about the problem, 2) someone else will fix it for them, 3) the problem will magically fix itself, or 4) they'd rather ignore the problem than go out of their comfort zone to try to fix it.

All of those are fairly major problems, but I'm of course a programmer and not a sociologist, so I only feel qualified to talk about the last one (as it often affects programmers). All too often programmers, including myself, get stuck in a comfort zone. They decide that language X on platform Y is their domain and anything else isn't their problem. They get comfortable with one litle corner of their teams application, decide to become it's "owner," and that they shouldn't stray to other parts of the application.

"Owning" a piece of code isn't the problem, in fact thats generally a very good thing; the problem is the fear it can induce. When you confine yourself to arbitrary bounds for very long, anything on the outside of those bounds suddenly becomes scary. You start becoming afraid to touch anything else. Afraid to write/rewrite something unfamiliar simply because it's outside your comfort zone. Absolutely afraid of traversing the stack. Terrified of breaking stuff.

Confining yourself to working on code/problems/domains that you're comfortable with will overtime cripple you as a programmer. So instead of getting comfortable and settling in, please, find something that looks like black magic and figure out how it works. Find a bug on a different OSI layer. Break stuff! Just whatever you do, don't stay comfortable.

A supersaturated solution is one in which the saturation point, at which no more material will dissolve, has been exceeded. This can occur because the saturation point becomes higher as the temperature of the solution is increased. When you dissolve the material at a high temperature and then cool the solution, the material sometimes doesn't crystallize out because the molecules don't know how. They require something to get them started, a seed crystal, or a grain of dust or even a sudden scratch or tap on the surrounding glass.

He walked to the water tap to cool the solution but never got there. Before his eyes, as he walked, he saw a star of crystalline material in the solution appear and then grow suddenly and radiantly until it filled the entire vessel. He saw it grow. Where before was only clear liquid there was now a mass so solid he could turn the vessel upside down and nothing would come out. The one sentence "I hope you are teaching Quality to your students" was said to him, and within a matter of a few months, growing so fast you could almost see it grow, came an enormous, intricate, highly structured mass of thought, formed as if by magic.

— Pirsig, Robert M. (2009). Zen and the Art of Motorcycle Maintenance (Kindle Locations 2950-2959). HarperCollins e-books. Kindle Edition.

What idea is supersaturating your mind? What will be the scratch in the glass that starts crystallization?

In June 2011, I got an invitation to move to Brooklyn, NY and work as a volunteer at the World Headquarters of Jehovah's Witnesses for a period of 3 months. Since this is something I applied for a while ago and have been working towards for as long as I can remember, I gladly accepted. At the end of those 3 months I was asked to stay another 3 months, then recently I was asked to stay for another year. Despite having to turn down some great offers and opportunities from some very interesting companies, I'm quite happy that I decided to stay here.

I'm working as a full-time developer on jw.org, a web-application with the purpose of distributing free, downloadable literature, and providing many other non-public facing, data-centric services. It's definitely exciting to work on a project of such large scale, serving over a quarter million uniques per day.

Anyone familiar with Java, C, C++, or another similar language would easily recognize this code:

switch (n) {
      case 0:
          puts("You typed zero.");
          break;
      case 9:
          puts("You typed nine.");
          break;
      default:
          puts("You didn’t type Zero or Nine.");
          break;
  }

This is a simple switch statement, generally used when IF-THEN-ELSE blocks would be overly complex or unwieldy. Python, however, doesn’t have switch { case } syntax, so we have to be a little clever. The most obvious way to duplicate the above code would be:

if n == 0:
      print "You typed zero."
  elif n == 5:
      print "You typed five."
  elif n == 9:
      print "You typed nine."
  else:
      print "You didn't type zero or nine."
  

That’ll work, but its a little wasteful when it comes to line count or more complex cases. We can simplify this quite a bit by making use of Python dictionaries:

cases = {0 : "You typed zero.",
           5 : "You typed five.",
           9 : "You typed nine."}
  if n in cases.keys():
      print cases[n]
  else:
      print "You didn't type zero or nine."
  

In that example, every possible case is placed as a dictionary key and the string to be printed is the value. In this example we only save 1 line of code, but we also cut the execution time drastically. On my machine (Core i7 920), example-1 takes 4.999ms to execute. Example-2, on the other hand takes only 1.999ms; this means its a speedup of roughly 250%. An extra 3ms may not be much, but in complex cases, limited hardware environments, or extremely time sensitive application it does.

Finally, we have one more example. What if you want to call functions instead of print strings? Thats easily done with almost the same code:

cases = {0 : Object.function_1,
           5 : Object.function_2,
           9 : Object.function_3}
  if n in cases.keys():
      cases[n]()
  else:
      Object.default()
  

In this example, each function call (minus the calling parenthesis) is placed as the value of its respective key. Since we don’t include the parenthesis, the function isn’t called yet. Then, on line 5, we select the appropriate function and call it.

Marie Antoinette did not actually use the phrase "let them eat cake" when she heard that the French peasantry was starving due to a dearth of bread. The phrase was first published in Rousseau’s "Confessions" when Marie was only 10 years old and most scholars believe that Rousseau coined it himself, or that it was said by Maria-Theresa, the wife of Louis XIV. Furthermore, although the proclamation may sound callous, it was actually made out of generosity and economic logic. What Rousseau or Marie-Theresa actually said was, "Qu’ils mangent de la brioche," essentially meaning that the peasants should be able to eat brioche, a sweeter egg-based bread instead of their normal fare. In fact, French law mandated that bakers sell their brioche at the same price as their cheap bread if their cheap bread ran out. Marie Antoinette was a very unpopular ruler and many people therefore attribute the phrase "let them eat cake" to her, in keeping with her reputation as being hard-hearted and disconnected with her subjects.

So, what she actually meant was if a baker ran out of bread, they had to sell their more expensive ‘cake’ for the same price so that the peasants could afford it.

Wikipedia Article

• Good design should be innovative.
• Good design should make a product useful
• Good design is aesthetic design
• Good design will make a product understandable
• Good design is honest
• Good design is unobtrusive
• Good design is long-lived
• Good design is consistent in every detail
• Good design is environmentally friendly
• Good design is as little design as possible

Whether you’re a web, graphic, or industrial designer, we all get stuck in ruts occasionally: blindly following trends, designing for the sake of design, etc. I think its very beneficial to frequently stop and use these rules to evaluate our latest work. It may cause you to realize that something in your design is completely arbitrary and is either unneeded or can be improved.