Thanks, gfurry!

I believe this is indeed a very significant step forward, especially taking into account the launch partners who are already on board.

Naturally, a lot of comparisons between OpenSocial and Facebook Platform have been made, mostly having to do with the fact that Facebook Platform is closed and proprietary, and OpenSocial is open and standards based. While I couldn’t agree more, after reading the OpenSocial documentation carefully, I couldn’t help but notice that there’re several Facebook Platform features missing from OpenSocial – mainly having to do with app management, permissions etc. To try and make some sense of the differences, I created the following table, comparing the two platforms side by side.

Conclusions – first, OpenSocial is only at its 0.5 version, and I’m sure it will be significantly improved and extended in the near future. With that said, looking at the features side-by-side today, it’s clear that OpenSocial currently provides two basic functionalities – containment and access to container data. It doesn’t provide any of the higher level functionality present on Facebook – things like application directory, application permissions and privacy settings, spam controls, additional application links and hooks, ‘app addded’ news posts etc. Each container site will need to implement most if not all these functionalities independently, as they obviously address pretty common needs and problems. This also means that within each container there will be slightly (or maybe even significantly) different app virality, discovery and distribution dynamics.

One thing is for sure – OpenSocial makes developers’ life much much easier. Unlike Facebook platform, OpenSocial doesn’t require learning new markup and query languages, and the specific platform quirks associated with many of the proprietary mechanisms. Also, with OpenSocial developers won’t have to work hard to figure out how to easily push updates to user profiles, or how to include dynamic images or initially interactive flash elements into the profile box. On the other hand, many of these restrictions were introduced by Facebook for a good reasons (at least in their opinion), and it would be really interesting to see how removing these restrictions will affect end-users’ experience.

I’m personally really looking forward to seeing what effect OpenSocial will have on the Web and how Google’s recent move will affect Facebook, Yahoo, Microsoft, AOL and other big players, and what will be their response. Exciting times!

With that said, you should always have scalability and performance in mind – know what steps you can take to improve performance if your site becomes popular.

If you have a scalable architecture, adding more servers and upgrading the existing ones should definitely solve many performance issues, but before you start buying more hardware, there are several simple things you can do to improve the performance of your existing system:

1. Minify your JavaScript files
Your JavaScript files often contain comments, white space and other unneeded characters. Minifying these files means removing these unneeded characters, which can reduce the size of your files by 5%-30%. Smaller files, faster transfers, better response times. A nice utility for minifying JavaScript files is JSMin.

2. Compress served content
Vast majority of modern web browsers supports compression, which means that your server can compress the document before it sends it to your browser, and the browser uncompresses it upon arrival. Compressing your HTML, JS and CSS content can dramatically reduce its size – by up to 70%! Again, smaller files mean better response times and happier users. The method for enabling this functionality really depends on your web server, but with Apache 2.x you can add something like the following to your .htaccess or httpd.conf files:

AddOutputFilterByType DEFLATE text/html text/css application/x-javascript

3. Force aggressive browser caching
Without caching, the browser would load all your JavaScript, CSS and other files over and over again for each page of your site your user visits. A better scenario would be for your browser to ask your server whether the requested file has changed, and if not, just use the local cached copy it already has. The problem with this scenario, that the browser still has to issue a HTTP request for each file, even if such request doesn’t lead to the whole file being downloaded. The best thing you can do is to tell your browser to keep the files cached forever, always using the cached versions and never needing to contact your server. Here’s how this works:

1. Tell your server to send out special HTTP headers with your JS and CSS files. These headers will tell your browser to cache the received files forever. With Apache, you’d typically add the following instructions to achieve this:

   Header set "Expires" "Mon, 28 Jul 2014 23:30:00 GMT"
Header set "Cache-Control" "max-age=315360000"


2. When including the JS/CSS file in your HTML, append a dummy version number to file’s URL:
   <script src="myscript.js?v=1"></script>
3. Once the browser loads the file once, it will never bother your server again (at least not until 2014!). If you change the file and want to force users’ browsers to load the new file, just increment the version number in your HTML:
   <script src="myscript.js?v=2"></script>

4. Use CSS Sprites
CSS Sprites is a really nice technique for reducing the number of image requests for each page. Basically, you can combine all your logos, icons and graphics into a single image, and then use CSS to specify which portion of the combined image corresponds to any specific page image. So, for each page, your browser only loads one larger image instead of many small ones. Decreasing the number of HTTP requests for each page speeds up the page loading times. More info about this technique can be found here.

