Rather than pollute this blog with radio related stuff, I’ve started a new one http://m0hpj.wordpress.com/

My first post relates to a review of a selection of Amateur Radio apps for Android

Been there – got the t-shirt.

Download and manually install XHProf:

wget http://pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd ./xhprof-0.9.2/extension/
phpize
./configure --with-php-config=/usr/bin/php-config
make
make install
make test
cd ..
cp -rp xhprof_html /usr/share/php/
cp -rp xhprof_lib /usr/share/php/
mkdir /var/tmp/xhprof
chown www-data /var/tmp/xhprof

Optional – install graphviz for the Callgraph funtionality

apt-get install graphviz

Create /etc/php5/conf.d/xhprof.ini

[xhprof]
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"

Create/etc/apache2/conf.d/xhprof.conf

alias /xhprof_html "/usr/share/php/xhprof_html/"

Restart Apache

apache2ctl graceful

Configure Drupal in /admin/settings/devel

xhprof directory: /usr/share/php
xhprof URL: /xhprof_html

Now to get my head around what it all means!

Here’s my script (simplified – mine actually fetches 4 images and writes to two ftp accounts):

#!/bin/bash

# fetch images, store them locally
wget --user=#### --password=#### http://192.168.1.15/axis-cgi/jpg/image.cgi -O video2.jpg
# ... next images

# now push them to a webserver
ftp -in <<EOF
  open my.domain.co.uk
  user ##### #####
  bin
  put video2.jpg
# ... put other images
  close
  bye
EOF

Ideas I’ve had but not been able to realise yet …

1. Scour the wget manpage for some option to only overwite the output file if sucessful
2. Get wget to output to a temp file, wrap in script testing filesize to overwite the ‘real’ file if filesize > 0 bytes
3. Get wget to output to a temp file, wrap in script testing wget repose to overwite the ‘real’ file if response contains ‘saved’
4. Somehow put logic in the ftp script to only upload files > 0 bytes

100 years later, this story remains terrifying–not because it’s the local network block, but because the killer is still on IPv4.

Specifically, I’m trying to get Apache to enable external access to a webcam inside my network, where for some reason I can’t enable access to it directly using my router.

I’m now relatively confident that the appropriate way to do it is to enable mod_proxy and mod_proxy_http with sudo a2enmod proxy_http, this then allows use of ProxyPass directive within a vhost for example:

ProxyPass /webcam http://192.168.1.15/

• Maplin Electronics Catalogue – Early 1980’s and I’m a schoolboy having been introduced to electronics by the gift of an electronics kit one Christmas – of all the sources of information available to me the Maplin Catalogue had to be my favourite – I devoured every page, tried to understand every component and product and what they could do, and fantasised about building many of the projects – alas it was mostly fantasy and ‘window shopping’ – but I must have learnt something in those days. Strangely, there’s almost nothing on the Internet about them (other than other people looking) – am I the only one with fond memories of the 1980’s Maplin Catalogues with their futuristic sci-fi covers?
• I Robot – of all the Asimov books, this has to be my favourite, and I credit it with my belief that nothing is impossible – taking the premise of the elegant ‘three laws of robotics’ that you would think covered all eventualities, what would the result be of some unimaginable situation – of course with hindsight it all makes sense, but who could forseen a robot lying as a result of the accidental ability to read minds for instance?
• Programming the Z80 by Rodney Zaks – not that I did much Z80 programming – my first computers were 6502 based – but this book helped me take the fundamental leap from a basic understanding of digital electronics to an appreciation of the inner workings of microprocessors. I first learned to program on an Acorn Atom with 2K of RAM (yes, 2048 bytes!!!) and the disciplines of squeezing every last ounce out of available resources set me up for later career in embedded systems – I still enjoy the ability to work in assembler even though most of my time is spent in much higher level languages with unimaginable resources to squander. I wonder how the next generations of geeks and techies will cut their teeth in the fundamentals, in the age of ‘GUIs’ and ‘IDEs’ and ‘RAD’ and ‘frameworks’? Would anyone now be able to shoehorn a game such as Elite onto the meagre resources offered by the BBC Micro?
• CGI Programming with Perl – This was the main book that helped me take the leap onto the Internet – whilst I now predominantly use PHP I still have a fondness for Perl (perhaps related to my love of lower level languages as described above) and it was through learning how to use Perl as a CGI scripting language to develop dynamic websites that helped me understand the ‘pleasures’ of the Internet, client / server architectures etc. Again, I wonder whether the next generation of developers who don’t have to go through this process will get as full an understanding of ‘why’ to go with ‘how’?
• How to be Idle by Tom Hodgkinson – it’s probably a bit early to claim this as a life changing book as I’ve not yet finished reading it, but it symbolises a change I feel coming. I don’t know if this is a mini midlife crisis but I’ve recently been reviewing the way I life my life and my attitudes to the world and those around me. This book suggests that much that is wrong with the world comes from how unnatural the 9-5 ‘must achieve’ worth ethic is. Many quotes from philosophers, thinkers (and idlers) have been striking a real chord, and helping me come to the conclusion that it’s OK to be content with what I do achieve while living a happy life, rather than feeling guilty because of course I could work harder and achieve more yet be miserable.

