On resolutions

I resolved initially to try and write something here once a week, but, well, it’s obvious I’ve fallen short of that. Instead, I’ve realized that I’m never going to be a great blogger, because I don’t desire to – I have better things to do (like reddit, and perhaps, if I ever find spare time, a renovated “park project”). I do, however, enjoy having a place to put my thoughts down publically now and then. Perhaps google+ would be a better place, but having a URL with my identity in it, and not google, is a plus for me.

So my New Year’s resolutions don’t include “write a blog post every week!” I don’t really do resolutions, directly, but in the next year, I’d like to accomplish some of the following:

  • Write a few more posts here. No strict numbers on frequency or total count
  • Start taking tango lessons. Seems like it could be good, fun exercise, and why not?
  • Read more non-fiction. I recently finished Stephanie Coontz’s Marriage, A History, and was fascinated by it. I’m reminded of how simplified the knowledge we get in school and pick up in every day life is; reading a deep, well-researched bit of non-fiction was a nice wake up call.
  • Get something done on that darn web-based rewrite of the park project. My “client” doesn’t have a direct need for it (the current Java version works well enough for the shrinking purposes she has) but I enjoy having a side-project, even if I only make a few hours a month to work on it.
Posted in General | Comments Off

reddit, inc.

Before you read this post, read the announcement that reddit.com is now its own company, reddit, inc. It’s exciting and scary to be part of reddit right now – we’ve got some great opportunities with reddit gifts, reddit, inc., and so on, but it definitely

So what’s my take on reddit, inc.? It’s opportunity. It makes reddit a little more “startup”-like – really, we’re in a state somewhere between “startup” and “established” (which will, I think, be better than “acquired”!). It’s not quite as risky as a fresh startup – reddit is an established entity, with a solid (if sometimes finicky) user base, and a revenue model that beats the pants off of “annoying overlay/flash/banner ads.” There’s plenty of room to grow, and we needed to step out from Conde Nast’s wing to take advantage of that room. Continue reading

Posted in General | Comments Off

Pagination, Scrolling, and the Never-Ending Website

Web 2.0. It means a lot of things: flashy and dynamic pages, with more content and gizmos and gadgets than you can toggle, push, swipe or click in a day. It means an evolution of the “website” as an interface to information. We’ve gone from static pages (with maybe a <blink> tag thrown in here and there) to sites that, under the hood, pull information in real time from multiple sources.

How do you deal with all that content? The approach most commonly used is pagination. Pagination means you break up your article, post, list of links, whatever, into multiple “pages.” It’s very “Web 1.0″ – very static. After reading the first page of your article, the user is forced to click through to page 2, suffering whatever load time it takes. Depending on how many terrible flash ads your site loads, you’re going to frustrate your user at a 6 or maybe an 8 on the 10 point frustration scale I just made up. On the plus side, forcing more page loads means your pageviews number in your site analytics looks better! That’s artificial, though. It looks fine on paper, but I don’t honestly think a user is more likely to click an ad on page 2 if they have to click through to page 2 vs. just scrolling down the web page more.

Option 2? The obvious one, of course – put the whole article on one page, and let the user scroll down. Key point here, though, if you’re reliant on ad revenue, you probably want to make sure you’ve got some ads that go down the whole way. Tasteful ads, of course, things that you’re users might actually be interested in.

Option 2 used to have problems if your site had “unending content” – such as your Facebook News feed. It’s not practical to pre-load ALL that data before sending the page to the user, so sites like Facebook take advantage of AJAX techniques to pull in more data as you scroll down. Most of the time, you’ll see just one page’s worth, and a site can optimize for that first page or two. If the user wants more, they scroll down, the site shows a spinny wheel thing, and pulls more content in. Rinse & repeat each time the user gets to the bottom.

One pet peeve of mine with the never-ending content – it screws with my use of the scroll bar. The scroll bar in every windowing system I’ve had experience with represents a static length. If that static length adjusts, the bar adjusts, but the paradigm starts to fall apart if the bar is adjusting constantly – as in with never-ending content. So I’ll appeal directly to all you “never-ending” site designers out there – find a way to make the page appear static in length to the user, and implement a more modern interface for going up and down within that content as part of your UI.

