The 10 biggest moments in IT history

Author: Jack Wallen

Despite its relatively short lifespan, IT has had some huge watershed moments. Jack Wallen followed the tech timeline to identify the most pivotal events.

---

It's unlikely that everyone will ever agree on the most important dates in the history of IT. I know my IT timeline has a personal and professional bias. But I've tried to be objective in examining the events that have served to shape the current landscape of the modern computing industry. Some of the milestones on my list are debatable (depending upon where you are looking from), but some of them most likely are not. Read on and see what you think.

Note: This article is also available as a PDF download.

1: The development of COBOL (1959)

There are many languages out there, but none has influenced as many others as COBOL has. What makes COBOL stand out is the fact that there are still machines chugging along, running COBOL apps. Yes, these apps could (and possibly should) be rewritten to a modern standard. But for many IT administrators, those who don't have the time or resources to rewrite legacy apps, those programs can keep on keeping on.

2: The development of the ARPANET (1969)

It is an undeniable fact that the ARPANET was the predecessor of the modern Internet. The ARPANET began in a series of memos, written by J.C. R. Licklider and initially referred to as the "Intergalactic Computer Network." Without the development of the ARPANET, the landscape of IT would be drastically different.

3: The creation of UNIX (1970)

Although many would argue that Windows is the most important operating system ever created, UNIX should hold that title. UNIX started as a project between MIT and AT&T Bell Labs. The biggest initial difference (and most important distinction) was that it was the first operating system to allow more than one user to log in at a time. Thus was born the multi-user environment. Note: 1970 marks the date the name "UNIX" was applied.

4: The first "clamshell" laptop (1979)

William Moggridge, working for GRID Systems Corporation, designed the Compass Computer, which finally entered the market in 1991. Tandy quickly purchased GRID (because of 20 significant patents it held) but then turned around and resold GRID to AST, retaining the rights to the patents.

5: The beginning of Linus Torvalds' work on Linux (1991)

No matter where you stand on the Linux versus Windows debate, you can't deny the importance of the flagship open source operating system. Linux brought the GPL and open source into the forefront and forced many companies (and legal systems) into seeing monopolistic practices as well as raising the bar for competition. Linux was also the first operating system that allowed students and small companies to think in much bigger ways than their budgets previously allowed them to think.

6: The advent of Windows 95 (1995)

Without a doubt, Windows 95 reshaped the way the desktop looked and felt. When Windows 95 hit the market the metaphor for the desktop became standardized with the toolbar, start menu, desktop icons, and notification area. All other operating systems would begin to mimic this new de facto standard desktop.

7: The 90s dot-com bubble (1990s)

The dot-com bubble of the 90s did one thing that nothing else had ever done: It showed that a great idea could get legs and become a reality. Companies like Amazon and Google not only survived the dot-com burst but grew to be megapowers that have significant influence over how business is run in the modern world. But the dot-com bubble did more than bring us companies — it showed us the significance of technology and how it can make daily life faster, better, and more powerful.

8: Steve Jobs rejoining Apple (1996)

Really, all I should need to say here is one word: iPod. Had Jobs not come back to Apple, the iPod most likely would never have been brought to life. Had the iPod not been brought to life, Apple would have withered away. Without Apple, OS X would never have seen the light of day. And without OS X, the operating system landscape would be limited to Windows and Linux.

9: The creation of Napster (1999)

File sharing. No matter where you stand on the legality of this issue, you can't deny the importance of P2P file sharing. Without Napster, file sharing would have taken a much different shape. Napster (and the original P2P protocols) heavily influenced the creation of the BitTorrent protocol. Torrents now make up nearly one-third of all data traffic and make sharing of large files easy. Napster also led to the rethinking of digital rights (which to some has negative implications).

10: The start of Wikipedia (2000)

Wikipedia has become one of leading sources of information on the Internet and with good reason. It's the single largest collaborative resource available to the public. Wikipedia has since become one of the most often cited sources on the planet. Although many schools refuse to accept Wiki resources (questioning the legitimacy of the sources) Wikipedia is, without a doubt, one of the largest and most accessible collections of information. It was even instrumental in the 2008 U.S. presidential election, when the candidates' Wiki pages became the top hits for voters seeking information. These presidential Wiki pages became as important to the 2008 election as any advertisement.

What's missing?

