iruel.net 2010-02-15T20:39:24-06:00 http://iruel.net/ <![CDATA[Jekyll setup and modifications]]> 2010-02-14T00:00:00-06:00 iruel.net:/2010/02/14/Jekyll-setup-and-modifications Now that we’ve established that this blog is now running on Jekyll, let’s get down to the business of looking at the setup of Jekyll, and the customizations that I’ve made.

For starters I took an existing published setup, and used it as my base instead of a vanilla Jekyll install. The particular setup I used was iruel.net, by Bruno Antunes. You can check out his repo for the list of changes over vanilla Jekyll, but they’re fairly basic. The majority of his enhancements revolve around Rakefile tasks to fit his deployment system. I wanted a different setup, so I ended up removing most of it.

The next step was to remove the files and posts that were already there (ignore the adds for now). After that, it’s time to get to work. I didn’t want to just start from scratch, I wanted to import my existing blog posts first. So I went into the Jekyll repo to look at the converter options. Jekyll currently supports importing from CSV, Mephisto, MT, Textpattern, Typo and WordPress. That’s quite a few options, and certainly should cover a ton of folks, but not me. As previously mentioned though I need to be able to import from Google Blogger, which means I need to get busy. Blogger luckily provides an XML based export file of an entire blog. I just needed to import posts, I ignored all of the stored settings and comments. I spent a couple of hours reading through the export file, and hacking up some really simple code to handle the import.

Currently the code supports importing all blog posts, their published date, permalink (which is stripped to just the path), and the posts tags. All of this is able to be imported cleanly into Jekyll, which is awesome. Next I decided to make a few tweaks to my workflow.

I’m a slow writer. Really slow. I’ve rewritten this post at least twice by the time you read it. If you look into my repo, you’ll probably see that it’s been in a draft status for longer than I’d care to know. Because of that I need to be able to easily manage draft posts. I decided that the easiest way to handle this would be through a few simple Rake tasks. I went on and modified the existing Rakefile, to add two tasks (drafts and publish), and modify the ‘post’ task. First I modified the ‘post’ task to create the post with ‘published’ set to ‘false’ which prevents Jekyll from generating an HTML file for that particular textile file. Next the ‘publish’ task goes in, removes this flag, and changes the file name to be the current date. This way the post’s date is current. The ‘drafts’ task is really simple, it just lists all the posts that are still un-published.

The last, but to me most important, part of my customization is my deployment process. To deploy my blog, I simply have to push into my github repository, nothing more. In github I setup a post-receive hook, that calls a script on my site, that has permission to run a ruby deployment script serverside. That script uses my deployment script dsl, to move the current site to a backup folder (just in case), create a new directory, clone the github repository, and then run jekyll. This seems complicated but with the deployscript dsl, it’s only a few lines of code.

This means in one evening I was able to setup Jekyll, customize it, write an importer for my previous blog, and import it, and deploy it all to my server. Not bad, not bad at all.

]]> Tanner Burson http://twitter.com/tannerburson <![CDATA[Now, with more Jekyll]]> 2010-02-10T00:00:00-06:00 iruel.net:/2010/02/10/Now,-with-more-Jekyll Apparently Google is abandoning FTP support for Blogger blogs this next month. As I’m sure none of you were aware, this blog was hosted via that service. Instead of waiting until the service went away and then cursing loudly, and flailing my way into a new blog platform, I got proactive, and made the move over a month ahead of time.

Being a geek of epic proportions, I couldn’t just use Wordpress or something similar. No, I needed to find something esoteric, complex, hackerish. And I found exactly what I was looking for in Jekyll. It’s a Ruby based static blog engine with a strong preference for being under version control. This means that the same tools I use to code, are the same ones I use to blog. Kick. Ass.

