Version 3.0
Instacast requires a new install for its 3.0 version, which currently is listed at $5. While I understand some circumstances may merit such a move, I would certainly expect some major update to merit a repurchase of the same app. Looking at the screenshots and product page, nothing looks significantly different. The iPhone UI looks exactly the same as before. But the thing that put me over the edge was this statement on their page:

We switched out old technologies like manual reference counting (like a stick shift) and SQLITE and removed them with automatic reference counting (like automatic gear shifting) and Core Data, the powerful object layer.

I’m calling bullshit on this.

The first set of changes (manual reference counting to auto) has nothing to do with performance, and the analogy is bad. The user won’t notice any difference, except if the old versions of the app use to crash more often because of poor use of manual reference counting. Furthermore, nearly all the work required for Automatic Reference Counting is handled by Apple’s Xcode compiler, with very little work to do on the part of the App Developer.

The second set of changes (SQLITE to CoreData) could improve performance, but most likely will be undetectable to the user as well. And again, this is just cleanup work for App Developer to make better use of the Apple’s built in data store, and ultimately makes their life easier as developers.

These two changes should most certainly NOT merit a paid upgrade in my opinion. Good maintenance of existing functionality is the responsibility of the App Developer, and charging users extra for these plumbing changes that change their experience is, in my opinion, not fair.

Cloud Sync

Version 3.0 boasts support for Cloud Sync. However, versions 2.x supposedly did so via iCloud, albeit poorly. I don’t understand how they can claim this as a new feature that requires a paid upgrade either.

iPad Support

The only major difference to users is the support of an iPad version of the app. While that is significant work, it doesn’t strike me as fair that users who purchased versions prior to 3.0 and perhaps don’t care about an iPad version are now forced to re-purchase a nearly exact replica of the same app. The new app is actually called “Instacast 3″ which differentiates it from just “Instacast”, which no longer exists in the AppStore, meaning they probably won’t issue new updates for it. Furthermore, the price is too high.

While I’ve been a supporter and fan of Instacast, I refuse to purchase the 3.0 upgrade and will start using other podcasting apps going forward.

Looking at the diffs, we noticed that it had to do with a property on the XML document called systemVersion.

That property turns out to be related to the version of the operating system the developer is running on. So we decided to do all of our mountain lion updates, and found that it solved that little nuisance. Its a temporary fix, as we all know it’ll come roaring back the moment one of us decides to run a OS X update in the future. Boo!

This leads us inevitably to some sort of device-local storage to persist data. In the case of iOS, we would use CoreData to store data that we’d like to query as fast as possible. This is very convenient because not only are we guaranteed to have this data on our local device when the app starts, we also know it is retrievable at orders of magnitude faster than pulling information from the web.

But not everything can live on our device. Eventually we need to sync our device with the server, pull new information from the server, etc. So we are faced with a complicated dilemma of maintaining persistent data in two separate contexts. It’s an interesting problem that have varying patterns to solve. A really great video that explains the problem and a few solutions was delivered at Google I/O 2010. Although it was in the context of Android, its principles can be applied elsewhere. I highly recommend watching it.

In the iOS context we now have CoreData and a server backend we communicate with using HTTP. Newcomers to iOS are often directed to Apple’s official guide to network requests, revolving around the NSURLConnection class. There is a lot of criticism of the utility of this class as is, and often times it just breaks down when dealing with different HTTP cases. I would recommend you read the guide, but don’t write your network code based on it. The open source community has offered a few libraries that both simplify and empower network operations. Two come to mind right now.

ASIHTTPRequest and RestKit are both good libraries that fill in the void left by NSURLConnection. From easy access to headers, cookie management, caching to support of persistent connections and connectivity notifications. I’ve been using ASIHTTPRequest for a while now. I like it for its simplicity, its ability to easily parse through HTTP headers, cookies, status codes and payloads. I also really appreciate the introduction of blocks into its request model. Blocks programming is a big plus in my book, especially since nearly all of your network operations should be asynchronous.

ASIHTTPRequest is a great toolset to use and I highly recommend its use, but its really only meant for network operations. My problem is not just with connectivity, its with persistence as well. So I was contemplating mapping my JSON payloads to CoreData for local-device storage. But then I discovered RestKit. In my opinion, RestKit is weaker than ASIHTTPRequest when it comes to network operation features. However what it lacks in that area, it makes up for in object mapping and CoreData integration. While ASIHTTPRequest utilizes CFNetwork code giving it a closer to the metal feel, RestKit network code is based on NSURLConnection, which is deficient in my opinion. RestKit also does not support blocks programming as of yet.

