Tag Archives: web development

I’m a Jack of all Trades and its OK

I thought I’d get back into writing and fulfilling a promise made at an enthusiastic Paul Boag workshop back in April (yes, Paul, I know…) by writing a short post about being a Jack of all Trades and how I feel this is sometimes wrongly devalued within the web industry.

I’ve had many different roles in my career from Junior Developer to Lead System Designer or Solutions Consultant to Community Manager. I’ve not got the typical experience of a “web guy” as I’ve spent the best part of 15 years in large enterprises and have not been one of the cool kids in one of the many fantastic agencies that exist – yes, that is envy. Each role that I’ve held has required a different set of skills at a given point of time meaning that I’ve had to be somewhat of a “Knowledge Chameleon” (I’m bagsying that!) and adapt to my environment. Whether it be knowledge of a proprietary system or understanding of the latest web standard, I’ve always had a “Just In Time (JIT)” education approach – JIT the term itself being learned from my days as a Java developer. Whilst this sounds a little fly by the seat of your pants, I’ve always made it work and made sure that I’ve understood what the experts are doing in a given space to guide my own practices and standards for the benefit of the customer.

So why am I writing this almost-on-the-verge-of-a-rant post? Well, I read all too often that Jack-of-all-Trade types aren’t as valuable as specialists. The most recent netmag contained an interview with the well respected Sarah Parmenter and the advice given once again for those starting out was along the lines of ‘be the best [insert specific skill here] in [insert a geographic area]’. Whilst I have tonnes of respect for Sarah and others who have said similar things in the past and am certainly not looking for a fight, I don’t completely agree.

I personally enjoy the fact that I have good appreciation about good design and typographic principles, good knowledge about HTML & CSS & UX best-practices, solid JavaScript knowledge, sound ability with several server side languages along with very good knowledge of enterprise back-end systems like Salesforce and I know what makes a good CMS.

“Big wow” [with rolling eyes] you may think to what may come across as a bit of an Ego-w*nk… and I would tend to agree. The value is not the skills themselves but rather how knowledge across domains allows for a ‘just right’ and appropriate solution to be proposed to a client regardless of the project size. In one project, I may have the luxury to oversee how the proposed solution is executed and brought together using what knowledge I have to liaise and discuss challenges with experts in each discipline. In another, I may be Mr. Hands On and Chief Get Things Done Officer who has to execute against his own plan. This flexibility is something I absolutely love and I feel it provides great value to my clients and gives me an edge over the competition for a given size of customer.

All that said, I am my biggest critic and would be first to recognise where I am weaker in some areas and stronger in others and am very open and honest about handing things over if they can be done better. Whilst I selfishly find closing the knowledge gap exciting because I sense an improvement in those weaker areas with every project I undertake, I do agree in part with the web gurus whose views I’ve taken exception to – focus is important. That focus or speciality level within a discipline however, has a context.

A case in point may be around my weaker design skills. A customer may have a limited budget initially and may need to have a site built out for a specific business need. I could come along and do a good job with the view that if things take off for the customer, there may be budget in the future to get a design rock-star to come in and take things to the next level to help increase conversions or another goal. Therefore, my job would be to future-proof and facilitate this potential future task by creating the site using well structured semantic HTML and well organised CSS (I like the SMACSS approach personally) and decisions within the front and back-end should be made with this context in mind.

This surely has value for customers who may want to spend incrementally, which also fits perfectly with an open and agile approach that many of enjoy as standard nowadays.

Given this, whilst I completely agree that you should use the best tool for the job and use the best person for a given job where the various constraints permit, I also think that the Jack-of-all-Trade types should be given a little more encouragement as it is most often those types of people who get things off the ground and get things done.

I have to admit to an exception here that may in some way contradict what I’m saying in that although I’m a passionate JOAT (brilliant, I’m basgying that too), I do suffer from the Cobbler’s Children Syndrome, which is why I’ve still not ‘got things done’ with my new site to show the projects I’ve worked on since leaving the slow and politics filled corporate world recently so you’ll have to forgive that indiscretion.

Oh well, I’m still a Jack of all Trades for my clients and get things done so I think its OK. 

 

 

 

What do you think? Do you agree or disagree? What is your experience?

Let me know in the comments.

A Mobile Approach in Concrete5

To compliment my short post on Multi-Site deployment of Concrete5, I thought I would add to it with a candidate approach for generating a mobile site.

Assumptions