Were there other important events in the timeline of IT? Sure. But I think few, if any, had more to do with shaping modern computing than the above 10 entries. What's your take? If you had to list 10 of the most important events (or inventions) of modern computing, what would they be? Share your thoughts with fellow TechRepublic members.

Seven fundamentals of IT project success

Author: Michael Krigsman

Many folks think large projects usually fail for technical reasons — software that doesn't work as advertised, bugs, and so on. In reality, that's not the case.

In my experience, the most serious project issues come down to misplaced expectations among participants. Fundamentally, problems in human communication lie at the root of most failures.

These expectation and communication mismatches are difficult to detect systematically, because they aren't quantitative or technical in nature. Failures persist despite fancy project management methodologies, precisely because traditional approaches do not isolate and address hidden problems.

These seven points of project success touch on conflicting agendas, multiple perspectives, and a broad range of business-oriented conditions that drive projects to succeed or fail:

1. Business case
2. Stakeholder and user engagement
3. Executive sponsorship
4. Third-party relationships
5. Project management
6. Change management
7. Resource availability

The Project Failures analysis

It's tempting to dismiss these points as obvious or to believe your projects have few problems in these areas. However, successful project managers dig deeper than that. For example, how do you really know that sufficient executive sponsorship is present? If you only asked one or two stakeholders, then your opinion may well be incorrect.

To gauge sponsorship accurately, you must gather perceptions across the project. After all, someone reporting directly to the CIO may have quite a different view than one working 1000 miles away who has never even met the sponsor.

Please do not ignore these seven fundamentals, thinking they are too "simple" or do not apply to your work. They really are that important.

In future blog posts, we'll explore practical steps you can take to uncover the hidden causes of failure that may be present on your projects.

Five job search tips for discouraged job seekers

Author: Toni Bowers


Few things are as discouraging as a long, seemingly futile search for a job. Nothing quite drags the self-esteem down than the long silence after you've sent out a resume.

In their new book, Unlock The Hidden Job Market: 6 Steps to a Successful Job Search When Times are Tough, Duncan Mathison, executive career consultant and former vice president of Drake Beam Morin, and Martha I. Finney, careers expert and employee engagement consultant, encourage job seekers to never give up.

Here they share five tips for job search survival:

1. Prepare for an extended search. When the job market shrinks, it takes longer to land a job. Adjust your finances and your expectations now to extend your staying power. Stopping the search until the economy improves is like the farmer who will go hungry at harvest because they didn't plant seeds in the spring. Do not give up. Keep planting those seeds.

2. Don't waste your time on long-shots. If you are only applying to posted jobs and those seem far and few between, your tendency is to cast a wider net by applying outside your geographic area or outside of your expertise ("I could do that job!"). This is a dead-end strategy and you will only face more painful rejection and depressing stories of 500 applicants to 1 job. When it comes to job postings: focus, focus, focus.

3. The right job for you is out there - it just won't be advertised. Employers cut recruiting budgets when times are tight. Instead hiring managers use less expensive and informal word of mouth strategies. As a result a higher percentage of available positions are in the "hidden job market". Job seekers must significantly expand the quality and quantity of their networking efforts to find unpublished jobs.

4. Leave the resume at home. The secret to good networking is to help your network help you. Instead of a resume, give people in your network (everyone you know) a list of 50-75 employers who you think would hire people with your type of skills. Do not ask if the companies are hiring. Instead ask if anyone knows people who work there - particularly managers who might hire and manage people with your skills.

5. Contact managers directly. Get their name, get an introduction and introduce yourself to them. Your introduction can be a simple, "I understand you have people with my kind of background and skills working for you. I don't assume to know if you have job openings but I would like to meet you and learn more about the type of people you like to have on your team and share with you a bit about my background." They may say "sure", they may say "send a resume" or they may say "no", but now they know about you. Remember the ONLY thing managers can do to assure their success is to meet and hire great people.

Making the case for dynamic languages

Author: Justin James 

Justin James presents reasons why developers should consider using dynamic languages. He also discusses how these languages trip up some developers.
——————————————————————————————————

Dynamic languages, for the most part, are ignored by the typical business developer. Sure, Perl had its flash in the pan moment during the CGI heyday of Web development, but dynamic languages are usually viewed as a niche item.

If you aren't considering using dynamic languages, I think you're leaving a lot of potential utility on the table. Here are three great reasons to take a look at what dynamic languages can do for you.

