Strict Standards: Only variables should be passed by reference in /home/rickhurst/sites/rickblog.eatstatic/lib/eatStatic/eatStaticBlog.class.php on line 595 Strict Standards: Only variables should be passed by reference in /home/rickhurst/sites/rickblog.eatstatic/lib/eatStatic/eatStaticBlog.class.php on line 595 Strict Standards: Only variables should be passed by reference in /home/rickhurst/sites/rickblog.eatstatic/lib/eatStatic/eatStaticBlog.class.php on line 595 Strict Standards: Only variables should be passed by reference in /home/rickhurst/sites/rickblog.eatstatic/lib/eatStatic/eatStaticBlog.class.php on line 595 Strict Standards: Only variables should be passed by reference in /home/rickhurst/sites/rickblog.eatstatic/lib/eatStatic/eatStaticBlog.class.php on line 595 Rick Hurst's blog :: Web Developer, Bristol, UK. PHP, Django, Front-end

eatStatic blog software current roadmap (November 2012)

This post was written 4 years ago.
Mon, 12 Nov 2012
I've written a post about the current plans for the eatStatic blog software (that this blog runs on), on the demo/ documentation blog.
Tags: eatStatic /

Sub-optimal web content workflow used by many agencies

This post was written 4 years ago.
Fri, 09 Nov 2012
I've worked at a fair few agencies in my time, and despite most agencies now using content management systems as standard, the content population and revision workflow is usually sub-optimal:-

  1. Designer inputs the content into a photoshop file
  2. PNG or PDF of the document is signed off by the client, or amends requested, which the designer deals with
  3. Developer copies the content into the CMS (they may need to create some custom content-types or templates to make this work)
  4. If the content needs to change - the designer is asked to change the photoshop document, and back to step 2
  5. At no point will the client touch the CMS, or entertain the idea of a few days training in basic HTML or markdown*

Yes, I think we can all see a flaw with this workflow - no need to point out how things could be done differently in the comments!

* I don't care if your CMS has a really good WYSIWYG editor - it's either too limited or too powerful, so an untrained editor at best will never really get the result that they want, at worst do some real damage!
Tags: cms / wcm / workflow /

Pushing a local git repo to a bare remote

This post was written 4 years ago.
Thu, 08 Nov 2012
Often I create a git repo locally, but then want to push it to a remotely hosted repo.

On the server, create a folder and move into it, then:-

git init --bare

Then in your local git repo:-

git remote add origin ssh://username@yourserver/path/to/repo.git
git push --all origin

(this assumes your remote repo is accessible via ssh)
Tags: git /

A few notes on image uploading and configuration in Django

This post was written 5 years ago.
Fri, 10 Aug 2012
I recently added image uploading to Too Old To Skate, and not having set up a "normal" django site for a while, hit about every stumbling block possible, so here are a few notes. Please bear in mind there may be other, better ways to achieve this - i'd love to hear them.

Adding an Image field
This is achieved simply by adding an ImageField to your model, e.g.:-

photo = models.ImageField(upload_to='image_uploads', blank=True)

Separate static and media directories
The static folder is where your local site assets go e.g. CSS and Javascript. Locally these are served up from /static/ by the django dev server, and on a live site this should be set up as aliases to serve by your web server (in my case Apache).

The media folder is where user-uploaded files go, in subdirectories specified in 'upload_to' in your image field in the model. The root is configured in settings.py, but unlike the static folder you will need to do some configuration to get the local dev server serving files up from this directory (and its sub-directories). The location of the media root needs to be different to static root, which threw me slightly, though I guess it makes sense to keep your own static assets and uploaded media entirely separate.

To get the local dev server serving up files from /media and its subdirectories, add this to urls.py:-

# you'll need to add this if you aren't already importing settings
from django.conf import settings

if settings.DEBUG:
urlpatterns += patterns('',
(r'^media/(?P.*)$', 'django.views.static.serve', {
'document_root': settings.MEDIA_ROOT}))

Permissions
Permissions need to be set on your media folder to allow uploaded files to be saved. This depends on your set-up, but for me adding write permissions for group allowed apache + wsgi + python (whichever one of those it appears as?) to save files and create directories.

PIL and libjpeg
As usual this caused me massive headaches to get running both locally and on my web server, and as usual I tried so many things i'm not 100% sure which steps actually made a difference in the end!
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: django /

