Songbird™ is a desktop Web player, a digital jukebox and Web browser mash-up. Like Winamp, it supports extensions and skins feathers. Like Firefox®, it is built from Mozilla®, cross-platform and open source.
http://www.songbirdnest.com
Donnerstag, Juli 26, 2007
Web Design from Scratch
Web Design from Scratch is for everyone involved or interested in creating web sites - whether novice or expert. It will help you understand what makes web sites succeed or fail, and what can be done to increase the chance of success.
http://www.webdesignfromscratch.com/
http://www.webdesignfromscratch.com/
Mittwoch, Juli 25, 2007
Note on Java complexity
The problem is that much of the Java stuff out there is just written by really smart morons who seem to love complexity for complexity's sake. Even in the API itself! Ever used the Calendar API? It's written by a monkey. Ever check out the code under the JSTL? Those guys have to be on crack. It's not the language itself that causes these problems, it's the culture around the language. When programmers respect patterns more than solutions, you know something is broken.
Complexity leads to disaster. Your application should be built around simple constructs and understandable layers, which combine to perform complex tasks. The code itself, however, should avoid complexity at every stage. This is much easier to say than to do, though, since many programmers are afraid of missing important pieces, or of oversimplifying.
- Justin Gehtland
Java Complexity is your enimiy
Complexity leads to disaster. Your application should be built around simple constructs and understandable layers, which combine to perform complex tasks. The code itself, however, should avoid complexity at every stage. This is much easier to say than to do, though, since many programmers are afraid of missing important pieces, or of oversimplifying.
- Justin Gehtland
Java Complexity is your enimiy
Donnerstag, Juli 19, 2007
What motivates programmers
As found on http://blog.assembleron.com/2007/07/11/what-motivates-programmers/
What motivates programmers?
11. July 2007, 10:33Nick Halstead
computer user
I will start with a question, if you have a spare £400 in your development budget do you A) Reward your star programmer with a £400 bonus or B) Buy him a 24 Inch 1920×1200 LCD screen?
If you answered ‘A’ then you need to read on. If you answered ‘B’ then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.
One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.
Tim Bryce writes:
“Regardless of the image they wish to project, the average programmer does not have a higher IQ than any other worker with a college degree. In fact, they may even be lower.”
This article is worth reading just to get a view of someone who does not understand programmers at all. And should certainly not be attempting to write about how to manage them with views like the above.
The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.
This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be … nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.
What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.
You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to ‘who gets what’.
Hardware Cascade
Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the ‘non-existent’ programmer hierarchy.
So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)
The appeal of solving a problem
Programmers program because they love to solve problems.
Remember this rule:
“If you give a programmer a job that does not involve solving something they will become unhappy.”
Solving can mean many things and it is easier (and more important) to understand what classes as a ‘non-solving’ task. Typically asking a programmer to go fix something would be classed as ‘non-solving’ as the solution has already been found and you are asking them to re-solve it by having to look at the code again.
What is important is that you find ways of making ‘non-solving’ tasks into ’solving’ tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can ’solve’ something and produce an automated system that will email you the report every day/week/month.
Other typical non-solving situations
* Writing documentation
* Creating schedules
* Writing reports
* 1st Line Support
All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher ‘non-solving’ ratio of tasks than others. Understanding your programmers and who can cope with what level of ‘non-solving’ is important to keeping an overall smooth operation.
Micro Managing
God help you if you try this tactic. My above statement about ’solving’ is at the very heart of why you cannot attempt to micro manage your programming team. Any attempt on your part to perform solving yourself means they are not solving. And even worse your are questioning their abilities to ’solve’ things which just about amounts to the worst thing you can do to a programmer.
In any crisis situation your programmers are likely to be in more of a frenzied state than you are and in nearly all cases your first reaction of helping is the wrong one. The hard part here is that you need to give the impression that you have the utmost confidence in their abilities (do not try and directly tell them this they will take it the wrong way) and that you can leave it to them to solve. And at the same time still be in touch with the direction they are taking to ensure that the crisis is resolved.
Meetings
Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is ‘unhappy time’ and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.
There are lots of other areas I could cover (and maybe will in another post) but just remember that a happy programmer is a productive programmer.
managing motivate motivation
What motivates programmers?
11. July 2007, 10:33Nick Halstead
computer user
I will start with a question, if you have a spare £400 in your development budget do you A) Reward your star programmer with a £400 bonus or B) Buy him a 24 Inch 1920×1200 LCD screen?
If you answered ‘A’ then you need to read on. If you answered ‘B’ then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.
One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.
Tim Bryce writes:
“Regardless of the image they wish to project, the average programmer does not have a higher IQ than any other worker with a college degree. In fact, they may even be lower.”
This article is worth reading just to get a view of someone who does not understand programmers at all. And should certainly not be attempting to write about how to manage them with views like the above.
The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.
This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be … nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.
What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.
You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to ‘who gets what’.
Hardware Cascade
Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the ‘non-existent’ programmer hierarchy.
So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)
The appeal of solving a problem
Programmers program because they love to solve problems.
Remember this rule:
“If you give a programmer a job that does not involve solving something they will become unhappy.”
Solving can mean many things and it is easier (and more important) to understand what classes as a ‘non-solving’ task. Typically asking a programmer to go fix something would be classed as ‘non-solving’ as the solution has already been found and you are asking them to re-solve it by having to look at the code again.
What is important is that you find ways of making ‘non-solving’ tasks into ’solving’ tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can ’solve’ something and produce an automated system that will email you the report every day/week/month.
Other typical non-solving situations
* Writing documentation
* Creating schedules
* Writing reports
* 1st Line Support
All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher ‘non-solving’ ratio of tasks than others. Understanding your programmers and who can cope with what level of ‘non-solving’ is important to keeping an overall smooth operation.
Micro Managing
God help you if you try this tactic. My above statement about ’solving’ is at the very heart of why you cannot attempt to micro manage your programming team. Any attempt on your part to perform solving yourself means they are not solving. And even worse your are questioning their abilities to ’solve’ things which just about amounts to the worst thing you can do to a programmer.
In any crisis situation your programmers are likely to be in more of a frenzied state than you are and in nearly all cases your first reaction of helping is the wrong one. The hard part here is that you need to give the impression that you have the utmost confidence in their abilities (do not try and directly tell them this they will take it the wrong way) and that you can leave it to them to solve. And at the same time still be in touch with the direction they are taking to ensure that the crisis is resolved.
Meetings
Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is ‘unhappy time’ and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.
There are lots of other areas I could cover (and maybe will in another post) but just remember that a happy programmer is a productive programmer.
managing motivate motivation
No end in sight
Movie Website / Trailer
The first film of its kind to chronicle the reasons behind Iraq’s descent into guerilla war, warlord rule, criminality and anarchy, NO END IN SIGHT is a jaw-dropping, insider’s tale of wholesale incompetence, recklessness and venality. Based on over 200 hours of footage, the film provides a candid retelling of the events following the fall of Baghdad in 2003 by high ranking officials such as former Deputy Secretary of State Richard Armitage, Ambassador Barbara Bodine (in charge of Baghdad during the Spring of 2003), Lawrence Wilkerson, former Chief of Staff to Colin Powell, and General Jay Garner (in charge of the occupation of Iraq through May 2003) as well as Iraqi civilians, American soldiers, and prominent analysts. NO END IN SIGHT examines the manner in which the principal errors of U.S. policy – the use of insufficient troop levels, allowing the looting of Baghdad, the purging of professionals from the Iraqi government, and the disbanding of the Iraqi military – largely created the insurgency and chaos that engulf Iraq today. How did a group of men with little or no military experience, knowledge of the Arab world or personal experience in Iraq come to make such flagrantly debilitating decisions? NO END IN SIGHT dissects the people, issues and facts behind the Bush Administration’s decisions and their consequences on the ground to provide a powerful look into how arrogance and ignorance turned a military victory into a seemingly endless and deepening nightmare of a war.
The first film of its kind to chronicle the reasons behind Iraq’s descent into guerilla war, warlord rule, criminality and anarchy, NO END IN SIGHT is a jaw-dropping, insider’s tale of wholesale incompetence, recklessness and venality. Based on over 200 hours of footage, the film provides a candid retelling of the events following the fall of Baghdad in 2003 by high ranking officials such as former Deputy Secretary of State Richard Armitage, Ambassador Barbara Bodine (in charge of Baghdad during the Spring of 2003), Lawrence Wilkerson, former Chief of Staff to Colin Powell, and General Jay Garner (in charge of the occupation of Iraq through May 2003) as well as Iraqi civilians, American soldiers, and prominent analysts. NO END IN SIGHT examines the manner in which the principal errors of U.S. policy – the use of insufficient troop levels, allowing the looting of Baghdad, the purging of professionals from the Iraqi government, and the disbanding of the Iraqi military – largely created the insurgency and chaos that engulf Iraq today. How did a group of men with little or no military experience, knowledge of the Arab world or personal experience in Iraq come to make such flagrantly debilitating decisions? NO END IN SIGHT dissects the people, issues and facts behind the Bush Administration’s decisions and their consequences on the ground to provide a powerful look into how arrogance and ignorance turned a military victory into a seemingly endless and deepening nightmare of a war.
Mittwoch, Juli 18, 2007
100 Open Source Downloads
No, it’s not the “Top 100,” nor does this list contain the “only” 100 open source downloads you should consider – there’s a big ocean out there, so please keep swimming.
http://itmanagement.earthweb.com/osrc/article.php/3689281
http://itmanagement.earthweb.com/osrc/article.php/3689281
10 Articles All Bloggers Should Read (at least once)
Bloggen will gelernt sein. Und die meisten machen das wohl besser als ich, da mein Blog ja größtenteils eine bessere Bookmarksammlung ist. ;)
Für alle, die das Bloggen wirklich Ernst nehmen, empfiehlt sich daher das Lesen des folgenden Artikels:
10 Articles All Bloggers Should Read (at least once)
Für alle, die das Bloggen wirklich Ernst nehmen, empfiehlt sich daher das Lesen des folgenden Artikels:
10 Articles All Bloggers Should Read (at least once)
How to Handle Thousands of Users with Your Blog
Nicht alle bloggen bei Google oder Twoday.net. Viele hosten ihr Blog privat.
If you are running a blog and you have your own server, here are a few tips to easily handle at least half a million hits per day.
How to Handle Thousands of Users with Your Blog
If you are running a blog and you have your own server, here are a few tips to easily handle at least half a million hits per day.
How to Handle Thousands of Users with Your Blog
Freitag, Juli 06, 2007
Abonnieren
Kommentare (Atom)