I went running today and now I can’t walk.
WHAT HAPPENED, LEGS? WE WERE WORKING SO WELL TOGETHER.
In other news, VALVE MAKE TF2 WORK AGAIN. JUST ROLL BACK THE PATCHES FOR GOD’S SAKES. I am willing to relinquish my Manniversary hat, even if it did look rather fetching on my Demoknight. On SPUF (steam user forums) half the people there are defending Valve. Why? They pushed an update and it’s broken TF2 for everyone. Don’t they test these things before they release them? Don’t tell me Valve is “doing their best”; they evidently are not. If they were taking the care you’d expect of a big name software house, they’d run updates on their test system for 24 hours before pushing it out. The lack of any kind of official announcement that they’ve fucked everything up is only adding to the image of unprofessionalism they are currently cultivating.
IN OTHER OTHER NEWS, for lack of anything better to do, I have been writing a blogging system using CodeIgniter. Mostly the reason for this is that I have a news announcement feed which currently runs off WordPress but WordPress is extremely heavy and difficult to customise. The WordPress you see here powering my blog is not very similar to the WordPress you get when you download it and deploy it yourself. The WordPress I have here is very nice, it provides me with much useful functionality, it is well configured and I have no complaints. The WordPress you download is less impressive and 3rd party plugins are a horrible minefield, and even the good ones, well, I can’t be bothered to review them for security and stuff. WordPress from a developer’s point of view is utterly horrible.
So for fun I’ve been putting together my own simple blogging app over the last two days. It is horribly incomplete but it does the following things in some form or another:
User login and registration,
Post authoring/editing,
Tags (and tag browsing),
Comment authoring and administration and classification into approved/pending/spam/trash,
RSS post feed (works for tags as well),
a loose plugin system using a signals/slots idea
A plugin which throttles comments by IP by setting them to ‘pending’
hurrah?
The biggest problem I’ve had is that CodeIgniter has not scaled to a non-trivial SQL schema as well as I’d hoped. I mean, I’m still writing a lot of SQL and I hate writing SQL. I also hate dealing with the results of SQL and trying to put it into a form useful for my program. Next time I will look at using Cake.
GeSHi 1.2
I checked out the SVN branch of GeSHi 1.2 today. I looked at GeSHi very closely about a year ago and was less than impressed. A lot of people seem to rate it, and to be honest, this mystifies me. I ended up writing my own syntax highlighter, which is better than GeSHi, I think.
Anyway, I looked at 1.2 and it’s better than it was, but I’m still not overwhelmed. As far as I can tell, it has been re-written to emulate a state machine, which is definitely an improvement, but the code seems convoluted and it still doesn’t seem that powerful. I gave it some JavaScript and it was easy to make it confused on regex literals. JavaScript’s disambiguation for the ‘/’ symbol is very simple and well defined, but if your lexer is not powerful/extensible/explicit enough, it will not be able to check the condition and you’ll have to resort to hackish regular expression look-behinds (which won’t always work).
I looked at the code and to be honest I don’t really understand it, but it looks like it’s still using one central lexer to handle everything. When you aim to recognise more than a few languages, it seems ridiculous not to try to abstract and equate them, but that’s exactly what I didn’t do and I think it was the best choice I could have made. That’s the thing with abstraction – it can make life easier or it can make life harder. At worst it can be a total pain and and be a problem in its own right, but more often, it just limits you. The key is in choosing what to abstract, and the best answer is not always the most obvious. It pays to be clever in your design so you can write straight-forward code; the minute your code has to be ‘clever’ is the minute you need a new design.
making a custom fully working 404 page with codeigniter
[update: I changed this to use exceptions, it's better this way]
CodeIgniter has a really annoying bug with its 404_override setting which makes it pretty much useless as a complete solution. The bug is that it won’t load the correct libraries and helpers of your 404 controller if the controller which threw the 404 also loaded those modules for itself. Fear not, a workaround is at hand. The advantage of properly handling a 404 in the context of your CodeIgniter application is that you get access to your standard stuff like your site layout (views) so you can load all your menus and stuff and load the error message where the content would normally go – this way the visitor feels like they’re on the site and they can get onto a working page easily, if they so desire. You can also hook into your database and perhaps do some logging.
Firstly, if you’re not using MY_Controller then, err, well you really should be. It makes life so much easier. MY_Controller is an easy to define superclass for all of your controllers. Implementing it lets you centralise all your site-wide constants and routines, and it’s very useful here.
Define it in application/core/MY_Controller.php and make all your ‘real’ controllers extend it. Also define individual exception classes that you want to handle. The _remap method wraps the controller’s method invocation, so we override that and use it to catch exceptions. This means that at any point in your controllers, you can just throw an Exception404 and you don’t have to worry about anything else; the exception bubbles up to _remap which unloads any existing output and then loads the 404 view(s).
You could extend this to also define 403 exceptions, and any other error codes your application may deal with, and you could use the exception message (i.e. throw new Exception404(‘some message’);) to set some descriptive text for your 404 view. [update: actually I tried this and it's a bit cumbersome, you're probably best off having just a HTTPException class and set the status code as a constructor argument)]
This is sort of how mine looks:
// defined for neater syntax only
class Exception404 extends Exception {
}
public class MY_Controller extends CI_Controller {
public function _remap($method, $params = array()) {
try {
if (!method_exists($this, $method))
throw new Exception404();
return call_user_func_array(array($this, $method), $params);
} catch(Exception404 $e) {
$this->show_404();
}
}
protected function _load_header($data=array()) {
$this->load->view('headerview.php', $data);
}
protected function _load_footer() {
$this->load->view('footerview.php');
}
protected function show_404() {
// clear any views that have already been loaded
$this->output->set_output('');
$this->output->set_status_header('404');
$this->_load_header();
$this->load->view('404.php');
$this->_load_footer();
}
}
CodeIgniter URLs work like this:
index.php/CONTROLLER/METHOD/ARG1/ARG2/ARG3/…/ARGN
So we can see here that when we request a method of a controller, the remap function catches it. If the URL is okay and the method exists, it is executed. If it doesn’t, the 404 is executed.
To make it so it also catches non-existent controllers, change application/config/routes.php:
$route['404_override'] = 'CONTROLLER/show_404';
CONTROLLER can be any controller which inherits MY_Controller. I use my default, you can use whatever most appeals or, if you want, define a new controller.
You may (probably) have your application and server set up so it’s possible to request URLs which aren’t handled by CodeIgniter’s index.php. In this case, you probably also want to redirect when Apache catches a 404 to your new custom 404. Put this in your htaccess:
ErrorDocument 404 /index.php/CONTROLLER/show_404
Where again, CONTROLLER is some controller that implements show404.
you should now have site-wide redirection of file-not-found URLs to your exciting and sexy new 404 page. I thoroughly recommend using the opportunity to display to your baffled visitor a picture of a lolcat. I recommend this one:
or (better),
php performance woes
I found a fairly strange case of php performance scaling today. I’m sorry, but I’m not going to try to separate this out of a several thousand line codebase to reproduce the exact conditions it’s happening, so we’ll just look at the snippet that directly affects the performance.
The function at fault is building a tree via a stack, the algorithm probably has a name but I don’t know it. It’s not important. We’re inserting some text into the tree as a child of current node, and we’re trying to avoid adjacent separate strings by concatenating them. As it happens, the concatenation here was later rendered redundant.
The function looks like this:
<?php
$children = & $this->node_stack[count($this->node_stack)-1]['children'];
if (!empty($children) && is_string($children[count($children)-1])
$children[count($children)-1] .= $str;
else
$children[] = $str;
you notice what about this code? It’s not entirely optimal, correct! But unless you’re a micro-optimisation nazi, you’ve probably misjudged the real impact it has. With this code, a 30KB input runs in about 0.55 seconds and a 60KB input (the first input doubled up) runs in 3.5 seconds. A 200KB input triggers a 60 second timeout. Err, clearly that’s not very good..
If you remove lines 2, 3 and 4, (these are redundant, remember) everything runs perfectly linearly: 30KB runs in 0.3 seconds, 60KB runs in 0.6 seconds and 200KB runs in about 2.0 seconds.
The problematic part turns out to be the call to count($children). The two following functions have 1) linear and 2) exponential(ish — didn’t plot a graph) runtime
<?php
// linear
function fast($str) {
$children = & $this->node_stack[count($this->node_stack)-1]['children'];
$children[] = $str;
}
// exponential (probably)
function slow($str) {
$children = & $this->node_stack[count($this->node_stack)-1]['children'];
$children[] = $str;
count($children);
}
This *really* shouldn’t happen. Everyone knows that count is O(1). And we’re also calling count on the node stack with no adverse effect.
Here’s the bizarre thing, as generated by the profiler on the same input:
fast: called 7924 times, 2.59% of program runtime
count (as callee of fast): called 7924 times, 5.23% of fast()
slow: called 7924 times, 42.3 % of program runtime
count (as callee of slow): called 15848 times, 0.55% of slow()
yeah! Read that again: count takes up a lot less relative time in slow() even though it’s called twice as many times, even though its presence magically causes the calling function to slow down massively. According to the profiler, the absolute time taken for count() is about 3x as much slow() vs fast(), we expect it to be 2x, but 3x is probably within error bounds.
It’s safe to say I haven’t got a clue what’s going on here.
MYSTERY.
this is php 5.3 and xampp on Ubuntu x64. I’ll find out exactly which version of php if anyone cares.
err edit, this seems to be it: http://bugs.php.net/bug.php?id=34540… OMG PHP is retarded sometimes. “Thank you for taking the time to write to us, but this is not
a bug.” umm yes it is.