Learning by Teaching (a crash course in Backbone.js)

This post was written 5 years ago.
Fri, 15 Jun 2012
rick hurst southville js backbone talk
On Wednesday, the day after my lightning talk at the Django meetup, I gave a talk "An introduction to Backbone.js", at a newly formed javascript meetup, loosely based around the locality of southville in Bristol. This was an interesting experience as other than using Backbone.js on one project (largely written by other people, so I only really dipped into it to add stuff), when I was volunteered to do the talk by Andy Mcgregor, I didn't actually know a great deal about Backbone!

When it came to the crunch, i.e. pretty much the day before the talk, I started searching for online tutorials that might demonstrate what I wanted to cover in the talk, and the first one that I found was Hello Backbone.js by Artur Adib, which provides a fantastic step through with a set of examples building up on the previous example. I created a little "To Do" list app based roughly on these examples.

I then found an excellent set of video tutorials called Introduction to Backbone.js, by Joe Zim, which run through some interactive examples for Models, Views, Collections, Routers and Ajax within backbone, which really helped the penny drop for me, and gave me a basis for my own live-coding examples. The audience (of about 20 people - not bad for a highly localised, highly niche meetup!), were a mixture of people who already know backbone and people who have never used it, but hopefully there was something useful there for everyone. On a personal level, being put under pressure to be able to demonstrate something, accelerated my backbone knowledge very quickly, to the point that I would confidently start my next project using backbone.

The moral of the story is - if you want to learn a new skill quickly, you don't need to pay to go to a workshop - volunteer to do a talk instead! Even if you don't want to do a talk, find your friendly local user groups (or friendly online user groups, if there's none local to you), and get involved. I'm not knocking paid workshops - there's a place for those and i'm sure some of them are good value for money, but i've always loved the way that the web community are happy to share their knowledge for free, and you really can find the knowledge out there without spending your hard earned cash! Being part of the web community provides valuable support too when you get stuck, something that doesn't happen in the world of "traditional" paid training.

The next southville js talk is "An introduction to CoffeeScript" by Tom Holder on wednesday 12th July, kindly hosted again by SimpleWeb. Also keep an eye on the Bristol Web Folk calendar for upcoming web related events in Bristol - there's loads!

Photo above nabbed from an instagram pic by Chris Mytton
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)

DBBUG lightning talks June 2012

This post was written 5 years ago.
Tue, 12 Jun 2012
Rick Hurst giving a talk on django snippets
On tuesday Potato Bristol hosted the Django Bristol and Bath User Group (DBBUG) lightning talks. It went really well and it was nice to have some technical content as well as the usual beer and chat. The turnout was great and so were the talks.

First up was Chris Hall - "Django from the outside in (and back again)" talking about his experience as a PHP/Drupal developer using Django on a project for the first time.

Second up was me, talking about my simple Django content management tool "Snippets" (shortly to be renamed as soon as I can think of something suitable, as googling around there are too many other similar projects under the same name). I was pleased by the response and interest in Snippets considering it is such a simple tool - mainly the result of an evenings experimentation. This gives me an incentive to develop it further, as it shows there is a demand for simple tools like these, especially if you just want to add a small amount of editable copy into a web app, but don't want the overhead of a full CMS.

Ed Crewe then talked about "using eggs for managed release and deployment".

Jamil Appa fron ZenoTech talked about "Using Django to front an application that makes
use of GPUs in the Cloud".

Lastly Russ Ferriday from SponsorCraft, talked about the spray project.

Ed has kindly created a lanyrd page for the event.

This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: dbbug / django /

Web developer tools of the trade

This post was written 5 years ago.
Fri, 01 Jun 2012
I've had to change machines a few times recently, and each time I wish I had a decent checklist of what I need to be able to do my job. I thought it might actually be an interesting blog post, detailing not just what I use, but why.

Machine: macbook air
I blogged about using a 13 inch macbook as my main machine for web development before, so I won't repeat it here - the main point I want to make here is that I don't want to be using more than one computer and it needs to be a laptop that runs some flavour of unix natively and will run the latest versions of Adobe Creative Suite reliably, and a mac laptop fits the bill. Why does it need to be a laptop? It was essential when I was a freelancer - I worked on site at clients offices and not many of them would supply a computer. My current employer provides hot-desks with monitor/mouse keyboard etc. for people to plug their laptops into.

