25+ Firefox Extensions for Web Developers

About one week has gone since Firefox passed the 400 million downloads mark. A lot of people and of course webmaster use the revolutionary browser to explore the web. So this time I want to present you a bunch of plugins, especially for web development!

Debugging

Firebug - A masterpiece of plugin! If you want to edit your sites CSS and preview it in real-time, this plugin is what you need.

JavaScript Debugger - A powerful JavaScript debugging environment.

Console Two - A plugin/console to display errors filtered by type, language and context.

Analysis

View Source Chart - A cool plugin which enables you to display a color-coded chart of a website’s source code.

OperaView - Open pages in Opera from Firefox context menu.

View Dependencies - This plugin adds a tab to the Page Info window which lists all the files that have been loaded to show the current page.

lori - It can tell you how long it takes to load a page.

HTML Validator - This plugin displays the number of found errors of the site you are viewing.

CSS Validator - As you may guess, it validates a site’s CSS stylesheet.

RSS Validator - One of many plugins to validate a RSS Feed using the W3C Validator.

Window Resizer - A plugin to resize your window to standard sizes; useful to see how your site looks with different resolutions.

IE Tab - Handy extension to see how your site is displayed in Internet Explorer.

ViewSourceWith - An extension that primary allows you to view the source code of a site with an external application but you can also open images with other apps etc…

CSS

Aardvark - This extension can show you the attributes, classes and ids by highlighting a page element with your cursor.

Font Finder - If you ever wanted to see the css-styles used for a certain element on a website, you need this plugin.

SEO

Social Media for Firefox - Really good plugin that shows the stats of 4 social services (digg, reddit, stumbleupon, delicious) for the page you are visiting, in the status bar. Useful if you want to know whether a site you own already has been submitted to one of these services.

Niche Watch Tool - Very good plugin that provides you the technical information like backlinks, page rank, keywords strength… everything a webmaster needs to analyze his site.

KGen - This addon retrieves all words of a page and lets you know how many times they appear; interesting for SEO optimization.

Others

Greasemonkey - Allows you to customize the way a webpage displays using small bits of JavaScript; a Must-Have!

Dummy Lipsum - Not the most valuable plugin for Firefox - it generates a “lorem ipsum” text.

ColorZilla - Nice Addon to pick the color of a page element and see its values.

Screengrab! - A plugin that saves the entire page as image (no flash elements).

Image Zoom - Offers you a zoom in, zoom out function for pictures.

Web Developer - Good extension that adds a toolbar to your Firefox with various web developer tools, e.g. Site Validation, CSS Viewer…

Unicode Converter - Converts entities or character references into Unicode and back.

Platypus - Another great addon which lets you modify a website from your browser. In addition to that you can save your modifications as a Greasemonkey script to make them ‘permanent’!

ShowIP - A useful extension that shows you the ip of the current page in the status bar. Also it enables you to see the whois details by querying some web services.

MeasureIt - Little Firefox extension that enables you to draw a ruler across any webpage to check the width or height of a element

The Fastest Growing Web Framework Is...

Hightower made an interesting observation in his blog recently when he compared job growth rates of various Web framework technologies on www.indeed.com. The clearly undisputed winner? JSF. As you can see from the attached graph images, JSF is growing much faster than any other other listed frameworks, as well as having far more job opportunities. But is it really? Is this graph telling the whole truth? More on that later.

Also very interesting, is the Spring and Ruby on Rails plots. It seems, at least according to this job site. That Ruby on Rails and Spring are virtually neck and neck, vying with each other for which one is more popular. At various times, Ruby on Rails has been more popular than Spring, but then Spring has overtaken Ruby on Rails and become more popular again.

This one I have a few problems with, since I don't see the supporting data on other job sites for it. For example, dice.com currently lists 2114 job openings for Spring, but only 241 for Ruby on Rails. That seems to differ radically from what the data at indeed.com suggests.

Of course, the sad story in all this, is the frameworks that just don't seem to be going anywhere at all. Tapestry, despite being a strong competitor to JSF, has gone virtually no where. once it is experienced its initial growth spurt after being released. It's basically flat. Unlike the Ruby on Rails vs. Spring data, the data at dice.com seems to support this one. There are currently only 87 jobs listed for Tapestry. This part is hard to debate no matter how you spin the numbers. Tapestry is virtually flat as far as having any kind of growth.

The data for WebWork and Struts2 is just as disappointing. Neither one of them has gained any traction at all. And once again, the dice.com data seems to support this.

To be fair, Struts2 was only released in February of this year, so it hasn't had a whole lot of time to gain in popularity. But since Struts2 is based on WebWork, I feel that it is fair to combine the WebWork and Struts2 graph lines. If we do this, we still find that neither one has experienced any significant growth.

