Step 1: VirtualBox

Do you have a MacBook? Great. Do you use Ubuntu? Perfect. Are you running on windows? Super!  But just DO NOT USE your own distribution’s PHP / packages. There are actually good reasons for this:

1. You can easily work with multiple versions of the components (PHP, Apache, Nginx, MySQL etc) without affecting the rest of your (base) system. Especially when you are working with 3rd party systems like Zend Server, things can go downhill really fast if you need to switch from project A to project B since it might involve downgrading packages on your system (which is annoying at best)
2. 9 out of 10 times you are not running on the same OS as your production server will be. Now this isn’t necessarily a problem, but the closer you can mimic such an environment, the better since it will result in less problems during testing and acceptance.

Leave your system as-is, and run through virtualBox. If you don’t like it, try it anyway as I will explain later why. VMWare Fusion might also do the trick, but has some downsides.

The way I’ve setup my box is like this:

I have 2 different base templates: a Debian 6.0 template and a CentOS 6.0 template. Besides those templates, I’ve got a single Debian 6.0 server running which is my “global” project machine. Every project that doesn’t need their own VirtualBox (because it’s a simple project, or a project that doesn’t need any 3rd  party components), I create that project on my global machine. Otherwise, I either clone the CentOS 6.0 or Debian 6.0 template. Now here is why you should use VirtualBox instead of VMWare: you can actually create such machines from scratch with the help of Vagrant, which allows you to automatically create and setup virtualboxes from standard templates already available on the internet. Check out http://vagrantup.com/ and http://virtualbox.es for more information, but for now, let’s just assume you use the standard templates like I have, which are nothing more than simple netinstalls of the distribution, with some of some standard tools installed while doing development like ssh/strace/mc/systools etc.

So: need a quick project: use the global development machine, otherwise, clone a new machine and use that one. They are not killing your performance, they are not eating away precious resources and you can have multiple open at any single moment. I run most virtual machines with 512MB of memory (sometimes more when I need to do stuff with data), and I can still have 5+ machines open at any single time on my MacBook without noticing any downside or any lag.

Using this will isolate everything perfectly: you need to work on a PHP4 legacy application? No prob: just fire up a virtualbox with a PHP4 installation and start developing (assuming you are about to port it to the latest PHP version, right?). You can even work on several projects at the same time. Your boss will love it!

Step 2: Virtualhosting & DNS

Now, we have our virtualboxes which all have a connection to the outside world through the “Bridge mode” network adapters. One annoying fact of virtualbox is that you need to connect your Vbox adapter to a physical adapter in your computer. For instance, on my macbook I have to connect adapter 1 to my ethernet adapter. But when I’m connected to a WiFi system, the virtualboxes cannot use the internet. That’s why I have two bridged adapters: adapter 1 for ethernet, and adapter 2 for WiFi. No matter how my MacBook is connected, the virtualboxes still have connectivity to the outside world (although it might require a restart of the network interfaces sometimes).

The other adapter  I have is the Host-Only adapter. This allows me to communicate with my virtualboxes on a private subnet (192.168.56.x in my case). I use this for remote debugging and file sharing which we come to later. Normally, the bridged adapters get their IP addresses from a DHCP server you are running at home or at your company network, but you can also opt for some static IP’s if that makes your life easier. I normally do not care since I do most of my work through the private subnet.

VirtualBox also runs a DHCP server for its host-only (192.168.56.x) network. I don’t think (never actually checked though) if there is a way to bind IP’s to your virtualbox MAC addresses, so I normally use static addresses. My global development server is running on 192.168.56.101, all other machines have different IP’s.

Now that we have network connectivity, we can talk about HTTP. On project-specific boxes I just use standard vhosts and everything, but on my global box this is a pain to work with. I don’t want to spend time setting up new vhosts, or create some tools that generate vhosts for me or such.. And I don’t want to place EVERYTHING in one big vhost / documentroot. Apache actually had got a nice feature called “virtualDocumentRoot” that allows you to create virtualhosts on the fly, so to speak.

<VirtualHost *:80>
  UseCanonicalName Off
  VirtualDocumentRoot     /wwwroot/%1/public

  php_value suhosin.srand.ignore 0·

  <Directory /wwwroot>
    AllowOverride All
  </Directory>
</VirtualHost>

To use the virtualDocumentRoot directive, you must enable the mod_vhost_alias module. For more information, take a look at the documentation at: http://httpd.apache.org/docs/2.3/mod/mod_vhost_alias.html.