OSes: OSX, Ubuntu and Windows
In the past i've experimented with Linux on cheaper non-mac laptops, but I always get caught out by needing a native version of photoshop running - using wine or VM's to do this has proved slow and unreliable. If Adobe really wanted to put a dent in Apple's revenues, they should release a linux version - I know many people who would drop OSX if they weren't dependent on Adobe products.

Why not windows as my main OS? Mainly because it doesn't run unix natively, but I also find windows a pain to maintain and keep stable and secure.

I keep Virtual Machines (VM) for when I need to develop or test stuff in windows - Windows 7, plus other versions for testing on different versions of internet explorer. I still look after some legacy classic ASP stuff, so for this I have microsoft webmatrix installed on the Windows 7 VM, which as a cut-down version of IIS for local development. I also use Heidi SQL as a GUI for MySql on windows, and Sublime Text (mentioned later) for code editing.

I also keep an ubuntu VM for LAMP development, mainly so I can keep it separated from the Python/ Django/ Appengine orientated dev environment I use in my day-job at Potato. It also makes it transportable and easy to back up.

Graphics Editor: Adobe Photoshop latest version-ish
I'm not a designer so shouldn't necessarily need Photoshop, but I receive layered photoshop files from different designers and agencies, and I need to do stuff with them. When i've tried switching to other tools in the past, as some will open layered photoshop files, but i've been caught out by one missing feature or another, usually from the latest, or almost latest version of photoshop. So it looks like I will be a slave to Adobe until such a point where I stop being a front-end developer, or start working with designers who don't use Adobe products (do they exist?). Otherwise i'd happily jump to something like pixelmator on OSX, or Gimp.

Code Editor: Sublime Text 2
I actually began writing this blog post months ago, but left it as a draft, and this section used to read Textmate! I used textmate for several years, but always had stability issues with it when I needed to edit something from a mounted folder or over sFTP. Sublime does the former quite well, and the latter is possible using macfusion. I haven't really explored sublime at all, so i'm probably only using a tiny percentage of its features, but it seems to do everything textmate did (or rather everything I did with textmate). The thing that really won me over is that there are versions for OSX, linux and windows, and the licence is transferable. This means that in the rare times I have to use other operating systems, I can use the same editor, which is great.

Code editing over FTP:Coda
I also bought a copy of coda, which I found invaluable when I was a freelancer, as some of my freelance clients were pretty old-skool with their hosting and I needed to use FTP, often including the necessity to edit stuff (local settings/ config files etc) directly on the live server without SSH access. Coda is great for this, and is also a nice text editor that I tried to start using full-time, but it was missing the "autocomplete strings already in the page" feature (i.e. if you added really_long_variable_name to a page, it appears as a suggestion when you start typing it again) that Textmate and sublime do really well. Actually, I haven't even installed it on this machine, not sure I will now..

Code editing in the terminal: Emacs
I usually install Emacs (No X version) on whatever server i'm accessing via ssh, for editing files on the server. I only know all the basic operations needed to be productive with it.

Server-Side web development: Python, Django and PHP
Wait, did I say Python *and* PHP in the same sentence? My chosen technology for building websites these days is the Django framework which runs on Python, but for years I also built stuff with PHP. Unlike most of the Python community, I don't have a problem with PHP, and will continue to use it for some things - the big advantage of PHP is that it runs on most shared web hosts, whereas Python/Django needs more specialist hosting environments.

Why not Rails? Basically i've been trying not to stretch myself too thinly, as I have a habit of doing. I wouldn't rule out learning Rails in the future, but there's only so many hours in the day! I am however learning Node.js, as I see it as a logical progression of my existing JavaScript knowledge, and think server-side JavaScript will be big in the future.

Source Control: GIT (with SourceTree as a GUI)
I've blogged before about how i've moved over to GIT from SVN. I do this mostly from the command line, but I also have a copy of SourceTree, which I find really useful for preparing large commits and searching logs etc.

General FTP and sFTP: Filezilla
I have to stress here that I only ever use FTP for website deployment when forced to - I don't run it on my own server, and deploy all my sites via GIT, in pretty much the same way I used to with SVN. Also Appengine has it's own deployment process, and doesn't support FTP or anything close to it!

