You can check the book out on Packt’s store page.

Some of you may recall I was also doing a review of Zend Framework 1.8 Web Application Development. This review was delayed becayse of me being the usual me and forgetting things, so I’d like to apologize to anyone who has been waiting for it. I’m going to post my review of it next week – I already have it written too and it just needs minor edits, so this time I’m not going to forget about it

The application that makes this possible is called Lemon ADE, and it runs on the iPad.

In this post I’ll go over how Lemon ADE works, and I have also recorded a short video demonstrating coding with the app.

How can you code PHP without coding?

Lemon ADE is an abstract syntax tree editor. This is similar to what the PHP parser does when converting written PHP code into something it can execute.

I think the video is the best way to explain how the app works, so here it is:

Lemon ADE features

As you can see from the video, Lemon ADE has a list of blocks you use to create your code. It currently supports enough stuff for being actually able to write an application, but it’s lacking things such as classes or arrays.

Once you have managed to construct your application with it, you can export the code to an FTP server. The code itself isn’t always formatted very well, for example indentation occasionally breaks, but it outputs working PHP code.

From a usability standpoint, the application is quite easy to use once you get the hang of it. However, it becomes tedious when you have a lot of code, as the code becomes difficult to browse and even more difficult to find what you need from the entire mess.

In closing

While Lemon ADE is a pretty cool concept, it’s far from being actually useful for day-to-day programming. However, I think it has promise, so perhaps with further abstraction (so you need to type less and add fewer blocks) and UI modifications (so you can actually find things) it may become at least semi-useful one day.

Lemon ADE is a free download for the iPad

Let’s talk about exceptions and how they relate to your classes and abstraction.

Classes and abstraction?

You might already know what I will be referring to when I talk about abstraction, but for the sake of this article let’s establish a base:

Say you have a class for database access. Maybe it’s called MysqlDatabase. You could also have a PostgreDatabase class in addition.

These two classes abstract how you access these specific databases. They both have a connect method which takes the same arguments – essentially, all you need to know is that this is a database class which conforms to the specific interface (maybe you have a separate IDatabase interface)

Okay, so what do exceptions have to do with this?

Your database classes throw exceptions when something goes wrong. Let’s say they throw instances of the standard Exception. When using these classes you catch this type of exception. Easy!

Let’s add another class to the mix. Say it’s some class which uses the database to fetch some specific sort of objects – let’s call it FooRepository. We would like to handle exceptions from the database and from the new class nicely, so we add a new exception type, MysqlException.

Now our MySQL class is throwing MySQL exceptions.

But now you decide to use PostgreSQL and you must change all your code to catch PostgreExceptions.

You also must change all code using FooRepository, because any code using it may have to deal with a database exception coming from this class.

Now that we know what will go wrong with our plan, how do we fix this?

There are two ways to improve this situation

• Designing our exception classes better
• Wrapping less relevant exceptions

Let's look at these next...

Designing exception classes better

Firstly, to combat the issue we face when swapping the implementation of the database connection classes...

To fix this, we can use inheritance to our benefit: Create a base exception type, from which the implementation-specific exceptions inherit from.

Say we create a base DatabaseException class, and both MysqlException and PostgreException inherit from it. Now we can just catch a DatabaseException in our catch-block. Easy fix while keeping all the benefits.

Wrapping less relevant exceptions

When you have a class with a collaborator, or multiple collaborators, we face the problem of having to catch all sorts of exceptions in our user code. Our user code may not even care that the class we are using uses the database (or maybe the filesystem), and as such, we should do something to hide this fact in our exceptions too.

A very good example is that our FooRepository class uses the database, and as such, you would need to catch database exceptions when using it. But what if we changed the implementation of FooRepository so, that it uses a web service or perhaps the filesystem? We would again need to change all our code using this class to catch the new possible exceptions.

To fix this sort of thing, we must make sure to catch everything in FooRepository, and wrap them into a RepositoryException. This way code which uses the repository will only need to be aware of and catch the repository-specific exception.

In most languages, we can do something like this:

try {
    //Do something with the DB which may throw an exception
    $db->doSomething();
}
catch(DatabaseException $ex) {
    //Wrap the exception in another to keep abstraction
    throw new RepositoryException($ex);
}

Conclusion

To use exceptions in an efficient way we must consider the whole application and not just the immediate code.

Give your exceptions base classes they inherit from - this will make it easier to write reusable code, especially if you're using something like the adapter pattern.