So what this does is setup dynamically virtualhost. It will take the first part (%1) of the URL (for instance: the “projecta” for the url http://projecta.example.org), and use /wwwroot/projecta/public as the document root. In essence I can create a directory /wwwroot/<myproject> and it will automatically be up and running. However, I use the /public as an extra directory so that would be my public webroot. This means that my framework and other components I don’t want to be inside my documentroot to be at /www/myproject, while my index.php, css, images and js files live in /www/myproject/public.

With this setup, creating new projects has become literally a five-second job.

Setting up DNS

Because we didn’t specify a server-name inside our virtualhost, and this actually is the only virtualhost available, everything that points to port 80 on the global development virtualbox IP (192.168.56.101, if you have kept track), will automatically use this virtualhost. So what I’ve done is setup a development DNS (which actually is a live domain), and let a wildcard point to this IP. This means that outside my notebook, it isn’t much use for others, so I prepend it with a subdomain.

This means that I’ve created an A-record:  *.dev.mydomain.com A 192.168.56.101.

At this point, if I go to http://projecta.dev.mydomain.com, it will resolve in 192.168.56.101, it will be picked up by the virtualhost and use the virtualdocumentroot /wwwroot/projecta/public. If I go to http://whatever.dev.mydomain.com, it will go to /wwwroot/whatever/public. Sweet!

If you need separate project boxes, just create another A-record (or update your /etc/hosts file) and point to the corresponding 192.168.56.x IP).

Step 3: Setup your tools

Now that we are able to connect, we need to start developping. Some will try to use the “shared folders” option that VirtualBox is able to. I don’t. I never really liked it, and for all my purposes, I just use a global samba share pointing to /wwwroot for doing all work. This means I don’t need to fuss around with strange FTP-uploads everything I modify a file, and my IDE is perfectly happy as treating it as a local filesystem since it doesn’t know any better. If you use VIM or another editor, you can work directly from the box through SSH (I always have Iterm2 open to the boxes). Samba is fast enough when using locally on your system. Even things like searching through your projects isn’t a real problem. Especially when you are running from an SSD, but even with a normal SATA drive, I didn’t notice any problems, even on large projects with the Zend of Symfony frameworks.

So connect your samba share to /wwwroot, mount it to your local /wwwroot, create a W:\ drive, whatever. At this point, creating a directory automatically creates a new project.

xdebug

Please, pretty please with sugar on top, if you don’t use XDebug, install it and try to use it. It will make your life easier and development / debugging faster. I know it will be hard to not use print_r() and var_dumps & die(), but really, don’t do that anymore. XDebug is so much better in doing a debugging job than you ever can with print_r.

Installing XDebug is a breeze and most distributions come with a pre-compiled XDebug package, so an “apt-get install php5-xdebug” or “yum install php53-xdebug” should be more than enough to get it up and running. Note however, that you have to change some settings in XDebug to get it up and running for remote debugging:

xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.idekey = "PhpStorm1"
xdebug.remote_port = 9000
xdebug.remote_handler=dbgp
xdebug.remote_autostart = 1

It basically tells XDebug that whenever it has been started, it must connect to the debugger that is running on the machine that is requesting the page (basically, it connects back to $_SERVER[REMOTE_ADDR]:9000). We talk about connecting XDebug in the next section, for now it’s enough to realize that XDebug will *always* try to connect to a remote debugger because we have configured “xdebug.remote_autostart = 1″. Some might not like this, and want to manually start XDebug. This would mean you have to set the option to 0, and issue a XDEBUG_SESSION_START=<idekey> to start the system automatically. Most browsers have extensions that actually makes it easier for you to do this. For instance, the FireFox extension “easy-debug”. But on the whole I really like the autostart feature, since I don’t have to worry about browsers. Every call, even from curl or standard telnet, will trigger XDebug.

Step 4: Set up your IDE

Now, we should setup our IDE. I personally like PHPStorm, but any other would probably work too (netbeans, eclipse, aptana etc). Since we have connected our /wwwroot directly into our main machine, we can just create new projects inside this directory by creating a subdirectory. PhpStorm saves all project information inside a hidden “.idea” directory inside the project root, but I normally let my version control system (git normally) ignore this by adding the directory to the .gitignore file. For SVN users you can issue a propset svn:ignore to ignore the directory (if you don’t use a VCS, shame on you!).

Now, the only thing really left to do is setting up remote debugging. With PhpStorm, this is a breeze: just hit the menu “Run | Start listening for PHP Debug Connections” and you are good to go! There is a shortcut on the toolbar (the red phone), that turns green when remote debug listening is enabled. What it does is opening a port (9000) on your local system. Since we have ordered xdebug to create a remote connection back to the requesting client, it means that when we start listening for connections, and we hit refresh in our browser, xdebug will automatically connect to phpstorm. You can set a breakpoint at the beginning of your index.php (or other entrypoint) to see  xdebug in action.

