Websites. Software. Consulting

Web Design and SEO Blog - TotallyBlog - London - Totally Communications

• Tuesday 11/11/2008

  10 Ways for a Web Designer to Save the Environment

  
  You may think that as a web designer, you don't play too large a role in saving the environment and making the world a better place for future generations to come.
  But just as every little drop of water adds up to make the mighty oceans, every small green thing you do helps to make our planet more sustainable and livable. So if you're interested in contributing your mite, here are 10 ways in which you can help save the environment:
  
  1. Work from home:
  You save the earth from the emission of fossil fuels that you would burn during your commute to and from work.
  
  2. Use less paper:
  You don't have to print out your designs to see how they look; and even if you do have to use paper, invest in the recycled kind and make sure you use both sides.
  
  3. Turn off your computer when you're not using it:
  Even systems on standby or those that are hibernating consume a certain amount of power, so make sure you shut down your computer when you're not going to use it for some length of time.
  
  4. Use alternative power:
  Rather than hook up to regular electricity to power your devices, try investing in solar or wind power sources.
  
  5. Email your clients instead of sending them mail through the regular post:
  Use email to send your clients marketing and promotional offers and for other communication needs instead of wasting paper by sending messages through regular mail.
  
  6. Don't keep buying new gadgets:
  It's not that you need to save yourself some money, it's just that you need to be concerned with the way your old electronic gadgets will be disposed. Most parts are not recyclable, and the more new stuff you buy, the higher the pile of junk grows.
  
  7. Use LCD monitors:
  It's a well-known fact that LCD monitors consume less than half the power that traditional CRT monitors do.
  
  8. Invest in a notebook computer:
  A laptop computer uses much less power than a regular desktop.
  
  9. Make your meetings virtual:
  Rather than drive to and from locations or have your clients do the same for meetings, use teleconferencing facilities, or simpler still, just use the telephone.
  
  10. Work during the day:
  When you're a night bug, you have to consume more electricity because of the lights that you have to keep on. So switch to daylight, and make a world of difference.
  
  This article is contributed by Sarah Scrafford, who regularly writes on the topic of web design schools. She invites your questions, comments and freelancing job inquiries at her email address: sarah.scrafford25@gmail.com.
  
  Read More | Comments (1)

• Tuesday 11/11/2008

  Leaving a legacy by Tom Jowitt

  We've all been there haven't we? You're given a huge undocumented legacy code base and told that the client wants new features A and B added. I doubt there are many PHP developers out there that don't spend at least a certain amount of their work time maintaining or upgrading old code.

  Even if you wrote the original code yourself a few years ago, the chances are you will have become a much better programmer during that time and will look at your previous efforts in disgust and think 'God, did I really write that? What a horrible way of solving a problem!' or 'Why on earth did I not write any documentation?'. Do not fear brave coder, here's are a few tips to make you and your colleagues lives a bit easier when it comes to the dreaded legacy maintenance.
  
  1) Don't be daunted
  It's very easy when looking at a large legacy code base for the first time to feel like any work on it is going to be an uphill struggle (especially if it's written in non-object oriented code). A lot of legacy code often looks a lot worse than it actually is and once you get your head around it you'll soon understand what the original developers were trying to achieve. If you plug away at it you'll soon get it. It's like those magic eye pictures ... you just have to look at them for long enough to see the sailboat.
  
  2) Don't refactor everything
  The temptation is always there when working on legacy code to refactor. Don't! If you've got to add a feature or make a change to old code then the likelihood is that the code is still working fine and people are using it. Sure, it might not be pretty OO code or follow that cool new design pattern you learned last week but if it's not broken, don't fix it. Save all your new ideas for new projects and don't introduce unnecessary bugs to already stable code. I often find the best approach is to follow the style that the code is written in, even if it differs quite significantly from your current way of coding.
  
  3) Write some basic documentation as you go
  If the code you are working on hasn't been documented, another member of your team is going to come along a few months after you and have exactly the same problems figuring out what's going on. Take some time to create some simple work flow diagrams with notes about which main classes each process uses. Writing proper documentation for these kind of projects is far too time consuming if all you need to do is add a few small features but adding some guidelines and notes will come in really handy for others (and yourself if you ever have to come back to the code at a later date).
  
  4) Auto-generate Entity Relationship diagrams
  There's nothing worse than trying to figure out how a database works by tracking keys across tables and writing SQL to gain an understanding of how everything ties together. Reverse engineering the database into an entity relationship diagram will automatically make it easier to understand. Most of the popular databases have either their own or 3rd party tools to create ER diagrams. Oracle has the Data Dictionary and 3rd party tools, open-source databases such as MySQL and Postgres have plenty of third party options to choose from and SQL Server has ER modelling built in. It's well worth documenting large databases and sticking them up on the wall near your desk for quick reference.
  
  Hopefully in the future these issues will be less relevant due to the advances in the way PHP is written. Object orientated code, MVC Frameworks, PHPDoc, etc all help to keep the code cleaner and easier to maintain but for the time being a lot of us are still required to maintain legacy code and I'm sure will have to for a long time to come.
  
  Happy coding!
  
  Read More