Coming up next will be a post detailing how I’ve got this setup (hint, checkout my github projects)!

]]> Tanner Burson http://twitter.com/tannerburson <![CDATA[Android scripting for fun and profit]]> 2009-06-26T00:00:00-05:00 iruel.net:/2009/06/Android scripting for fun and profit
I decided to organize and prune my book collection the other day, and remembered reading a brief tutorial on scanning barcodes using Python and the ASE. I thought this would be a great chance to learn a bit about ASE and Android in general. Here's the basic steps I took, hopefully they'll be of some use to someone.

Despite the instructions which recommend starting with the ASE install, I found it easier to download the python interpreter to the phone first. http://code.google.com/p/android-scripting/wiki/InstallingInterpreters

Then install the most recent version of ASE to your phone (either using the QRCode at http://code.google.com/p/android-scripting/ or downloading the APK straight to your phone).

The ASE site has a fair bit of sample code, so I took the barcode sample and made a few adjustments that will let me track my book collection easier.

The script is admittedly pretty simple: read the barcode, check to make sure we got an actual result, then send it on to the webserver. Make sure to fill in the proper server name before you use the code. For my purposes I was going to be scanning a bunch of books all at once, so I put it in an infinite loop so I didn't have to relaunch it for every book. To exit the loop simply hit the "back" button on your phone.

Now that we can scan the barcodes locally, we need to do something with them on the server side.

Above is a simple PHP script that will write the ISBNs to a text file. The most important part is parseUPC method, which converts a UPC barcode to an ISBN. If the barcode isn't formatted as an ISBN it's left in it's original format.

And that's basically it. Drop the PHP code on your web server, make sure the path and server name match in the python script, and you're off and scanning!

Add in some queries to Amazon ECS or Google Books, and you're halfway to your own personal version of LibraryThing. ]]> <![CDATA[Migrating from Sinatra::Test to Rack::Test]]> 2009-05-18T00:00:00-05:00 iruel.net:/2009/05/Migrating from Sinatra::Test to Rack::Test release of Sinatra 0.9.2 mention (again) that Sinatra::Test would vanish by 1.0, I decided to get with it and move to Rack::Test. It was really pretty painless and my tests were forced to become a bit more explicit (still not convinced I really LIKE this). Since I found a few bits of fun along the way I thought I'd share.

I use Test::Spec so some of this may not apply, or may look a bit 'off' to you, but I think the point should be clear.


Anywhere you're using @response/response, or @request/request you need to change to last_response or last_request.

Anywhere you were checking a redirect URL, you now need to check for a full hostname not a relative path. The default hostname for requests is http://example.org.

Also be aware that that Rack::Test tracks cookies. I haven't looked heavily into what that will mean in practice, but if you were manually twiddling the cookies around, you need to look into the CookieJar and how it may affect what you're doing.

That's all that I ran into when moving my tests over. What did you find? ]]> <![CDATA[Pushing an entire Sinatra app into a Rackup file]]> 2009-05-13T00:00:00-05:00 iruel.net:/2009/05/Pushing an entire Sinatra app into a Rackup file this post by the guys at devver. They came up with a simple way to put both a sinatra application AND it's tests into a single file. Nothing TOO crazy, but definitely cool.

Not satisfied with simple and effective, I went to complete overkill. I put together a way to not only embed a sinatra app and it's tests into a single file, but for that file to be a rackup compliant file. Also, as a pointless but neat bonus, I forced the tests to run before successfully before the app can start. What's the point? I don't really know, but it seemed cool so I thought I'd share. And no, I'm not using this anywhere, I don't think.
]]> <![CDATA[Extracting subdomains in Sinatra]]> 2009-01-31T00:00:00-06:00 iruel.net:/2009/01/Extracting subdomains in Sinatra continuing education in Sinatra, I decided to learn how Sinatra handles subdomains. It turns out that neither Rack, nor Sinatra seem to have any native subdomain handling code. So I took a quick stab at it.



The easiest method I could come up with was simply to re-open the Rack::Request class and add a subdomain method. The method implementation is adapted from Rails, except with Rack style caching.

To test this you will need modify your hosts file with something like:

127.0.0.1    sample.test.dev


Then after running the above script, use the url http://sample.test.dev:4567. You should see just the word "sample" as the output.

I'm not sure that this is the best method, but seems to work for now. ]]> <![CDATA[Multiple Sinatra .90 applications in one process]]> 2009-01-20T00:00:00-06:00 iruel.net:/2009/01/Multiple Sinatra .90 applications in one process
One of the things that drew me to Sinatra was the absolute simplicity in it's approach to web apps. One of the keys to this simplicity is leaning heavily on Rack. Rack provides a variety of what they call Middleware, small bits of code that insert themselves into the request/response process, handling things like caching, session management, or even JSON parsing.

Now that we're through with the background, let's hit my find of the day.

As I started working I found that I felt more comfortable with my application being defined inside of a class instead of just floating around in files (the default method of building a Sinatra app). It turns out this is one of the lesser documented parts of the new Sinatra .9 release. (In all fairness this seems to be due to the fact that a lot of the infrastructure that allows this to happen is either brand new, or heavily refactored in this release)

It turns out I could do a whole lot more, such as making each portion of my application it's own standalone Sinatra application, then using some Rack Middleware to mount each portion into it's own URL space. Why would I want to do this? I think it will make for a very extensible, and potentially scalable infrastructure. All of that aside, let's see HOW you do this!

For starters you need to define a class for your application to live in.



There's a simple set of classes that function as little application stubs. Notice that we require sinatra/base instead of just sinatra. This is one of the new things in the .9 release. By requiring just sinatra/base we get all of the sinatra goodness, without any of the intrusive top-level methods. Since we're going to encapsulate our application in our own classes, this is perfect for us! For these little applications to fully work we'll have to define some views, which I'll leave up to you (or you can check the full project files at GitHub at the end of this post).

Now here is where we define our Rack magic. We'll create a config.ru file, which uses what's called RackUp syntax to specify some options for Rack compliant servers to use to configure and start our application. For this example I'm using Thin, but you can use whatever you prefer!



Up until line 15 it's pretty standard boilerplate for getting any Sinatra application going, but after that is where things get interesting. Rack automatically includes the URLMap Middleware which gives us access to the 'map' method. This method takes two parameters, a URL prefix, and a block specifying that applications configuration. We could do any configuration we can do at the top level inside of that block, giving some pretty powerful per-application configuration.

And that's it! Start it with thin -p 4567 -R config.ru start, or the equivalent. You should be able to navigate to / and see your first index, and /blog and /blog/list respectively to see their content. Notice how our Blog class never uses the /blog URL prefix anywhere. This would let us pass the exact same class into a different application, at a different URL space, and the application wouldn't be any wiser for it.

Want to see the whole thing already setup? Check out the GitHub link below for the full sample application.
http://github.com/tannerburson/multi-sinatra-sample/tree/master ]]> <![CDATA[on wearing mental blinders]]> 2008-11-24T00:00:00-06:00 iruel.net:/2008/11/on wearing mental blinders
My first thought was that this was indeed a problem that would only grow in significance thanks to everyone being told to live in "the cloud". Upon further thought, this is one of the most pointless things anyone has ever wasted time on, and I should know, I've wasted a lot of time on pointless things. Sidebar: What level of irony does this post reach?

One of the key reasons this is incredibly pointless is that the problem has been faced, in varying forms, for hundreds of years. Just because the data is now in a computer, doesn't change the nature of the problem. To prove this, let's break down the process of what is actually being considered.
  1. There is data that is important to you, that you don't want others to read, so it is protected by some form of password
  2. You don't want to write down your important account information as it changes because that is too cumbersome
  3. You are now dead
  4. You now wish your private data to be shared with your loved ones (or something)
Replace data with "sharp rock good at killing things", and "password" with "which bush near the cave I hid it under" and you've got roughly the same issue.

