Tag Archives: development

Flomo iphone app

icon.pngA few weeks ago I decided to start playing around with iPhone app development. It would, I thought, be a relatively straightforward thing. Even small children could do it.

But what to choose as a test project? Perhaps something stupid that made some kind of farty noise each time you shook your iPhone? Nah… build something useful Matthew. Something I and others like me would want to use.

Uploading images to Flickr seemed like a cool idea. There are some really nice apps out there that do this already. Hmmm…

Another thing was simple image manipulation. You know, make your crappy iPhone photos look like you took them with a Lomo ie turn them into something bad yet cool. Already done. Hmmm….

I know – combine the two! Brilliant idea! Let’s call it Flomo (flickr + lomo). Lame name – yes. Arsed to think up a better name – no. I even designed a funky logo (above).

Turning the idea into reality has proven to be somewhat more tricky than I’d thought. Trying to run before learning how to walk is a cliché that springs to mind. But it’s been a useful lesson in iPhone development.

Specifically it’s taught me:

1. How to access flickr’s API. Authentication with their API is like sticking hot pins in your arm at the best of times, never mind in an unfamiliar language (Objective-C).

2. Objective-C doesn’t have a simple way of doing MD5 hashes. It’s a pretty much build your own kind of thing. Ugh.

3. How to process images. Thanks to some online help and general banging-head-on-wall type thinking, I’ve finally realized that image processing isn’t all that hard. Neither is it easy. Finding stuff on forums like (I paraphrase) “listen you newbie scum, this kind of thing is so trivially easy I’m not even going to explain how to do it” didn’t help. But I got there. I’ll publish relevant bits of my code in the next post.

4. Multithreading is really useful. Do you want a nice spinny wheel thing while the image is uploading, so your user doesn’t think the app has broken? Well you *have* to use multithreading. Obvious if you know that it’s obvious. Like so much in iPhone world.

5. XML parsing? Not easy and not fun. Just parsing a simple web service response is bad enough. Making any sense at all of complex XML seems like far too much hard work. PHP SimpleXML – I love you!

There are all kinds of other bits and pieces which I’ve had “fun” with. I’ve probably implemented them really badly. But I don’t care. I have an iPhone app which works. Just a little more work and it’ll be ready to submit to Apple and wait months before it ever appears on the store for free.

Oh, and those news reports about small children coding for the iPhone? Two words: parental guidance.

IWMW2009

The Institutional Web Management Workshop (IWMW 2009) will be held at the University of Essex from Tuesday 28th to Thursday 30th July 2009.

This is generally a great chance to catch up with what’s going on in the Higher Education web world. Oh and there’s great food and lots of booze too, not that I’m swayed by such things of course…

Beginning iPhone Development: Exploring the iPhone SDK

iPhone development isn’t really all that much fun, but the end results can be very cool. Dave Mark and Jeff LaMarche have written a really nice introduction which makes the whole process seem just about manageable. Almost cool and quirky even.

Importantly, it successfully captures the key to the iPhone’s success as a development platform: anyone with sufficient determination (yes, you!) can get through the unnecessary and bizarre horrors of Objective-C and the iPhone SDK, and can produce something that people might pay some money for. It’s something you can almost impress people with at parties. Almost.

Of course the book has an online forum and downloadable source code – de rigeur for coding books these days, but good to see nonetheless. In summary, if you want to try your hand at some simple iPhone apps, you really will need this book.


Drupal in perspective

Drupal prides itself on its community aspect. And so it should as a truly open source system. One of the good things to come out of this is the principle that dissenting voices should be given a platform. Hopefully what they say gets taken on board too. A talk titled ‘Why I hate Drupal’ at the recent DrupalCon in DC is a great example of this principle.

‘Why I hate Drupal’ was given by James Walker, one of the Lullabot team, and general Drupal insider and guru. It’s important to point out that this isn’t just some bile-filled sour-grapes rant. It’s a considered, insightful and eloquent discussion of some of the problems and issues with Drupal as it grows in popularity, and enters a new, more mature phase of its life.

Here’s a link to a video taken of the talk. It’s an hour long, so you may have to book out some time to watch it. It’s worth it though.

