KuchtaBlog

Because I got bored and my javascript is rusty, I put together what I’m calling a Wrttn.in quine.

Edit: Does not appear to be working in Chrome (my main browser). I’d only tested it in Firefox so far because A) firebug rocks and B) I’m too lazy to care about cross-browser compatibility in my free time. I’ll take a look at the problem sometime soon when it’s not after midnight on a workday.

Wrttn.in

Wrttn.in is just a notepad-type site. It’s similar to a.longreply.com. You enter some text, hit save, and it gives you two urls: a public one that shows that text (eg, wrttn.in/323f1) and a private one that allows you to administer it (eg. wrttn.in/admin/46feb701xda). Now, as it happens, the text you enter will not be sanitized for html or javascript… :D

Quine

A quine) is a programmer toy. It’s a program that outputs a copy of it’s source code. What I’ve written is a hunk of javascript that, when placed in a wrttn.in page, will put a button on the page. Pressing that button will ajax up a new wrttn.in page, populate it with the same code as the initial page, and redirect to it. Not a traditional quine, of course, but it’s the same spirit. :)

Explanations

A few things to explain in the following code:

• It’s possible to pass in content on a wrttn.in create call, but that content will be stripped of it’s javascript. That’s why we have a subsequent edit call- edit does not strip it.
• This may not work long since we’re not using an api or anything stable- the calls were just reverse engineered from the pages. It’d be pretty easy for the wrttn.in creator to shut down this code he decides to. Just has to sanitize his edit inputs.
• Content type has to be markdown. Textile encodes the quote marks.
• This is a quick hack- nothing more. Don’t expect great code.

Code

<div id="vcms_whole">
    <div id="vcms_content"><input type="button" id="btnCreateNew" value="Create New!"/></div>
    <script type="text/javascript" src="http://code.jquery.com/jquery-1.4.2.js" charset="utf-8">
    </script>
    <script type="text/javascript" charset="utf-8">
        function createNewPage(){
            var wcms_wholeElement = document.getElementById("vcms_whole");
            var outerDiv = document.createElement("div");
            outerDiv.appendChild(wcms_wholeElement);
            wholeHTML = outerDiv.innerHTML;
            var publicId = "none";
            $.ajax({
                async: false,
                url: 'http://wrttn.in/create',
                dataType: 'html',
                type: 'POST',
                data: {content:wholeHTML,parser:'markdown'},
                success: onCreateSuccess,
                cache: false
            });
            var fullEditUrl = "http://wrttn.in"+editUrl;

            //Send edit request because 'create' filters out the javascript, but edit does not.
            $.ajax({
                url: fullEditUrl,
                dataType: 'html',
                async: false,
                type: 'POST',
                data: {content:wholeHTML},
                success: onEditSuccess,
                cache: false
            });
        }

        function onCreateSuccess(data, status, request){
            var dataEl = $(data).filter("title");
            var titleText = dataEl.text()
            adminId = titleText.replace("wrttn admin:","");
            var idLink = document.createElement("a");
            var something = $(data);
            var editEl = $("#edit",something);
            var formEl = editEl.children("form")[0];
            editUrl = formEl.attributes.getNamedItem("action").value;
            var editUrlSections = editUrl.split("/");
            publicId=editUrlSections[editUrlSections.length-2];
        }

        function onEditSuccess(data, status, request){
            window.location='http://wrttn.in/admin/'+adminId;
        }

        function setup(){
            $("#btnCreateNew").bind('click',createNewPage);
        }

        setup();
    </script>
</div>

I have a slightly more interesting application for this technique, but I’ll post about that when/if I actually get to it.

I heard a fun statistic today: the average software development turnover rate is 20% annually. The Bureau of Labor Statistics says 33% for all departures in IT, and 15% for quits. Let’s say it’s 20%- that’s a whole new company every 5 years (not really, of course, but it’s still a significant chunk of your company gone in that period). How can any company achieve consistent results when more than half their company is swapped out every 3 years? Predictable budgets and schedules become hella-difficult, not even to mention the cost of training new employees and the lost production while that’s happening.