The only thing that you need to make sure that you setup your path mapping correctly. Sometimes it cannot find the correct source-file to debug. For instance: your PHP file does a “include(“../test.php”)”, it only knows that you want the file /wwwroot/yourproject/test.php (assuming that you called the include file from /wwwroot/yourproject/public/index.php). XDebug will “tell” your IDE that it needs the file /wwwroot/yourproject/test.php.

Now, your IDE doesn’t know anything about /wwwroot/yourproject, since that is the directory on the REMOTE filesystem, which may or may not be mapped differently. On a windows machine, your IDE might know this file as W:\yourproject\test.php, or on your ubuntu machine, /mnt/wwwroot/yourproject/test.php, or on your macbook /Volumes/wwwroot/test.php. So you must tell PHPStorm to map the file to the correct directory. Luckily, PHPSTorm will tell you that it cannot find the file, and gives you the opportunity to map the file. What I normally do is not map that file directly, but map the root-directory. So I will tell phpstorm that the remote “/wwroot/yourproject” directory is locally mapped to “/Volumes/wwwroot/yourproject”. From that mapping, it can deduce where all other files inside your project are so you would only need to do the mapping once (I don’t know if you can create a global mapping in phpstorm: /wwwroot to /Volumes/wwwroot, because that would mean that phpstorm would always find the files, regardless of project.

Conclusion

That’s it, really. There are all kind of nifty things you can add yourself, like using VCS through the IDE, but I prefer command line so I always have a iTerm open to do the git-stuff. And I’ve got a global alias for /phpmyadmin, so I can always directly goto my phpmyadmin screen (yeah, sue me) and some other nifty stuff. On the whole, it’s a very easy setup that works pretty well. I can do symfony2, zend framework side by side without problem. I have a simple setup of memcache, mysql, and other components on my global machine to test stuff and when doing more powerful jobs, I clone a new machine and work from there. It’s easy, fast, and really isolate your work. And I truly work on two or three projects at once, on different PHP versions as well, so isolation like this is perfect, although I assume you all have other ways of setting up your development environment. Do you use this kind of isolation? Do you have another way of setting up projects? Do you use vagrant and/or puppet to maintain your machines? I’m curious on how to improve my system, and how yours work, so do leave a comment :)

Nevertheless, looking back at the plan, a lot of it has been achieved, even though some not quite as I planned. Let’s go over the list:

Broad Goals

Certify for LPI 301 – and at least 2 (30x) specialties.
Status: did not succeed.
Reason: I’ve actually scheduled these exams and had to reschedule three times before I decided to cancel them. There wasn’t enough time for me to actually do some studying (since I don’t know everything (yet) there is to know about LDAP).

Certify for MySQL Clustering.
Status: did not succeed.
Reason: Again, I’ve scheduled this together with the LPI-301. But afterwards found out that the exam materials (the book itself) isn’t available anymore. I find it strange that the exam itself is still given, but after looking at the syllabus, I’ve decided I would drop this exam on the grounds that it’s worthless.

Trying NOT to be part of everything (hard to do).
Status: did not succeed.
Reason: There are many nice things, and I like them all. Writing a patch here, submitting a pull request there. Writing program A, B AND C at the same time.. It’s horrible! I really need to focus less projects.

Getting more articles published.
Status: success!
Reason: More articles have been published in PHP|architect magazine. And once in a while, when I feel up to it, and they want some articles, I’m happy to write an article about – something.

Finding out if ANYONE is interested in co-writing a book about Operating Systems programming.
Status: success!
Outcome: nobody is interested :-). However, writing a book is something that is currently in progress, and I’ll probably can tell you a bit more about it very soon… (secretsesss)

Writing more blog posts on CybOS.
Status: did not succeed
Reason: I haven’t spend much time on CybOS, but I’ve managed to finish up enough to place it online on github. So it’s out there for everybody to take a look at the internals of an OS. However, more stuff should be written about it.

Attend FOSDEM 12
Status: will not succeed
Reason: personal plans interfere for me to come over.

Attend Confoo 12 (as a speaker preferably)
Status: did not succeed
Reason: I blame Anna Fillina for this (no, just joking). However, seeing the schedule makes me even more sad I won’t be attending. But there is always hope for next year.

Attend Tek12 (as a speaker preferably)
Status: will succeed
Reason: I’ve been selected as a speaker and will be talking about three very neat subjects.

Attend Loadays 12
Status: no clue
Reason: It might interfere with another conference.