I understand the problem that many people face today of thinking that somehow using the internet in the solution to a problem makes the solution inherently better, but in this case it's going way too far. The real problem here isn't a technical one, or a social one, it's simple human laziness. People are considering working on very complicated public key signing mechanisms, or notification/verification systems, or something else equally as complicated to solve the problem of people being too lazy to write down a couple of lines of data every few months. (A note to lazy readers like myself, the laziness in the process is in bold)

After great thought, I have come to what I believe to be the ultimate solution to this problem.

  • Write down important account information (usernames, account numbers, etc).
  • Write down a list of possible passwords, because we all know no one is changing their password to something totally unique for every service they use every 60 days.
  • Write down your most common challenge question/responses.
  • Place the above information in a safe, either at your house, or at a bank.
  • Leave a key somewhere safe, inform your loved ones that should you finally get hit by that bus that everyone always talks about, the safe has usernames and passwords they may find helpful.
You may now sleep easier knowing that your loved ones can access all of your excellent daily stock tip emails, and unsolicited offers for medication long after your untimely demise.

Now that I'm done ranting, what did I learn from this little thought exercise? The people discussing this topic aren't stupid, hell I'm sure they're smarter and more accomplished than I am. So why are they wasting time trying to fix a problem that can't really be fixed? They're either participating in a mental exercise of their own, or they put on their Mental Blinders.

Mental Blinders is what I call the "thing" that happens when we constrain ourselves to a particularly narrow solution set, often in the process ignoring simpler or more effective solutions.

The next time I find myself slogging through an increasingly complicated solution to a problem, I need to remind myself to stand back and see if I've put on my blinders. ]]> <![CDATA[on dead projects and spam]]> 2008-11-12T00:00:00-06:00 iruel.net:/feeds/5964520279678788379/posts/default/on dead projects and spam
Then one day the project leader vanished! People were concerned, but kept on working, as they really loved the project. Things continued in this way for several weeks. But then a change happened, the leader stepped down, and named his replacement, and all was well again.

Tragedy strikes! After many months of calm and quiet the projects dedicated server crashed, the admins had no backups, and without a gathering place, the community vanished in ]]> <![CDATA[it's all about the data, stupid.]]> 2008-10-16T00:00:00-05:00 iruel.net:/2008/10/it's all about the data, stupid. On an average day I'll touch three different operating systems, and a pile of applications on each one, and I've come to an important realization for me as a programmer: operating systems, and most applications, suck. Tying your business to any one of them undermines your business from the start (but is often a necessary evil). Most applications don't respect your data, and actively work to make your life more difficult.

My day job involves working closely with our art department, who all use Macs, and their work products (primarily images). Because of this, it's convenient for me to also work on a Mac, to simplify the sharing of data as much as possible. This works out really nicely, until I need to edit a document that a manager created in MS Office 2007. I've got Office on my machine, but it won't edit that file, or it's missing some chart, or annotation, or what have you. The fact that it was created in Office is unimportant, what's important is the data in the file not the file itself. The file format is actively preventing me from getting to the data.

Applications may be irrelevant, but what isn't irrelevant is user data. The important choices when developing, or evaluating a new system aren't whether to use OSX or Windows or Linux. What's important is deciding what needs to be done, what the constraints are (cost, time, etc) and what to do with the data. Does the data need to be secured from all prying eyes? Displayed prominently on a website? Printed to paper and stored in a humidity controlled vault in an abandoned salt mine at an undisclosed location? All of the above depending on the phase of the moon?

The applications that I enjoy working with the most are the ones that understand that the way I need to see my data today may not be what I need tomorrow. When you design an application, be it on the web, or the desktop, think about the ways in which you show and share data with your users. Is it easy for them to change the format? Is it easy for them to get at the data in as raw a form as is applicable? If your answer to either of the above is 'no', then you're not respecting your users.

I don't want to have to use MS Office to read my data I've exported from your site. I don't want to be stuck with only a PDF. I want the option to get raw, unformatted text, or a formatted TeX doc (yes, yes, wishful thinking). I want the option to get a simple CSV file, or RSS/Atom feed. I want control of my data. I want the comfort of knowing I can get my data out of your system, for my own uses, with as few restrictions as possible. Because I don't expect you to know every possible way that I may want to use my data. But I don't want you restricting me from certain options based on limited export options.

So, what's the point? (Other than that I'm apparently trying to become the next Steve Yegge, yeeshk this is getting long winded) The point is that it doesn't matter what OS you use, it probably sucks. The applications you use are less important than the data you're creating in them. What's really important is having the data that's needed, in the format it's needed in, when it's needed and if you're preventing your users from doing this, you're ripe for replacement.
]]> <![CDATA[on shameless self-promotion in a time of social networks]]> 2008-10-12T00:00:00-05:00 iruel.net:/2008/10/on shameless self-promotion in a time of social networks
Today I joined twitter, the poster-child for time wasting, self-indulgent, Web 2.0 buzzword compliance. What could possibly make such an adamant hater of social networking pull such a 180 overnight? It's really simple, shameless self-promotion.