Of course, we all know that holding on to quality developers means keeping them challenged, paying them highly, throwing them cool technology, etc. That said, we’re not all made of money, so here’s a few cheap tricks that buy a lot of developer love for not much money.

Free food

Give your employees a free dinner once every month or two. Somewhere nice and a little highly-priced, but not someplace they have to dress up. High-quality barbecue joints or steakhouses are decent choices. A lot of the common-folk consider a meal around $50 a head to be too pricy to treat themselves, so it’s pretty great when it’s gifted from management. Remember, you paid them 100 times that amount this month alone (assuming 60k a year). It’s a gift you don’t even have to do on company time, and gets a lot of bang for a tiny cost.

Dual Monitors

A number of sites and studies espouse the productivity virtues of multiple monitors- they easily make up for a $100 investment on that alone. Further, though, developers enjoy using them. Again, you’re paying them $60,000 a year- you can afford to give them a tool they love that’s been shown to increase productivity up to 44%, lasts 3+ years, and costs 0.16% of a developer’s annual pay.

Free Coffee

It may seem like a small thing, but one nicety I’ve heard programmers and IT workers complain about endlessly is the lack of free coffee. It’s a little weird, considering how cheap home coffee-makers are (got mine for $12 at a thrift store), and how cheap making one’s self a cup is. That said, developers seem to love having it on hand in the office, and I can hardly fault them- they get up early, come in, and sit without much movement for the next 4 hours. Anyway, you can get a high-end office-oriented single-cup maker for $500, or $17 a head in a 30-person office. Hell, even a cheap home-oriented brewer (<$50) kept well supplied will do the job (though the wasted time for high-paid developers to set up and brew pots may not be worth the savings).

Decent Chairs

A rower notices the rowboat. A pilot notices his cockpit. When I tour a potential job, I notice the chair I’m going to spend 40 hours a week in. Yes, good chairs are stupidly expensive ($750 for the famous Aeron chair), but quality chairs stand out. There’s talk about improved back health, productivity, etc, but the biggest advantage is their attractiveness to new and old developers. They signal that the people in management care about the day-to-day physical needs of developers (even though we all know you just want more work out of us). At a dollar a week (assuming a 10 year lifespan), that Aeron chair is a solid investment- cheaper than (as Joel Spolsky points out) your average toilet paper expenditure.

There, that wasn’t so bad, was it? I didn’t suggest that everyone get private offices, litter the place with beanbags, or have catered sushi every day. These are simple things, and you can do them without really high-level approval. They’ll reduce turnover, increase productivity, and attract brighter minds- in short, they’ll pay for themselves.

I recently undertook participation in RIT48 with my good friends Chris ‘Cap’ Tosswill (a fellow software engineer) and Meghan Manders (a designer). RIT48 is a competition to create a web business in 48 hours, with mixed emphasis on business plan and implementation. Our team got a working prototype of our product (FulStack.com) up and running, and we won second place (+ $400)! More details in the project page.

Much like throwing a kitten into a pit of rottweilers, there are a few questions you can throw into any group of developers that’ll have them at each other’s throats in moments. One fun one I discovered recently was:

“When do you comment?”

Most opinions I’ve seen have fallen into one of a few categories:

1. Real men don’t need comments
2. The code should be self-documenting
3. Comment on design decisions (the ‘whys’ of code blocks)
4. Comment on the what blocks of code are doing (the ‘whats’ of code blocks)
5. COMMENT EVERYTHING!!!!1!!1ONE11!1!!

Few reasonable people hold position 5, and the people holding position 1 aren’t likely to turn away from their RPC-4000 to care what some wet-behind-the-ears, object-oriented, virtualizing, abstracting, greenhorn youngin’ like me has to say.

Self Documenting Code

The general argument is that clear method/parameter/variable/etc names, clean well-formatted code, and well structured source are sufficient for the sort of low-level documentation you see.

The Pros are pretty clear- less commenting means less stuff to keep up to date and in sync with the code.

Commenting just makes the source file twice as long.