Metaprogramming is a breeze

Dynamic languages are excellent for metaprogramming. And with that attribute, dynamic languages are a great choice if you're working on a template system,a domain specific language (DSL), a code generator, a parser, or other type of application that can build applications. Can strongly typed, static languages do these things? Sure, but it is typically a lot more work than it is with a dynamic language.

The .NET world contains a number of tools for performing metaprogramming. You can use Reflection.Emit to spit out code; CodeDOM is slightly less painful; and for the current acme of VB.NET or C# metaprogramming, there are T4 templates. Out of those choices, T4 templates are the least effort to use. But by the time you're using T4, you aren't even performing metaprogramming anymore — to begin with, you're programming in a template system. It is my understanding that T4 is essentially just an abstraction layer on top of CodeDOM.

On the other hand, look at what you can do in a language like Ruby, Perl, Python, PHP, or even JavaScript when it comes to metaprogramming. It is a cinch to hash together a templating system. In Perl, for example, the "guts" of one consist of one line of code. Want to make a code generator? That's easy too. And, thanks to eval, you can do some pretty wild stuff in terms of on the fly modifications to business logic, such as allowing per-customer overrides of default functionality while maintaining a single install base in a multi-tenanted application. You can do all of this with very few lines of code and relatively low complexity. The systems practically write themselves.

Cross-platform compatibility

Dynamic languages tend to be much more cross-platform compatible than other languages. The runtime environment takes the guesswork out of the gotchas that you can encounter. There will occasionally be incompatibilities, such as when the language needs to make calls to the underlying operating system. Sometimes the results will not be the same (math functions with large numbers and cryptography are two examples). Even still, you shouldn't need to rewrite or modify the overwhelming majority of applications written in dynamic languages to move from platform to platform.

Code focused rather than structure focused

Dynamic languages often get a bad rap for being too loosey-goosey about architectural principles. Developers who knock dynamic languages on this basis will often call them "scripting languages," with the implication that the languages are really only suitable for gluing together OS functionality or automating an application via an API.

The truth is dynamic languages simply focus on the code. And while dynamic languages can often support the detailed architecture that C++, Java, and C# are capable of, the languages tend to minimize that aspect of programming. This is not always the case. Perl and PHP, for example, have never been truly object oriented at heart, although both are changing in that direction. Languages like Ruby and JavaScript support the kind of enterprise development styles of architecture, but in standard usage, you don't need to deal with it at all.

Possible issues

In my experience, most developers who experiment with dynamic languages find this de-emphasis on structure to be refreshing. Those who do not usually trip up on the following common problems:

Undisciplined programmers writing sloppy code.
In a dynamic language, some of the "safety net" that static, strongly typed languages have is removed. The programmers are trusted to do what the compiler in other languages enforces. While this allows for rapid code writing, it also enables developers who lack discipline to write code that runs but not correctly.

Built-in shortcuts can reduce readability.

Dynamic languages tend to have a lot of built-in shortcuts. Developers who rely on Perl's "implicit variable" usually produce code that is difficult to understand when other developers read it. Ruby has lots of aliases for functionality; this makes the code feel more logical, but it also requires subsequent readers to have an expanded "vocabulary" to know what each of those aliases do.

Flexibility.

Dynamic languages often allow you to override or remove functionality from even the core language. While this can reap huge rewards, it can be confusing. For example, if someone overrides the "print" function (maybe to include application-specific formatting), developers who are not aware of this could end up pretty confused.

Each bullet point shares a common theme: responsibility of the developers (thanks to Chip Camden for pointing me to this post). To put it simply, these languages make the programmer responsible for doing the right thing, instead of enforcing it at the syntax level. Some might compare it to C/C++, but I don't think it's a good comparison. In C/C++, you don't have a choice but to tread on dangerous ground; it's impossible to write anything in C that does actual work without using a pointer. In dynamic languages, all of the potentially problematic features are squarely in the category of features rather than requirements. As a result, you'll find that these languages tend to not expose you to too much danger before you're ready.

Conclusion
Are dynamic languages right for every developer? Of course not. There are some very real problems with dynamic languages, and some of these problems are inherent to their design. Performance will always be a bit slower than other languages (not to say that they are necessarily slow). IDEs will always have a hard time understanding what many areas of code do simply because the code is non-deterministic until runtime. Along the same lines, many pre-runtime tools (such as static analyzers) will not be able to do the same things with dynamic languages that they can do with static languages.