Wicket was not included in this graph, but a quick dice.com search for Wicket shows only 23 openings, bringing it in no better than WebWork or Struts2.

What does this say about the future of Java Web frameworks? Is JSF going to usurp all of them and become "The Java Web framework?" Is JSF clearly the "current hot skill to have?"

Winning Through Effective Self Promotion

Setting personal goals and working single-handedly toward their success is both noble and a worthwhile use of your time. But as you reach for more challenging goals you are going to need the cooperation of others. Others can help you with their skills and resources. They will make it easier to succeed in the long run.

Effective self-promotion is the way to get others to help you reach your goals.

In this post you'll see how you can gain the power of persuasion to sell yourself and your services to the people who need them.

1. Why Promote Yourself?

2. The A.I.D.A. Formula Explained

3. 4 Surefire Tools That Grab Attention

4. Big Returns From Low Pressure Networking

5. Get Publicity!

Outsourcing may be coming to an end

As we have been hearing, costs among the outsourcing companies have been going up for the last couple of years. Competition has increased wages among outsourcing companies across the board.

Now Nishant Sivakumar in The Code Project:Finally something that might kill outsourcing brings up what will most likely bring Outsourcing to an end. When Outsourcing began the exchange rate was about 47 rupees to a U.S. dollar, today the exchange rate is 40 rupees to a U.S. dollar, so if trends continue even the stupidest MBA will figure out that there isn't the money in outsourcing that there was supposed to be.

The exchange rate coupled with rising expenses is sure to but the squeeze on the outsourcing companies and their customers. Thanks Nish for pointing out the obvious.

Programmer or Developer?

This made me think more about the distinction between a Software Programmer and a Software Developer. To me there is a subtle, but important difference. Let me give you my definition:

A Software Programmer is someone who really knows the environment he is programming. He knows everything there is to know about the language, the API and the Framework he’s using. He can do low level optimizations because he knows in detail what the compiler does behind the scenes. He is indeed a Wizard and a Guru of his domain. A Software Programmer usually starts with the implementation (probably because that’s what he is doing best) and work his way outwards.

A Software Developer on the other hand is a specialist at giving the customer (user) what he wants and what he needs. He doesn’t waste time on premature optimizations; he prioritize maintainability over performance, unless the performance is proved to be unacceptable; he has great testing skills, designing skills and communication skills; He is empathic, knows his HCI, and cares more about the user than he cares about his code. He cares so much that he usually becomes an expert himself of the users domains. A Software Developer starts with the interface (probably because that’s what he does best) and work his way inwards.

A person can be both, or more of one or the other. In a team you want both kinds but they are rarely found within the same individual. I, for instance, consider myself a great developer but an intermediate programmer. One simple way to test what type you are is to ask yourself this question: Do I care more for the interface (GUI or Programming Interface) than I do for the implementation? If you think the implementation is unimportant as long as it does what you want, and is reasonably maintainable, then you’re probably a Software Developer. If you find the previous sentence a blasphemy, you could be a Software Programmer. Which one is it?

What Tools I Use For Web Development

I use all of these applications/plug-ins

* Jetbrains IntelliJ Idea. The best IDE I've ever used.
* Textmate. The best text editor I've ever used.
* DBVisualizer. Makes working with databases easy.
* Fireworks, now from Adobe and likely to vanish someday.
* Interarchy. For moving stuff from one system to another.
* Path Finder. It's not a development tool but a Finder replacement; lots of neat programming assistant features.
* Firebug. If you don't use this for debugging javascript, you stand along in the world.
* Web Developer Toolbar. Although there is some overlap with Firebug, it's mostly complementary.

OK, you can argue with me, but these are my weapons of choice.

All I Need To Know To Be A Better Programmer

Programming is complicated stuff, but a lot of what makes a good programmer isn’t all that different from the earliest learning we did in school.

1. Share everything.

Use open source where possible, and contribute to it when you are able. The collective wisdom of the entire community is better than the limited vision of a few large companies.

2. Play fair.

Give other technologies, frameworks, methodologies and opinions a chance. Don’t think your choices are the only ones that work. The other choices may very well be better than yours; it doesn’t hurt to check them out with an open mind.

3. Don’t hit people.

Like #2, don’t attack people just because they happen to use .Net or Java or PHP (I learned my lesson there!). Sometimes they might be more usable and useful than you think. You can learn a lot more from someone when you are not pounding them to a pulp.

4. Clean up your own mess.

Strive to deliver code that works. Never expect QA to find all of your bugs for you. Test your code often, both narrowly and broadly.

5. Don’t take things that aren’t yours.