However, no one is perfect. Your code is never ultimately well structured, named, and formatted. If you think it is and I have to deal with your code later, I want to track you down and light your face on fire. Unless you’re the perfect lovechild of Steve McConnell and Erich Gamma, then your naming, structure, and formatting will be incomplete, and I will hate you. You’re better off assuming you suck and commenting as such.

Comment on design decisions

The idea here is that you’d comment on how a method or block of code fits in with the rest of system. Obviously you don’t want a complete design document in the comments for every method, but you might want to point out specific gotcha’s and the code’s general role in the system.

The Pro’s to this are that it helps someone going through the code understand the possible ramifications of changes, especially if they’re non-obvious.

The problem with this approach is that it’s hard to keep up to date. That’s true of any documentation, but comments are supposed to be the closest thing to the code itself. Comments that reflect not just changes to the code at hand but also the rest of the system are difficult to keep current. If code in modules A, B, and C all discuss what module D does (in relation to how they interact with it), then they all have to be updated when module D is changed or repurposed.

Comment on function

Pretty simple - comment on what a block of code or method does. You see this formalized in Javadocs.

The main argument against this tact is that it should be unnecessary. Programmers can read code, why do we need text to tell us what code does?

I would argue that we don’t want to take the time to read your code and figure out what it does. If I’m skimming through a dozen foreign thousand-line class files, I don’t want to have to read every line in them just to find the one block that modifies X; it’d be nice to be able to skim through comments to find “//This section deals with X.”

In another case, your code may just be too dense to be read quickly. I can figure out what your line-noise regex does, but unless you deal with it constantly it’ll take a minute- it’d save me some time if you took 20 seconds to give dense code a brief description. The same can go for any unusually clever or cryptic piece of code: yes I can read it, but I’m looking at this source to find information, not marvel at how clever you thought you could be.

Whaddaya say?

So which style’s best? It really depends on how you and your development team work. Some things to consider:

• How good is your external documentation?
• How big is your codebase?
• Is your architecture clear enough that the consequences of most changes are obvious?

Personally, I try to err on the side of more commenting- while I’ve seen some egregious examples of over-commenting, those are few and far between. Under-commenting, though, I’d bet we’ve almost all been burnt by.

Hell is shiny objects

I don't know about you, but I often suffer from a lack of motivation on personal projects. Usually it goes something like this:

1. Be sitting at my computer and thing "Hey, I've got a half hour; I could try to fix that bug in the FPA event model."
2. Launch Textmate, open the relevant directory in it, and wait for that to load.
3. Launch MAMP and wait for it to spool up it's isolated MySQL and Apache servers
4. Start up the Fixx issue tracker server and wait for that to load.
5. Go to the production and staging sites for reference, and wait for those to load
6. Go to the site on localhost, as well as the bug tracker page, and wait for those to load.
7. Open Cyberduck (my sftp client of choice) and wait for it to load + make it's connection
8. Load up the terminal and navigate to the right directory
9. Switch back to Textmate and get to work.

Of course there's usually some point in there where, while waiting for something to load, I get distracted. Stumbleupon is just a keystroke or two away. Cmd-T, Ctrl-Shift-S and I'm reading about baby elephants in Asia. 30 minutes later, I'm out of time, and no work got done.

While this isn't a huge problem when I'm being payed to work or any project that I'm working on for large contiguous blocks of time, it used to come up all time with personal projects. Further, even without the distraction factor, the amount of effort required to get down to work can be off-putting. Once I'm working, I'm focused like a racehorse (assuming racehorses are really focused- I really have no idea). Getting to that point can be an issue, though.

Make the robot do it

We automate every other aspect of our projects, why not this? Continuous integration severs, build scripts, unit tests- we script our way past any monotonous task, so how 'bout setup?

I have one button on my dock to load up all the tools I need to code, run, test, and deploy my work for SPDB, and slightly less involved but increasingly automated processes for my other tool-intensive projects. These tend to be some amalgomation of Automator, AppleScript, and Bash. They're not especially elegant, but they're not ment to be- spending too much time developing tools to organize tools to do actual work starts bogging down your ability to actually do work.