http://dc2009.drupalcon.org/session/why-i-hate-drupal

Pro Drupal Development 2nd Edition by John K. VanDyk

Pro Drupal DevelopmentIf you want to get at all serious about taking Drupal beyond a simple installation, Pro Drupal Development is going to be a massive help to you. If you’re anything like me you’ll come back to it again and again for reference and to try out some new ideas. 

It covers all kinds of development areas such as building your own modules, the form API, themes, and even best practices. All this kind of stuff can be found online, but it’s a big help to have it all clearly explained in one place. Sometimes you just need someone to guide you through the maze of options that Drupal offers. 

Much of the book isn’t for the faint-hearted. You need a good working knowledge of PHP and some MySQL. Most books start you off nice and easy, but here the early chapters are very much a leap into the deep-end. There’s a certain amount of reliance on just accepting fairly esoteric Drupal stuff until it’s explained more clearly later in the book. 

The book also comes with plenty of examples, which you can download for free from Apress. These really help you get your head around some of the trickier ideas (I found one or two of the examples didn’t work as described – but to be fair there are some errata by the author on the Apress site). 

In summary – this book is an excellent buy if you want to take Drupal to the next level but don’t know where to start.

Using Drupal by Angela Byron

Using DrupalUsing Drupal is a great little book if you’re just starting out with Drupal, and want to know which modules could be useful for you. If you’re getting into true development stuff and want to play around with Drupal a bit more, the excellent Pro Drupal Development by John VanDyk would be a much better choice.

This book was written by members of the Lullabot team, who do Drupal consulting and development work. They really know their stuff, so you feel things they suggest in this book (like choosing module x over module y) are worth listening to.

The book itself guides you through typical scenarios you might want out of a Drupal website, like wikis, a shopping cart, workflow, multilingual sites, etc, etc. Each section has some useful tips and ideas, but doesn’t go into a massive amount of depth. So again, great if you’re just starting out and want a flavour of what’s possible.

wordpress mu XSRF

Cross-site request forgery (XSRF). It’s something that’s becoming a big issue in internet security, and yet is still relatively poorly understood by many developers. If you don’t already know what it is, you can find an excellent introduction in wikipedia:

http://en.wikipedia.org/wiki/XSRF

In a nutshell, anything on your website is a security risk if it lets someone modify something on your system (eg an entry in a database) without first making sure that the request for that modification actually came from your site. This isn’t restricted to a URL query string. Forms are probably the worst offender because many developers seem to think they’re somehow safe. They’re not.

A good way of preventing a XSRF attack is to give each form a unique identifier which keeps changing. Only your web application will know for sure that a request has come from a form on your site, because that application generated the identifier in the first place and can cross-check it against an entry in a database. Drupal does this, and so does WordPress (including WordPress MU).

Here I’m focusing on how WordPress MU does the XSRF protection. It’s called, wait for it…

Nonce?

ok, ok. Get the sniggering done now. And relax…

To the good people at WordPress (and seemingly everyone in America) nonce has only one – very unfunny – meaning: a word or expression which only ever occurs once. ie. a unique key which changes its value every time it’s used.

By default all WordPress forms use nonce values to help prevent XSRF. If you write your own plugins, to get this to work in WordPress is amazingly simple. Just put this in your home-grown form:

 wp_nonce_field('my_nonce_phrase');

where ‘my_nonce_phrase’ can be any unique phrase which acts as a base for the system-generated nonce key. It’s usually a good idea to use something like plugin-name+form-name so you eliminate the risk of clashing one nonce value with one from a different form. But basically you can use any phrase you like.

If you need more info, the WordPress API listing is here:

http://codex.wordpress.org/Function_Reference/wp_nonce_field

If you want to put a nonce in a URL rather than a form, just use the very similar:

wp_nonce_url('theurl', 'my_nonce_phrase');

where this time ‘theurl’ is, predictably, the url that you want to noncify, and ‘my_nonce_phrase’ is once again your unique phrase which is going to act as the seed for the eventual nonce key.

Whitelist

