News coverage and postmortem

October 27, 2008 by

I posted a brief “ClayValet in Hindsight” post on my blog.

Also, for completeness, a couple of news blogs covered the demise of ClayValet:

Shopping startup ClayValet shuts down, liquidating assets – Brier Dudley for the Seattle Times

ClayValet closes doors – John Cook for TechFlash

RIP ClayValet. Developers, office space, and web assets available

October 17, 2008 by

(I sent the following email to the SeattleTechStartups this morning. Reposting here for the record.)
Hi everyone,

Unfortunately, I’m writing to announce that we are closing our doors after 22 months in business. I am working out the transition details over the next few days. We’ll post the story of ClayValet; I’ll send
another email when it’s online.

In the meantime, some of you may be interested in helping us liquidate:

Startup developers (Ruby/Rails, other languages, Linux)
——————————————————-
My colleagues, Ken and Jason, are now available for full-time and contract development work here in Seattle. If you’re hiring developers, you should really talk to them: they’re smart, they learn fast, they both know several languages, and they’ve done quality work on our Rails website and Ruby workflow engine. I’ll be happy to put you in touch, forward you their resumes, and serve as a reference.

Ideal startup office space
————————–
Our office space is the best deal in Seattle. It’s paid through the end of the month; for $600/month (+ $100/parking) you get 700+ square feet as 4 private offices in a great Capitol Hill location (1631
Belmont #1, 98122). For an additional $600 up front, it comes with desks, office chairs, breakroom furniture, and Speakeasy DSL (which we can transfer to you, saves 2 weeks of installation). It’s the perfect
starter package for a frugal startup. Map:

http://maps.google.com/maps?q=1631+Belmont+Ave,+Seattle,+WA+98122,+USA&ie=UTF8&ll=47.623637,-122.320232&spn=0.007854,0.020084&z=14&iwloc=addr&om=0&source=embed

Software and Web assets
———————–
Also available:
- Our workflow engine, built in Ruby on top of MechanicalTurk, makes it easy to use Mechanical Turk for non-trivial tasks.
- Our Rails website (SaneShopping.com) with content, domains, shopping experts, and 800+ registered users, currently running on Amazon EC2 (including MySQL master/slave replication with S3 backups)

Please contact me about any of these, and thanks to STS for your support over the last couple of years. Best wishes to all of you in your own endeavors.

Mikhail
——
SaneShopping. Remarkable personal advice.

http://saneshopping.com

——
Mikhail Seregine, CEO
206.909.8296 cell
mikhail@clayvalet.com

Trust: The Librarius Virtues and the Optimization of High-Level Code

September 2, 2008 by

I learned to code about the time I learned to read (fairly late), so in the modern world I am not necessarily as good a coder as people who learned in high school or college–the world of 0.995 MHz 6502 ASM is not the world of 2GHz Dual Core X86 Ruby. The practices appropriate to coding on tiny, hardware-level machines don’t really jive in a world with operating systems and enough memory.

It comes down to trust, and if we may paraphrase one Francis Fukuyama out of context and into our context of databases and high-level languages: Trust reduces transaction costs. One must trust the database to be efficient with its queries, and not simply grab whole tables and perform one’s own queries. One must trust hash functions to be efficient and not code them up as needed. One must trust libraries, sorting algorithms, internal data structures, drivers, and especially parsers. One must also remember overheard, and not make database queries on inner loops.

There is more to optimize for than execution speed and low-memory consumption (or rather, just speed given that all memory will inevitably be used). The 4K demo contests preserve and transmit the old ways, and these are a valuable and venerable tradition. But execution speed is not the only criterion for which one optimizes. Perhaps this is why modern programming is sometimes called software engineering, as if one were engineering solutions to balance a number of criteria. Despite the number of promising open problems (like the complexity of computing Nash equilibria for various classes of games), day-to-day optimization tasks tend to balance a number of concerns, and when obvious ‘optimize for speed’ cases come up, often the best solution is to trust the code base. And by best we might mean readable, quickly coded, stable, reliable, easiest to maintain, and not just fastest during execution. I have even heard tell that premature optimization is known to be something one wishes to avoid.

One of the grand, not-quite-over-looked but definitely under-appreciated prospects for accelerating the growth of growth (second derivative, if you will) is the phenomenon of re-usable code through libraries. The modern world suffers from superstar effects and network externalities–you only need a few really good writers and everyone reads them, if an operating system is really bad everyone still has to use it because everyone else still uses it–but these dynamics of path dependence are not totally on the side of entrenchment and against progress (as trendy as it is to belittle those who believe in ‘progress’ rather than simply ‘adaptation’ I should say that having lived a little while I find the empirical evidence strongly on the side of progress, perhaps due to adaptive arms races but too evident nonetheless).

I suppose that for a modern developer this is patently obvious, but it may have been less so back in the day. On an old computer, you really couldn’t just write functions in LISP without thinking about the internal representation and the costs of certain operations. Alan Perlis was correct when he observed, “Lisp programmers know the value of everything and the cost of nothing.” The STL in C++ back in the day too was a little iffy, and things would break for reasons obscure to the non-expert. Hardware libraries for graphics required a lot of empirical testing to infer which functions were faster than others in what circumstances. Risk aversion was indicated, as the cost of writing things from scratch (part of the fun really) might be less than the cost of debugging something that doesn’t quite work as we might expect. What has changed? The Internet.

If we use a library, and something does not go quite as expected, we can plug the error message directly into Google and almost always someone else has had the same problem. Typically there is a solution or workaround, and the next version of the library will be fixed. Because technology changes so quickly, rather than mastering a field and perfecting a technique, we end up becoming adept at figuring out how to do what we don’t already know how to do because we’ve never done it. Well, if you like learning new things, this makes development a good day every day.

One does acquire a familiarity with those things which remain somewhat stable, namely the libraries we return to again and again, along with a handful of techniques that come up in any language and on any project, programming being only one aspect of the greater ‘systems’ or ‘enginerring’ perspective of the modern day. Refactoring is one technique. It is admittedly a challenge to get good enough at programming that one can get the computer to do what one likes, but this is like playing the right notes on an instrument, only the beginning, a base literacy. Proper code must be eminently readable, maintainable, stable, provably correct (if possible), documented, sensibly organized, and so on. Coding is like writing an essay but far more demanding. Writing is rewriting, and coding is refactoring. But what has refactoring to do with libraries?

Most code we write is specialized and not particularly reusable; at least, this should be the case if we are reliably refactoring. Theoretically, libraries are like refactoring that has already been done by others across independent projects. If a library hosts a number of functions shared by such independent projects, chances are that our independent project may also share those functions. In a sense, library functions are selected for utmost reusability and flexibility, and the more people who use them, the more reliable they tend to be. So here is one network externality, a superstar effect, that is distinctly on the side of progress (which is not analogous to complexity, indeed refactoring is our great technique against explosive complexity).

All this is to say that in the modern world, I do believe it is safe and wise to ‘rely but verify’ when it comes to libraries.

Finding unused partials

July 26, 2008 by

There’s a large set of view template changes in my client, part of the soon-to-be-deployed redesign. As I was making some of these changes, I wasn’t very careful to delete partials that aren’t used anymore. So I thought I would whip up some ruby one-liners to find these for me.

The following mix of Ruby and zsh is not the cleanest way to do it, but it gets the job done:

1. List all partials in my client

find . -name “_*.rhtml” | ruby -ane ‘
return unless $_ =~ /\/_(.*).rhtml/
puts $1
‘ > partial_names.txt

2. Count the number of times each is referenced.

for i in `cat partial_names.txt`
echo `grep -r “render.*:partial.*$i” ./shopperview/app/views ./shopperview/app/controllers | wc -l` $i >> partial_frequency.txt

3. Sort partials by the number of times they’re referenced

sort -g partial_frequency.txt

June 25, 2008 by

I see Turkey is playing Germany today (Wednesday 2008.6.25) at 11:30am.  Therefore, I’ll be “working” from Cafe Presse.

Come hang out.  But be aware that if you’re wearing a German jersey, we might not be able
to sit together.

Serialized Attributes and Dirty Flags

June 17, 2008 by

Well we seem to have upgraded to Rails 2.1, or at least the new ActiveRecord which runs with 2.1, and this new version is most uncooperative when it comes to saving records after modifying a serialized field. I have been told (by the notorious KenValet) that the dirty flag is not being set on modify but will be set on assignment, so calling ‘save’ doesn’t actually save since as far as MySQL is concerned nothing has been modified. It’s not the sort of thing one expects, and a strange thing to put in an upgrade.

Lazyweb: a Mac Service

June 10, 2008 by

Today I found a Word Count service (for the Mac Services menu).  It’s 8 lines of AppleScript, plus something called ThisService which makes services a lot easier to write. Independently, I have on my desktop an AppleScript called “Move Windows To Main Display.scpt” (sorry, don’t remember where it came from) that moves all my windows back onto the (visible) screen — very useful when I unplug my external display, because Mac OS 10 is no longer smart enough to keep all my windows visible.  Could somebody make a Service “Move This App’s Windows Back Onto This Screen”?  That would be awesome.

How to Describe Ourselves

May 30, 2008 by

I was thinking this morning about how I describe CV. My usual phrase is “we’re an online shopping service”. In my mind, this is “shopping service” (i.e., like a personal shopper) + “online”. But that’s not how people interpret it (“oh, like Froogle?”), so I need something better.

Other obvious words fail, too. People hear “service” and think “web servers” — different kind of service. Or if I say “online personal shopping”, they hear “online” + “personal” = “it says ‘hullo Mike’ when I log in”. “Social” is similarly overloaded. So I’m looking for a better word/phrase.

The best I’ve got so far is “human”, as in “human shopping service”. The term “human-assisted search” does exist, and kind of describes the superset of the problem we’re solving. But it isn’t a common term, so it’s a description that encourages questions.

Nearer, my opinions, to thee

May 22, 2008 by

I wish I knew enough about things to have opinions about them. Other people have ideas, and they’re sure of them, and I’d like to be that certain about something. In fact, I am that certain about a lot of things, things I know a little something about, which is why my general lack of opinions on technical things worries me.

I run into people with strong ideas about type systems, run-time typing vs static declaration, compiler theory, how best to pass around code blocks and namespaces, object orientation as opposed to other metaphoric systems, the merits of lazy evaluation and infinite objects, threads vs processes or parallelism, monolithic vs micro, or why language/database/framework X is vastly cleverer than language/database/framework Y. I’d like to have opinions too. But I find I just don’t know enough.

My impressions of things are based largely on how they look and whether or not they exist. So I like Ruby a great deal, because it looks nice on the screen, and it exists. I don’t really like Perl because I don’t like the way it looks; Python looks nicer although I don’t care for the tabbing bit. I think Ruby looks best, so I prefer it. I don’t like terminating semi-colons in C/C++/Java, and sometimes too many parentheses make LISP look weird. Assembly code has a nice regularity to it, to be sure, but is not really feasible. When I find there’s some way I can’t do something in a given language, I assume there’s a good reason and just do it another way.

Editors I like for syntax highlighting. I don’t use vi, because I always type something when I’m not in insert mode and something horrible happens, so I use Emacs instead, but just for syntax highlighting; it takes so long to load that I end up using Pico quite a lot. I don’t use any Emacs fancy features, and the huge ELisp bit I only use for… syntax highlighting. So I also like TextMate, because it looks nice and reminds me of Emacs, but I still don’t use any fancy features.

Most of the time, though, I am just too amazed that something exists in the first place to find fault with it. This is not a character virtue, because I find fault with plenty of other things, but when it comes to tech, I’m just astounded at what’s out there. Perhaps my baseline is set too low, having grown up on C64s and Amigas, where compilers couldn’t exist because we hadn’t the memory or hard drives, and when people hid rather than shared code, when shareware and even expensive serious software was fairly bad, and when monitors were basically cheap televisions that broke a lot. So I can download a free setup like Rails and start a website (a graphical BBS) on a laptop. A laptop? With a flat-panel LCD? A GHz processor? A gigabyte of RAM? That’s insane!

I have had minor problems with MySQL and ActiveRecord, but nothing like the cement wall of impossibility to which I’d grown accustomed. Sometimes we have to do something a weird way because the computer expects it, but that is fine. In the not-so-old days it was like that all the time. Even in the early Linux kernel days, it was a victory when anything worked at all (try getting a sound card set up 12+ years ago, or certain wireless cards just a few years back). Try putting Linux on a laptop. Well, now you can order laptops with Linux, or get a MacBook which is basically Unix-based. Wireless cards, cafes with free internet, 4-hour battery lifespans, cell phones, hybrid cars with screens and gps maps, CDs instead of 5.25″ floppies or tape, ethernet as the norm instead of a beeping modem.

Some people are so accustomed with this environment that they can find fault. I would like to feel so at home in this world that I too could someday find fault with it. The most disturbing thing, to my mind, is that regular expressions are not really DFAs, or that non-deterministic algorithms aren’t a bigger part of daily life. As time goes on, which it does, I find myself using computers more and more for old-fashioned things, studying history or economic modeling, but the machines march on without me.

Hacking Hacker News

May 20, 2008 by

It seems to be standard practice on HN for the first comment on any PDF link (which is automatically converted to Flash, through scribd.com) to be a comment with the original PDF link, followed by 273 comments discussing the various ways scribd.com is disliked.In the interests of “make something people want”, here’s a GreaseMonkey script to de-scribd.com HN PDFs:

describd.user.js

YC probably hates me now, but you can’t win ‘em all.


Follow

Get every new post delivered to your Inbox.