Take that Duke Nukem.

A couple more hours of applied effort and I had a macro that looped through all the images in a directory tree and laid them out in Excel. I spent the next four days surfing the web and handing out files.

The first time I did any programming it was more than likely a “Hello World” script in ASP. However, I do remember doing something very similar to what Kan did to automate a process which a fellow employee spent hours a day doing.

I worked for a brokerage and each and every day a fellow employee had to take about 100 stock ticker symbols and run reports on them and input that data into an Excel spreadsheet. This was circa 2000. This went on for nearly a year before I caught wind of what they were doing. On a break or at lunch I was talking to this person and they explained to me what they did nearly every morning for two hours. I was astounded.

When I got back to my desk I fired up my code editor (EditPlus I believe) and in about an hour I had built a very simple PHP script to pull the relevant information for all 100 stock tickers using Yahoo! Finance’s CSV creator. Then a simple Excel macro formatted the data the way that this person had been doing. In all it took the script and macro about 45 seconds to run and create an email with the new data as an attachment.

It wasn’t long after I shared this workflow with my boss that the person that had been doing that job needed to figure out something else to do or they’d probably be of little use to the company. Whoops. Not my intention.

Another co-worker and friend at the time bought me a sticker from Thinkgeek and stuck it to the side of my computer. It read “Go away or I’ll replace you with a very small Shell script.” (Now available in T-shirt form.)

There has been a lot of hoopla lately about the fact that people believe that everyone should learn to code. Some are taking that quite literally to mean that everyone should learn how to build applications or websites. I don’t take it that way. I think everyone should learn the “languages” that their applications speak so that they too can take advantage of working smarter rather than harder. If you are tasked with using Excel all day become the very best at it you can be. And that means being able to program macros. If you are asked to use multiple applications on a Mac learn how to use Services or Automator to do some of your reoccurring tasks for you.

This type of programming won’t put you out of the job. It will free you up to get more work done. To use your time to do other things rather than the same thing every single day. If you do the same task more than once a week you should seriously consider learning how to automate it.

Light Table is based on a very simple idea: we need a real work surface to code on, not just an editor and a project explorer. We need to be able to move things around, keep clutter down, and bring information to the foreground in the places we need it most.

This project is inspired by Bret Victor’s presentation Inventing on Principal that I also mentioned Nilai is inspired by. Light Table makes for a very interesting demo. The most intriguing of the modes shown was the mode wherein you could see all of the related code while you were editing, say, a specific method in a class. This type of IDE wouldn’t just save time, it’d probably result in far better code.

It will be interesting to see what comes of this.

One of the distinct features in the Path app is the fly-out menu that allows you to share photos, comments, location, etc. Two developers took it upon themselves to build out that menu both in CSS3 and using CoreAnimation. Both open sourced their work and gave credit.

• Path menu in pure CSS 3 by Victor Coulon.
• Path menu using CoreAnimation by ??? (Levy)

/via Mike Rundle on Twitter.

/via John Gruber.

/via Kyle Neath on Twitter.

“Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.”

This bubbles all the way up to the top of the product too. The code of a not-so-great feature can be gorgeous but it is still a feature that isn’t quite right. Focusing on the quality of the product from the engineering to the coding to the marketing is also contagious.

Shaun Inman, who just released The Last Rocket for iOS, put together a quick game called Data Entry Sentry that works on an iPad (or any Webkit browser). Fun to play. I don’t know where he gets the energy.

In the May issue of Hacker Monthly my piece Why you should never ask permission to clean up code (which has received over a quarter-of-a-million views to-date) was published and I’m extremely grateful to the Hacker Monthly team for their consideration.

I highly recommend picking up a subscription to Hacker Monthly (if you don’t already have one shame on you).

This is especially true with writing software but lets think about an everyday task, shall we? What about washing the dishes? How long is it going to take you to wash the dishes the next time you decide to do that oft procrastinated task? Five minutes? Ten? Two hours? The truth is, you don’t know. You might count the number dishes, say 10 dishes, and think it will take you about 5 minutes (or 30 seconds per dish) to wash, dry, and put them all away. But, how dirty are these dishes? Is one a burnt pan? Do you have the right soap or tool to do the job? What if you find that, while you’re washing a pot, that the pot’s handle is loose? Do you fix it right then or wait till next time? If you fix it right then how long will that take?

You see where I’m going? Estimating the amount of time it will take to complete a task is – well, I’ll just say it – impossible. But we try. We try to calculate all of the possibilities, rule in error, and even give ourselves some padding in the estimate to lower expectations and over deliver. But we almost always fail. Sometimes miserably. The difficult part is coming to grips with that and embracing it.