Posted in General | Comments Off

Apparently, my blog is really popular in Russia. Unfortunately, I don’t speak Russian, so I wasn’t able to get much discussion out of some of those comments.

In all seriousness, to reduce spam, I’ve turned off automatic approval of comments. If you stumble across my site, and post a comment that doesn’t show up right away, that’s why.

Posted on by kemitche | Comments Off

On Why Simple Fixes are Never Simple

Over at reddit, I recently announced that we’d try to make use of a new subreddit to show off to our users some of the smaller, little enhancements that we work on day-to-day. The place is r/changelog, and so far, we’ve only posted a handful of things there.

Now, my first bit of real work for the site was rather small – just a handful of lines – and there were certain commenters who seemed to be under the impression that I spent a week and a half doing it. In truth, I probably spent a full day working on the fix, and at first glance, that seems like a lot of time!

I’ve only been doing software development “in the field” (non-school) for about 3 years, but in that time I’ve come to realize something: Simple fixes are never simple. Ok, “never” might be exaggeration. Still, here’s why the above “simple” fix took so long:

  • The code was new. Prior to starting at reddit, I’d never really touched their code. (“But they’re open source!” – yes, I know, but I had other priorities). So a large percentage of the time I spent “fixing” the bug was actually spent simply learning the code structure.
  • The code is complex. Not in a bad way; a site like reddit just requires some complexity to be at the scale that it’s at. There are caching layers, backing stores, pre-rendered pages, and so forth. I don’t have a deep background in website development, but I would venture a guess that most sites don’t have the same level of complexity. Those layers mean that it’s not possible to jump into the code, tweak a line, and push it. Over the course of fixing the bug, I “solved” the problem at least 3 times only to find out that the code I changed didn’t actually have the expected effect.
  • After finally fixing the bug, I stepped back, examined what I’d done and what I’d learned, and realized that I’d made a poor fix. I then spent the same amount of time over again fixing it the right way.
  • Testing. Small changes can have big side effects; I had just set-up a local reddit clone for the first time; there was a lot of time spent making sure that while fixing the bug I didn’t introduce another – particularly given the unintended side effects I observed above.
  • On top of all of the above, there was the “process” of it all; the initial reddit clone set-up, the subsequent set-ups when I broke things, the process of using the push tool to deploy code to a live website (something I’d never done before -it was scary and also exhilarating to see an instant effect on the site!)

I don’t write this to make excuses; I probably could have done things more quickly. I know I was a little slower than I could have been, if only because my brain has been wired to have a certain level of caution after two years of working on an operating system installer. Website development is, obviously, a completely different process, with its own advantages and pitfalls (which I’m sure I’ll have more to say on later!). I’m sure that in a few short weeks I’ll be back to a speed that let’s me feel more useful.

Posted in programming, reddit, release management | Comments Off

Key Components for Release Management

Catching up on thedailywtf after some time away, and I saw a non-WTF entry on release management. Call me boring and bland, but what interests me the most about programming and software engineering is the process behind it.

I haven’t “been around the block” much as of yet in my career, but it strikes me that no matter the size of the company, they probably have LOTS of room for improvement in their release management process. Small startup? Probably hasn’t thought about “release management” at all – the product is too small, there’s more important things to do, and it’s probably (in their minds) best not to inhibit developer productivity. Tech giant? Probably thought about it a lot (likely overthinking it), but only in terms of using it as a tool to improve the quality for the end user.

So, what do I think is important for a release management process?

One-step: However the release is built (and in the case of web apps, deployed), it should ideally be a one-step process. As in, you go to the website or log in to your build/deploy server, run “# build_and_deploy” and some amount of time later, it’s done. No configuration, no billion cli flags that you need to remember every time, just run it and done. If there are configuration parameters needed, they should be stored in (private) SCM somewhere, and the defaults already set. Overriding should be possible if needed. Alternatively (for web apps), if you’ve got a good set of automated testing tools for your code and infrastructure, the code could get deployed automatically after every push to the main source code repository.

