debuggable

Hey folks,

if you are running a company or know a company looking into hiring an excellent network engineer and server administrator, here is your chance to get your hands on Henry Acevedo.

Henry has been incredibly helpful while working as a contractor for Tim and Me, setting up several machines way beyond typical LAMP requirements. He is one of the most reliable and trustworthy people I have ever worked with and did an amazing job at picking up new technologies and things we threw at him.

He is currently leaving his job at NY Daily News and looking for a new company in NY, NJ or Connecticut to work for as a full time employee. Henry is definitely the man you want to hire if any of his skills are what you're looking for.

For more information view his resume or email him at henry.acevedo@gmail.com.

-- Felix Geisendörfer aka the_undefined

Hey folks,

sorry to interrupt the normal broadcasting schedule, but one article of this blog has gone crazy. Pretty much 2 years ago, I wrote a post called Hacking a commercial airport WLAN. It essentially documents an incredible stupid hole in the system of one of Atlanta's WiFi providers at the airport. Next thing I know is that suddenly a few days ago, we got hit by StumbleUpon, Reddit and even freaking lifehacker.com. Wtf. Traffic is through the roof and I'm surprised how well our little blog here is holding up to the load.

Anyway, what I'd like to do is to share the story behind the article with the people who normally read this blog.

Summer 2 years ago. I was flying out of Atlanta back to Germany after having stayed with my old host family there. My flight was delayed by 3 hours and I was borded and noticed some open wifi's around. Sure enough they wanted to charge me $7,99 for 24h hours of internet usage. Besides the fact that I didn't have a credit card back then, paying 30x the price of what my internet costs at home seemed to be quite a rip off. But even if I had a credit card back then, putting a lock on a box just gives it this compelling challenge. In this case the message sounded something like this: "Hey our Software has automated the process of ripping people off and there is nothing you can do about it!"

Nothing? I doubted it. There had to be a loop hole somewhere. I was hoping that by disabling redirects I could prevent being thrown back to their homepage portal every time I accessed a site, no chance. I tried a few things here and there, but nothing. Eventually I decided to look at the html of their portal and noticed they were including some of their images from an external site. A few minutes later and I turned this knowledge into a workable exploit. Well, that's if you can call appending '?.jpg' to every url you type in an exploit ...

Anyway ... the recent popularity if this posts scares me a little given the fact that I want to travel to the US in a week from now. Who knows, maybe I qualify as a terrorist now? Maybe I'll be interrogated about how I was able to pull of an attack against the sophisticated infrastructure of the USA? Anyway, I love the USA and I hope they'll continue to love me as well ; ).

-- Felix Geisendörfer aka the_undefined

Update: Shit, I posted this 6 seconds before loosing 50 bucks - that was close.

A long time ago, I promised to begin a segment on my blog where readers would send me challenges that they faced in their CakePHP development, or solutions they implemented which they felt could be more elegant. Continuing the great tradition of Wil Shipley, I will tear your code apart and rebuild it in my image, hopefully teaching you something along the way.

If you don't care for or about the way I write code, then you won't get much out of this, but if you use CakePHP, chances are that's not the case. Furthermore, you will hopefully, through this process, be able to get more out of CakePHP in your daily work.

To apply, the rules are as follows:

Send me an email at nate@cakephp.org with the phrase "code insults" somehwere in the subject.

You have to send me actual code. No theoretical problems, and no "how do I build a forum?".

You may send me anything from a few lines of code to an entire file. You don't need to send me your entire app (in fact, don't), but the code must at least already be working for you, so no broken stuff.

That's about it, but I may add more later. I figured it'd be an appropriate time to discuss this, given the recent talk of requestAction usage. So with that, let the submissions (and insults) begin.

Hey folks,

this is post #2 of my 30 day challenge. If you've ever written any non-trivial String processing code, you've probably ran into the situation where you wanted to exclude certain parts of your string for a certain operation. Usually that would mean you have to tokenize your string, or adjust the operation you want to run so it doesn't affect the part of the string you want to exclude from it. Both of those solutions can be fairly time intensive so I was looking for a shortcut and found one.

Let me make a practical example so this sounds less like hypothetical BS: Let's say you have written your own Textile-inspired parser, but you want to allow sections to remain untouched by the parser as well. My solution: Just substitute the parts you want to exclude from textile processing with UUIDs and put them back in afterwards:

I actually found having this little substitution method useful a few times in the past so I thought I share it ; ). Suggestions for improvements and other approaches are more then welcome!

-- Felix Geisendörfer aka the_undefined

PS: I have decided to allow myself to write my posts for the weekend the night before and have them auto-published. Otherwise my girlfriend is going to kill me ; ).

Hey folks,

this is post #1 of my 30 day challenge. If you have ever written a modestly complex application in CakePHP, you probably noticed that it is very tempting to use requestAction to glue together pieces from different controller actions. While initially that sounds like a good idea, I think requestAction should be avoided wherever possible.

Avoid requestAction in your application wherever you can - it will save you from terrible debugging nightmares.

For one, the speed penalty of using requestAction is quite prohibitive. The main slowdown is that every time you call requestAction, a full dispatch cycle takes place. This is pretty inefficient given that you probably already know what exact Controller/action you want to call up. A much bigger reason is that you will create a debugging nightmare for yourself. As soon has you have requestAction calls that invoke requestAction calls that invoke requestAction calls - you're screwed. If somewhere along the chain odd things happen (like a bug in your Auth system, some controller's / component's beforeFilter) debugging is going to become a major pain.

But worry not. This doesn't mean that you have to overload your dashboard / profile pages with ridiculous amounts of logic. The approach to use is to create named find calls and move all logic there. Once you have done that, getting the data for a complex view is simply a matter of making the right find calls and rendering a bunch of elements. You can even render other controllers views where it makes sense. For example lets say you want to re-use posts/view.ctp inside posts/edit.ctp to show the user a preview of the currently edited post. Instead of using requestAction, try this:

Again, there are some legitimate cases for using requestAction. All I'm saying here is that you should avoid creating an architecture that depends on requestAction at all costs. I've seen (and rewritten) applications that have gone that route and it has never been pretty so far ; ).

HTH,
-- Felix Geisendörfer aka the_undefined