If I read books, at least review them on my blog.
Status: succes!
Reason: On occasion I do read some (marvelous) books. So I’ve tried to do some blogging about it. Truth be told that I don’t really know much about reviewing books, and most of the time it’s not a long post about the actual book. Somehow, reviewing books isn’t my forte so I’m not sure if more will follow.. sorry :)

Read up on the following (new) techniques

Read up, and do more work on some interesting Apache TLP projects like:
Apache Couchdb – very done.
Apache Hadoop – done.
Apache Mahout – haven’t done, except for some basic reading up and fiddling around with it.

Areas to investigate

Write more blog posts about different subjects in both development and system administration.
Status: Meh
Reason: I think I could make more time blogging about the things I do a bit more..

Find out more about devops in general.
Status: done
Outcome: fascinating stuff and probably the way to go.

Learn more about puppet.
Status: done
Outcome: spend the last year knowing a lot about puppet and being able to teach to others (which is the only way to know for sure you get it as well). Love the system and we WILL see more of this in the coming years in the PHP-scene as well.

Grasp (not only program) the stackbased context switching system.
Status: success!
Outcome: I get it know.. And yes.. there should be a blogpost about it…

Knowing git
I’ve read the git internals twice, and so did I with the pro-git book. Last year was actually the first year I’ve started to use git for work, and loving it! I don’t think that A) I like spending time in SVN and B) have anything that is not .git’ed (even my book is currently versioned by git). After reading the internals for the second time, things actually made much more sense than the first time I’ve read it :)

Do more with iSCSI.
Status: did not succeed
Reason: mostly because iSCSI didn’t really crossed my path last year. There was some preliminary stuff I did with vsphere and some SAN setups, but not enough.

Development

 Get newlib compiled and run userapps in CybOS.
Status: succes!
Reason: did a few attempts but finally managed to get it running thanks to xomboverlord toolchain
   

Redesign the Joind.in Android app. Make it a bit more workable, even with the current API.
Status: did not succeed
Reason: not enough time / bugreports.  So apparently it’s still working. I do have heard others where thinking about writing a new one for Lorna’s v2 api.

Redesign EZShopping – Merge all the stuff still in progress. And deploy a 3.0 version.
Status: meh
Reason: still in progress 

Do some more work on joind.in itself. I tend to do a lot, and move on to the next interesting project. Stop doing that :)
Status: succes
Reason: did (lots more) bug-fixing and features for joind.in, and still find it a nice project to work on. It’s strange, because the codebase – well – isn’t the best one you’ll ever meet, but it’s nice to take your mind of your daily work and just work on these things once in a while. There are times I fix 10 bugs a week, other times I don’t touch it for months. It’s just an on-off project so it seems.

 Get my Arduino to do something useful.
Status: did not succeed
Reason: can’t think of anything.. :/

Language of the year

It was RUBY. Did some work in ruby to try to get the hang of it. I really like the language so I’ll try to do more things in ruby just for the fun of it.. Also, makes it easier to checkout puppet and even see if we can contribute to it..

Vanity

Meet more, and keep in touch with many interesting people.
Status: big success!
Outcome: oh boy. Did I meet interesting people. I don’t even know if I can name them all, so if I forgot you – i’m terribly sorry :)   So hi to Jeroen Keppens – Wim Godden – Matthew Weier O’Phinney – Zeev Suraski – Stephan Hochdoerfer – Anna Fillina – Juozas (utf8) Kaziukenas – Rowan Merewood – Sebastian Marek – Dean Wilson – Kris Buytaert – Karanbir Singh – and many many others I’ve talked or got drunk with the last year… You know what the cool thing is this year? I will meet even more!!!

Now probably the first rule of writing a book is: do not worry about the layout. So obviously – the thing that worried my was – in fact – the layout :). Since I started writing the book in NeoOffice, I tried to mimic the publishers layout as close as possible based on other books to see if my page-estimates were still correct. But trying to create a decent layout in such applications would even make Chuck Norris cry. So that was when I started to look for other ways..

I started to look at LaTeX because I was yahoo’ing on how to write books in a decent markup and LaTeX popped up a lot. My understanding used to be that LaTeX was a kind of language that makes it easy to create all kind of mathematical formulas. Which is correct, since it makes this very very easy, but LaTeX is much more than that. It’s an environment where you can focus on writing instead of struggling with markup, while still being able to have full control over it.

I’ve downloaded the LaTeX package (don’t get fooled, it takes around 1.5 GIGABYTE of software you need to download) and a front end application (Latexian in my case). This just makes your life easier because LaTeX source files (.tex files, the things you type) needs to be compiled and takes a while to get this all right as a beginner. But about one hour later, I was absolutely stunned on how cool my book was already looking!