Same steps for development and for production/releases: A new developer on your team should be able to build and test his setup in the same way that the build/deploy is done “officially” (with perhaps an extra parameter, e.g., “# build_and_deploy –dev”).

Components are isolated, and can be rebuilt individually: That is to say, if a developer makes a change to the authentication subsystem, “build_and_deploy” should notice that it only needs to rebuild that part. It should then package everything together – the already built stuff with the parts that were repackaged (see the daily WTF link), and deploy to production or a test bed for the developer.

Everything is included: The build and deployment process should understand every part of your system (for both ‘dev/testing’ and ‘production’) – application components, backing data stores, caching solutions, etc.

Everything should be reversable: Upgrading the database version? There should be a way to reverse it for your environment, and your deploy process should understand it. Changing the schema? Have a way to reverse it. Updating the app servers? Should be able to backout SCM changesets. And so on.

If you’re release process is missing these, I won’t call it “broken” – but I will say I think you’ve got room to improve.

Posted in programming, release management | Tagged , , | Comments Off

Hi reddit!

As I hinted at previously, I am unbelievably excited to announce that I’ll be working at reddit starting this week! I have high hopes and big plans for making reddit a better place, and I’m determined to see them come to fruition.

When I saw the reddit blog post a few months ago asking for applicants, I decided to give the backend challenge a go just for the sake of doing something a little different than my normal day-to-day. It was a fantastic day when I finally heard back from them, and though it took some time to get to this point, I have no doubt that it was worth the wait.

What could possibly be better than spending all day browsing improving reddit? There’s something inherently exciting (thrilling, fascinating… time to buy a thesaurus) about getting back into a small team dynamic. The fluidity of the work, the freedom to pursue new ideas, the experience of wearing more than just one hat.

So redditors, what can I build for you?

Posted in reddit | Comments Off

A Rough Ride

It doesn't take superpowers to save lives

ALC 10 was a very rough event for me. Having participated in AIDS/LifeCycle twice prior, I expected this one to be a walk in the park. There were ups and downs – in elevation, of course, but also in mood and weather – this was a cold one! The combination of low temperatures, my inability to let a certain someone ride at his pace instead of mine, and a bit of over-exertion made this year perhaps the most challenging yet.

My hubris began to show within 2 days. By the end of Day 2 – 108 flat miles from Santa Cruz to King City – my right knee was beginning to feel pained. Not sore, I’ve-been-riding-a-bike-for-two-days-and-I’m-tired pain, but honest to goodness hurt.

[Selection of photos at the end of the post, after the break]

Continue reading

Posted in ALC | 2 Comments

Dusting Off and Starting Fresh

There’s something about starting fresh that I really enjoy. The chance to discard old ties, cut the cruft, and start clean and anew is simply invigorating. Perhaps that’s why I’m so excited this week – I’m breathing new life into three parts of my life.

First, this site. A blog. How cliché, yes? But it was time to dust the website off – no point in paying for a domain I’m not using, and perhaps I’ll have something worth saying now and then.

Next, and most importantly, it’s time for AIDS/LifeCycle 10. The event starts Sunday, June 5. That day also marks the 30th anniversary of the start of the epidemic – not exactly worth celebrating. What is worth celebrating are the funds the event is raising for the San Francisco AIDS Foundation and the LA Gay and Lesbian Center. Last I heard, the total is expected to surpass $12 million dollars!

Finally, it was time for a new job. I thoroughly enjoyed contributing to the Caiman/Install project as part of Sun (and then Oracle). The team I worked with was a fantastic group of people, with a lot of great ideas and a hell of a lot of energy. I learned a lot working there, as well. Before I started, I thought “Python” was just a snake, and didn’t have a clue how I felt about the “engineering” side of Software Engineering. I’ve always been keen on the software/programming side, but nothing in school prepared me for the engineering aspects of piecing together a final product – particularly one as large as an operating system!

I’ll give details on where I’m going when I get back from ALC – no point in taking that event out of its spotlight prematurely!

Posted in General | 1 Comment