Sunday, February 13, 2005

zsync

Yet another OS package that might be helpful in our distributing mechanism. It's an interesting alternative to rsync and other MD5 checksum based methods. Although, how many times do we really want to 'update' a file like zsync can do very well.

Nevertheless a note to self: zsync

Using ACLs with Fedora Core 2

Another link that justifies to use BlogThis... This might solve a lot of our problems with regards to running a Linux server in a Windows PDC environment. Linux permissions are too restrictive; ACLs might solve a lot of issues: Using
ACLs with Fedora Core 2


And very simple to implement with FC2: Remounting a partition other than /, /boot or swap with the acl option, enables you to define ACLs on files and directories. Wow, that easy? ;-)

SourceGuardian (PHP Encoder)

We seem to need this (or something equivalent) to protect our main external project. Consider this a note to self ;-) I am curious how it works though, as no server side changes are required...

PHP encoder - protect and secure your PHP code using encode, encrypt and obfuscate

Thursday, February 03, 2005

Spettertuitje

Today I introduced B to world of Spettertuitjes, PlatHandjes en Keppelkopjes. The world of dry humor; so dry that a camel would get thirsty hearing about it.

At the office there is a group of network specialists that form their kind and speak a language of their own between themselves. A language that (as I learned tonight) can only be understood if one can appreciate dry humor. The Monty Python kind. Fawlty Towers Nudge, nudge, know what I mean, know what I mean. That kind ;-)

For the Dutch readers among you, I can recommend Het Ganzen Gebeure. The beautiful report on how gees can be called names and be funny... Don't think B particularly found this funny ;-)

Back to some serious stuff. In my department, we set a goal for becoming more release driven in our application management. With web based application development we have noticed it has become really simple to promote certain enhancements or bug fixes to production. Lots of times, testing is done by the developing collegue and not verified by one of the other team members. Resulting in required hotfixes after these quickly released updates. Using a certain development, testing and release cycle we imagine we can formalize all of the the things that need some formal way of dealing with. We've chosen to (initially) use a three month release cycle for one of our external products and a monthly cycles for all our corporate applications.

To get ideas on how to come to a reasonable and well composed roadmap for our applications, I decided to browse through the roadmaps for Mozilla, Firefox and Gnome to get a good idea of how those guys have set this up. Of course Mozilla was the most complicated one, but Firefox looked as if they had their things put together well. I like the idea of using the terms DPR (Developer Preview Release) and PR (Preview Release). The former basically a non-feature complete alpha quality code base and the latter a beta-like quality release that could be tested by the public. Especially for our external product that would be a good way doing things. We could throw in a RC (Release Candidate) that could be tested by a handful of customers. before updating all our customers.

Another breakthrough todat was the stumbling across OpenAFS; a distributed filesystem that we have been lookng for for our external product again. Maybe we could even deploy something similar in our corporate production environment? Definitely worth looking into.