Useful at Night is a mobile guide for nightlife empowering real time discovery of cool locations, allowing nightlife players to identify opinion leaders. Through geo-location and data aggregation capabilities, the application allows useful exploration of cities, places and parties.
Evelin Velev was kind enough to share what technologies his team uses to run their star-up.
Main technologies used are Node.js, HTML 5 and NoSQL.
Back-end application servers are written in Node.js and hosted at Heroku, coupled with RedisToGo for caching and CouchDB served by Cloudant for storage.
Their mobile front-end supports both iOS and Android platforms and is built using HTML5 and a homemade UI framework called RAPID. There are some native parts developed in Objective-C and Java respectively.
In addition Useful at Night uses MongoDB for metrics data with a custom metrics solution written in Node.js; Amazon S3 for storing different assets; and a custom storage solution called Divan (simple CouchDB like).
We chose Node.js for our application servers, because it enables us to build efficient distributed systems while sharing significant amounts of code between client and server. Things get really interesting when you couple Node.js with Redis for data structure sharing and message passing, as the two technologies play very well together.
We chose CouchDB as our main back-end because it is the most schema-less data-store that supports secondary indexing. Once you get fluent with its map-reduce views, you can compute an index out of practically anything. For comparison, even MongoDB requires that you design your documents as to enable certain indexing patterns. Put otherwise, we'd say CouchDB is a data-store that enables truly lean engineering - we have never had to re-bake or migrate our data since day one, while we're constantly experimenting with new ways to index, aggregate and query it.
We chose HTML5 as our front-end technology, because it's cross-platform and because we believe it's ... almost ready. Things are still really problematic on Android, but iOS boasts a gorgeous web presentation platform, and Windows 8 is also joining the game with a very good web engine. Obviously we're constantly running into issues and limitations, mostly related to the unfortunate fact that in spite of some recent developments, a web app is still mostly single threaded. However, we're getting there, and we're proud to say we're running a pretty graphically complex hybrid app with near-native GUI performance on the iPhone 4S and above.
If you'd like to hear more from Useful at Night please comment below. I will ask them to follow this thread and reply to your questions.
There are comments.
A query string is the stuff after the question mark in URLs.
Two reasons: clean URLs and social media.
Clean URLs not only look better but they prevent users to see if you are tracking where they came from. The picture above shows what the address bar looks like after the user clicks a link in Feedburner. The high-lightened part is what Google Analytics uses to distinguish Feedburner traffic from other types of traffic. I don't want my users to see this.
As you know, social media sites give URLs a score, whether it is based on number of bookmarks, reviews, comments, likes or whatever. Higher scores usually result in increased traffic to your site. Query strings mess things up because http://www.dif.io and http://www.dif.io/?query are usually considered two different URLs. So instead of having a high number of likes for your page you get several scores and never make it to the headlines.
Place this JavaScript code in the <head>
section of your pages. Preferably near the top.
<script type="text/javascript">
var uri = window.location.toString();
if (uri.indexOf("?") > 0) {
var clean_uri = uri.substring(0, uri.indexOf("?"));
window.history.replaceState({}, document.title, clean_uri);
}
</script>
This code will clean the URL in the browser address bar without reloading the page. It works for HTML5 enabled browsers.
This works for me with
Firefox 10.0.12, Opera 12.02.1578 and Chrome 24.0.1312.56 under Linux.
In fact I'm using this snippet on this very own blog as well.
UPDATE: I've
migrated to Pelican
and haven't enabled this script on the blog!
Updated on 2013-01-30
Here is another approach proposed by reader Kamen Mazdrashki:
<script type="text/javascript">
var clean_uri = location.protocol + "//" + location.host + location.pathname;
/*
var hash_pos = location.href.indexOf("#");
if (hash_pos > 0) {
var hash = location.href.substring(hash_pos, location.href.length);
clean_uri += hash;
}
*/
window.history.replaceState({}, document.title, clean_uri);
</script>
If you'd like to keep the hash tag aka named anchor aka fragment identifier at the end of the URL then uncomment the commented section.
I've tested removing the hashtag from the URL. Firefox doesn't seem to scroll the page to where I wanted but your experience may vary. I didn't try hard enough to verify the results.
One question still remains though: Why would someone point the users to an URL which contains named anchors and then remove them? I don't see a valid use case for this scenario.
You may want to take a look at the many HTML5 and JavaScript books if you don't have enough experience with the subject. For those of you who are looking into Node.js I can recommend two book by my friend Krasi Tsonev: Node.js Blueprints - Practical Projects to Help You Unlock the Full Potential of Node.js and Node.js By Example .
There are comments.