Wednesday, July 26, 2006

When Tabbed Browsers Attack: Reducing Distrations and Clutter

As the Web 2.0 portal sites like Google and Yahoo! begin to offer more and more services - such as email, calendering, stock portfolios, spreadsheets - you may start to find that you open lots of browser windows - one for each service - or lots of tabs on those browsers that support tabs.

The tabbed browser approach is also problematic because you usually end up mixing service tabs with general surfing. It can take a while to find which tab contains a particular service.

This could become a real UI challenge for users of these portal sites as more and more applications are offered over the web.

So what can you do? You could start a new browser window just for, say, Google services, but you will still have to juggle multiple windows and tabs.

The CheeseBurgerMan has a solution he calls Googlr, which is a WinForms wrapper with embedded iexplorer around Google services where tabs are replaced by menu items. I suppose this could be done using iframes and a bit of clever javascript, but it is a nice attempt at making the navigation of these portals a bit easier.

You still do what?

This cartoon from Metro of a few weeks ago reminds me of how quickly things change.

I can't wait for the day when I hear:

  • You still use vi? (The evil "six" editor)
  • You still program in Java/C#/Ruby/C/C++/Perl?
  • You still program?
  • You still use a keyboard?

Wednesday, July 19, 2006

One Hundred Rules for NASA Project Managers

Jerry Madden, a long serving NASA project manager, lists out his '100 Lessons Learned for Project Managers'. Among his perls of wisdom:

  • Rule #5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot.
  • Rule #20: You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job.
  • Rule #24: One must pay close attention to workaholics—if they get going in the wrong direction, they can do a lot of damage in a short time.
  • Rule #38: Never undercut your staff in public (i.e., In public meetings, don't reverse decisions on work that you have given them to do). Even if you direct a change, never take the responsibility for implementing away from your staff.
  • Rule #56: The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.
  • Rule #66: Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will astonish you.
  • Rule #79: Next year is always the year with adequate funding and schedule. Next year arrives on the 50th year of your career.
  • Rule #84: Never make a decision from a cartoon. Look at the actual hardware or what real information is available such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.
I'm a bit worried he has so many rules to follow :)

Tuesday, July 18, 2006

Is C really that fast anymore?

An interesting article exploring the possability C is not necessarily the fastest language on block anymore because processor architectures have changed so much that C no longer maps directly to the processor instruction set. What is better? Runtimes that dynamically adapt, like Java.

The closer to the metal you can get while programming, the faster your program will compile — or so conventional wisdom would have you believe. In this article, I will show you how high-level languages like Java aren't slow by nature, and in fact low level languages may compile less efficiently...

Early versions of UNIX were written in Assembler, but this proved to be a hindrance when porting it to new platforms, because assembly languages are machine-specific. Existing high-level languages, such as LISP, provided too much abstraction for implementing an operating system, so a new language was created. This language, C, was a very slightly abstracted form of PDP-11 assembly language. There is almost a 1:1 mapping between C semantics and PDP-11 machine code, making it very easy to compile C for the PDP-11 (the target machine of UNIX at the time)...

When C was created, it was very fast because it was almost trivial to turn C code into equivalent machine code. But this was only a short-term benefit; in the 30 years since C was created, processors have changed a lot. The task of mapping C code to a modern microprocessor has gradually become increasingly difficult...

As a simple example, consider the vector unit found in most desktop processors. One instruction might take four integers, add them to four other integers, and provide the result as a set of four more integers. Now imagine some code that could be adapted to take advantage of this capability.

In C, the usual representation of a vector is as an array. Unfortunately, you can’t define operations on arrays, so adding the values in two arrays would be done as a loop in C, with scalar operations in the loop body...

A just-in-time compiler doesn’t have these limitations.

Sunday, July 16, 2006

Getting the full Java command line from Solaris

These days the entire command line for starting up some of the bigger Java application servers can be very, very long - in the order of 500+ characters.

