It's become clear in recent years that people want cross-platform access to their music. iTunes Match, Amazon Cloud Player, and other music locker services have made manual syncing of music across different devices a thing of the past. At the same time, streaming services like Spotify and Rdio have obviated the need to actually "own" any music at all, with their all-you-can-eat monthly plans.

While these developments have been great for record labels, artists, and music lovers, there still remains a plethora of music that isn't released on these kinds of services. Some sites cater directly to helping independent artists promote their music, but a lot more is being uploaded to SoundCloud and YouTube, both officially and unofficially by fans. A record label might post a full-length track to promote download sales, or a DJ might unleash their latest remix to solicit feedback.

All these options make it difficult to find music without doing a lot of manual searching across different sites. And when you do find it, you can't add it to a playlist or like/favorite it with music from other sources. But many of these sites have great APIs that remain underused by music players.

CloudPlay, inspired by the fantastically simple interface of Winamp, is designed to stay out of your view as much as possible, by being a menu bar app. It's intended to be visually minimal, but functionally rich, with the goal of feeling more like a mobile app than a desktop app.

A web-based player often gets buried in a browser tab somewhere, making it impossible to seamlessly switch between songs on different sites. Desktop players consume lots of screen real estate and have weak, if any, support for playing music from multiple online sources.

Playing music from your iTunes library (if you have one) is a given, but CloudPlay takes it to the next level by helping you search for music on YouTube, SoundCloud, exfm, BandSoup, and providing easy access to curated playlists on Console.fm. It works basically the way Spotlight does: type a few search terms, and results from all sources are displayed.

Adding tracks to a playlist is as simple as clicking on a result and picking a playlist. Naturally, a playlist can contain tracks from any of the supported sources. And since it's a menubar app, it supports full keyboard navigation, making it easy to use the player while in another fullscreen app.

In the coming months, I'll be working on improving music discovery with artist profiles, recommendations, stations, and social thingamajigs, while striving to maintain a clutter-free user experience.

CloudPlay will be officially released in the Mac App Store in the next month. In the meantime, grab a free trial version at cloudplay.fm and let me know what you think!

Just like Twitter, you can follow other users on Dialoggs and they can follow you. You can send a private message to any user who follows you, much like a Twitter DM. If you see an interesting post, you can repost it to all of your followers (similar to a retweet). So far, nothing surprising.

If you use Twitter and follow a lot of people, it can be hard to keep track of conversations, whether they're in the form of replies or mentions to someone in the conversation. Thankfully, the grass really is greener on Dialoggs. Anyone can create a dialogg so people know the general theme or topic for posts. People can also follow dialoggs (of course, dialoggs can't follow anyone :). This means that whenever you make a post into a dialogg, anyone who follows the dialogg will see the post, even if they don't follow you.

In addition to mentioning other users, you can mention a dialogg using the @username/dialogg syntax. For example, if you mention @amir/new-music then your post will show up in the mentions stream of all of the dialogg's members (including its creator, me) if the dialogg is invite-only (see below).

By default, a dialogg is public and allows anyone to post, but it can be set as invite-only so only specific users are allowed to make posts into it, but everyone can see them. You can allow those users to invite other users, so membership management (ie. posting privileges) can be shared.

If you want something more controlled, you can create a private dialogg, which is always invite-only. All posts made into a private dialogg are not visible anywhere unless you're logged in and a member of that dialogg. Private dialoggs are great for internal team collaboration and anything that's confidential. Obviously, it's not possible to follow private dialoggs.

When creating a dialogg, it's possible to set the first post as "sticky," meaning the post will stay at the top in the stream of posts for the dialogg as the user scrolls through it.

Now that we're done discussing features, how about some real-world examples ("use cases" as some people say) of what you can do with Dialoggs:

• A read-only blog, mailing list, or announcements

  Create a public dialogg and set it to invite-only. Invite anyone else you want to be able to make blog posts. Each post becomes an entry in your blog. This can be used generally for any one-way communication to a large group of people.

  But "wait Amir, why isn't your own blog running on Dialoggs then?" you ask. Not to worry, third-party integration of Dialoggs data using an open API is in the works so you'll be able to embed posts on your own site.

• A comment stream for another blog

  Much like people use hosted blog comment platforms like Disqus, you can create a dialogg for every blog post, but don't set the opening post as sticky. Now all posts in the dialogg will effectively be comments. Set the website of the dialogg to point to your blog post URL so people that discover the dialogg on Dialoggs know what the posts are about.

