Web developers live in an ever changing world of languages, browsers, development kits, and platforms. The recent introduction, and popularity, of “App” development has introduced a serious competitor to the open web. Our world as web developers is about to change.
Presumably in October (at GOTO) Google will be unveiling their new Dart language.
ConceivablyTech has done a good job summarizing the data from NetMarketShare.
Google’s Chrome had another successful month and ended 2010 with 10.70% market share, according to Net Applications and almost 16% according to StatCounter. Microsoft’s Internet Explorer continued to lose market share on a fast pace while Mozilla’s Firefox is fighting and tightly holding on to the market share it has.
Everywhere I look on the web (the web developer web that is) is CSS3 this, jQuery that, shadows, HTML5.
Such a tease, what about our minimum browser requirements spec? Damn IE6 is yet again 10% of the target demographic.
Not only is IE6 the problem, but so is the most recent IE8, as well as IE7. They just don’t support CSS3 and HTML5.
Now we have some solutions…
Saw this link on reddit today, Exploring the software behind Facebook, the world’s largest site:
At the scale that Facebook operates, a lot of traditional approaches to serving web content break down or simply aren’t practical. The challenge for Facebook’s engineers has been to keep the site up and running smoothly in spite of handling close to half a billion active users. This article takes a look at some of the software and techniques they use to accomplish that.
HTML Zen Coding is a plugin for many popular HTML editors that gives the web developer many tools for quickly building out HTML pages. If you are comfortable (and enjoy) CSS selectors popular today in many frameworks (such as jQuery) then this may be for you.
When we build HTML documents, we are always building code that is repetitive, and we have ways of making that better. Creative copying and pasting usually. Sometimes I feel like I’m playing music on my keyboard when I do my copy paste and edit keyboards commands over and over.
With Zen Coding the process is much “simpler”. You need to learn the syntax, which is straightforward for most selector friendly folks — but it will shorten your workload and let you do some things that you may have avoided before.
To test, on your machine, what it would look like for someone who doesn’t have flash (iPhone / iPad) or has flash disabled (some ultra sensitive geek), do the following:
- Launch Firefox
- Tools ->Add-ons
- Scroll down to “Shockwave Flash”
- Click on “Disable”
- Refresh or Load the page
You can do this in other browsers, I just find it easiest in Firefox.
Web developers have to refresh browser caches a lot (if we even have our browsers set to cache) — if you want a quick way to pull up the “Delete Browsing History” screen in IE8:
It’ll pop up, click “Temporary Internet Files” and then “Delete”. It will stop you from having to click into the menus up top.
Bonus – Force IE8 to “Always Refresh from Server”
If you’re in IE8 and are constantly refreshing the cache, why not temporarily force refreshed content:
Hit F12 (for the Developer Tools)
Click on menu item “Cache” and click on “Always Refresh from Server“
You can look back in there to see a checkbox next to it, so you know it’s on. It will let you always refresh from the server for just the current browser session (very useful).
It is cool that you “sniff” the end user’s device as iPhone and automatically redirect them to an iPhone friendly format of your website.
Don’t automatically redirect them to the home page.
If I’m browsing the internet on my iPhone, and click on a link to an article on … say fish … and I’m redirected to the home page because you want to show me the data in the right format, it pisses me off.
Web developers are responsible for writing websites that work today, but also years or even decades from now (though I would argue the average website shouldn’t be left alone for a decade).
It can be difficult to protect a website against all future attacks. There is one big one we all have to be prepared for (because it is just so easy to fix)… SQL Injection attacks.
In my days as a web developer I’ve probably worked with about 100 other developers. Every team I’ve been on, I always knew who would (correctly) pump out bug after bug, and who would sit with a single bug for weeks.
Think of the slowest developer you know. They usually are reluctant to learn new development methods, new software, and practices. These slow developers can spend days or weeks on a single bug, constantly absorbing your time as they stare blankly at a bug.
Sometimes there are reasons for this:
- They have never worked in this environment
- They do not want to ask for help
- The bug is actually hard
- They can’t even find where to begin looking
Just today I found a blog written in July by Steve McConnell titled:
Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell’s thoughts about how to move toward the “10” side of that 10:1 ratio.
How true is that statement? We’ve all been on the projects where we wish we had “5 Toms” or 3 of another developer. Why? Not only does he get it, he knows how to handle software development.
How can you improve your software development speed?
First of all, speed isn’t everything. Lets define speed, by the total time it takes you and all others involved to complete (not just submit a fix) a task.
If you get a task and submit it for approval (or even worse, just deploy it) consider the time it takes the QA team to look at the bug, boggle their head when it still isn’t working, document the bug and assign it back to either the project manager or yourself. Yes, the QA team would have looked at the bug anyway, but now they have to do it again. The project manager now has to review this bug, and reassign it to you, or you yourself have to read it again and develop again.
There is a huge delay in speed when submitting a completed task that is not complete.
To establish a baseline, it is top priority to submit fully tested and fixed bugs. Otherwise you are just wasting everyone’s time. The bug won’t go away, you know it will come back.
We are now submitting actually fixed bugs (we tested ourselves, and they work in all possible scenarios) … how can you improve your speed?
- Talk to other developers on the project, someone always has a better software package, or better way to handle those time consuming repetitive tasks
- If at all possible, automate compilation. Use Ant or a build script, but somehow, you need a way to quickly (and CONSISTENTLY) compile your work. Nothing sucks more than trying to troubleshoot a bug, only to realize you didn’t compile the same files the same way.
- Expedite testing of your tasks. Local servers are great for this (and make it easier for the rest of the team). Every time you test a change, you have to spend time doing the actual test. This takes maybe 15 seconds, but sometimes you do this 100s of times for every bug you complete (or more). 15 seconds * 100 times = 1500 seconds that is 25 min. of time. If you get it to 3 seconds, you have just gained 20 minutes worth of time to fix that bug.
- Always search for new tools. Aside from talking to other developers, you can research better ways to do what you are doing.
- Communicate with everyone. A project takes a team to complete (usually), so if you are speeding ahead and done weeks ahead of everyone, the project is not going to be done earlier. If you are ahead, help out your team members, proactively provide faster / better ways to do tasks. Additionally, it is easier for the client to react to a delayed delivery when notified of it earlier on. While it may take time from your schedule to say you messed up estimation (it happens, a lot), the client won’t have to scramble and can establish a well thought out backup plan.
- Keyboard Shortcuts. When I code I get into a groove where I hit buttons almost like playing music. There is a beat to saving, tabbing over, repeating last compile command, tabbing over again, and refreshing a web page. How many times do you save a file? Ctrl+S is much faster than using your mouse (I know, it’s a basic example, but you get the idea).
- Don’t get stuck. Obvious, but still not easy to do. When you get to a bug that you just can’t solve. Don’t. Move on to another one that you can, notify the team that you are stuck on the bug, maybe someone else can fix it who has a different perspective on the issue. Software development shouldn’t be about ego, it is about working with everyone towards a single common goal.
- Make a list. I hate lists. Ask anyone who knows me, family, friends. They are great for putting things in perspective. If you have a list of 20 tasks to do this week and are stuck on #3. You know you should MOVE ON. Getting 3 out of 20 is much worse than 16 or 17 out of 20. You also start to see groups of tasks that involve the same set of files or code and can work on them together.
- Test frequently. Sweeping changes to code never work. I’ve been on countless projects, and then minute I start feeling bold and implement 2 or 3 fixes, I always have to go back and fix something.
- Learn to debug code. I cannot emphasize the importance of this one enough. Debugging code is perhaps the single greatest skill any developer can have. Usually the hardest part of fixing a bug, is finding the bug. Here are some hints:
- Binary search is amazing not just for searching, but sub dividing code. Comment out half of your program, see if the bug is in that half or not. Even if you have no idea where the bug is, you can eliminate 50% of your options with a few comments (ok, sometimes you can’t quite do this, but you can get close). Within a few attempts you will narrow down your scope.
- Don’t be afraid to get ugly. I always make sure when I’m debugging, to make things as visible as possible. If I’m debugging a flash project, I make big ugly bright colored shapes appear when code is executing. Use system.out, writeln (Pascal, there’s an old one), trace, alert, anything that will help you know more bout what you are doing
- Use debuggers. Debuggers are your friend. You can see variables, set breakpoints to inspect loops. Frequently developers think they can just “alert(‘test’)” their way out, but there are many free debuggers out there (some are already on your computer).
Another big one, is don’t post blogs while working! Focus.
Usually some non code related things get me going faster too. A clean workspace, work friendly music (sometimes classical, sometimes club music, you pick your mood). Sometimes its a snack you grab in between bugs as a treat.
Best of luck everyone, check out that blog again: 10x Software Development