I'm Persian

HNDroid is a Hacker News android client which I first released in September, and announced in a Tell HN thread.

Well, I'm not actually writing to introduce an already 2-month-old project, but to thank everyone who helped me getting HNDroid more bearable. Emil helped me debugging and testing it on a real device, Michael kindly offered a new logo for application, and Ben from Solid State Group helped me putting it in Android market.

A couple of days ago I released version 0.2 with a new light theme, bugfixes, performance improvements, and some minor new features. You can download the .apk from project's page, or download it from Market (search for hndroid).

So Twitter finally dropped Basic authentication, and now OAuth (twitter's implementation though) is the only way to authorize clients.

I'm not going to tell you how bright is the idea behind OAuth, the idea of letting an application to do things on behalf of you without letting it know your credentials, the idea of revoking the access of misbehaving application as soon as it started being fishy, the idea of letting the server to revoke the consumer's access whenever it wants, cause of course you all know these. But wasn't that application (the one service provider decided to revoke access), the one you authorized earlier on? You and hundreds of thousands of other users? Apparently it doesn't matter, after all you are not the ultimate resource owner.

The shiny new twitter client (which you may have even paid for, and/or even better you got it from a distribution channel) stopped working? Who's to blame? Depends on whom you ask. Twitter would eventually blame developers for not being able to hide their key and secret.

But is it really developer's underdo? OAuth specifications clearly state that the service provider shouldn't solely rely on the secret as a method to verify the consumer identity, because it's pretty damn easy to extract the key, and secret if the client is a desktop application, ergo the answer is "No".

Enough rant, time to talk about the third part of the post's title.

"bti" is an open source CLI twitter/identi.ca client originally developed by the famous hacker Greg Kroah-Hartman to annoy the whole world by piping the bash input as tweet/dent. I sent my first patch (readline support) in February 2009, and after that I couldn't resist sending more patches (e.g., read support) because Greg is a pleasure to work with, he accepted all my silly patches, and silently fixed all the issues with them.

When a bug filed at debian BTS for sending bti to grave for not having OAuth supprot, I thought it's about time to make bti OAuth aware. The obvious was to register bti, and put the consumer key, and secret in the source. Wait, what?! You Idiot! Twitter has warned that would kill all OAuth keys seen in the wild - yeah, that's what you do when you solely rely on the secret (I know, I switched off the rant earlier, but the rant was inevitable). So we decided we'd better not distribute the key and secret, thus there's no key bundled with bti.

OK, this is what you should do in order to allow bti to tweet (thanks to Greg, the Basic auth support is still there, since Identi.ca has OAuth service provider too, I was tempted to purge Basic auth's codebase entirely):

• Go to http://twitter.com/apps/new to register a new application. Set the "Application type" as "Client", and "Default Access type" to "Read & Write".


• Open bti config file (~/.bti), and put these two lines into it:
  
  consumer_key=THE_CONSUMER_KEY_IN_APPLICATION_DETAILS_PAGE
  
  consumer_secret=THE_CONSUMER_SECRET_IN_APPLICATION_DETAILS_PAGE
  
  


• Run bti, if things go well bti should print an URL, open that in your browser, and allow bti to access your account. Copy the PIN and paste it in bti prompt. Now bti should print access_token_key, and access_token_secret, paste those two lines in your bti config file as well.

That's it!

Apparently the only way to pull information from Gearman job server is via a text-based protocol which runs on the same port as the binary protocol. I wrote a simple mod_status-like Apache module to monitor gearmand.
WARNING: bad code ahead. I warned you!
mod_gearman_status

UPDATE: Just uploaded some screenshots.

As you probably know Google started hosting popular JavaScript libraries back in months. Letting Google be your CDN is quite cool, to quote the project itself (http://code.google.com/apis/ajaxlibs/) using this service:

...your application has high speed, globally available access to a growing list of the most popular, open source JavaScript libraries...

Oh wait wait wait! Global? Then there's got to be something wrong with Google's definition of "global". As far as I know Iran is part of the globe, and I believe you have to tell your users clearly if your mileage varies than theirs. Google has to tell web developers that by "globally" they actually mean "the World minus some countries".
Here in Iran we get silly "HTTP Authenticate" popups upon each request to that service; not just clicking on "OK/Cancel" multiple times hurts - but not loading JavaScript libraries will break the web page entirely.

Here in Iran websites are categorised in one of these three:

1. Those which are censored by the government


2. Those websites which will throw us "Forbidden" (a.k.a 403) while visiting from Iran, and


3. Those innocent ones which don't really believe we Iranians should not use their services, but they just consume hosted files in the services like one Google offers.

(well there's also some rare ones which works just fine, but come on they don't deserve a separate category )

So, please stop using Google's service (the other annoying one is Google code which does not let us browse project's pages, checking out from subversion repositories ...)

I call the web "broken", and it's all your fault Google.

It seems dev-scheme/mit-scheme package has been removed from portage, it could be because of files containing executable stacks or something.
If you (like me) need the MIT/GNU Scheme, and prefer not to install packages unless there's an ebuild (thus there's emerge) somewhere, here's the Gentoo lisp overlay, but to my surprise it's not listed at overlays.gentoo.org. This overlay contains dev-scheme/mit-scheme-c, and no, it's not binary.
Simply clone it (and don't forget to pull periodically), and add the directory to your PORTDIR_OVERLAY.

I just picked up a ThinkPad T61 (14.1", Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz, 2GB RAM, Quadro NVS 140M 512MB).
It comes with "Windows Vista Home Premium Ultra blah blah", and I only booted into it once, actually the shop guy did, damn.
When I got back home, the first I did was downloading and burning a Gentoo minimal, and after almost three days I had a Gentoo from stage3 "up & running".
After installing Xorg and nVidia drivers, it was time to choose a DE, and with no surprise I ended up with no DE, just a WM, a tiling one of course, awesome.
Awesome 3 is about to release (and it's RCs are in portage, though hard masked), and it's configuration format is not backward compatible with awesome 2, so there was no point in starting with 2. Usually I don't install hard-masked packages, but this time I did, and actually emerged bunch of them in order to satisfy awesome's dependencies.
And ..., everything is compiled with native march and mtune

Lately I've been playing alot with the PEAR CLI.  The one annoying thing I noticed the most was its lack of tab completion that I'm used to from the shell.  It turns out that this feature is very easy to add, in the bash at least.  Here (Update: Now it's in PEAR SVN repository) is a simple tab completion script for the bash.  In addition to completing the PEAR commands and their respective options, it can even autocomplete the names of installed packages and discovered PEAR channels.  Just source it, and enjoy

As the title suggests this book is about advanced PHP related topics, being divided into 5 parts and 21 chapters. The title enunciates the book will cover many different aspects, but you'll get disappointed as soon as you perceive it's only about 300 pages.

First part starts with "OOP and Patterns" and will end up with PHP 6's new features. The Patterns chapter is the first one which disappoints you - you'll wish it was a little more verbose, covering some more patterns and being more than only 7 pages.

The next Part is about "Testing and Documentation", covering PHPDoc and DocBook in it's first chapter. In the next one about "Reflection API" - which I think is one of the best chapters - Kevin goes deep into two complete real world examples. But unfortunately then book disappoints you again, trying to cover some topics like "Development Environment", "Unit Testing", "Deployment" and "Continuous Integration" in just about 20 pages. Kevin just skims through introductory concepts of tools like Subversion, PHPUnit, Phing, Xinc and Xdebug.

The third part is all devoted to SPL. Kevin describes SPL from fundamentals to some advanced topics like "Array Overloading" and "Observer Pattern" in a way you wished that all of the book was written this way.

Part 4 covers another Pattern, MVC this time. Describing what it is, why it's good, and talking about criteria you may consider when choosing an MVC framework. Then it helps you to roll your own MVC framework by recommending to choose from one of the publicly available frameworks. The book also covers Zend Framework as one of those "publicly available frameworks" which meets the most criteria in his opinion.

And the final Part, and with no surprise it's titled "Web 2.0". In my opinion the first chapter of this part is the book's truly weakest chapter, it's about Ajax and JSON and it barely covers anything more than what you'll find in any of the beginner Ajax tutorials. But the rest chapters compensates, "Web Services" and "Certificate Authentication".

All in all I found the book a good one, a good next step if you are already familiar with PHP and looking for a book to extend your knowledge, then this one is a recommended one. But I by one would like to see some practical solutions applied to enterprise level when buying a book titled Pro.