Blog posts from February 2010...
I've got to lose weight. Working from home and the sweeties that line the red bar in the kitchen 6 feet from my desk are killing me. I can't do diets. So here are my simple principals for de-fatting myself that I plan to stick to for the next 3 months to see if it makes a difference.
- No snacks between meals (at all!)
- No desserts
- Evening meal must be the smallest meal of the day
- Drink lots of water
I'm going with the keep-it-simple path to see if just controlling my food consumption is enough. I'll let you all know how it's going in a few days.
Link | Posted by deryck on February 17, 2010 | 0 comments
A couple weeks ago I was in London for a Launchpad team leads sprint.
There were lots of cool discussions, focused mostly on processes within
Launchpad. Because of all this process talk, we ended up talking
about our release process a fair amount. I had some ideas forming
before this, but a week's worth of discussion helped cement my thinking
about "releases" for websites. Now some two weeks later, I'm still
thinking about this, so here's a quick sketch of what's on my mind.
First, websites don't "release" anything. It's a metaphor, and a
poor one at that. We update the site with some version of our code.
Different sites do this differently. With regular updates to
edge (our beta site which many of
our users use anyway) Launchpad has many levels of release -- code
updates to edge regularly, db updates to staging regularly, and roll
outs of both to the main site monthly. Other sites just continually do the
equivalent of svn up on trunk on their site and apply DB
updates as needed.
Using the term "release" so casually also makes you feel like you have
to build in artificial barriers to make the false release feel more
like a traditional software release. Version numbers are a prime
example of this. We give a version number to each month's "release"
on Launchpad, and I think the only purpose this serves is to confuse
developers and users about the meaning of the number. If I download
Django 1.1 and hate it, I can choose to download Django 1.0 and use
that instead. If you hate Launchpad 10.01, there's nothing you can do
about it. If we bork something in 10.01, it's not like we're rolling
back to December's release (whatever it was numbered). We will continue
moving forward, adding a new branch that removes the busted feature or
fixes the newly introduced bug, or what have you.
And it's this very act -- the act of continually moving forward -- that
makes me hate talking about website releases all the more. What
everyone who works on websites wants to do is move forward as quickly
as possible, constantly adding new features and bug fixes to a site.
The moment you place some arbitrary stopping point on the process and
name it a release, you slow down forward progress.
I realize some would argue this a good thing, that stopping causes you
to assess or do QA or ensure some other permanent quality is in the
"release." But there's nothing permanent on the web. I would argue
that rather than faking something permanent, your time would be better
spent getting features and fixes to your users more quickly. I know
I'm not alone in this, but still this word "release" hangs on, even in
web development.
I'm excited, then, to see some of the changes we're proposing to our
"release" process for Launchpad. Björn has proposed a way to
release
features when they are done which will require a new
merge workflow
for our work on Launchpad. These are all good things, even if the
specifics may change as we discuss this among LP developers. The only
thing that would make this better is to drop the word "release" from
any discussions of these new proposals. But old habits die hard, as
the saying goes.
Link | Posted by deryck on February 16, 2010 | 2 comments
Last night I watched
Surrogates,
which was a fun movie. (Yes, I have kids and watch every
movie later than the rest of the movie-going world.) I've also been
watching Caprica.
Then there's this little film called
Avatar, which it
seems the entire world has seen. As I finished watching Surrogates last night, I was struck by how much I'm seeing similar themes in sci-fi films and tv shows lately. These stories deal with people living their lives virtually through some intermediary -- an avatar in a virtual world, a robot, or a life-like robotic avatar, and so on. I suspect this will become even more common as time passes.
This suggests to me that there is a deep-seated sense among artists that such a future (or present) is immanent. People have been doing the machines-take-over-from-humans meme forever, but this is slightly different. This is humans-live-through-machines. Surrogates starts with a 10 year timeline that maps from creation of the first surrogate unit to world-wide adoption, which is realistic for how quickly technology can cause a paradigm shift. I think some form of this experience is very close to being a reality.
I say this as someone who views every activity of life through the "lens" of a computer screen. I'm not alone in this. Everyone I know might as well have a computer or smart phone attached to the body permanently.
I started reading The Singularity is Near some time last year. I've read bits and pieces but haven't committed to finishing it yet. I just recently moved this from "reading" to "to-read" on Goodreads because of this. I mention the book here because it deals with similar ideas -- this notion of a convergence of machine and humanity as we human beings push forward our own evolution. This can sound fantastic in the abstract, until you read the book, take an honest look at our computer-connected lives, or see a few stories like Surrogates, Caprica, or Avatar that make some version of this concept seem possible.
I'm not a technophobe, nor do I work in an area of software development that directly touches this kind of work. I do think, however, that inevitably I'll be connected to this kind of work, if I'm not already. "Everything that rises must converge" is not only a great Flannery O'Connor story, but also a great principal of life and technology. No one really knows what this future will look like, or what parts of it will be good or bad for us. It's nice to see artists wrestling with these questions, though. I'm sure the increase in stories like these only confirms how near such a future really is.
Link | Posted by deryck on February 12, 2010 | 0 comments
JavaScript: The Good Parts by Douglas Crockford
Anyone doing a lot of JavaScript development would benefit from reading this book. I feel very comfortable in the depth of my JavaScript knowledge, and I work with JavaScript on a weekly, if not daily, basis. I still learned things from this book. In many cases, I already knew about the particular peculiarity of JavaScript being outlined, but I learned a bit more about why a particular wart exists in the language.
View all my reviews
Link | Posted by deryck on February 8, 2010 | 0 comments
