They have a new twitter account www.twitter.com/Ingratefully.

Is this the return or some group posing as lulzsec?

https://github.com/recomputing/abu.js

Get the t-shirt! http://www.zazzle.com/dont_fork_abu_js_tshirt-235023689340217923

Viewie for jQuery was written in response to the plethora of Lightbox-clone plugins that all do the same thing: They open a modal window, darken (or otherwise hide) the original page, and show you the content in the modal window. Everybody and their uncle has written a lightbox clone now, and I have yet to find the one that just lets me make my own choices.

Gone is the modal window! Gone are external style dependencies like images and stylesheets! Viewie has two dependencies. jQuery and jQuery UI. If you’re any web developer worth your salt you’re using these already so now your dependency listing just dropped to nil. So go ahead, check out Viewie now!

You can find Viewie in these great locations¹:

• GitHub (The most up-to-date location)!
• jQuery Plugins!

The reason I (and the rest of the team) think it is better than most commenting systems out there is that it is better than most of the commenting systems out there. Our comments are presented to you in real time alongside whatever article you are reading. Not only that, but every comment can be associated with specific parts of the article (including text and even images).

Of course, due to the fact that it was a 48-hour competition, we aren’t completely satisfied with all that we did, but I think that we accomplished a good amount in the time we had. Following is the story of what we did and how we did it.

It all started on a dark summer night (as nights are wont to be) at the Hashrocket office in downtown Chicago. Three programmers and a designer gathered to beget the greatest Node Knockout application mankind had ever seen! The only foreseeable problem was that they all weren’t in the same boat as to what exactly this application was going to be. Did they have ideas? Of course. Were some of the ideas pretty good? Absolutely. Did some of them already exist in superior forms to what these brave creators thought could be accomplished in 48 hours? Most definitely. (I think all of those were mine.) But the real problem was they had less than two hours until the competition started and they hadn’t even hashed out any of the major implementation details. Nevertheless, undaunted, they selected the idea which perched atop the pile and set forth (errr, sat down) to build a better tomorrow for commenters everywhere.

The first night everyone was relatively fresh and the building began at a breakneck pace. The fearless paragons of application construction split up tasks, identifying potential problem areas and tackling those first. Of course, @kfalter began design of the site, @calebcornamn decided he would tackle authentication (which turned out to be much more difficult than any of them expected), @endangeredmassa volunteered to battle with setting up the back-end, and @xonev got stuck with the UI coding (which, to his credit, he only complained about a little bit). The first night went swimmingly – the API for creation and retrieval of comments began to take shape, mock-ups of the interface were created, Facebook and Twitter authentication were investigated, and a silly little commenting pop-up dialog was formed. The courageous band even got some sleep.

The next day, the pace continued, but, as the day wore on, the group began to wear around the edges. @endangeredmassa mercilessly revealed bugs in @xonev’s code, @calebcornman slowly came to the realization that neither Facebook nor Twitter easily fit the needs of the application’s authentication, @xonev’s jokes began to make less and less sense (which is pretty bad considering how much sense they were making at the beginning), and @kfalter continued on merrily designing, unconcerned by the obvious downturn events were taking.

On the third and final day, everything started to come together. Everyone except @xonev was relatively fresh due to getting a more-or-less reasonable amount of sleep the second night. @xonev had only taken a half-hour nap. Around noon, he began to descend into delirium, singing snatches of Michael Jackson songs and often forgetting what he had been working on. Fortunately, the core of what he had been working on was already implemented and the others were able to pick up the slack. In the final hours, @kfalter, @endangeredmassa, and @calebcornman all worked furiously to put finishing touches on the application – @kfalter putting in place the demo and “splash” pages and @endangeredmassa and @calebcornman fighting with deployment issues. Meanwhile, @xonev was either wandering around from computer to computer, barely able to think straight enough to ask what he should be working on or threatening to push some nonexistent code that would supposedly break everything.

Fortunately, despite @xonev’s threats, everything came together in a reasonably working order. Granted, there were some desired features that were missing from the submission – things such as comment threads, closer tying of comments to context (highlighting the actual text commented on instead of just the section commented on), and IE and Firefox support (Firefox was working at some points throughout the weekend, but @xonev was too useless to remember to check it out toward the end of the competition) – but there is clearly potential displayed in what was submitted and the possibilities of future development.

So that’s the story of what happened with our Node Knockout experience this past weekend. I learned that sleep is important – I really was useless at the end. I should have taken naps more frequently or perhaps dedicated a chunk of time here or there for sleeping. I think that going with an hour-and-a-half nap every so often would have been beneficial. That way I could’ve gotten a full sleep cycle in, which I am sure would have assisted with refreshing the ol’ noggin. I also think that we should have spent more time before the competition going over exactly what we were going to attempt to do and how we were going to attempt it. I’m actually somewhat surprised at how well it turned out considering the amount of planning that occurred beforehand. I think it speaks to the flexibility and skills of the team.

