Test::Class::Most

Test::Class::Most.

Mobile Apps mit PhoneGap -> Vortrag@Mayflower-München – ThinkPHP /dev/blog – PHP

Am kommenden Donnerstag, den 04.02.2010 findet wieder ein öffentlicher Vortrag im Mayflower Büro in München statt (Mannhardtstraße 6, S-Bahn Isartor).
Beginn ist um 18:00 Uhr, Thema des Vortrags ist “Mobile Apps mit PhoneGap“.

Thorsten Rinne zeigt, wie man mit Webtechnologien (Html, Css, JavaScript) mobile Apps für iPhone, Android, Blackberry und Co. entwickeln kann und weist auf die Unterschiede zwischen PhoneGap, Titanium Developer und anderen ähnlichen Plattformen hin.

Die “Donnerstags-Vorträge” werden sowohl in München als auch in Würzburg gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!
Wir freuen uns auf viele Teilnehmer!

Thomas Vander Stichele: A Google ad with the National in it ?

Weird. But good weird. Here it is.

Thanks to Ticketmaster I have 0 tickets for their show in London. But I’ll still be buying their new album come May.

Python News: Python 2.5.5

2.5.5 is now available for download.

Mike C. Fletcher: Didn’t even think to enable epoll in Twisted+TG

Enabling the epoll reactor in Twisted is a two-line change:

from twisted.internet import epollreactorepollreactor.install()from twisted.internet import reactor

From there on the app is unchanged. I didn’t have time to really test that today (paying work and all), but I don’t really expect to see much of a change. EPoll is about scaling up, and my current speed annoyances are all about single-query latencies (I see most queries taking 300-430ms).

Anyway, I’ve got more paying work to get done this week, so the ChatTrack stuff is going to have to wait a bit. It needs to be done for PyGTA’s PyCon Dress Rehearsal on the 19th at the latest, but I can likely get another 2-3 days between then and now, maybe as much as a week if I finish these projects with few speed-bumps.

Mike C. Fletcher: Specs can really suck the life out of you…

Just spent hours tracking down the "DOCSIS TLV" config-file format and implementing it. This is one of those things where the project spec says "do what that spec says to do", pointing you at a deprecated version of the big spec, then the updated version of that spec says "do what this other spec says to do", but that spec is then defined in terms of 2 other specs… an enormous amount of reading to specify something that can be described in a tiny amount of code.

The key thing that gets left out AFAICS is that the spec is recursive; so for option 43.1, 43.2, or 43.3.4.5.2.3.4.5.6, for example, you do all of the encoding steps as though you were doing a top-level encoding for the various named (numbered) sub-options at each level, then you break the resulting (potentially very long) value into 255-byte chunks of top-level encodings. For instance, our last example there with a value of ‘hello’ looks like:

[43,21,3,19,4,17,5,15,2,13,3,11,4,9,5,7,6,5,104,101,108,108,111]

Once you actually get all that, it’s one of those relatively simple specs that likely should just be wrapped up in a standard library… but that would be hundreds of times more work than putting together something that can do what you need for this tiny project.

There are likely stupid little corner cases, such as whether to do splitting of long option-values only at the top-level, or whether you are intended to also split them in the recursive elements if an individual sub-element is > 255 chars. There’s also some checksums and the like, basically just some sha1 hashes.

The fact that you need lookup tables for all non-trivial interpretation makes the whole thing look way too messy to bother with beyond the needs of your clients of the day. In the example above, unless you know that 43.3 has internal structure you can’t parse the result meaningfully. It might just as easily be a single long string. The T (type) in TLV is just a single-byte-integer reference into the current table space, not a direct data-type value. Those tables are vendor, and potentially even project, specific, so you then need to create a mechanism for users to define the tables… ick. Makes one appreciate context-free formats all the more.

Fabio Zadrozny: Pydev 1.4.6 released / Google App Engine on Pydev video

Pydev 1.4.6 has just been released.

The major highlights in this release are:

The project and interpreter configuration was improved:

The pydev package explorer will now show problems in the project configuration (until now, those misconfigurations wouldn’t be properly shown and some subtle problems could arise because of those misconfigurations);

The project pythonpath can use variables;

The interpreter can be referred from a user-given identification.

There is an easier way to create and manage a Google App Engine project in Pydev. The video below shows how to properly config/upload/manage it from Pydev:

hmm, Nordic Perl Workshop…

It came to my attention via brian d foy’s blog post that the next Nordic Perl Workshop will take place in Iceland – which sounds very interesting. At the same time I decided that I need to take a longish break after working very hard for the last two y…

Michael Foord: A Little Bit of Python Episode 3

A Little Bit of Python is an occasional podcast on Python related topics with myself, Brett Cannon, Jesse Noller, Steve Holden and Andrew Kuchling. We still don’t have our own website although that is due to land any day now. … [172 words]

How to turn bad code into good code – Stefan Priebsch

Want to learn how to turn bad code into good code, and master the full software development cycle, from good design to successful deployment of PHP applications?

« go back — keep looking »

Enterprise LAMP