• Friday 31/10/2008

  How does Firefox make money? by Craig Taub

  This being my first real blog I decided to scan through the past 6/7 months of other Blogs written by some of my colleagues here at TotallyCommunications just to get an idea on how Blogs are written.

  
  

  What I found was a repository filled with compelling and mentally stimulating articles. Each of which containing detailed descriptions/guides/reviews on almost anything one would find in the newspaper, except the subjects were usually computer related.

  
  

  After spending a short period of time thinking what I should write about, I decided to write on something which I had often wondered about.

  
  

  At this moment in time, as I write this article, my browser is open and running Firefox 3.0. Like all machines running a Windows operating system it comes with Internet Explorer loaded already, but like less than half of internet users I chose to take the initiative and downloaded Mozilla Firefox. Something I have absolutely no regrets about. The reasons for this are numerous but will have to wait until my next blog post.

  
  

  The much anticipated launch day for Firefox 3.0 had 1 million users click on and download it in the first 24 hours alone. For something that is so widely used it makes sense to me that they put so much effort into their project. Firefox has made its owners over $74 million in the past year. But where does this money come from because I certainly didn't pay to download the product, and have thus far used it on a daily basis and never paid a thing. A lot of it comes from development grants and advertising revenue, however where does the rest of it come from?

  
  

  The question can be solved by looking at the way that Firefox 3.0 is presented. What is it inside the browser that could make Firefox money? The answer is a found inside the browser itself.

  
  

  ALL Firefox 3.0 browsers come equipped with a Google search bar in the top right hand corner. This cannot be removed or edited easily. For AdSense Referral publishers , Google pays $1 per referral (every person who installs Google Toolbar TO their Firefox) or per conversion (a conversion occurs when someone successfully installs Firefox WITH the Google Toolbar). This does not sound like much but considering that almost two thirds of ALL UK residence are on the internet, and almost 50% of this number uses Firefox, even in the UK alone the number of Firefox users is staggering*.

  
  

  The ease of using this search bar also means that I will not even have to visit the Google homepage and do a search from there.

  
  

  But the Google search bar has more functionality then it appears. If I was to click on the Google G image. A list of other sites appears to me. These include Amazon, Wikipedia, eBay. Almost all the sites which I would do a search in. This removes the hassle of having to go to the site each time I wanted to perform a search. Search engines can be easily added and removed allowing the user to take control of their search bar. A very neat little function indeed.

  
  
  *Statistics from PC Plus Magazine Issue 273.
  Read More

• Tuesday 28/10/2008

  Mother Lay-by by Toby Mason

  Some of you may have seen an advert on Television a few days ago which ended with the instruction to Google search "Mother Lay-by".

  Well its taken me until now to try this search term and it takes you to an interactive YouTube advert for a new Dido album. Anyway I just thought I would try a little SEO experiment and see if I could get this page to rank somewhere close.
  
  Without doing any indepth analysis the term it doesn't look that competitive although YouTube is of course an authority site, the sites directly below it refer to a mum giving birth.
  
  So here goes with phase one of the experiment - The Blog Post.
  
  There is no good reason for me doing this other than perhaps testing the robustness of eager marketing executives. Either way I applaud them for thinking outside of the box so far and just wish I had done this 6 days ago!
  
  If anyone fancies giving me a helping hand with a subtle, optimised back link it would be much appreciated.
  
  P.S I have purposefully not linked out from this post because I don't want to pass any link juice to the YouTube page (so no need to email me Kelvin)
  
  
  
  
  Read More

• Friday 24/10/2008

  Date comparison with Zend Date by Bede Pavan

  Working with dates often involves some unavoidable complexity. Fortunately Zend_Date provides a simple API for some common localization issues. Unfortunately it doesn't provide the same level of support for common comparison calculations.

  I've recently started playing about with the Zend_Date API to see what it offered compared with PHP's native date and time functions. Working with dates often involves some unavoidable complexity especially when considering localization and internationalization. Fortunately Zend_Date provides a simple API for handling various timezones and daylight savings, locales (such as mm/dd/yyyy vs dd/mm/yyyy), internationalization and functions for sunrise and sunset times. To get started I recommend checking out the reference guide. Don't expect a tutorial with useful working examples (something many Zend Framework components sorely need) but instead a simple reference to complement the API documentation.
  
  Zend_Date handles the common task of comparing two dates with the compare() function. e.g.
  

  
  $today = new Zend_Date();
  $temp = new Zend_Date();
  $tomorrow = $temp->addDay('1');
  if($tomorrow->compare($today)){
  echo "Tomorrow is after today. Duh!";
  }
  

  
  Another common task is calculating the number of days between two dates or maybe the number of years for a date of birth. Adding and subtracting dates is also very simple but may not return the results you might expect.
  

  
  $today = new Zend_Date(null, 'dd/MM/YYYY');
  $xmas = new Zend_Date('25/12/2007', 'dd/MM/YYYY');
  $dateDiff = $today->subDate($xmas);
  echo $dateDiff;
  

  
  The code above will output 1 Oct 0000 00:00:00 which isn't very useful. In this case we could use the getDayOfYear() function but it won't work for differences greater than one year. What we need is the equivalent of the MySql DATE_DIFF function which returns the number of days between two dates. We could use the following as a workaround.
  

  
  $diffTs = $today->get(Zend_Date::TIMESTAMP) - $xmas->get(Zend_Date::TIMESTAMP);
  $tsInDays = floor((($diffTs / 60) / 60) / 24);
  

  
  Obviously the number of years could be obtained by dividing the result by 365 but this might be slightly inaccurate when taking leap years into consideration. Hopefully the Zend_Date API will include a date difference function in the near future. Until then I hope this is of help.
  
  Read More