If you are working with one of the BSD variants of UNIX then viewing the entire command line is easy - pass the "ww" (wide wide) arguments to the ps command, which will display the entire command line. If you are using a SYSV variant of UNIX, like Solaris, then that version of ps doesn't provide any "extra wide" options.

For example, using the standard SYSV ps on Solaris will give you something like the following:

rmaldon@sun1> ps -ef | grep rmaldon
rmaldon 13703 1 0 17:40:11 pts/11 0:33 /opt/IBM/WebSphere/AppServer/java/bin/java -XX:MaxPermSize=256m

which is only a fraction of the full command line that was used to start the process.

How can you find out the full Java command line on a SYSV platform? You can compile a BSD version of ps for your SYSV platform courtesy of the GNU shellutils package. Or, on Solaris, because Solaris started out as a BSD variant many moons ago they still bundle some BSD tools, including ps, in the /usr/ucb directory. So, using the /usr/ucb/ps on Solaris will give you something like:

rmaldon@sun1> /usr/ucb/ps -auxww | grep rmaldon
rmaldon 13703 9.0 2.4300728187352 pts/11 S 17:40:11 0:32
/opt/IBM/WebSphere/AppServer/java/bin/java -XX:MaxPermSize=256m -Dwas.status.socket=45169
-Xbootclasspath/p:/opt/IBM/WebSphere/AppServer/java/jre/lib/ext/ibmorb.jar:/opt/IBM/WebSphere/AppServer/java/jre/lib/ext/ibmext.jar -classpath /opt/IBM/WebSphere/AppServer/properties:/opt/IBM/WebSphere/AppServer/lib/bootstrap.jar:/opt/IBM/WebSphere/AppServer/lib/j2ee.jar:/opt/IBM/WebSphere/AppServer/lib/lmproxy.jar:/opt/IBM/WebSphere/AppServer/lib/urlprotocols.jar
-Xms50m -Xmx256m -Dws.ext.dirs=/opt/IBM/WebSphere/AppServer/java/lib:/opt/IBM/WebSphere/AppServer/classes:/opt/IBM/WebSphere/AppServer/lib:/opt/IBM/WebSphere/AppServer/installedChannels:/opt/IBM/WebSphere/AppServer/lib/ext:/opt/IBM/WebSphere/AppServer/web/help:/opt/IBM/WebSphere/AppServer/deploytool/itp/plugins/
-Djava.util.logging.configureByServer=true -Dibm.websphere.preload.classes=true
-Ddb2j.system.home=/opt/IBM/WebSphere/AppServer/cloudscape sun1 server1

Thursday, July 13, 2006

The technology behind Google

"How Google Works" is a summary of the interesting technology used by Google. Among the highlights:

  • Built their own highly distributed Google File System (GFS). This is really an application storage utility rather than integrated with the operating system, and "relaxes" consistency for performance. (See "The Anatomy of a Large-Scale Hypertextual Web Search Engine" and BigTable.)
  • The secret PageRank algorithm.
  • Pre-packaged racks of cheap computers that can be deployed over night at a data centre near you.
  • Go for server hardware that uses less power (rumor that Google switched to AMD just because their processors ran cooler) so you can pack more servers into a datacenter.
  • Developed their own project management software that allows users to enter a summary of what they did this week and what they plan to do next week. Nothing special there except the software analyzes free-form text instead of forcing the user to enter text in a structured, less flexible way (e.g. an HTML forms application).

Wednesday, July 12, 2006

Recovering passwords from WebSphere

WebSphere stores passwords for datasources, security aliassss, etc in an encrypted format in its configuration files. The format, called XOR (exclusive OR), is not a particularly strong encryption algorithm, probably designed just to stop casual snooping. (In contrast WebLogic uses triple-DES encryption.)

(To be precise IBM says WebSphere "encodes" paswords, not encrypts them.)

