Vault

Great article on “How to Become an Early Riser” Part I and Part II. The best quote from the article is about the more general topic of self-discipline.

If you can’t get yourself out of bed when your alarm goes off, this is likely due to a lack of self-discipline. If you have enough self-discipline, you’ll get out of bed no matter what. Motivation can also help, but motivation is short lived and may only last a few days. Discipline is like a muscle. The more you build it, the more you can rely on it. Everyone has some discipline (can you hold your breath?), but not everyone develops it. There are a lot of ways to build discipline… But basically it comes down to taking on little challenges, conquering them, and gradually progressing to bigger ones. It’s like progressive weight training. As your self-discipline gets stronger, a challenge like getting out of bed at a certain time will eventually become trivially easy. But if your self-discipline has atrophied, it can seem an almost insurmountable hurdle.

I have previously discussed KDExecutor a automated unit test tool for scripted GUI application testing. Well, it seems that here is another tool that exists to do automated platform testing. Squish is a tool created by FrogLogic that supports all Qt platforms out-of-the-box. Squish seems to use Python scripts and costs betwen $150 and $800.

Just bookmarking an article that I intend to check out. It is suppost to cover codeing guidlines and how they can be used to reduce code faults.

Couple links to Desktop Search Tools:

• kio-clucene –A desktop search engine for KDE that uses clucene. The C++ version of Sun’s lucene engine.
• KAT –The basis of KDE 4′s Tenor project for contextual linkage engine. Already used in Mandriva and Kubuntu.

How to use OpenOffice’s database tool is a useful tutorial on setting up, using, and developing with Open Office 2.0 Access replacement.

I thought this article by Google’s Eric Schmidt and Hal Varian was really solid so I am linking to it and posting some of the more important parts of the article. Here is Google: Ten Golden Rules

By Eric Schmidt and Hal Varian
Newsweek
Updated: 11:33 a.m. ET Dec. 2, 2005

Issues 2006 – At google, we think business guru Peter Drucker well understood how to manage the new breed of “knowledge workers.” After all, Drucker invented the term in 1959. He says knowledge workers believe they are paid to be effective, not to work 9 to 5, and that smart businesses will “strip away everything that gets in their knowledge workers’ way.” Those that succeed will attract the best performers, securing “the single biggest factor for competitive advantage in the next 25 years.”

At Google, we seek that advantage. The ongoing debate about whether big corporations are mismanaging knowledge workers is one we take very seriously, because those who don’t get it right will be gone. We’ve drawn on good ideas we’ve seen elsewhere and come up with a few of our own. What follows are seven key principles we use to make knowledge workers most effective. As in most technology companies, many of our employees are engineers, so we will focus on that particular group, but many of the policies apply to all sorts of knowledge workers.