So, with that clear, if I ever need to do some general FTPing for whatever reason (the last time was to bulk upload about 200 video files to a client's wordpress site on shared hosting), I use the excellent FileZilla. Just like Sublime Text 2, there are handily versions for OSX, Windows and Linux.

AppEngine python SDK/ GoogleAppEngineLauncher
To develop Django apps on AppEngine (or more specifically Python AppEngine apps that use parts of Django), you install Google App Engine Launcher. We actually deploy apps via the command line rather than using the launcher GUI, but it's all part of the same install.

Databases: MySQL and PostGres
For PHP and non-appengine Django stuff I mainly use MySQL. It does what I need it to, and i'm confident the performance and scalability are more than enough for most projects. I also use PostgreSQL for GeoDjango projects, using the PostGIS extension.

General Django dev: virtualenv and pip
For any local sites running Django I install a copy of Django and specific packages in a virtualenv. This means that I can have multiple different versions of Django installed with different dependencies in a sandbox. I also use virtualenv when deploying a Django site on my server, allowing me to have different standalone django versions on the server too. I install dependencies using PIP.

Email: Gmail web interface
I don't use a desktop mail client anymore, preferring to use the gmail web interface, for both my personal gmail account and google apps for domains email accounts. This is for two main reasons: my gmail account is so massive that the mail app on OSX struggles with it - it ends up contstantly syncing and you are never quite sure if it is up to date, and also in the past I have ended up switching machines so frequently that it was just a pain trying to get everything set up. I actually get on fine with the Gmail web interface and would be lost without its search!

Front end debugging: Firebug and chrome developer tools
I still think firebug is the most important tool in a front-end web developers toolkit. Chrome developer tools does exactly the same thing, but my familiarity with firebug stops me moving over to chrome full-time, along with possible caching issues I once experienced with JavaScript generated DOM elements.
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: software / skills /

eatStatic demo site online

This post was written 5 years ago.
Sat, 28 Apr 2012
eatstatic demo site screengrab
Shhh.. don't tell anyone but i've quietly launched the eatStatic demo site, which now runs from the master branch of the github repo. This is still the PHP version, slightly tidied up, and now using twitter bootstrap for the default skin. I had previously said that I wouldn't be maintaining the PHP version in favour of building a python/ django version, but as i've thought of a new personal project to build with django (which for once - STOP PRESS - is not a blog engine or CMS), I thought it would be good to get the PHP version tidied up into a usable state if anyone else wants to try it out. Also, as I happily run this blog from it, and am likely to do for years to come, it would be nice to get all the features built in that i'd like to use, and bugs ironed out.
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: eatStatic / projects /

Macbook air 13 inch as primary machine

This post was written 5 years ago.
Mon, 23 Jan 2012
macbook air 13 on a griffin elevator stand
When I first saw the macbook air I was awe-struck by it's design and portability, and like many people I was wondering if it would be up to the job of being an everyday work machine for web development. At the time I was primarily interested in the 11 inch version - I wrote off the idea of the 13 inch version, thinking that if I wasn't going to get the really small version, I might as well just get a more feature-rich and powerful 13 inch macbook pro. Several of my friends have got the 11 inch version, and have found it very capable, however..

Screen Resolution
max resolution on macbook air 13 inch (1440 x 900)
I spend most of my work time with my laptop plugged into an external monitor, with a separate keyboard and mouse, so I effectively have a dual-monitor set-up. When I do work away from the desk I use the laptop by itself, and I really want as much screen-estate as possible - especially when doing front end CSS and JavaScript work with firebug open. So when I noticed that the 13 inch air has 1440 x 900 resolution, which is better than the 1280 x 800 on the 13 inch pro and basically the same as the current standard 15 inch macbook pro (though smaller), it became obvious that the 13 inch could be ideal. So in december last year when it came time to upgrade (thanks Potato!) from my tired old black macbook (it had a good innings!), I went for a top-spec 13 inch macbook air.

macbook air 13 inch set up as dual monitor workstation
Power and Storage
A couple of people have asked me about the power and storage - I went for the highest spec I could, so this has an i7 chip and 256gb SSD. I've been using it for a month or so and still have 130gb spare on the SSD, so the drive is plenty big enough once all my software, music, photos, a few movies and TV series are on it, not to mention several work projects. I would have been struggling with the 128gb version, though arguably I could use an external drive for all the media, and be ruthless with deleting stuff, and just about get away with it.

I haven't done any speed benchmarks, but this machine feels blazingly fast compared to my old core duo macbook, in fact i've never used a faster machine! Photoshop opens very quickly and it handles large photoshop files really well, is plenty fast enough for general web development and associated tools. The most demanding scenario for me is having multiple browsers (and dev plugins) open, using my usual dev tools along with a massive multi-layered photoshop file open in CS5, at the same time as virtualbox running windows 7 for IE browser testing. While this pretty much uses all of the 4GB of ram, it still runs really happily compared to my old macbook - probably because the disk is much faster.

The only thing I haven't done is try editing a video with final cut pro - I know this machine has the same graphics capability as the 13 inch macbook pro ("Intel HD Graphics 3000 processor with 384MB of DDR3 SDRAM shared with main memory"), so should be capable, though not as good as the 15 inch and 17 inch pro, which have a second dedicated graphics chip and memory. I would imagine it is entirely possible to edit and process large videos on this, though if video editing were my primary job (and needed a portable editing machine), i'd have gone for a 15 inch pro at least! My video editing amounts to occasionally splicing together clips in iMovie, and adding titles and soundtracks - it is more than capable of doing that, including HD.

Battery
The advertised battery time on the 13 inch air is up to 7 hours - another selling point for me in comparison to the 5 hours on the 11 inch version. I haven't had the full 7 hours yet, but whenever i'm working I nearly always have a whole load of stuff running, so i'm getting more like 4 - 5 hours. Coconut battery is telling me I have a max capacity of 6450 mAh as opposed to the design capacity of 6700 mAh - I may pop in to the apple store to see if this anything to worry about, though i'm not keen on the idea of it being taken away from me for more than an hour or two to have a new battery put in!

Portability
Obviously this is a big plus with the air - the backache I used to get carrying round my old macbook in a backpack is no longer a problem - I can barely tell whether it's in my bag or not. If you spend half your life on a train or plane, the smaller version may of course be preferable, but i've not yet been in a position where this one feels too big.

Conclusion
I would definitely recommend the macbook air 13 inch as a portable web dev machine! I'm really happy with it and hopefully i'll get many years out of it, just like I did with my old macbook and the powerbook that preceded it. As ever, whenever you commit to buying a new mac, there's always the "but aren't the new ones being released tomorrow/ next week/ next year?" consideration. I think if a macbook air with 8GB of ram suddenly appears i'll have slight regrets for not hanging on, but other than that i'm very happy that i've made the right choice!

This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: mobileworking /

eatStatic is Dead, long live eatStatic

This post was written 5 years ago.
Sat, 21 Jan 2012
I was pleased to see people recently enthusing on twitter about text-file based blog and CMS tools - nesta CMS, Kirby and scriptogr.am, as it validated my theory that there is a demand for tools like these - I was met with fairly bemused looks when i've explained the concept to people in the past!.
I was also slightly annoyed with myself for not pushing my own text file based blogging system more and taking it further, as maybe people could have been getting excited about my project instead. It seems fairly pointless to develop it further now when these other tools exist, and i'd already decided to park it last year. My other reason for halting development on it was because it is written in PHP, and i'm determined to concentrate my efforts on django and python for personal projects.

Whilst at New Adventures in web design conference on thursday, I was feeling inspired to create something, so thought maybe I should build a django version of one of these systems. For a crazy second there I thought maybe I would be the first person to think of this, so I did about 30 seconds research and found that Luis Pedro has already created a django text file based blog/ CMS called Git CMS. It looks great, so my first reaction was that I should fork it and develop some of my other ideas around it, but then I noticed that he is still using a database, with a sync script to populate Django models from the text files. This is actually a very sensible way of doing it as it means that you can take advantage of all the stuff you get for free in django. However, my initial goal for eatStatic was to avoid the need for a database at all..

So i've decided to do a more or less straight port of eatStatic blog engine to python - a standalone text file blog engine implemented as a python library, that can be dropped into a django project, or any other python web framework, with little or no configuration. I've given myself an initial goal of moving this blog over to it as soon as it is stable, but then I want to take it further, and do some marketing around it - encourage people to try it, and to fork it, join me in my quest for a really fast, really simple, really portable, really powerful python powered database-less blog and cms. As soon as I have the initial code ready, and am convinced it isn't too embarrassing i'll get it up on gitHub alongside the PHP version :)
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: eatStatic /