Also, when you look at many (technical) books, the layout looks remarkably similar to the standard LaTeX layouts :-) I found that this made estimations on page sizes much easier in the end.

Not only is it possible to create really cool looking books and documents out of the box, but you can also split your documents in smaller files which you just include from your main document. Since my book is around 170 pages, I have one main .TEX file in which I set some default parameters (for instance, I don’t want my chapters to have numbers, I use code-snippets that are formatted in a certain way etc). This is called a preamble (maybe comparable to a <HEAD></HEAD> part of a HTML file). Every chapter itself is a subdirectory in which I have every section broken down in separate files (with large sections, I even have another sub-directory with each subsection as a file). My main .TEX file only includes all the chapter files so I can easily change the chapters by moving them up or down. Everything else gets automatically adjusted.

I’ve created a simple LaTeX document to show you how a document would look like:

and off course I’ve compiled the result as an exported PDF file.

As you can see, there is some markup here and there in your sources. To make your life even easier, there are packages you can include in your book which can change literally every aspect of your document. For instance, in my book I’ve included a package to automatically create an index, a package to wrap text around images and a package to create fancy chapter headers. Even though on occasion I found myself stuck, I just added a small TODO comment (you can comment stuff, how cool!) and looked up the answer later. Most of the problems I experienced was just a lack of knowledge and the answer was found quite quickly.

Besides being a cool guy for using LaTeX and automatically create very professional documents, LaTeX has some other advantages:

It makes it possible to version control your documents easily.

Since we are not dealing with binary documents but with just text-files. We can use any version control system to version your documents. My book is actually – together with all examples – hosted on a private repository on GitHub. I can find out where I was a month ago, others can see its progress and even possible to collaborate easily while working on the same book (if needed).

Use the editor you want

I’m currently using Latexian, which is a commercial product (but not expensive), textmate and vim. All of them have LaTeX syntax highlighting and spell-check so again, you only need to deal with the markup.

It’s still possible to see what you are doing real-time (only, it’s not really that important anymore)

Latexian has the possibility to automatically compile your .tex-file and display it. There are others that might have the same functionality and it makes it easy when you really need to focus on layout (I had some tables that needed some TLC).

It’s not only for documents.

Lorna Mitchel uses LaTeX primarily for creating presentations. This is something that LaTeX can do easily as well. For more info, read up on Lorna’s blog.

Conclusion

Even though I’m still learning LaTeX true power and discovering more every day, writing (my) documents will be primarily done in LaTeX. It’s easy, it looks good and it has got loads of advantages over most wysiwyg-editors. And there is absolutely no reason not to do it. Even writing things like functional and technical specification files can easily be done with LaTeX (probably even better, since versioning is a very important aspect for those type of documents).

Give it a try for yourself. You will absolutely love it!

One of the things that most frameworks do nowadays is to rewrite all URL’s to a single entry point. This entry-point (sometimes called the front-controller), will decide how the request is handled (which controller gets called, if it needs authorization first etc). However, some files, like images, css or javascript files can be fetched directly. It is a bit pointless to rewrite those URL’s to the front-controller.

Now, normally this would mean you need Apache to configure to rewrite “non-existing” URL’s to the front controller. This is done with a .htaccess:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

This will check if the requested filename either exists or is a directory, if that is NOT the case, it will call the file index.php (the [L] means this is the last match that needs to be made, if there are my rewrite-rules present, they will be skipped).

Now this is all nice, but a little fragile. It’s easy to mess things up (as I do on occasion) but there is another command that does the same thing with only one command:

FallbackResource /index.php

This would be exactely the same as the rewriting seen above, but with less time to create typo’s. Funny enough, it’s not part of mod_rewrite, but of mod_dir and is available from Apache 2.2.16 and above.

If you want to do a little bit more exotic stuff, like if you need to use rewriteBase, or maybe have different rewrite conditions, you must stick with the mod_rewrite rules, but most of the time, the fallbackresource will suffice.

17-01-2012 Update: and yet another conference bites the dust thanks to PayPal. Thanks for proving my point.

Since I am also in the business of e-commerce, I always have strongly suggest not to accept PayPal as a method for payment. Sure, it WILL lose you some clients, but when (not if, but WHEN), things go wrong between you and PayPal, you would have wished you never have accepted those payments. Most people, especially in the Netherlands, are more accustomed to other ways of payment like iDEAL, which is the most common way of dealing with payments. I can convince most of my clients so I see this as a personal win.

