Technology

Pagoda Box – scalable platform for your PHP application

I got my hands on a private beta of Pagoda Box. It is a platform that you can deploy your PHP applications to. I gave it a brief look around and I have to say it’s pretty sweet.

Right after you register and get access to your dashboard, you can add applications. Applications are cloned from GitHub repositories. Both public and private repositories are supported. Once you add an application, you can access it at http://your-app-name.pagodabox.com. If you’d rather have your own domain – you can assign it to your application from the dashboard and all that will remain to be done is adding an A-record in your DNS zone. Super easy!

There is more to it, even at this beta stage. Pagoda Box supports a number of PHP frameworks, including all major ones – CakePHP, CodeIgniter, Lithium, Symfony, Zend, and more. You can also optionally have a MySQL database for your application. They even help you out with outgoing email.

On top of that, you have control as to how many instances of the application you want (the more you have, the more requests you can serve at the same time, and the more you’ll have to pay). There are statistics of your application performance, requests, and a few other parameters (I’m sure those will grow together with the project).

I’ll admit, I am too used to hosting my projects on my own servers to take immediate advantage of Pagoda Box. But I am now seriously considering which projects I can move out of my server and into this platform. It just makes things so much easier. Deploying and re-deploying works wonders for any GitHub commit of your project. Initial resources that one usually needs to try an idea out are free of charge. If the idea picks up, the prices are more than reasonable (and comparable to other hosting solutions).

Out of those things that I consider necessary, I haven’t see any mentioning of files (uploaded via application, for example), support for build systems (such as Phing), and some sort of common library of frequently used code (PEAR modules, for example). But I’m sure that either I simply didn’t look for these hard enough, or they will be added in the future.

If you are a PHP developer or involved with PHP source on GitHub in any other way, I suggest you try it out. You can request a private beta invite directly from Pagoda Box website. Or, if you prefer, I can send you one (I have about 10 of them left for now). Also watch the demonstration screencasts, and read through other platform features.

Google push for modern browsers

Here is a quote from this Google blog post:

[…]soon Google Apps will only support modern browsers. Beginning August 1st, we’ll support the current and prior major release of Chrome, Firefox, Internet Explorer and Safari on a rolling basis. Each time a new version is released, we’ll begin supporting the update and stop supporting the third-oldest version.
As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.

All I have to say to this is: Bravo Google! Enough is enough!

As pretty much anyone with a computer science degree, I was a big supporter of backward compatibility at the beginning of my career. Backward compatibility just comes naturally. Each and every textbook, boss, and mailing list opponent tells you to care about each and every user out there. Often, with a complete disregard for your own costs. Completely forgetting that backward compatibility is extremely expensive.

There has also been a huge change in software development since my college times. The change is called the Web. Backward compatibility was more important in the old days, when software was installed on a computer and when it had to be distributed via such inefficient ways as compact disks. Since then, software development had largely moved into the Web. Updates can be pushed out to users several times a day and they require no effort on the client side. That has to count for something. All that is asked in return is that your web browser is of a reasonably recent version. And not even that it is of any particular brand – you can chose from a few options, and you can have the choice no matter what kind of computer or operating system you use.

To those scared of the updates and what such changes can bring to them, consider other example, which exist in open source software. Fedora Linux distribution, supports less than two releases back. Painful? Maybe. But it’s a desktop oriented software collection, with a very painless upgrade process (albeit a few examples, such as a recent Fedora 15). What is the result? Most of Fedora users are upgraded to the latest or so version. Compare that with a huge chunk of enterprises running Windows XP, which is a 10 year old operating system, and you can see the difference.

Most modern browsers provide automatic upgrade functionality, which makes user life so much easier that there is really no reason not to upgrade. The only argument for older browsers that I’ve heard to now is support of legacy applications that only work in specific versions of specific browsers. And you know what, I have no problem with getting rid of those. The world will be a better place. It’s been years since we have web standards, browsers that support them, and plenty of tools that assist in development and migration. If you haven’t moved your application in all these years, chances are you’ll never will. In which case, you deserve all the troubles that you are about to get. The world shouldn’t hold its breath waiting for you to upgrade.

Heck, when even Microsoft is jumping out of its pants for people to upgrade MSIE 6 to something newer, you know there is a problem. And solving it once and for all (rolling release version support) is an excellent approach. I hope more people will follow this example.

P.S.: Please excuse the lack of links. The things I mentioned have been discussed many times all around the web and I do see them as obvious truth. Those of you who need references, shouldn’t have any troubles finding some. If you do – let me know.

Cyprus Hack Day

I got a message today via an almost non-existing mailing list of Cyprus LUG (Linux User Group) about the following event (please forgive my reformatting, translation, and interpretation):

Event: Cyprus Hack Day
Date: Wednesday, June 1st, 2011
Time: 16:30
Location: University of Nicosia (used to be known as Nicosia campus of Intercollege)
Price: Free
Registration: Online, via Cyprus Computer Society website.
Agenda:

Presentation “Chaos in the cloud” by Dr Mike Chung, KPMG Netherlands

Presentation “The emperor has no clothes: Remote Access Trojans (RAT) – A Unique Danger” by Andreas Constantinides and Angelos Printezis, Odyssey Consultants Ltd.

Demonstration “Hack-Jutsu 101” by Demetris Papapetrou, Information security researcher.

Organizers:

Cyprus Computer Society

Cyprus InfoSec

Vim tips of the day

I’m using Vim text editor for more than decade now. And I still can’t say I really know Vim. I’m used to it and my fingers remember the commands. And for those commands that I don’t remember, I’ve found some way of working around and got used to it too. Today I came across not one, but two tips that I’m adding to my arsenal of Vim tricks.

Re-selecting visual block

Usually I only need to select the block once. I then process it and never get back to it. But sometimes, I need to select the same section of the text a few moments later. Until today I was simply switching to visual selection and marking the block again. Not too much of a problem, but it would be nice to have a shortcut for re-selecting the previous selection. Of course, there is such a shortcut in Vim. I just didn’t know it. Simply type ‘gv‘ (without quotes) while in normal mode and your last visual selection will be selected again.

Increasing line limit on cross-file copying

There is no limit to number of lines copied between files, if all files are being edited in the same instance of Vim. However if you copy a large selection from one file, then quit Vim, then open another file, and paste, you’ll probably see that only the first 50 lines or so were copied and the rest was lost. Again this is not such a frequent scenario for me, and when it was happening I was simply opening both files in the same instance of Vim and copy all that I needed. It turns out, I don’t really have to do that.

Vim uses ~/.viminfo file (default location) to remember things like command history, file marks, and registers between Vim instances. There is a way to configure what and how much of what is going into this file. If you are annoyed by any limits, you can easily raise them or totally remove them. Have a look at “:help ‘viminfo’” manual page to see what is possible. Adding “set viminfo=’100,<1000,s100” to ~/.vimrc file solved my problem.

P.S.: my messy Vim configuration files are available from GitHub, in case you wanted to take a pick at what else I have there.

Gnome3 Tutorial

Here is one solid piece of advice I can give you after spending way too much time tweaking Gnome 3 in the last few days: read this Gnome 3 tutorial. Don’t just scroll through it. Read every single word of it. It will save you a lot of time and hair pulling. I promise.