A great tip:
When you go on vacation, set up an autoreply that says, “I’m on vacation until x/x/2010. When I get back, I’m going to delete all the email that arrived while I was gone, so if this note is important, please send it to me again after that date.”
Something I’ll try next time I’ll go on vacation…
Read the full story called 8 things I wish everyone knew about email.
On Wednesday the mysterious Apple iPad has been announced. Phase 2. And because a lot of people know that I’m an Apple fanboy and feel the urge to discuss “what does not work on the iPad and why it is crap” with me I’d like to finally outline a few thoughts about this device….
What the iPad is and what it is not
What I miss on the iPad
These features would make the iPad of real use to me and I think they are missing in the current version of the device:
Will I buy it?
Let me quote someone here:
To hell with it! It’s not something I need. It doesn’t solve any problems I have. I can resist. I am strong. I may be “Mr. Mac,” but I am also “Mr. Practical.”
Which is exactly what I said when the iPhone came out. 3 days later I was in the Apple Store eagerly holding out my credit card to anyone who would take it. (source)
So: I don’t know yet. Most probably I’ll skip the first generation and wait for an upgrade. It is also depending on the iPhone 4 which is to be released this summer (yes, my contract is finally over!) and what features it offers. And of course what features Apple will add to the iPad over time…
Unit-tests are what saves a developers ass – and each app should have them, if it makes sense. So it depends 
But for the project I’m working on right now it made sense, the perfect subject for unit testing. Or do you remember almost 100 different cases and conditions which might break if you change code? In my case I rewrote about 30% of the servlet code to be better structured and being capable of implementing a new requirement. Large parts where Spaghetti code without class inheritance or good usage of objects… subject to be thrown away or rewritten.
After trying the code for the first time after the rewrite the simple, LWP based unit tests immediately showed me where I had to “tweak” the code – and now that they again show a green PASSED I’m confident that it really works in production as well.
That’s how it should be – being confident that changes did not break any other part of the code.
Unit tests are way cool!
Logwatch is a very flexible and customizable log watching system for lazy system administrators. It checks the logfiles regularly and sends custom mail reports – very useful and way better than daily manual checking of the logs.
Unfortunately the configuration for MySQL, PHP and the Apache error_log is missing; so let me share the configuration scripts:
Logwatch configuration for PHP
Interestingly there is no logwatch configuration for PHP error_log files – and all a search revealed are some outdated files which don’t work anymore. Here are the adopted files that allow you to get notified about PHP errors:
Logwatch configuration for MySQL
Also a configuration for MySQL is missing in the default configuration; here are the configuration files:
Logwatch configuration for Apache’s error_log
Now hat really made me wonder is the at the httpd access_log is monitored but the error_log is left out, so no details about errors are included in the logs. This configuration ignores PHP errors and includes all httd errors in the logwatch output:
To test that the individual scripts work use this command:
/usr/sbin/logwatch –detail high –print –service $SERVICE –range today –debug 0
Replace $SERVICE with either php, mysql or http-error and set debug to 5 if you want to see more (but not too much) debugging information.
All the logwatch configuration scripts for MySQL, PHP and the Apache error_log can be found here.
Update: There was an error in the scripts_mysql file, fixed now.
While the follow up article of “Must-have tools for HTML, JavaScript and AJAX development and debugging” (which has also been translated to Chinese, Japanese and Korean) is not written yet I want to share a useful trick that helps debugging live Web applications by injecting custom files into them.
The problem is how to test a new version of a JavaScript library on a production system without even touching the system itself in any way. Testing with local copies of the HTML pages work fine for a few files but does not scale very well, and staging systems might not be properly configured or really tell you if something works on the production system (bugs always just happen in production, right?).
Another problem with debugging JavaScript on production system is that the files might be compressed, which makes debugging in Firebug almost impossible – variable names are shortenend and line numbers don’t make sense any more – would be great to have the uncompressed version instead…
The solution is using a local proxy and replacing certain requests with local files. That way custom files can be injected based on regular expressions and tests can be performed on the production site or even on sites without access to the system itself.
While Fiddler works great on Windows and Charles Proxy does the same on OSX I want to present the poor man’s solution which makes use of any local Apache installation (i.e. MAMP).
The required changes in the httpd.conf are:
# Enable proxy requests
ProxyRequests On
ProxyVia On
<Proxy *>
# Secure the proxy to allow localhost requests only
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1# replace some files with local copies
RewriteEngine On
RewriteRule myfile.js http://localhost:8888/test/myfile.source.js [P]# Disable caching
ExpiresActive On
ExpiresDefault “now”
</Proxy>
Lets go through the changes line by line:
The first two lines enable the Apache Proxy support (ProxyRequests On); the <Proxy *> block then configures the proxy further. As stated in the documentation multiple times it is a good thing to secure the server, that’s why only access from localhost is permitted. The important part are now the RewriteRules – they proxy certain requests to the local server instead of the remote server, in the sample above all requests that contain myfile.js will be replaced by the version served from the local server. This could as well be any other remote machine serving the file, as the request is proxied again ([P] flag). Finally caching is avoided by setting all files to expire right now (while this adds more load to the proxy it is not that bad to do during testing).
Now the proxy has to be used in the browser or application of choice; once the proxy settings are changed within the networks settings the access log of Apache should become quite busy when browsing around and, depending on your mod_rewrite settings above, some requests should be replaced with the local copy of a file, making debugging way easier.
Of course the drawbacks of the poor man’s solution are that Apache has to be reloaded in case the RewriteRules change and changing the configuration is not as comfortable as with the dedicated proxy solutions mentioned above. Nevertheless this solution works, is fast and very reliable… and free
Until today I did not know that data centers can be that cool – but check out this article about the server location in Stockholm. Looks like directly out of a James Bond movie:
In my opinion the provider Bahnhof built one of the coolest data centers ever – let’s see what Google builds up in Austria.
My EAR package worked fine, until tonight during the deployment to another server infrastructure. How hard can a simple EAR update be? “Could not find symbol” somewhere next to a simple line initializing log4j. It complained about missing the Logger class.
A check in the EAR file revealed that the required jar files are all there. Still this error. But why?
Finally I figured out that the manifest file included all of the required libraries in the classpath but missed the “.” to include the current directory as well, after adding it everything worked out:
Class-Path: log4j.jar lib.jar .
Took some time to perform a simple upgrade of an existing EAR file… because of such a simple error – so ensure your MANIFEST.MF file contains the dot!
To have my data secured I run (almost) daily backups using a custom script to my NAS system. Over there, at the great, little Linux box, runs a script that does daily increments using rsnapshot. There is also another script that keeps a copy on an external WebDAV server up-to date.
Implementing this was not that simple – as the NAS itself does not support mounting WebDAV servers natively I had to use a PHP script, which required patching the PEAR WebDav Client (digest auth, block size, stat entries) but eventually I got it working at a reasonable speed (8k block size does not make sense for a HTTP based protocol!). The big benefits – my computers don’t have to run to upload the data, the NAS is doing that work and it is running 24/7 anyway.
End of story, zero maintenance required.
Until I tried to switch from Bingodisk to Apple’s iDisk.
For some reason the backup on the iDisk always included hidden files, despite the fact that they have not been changed and already existed on the disk. Some simple investigation has shown that the iDisk server simply did not return any file that started with a dot (.). But why?
Packet sniffing revealed that there are some differences between the PHP request and the one sent by OS X, but even after modifying the PHP code there were no hidden files included. Last difference – the mysterious X-Source-Id header – but adding that also had no impact. Eventually, after digging in the source code, I figured the change that is needed – as stated on top of the InitUserAgentHeaderValue function:
IMPORTANT: The user-agent header MUST start with the
product token “WebDAVFS” because there are WebDAV servers
that special case this client.
Clear, concise and exactly what I needed to do – as soon as I sent this header iDisk responded with a file listing including hidden files!
I still have no clue why iDisk makes this difference, but it is good to know how to be able to run full backups including hidden files over WebDAV!
Since the review of Todo and Things a lot of things happened (and I don’t mean the US elections!) and recently a new Todo application has been added to Apples AppStore – the Remember The Milk app for the iPhone. Time to compare it with Appigo’s Todo application, which I use since September and was updated several times since then.
Remember The Milk for iPhone
It was just a matter of time until RTM would launch their own application. And while Todo can also sync with RTM this app is of course highly optimized for the own service. It features everything needed for GTD so I just want to outline the postive and negative highlights:
Todo (Appigo)
Since the last review two new releases have been published by Appigo. While the first one “only” contained bug fixes and translations the update to version 1.4 introduced a lot of great new features:
Whom to choose this time?
Based on the pros/cons above the USD 25,- price tag for the Remember The Milk application seems a bit high to me. Certainly you get a lot of options and access to one of the best GTD list managers out there. Nevertheless if you already have a working system it is not worth switching and migrating all your tasks, especially because both Appigo and Toodledo are updating their products constantly.
If you start from scratch also check out Toodledo for the iPhone, which supports all features available but yet has to proof that it is working as reliable as Todo.
Happy Foto ist ein qualitativ sehr guter Anbieter von Online-Ausarbeitungen welcher (als Ausnahme am Markt!) auch eine Mac-Version seiner Software anbietet. An sich wirklich sehr löblich nicht nur auf Windows-User zu schauen. Leider lässt sich diese Software auf meinem System aber nicht starten – in /var/log/system.log wird nur folgendes ausgegeben:
2008-10-21 10:28:01.810 HappyFoto-Designer 1.0[12134:10b] -DCI_USE_SETCURRENTCONTEXT_NIL=0
2008-10-21 10:28:01.811 HappyFoto-Designer 1.0[12134:10b] -DCI_WORKAROUND_CICONTEXT_MAPTABLE=1
2008-10-21 10:28:01.811 HappyFoto-Designer 1.0[12134:10b] -DCI_WORKAROUND_CICONTEXT_MAPTABLE_VIA_CG=0
2008-10-21 10:28:01.812 HappyFoto-Designer 1.0[12134:10b] -DCI_FORCE_SOFTWARE_RENDERER=0
2008-10-21 10:28:01.812 HappyFoto-Designer 1.0[12134:10b] -DCI_FORCE_SOFTWARE_RENDERER_VIA_ENV=0
2008-10-21 10:28:01.872 HappyFoto-Designer 1.0[12134:10b] Unable to load nib file: MainMenu, exiting
Sehr lästig, das Programm-Icon verschwindet nach rund 2 Sekunden wieder. Das wars. Keine Fehlermeldung für unerfahrene Benutzer. Grund ist laut Hotline die “ungewöhnliche” Spracheinstellung meines Systems – Englisch. Nun ja, ich verstehe ja, dass Happy Foto nicht alle Sprachen dieser Erde unterstützt, aber das Programm sollte zumindest in der Standardsprache Deutsch starten, falls keine Lokalisierung verfügbar ist.
Der Helpdesk konnte nicht weiterhelfen – “Umstellen auf Deutsch” ist aber nicht wirklich eine Option für mich. Hier also die Lösung für alle die den Terminal starten und bedienen können:
cd HappyFoto-Designer 1.0.app/Contents/Resources
cp -R German.lproj/ English.lproj
Das legt eine Kopie der deutschen Sprachdateien an und fortan startet der Happy Foto Designer für den Mac auch auf einem englischem System. Endlich ist der Happy, der Foto Designer!