• A blog with comments, or Q&A

  For every blog entry, create a public dialogg and create an opening post that's sticky. This opening post will be the blog entry. Any subsequent posts in the dialogg are comments.

• A public or private chat room

  This should be obvious, but since Dialoggs is near real-time, any public or private dialogg can be used as a chat room, although there is no typing notification and there is approximately a 1-2 second delay for a new post to show up.

I'm really excited about what we have planned for the next few months! Take a look at the Dialoggs roadmap to see what's brewing and don't forget to follow @amir on Dialoggs!

That’s what I had in mind when I decided on a vacation in Kauai, the oldest Hawaiian island. Also known as the Garden Isle, Kauai has fewer than 70,000 inhabitants, and a rich history including being the first landing site of James Cook, and the last island in the archipelago to join the Kingdom of Hawaii.

When you land at Lihue Airport it becomes apparent why you’re on the Garden Isle. There’s green everywhere, contrasted by the mountains to the west of the island. The second thing you’ll notice is metal that is exposed to the elements shows signs of rusting. The salty air combined with the small size of the island means that most cars (except rentals for tourists) are a decade or more old. One highway (33 miles in length, max 50 mph limit) doesn’t exactly make your odometer spin.

I’m not a speed freak (anymore), so I was content with the lower speed limits. For example, on the highway, as you approach a town, it’ll go from 50 to 45 to 35 to 25 while in town and gradually back up. Much of it is one lane in each direction (except small stretches in major towns or for passing). Some locals and tourists always seem to be in some kind of hurry, though.

You don’t go to Kauai for the night life (there isn’t any), but there’s so much more to do. Most of it is exploring quaint little towns and taking in the nature. Then there’s the beach, too. The Kauai Underground Guide (free PDF) is awesome.

I strived to eat a lot of fresh fish with hopefully less mercury than back home. Ono, another name for wahoo, is a great fish when grilled or inside a sandwich. Honestly, I wouldn’t have tried it if they had called it wahoo; bad experience at Wahoo’s Fish Tacos, I guess. We found a traditional place where only locals eat and everyone seemed to be having either fried or laulau-style meat and poultry, with a side of rice. It was cheap and basic fare, but I think KFC does it better.

A better option is to try one of the fish markets where you can get sashimi-grade fish and other seafood in taco, sandwich, or fried form. Of course, it would be illegal not to serve fried chicken, too. We splurged a bit on touristy restaurants at Kukui’ula Village. Be sure to ask for the free focaccia and curry muffins at Josselin’s Tapas Bar and Grill. It’s a foodie type joint, but damn tasty. And finally, Bubba’s is a must; it’s the Kauai equivalent of California’s In-N-Out. Brennecke’s Beach Broiler has the best Mai Tai you can enjoy in between snorkeling and beachin’.

Kayaking up the Wailua River to bathe in the Wailua Falls is not to be missed. Our guide was awesome. He pointed out red honeysuckle, purple flowers that taste like mushrooms, and found a rare mango that we all shared. The 5+ hour roundtrip trek is worth every moment, considering it also prepares you to hike the muddy Hanakapi’ai Trail. Best educational kayak/hike combo ever.

Kauai is mostly an explorer’s paradise and a sense of adventure is required. I’d feel guilty if all I did was lounge on the beach. Here are some of my favorite memories from around the island.

Enjoy!

Spouting Horn

A blowhole near the end of Lawa‛i Road that bursts as water rushes under the lava shelf. It’s supposed to be more spectacular in the evening as the sun sets so you see sparkles of the rainbow, but it didn’t occur to me. Best to go there when the sea is rough.

Ho’ai Beach

Waking up to this sight every morning was wonderful. So much that snorkelers seemed to prefer the rocky beach here in Ho’ai Bay more than the sandy Ho’ona Beach down the road.

Kilauea Lighthouse

This is the northernmost point of the Hawaiian Islands. Replaced in the 1970’s with a light beacon (behind it), there’s some restoration work going on to make it more functioning, but they’re taking their sweet time in completing the work.

Moku‛ae‛ae Islet

A bird sanctuary just offshore from the Kilauea Lighthouse.

Kilauea Point National Wildlife Refuge