There is however a slight catch. Some forms on the backend are forms where you want someone to update various options parameters. For example, if you’ve built a plugin and want someone to be able to set various plugin default options. In standard WordPress, you use options.php as the form’s action, and can use the following as a nonce field:

wp_nonce_field('update-options');

This way, when the update button is pressed the fields you’ve added to your form will automatically get updated as part of the options.php code, and the nonce system will be happy that the form came from the right website. Everyone’s smiling. Everyone’s happy.

This doesn’t work with WordPress MU, however.

Instead you need to add this to your form:

wp_nonce_field('my_nonce_phrase-options');

where adding -options to the end is crucial if you want options.php to work properly. I’m not sure why. It just is.

Finally, in your plugin you need to be able to alter the nonce whitelist ie. the list of option names which are accepted by options.php. You could just alter options.php, but that would be crazy. Instead use a filter to intercept the whitelist and add your own values to it:

function my_plugin_alter_whitelist_options($whitelist) {
  if(is_array($whitelist)) {
    $option_array = array('my_nonce_phrase'=>array('plugin_option_1', 'plugin_option_2', 'plugin_option_3', 'plugin_option_4'));
    $whitelist = array_merge($whitelist, $option_array);
  }
  return $whitelist;
}
add_filter('whitelist_options', 'my_plugin_alter_whitelist_options');

Yes, it’s ugly and bad. But there doesn’t seem to be any way round this for WordPress MU and forms used for setting your own options in a plugin.

Summary

WordPress MU lets you build forms which are relatively safe against XSRF attacks. Doing this is easy, and takes just one line of code in your form. A word of warning: adding protection to forms which make use of WordPress’s options feature is more fiddly in MU than it needs to be, but still not too bad.

Review of Panic’s Coda – One-Window Web Development for Mac OS X

I’ve recently been trialling Coda, Panic’s web development environment for Mac OSX. It currently costs $99 (about £65 at current rates) per licence, and offers a fully-featured 15-day trial before you burn your money. The version I’m looking at here is 1.6.2.

Coda sells itself as offering a complete environment for all-round web developers: somewhere to do your coding, a css tool for the design-oriented, and built-in subversion, FTP and SSH tools to transfer your masterpieces from your localhost to your live environment. In other words… an IDE (although it’s perhaps telling that it never uses that acronym in its sales pitch).

Coding
Coda offers a passable pure coding environment. It has all the basic text editing things: fancy colours, a certain amount of text completion and insertion (e.g. comment blocks). I don’t want to bore you with a list all the small details I found wanting in its text editor. Some of the bigger issues I had were lack of diff tool, and the inability to search across an entire project (or ‘site’ in Coda-speak). On the plus-side the editor did have a nice visual list of functions in your code. Macromate’s TextMate is often compared to Coda (a not entirely fair comparison, but anyway…), and to be honest in terms of code editing offers lots of things Coda doesn’t, and all the things Coda does. So, take your pick…

Styling
The css editor is pretty much what you get from tools like MacRabbit’s CSSEdit. You get to edit your css with a user-interface rather than hand-coding the stuff. That’s pretty much it. I’m left wondering just how useful Coda’s CSS tool is. If you’re proficient in CSS then do you really need a GUI to help you? If you’re not proficient in CSS then you’ll still be confused because Coda assumes you have some knowledge of how HTML and CSS work together. It’s a kind of irritating half-way house which I suppose might make life easier for half-way-house developers. I’m not sure.

FTP/SSH
One of the really nice things about Coda is that you can fiddle around with a local copy of your website and FTP it up to your live hosting account, all in a simple, integrated way. When you alter a file a little icon appears next to it in Coda’s file browser. Just click it, and off it goes. It really is very simple and easy to understand. So it has the same feature if you’re working in a more serious environment, where SSH is the only way to transfer? Erm… nope.

No quick-and-easy scp-equivalent? Let’s just stop here and digest what Coda’s all about. Those of you wondering what scp is will probably be ok with Coda. Those of you who know will probably realize that Coda’s aimed primarily at semi-pro developers who need to access hosting accounts with FTP. If you work in a professional environment where servers are locked down to such an extent that SSH is probably your only means of access, well one of Coda’s main selling points is lost.