I spent several days last week at a conference, Tulsa Tech Fest, meeting many very interesting people. I found quickly that social networks, particularly twitter, were the dominant means of communication and organization amongst the conference attendees that I was most interested in keeping up with. I heard many tales of meetups, and user groups, all of which are held in places that aren't here.

If I want an opportunity to get out of here, and do the sort of work I'd like to do, for the sort of company I'd like to be doing it for, I've got to be something more than another obscure, unknown developer. Given that I'm not currently able to live in a more developer friendly area, the best option for moving forward in my goals, is shameless self-promotion. Now, back to how this all relates to twitter.

I'm excepting my self-imposed ban on social networking, for purely self-serving reasons. I need a way to better communicate with others who are working towards the same ends that I am. Several years ago, the most prevalent tool for this sort of communication was IRC. But my brief and informal survey seems to show that a lot of conversation has moved to the vast unorganized land of twitter.

So here I am, forsaking my self imposed title as an internet luddite in exchange for the chance for some shameless self-promotion. Sometimes, I guess, we all make sacrifices in exchange for making progress towards our goals. With that in mind, I humbly apologize for my hypocrisy, and by all means follow me on twitter. (sigh) ]]> <![CDATA[on blinking lights and wasting time]]> 2008-09-15T00:00:00-05:00 iruel.net:/2008/08/on blinking lights and wasting time

or how I learned to quit being interrupted and regain my productivity

Hello, my name is Tanner, and I'm addicted to blinking lights.  The addiction costs me hours of my life every week, and it's time to quit.  From the minute I wake up to my screeching blinking alarm clock, until I turn off the TV, put down the phone, and go to sleep I'm blasted by little blinking lights. In every part of our life we're conditioned to pay attention to bright blinking lights, microwaves, fire alarms, emergency vehicles, phones, alarm clocks, status lights on every gadget under the sun, so why should our offices be any different.    But how do you even start trying to break a lifetime of psychological conditioning?  I set out on a quest, a quest to regain my productivity at the office from the blinking lights.  For one week I did everything I could to disable all of the blinking lights I'd found controlling my time, and in the process figured out how to regain control of my own time.