Yes, all those white dots are birds relaxing. You can also see a small boat exploring the rocky mountain side.

Kalihiwai Beach

Drive a little north of the Kilauea Lighthouse and you’ll get to this beach. It’s situated in what seems like someone’s giant backyard.

Hanalei Valley

A typical shot of what a lush valley agricultural valley looks like.

Coconut Shrimp

On a hot day, a quick fix at the Shrimp Station is all you need. Beer-battered shrimp in the background.

Mailbox on Waimea Canyon Drive

On the drive up to Waimea Canyon, I spotted this mailbox. Makes you almost want to commit a federal crime and deliver the mail to its owner to find out where he lives!

Overlooking Waimea Canyon to the East

A narrow opening across the eastern end of the Waimea Canyon. Volcanic red dirt is everywhere here, fantastically nutrient rich.

Waimea River

The Waimea River snakes through the Waimea Canyon on its way out to the Pacific Ocean.

Stream along Waimea Canyon Drive

Rivers seem to flow everywhere on the canyon. Someone will find this and confuse it for what Mars looked like with waterfalls.

Waimea Canyon

The Grand Canyon of the Pacific. The lines on the walls are caused by lava flows and rivers that flowed from Mount Waiʻaleʻale thousands of years ago.

Prayer at Waimea Canyon

Paying respects to the canyon.

Cliff Trail

The first trail of Kokeʻe State Park, leading to a different viewpoint of the canyon.

Trees on the Cliff Trail

Cliff Viewpoint, Waimea Canyon

The end of the Cliff Trail. Overlooks the Canyon Trail, which goes through Waipoʻo Falls.

Waimea Canyon Drive

The entire road is covered in a red volcanic film. And I guess people like to shoot signs that tell them what to do.

Russian Fort Elizabeth

A dismantled Russian forth near the mouth of the Waimea River. Very near James Cook’s landing; his original flag seems to also still be installed.

Sunrise at Kuhio Shores

Footsteps at Maha‛ulepu Beach

In the winter, you’ll see mostly windsurfers and seasoned surfers attempting anything in these waters.

Waves at Maha‛ulepu Beach

Maha‛ulepu Beach

Strong winds limit enjoyment on this side of the beach. There are few trees to protect you from sandstorms.

Makauwahi Cave

An active archeological dig with 10,000 years of preserved fossils found. The entrance requires crouching and head bumping is an initiation injury.

Pila’s Point

Overlooking the Maha‛ulepu area. Sugar company land.

Bridge to Makauwahi Cave Reserve

Makauwahi Tree Stump

Makauwahi Cave

A view of the open-air cave from the entrance.

Kilohana Plantation Railway

McBryde Garden at National Tropical Botanical Garden

Dead Tree at Kalalau Lookout

At higher altitudes, you’ll often find isolated patches of dead vegetation, like this tree stump. I’m not sure why, but I’d like to think a spray of lava killed it!

Pu‛u o Kila Lookout

Overlooking the northern end of the Kalalau Valley, on the Na Pali Kona Forest Reserve Pihea Trail.

Scene around the Pu‛u o Kila Lookout

Na Pali Kona Forest Reserve Pihea Trail

Sunset at Kekaha Beach

Turquoise Waters on the Hanakapi’ai Trail

Na Pali Coast from the Hanakapi’ai Trail

The Hanakapi’ai Trail is a very rewarding hike, but beware of the conditions. We went when it was muddy and it took 1 hour 40 minutes to get to Hanakapi’ai Beach (3.25 miles). We arrived at 2pm, but ideally it would be best to arrive around noon, since the beach gets a bit dark sooner due to the tall surrounding mountains. On the way back, if you’re lucky, there’ll be a guy with a machete slicing open fresh coconuts.

Small Stream on the Hanakapi’ai Trail

Hanakapi’ai Beach

The last river you cross to get to the beach. It’s waist deep and moves quite fast in the middle. Another option is to walk on the rocks toward the beach and cross a shallower stream there.

Highest Point on the Hanakapi’ai Trail

The portion of the trail to the beach snakes around the mountains and is really a sight to behold. After rains, most of the trail is muddy, with patches of dry dirt where directly exposed to the sun.

River at Hanakapi’ai Beach

To enter or exit this beach, you need to cross this river. You can do it here or further downstream, closer to the beach. You still need to do some rock hopping afterwards.

