When we originally migrated from PHP to Python, the offering of foursquare Python libraries was really lacking in terms of polish. So rather than bitch about it, we rolled our own. The goal was simple, Pythonic, and following the official API one-to-one. Full unit tests can't hurt either.

Naveen and the foursquare crew have been great to us as developers, so we'd like to give back by releasing our library. Check it out if you'd like a nicely-maintained foursquare Python library. As of this blog post I think it's the only up-to-date one that I could find.

The source is at https://github.com/mLewisLogic/foursquare

It's new, but it's already being used in a few projects, some in production. Let me know if there are improvements you'd like to see in it.

How? The gist is to keep your records in an array that you atomically push to.

MongoDB's documentation (http://www.mongodb.org/display/DOCS/Updating#Updating-%24push) should get you started on understanding how atomics work. Whenever you get a new event/activity that needs logging, just $push it to your array for storage or later processing. Make sure you set safe=False for whatever Mongo driver you're using. That will let it be done asynchronously, mostly eliminating the front-end cost of the operation.

Note: Mongo's $push operation can get pretty slow on really large lists, so take that into consideration.

I'm sorry, but you've lost an alpha-geek customer today.

I remember back in college having a motherboard and memory die within a week of getting installed. You had replacements in the mail the next day, before I'd even sent back the bad ones.

I've had hard drives arrive DOA, and every time you've fixed the problem immediately.

Power supplies prematurely dying? Check! Always an easy-to-handle RMA process.

Today, after being dragged around by UPS for two weeks, who finally ended up losing my package (no surprise from them), I went to your customer service chat expecting my problems to disappear. Instead, what I got was being told that a replacement could be shipped in 7-10 days once your claim was processed by UPS. Really? That's your solution to a pissed-off customer who has been waiting for 2 weeks on hard-drives to repair a failed RAID array?

When threatened with a charge reversal, you retreated to "you should re-place the order and ask for a refund, which should process in 7-10 days". Don't mind the $40 more that same order would cost to place now. After pressing on that, and being put on hold for 10 minutes, I'm told they would credit me the difference, in a tone that made it seem like I was being done a huge favor. Don't mind the $50 gift certificate that now gets refunded and I'm unable to use for this purchase and the extra $300 on my credit card. How does creating more of an inconvenience for me help anybody? All I wanted was for my original order to be fulfilled. Don't make your problem with UPS into mine. I'm already pissed off enough at them.

Icing on the cake? 500 character limit on their feedback form post-chat. Really? You're actively trying to discourage your customers from giving feedback?

What happened to the Newegg I used to love? I really feel like the heart and soul is dead. Customer service reads off of a script and is un-empowered to actually fix any problems.

I may still purchase here and there if you have the best price, but the loyalty is gone, along with a willingness to pay a premium for better service. Anything I would have blindly put in my cart will now get price-checked on Amazon first.

I'm sorry, but I've dropped ~$10k through Newegg since '03, and have been a vocal fanboy to anybody needing computer gear. That enthusiasm died today. This isn't a letter I write to every company that gives me crappy service or disappoints me. This one actually sucks to write because I feel like I've lost my "home" on the internet for computer gear. You guys need to get your shit together, or somebody's going to come along, treat their customers right, and steal your lunch.

All the best,

Mike

P.S. This isn't written in anger due to some perceived injustice or atrocious customer service. Their policies are not the worst that's out there. It's more sad that a bastion of great online customer service has given way to mediocrity and lackluster soul. Here's to jumping the shark.

1. Install the dependencies needed for the PIL library, using aptitude. This installs everything but PIL itself.

sudo apt-get build-dep python-imaging

2. Install the python-dev package so that we can compile PIL.

sudo apt-get install python-dev

3. Make sure that PIL's setup.py can find JPEG/ZLIB, by supplying a settings override file. Ubuntu installs these libs in a non-standard place, so we need to let the package's installer know where to find them. Create a file named setup_site.py in the root of your virtualenv (or somewhere in your path) with the following contents:

JPEG_ROOT = ('/usr/lib/i386-linux-gnu/', '/usr/lib/x86_64-linux-gnu/')

ZLIB_ROOT = ('/usr/lib/i386-linux-gnu/', '/usr/lib/x86_64-linux-gnu/')

FREETYPE_ROOT = ('/usr/lib/i386-linux-gnu/', '/usr/lib/x86_64-linux-gnu/')

4. From the root of your virtualenv (with it activated) run:

pip install PIL

That's it! If you run into any problems on Ubuntu 11.04+, leave a comment and I'll try to update the post accordingly.

Over the last decade of developing, I've noticed two major schools of thought when it comes to software development. They're really two ends of a spectrum, and most developers fit somewhere on that line between them. The extremes of the spectrum are the Hacker, and the Architect. I won't argue that one is better or "right", but each lend themselves to very different situations.

Hackers focus on a visible end-result, and obtaining it as simply and quickly as possible. They are fast to cast off any baggage that slows them down, and build their software "just in time." A common mentality is "I'll build it when I need it". If it would take them 3 hours to hack a solution together, and 5 hours to integrate a 3rd party library, they'll opt to build it themselves. They concern themselves with "time to market" and are adept at cranking out working prototypes within hours or days.

Architects focus on beautiful, robust software that is elegantly constructed and flexible to future changes. They will often delay the immediate gratification of an early ship in order to get the technology "right". They pride themselves in their focus on systems engineering. Characterized by a fear of technical debt, architects can be known to bring a touch of OCD to their work. A common mentality is "If we do it right now, we won't have to gut it later". They always plan for the long term, even if it takes more time in the near-term. They concern themselves with "overall cost of ownership."

Obviously, each school has its pros and cons, which suit themselves better to different scenarios. Are you most concerned with immediate delivery (at the expense of long-term cost)? If so, you need a hacker. Is reliability, security, or stability a concern? Get yourself an architect.

Details & apply: http://bit.ly/kM9hoX

""""""""""

NextNY presents the NYC Tech Mentorship Program, in collaboration with General Assembly. It is connecting a select group of smart developers with top startup leaders serving as mentors. The goal of the program is to help high-potential techies reach into the startup world through advice, mentorship, and the wisdom of tech leaders who have been in their shoes. It will be an opportunity for developers to ask questions relevant to their goals and situations, and get personal feedback from industry vets.

How it works:

• Each mentor gets paired with one or two developers
• Each mentor and their mentees meet once a month from May-August
• Meeting is over lunch or coffee, and we'll leave it to each group to pick time/place

Requirements:

• You are a bona-fide techie. You have a degree in CS or have worked as a developer professionally.
• You're looking to get involved (or more involved) in the tech startup world.
• The program is free, but we ask that you pay for your mentor's coffee or lunch as a thank-you.

The mentors:

• Andrew Kortina, Venmo (twitter.com/kortina)
• Carter Cleveland, Art.sy (twitter.com/carterac)
• Chris Maguire, Postling (twitter.com/revolvingdork)
• Dana Spiegel, AxialMarket (twitter.com/danaspiegel)
• Dmitri Tcherevik, MightyMeeting (twitter.com/cherevik)
• Eliot Horowitz, 10gen (twitter.com/eliothorowitz)
• Kevin Owocki, Ignighter (twitter.com/owocki)
• Liz Crawford, Birchbox (twitter.com/liscrawford)
• Mike Lewis, SpotOn (twitter.com/mlewislogic)
• Naveen Selvadurai, foursquare (twitter.com/naveen)
• Nick Ganju, ZocDoc (twitter.com/nganju)
• Pete Miron, Knewton (twitter.com/petemiron)
• Simon Murtha-Smith, Singly (twitter.com/smurthasmith)
• Vanessa Hurst, Paperless Post (twitter.com/dbness)

Deadline is midnight May 11, EST.

Tweeting "Apply for the NYC Tech Mentorship program by May 8th http://bit.ly/kM9hoX" might get you bonus points.

""""""""""

Up until recently, I was the solo founder of eventLo, a recommendation engine for upcoming social events. I even wrote a post about some of my experiences as a solo founder. About a month ago, that changed, as I merged eventLo into SpotOn. Here's how it happened, and some reflection on the last month.

I was chatting with Charlie O. back in September when I first heard about SpotOn. He mentioned that their CEO, Gauri Manglik, was deeply passionate about the space. He also seemed worried that the space was a bit crowded, but I wouldn't let that deter me. I was on a warpath with eventLo, and wouldn't be scared off.

Over the next few months, I heard about SpotOn through several friends in the tech scene. It was probably my closest competitor and most buzzed about startup in the 'local' space. I was interested, but wary.

Back in early January, things changed. My friend Zach had met Gauri at a local tech event and mentioned the connection. Apparently she had been hearing about eventLo for a while as well. Zach suggested we meet and arranged a lunch.

Over several lunches throughout January, Gauri and I met, chatting about our visions for the space. It was easy to open up to each other because our products were adjacent, but not overlapping from a product perspective. From a business perspective however, we were on a collision course.

It really wasn't too long before our talks were getting serious. Tech infrastructure, team makeup, business direction, funding objectives. We knew where it was heading, but were still both just dabbling our toes in the water. As we got more comfortable we really started opening up, and finally, like a dating couple, the question was out there. "Are we talking about combining forces?"

The coming weeks were filled with rapid due-diligence. Team introductions, tech shares, planning meetings, co-working sessions. We confirmed that we all worked complementary to each other, and agreed to join up. Cap tables with Gauri and Orion, investor meetings, and finally an annoucement at the Hoboken Tech Meetup.

So, what changed on my end? A lot of things, but the biggest was a realization that when complementary skill-sets combine, the result is far more than a sum of the parts. Seems obvious, but it was hard to internalize until I felt that intense sense of collaboration in those early meetings. The early lunches set the tone for what was possible, and reminded me that the best way to delegate is to give up control to people more expert than yourself. At this point in my life, I'm a better CTO than a CEO, and Gauri is a better CEO than I am. Focusing on technology and product is how I am most effective, and I've come to truly embrace that. In a lot of ways, Gauri handling CEO responsibilities frees me up to do what I do best, which is building great tech products with a solid team.

Through this entire experience, I've learned a lot about myself. The biggest is that I don't want to be a solo founder at this point in my life. Building a business is much more than building a tech product, which is what I'd like to focus on right now. Now, I've got a killer, well-rounded team and driven partners. We push each other, which really gets you through the slow days. The shared passion is an unbounded source of energy, and every idea gets rapidly iterated and improved upon as soon as it's uttered. This team is lightning-dynamite-laserbeams, and the potential is mind-blowing.

If I had the chance, I wouldn't go back and change anything because I've learned so much. On the other hand, I now understand that finding the right founding team should have been priority #1, and done before I ever wrote a line of code (it's easy to let product take up all of your founder-search time). Another reason is because once I started building eventLo and called myself CEO/Founder, it erected a wall between myself and potential co-founders. The whole time I was thinking "the more I build, the more control I'll have long-run." I should have embraced the possibility of giving comparable equity to passionate partners who would have added gasoline to the fire.

To the founders and aspiring founders out there: I'm not suggesting you avoid solo founding, but be aware of who you are personally. Having the right team is invaluable, and brings with it more than just skills and another set of hands. Solo founding is emotionally tough and will push your limits, but it is also a self-learning experience unlike anything I've ever experienced.

However big your captain's table, keep strong and carry on.

