Jeg kom tilfeldigvis over denne engelske bloggen, som også kommer i internasjonalisert utgave: http://blog.taragana.com/index.php/archive/java-ee-6-highlights/no/
Og hva kan man si. Her er det flust av gullkorn. Skulle ønske Sun kom med en norsk utgave av Java EE 6.
The key features of Java EE 6
= Nøkkelen vise egenskaper av Java EE 6
RESTful web services
= Hvile web tjenestene
Annotations across Web API
= Merknader vannrett Web API
Mobile developers
= transportabel utviklerne
Scripting languages
= Skriften språkene
Manual editing of web.xml
= håndbok redigere bort av web.xml
Og andre mer anvendelige oversettelser:
Submit tips
= Underkaste seg drikkepenger
Albert Einstein
= Enskjønt Einstein
mandag 17. august 2009
onsdag 12. august 2009
Blog blah blah
I just can't enought of them interesting blogs to read. And none of those publish exclusively interesting content. I find myself skimming titles to decide what posts to read.
So I got this idea: Combine Delicious and the blogsphere, and let me subscribe to tags or semantics or even something from a dewey-style categorisation of the world. Let me decide that I want all blog posts concering acquisitions of OSS companies by enterprise organisations. And let something, somewhere handle where to find those blogs, how to rate them, decide what to present to me.
Sort of like when people tweet about their blog postings.
So I got this idea: Combine Delicious and the blogsphere, and let me subscribe to tags or semantics or even something from a dewey-style categorisation of the world. Let me decide that I want all blog posts concering acquisitions of OSS companies by enterprise organisations. And let something, somewhere handle where to find those blogs, how to rate them, decide what to present to me.
Sort of like when people tweet about their blog postings.
tirsdag 11. august 2009
Spoils of Peopleware
So,
I read this black bible of technology workers satisfaction. Or perhaps programmers satisfaction. Or perhaps even skilled programmers satisfaction. It is said that this book should be kept secret from any management spy which happen to hoover over your desk. This because it is said to contain revolutionary ideas and truths about productivity, contrary to management theory and practice. So what is it all about?
Projects are failing to meet deadlines, to implement the specifications, to specify what the costumer really needs. The book claim that there are often no technological issues to explain this, but rather political and sosiological issues.
"Development is different from production". It's not a process that can be tuned and kept in a steady state, but instead a dynamic organism that should be nourished and kept happy. It's about creating value through ingenuity, not by running the motor at full throttle. One hour of overtime (at which you seldom can work at 100%) may cost an hour of undertime (where you recover and clean up after last nights desperate moves). Deadlines are not always absolute. Sometimes it's acceptable and even sensible to delay a deadline to fulfill quality requirements. I wish we could have both. "Quality is free, but only to those who are willing to pay heavily for it".
Then there's this part about the office environment. Cubicles and uniform environments are strongly discouraged. As opposed to factory workers, programmers are said to be intellect workers, and there are different rules that make them perform better. Cramped and noisy quarters can be a killer to productivity. Personalization enhances smartness. Interruptions steals a whole lot more of time than their duration, due to interruption of flow. You need at least 20 uninterrupted minutes to start working efficiently, and you need at least one hour to produce efficient results. Thus, behold of the E-factor: uninterrupted hours per working hours. Try measuring them by yourself. It's suggested that your will achieve a factor between 0.1 and 0.4. The number alone tells no story, but try to calculate it prior to and after a change, like moving to another office space, tearing down the office walls, putting up walls, switching offices and so on.
The right people is another keyword. A short formula for success: get the right people, make them happy so they won't leave, turn them loose.
The first clause is about hiring. Have an audition. Make the candidated program. Accept those that your collegues think highly of. Measure the cost of turnover. It can easily be as much as 5 months of lost work. Consider them people instead of workers. Most people leave because 1) they're just passing by, 2) they are feeling disposable or 3) they are not loyal because they are being threated as workers.
It's all about putting a kick-ass team together. There's this concept called jelling, which is rather difficult to quantify. It happens when people are professionally happy with each other, they feel identity and ownership and eliteness. Don't change a winning team. Spend some money on jelling acitivties, like teambuilding. A few hundred hours can easily be spent, or what?
So, this was a quick and superficial summary of the epic. Mostly written down to serve as my own mindmap for remembering things. Everything favors the developer, and I guess any manager would have loads of counter arguments to any of the claims. I agree with the majority of claims, and then I guess the rest is not applicable to my situation. It seems as if the paradise of developers is a small company owned by the developers themselves. Growth implies overhead, and the overhead eats up the advantage.
But then there's some advantages of working in a production environment as well. Your schedule is predictable. Your hours are predictable.
Your duties are predictable. Your requred skills are predictable. And then sometimes they're not, but then it's no longer a stable and optimised production process, is it?
I read this black bible of technology workers satisfaction. Or perhaps programmers satisfaction. Or perhaps even skilled programmers satisfaction. It is said that this book should be kept secret from any management spy which happen to hoover over your desk. This because it is said to contain revolutionary ideas and truths about productivity, contrary to management theory and practice. So what is it all about?
Projects are failing to meet deadlines, to implement the specifications, to specify what the costumer really needs. The book claim that there are often no technological issues to explain this, but rather political and sosiological issues.
"Development is different from production". It's not a process that can be tuned and kept in a steady state, but instead a dynamic organism that should be nourished and kept happy. It's about creating value through ingenuity, not by running the motor at full throttle. One hour of overtime (at which you seldom can work at 100%) may cost an hour of undertime (where you recover and clean up after last nights desperate moves). Deadlines are not always absolute. Sometimes it's acceptable and even sensible to delay a deadline to fulfill quality requirements. I wish we could have both. "Quality is free, but only to those who are willing to pay heavily for it".
Then there's this part about the office environment. Cubicles and uniform environments are strongly discouraged. As opposed to factory workers, programmers are said to be intellect workers, and there are different rules that make them perform better. Cramped and noisy quarters can be a killer to productivity. Personalization enhances smartness. Interruptions steals a whole lot more of time than their duration, due to interruption of flow. You need at least 20 uninterrupted minutes to start working efficiently, and you need at least one hour to produce efficient results. Thus, behold of the E-factor: uninterrupted hours per working hours. Try measuring them by yourself. It's suggested that your will achieve a factor between 0.1 and 0.4. The number alone tells no story, but try to calculate it prior to and after a change, like moving to another office space, tearing down the office walls, putting up walls, switching offices and so on.
The right people is another keyword. A short formula for success: get the right people, make them happy so they won't leave, turn them loose.
The first clause is about hiring. Have an audition. Make the candidated program. Accept those that your collegues think highly of. Measure the cost of turnover. It can easily be as much as 5 months of lost work. Consider them people instead of workers. Most people leave because 1) they're just passing by, 2) they are feeling disposable or 3) they are not loyal because they are being threated as workers.
It's all about putting a kick-ass team together. There's this concept called jelling, which is rather difficult to quantify. It happens when people are professionally happy with each other, they feel identity and ownership and eliteness. Don't change a winning team. Spend some money on jelling acitivties, like teambuilding. A few hundred hours can easily be spent, or what?
So, this was a quick and superficial summary of the epic. Mostly written down to serve as my own mindmap for remembering things. Everything favors the developer, and I guess any manager would have loads of counter arguments to any of the claims. I agree with the majority of claims, and then I guess the rest is not applicable to my situation. It seems as if the paradise of developers is a small company owned by the developers themselves. Growth implies overhead, and the overhead eats up the advantage.
But then there's some advantages of working in a production environment as well. Your schedule is predictable. Your hours are predictable.
Your duties are predictable. Your requred skills are predictable. And then sometimes they're not, but then it's no longer a stable and optimised production process, is it?
lørdag 8. august 2009
Installing Debian on EEE 901
For some reason, my Asus 3e 901 decided to freeze during boot. No magic would heal the system, so I booted into a live distro, salvaged the content of my home directory, and decided to offer myself a brand new debian installation.
For once, I didn't have a linux machine to help me. That caused some trouble, but I was able to get windows utilities to perform the same tasks as dd.
Struggled a while with booting the 3e from a usb device. I figured out that you should enter bios (f2 during boot), and enable removable device as primary boot medium, and turn off silent boot and quick boot. It might also be a good ide to set the bios in "install os" mode.
Save, reboot. Then hit ESC while booting to get a boot menu, and select USB.
The installer was able to detect both ethernet and wireless NICs. I was able to retrieve the base system as a charm. Promising. I got some hints out of http://wiki.debian.org/DebianEeePC/HowTo/Install
Then boot. Remember to revert the bios settings - at least set os install mode to "installed".
For once, I didn't have a linux machine to help me. That caused some trouble, but I was able to get windows utilities to perform the same tasks as dd.
I decided to use the eee community edition of debian. It is available at http://eeepc.debian.net/debian/images/debian-eeepc.img. Used HP usb disk storage tool to format a pendrive and flashnul to write the image to the device.
Struggled a while with booting the 3e from a usb device. I figured out that you should enter bios (f2 during boot), and enable removable device as primary boot medium, and turn off silent boot and quick boot. It might also be a good ide to set the bios in "install os" mode.
Save, reboot. Then hit ESC while booting to get a boot menu, and select USB.
The installer was able to detect both ethernet and wireless NICs. I was able to retrieve the base system as a charm. Promising. I got some hints out of http://wiki.debian.org/DebianEeePC/HowTo/Install
Then boot. Remember to revert the bios settings - at least set os install mode to "installed".
After boot, I installed those xorg packages suggested by the debianeee howto, and then fluxbox with dependencies. And behold, Xorg started without a glitch. Amazing. Nothing like those old days of xorg.conf hacking, hsync, vsync yadda yadda.
apt-get install bliss
Abonner på:
Innlegg (Atom)