Time is an illusion

Like most labor-saving labor, this seemed like more work than it was worth right up until I started using it. That seems to be a common theme on automation- ever heard any of these?

• "Automated Unit testing takes too much time to write- time we could use to develop"
• "Version Control is too much effort to be worth the small amount of time it save."
• "We don't need to script our deployment process- we don't do it /that/ often."

But once these tasks are completed, you immediately start to see the benefit. Saving even 30 to 60 seconds every time I launch my dev environment setup script builds up pretty fast.

Housing Prices

Automating a task is like buying a house. Before that, you're just renting. Every month you pay your rent, and have nothing to show for it other than living in your flat for that month. Every time you do a task by hand, you pay the time it takes and have nothing to show for it other than completing it once.

When you buy a house, you start building equity. Yes, you had an up-front cost, but now every house payment is building up benefit to you, instead of just being thrown away. Likewise, a scripted task takes time to set up up front, but thereafter saves you time every time you do that task at a fraction of the effort.

Further, what's more fun- launching, spooling, loading and opening? Or just coding?

Whenever and whereever it's practical: automate it. It's usually worth the time.

A New Hope

Since the dawn of time, man has yearned for full control of fonts on his website. For many years, though, we’ve been stuck using just the fonts that we can reliably expect every user to have installed on their machines.

However, hope has come at last; no longer must we toil in typographic mediocrity. As of summer-ish of 2009, most major browsers (Safari, Firefox, IE) support it (in anticipation of the CSS 3.0 spec). We are now free from the shackles of conformist font faces!

Given all this, I decided to have a go of playing with embedded fonts on www.kevinkuchta.com. It’s easy, what could go wrong?

Fail and You

Of course, it’s not that simple (it never is). IE’s been doing font embedding since it was put in the CSS 2.0 specification (then subsequently removed in CSS 2.1). As such, they do it entirely different from everyone else (and, for that matter, the spec).

There are plenty of other references on font embedding , but I thought I’d focus specifically on the weird things IE does, since that’s what’s been giving me some fun headaches. Hopefully this will save some people some trouble in the future.

Things IE Doesn’t do

Multiple Font Sources

In an ideal world, your font list could look something like this:

src: url("/fonts/HelNuBold.ttf"), url("/fonts/HelNuBold.eot")