In conclusion, I just want to say that I would recommend this type of competition to anyone who likes to build stuff. It was a ton of fun to work with a few other people to put together an application in a frighteningly short amount of time. It was also great to build something that just might turn into something bigger in the (hopefully near) future.

Disclaimer: any and all opinions, jokes, and facts included in this blog post are those held, told, and perceived (respectively) by @xonev and do not necessarily reflect the opinions, sense of humor, or interpretation of events of anyone else mentioned or not mentioned in this blog post.

Google TiSP:

Google’s free in home broadband service.

http://www.google.com/tisp/

Google Gulp:

Let Google quench your thirst!

http://www.google.com/googlegulp/

Google Romance:

Match.com and E-harmony.com don’t know you this well…

http://www.google.com/romance/

Google Lunar Jobs:

To infinity and beyond!

http://www.google.com/jobs/lunar_job.html

Google PigeonRank:

Homing in on your search terms.

http://www.google.com/technology/pigeonrank.html

Google MentalPlex:

This project has been in the works for more than 10 years!

http://www.google.com/mentalplex/

Google seems like a fun place to work!

HTML5 Voice Search How To

A while ago Google added their voice search to google.com.  This feature has been around for a while on Android and proven to be quite useful.

The HTML5 drafts have begun defining the api for voice search.

http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html

If you have Google Chrome and you’ve tried the voice search, then you might want to add it to your site!

Believe it or not, it’s really simple! I added it to this website in about 30 minutes from not knowing anything about to full implementation.

How to do it!

<!DOCTYPE html>
<html>
    <head></head>
    <body>
        <script type="text/javascript">     
            function startSearch(event) {       
               document.getElementById("searchform").submit();     
            }   
        </script>
        <form action="#" method="get" id="searchform">
            <input title="Search"  type="text" name="q"  x-webkit-speech="" x-webkit-grammar="builtin:search" onwebkitspeechchange="startSearch()" />
        </form>
    </body>
</html>

More Information

http://slides.html5rocks.com/#speech-input

http://www.w3.org/TR/xhtml+voice/

http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html

United said its flight departures, airport processing and reservation system, including its website, were affected by the outage.

- http://www.businessweek.com/ap/financialnews/D9NU7J481.htm

My question is simply this…hacked? or did a squirrel chew through the fiber again?

Comment away guys!

I’ve recently purchased a MacBook Pro and I started doing some Python/Django development. I came to a point where I had to use some of MaxMind.com’s GeoIP module and setting GeoIP up on OSX was a bit more challenging than Ubuntu but it wasn’t too bad.

In Ubuntu you can essentially sudo apt-get install python-geoip and things start working but it takes a slight bit more in OSX.

In order to do this on the Mac/OS X you need to install two things,
1. The MaxMind GeoIP C library http://www.maxmind.com/app/c
./configure
make
make check
make install

and 2. The Python MaxMind GeoIP library http://www.maxmind.com/app/python
python2 setup.py build
python2 setup.py install

For further information here’s a great page on MaxMind.com http://www.maxmind.com/app/geoip_resources

This feature has been on Android and iPhones for quite a while now, providing nearly hands free searching to it’s users.

I also added some loading messages. I hope you guys can get some use out of it! Thanks to all those who’ve downloaded already!

If for some reason you don’t have the app then you can download it with the QR code on the right sidebar of the site here or you can go here https://market.android.com/details?id=com.pointlessrants.rss or you can search “pointless rants” in the android market!

Some of you may have read my article about python-geoip for mapping an IP to a city.

If you provide a service which relies on timezones or even just want to display a message at that time then being able to map an IP address to a timezone can be valuable.

This assumes that you have the GeoLiteCity.dat database and that it’s all setup and working. I can show you how to do that in this article.

Once you have that all setup and working all you have to do to get the timezone is pass the country code and region to the GeoIP library function GeoIP.time_zone_by_country_and_region() function.

Here’s an example…

>>> import GeoIP
>>> GeoIP.time_zone_by_country_and_region(gi.record_by_addr("74.125.93.106")['country_code'], gi.record_by_addr("74.125.93.106")['region'])
'America/Los_Angeles'


PyTZ

PyTZ is a nice library that you can use to manipulate timezones in python.

If you want to find out the timezone for an IP address you’ll need to pass it through PyTZ.

>>> from pytz import timezone
>>> tz = timezone(GeoIP.time_zone_by_country_and_region(gi.record_by_addr("74.125.93.106")['country_code'], gi.record_by_addr("74.125.93.106")['region']))

