Yesterday, while looking for the proper Railsy way of doing dynamic sidebars, it became clear that breaking down and watching the railscast that specifically covered the topic was the right thing to do.  An hour and a few failed driver installs later, I had sound and was ready to go.

I shouldn’t have waited this long.

I’m naturally skeptical of video podcasts, or really podcasts of any kind, when I’m looking for the answer to a problem.  Generally I can read faster than I can listen, and I have that cranky Luddite gene that makes me skeptical of newfangled ways of doing things.  The irony of being adverse to change while working on a newfangled web development platform does not escape me.  But sometimes – maybe a lot of the time -  you’re wrong, and I was dead wrong here.

Railscasts is run by Ryan Bates.  He does great job of covering useful topics and doing it succinctly.  Most of the casts are around 5 minutes long, which strikes me as a sweet spot for answering a question in video form without being irritating.  I had about a dozen questions about Rails when I found it; questions that weren’t technical enough to look up in a reference guide.  It’s one thing to search for the syntax for removing whitespace from a string in Ruby (strip, by the way).  It’s another to find something a little higher level, problems you have a technical solution for, but probably not the right one.  Railscasts nails these topics, and nails an awful lot of them.

Kudos, Ryan, and thanks for the help.

In Rails you’ve got two ways to create a form:  form_for and form_tag.  You see examples for form_for everywhere, because that’s what you use to directly interact with the models you created in your database.  But a lot of times you need to create a form that has no interaction with your database and that isn’t mapped to any data model.  Enter form_tag.

There are two syntatic differences between forms created with form_for and those with form_tag.  First, you typically declare form_for like this:

<% form_for(@person) do |f| %>

And from then on you add fields using the f variable you just defined, like f.text_field or f.select.  The other difference is that the way you declare the fields themselves changes.  text_field becomes text_field_tag, select becomes select_tag and so on.  The reason is that text_field is meant, just like form_for, to interact with a defined object model.  All those ones ending in _tag are for unbound forms.

<% form_tag(create_ticket_path, :method=>'post', :multipart => true) do %>

In the example, you see a couple of things.  First, when defining a form_tag you can’t just pass it an object and let rails figure out what needs to happen.  You need to tell it, first, what URL to point at and, second, what HTTP call to make (typically post or put).  Those are the first two parameters. In my case, I have a path defined in my routes.rb for create_ticket, so I can call create_ticket_path to get it. And I’m creating a support ticket, so I’m going to use the ‘post’ method.

The third parameter is where you pass your options, which are roughly the same as the options you can pass form_for.  You’ll see in mine I passed it :multipart => true.  I do that to define a multipart form so that I can let people upload a file on submission.

The other thing to note is when defining the input fields.  When using form_for, you can just pass, say, text_field the symbol for the field you want it bound to. So, if you were creating a field for the subject of a support ticket request, you’d do:

<%= f.text_field :subject %>

Rails figures out the rest.  Without the model, we need to do it ourselves and define the field’s id.  (If you wanted to have a default value, you’d put it in the second parameter, but for this example it doesn’t really make sense).

<%= text_field_tag "subject" %>

Pretty simple, I know.  But sometimes you just need to see how the syntax works, and it felt like every tutorial assumed every form would either use Rails’ models and form_for, or your form_tag usage would be hilariously simple.  The full example of the form is below.  Just like when you use form_for, if you’re catching this with a rails controller, everything will be available through the params[] array.  So, to catch that text_field_tag “subject” all you have to do in your controller is grab for params[:subject] .

File uploads are their own story, but to get you started, it’ll be in params just like everything else. Just be sure to use :multipart => true or your form will quietly ignore that an attachment was chosen.

Easy, right?

<% form_tag(create_ticket_path, :method=>'post', :multipart => true) do %>
 <p>
   Subject:<br />
   <%= text_field_tag "subject" %>
 </p>
 <p>
   Priority: <br />
   <%= select_tag("priority", options_for_select([['Critical', '1'],
                 ['Important', '2'],['Standard','3']], '3')) %>
 </p>
 <p>
   Describe your problem:<br />
   <%= text_area_tag "description", "", :size=>"50x20" %>
 </p>
 <p>
   Add an attachment:<br />
   <%= file_field_tag "attachment" %>
 </p>
 <p>
   <%= submit_tag 'Submit' %>
 </p>
<% end %>

Whatever. It’s only tangential to this.  I’ll get there later.  Oh, and the title isn’t referring to my job.  That’s going pretty well.  Anyway.

