Work as a platform

by on

Rian van der Merwe on How to Do What You Love, the Right Way:

Merlin Mann and Dan Benjamin discuss what they call “work as platform.” The basic idea is that we need to stop looking at work as a thing you do for a company. If you view your career like that, your success will always be linked to the success of the company, as well as your ability to survive within that particular culture. You will be at the mercy of people who are concerned about their own careers, not yours.

Instead, if you think about your work as platform, your attention starts to shift to using whatever job you are doing to develop your skills further, so that you’re never at the mercy of one company.

This is a sound concept, and it’s worked out pretty well for me.

The idea of using work as a platform has been around since at least 1997, when Tom Peters wrote about it in his fantastic article, A Brand Called You:

A career is now a checkerboard. Or even a maze. It’s full of moves that go sideways, forward, slide on the diagonal, even go backward when that makes sense. (It often does.) A career is a portfolio of projects that teach you new skills, gain you new expertise, develop new capabilities, grow your colleague set, and constantly reinvent you as a brand.

Back then it was called “Personal Branding,” but it’s the same thing. Regardless, it’s a healthy approach to life and work

Making it big

by on

Iggy Pop’s keynote had an interesting point about making it big. I’m not really sure what the rest of the keynote was about though.

I told him [Johnny Ramone] look, some guys are born and raised to be the captain of the football team and some guys are just gonna be James Dean in Rebel Without a Cause and that’s the way it is. Not everybody is meant to be big. Not everybody big is any good.

I like the idea of things just being what they are.

Owning up and awareness

by on

This is Not a Pattern, Ways Men In Tech Are Unintentionally Sexist:

If you care about others, nothing feels worse than realizing you accidentally stepped on someone else’s foot. I really think it’s a natural reaction to bristle a bit, to try to minimize it, to protect ourselves from feeling bad. Once I recognized that defensiveness as a natural part of the process, it was much easier for me to realize I was doing it, then apologize and move on instead of digging myself deeper. It takes practice.

The truth is that this applies to any type of offense, not just sexism. I’m trying to be more conscious of this lately.

Being more conscious of this reaction (defensiveness) has helped me to be more aware of my actual feelings: when I slow down enough to process my feelings1, rather than acting out on my gut, I become more aware of my rationale for being defensive in the first place.

More often than not, my rationale and my default reaction are both flawed. And more often than not my feelings change once I actually think about them.


  1. Honestly, this is the hardest part for me. I have no problems apologizing. 

Finally! Same-sex marriage in Arizona

by on

Attorney General Tom Horne finally gave up the fight against same-sex marriage in Arizona! It’s official as of Friday, October 17—if you’re gay, you can legally tie the knot.

This ruling overturns two Arizona laws — one is a ban on same-sex marriages passed by the Legislature, and another is an amendment to the Arizona Constitution, which was passed by voters, that defines marriage as a union between one man and one woman.

Robin and Renee were there, and were on the cover of the Arizona Republic today, and featured on AZ Central:

In August, they married legally in Hawaii, so Friday’s decision didn’t mean a trip to the courthouse.

“It was all worth it, absolutely 100 percent,” Renee said. “We decided to fight for our family and our kids. To see this overturned and all this excitement happening … I’ve been shaking all morning.”

So a hearty congratulations go out to all of our same-sex friends and family! You deserved this victory!

You kids get off my lawn

by on

Ernest Hemingway, on “put your damn phone down for two seconds while we’re talking so we can have a normal conversation about something”:

Listen now. When people talk listen completely. Don’t be thinking what you’re going to say. Most people never listen. Nor do they observe. You should be able to go into a room and when you come out know everything that you saw there and not only that. If that room gave you any feeling you should know exactly what it was that gave you that feeling. Try that for practice.

via ma.tt

Obama says hell no to FCC

by on

In one of the first signs of sanity from our government regarding Net Neutrality, Obama spoke out against the FCC’s Internet death march:

I know one of the things people are most concerned about is paid prioritization, the notion that somehow, some folks can pay a little more money and get better service, more exclusive access to customers through the Internet. That’s something I oppose. I was opposed to it when I ran; I continue to be opposed to it now.

It feels good that our collective resistance to Tom Wheeler’s ridiculous destroy-the-internet-plan got the President’s attention.

Maintenance mode

by on

My Dearest Codebase,

I’ve so thoroughly enjoyed the last few years together with you. When we started out we were passionate and alive; we approached every problem in fresh, creative ways. It was just you and me—lean and mean. You’re amazing in so many ways: you held up even when you were stressed; you’ve always been adaptable and ready to try new things; you get along great with my co-workers, and they seem to like you a lot too. I’m damn proud of you, Codebase.

We’ve made it through some tough times together. For a while there I wasn’t exactly sure what I was doing: I spazzed out and made some mistakes; I didn’t always think things through, and that was pretty hard on us. We’ve both lost legacy code now which has stretched us both; you had some health issues and had to go through that big refactor, which I’m so glad we don’t have to worry about that any more.