I’m still getting to know RestKit. I’ve spent a few does reading the source, fixing a few bugs, and adding blocks support. Its been useful to properly sync my server to CoreData with little code on my part. The areas it needs improvement on are to get away from NSURLConnection, provide better support for synchronous operations and introduce blocks as the callback paradigm. This was not meant to persuade one to use one library or the other. Rather it is meant to share, in my experience, when I would choose to use one over the other. Since I haven’t benchmarked the two, its hard to conclude just yet. However, if you are looking to build a CoreData layer that needs to be in close sync with a server backend, you may save yourself a lot of time by trying out RestKit.

My forked version of RestKit with blocks support is up on github if you wanna take a look and contribute.

Things got more real again when i took up a job working for a startup based in SF. They did have an office in LA, and I found myself once again conflicted between the emotional attachment to a city where I grew up, where all my friends & family reside, versus the more ambitious road of immersing myself around the cream of the crop of my industry. I decided to stay in LA because the opportunities presented themselves career-wise to stay, but it still didn’t quite turn of the alarm; another snooze but for a lot longer time.

This rekindled once again when I found out Omar Hamoui was starting Churn Labs. Omar having decided to create two locations, I was once again presented with the options of being in norcal or socal, even better in Irvine, my residence and all-around favorite city to settle down in. I chose to move back to Irvine and help set up the Irvine office, which was a blast. We found an awesome location in Irvine, and set up a pretty cool office. Best of all, I got to see Omar daily and learn from him. Seemed like a dream situation for most people. But I kept feeling the call of the valley.

Last July, the Churn Labs team decided to do a heads down month-long hackathon out of our San Mateo office. I took my family up and settled in an apartment. We got so much done just being together. We hacked and hacked, and I just enjoyed the isolation. It was in that month that my family and I finally had the courage to do what we should have done long ago. I remember discussing it with fellow Churner and co-founder of the lab Mike Rowehl, an awesome hacker to learn from on a daily basis, and his experience in making the move several years back. It was a forgone conclusion at that point. We decided to relocate and join the legion of hackers in this part of the world.

Having said all that, I have special regards and high hopes for the LA startup community. Time will tell if my words are correct, but now that I’ve moved up here, I am happy with my decision. I am happy to be working with awesome team members on a daily basis. I’m happy that my social life aligns with where I want my career to go. I’m happy to not have to deal with traffic. I’m happy that random folks I run into in coffee shops are fellow geeks. Most of all, I’m happy that my fear of leaving socal, my comfort zone, was unwarranted. Breaking out of your comfort zone is a necessary exercise any entrepreneur should do. Doing it with my family of 2 kids isn’t easy. Leaving behind your family & friends isn’t easy. But at least now I don’t have to hit snooze on that same alarm clock that has been ringing for years. Rather I’ve enabled several new alarm clocks that I feel I won’t have to hit snooze on as long as the last.

Anyhow, here is the link to the demonstration, and the subsequent launch of Gnonstop Gnomes a few weeks later.

I am a total beginner to the field, but some folks in the field directed me to OpenCV as a good starting point to learning what can be done. My ultimate use for CV is to do some cool stuff using iOS (for now) which recently has enriched its SDK with AVFoundation to allow developers to have a lot of power over the camera. Anyhow, OpenCV with iOS prove to be a great combo.

However, since OpenCV is a toolkit more than an end solution, it is hard for a noob like me to know exactly how to use it for the needs that I have (in this case i’m trying to do object recognition). So in such scenarios its good to have a set of image frames on your local machine, and apply your alogrithm to them as you tweak it to get the results you’re looking for. The cool thing about OpenCV is that you can compile it with python bindings. So although my eventual algorithm on iOS will be in C++ or Objective-C, I at least have the luxuries of python to get my algorithm in a position where I like it.

OpenCV recently had an update to the 2.2 edition, and although the C++ samples seemed to be working, I found the python samples outdated. It seems quite a few structures and functions have changed with the new Python bindings. So, as an exercise in learning more about OpenCV and a contribution to the OpenCV project, I went about redoing the squares.py sample to conform to the OpenCV 2.2 version. Squares.py basically takes images and detects if there are squares on them. You should go through the process of downloading and installing OpenCV first, then compare the squares.py in the samples folder with the one here. If you are interested in using it, you can download it from here. Let me know if it was helpful.

For the longest time I’ve wanted to just free myself from monetary obligations to focus on building cool things. Yeah I would spends my nights on side projects, but the places I’ve worked in the past few years have been super demanding. Sometimes I just had to travel too much; other times the deadlines were unrealistic. I think that Churn Labs answers a few needs that the entrepreneurial engineer deeply desires:

First, we want that opportunity to learn new things. We want to jump on every cool subject out there and just play. “Don’t have a data problem where I work? Who cares, i want to use MapReduce and Hadoop anyways” or “I know I don’t really need computer vision to do this, but I want to anyways!” or “Gee, I’m sure this would perform way better using a graph database”. The lab is constructed to be a lab; to explore things differently, and that often means allowing us to experiment with different things we’ve never worked on before.