• Wednesday 15/10/2008

  Out of the box CMS' - A Many and Varied World by Richard Aspden

  It seems that every time I get to grips with a new content management system someone always comes along and says 'yeah but have you tried....'. They seem to be sprouting up everywhere, each offering new must-have features and simpler levels of use. It probably says everything about the web that no-one can really agree exactly the best way to build a CMS. Each one works a different way and despite all the claims of how easy they are to setup and use, I find it always takes at least a day of playing about with it before the site shows the first signs of any structure. Then there is always the momentary wondering of whether I could have spent the day building my own cruder user backend.

  Out of the box CMS systems have become very popular with developers seeking a swift solution to handing over control of website content to their client. Yet despite reading up on the features and capabilities of many I had only really become used to Joomla. That is until recently when here at Totally we were asked to build a site in ModX. So therefore I thought I'd offer up my thoughts on the two systems which illustrate very well the many different approaches that developers take when building a CMS.
  
  First off for those who like to get to grips with coding Joomla is not really built for you in mind, unless you want to build dedicated add-ons which can then be shared with the rest of the ever expanding Joomla community. The principle is simple with Joomla. The emphasis is on ease of use. Just plug things in, set a few parameters and it's good to go. This makes adding forums, directories, online shops, newsletters... in fact just about any web application you want, an absolute breeze. There is even a dedicated installer in the backend which installs the extension from the downloaded zip file. There are three types of these extensions: Component s -- which are the main web apps. Modules -- which often fit alongside components, and are placed in and around the site. And Plugins (Mambots in Joomla 1.0) which allow extra features to be added to content in order to include non-static content on certain pages.
  
  ModX is not as fully-featured as Joomla but it's simplicity is to its advantage allowing developers the freedom to incorporate their own application code. It's simple to navigate via the backend as well and includes features such as SEO friendly urls built in, whereas with Joomla you have to install an external module. The use of CSS in menus is also more intuitive with ModX. Again a separate module is required in order to get DHTML operating effectively within Joomla. ModX uses different templates for each page while Joomla has one site template making sites with many different page layouts tricky to create. Heavy use of tables and lack of control over class and id names means Joomla isn't the most CSS friendly system either.
  
  Further to this, AJAX integration with ModX is pretty painless, while in Joomla some users have reported it to have crashed their website. The fact that, through the use of scripts, snippets and chunks, ModX allows a developer to actually include their own PHP code might have something to do with this. In Joomla PHP code can be added (you guessed it) by installing a module. I have yet to try this but it's hard to imagine it being as pleasant an experience as it is with ModX.
  
  Going into more detail ModX offers unlimited user types, Joomla is restricted to four. ModX allows searching of the whole website, Joomla requires a great degree of fiddling to acheive this and in order to search content from a component, use of an extra plugin is almost always required. The rigid site framework in Joomla does it no favours with just three levels -- Sections, Categories and Articles. In ModX you can easily define the site structure using the tree layout on the left-hand side. It also has its faults but still offers far greater flexibility than Joomla can.
  
  There are similarities though. Both systems use TinyMCE as the default HTML editor. But yet again ModX adds greater functionality by allowing links to specific pages via a dropdown menu. In Joomla you have to copy and paste the links in which, when they are query strings by default, can be a frustrating experience.
  
  Of course there is plenty to Joomla, and that's its main advantage. If you need a website to do something it's likely you can find what you looking for on the Joomla website. The shear wealth of resources available are something to behold. Don't like the photogallery you installed? No problem try another -- maybe one with Flash? ModX simply cannot compete. You'll probably have to start from scratch to achieve what you want.
  
  So in conclusion it's not for the likes of me to laud one over the other. They are two very different beasts. The one conclusion I have come to having used both is that they will appear to different types of web builders. As with those who prefer design mode in Dreamweaver and those who prefer the code mode. Or perhaps more accurately for those who use still use Dreamweaver against those who junked it for Eclipse long ago. The web is a many and varied place and so it's perhaps right that there are CMS systems to cater for everyone.
  
  Read More | Comments (2)