* Hire by committee. Virtually every person who interviews at Google talks to at least half-a-dozen interviewers, drawn from both management and potential colleagues. Everyone’s opinion counts, making the hiring process more fair and pushing standards higher. Yes, it takes longer, but we think it’s worth it. If you hire great people and involve them intensively in the hiring process, you’ll get more great people. We started building this positive feedback loop when the company was founded, and it has had a huge payoff.
* Cater to their every need. As Drucker says, the goal is to “strip away everything that gets in their way.” We provide a standard package of fringe benefits, but on top of that are first-class dining facilities, gyms, laundry rooms, massage rooms, haircuts, carwashes, dry cleaning, commuting buses—just about anything a hardworking engineer might want. Let’s face it: programmers want to program, they don’t want to do their laundry. So we make it easy for them to do both.
* Pack them in. Almost every project at Google is a team project, and teams have to communicate. The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. Of course, there are many conference rooms that people can use for detailed discussion so that they don’t disturb their office mates. Even the CEO shared an office at Google for several months after he arrived. Sitting next to a knowledgeable employee was an incredibly effective educational experience.
* Make coordination easy. Because all members of a team are within a few feet of one another, it is relatively easy to coordinate projects. In addition to physical proximity, each Googler e-mails a snippet once a week to his work group describing what he has done in the last week. This gives everyone an easy way to track what everyone else is up to, making it much easier to monitor progress and synchronize work flow.
* Eat your own dog food. Google workers use the company’s tools intensively. The most obvious tool is the Web, with an internal Web page for virtually every project and every task. They are all indexed and available to project participants on an as-needed basis. We also make extensive use of other information-management tools, some of which are eventually rolled out as products. For example, one of the reasons for Gmail’s success is that it was beta tested within the company for many months. The use of e-mail is critical within the organization, so Gmail had to be tuned to satisfy the needs of some of our most demanding customers—our knowledge workers.
* Encourage creativity. Google engineers can spend up to 20 percent of their time on a project of their choice. There is, of course, an approval process and some oversight, but basically we want to allow creative people to be creative. One of our not-so-secret weapons is our ideas mailing list: a companywide suggestion box where people can post ideas ranging from parking procedures to the next killer app. The software allows for everyone to comment on and rate ideas, permitting the best ideas to percolate to the top.
* Strive to reach consensus. Modern corporate mythology has the unique decision maker as hero. We adhere to the view that the “many are smarter than the few,” and solicit a broad base of views before reaching any decision. At Google, the role of the manager is that of an aggregator of viewpoints, not the dictator of decisions. Building a consensus sometimes takes longer, but always produces a more committed team and better decisions
* Don’t be evil. Much has been written about Google’s slogan, but we really try to live by it, particularly in the ranks of management. As in every organization, people are passionate about their views. But nobody throws chairs at Google, unlike management practices used at some other well-known technology companies. We foster to create an atmosphere of tolerance and respect, not a company full of yes men.
* Data drive decisions. At Google, almost every decision is based on quantitative analysis. We’ve built systems to manage information, not only on the Internet at large, but also internally. We have dozens of analysts who plow through the data, analyze performance metrics and plot trends to keep us as up to date as possible. We have a raft of online “dashboards” for every business we work in that provide up-to-the-minute snapshots of where we are.
* Communicate effectively. Every Friday we have an all-hands assembly with announcements, introductions and questions and answers. (Oh, yes, and some food and drink.) This allows management to stay in touch with what our knowledge workers are thinking and vice versa. Google has remarkably broad dissemination of information within the organization and remarkably few serious leaks. Contrary to what some might think, we believe it is the first fact that causes the second: a trusted work force is a loyal work force.

Of course, we’re not the only company that follows these practices. Many of them are common around Silicon Valley. And we recognize that our management techniques have to evolve as the company grows. There are several problems that we (and other companies like us) face.

One is “techno arrogance.” Engineers are competitive by nature and they have low tolerance for those who aren’t as driven or as knowledgeable as they are. But almost all engineering projects are team projects; having a smart but inflexible person on a team can be deadly. If we see a recommendation that says “smartest person I’ve ever known” combined with “I wouldn’t ever want to work with them again,” we decline to make them an offer. One reason for extensive peer interviews is to make sure that teams are enthused about the new team member. Many of our best people are terrific role models in terms of team building, and we want to keep it that way.

A related problem is the not-invented-here syndrome. A good engineer is always convinced that he can build a better system than the existing ones, leading to the refrain “Don’t buy it, build it.” Well, they may be right, but we have to focus on those projects with the biggest payoff. Sometimes this means going outside the company for products and services.

Another issue that we will face in the coming years is the maturation of the company, the industry and our work force. We, along with other firms in this industry, are in a rapid growth stage now, but that won’t go on forever. Some of our new workers are fresh out of college; others have families and extensive job experience. Their interests and needs are different. We need to provide benefits and a work environment that will be attractive to all ages.

A final issue is making sure that as Google grows, communication procedures keep pace with our increasing scale. The Friday meetings are great for the Mountain View team, but Google is now a global organization.

We have focused on managing creativity and innovation, but that’s not the only thing that matters at Google. We also have to manage day-to-day operations, and it’s not an easy task. We are building technology infrastructure that is dramatically larger, more complex and more demanding than anything that has been built in history. Those who plan, implement and maintain these systems, which are growing to meet a constantly rising set of demands, have to have strong incentives, too. At Google, operations are not just an afterthought: they are critical to the company’s success, and we want to have just as much effort and creativity in this domain as in new product development.

Schmidt is CEO of Google. Varian is a Berkeley professor and consultant with Google.

Shared specifications and shared standards are an admirable goal as long as the “standards” are not acting as limitations to the advancement of a given technology. This was the problem that KDE ran into with the use of Corba. It was a open and shared standard used by KDE (and Gnome) in its early development. But we quickly discovered that it became a nightmare to manage/extend to the more advanced uses that we wanted to see KDE move towards. The decision was made (and lots of “shared standard” developers SCREAMED about the change) to switch to a custom KDE specification now known as KParts. History has shown that decision to use KParts was the correct one, as KDE would NOT have progressed to the level it has using Corba.