We’ve been using some of these techniques on FoxyTunes and recently I’ve also added many of these small optimizations to Flickriver, in order to help the site cope with the increasing traffic, without needing to spend more money on additional servers.

A great resource for learning more about these and additional techniques is the “Exceptional Performance” area of Yahoo Developer Network.

All the photographs are uploaded to Flickr and create a living documentary of camera’s travels.

In Ami’s own words:

This Friday I’m going to hand the camera to my friend Y. That’s where the T7’s unusual journey will begin. Y, who’ll be the camera’s new custodian, is an amateur photographer among other things. On Sunday he’ll take his own picture with the camera, along with a clip from that day’s newspaper. He’ll upload the picture to Flickr. It doesn’t matter where, provided that he does one thing: upload all images under one tag: “katze-blog”. That way, anyone who wants to see the pictures can key “katze-blog” in Flickr’s search engine and join the photo journey. That’s all.

Photo journey? Exactly so. Y isn’t going to keep that amazing camera. Instead, he’ll hand it on with the box (and this text) to a certain friend. Now the story starts over. Whoever gets the camera can keep it for a week. On Friday they have to pass it on. But before they do that, they’ll upload to Flickr (katze-blog) at least one picture of themselves with a newspaper and a date, and several others – all of them taken by this little naughty camera. They should not forget, of course, to put them under the appropriate tag so that we can all see it.

And on Friday they’ll hand this little treasure to a new user.

Ami’s post announcing the Nomadic Camera Project can be found here.

I was very fortunate to be the third one in the chain to get the Nomadic Camera – after my friends Yaniv Golan and Amit Knaani.

You can see the Nomadic Camera photos I took so far on Flickr and on Flickriver. All project photos are added to the Nomadic Cam group pool that also has its own Flickriver view.

I’m really looking forward to following the Nomadic Camera travels – first here in Israel and then, hopefully, all over the world.

—————-
Now playing: Bob Dylan – Like A Rolling Stone
via FoxyTunes

So, I added a new top navigation toolbar to every page on the site with links and menus that directly lead to almost any piece of content available on Iosart.com. Also, I moved some stuff around and created a new front page which is now more dynamic and lightweight.

Doing some work on my website got me thinking about the technological choices I made back when I first created it versus what I’d use today, if I had the chance to start things from scratch.

Iosart.com website dates back to early 2004, when I realized that I need a place where I could post some of the stuff I was doing – my photos, plugins, articles and so on.

It’s interesting to compare the technologies I used back then with what is considered the state of the art today

• My initial site was written in static HTML with some Server Site Includes for templating. Today, I would definitely be using PHP for everything
• I wrote my photo gallery system called KPSS in Perl. Again, today I would definitely use PHP for stuff like that. Better yet – today I’d use the Flickr API to create my own view on my Flickr photos. Bear in mind that in 2004 Flickr was still in its infancy…
• My blogging software at the time was Nucleus – WordPress wasn’t yet the undisputed king of blogging platforms.
• I posted some of my academic papers as raw PDFs . Today, I’m posting such things to Scribd and then I can take their widgets and put a document on my site in a nice doc viewer widget.
• I had “Links” page where I manually collected some of my mostly used links. Again, del.icio.us and other social bookmarking services still weren’t very common. Today, it really makes more sense to manage everything in some bookmarking service and show the most common links on my site using a widget.
• Finally, I had some pages with tutorials and I wanted to allow people to add their comments or questions. Because I wasn’t using any CMS (Content Management System), I created my own script that allowed adding user comments module to any static page. Today, I’d just use a WordPress based page for this, which would also solve the terrible spam problems I experienced during these years.

In fact, today I’d seriously consider basing my whole site on WordPress. Beyond blog posts, WordPress allows creating custom ‘pages‘ which can optionally have comments, their own custom templates and so on.

Anyway, it’s really interesting to see how much has changed in only three years. New “best of breed” tools and services have emerged – Flickr, del.icio.us and WordPress are only a few examples. Things are getting better all the time with services such as Ning, Amazon EC2 and S3 and many others.

Now, one can really focus on the content instead of infrastructure. And, once the infrastructure becomes a non-issue, the creativity can really blossom.

I think Flickr has great user interface, but after using it for a while I could think of quite a few things I wanted to add, tweak or just do a bit differently.