When you forget that password to your development database it can be useful to have the ability to decrypt XOR-encrypted passwords. Fortunately IBM have provided the means to encrypt and decrypt passwords in XOR format (although they probably didn't mean to leave the code around for general use).

So lets encrypt the password "secret":

WebSphere 5.x

> ../java/bin/java -cp securityimpl.jar:iwsorb.jar secret
decoded password == "secret", encoded password == "{xor}LDo8LTor"

WebSphere 6.0.x

> ../java/bin/java -cp securityimpl.jar:iwsorb.jar::ras.jar:wsexception.jar:bootstrap.jar:emf.jar:ffdc.jar secret
decoded password == "secret", encoded password == "{xor}LDo8LTor"

and to decrypt (don't forget to prefix the encoded password with "{xor}"):

WebSphere 5.x

> ../java/bin/java -cp securityimpl.jar:iwsorb.jar {xor}LDo8LTor
encoded password == "{xor}LDo8LTor", decoded password == "secret"

WebSphere 6.0.x

> ../java/bin/java -cp securityimpl.jar:iwsorb.jar::ras.jar:wsexception.jar:bootstrap.jar:emf.jar:ffdc.jar {xor}LDo8LTor
encoded password == "{xor}LDo8LTor", decoded password == "secret"

UPDATE: IBM have heard the cries about poor password security and have added hooks from WebSphere 6.0.2 onwards that allow you to write your own password encryption. One step forward...

Sunday, July 09, 2006

Helping the homeless keep in touch

After hearing so much negative social news about the internet it is good to see a story about how the internet is helping some of the homeless to keep in touch with family and society.

Hidden costs of outsourcing

One of the more balanced articles on outsourcing I've seen, highlighting some of the hidden costs that companies often don't correctly factor into details. If you're going to outsource you need to invest in it long term (to service your needs you will need a vendor who truly understands your business, which is often not trivial) and you will need to set up a layer of management to co-ordinate with the outsourcing vendor for day-to-day activities (do I hear "Scrum Vendor Master"?).

Precisely half of companies rate their outsourcing efforts a success in InformationWeek Research's recent survey of 420 business IT pros. Yet, a third are neutral, and 17%--nearly one in six--call them disasters. That range should give pause to anyone looking to outsource IT or a business process for easy money. Companies also had better be prepared for the possibility of taking work back in-house, because it has become commonplace. Half of companies in our survey have done so, 23% on a major project...

Outsourcing carries a long-term, big-ticket financial commitment, so major deals need board-level scrutiny. Just like building a new factory, they can outlast the executives who broke ground...

Walking away from a deal early can cost a company dearly unless it can prove that the outsourcer was failing to live up to key terms in the contract...

The aftermath of a failed outsourcing agreement isn't limited to the financial impact. It can seriously damage a company's day-to-day operations...

Companies aren't shy about taking back work from outsourcers if a project gets off track. One-quarter of 25 large companies Deloitte Consulting surveyed last year had brought functions back in-house after realizing they could do the work themselves more successfully and at lower costs. Forty-four percent said outsourcing didn't save any money. Nearly half identified hidden costs as the most common problem when managing outsourcing projects. In InformationWeek's survey, poor service and lack of flexibility are cited most often for failures, by 45%, and 39% point to hidden costs. The Deloitte study concludes that companies embrace outsourcing to cut costs, simplify projects, and tap expertise not found in-house. But many find outsourcing actually introduces unexpected com- plexity, adds cost and friction, and requires more senior management attention and deeper management skills than anticipated...

Broad buy-in is vital but so is a single point of buck-stops-here accountability...

Increasingly, offshoring is just one more variable to manage, since so many projects have some overseas component. Cost cutting is the overwhelming reason companies look offshore. Companies also need to moderate their expectations when it comes to offshoring, warns Worldspan CIO Sue Powers. "It's like a bell curve," she says. "Some projects will go well and others will be difficult. Most are somewhere in the middle."...

Friday, July 07, 2006

Make those PDFs talk!

A groovy feature of Acrobat 7 (Reader and Professional) that I only discovered is the ability to "read out loud" documents (i.e. text-to-speech). To do this choose the View -> Read Out Loud menu option once you've opened the document in Acrobat. This works out of the box on Windows. If, on Linux, the Read Out Loud option is greyed out you will need to install text-to-speech software like Festival.