In my entire life I’ve never been 100% accurate on estimating time. I’m forever an optimist and because of that I’m almost always late at getting something done because I always think it will take less time to finish something than it really will. I think in rose pedals and rainbows.

One quick example to beat this horse until bloody. Recently I was playing around with a pet project of mine and I wanted to add Twitter’s authentication tools to it. In short, this allows people to use their Twitter credentials to log into my application. Should be relatively straight forward, right? Well, ever the optimist and being smart and efficient I grabbed an open source library that claimed to do exactly what I needed. I thought, foolishly, that I’d simply plug the library into my application, follow the setup instructions and I’d move on in less than 30 minutes. It works this way sometimes but not very often. Suffice to say it didn’t work like this for me. In fact, I still haven’t finished hours later. Hours. Something I thought would take me less than 20 minutes and I have now spent hours trying to get it to work properly. And guess what? I’ve decided to scrap it. Hours and hours wasted only to figure out that I’d have been better off building this myself. And now it will take me a few hours to do just that (or much longer).

I’ll never learn. I’m freely admitting that right now. I’d rather be an optimist than be the person that thinks that everything they ever want to do will take too long, be too hard, and will ultimately not be possible to achieve and thus; never try. I’m going to continue to try and continue to fail but – every once and while – I’ll succeed (although later than I would have thought) and be happy.

“Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. However, often times we find ourselves up against walls in the form of budgets, time, due dates and expectation and so the typical “powers that be” at companies often veto the request. My advice to you, dear developer, is to never ask for permission for things you know are vital to your work.

You know your work environment better than I do so perhaps you can ask this question and immediately have the full support of your team. Sad to say that many aren’t so fortunate. They’ll ask their boss if they can take some time to clean up their code, make it efficient and extensible and, while the boss may recognize the need for such tasks, ultimately the boss will simply say “maybe we can do that later”.

Why is this the typical reaction? Because bosses don’t have to read, edit and support the code.

This is folly and every developer knows it. Bosses, (if you’re reading this) putting off a few hours worth of code clean-up now will only turn into many hours or days in the future. So by allowing your developers time to do this much needed code maintenance you’re actually saving your company money. But don’t worry – they’re not going to ask you for permission anymore. They’re just going to do it.

We’ve set up a special page on Viddler just for Magic Ruby to help let people know some of the things we’re already doing with the Ruby community. We hope to learn a little about Ruby, to let attendees know about Viddler, and to enjoy the weather.

Viddler’s offerings to developers aren’t limited to only Ruby. We’ve got a fantastic API that has been recently overhauled and wrappers for just about every language. We power some of the biggest brands online and our platform has been used to power web sites, applications, iPhone and iPad applications and much more. I personally hope to help Viddler grow in this area in 2011.

If you’re a developer and ever have any video needs – consider using Viddler for your next project.

My handy dandy little script that makes it easy to parse an RSS feed and send links to Twitter using PHP just got a nice little update. It now supports OAuth and has been cleaned up quite a bit.

Oh, version 1.0 is still available.

I’m working on a relatively big update to Viddler’s WordPress plugin and something that doesn’t seem to be documented anywhere is how to test a Dashboard Widget if your plugin supports one.

It is fairly easy to add just a bit of code to make it pretty simple to test your widget. First, rather than only loading your WordPress Admin URL (ie. yoursite.com/wp-admin) you simply prepend the appropriate information to the end of the URL. Like this: yousite.com/wp-admin/index.php?page=viddler&noheader.

Then, somewhere within your plugin’s code, you add something like the following:
function viddler_page() {
if ( isset( $_GET['noheader'] ) )
return viddler_dashboard_content();
}

Obviously viddler_dashboard_content() is the function that I use to build the HTML for the Dashboard Widget. This will return the HTML you’re creating for your WordPress Admin Dashboard Widget sans JavaScript and CSS. But at least you’re able to test your output.

/via the Viddler Developers Group.

Doing JavaScript for mobile platforms? Maybe you should check out Zepto.js.

Update: Via Kyle Slattery on Twitter: Sencha.

I haven’t yet had any experience using jQuery mobile (I simply do not do too much JavaScript anymore) but I wanted to make sure that any “competitors” to such a popular framework gets some attention. Does that make sense?

Last night I ran into such a problem wherein, so far at least, I’ve been unable to find the cause. It is very frustrating. Trial, error, trial, error, hunt, poke, literally cause my app to crash on purpose hoping I can find the problem, comment out line after line after line, change settings, etc. Usually during this process I will end up breaking my application even more and forget how to change it back (thank goodness for Git).

The problem I’m currently having seems to be environmental. The problem doesn’t exist in one environment but does on another. This actually causes even more fist-pounding because I know my code works.