In the midst of all this we spawned several more “Lil Codebases” together, which has added a whole new dimension to things. It’s been fun pouring everything we’ve learned together into them. I look forward to the times I get to play with each of them—they’re still so fresh a small and carefree.

We’ve been fixing a lot of bugs lately—maintaining our relationship. For months we’ve been at it, making things better a little at a time. Slow and steady, and we’re doing a great job, in my opinion. Bug fixing can get pretty boring though, so I wanted to make a list of things to do during this slow time in our lives:

Comments

For the most part what we do is self-explanatory, but there are some things that are worth a little more elaboration. We should leave more notes for each other: a little note about a new trick I learned, or a problem you’re facing that we need to discuss.

Clarity

I can get a little terse at times. Other times I’m too abstract. I could definitely try to be more clear. Maybe updating things I’ve written to be a little easier to understand.

Standards

We have some established rules and I really need to make sure that:

  1. I am following the rules
  2. The rules are being enforced
  3. Any currently broken rules are fixed

Performance

We’re both a bit bigger than we should be and we’re getting slow and a little tired. A healthy diet is good, but I think it’s time for a dose of exercise. It would be nice to have a little more pep, and less bloat in general. Honestly most of our performance issues could probably be solved with just a few changes.

Unit tests

Unit tests are the little signs here and there that let us know we’re on the right track. We’re doing alright, but there’s definitely room for improvement. Maybe it’s time for a date night—get that code coverage up a little higher. Or maybe a little check-up with the couples counselor (AKA unit tests) just to make sure we’ve really got a thorough understanding of how things are supposed to be working.


Thanks for being so awesome, Codebase. I’m looking forward to spending some more time with you—even if we’re in maintenance mode.1


  1. P.S. Inspired by The Daily Post 

Mimosas 1.0, Smalltalk-style MVC

by on

An upclose shot of a bright pink mimosa flower with yellow blossoms
Mimosa Blossom Macro, by .

Over the past few years I’ve begun to explore application architecture in earnest. My latest attempt, Mimosas, has worked out well in production so I gave it the big 1.0. Here’s its first introduction to the world.

Module, Facade, Mediator architecture

My first real attempt at a cohesive architecture was Aura, co-created with Addy Osmani and later brought to life by many other very talented engineers. From the about page:

Aura is an event-driven extensible architecture for wrapping your code into reusable components and extensions that can easily communicate with each other.

Aura works great with existing frameworks like Backbone.js or Ember, but is framework-agnostic, adapting many best-practice patterns for developing maintainable applications.

Request-driven architecture

Later that year I started thinking about the solution to a host of architectural issues I was facing at work. After months of consideration, I attempted a re-interpretation of an old Java stand-by, Request Driven JavaScript Applications with Core J2EE Patterns.

I got turned on to the Core J2EE patterns while reading PHP Objects, Patterns, and Practice by Matt Zandstra. In his book, Matt demonstrates a super common approach to PHP apps using the J2EE patterns as a guide. I’ve come to call this approach request-driven, and it is used by many if not all of the most popular PHP frameworks.

The request-driven approach mostly means that the URL drives the behavior of the application. Backbone and a few others do this with Routes, but it is fairly de-emphasized in comparison to server-side frameworks.

I’m proud to say that my implementation of the request-driven architecture has been in production for several years now. It’s had a ton of testing and real world use by some huge brands, under some pretty decent traffic. It’s really turned out to be a hit in my mind.

MVC as it was intended1

For some time I have been dissatisfied with the state of MVC frameworks. Most aren’t truly MVC and many are very difficult to use. Maybe this is because documentation about the original MVC implementation is fading away. Or maybe it’s due to a collective misunderstanding about MVC in general.

Authoritative documentation on the Smalltalk approach to MVC is hard to find. I read white papers, blog posts, books, and source code in search of The One True MVC. I consider Applications Programming in Smalltalk-80™: How to use Model-View-Controller (MVC) by Steve Burbeck, Ph.D and A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System (PDF), by Glenn E. Krasner and Stephen T. Pope, to be canon. Design Patterns: Elements of Reusable Object-Oriented Software, does a great job of explaining how each part of the MVC triad should be implemented with the GoF design patterns.

I wanted to try to create a JavaScript based MVC framework that was true to the original implementation. To do this, I basically had to reverse-engineer MVC from the canonical sources and bits of Smalltalk 80 lying around the web. I’m really happy with the result. I called it Mimosas, which also happens to be (what I think) is a clever little recursive acronym:

Mimosas implements MVC’s original Smalltalk-80 architectural system. It is an honest attempt to disconnect from all the fancy modern development paradigms and reconnect with the basics of MVC. The aim is not to be a clone of Smalltalk MVC, but to capture its spirit, build upon its foundations, and possibly make something useful in the process.

How it works

As in Smalltalk, Mimosas divides an application into three parts, the model, view, and controller.

  • Models use the Observer pattern to notify views that data has changed, optionally passing additional data about the operation that triggered the notification
  • Views use the Composite pattern to create a hierarchy of UI elements that form the application
  • Controllers use the Strategy pattern to handle events from views