During the last 10 years, I’ve used PayPal, let’s say around 5 times for receiving payments. This is mainly because I would have been dealing with customers/clients that are living inside the United States and Canada. Those countries prefer to write cheques, but unfortunately, cashing cheques is very expensive in the Netherlands. It’s not uncommon to pay up to 40 euro to your bank to cash a cheque that is worth 100 euro’s. On such occasions, I prefer PayPal for automatic bank transfers, since those are still pricy, but less than me cashing cheques.

However, I’ve decided I will never use PayPal again for either paying or accepting payments, both personally and in my company. If somebody wants to pay me through PayPal, I’ll ask them to make a bank-transfer. It’s quite easy, even for Americans to do this as well. All you need to have is the IBAN number, which every bank account automatically has (some countries uses the IBAN numbers as their bank accounts). It’s very safe, doesn’t cost much and is way better than dealing with a man-in-the-middle that let’s face it: behaves even bad on its good days.

I know I’m just one person who refuses PayPal. But we all have to start somewhere and one person is enough to get the ball rolling. I know it’s easy to pay things by a simple click here and there, and even if you are not willing to stop using PayPal, please take a look at other options: iDEAL, creditcards, bank transfers and yes, in the end we have the choice between a company that destroyed a violin and a company that destroyed the economy, but we have to start somewhere. Reducing fraud is important, but too many people get victimized by PayPal’s way of dealing with this problem.

First of all, the source: https://github.com/jaytaph/PuzzleChess

The basic idea is simple: it’s an engine where you can define a chessboard, add some initial pieces onto it, have some kind of rule-set and let the user figure out how to win. Every one of these puzzles gets added to the main index, so you can see which puzzles are done, which are still left open etc:

Each puzzle has a name, a small caption, an icon and a difficulty. When the puzzle has been solved, a check mark will appear (saved inside a small database).

Now, the actual engine is very simple: a board that can have their cells either active or inactive. Inactive cells makes it possible to create a smaller board. For instance, in the knights-game:

You can only place move pieces to active cells. Note that for this game, I needed to have some “dots” on the cells as well to mark the places of the black and white knights. It’s possible to add some extra stuff to a cell.

Another nice thing: there are themes as well! These themes are available from the menu. It basically does nothing more than change which graphics need to be plotted on every frame. This includes the pieces and the board (the dark and light cells).

Every piece have their own special way of moving: a rook can only move straight, while a bishop can only move diagonally. All pieces extend the “piece” class which defines how a piece can move.

Creating a new game

It’s quite easy to create a new game:

• Add a game class that extends “game” to the game-directory.
• Define the board (all fields visible, or only some)
• Add pieces to the board
• Add optional decoration to the board (in case of the dots at the knights-game)
• Define the objective in getObjective(). This is shown to the user to figure out what he/she needs to do
• Define a hasWon() and an optional hasLost() to let the engine know when the game is won/lost.
• Define a init() in which you define the engine parameters. The game can have an unlimited amount of moves, or only a select number. Unlimited time, or you need to figure the game out in a certain amount of time. You can define if you need to show the trace of moves, so every piece leaves a mark on where it has been (handy in games where you need to travel a knight over every cell of the board once), or maybe you can “take” pieces from the enemy.  These are all defined by the GAMEOPTION_* constants.

Background info

The application itself is quite easy in setup. It has 2 activities: the main menu and the puzzlechess activity. The main menu does nothing more than select a game that is passed to the puzzleChess activity (main.java:onCreate -> the setOnItemClickListener).

puzzleChess.java

The actual meat of the application starts with the puzzleChess activity. It has a timer-thread to keep track of the time by sending a MESSAGE_DURATION message. This will allow the updateHandler to update the current time (either increase or decrease the timer). Another thread is started for updating the screen itself. This timer runs every 10ms and sends a MESSAGE_UPDATE message to the handler. This will redraw the panel (chessboard) and checks if the game has been won or lost. This update is needed because when we move a piece to another screen, it’s done through a simple animation that moves the piece from cell A to cell B. This is taken care of by the ChessPanelView.java class.

ChessPanelView.java

The chesspanelview is nothing more than a simple view that draws the screen. It will draw the background, will allow the board to be drawn (this is done by the Board.java class itself), and displays the status like Moves Left, Moves Done and Duration of the game. When the panel is touched (onTouchEvent), it will figure out which cell has been touched, and directs it to the game class that will handle the onClick(X, Y), where X and Y are the row/col of the cell, not the actual coordinates (because that is not needed for the board/game).

Board.java