Night Sky in Koloa

It’s a pity that I can’t enjoy dark skies like these at home. Stargazing next to rolling ocean waves is heaven on clear nights! This is a 13 second exposure at f/2.8, ISO 1600 of a part of the eastern sky (full size). As far as I’m concerned, I’ll be using Jupiter instead of the North Star for navigation.

Unsurprisingly, the initial idea started out with a huge scope. We wanted to track users as they moved through a site, drill down into GET/POST parameters, including any JSON received or sent by an API, track uptime, slowest API endpoints, and more. Fortunately, we trimmed it down to just the basics: monitoring requests in real-time, tracking average response time, and counting the number of requests.

In 48 hours, a great deal was accomplished, but in the end it turned out that just getting a nice real-time graph working with the proper backend architecture in place took some time. Due to last-minute issues, we weren't able to show the most popular endpoints or top sources in the dashboard, but hopefully the general idea of the service is clear.

On the third-party API server side, a developer only needs to install the restalytics node module (npm install restalytics), and include this line of code in their main server-side script:

require('restalytics').apiKey('_YOUR API KEY HERE'_);

The restalytics module is able to track incoming HTTP requests (to any server subclassed from http.Server) as well as responses. The graph on the main dashboard shows requests on the horizontal axis and response time as their height. The response time is the time required to handle an incoming HTTP request (after it arrives) and send the first HTTP response header. It's purely the request processing time, not data transfer time.

The restalytics node module, by default, flushes the collected statistics every 5 seconds to the RESTalytics API server. This allows you to see a near real-time view of requests to your server. In case the RESTalytics API ever goes down, the node module is designed to retry. If the API is down is for an extended period of time, the module will drop older statistics to conserve RAM.

The module sends each batch of data points as a POST request to /api/data. Each batch is asynchronously processed by adding each data point into an incoming queue (stored in Redis). A worker process processes each data point, calculates daily and 5 minute averages by storing them into keys in Redis for each type of statistic required (number of requests, average response time, slowest endpoint, etc.). Finally, the actual data point is stored for safekeeping into MongoDB.

MongoDB also contains the different sites (APIs) that a user account may have, as well as all detected URI endpoints. By storing the raw data points in Mongo and issuing dashboard queries directly to Redis, we're able to maintain acceptable performance with little datastore overhead.

Future improvements:

• Historical graphs
• Browse individual requests (Logs tab)
• Find requests by filtering on query string parameters or request data

To find out more, check out RESTalytics or follow me on Twitter and I'll keep you updated.

Compass is pretty awesome to work with. You write your style rules in a Sassy CSS (SCSS), a superset of CSS. While developing, I run the "compass watch" command, which automatically monitors the file system and compiles .scss files to .css on any change. Being too lazy to reload the page on every change, I employ CSS auto-reload to dynamically reload CSS stylesheets as they change without requiring a full page refresh. This is a huge plus during development for a CSS novice like me. Experimenting with layouts to achieve pixel perfection become realistic, much faster than playing with WebKit Developer Tools.

Compass and Sassy have been web development fun again for me, so much that I went crazy and designed this blog theme from scratch. Call me cliche, but I couldn't resist border-radius and shadows!

My idea received enough votes to be one of the dozen or so teams to start working. I, along with @evanwolf and @romil4you started exploring the idea and what was doable within the 54-hour timeframe. My original idea was to use Tropo to allow people to call a number, transcribe a tweet, and post it on Twitter just by using their voice from any phone in the world. Technically, this would involve doing speech recognition to capture a transcript, play it back to the user (to ensure the recognition was accurate), and then post it. Since the Tropo speech recognition API isn't real-time, though, the user would need to wait at least 15 seconds before we could confirm the transcript.

So we decided to scrap the tweet sending feature and only allow people to receive tweets as a phone call. This means anytime someone @replies to you or directly messages you on Twitter, you'd get a phone call. To prevent multiple phone calls, tweets sent within a short period, are batched together and spoken in one phone call. For most people, this is fine. In the future, the plan is to add filtering, so that you only get calls when certain people (eg. in one of your lists) tweet you.

By presentation time (around 6:30 PM on Sunday) we had the basic product working, from signing up on the Speak It, Baby! web site to making phone calls with new tweets.

Due to the limited timeframe, we weren't able to get approved for the Twitter Streaming API, so we decided to drop the DM feature, and just focus on @replies until we get access to the API. As you can guess, the current way of detecting new tweets is to continuously poll search.twitter.com with a list of interested users. (If your tweets are protected, you currently can't use the service.) Finally, incoming tweets are correlated to registered users and stored into a CouchDB database hosted on Cloudant.

A node.js server monitors the _changes stream from CouchDB and builds up a queue of tweets, for which phone calls need to be made. It uses the Tropo Sessions API to create new outgoing phone calls and manages any phrases the callee might say on the call.

Overall, it was a wonderful experience and I'd do it again. I consider myself a winner anyway since we pretty much launched something that users can start using right now :) So sign up today and wait for someone to @mention you, or tweet @ammmir and I'll be happy to oblige!

A more general way to tackle this is by taking advantage of load balancing. Let's take the simple scenario of one reverse proxy (nginx) sitting in front of one node.js instance. You have nginx configured to to talk to the live production instance (version 1) or to the pre-live instance (version 2). When you want to deploy version 2, the code will be uploaded to the server, and the v2 node instance started. Now, at this point, traffic is still going to the v1 instance. We must let nginx know that for all future requests, route requests to v2, but let in-flight requests continue to talk to v1. This will keep things like WebSocket connections and long-poll sessions humming along until you retire v1.

So now we have two versions in production, but eventually, v1 can be shut down organically (when all requests finish) or it can be forced to shutdown after some specified amount of time. In the latter case, the web app or whatever thing is talking to your node application, should be designed to reestablish connections transparently. That way you can deploy during peak traffic without user complaints.

In this nginx configuration snippet, two upstreams are defined with one server each. You can add more if you like, since node.js doesn't currently support worker processes out of the box. I'm using UNIX domain sockets because they're represented as files and we can use mv to "atomically" switch versions on the fly.

Initially we have v1 deployed and listening on /tmp/myapp-new.sock and myapp-old.sock doesn't exist yet. Now we bring up v2 and have it listen on some other unique socket, /tmp/myapp-v2.sock. First, we need to free up myapp-new.sock so we move it to myapp-old.sock. To the outside world, nothing has changed, but nginx is now proxying requests to a new socket. Finally, we move myapp-v2.sock to myapp-new.sock.

Done.

And the best part? The only change to your app is the line that calls server.listen(): instead of specifying a port number, use an absolute path to a UNIX socket.

One of the real beauties of server-side JavaScript is that you're able to reuse business logic on the client. Mundane tasks like input validation, need to at least happen on the server. Traditional Web 1.0 apps did these entirely on the server, but modern web apps often need to do it both on the server and client since a web-based UI might not be the only consumer. If you're offering an API for third-party developers, then it's handy to offer single logic for validation to avoid inconsistencies.

Backbone.js requires Underscore.js, so both need to be made available to modules in the node.js environment. Luckily, both are CommonJS-aware, so adding the directory containing underscore.js to the require path as part of your bootstrapping process is a good idea:

require.paths.unshift('../vendor/underscore');

The following code generates the client-side source from a model object that could contain both server and client-side logic. It looks for an __exports__ property in the constructor. ClientModelFactory will only serialize properties defined by __exports__ either through the exact name or a regular expression matching the constructor's own properties or those of its prototype.

To use this technique, you should include both Underscore.js and Backbone.js in your HTML page as usual. You'll also want to include the generated client-side model that is generated by calling ClientModelFactory.makeAll(). For development, you could have a URL handler at /js/models.js that calls this and returns the generated content. Obviously, for production, doing the generation offline and integrating it with part of your build process makes much more sense.

This approach blurs the line between client and server. In the war against cruft, this is a plus for me.

I've seen people create great things and I'm part of some now, but I'm starting to feel another startup itch of my own. I'm hoping to channel this itch into some really exciting things over the next few months. My biggest problem is always: there are too many ideas worth exploring, what to do first?

While doing my last "startup" I realized we had a great idea for a product users were begging us to release, but the business side didn't really make sense at the time. I've realized that it's important to just brainstorm ideas, wherever you are, or whatever they may be. And it's even more important to write them down somewhere for future reference, since there's bound to be an Aha! moment when you look at ideas from different angles.

I'm constantly asking myself "why does X suck so much?" -- it's my frustrations, sometimes hatred, with technology that really stimulates the most unique, often ridiculous, ideas!