Arguably, the most important element in CSS development is the team that supports the developer. Every team is different, not just the personalities of the members or the sizes of the teams but also the disciplines and skills within it. Some teams include a few server-side developers and a single front-end developer, some include the entire skillset required to build a web solution: designers, front-end developers, server-side developers, database specialists, testers, and so on.

A team this size has the benefit of rapid communication between its component parts but has the disadvantage of size; larger teams are slower to respond to requirements for various reasons. The primary reason for this is something researchers call "diffusion of responsibility." This means that in larger teams, members assume that someone else is doing any given task at any given point rather than taking it upon themselves to do it. Without clear guidelines in place, it can be difficult to be sure of who is or should be responsible for unexpected problems or tasks, so even though these issues are noticed, they are forgotten. In smaller teams, besides communications being more immediate and effective, more attention is on each individual, and members will assume responsibility and be more proactive. This issue, however, can be overcome with good project management. If you have all your tasks mapped out with clear areas of responsibility, there is no room for confusion.

The processes within your company change dramatically depending on the type of team you have. For teams that do not include designers, if the requirements fed to your team already include complete designs and specifications, there is little room or time to feed back any issues to the designers or information architects and the development is more siloed away from the requirement creation process. If the teams do not include testers, and the user testing process is outside of your team, errors or problems they find are fed back to you after you have finished developing, which is the least efficient time to fix them.

It also makes a big difference who writes your CSS. If it is written by web designers (hopefully the same people who made the designs for what you are developing), then as long as they are good at what they do they will have taken into account things like accessibility, usability, and templating. If the designers are separate from your team, you may find the designs they provide do not intrinsically consider these things. The worst case is where the CSS is written by those who don't specialize in front-end code at all because they are not expert in what they are doing, and may do more harm than good. CSS is deceptively simple, and it is easy to write inefficient bloated code that quickly becomes legacy code. However, companies' processes are often based in legacy and not that easy to change.

The project manager is responsible for getting the most out of the team and dealing with these issues. One of the most important pieces of a process is defining areas of responsibility. These areas need to be mapped out clearly before a team is even put together, so you know who to include in the team. A simple example is as follows:

With these roles clearly defined, it becomes obvious who should be doing what. With regular meetings any problems should be located and dealt with quickly.

We have not mentioned designers or testers because they are not always within the team that develops the project, but if they are members of your team it is important to also list their responsibilities. If your team includes web designers who can write HTML and CSS, you can consider them developers for the sake of this nomenclature.

Once you have your team planned out, it is easy for your company to begin using that template for every team you have and for every project you have. We encourage you to continue to consider how your team is formed on a project-by-project basis. Although strict processes are a good thing, if you don't change them on occasion you may never discover better ways to run your development.

Figure 1-1 shows an example hierarchical diagram of a team setup.

Figure 1-1. An example of hierarchical design

Once you have your process in place and all the members of the team know it inside out, there should be very few surprises. In smaller companies or teams, though, strict processes are thought to be less important. Assuming that everyone is a useful and hard-working contributor (in smaller companies they will be caught out quickly if this is not the case), communications can be facilitated with quick spontaneous meetings and face-to-face conversation. Because interaction between staff is more intimate, training new employees is a much more hands-on task. Policies can be changed day to day, and although processes are still useful for efficient performance, a little chaos can, in fact, help with creativity.

As companies and teams grow larger, this becomes less of a luxury and more of a cumbersome chore. Trying to train all your new staff as they are recruited becomes a mammoth task requiring dedicated space and further staff. Keeping communication open and flowing between teams becomes more difficult and more time-consuming. The carefully crafted CSS styles and verbally agreed-to methods of working and keeping your website consistent and clean start to get lost between the increasing number of teams. If your team grows larger, more and more time is taken up in the administration of the individuals, and even just waiting your turn to speak in meetings. If you have off-site resources, the meetings become even less productive as they morph from in-person conversations into conference calls and e-mail.

There are clear and obvious advantages to off-site resources, in that you only use (and pay!) them when you need them, and they are often dramatically cheaper—but this comes at a loss of personal communication.

The benefits of face-to-face communication are as follows:

The disadvantages of remote communication are the following:

If you have members of teams that are in different countries, time zone differences and potential language barriers further compound these issues. However, the reduction of cost in using remote developers in countries like India or Estonia is often too attractive to the business to overlook and potentially for good reason.

