We came, we saw, we concurred
Loosely Typed in Ohio

Open Source,Software GitHub Saves The Day

In the dark times (a few years ago) if Innova decided to make use of a third-party library that had bugs, we essentially had three options:

  1. App-specific workarounds: sometimes feasible, sometimes not
  2. Local modifications: wherein we dork around with the library code on our end, fix the bugs, and then maintain our own separate branch of the library. These made merging in new changes from upstream fun (in that why was I programmed to feel pain kind of way).
  3. Find/Write a replacement: You’d be shocked at how often we didn’t do this. Or, alternatively, underestimated how difficult a particular issue is.

In the last few weeks alone, GitHub’s changed that. Now, the libraries I want are on GitHub as rubygems or PHP tarballs or what have you. And when we encounter issues, the process is smooth:

  1. Fork project. GitHub has a button for this.
  2. Get our fork, make local changes, commit and push up to GitHub.
  3. Send a “pull request” to the original author to let them know we have patches that they may want. GitHub has a button for this.

My contributions are available for whoever wants them.

Now, if the original project checks in a few bugfixes I want, I can cleanly merge them in and keep my local fixes. And if upstream wants my fixes for the “canonical” repository for a project, then they’re welcome to them whenever they like. Git makes the magic happen, and GitHub makes the magic ridiculously easy.

How the hell did we develop software before this?

Open Source Innova gets with git

We’ve started using git for more of our projects, which I enjoy a lot. I do a lot of things offline, so keeping changes locally, keeping local branches, etc. is a great thing for what I do and what I like to do.

Oh, and if you’re using different versions of git (say, versions 1.5 and 1.6), the utility doesn’t puke instantly when you try to do anything with it as some others do.

Anyway, I would be remiss in my duties if I didn’t pass on this link — it hasn’t saved my bacon yet, but I’m sure it will. GitReady has the idea of using a daily tip, now categorizing the tips by beginning, intermediate, and advanced usage.

Open Source I <3 iTextSharp

I’ve just started using iTextSharp, a .NET port of the Java iText library. It’s surprisingly good.

The library can create files or streams of PDF. I’m caching my output, so this example uses files:

        // create a document
        Document document = new Document();

        // associate it with a file
        String filepath = Request.MapPath("/Pdfs/test.pdf");
        FileStream file = new FileStream(filepath, FileMode.Create);
        PdfWriter.GetInstance(document, file);

        // write the pdf
        document.Add(new Paragraph("OMG this thing works"));

Design,General,Open Source Goin’ ’bout things tha wrong way ’round?

I was trolling the internet tonight (I want a nice ajax-y image gallery for Drupal — thumbnails on one side, nice big picture on the other), and I came across this interesting article:

Project outline and UI Design for an AJAX-powered Image Gallery Module

Okay, let’s leave the fact that he’s using ‘scribd’ aside… This presents a rather novel approach to problem solving:

Step 1: Acknowledge the existence of a problem and quantify it.

Step 2: Define the UI to solve the problem.

Step 3: Hammer out the technical side of everything, keeping the problem (step 1) and the UI (step 2) in mind throughout.

Step 4: Profit!

Okay… I just threw Step 4 in for giggles.

This is a huge issue in Open Source (I love my Debian box, but I gotta admit my Mac does things more elegantly…) and for Drupal specifically. Anyone who has used Drupal for more than about a month knows that it can do pretty much anything. (Make some toast? You bet. Just install toaster.module) The problem with Drupal is finding which particular switch, in which arcane location, is going to fix whatever problem it is that you have.

And let’s face it: Being nerds usually means that we fixate on Step 3 a lot more than we fixate on Step 2.

And yes, I prefer the term ‘nerd’ to ‘geek’. Ask me why some day.

Which brings me to the second bit of light reading for the evening, courtesy of the kind folks over at Smashing Magazine:

7 Essential Guidelines For Functional Design

Yeah, a lot of it is stuff we all know already, but it still stands as a decent reminder of how to get things done, and how to evaluate if we’ve succeeded in our goals.

Oh… and I eventually had to punt on the ajax-y gallery, and went with this one. Jury’s still out. I welcome suggestions.

Design,Open Source,Productivity Writing Drupal Themes

One of the many things that I do here is create custom themes for Drupal. It’s kind of an artsy thing, and since I’m the resident designer (or so it says on my card), I tend to be a bit artsy about it. One of the things that being artsy means to me is being off-site. The Innova office is a very cool space, but I like to have a change of pace every once in a while. A change of lighting or a change of atmosphere does a world of good.

But one thing that becomes a problem is remote access. Sometimes, I really like to get off the beaten path, and away from it all. I have a laptop, but I’m not going to be able to connect to anything when I’m sitting in the middle of a park. And even if I could, I certainly don’t want the lag time in connection, especially if I’m tweaking css. “Okay… just one more pixel to the left. Right. Save. Okay… Now I’ll go make a sandwich while that goes through the VPN.”

In be beginning stages, I like to do everything remotely. Most of the time, the client has only sent a spec, maybe some rough ideas about what they want the design to look like, and maybe some color ideas and or photos. Usually, I don’t have any content at all, besides a tentative site name, and I can’t sit around waiting for content.

To develop locally, and rapidly, I use MAMP (what do you want? I’m on a Mac). You can do the same thing with a windows machine, with a stack called XAMPP. It’s a full Apache-Mysql-php stack that you can kickstart whenever you need to, and can shut it down when you don’t. In short, I love the thing. I didn’t at first, but I didn’t like Drupal at first either.

Until I get content here’s what I do:

  • I have two different setups: one for Drupal 5.x and one for Drupal 6.x.
  • I keep two seperate databases: called drupal5 and drupal6. These databases contain only the most generic of content. It’s basically all lorem ipsum but it has the content that I expect clients to want (stories, pages, blog entries, etc.)
  • Copy one of the stock themes in /themes to /sites/all/themes/projectnamehere. This keeps all of my new themes separate from the stock ones, and if this directory gets clogged (which it will after a few projects) it’s easy to offload the directory to somewhere else.
  • I’m not usually trying out modules at this phase, but if I do need to, I try to keep them sequestered out from the stock modules and keep them in /sites/all/modules. That way, I remember that there are modules that I need to upload to the production environment.

And away I go. I can take my laptop anywhere I want, and I can sit down pretty much anywhere and get things knocked out pretty quickly.

Getting out of the office is often a great way to get things done. If I can work without a network connection (as I generally do when working as outlined above), it’s a great way to shut down a lot of the distractions. I can’t check the news. I’m not going to be pinged with IMs. I’m not going to be sidetracked with new mail. It’s a lovely world out there, so go out and get to work in it.

E-mail It
Socialized through Gregarious 42