open source

Pretty icons using CSS and Mark James’ Silk Icons

I recently saw a post via reddit on Rediscovering the button element about making nice buttons with little icons, and was introduced to the Silk Icons available from Mark James. Mark has released these under a Creative Commons Attribution license, any my UIs will be better for it.

I went through last night and gave a little face-lift to one of my intranet projects, and it looks a lot nicer now. I added icons to buttons and links using CSS.

Here’s the css I used:
[css]
.icon
{
background-repeat:no-repeat;
padding-left:20px;
}

.delete-icon
{
background-image:url(‘icons/cross.png’);
}

.edit-icon
{
background-image:url(‘icons/pencil.png’);
}

[/css]
and so forth, with a *-icon for the different icons I wanted. Then, I decorated my buttons, links, and what-have-you by adding a class="icon foo-icon" attribute. There are other ways accomplish that with CSS, but I liked this scheme the best. In the end, I have added nothing significant to the markup, but made everything else look a lot nicer:

Silk icon example 3Silk icon example 2Silk icon example

Thanks a lot, Mark!

code snippet
design
open source

Comments (0)

Permalink

Codeplex wastes six months reinventing wheels

I saw an announcement today that CodePlex, Microsoft’s version of Sourceforge, has released a source control client. From the release:

A common theme we’ve heard from our users is the desire to be able to work offline (in the “edit-merge-commit” style) when working on their CodePlex projects. Six months ago, we started working to write such a client that would integrate with our existing TFS server infrastructure, and today we’ve released our first beta of the client.

The CodePlex Client is a command line client for Windows, and requires .NET 2.0.

This infuriates me. This cool thing they spent six months (six!) writing is called Subversion, and it had a 1.0.0 release three years ago. Subversion had its first beta in late 2003, so the Codeplex folks are waaay behind the state of the art on this one.

As a whole, I think the state of software is abysmal. The only way to make it better is to stop writing new code. New code is always full of bugs, and its an expensive path to get from blank screen to stable program. We need to treat programming more like math, we need to build on our results. Development tools is a special market, as our needs are all very similar, and when we need a tool, we have the skills to make it.

The Codeplex staff stated they needed to write their own client in order to integrate with the TFS server infrastructure. According to an msdn article (Get All Your Devs In A Row With Visual Studio 2005 Team System), TFS seems to be a complicated tool to help manage your developers. Reading the description, TFS seems to be an issue tracker, unit tester, continuous integration, source control system, and visual studio plugin. So, basically a combination of Trac, NUnit, CruiseControl.NET, Subversion, and a visual studio plugin. Why not just write the visual studio plugin, and hook into the tools people are already using? All those tools have rich plugin-architectures that would probably support any sensible addition you’d want to make.

This problem is ingrained at Microsoft, which feels the need to brand everything, but it is in no way limited to them. A search on Sourceforge for “issue tracker” gives 585 results. Sifting through those to pick a winner is difficult.

It’s more fun to write new code than read old code, but this fun wears off. After a certain initial momentum creating your new tool, you will inevitably come to a realization “this is going to take me for-fucking-ever”. Unless your itch is particularly strong, you’ll probably quit, and the world will be cursed with a 586th buggy issue tracker. By writing a plugin, you can ride the new-code high usually from start to finish, since its a much smaller task.

Reading code seems more difficult, but I think that’s largely perception. Its just another puzzle to solve. Once you get over the idea that reading code is more difficult, it’s really not that bad. For most mature projects, it’s probably easier for you to read through someone else’s mound of debugged code than it is to write and debug your own mud-ball.

I think we need find and evolve extensible tools, and stop trying to write them over again. We can get the custom behavior we all need by writing and debugging plugins, which are going to be orders of magnitude faster and cheaper than writing the whole system from scratch. I see this happening already, with communities forming around different tools to share plugins.

Next time you need a development tool, don’t open a new code file. Do us all a favor, open up a browser, and just re-use previous results.

annoying
open source

Comments (63)

Permalink

Migrate PuTTY saved sessions

PuTTY stores its session information in the registry, and there’s no function in PuTTY itself to import/export sessions. This makes moving to a new computer a little sticky. I did some googling and whittled down the documentation for storing configuration in a file into a few steps:

  1. On the old computer, open up a command prompt (not cygwin), and run:

    regedit /ea new.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

  2. Copy new.reg onto the new computer
  3. On the new computer, open up a command prompt (not cygwin), and run:
    regedit /s new.reg

Done!

open source
windows

Comments (56)

Permalink

qpsmtpd-forkserver on debian

I had some problems getting qpsmtpd-forkserver to run on debian. The punchline: qpsmtpd-forkserver relies on an environment variable called QPSMTPD_CONFIG, which should point to the directory containing your config files.

$ export QPSMTPD_CONFIG=/etc/qpsmtp
$ qpsmtpd-forkserver ...

Problem solved.