It is clear that the previously acceptable methods when the company was small and growing of sticking hastily scribbled post-it notes to a big whiteboard and shouting important messages across the room are no longer effective means of management. A solid process that everyone in the team (and hopefully, the company) has bought into and agreed upon will help to alleviate many of these concerns. As mentioned before, if it is clear what tasks everyone should be performing and when, it becomes more difficult for misunderstandings to occur.

If what everyone is doing is recorded in a trackable and consistent manner, any remaining misunderstandings can be uncovered and addressed. More so, whereas in a smaller company it is difficult for neglectful, incompetent, or unproductive members of the team to go unnoticed—writing CSS inconsistent with legacy code, modifying code without due diligence or causing bugs and defects in dependent pieces of code—in larger companies these costly individuals can creep under the radar for months. The processes that we willcover in this chapter can surface and expose their activities (or lack of them) much more quickly.

In smaller companies, every individual has a voice. However, in larger companies this voice can get drowned out by the crowd or simply have no route to the ears of those who need to hear it. Great ideas and improvements can go unheard, and staff members are less invested in a company on which they can leave no impression or mark. Simple processes like feedback sessions, company meetings, available line managers, and fewer levels of hierarchy can help ensure that every staff member has an opportunity to participate and contribute.

If these processes can become ingrained in the company's way of thinking from the start, they will be much easier to implement and a good base for growth.

Many larger companies tend to have a high rate of employee turnover—people come and go more frequently, taking their knowledge and the skills invested in them. This is especially true for front-end developers; they are very much in demand in today's markets and often work as contractors with short notice periods, and as such can jump from role to role with little warning. Although company founders want to think that their employees will stay loyal to them forever, the truth is that most people will at some point leave and move on. For smaller companies, a lot is invested into each employee financially and sometimes even emotionally. Every new employee taken on (whether replacing an employee that has left or filling roles that have become necessary due to growth) requires induction and training. These employees help shape the company, and choosing the right people is something that must be considered carefully. In a larger company this becomes even more important. Larger companies gain their own personalities and characteristics and there is more to learn to fit in. New employees must almost be assimilated into the company's behaviors. It can take quite a while to start being productive and longer still to reach the level of productivity that comes with being comfortable in your environment. More-complicated processes mean more user accounts and passwords to set up, documentation to read, policies to learn, and larger premises to find their way around. This means that inducting your staff and training them is paramount to efficiency—you are still paying staff during their unproductive periods, after all.

Something else you should be exploring is how to retain these employees more effectively. Every staff member imposes costs on the business, but the knowledge they acquire over time builds exponentially, as does the value of a good team member. First, consider whether you are offering salary and benefit packages that stand up well against those of your competitors. Evidence has been found in many studies that indicate that the simple concept of increasing monetary reward to increase performance only holds true when considering manual labor. In the instance of more cerebral pursuits, it is more important that staff members feel challenged and valued. To this end, it is important to pay them enough that money is not the concern, but you don't have to pay above market rates to get good loyal people. Nonmonetary rewards to increase the individual's happiness in the workplace are valuable also. Things like flexible working hours, training, vacation time, and even just providing a bowl of fruit each morning all serve to add to an employee's level of satisfaction in the workplace. A good canteen doesn't just make your staff happy and well fed—it also keeps them closer to their desk and thus quicker to get back to work!

Another thing that will help retain staff is to demonstrate appreciation for their contributions. Awards ceremonies or other forms of recognition, parties, and nights out demonstrate an appreciation of their commitment to the company and further strengthen the team as a whole.

Although you want your staff to meet your deadlines and requirements and be as productive as possible, you also do not want them to suffer burnout. Ensuring that your deadlines are as realistic as possible (by involving staff in the estimation process and basing estimation accuracy on previous estimates) and that your employees are content in the workplace will help sustain a good work ethic and rate of achievement.

Finally, you want to ensure that your staff members are proud of what they do and feel invested in it. Doing your best to give everyone a voice will help with that. Some companies like Google give their employees opportunities to work on their own products, and support and recognize them if they develop something of value to the company as a whole. Every Friday at Google is "Google Friday," when developers are encouraged to play with new technologies. This playing has resulted in Gmail, Google News, Orkut, the Google logo becoming a fully functional Pacman game, and other internal innovations. At Atlassian, once every three months their employees are allowed to do whatever development they like for a day, as long as they present their results to the company afterward. Developers take pride in their work, and this is demonstrated in the items the developers choose to work on when given free reign. Bugs that are important to developers (but not the business) are fixed, spelling mistakes are rectified, vital refactoring takes place, issues with process are isolated, and solutions appear for existing business problems during this time. The result is that you have better software, but more than that, you have happier and prouder people.

All these suggestions apply just as well to CSS developers as other members of staff. However, the web development world progresses and changes rapidly, and it can be difficult to keep up. If staff members are passionate about what they do, they will want to keep their skills up to date, and if the company wants them to be happy, it will help them achieve this. Although newer CSS techniques might not be ready for prime time due to patchy browser support, time should be allocated for the CSS developers to read about and become familiar with these techniques. Allowing your web developers opportunities to attend conferences (and perhaps even speak at them to represent your company) demonstrates a commitment to the employee and to the technologies they care about. Keeping a good library of reference books (like this one!) and considering subscriptions to magazines helps, too, as does giving the developers time to read them as well as blogs and other articles online. Allowing them to present their own findings online via a company blog is often something they will appreciate, but this may depend upon your company's public stance and policies.

Keeping staff happy should be a primary concern and will help retain them longer, but employees resigning should be planned for, not a cause for panic.

When hiring new staff, you should always strive to hire high-caliber individuals. You want people who know their stuff, and have things to share with the rest of the team. However, particularly in the realms of programming and coding, different people have different styles of writing.

Inconsistency of code is a cost, both in terms of time and resources. Although writing CSS selectors in a particular way may be more efficient and clever, due to the potentially high churn of staff, if this code is unusual or more difficult to understand it becomes difficult to share among the team members. Writing your own CSS framework is a good thing, as long as it is not too complicated to pick up. You should also consider some of the already available CSS frameworks that we talk about in Chapter 4. If the process of implementing your own CSS framework requires complicated build scripts and makes debugging difficult, perhaps the solution is being over-engineered. We are not suggesting at all that build scripts (which you can read about in Chapter 9) should not be employed for reasons of performance and efficiency, but the process should be simple. CSS developers typically work very fast, often flicking between their text editor and a browser many times a minute. Any processes required to get your code to run should be implemented in an unobtrusive manner. A build process that hinders that has a much larger hit on the developer's efficiency than many might think. Entering a CSS debugging mode should be just as simple, so in the case of CSS being minified upon reaching production, the CSS developers can see their code as they wrote it instead of a CSS/DOM inspector reporting the selector as being on line 1, where there is only one line.

A single developer hoarding all the knowledge of how certain parts of your code work should be an obvious red flag. If this developer chooses to leave the company, or for some reason cannot work for them anymore, there is an immediate knowledge deficit. New developers may have trouble understanding the code, and a period of stagnation begins, while these developers struggle to come to grips with the complexity of the code. Without the previous CSS developer there to mentor them, huge areas of CSS may just be left in place for years because no other developer is brave enough to remove them for fear of causing issues elsewhere in the site. This kind of stagnation of legacy code is very common and is difficult and costly to resolve.

To that end, it must be preferable to have simpler and clearer code wherever possible so that knowledge hoarding remains at a minimum. Some companies choose to frequently rotate their developers onto different pieces of their projects at particular intervals to combat this. In fact, despite the obvious cost in time, this methodology has some considerable benefits, in that every team member has a good idea of how the project works as a whole and may consider factors that could otherwise have been overlooked without this holistic view. Problems found during development rather than during planning are always more costly to overcome. The main downside to this methodology is that developers are constantly moving from one piece of the puzzle to another and may find it difficult to "get into the zone," which can be frustrating and a further cost.

The value of consistency in these scenarios cannot be overstated. As a very basic example, one individual may compose their CSS code in this fashion:

/* Main Heading */
#mainHeading {
   font-size: 2em;
   font-weight: bold;
   color: red;
}

Another may write it like this:

/*========================================================================
   Main Heading
========================================================================*/
#main-heading {font-size:20px;font-weight:bold;color:#ff0000}

Both of these are completely valid and technically correct ways of writing CSS. However, if these two individuals both worked on the same CSS file at different times, you could end up with a mixture of these two very different coding styles in the same document. This leads to a document that is hard to scan and read. Many developers, upon finding the style of code that was different to their own, may reformat it in a way they find is preferable to them. The original developer may then format it back the same way. This is both inefficient and unnecessary.

CSS suffers from this problem more than most coding languages. It is so easy to just throw lines of code into a file until something renders correctly, and it is very difficult to isolate the pieces that you can safely remove or that are no longer in use. To that end, strictly formatting your CSS documents and keeping the selectors and rules in the right place is paramount to avoiding a big mess of code with legacy and leftover pieces that are difficult to locate. Code that is badly or hastily written is known as "technical debt", a term coined by Ward Cunningham in 1992. A little debt is okay as long as you pay it back (refactor and fix the code), but the longer you wait, the more the interest builds up (code built on top of and dependent upon the initial code) until you go bankrupt (have to start all over again).

To solve this problem, it is important to have standards predefined in a guide so everyone knows that CSS is written in a particular way in your organization. Most companies of any size have some kind of wiki (see following) or company handbook, which is an appropriate place to store a guide like this. Although outdated, the BBC makes its CSS Guide available online at www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml.

We don't recommend having rigid guidelines that are enforced strictly (for example, you should not use !important,^[3] but there may be situations where it is the most appropriate thing to do). However, we do recommend some form of guidelines exist. Here is an example of a section of a CSS formatting guide:

These points serve as an example, not necessarily steps that we recommend you take. We will present you with an example CSS formatting guide at the end of this book. For this guide, it is useful to employ MoSCoW (a common method for prioritization). MoSCoW (in this context) means the following:

Using this method is useful because it means all CSS topics are captured to demonstrate they have already been considered, and previous conclusions can be kept for future discussions.

It is also important wherever possible, and where it is not clear, to explain the reasons for the rules in our guide.

From the business perspective, creating clean and well-written CSS is very hard to justify. It's not that the business wants bad or messy code to be written, it is that our work is typically based upon business requirements. The business wants those requirements delivered and for the team to be ready to move onto other pieces of work as soon as possible. To that end, you need a good compromise. You want good clean code—you know it makes life easier in the future and it allows you to take pride in your work. But perhaps complicated and terse code (which is not always the same as good code) is more of a hindrance than a benefit. If you have a solid and rigid structure and methodology that you stick to, our new staff can adjust to our in-house coding style with the minimum of fuss and get straight to being productive. If you know which styles go in which files and how to locate the blocks of CSS in those files, you can find the pieces you need to amend straight away, with no need for endless debates (with very little business value) about which location to use.

Of course—taking this to the extreme—excessively verbose and overly commented code is just as hard to work with. Selectors may become too specific, and comments may take up all our screen estate, making it difficult to scan the document. We willbe looking at comment usage in Chapter 2.

This does not mean using newer technologies is a bad thing or that you should not debate techniques. It does mean, however, that these debates should have an appropriate forum at set intervals as part of our process. You can amend documents as and when you need to, as long as you communicate the changes to everyone who needs to know. If you keep your CSS guide in a wiki (see the section on Wikis under the Tools heading below), they will typically support some kind of notification mechanism via "watched pages" or similar means. This means that upon any revision that is not specifically marked as minor, a list of subscribers will be alerted to the change. Anyone working on the CSS within the organization should be a member of this list. They should also have the ability to modify the guide themselves (and, in turn, notify the others). It is very important however, that someone owns this document—that is, that someone is responsible for the changes that occur within it—and makes sure the others are aware of any changes made to it.

Let's say that the RGBA (Red Green Blue Alpha) method of declaring colors has recently found favor among our CSS developers. In our imaginary organization, Igloo Refrigerator Parts Inc, we have a monthly meeting between all our front-end developers. It is proposed and agreed at this month's meeting that this method has value, and we want to start using it. Using RGB (Red Green Blue) as a flat-out replacement for hexadecimal code is found to have good support in the browsers in which we look to maintain adequate functionality (see "Graded Browser Support" in Chapter 6), and RGBA gives us a capability we did not have before (notably alpha transparency), so we want to add it to our CSS Formatting Guide and amend our previous recommendation. Again, this is an example, not our suggestion.

Before, we had this line:

We can now amend it like so:

At the meeting, someone is given the responsibility to make these amendments, and to make sure that everyone is notified about them. Note that this does not mean we should immediately revisit all our CSS code and convert all hexadecimal colors to RGB, but it does mean that any future colors should be in RGB. The next time we have an opportunity to refactor is an opportunity to convert the rest of the legacy code across to satisfy the new guidelines.

Often, in larger organizations, different departments will not communicate with each other, and the business may be so large that indeed they never even know the others exist. We would encourage you to reach out to everyone in your business that writes CSS, and try to get everyone speaking the same language and working together.

Many tools exist to help us develop our website and manage our processes. There are myriad pieces of software to manage our tasks, store our files, store documentation, create mock-ups, share files, develop our code, communicate with each other, and so on. This section discusses some of the types of software that are likely to be useful to your process and mentions a few examples of each type. It is impossible to mention (and have used) everything, so please consider these tools a list of potential candidates with notes on important features, and not a complete overview. Review the options available before deciding on particular choices.

Source Control

Source control comes in many flavors, but at the heart of every one is the concept of maintaining a history of every file in your project (stored in a repository) with the ability to roll back to previous versions of any file. There is also (typically) the concept that one file may have been worked on by many people, and thus needs to be "merged" to include everyone's changes.

The main copy of the files in our project is called the trunk. When a version of software is released (considered safe to put in a production environment), it is very common to tag the current state of the repository, or branch the repository (which means to create a duplicate version of the current state of the repository). We do this so that if problems are found with the version on production, we can make amendments to that code without worrying about more recent changes that might conflict or not be ready for release. Typically we should work in the trunk where possible because merging the changes between branches can be problematic.

Some examples of source control systems are shown in the following sections.

Visual SourceSafe (VSS)

VSS (www.microsoft.com/visualstudio) is now widely considered a legacy and outdated method of source control. When one user chooses to work on a file (by checking it out), that file is locked from being worked on by any other user until it is committed back into the repository (checked in).

There is a benefit of this methodology: files almost never need to be merged because they are always left in a state the developer is happy with. However, this means that developers can never simultaneously work on the same file and often forget to commit their files, thereby locking the file away from other users.

Concurrent Versions System (CVS)

CVS (www.nongnu.org/cvs/) was developed by Dick Grune in July 1986. Although other versioning systems similar to CVS existed before (this was the first that allowed files to be modified by multiple people simultaneously) to gain widespread acceptance. The CVS model keeps all files in a centralized repository on a server, and clients check out and commit files from and to that repository.

Subversion (SVN)