My first real assignment here was to create a web portal to our support ticket system: HEAT. We’d had the system for  a year, but my two predecessors had been unable to get a web front end running for it. HEAT apparently comes with its own front end, HEAT Self Service, so why there had been so much trouble was not clear.  I started to get really worried when my co-worker told me her nickname for the system:  Hate Everything About This.

Ok. So it sucks.  But how much can a support ticket system really suck? This would be my third system I’d be throwing code at, and I’d seen some noxious stuff, but nothing that would have kept me from adding a ticket to the system through its API.  And you know what? As far as the coding went, I was mostly right.  The API worked.  I got tickets back. I could create them, too.  After understanding its slightly confusing attachment system (you send it a link to the attachment, but save the actual file yourself somewhere), there wasn’t anything all that difficult about it.

Then I loaded up the application itself and started to use it. That’s about when the hate began.

I’ve seen support ticket systems be clunky.  I’ve seen them have UIs that were confusing and even nonsensical.  I’ve seen an action that should take one click take three.  But I’ve never seen a support system so completely embody every single bad design idea possible all in one package.

Let’s say a new ticket just got into the system, into the general queue and isn’t assigned to anyone yet.  You see it and it’s one of those things where you can just rattle off an answer and close it immediately. What do you have to do if you want that ticket to show as Closed? Well.

1. Click on the Assignments tab.
2. Click New to create a new assignment.
3. Pick your group then pick yourself out of the nested drop-down lists.
4. Save the Assignment.
5. Enter information into the Assignment resolution.  Note, this is not the call resolution. You are just resolving your part in the ticket.
6. Click Resolve for the assignment.
7. Go into the main Call Info tab and enter Resolution information there.
8. Now click Resolve to resolve the call.
9. Click File->Quick Close (you can start laughing now).

If you fail to do any of this, the call will not let you close it.  Thankfully, it will at least tell you what you’re missing, but when it tells you you have more work to do closing the ticket than you did to fix the problem, you probably won’t be feeling very gracious.

The whole system is laid out that way. Getting from the list of calls to the list of customers is, at best, perplexing.  As is the as-yet-mysterious handling of its Call Groups, which make it very easy to not see a ticket and not realize that you are not seeing a ticket.

I hope that someone reading this is considering buying HEAT and that this post has just made their decision for them.  That’d make this all worth it.

PHP supports a model that’s a lot closer to the way I think, though I don’t know if it’s actually a good model.  You create your page, include other pages to fill in chunks of that page (like loading the header and footer) and, when needed, slap in some code amidst the page itself to dynamically load pieces.  If you need a person’s name to appear in the top of the page when they’ve logged in, you can just put in the function call to getUserName(); and whatever that function returns gets put into the page.  It’s a very procedural way of thinking through your page, and it’s comfortable.

ASP.Net – the default way,  not their newer Model-View-Controller pattern – does things in this weird hybrid way that’s a totally uncomfortable way of thinking.  You still create your base page – index.aspx or whatever – and into that page you can stick includes for other code and you can also call a templated header/footer file like you would in PHP.  But the implementation is oddly circular.  In an effort to avoid a separate header and footer file, ASP.Net uses Master Pages.   Unlike PHP, you don’t get to say, on the page itself, “Stick the header here, then do this other stuff, then stick the footer here.”

Instead you build a Master Page that you lay out like a normal page, except that where the content would go, you put an asp:contentplaceholder tag.  Then, at the top of the actual page, when you’re declaring the namespace for the page and where the code file lies, you say, essentially “Use this Master Page” which tells ASP.Net to take everything you wrote on the actual page and shove it into the place where the contentplaceholder tag is sitting.  It makes a sort of sense, but it forces you to think about the page layout from two different directions, and to build your actual code in a way that doesn’t map to the way the page will look when it’s done.

This isn’t helped by the fact that additional included code is done using User Controls, that feel like another type of file just to have a different type of file.  I guess it’s comfortable if you need a certain amount of forced abstraction, but it makes for pages that are really hard to pick apart.  Nor does the ASP.Net model of separating the HTML part of the page from the code itself help with the clarity.  They’ve got a fancy term for it – Code Behind – but it just means more time figuring out what’s loading and in what order.

PHP’s model certainly does not reward clarity, nor does it punish obscurity, but my experience with ASP.Net is that it enforces a certain opacity that isn’t good for development.  The model works – I’ve used it for years and gotten good work done with it – but it’s uncomfortable.

