Nov 11

Applescript to open Mail.app and attach a zip

Every once in a while, while you're working on something, you find that all the available solutions to a task are horrendously out of date. After bashing my head against the problem, I eventually figured out the recipe that made things work, so I thought I'd post the solution here.

I was attempting to streamline the process of iterating on localization files. Being a member of the Engineering team, we wanted to make this as turn-key as possible on our end. The Localization team actually coordinates between several external contractors, who don't have access to our git repositories. 

I knew I could construct a mailto: URL but that didn't have a clear way to attach files to the body of the e-mail. Being that our primary development computers are all running Mac OSX I figured Applescript would be the solution. I scoured the internet for solutions and it turned out that no sample code out there actually still worked for the problem at hand. Eventually I glued things together based on sample code from Apple and bits of several hints around the internet.

Most of the other e-mail applescripts I've seen fail to work on Leopard and all failed to fully work on Lion, so here is my sample code:



subject_stub="Daily Zip for files"

pathToZip= "build/DailyZip_"

/usr/bin/osascript <<-EOT

set cwd to "$cwd"

set {year:y, month:m, day:d} to (current date)
set datestr to y &"-" & (m*1) &"-" & d

set zipPath to cwd &"/$pathToZip" & datestr & ".zip"
log zipPath
set targetFilesPath to cwd & "/$folderToZip"
do shell script "zip -r -j " & zipPath & " " & targetFilesPath & ""