The part about this process that is most frustrating is that the time spent solving one of these minor problems (that have a major impact on the app) could be time spent making a great application. It is my least favorite part about programming. Nowadays it is possible to accomplish an incredible amount of work in a short period of time yet, still, you run into these little time wasting seemingly no cause no solution problems that take a very long time to work out. Grrr!

Although it may seem like an anal attempt at control style guides can go along way in making a lot things easier in the project workflow. Reading through and fixing bugs in someone else’s code, less conflicts will occur when merging branches and the speed at which new features can be added are all fringe benefits.

As Jon said: “It helps with everything from readability to quality control and especially helps a team become that much more cohesive.” So, do it.

/via Simon Willison.

After searching on GitHub for scripts that did the same thing I didn’t come up with much. Hopefully this both fills that void and gets better because it is now out in the open.

I love that they came right out and said that they were inspired by WordPress’ move.

Hopefully this feature will be available via a plugin sometime in the near future?

/via Tony Schneider.

Update January 19, 2010: This script is now available on GitHub. Go forth and fork.

Today I noticed that my now ancient PHP script to update Twitter automatically using PHP/cron needed to be updated. It turns out that Twitter stopped recognizing URLs with ? in them as clickable links. Here is an example tweet where you’ll notice this happening.

I could have told Twitter and asked that they update the way they handle URLs but in reality my script was old, slow, too long, and shouldn’t include ? anyway so I figured I’d write a new one from scratch that included my short URL scheme.

So, here is the PHP script to parse an RSS feed and send the posts to Twitter. It includes a caching mechanism so that you won’t have duplicate URLs posted to Twitter. If you want it, take it. However, if you are better than I am at PHP (most 6yr. olds are better than I am at programming) then I ask that you fork the script on Gist and try to improve it.

Update Dec. 6 @ 5:34p: Kyle Slattery, follow Viddler team member, loves him some Ruby on Rails. As such he’s offered up this version of the script rewritten in Ruby.

Next up we have Anthony Sterling, self-proclaimed “PHP addict”, who has rewritten the script to make the configuration a bit easier. He also changed the way the cache is saved. He’s using a hashed version of the title for each post as his key. I do not believe this to be the best way to go, since post titles can easily change after publishing – but I do like that the script is about 20 lines shorter and the code is arguably cleaner.

Thanks to both Kyle and Anthony for their versions. Lets keep this going and see if we can get this script much more succinct, stable, faster, and usable by others?

Pie Guy is a fun game for your iPhone that is free, is installed via the Web (it is a fancy Web page), works offline, and is actually a lot of fun (works sorta like Pac-Man).

Neven Mrgan, the developer of Pie Guy, built the game – not only so people can enjoy the game – but to help show what is possible via HTML, JavaScript, and CSS for building games or applications on the iPhone using the Web browser rather than native cocoa technologies.

“If you find Pie Guy a fun game to play, well that’s grand.

But, I hope Pie Guy will also be an opportunity for the code-savvy among you to learn a trick or two about making serious web apps for the iPhone. Just grab my source code and tweak it. I’m not talking about just a fancied-up webpage here; this is a fullscreen game, with fast gameplay and responsive touch controls. I can’t wait to see what a better programmer does with this stuff (it’s not hard to program better than me!)”

A very notable thing to do and I hope a ton of talented developers take him up on it. I’d love to see stuff like jQuery for iPhone games/apps (which I’m sure exists in some form or another).

Also of note: As Neven pointed out in his announcement post – don’t try this on your first generation iPhones. This game only performs well on an iPhone 3GS.

/via Simon Willison.

Viewing the source of a page on Google Chrome is, for the most part, a terrific experience. Chrome supports syntax highlighting of the underlying code of a page making it much more readable for us geeks while we look under the hood.

However, something I’ve run into of late is that it doesn’t work very well for dynamically generated pages. The issue seems to be that since Google Chrome opens a new tab to view the source of the current URL that you’re on, it actually “reloads” that page with new session data, as well as ditching all of the POST variables you may have sent to it. This causes some confusion and may lead to head scratching (as it did for me).

I don’t know of a work around currently but knowing this may save you some time.

Side note: I’m loving Google Chrome for Mac.

/via Mike Rundle on Twitter.