But is it wrong?  Is PHP’s procedurally minded comfort just a crutch?  And is Model-View-Controller, which I haven’t delved into yet, a help or is it just another flawed abstraction that confuses as much as it clarifies?  The whole nature of web development is coming up with ways of building templates that we can easily shove different things into as we need.  What works for you? Anything? Nothing?

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I recently finished up a huge project at work.  We moved basically every system but one in the company to a new system, and we did it in less than six months.  This meant that every single department in the company had a significant piece of their job being moved from a familiar system to some new thing that no one fully understood.  That meant someone had to talk to the departments so that we, the development team, could build out the new system properly.

That someone turned to be the development team itself.

The bulk of our work was done over a three month period, during which we had to find out what department heads wanted, find out if what we had done met what they wanted and then make sure what they wanted didn’t clash with what other department heads wanted.  This meant a lot of meetings. A. Lot. Of. Meetings.

There were weeks where I had meetings every other hour.  Those were the weeks I got nothing done.  There was no way for me to get out of a meeting, sort out what we had just talked through and prepare for the next meeting in the hour I had free.  So that also meant I got no design and no programming done either.  Those four hours of meetings might as well have been eight.  At a certain point, your day is segmented that you never get any momentum.

When I’m getting ready to write or program, I spend some time doing what looks like nothing. I skip between websites, send off a brief, no-thought e-mail or two, drop a few pointless notes on twitter.  Stuff like that.  I know when my wife looks at me flitting between websites, she thinks I’m not working and thinks she can talk to me without interrupting anything.  I can’t blame her, but what I’m doing is part of working.  I’m clearing my head, getting into a place where I can do what I have to do.  Things like phone calls from co-workers and my wife showing me funny things on her computer screw that process up.  And meetings?  They absolutely demolish it.

In the creative world this is less of a problem.  Writers work from home, so at the least they don’t have to worry about management meetings and status calls.  Programmers are forced to deal with a half dozen people who think that an hour meeting really only steals an hour out of their day.  In fact, suggesting otherwise is met by a mixture of puzzlement and outright hostility.

But hey, who wants your people to get stuff done when they can have a meeting about the things that could be working on if they weren’t actually in the meeting?

I don’t think the description of open source software on the post got to the heart of things. One of the listeners gave a fair description, but missed some areas that I thought were important. She was correct in saying that the license the software is under is what’s actually important, not just that it’s “open source,” but the way this applies to Aleynikov’s case deserves clarification.

Open source tends to mean something different depending on who you ask. The Open Source Initiative has a definition of what they would like it to mean, but in practice it gets used in all kinds of often incorrect ways. But let’s use the OSI’s definition as a starting point.

Open source licenses cover distribution and modification of software. In a general sense, an Open Source Software license says that if you let me download an application, you also need to give me the source code for it and you can’t stop me from making changes or sending the application to someone else.

It’s more complicated than it sounds. Programmers tend to take chunks of code and insert them into something else. If I downloaded an e-mail application and liked how they handled text searching, I might take that and put it into my support ticket software. Does that mean my support ticket software is now open source, too?

It depends on the license. Some say “If you take any code, your application must use the same license we did.” Others say, “You don’t have to use the same license, but you’ve got to use one that follows the OSI definition.” Some don’t care at all; you can use the code however you want. Most licenses that see wide use don’t care at all until I actually give my program to someone else.

Here’s the thing about this case: This is about an employee of a company taking code with him when he left. This gets into much hairier legal ground over ownership and what other agreements the employee signed. Even when an employee uses code covered by an open source license at work, that doesn’t necessarily give them the right to determine how it will be distributed.

Let’s say I was working for a company when I was building that support ticket system, and the code I used came from one of those licenses that said “Hey, use this however you want with no restrictions.” At that point, the employer owns the code and it’s up to them how that code can be used. It doesn’t matter that the original code was free to use. This stays true even if the code was covered by a license saying any derivative works needed to use the same license. Since the license covers redistribution, and the decision to distribute stays with the owner of the code, it’s still under the employer’s control.

(Thanks to Brennen for looking over this and making some important corrections)

This doesn’t mean I don’t praise them when it’s due.  Microsoft Office didn’t become the standard office suite by accident.  It was the best option, and has been for years.  Certainly Microsoft engaged in their typical format games to help; Word’s obscured, proprietary standard meant that every time a new version of Office came out, the alternative application you had been using couldn’t read the new Word files until someone managed to untangle their format.  So once Office became the standard, it was – as it usually is with Microsoft products – less than simple to find a reasonable alternative.

