Sunday, January 30, 2011

The Indium Includer and Class Loader

Indium comes with its own includer class called Core\Includer. This class contains a thin set of wrappers around PHP:s native include language construct. In an Indium application, every file system operation that depends on the include_path ini setting should be routed through Core\Includer. Of course, an application may choose to use include or file_get_contents directly, but this is neither supported nor encouraged.

Why does Indium encourage applications to wrap includes?
  1. First and foremost, we want to fight a potentially dangerous "feature" of PHP:s includer. If the specified file cannot be found in include_path, PHP will silently search the current directory and the directory in which the calling script resides. This behavior has unpredictable (run time dependent) security implications, encourages the generation of implicit dependencies and imposes an unnecessary cost in terms of file system operations. The only way to turn this "feature" off is to specify an absolute path, or a path which is relative to the current directory. Core\Includer scans include_path to determin the absolute path of includes before calling on PHP:s native includer.
  2. Controlling the scope inside which the include takes place. For reasons of encapsulation and security, Indium has to be able to decide what is visible to an included view.
  3. PHP:s includer is a swiss army knife. Wrapping and controlling it helps us in identifying common include idioms and providing standard, Indium blessed methods for carrying them out.
  4. We love classes. We want to encourage application writers to use classes. Applications should rely on Indium's Core\ClassLoader for autoloading.
  5. Lastly, wrapping includes enables us to impose strict validation on file names, which helps with tightening up security.


Okay, that's the Indium includer covered, on to the class loader. The Indium class loader provides a unified and highly configurable interface to class loading. It hooks into PHP SPL:s autoloading infrastructure and sits on top of Core\Includer. Essentially, the class loader provides a mapping from ( namespace path, class name ) tuples to include paths. Include paths may be searched to any specified depth. In addition the class loader has "magic" hooks for Indium exceptions and interfaces; these are automatically searched for in subdirs named "exceptions" and "interfaces". The best thing about Indium's class loader and includer is that the appplication need not really care about them. As long as your put your controllers and models in APPLICATION_PATH/controllers and APPLICATION_PATH/models, things are guaranteed to just work.

Core\Includer and Core\ClassLoader has proven to be a very strong and robust combination which gives a reliable and secure foundation to the Indium framework.

Tuesday, January 11, 2011

Ubuntu on an Acer Aspire 5000


Okay, this is just me posting the kind of blog post I wish I could have googled for before I installed Linux on my laptop. Would have saved me some time... I hope it comes in handy to someone else.


Hardware: [1]
  • Processor: Mobile AMD Turion 64 1600MHz
  • Memory: 1GB DDR SDRAM, 128MB of which dedicated to video.
  • Graphics adapter: SiS M760GX
  • Audio: RealTek ALC203 AC 97 Codec
  • Ethernet adapter: SiS900 PCI Fast Ethernet
  • Wireless network adapter: Broadcom Corporation BCM4318
  • Storage: Seagate ST9100822A Momentus 4200.2 100 GB ATA

Partition layout:



In retrospect, 4GB swap was really a mouthful since in practice swap is rarely touched. I could have gone by with 2GB for hibernation, but at least now I have room for that 2GB RAM upgrade...

32 GB for the root file system is a lot. I tend to accumulate a lot of crap in ~ so it's nice to have a safety margin. I made sure that /opt is large enough to contain a copy of /home in case I need to do something drastic with root.

Works out of the box:

  • Sound. Audiophiles would probably not buy this computer but the on board codec does the job for me.
  • Graphics, Xorg plays along just fine at native 1280x800 resolution. No configuration needed. No DRI, slow 3D!
  • Ethernet adapter.
  • Hibernation just works.
  • Touchpad. The first thing I did was disable "tap to click". My fine motor skills are simply inadequate for that.
  • 896 MB of memory is not terribly much but I find it surprisingly hard to provoke the machine into swapping.

Issues:
  • Fan control is borked in 10.10 (Maverick)! For some reason, the fan kicks in too late to prevent the CPU from transferring lethal amounts of heat to the graphics adapter, which overheats and freezes the computer. Solution: download Ubuntu 10.4 and hope this gets fixed in Natty.
  • Onboard SiS graphics adapter does not play nicely with frame buffer console. Solution: blacklist frame buffer console by appending the line "blacklist vga16fb" to /etc/modprobe.d/blacklist.conf
  • Wireless is some proprietary Broadcom crap which does not work out of the box. Solution: use wired connection, run jockey-gtk and install b43-fwcutter Wireless should be up on reboot.
Other than the stuff Casper installs for you, I installed sensors-applet for monitoring the temperature. Anticipating the Maverick move from f-spot [2].  I also installed the shotwell photo manager. For PHP development I installed apache2 and php5. I'm currently evaluating Netbeans 7 Beta [3] as my IDE, so I have installed it in my user directory. NB 7 needs the Sun JDK which I downloaded and installed to /opt/java

Other software sources I have added:
That's it, really. I will add content to this post whenever I stumble over some new issue.




Footnotes:
  • [1] http://support.acer.com/acerpanam/notebook/0000/Acer/Aspire5000/Aspire5000sp2.shtml
  • [2] http://linux.slashdot.org/story/10/06/14/0055221/Ubuntu-Replaces-F-Spot-With-Shotwell
  • [3] http://netbeans.org/community/releases/70/