Second, we want to work with smart people. I’ve always judged a good engineer by his humility and desire to work with smarter folks. We all know that we thrive in those environments that allow us to interact with smarter people than ourselves. In that regard, I’ve been super jazzed with the guys I’ve been working with here at the lab.

Third, we want to work on a successful product. In addition to our passions for engineering, we are still humans (although some of our non-geek friends may disagree), and we want our work to pay off in the end. I’ve seen some great teams that have great engineering power, but they lack a compelling product. Or they lack the right leadership to steer them in the right direction. With the lab, we are building many products, and our stellar leadership is connected everywhere to get the right feedback and make the right connections to help elevate the value and success of the products we work on. This point is actually very important. This point is what makes a team truly successful. Churn Labs, its founders and leaders speak for themselves. This week I met some pretty significant pillars of the tech industry. I could not have imagined that I would be sitting across the table and talking with people who have left a permanent impression on the technical landscape of the world in so many ways.

It is said that successful startups have three components: great teams, great products, and great entrepreneurs. I consider myself lucky to be at a place where I believe all have converged.

CodeIgniter is really easy to use. It allows you to create a PHP site pretty quickly. Along with following the MVC pattern a lot more strictly, CodeIgniter comes with an assortment of helper libraries that are really easy to use. Go checkout CodeIgniter.com to get a better feel for it.

Although I like the simplicity of using TextMate as a simplified IDE, there are times I’d like to be able to step through my code and make sure things are working right. What i want to talk about here is to get your environment setup to use CodeIgniter with NetBeans. NetBeans recently added functionality to allow for code completion when coding against CodeIgniter libraries. Not all work perfectly, but its a great way to understand the framework.  What we are going to do is walk through how to get you up and running and attaching to the debugger.

I’ve only done this on a Mac, so my apologies to windows users. I’m running on Snow Leopard, but this should work on previous versions as well.

1. Download the codeigniter source.

2. Download Netbeans 6.9 with PHP support or higher.

3. Make sure you have xdebug installed and configured with your PHP. For more info on that, go here. 

4. Go to Netbeans->Preferences->PHP->General. Make sure your PHP 5 interpreter path is correct. Set your debugger port to 9000 and ensure Session ID is ‘netbeans-xdebug’. I would also unclick "Stop at the first line" because I find that a little annoying to stop there everytime a breakpoint is set. Its good to see it for the first time just to know where your code starts, but thereafter its not necessary.

5. Now the default settings of codeigniter is to disregard GET (query) parameters. This is problematic because for Netbeans to attach to the xdebug, it needs to pass in the following query parameters: XDEBUG_SESSION_START=netbeans-xdebug. With the default settings, this causes a 404 error. So to get around this, while preserving the nice URL segment based settings that come pre-baked into codeigniter, go to the config.php file under /application/config and change the following values:

$config['uri_protocol'] = "PATH_INFO";
$config['enable_query_strings'] = TRUE; 

6. Now place your breakpoint wherever your heart desires. And copy your URL into a browser, or curl. Make sure to append ?XDEBUG_SESSION_START=netbeans-xdebug at the end of it.

I’m a bit annoyed that i have to pass in a query parameter to be able to attach to a debugger, but since this will only come in handy occasionally, it seems like a necessary evil. XDebug actually has a lot more power stuff in it, which will be handy in more cases than attaching a debugger.

Powered by Qumana

This version of the library comes with support of 3-legged-OAuth, which keeps in tune with MySpace’s devotion to the "Open Stack".  The 3-legged-OAuth flow requires a redirect to the browser, so your application will go to Safari for authentication.  Although breaking away from your application does seem rather counterintuitive from a user experience, the good news is after authentication, your app will be fired up once again.  This is because the SDK takes in your iPhone URL scheme to make a callback after authentication. The other good news is, you will only have to do this one time to associate your user with his MySpaceID.  This is because the SDK stores the Access Token needed for future requests.

On top of OAuth support, the SDK comes with methods to make calls to the MySpace REST API’s.  We have full support for all the V1 and V2 endpoints. As more and more API’s get added, we will add more support.

I’ve also added a VERY simple dumb-down sample application with the SDK, just to demonstrate the OAuth flow, and a few API calls.

I have to admit that this is actually my first real cocoa/iPhone project.  I’ve had a blast picking it up, and I really like the Cocoa Touch framework.  Coming from a managed and scripting code background, I did have hiccups with memory management, but I got the hang of it eventually.  I definitely see areas of improvement to the code, and welcome any feedback.

Take a look at my code. We have open-sourced it like all the other SDK’s. Check it out here: Google Code Page MySpace Wiki Page