As long as the standard is good for KDE development and advances our ability to provide application solutions to users (and developers) then I am all for shared standards. But the moment those standards hold back KDE development in the interest of some “perceived” value from shared specifications. We can all agree on standards up until those standards have the net result of holding-back all of our development efforts equally.

Think of specifications as food for software. Good standards will help you (or your software project) grow strong and healthy. Bad standards will make your application bloated, lethargic, and will eventually be the cause of most of your application “sickness.” Standards are NOT more important than the applications (arguably they are part of the application, but a part is seldom more important than the whole.) Because they are NOT more important than the applications themselves, comments like this verge on being insulting.

The fact that KDE gets appreciated this much and that KDE is the market leader in UNIX and Linux desktops today is negligible compared to the extremely important effort to create a single specification of the free desktop environment.

Also, I think too many people get shared specifications confused with open specifications. KDE (and Gnome for that matter) will ALWAYS have open specifications because of the very nature of F/OSS. Open standards are very very important, shared standards are less important. One could argue that Microsoft DOC format is a shared standard because just about every office package in existence tries to write and save to it. That doesn’t make it an open standard.

All about Linux: 10 Things that make Ubuntu a Neophyte’s Distribution is a quick article about some of the things that make Ubuntu easy to use. Most of these things are already available on KDE centric distrobutions but the list is useful from a reference standpoint.

Here is a link to the U.S. SBA. Just in case anyone wants to start a small business.

This post pointed me to a tool that I have always wanted without ever knowing it. ccache is a C/C++ compiler cache. It is used to produce code from already compiled sources that have not changed. Its particularly useful for package building environments where package directives change often but the source code doesn’t.

Risk qualifies as one of my all time favorite board games. Well now I can play Risk via Google Maps. This really shows off the flexibility of Google’s API and what is possible when a company makes that kind of power openly available.

I generally don’t get too excited about optical illusions; but this is one very cool illusion. If you follow the rotating pink dot you will only see pink. If you look at the “+” in the center you will see a green dot. Stare at the “+” long enough and you will only see the green dot.

If you are interested in this kind of thing here is a site listing 60 common optical illusions.

I overheard a discussion on NPR the other day that exemplified something that I have been thinking about. The discussion was a panel debate on last weeks news. The conversation inevitably centered around the war in Iraq and the current public opinion about the war.

A caller to the radio show (actually I think it was an email submission) made an articulate remark about the failure of the media to accurately report the successes the U.S. has had in Iraq. When the panel responded; they admitted that many military personal in Iraq make the exact same comment to them. Each of the panel members was a reporter of some type (the question of why expert panels are always filled with reporters and professors is left for another day) and as such each of them had heard this complaint a number of times in the past.

Then one panelist responded with the counter-point that “The problem is that I often hear the exact opposite remark; that if we (as reporters) had been more critical of the president when he made the case for war, we might not have ever gotten into Iraq.”

The problem with that statement is that its not the exact opposite remark (the opposite stance would be that the media doesn’t report enough about the current violence in Iraq.) In fact the two positions can actually be explained in relation to one another. Let me explain. I believe, in some cases, people tend to “compensate” for their mistakes by making up for the short coming. Something of an enforced karma. It’s similar to when a baseball umpire makes a really bad call, realizes it as such, and then “compensates” for it by giving his next call to the infringed upon player/team; regardless of what the correct call should have been.

In some ways I think the media is trying to compensate for their own perceived failure to critically report on the argument for the war. The way they are “balancing” things out is by being overly critical of the success of the rebuilding effort. I don’t necessarily believe this umpire effect is intentional; but the evidence for it is pretty strong. While there is no doubt that the insurgency in Iraq is getting stronger, by almost any other measure things are getting much better there. Public projects are at an all time high, as is the number of completed project. Political involvement has steadily increased, oil revenue is up, the majority of law enforcement work is being done by Iraqis now, and GDP is steadily on the rise. What is more, the vast majority of Iraqis don’t want the U.S. to leave yet and think they are better off now then they were under Saddam (even if the really don’t like us.)

Because of the pathological nationalism that was rampant post 9/11 the media felt reluctant to criticize the President. Now that the President is unpopular it is much easier to be critical of him and the war he started. I guess that is really the point of this observation. More than I would like to believe the media is not simply a distributor of information but a reflection of our own prejudices. The umpire effect exists in the media (I have noticed it in a least a couple of other non-national news stories) because it exists among us. It is a way to make life (and baseball) a little more fair; as least from our point of view.

