By Ben Griffith | 23 April 2013 | Comment
Since its initial release in 2010, jQuery Mobile (jQM) has developed a well deserved reputation for being a flexible mobile framework. jQM's philosophy can be summarised in 3 points:
- It offers a unified system
- Allows universal access, and
- Is easy to develop with
We all love a slick functionality fueled website, but are your users being given what they want, when they really want it?
Your homepage gives your user the opportunity to sign up to your newsletter with some nifty validation, check out your office location on a google map, interact with your content on a social level and look at your great photography in a carousel. This is awesome, but we know they can't do all of these things simultaneously, right? When the user lands on your page, all they need to know is that they can do all these things - if they so wish.
Continuous Integration is the
process where code from a developer's repository is called by an
automated system, built and tested against a set of standards that
the developer has created in their tests. In this post we look at the steps to create a server
that will automate your testing suite - and hopefully make you more
Doctrine's ORM Module offers a very simple and elegant way to integrate the Object Relational Mapper (ORM) into Zend Framework 2 (ZF2) . There are a few really handy classes shifted with this module, allowing Doctrine to be nicely integrated with ZF2 components. Here are a few useful components like paginator.
By Zdenek Machek | 16 November 2012 | Comment
Docblock Annotations in Doctrine is a really nice way to specify object-relational mapping metadata. But ZF2 also comes with a Zend\Form\Annotation class for specifying field properties on forms. Wouldn't it be nice if you could combine these two? It turns out you can. Let's have a look at how easily a Doctrine entity can be turned into a Zend form.
By Zdenek Machek | 01 November 2012 | Comment
Doctrine 2 filters are a very powerful feature allowing you to easily modify every request sent to the database. This comes in very handy when you need to implement a soft delete filter: a filter which will load only records from database which are not marked as deleted.
With ZF2 dependency injection (DI) support, this is really easy to configure.
Just been checking out CloudFlare ahead of the Homeless World Cup next month. Every year the site goes mental during the tournament, but we're expecting even more this year: evidently YouTube is on board with the live video we'll be doing from pitch 1, and I understand that sponsor TelMex is planning to keep its many customers updated throughout the event. We're also planning some serious Twitter, Facebook and other social activity around the event, together with a focused live reporting operation.
It's hard to forecast traffic levels around something like this, and therefore hard to quantify exactly what server resources we'll need to keep the site at peak performance. Ideally we'd be hosting in an elastic cloud, but realistically this is a job for another time; instead, we're currently using a Rackspace cloud setup, which does give us the option to scale operations up fairly quickly if required.
Meanwhile, we've also been looking at various options to optimise parts of the application without the need for major rewrites. One of these is around the delivery of static assets. We were considering various CDN-type solutions, and even setting up our own quick nginx reverse proxy to do the job - until Paul mentioned CloudFlare. So we gave it a trial run on a dummy Loft domain, and have to say - very impressed indeed.
Squeezing the most out of a web server...
Ever thought of setting up a reverse proxy to serve your static content a lot faster than the lumbering giant Apache? Don't get me wrong, Apache is still one of the best web servers going and used by over 60% of the Internet. The problem is, it is too good, and we wake this slumbering giant up for everything! Instead, we could be getting a smaller package to nip in and do the job without the excessive memory overhead.
The setup is simple!
Get Apache to work on the LO interface (127.0.0.1 - yes, even on port 80!) and set nginx up to serve on the public IP on the usual ports. All we need to include in the vhost for nginx is the proxy pass syntax to 127.0.0.1:80, etc., and think about forwarding headers, etc., and .... voila! We have a small process serving static content, and only looking to Apache when it is unsure what to do when dealing with things like PHP.
The best part for a sysadmin like me is security. Apache is protected against most 0 days, and in the event of a 0 day on nginx we can drop it from the line-up and within a nanosecond have Apache run the show direct (usually with no downtime either).
GNU Screen and tmux are terminal multiplexers designed for Unix-like platforms. They are basically window managers for text consoles instead of the X Window System. Screen is the more heard-of terminal multiplexer.
tmux-only features include:
- Client/server system - a server instance is started automatically when a session runs as a client for that server, which leaves less of a footprint.
- Synchronize-panes - duplicate input from any pane to all other
panes in the same window. A bit like a clusterssh function to
simultaneous input to all of the terms all at the same time.
ctrl+b :set-window-option synchronize-panes [on|off]
Screen only features include:
- Zmodem transfers - the abilty to transfer files when all you have is a serial connection available. Although this sysadmin does not need to use this feature.
- Attaching to a serial tty - such as screen -r /dev/ttyS0 115200 in case you lose a session.
- Naming of invidual panes - you can name each pane in case you loose track of things! TMUX wins for me
I first started using Screen, but I quickly found tmux to be the
better option. With less of a footprint to deal with, I could have many
hands on one server with out the need to keep spawning servers. I also
found tmux had a better mastery of panes (as a terminator user very
important!) and the conversion from Screen was simple after getting used
to using ctrl+b instead of ctrl+a.
Working with PHPUnit and Eclipse PDT has always been a bit of a pain. We ended up using it as an external tool, and it worked, but it wasn't pretty. Then one day, I discovered the MakeGood plugin for Eclipse. Not only does it enable you to run tests directly within Eclipse, but you can also set it to use PHPUnit's configuration and bootstrap file - and this means you can debug tests in Eclipse in just the same was as any other PHP script, using the Xdebug PHP extension.
This is a lifesaver, once you've got it set up. But it does take a few steps to get the whole
thing up and running, which can be tricky if you haven't done it
before. So here a quick guide from the Loft folks.