In Smalltalk-80 views were always hierarchies, with one single “top view”, and many child views. A single view could represent both single items, such as a checkbox, or more complex components, such as a list of selectable items.

In Mimosas, the top view and other views which can have children implement the ViewComposite class, which is the Composite in the Composite pattern. Views that do not have children implement the ViewLeaf class, which is the Leaf in the Composite pattern. Both classes inherit from the ViewComponent (Component), which in turn inherits from the ViewObserver (Observer).

Views and controllers are tightly coupled. They both maintain a reference to the other. Mimosas minimizes this coupling by forcing views to communicate with their respective controllers through the ControllerContext class, which is the Context part of the Strategy pattern and can be viewed as a sort of Facade in this scenario. This communication happens transparently.

Lastly, models can be strings, a single object, or a collection of objects. Smalltalk didn’t really care, as long as they inherited from a base object. In Mimosas that object is the ModelSubject.

Installation

Mimosas doesn’t have any dependencies. The only file that is required for use in your project is mimosas.js. There are three options for obtaining this file:

Once you have Mimosas somewhere in your project, check out the Getting Started section.

Getting Started

You can use Mimosas in the browser with AMD and globals, or on the server using Node. This is accomplished with the returnExports UMD pattern. The controller/view event handling needs to be refactored to work without the DOM on the server side.

// Node
var Mimosas = require('libs/mimosas');

// Browser AMD
define(['libs/mimosas'], function (Mimosas) {});

// Browser Globals
window.Mimosas;

Next, create your Models, Views, and Controllers by extending Mimosas core classes. If you’re using plain JavaScript you’ll need to manage inheritance using the Mimosas.Class.extends method. Whenever there’s talk about “extending a class” use this pattern with your constructor functions:

var MyClass = (function(classToExtend) {
  Mimosas.Class.extends(MyClass, classToExtend);
  function MyClass() {}
  // ..prototypes
})(ClassToExtend);

Here’s a basic example:

var Model = (function(classToExtend) {
  Mimosas.Class.extends(Model, classToExtend);
  function Model() {}
  // ..methods
})(Mimosas.ModelSubject);

var View = (function(classToExtend) {
  Mimosas.Class.extends(NewSongView, classToExtend);
  function View() {}
  // ..prototypes
})(Mimosas.ViewLeaf);

var Controller = (function(classToExtend) {
  Mimosas.Class.extends(NewSongController, classToExtend);
  function Controller() {}
  // ..prototypes
})(Mimosas.ControllerStrategy);

If you’re using CoffeeScript it’s a little easier. For example:

class Model extends Mimosas.ModelSubject
  # ..methods

class View extends Mimosas.ViewLeaf
  # ..methods

class Controller extends Mimosas.ControllerStrategy
  # ..methods

Within the project I have included two examples that will help you to structure your application in a sensible way. One is a command-line application and the other is for use in the browser.

In a very meta way, the source code itself is an example of how to combine patterns to form working applications. When I began learning about design patterns I had a very difficult time understanding how to do this. Maybe it will help someone else.

Parting thoughts

I never started out for this to become yet another MVC framework. Honestly, it was a personal project that grew into something bigger (at least in my head). But what I’ve learned is MVC as existed 20-plus years ago was simple, understandable, and extendable in ways that are rarely seen these days. No wonder it was so transformative!


  1. It has been argued that MVC is not an architecture. Based on my understanding of the Smalltalk implementation, I believe the intention was that it would serve as architectural framework. I agree and now have proof that MVC can absolutely work as an architecture. 

Daydream

by on

Looking up, over a sandstone hill, at the bright sun behind the clouds.
The Chains at Lake Powell, by .

The engine drones on and on for hours, modulating rhythmically each time the hull lifts over a wave. Blue-green water and red canyon walls in all directions, as far as the eye can see. Warm wind blows—a cold splash of water invigorates and refreshes.

When the day is done—the bow of the boat beached upon the sand: watch the sun play peekaboo behind the clouds; listen to the water clap gently against the boat. Until rest settles in and a sublime calm washes over.

daydream

Our Hateful Internet

by on

Criticism is, arguably, healthy; bikeshedding, while exhausting, is bound to happen; drama will unfold, as trite as the topic may be. These characteristics, make the Internet less pleasant, but are still tolerable. One thing that is not tolerable, however, is hate. And the Internet is full of it.


Dave Winer, prolific blogger, discusses how hate-filled people are, drawn from his experience after 20 years of blogging:

I’ve learned that creating new stuff is a great way to get people to hate you. To create stuff you have to take a stand. You have to say “This is the way to do it.” That pisses almost everyone off. People who think it should be done the other way hate you. And people who think it should be done the same way hate you too, because it was their idea, not yours.

Kathy Sierra understands this better than anyone, and calls it out in Trouble at the Koolaid Point:

It begins with simple threats. You know, rape, dismemberment, the usual. It’s a good place to start, those threats, because you might simply vanish once those threats include your family…

That’s just scratching the surface of the horrific things people do online. Threats, hate speech, and actual real-life, physical assault are serious offenses.

The Internet has become such a terrible, toxic place.