Yesterday, I set up a blog for our internal development team to use as a project tool. We'll use it to capture knowledge that would otherwise be lost in individual emails and cube conversations.
I looked at a number of blog platforms, but I was able to narrow the field quickly based on my criteria:
First, it had to be free, and under active development - I want support, but I don't have a budget to pay for it, and I'm willing to give back where I can with bug reports and such.
Second, I wanted a pure Java blog tool. As a developer who works primarily in Java, I wanted something that I can rip apart and understand without too much frustration.
Third, I needed a tool that allowed multiple users to post to one blog. This cut out one of the big contenders, Roller Weblogger. I've been looking at Roller for some time, but I couldn't find enough information on its capability for multiple users to post to a single blog.
I finally settled on Blojsom. One of Blojsom's big selling points is that it uses the file system to store blog entries. ("Look Ma! No database!") This is an idea Erik Hatcher sold me on a couple of years ago. A quick install and I was blogging in just a few minutes.
Blojsom is a decent blog platform. Setting up users is easy, and it comes with a number of good templates out of the box.
I believe Blojsom's weakness comes from its flexibility - it uses an event driven plug-in model, which allows limitless extensibility. I don't really need a lot of flexibility, I just need something that's easy to configure. Having said that, I find Blojsom's admin console in need of some design help. It's just not terribly intuitive, and doesn't leverage existing, accepted UI practices. All the options you need are there, it's just a matter of figuring out how to use them. This goes for the Blojsom web site as well - all the info you need is at your fingertips, somewhere.
As for support, I did run into a configuration problem with blog comments, but David Czarnecki responded to my request on the user list within minutes with a fix for me.
So, despite the admin console, Blojsom meets all my needs quite nicely - free, good support, java, multiple users. I'm also going to spend the obligatory 10 minutes on Pebble, if for no other reason than the website screams simplicity, but I'm more than happy with Blojsom.
Only time will tell if the team accepts blogging as a communication medium.
Al Issa's Blog
Friday, February 18, 2005
Thursday, February 17, 2005
Great Developers, Bad Managers
While reading a post on Mini-Microsoft, I was reminded of the boundless hope found in so many technical managers: if we promote a great developer to a management or lead role, he/she should succeed and become a great manager in addition to being a great developer. After all, they're already really good at being technical.
This hope is no more than a dream, and for me, the dream has become a nightmare. My current manager (I'll call him Ted), while a very good technical talent, has little to no managment skill. It's hardly Ted's fault; he's been set up for failure by his manager - who, you might guess, shows little or no management competence himself. And this problem is certainly not isolated to my employer. Stories of poor technical managers, raised up from the ranks of wee developers, abound.
Alas, it is the wee developers in the trenches who pay the price: outrageous demands on our time, poorly formed requirements, and dreadful communication. All of which culminates in stressed developers; stressed developers generate poorly written and documented code, missed deadlines, and a great deal of bitterness about generally everything.
So, I sat idly by for months as my manager failed to manage. Then, gradually, I began letting Ted know just how bad he was at it. My latest attempt came in the form of an intervention. I simply told him outright just how poor a job he was doing. To my surprise, he agreed. And he promised to make an effort to change. "Good luck turning those stripes into spots," I thought to myself. But, until I quit or go mad, it's my job to support Ted as he attempts to make himself into something he's not.
The hardest part for me is being a developer after having led a team. Once you've been the lead dog (and a good lead dog, at that), it's hard to be moved back to being a team dog.
This hope is no more than a dream, and for me, the dream has become a nightmare. My current manager (I'll call him Ted), while a very good technical talent, has little to no managment skill. It's hardly Ted's fault; he's been set up for failure by his manager - who, you might guess, shows little or no management competence himself. And this problem is certainly not isolated to my employer. Stories of poor technical managers, raised up from the ranks of wee developers, abound.
Alas, it is the wee developers in the trenches who pay the price: outrageous demands on our time, poorly formed requirements, and dreadful communication. All of which culminates in stressed developers; stressed developers generate poorly written and documented code, missed deadlines, and a great deal of bitterness about generally everything.
So, I sat idly by for months as my manager failed to manage. Then, gradually, I began letting Ted know just how bad he was at it. My latest attempt came in the form of an intervention. I simply told him outright just how poor a job he was doing. To my surprise, he agreed. And he promised to make an effort to change. "Good luck turning those stripes into spots," I thought to myself. But, until I quit or go mad, it's my job to support Ted as he attempts to make himself into something he's not.
The hardest part for me is being a developer after having led a team. Once you've been the lead dog (and a good lead dog, at that), it's hard to be moved back to being a team dog.
Wednesday, February 16, 2005
Learn to live with Software Patents
Interesting quote from HPs top Linux Exec:
"'Refusing to patent one's ideas is leaving oneself exposed for absolutely no good reason,' Fink said. 'For some, (getting patents) may seem like selling out. You can comfort yourself that it's what you do with the patent that matters, not the fact that you have one.'"
This makes sense to me. Software patents are here to stay. In many cases, the intellectual property is more valuable than the tangible assets of a company itself (via Salon):
"...What made this fire sale different from most, though, was the power of a single set of assets -- Commerce One's Web services patent portfolio. In a relatively rare decision, the bankruptcy court decided to separate the sale of these patents from the sale of the rest of the company, thereby allowing a separate bidding process to take place exclusively for the patent portfolio.
This decision drew significant attention from the patent community, including companies such as Intellectual Ventures and ThinkFire Inc. that persist solely on the acquisition, licensing and litigation of patents. With these new bidders in the game, the auction became highly competitive, eventually ending with a bid from the mysterious "JGR Acquisitions" for $15.5 million. (The rest of the business was sold for a mere $4.1 million.)..."
"...When faced with two choices -- selling a company's patents as part of its overall assets or selling the patents alone -- the court (and the market) chose the latter. This means that in the eyes of the legal system and the marketplace, the Commerce One patents were more valuable to independent licensing firms as legal threats than they were to an actual company that makes a Web services product."
Although I disagree with the Salon's conclusions, it seems that software patents are here to stay and are quickly becoming more valuable than the software itself.
"'Refusing to patent one's ideas is leaving oneself exposed for absolutely no good reason,' Fink said. 'For some, (getting patents) may seem like selling out. You can comfort yourself that it's what you do with the patent that matters, not the fact that you have one.'"
This makes sense to me. Software patents are here to stay. In many cases, the intellectual property is more valuable than the tangible assets of a company itself (via Salon):
"...What made this fire sale different from most, though, was the power of a single set of assets -- Commerce One's Web services patent portfolio. In a relatively rare decision, the bankruptcy court decided to separate the sale of these patents from the sale of the rest of the company, thereby allowing a separate bidding process to take place exclusively for the patent portfolio.
This decision drew significant attention from the patent community, including companies such as Intellectual Ventures and ThinkFire Inc. that persist solely on the acquisition, licensing and litigation of patents. With these new bidders in the game, the auction became highly competitive, eventually ending with a bid from the mysterious "JGR Acquisitions" for $15.5 million. (The rest of the business was sold for a mere $4.1 million.)..."
"...When faced with two choices -- selling a company's patents as part of its overall assets or selling the patents alone -- the court (and the market) chose the latter. This means that in the eyes of the legal system and the marketplace, the Commerce One patents were more valuable to independent licensing firms as legal threats than they were to an actual company that makes a Web services product."
Although I disagree with the Salon's conclusions, it seems that software patents are here to stay and are quickly becoming more valuable than the software itself.
Tuesday, February 15, 2005
Programming your body
Well, here is a fellow with too much time on his hands. Where's the API?
Inventor preserves self :
"As part of his daily routine, Kurzweil ingests 250 supplements, eight to 10 glasses of alkaline water and 10 cups of green tea. He also periodically tracks 40 to 50 fitness indicators, down to his 'tactile sensitivity.' Adjustments are made as needed.
'I do actually fine-tune my programming,' he said.
The inventor and computer scientist is serious about his health because if it fails him he might not live long enough to see humanity achieve immortality, a seismic development he predicts in his new book is no more than 20 years away."
Inventor preserves self :
"As part of his daily routine, Kurzweil ingests 250 supplements, eight to 10 glasses of alkaline water and 10 cups of green tea. He also periodically tracks 40 to 50 fitness indicators, down to his 'tactile sensitivity.' Adjustments are made as needed.
'I do actually fine-tune my programming,' he said.
The inventor and computer scientist is serious about his health because if it fails him he might not live long enough to see humanity achieve immortality, a seismic development he predicts in his new book is no more than 20 years away."
Monday, February 14, 2005
Why I love code refactoring..
I love code refactoring! Code refactoring is a process by which computer source code is re-written to improve (among other things) efficiency, readability, and maintainability. In other words, to make it better. Successfully refactoring code is like the calvary riding in to save the day.
The main reason I enjoy refactoring is the chance to improve efficiency. I get a vicarious thrill from seeing a poorly written algorithm run orders of magnitude faster by changing one or two lines of code. It often seems that efficiency gains are achieved with minimum code changes. That's another reason I enjoy it so much. It's the most bang for the buck.
This leads to a question. How much electricity could we save if all computer programs were written as efficiently as was possible? Could we reduce the emissions of coal burning power plants to the point where we could eat the fish caught in our lakes and rivers?
The main reason I enjoy refactoring is the chance to improve efficiency. I get a vicarious thrill from seeing a poorly written algorithm run orders of magnitude faster by changing one or two lines of code. It often seems that efficiency gains are achieved with minimum code changes. That's another reason I enjoy it so much. It's the most bang for the buck.
This leads to a question. How much electricity could we save if all computer programs were written as efficiently as was possible? Could we reduce the emissions of coal burning power plants to the point where we could eat the fish caught in our lakes and rivers?
Verizon to buy MCI in $6.7B deal, beating out Qwest - Feb. 14, 2005
Another formerly high flying telecom provider being bought:
Verizon to buy MCI in $6.7B deal, beating out Qwest - Feb. 14, 2005:
"Verizon Communications agreed Monday to buy MCI in a cash, stock and special dividend deal worth nearly $6.75 billion that could result in as many as 7,000 job cuts."
Wonder what this means for that industry?
Verizon to buy MCI in $6.7B deal, beating out Qwest - Feb. 14, 2005:
"Verizon Communications agreed Monday to buy MCI in a cash, stock and special dividend deal worth nearly $6.75 billion that could result in as many as 7,000 job cuts."
Wonder what this means for that industry?
Friday, February 11, 2005
The Job Market Tightens for Developers
Based on my small sample, it seems to me like the job market is the strongest since the Internet bubble burst. For the first time since then, I don't personally know anyone who is out of work. Also, my company has been trying to hire a junior level and mid level Java programmer in the RTP area, and we have only received just a few resumes - after posting on Monster and the corporate site. Two years ago, I was flooded with resumes after a similar posting.
Hope that trend continues. I wonder if anyone else has other data to confirm my theory.
Hope that trend continues. I wonder if anyone else has other data to confirm my theory.
Thursday, February 10, 2005
Mapquest, Eat Your Heart Out
The beginning of the end came when Mapquest removed the My Mapquest feature. I only had a dozen maps in there. Thanks for not telling me before you deleted them.
But now it's over. I've found a new, better map provider.
Google has done it again, this time with Google Maps.
Just enter an address or the name of a location. Here, I've searched for "New England Aquarium, Boston, MA":
There are two things I would like to see with Google maps. First, I need one-way streets to be labeled. In cities like Boston, there's just no getting around without knowing the one-ways. Second, I'd like to have a search for finding my destination after selecting "To here". In the example above, I would like to type "Fire and Ice, Boston, MA" in the box; Google should then present me a list of choices. I pick one, and the directions are drawn on the map.
Good luck, Mapquest.
But now it's over. I've found a new, better map provider.
Google has done it again, this time with Google Maps.
Just enter an address or the name of a location. Here, I've searched for "New England Aquarium, Boston, MA":
There are two things I would like to see with Google maps. First, I need one-way streets to be labeled. In cities like Boston, there's just no getting around without knowing the one-ways. Second, I'd like to have a search for finding my destination after selecting "To here". In the example above, I would like to type "Fire and Ice, Boston, MA" in the box; Google should then present me a list of choices. I pick one, and the directions are drawn on the map.
Good luck, Mapquest.
Wednesday, February 9, 2005
Tuesday, February 8, 2005
The Cuckoo's Egg
I was reminded yesterday of Cliff Stoll's book, The Cuckoo's Egg. This book is an easy read and it is so entertaining that I read it cover-to-cover in 2 days. I recommend it to anyone who has an interest in systems or programming, or hacking, or who just enjoys a good mystery.Buy it. Read it. Enjoy.
Monday, February 7, 2005
The Importance of the Tivo API
I took the Tivo Java API for a test drive recently, not because I thought I had the next killer Tivo app, but because I think the API itself could prove to be an important development.
I don't think it's important for the reason most developers will point out - it empowers developers to write applications that run on a Tivo (which is really a linux box under the covers). It is important because developers everywhere can now write applications for a home appliance.
We have a Tivo at home, and my wife and I use it just like any other appliance or electronic device that isn't a computer; we turn it on and use it: record shows, watch shows, change channels. We don't think about it being a computer inside.
In reality, most users don't think about it being a computer - most don't know how it works. (Of course, they don't know how their computer works either, but they know a computer is a computer.) They don't recognize their Tivo as a computer - it's just a Tivo. It records things. It's an appliance, taking its place alongside the family DVD player.
Tivo is the first mainstream appliance that allows home users not only to dictate how they use it, but to dictate what they use on it. Users can now extend their tivo to show them virtually anything, from a grocery list to the latest RSS feeds to games written for Tivo.
"Ho hum." you say. "The Tivo might be an appliance, but other appliances don't need an API." Well, maybe you're right. Maybe Tivo is just using developers to find a way to sell more Tivos. (And developers will have to go through Tivo get their applications deployed to the mainstream user base.)
But maybe the Tivo isn't the only appliance that could benefit from a public programming interface. I certainly don't want to run custom code on my coffee maker, but it's not out of the question that other applicances will take on more traits of a Tivo in terms of user programming and control.
And, in case you're wondering, the API is pretty good. I wrote a simple application in just a few minutes. It doesn't offer hooks into the really interesting Tivo data, like season passes and what's queued to be recorded, but it's a start...
I don't think it's important for the reason most developers will point out - it empowers developers to write applications that run on a Tivo (which is really a linux box under the covers). It is important because developers everywhere can now write applications for a home appliance.
We have a Tivo at home, and my wife and I use it just like any other appliance or electronic device that isn't a computer; we turn it on and use it: record shows, watch shows, change channels. We don't think about it being a computer inside.
In reality, most users don't think about it being a computer - most don't know how it works. (Of course, they don't know how their computer works either, but they know a computer is a computer.) They don't recognize their Tivo as a computer - it's just a Tivo. It records things. It's an appliance, taking its place alongside the family DVD player.
Tivo is the first mainstream appliance that allows home users not only to dictate how they use it, but to dictate what they use on it. Users can now extend their tivo to show them virtually anything, from a grocery list to the latest RSS feeds to games written for Tivo.
"Ho hum." you say. "The Tivo might be an appliance, but other appliances don't need an API." Well, maybe you're right. Maybe Tivo is just using developers to find a way to sell more Tivos. (And developers will have to go through Tivo get their applications deployed to the mainstream user base.)
But maybe the Tivo isn't the only appliance that could benefit from a public programming interface. I certainly don't want to run custom code on my coffee maker, but it's not out of the question that other applicances will take on more traits of a Tivo in terms of user programming and control.
And, in case you're wondering, the API is pretty good. I wrote a simple application in just a few minutes. It doesn't offer hooks into the really interesting Tivo data, like season passes and what's queued to be recorded, but it's a start...
Wednesday, February 2, 2005
Tuesday, February 1, 2005
Politics-Oriented Software Development
This is a very funny, but surprisingly useful guide on politics and software development. My favorite part:
"9. Overtime only counts when people see it.
It's usually better to do overtime in the evening than the morning, if there are more people around to see it. Weekend overtime is usually pointless since there are rarely witnesses.
Remember that you're not just being visible to your boss, but the office as a whole. Your overtime is useless to him unless it's visible to his boss, or else other people who contribute to your team's reputation.
Keep to the minimum possible. Remember that the earliest part is most valuable since there are more witnesses: better to do half an hour Monday to Thursday than two hours on Wednesday. It also sounds better to say: 'I've worked late four nights this week.' No-one will be keeping track that closely anyway."
"9. Overtime only counts when people see it.
It's usually better to do overtime in the evening than the morning, if there are more people around to see it. Weekend overtime is usually pointless since there are rarely witnesses.
Remember that you're not just being visible to your boss, but the office as a whole. Your overtime is useless to him unless it's visible to his boss, or else other people who contribute to your team's reputation.
Keep to the minimum possible. Remember that the earliest part is most valuable since there are more witnesses: better to do half an hour Monday to Thursday than two hours on Wednesday. It also sounds better to say: 'I've worked late four nights this week.' No-one will be keeping track that closely anyway."
Subscribe to:
Posts (Atom)