Guice or Spring?
Just today, someone mentioned that because Spring already does what Guice does (and more, I might add) that I should stick to the latter. I beg to differ. Each has its own purpose, I wouldn't put these 2 in the same league.
Spring is almost a complete container. From security, a web MVC model, batch framework, persistence, JMX, scheduling, web services and many more, Spring offers (or is able to piece together) an almost complete stack to build enterprise applications. In other words, it's a JEE competitor. Its selling point has always been as a lightweight enterprise stack anyway.
Guice on the other hand is a lightweight DI enabler, so to speak. It offers to take away DI code that a developer could otherwise write themselves. This is probably a gross over-simplication but that's how I see it. When I want DI or AOP but I don't want the whole she-bang (and I don't want to do DI manually), Guice is the solution. On the other hand, if I'm looking to develop enterprise software, I could use Guice, but Spring offers so many bundled services that it's hard to ignore.
I like how Guice encourages constructor injection (which, along with final fields, encourages immutability) and that it returns new instances by default - both of which should allow better performing apps when paired with powerful hardware (read: multi-core friendly). I also like how Guice encourages thinking of applications in Modules, its promotion of testability and its potential reusability. I'm a seasoned Spring developer but it was Guice that really made me step back and think about DI, testability and modularity.
After a few weeks of implementing a small library in Guice, it seems there's no turning back. For non-trivial stuff, there's Spring but for everything else, Guice may be the better choice for me. At the end of the day, Guice is yet another tool under my belt. To dismiss it entirely because I already know Spring is just foolish (even if I've been using Spring for 2 years). Of course, I'll also keep my eye on the recently announced JSR that will bring DI to standard Java.
Guice and Spring are but tools. It's DI, AOP and testability that I need.
Firefox Officially Retired – Long Live Google Chrome!
Yes, I was sceptical such that such a thing could happen. Sure, Firefox wasn't stellar in performance, but I put up with it. Javascript can't be fast. Firefox loads up slow because I've got a tonne of add-ons installed and dozens of tabs open (literally). And font rendering sucks because web developers chose to use non-standard fonts. But more importantly, Firefox, in my books, is better than Opera (because of the add-ons), IE for Windows (because it's secure) and any other browser on Linux (they're just unpolished).
Then came Chromium (or Google Chrome). I ignored it from v1 to v3. Then I tried it on Linux and I've been using it for months, the Linux nightly builds. It's stable enough for extended use, having only crashed once or twice loading Flash. And now it has graduated to Beta, with extensions. I bet soon users will realize how fast a browser can be. It's just amazing. When you're on the web 8-hours a day due to work, 10 seconds here and there adds up!
The first hint of performance issues with Firefox was with Google Wave (I still have 25 invites). And Facebook. And Google Docs... Oh well, you get the idea. Most Javascript-laden site would perform just average or below average on Firefox, but totally flew once Chrome is used. And the start-up time is just stellar! Firing up the browser with dozens of tabs open no longer needed a trip to the pantry for coffee!
If you're not on Google Chrome yet, try it. You might just be surprised (as I was). Then get some extensions.
Some Google DNS Benchmarks Against Open DNS and TM’s DNS
Script that was ran:
for i in "lifehacker.com" "facebook.com" "manu-j.com" "reddit.com" "tb4.fr" "bbc.co.uk" "bernie.net.my"
do
for j in "4.2.2.2" "8.8.8.8" "208.67.222.222" "202.188.0.133"
do
echo $j $i `dig @$j $i | grep Query | awk -F ":" '{print $2}'`
done
done
Readings:
The result is surprising, since it shows that for certain sites (facebook.com, lifehacker.com and bernie.net.my), TMNet's DNS is getting better response times than all the other DNS servers, including Google's. But they are worse in others. Google's DNS however, performs more consistently (~67ms).
Credit goes to Manu-J for the script and inspiration come up with the stats.
How do I use Google’s Public DNS Servers?
Context: What are DNS Servers? From Wikipedia (read it in full):
An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166.
In short, if you're on the Internet, you are already using some DNS server - most probably the one provided by your ISP. Some more technically inclined folks may also be using OpenDNS servers.
Google announced just today that they are providing publicly hosted DNS servers. The motivation? Speeding up the Internet. It's is not the only effort to do so - see their SPDY protocol. So what is Google trying to achieve with its DNS servers? From the horse's mouth:
- Speed: Resolver-side cache misses are one of the primary contributors to sluggish DNS responses. Clever caching techniques can help increase the speed of these responses. Google Public DNS implements prefetching: before the TTL on a record expires, we refresh the record continuously, asychronously and independently of user requests for a large number of popular domains. This allows Google Public DNS to serve many DNS requests in the round trip time it takes a packet to travel to our servers and back.
- Security: DNS is vulnerable to spoofing attacks that can poison the cache of a nameserver and can route all its users to a malicious website. Until new protocols like DNSSEC get widely adopted, resolvers need to take additional measures to keep their caches secure. Google Public DNS makes it more difficult for attackers to spoof valid responses by randomizing the case of query names and including additional data in its DNS messages.
- Validity: Google Public DNS complies with the DNS standards and gives the user the exact response his or her computer expects without performing any blocking, filtering, or redirection that may hamper a user's browsing experience.
Out of the 3 things promised, I find validity interesting. Why? Because by controlling DNS servers, Google has the power to block, filter and redirect Internet traffic, but they promise not to do so. This is a big concern because the big G could've chosen the more 'cunning' way of redirecting unresolved hostnames to its search engine (redirection) or choose to filter out their competitors' traffic. I'm hoping Google is above such dirty tactics of course, they don't need to do so anyway.
Interested yet? See the guide on how to use Google's Public DNS.
Google Wave Invites To Give Away
First 19 to comment about how you're gonna use Google Wave, then tweet me (@ebernie) or email me (ebernie at gmail) your email address gets one. I'll need your email address to send you an invite but please don't write your email in the comments section. Instead use a valid email address when commenting and I'll send it to that email address. Alternatively, you can send me your email address directly via twitter or email.
Don't know what is Google Wave? Watch these video.
Remember, comment with a valid email address (or optionally tweet or email me a valid email)! If you're already Google Wave user, I'd love to hear how your using Google Wave. Add me - ebernie@googlewave.com.
Closure Tool – Javascript Compiler, Library and Templates
Google is doing its thing again, this time at the Javascript front. Google is pretty heavy on Javascript, all of the major Google web applications uses Javascript - think GMail, Maps, Docs and Sites. Closure it seems is the result of talented engineers that needs to use something, realizes there are no standards, and set off to solve these issues (regular engineers would of course just sit back and bitch about the lack of standards).