I use Dropbox as my cloud sharing weapon of choice. I share folders with friends and colleagues, and all of my screenshots are saved to a sub-folder of my public folder so that I can easily share them with anyone. This workflow might seem inherently insecure, but I don’t tend to screenshot things that are particularly secret; whether that’s a result of my screenshots having been public for so long, I don’t know.

You can easily change your screenshots directory from your Desktop to your Dropbox folder by opening a Terminal (/Applications/Utilities/Terminal.app) and running the following command:

defaults write com.apple.screencapture location /Path/to/Dropbox/Public/Screenshots


I like to have them in their own folder as I use Public for other things and don’t want it becoming overrun with screenshots. I don’t delete images; occupational hazard.

You can now close your Terminal window and go back to ignoring it if it scares you. I know a lot of people are uncomfortable with it. Once you’re saving screenshots to that directory, you can download the Automator Workflow. Unzip and open with Automator. You’ll be asked if you want to install it. If you trust me, click install and the workflow is copied to the correct directory and opened for you to edit (you’re going to need to edit).

You should be presented with a screen that looks a little something like this:

We’re only interested in the first box, where you’ve got some config to edit.

dropbox: The path to your Dropbox folder.
screenshots: The path to your Screenshots folder. Must be relative to $dropbox.
dropboxuid: Your Dropbox User ID. Go into your Dropbox Public folder, context-click (right click, thanks Apple) > Dropbox > Copy Public Link. Your User ID is the big number in the URL copied.
bitlyuser: Your bit.ly username.
bitlyapikey: Your bit.ly API Key can be found at the bottom of this page.

You may not care if your URL gets shortened. If this is the case; find the following block of code in the first box:

short=`curl -m 4 -0 "http://api.bit.ly/v3/shorten?login=$bitlyuser&apiKey=$bitlykey&format=txt&uri=$encoded"`
if [ -z $short ]
then
    short=$url
fi
echo $short


And replace it with:

echo $url


Now you’ll just get the Dropbox Public URL copied to your clipboard; not bit.ly (which bit.ly will probably prefer if you take a lot of screenshots!)

I’m making the following assumptions about your system:

• You have Growl.app installed. If you’re not sure, open System Preferences and look for a pane under “Other” called “Growl”.
• You have Dropbox installed
• You have changed your Screenshots path (using the method above) to be within your Dropbox Public folder
• You have OSX Lion installed. I don’t see why it shouldn’t work on Snow Leopard, but I haven’t tried and I can’t.

If you satisfy those criteria, you should have success with this workflow. It is, however, offered with no support and I will accept no responsibility if you break your computer playing around in the Terminal because it looks like The Matrix or trying to update Ruby (system Ruby works fine) or something. If you’re friendly and would like some help, please ask on my Formspring and I’ll try to help. I’m by no means an expert at Automator, bash or zsh scripting or AppleScript but I can get things to work. I suck at AppleScript so badly that I had to paraphrase the AppleScript portion of this Workflow from here.

Yes, Perkins, I’ve heard of Cloud.app.

Non-developers often assume an application is invariably more valuable with a feature than without it

Via literate programmer

I can really empathise with this sentiment. There’s a huge temptation instilled somehow in people buying websites that more features = better quality. We really try to get clients to spend money on quality marketing at Buffalo, but they rarely realise that a bucket of features is pretty irrelevant if people don’t know your site exists. In the above, you can substitute the word “site” and its variants above with anything really.

Not 1000, but you get the idea. Fuck.

Personally, I get my kick from cleaning really crappy data. Lucky for me, I’ve had a lot of crappy data to clean recently, so I’ve been able to flex my XPath, Regex, semi-complex MySQL and image manipulation muscles relatively frequently. If you’re as much of a fanatical cleaner and hoarder as I am, cleaning data is probably for you. Grab a 50MB CSV and try to programmatically make sense of it. It’s fun! I promise.