Enter Flickriver – my latest personal project. It’s new website that offers a different approach to viewing and exploring Flickr photos. Basically, it encompasses several of my ideas for how Flickr viewing experience could be enhanced. As I said, I’ve been thinking about these ideas for a while now, so I used the recent holiday to go ahead and implement some of them using the Flickr API – and this is how Flickriver was born.

Here are a few examples of what Flickriver offers:

• River of photos view – on Flickriver, the photographs are always displayed as one continuous stream – you can view thousands of photos without ever needing to hit ‘next’ and waiting for the next page to load! This is also known as “infinite scroll”. I noticed that with paged interfaces, I’d typically see a page or two of any specific view and then give up and move on to something else. With “river of photos” I can see much more photographs, or even all photographs in a view, quickly and conveniently. For an example, you can see the most interesting photos stream from a couple of days ago
• Large images – I believe that size really matters when you truly want to appreciate the beauty of photography – thumbnails just don’t do justice to many photographs, making it so much easier to miss a great photo. So, all photographs in Flickriver streams are always displayed in large size.
• Black background – I believe that most photographs just look much better on black. I think that the photograph (and not the background) has to be the brightest thing on the page – this really makes great photos “pop out” and look even more beautiful.
• User most interesting photos – when I stumble upon a new Flickr user, the only view I get on Flickr is “user’s most recent photographs”. But what if the most recent photographs are not very good, while other, older photographs, are really outstanding? How can I discover these great photographs? I believe that “user’s best photographs” is a very important view for discovering and exploring users. Flickriver adds “user’s most interesting photos” view, allowing you to quickly see user’s best work. Check out my most interesting photos for an example.
• Photos of user’s contacts – this is an additional Flickriver view not available on Flickr. Basically, Flickr can show me what my friends and contacts are posting. But what if I want to see what the friends of my contacts are posting? This additional Flickriver view is a great way to discover new people and photos through other people. For an example, you can see photos from my contacts here.
• Most interesting Pool photos – similarly to user views – Flickr only shows the most recent photos added to any given group pool. Flickriver allows you to also see the most interesting photos in any pool. Here is an example for the 24 hours of Flickr project pool.
• Keyboard navigation – when viewing a Flickriver stream, you can press j/k to go to the next/previous photo. Hitting space also allows quickly jumping to the next photo. So, you can quickly go over many photographs with Flicrkriver just by pressing space and going through the pictures one by one. When you’re using keyboard for navigation, Flickriver adjusts the view so only one photo is visible at any given moment.

These are just a few of the things Flickriver enhances. Beyond that, Flickriver has many additional Flickr photo views – user recent photos, favorites, sets, user and everyone’s photos by tag, everyone’s most interesting and recent photos, group and pool photos and much more. Also, Flickriver follows the Flickr URL structure as much as possible, so you can easily go back and forth between the two.

I added several tools and extras to enhance Flickriver – you get a link creator that allows you to quickly create a link to any Flickriver view and post it on your site and there’s a mini-Flickriver widget that you can embed on your Webpage. There is a bookmarklet and a Greasemonkey script – both allow you to quickly jump from any Flickr page to the corresponding Flickriver view. Finally, there are ‘share’ buttons that allow you to post any Flickriver view to StumbleUpon, Delicious, Digg and Facebook.

That’s it for now, I hope you enjoy Flickriver as much as I do

The problem

I used SharpReader and RSS Bandit and encountered very similar problem with both of them. Once the number of feed items starts to grow (I hate deleting old items), so does the memory and CPU consumption. Last time I looked before uninstalling, my SharpReader used 800Mb of memory. RSSBandit would use 100% CPU for minutes…

Additionally, because I use at least 3 computers almost daily (home/office/laptop) – synchronizing my feeds between all of them was very cumbersome, if not impossible with these apps.

Google Reader? A few problems still…

Enter Web based RSS readers. I tried both Bloglines and Google Reader in the past, but something in their interface just wasn’t working for me. The latest version of Google Reader introduced a truly convenient Web RSS reading experience but I still couldn’t use it. Why? Here’re several reasons:

• Developing, testing and installing extensions requires constant browser restarts. Having to open Google Reader each and every time is just not very convenient
• Having Google Reader open requires being logged in with my Google login. This has several downsides – first, I often use different logins for different Google apps – Gmail, Analytics and so on – and logging in with a different user in some Google app kills the Google Reader login as well. Then there is the privacy concern – I search using Google tens if not hundreds times a day, and I just prefer to do it while not being logged in with my Google credentials. Being logged in into Google Reader obviously means I’m logged in when searching and basically everywhere.