Despite these points, dynamic languages are a potentially useful tool that more developers should consider using in their work.

J.Ja

Ten tips for handling .NET exceptions exceptionally

by Lamont Adams

Takeaway: Get the most out of .NET's structured exception system with these 10 best-practice tips.

When used properly, the structured exception-handling system in .NET can produce efficient, clean, and unobtrusive error handling for your applications. When used improperly, however, this same system can bog down your apps and become a major pain in the neck. So, to keep everyone on the straight and narrow, I present my 10 tips for exceptional exception handling.

1. Use one try and many catches
When placing exception-handling code in your applications, it's generally better to enclose all code that may throw an exception in a single try block and have multiple catch blocks set to trap different expected exceptions. Having all catch statements in a central location increases the readability of your code.

2. Order catch blocks from specific to general
When placing catch blocks in your code that are set to catch different types of exception, always place them in order from most specific to most general. Doing so not only makes it clear that specific exception types will be handled before the more general types, but it also helps other developers reading your code understand what's going on.

3. Always ensure you reach a valid state
The minimum standard for exception handling should be to ensure that your object returns to a valid state after the exception occurs, and a caller should be able to safely assume that there were no side effects from an exception in a method call. Perform any needed cleanup to ensure this valid state in a finally block so that it always takes place.

4. Document what you can throw
In Java, developers must declare that a method they write can throw an exception and explicitly list the exceptions that a caller can expect to have thrown to it. That may seem a bit cumbersome to some developers, but knowing in advance which exceptions a method call can generate allows you to form a specific plan for dealing with each of them, rather than depending on a generic "catch everything" block. Always endeavor to document which exceptions can be thrown from any class or method you create.

5. Throw the closest match
In situations where more than one exception can represent the same error, always throw the exception type that most closely matches the error condition. In the case of a division by zero error, for example, where either an ArithmeticException or a DivideByZero exception could apply, you should throw the latter instead of the former. The main idea is to always communicate the most specific information possible about a given error condition to the code that will catch your exception.

6. Never throw in the course of normal use
Remember that the use of the term exception in programming has to do with the thinking that an exception should represent an exceptional condition. Exceptional conditions, by their very nature, do not normally occur; so your code should not throw exceptions as part of its everyday operations.

Do not throw exceptions to signal commonly occurring events. Consider using alternate methods to communicate to a caller the occurrence of those events and leave the exception throwing for when something truly out of the ordinary happens.

7. Extend the ApplicationException, not the base Exception, class
When creating a custom exception, always extend the ApplicationException class, never the base System.Exception class. Doing so keeps user-defined exceptions in a separate object hierarchy than exceptions that could be thrown by the .NET runtime.

8. Use the inner exception property when rethrowing
Sometimes, you'll need to create and throw a new exception of one type in response to catching an exception of another type in your code. In those cases, you can use one of the overloaded constructors of the base System.Exception class to wrap the exception you caught in the new exception you are throwing. The calling code can then examine the InnerException property of the exception thrown to it to determine the underlying cause of the problem.

9. Do not create lightly
All told, there are well over 100 built-in exception types in the .NET Framework's class library. The children of SystemException represent the largest fraction, covering everything from simple arithmetic errors like division by zero, all the way to an invalid Xpath query.

The point is that a system exception is probably already defined for most errors you'll encounter. If so, you should use that exception rather than create your own. The only time you should consider creating a new exception for an error situation that has a predefined system exception is when the situation is "exceptional" enough that you want the catcher to be able to take a specific action that wouldn't be taken normally.

10. Name appropriately
Any new exception classes you create should have a name ending with the word Exception so there is never any question that the class is an exception class.

Create better Web sites with CSS and the Font Control property

by Contributor Melonfire

Takeaway: Explore the CSS font property, which provides an alternative to the older font element and is a great tool for when you need to centralize control over the typeface, color, size and spacing of your HTML pages.

This article is also available as a TechRepublic download, which includes the example code listings in a more manageable text file format.

In times past, altering the typeface of a Web page usually meant enclosing the relevant text in a <font> tag and applying attributes to control its color, size and style. Today, this method is frowned upon, because it mixes visual styling aspects with actual content markup. The recommended method these days is to extract typeface styling information into a separate file, called a Cascading Style Sheet (CSS).

Putting font information into a CSS file has a number of important advantages: it's easy to do, doesn't require any special software, and works uniformly on most major browsers. More importantly, because information is centralized in a single location, altering the visual appearance of your pages is a snap: simply alter the font or color in your primary style sheet and the change will "cascade" across your site instantly.

Sounds interesting? Then keep reading, because this article explores the CSS font property, which provides an alternative to the older <font> element and is a great tool for when you need to centralize control over the typeface, color, size and spacing of your HTML pages.

Controlling typeface

The font-family property defines the font(s) to use for the corresponding element. This typically contains a list of font names, separated by commas; quotes can be used to enclose those names which contain whitespace. The browser will use the first font it finds in the list, or default to the standard browser typeface if none are available.

Listing A is an example of this directive in action:

Listing A

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana";
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
</body>
</html>

And Figure A shows you what the output looks like.

Figure A

Font_family

It's important to remember that this directive depends heavily on which fonts are present on the client system; in the example above, if neither Bookman Old Style nor Verdana are present, the default browser font will be used instead. To avoid this, it's a good idea to follow up the list of specific font names with the name of a generic font family, such as serif, sans-serif or cursive; this tells the browser to use the closest match within that category of fonts. Listing B is a revised version of the previous example, which does just that.

Listing B

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana", "cursive";
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
</body>
</html>

Controlling color

Font color is controlled using the color property, which accepts either an RGB value in hexadecimal notation or a "color word" such as red, silver or blue. Listing C shows you an example.

Listing C

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana";
        color: purple;
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
</body>
</html>

And Figure B shows you what it looks like.

Figure B

Color

Controlling size

Next up, size. Font size is controlled via the font-size property, which accepts either absolute (numerical units or keywords such as xx-small, small, medium, large, x-large) or relative (larger and smaller) values. Size units may be described in terms of points, percentages or ems. Listing D is an example; it magnifies the font to 400% of its normal size:

Listing D

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana";
        color: purple;
        font-size: 400%;
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
</body>
</html>

And Figure C shows you what it looks like.

Figure C

Size

Controlling emphasis

Font emphasis is controlled via the font-style and font-weight properties, which broadly correspond to HTML's<i> and <b> elements. The font-style property accepts any of the values normal, italic and oblique, while the font-weight property can either accept values on a numerical "boldness" scale between 100 and 900, or the keywords normal, bold, bolder and lighter. Listing E is an example that demonstrates both these properties.