Calculating Daylight Savings Time (DST)

>>> from datetime import datetime
>>> loc_dt = tz.localize(datetime(2011,5,26,16,0,0))
>>> loc_dt.dst()
datetime.timedelta(0, 3600)
>>> loc_dt = tz.localize(datetime(2011,12,26,16,0,0))
>>> loc_dt.dst()
datetime.timedelta(0)


Here you can see that on May 26th 2011 the DST 3600 seconds (an hour), then on December 26th 2011 the DST is 0.

Summary

So here’s the complete code for figuring out daylight savings time from an IP…

>>> import GeoIP
>>> from pytz import timezone
>>> from datetime import datetime

>>> gi = GeoIP.open("/usr/share/GeoIP/GeoIPCity.dat", GeoIP.GEOIP_STANDARD)
>>> googles_tz = GeoIP.time_zone_by_country_and_region(gi.record_by_addr("74.125.93.106")['country_code'], gi.record_by_addr("74.125.93.106")['region'])
>>> tz = timezone(googles_tz)
>>> loc_dt = tz.localize(datetime(2011,5,26,16,0,0))
>>> loc_dt.dst()
datetime.timedelta(0, 3600)
>>> loc_dt = tz.localize(datetime(2011,12,26,16,0,0))
>>> loc_dt.dst()
datetime.timedelta(0)


You get the same great interface but now in the United Kingdom as well.

AuthenticJobs.com has been around since 2005 and has been providing a great service for freelancers and companies looking for full-time, part-time and contract workers.

As of earlier today Sony announced that PSN – PlayStation Network would begin to be restored .
There is an update that Sony wants you to download which will require you to change your password.
It’s been 24 days since the outage began. Some suspect that the so called “hacker” group “Anonymous” was responsible but Anonymous claims the action to be rogue and that they are not involved.

Regardless of the direct or indirect involvement of Anonymous, I have to say that Sony’s response time clearly indicates a serious structural issue with their network and systems.

What’s @ignore and @expectedFailure?

I think that JUnit’s description says it best, “Sometimes you want to temporarily disable a test.”

Here’s the whole thing for JUnit…

“Sometimes you want to temporarily disable a test. Methods annotated with Test that are also annotated with @Ignore will not be executed as tests. Native JUnit 4 test runners should report the number of ignored tests along with the number of tests that ran and the number of tests that failed.” - http://api.dpml.net/junit/4.2/org/junit/Ignore.html

And for Python these two links seem to begin to explain some of the thought behind the decisions to add this feature…

http://bugs.python.org/issue1399935
http://mail.python.org/pipermail/python-dev/2006-January/059503.html

My concern with this feature

I think this is one of those features that kind of got added on a slow day rather than really thinking about the impact that it has on the code and that reflection on the language. It makes sense right? You run your tests, you see some tests failing and you make a decision in your mind that you expected those to fail for a little while during development so you want them to stop sounding the alarm and blowing whistles!

This seems innocent enough at first but what are the long term implications?
Well firstly I think that you should really ask the question “Why do I have failing tests that I want to suppress??”  I can’t think of any good reason personally.  If you’re implementing something so huge that you’ve written tests that you can’t make pass before you test it on an integration server then you’ve probably bitten off more than you can chew and your feature will change/get removed before you can make the tests pass anyway.

Secondly, writing tests should be as simple as possible. Adding something extra to a testing framework, which also defeats the purpose of the framework, seems like we’re making things way more complicated than they have to be. A unittesting framework is supposed to tell you when things pass or fail. If you don’t want the tests to show up as failures and they do not indicate that something is broken then remove them.

Thirdly, maintenance…who’s going to clean this all up? You’ll see some places that warn the users of these features about this. Make sure that you remove this before you finally commit or merge to trunk! Why not just not worry about it by not using it?

If anyone has a really great use case for this please share in the comments! I may have my opinions/rants but I’m mutable

Update:

This is an interesting perspective on the use of @expectedFailure. Basically it can allow you to manage bugs in third-party libraries. For instance if you find a new bug in some library that your’re using, you can write a test for that bug and when it gets fixed that will turn into an “unexpected success” and you can then clean up that test.

For me I still wonder how often this is truly useful. I haven’t seen a lot of tests written for bugs in third-party software. Also, if you have to use that part of the third-party library that has the bug then you must depend on that bug being there or not so you should have tests covering the outcome of the third-party’s bug.
The tests that you have will be covering “your” use of the third-party software. Obviously if the third-party software has a severe bug in it then you may decide not to continue using it.

Thanks Andrzej Krzywda! Great article on your blog.