If any given source failed for whatever reason, it’d fail over to the next on on the list, and this is exactly what Firefox et. al will do. IE, on the other hand, will fail entirely if it sees multiple source declarations on one line like that. It tries to load the font entitled: "/fonts/HelNuBold.ttf"), url("/fonts/HelNuBold.eot"

Local Font Sources

Ideally, you could declare a font-face that would look first to a local source:

src: local("Helvetica Neue Italic")

This would be especially useful in conjunction with multiple font sources. IE doesn’t like the “local” syntax, though, and will ignore a line with local in it. This is actually useful if you want to set up a source list that IE will ignore, but Firefox et al. will read.

Font Weights

Some fonts have different actual font files for bold text- it’d be nice if we could set up a set of fonts to automatically switch to the correct font whenever a section of text in a certain embedded font was bolded. It’d work something like this:

@font-face{
    font-family: "somefont";
    src: "url("/fonts/HelveticaNeueBold.ttf")"
    font-weight: 700;
}
@font-face{
    font-family: "somefont";
    src: "url("/fonts/HelveticaNeueRegular.ttf")"
    font-weight: 400;
}

This is even more useful when dealing with a font (like Helvetica Neue) that has half a dozen different font-weights, from UltraLight to Black. Of course, true to form, IE fails and Firefox/Safari work fine. What’s interesting about this one, though, is that it fails non-deterministically. It will decide to render bold/regular fonts with random fonts, weights, and variously condensed/expanded.

It makes for a cool party trick to switch fonts randomly on different reloads from static css/html. If you have access to IE, you can check out a live demo, in which I’ve assigned several very different fonts to the same font-family but different font-weights; try reloading a few times. If you don’t have IE, you can see the effect using the excellent IE testing tool Netrender and reloading a few times.

Font Styles

Very similar to how you’d use font-weights- italicized text would automatically use the italicized font, rather than just being slanted by some browser algorithm. It’d look like:

@font-face{
    font-family: "somefont";
    src: "url("/fonts/HelveticaNeueRegular.ttf")"
    font-style: normal;
}
@font-face{
    font-family: "somefont";
    src: "url("/fonts/HelveticaNeueItalic.ttf")"
    font-style: italic;
}

But, of course, IE reacts non-deterministically to this. Firefox/Safari work fine.

TTFs

Everyone’s gotta have their own font format, of course. Firefox/Safari take, among others, .ttf (TrueType Font) files, whereas IE takes .eot “Embedded Open Type” files. The technical differences between these two are a topic for another post, but for the purposes of embedding, they can be treated the same. For those starting out with ttf’s or otf’s, I cannot recommend highly enough the font generator by Font Squirrel. It’ll output the necessary eot’s as well as the correct CSS to work in both IE and Firefox.

Writing a blog engine is a right of passage for young developers.  It is the web equivalent of printing Fibonacci numbers or calculating the sides of a triangle- step number two after Hello World.  As such, the question is raised:

Why don't I roll my own?

The first answer to that is that there's not much more to be gained from it.  It was useful when I was first learning HTML, then CSS, then PHP, the Rails, as a project with some practical application that also has enough technical requirements to flex the tool being learnt a little.

Further, it scaled well to various tools (when learning HTML, I could do a simple static-page blog; when learning rails, I could do a dynamic mvc blog engine with tests and a db).  Now, though, I know enough about the principle web tools (HTML/CSS) and a smattering of languages + frameworks (CodeIgniter, Rails, etc) that building another blog engine in them just isn't that useful to me.

Secondly, the need for this project to be done outweighs my need to learn from it.  I've gone through half a dozen iterations of my personal site- each time better and more complex.  The problem is that when using a project as a learning tool, it never gets done.

By the time I finished building one of the first versions of my site with table based layouts, I'd figured out that css layouts were much better.  By the time I finished a static css-layout site, I realized that even a little php could make modifications much easier, etc, etc.  I always want to rewrite it in light of the flaws I learnt while writing it.  At this point, I need a solid web presence that isn't constantly changing.

Thirdly, I want the sort of features that a mature product gives.  I can roll a basic blog engine with post and paginated archives in 20 minutes in Rails (less using generators), but then what?  Then I want comments on that, so I write comments in another 20.  Then I realize that I want formatting for my comments and blog posts, so I spend some time putting in markdown.  Then I get a spammer in the comments, so I put in captchas.  Then I decide that I upload enough images that I'd like a way to do that through the ui, rather than ftp-ing to the server.  Then I need... and so on.

Role-based authentication, searching, skins, analytics, performance optimiziation, OpenId, RSS/Atom, etc.  These are all things I can or can learn to do, but it often means I have to choose between living without the feature or putting all my other pojects (and the writing itself) on hold to do it.  Having a well thought out platform like MovableType, with the features I'm likely to need already there, allows me to focus on other things.

So, why not roll my own? Because it's no longer educational, I need this site for itself, and I want a full-featured system.  Good enough reasons for me.

"A man's domain is his castle"

I've been kicking around the internet since I was a kid, and I've owned various websites about as long.  From the HTML course I took over the summer in elementary school to the rails system I put together a couple years back, I've always had some online representation, often tied to various user names and interests.  I've made Starcraft fan pages, webcomics, rough cms's, collections of written work- everything but the standard blog.

What I've lacked until now, though, has been a place directly associated with Kevin Michael Kuchta.  The closest thing to that is my facebook page, which isn't the front I want to show the world.  To this end, I'm getting my hair combed, buying a respectable domain name, and putting a decent blog there.  That's this thing.

I'll get into the decisions I've made concerning this site, the history of my online presence, my current place in life, etc in future posts- this is just to say why this site exists: to be a stable repository for all things Kevin Kuchta.