Refurbishing the Newtonian

"Newt" Raytrace for SPX350
“Newt” Raytrace for SPX350

I’ve been working recently towards finally completing the observatory dome in my back garden (that I bought almost 4 years ago now…) – with flooring done and power connected, I need just some steps, finish security and I can start to setup.

Attention has turned towards the Orion Optics SPX350 that’s been languishing in my garage awaiting use. I’ve known that the current secondary mirror doesn’t offer anywhere near enough completely illuminated field – and so I’ve finally measured the location of the focal plane  and using the excellent “Newt” software (now available as a web based app) and determined the size of a new secondary mirror for it. Yesterday I ordered a new 89mm secondary from Galvoptics that I plan to mount in a new secondary holder from Protostar (and hoping I won’t need a new spider :-/ ). This should give me a 100% illuminated diameter approaching 20mm – more than enough to cover the KAI2020 CCD chip I use, and good enough (with flats) should I decide to try upgrading to a KAF-8300 based camera in the future.

SPX350 - Primary Mirror
Primary Mirror – warts and all.

More importantly, the primary is going to need some work to bring it back to its full potential (the original zygo report says it is ~1/12 wave P-V) as even after washing off the dead moth remains (!) and flies, the coatings look to be past it, and there’s a load of spider poo stuck to the surface as well. Here’s hoping that they will clean off well and it’ll recoat fine – and so once I have the new secondary installed, a trip to Newcastle-under-Lyme will be needed in due course to look to get the whole thing serviced.

More to follow.

Debian Wheezy, Apache+FCGI+PHP; changes to /etc/mime.types and php5-cgi

Here’s a potentially useful note for anyone upgrading to Debian Wheezy on a system that uses Apache2 + FCGI + PHP. If you’ve configured it to run using one of several guides (like these:, then you might well be bitten by a similar issue to that reported in

Previously, one could define config such as the following in an apache2 conf.d file:

AddType application/x-httpd-php .php

AddHandler php-fcgi .php
Action php-fcgi /fcgi-bin/php5-fcgi

<Location /fcgi-bin/>
SetHandler fcgid-script
Options +ExecCGI

This would instruct Apache to use the handler “php-fcgi” to process .php files – with the “Action” referencing a wrapper held at /fcgi-bin/php5-fcgi (suitably aliased in the vhost). This all looks well and good and doesn’t appear to change between squeeze and wheezy (Apache is still at 2.2).

However, if you do a straight upgrade, you may find that your server starts serving out php files in plaintext (not only is your site down, but it’s a security risk as well with potential connection details listed in config files). In Wheezy, the php MIME types have disappeared from /etc/mime.types –  php5-cgi now includes two files (in /etc/apache2/mods-available) to try and correct the missing MIME type definitions. With php5-cgi enabled in the webserver, the config as follows is included:

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
SetHandler application/x-httpd-php

This sets the handler appropriately. With this set, Apache serves out the file as text, instead of using the relevant action “php-fcgi”  – the FilesMatch directive overriding the old config. The fix is reasonably simple – comment out the AddType and AddHandler in the conf.d file and change the Action line so you have:

Action application/x-httpd-php /fcgi-bin/php5-fcgi

In the case you just want sidewide php5-cgi with no suexec, then you don’t even need the above – in php5-cgi.conf in mods-available, just uncomment the last section of the php5-cgi.conf file – this has a similar “Action” directive to that above. I keep the above as I use suExec to run the fcgi processes under individual accounts (you’re unable to call outside of the suexec root, and it’s easy to repoint the fcgi-bin location appropriately in each virtualhost).

(Note that this type config appears also to be not vulnerable to execution of files of the type evil.php.jpg thanks to the FilesMatch directive in the module .conf)


Featured image adapted from work by W. Rebel (Wikimedia Commons)

Testing, Fixing and Costs

For those of you who don’t know me, you almost certainly won’t know what I do. Of course, there are probably a load of people who do know me, who still don’t know what I do (and, no, “Nothing” is not the answer). I work as a software tester and I have done for the last 7+ years now in a few different places.

cost_curve1Generally, this job involves a fair bit of evangalism – sometimes it’s quite successful (eg Promoting the use of Bugzilla as a defect tracking tool). One of my favourite diagrams is that shown in this post – I like this graph a lot. It is a graph showing the rough relationship between the cost of fixing a bug or defect, and what stage of the development process that bug or defect was found.

It’s fairly clear from the graph that, the later you realise there is a problem, the more it costs you to go back and unravel what is wrong and sort it. The reasons are fairly clear – if you find a problem at a later stage, you often have to go right back to the beginning of the process of development, testing and so on.

Some notes I like to make relating to this:

  1. Even if you are already employed by a company, you are not “free”. Having someone fix a problem, and work repeated costs money – “we already pay their wages” is not an argument! Sheffield Teaching Hospitals Trust – take heed (Quote from the Reg article: The trust argued that the consequences of its decision making had not cost public money, “just time and effort by the IT teams”.).
  2. Accurate. timely requirements are essential. Finding out that you have mis-specified something as it is nearing the release date is a Bad Thing™.
  3. Not having requirements before coding is asking for even more trouble.
  4. Changing requirements part way through the process (or, worse, finding out during testing that your requirements were duff!) is much along the lines of 2 and 3 with similar outcomes (moving goalposts anyone?).
  5. Doing unit testing is much better than sending code straight to the testers – it saves a lot of heartache on both sides…
  6. Actually having enough time to perform a sufficient level of testing can save you an enormous amount of hassle and cost.
  7. Squishing bugs as you go at the earliest possible opportunity is much advised – multiple bugs can quickly make a system unusable and costly to fix up. (There is another similarly shaped graph – see it as The Law Of Bugterial Infection)
  8. No one is perfect… not even me 😉

Feel free to use the graph above if you want and evangelise away…

%d bloggers like this: