Pages

Blog

Yeoman’sweb app generator is a great workflow and collection of tools for streamlining your front-end development, but what happens when you need to add a back-end? Do you stop using Yeoman, or just use it for the CSS? If you’re using version control do you have a different repo for the front and back end? These are just a couple of the questions I was asking myself after doing a couple of projects that included a CMS. Fortunately I found a pretty easy solution. MAMP.

I used to use MAMP a lot before I got into Yeoman, which of course has it’s own local server, but now that I’m doing a few more front and back-end builds I need to be able to work locally with Yeoman and PHP. I looked into Jedidiah Hurt’s PHP from Yeoman solution, and also Sindre Sorus’ grunt-php module. Jedidiah’s solution is unfortunately out of date, Sindre’s doesn’t allow for a ‘base’ array (for serving multiple directories as we’ll need to) and both require you to have PHP installed already. I also needed MySQL, so it was easier to just use MAMP really.

It’s actually fairly easy to configure Yeoman to work with PHP, I’ll be using MAMP Pro but you could use the regular version or just plain Apache.

Start by setting up a new host and pointing it at your app directory. Start your server and get your site up in a browser.

I use SASS, and the first thing I noticed was that the CSS wasn’t loading. That’s because the grunt task compiles it to a hidden .tmp directory above your app which Apache can’t see. There are two ways around this: changing the gruntfile to compile the SASS into your app directory (in which case you could just use grunt-php); or adding an alias to the .tmp folder via MAMP. I’m going with the latter, as it’s cleaner and easier to do. If you’re not using SASS/CoffeeScript then you can skip this part.

In MAMP Pro, select your host and click the ‘Advanced’ tab. In the bottom text box labelled ‘Customized virtual host general settings’ add the following line:

Alias /styles/ “/Absolute/Path/To/Your/App/.tmp/styles/”

Obviously adding in the path to your “app/.tmp/styles” folder. A quick Apache restart and you’ll see the styles in your browser. Of course you could make this change directly in the Apache virtual hosts config file if you’re using regular MAMP or plain Apache, or do something similar in Nginx. For some reason this doesn’t work in MAMP Pro for the ‘localhost’, but does for any other host your create.

Now that we can see the site, you can work on it as normal. Just run “grunt watch” and you can edit the SASS and it’ll be compiled on save as per usual. What we need to do next is get the livereload working. Firstly we need to watch PHP files (I’m assuming you have PHP files in the app already, if not just rename index.html to index.php and add an echo or something). In your gruntfile find the livereload options, the first item in the files array is what we’re after:

‘<%= yeoman.app %>/*.html’

Change it to:

‘<%= yeoman.app %>/*.{html,php}’

Which will then watch HTML and PHP files for changes. If you already have the livereload browser extension installed then you’re good to go, just start it and watch the magic happen! If you can’t use / don’t want to use the browser extension, then you can use the livereload javascript file by adding it to each page.

That’s it! As long as MAMP is running you just run “grunt watch” and you’re away. Any changes you make will trigger the livereload and it’ll work just like you’re used to.

Using an external server might not be the best option, but until we can get something like grunt-php serving the .tmp folder as well then we’ll have to compromise somewhere. Personally I’d rather do it this way than compiling my JS/CSS into the app directory, but you might prefer doing it that way instead. Whatever floats your boat!

Update

You’ll need to change one more thing for the “grunt build” task. Find the “useminPrepare” task and on the following line:

html: ‘<%= yeoman.app %>/index.html’

Change it to:

html: ‘<%= yeoman.app %>/index.php’

That’s the file that usemin uses to process all the JS/CSS concatenation and uglification. If it can’t find that file the task will fail.

What do you get when you cross Node.js with a Parrot AR.Drone 2.0? Hours and hours of geeky, geeky fun! I love Node, and I’m a guy so obviously I love gadgets, so this was a match made in heaven. NodeCopter is a day where small teams program flying robots to do their evil bidding. Mwuhahahaha!

If I’m doing larger content managed sites I tend to combine and compress scripts server-side, but for smaller sites I used to not bother. Manually combining and compressing files isn’t much fun, and you’ve normally got better things to do with your time. Yes you could install a server-side library like minify, but sometimes that’s not the best option.This is where CodeKit comes in handy.

It’s been a while since I started looking at using a Distributed Version Control system. In my previous post I talked about the pros and cons of Subversion, now it’s time I talked about why I went for Mercurial.

I’ve used CSS to create squares and rectangles (obviously), I’ve also created lozenges and circles, even triangles in CSS. I’ve seen hexagons and pentagons, but never the infinity symbol! It’s really cool, there’s also some nice stars and hearts!

It used to be the case that you would only sprite images as a last resort, it was a way for the big boys to reduce server load by minimising requests. Nowadays though everyone can and probably should benefit from sprite images.

I’ve recently been doing a lot of ExpressionEngine work, and with that comes the pain of editing it’s template files. I tried doing it via the built-in editor, I tried using ExpressionEngine’s ”Synchronise Templates” feature, I even tried editing a copy of the files locally and then pasting them into the built-in editor. Needless to say these “solutions” weren’t cutting the mustard and it was getting right on my tits – until I happened upon Mountee.