The solution

To solve this problem I thought about ways I could create two separate ‘spaces’ – one would be my browser space in which I could be logged out from Google and periodically log-in into various Google apps, and a ‘Google Reader’ space in which I would be constantly logged in into Google Reader.

It occurred to me that XulRunner would be a perfect candidate for this. I thought about creating some custom solution using XulRunner, but then remembered that Mark Finkle has already created something very similar – WebRunner. Basically, it’s a ‘Site Specific Browser’ a simple XULRunner program that displays a single Web application in a simplified interface.

Here’re a few advantages of using Google Reader in WebRunner:

• Completely solves Google login problems and my privacy concerns. I’m always logged in into Google Reader in WebRunner, and logged out in my Firefox
• WebRunner being a separate process means that my Google Reader is always running like a regular desktop application, and obviously survives browser restarts
• It has minimal UI that fits perfectly for Google Reader and similar Web apps – there is no need for ‘back/forward’ buttons, browser toolbars and so on. So almost all the screen real-estate is allocated to the Web app, and there is no unneeded and distracting UI elements

So, with the help of WebRunner and XulRunner, Google Reader has become my main RSS Reader. I get all the advantages of a desktop RSS reader and all the conveniences of a Web app – synchronization across machines, performance, storage and so on.

A few quirks

There are still a few disadvantages to using Google Reader over a desktop RSS reader:

• No ‘new items’ alerts. Desktop readers can show an alert window once new items are published. While there are extensions that can accomplish something similar with Google Reader, their functionality is still fairly limited.
• No search – I know, this is very ironic, but Google Reader still has no search functionality that would allow me to search within feeds.
• New item delays – it can take Google Reader several hours to display new items after they are published. I really hope Google would solve this one.

Conclusion

Overall, I’m really enjoying my transition to Google Reader and would really recommend checking out WebRunner for this.

The reason for closing comments is pretty straightforward – spam. Each Blog post that accepts comments is a target for spammers – so the more such posts you have you’re increasing the amount of overall spam your blog receives every day.

A common strategy for dealing with comment spam is to close comments on older posts – after two weeks, a month etc. Which brings us to the original problem – closing comments on older posts prevents future discussions, even if those would really make sense long after the post was published.

Imagine yourself browsing Flickr and finding a great photo. You want to tell the author how great the photo is or ask a question, but you discover that the photo was uploaded two months ago and the comments are already closed! I couldn’t imagine such a scenario, because more often than not I discover photos long after they have been uploaded and I often see discussions go over long periods of time, being re-newed etc. – which is great. Unlike discussing some current events, discussing photographs cannot really be limited to a short period of time.

Many Blog posts are exactly like that, IMHO. People often search the Web for a specific topic and find old, but still relevant blog posts, and there is absolutely no reason, other than spam, not to allow the discussions on these posts to keep going.

My suggestion – a simple two-level comment protection system. Comments can be open or closed, exactly as today, but a third state can be introduced – let’s call it ‘protected’. In this state, posting a new comment is still possible, but more difficult – protected by CAPTCHA, verification via email etc. Now, after two weeks, instead of closing the comments, they can be set to ‘protected’ mode – this allows minimal barrier to commenting initially, while allowing valid conversations about the post to continue forever.

Jeff had a simple and elegant suggestion – we need a tool that given a conference or an event tag will show me all the people who posted photos on that event and who are not yet on my contact list. This is a great way of finding new and old friends on Flickr.

Anyway, I had some Flickr API code already open in one of my editors (people who know me know that I never close windows, so if I did some Flickr related stuff sometime since the last reboot, I’ll have it handy ), so… Check out the Flickr Post Event Networking tool.

A few implementation details:

• The images are ordered by interestingess
• You don’t have to login to Flickr – the tool grabs your public contact list
• The results are cached for one hour – so after adding people to your contact list, it might take a while for the page to reflect the new status

Jeff – thanks for a killer idea!

I’m really excited to see all the great feedback we are getting from the community – on people’s blogs, in their comments, forum posts and emails to us. Also, the Planet has already been reviewed by popular blogs such as Mashable and Lifehacker.

I must say that creating something that is loved and appreciated by so many people is truly amazing, and this along is enough to keep us working those long long hours on FoxyTunes!

We have a huge list of cool things we’re planning for FoxyTunes soon – the browser extension, FoxyTunes Planet site and the integration of the two. So, stay tuned – more exciting stuff ahead!