I work in your average office, working average hours (8am-5pm, 5 days a week).  I'm surrounded all day by a half dozen blinking lights.  Thanks to email, office phone, personal email, iCal, and my wonderful BlackBerry, rss readers, etc, my day consists of bouncing my attention from one blinking light to another.  To top it off I get all of my work (and personal) email forwarded to my phone, so I get hit twice when I'm at work, often separated by a minute or less.  Let's have a brief example of what occurred daily when I was at my desk.
Oh, my email icon (on a mac) has a red badge on it, I need to check my email.  My voicemail light is blinking, better drop what I'm doing and listen.  My cellphone is blinking (or vibrating), I must have a text message, personal email, or voicemail, or just another copy of that email I read less than five minutes ago.  Ohh, 10 new stories in my feed reader, I can at least skim them real quick.
The straw that broke the camel's back, was counting how many emails I got one day.  The day that I counted, I received over 30 emails.  That day was not extraordinarily busy and I didn't even include text messages, personal emails, phone calls, or rss triage sessions.  At this point I should also mention how compulsively I checked my email, if the little badge popped up, I HAD to check my email, that second, and possibly respond, or else catch myself continually glancing at the little red icon. Combine that with the latest research showing it takes on average 64 seconds to regain your concentration after an email interruption and you have a recipe for non-productivity. Some simple math shows that I was losing an average of 32 minutes of productivity just regaining my concentration, add in a minute or two actually dealing with whatever interrupted me and you've got a full hour of my day vanishing down the hole of non-productivity.  

What's worse, thanks to the little red badge, or a blinking phone, even if I managed to have the will power to ignore the new email or phone call that just came in, I'm anxious and distracted until I stop and look at the new message.  But thanks to my little experiment, in the last week I've learned how to regain those lost minutes and hours, without losing my connectivity to the rest of the office.  Now on to what I did that made such a big difference.
  1. I disabled any audible mail, or calendar sounds.  (I left pop-up alerts active on my calendar as it's easy for me to get distracted and miss meetings!)
  2. I found a wonderful (Mac only) application, that hides the unread mail indicator from Mail.app.  ( Mail Badger ) This allows me to only check my email when I am between tasks and not have a steadily increasing little red number staring at me all morning.
  3. While I'm at my desk, I set my phone to a non-vibrate, non-blink, mode for all messages.  This dodges the "double email" problem mentioned earlier, as well as keeping me from dropping concentration to check a personal email.  To increase the effect (and due to an odd issue where the screen randomly brightens as it charges) I flip my cell phone screen side down on my desk.
  4. I started screening my calls if I'm in the middle of a task.  Obviously some calls you answer right away, but some of them you let go to voicemail.  I'd done this for a while with my cell-phone, but doing it with my office phone as well has made a huge difference. While this doesn't eliminate the distraction, it does make it as minimal as possible.
  5. I taped over my voicemail light on my desk phone.  It doesn't completely hide the bright red blinking light.  It still serves as a reminder to check (or act on) whatever call came in, but again it minimizes the distraction as best as possible.
Obviously some of these steps won't work, or don't apply to everyone.  I'm still an addict, despite this little experiment.  But thanks to a few simple tricks, I have regained my productivity from the continual blinking lights.  Have other suggestions?  Put them in the comments!
]]> <![CDATA[on fire and forget online services]]> 2008-07-27T00:00:00-05:00 iruel.net:/2008/07/on fire and forget online services Fire and Forget service. I set it up, start using it, but even if I don't come back for six months, I don't have to deal with any extra tasks punishing me for being away. Facebook is a great example, that I'm fairly familiar with, at failing miserably at this so let's break it down a bit.

To write this post I logged into facebook for the first time in I don't know how long. What I find upon logging in is a "News Feed" full of every minute detail of everyone on my list's life. There's so much data there I immediately ignore it. I then am told I have 6 friend requests, 7 green patch requests, and 15 other requests. I only know for sure what one of those three categories means. So I'll check out my friend requests. Turns out that clicking on friends requests just puts it at the top of the list of nearly 30 miscellaneous requests for me to check out. At a glance there is only one friends requests I care about, so I accept it. Now I want to ignore the rest of the mess on my screen. The only solution? Clicking each one of the ignore boxes individually until they're all gone, no select-all, nothing but individual actions. I can select all in my email, in my RSS feeds, hell in my news groups, but not on facebook. Now I realize that the reason this problem even occurs is due to the fact that it's been months since I last logged in. But so what? Just because I choose to use the service infrequently, does not mean I should be punished with performing various forms of "account maintenance" when I do decide to log in.