With this approach, I’m assuming a setup of a mobile site on a subdomain as opposed to sub folder.  I would consider this best practice as URLs stay consistent between the desktop and mobile site, which is encouraged in the Mobile Web Best Practices Guidelines from the W3C (http://bag.gs/gReORJ).

I’m also assuming that the desktop site has been created already.  I appreciate that this may not always be the case and that in some circles, it is encouraged to consider mobile first.

1. Set up another site on your mobile domain

Follow the steps in Multi-Site deployment of Concrete5 for your mobile domain.  In my case, I’ll use the example m.example.com but do not go back to the basic install steps at the end and do not set up your site by providing the name, URL, and database details.

2. Share the Desktop Site Content

With thanks to the great MVC design of the Concrete5 product, all the content resides in the database away from the templates and the controls, which affect the view or presentation.  Therefore, sharing the database between sites is like sharing the content.

So, open up your site.php (e.g. /var/www/m.example.com/config/site.php) and simply copy into it the contents of the site.php from your desktop site.  This means you bypass the latter install steps.

3. Themes, Controllers, and Templates

Now that we share the content, we have a blank canvas for how we would like that to appear.  I actually take a copy of the desktop site files as a starting point as I can then build into them the various mobile optimisations and at least have a starting point where all the theme templates and blocks exist so nothing breaks.

So at this point, the site will be effectively a copy of the desktop site but on a different domain.

4. Device Detection

There are different services available for device detection but they all are orientated around detection through reading the User-Agent HTTP Header.

I ended up using Tera WURFL (http://bag.gs/ewCsoc) as I didn’t want to pay for something and thought that I could manually update ok.  This is working out fine for me but your needs may be different.

Based on the simple example available on the Tera WURFL site (http://bag.gs/fKsG2X), you can extract various properties about the device and make a decision about how you want to serve that device.

I chose to categorise devices based on certain screen resolutions and other capabilities meaning that I ended up with 3 different device profiles to serve: Basic, Intermediate, and Advanced.  From this, I can make decisions based on the profile within my templates.

 

Summary

I don’t make any claims for this being the best approach but I sure would like to get the conversation going about this.  I know there are other smart ways where people change the theme based on device (in comparison to the changing of domain based on device as exampled in this post).

As mentioned earlier in the post, I like this approach as it keeps a balance of URLs between the main and mobile site.  Additionally, block templates are not tied to a theme and so the view.php or custom template for a block on the desktop version could be totally different than in the mobile version.  This also means that you can use Concrete5’s great image helper in such templates to help optimise image sizes for mobile.

Please feel free to leave comments and questions and I’ll do my best to answer or improve the post.

 

A Multi-Site Approach in Concrete5

After seeing that many were having trouble understanding how they could use a single core Concrete5 installation to run multiple sites, I thought I would write this post to provide a strawman to help facilitate the discussion of how this can be done.

I run a server in the cloud using Amazon’s EC2 service and utilise an Ubuntu server with the usual LAMP setup.

1. Core Installation Preparation

To start, I have my core Concrete5 installation files in my default web site folder:

/var/www/default/concrete5.4.0.5

I keep the version number as this allows for the many different sites to use different cores if you wish.  How this is achieved will become clear later on in the post.

This basic setup of copying files is covered on the concrete5 site (http://bag.gs/hEWOT9) so I’m not going to repeat that here but it is important to say just copy the files for now.

N.B. Don’t go to the installed location in a browser yet – just copy the files.

2. Set up the domain that you want to host

This means that you can set up a separate virtual host in Apache or however which way you’d like to.  A search (http://bag.gs/heaC2L) will surely find you some assistance here.

The end result will be a virtual host that corresponds to your domain (e.g. www.exampledomain.com) and a separate directory from which that site is served on your server.  In my case, this directory is:

/var/www/example.com

N.B. I’m assuming that you’ve purchased your domain and have all the right DNS entries set to point to your server.

3. Set up site specific structure

This step is reasonably simple.  We are going to copy the entire contents of the core installation folder (concrete5.4.0.5 in my case) over to the new site directory so that we have the following:

/var/www/example.com/blocks
/var/www/example.com/concrete
/var/www/example.com/config
...
/var/www/example.com/updates

This copies what are in the most part empty directories and the inner concrete.  The root index.php is important as well as the couple of files in the config directory so make sure you take those across.

As concrete5 is well designed, the guys who have created the product have nicely permitted the extension of almost everything through utilising the directory hierarchy.  This means that as site developers, we should never touch the content of the internal concrete directory.  In the above case, the /var/www/example.com/concrete directory.  Consider it sacred!

If we obey this principle of not messing with anything in the core concrete folder, which helps us all upgrade, then you would notice that there is no value in that the …/example.com/concrete folder being a copy of the …/default/concrete5.4.0.5/concrete folder and you’d be correct.

Therefore, we are going to delete the /var/www/example.com/concrete directory and replace it with a symbolic link.  It is the symbolic link that allows us to point to different cores for different sites.

The syntax for the symbolic link when in the /var/www/example.com directory is:

...:/var/www/example.com$ ln -s ../default/concrete5.4.0.5/concrete concrete

Your Done!

Seriously, that’s all.  You can then pick up the basic setup (http://bag.gs/hEWOT9) at the point where you navigate to the new site, enter the site name, URL, and Database settings and away you go.

This small amount of preparation allows you to scale a single core instance of Concrete5 through using separate databases.

It would be great to get people’s views on this as I’m sure there are areas to improve or things that I’ve not considered.  Therefore, please leave a comment with your feedback.