However, one drawback of unit testing as a concept is that computers are, as a rule, infallible when it comes to this sort of thing. Humans, on the other hand, are completely fallible. If I make a change to some code in my checkout process that has a knock-on effect I didn’t count on in my unit testing (like changing the way delivery is calculated/stored/whatever), I wouldn’t necessarily foresee there being any problems in the email that gets sent after a transaction is completed (that may seem pretty esoteric, but it happened today). Part of this issue arose because I didn’t write the original site, and there was no way for me to detect that this could’ve caused a problem without going through every file on the site and manually checking that there was a problem, but another part could have been solved if a good unit testing framework was in place.

Now, when I say “good”, what I really mean is “comprehensive”. Anyone can write a good unit testing framework and here’s how, in my opinion. You test /every single dependency/. Everything. Bar nothing. If unit testing could’ve solved my problem today, it would’ve been done a little something like this (not exactly like this because the code on this site is largely a mish-mash of procedural and I-don’t-quite-understand-OOP-so-I’ll-give-it-my-best-shot – I assume it would’ve been very difficult to express this as a unit test).

Say I have a method that outputs this email that gets sent. I would write a unit test to capture the output of that method (when supplied with sample data from my database table, for a little extra reliability). I would then take this method and write my own version of it inside my unit test, so that I know it’s correct and compare the output of the two methods. If they differ, I would (PHPUnit) assertSame(legacy_method_output,my_method_output), and the test would pass if I hadn’t fucked it up. Now, the perceptive among you will have spotted something wrong here. In order to write this unit test, I would first have had to know about this email’s pre-disposition to causing problems in the first place. This, in this case, is the entire battle. Furthermore, I would have had to completely rewrite the method, solely to test that the old method hadn’t been broken in some way. For future testing purposes, this is really useful but, chances are I’d just rewrite the method and move on.

All of this isn’t to say that unit testing is fundamentally flawed. Far from it, in fact. I can see that it’s an incredibly useful tool for documentation and future-updates. When I come back to code that already has a unit testing framework, I’d simply make my alterations, run my unit tests until they all pass, then write some more to cater for my currently augmented feature-set. I would then know (with only a shadow of a doubt) that everything is brilliant and nothing is going to get fucked up when I put my code live. That’s got to be worth it! Not only the above, but unit tests seem to me to serve as excellent developer documentation. If you want to know how something’s supposed to work, never mind asking the project manager or client (who probably don’t know, and don’t really care!), you can just look and the guy who wrote it will have told you! Brilliant.

The only (and sadly, this is a pretty substantial “only”) problem is time (as with everything, I guess). You get all of this great peace of mind, but you have to put time into it. And it’s not just a small amount of time either, it’s a lot of time. Once you’ve written all your code (maybe doing it as you go along – 30 minutes a day or something) you then have to write tests to try and break it, and cater for every potential outcome that could arise from user or developer input of the code you wrote. That’s a large investment of time. I can’t quite decide if the net gain is quite worth the input, but I’m tipping towards a yes. I spend a lot of time a bit stressed about whether a modification I’ve made is going to cause unexpected problems, and I’d really like to be able to be more confident with this. I’m also one of those people who likes doing little scripty things, and gets a great sense of satisfaction from ticking boxes and watching “make test” throw out 100% success. Maybe this is for me, after all!

I never really got what spaghetti code was until today. That might sound dumb, but it’s a term that is quite widely-used in different contexts so it can be an odd one.

Today, I have been working with code that is devoid of any design, regard for future developers or useful documentation. Like so much PHP, the end result works, so it’s great. Except it’s not.

Imagine each line above is a function or method call, which has its own integral part to play in the execution of a web page (in this case). The entry and exit points are single entities, but what goes on in between is nothing short of scary!

Ideally, I like to see code the main vein of which is there at the start and the end of the app’s execution. Logic can branch from this as far as it wants to get what it needs, but it’s ultimately serving a purpose for the main line. The more I delve into OOP in many languages, the more I realise that procedural code is quite liable to spaghetti, whereas OO is not. That’s not to say it’s impossible, but it’s easier to have one method that sets everything in motion, configures your program and then receives and redirects input in OO than it is procedurally.