Now one could argue that facebook provides email notifications to keep this problem in check. You don't have to log in all the time, just when they notify you about something requiring your attention. Which sounds great, until that friend of yours goes on a picture tagging spree, and you get a dozen emails about all the pictures you now appear in. To combat this issue you can opt out of those notifications.  After a quick look of my personal notification settings, I'm given the option of disabling 37 separate notification options. Again without a select-all type option, I would have to click through each one and disable it. I can setup a spam to block facebook faster than that (and conveniently already have).

When you signup for a facebook account facebook puts the burden on you, the user, to keep the service running, and under control. By simply accepting a few friends to your facebook account, you implicitly agree to carry the burden of keeping facebook from overwhelming you.

So there's my small rant about how things are all wrong, and how I know so much better. But I haven't really provided any concrete examples of the way things can be better. So let's walk through some key ideas of Fire and Forget services.
  • Users are lazy, and already approaching information overload
  • Make defaults for user contact opt-in, not opt-out
  • Hide old, and possibly irrelevant data
  • Allow digest style notifications
  • Whenever reasonable, add select all/none options
  • Make complete account removal simple
  • Don't burden the user
  • Allow things to auto-expire
This list is not inclusive, and has the implied caveat of "whenever applicable and reasonable" to every item.  The idea is to let the service run itself, I want to set it up (Fire) and not have to manage it daily (Forget).  The key is letting me spend my time using the service not managing the service.  It's a simple list of things that will make your services more friendly to your less frequent users, without inconveniencing your constant users.  Everything on this list could be implemented almost universally.  Even twitter, the poster child for information overload, could handle almost all of these options, which is proven by the considerable number of third-party twitter add-ons offering a large majority of these features.  

Consider it a list of things to keep in mind when you're developing a new service to keep people like me happier.  If your service followed these suggestions I might even use your new application that will revolutionize and harmonize my social experiences with friends, family, and co-workers.  But probably not.

]]> <![CDATA[on subtle failure]]> 2008-07-17T00:00:00-05:00 iruel.net:/2008/07/on subtle failure proggit, I ran into a project I'd seen a long while ago and promised myself I'd keep track of.  I didn't.  But this story isn't about me and my need for a simple bookmarking/reminder service, and the ways in which such a thing could change how I keep track of interesting things on the web.  That story will come later.  No this story is about the clutter project, the project I had accidentally lost track of.

From reading their very dark website, you'll discover that clutter is YAGUIWT(Yet Another GUI Widget Toolkit). What makes it special? It's cross platform-ish, has bindings to a ton of languages, and supposedly doesn't bring the cruft that most of the well known toolkits have grown to contain. Despite being a bit dark, and being quite a visual shift from reddit's simple blue on white look, it's a visually appealing site that has the touches of professional design. It was easy to get my bearings on the site and find information about the project and things of interest, save for one little subtle thing. Screenshots.

Again, the clutter project, is a GUI/Widget toolkit, a graphical tool to make your applications usable by the masses. A tool that claims to work across several platforms, and languages. But most importantly, it's end result is a visible GUI application. I thought at first that I was just missing the link to the screenshots. They have to be there. Maybe they're just not linked off of one of the top pages. Who would make a well designed, and informative web page about a GUI/Widget toolkit, and not put up any screenshots? So, being the resourceful individual that I am, I moved on to the omnipresent google. This search should return all the instances of the word screenshot on their site. That's bound to turn up these hidden screenshots. Except it doesn't.

Failing to put up screenshots has obviously not caused the death of the project. But it's still a failure. A subtle failure, but a failure nonetheless. They've failed at managing their user's expectations. They've failed by forcing me to go hunt for information, that should be clearly displayed on their site. Or at the very least made it known that the information wasn't provided by the site. Despite failing to provide me with information I think is pertinent, as a programmer I'm still very intrigued by their product.

