As you may have noticed a great number of my posts are simply scripts with a bit of explanation. I thought it would be useful to outline my philosophy of scripting. I’ve found these general tips to really make things considerably more useful and hope they help you.
1. Consider scripting an interactive process. Unless you are writing workflow scripts for other people don’t worry about making everything perfect. Rather write scripts so you can easily customize for any new task at hand. That is don’t worry about the polish and to a point look to customizing the code rather than putting a generalize UI in them. A big mistake people make (IMO) is putting too much error checking, prompts or the like in their scripts. A script should be focused on the problem at hand and not the general case. I also find that 90% of my scripts I simply run out of TextMate since they are one off scripts. By running them interactively I can quickly customize them to the problem at hand.
2. Make your scripts easy to customize. This is a natural corollary to (1). Consider your script to be like a toolbox. Make it so you can quickly leverage it to a new task. This means making sure you break things down into neat functions you can move to new scripts. It means making sure you write it so it’ll work from the command line, from a script menu, or as included by an other script.
Despite being a corollary of (1) this principle ends up being in tension with (1). That’s because you’ll always have to decide whether to write just enough for the task and hand versus writing enough that you can more easily leverage later. Usually I have two methods I use. I first try to guess what other tasks I’d be using it for in the near future and prepare. But no more. For error checking I put in a reasonable amount and then just run the script against my sample data. When it hits a problem I add in more error checking.
3. Organize your scripts. You can organize by task, by application or whatever. Personally I have in my ~/script several subfolders labelled iTunes, Address, Excel, etc. I also have a few project directors such as ‘shipping scripts.’ This makes it quite easy to find your script but also to include functions from other scripts (if you are using Python) For frequently used functions, consider breaking them out of individual scripts and placing them in modules you include. This allows you to improve all your scripts as you run them (say with increased error checking)
4. Leverage macros and Automator. With Automator you can use your script to either do some pre or post processing of automator workflows. But with Snow Leopard Apple allowed Automator to generate services. These services pop up in the service menu and are a fantastic way to call scripts, to pass data to scripts and so forth. The only downside I’ve found to Automator Services is that they are quite slow. I also heartily recommend using a macro program like iKey, Quickkeys or the like. You can call scripts immediately by some command key or function key. These programs also often let you have custom menus that are much faster than the service menu. Finally many applications like iTunes have a Script menu. This won’t allow you to call Python scripts, sadly, but it is trivial to create an Applescript that calls a Python script. When scripts are easy to call you are more likely to use them.
5. Use logging. Often scripts work through a lot of data or run in the background. Writing logs so you can check to see what your scripts are doing is essential. I’ve discussed doing this with Python in the past.
6. Use intermediate steps. There’s sometimes too much of an inclination to have everything done by a single script. I’ve found that writing data to an intermediate storage such as a Numbers or Excel document is extremely helpful. That way you have one script to generate the spreadsheet, you then look through the spreadsheet deleting anything you don’t like, and then use a third script to finish the job.
For instance I was recently working on a script that was sending out some samples to many clients. I had a script that generated mailing information for all our clients. I then went through the list and removed clients that didn’t need samples. Then I ran the script that printed FedEx labels for each. Trying to achieve that with a single script would have been ridiculous. Either I’d have to carefully select the clients in Address Book or I’d have to put a slew of if statements in the code. Sometimes manual manipulation is ideal and you have to keep that in mind when scripting.
This entry was posted on 2009/10/07, 2:24 pm and is filed under Applescript, Automation, Commentary. You can follow any responses to this entry through RSS 2.0.
Both comments and pings are currently closed.
Keep your iPhone wifi connection live. That way you're not always turning the phone on just to access it from the Finder. Add the Insomnia SBSetting to turn this off when not in use.
The psychological benefits of schedules. Sadly I've found this as well. The main reason I quit doing IT is people would want me in at 9 and be in late working on the machines.
Windows Live Sync for Mac available. I might give this an other try. In the spring I'd looked at a ton of syncing options and none of them, including Microsoft's, were up to the task. I loved the idea of Live Sync (then Live Mesh) but it just didn't work well in the beta.
Sharing your dotfiles. I really need to go back and reorganize all my .bash_profile stuff. Maybe that'll be a good way to get a few more scripting posts up here.
Problems with Google adsense. Customer relations have long been Google's achilles heel. For most of their services there is no one you can call to even get a simple answer as to what is wrong, let alone fix it. When cell carriers are a huge step up in customer service you know there's something wrong.
1/3 of AT&T iPhone 4 users would leave to Verizon if given a chance. I bet they say that because they didn't look at the early termination fees and having to buy a new phone. That said I hope Apple goes Verizon if only to make the network better for the rest of us who stay. (For the record - no trouble with my iPhone 4. Some places it's better and some places worse.)
.jpg)
Tips for Writing Scripts
As you may have noticed a great number of my posts are simply scripts with a bit of explanation. I thought it would be useful to outline my philosophy of scripting. I’ve found these general tips to really make things considerably more useful and hope they help you.
1. Consider scripting an interactive process. Unless you are writing workflow scripts for other people don’t worry about making everything perfect. Rather write scripts so you can easily customize for any new task at hand. That is don’t worry about the polish and to a point look to customizing the code rather than putting a generalize UI in them. A big mistake people make (IMO) is putting too much error checking, prompts or the like in their scripts. A script should be focused on the problem at hand and not the general case. I also find that 90% of my scripts I simply run out of TextMate since they are one off scripts. By running them interactively I can quickly customize them to the problem at hand.
2. Make your scripts easy to customize. This is a natural corollary to (1). Consider your script to be like a toolbox. Make it so you can quickly leverage it to a new task. This means making sure you break things down into neat functions you can move to new scripts. It means making sure you write it so it’ll work from the command line, from a script menu, or as included by an other script.
Despite being a corollary of (1) this principle ends up being in tension with (1). That’s because you’ll always have to decide whether to write just enough for the task and hand versus writing enough that you can more easily leverage later. Usually I have two methods I use. I first try to guess what other tasks I’d be using it for in the near future and prepare. But no more. For error checking I put in a reasonable amount and then just run the script against my sample data. When it hits a problem I add in more error checking.
3. Organize your scripts. You can organize by task, by application or whatever. Personally I have in my ~/script several subfolders labelled iTunes, Address, Excel, etc. I also have a few project directors such as ‘shipping scripts.’ This makes it quite easy to find your script but also to include functions from other scripts (if you are using Python) For frequently used functions, consider breaking them out of individual scripts and placing them in modules you include. This allows you to improve all your scripts as you run them (say with increased error checking)
4. Leverage macros and Automator. With Automator you can use your script to either do some pre or post processing of automator workflows. But with Snow Leopard Apple allowed Automator to generate services. These services pop up in the service menu and are a fantastic way to call scripts, to pass data to scripts and so forth. The only downside I’ve found to Automator Services is that they are quite slow. I also heartily recommend using a macro program like iKey, Quickkeys or the like. You can call scripts immediately by some command key or function key. These programs also often let you have custom menus that are much faster than the service menu. Finally many applications like iTunes have a Script menu. This won’t allow you to call Python scripts, sadly, but it is trivial to create an Applescript that calls a Python script. When scripts are easy to call you are more likely to use them.
5. Use logging. Often scripts work through a lot of data or run in the background. Writing logs so you can check to see what your scripts are doing is essential. I’ve discussed doing this with Python in the past.
6. Use intermediate steps. There’s sometimes too much of an inclination to have everything done by a single script. I’ve found that writing data to an intermediate storage such as a Numbers or Excel document is extremely helpful. That way you have one script to generate the spreadsheet, you then look through the spreadsheet deleting anything you don’t like, and then use a third script to finish the job.
For instance I was recently working on a script that was sending out some samples to many clients. I had a script that generated mailing information for all our clients. I then went through the list and removed clients that didn’t need samples. Then I ran the script that printed FedEx labels for each. Trying to achieve that with a single script would have been ridiculous. Either I’d have to carefully select the clients in Address Book or I’d have to put a slew of if statements in the code. Sometimes manual manipulation is ideal and you have to keep that in mind when scripting.
Related posts:
This entry was posted on 2009/10/07, 2:24 pm and is filed under Applescript, Automation, Commentary. You can follow any responses to this entry through RSS 2.0. Both comments and pings are currently closed.