Rather than let this post turn into a rant, however, it spurred a lot of personal thought about user experience. In my mind, UX is the interface by which users and customers interact with your company. This interface covers many different fronts: product, policies, support, tone, etc. There are a million UX design tactics to employ, but I like to think about it holistically.

UX is the interpretation layer between customers and the insiders in your company.

The closer your internal view is to the external view, the more users will trust you, and the more fulfilling your company will be to be a part of. Letting the marketing message diverge from the internal attitude is a slippery slope towards becoming faceless. Customers naturally gravitate towards offerings that have soul, and cultures that they can relate to.

This is by no means an academic list, but here are a few things that I like to keep prominent when considering UX decisions.

1. There's always a competitor. No matter how great you feel your product is, there are 20 other things competing for your users' attention. Treat them with respect and go the extra mile. Win their hearts with honest dialog and transparency. Give them reasons to become a believer.
2. People talk. Whether good or bad, people share news. Give them something good to talk about. Friends don't forward press releases to each other, but they do share great new tools, first-rate experiences, and good surprises. If you can make an experience special or personalized to a user, you're going to have a huge leg up over companies that assume all of their customers are the same.
3. Rich enough for power users, easy enough my parents can use it. Granted my parents are pretty tech-savy, but that's not the point. UI matters, and is an important component to UX. Trim the fat, then trim it again. 5-star restaurants don't worry about the trimmings they throw away, because their goal is to be breath-taking, not the cheapest.
4. Build for your target market. Don't be afraid to change the world, but make sure it has context. Think Google Search vs. Google Buzz. Both were technological breakthroughs, but only search served a burning need and played into a context people were comfortable with ("How do I find things on the web?"). Buzz may have been useful to people willing to make the leap, but without filling a compelling need, it was just a blip on the tech world's radar.

I was looking for a 5th point to round it out, but that would be disingenuous. There are plenty of tenants to building a great UX, but these are the ones that I focus on. Hopefully they're helpful.

Finally, I'd like to thank Charlie O'Donnell and the nextNY crew for selecting myself, Alexis Goldstein, James Swetnam, Danielle Banks, Michael Horn, Lindsay Kaplan, Alexander Taub, and Emily Miethner as nextNY Fellows. There will be some pretty interesting stuff coming up related to the program, so stay tuned.

My biggest take-away from the experience is the catharsis you feel when you strip away dead code. Entire packages were re-done to do more with less. Less code. Less edge cases. Less rigid models. Less architecture. Less dependencies.

When I look at the code-base now, it almost seems trivial, but it's important to remember that this sort of simplicity didn't happen overnight. It took a thorough understanding of the problem domain to architect this simpler solution. That sort of understanding just can't come around in pre-production design sessions. The most thorough understanding almost always comes from paying your dues in the trench.

Making art is easy. Making it beautiful is an art.

At the end of November, the first public alpha of eventLo was launched. We're holding back on any marketing or PR at the moment, until a few key issues are sorted. As it stands, the site actually looks quite vanilla, but there's a lot more going on than meets the eye. I'm likening the current site to that of an iceberg, where 90% of it's mass is below the surface. Expect to see that power wielded in the near future.

Over the month of January, we'll be hitting on several initiatives, including product improvements, market validation, and a heavy refinement process. I'm thrilled with how much we've accomplished in such a short period of time. The beautiful thing about having invested time in infrastructure and architecture is that future development, iterations, and improvements can be implemented at breakneck speed, without a rickety and patchy framework to hold it back.

I'll be keeping the eventLo blog up to date on eventLo issues. That frees up CleverKoala to once again focus on tech industry commentary and the life of a startup technologist.

Over this next year, I'll be focusing a lot of the writing on my emergence from a software focus to a broader tech industry focus. Still expect the nerdy how-tos and tech-heavy details, but much of it will be coming from a broader perspective. As my responsibilities have grown, so to has the perch from which I see my surroundings.

New Year's resolution: learn to sell, responsibly