You can now pull in photos from your Facebook account. Right now, it grabs everything, but I have controls in the works to let you choose privacy settings or hide individual photos.
There’s pseudo realtime support, too. Proxigram should update basically as soon as you upload the photo.
As always, everything is on Github.
Quick update on Proxigram: it now supports Flickr, Yahoo’s popular photo sharing service. If you’re a Pro account holder, it will even get realtime updates from Flickr, just like Instagram provides.
The “point” of the app has changed, too. The goal is to build a single API endpoint for all of your photos. While the photos will still be hosted on their respective services, you can now get one read-only API to see a normalized view of them all.
The project is still open source, so if you’re looking for a sample node app that connects multiple third party services via oAuth (using passport.js), you can get the source on Github.
Facebook support is coming next. If you want support for your favorite photo services, please let me know what you want or, if you have the ability, submit pull requests with patches.
I’ve also written a few bits of supporting code for this. I abstracted out the basic PubSubHubbub verification calls into a standalone library: node-push-helper.
I also have stubbed out a new node Flickr client. I made a new one because I wanted to use oAuth instead of the deprecated Flickr authentication methods. After trying to retrofit one of the other libraries, I decided to just start over. I may merge this back into one of them, but for now, expect new functionality in the coming weeks. Here it is: node-flickr.
Would love code reviews and criticism from node experts. I know the code can be better.
As I just posted on the VarioLabs blog, we’re going to be shutting down the company over the next few weeks. My co-founder had to drop out because of a family issue and I’ve decided against trying to keep things running on my own. It just didn’t make sense for a number of reasons. You can read the details on the VarioLabs blog.
The next chapter is already getting written, so this isn’t all bad news. I’ve taken the last 3 weeks to unwind and work on fun projects like Proxigram. This week, I’ll be cleaning up The Storyline to be a little simpler and a little more useful in its current state.
After that, I’m happy to say, I’ll be rejoining Fanzter the following week as CTO. Fanzter has continued to grow since I left in 2008, and they’ve added a successful suite of iOS apps to their product portfolio. There’s a natural fit there for me.
While I had offers to start or join other startups and a solid freelancing pipeline, Fanzter made the most sense: they have real revenue, a platform that has proven extensible and flexible for a number of products, and people for whom I have a tremendous amount of respect. In the end, being with proven people and a proven platform with millions of eyeballs on it offers an opportunity to build the next great thing without starting completely from scratch.
Plus, after talking to Aaron a lot over the last few weeks, I’m convinced that the next product we’re planning is going to be awesome. It scratches an itch both of us have felt and has a clear business model. It comes down to execution, something Aaron, Josh and I are confident about.
It’s been an interesting journey to get here. I’ve learned a lot, met a lot of interesting people, and built something that I’m proud of. The Storyline is unfinished and raw but the guts are very interesting. I’m going to keep it running under Forche Software, though it will become much more of a side project.
Hopefully, at the end of next week, I’ll open the doors to everyone and remove the beta status once the cleanup is complete.
And keep an eye on Fanzter. The next 12 months should be legen — wait for it — dary.
I’m happy to share a little experiment I played with this week. I needed to take a look at Node.js & it’s family of technology for a project but found it hard to find good explanations of best practices, etc. There are a half-dozen competing boilerplate/template samples that have very little in the way of explanation or comments. So, I decided the best way to get familiar with the nitty gritty of building a Node/Express app was to write one.
I decided to solve a simple problem I had. I wanted to get my recent photos from Instagram onto my blog. I wanted it to be a simple JS call or plugin, and I wanted it to be smart about storing keys for read-only access to my Instagram account. It seemed like a simple proxy for the Instagram API would suffice. The OAuth credentials are stored on the proxy and a new, non-Instagram specific key gets embedded in the JS.
And thus, Proxigram was born.
Sure, it’s a little contrived, but now that I’ve built it, I’ve got ideas for some improvements and, even better, I now have a functional, real app to share with everyone so I can get feedback about all the things I did poorly.
The source code is all on Github, both for Proxigram itself as well as the jQuery Proxigram library to access it.
The app is interesting to look at on a few levels. The package.json listing the bits and pieces I used is below. The app talks to the Instagram API, obviously uses MongoDB to cache results local to the app. It keeps that cache fresh by using Instagram’s real-time API to get updates for users. It uses passport.js for authentication (though it seems like more of the cool kids are using everyauth these days). It uses less.js for the stylesheets.
So, if you need a working example for all of those things, here you go.
Please leave feedback about things that make you itch about the code. I know a bunch of you are serious Node.js mavens, so I’m really curious what you folks think and what conventions you’re following in your projects. My biggest question at this point is how to deal with making shared components available to code in different files. For example, I made some of the authentication filters global because I split my routes up into multiple “controller-ish” files. None of the boilerplate/template apps did it better, IMHO. If you have thoughts on that one, let me know.
PS. The images on the right are getting served through Proxigram. 
Here’s the dependency list from my package.json:
{
"name": "proxigram"
, "version": "0.1.0"
, "private": true
, "dependencies": {
"express": "2.5.8"
, "less-middleware": ">= 0.0.1"
, "jade": ">= 0.0.1"
, "moment": ">= 0.0.1"
, "passport": ">= 0.1.8"
, "passport-instagram": ">= 0.1.1"
, "passport-http-bearer": ">= 0.1.2"
, "mongoose": ">= 2.5.0"
, "connect": ">= 0.0.1 < 2"
, "connect-redis": ">= 1.0.0"
, "connect-heroku-redis": ">= 0.1.2"
, "airbrake" : ">=0.2.0"
, "instagram-node-lib": ">=0.0.7"
, "express-messages-bootstrap": "git://github.com/sujal/express-messages-bootstrap.git#bootstrap2.0"
}
, "engines": {
"node": "0.6.x"
, "npm": "1.1.x"
}
}
Another big speech in front of important people, another very pointed set of jokes. You should read the whole thing. Here was my favorite bit:
Of course, all of us should be honored to be listed on the TIME 100 alongside the two men who will be slugging it out in the fall: President Obama, and the man who would defeat him, David Koch.
…
I was particularly excited to meet David Koch earlier tonight because I have a Super PAC, Colbert Super PAC, and I am — thank you, thank you — and I am happy to announce Mr. Koch has pledged $5 million to my Super PAC. And the great thing is, thanks to federal election law, there’s no way for you to ever know whether that’s a joke.
By the way, if David Koch likes his waiter tonight, he will be your next congressman.
Zing.
If you’re a Rails developer, you probably have used Pow to simplify your development environment. Pow is a simple web proxy that makes it nicer to develop locally. For Rails (or any Rack environment), it will automatically start the service, map it to a clean domain, and proxy requests. For example, for The Storyline, I point at http://storylines.dev and it automatically starts up the server in dev mode if it isn’t running, and then sends requests along. The main advantage is that, if you follow conventions, you end up with an easy way to switch between dev & prod. Just change .com to .dev and you’re running off your dev box.
I use it for a lot of other projects, too. Right now, I took a day off to work on a Node.js project and used Pow to proxy off requests. For non-Rack apps, Pow simply acts like a simple web proxy. It won’t automatically start/stop your dev server.
This proxy support is buggy, however, and I’ve run into a few problems that I’ve had to fix. My fixes are at my fork of Pow. You can see all of the commits in this compare view. More details about the bugs themselves at the end of this post.
I also wanted to quickly document for posterity (and Google) how I run my dev copy of Pow. I want to have it written down so I don’t spend another morning re-learning this. The following notes assume you’ve used Pow before and are for people that want to develop features for or fix bugs in pow.
First, install the official version of Pow using the regular installer. Find the following files and copy them somewhere safe:
~/Library/LaunchAgents/cx.pow.powd.plist
/Library/LaunchDaemons/cx.pow.firewall.plist
/etc/resolver/dev
Next, check out the project locally. I almost always check out my own fork, then add remotes for the official repo and any other forks that have interesting commits so I can fetch and merge/cherry pick commits I want.
To run my own copy, I uninstall the official Pow install by using their uninstall script. Typically, this is something like curl get.pow.cx/uninstall.sh | sh at your terminal prompt.
Then, from your local copy of the project, use NPM to install the library on your system.
npm install -g
For me, that ended up with everything in /usr/local/lib/node_modules/pow with a symlink for the pow binary in /usr/local/bin.
Pow uses launchd to start/stop/restart the server, so the next step is recreating the various plists. Remember the files you copied earlier? Copy your saved copies back to where they belong.
Next, open up ~/Library/LauncgAgents/cx.pow.powd.plist in your favorite editor. Replace it with something like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>cx.pow.powd</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/node</string>
<string>/Users/sujal/code/thirdparty/pow/bin/pow</string>
</array>
<key>KeepAlive</key>
<true/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
The key bits are the ProgramArguments strings. The first should point to wherever your node executable lives. The second should point to where your pow script lives.
Then, you need to launchd to use those configs. Execute these commands at your terminal prompt:
sudo launchctl load /Library/LaunchDaemons/cx.pow.firewall.plist
launchctl load ~/Library/LaunchAgents/cx.pow.powd.plist
If you check for running node processes, you can just ps ax | grep node at the prompt to see if it’s running. You should see something like:
65965 ?? S 0:01.08 /usr/local/bin/node /Users/sujal/code/thirdparty/pow/bin/pow
The output should match whatever you put in for the arguments in the powd plist above.
Some details about the bugs I ran into (and fixed):
I’m using two non-Rails frameworks right now. I use Goliath.io for our API server on The Storyline. I’m using node.js & express.js for this 48 hour hacking break project.
In both cases, I have to use Pow’s simple HTTP proxy support to get it to talk to the dev instances. The two major issues I ran into had to do with cookies and redirect support.
For the Goliath app, I have optional cookie support for API clients that can support cookies and don’t want to muck with custom auth headers. This makes testing in the browser easier, for example. I found that cookies weren’t getting set when I connected through Pow but did work if I hit localhost directly. The bug had to do with how Pow was forwarding cookies. Cookie handling was just broken, so I fixed that.
The other issue I ran into had to do with redirects. My node.js app uses Passport.js for authentication. It seemed that all of the authentication redirects were getting swallowed by Pow. It manifested as a hung connection on the browser. The browser would just sit and spin, spin, spin. After 4 minutes (!), the connection would end and the browser would show an empty page. That’s fixed, too.
If you want to check out the bug fixes or have other concerns, you can see the commits here. Feel free to leave comments – I check my Github notifications regularly.
Where We Live ran a show today on why younger people (25-34) are leaving the state. I ended up missing the show (listening to it now!), but caught a very lively discussion on Twitter.
One side conversation (you can see it on storify here) that I joined in on was about how hard it is to convince people to move to CT.
Let’s be honest. It’s hard. Harder than it should be, quite honestly, considering how nice it is to live here. I had a lot of experience with this when I was hiring people at ESPN. Even with a kick ass company, a dream job for most sports fans, and great relocation packages, it was hard to convince people to move to CT. There are a lot of reasons, and they vary by person, but they all seemed to boil down to cost and opportunity.
For people moving from a relatively low cost-of-living area, like Kansas or Vermont or Nevada, it was mostly about cost. CT looks and feels expensive when you’re browsing real estate or rents even though we’re cheap-ish for the region. For whatever reason, cost-of-living adjustments never seemed to truly capture the difference people felt.
For people moving from a big city or high cost-of-living area, like New York City or Boston or San Francisco, it was mostly about opportunity. What if they didn’t like the job here? What job opportunities would they have at a similar style company? This was exaggerated in my particular industry. There aren’t many of the kind of companies that are doing consumer Internet or mobile products that ESPN makes. If you live in NYC or Boston or SF, on the other hand, you have dozens of options plus many, many strong startup and entrepreneurial companies nearby.
There are people working on the second issue (e.g. this effort). So I asked about the cost reason, specifically:
@wherewelive silly question: what programs incentivize people to move to area/city? I know we subsidize companies all the time.
— Sujal Shah (@sujal) April 19, 2012
As I mentioned, you can read the whole convo if you want, but that’s the main point.
CT just authorized $291 million in spending over 10 years to incentivize Jackson Labs to build a $1 billion facility here. Of that, $192 million is a loan that is entirely forgiven if the facility creates & retains 300 jobs in 10 years.
Now, I don’t know whether that’s a good program or not for 300 jobs, but like a lot of programs, the government seems to focus on giving money to companies rather than individuals. This isn’t bad per se, but the tradeoffs are worth talking about.
For one thing, this means that the government has to choose an industry or individual company to offer these incentives to. This doesn’t prevent existing companies from leaving, nor does it help them. That seems odd to me. But it’s also exceedingly common. Remember the brouhaha about Boeing moving it’s HQ?
Instead, I wonder if cities or states have considered incentivizing individuals to take existing jobs. For the same expenditure ($192 million over 10 years), the state could offer 5 year rent or property tax credits of $5,000 to over 7,500 families or individuals. $5,000 would cover over 100% of the median property tax for the state.
On the surface, that seems like a better use of taxpayer money. That assumes there are, of course, 7,500 jobs to fill in the state. Then again, more people moving here mean more people needing services and products. I suspect like any social network, virtual or real, there are network effects that come into play once you create some momentum.
Curious if anyone has seen studies or programs like this in the United States. I wonder how well they work, and what data we can glean from them.
If I were still single & not a parent, I would totally get big speakers, put them at the foot of my bed, turn them up, and set Glitch Mob’s remix of Seven Nation Army as my morning alarm song. Not only would I get shaken out of bed by the rumbling, I’d be pumped to face the challenges of the day.
Love this essay by Craig Mod, one of the key guys behind Flipboard for iPhone. Lots of neat nuggets in a reflection on the journey of getting Flipboard for iPhone out the door.
Abstractly, you can think about going from digital to physical as going from boundless to bounded. A space without implicit edges to one composed entirely of edges.
For a while now it had been clear to all of us that edges are a critical framing aid in helping us consume [1] but it wasn’t until last year — helping build Flipboard for iPhone — that I began to understand how critical they are to gain perspective on creation. To gain perspective on a journey captured in bits.
[1] It’s one reason, for example, it feels so good to scroll down to most e-mailed on nytimes.com — it’s bounded, doesn’t update much, and you feel like you can read it all.
The Storyline is about helping you find and set edges on your news consumption. I love this way of describing what we’re trying to do.
(via Daring Fireball)
Update: so much awesomeness in this essay:
Perhaps the next Carver’s manuscript will contain the entire typing history of the document including GPS data of where he was when he wrote it. We will be able to replay the entire composition process. Shadow, if you so desire, a particular Hemingway through a certain Spain as he writes a new The Sun Also Rises.
I was writing a method today that flexibly parses a “city, state” pair in order to see if The Storyline already covered the city or town in question.
In doing so, one of my test cases, “New York, NY” tripped a tiny, but annoying bug because the city name is the same as the state name. I didn’t expect that, but it got me thinking: are there other U.S. cities where the commonly accepted way to address an envelope results in the city being the same as the state name?
I don’t have a definitive answer, but in the GeoNames database of postal codes, which I have locally in a MongoDB database, I ran a query looking for place names that begin with the name of the state they’re in. The results are below.
Initial observation: only New York City is commonly written on envelopes without the “City.” Did I miss any?
Couple of caveats: this data is only as good as the GeoNames DB. Plus, it is based on zip code data, so if the place doesn’t rate it’s own zip, it might not be in the system. I’m open to other sources of data if you have suggestions.
Here’s the query result:
{
AL: [],
AK: [],
AS: [],
AZ: ["Arizona City"],
AR: ["Arkansas City"],
CA: ["California Hot Springs", "California City"],
CO: ["Colorado Springs", "Colorado City"],
CT: [],
DE: ["Delaware City"],
DC: [],
FM: [],
FL: [],
GA: [],
GU: [],
HI: ["Hawaii National Park"],
ID: ["Idaho Falls", "Idaho City"],
IL: ["Illinois City"],
IN: ["Indianapolis"],
IA: ["Iowa Falls", "Iowa City"],
KS: ["Kansas City"],
KY: [],
LA: [],
ME: [],
MH: [],
MD: ["Maryland Line"],
MA: [],
MI: ["Michigan Center"],
MN: ["Minnesota City", "Minnesota Lake"],
MS: ["Mississippi State"],
MO: ["Missouri City"],
MT: [],
NE: ["Nebraska City"],
NV: [],
NH: [],
NJ: [],
NM: [],
NY: ["New York City", "New York Mills"],
NC: [],
ND: [],
OH: ["Ohio City"],
OK: ["Oklahoma City"],
OR: ["Oregon City"],
PW: [],
PA: ["Pennsylvania Furnace"],
PR: [],
RI: [],
SC: [],
SD: [],
TN: ["Tennessee Ridge"],
TX: ["Texas City"],
UT: [],
VT: [],
VI: [],
VA: ["Virginia Beach"],
WA: [],
WV: [],
WI: ["Wisconsin Dells", "Wisconsin Rapids"],
WY: [],
}