I have always understood the World Wide Web to have originally been
motivated and shaped by the desire to
exchange documents. Given that, I've always been curious about when the idea emerged to
generate documents and responses on the fly. Well it turns out the
idea was there right from the
beginning.
The relevant bit:
We also have code for a hypertext server. You can use this to make
files available (like anonymous FTP but faster because it only uses
one connection). You can also hack it to take a hypertext address and
generate a virtual hypertext document from any other data you have -
database, live data etc. It's just a question of generating plain text
or SGML (ugh! but standard) mark-up on the fly. The browsers then
parse it on the fly.
- Tim Berners-Lee
On DRY
This was something I was taught early on in my first programming
course. It often feels like keeping code DRY is a significant part of
what programming is about. It's about finding those abstractions. So
not finding (or ignoring) those abstractions is emotionally very hard.
It feels like I am not doing one of the primary things I am tasked
with doing. Not keeping my code DRY makes me a bad developer. When
writing code, as soon as I see similarities, every fiber of my being
is urging me to refactor and make that code DRY. For most of my time
as a programmer I would have immediately given into that urge but
recently I've become convinced by many of the arguments against
premature DRYing like
this one.
This is hard advice to put into action, when you've had DRY drilled
into you for so long. You have to fight that feeling. And what I've
realized is that you have to fight it for a long time. Because often
the pieces of code you are working on will develop in the same way for
some time. And so at each stage where you add something new in both
places you think, “okay surely now I can refactor this”. But this
should be resisted! Keep it going for a while and often you will find
critical bits of divergence so that not keeping your code DRY will
have paid off. It really isn't that difficult to develop these similar
pieces of code in parrallel. The hard part is just ignoring the
screaming impulse to refactor. I have found this has resulted in
simpler code because I am no longer torturing these abstractions into
place.
Two examples:
For an HTMLCanvas compositing library - I have been waiting to
abstract. It's killing me because there are many entities that can
be added to a scene graph and they need to have many of the same
attributes. But realistically duplication hasn't slowed me down and
is leading to better understanding about what is truly similar
between all these objects and what is divergent.
For a live video studio - I have waited to abstract a lot of
repeated UI code for different video sources (webcams, screenshares,
WebRTC streams, local videos) and I was able to iterate very
quickly. It's turning out that the requirements are actually
importantly different between these different source types and I
think that I am unlikely to condense these into a single
abstraction. DRYing early would have made for some very awkward
abstractions.
This
Google Testing Blog article
sums it up brilliantly: "When in doubt, keep behaviors separate until
enough common patterns emerge over time that justify the coupling. On
a small scale, managing duplication can be simpler than resolving a
premature abstraction's complexity. In early stages of development,
tolerate a little duplication and wait to abstract."
Initial post
I'm intrigued by this idea of a
digital garden. Unlike a blog which typically includes fully formed thoughts and
well written posts, a digital garden is a working document whose main
audience is often the author themselves. It's a place where someone
can work out ideas of interest in public. This appeals to me as a
method for being more structured in thinking and learning.
That said, this idea has appealed to me for a while now and I still
don't have a digital garden up and running. Why not? Because every
time I think of doing this it spirals out into a list of other
questions. "What pages should it have?" "What technology should I use
to build it?" "Where should I host it?" And then nothing gets done. A
blank canvas is too daunting. In art school I learned that it's often
best to just put something down on the canvas. Anything. It could be a
line across the middle, or a big circle. The point is, just start and
eventually the rest will follow.
So that's what this is. I'm marking up the canvas in the most minimal
way possible. One "index.html" in a git repo, hosted as a
Github page. And in the spirit
of a digital garden (and mixed metaphors), we'll see how it grows from
here.