I didn’t want to run qpsmtpd for its standard usage (wrapping a mail server on the same machine), I just wanted a mail proxy that ran some code whenever any email came in, and then forward the email to a real mail server running on a different machine. qpsmtpd has a great plugin system, and was the path of least resistance. However, Debian’s qpsmtpd package is setup to wrap another mail server running on the same machine, and its init scripts configure the QPSMTPD_CONFIG variable for you. This did not help when I tried to start qpsmtpd-forkserver on the command line. I eventually figured it out by reading through the perl code for qpsmtpd, and then the init script itself.

To add insult to injury, qpsmtpd-forkserver had no way to pass the config on the command line.

I don’t know if this behavior is debian-specific, or just an oversight by the qpsmtpd maintainers.

At any rate, I was able to look through the code and figure it out, which is more than I can say for my latest .NET problem. The solution to that one was to speed my move to a new machine.

linux
open source

Comments (0)

Permalink

To Linux / Open Source Advocates

I just read another linux advocacy article off of reddit, in this case Five Reasons why Linux will eventually rule the world, and it hit a lot of my pet peeves about these kinds of articles. In a nutshell, for users, all that matters is that their work gets done, and all other arguments are wasted bits.

I have a few suggestions for open source / linux advocates:

  1. Don’t mention Microsoft
    Just don’t do it. My friend Nathan has a set of trolls, and regularly downmods anything referring to those in any setting (slashdot, reddit, what-have-you), and for you linux advocates, Microsoft should enter your troll-sphere. I’ve heard that any press is good press, and while that might not be true (ask Bush about Iraq), I do know that zero press is zero press. I also believe that branding-advertiso-brainwashing works (ask deBeers), so do everyone a favor and not mention the “competition”. At this point the fact that Microsoft exists is almost a non-issue to you. You solve all your problems without Microsoft products, so they are about as relevant to you as vitameatavegamin.
  2. Don’t mention intangibles
    For most people, the choice of operating system or office suite has nothing to do with freedom, morality, or elegance of the code. It’s a non-issue for non-techies, and a dead end for advocates. Technical folks can look all that up, and understand the advantages / disadvantages, but you don’t need to convince them. You need to convince the non-technical CEOs and managers who believe that using open source takes money from their pocket. I run into people in the course of my job who have little to no to false understanding of what “open source” really means. I’d guess half the CEOs in the country think that their codebase is their competitive advantage, and if they employ open source then competitors will steal their business. They will not be convinced by tirades about liberty.
  3. Blog your solutions
    Get a blogger account, and start blogging how you solved your problems using linux or open source. Please, don’t plan to run your own server from your apartment with your hand-rolled Erlang blog engine, cause you’ll never get to it. Just go ahead and start the blogger account with the crappy template that doesn’t use CSS classes the way you’d prefer. When people google to solve their problem, you want there to be multitudes of open source solutions clogging the results. This mostly already happens, but more content can’t hurt, and I’m curious how many dead accounts blogger will keep hosting.
  4. Appeal to the wallet
    In case you haven’t realized it, money makes the world go round. That will remain the case until the either the zombies or the aliens arrive, and then we’ll have a brief respite while exchange rates re-adjust. When people ask why they should use open source, the answer needs to be “because it saves you money”. Last week alone using Firefox with Firebug saved me probably 12 hours worth of time in debugging javascript and reverse-engineering colors and styling from a mock-up. That sort of productivity gain gives managers and CEOs a high equivalent to 3 whippets. Time and cost savings need to be a main point in any article designed to convince someone to switch.
  5. Focus on the user benefit
    Users care about how they benefit. That’s it. I feel this Gimp vs Photoshop article is a good example of open source advocacy. It’s focused on what benefits differentiate the two, and concludes:

    I know I’ve beat the horse to death, but unless you want to pirate software, there is no reason to use Photoshop if you’re not producing a print publication – use the Gimp.

    That is the essential message to send: “Unless you want to (increase cost | increase risk | break the law | behave irrationally), use the open source equivalent”.

  6. Be rational
    Lastly, and most importanly, you have to be rational. Avoid (or at least acknowledge) logical fallacies, call spades spades, and admit weaknesses where you believe them to be. Don’t speak as if you are the end-all, be-all authority. Computing is ridiculously varied, and your solution might not work for others for a wide variety of legitimate reasons. Your mileage will always vary. Don’t be whiny. I read many posts about linux, and sometimes all I can hear is Luke Skywalker whining “But I was going into Tosche Station to pick up some power converters…”. It doesn’t matter if its unfair, it doesn’t matter if its right, it doesn’t matter if its monopolist, don’t whine. Open source is going to take over the world, but not because M$ sux0rs or the mafiaa doesn’t want you to watch DVDs.

Advocates, next time you want to rant about Microsoft doing something bad for humanity, take some time and additionally post how you solve a day-to-day problem. Open source and linux will win because they will be the path of least resistance, and as advocates, it’s our job to make sure the path of least resistence is well-lit.

linux
open source

Comments (5)

Permalink