There was one problem with Office: it was expensive.  This was a throwback to the days when productivity software was a specialty field.  People literally in offices used Word Processor software like Microsoft Office. Everyone else could stick with WordPerfect or those electronic word processing machines that looked like typewriters.  Though the market for office software changed radically, pricing did not.  Or at least, the normal pricing model did not.  When I went to college, Microsoft Office started offering student and teacher pricing, but for years the only way to get it was through educational resellers that demanded to see a school ID.  This was a sloppy way to address a more serious problem: people at home wanted to use Microsoft Word and Excel, but not enough to spend $400 for the privilege.

In the past few years, some significant changes make Office’s continued corporate pricing strategy look far out of date.  First, the switch to more open document formats means that cheaper alternatives can read and write files that came from Office.  The OpenOffice project has produced some great products, like Symphony and Neo Office, that make owning the Microsoft variety a luxury.

Compounding the problem is that whole World Wide Web thing.  Google, in particular, is salivating over becoming the next tech monopoly and is just giving the whole office productivity suite away for free without even asking you to install anything.  Google Apps isn’t near the level of Office in terms of functionality, but for most people, Google Docs does everything they need from Word with the added benefit of real time document sharing and the ability to access things from any computer.

Yet Microsoft continues to charge for Office like productivity software is a specialty niche.  With totally free alternatives on the market, some of which are nearly as good as Office itself, what exactly is Microsoft’s strategy?  The barriers to leaving the Office platform are gone, meaning the only thing that would keep people using Microsoft Office is inertia.  I know Word so I’ll stick with Word.  But even inertia is subject to friction, and $200 is a lot of friction when there are free alternatives.  Yet rather than just change their pricing model and risk corporate buyers – who are likely Microsoft’s primary source of income – getting Office for cheaper, they’ve done things like selling the Student and Teacher edition of Office in stores everywhere.  So the Student and Teacher edition is essentially Cheaper Office for Everyone without anyone coming out and saying it.

I’d guess the ship is about to sail on Office’s hegemony one way or another, but if Office 2010 doesn’t do something significant with its pricing they risk losing more than a near monopoly.  They could end up being a has been, which would be too bad.  Office is one of Microsoft’s best products.

In fact, maybe it’s already too late.  Many of my friends have switched to OpenOffice already.  Even I haven’t purchased a new version of Word since 2003.  Its superior formatting features are all it has left, and I can’t justify spending over $100 for better control over my Headers and Footers.  Pretty soon, those big corporate buyers are going to lose their willingness to pay more for convenience, too.  At that point, what is Microsoft Office but another software package, scraping out some market share?

The timeline project was done on a whim, because Laura tossed out the challenge that something like this would be neat and because I can’t turn down a good challenge.  In the end, it was a great opportunity to stretch my skills.

I have to take a moment to thank my good friend Brennen Bearnes, who pointed me to the Simile timeline widget in the first place and who checked my code for craptacularity. He also made some nice, elegant CSS adjustments that took my timeline page from Minimalist Ugly to Minimalist Clean.  He’s perhaps more certifiable than me, but he’s definitely more of a web genius.

Anyway, it’s nice to have you. If you decide to stay, or if you just want to leave me a nice or nasty comment, feel free.  Thanks to Laura Conaway and Caitlin Kenney of NPR’s Planet Money for giving me the chance to do this.  It was a blast.

Structure, you are my master.

There are things you do early into a story that are very hard to unwind later.  If you write half of your book with short chapters all from the same character’s point of view before realizing one character’s POV isn’t enough, you can’t unwind that by dropping new chapters in-between the others.  At least, I can’t unwind it like that without stressing myself into tossing the book aside for a couple of weeks.

I do the same thing when I program. I spend a lot of time figuring out how I want to name things, how I want to structure my classes and methods so that it all makes sense in the larger scheme of the project.  This doesn’t put me behind schedule, and in fact it usually pays of at some point, but it can feel like a lot of spinning your wheels while it’s going on.

So while a part of me wants to just start slinging words onto the page, I’m keeping the parking break on.  Because I know that at some point in the future of every project I’ll hit a point when taking the time to make elegant changes is no longer an option.  This is the point in programming when someone dumps some unmentioned critical business process onto your desk and needs it in by go-live.  Your only option is to race madly through everything you’ve already done and patch the hell out of your work.  There’s no time to think about how it should best be structured, not anymore.  It’s fire and motion and crossed fingers.

