The event represents a splendid opportunity to get to grips with functional programming, often mistakenly assumed to be a niche, academic language with little practical application. Paul Williams is an adept software developer and always delivers an interesting and informative session.
There is a practical session on Thymeleaf and Thymesheet with Agile Staffordshire this month, hosted by Ruth Mills. The session will introduce these Java view layer technologies and how they can be utilised alongside Maven and Spring. This hands-on session will provide an opportunity to use these technologies with examples. It promises to be a good evening and I am looking forward to it.
On Thursday 28th May, Paul Williams is hosting a follow-up to his Git at the Command Line session earlier this year. Paul is going to build on the previous session by digging deeper into branchless development, feature switches, and how to commit and push bite size changes with a practical workshop.
As ever, you can read more details about Agile Staffordshire on their blog and register your intention to attend via the meet up group. It is free of charge and new comers are welcome. This month’s Agile Staffordshire event is a practical session, so bring your laptop! Check the meet up notes for software prerequisites. I am looking forward to it.
Learning how to use a tool is one of the best value-for-time activities for a software developer. Vi isn’t a new tool; on the contrary it has a long and distinguished history as an editor. There’s a real treat planned this evening with Agile Staffordshire and I encourage you to stop by and join in. Details are available on the Agile Staffordshire Blog.
Jason Underhill and Paul Williams have organised a superb showcase of vi being used in a professional context as a tool for software development. These two know their craft and will definitely have some useful and interesting articles to show you.
January’s Agile Staffordshire session looks set to be another great one. It will be great opportunity to acquire some experience with version control software. Git techniques will be presented in this session by the abundantly capable Paul Williams. Stop by on Meet-up and let Agile Staffordshire know that you’re intending to join in!
I want to direct your attention to March’s Agile Staffordshire group. This month we are getting together to cut code and talk about it! If that sounds like your thing, take a look at the March blog post for more details.
We (those who develop software) still argue over coding standards. I do not refer to meaningful discussions over clarity, readability or group/project management. I mean crazy, ranting and aggressive behaviour towards one another over a ‘trivial’ matter.
Before anyone jumps on my face for using the word ‘trivial’, I offer the following advice:
If you work at a place with a compelling reason to adopt a style, adopt it and join in on constructive discussions about its use at the appropriate time.
If you have a personal preference, then apply it consistently and bask in the loveliness of your own code.
I do not think code standards are trivial and pointless. I think they are important and create clarity. I think arguing about code standards is unimportant. Actually, I think arguing about code standards is more than unimportant, I think it can be destructive for communities in general. It really does not matter what the requirements are, we have programs to format source code at the speed of a key stroke.
PHP, for example, has a number of standards to consider:
That list is not exhaustive, there are many other code standards to consider and they are usually related to various application frameworks. Big choices, big decisions – so big that I can configure my IDE of choice (PhpStorm) to convert my source code to any of them, almost instantly. I can also configure hooks to format code according to a project specifications, which can even be done automatically before commits. Unless you are pair-programming and decide on a mutually acceptable standard, code in whatever standard you like and simply convert it for your needs.
Why argue? Get along with each other and create software instead; you might even catch yourself smiling more!
Agile Staffordshire is running at Staffordshire University this month. It has been difficult finding a regular location recently, but Staffordshire University has some excellent facilities to host a good evening of software development topics. April’s meeting will be of particular interest to me as it is introducing Ruby, a language I have yet to use seriously. I am really looking forward to it.
In summary, the meeting will be at Beaconside Campus in Stafford and will start at 19:00 in K102, The Octagon. Full details of the evening are available on the Agile Staffordshire Blog. I hope to see people there.
LESS is a neat library that extends CSS with dynamic behaviour. It is not the only tool of its type but I like it as it is fairly quick to configure. I tend to build HTML projects as a quick front end to some code. LESS gives me a quick way of making changes to style. PhpStorm 6.0 provides file watchers that run LESS in the background and compiles CSS while you work. This very brief tutorial will help you get things going on Mac OS X Mountain Lion.
If you have LESS installed, skip this section. You need node.js installed, including the node package manager (npm). Download and run the installer package. Accept the default options. If you have installed Xcode in the past then your development environment will have already configured your shell to contain the correct paths. The installer package will prompt you if you need to update your shell path to include the location of npm. By default, at the time of writing, npm is installed at /usr/local/bin/npm. Confirm this by running the which command:
$ which npm
Once npm is installed, open a terminal window and run the following command to install LESS.
$ npm install less -g
If you experience problems during the installation, my security options required sudo to be used and that allowed the installation to proceed, it may be the case for you too. Once the installation has completed, confirm the presence of lessc using which.
$ which lessc
Try it out by passing a simple .less file through the compiler.
$ lessc example.less > example.css
You should be good to go with LESS.
Configuring PhpStorm / WebStorm
File watchers are a great feature in the JetBrains web IDEs. As you edit LESS files, Php/WebStorm will automatically compile them and produce CSS files in your project. You may get prompted to add a file watcher when editing a LESS file. Responding affirmatively is the simplest way of enabling the file watcher. If you missed it, select Preferences from the application menu. Select File Watcher from the ‘Project Settings’ section.
If you responded to the auto-detect LESS prompt, there will be a file watcher already listed, as shown in the screen shot. If you are configuring for the first time, select the + icon and choose LESS.
PhpStorm should detect the installation of lessc automatically. Additionally, there are some useful settings in the dialog. The ability to track root files only is great when working with Twitter Bootstrap projects; when you only desire bootstrap.less to be compiled in response to changes in variables.less. A full description of the options is available in the JetBrains documentation.
That is all there is to it. Any time you edit a LESS file, the IDE will compile it using the settings configured in the file watcher.
I am currently crafting a brief tutorial on testing using PhpStorm, CakePHP and my recent experiences in running a project with this setup. However, running CakePHP unit tests from within the PhpStorm IDE was driving me to despair until Maarten Balliauw came to my rescue. He has made a blog post explaining how to hook the PhpStorm and CakePHP unit tests together. I can verify that it works well and I have run hundreds of tests. If you are working with CakePHP and PhpStorm, you should read Maarten’s post.