CVS had many shortcomings, and although it is still in common use today, Subversion (http://subversion.apache.org/) was created by CollabNet in 2000 as an attempt to fix many of the bugs in CVS and to add many of the much requested "missing features." As such, it operates in a very similar manner to CVS. Due to its relative stability and maturity, it is one of the most common version control systems in companies today.

Git

Git^[8] (http://git-scm.com/) is a form of distributed version control. This means that the developer has a repository on his own machine as well as one (or many) stored centrally. Rather than "hoarding changes" for fear of committing faulty code (and therefore increasing the potential for data loss due to crashes or hardware failure), users commit their code to their local repository and can manage revisions from there. Instead of being a single library, Git is actually formed from a series of individual tools with which it is possible to come up with pretty much any version control process you might like. Although the merging algorithm used in Git is well respected and has been proven by merging 12 Linux kernel patches simultaneously, Git is a complicated system to get your head around and may well be overkill for your projects.^[9]

Mercurial

Another distributed version control system, Mercurial (http://mercurial.selenic.com/), is sometimes known by its command-line name: hg. It was developed by Matt Mackall and released in 2005. Git and Mercurial were developed concurrently because the free version of BitKeeper—the source control software used at that time by the Linux kernel project—was withdrawn by its developer, BitMover. Although Git was ultimately used by the Linux kernel project, Mercurial is still championed by many in the industry. Less full-featured than Git, Mercurial is still very functional and fast, and simpler to use—particularly for those migrating from Subversion.

Note

BitBucket (http://bitbucket.org/) is a service similar to GitHub for Mercurial projects.

Graphical User Interfaces

Almost all version control systems ship with command-line interfaces, but many graphical user interfaces (GUIs) exist as well as plugins to enable integrated development environments (IDEs) and other pieces of software to communicate with them. To mention them all would be beyond the scope of this book, but it is worth mentioning the Tortoise family of shell extensions for the Windows platform (TortoiseCVS, TortoiseSVN, TortoiseHG, and so on). They integrate tightly within Windows, adding functionality to the right-click menu within the file system explorer as well as icons signifying state, which is the most intuitive place for them to be. Copycat versions have been attempted for OS X and Linux, but none have (at time of writing) been integrated as tightly and intuitively as Tortoise.

Using Version Control Systems

When working with source control, when you are happy with what you have done, you commit the file to the repository. This updates the central code with the version you are working on. If you are using distributed version control, you should commit to the local repository often, and only commit to the central repository when you are confident your code is working correctly. You can see a visual comparison between version control and distributed version control in Figures 1-2 and 1-3.

Figure 1-2. Diagram of normal version control

Figure 1-3. Diagram of distributed version control

Using version control systems is vital when you work on CSS in teams. It gives you the added confidence to work on files that other developers may be working on, as well as the reassurance of a restorable history for each change we commit. When we work with CSS, we often work in small chunks. We make small changes, switch to our browser, refresh the page, change, switch, F5, and so on. We should remember to commit our changes often, so that we have a good history of everything we have been doing.

When committing your changes, most version control systems will ask you for a comment describing what you have changed. When your version control system is further embedded in your processes, these comments become invaluable. It is therefore of utmost importance that your comments are relevant, descriptive and helpful.

A comment like this is of very little value:

Changed some bits and pieces.

But a comment like this describes exactly what happened within the file:

Changed hex colors to RGB colors.

When things go wrong (which they will), you will find yourself viewing the commit history of the files with the problem and useful comments will be very helpful in clarifying what changed in each revision.

Typically, you are encouraged to update a file by hand before beginning work on it. This means to fetch the latest version from the repository. If you fail to update and begin work on an outdated version of the file, or if another developer has committed changes after you began work, you are required to merge the files. Because two developers have been working on it simultaneously, the changes between your local copy and the version in the repository are non-linear. It is impossible to work out which pieces to keep and which to replace in an automatic fashion; this results in the files being in conflict. To resolve the conflict, it is necessary to locate the differences, edit the file appropriately, and then mark the conflict as resolved so that you can commit the amended version of the file.

Diff Tools

To deal with these conflicts, you will want to see exactly what the differences are between the two files. A special type of application exists that does just this: a Diff program. Again, lots of them exist, and we don't intend to promote one over the other. The purpose of these programs is to compare two similar files and show the differences between them.

The intention is to make it easy to recognize and resolve the conflicts between two versions of the same file. Because CSS is often less modular than we would like it to be (or can have effects in unexpected places), and although conflicts can be resolved, we should still avoid them wherever possible. The best way to do this is to communicate effectively with your team and let everyone know exactly which files you are working on at any one time.

Where these conflicts exist, we must merge and resolve them. Resolving conflicts and merging changes are some of the biggest headaches of having multiple individuals working on the same file. Older style command-line Diff programs show only the differences between the files, similar to the output shown in Figure 1-4.

Figure 1-4. An example output of a command-line Diff tool

More modern Diff programs ease this pain by letting you view two documents side by side. Differences between the two documents are highlighted, and any section that is different can be copied from either document to the other document (see Figure 1-5).

Figure 1-5. An example output of a GUI-based Diff tool

Often simple versions of Diff tools will be available within your IDE or version control system, but the following sections describe examples of other dedicated Diff programs.

Araxis Merge

The standard version of Araxis Merge (www.araxis.com) can compare two documents, but the professional version can compare and merge three separate documents simultaneously. It is reasonably priced, and available for both Windows and Mac platforms with great performance on both platforms.

WinDiff

WinDiff (http://support.microsoft.com/kb/159214) is included with Microsoft Visual Studio, so it is free if you already develop with that platform. You can also download it from www.microsoft.com/downloads/details.aspx?familyid=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en if you are running Windows XP, but it is included on the CD for versions of Windows including Windows 2000 and later.

WinMerge

WinMerge (http://winmerge.org/), as the name suggests, is a Windows application. It is open source, available for free, and performs well.

Beyond Compare

Beyond Compare (www.scootersoftware.com/) is developed by Scooter Software and on its third revision. It is available for Windows and Linux. It is reasonably priced, and has a great reputation and feature set.

Changes

Changes (http://connectedflow.com/changes/) is a Mac-based application that integrates well with other apps on OS X. Figure 1-5 shows Changes in action. It is inexpensive and can compare folders as well as files.

Kaleidoscope

Kaleidoscope (http://kaleidoscopeapp.com/) deserves a mention as a very attractive and intuitive Diff tool. It is made by Sofa (which also makes the Versions SVN client for OS X at http://versionsapp.com) and is a great example of beautiful and intuitive software at a low price. Unfortunately, as of version 1 (the current version at time of writing), it includes no merging capability, which may limit its usefulness to you.

A more complete list of Diff tools is available at http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools.

Resolving Conflicts

Let's demonstrate how to resolve an SVN conflict. We willuse the Versions SVN client and Changes Diff tool, both on OS X. For the sake of example, we are working on a file specifically for Internet Explorer 8 called ie8.css. We have updated our local repository and then worked on the file locally. The contents of the file initially were the following:

#imagePath {
   filter: alpha(opacity=0);
}
#tryit-form .input-file {
   height:18px;
   width:217px;
}

We have added an extra selector and changed the height and width for #triyit-form .input-file, so the file now looks like this:

#imagePath {
   filter: alpha(opacity=0);
}
img.example {

float:left;
}
#tryit-form .input-file {
   height:22px;
   width:220px;
}

We tested these changes and they work fine, so we go to commit the file with an appropriate comment (see Figure 1-6).

Figure 1-6. An example SVN commit dialog

The result is shown in Figure 1-7.

Figure 1-7. An example SVN conflict dialog

This figure tells us that this file has been modified and committed since we last updated it. As suggested, we will now perform another update of our local copy to pull down the latest changes (see Figure 1-8).

Figure 1-8. The SVN conflict in the file browser window

Versions now shows several new files and icons. ie8.css has an exclamation mark next to it, which indicates it is currently in conflict. But three brand-new files have appeared, too:

• ie8.css.r313

• ie8.css.r312

• ie8.css.mine

Each of these files has a purpose:

• ie8.css.r313 is the latest version of this file in the repository.

• ie8.css.r312 is the version of the file we downloaded from the repository when we last updated.

• ie8.css.mine is the version of the file we just tried to commit.

• ie8.css now contains markers, the version we created, and the changes in the repository.

The contents look like this:

#imagePath {
   filter: alpha(opacity=0);
}
img.example {
   float:left;
}
#tryit-form .input-file {
<<<<<<<.mine
   height: 22px;
   width: 220px;
=======
   height: 24px;
   width: 320px;
   float: left;
}
.clearfix {
   zoom: 1;
>>>>>>> .r313
}

The markers show what has changed. Everything between <<<<<<< .mine and ======= were changed since updating, and everything between ======= and >>>>>>> .r313 were changed by someone else. Notice that SVN is not suggesting that our img.example selector and rules are in conflict because it is clever enough to resolve and merge those changes itself.

To resolve this, let's compare our version and the latest version from the repository. First, we open both of those files in Changes (see Figure 1-9). We need to consider that one of these files as the master file, so we willuse the .mine file and make sure that file is selected first so it appears on the left.

Figure 1-9. The Changes app file selection dialog

The result is shown in Figure 1-10.

Figure 1-10. A file comparison in the Changes app

The differences in the files are now very obvious. We added a section for the selector img.example, someone else has added .clearfix, and the contents of the other selector have been modified. We check the logs quickly, and find out who has changed this file and read their commit comment. If necessary, we can then contact them to ask them about their changes. It turns out that a change in design required the change to height and width of a particular element, and that our changes to them are no longer necessary. Using the left file in Changes as our master, we now merge our changes. We just want the bottom part of the file, so we click anywhere in that section in the document on the right and click Copy to Left (see Figure 1-11).

Figure 1-11. Merging files in the Changes app

The file on the left is now how we intend the file to be. We copy and paste the contents into ie8.css file, and in Versions mark it as "resolved" (see Figure 1-12).

Figure 1-12. Resolved conflict in the Changes app

Finally, we do another update from the repository, and test the file to ensure that it works correctly. It does (hopefully!), so we commit it to SVN.^[10]

It goes without saying that backups are a vital element of any development process. It is of huge importance that you back up your repository and other important data. Where possible, versions of these backups should be stored in several discrete locations. Hardware failure, data corruption, and fire or flood damage can destroy months or even years of work in a moment.

A backup should be treated like insurance. You almost never need it, but if and when you do, it is potentially hugely more valuable than the cost to implement it. You should also have backups of different days—something like one backup a day for the last seven days at any point, and possibly even monthly backups going farther back. Sometimes we find we want to revert to a version that was lost a few days ago or look at a legacy version of a product, and not everything will be stored in source control.

It is important to ensure that your backups actually work. It is all well and good to religiously remember to take different backup tapes home, but if you don't run a test restore, you could find out at the worst possible time that all that hard work has gone to waste.

Developers' machines are less vital than your repository and servers. A simple hard drive backup should be adequate; the goal is to be able to get a developer back up and running as fast as possible when the hard drive fails (which is inevitable).

As part of the scoping process, it often becomes necessary to create a basic version of what we are going to build to give a hands-on example of what may otherwise be a complicated concept to explain. The considerations we would give to production-quality code—things like accessibility, file size, browser support, and so on—are not important here. The code we are developing is to be seen in-house only, and we can specify browser requirements. Any frameworks (read more about frameworks in Chapter 4) and shortcuts to speed up development are completely acceptable when creating prototypes.

Often the completed prototype is considered good enough and becomes production code, despite not being written as well as other code. This should be avoided because it encourages code bloat and technical debt, as well as other CSS sins. To that end, it is often a good idea to cripple the prototype somehow, so that we will definitely be given an opportunity to refactor and rewrite it later on.

If it is something purely visual we want to prototype, like a layout or user journey through a site, many tools exist to help us with this. A great example is Balsamiq Mockups (www.balsamiq.com/products/mockups), which has the benefit of creating diagrams that can be functional, but still look like sketches (one of the only valid uses for Comic Sans!). They cannot be mistaken for production imagery, and the discussions focus on the content and layout rather than things like fonts and color.

Spikes are similar to prototypes. A spike is named as such because it is a visual description of a tangent from our current path. If during development we find something we need to develop, and we're unsure of the best path to follow, we can "spike" development at that point. We would create a very rough example to demonstrate our intended path and to prove that it works. This example wouldn't include anything but the pieces necessary to demonstrate that our approach will achieve what we want it to, and would by definition (unless it is something very visual we are spiking) be unattractive and limited. Although a prototype is something we would copy and paste and modify to our needs, a spike will pretty much always be discarded after it has been proven (or failed to be).

Many development methodologies and processes exist. Each of them warrants a book of its own, but we will touch quickly on the two most popular kinds (by a long way), Waterfall and Agile.

Waterfall Development

The waterfall model has its roots in manufacturing. Although the word waterfall was never used, the first official description of this model is commonly thought to have come from an article Winston W. Royce wrote in 1970. Royce was actually writing about the model in order to point out that it is, in his opinion, a flawed and problematic way of working.

Waterfall (in software) describes a legacy development methodology, although still in use in many organizations. In its most basic form, it is the process of producing a technical specification for what we intend to deliver, giving details of the levels of effort (time periods) required by our resource (staff) and very granular descriptions of the exact details of the solution we will be building. Once the specification is agreed upon, the developers work on delivering exactly what is in the specification until it is complete, at which point it is presented to the business or client. It is at this point either rejected and then amended, or signed off and marked as approved.

The phases can be described like so (see Figure 1-13):

• Requirement Gathering (or Scoping)

• Design

• Implementation (or Build)

• Verification (or Testing)

• Maintenance (or Support)

The term waterfall was coined because of the concept that once we have reached a phase, it is impossible to change the output of (or return to) the phase previous to that one. That is, we can only flow in one direction.

Figure 1-13. An example waterfall process

As with all methodologies, there are pros and cons of waterfall development:

• Pros

  • The business/client has a clear indication of expected costs and timescales.

  • There is a definition of exactly what is being built.

• Cons

  • The specification is often incomplete or has errors that are too low level to isolate before the build commences. This results in the development team and client arguing over whether particular pieces of the solution were included in the original costings. Without making the specification ridiculously fine and detailed, items that may be obvious, implicit, and intuitive to the client/business could be misunderstood by the developers.

  • There is a paradox: to write a perfectly accurate specification requires the author to have already built the solution.

  • The specification leaves no allowance for change during the process; if the business/client finds another requirement that has to be included, it is necessary to wait until the "waterfall" runs dry before that requirement can even be considered.

Regardless of which development methodology you employ, it is rare to find a business or client that does not inherently work in a waterfall manner. When we as a business need something built, we need to know how much it will cost and how long it will take. To that end, it is common to treat the project from their perspective as a waterfall, but to use different methodologies internally during the project lifecycle.

This chapter focused on processes and tools that we can use to help us develop in the most efficient manner possible. Although processes change from company to company, and tools are often developed in-house, the basic tenets we have discussed still apply. Our processes must be strict to ensure that they are followed, and we must always ensure there is a "feedback loop" so our staff can highlight any failings in our processes and they can be changed to reflect this.

If possible, the team as a whole should pick and choose from all the styles and methodologies available and continue to perfect them over time. These processes apply to all kinds of development disciplines as well as to CSS development specifically, but they form the base of your working environment. To build a good team and write the best and most efficient CSS you can, you need a solid underpinning.

The next chapter will focus on CSS formatting guides and rules we can apply specifically to how we write and structure our style sheets. We willalso begin to look at best practices and discuss what you need to consider when working on high-traffic websites.