Thursday, June 30, 2011

Broken Tutorials

In the past, whenever a novice programmer asked me for tips on how to pick up a new language, I'd give them the same advice I'd been hearing for years. Play with it! There's nothing quite like identifying a project you're interested in doing and then diving in, following online tutorials until you are comfortable enough with the new language to venture off on your own.

However, my recent experience with node.js has shown me that there's an even better technique: Follow *broken* tutorials and struggle through the issues until you've made it work. This excellent tutorial is a bit out of date and requires a bit of tweaking to get running. However, once you've conquered it, victory is that much sweeter and you knowledge of node.js and express is that much deeper because of your struggles.

Wednesday, February 10, 2010

Some thoughts on Google Buzz

As nearly everyone knows, Google released Buzz - a FriendFeed-like social lifestream platform that allows people to pull in updates from various sites like Twitter, Reader and Flickr, add status updates and consolidate them into a single feed accessible via your Google Profile and Gmail. Add in Gmail's natural social graph powered by your contacts list and we have a pretty compelling social offering.

However, with this offering comes another degree of confusion. Which of my feeds should my friends consume? I have a twitter feed which my twitter followers can consume. It posts updates to Facebook for Facebook users to read and comment on. People who follow me on Twitter and are friends with me on Facebook get these updates twice. Not a great setup but understandable. Now throw Buzz into the mix and suddenly Twitter posts show up in 3 locations! I can see that getting annoying quickly. To make matters worse, each platform has "some" content that won't show up in the others.

To combat this, I think Google needs to step up and make Buzz "the" aggregator for all of a person's social content. To do this effectively, it will need to eliminate duplicates caused by cross posting services and somehow incorporate site-specifc comments as well. (Sounds *a lot" like FriendFeed, doesn't it.) Aggregating site comments is extremely complicated, especially when we add blog commenting services like Disqus into the mix but if Google solves this problem, it will have positioned itself to be a dominant player in the social space.

Wednesday, November 11, 2009

In App Purchases (Part 2)

And now that Apple allows IAP on free apps, the App Store will become even more "shareware-y".

Thursday, June 11, 2009

iPhone OS3

I think that when the iPhone OS3 drops, the App Store will be come a much less friendly place. Part of the beauty of its current incarnation is in its simplicity. You know what you're buying and how much you're paying for it. Once Apple allows in-game purchases, apps will start getting all annoying with nickel-and-dime upgrades on top of seemingly low app prices. "Sure you can get this awesome driving game for 99 cents! Oh, you want tires on that car? That'll be an in-game purchase of $3.99 please."

Get ready for the App Store to be a lot less fun to shop.

Tuesday, May 12, 2009

Correlated Subfeeds

RSS is one of those technologies that is amazing in its simplicity yet extremely versatile. I think of it of the Twitter of yesteryear. Nearly every blog and website exposes an RSS feed for easy consumption by RSS readers such as Google Reader and Newsgator. These tools allow you to easily see updates to several blogs, all in one place, without ever having to visit the multitudes of sites you may be subscribed to.

And therein lies the rub. A typical RSS subscription only brings in the posts of a blog, not the comments people have made on those posts. As Fred Wilson of AVC.com has said, often, the comments are just as, if not more valuable than the posts themselves. Its also difficult to join a community around a blog like Endgadget or Lifehacker when all you see are the blog posts themselves. Much of the sites' flavor and sense of community comes from the comments.

Google Reader offers the ability to comment on posts and even share thos comments with friends but those comments only live withing the Google Friend Connect universe (for now). Friendfeed tries to address this problem but can only be successful if all your commentors are using Friendfeed. Disqus.com makes it easier to follow comments on your own blog and helps you track comments that were made as replies to your own comments but still falls short when it comes to watching conversations in your favorite blogs.

What I'd love to see in RSS is "Correlated Subfeeds". Before you start Googling it, you should know that I just made up the term. It was inspired by Correlated Subqueries which derive part of their filtering clause from a parent query. In other words, allow every RSS feed to specify a subfeed that would take the unique post ID for any post in the feed, and insert into a new feed request for comments on that post.

For example: suppose I've defined a feed for this blog at http://izontech.com/rss/posts. My subfeed would be http://izontech.com/rss/comments/postid{0}. The {0} would then be replaced with the ID of each post. Readers that support this feature would be able to provide a tree view under each post that would show the comments belonging to each post. This would also make subcribing to a discussion forum much more intuitive. Instead of subscribing to a new thread feed and then to individual discussion feeds, we could just have one feed, "New Threads" and the discussions would be captured in the correlated subfeeds.

Perhaps the world has moved on from RSS and embraced newer technology. The real-time aspect of these alternatives is incredible attractive. However, RSS has been around for a long time and will continue to be for a while. Why not make it more useful?

Thursday, February 26, 2009

Power Copy-n-Paste

Have you ever copied something to your Windows clipboard and were ready to paste it when you realized you needed to copy and paste something else? Yep, you had to go copy and paste the new item, then go back to your original source and the copy and paste that again. What a hassle. Here's a little timesaver I've discovered. Don't copy and paste the new item - instead, select the new text with your cursor and the ctr+drag it to its new location (or just drag it for cut and paste). Then when you hit "paste" or ctrl+v - you're original text is still in the clipboard and gets pasted!
Reblog this post [with Zemanta]

Tuesday, February 17, 2009

Testing PayPal IPN

When working with PayPal as a payment provider, you'll inevitable wind up dealing with their Instant Payment Notification (or IPN). Its not always instant and not always payment related but is a notification.

An IPN is a simple HTTP form post that PayPal sends your server (to a url specified in your account settings or the "notify_url" parameter of the transaction) that provides information about the transaction that just took place. It contains information like item names and codes, price information, and the buyers shipping info. Because it is sent directly from PayPal's servers to yours without passing through the user's browser, it is much more secure and less susceptible to tampering.

However, when working behind a firewall or NATed router, PayPal's IPN has no way of reaching your development machine! Sure, you can forward a port to your PC but chances are, your port 80 is already being forwarded to a real web server (or you might not have access to the router).

To get around this problem, I built a simple ASP.Net page on our public facing test server (that has access to our internal network) that simply accepts the post from PayPal and reposts it to my development machine. The code is very simple:


_internalURL = "http://mydevmachineurlhere";

string postData = "a=" + "a";
for (int i = 0; i < Request.Form.Count; i++) {
postData += "&" + Request.Form.AllKeys[i] + "=" + Request.Form[Request.Form.AllKeys[i]];
}

encoding = new ASCIIEncoding();
byte[] data = encoding.GetBytes(postData);

// Prepare web request...
HttpWebRequest myRequest = (HttpWebRequest)WebRequest.Create(_internalURL); myRequest.Method = "POST";
myRequest.ContentType = "application/x-www-form-urlencoded";
myRequest.ContentLength = data.Length;
Stream newStream = myRequest.GetRequestStream();

// Send the data. newStream.Write(data, 0, data.Length);
newStream.Close();


As you can see, this page will redirect the POST to an internal URL of your choice. You can even get fancier and have the repost go to different URL's based on any parameter you want (e.g. "payer_email", "item_name" etc.) to facilitate testing for multiple developers - without having to mess with your firewall.
Reblog this post [with Zemanta]