To be fair there is an SSH terminal. My feelings are that this has been bundled to make Coda look more professional and justify a higher price-tag. Why is it any easier to click a button in Coda taking you to the terminal, than it is to switch to a terminal in a different window? Cmd-Tab? At best you might consider it a very, very minor advantage. At worst it confuses Coda and makes you wonder whether it’s trying to pitch itself at semi-pro or at professional developers. Is it for the Rails and Symfony developers out there? Who knows.

Preview window
Coda’s preview window lets you see your webpage as it would appear in a browser. Well, actually it shows you how you web page does appear in a browser, because the preview window is basically just a browser window. Again, I’m left asking the question: Cmd-Tab? Personally I found it more useful to analyze my CSS changes in Firefox + Firebug. Note too that the idea that you can review a single page of your website as a complete entity is a very out-dated and curiously amateurish one. The idea that ‘blah.php’ as a file actually renders a page of HTML is verging on the laughable: there will typically be dozens of files involved in rendering a single web page. Any serious (PHP) web developer would surely be using either home-grown code developed in a framework such as Symfony, or would be modifying available web apps such as Drupal or WordPress. The only way to view a ‘page’ in any vaguely sophisticated web app is to view it in a browser with a web server running. All this makes Coda’s preview window largely defunct. Once again, just Cmd-Tab to Firefox or something. Is it really that hard to do?

Subversion
A big selling point of Coda has been its inclusion of some kind of version control mechanism for your code. In this case subversion. The user interface is nice, although a little basic. Any checked-out code will display little icons next to the file name in the file browser. If you’ve made a change, you’ll see a little ‘M’ icon appear next to the file, which you can click to commit to the repository. It’s all very neat and rather lovely.
This does seem to be one area of Coda that works well. You will have to rely on terminal svn commands for some things, but most day-to-day stuff can be done very neatly and easily. Incidentally, TextMate includes very similar functionality. It doesn’t have the useful icons to let you know when something is out of sync with the repository, so for me Coda’s svn scores a point over TextMate here.

Conclusion
Coda looks lovely, and feels like something designed for semi-pro web developers. I can’t imagine hard-core designers and CSSers finding it particuarly useful, and hard-code programmers and coders won’t find its text-editing functionality up to scratch compared to much cheaper/free tools like TextMate, JEdit, or Eclipse. The preview window and SSH terminal features feel like a bolt-on, and honestly you’d have to be pretty lazy to find Cmd-Tabbing to another application much harder than pressing a button on Coda’s UI. The lack of integrated scp functionality will be annoying for many developers.

Coda costs $99, and could be a really useful value-for-money tool for semi-professional web developers who appreciate the convenience of having almost-TextMate, almost-CSSEdit, almost-web-browser, and SSH terminal thrown into one eye-candy package. Dreamweaver it ain’t. For starters Coda it has none of the HTML-building capability of Dreamweaver.

For about half the cost of Coda you can buy TextMate, CSSEdit, and use Firefox and an SSH terminal. Ok, you have to switch between them which is a slight inconvenience. But you do get more functionality for less cost. At the end of the day it’s all about what you’re comfortable with as a developer.

symfony and LDAP

I’ve recently been looking at the essential (ie why isn’t it included in the core?) symfony plugin sfGuard. It offers are really nice, simple way of building a simple user, role, and permissions system into your symfony app.

The great thing is that with a little tweaking (documentation not great) you can add a custom LDAP lookup class, which overrides the standard built in user password lookup. Ok, you need to write your own class, or use a 3rd party one. But the basics of LDAP are built into php5, and it’s really not hard to do.

One problem I had was that sfGuard is designed to make it impossible to do an LDAP lookup and an internal check for a superadmin user. The reasons are a little esoteric, and have to do with mixing static and non-static contexts. Basically, the only option is to change one of the sfGuard library classes. Specifically sfGuardPlugin/lib/model/plugin/PluginsfGuardUser.php