• Use your own API. The very best way to make sure your API is equipped with everything one would need to build something of value is to use it yourself. You will find that by using your own API to build your product you will work out a lot of kinks that would otherwise frustrate third-party developers.
• Remove as many learning curves as possible. An example of this is to provide more documentation than you really need to by writing tutorials and not just flat documents. Code examples go a long way too. Provide “wrappers” or frameworks in common languages that help third party developers to “plug and play” with your API.
• Follow standard conventions. This is related to removing learning curves, but you do not go against the grain. Try to utilize as many standards as possible. Chances are any third party developers that use your API will already be familiar with much of what you’re doing.
• Support multiple response types. Do not assume that third party developers will only use the response type that you prefer. Supporting XML, JSON, PHP, and others is not too much more work and yet has a measurable impact on your APIs adoption.
• Create and keep your own conventions. If you have one way to do things try to stick with it all the way through your API. An example of this would be how Twitter recently added a Lists API to their API and used the very same convention of interacting with that API as they do with accounts. This makes integration of new features dead simple and it will be appreciated.
• Add some brains! If there are common actions that must be taken by all third party developers to interact with your API try to build those actions into the API. A good example of this is Flickr’s support for machine tags. Although a third party developer could do all of the work on their end to work with namespaces, predicates, and ultimately the values they are looking for – Flickr makes it easy by doing all of that work on the server-side. Taking the most common actions and rolling them back into the API will slowly build tremendous value in your API.
• Open source as much code as you can. If you build any tools, frameworks, testing applications, products, or anything that uses your API – try to release that stuff as open source. This will help any new third parties to be able to see real examples of products that use your API. It would also be a good idea to promote open source projects to use your API as well so that the entire development community that you build can benefit.
• Communicate with those using your API. Give the developers a clear path to communicate with you about your API, their applications, or anything they may need to get their jobs done. You will learn a lot about what you are lacking that you may have never thought of.
• Drink a lot of caffeine.

These are just a few tips that I’ve learned in working with Viddler‘s development team to build our API. We’re currently working on the next version of our API, dubbed version 2, and we’ll be making massive improvements to the way that the API works, is documented, and how we use it internally. We’ve learned a lot over the last few years and we’re taking all of the tips above and everything we’ve learned from our development community to build what we think is a much more solid offering.

I hope that if you are building an API you can learn from our experience, our failures, and our successes (and I’ll try to share more of them here). If you have anything you’d like to add about good API design please do so in the comments.

The photo of the fire hydrant has nothing to do with this post but I liked it. It is one from my Lincolnton, North Carolina photo set.

Even though he’s publishing all of these “drafts” on the site for free, I will be getting the paper version when it is published.

Via John Gruber.

I’ve been dabbling with zen-coding plugins with Coda for about a week. Loving it.

Fellow Viddler and friend Kyle Slattery is reworking his tag search pages. He’s created a really nice way to filter through the various types of content on his site based on tag search results. For instance, going to a tag search for my name will result in a few photos and a few links that he tagged with my name. You can then filter those results to only show you the photos or only the links.

But what if you hack the URL and search for a tag that shows no results? At current Kyle shows an error page. However, there was no error. His Web site should never link you to a page that doesn’t return any results (though it does right now). So how did the person end up here? They may have done a search, they may have hacked the URL, or someone else linked them to this page. Which ever way they ended up on that URL – there is still no reason to show an error.

This brings me to why I call these types of URLs “These aren’t the droids you’re looking for URLs”. These are URLs where you know what the person is looking for (droids) you just don’t have any. In the example URL I use above, a tag search for my name filtered by entries, Kyle does a good job of stating that there are no entries tagged with my name. This is much better than showing an error. In the other example, of a tag search that ultimately returns no results, he should do something very similar. This isn’t an error. There is just no content on his site that is tagged with ‘asdf’.

One of the suggestions I gave to him was to do a search through his own tags and try to see if, perhaps, they’ve mistyped the tag. I’m not sure what ‘asdf’ could have been, maybe sad? Or, what if someone spells my name with two Ls? This isn’t easy to program against – but there is an easier option that he could set up. Offer a search box with the tag that they entered already filled in and show a message of “Sorry, but I have nothing tagged with ‘asdf’. Maybe you misspelled what you’re looking for?”

My site isn’t a good example of best practices here. It used to be. But I had to hack WordPress to bits to get it to work last time and I’ve since upgraded WordPress too many times for those old hacks to work. However, if you’re looking for good examples – I’m sure Kyle’s site will end up being a pretty good example soon enough.

Have you seen any really good examples of this?

“The Viddler team is using CodeIgniter more and more for our internal PHP projects. Obviously we need to use CodeIgniter with the Viddler API quite a bit so we figured we’d share with you how easy it is to include PHPViddler, the open source PHP API wrapper class for the Viddler API, in your CodeIgniter application.”

Read more in the blog post titled How to: Use the Viddler API with CodeIgniter.

Speaking of Code Igniter, Jonathan Snook (way back in March 2007) compared it to CakePHP. Although both frameworks have matured slightly since then, this overview still holds up ok – although he is a fan of CakePHP where I’d choose Code Igniter. Thank goodness for choices.

Go forth, and hack! Oh, and its completely open source too. (More on this later.)