Since I started properly getting into OO, I started to liken the execution cycle of a procedural program to a glass of water falling. Everything starts from the same point, but over time everything splays out and does its own thing. Debugging procedural code, therefore, is analogous to blindly cleaning the aforementioned spillage – there is a good chance that the part of the spillage you’re working on has nothing to do with what you’re actually trying to achieve – no matter how relevant it looks!

Unfortunately, I blame PHP for the natural progression of spaghetti code from procedural to half-assed-OO. It’s so easy to get things done without really knowing what you’re doing that it’s actually borderline dangerous. A mishmash of procedural and OO is the absolute worst thing to debug, as it normally combines the horrible execution cycle of procedural apps with the potentially confusing trail of inheritance. Let me tell those who don’t know – it is VERY obvious when you’re working with code written by someone who does not understand inheritance (and I don’t mean what it is, I mean *why* it is) and it almost always makes their half-baked bastardisation of OO impossible to work with.

Have I had a difficult day? You could say that.

Sometimes I wish I didn’t have this obsessive need to solve everything right now. I keep missing out on the important things in my life because I’m so paranoid that a fresh pair of eyes won’t fix the problem I’m having. Tonight, I was so frustrated that I actually cried and shouted and drank and wished for cigarettes. I’m so pathetic. I worked through deliveries of photos of my babies being cute, and my wife being sleepy and adorable, just to reach the realisation that I need to really look at a problem and stop wasting my time thinking that working harder, or swearing more will solve my problem. Stupid, stupid, stupid.

I need to sleep more, not just go to bed and stare at the ceiling.

You try being creative when you’ve spent all day describing parameter data types.

I’m working on a project at the moment that requires me to have an awareness of “working” days. Specifically, when a product is sold, the customer has three working days to cancel their order. This would be all well and good if there was 365 working days in the year, and all companies were the same. I started out with this assumption, but was quickly confounded.

Before I explain how I solved (well, only partially – it would require a calendar app to fully solve it to my satisfaction!) it, I’ll explain a little about how some classes come to be in my workflow.

When working in PHP, I have around 5 or 6 classes that I take everywhere with me. One for generating a class that represents every database table, one for DOM generation, one for database access, one for laying out application-specific database entity grouping (how hard can one try to avoid saying the word “model”?!) and one that acts as a sort of “other” class and includes functionality that doesn’t fit elsewhere. This is a single class (called “core”, if you’re interested) that contains a bunch of un-interrelated static functions. It acts as a breeding ground for functionality that gets bigger and bigger (either in the file or my head) before I give up and move it to its own domain. An example of this was back when I started this way of working and my database access functionality was in here. In a perfect world, only my __autoload() (best function ever, by the way) function would be here but, as I said – in a perfect world!

So, I have my core::nWorkingDaysPassed function, and all is well. The first argument is the date you’re counting from, the second is the date you’re counting to (defaults to now), the third is the number of days you want to count (defaults to 3 because that’s what I’m working on now) and the 4th is an array of days of the week that are in your working week, defaulting to Monday through Saturday, again because of what I’m working on now.

I’ve already spotted a problem with this function – it has too many arguments. I don’t like passing a lot of arguments to a function, and I think this is probably to do with my grounding in PHP – the argument orders in PHP’s core functionality is so varying that it’s incredibly difficult to remember what they are, even for functions you use every day! Luckily the documentation is good enough to counteract this. By the time I’ve finished this thought, I’ve spotted another problem – it doesn’t take public holidays into account. To take public holidays into account, it’s going to need to be an object of its own. I can’t get that much functionality into one function. Because of time constraints, and authorisation from the client, holidays are no-longer a concern (as they’re open, thankfully!).

On to solving my problem. It’ll be a lot easier to write this in pseudo-code. I know this because I just deleted the verbose version!