Adding in this fixed things:

    if ($callable = sfConfig::get('app_sf_guard_plugin_check_password_callable_both'))
    {
      $result = false;
      $result = $this->checkPasswordByGuard($password);
      if (!$result)
      {
        $result = call_user_func_array($callable, array($this->getUsername(), $password));
      }
      return $result;
    }

which meant I had to use a special ‘check_password_callable_both’ option in the app.yml file. But at least this way it did checkPasswordByGuard() first, and then tried my added in LDAP class second.

Is there another way of doing this? I don’t know. Probably. But this seemed to work for me, and perhaps could be included in the sfGuard plugin by default. I guess I should get in touch with the developers to check…

 

symfony

I’ve recently been deploying some symfony (http://www.symfony-project.org/) applications at The University of Kent. I’m pleased with the results.

symfony logo

Symfony is an MVC framework, along the lines of Ruby on Rails, but based on PHP5. It is widely used, including yahoo bookmarks:

http://www.ysearchblog.com/archives/000376.html

and the beta of the new version of del.icio.us:

http://www.symfony-project.org/blog/2007/10/02/delicious-preview-built-with-symfony

Why?

So why did I choose symfony as a framework for web development at Kent, as opposed to the many others (for example cakePHP and codeIgniter)? There are lots of reasons, as I’ll show later. But the three most important are:

  • it’s well documented
  • there’s a good and helpful user community
  • it’s very powerful

Huh?

Documentation? No, don’t need that. Well clearly that’s what a lot of frameworks seem to think. Although most frameworks – and certainly cake and codeigniter – have great communities, their documentation isn’t always great. For example, cake has a kind of ‘getting started’ document and then sort of leaves the rest up to you. Fine if you want to do basic stuff, but not so great if you want more.

Plugged in

The key thing with a good community, apart from helpful advice on forums, is the availability of plugins. Symfony has loads of those, as you can see here http://trac.symfony-project.com/wiki/SymfonyPlugins. Many are pretty esoteric, but a lot are really useful, such as a really nice user security plugin called sfGuard.

OOPs

As for being powerful, the thing you notice first off with symfony is that it’s only compatible with php5. Only? That seems odd. Brave almost. But surely they could’ve tweaked things a little to get php4 support? Once you take a look under the hood, you realise that symfony is totally object-oriented. Inheritance, mixins, overloading, public/private/protected. It’s all there, beautifully structured. What’s great about the use of OOP and php5 is that symfony uses autoloading, so a lot of classes (including plugins) are easily available without lots of includes all over the place.

Less is more

OK so symfony sounds complicated, and in many ways that’s true. The real power of the framework comes from its flexibility. There are dozens of configuration files which let you change many aspects of how your application works, from how the urls appear to fine details in a pre-generated backend system. This power creates complexity. But really, any good php developer ought to be able to cope with this kind of thing.

But the power of the system also lies in its potential to bypass many parts of symfony altogether. For example, you don’t have to use the built-in database abstraction layers. Just use anything you want instead, including (heaven help us!) raw SQL. You don’t have to use the built-in scriptaculous ajax methods (but why wouldn’t you).

Scriptaculous

Which brings me to another nice feature: ajax. Although not unique to symfony, it is nonetheless made spectacularly easy in symfony to do some really nice things with ajax. And I do mean the real asynchronous ajax stuff, not just the javascript eye-candy that has become known as ajax.

Saving time

One of the main reasons for using a framework is to give your code some structure, rather than the usual ordered chaos of a hacked-together website. That’s all very well, particularly for big projects. But a real plus for many developers is the ability to produce web applications quickly. symfony can help there too.

One feature that really helped me recently was the admin generator. Beautiful. I basically made a mini-phpMyAdmin interface in about 5 mins. Add to that the sfGuard plugin for authentication and authorization, and in about 10 mins you have a fully-featured admin system. And it actually looks good too.

There are also great time-savers for things that sane developers hate. Things like forms and input validation.

Summary

symfony is a great way to save time and develop good, maintainable code. It’s a powerful framework, and is surely set to grow, particularly now that yahoo have adopted it for a couple of applications. It’s not perfect, but offers a huge amount of power and flexibility, and speeds up application development significantly.