Make sure you catch and wrap exceptions of objects you use. This may seem a bit pointless occasionally, but as with using inheritance to your advantage, this will make your code easier to use.

Both of these approaches will also help in decoupling your code - you can make changes without having to change everything using the code.

That’s nice and all, as at least you have some sort of error handling, but I think this way of handling errors must go. There is no place for it in modern PHP code – it’s the worst way to handle errors, not much better than not handling them at all.

Background

So you are a newbie and want to learn how to do MySQL in PHP.

Okay, let’s do a google search: PHP MySQL tutorial

I’ll let you guess how many of the first 10 use “or die()” to catch failing queries.

One?

Nope.

Five?

Nope.

All ten of them use “or die”! (and some even use the evil error eating @ operator)

So is it any wonder why it is so common?

If you’re a beginner, I’m not blaming you – how could you know of a better way if everything you can find talks about the bad way to do it?

How hard can it be to do error handling properly?

Never use die()

So why is die() so bad?

For starters, it may be a decent approach. However, when the size of the codebase grows, it becomes more and more difficult to locate problems.

If your code dies, you won’t know the line. You won’t know the function, and not the file. You won’t be able to graciously handle the error either – The application will just stop right there, right then.

There are two other approaches that are better:

• trigger_error (or user_error)
• Exceptions

trigger_error

trigger_error is, in a way, the next step from die(). Despite being the obvious next step, it’s still a much better approach.

1. You’ll get better output: Not only will it show you the line number, it will tell you the filename too, so you know where to look. Even better, if you have Xdebug, you’ll get stack traces and other useful information.
2. You will actually get output in the error log from this one.
3. You can “catch” errors triggered by code using set_error_handler. This will allow you to maybe automatically display a nice “oops something went wrong” type of page or other such stuff

And perhaps also good is that you can use trigger_error in a very similar fashion as die:
do_X() or trigger_error('I have a boo boo', E_USER_ERROR);

This makes it very easy to make the jump to better error handling, and it can even be done with relative ease with an automatic search and replace.

Exceptions

Exceptions are in my opinion the way to handle errors.

1. Exceptions are flexible: You can have use the standard exceptions or create custom ones to better describe the error.
2. They can convey extra information: A custom exception class can, for example, include additional fields – it is an object afterall
3. Using a try-catch block, you can easily handle exceptions on a case-by-case basis, making it easy to choose how to recover from specific exceptions.

Of course, the benefits mentioned for trigger_error also apply: Uncaught exceptions will provide good output (and better with Xdebug) and will cause output in the error log.

The only downside of using exceptions is that it’ll make your code a little more verbose. Except I lied when I said it’s a downside – more verbose code can be a good thing too.

Conclusion

Stop using or die() to handle errors.

Using either of the approaches mentioned here is much, much better. You’ll get output that makes it much easier to debug your code, the error log will actually become useful and you can handle your error cases much better in code, so that the application will not crap on the user.

You have no reason to use die() when encountering an error.

ps: Never make your error message say “I have a boo boo”

I’ve mostly used PHP and Python to do server-side web application sort of programming. Compared to what I’m used to, Wicket is way different.

Read on to find out about a different way to develop web applications.

My starting point

My starting point with Wicket was basically zero, at least Java-wise: I had never used any Java web app framework, so I didn’t really know what to expect.

Since as I said I’ve mostly used PHP and Python, I assumed the program flow would be something like in them:

• Bootstrap
• Routing etc. handled by framework, goes to a controller
• Controller checks things like whether this is a POST or a GET, maybe decides to load data from models
• View is rendered. PHP or a template language is used to print values from controller in the view

Of course, this was a completely wrong assumption.

Form submit: PHP vs. Wicket

Wicket in my experience has much more in common with traditional desktop application frameworks than with web stuff. Whether this is a pro or a con, I can’t say at this point.

Consider a very typical case of handling a form. What I had done before it was something like this:

• Is this POST? If so, save stuff
• Display form, with values from POST if there was a validation error

In Wicket, it works something like this:

• Display form

Of course, there is a bit more to it than just that.

First, we would create the HTML markup. In PHP, you typically would just put a bunch of echo statements here to display values. Wicket however does things completely differently: You add special attributes to the tags – in the case of a form, we would add wicket ID attributes to the form element and any fields and buttons we might have.

Next, we tell Wicket what components our page has. The reason we put special ID attributes into the markup is so that Wicket knows what elements to associate with which components. So we tell Wicket that we want a form component, input components for input fields, and a button for the submit button. We can also add validators to each component. Also needed is a model, which for sake of simplicity you can assume is a bunch of key-value pairs automatically serialized to some storage (You can actually have something like this pretty easily).

