Aside from Paste2.org I have a full time development job, for UK2 Group; which takes precedence because, simply; it pays the bills. What that job tends to do is make me want to not write code at the end of the day because I’ve been doing it all day.
That slows me down but it’s not currently the main issue with paste2.org. View full article »
Just came up with a fairly smart way to validate email that removes a few issues generally caused by this sort of stuff. It’s not totally complete and it’s obviously part of a validation class – anybody planning on using it will need to modify it to make it work to their needs. View full article »
It’s been my goal since the day I started paste2 to figure out how I can bring something new to the pastebin concept. I’ve targetted performance (already fast, but improved again in the new code), tried to make the interface as uncluttered as possible (which is also much improved in the new code) and paste2 is about to get the Akamai treatment on it’s assets with the new code. Not wanting to just compete and be like other pastebins, I’ve been trying to figure out – for over 3 years now in fact, where pastebins should go next. I’m absolutely convinced now that the next step for pastebins is ‘live’ real-time collaberative editing.
After seeing this happening in a IRC channel not long back, being done inside an editor that is really designed for creating word processed style documents, but with code, I’m absolutely sure it’s the way forward.
The problem of course is that this stuff isn’t easy. I already have a plan to do it using some parts of google mobwrite, and building the server side in PHP because it’ll be faster – and I’ll trust myself more if a bug comes up to know the language ins and outs, which while I can write Python I don’t really trust it or myself. I could easily just do it easily using mobwrite in it’s entirety but the performance wouldn’t be great, and like I said – if something came up it’d probably push my Python knowledge.
Problem is getting it done. I was thinking about (and started) writing the whole thing into the new code, but I’ve changed my mind – I’m going to push the new code out on the new application server, then start working on that.
There’s some other good pastebins around, since paste2 came on the scene (at the time pastebin.com was down basically all the time) some other new ones have popped up and are helping improve the competition in the ‘market’, which can’t be a bad thing. Even pastebin.com has had a redesign now (after being sold).
So this project got sort of abandoned due to a really horrible potential issue I thought of, the new job taking up a lot of time and just general roadblocks.
It’s now been brought back from the dead, like Frankenstein.
I’ve been trying to fix a problem I thought of in my head, sort of a “how the hell am I going to solve this problem?” type deal.
The problem being essentially, because you maintain a connection with the DB server (because the application is persistent), if it gets restarted the application flaps – because the server kills the connections. It’s not really feasible to ask people to try/catch the specific exception, and because of one of the features of the server that isn’t available anywhere else (it’s essentially a minimal preforking HTTPD – though not intended to be used as one, I’m actually considering killing the process if there’s no forwarded-for header – to make it a “on your head be it” type deal), it’s very hard to catch this stuff further up the stack. You can’t just pretend it’s not happening and kill the child when you’re working with a forked server like this – if you have 10 children you’re going to output errors for 10 clients which is not really what you want to be doing.
I experimented with using semaphores to resolve the issue, which didn’t work too well and was kind of ugly – and it made the code that much more complex.
The solution I came up with was to catch the problem in the PDO class (currently only for MySQL), and create a new kind of exception that gets caught in the routing code (the chunk of code that decides where requests get sent). This then redirects the client to the same page (302/Location headers) and kills the child, the system then does what it usually does when children die – fires up a new child, which creates a new instance of the app class – which will reconnect to MySQL.
It also shows you the problem with being very hands-off with what people who use systems you write, if you’re not paying attention you can create problems that you don’t anticipate then the day you let people play with it somebody restarts a server in production and the world ends. So you basically have to force people to work like you want them to.
So I’ve been working on a major Paste2.org update for a while now. One of the major things I’m currently doing with it is making it work in the application server I described in my previous post. The improvements in performance will mean it’ll scale to the traffic increases it’s been getting for some time to come without needing to upgrade it’s infrastructure. A few times paste2 has came very close to breaking into the top 10k sites in the Alexa rankings, and consistently hanging around the 20k mark, meaning it’s my most successful personally-owned site to date. To some people it might not be that impressive but I guess it’s a bit of a milestone for sites I personally own.
I’ve also either added or are working on adding a few new features. View full article »
What I really wanted to talk about is an application server that I wrote for PHP. The problem I identified a while back is when I’m writing code in PHP the thing I’m doing most of the time is writing web applications. Now PHP is usually fast, at least that is, when you’re not writing huge sites that take a lot of requests. The way PHP is normally, historically, implemented is for every page request you have to build up and tear down your application, and with some SAPIs you have to also build up and tear down the PHP binary on top.
That presents a problem for performance, in that every time somebody requests a page you’re doing a lot of work to get the application to a state where it can start spitting out content – then at the end throwing away all that hard work you did. It wastes physical time and CPU cycles, not forgetting often IO and memory in the process. To resolve the issue you have to make your application persistent, which is something that PHP isn’t designed for in this context. View full article »