The time I spent hunting for the missing screenshots (and subsequently writing this post) should have been spent reading the API docs, or downloading the source, or installing a binary package, or a sample application, or any other activity that could lead to me becoming an active user, contributor, or at the least a vocal supporter. Instead I'll add the project back to my mental (or conveniently web based, and amazingly intuitive, and hopefully soon to be released) list of things to check back on when I have time. Odds are good that like the last time, I won't. ]]> <![CDATA[on living and working in the cloud]]> 2008-07-08T00:00:00-05:00 iruel.net:/feeds/5964520279678788379/posts/default/on living and working in the cloud Bingo!  Oh wait, "the cloud" isn't just a new phrase for your bullshit-bingo card, it's serious business.

Cloud computing is the latest buzzword from the folks who brought you such winners as: social media, social networking and Web 2.0.  

bullshit phrase for "the internet".
consumer rights, data transfer, offline access, licensing, ownership,
proprietary, application transfer
]]> <![CDATA[on being an internet luddite]]> 2008-07-07T00:00:00-05:00 iruel.net:/2008/07/on being an internet luddite Welcome to the blog of the world's only web programming Internet Luddite (as far as I know). Why would any sane individual who makes a living working on and with the Internet describe themselves as a Luddite? It's simple. Despite (or possibly because of) being one of the most technically capable people in my social circle, I'm often the last to adopt the newest online service and in some cases I'm actively campaigning against them.  It's to the point that people have quit sending me invites, friend requests, pokes, or whatever.

I don't actively maintain a facebook profile.  I have one, but it was setup by my wife, and I don't login regularly.  I don't have a myspace account.  I don't follow anyone on twitter.  I don't have any delicious bookmarks.  In fact, I've all but avoided almost all of the social networking services out there.  I just recently started subscribing to and following RSS feeds.  This is my first real blog.  

I've been developing web sites and web applications both as a hobby and a profession for about six years.  I wrote my first blog engine probably in 2003 for a very web 1.0 social site.  I wrote an RSS feed parser/generator around the same time.  I've built large enterprisey applications (boooo), and am about to launch a light and lean Web 1.99 application (stay tuned for details!). So why haven't I latched onto the Holy Grail of Web 2.0, the social network?

I'm a simple person.  I'm not an extrovert.  I value my privacy.  Most importantly, I'm lazy. My experiences show me that the current crop of social networking applications, don't fit my needs.  Most of them have too many features (facebook, myspace), have poor track records with privacy (facebook, myspace), or require a time investment to keep them from overwhelming me with data  (facebook, myspace, twitter).  The other major issue, which really is at the core of a lot of the privacy problems I have with these services, is that they assume that I want to share some or all of my data with others.  If I wanted to share my links, my photos, or my documents with others, I'd use something simple and direct, like IM or email.  I know, how quaint!

So what applications and sites do I use then?  I'm a fan of what I'll call "Fire and Forget" services.  RSS readers are a good example of this, I subscribe to a feed, and the reader keeps track of everything for me.  It doesn't email me everytime every blog I'm subscribed to changes (unless I was to set it to do so), it just sits and waits for me to come back.  I can skim over them, read them, or mark them all as read and move on.  Managing my RSS list can be done at my own time.  Most importantly to me, I can handle each message individually, or choose to ignore all of the changes and start with a blank slate again.

My favorite social services, are ones in which the social features that I use are almost exclusively anonymous.  Last.fm music suggestions have brought me to a variety of music I wouldn't have ever found otherwise, but it does so without requiring a huge commitment from me.  I install their application, and listen to music like normal.  When I decide I want to check my recommendations, I can play them at my own leisure.  Amazon's "others who bought this also looked at/bought...".  I've found great music and books this way as well, typically without ever being logged in.

Well there's the brief bit about who I am, where this blog came from, and what you can expect.  Thanks!

--Your friendly neighborhood Luddite.

UPDATE: It has been brought to my attention, that the term Luddite may not be as well known as I had previously thought.  For a bit of background check out the article at the repository for all the world's knowlege.
]]>