set att to POSIX file zipPath as alias
--set att to choose file
using terms from application "Mail"
	tell application "Mail"
		set m to make new outgoing message with properties {subject:"$subject_stub" & datestr, visible:true}
		tell m
			make new to recipient at end of to recipients with properties {address:"$target_address"}
		end tell
		tell content of m
			make new attachment with properties {file name:att} at before first paragraph
		end tell
		(* Commented out so it doesn't auto-send the e-mail
		tell m to send
	end tell
end using terms from

Jan 11

Python Egg Uninstall

Note to self:

sudo easy_install -m EGG_NAME

Will attempt to remove the installed egg.

Sep 10

The Collective

This is a draft idea that I wrote about a while ago, and I figured I might as well publish it since I don't have much time to flesh it out these days.

What is the Collective?

The collective is a distributed trust system for giving/receiving/trading access to shareable resources such as on-the-go wireless access. Businesses will be able to provide an integrated Collective node instead of or in addition to standard Wifi. People will be able to roam and instantly have their devices pick the most appropriate collective node to communicate with. The Collective would punish poorly performing service providers and each location's trust metric would rise and fall as clients are happy or unhappy with them. The better a particular client's ratio, the higher priority it's requests are and the lower latency it has. There would be queues for several buckets of users depending on the capacity of the device, and the accessing client would be tossed into the bucket most appropriate to their respect level. If you have an industrial accesspoint then you might have 10 buckets of users with their own priority, while a home wifi network might only need 2 buckets. Every human user would have the ability to link multiple devices and have them all access through their account, some of these devices would also be providers and not just consumers. Your car's computer might get licensed under your account, and you could set it to only contact the web through your providers, or you could set it to get the web through any available access points while billing its access against your overall trust level. 

How does it work?

In provider mode, your laptop might be set to rebroadcast unauthenticated web access under your own collective account. Say 4 users are plugged in to wired internet in a room. Their laptops would all broadcast they are providing "collective" service. A 5th user would walk into the room and with a pod style device (no cellphone internet) and the 5th user would try to get online. Their pod device would listen to the collective broadcast beacon. This would be a shared service provided by all the laptops, and each laptop would take turns broadcasting the main part of the beacon message. This beacon message would attempt to inform the pod device of all local collective providers. Each provider would also broadcast a ping containing an NTP timestamp immediately after they receive the beacon message. This would allow the pod device to make a decision as to it's proximity to each provider. The timestamp would allow the pod to separate the distance between provider B and beacon broadcaster (provider A) from the distance between the pod and broadcaster B. It would then attempt to satisfy its own internet request through the collective in order of proximity. Each provider that succeeds would get credit on a sliding scale based on the latency of the whole request, and the amount of data of the request. Each client would be *charged* a certain amount of credit. This both encourages the user to broadcast Collective access points when they can, and it helps give priority access to users who use less sparingly. Every day a user would automatically gain a small amount of credit. Additionally users would be able to subscribe to the Collective and the amount of their subscription would increase their daily allotment. Providers could be jointly owned between multiple users (example: shared wifi in an apartment). Every provider in an apartment building would be a shared web zone and any device could roam among all the Collective providers.

Jul 10



Turns out I had to do some further tweaking for my subdomain plugin. Unfortunately, my subdomain code didn't originally handle the redirect_canonical filter provided by WordPress. This was originally no big problem, until I tried to create a subdomain for all posts tagged with a particular tag. (In this case dev.fbartho.com which presents all posts tagged with "Development").

Implementing the redirect_canonical filter hook in my plugin was a little tricky because by the time it is called I had already destroyed the original request URI and thus my ability to detect what the unmodified page url was at that time. Thankfully, all it took once I understood the problem was to store that in a global before I modified it, and then read that global back at the appropriate time in redirect_canonical


Today I also added the CKEditor plugin for WordPress. My first impressions of it are that it works very well. In most situations it seems pretty polished. It has a good number of toolbar buttons, without them being overly crowded, and you get to customize their appearance. Minor niggle: there isn't a <code> button, but I think I'll be able to add that with a quick little change.

Screenshot of CKEditor in WordPress in a Fluid Site Specific BrowserTwo features I recommend you use: there's a "Fullscreen" button and a "Show Blocks" button. The show blocks button gives you little grey rectangles around the major semantic elements and that lets you get a good feel for where your insertion point is located and what the editor is actually doing under the hood.  As for the fullscreen option, obviously that's self explanatory, but if you put that together with a Fluid-generated site specific browser for your blog, and the experience you get is that of a dedicated word-processor for your blog entries.

My one caveat is that, to my supreme disappointment, CKEditor completely fails to load on iPad. I have no idea why yet, but the editor simply flickers out of existence and you're left with the simplest and dumbest of editor experience. (It doesn't even let WordPress' original editor reappear)

I'll see how things go, but moving forwards, for desktop publishing, I may primarily use CKEditor within my Fluid Journal app. However, I really wish I had a more mobile editor that works well. Any recommendations?

Jun 10

Triumph at last! WordPress & subdomains do go together

I finally decided to do something about the abysmal visual quality of my site in recent times, but I definitely didn't want to compromise on complexity. Sometime in college, I started taking to heart the idea that it is rarely worth doing something, unless you plan to do it well. There is a modifier on that however: you need to define what *well* means for yourself. I had always held the opinion that my website was primarily for experimenting with new technologies or learning new things; having a visually interesting website was of distinct lesser importance. After I was in the job market this last I was informed — to my surprise — that my resume had been found via my own website more than through any other means. I cringed when I heard. Apparently, the visual effect of my site has become more important to me.

Back in the day I setup a WordPress and a Movable Type blog just to see how they worked, and over the past year I noticed enough respectable WordPress blogs that I decided to go with that option. Bringing back the point about needing my endeavors to be technically interesting, I decided to put a twist on my setup: I would attempt to integrate my full control of subdomains into the same WP installation. Little did I know quite how challenging that would prove to be.

The first obstacle I ran into was that WordPress 3.0 had just landed, and that meant that many plugins, and a few of the themes I tried weren't fully compatible. Not a big deal, I dove right in and started learning about the WP API and the types of things that broke from 2.8; A couple patches here and there and next thing you know the core pieces were working.

The basics resolved, I attempted to find a plugin that would do what I wished for subdomain management. No dice, though one plugin did stand out as being from the same family, and I was able to learn a bit from how it was structured.

Obvious next step? Start to a custom plugin to do what I wanted.

Key things I ended up learning much about:

  • Use 302 redirects instead of 301 while debugging.
    I lost some time attempting various (still flawed) solutions just to find that my webbrowsers had cached the 301 as the Permanent redirect that it is.
  • add_action()/add_filter()

    Crucially important, these are how your plugin gets the ability to override and inject data throughout the WP data flow. Basically there are a ton of keywords that WordPress broadcasts to at certain steps in it's life. This is effectively an observer pattern. In many cases WordPress will pass in its initialized array of data, and then ask all observers if they think it's correct. These observers include components across the system many of which might be plugins. These plugins have the option to remove or inject data based on their own logic, before the results are passed along to the next observer in the chain. Finally the potentially modified data is handed back to WordPress which then uses it.

  • Permalinks and URL rewriting

    I spent much too long learning how WordPress works in this case. Basically, there is exactly one initial entrance point to WP for everything of relevance to normal operation. The URL rewriting rules in the .htaccess just reformat the URL such that it passes data into index.php Further URL matching also happens at runtime in WP_Rewrite. I tried and I tried to figure out supplemental mod_rewrite rules to help create the subdomain effect I wished and had absolutely no luck. I tried to hook in to the additional rewrite rules and those were even more of a headache than mod_rewrite!

  • K.I.S.S.

    As usual, this principle seems to be a good guide. With every attempt frustrating and each subsequent attempt becoming more and more convoluted I eventually spent some serious time examining the flow of data in WordPress. I finally determined that the crucial datasource used to disambiguate which page to load is $_SERVER['REQUEST_URI']. And with that realization came final success. Discarding the evolutionarily created mess and substituting one quick little method added in the plugin's startup, and Tahdah! Pretty permalink urls with subdomains in use, for every subdomain I care to map in my standard WP admin console.

After spending over a day frustrated on this problem, I'm elated to have solved it and I needed to write my first post. From my iPad no less!

PS. WordPress for iPad (the app) is extremely flaky, I typed my whole post in it and then it completely fails to actually submit the post (no error message) Additionally, until reboot, copy paste was broken in it so it looked like this post would be lost. Eventually, extracted, this post was published via the web admin console's raw HTML editor. Any recommendations for a better client? For the desktop it looks like I'll be using ScribeFire embedded in Safari unless someone has something better?