Listing E

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana";
        color: purple;
        font-weight: bolder;
    }
   
    .attribution {
        font-style: italic;
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
    <div class="attribution">-- Hamlet</div>
</body>
</html>

And Figure D what it looks like:

Figure D

Font weight and style

Controlling word, character and line spacing

CSS also makes it possible to control the space between words, characters and lines, via the corresponding word-spacing, character-spacing and line-height properties. As with the font-size property, values may be expressed in points, pixels and ems. Listing F demonstrates with an example.

Listing F

<html>
<head>
    <style type="text/css">
    .quote {
        font-family: "Bookman Old Style", "Verdana";
        color: purple;
        font-weight: bolder;
        font-size: 200%;
        line-height: 50px;
    }
   
    .attribution {
        font-style: italic;
        word-spacing: 15pt;
        letter-spacing: 8px;
    }
    </style>
</head>

<body>
    <div class="quote">To be or not to be, that is the question.</div>
    <div class="attribution">-- Hamlet, Act 3, Scene 1</div>
</body>
</html>

Figure E shows you the output:

Figure E

Spacing

Of course, these examples are just the tip of the iceberg when it comes to working with fonts in CSS. However, they should have given you some insight into how these properties work in practice, and you should now know enough to begin experimenting on your own. So what are you waiting for?

How do I check how different fonts and styles look without recoding?

Author: Jack Wallen

One of the issues that can plague Web designers (not to be confused with Web developers) is that of font choice. Choosing the proper font and font style for your Web site can make or break a site's overall design. And I am sure you've seen it — a great site with fantastic elements, images, color schemes, style, and content that is rendered either ugly or unreadable simply because of a poor font choice.

The problem for designers, which quickly trickles down to developers, is that font choice can be dictated by browser choice, browser release choice, and CSS usage. These layers add up to create a fairly complex problem that is often solved by making a choice, seeing if it works, and then tweaking the CSS file over and over until the choice is perfect (or as close to perfect as you can get). This tweaking can take some time, unless you employ an amazingly helpful tool like FontFriend.

FontFriend is a Web-browser bookmarklet that will make your design work so much easier that you will wonder what you ever did without it. With this tool you can simply open up your Web site, click on FontFriend, change the font and font styles as FontFriend makes the changes in real time, and then, once you have found the right font and font styles, apply those changes to your CSS files as needed.

Now, before I get into how to use this tool (it's quite simple actually), I will warn you that the larger and more complex the site, the slower FontFriend will be. If the site is too large and too complex FontFriend could take your browser down. Fear not, though, even if FontFriend takes down your browser, it will not make any changes that are permanent or damaging. So, in the event of a crash, you will only need to fire your browser back up.

This blog post is also available in PDF format in a free TechRepublic download.

Installing FontFriend

If you have ever installed a bookmarklet you will not have any problems installing FontFriend. You don't actually "install" FontFriend. What you do is click on the bookmarklet link (from the FontFriend site) and drag it to your Bookmark Toolbar. Now this bookmarklet can be used in Firefox 3/3.5b and Safari 3 and 4. FontFriend does not support Internet Explorer, and, as the site says, "any compatibility with IE is mostly accidental and, frankly, surprising."

NOTE: With this "installation" don't mistake your regular tool bar with the bookmarks tool bar. You cannot install this bookmarklet anywhere but on a bookmark toolbar.

Once you have FrontFriend on your bookmark tool bar it will show up on your tool bar simply as FontFriend. You can change this name if you like by opening up the Organize Bookmarks, clicking on the FontFriend bookmarklet entry (it will be located in the Bookmarks Toolbar folder) and making the changes (Figure A).

Make sure, however, that you do not make any changes to the location. If you edit the location of FontFriend you will most likely break it. The only fields you should concern yourself with are Name, Keyword, and Description.

Figure A

The location is the "code" that actually makes FontFriend work.

Using FontFriend

When you navigate to your site, you need to click on the FontFriend bookmark in your Bookmark tool bar. When you do this FontFriend will open an overlay on your page at the bottom left, as you can see in Figure B.

Figure B

You can minimize this overlay by clicking the "F" in the upper-left corner.

Once this overlay is open, you can click on different font elements and the changes will update on the page in real time. As mentioned earlier, the more complex the page, the longer it will take for the change to take effect.

Let's take a look at a changed page. First I will show you the FontFriend page with the default fonts (Figure C).

Figure C

Here is the default font for the FontFriend page.

Now let's take a look at the same page with a different font and font style. Figure D shows FontFriend laying out the same site with a bad font.

Figure D

This font is Cambria in small caps.

This time around we'll see the same site re-rendered with a font that makes the page much nicer (Figure E).

Figure E

This time the page is rendered with the Tahoma font.

Remember, you can do more than just change the font on the page. You can also set the text to all Small Caps, Initial Caps, Bold, Normal, Upper Case, Lower Case as well you can edit body text, paragraph text, header text and even roll your own. If you decide to roll your own, make sure you take a look at the jQuery JavaScript Library link within the FontFriend overlay so you can see the types of tags you can use.

Resetting to default

Resetting the page back to the default style is simple. At the bottom right of the overlay you will find a very faint "S." If you click that "S," the site will return to its default styles.

Moving the overlay

There are times that you will want to see the text under the overlay. You can do this by moving the overlay around with the four arrows. When you click one of the arrows, the overlay will move that corner of the Web page being viewed. If the overlay is in the bottom right and you click the up arrow, the overlay will move to the upper-right corner. Click the left arrow, and the overlay will move to the upper-left corner, and so on.

Final thoughts

FontFriend is one of those tools that will make a designer's job easier. You will find that FontFriend takes some of the tedium and guesswork out of finalizing your CSS for the sites you are designing/developing.

Great Persons-Great Sayings...

 

For Nice, Quotes, Fun SMS and Shayaris Visit SMS Messages

 

 

 

 

 

 

 

 

 

        

 

Colors of the Earth

 

Play 10,000 + Free Games Here :  Games

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

   

 

 

Wooden Scale Models

 

Play 10,000 + Free Games Here :  Games

 

 

 

 

 

 

 

 

 

   

 

 

.

__,_._,___