normal_week = ('mo','tu','we','th','fr','sa','su')
working_week = normal_week
for each working_week as day:
	if day is not in argument_working_week:
		remove day from working_week
weeks_spanned = argument_days / 7 rounded up to nearest 1
all_weeks = merge weeks_spanned*normal_weeks
i = first instance of argument_from weekday in all_weeks
j = i + argument_days
while i < j:
	argument_from = argument_from + 1 day
	if all_weeks[i] is in working_week: # normal working day
		i++
	else: # shouldn't count towards our total
		append a day to all_weeks # so we don't run out!
		i++
		j++
if argument_from >= argument_to: # that amount of days has passed
	return True
else:
	return False

I realise that commenting pseudo-code largely invalidates the need for pseudo-code but it started to look like Python and I didn’t want to spoil it!

Looking back at it now, I don’t know why it caused such a headache but I’m just one of those people who has problems with the difference between dates. I hope this helps someone, though I doubt it will!

It’s crazy-simple, and I’m not bothered about people using it or ripping it off so go for your life! The Twitter class, twit.py:

import urllib2 as urllib
import base64
import xml.dom.minidom

class Twitter:
	public = 'http://twitter.com/statuses/public_timeline.rss'
	friends = 'http://www.twitter.com/statuses/friends_timeline.xml'
	action = 'public'
	actions = ['public','friends']
	items = []

	def __init__(self):
		pass

	def auth(self,username,password):
		self._username = username
		self._password = password
		self._b64 = base64.encodestring('%s:%s' % (self._username,self._password))
		self._authhead = 'Basic %s' % self._b64

	def setAction(self,action):
		if action not in self.actions:
			return False
		self.action = action

	def fetch(self):
		if self.action == 'public':
			url = self.public
			self._req = urllib.Request(url)
			self._handler = urllib.urlopen(self._req)
			self.parsePublic()
		elif self.action == 'friends':
			url = self.friends
			self._req = urllib.Request(url)
			self._req.add_header('Authorization',self._authhead)
			try:
				self._handler = urllib.urlopen(self._req)
			except IOError, e:
				return False
			self.parseFriends()

	def parsePublic(self):
		txt = self._handler.read()
		feed = xml.dom.minidom.parseString(txt)
		statuses = feed.getElementsByTagName('item')
		for status in statuses:
			self.items.append(status.getElementsByTagName('description')[0].childNodes[0].data)

	def parseFriends(self):
		feed = xml.dom.minidom.parseString(self._handler.read())
		statuses = feed.getElementsByTagName('status')
		for status in statuses:
			self.items.append('%s: %s' % (
				status.getElementsByTagName('screen_name')[0].childNodes[0].data,
				status.getElementsByTagName('text')[0].childNodes[0].data))

	def printall(self):
		for item in self.items:
			print '%sn' % item

and twitter.py

#!/usr/bin/python
import sys
from twit import Twitter

twit = Twitter()
if len(sys.argv) == 1:
	twit.setAction('public')
else:
	twit.setAction(sys.argv[1])
if (twit.action == 'friends'): # needs authentication - check sys - 2 is username - 3 is password
	if len(sys.argv) == 4:
		twit.auth(sys.argv[2],sys.argv[3])
	else:
		twit.setAction('public')
if twit.fetch() is False:
	print 'Username or password was incorrect'
twit.printall()

To use it, you’ll need to go to the directory that twit.py and twitter.py are in and run chmod +x ./twitter.py so that you can execute it, then use the following commands to access it:

./twitter.py # this will retrieve the last 20 results from the public timeline

./twitter.py public # as ./twitter.py

./twitter.py friends username password # retrieves the last 20 tweets by your friends

there is pretty rudimentary functionality for checking if you’ve put the correct username or password in, and hopefully it will become more friendly once I get a bit more used to sys.argv and lists in general. This has only been used in python2.5.2 in OSX, so YMMV in other environments. Let me know in comments!

Also, follow me on twitter.

Also also, I’ve just noticed that the code is too wide for my layout. It’s only temporary anyway – copying still works.