In PHP we would typically tell the view object what values to assign to variables that we echo in the form. We might also test if the method is POST and perform validation and model stuff there.

In Wicket we don’t need to give the form an action and we don’t need to check whether the form was submitted or anything – Wicket does all this for us. The model can even persist things automatically without us having to lift a finger.

So if you compare this explanation (which is not very in depth), it is a lot like a desktop application in Wicket. We don’t tell it anything about the web stuff that happens around it – we just tell it that this is how our document looks and this is how our document behaves. In Windows Forms, you tell the same things. In PHP you need to take care of the logic of the web too, such as handling POST or determining the URL where the form needs to be submitted for it to work.

Conclusion

Wicket is a lot like desktop app development, since you work with components – in desktop apps, you work with controls. Desktop developers don’t need to worry about where stuff goes when the page changes, saving the state, because there are no page changes. Wicket developers don’t need to worry about that either, because Wicket persists things – in a somewhat similar fashion to PHP’s session storage, but automatically and much more extensively.

I was working with Wicket in a portlet environment, so I probably didn’t see all of basic Wicket stuff. Also bear in mind that I only have little experience working with Wicket, so there probably is more than just this.

One case where Wicket’s automatic state persistence and other features might be useful is web applications where you perform actions with multiple steps. Other than this, it does feel somewhat heavy, and occasionally repetitive for the markup and component parts.

Nevertheless, it is an interesting way to do things and if you have the chance, I’d recommend giving it a shot.

But did you know it’s good for learning even if you don’t ask any questions – just answer them?

You may be familiar with Code Katas – basically small programming challenges – which I’ve seen pop up a lot lately.

To solve a Code Kata (I never bothered ) you need to exercise your knowledge and maybe learn new things.

Heck, to solve any programming problem you have to exercise your knowledge and maybe learn new things.

This also applies to answering questions on Stack Overflow. You actually have to think about the problem at hand and come up with a good solution – assuming you actually want to answer the question properly.

You could even go as far as pick tags you want to learn more about and try answering those questions.

So one more thing to keep everyone using SO. It’s great for finding answers, somehow addictive and you even learn things by just answering!

I thought “What crap is this? I’m not going to install it!”. That was stupid, because Unity rocks as a game development tool!

Why Unity rocks (in my opinion)

In a matter of a few hours, I wrote a third person shooter prototype.

Of course, this was after I spent some days to get familiar with the environment.

The basic features my game had in about 8 or so hours:

• 3D 3rd person “over the shoulder” camera
• Enemies who moved around
• The enemies could smartly aim at your current location
• A spawner system where I could place a spawner object anywhere and it would automatically spawn more enemies
• A waypoint based movement system
• A simple user interface which displayed health and some other stuff

What is Unity?

Unity is basically a game engine with an IDE sort of editor tool. It can be used to develop games for multiple platforms and the web (which uses their browser plugin).

It has a fast 3D engine, a PhysX based physics engine and libraries to work with all sorts of things you might need when developing a game (GUI, collisions, even multiplayer is quite straightforward to do).

The editor itself is kind of like a level editor for a 3D game – think Valve Hammer or WorldCraft – but it also has an asset list, scenes, input management etc. quite easily straight from the UI.

Oh, and did I mention it also works on Macs and not just Windows, and that you can write scripts for your game in JavaScript, C# or Boo?

If you develop games, for fun or for profit, Unity is worth checking out

Now I’m not very familiar with other 3D game engines, but Unity is the best I’ve seen. It does require some getting used to, especially how the scripts are attached into the game, but I can’t really think of many bad things about it.

ps: I’m not going to attach a screenshot of my game because it’s basically just a bunch of boxes. I’m not a 3D modeller, sorry

Later on, I decided to explain it to him with actual code examples, although the most he has ever done was some HTML back in elementary school.

Here’s what I told him…

A simple example with HTML, PHP and SQL

I used HTML, PHP and SQL to create a very simple example: A simple webpage which displays a list of things loaded from a database.

The reason I chose these three is because they allowed me to present a very simple example, but still would allow me to create a scenario where it would be easy to show how code can become complex, and how you would change it to improve.

Stage 1: HTML/PHP/SQL-soup

The first stage is the most straightforward way you could do this:

<html>
 <head>
  <title>Listing</title>
 </head>
 <body>
  <h1>List</h1>
  <?php
  $db = mysql_connect('localhost', 'username', 'password');
  mysql_select_db('database', $db);
 
  $sql = 'SELECT * FROM lista ORDER BY id DESC';
  $result = mysql_query($sql, $db);
  ?>
  <ul>
    <?php
    while($row = mysql_fetch_assoc($result)) {
      echo '<li>' . $row['name'] . '</li>';
    }
    ?>
  </ul>  
 </body>
</html>
<?php
mysql_close($db);
?>

So in this example, we have a page that is very typical for a PHP beginner: It mixes everything together in one file.

Stage 2: Split output and data processing

To improve from stage 1, we can split the processing of data and output. We do this to achieve separation of concerns.

This time, we have two files: index.php and a template file index.phtml

index.php

<?php
$db = mysql_connect('localhost', 'username', 'password');
mysql_select_db('database', $db);
 
$sql = 'SELECT * FROM lista ORDER BY id DESC';
$result = mysql_query($sql, $db);
 
$list = array();
while($row = mysql_fetch_assoc($result)) {
  $list[] = $row;
}
 
mysql_close($db);
 
require 'index.phtml';

index.phtml

<html>
 <head>
  <title>Listing</title>
 </head>
 <body>
  <h1>List</h1>
  <ul>
   <?php foreach($list as $item): ?>
    <li><?= $item['name']; ?></li>
   <?php endforeach; ?>
  </ul>  
 </body>
</html>

As you can see, now our data processing code is in index.php and the HTML markup is in the index.phtml template file. It’s now much more clear what the structure of our HTML markup is (and we could now reuse it etc.)

Stage 3: Reusable functions

We can still perform some improvements to the code. Let’s extract the data processing code into separate functions. By doing this, we will improve the readability of the index.php file and if needed, we could easily reuse the data processing code.

We will create a new file, called database.php, which will include our functions:

database.php

<?php
function connect_db($user, $pass, $host, $dbname) {
  $db = mysql_connect($user, $pass, $host);
  mysql_select_db($dbname, $db);
  return $db;
}
 
function get_list($db) {
  $sql = 'SELECT * FROM lista ORDER BY id DESC';
  $result = mysql_query($sql, $db);
 
  $list = array();
  while($row = mysql_fetch_assoc($result)) {
    $list[] = $row;
  }
 
  return $list;
}

We will also change index.php to reflect the extraction of the code:

index.php

<?php
require 'database.php';
 
$db = connect_db('user', 'pass', 'address', 'database');
$list = get_list($db);
 
require 'index.phtml';

As you can now see, the code is much easier to understand as we can clearly see from the function naming what it does and the index.php file is also much shorter.

Conclusion

By splitting code into their separate places, you can easily improve your code. You don’t need to be a rocket scientist to understand the basic points.

I did omit some things here, though: in reality I did give a brief introduction of HTML, PHP and SQL to my friend, and gave him an example of how the resulting page would look and stuff like that. Oh, we used Google Wave for it, and it worked pretty well, so maybe it isn’t as useless as it sometimes seems

Finnish games

• Slicks ‘n’ Slide – A great top-down racer with a track editor. I made a similar JavaScript based top down racer.
• Triplane Turmoil – Side-scrolling multiplayer shooting with triplanes
• Wings – Side-scrolling cave flying shooter with tons of weapons and maps etc. etc.
• Minebombers – Top-down shooter, a combination of bomberman and miner
• Tapan Kaikki – Top-down shooter
• Liero – Side-scrolling shooter where you are a worm and as usual the goal is to kill the other worms
• Koiratappelu – Couldn’t find anything in english about this. This game was a bit like Triplane Turmoil
• Areena 4 – As with Koiratappelu couldn’t find anything about this in english either. A great strategy game where you manage a team of gladiators in a fantasy world and fight in different leagues to be the best.
• Duck, Mr. Duck (in finnish, has a screenshot) – A very Worms-like turn-based shooter, except this time you are a duck.
• Alien Phobia – Top-down shooter, simple and fun: The only goal is to survive against an endless flood of aliens out to kill you. There is also Alien Phobia III.

Others

• Action Supercross – Possibly one of the first good physics based games? Side-scrolling motocross puzzle game
• Assault Trooper – Isometric shooter
• C-Dogs – Isometric shooter with two-player support and I think there also was a map editor

What’s your favorite?

I spent countless hours playing the above games, although there probably were others that I forgot about.

Share your favorite old games in the comments

Please let me know if anything appears broken (Leave a comment or contact me via email/IM)