The Board has got a lot of logic to deal with cells and pieces on those cells. It’s draw() method will create a cache of the board (without any pieces) so we don’t have to regenerate this on every update. Then it will draw that cached background onto the canvas (which is the panelview). Then it will draw all pieces on the board, but when a piece is animated, it means it’s in progress of moving from one cell to the next. In that case, the piece must not be drawn in a cell, but somewhere between cell A and cell B. The piece itself will interpolate the route between the two cells and returns the correct position. When we have arrived, the animate() method of the piece will return false, so the board will draw the piece correctly onto the cell (so it’s an active piece again).

More stuff will then be printed, like the tracemoves of traveled cells (if the game needs this), and border colors, which are the colors that are shown when you have clicked on a piece and will show you where the piece can move to.

The rest of the methods in this class are pretty straight-forward and takes care of handling the board, cells, and pieces on the board.

Piece.java

The piece.java class is an abstract class that defines a piece. Every piece has got an identifier (a tag, for instance: white rook 1, black knight etc). A color (black or white) and a boolean if the piece can be moved or not. It has got some methods to deal with animation, in case we travel from one cell to another.

This class defines “move”-methods like singleDiagonalMoves(), diagonalMoves() etc, which returns the available moves that can be made into that direction for the piece. It’s quite simple: if we are in a corner, a bishop can only move in one direction: away from that corner. When the bishop is in the center square of the board, if can move in all four directions, unless there is another piece in the way. These functions takes care of these conditions (together with the fact if the actual fields are enabled on the board or not), and returns an array with all available moves that can be done.

These move-functions will call the isValidAvailableField() method, which checks if field X, Y is available. Off course, it will take everything in account (disabled fields, traced fields, fields with pieces that we cannot take etc).

There is not much more going on for pieces. They are simple elements that can be moved and which can define their paths by themselves. The rest is taken care of by the board-class.

Every type of piece (rook, king, queen) etc, have their own class, in which we define the name (getName), the resource (the image of the piece) and a list of available moves. This list is created by calling the move-methods from the abstract class. A queen will check Piece::straightMoves() and Piece::diagonalMoves(), but not Piece::knightMoves(), a king will check Piece::singleDiagonalMoves, Piece::singleLeftRightMoves and Piece::singleUpDownMoves() etc..

Game.java

The game class by itself is also an abstract class. It holds all information about the game and takes care of moving the pieces. The onClick handler, which is passed from the PanelView, will check if we already selected a piece. If not and we clicked on a piece, that piece will become active so we can show all the possible paths for that piece (_onClickNoSelection). It will check if there is a piece, if we are allowed to move it, and if so, adds “bordercolors” to the board: when the piece can overtake another piece on it’s path, it will have a red bordercolor, otherwise a green.

When we have clicked on the same piece that we activated, it means we need to deactivate it and remove all the border colors again. This is done by _onClickSelectionSameField.

When we have clicked on another field while a piece has been activated AND we are allowed to move to that field, we will move the piece. The board-class will start this move, and stores the information (animated) into the piece so on the next update, we will see this piece actually moving from cell to cell.

The game class itself has basic functionality for the game itself: hasLost, hasWon etc to check if we have won or lost the game.

Every game must extend this game class but is really easy to setup as you have read in the “creating a new game” chapter.

Conclusion

There are still some issues with the application. And there is still a big issue I need to figure out: we use a canvas defined by pixels so it doesn’t work quite well on every tablet or phone. I use a 480 (was 320) large panel so we have 60×60 pixel cells. We should be able to scale everything: the cells, the background, the pieces etc.

Another issue that the game isn’t finished yet. There are still some issues here and there (crashes, actually) and we need to check all the current games to see if they actually work. But on the whole, it’s almost ready..  Now just find the time to create the finish 10 percent. If you like to contribute: https://github.com/jaytaph/PuzzleChess

This means you should not install the default PHP package for your distribution when the distribution also runs on Zend Server. This Facter plugin will allow you to use the $zendserver fact inside your own manifests to check if Zend server is installed, so you can take measures against installing stuff that is taken care of by ZendServer itself.

Note: it’s a VERY crude check, nothing more a check to see if a directory exists, and we don’t return the Zend Server version (Zend Platform is not supported). However, these things can be changed quite easily.

• Download from: https://github.com/jaytaph/puppet-facter-zendserver
• Installation: through puppet off course! :-)

Introducing: the .htaccess

Most frameworks, CMS systems and projects are being run on an Apache web-server platform. One of the benefits is that this platform is not only very stable, but also got a lot of extra functionality that can be implemented through modules. These modules can be configured through Apache’s main configuration or through user-defined configurations – mostly known as .htaccess files.

Most .htaccess files are used for 2 things: rewriting url’s and authentication/authorization. The authentication comes in handy in combination with a .htpasswd file, where you can store a user/password combination for the persons that can log into your website. We all have seen it, and most of you have “secured” at least a portion of a website (it’s also a good way to secure a preview website for instance). Apache accepts even more advanced ways of authentication, for instance through LDAP.

