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
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.
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.
Honestly, this is the hardest part for me. I have no problems apologizing. ↩
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.
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.
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.
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:
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.
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.
We have some established rules and I really need to make sure that:
I am following the rules
The rules are being enforced
Any currently broken rules are fixed
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 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
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.
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.
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.
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
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.
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.
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.
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.
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!
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. ↩
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.
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.