Archive for category Python
Displaying a SalesForce Contact’s Emails in Mail
Posted by clark in Applescript, Automation, Mail, Python, SalesForce on 2010/02/23
SalesForce has a nice way of keeping track of emails from within SalesForce. But it tends to presume you do all your emailing from within Salesforce or use a program (like Maildrop) to sync your email from Apple’s Mail with SalesForce. This really isn’t terribly convenient. I do all my emailing from within Mail itself.
When I’m looking at a lead or contact though it would be nice to see a list of all our emails back and forth at a glance. The following script does that by creating a smart mailbox for the email address of the currently viewed lead or contact.
While I wrote this to access SalesForce it would be trivial to modify this to use a different source, such as Address Book.
Address Book to Sales Force
Posted by clark in Address Book, Applescript, Automation, Python, SalesForce on 2010/02/06
Here’s an other little script I wrote for using SalesForce.com. We take the selected contacts in Address Book, open up a new contact entry in SalesForce and then fill in the data. Now I could have made this a bit more advanced, copying in all the emails, addresses, phone numbers and so forth that are possible. But I rarely use those. So I can handle copying and pasting those or just modifying the script if they become more common.
Once again Apple’s optional develop menu in Safari is invaluable. I used to do all this with plugins for FireFox but I now actually prefer analyzing web pages in Safari. All you have to do is find the form name and then the id of the field you want to fill in. You then use JavaScript in Safari to set the value like this:
Safari.do_JavaScript("document.forms['form_name']['field_id'].value = \"" + myvalue + "\"", in_=FEdoc)
I’ve used this technique a lot in various scripts. So long as there aren’t logic bugs on the page (i.e. using an identical id multiple times) this approach works fantastic and is a rapid way to fill in forms.
SalesForce to FedEx
Posted by clark in Applescript, Automation, Automator, Python, SalesForce on 2010/02/06
A lot of my scripts are designed to make shipping easier. I usually use FedEx for my shipping and have discussed in the past filling out the packing forms in Safari in an automated way. I don’t know about you, but this saves me a lot of time. I’ve been using SalesForce a lot of late and one thing I do frequently is ship samples to leads or to existing contacts. Since I don’t (yet) have a safe syncing between my leads and Address Book I wanted a way to use a Service to print a FedEx packing slip for the displayed contact or lead.
This script makes a few assumptions. First it assumes you are logged into FedEx. (If you have an open window in Safari somewhere that’s sufficient) It then assumes the front window is your SalesForce window. It does check to ensure you are in a detail. If you’re not then it doesn’t do anything.
Using Python to Cleanup Excel
Posted by clark in Productivity, Python, iWork on 2010/01/21
Often you get a spreadsheet with some data that needs heavily filtered. You could try Applescript but let’s be honest. For text processing Python is so much easier. So here’s a Python script I use a lot with Excel. It’s pretty flexible following my scripting rules. It’s designed to be more a template that I then modify when the need arises.
First the code and then the comments.
Count Your iPhone App Usage
Over at an Ars forum post someone pointed out that there were some files keeping track of how many times your iPhone applications were run. These were crash reports and there are a lot of them.
I should note up front that I’m real skeptical that these are terribly accurate figures. But I’m not an iPhone programmer so I haven’t read anything about these crash reports. I do know the counts for the main built in applications (Mail & Safari) are almost certainly wrong.
If you go into “~/Library/Logs/CrashReporter/MobileDevice” there will be a directory for each iPhone or Touch you’ve synced with iTunes. In each of those directories are a bunch of crash files plus a few others. A few are called aggregate plus the date of the crash. Inside these files are a bunch of XML including a key that is the crash count for each application.
Scripting GrandTotal Part 2
Posted by clark in Automation, GrandTotal, Python on 2009/11/06
OK, last time I introduced how to access the database of GrandTotal. Half the fun is figuring out how the author put together his database. I have to say that some of it isn’t how I’d have done it, but thus far it hasn’t been too hard to figure out. The author put in his invoice item tables rows that identify an invoice as a whole and then other rows that are the items in the invoice. I think that would have been cleaner and easier to have two separate tables. It’d certainly have made the SQL easier.
To demonstrate getting data out I wrote a small program that goes through all the clients, finds the invoices for each, and then searches through the items in each invoice summing up the invoice total.
Now this wasn’t an exercise. I actually had a need to do this but exclude certain types of fees. My invoices contain the items I ship and then shipping charges. However if I’m trying to figure out profits I can’t include shipping since I don’t make any money on shipping. You might not have this particular need, but I think it demonstrates the principle of how to utilize a script in a helpful way.
Scripting GrandTotal Part 1
Posted by clark in Automation, GrandTotal, Python on 2009/11/06
GrandTotal is my invoicing program of choice. I’ve used quite a few others but this is my favorite. For one the developer is very quick about feedback. For an other, it uses a lot of open standards that makes it easy to expand the program’s weaknesses.
There are a lot of reasons why you’d want to script GrandTotal. (Sadly it doesn’t support Applescript – so there’s a lot more I’d like to script but can’t – but it’s more open than the other programs I’ve tried) One problem I have is that the program doesn’t do a lot of analysis reports. It’s great for generating invoices. Not terribly good for things like Aged Reports or client summation reports.
My first job out of college was doing IT for a multimillion dollar company. (I was the entire IT department and handled more of the accounting than I expected) Half of what I did was hack into their accounting program to create custom data and reports using PowerBuilder, FoxPro, Access and Excel. Effectively that’s what I’m doing here with GrandTotal and Python. But it’s quite easy.
Over the next few posts I’ll show how to figure out the database structure, how to get data from the database, on up to doing some simple reports.
Proximity Address Search Script Revisited
Posted by clark in Address Book, Applescript, Automation, Python on 2009/10/17
OK. This is an update to a script I wrote back in July. It scans through your Address Book returning all addresses within a certain distance of a specified location. It’s very useful if you have people ask if you have distributors for your product nearby where they live. But there are lots of other uses – say looking up clients who are nearby.
I’m putting it up partially because I’ve been too busy to write a lot of new scripts and partially because I made a lot of useful changes to it.
The original script did the job but had several negatives. First, it just printed the addresses in the order encountered. A lot of people requested that I send proximity searches sorted either alphabetically or by distance. Secondly I put a lot of “extras” into the scripts for when I need them. So I might want to print to screen or I might wish to end up in a Numbers spreadsheet.
Script New Document in Numbers
Posted by clark in Applescript, Automation, Python on 2009/10/17
OK, I can’t believe this was the case. And it almost was enough to send me back to scripting Excel. But I figure an update to iWork will be out within a couple of months. Inexplicably Apple provided no mechanism to create a new document in Numbers via scripting.
“What!?,” you say?
Yup. It’s true. I always knew scripting was crippled in Numbers but I’ve never had trouble actually putting data into a sheet. Normally I always have an already opened sheet I use. But when I tried to create one I discovered what many of you already knew. It just ain’t there.
Here’s the workaround.
Significant Digits
As a former physicist I’m kind of a stickler for significant digits. Nothing bugs me more than when you get all these decimal points in some published number that makes it look exact when you know it is anything but. Normally in physics you use error bars and significant digits to indicate that the number is far less certain than it appears. A few of my scripts, such as my old proximity address book script, committed the sin of reporting fairly inaccurate distances as detailed numbers.
Fortunately there’s an easy and simple way to fix this using Python’s string formatting. Without giving a lecture on Python’s expansion of C string formatting let me simply provide a function that does it for you. (Since you are probably like me and have to look up the string formatting every time)
I plan on using the below from now on.
.jpg)
Recent Comments