Follow the licenses for stuff you use, don’t just steal it and claim innocence later.

6. Say you’re sorry when you hurt somebody.

Code reviews are a good but rarely used idea. Mentoring programmers with less experience than you helps the entire team. Just don’t criticize people openly. Learning is not belittling people. Sometimes people will listen and sometimes they won’t. Sometimes you might learn a lot from people you think are inferior to you.

7. Wash your hands before you eat.

Try to understand things before you set out to write code. Do prototyping, check out examples on the web, talk with other folks who do it, or even just play around. Architecting something you’ve never done before or worked with is tough cold turkey. The end result will work much better if you start with a clue.

8. Flush.

Don’t be afraid to replace, rewrite, refactor or give up on something that is crap. Sometimes “when in doubt throw it out” is the best philosophy. Never fall in love with your code.

9. Warm cookies and cold milk are good for you.

Yes, programmers should be well supported in their work environment. A good chair, a quiet place to work, a decent computer and tools that make coding better and easier are essential. Managers should act as umbrellas to keep the crap from flowing down to the programmers. As a programmer, don’t accept a life of lowly servitude. If the employer treats you poorly then find one who treats you better.

10. Live a balanced life - learn some and think some and draw and paint and sing and dance and play and work every day some.

I like Google’s deal where 20% of your time is devoted to whatever you think it worth working on. Employers should (discretely) offer nap rooms or game rooms or some kind of chillout environment. Programming is hard mental work; sometimes you really need to give your brain a rest. Refuse to routinely work 80 hour weeks as the quality of your work will wipe out any gains in hours.

11. Take a nap every afternoon.

Working 24 hours a day doesn’t make you more productive. Take breaks, go home, take a real nap. Often I have solved nasty problems by going home, and the solution came to me as I was driving away, or the next morning.

12. When you go out in the world, watch out for traffic, hold hands and stick together.

Community is good for the soul; read blogs, learn about new languages or frameworks, participate in discussions and see what other people are doing. Just doing your job isn’t going to make you a better programmer. Keeping your head down means you will eventually be obsolete.

13. Be aware of wonder. Remember the little seed in the Styrofoam cup: the roots go down and the plant goes up and nobody really knows how or why, but we are all like that.

Every day something new and wonderful appears in the programming (and technology in general) world. Check it out. Be amazed. Learn something new everyday. It keeps your mind fresh, your options open, and your skills up to date. If you think programming is boring or dead then you may need a new career.

14. Goldfish and hamsters and white mice and even the little seed in the Styrofoam cup - they all die. So do we.

Code goes stale and dies. Sometimes you just have to bury it and do it again. Fight against keeping terrible code bases around just to save money.

15. And then remember the Dick-and-Jane books and the first word you learned - the biggest word of all - LOOK.

You won’t learn anything at all if you don’t try. Everything I learned in programming came from trying new stuff and generally playing around. Every morning I read a lot of sites to see what is happening in the programming world; I have been doing this since my first job in the early 80’s (when it meant reading catalogs and magazines).

See, programming is easy when you look at it through 3-year-old eyes.

Fix The Bug, Not The Symptom

I'm a big believer that a large part of the art of successful debugging is attitude. If you adopt the attitude that you can fix the problem and you're not getting to let this piece of technology make you look feeble and unworthy, you'll usually win.

There's more to write about that another time. Today I want to write a bit more about the flip side of this: being a responsible debugger and making sure you are fixing the real problem, not merely making the symptoms go away.
Learn A Lesson From The Villagers

Imagine that you live in a village on the edge of some grassy plains in Africa in the 19th century. Every now and again, a lion comes through the fence, enters a hut and eats all the meat inside. You decide to "fix" this problem. It seems to be a choice between two options:

1. Put a stronger door on your hut and maybe hang a slab of meat on your neighbours' huts as an extra incentive for the lion to go and visit them instead of you.
2. Look for all the places where the fence line can be breached and fix them.

Why is it that the 19th century African villager will pick the right solution (you picked #2, right?) and the 21st century software developer will often go for something akin to solution #1? Is it just because "screw your buddy" is much more obvious in this scenario than in the software band-aid patching approach?
Be Doubtful. Be Reluctant. Work Hard.

Tracking down the place where a bug appears is only the first step. That isn't the place where you necessarily need to fix the code. It's the place where the problems have finally mounted up to such an extent that the software falls over. It's the lion coming through the door of the hut when the problem was really the lion getting into the village in the first place.

When you're debugging a problem, as a practical matter, doubt that the problem you're seeing is the root cause. Maybe — once in a while — the problem is something obvious that was caused by a bad piece of logic a few lines earlier. More often, though, you're going to find that the current method or function was passed bad data by something else and that added to the problems until the camel's back completely broke.

The data might not necessarily be bad in the obvious sense. It might be perfectly valid data in another part of the program but you weren't expecting to handle it at the point the bug appeared. Sure, you could adjust the final location to handle this new data type, but why do this? Be very reluctant to broaden the interface you allow as input to a function. It just increases the number of code paths you have to worry about. Why is the unexpected data type getting here? Is there a broken assumption somewhere else? Is it newly added code that didn't respect the (possibly unadvertised or implicit) interface? It might be a legitimate oversight, but don't make that your first approach to a fix. That's a band-aid solution. You're fixing the symptom.

I will claim that for any reasonably large and stable body of code, there is usually a coherent set of design choices floating through the implementation. They might not be your choices and they might vary from component to component (particularly if the code has been built up over years and years), but there is going to be some logic to things. Try to understand this imlpicit logic. Work hard to ferret out the reasoning behind the interfaces and information flow. At some level, a "proper" bug fix feels very right. It feels like you've fixed it in the right place.

Applying a fix that makes the symptom disappear is lazy development. Maybe it's the right fix, but you'd better be able to explain why the problem should be fixed there. Why is that place the cause of the problem? Does the design back you up?

If you write a quick change to the code, run it and think to yourself "cool, that seems to have worked," it should make you feel uncomfortable. Why are you surprised that it worked? Lack of understanding of the root problem, perhaps?
Reviewing Proposed Fixes

Donald Knuth wrote somewhere (maybe in the TeX book?) that debugging was easier if you were already in a bad mood. The logic being that it's easier to be prepared to rip something apart if you want to do exactly that.

This might sound abstract, but on some level it's very true. I find my most successful periods of reviewing patches or designs — in my own code, just as much as other peoples' — is when I walk in dying to find a way to reject the proposed solution. If it holds up despite my best efforts to tear it down, it's probably a reasonable fix. This is, of course, the software development equivalent of statistic's null hypothesis; you have to disprove the opposite claim to have your version accepted.

The one line fix that applies to the precise spot of the traceback in a bug report is a prime candidate for this treatment. Without a lot of hard data, but with the benefit of about 15 years of professional experience, I will claim that most of those fixes are band-aids. Particularly if they're in an area that is likely to be executed with some frequency. Why hasn't this problem been noticed before? What special conditions caused the pile up of problems that made it noticeable only now? Again, working hard and being reluctant to apply the fix that makes the symptom disappear makes for stronger code.
Surely This Doesn't Happen In Practice?

I'd been planning to write this entry for a little while now. I spend a lot of time reading and reviewing bug reports and proposed fixes. I see more than a few messages on mailing lists asking why ticket number XYZ hasn't been fixed despite having three patches attached that make the problem go away.

Symptom removal happens. Unless you recognise it that way, and are prepared to look for the disease in every patch, it's easy to overlook. Particularly in Open Source code. We (Open Source developers) encourage community submissions. This pays off in the form of lots of bug reports, feature suggestions and patches to fix problems. The hidden downside is that a lot of patches for problems are written by somebody trying to get real work done. They want the fastest fix possible so they can get on with their real work, not devote a lot fo time to work on this piece of code that they downloaded from somewhere. Under those circumstances, it's easy to forget to look at the bigger picture. It's not a black mark against the person writing the patch — all contributions are welcome and if we don't take a particular patch, it causes no harm. It does explain why an existing patch might not necessarily be the right solution.

So, yes, the problem exists in practice.

Coincidentally, the issue was brought into the light recently when a couple of articles appeared on IT websites pointing out that Microsoft's Vista had degraded network performance when playing and mp3 file. That sounded odd on first reading. Microsoft's statement to explain why it was expected (for some value of "expected" that means "we thought it would be acceptable") raised eyebrows around the world.

Robert Love has written a good deconstruction of why this explanation is a model case of symptom hiding rather than bug fixing. You can see from Robert's write-up that a detrimental effect was made to go away, instead of investigating the root cause: why does using the network take up so much CPU? As noted in that article, Linux (amongst many others) has already solved this problem. It's hardly new technology any longer.

Clearly the solution isn't having more funds, more available developers or more process in place. Eternal vigilance is the last defender here. How you choose to get into that mode, using my "I'm going to assume this is busted until I can prove otherwise" approach or some other way, is entirely up to you.

Programmer’s life (cartoon)

Programmers carry small world with their selves. They require really small things to be happy. If they done their tasks according to specs, they will be very happy. Some times little showstopers make them sad, and they got frustrated. And start thinking diffrent kind of things like switching the job, how cruel the managers are, do I get appraisal etc, etc.

The given cartoon depicts interesting thing about programmers…