Two articles from The American Enterprise discussing the slow decline of U.S. and European ties and how they relate to the differences in our economies. The first article (Europe’s Not Working) covers the failure of European style socio-progressive economic model. The second article (Europe Learns the Wrong Lessons) covers the failure of Europe to accurately identify the solution to their current economic crisis.

In addition to pointing out some of the serious flaws in continental European democracy, the articles are especially interesting in their analysis of Europe’s reaction to such failure. Iraq is not the only reason for Europe to feel frustrated with the U.S. While many of us in the states are continually led to believe (mostly from institutional academia) that our form of capitalism and democracy is inferior in every way to the European model; the reality is quite different. Europe’s excessive social progressivism has lead to a standard of living some 40% below U.S. levels and unemployment rates in the double digits.

While the problem is easily identifiable to those who are on the outside of the European economic socialist mind-set; it requires a paradigm sift for those who are comfortable with the welfare state. The solution is as straightforward; implement a more American/Asian model capitalist environment. Dozens of successful examples exist (Ireland being the closes to home for Europe.) Unfortunately, Europe seems dead-set on continuing down the failed course it has begun; at least for the foreseeable future.

brought to you by Quizilla

Funny, with my inseam I would have figured I was a Dwarf. Possibly even a Hobbit.

According to The Elvish Name Generator my Elvish name is:

Eöl Nólatári

Berry Rubin (via the U.S. foreign service website AmericanDiplomacy.org) has an article about the ideological influence of extreme Islam and its failure to provide tangible results to improving the Arab situation in the Middle East. While some people may consider this victim blaming, the reality is that the Arab response has done a great deal to perpetuate the status quo. The article doesn’t provide a solution to the problems of the middle east but it does enable a framework for better understanding the problem.

The Guardian is running a list of the Top 20 geek novels of the past 100 years (or so.) The HitchHiker’s Guide to the Galaxy places number one with multiple entries for Neal Stephenson and Isaac Asimov. The Lord of the Rings trilogy was not on the list. Probably because, as one responder put it:

I think that (the LOTR trilogy) comes under the category ‘Geek Bible’.

Thanks to Jason I have discovered the wonderful world of Urban Dead is a massively multi-player web-based zombie apocalypse game. Create a character (human or zombie) and start to do battle with others online for control of the city. No flash, ActiveX, or Java required. Currently I have two characters; brockers and S1ider but I think one of them will become a Zombie pretty soon based on the fact that I left him sitting outside on the street because I didn’t entirely understand the daily usage limits.

Urban Dead also pointed me to another (admittedly less advanced) web-based MMPOG called Vampires! The Dark Alleyway. brockers can also be found in Vampires.

I have been doing an overhaul of our CVS tools infrastructure and in the process added some very nice NEW functionality. Here are some links to a couple of the more interesting tools for CVS tracking, management, review, and statistics.

• ViewCVS- The standard in CVS web viewing. Supports diff viewing, visual history layouts, Bugzilla support, and color code previews. Its only real downside is that its a python application. Version 2 will be out any-time-now.
• CVS Web- The original cvs online code viewer. CVSView was originally a python port of this Perl application. Visually it is more flexible (by default) than viewcvs 1.x series.
• Bonsai-Mozilla foundation CVS code viewer. They have not released a packaged version as of yet.
• Cvstat-Perl script that generates some general statistics about a given CVS project. Its biggest weakness is that is can only be run against a given project and now the entire CVS repository.
• CVS Monitor- One damn fine project tracking and project monitoring tool. Includes graphs of file and line activity, web administration, and change-set tracking.
• Codestriker- Code auditing and review tool. Allows reviews to make line by line comments of projects directly against CVS. Sub-projects can be created to review specific feature proposals. Includes file viewing (via viewcvs or webcvs), color code (via LXR), diff creation, package/file download access, life-cycle management tools, and integrated support for Bugzilla.
• Bloof-Java based CVS metric tool. Provides interface for analytical processing of version control data. Its capable of providing an amazing number of reports based on hundreds of criteria.

Via this link, I found a VERY useful command that I was not aware of for CVS. Basically it creates a distribution ready package from a given CVS tag (i.e. removes the CVS directories, attic files, and file changes betwen current and the tag.)

user@localhost$ cvs export -r foo-1_0 -d foo-1.0 foo
user@localhost$ tar czf foo-1.0.tar.gz foo-1.0

The first command is the interesting one (the second command simply makes your tar.gz package.) The command is run after you have correctly done a cvs login.