One thing is for certain, I’m looking forward to finding out what the next phase of my life will bring, and wondering what the accompanying books will be.

Of course I would like to say that part of my apparent success is due to years of study and experience having given me the ability to ‘think like a machine’ – or more accurately to be able to appreciate at quite a high level what’s going on inside the little black boxes – but I would also say that another part is an innate stubbornness and determination not to be beaten by a sliver of silicon.

Some days, no mater how hair-brained an idea you come up with might be – it just ‘works’. Other times, even the simplest most proven task fights back and you get nowhere, or as is often the case seem to go backwards. But I hold a strong belief that if machines and the things they do for us are to be worth anything, they should work for us rather than us having to work around how the machines want to do things.

Of course I’m not really suggesting that there’s some deep ‘conspiracy of the machines’, or that they have to handled like some wayward puppy you’re trying to house train, but I would suggest that to succeed in getting the most out of machines you do have to persevere and for goodness sake don’t let them see any fear in your eyes!

On the one hand, you know you should apply updates as soon as you can to get any potential benefit of new features, bugfixes or even improved security and performance – but anyone who has been around long enough will know that even the simplest patch can upset an otherwise stable system and be a royal pain to resolve.

That leads to the temptation to procrastinate and put off updating systems until it can’t be avoided any longer, but the longer updates are left the more they build up, and the worse the process of updating becomes – again you may hear the sigh of bitter experience?

I’m not just talking about applications like WordPress and Drupal, or the dreaded Windows Update – there are so many constant reminders from all sorts of systems to ‘update now?’ And I’m talking about minor updates rather than the biggies like Vista -> Windows 7 or Drupal 6 -> Drupal 7 – those you have a choice, but minor updates you really don’t, it’s more a matter of ‘when’ than ‘if.

Here is a summary the guidelines that I try and stick to:

Have a regular ‘maintenance period’ – Accept that maintenance is a fact of life, and schedule an appropriate amount of time at least monthly to review logs, apply updates and other housekeeping tasks to maintain a healthy system. Of course this implies that the more systems you look after, the more time will be spent in maintenance, but that cannot be avoided – without tlc systems tend to ask for your attention when it’s not so convenient!

Don’t do updates on a Friday afternoon – As tempting as it may be to slip this task in at the end of the week if your ‘proper work’ allows, it’s tempting fate and if you have problems with an update you might not have enough time to resolve it, or you might shortcut testing and not spot an issue until Monday. Make sure you have set enough time aside to do it properly, and you’re in the right frame of mind.

Design your system to be maintained – when carrying out initial installation and configuration, think ahead to how you are going to apply and test updates and patches, and migrate changes between environments. Good decisions at the start make life so much easier six months down the line. Documentation and good naming conventions are key. And of course as part of your deployment there was a test plan that can be used to validate updates?

Prepare and maintain a documented maintenance procedure – It makes the task much less daunting to know that you have a ‘script’ worked out rather than having to keep re-inventing the wheel. Wikis are ideal for the purpose as they’re easy to create and maintain. Anything you have to spend time figuring out so that next time you don’t have to struggle to remember it, or work it out again. If you find information that’s wrong or missing, fix it, and keep documentation updated as your system evolves.

Read the release notes – try to get an understanding of what the update or patch you’re about to apply will change so you can analyse potential risks and identify any mitigating measures you might take, and to also identify what testing you can do to satisfy yourself all’s OK afterwards.

Once you start – don’t stop until you finish – it’s probably worse half applying updates than not applying them, and even harder to do maintenance next time. So no distractions, and remember the ‘not on Friday afternoon’ rule.

Pat yourself on the back afterwards – it’s a necessary job, so make sure you get your due reward. If you’re doing this for someone else (a client) make sure they appreciate the effort it takes, and don’t be apologetic about taking the time to do it properly. Few people notice a well running system, but you soon get shouted as when it goes titsup, so sleep well in the knowledge that all is right with the world again and you have done a proper job!