And when that happens, when I hit some point in the story and realize the ending will only work if I add in some unthought of plot threat, I have to hope that the structure of the story is sturdy enough to support a little extra weight.  When you get into the rhythm of something – a story, an application, whatever – you kind of get an instinct for how it all fits together.  That instinct is all you have to guide you when you need to start patching your work midway through.

At times like this, all you can do is hope that you’ll fit the pieces together quickly.  There’s a price to pay for jumping the gun, and that price is a third of an unfinished novel that you hate too much to think about.  It’s hard enough finishing these things. I don’t need to give myself any more reasons than I already have.

This has happened over and over again, and I suspect the rise of the Internet has only made this problem worse.  Fifty years ago, for a novelist’s private thoughts to be published, someone needed to believe they would make them money.  Now, all it takes is a one-click install of Wordpress and anyone can sound off with the whole world watching.  Orson Scott Card can write close-minded, reactionary tracts about homosexuality; Dan Simmons can write time-travel psuedo-essays; Eric S. Raymond can say ugly, racist things.  Can I go back to their writings that I love, that changed me as an artist or as a programmer and still respect them?

I came to the decision that I had to separate out the things I loved from the people who wrote them.  The worth of Ender’s Game is not related to how much I want to talk to Orson Scott Card; it’s that when I read it, it meant something specific and important to me.   It might change how I see their future novels, now that I’m seeing the subtext of their writing differently, but what they did that mattered still matters.

That said.

I’d feel better if, as my heroes demolished themselves before me that they would leave alone their seminal works.  I listened today to the EconTalk podcast, which had Eric S. Raymond on as a guest.  EconTalk is, as you may have guessed, an economics podcast, and for this episode had Raymond discussing The Cathedral and the Bazaar. I was concerned as soon as I saw the pairing.

Russell Roberts, the George Mason University economics professor who hosts EconTalk, has shown himself to be  a smarmy, intemperate ideologue.  He spends more time bashing liberals, the government and Keynes than he does presenting actual evidence in support of his  supply-side Chicago/Austrian economic theories.  I’m still unsure how he keeps getting time on Planet Money.  And as for Raymond, it wasn’t long after I read and loved The Art of Unix Programming that Brennen directed me to his disappointing, extremist political blog posts.  I did not want to see The Cathedral and the Bazaar get dragged into the middle of our country’s complicated economic debate as proof of anything at all.

Thankfully it never devolved into the free-market = open source software praisefest I was afraid it would become, but that didn’t stop them from scooting over to the issue when they could, including the end when Roberts decided to talk about the fiscal stimulus proposal as if it has anything to do with software development at all.  It’s a perfect example of the danger of having worthy and important thoughts in one field and trying to apply them to another field about which you are more passionate than knowledgeable.  Their brief digressions into analogies between open source organizations and the way the free market organizes itself were unwelcome and unsupported.  The model for open source software relates to scientific peer review of theory, not to macroeconomic policy.

The Cathedral and the Bazaar is useful in understanding the quality of software in relation to how it was designed and developed,  not the saleability of that software, nor of the economic forces that affect the industry as a whole.  Raymond just sounded silly when suggesting that The GIMP was not developed because Photoshop was too expensive, but because the developers thought it would be fun to develop a photo application.  I’m not saying they didn’t think it would be fun, but are we supposed to ignore The GIMP’s similarities to Photoshop in this? If Photoshop cost $30, would The GIMP’s user base be as large?  Would it have been worked on to the level of polish that it has been by the development community?

There are interesting economic anaologies to draw between The Cathedral and the Bazaar and the way the market functions, but it has very little to do with Central Planning vs. unregulated free markets, or whether or not the government should spend money on things.  If the financial system was software, the privately owned credit rating agencies would be closed source software, in contrast to an open, peer reviewed system of corporate accounting practices and financial balance sheets.  Or, in examining the problems of government actions in the market, consider this: is it that the market is analogous to Linux?   Or that the lack of public transparency and democratic control over our government’s actions is depressingly similar to the closed source software we are often forced to purchase if we wish to get our jobs done?

At least this phenomenon of good writers going crazy isn’t new.  After all, once Martin Luther was through reforming Christianity, he decided he had some ill advised things to say about Jewish people. In comparison, Dan Simmons pretending a time traveler came to tell him that Muslims are evil seems almost quaint.