Second common feature of .htaccess files: the URL rewriting. Sometimes it’s just nicer to go to: http://www.example.org/this/is/my/page, instead of http://www.example.org/index.php?page=this&article=is_my_blog. With the help of URL-rewriting, it’s easy to achieve this, and create permalinks and such. Most frameworks have a so-called front-controller where all urls will be redirected to (in symfony’s case, this would be app_dev.php or app.php, and Zend Framework uses the more standard index.php for this).

The problem with the new PHP 5.4 internal web-server is that it isn’t Apache. Thus it does not know anything about .htaccess. Even when you have defined your .htaccess to do authentication, the internal PHP web-server will ignore it, while in production, the authentication will be needed (if you will be running Apache, of course). Also, you need to reroute everything manually through your app_dev.php, so your URL’s don’t really match the way they will be on your production.

Introducing: the php 5.4 webserver

The PHP internal web-server has the opportunity to route all requests it receives through a single PHP file.

$ php -S 127.0.0.1:80 router.php

The router.php itself can be a simple program that parses the request, and checks if it’s something that needs to be passed onto your normal PHP code (for instance, your index.php) or maybe it will be something that can be served directly from disk. A simple router.php doesn’t have to be very complex:

This is one of the most basic router.php scripts that are available: if it’s in image file, it will load directly the image from disk (by returning false). Otherwise, it will include the main index.php file, so everything gets rerouted through that file. You get automatically some very crude URL-rewrite functionality: everything will be rerouted through index.php, so when you go to : http://server:8080/my/url, it will redirect to index.php with the request-uri being:

  [REQUEST_URI] => /my/url

But of course, it is in no way compatible with a regular .htaccess file. That is where this project comes into play:

Introducing: the HTRouter project

The code itself is pretty simple: it just loads all available “modules”, parses a .htaccess file found in the main directory and executes the things that normally Apache would do for you. In the end, it will pass control to your application (if needed). So in essence, it’s the Apache module-functionality completely rewritten in PHP.

All the modules that can be loaded, will mimic the actual modules as found in Apache itself. So there is a mod_rewrite module, a mod_auth module for authentication, a mod_authn_file module that will authenticate by reading users from a .htpasswd file etc.

Of course, the code is on github:https://github.com/jaytaph/htrouter

Note: the code is not finished! There are still lots of things that needs to be implemented:

• mod_rewrite, so we can rewrite url’s (pretty important)
• mod_alias, so we can alias url’s (not so important, but nifty enough)
• Package everything through PHAR

So there is still some work left. However, the basics are beginning to show, and the standard basic authentication through htpasswd files are functional. I’m really hoping this will be a good way to help developers that will use the standard web-server but still crave .htaccess functionality.

Again, I’m terribly sorry for all developers who now will get the idea it might be a good idea to use this in production. Please don’t. It will probably never will be a good idea, HOWEVER, and this is still something I truly think can and will happen: it will be a perfect system for backend-maintenance or as an admin-panel web interface. Normally, you don’t need threading and serve many requests but sometimes you want the simple .htaccess handling. I’m sure the PHP internal web-server will evolve over time into something more robust, and hopefully, this project will be part of generalize the usage of .htaccess.

So the preview was good, but don’t you just hate it when you are watching a movie-preview and they use the best pieces of the film for it (which means, the average movie has about 30 seconds of good parts in it.. which sounds about right for the average Hollywood movie nowadays). Luckily, the rest of this book is just as funny and interesting as its preview.

Not only is the book about Scott’s story on the pros (and cons) of being a public speaker, but he will tell you how to become one yourself. Not only will he talk about the psychology of lecturing, but also how you as a speaker can easily make or break a talk just by the way you bring it to your room (yes, it’s YOUR room). He talks about why most speaker evaluations are useless (sorry, most of them, except joind.in off course :)). What to do when you are facing a difficult crowd, or even how to act when a SWAT-team comes busting into the room and take away one of the attendees (seriously, there is a anecdote on exactly this in the book!) or how to deal with the annoying know-it-all guy in the room.

This book is also a lot about common sense but which we all forget once we enter the stage. It truly is a must-have when you are – or want to become – a public speaker! What’s left to say? Nothing really, you should just buy it and read it, even if you don’t ambition a public speaker role, it will be a quite funny and interesting book nevertheless!

Info

Confessions of a public speaker

Scott Berkun

ISBN: 978-1-449-40195-8

http://shop.oreilly.com/product/9780596802004.do

http://www.scottberkun.com/