It is a common use case to enter a page with the first form field selected for the user. I've historically implemented very customized JS to accomplish this but with Prototype this is almost too easy.
Event.observe(window, 'load', function() {
var field = $$('.focus').first();
if (field) field.focus();
});
Sunday, February 5, 2012
Thursday, February 2, 2012
Java Pattern Formatter
If you have worked in Java for a healthy amount of time you have probably come across Format, specifically DateFormat, NumberFormat and MessageFormat. All of these are crazy awesome but I find that I need another type of formatter that isn't part of the standard Java offerings - PatternFormatter. I love how you can use SimpleDateFormat to customize the layout of a date but I come across several situations that I wish I could come up with my own formatting tokens to format anything - Phone Numbers, Addresses, ZIP codes or any other varying but standardized format. I've spent many a night trying to solve this problem but I think I finally have something that is workable and simple...
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class PatternFormatter {
public static interface TokenEditor {
String replace(String token);
}
private static final String EMPTY_STRING = "";
private TokenEditor _editor;
private Pattern _pattern;
public PatternFormatter(Pattern pattern, TokenEditor editor) {
_pattern = pattern;
_editor = editor;
}
public PatternFormatter(String regex, TokenEditor editor) {
this(Pattern.compile(regex), editor);
}
/**
* Finds all matching pattern tokens and delegates the replacement to the
* {@link TokenEditor}. The pattern token is passed along to the editor so it
* can determine the appropriate replacement.
*
* @param mask
* to use against the pattern
* @return the formatted string
*/
public String format(String mask) {
Matcher matcher = _pattern.matcher(mask);
StringBuffer sb = new StringBuffer();
while (matcher.find()) {
String replacement = _editor.replace(matcher.group());
matcher.appendReplacement(sb, replacement == null ? EMPTY_STRING : replacement);
}
matcher.appendTail(sb);
return sb.toString();
}
}
Then to compose the Pattern formatter in a class...
public class Phone implements TokenEditor {
private Integer _areaCode, _prefix, _lineNumber;
public String replace(String token){
if(isNotBlank(token)){
if(contains(token, "a")){
if(_areaCode != null) return leftPad(_areaCode.toString(), length(token), "0");
} else if(contains(token, "p")){
if(_prefix != null) return leftPad(_prefix.toString(), length(token), "0");
} else if(contains(token, "n")){
if(_lineNumber != null)) return leftPad(_lineNumber.toString(), length(token), "0");
}
return null;
}
}
private PatternFormatter _formatter = new PatternFormatter("[apn]+|\"[^\"]*\"|'[^']*'", this);
public String format(String mask){
_formatter.format(mask);
}
}
Finally to use...
new Phone(555, 222, 3333).format("(aaa) ppp-nnnn"); = "(555) 222-3333"
new Phone(555, 2, 33).format("(aaa) ppp-nnnn"); = "(555) 002-0033"
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class PatternFormatter {
public static interface TokenEditor {
String replace(String token);
}
private static final String EMPTY_STRING = "";
private TokenEditor _editor;
private Pattern _pattern;
public PatternFormatter(Pattern pattern, TokenEditor editor) {
_pattern = pattern;
_editor = editor;
}
public PatternFormatter(String regex, TokenEditor editor) {
this(Pattern.compile(regex), editor);
}
/**
* Finds all matching pattern tokens and delegates the replacement to the
* {@link TokenEditor}. The pattern token is passed along to the editor so it
* can determine the appropriate replacement.
*
* @param mask
* to use against the pattern
* @return the formatted string
*/
public String format(String mask) {
Matcher matcher = _pattern.matcher(mask);
StringBuffer sb = new StringBuffer();
while (matcher.find()) {
String replacement = _editor.replace(matcher.group());
matcher.appendReplacement(sb, replacement == null ? EMPTY_STRING : replacement);
}
matcher.appendTail(sb);
return sb.toString();
}
}
Then to compose the Pattern formatter in a class...
public class Phone implements TokenEditor {
private Integer _areaCode, _prefix, _lineNumber;
public String replace(String token){
if(isNotBlank(token)){
if(contains(token, "a")){
if(_areaCode != null) return leftPad(_areaCode.toString(), length(token), "0");
} else if(contains(token, "p")){
if(_prefix != null) return leftPad(_prefix.toString(), length(token), "0");
} else if(contains(token, "n")){
if(_lineNumber != null)) return leftPad(_lineNumber.toString(), length(token), "0");
}
return null;
}
}
private PatternFormatter _formatter = new PatternFormatter("[apn]+|\"[^\"]*\"|'[^']*'", this);
public String format(String mask){
_formatter.format(mask);
}
}
Finally to use...
new Phone(555, 222, 3333).format("(aaa) ppp-nnnn"); = "(555) 222-3333"
new Phone(555, 2, 33).format("(aaa) ppp-nnnn"); = "(555) 002-0033"
Friday, December 16, 2011
Monday, December 12, 2011
Running Tomcat in the background on DOS
I came across a nifty bit of code that can start Apache Tomcat in the background on DOS. I'm so used to starting in Linux with nohop. But alas, nohop on DOS so I found this batch script (which can be used to start any process in the background)...
@echo off
if {%1}=={} @echo Syntax: HideBatch BatchFile [Param1 Param2 ... ParamN]&goto :EOF
setlocal
set VBS="%TEMP%\HideBatch.vbs"
if exist %VBS% goto Runit
@echo dim obj, obj1, obj2, objArgument>%VBS%
@echo Set WshShell = WScript.CreateObject("WScript.Shell")>>%VBS%
@echo Set objArgument = Wscript.Arguments>>%VBS%
@echo obj1=objArgument(0)>>%VBS%
@echo obj2=Replace(obj1, "```", """")>>%VBS%
@echo obj = WshShell.Run(obj2, 0)>>%VBS%
@echo set WshShell = Nothing>>%VBS%
:Runit
set param=%*
set param="%param:"=```%"
cscript //nologo %VBS% %param%
endlocal
It is simply a matter of executing this batch with the correct arguments for Tomcat...
$> launch.bat catalina.bat run
@echo off
if {%1}=={} @echo Syntax: HideBatch BatchFile [Param1 Param2 ... ParamN]&goto :EOF
setlocal
set VBS="%TEMP%\HideBatch.vbs"
if exist %VBS% goto Runit
@echo dim obj, obj1, obj2, objArgument>%VBS%
@echo Set WshShell = WScript.CreateObject("WScript.Shell")>>%VBS%
@echo Set objArgument = Wscript.Arguments>>%VBS%
@echo obj1=objArgument(0)>>%VBS%
@echo obj2=Replace(obj1, "```", """")>>%VBS%
@echo obj = WshShell.Run(obj2, 0)>>%VBS%
@echo set WshShell = Nothing>>%VBS%
:Runit
set param=%*
set param="%param:"=```%"
cscript //nologo %VBS% %param%
endlocal
It is simply a matter of executing this batch with the correct arguments for Tomcat...
$> launch.bat catalina.bat run
Sunday, February 20, 2011
Learning Object-C and Ruby
I'm trying to teach myself several languages to increase my Foo. I've decided to learn Ruby (which I already know via Rails but I want to become intimately knowledgeable), Objective-C, Python and Groovy. I'm starting off learning Ruby and Objective-C and Here are the things I've found that I like and dislike about each - with the caveat that since I'm still learning these languages I may incorrectly understand some of the things I dislike.
Objective-C
Like:
Like:
Objective-C
Like:
- Since it is the language of Apple, the tools (XCode, IB) are powerful but insanely simple.
- The basics of the language feel comfortable coming from a Java background - why shouldn't they since both harken back to C.
- It is taking some getting used to but I really like the separation of the header (interface) with the class file (implementation) because it forces me to think of the messaging of my objects instead of the data - ala SmallTalk
- Documentation is right at your fingertips, even offline. I know you can download the Java API but I'm lazy. :)
- Pointers: I understand their power but with great power comes great responsibility; responsibility that I haven't had to worry about in Java.
- Glyphs: I thought Java had a lot of syntactic glyphs but Objective-C will gives you carpal tunnel - (MyObj *)methodName:(type)parameter vs. MyObj methodName(type parameter) -- 4 extra syntax characters to accomplish the same thing. But the Obj-C way is a lot more descriptive.
- That darn 'NS': Was it really necessary to append every single library object with 'NS': NSString, NSArray, NSMutableString, etc...; couldn't have been just as easy to use String, Array, MutableString?
Like:
- Natural Language: As I get more used to the Ruby way, my assumptions end up being correct more often than not.
- Syntax: glyphs and ceremony is kept to an absolute minimum.
- Brevity: Accomplishing tasks in Ruby requires 1/2 or even 1/4 of the lines of code that are required with Java just to do simple tasks.
- IDE: I've become spoiled with content assistance and my IDE of choice, TextMate, is very powerful but it doesn't have content assist so I have to actually memorize the library or have the API handy at all times.
- Dependency management: I hate wrestling with dependency issues in Java but Ruby takes it to a whole new level with require, require_relative and include.
- File sprawl: I remember my old days of PHP where packaging your project for deployment was like herding cats, files spread out everywhere on the filesystem. More often than not it was my fault for allowing my directory structures to get so scattered but with Java I'm forced to at least have a reasonable directly layout. With Ruby the onus is back on me.
Friday, January 30, 2009
There Is No Shame In Shame
This post is a divergence for me as it is not related to development nor is it technical it is simply an observation of the current economic situation and what I see as some of the major problems. I don't presume to be all that economically savvy but I can observe and evaluate what I see as well as anyone.
With the economy getting visibly worse I think this is a great time for Americans to take a hard look at themselves and try and figure out what went wrong and why. I have heard many opinions about why we are in such a terrible economic downturn: greed, bursting housing bubble, frozen credit, lack of consumer spending and a whole host of others. But I believe that all of these are effects of not the cause of the economic downturn. The most fundamental reason for all of these is shame or more precisely the lack of shame.
In the current politically correct age Americans have lost their sense of shame. This is going to sound contradictory but shame is nothing to be ashamed of. People feel no shame for anything, and if they get a whiff of shame they lash out and blame those shaming them. What the hell happened to us.
Banks and mortgage companies conjured up "sub prime" loans for people who historically couldn't qualify for a loan on a $3 cappuccino but all of a sudden qualify for a $100K plus home loan. The human waste that would willingly dupe good people into such a ludicrous financial situation should be shamed. It wasn't greed but the lack of shame of making money by graft and deception that caused the sub prime mess. Greed was the fuel but shame could have been the breaks to reign in the greed, but those breaks were never applied.
Don't believe for a minute that those people who were allowed to be duped share no responsibility. They people should be ashamed for being so ignorant of basic microeconomics. In the time of almost limitless and FREE information (books, Internet, financial advisers) there is no excuse for anyone to make a financial decision that gets them into so much financial trouble from something as simple as the value of their home decreasing or the interest rates going up 1 or 2 points. Those people should be shamed for being so ignorant and lazy, not stupid; stupid assumes they didn't have the brain power, ignorant and lazy because they just didn't take the time to take advantage the myriad of information sources. Now if they really didn't have the brain power the onus rest squarely on the banks and/or mortgage companies for serious malfeasance and they not only should be shamed but incarcerated. The problem now is that those people who did take the due diligence to make a good financial decision but were swept up in the tsunami are now being punished for nothing more then their neighbors and financial institutions not being ashamed of doing the wrong thing.
Onto to the executives. This group is a little harder to shame as a group because their are good executives and their are some mediocre executives and then there are the down right piles of crap executives. The good executives who didn't lie, cheat and steal to get ahead and in fact helped your customers and employees steer clear of the current debacle [Daniel P Amos of Aflac], you should be applauded for your strength of courage to do the right thing in an environment of "irrational exuberance."1 For the truly monstrous executives who exacerbated the current economic disaster you should be ashamed for living like a vulture, in which case you should do the honorable thing and give back your millions and step down and never be in charge of anything more than a hot dog cart. Mediocre executives, well you should just be ashamed for either being too stupid to be in the position you're in or for sitting on the sidelines and watching the world crumble. As an American executive you have a responsibility greater than than to your share holders. You have a responsibility to the American people to live honorably as well as successfully. You have a responsibility to your customers who have spent their hard earned wages to purchase your product. You have a responsibility to your employees who give you their blood, sweat and tears every day to help you prosper. As an executive you should know who is trully important and why. America is important because it has an economy and government that, while flawed, allows you to succeed. Your customers are important because they are the reason you are in business and they are your livelyhood,without them you don't have a business. Your employees are important because they are the company they are its hands its heart and its brain, without them your ideas are just thoughts without purpose. You, the executives, are important because you are the soul of a business and if you are dishonorable then the soul of the company is no better than a common criminals. The only group that really isn't that important is the share holders, because thousands of successful and privatly held companies prove that every day. If a share holder insists on making money at any cost they are a cancer to America, to your customers, to your employees and to you and they should be disregarded as you would disregard the rantings of murderer. Let their money go because its not worth selling your soul to let evil prosper. A share holder who doens't feel shame for making money at the expense of the truly valuable is a terrorist in every sense of the word.
While I'm not as synical as most and don't believe all politicians are crooks, I do believe that the only good politician is a hog tied politician. Power always progresses toward corruption. Americans have been wrongly convinced that a good government is a productive government. A stalled and divisive government retards its power and therfore slows progression toward corruption. There are times, during war or national emergency, that an efficient government is necessary but generally a government mired in debate and conflict is desirable. During the roaring 90's and early 2000's politicians were given too much power by the American poeple. They were allowed to create policies that were are now suffering under. Policies that made lending to "sub prime" borrowers possible through Fannie Mae and Freddy Mac which were allowed to leverage to the tune of 50 to 1. That means for ever $1 of actual equity they were in debt $50 dollars. This policy was to make home ownership a reality for all Americans all in the name of fairness. Those politicians, particularly Barnie Frank, should be ashamed for putting the American economy and the world economy for that fact in serious jeopordy. These same politicians that got the world into this mess are now trying to tell us they are going to get us out of it. They should be ashamed for being such a miserable failure but still thinking their opinion counts. The American people should be ashamed for not throwing these bums out of office when their stupidity caused this mess and now we are giving them another bite at the proverbial apple. I had a hope that Obama could turn this around but he is turning to the one thing that got us into this mess in the first place, debt. It is shameful that our addiction to debt is going to cause the first American generation to be worse off than their parents. We should be ashamed to leave our children and grandchildren the burden of paying for our multi trillion dollar debt, I repeat $3,000,000,000,000 +/- 2 trillion. It makes me physically ill to think we are going to screw every man, woman and child with a minimum of $35,000 of debt for at least the next 20 years.
So be ashamed America. Be ashamed that we deserve this recession/depression for our stupidity, ineptitude and greed. Be ashamed for being the first generation in America to leave our children with less than we we given from our parents. Be ashamed because it is the only thing that will force us to do be better than we have been.
With the economy getting visibly worse I think this is a great time for Americans to take a hard look at themselves and try and figure out what went wrong and why. I have heard many opinions about why we are in such a terrible economic downturn: greed, bursting housing bubble, frozen credit, lack of consumer spending and a whole host of others. But I believe that all of these are effects of not the cause of the economic downturn. The most fundamental reason for all of these is shame or more precisely the lack of shame.
In the current politically correct age Americans have lost their sense of shame. This is going to sound contradictory but shame is nothing to be ashamed of. People feel no shame for anything, and if they get a whiff of shame they lash out and blame those shaming them. What the hell happened to us.
Banks and mortgage companies conjured up "sub prime" loans for people who historically couldn't qualify for a loan on a $3 cappuccino but all of a sudden qualify for a $100K plus home loan. The human waste that would willingly dupe good people into such a ludicrous financial situation should be shamed. It wasn't greed but the lack of shame of making money by graft and deception that caused the sub prime mess. Greed was the fuel but shame could have been the breaks to reign in the greed, but those breaks were never applied.
Don't believe for a minute that those people who were allowed to be duped share no responsibility. They people should be ashamed for being so ignorant of basic microeconomics. In the time of almost limitless and FREE information (books, Internet, financial advisers) there is no excuse for anyone to make a financial decision that gets them into so much financial trouble from something as simple as the value of their home decreasing or the interest rates going up 1 or 2 points. Those people should be shamed for being so ignorant and lazy, not stupid; stupid assumes they didn't have the brain power, ignorant and lazy because they just didn't take the time to take advantage the myriad of information sources. Now if they really didn't have the brain power the onus rest squarely on the banks and/or mortgage companies for serious malfeasance and they not only should be shamed but incarcerated. The problem now is that those people who did take the due diligence to make a good financial decision but were swept up in the tsunami are now being punished for nothing more then their neighbors and financial institutions not being ashamed of doing the wrong thing.
Onto to the executives. This group is a little harder to shame as a group because their are good executives and their are some mediocre executives and then there are the down right piles of crap executives. The good executives who didn't lie, cheat and steal to get ahead and in fact helped your customers and employees steer clear of the current debacle [Daniel P Amos of Aflac], you should be applauded for your strength of courage to do the right thing in an environment of "irrational exuberance."1 For the truly monstrous executives who exacerbated the current economic disaster you should be ashamed for living like a vulture, in which case you should do the honorable thing and give back your millions and step down and never be in charge of anything more than a hot dog cart. Mediocre executives, well you should just be ashamed for either being too stupid to be in the position you're in or for sitting on the sidelines and watching the world crumble. As an American executive you have a responsibility greater than than to your share holders. You have a responsibility to the American people to live honorably as well as successfully. You have a responsibility to your customers who have spent their hard earned wages to purchase your product. You have a responsibility to your employees who give you their blood, sweat and tears every day to help you prosper. As an executive you should know who is trully important and why. America is important because it has an economy and government that, while flawed, allows you to succeed. Your customers are important because they are the reason you are in business and they are your livelyhood,without them you don't have a business. Your employees are important because they are the company they are its hands its heart and its brain, without them your ideas are just thoughts without purpose. You, the executives, are important because you are the soul of a business and if you are dishonorable then the soul of the company is no better than a common criminals. The only group that really isn't that important is the share holders, because thousands of successful and privatly held companies prove that every day. If a share holder insists on making money at any cost they are a cancer to America, to your customers, to your employees and to you and they should be disregarded as you would disregard the rantings of murderer. Let their money go because its not worth selling your soul to let evil prosper. A share holder who doens't feel shame for making money at the expense of the truly valuable is a terrorist in every sense of the word.
While I'm not as synical as most and don't believe all politicians are crooks, I do believe that the only good politician is a hog tied politician. Power always progresses toward corruption. Americans have been wrongly convinced that a good government is a productive government. A stalled and divisive government retards its power and therfore slows progression toward corruption. There are times, during war or national emergency, that an efficient government is necessary but generally a government mired in debate and conflict is desirable. During the roaring 90's and early 2000's politicians were given too much power by the American poeple. They were allowed to create policies that were are now suffering under. Policies that made lending to "sub prime" borrowers possible through Fannie Mae and Freddy Mac which were allowed to leverage to the tune of 50 to 1. That means for ever $1 of actual equity they were in debt $50 dollars. This policy was to make home ownership a reality for all Americans all in the name of fairness. Those politicians, particularly Barnie Frank, should be ashamed for putting the American economy and the world economy for that fact in serious jeopordy. These same politicians that got the world into this mess are now trying to tell us they are going to get us out of it. They should be ashamed for being such a miserable failure but still thinking their opinion counts. The American people should be ashamed for not throwing these bums out of office when their stupidity caused this mess and now we are giving them another bite at the proverbial apple. I had a hope that Obama could turn this around but he is turning to the one thing that got us into this mess in the first place, debt. It is shameful that our addiction to debt is going to cause the first American generation to be worse off than their parents. We should be ashamed to leave our children and grandchildren the burden of paying for our multi trillion dollar debt, I repeat $3,000,000,000,000 +/- 2 trillion. It makes me physically ill to think we are going to screw every man, woman and child with a minimum of $35,000 of debt for at least the next 20 years.
So be ashamed America. Be ashamed that we deserve this recession/depression for our stupidity, ineptitude and greed. Be ashamed for being the first generation in America to leave our children with less than we we given from our parents. Be ashamed because it is the only thing that will force us to do be better than we have been.
Sunday, January 25, 2009
Back To Work Reflections
Well, I'm starting my new job on February 2nd and it feels pretty good to be going back to work. Thanks goes out to everyone for their prayers and thoughts which are greatly appreciated. I am humbled by everyone's concern for my wife and I and we won't soon forget everyone's kindness. As a form of gratitude I want to examine what I learned during this turbulent time in my life. To that end I ask myself what did I learn - ala South Park.
So, what did I learn from all this? First, before leaving a good company do an in-depth self examination of your situation and ask, "is it really horrible or is it just challenging?" If it is horrible can it be corrected? Second, don't run to the first opportunity presented, do diligent research of the organization/business that you are thinking of joining and make sure you can be successful, happy and that the company shares your beliefs both socially and culturally. Thirdly, take good advice from good people who honestly care about you and discard negative and short sighted advice.
Enough generalities, what did I learn that is specific to my situation? Flat organizations are idiotic in concept and in practice; without minimal bureaucracy how do you rationally organize projects, resources and people. A truly flat development organization has no way of preventing nomadic development and cowboy coding. Great technical professionals are very smart, great at solving problems and taking advantage of opportunities but technical professionals are, let's face it, not the best organizers. How many times [as a developer/thought worker] have you started down a path of solving a particular problem and end up building a new framework or library. I know if I don't actively stay focused on my target I tend to start solving problems that nobody has or is likely to have; or worse, creating something that my employer neither needs nor wants. A flat organization also tends toward context thrashing. If people aren't assigned particular tasks/projects then the chances of bouncing from one task/project to another is inevitable. Flat organizations also lack any real leadership because there are no assigned leaders and if a business/organization isn't lucky or innovative enough to have automatic leaders then you are stuck with a developer herd going in all directions - not exactly a rosy work environment.
I also learned that when you enter an environment where you are continually told that you are working with the smartest people, run, run like the wind. When people have become so arrogant and self absorbed that they begin to truly believe they are the smartest people in the room you are dealing with a room of typewriting monkeys. You very well may or may not be working with some very intelligent and talented people but when those same people begin to toot their own horn then they have become blind to their own ignorance. Take a queue from Socrates, "I know that I am intelligent, because I know that I know nothing." No one, not even Einstein, was the smartest man in every room on every subject. What happened when Einstein joined a group of botanists? He became an above average Joe. If you are humble enough to know that you are not the smartest then you will always be pushing yourself. If you are the smartest around then you don't need to push yourself you can just rest on your laurels - not a good trait in IT.
I also learned to be more diligent about a budget. When I first got laid off my wife and I took a look at our finances and quickly realized that we had very little in reserve. The worst part was not that we were going to have to tighten our belt but that if we would have just handled our finances while times were good we wouldn't have been in such dire straits. My income alone was enough to pay-off most of our debts if we would have just been more disciplined. This was the hardest thing because it is the one thing we had the most control over and we squandered a great opportunity. This was a hard learned lesson that I am going to correct quick, fast and in a hurry at my new job.
If you have recently lost your job trust me I know how hard it is, especially psychologically. All I can say is turn to your family and friends they are going to be your anchor in the coming storms. Try not to panic, I know, I know easier said than done but this too shall pass. Try and learn from your current situation, you are living through a difficult time that can show you who and what really matters in your life. For me I rediscovered the strength of my wife, the love of my family and the strong bonds of friendship. I believe that everything happens for a purpose and if you stay alert you will discover the purpose of your hardships.
So, what did I learn from all this? First, before leaving a good company do an in-depth self examination of your situation and ask, "is it really horrible or is it just challenging?" If it is horrible can it be corrected? Second, don't run to the first opportunity presented, do diligent research of the organization/business that you are thinking of joining and make sure you can be successful, happy and that the company shares your beliefs both socially and culturally. Thirdly, take good advice from good people who honestly care about you and discard negative and short sighted advice.
Enough generalities, what did I learn that is specific to my situation? Flat organizations are idiotic in concept and in practice; without minimal bureaucracy how do you rationally organize projects, resources and people. A truly flat development organization has no way of preventing nomadic development and cowboy coding. Great technical professionals are very smart, great at solving problems and taking advantage of opportunities but technical professionals are, let's face it, not the best organizers. How many times [as a developer/thought worker] have you started down a path of solving a particular problem and end up building a new framework or library. I know if I don't actively stay focused on my target I tend to start solving problems that nobody has or is likely to have; or worse, creating something that my employer neither needs nor wants. A flat organization also tends toward context thrashing. If people aren't assigned particular tasks/projects then the chances of bouncing from one task/project to another is inevitable. Flat organizations also lack any real leadership because there are no assigned leaders and if a business/organization isn't lucky or innovative enough to have automatic leaders then you are stuck with a developer herd going in all directions - not exactly a rosy work environment.
I also learned that when you enter an environment where you are continually told that you are working with the smartest people, run, run like the wind. When people have become so arrogant and self absorbed that they begin to truly believe they are the smartest people in the room you are dealing with a room of typewriting monkeys. You very well may or may not be working with some very intelligent and talented people but when those same people begin to toot their own horn then they have become blind to their own ignorance. Take a queue from Socrates, "I know that I am intelligent, because I know that I know nothing." No one, not even Einstein, was the smartest man in every room on every subject. What happened when Einstein joined a group of botanists? He became an above average Joe. If you are humble enough to know that you are not the smartest then you will always be pushing yourself. If you are the smartest around then you don't need to push yourself you can just rest on your laurels - not a good trait in IT.
I also learned to be more diligent about a budget. When I first got laid off my wife and I took a look at our finances and quickly realized that we had very little in reserve. The worst part was not that we were going to have to tighten our belt but that if we would have just handled our finances while times were good we wouldn't have been in such dire straits. My income alone was enough to pay-off most of our debts if we would have just been more disciplined. This was the hardest thing because it is the one thing we had the most control over and we squandered a great opportunity. This was a hard learned lesson that I am going to correct quick, fast and in a hurry at my new job.
If you have recently lost your job trust me I know how hard it is, especially psychologically. All I can say is turn to your family and friends they are going to be your anchor in the coming storms. Try not to panic, I know, I know easier said than done but this too shall pass. Try and learn from your current situation, you are living through a difficult time that can show you who and what really matters in your life. For me I rediscovered the strength of my wife, the love of my family and the strong bonds of friendship. I believe that everything happens for a purpose and if you stay alert you will discover the purpose of your hardships.
Sunday, January 11, 2009
Fluent Calendar Builder
If you have ever worked with Java's java.util.Calendar interface, you understand the definition of pain. Don't get me wrong, java.util.Calendar is head and shoulders above java.util.Date or java.util.Time but it still hurts way too much to work with. Especially if you want to do something simple like instancing a Date/Calendar with tomorrow's date:
java.util.Date:
Date date = new Date(2009, 1, 12, 0,0,0);
System.out.println(date); <-- Fri Feb 12 00:00:00 MST 3909
java.util.Calendar:
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.YEAR, 2009);
calendar.set(Calendar.MONTH, Calendar.JANUARY);
calendar.set(Calendar.DATE, 12);
calendar.set(Calendar.HOUR_OF_DAY, 0);
calendar.set(Calendar.MINUTE, 0);
calendar.set(Calendar.SECOND, 0);
calendar.set(Calendar.MILLISECOND, 0);
System.out.println(calendar.getTime()); <-- Mon Jan 12 00:00:00 MST 2009
As you can see Date just gets it wrong. First of all it starts the months at zero, there is no reason for a zero index other than bad habits carried over from pointer based languages (C,C++). Second, what's with the year 3909? Oh that's right, Date works with 2 digit years [ala millennial bug] so instead of 2009 you would need to set the year to 2009 - 1900 (Date's epoch) which is 109.
Calendar doesn't do any better with the month index starting at zero, but at least it gives you some static fields to prevent mistaking January with 1 (how silly of you using logic, 1 = January). Plus, Calendar does work correctly with 4 digit years. But, OMG what a pain, from 1 line of instantiation for Date to 7 lines for Calendar.
These are just the easiest pain points to point-out, there are dozens for both Date and Calendar. Review this pdf to see more problems. Why can't it be as easy as:
Calendar calendar = Calendar.tomorrow().midnight();
Well it can be with a little work. Enter the Fluent Interface pattern. It can be used as like a DSL and it can ease the Date/Calendar pain immensely. By wrapping the instantiation of Calendar in a DSL Fluent Interface, CalendarBuilder I was able to do some amazing things like:
Calendar id4 = CalendarBuilder.builder().july().fourth().year(1776).build();
Calendar tomorrowNoon = CalendarBuilder.builder().tomorrow().noon().build();
Simple as Date but with the power of Calendar - much nicer. Be warned, this still doesn't remove the other failings of Calendar but it does make it less painful than pulling nose hairs but still as painful as hitting your silly bone, a little tingly and sometimes you even laugh. Don't expect the problems with Date/Calendar to get resolved any time soon. Date was Java's first attempt at working with temporal data but it was very flawed. Calendar was introduced in Java 1.1 and it fixed some of Date's ills but introduced a whole new set of problems. Now JSR-310 is set up to fix all of Date and Calendar's flaws but I'm not holding my breath. Some of the smartest people around created Date and Calendar and they couldn't get it right. I expect JSR-310 to make some good progress toward a better temporal model but I suspect that it will keep some warts and sprout several of its own. But if you have to work with Calendar I would strongly suggest a Fluent Calendar Builder until JSR-310 rides in to the rescue.
java.util.Date:
Date date = new Date(2009, 1, 12, 0,0,0);
System.out.println(date); <-- Fri Feb 12 00:00:00 MST 3909
java.util.Calendar:
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.YEAR, 2009);
calendar.set(Calendar.MONTH, Calendar.JANUARY);
calendar.set(Calendar.DATE, 12);
calendar.set(Calendar.HOUR_OF_DAY, 0);
calendar.set(Calendar.MINUTE, 0);
calendar.set(Calendar.SECOND, 0);
calendar.set(Calendar.MILLISECOND, 0);
System.out.println(calendar.getTime()); <-- Mon Jan 12 00:00:00 MST 2009
As you can see Date just gets it wrong. First of all it starts the months at zero, there is no reason for a zero index other than bad habits carried over from pointer based languages (C,C++). Second, what's with the year 3909? Oh that's right, Date works with 2 digit years [ala millennial bug] so instead of 2009 you would need to set the year to 2009 - 1900 (Date's epoch) which is 109.
Calendar doesn't do any better with the month index starting at zero, but at least it gives you some static fields to prevent mistaking January with 1 (how silly of you using logic, 1 = January). Plus, Calendar does work correctly with 4 digit years. But, OMG what a pain, from 1 line of instantiation for Date to 7 lines for Calendar.
These are just the easiest pain points to point-out, there are dozens for both Date and Calendar. Review this pdf to see more problems. Why can't it be as easy as:
Calendar calendar = Calendar.tomorrow().midnight();
Well it can be with a little work. Enter the Fluent Interface pattern. It can be used as like a DSL and it can ease the Date/Calendar pain immensely. By wrapping the instantiation of Calendar in a DSL Fluent Interface, CalendarBuilder I was able to do some amazing things like:
Calendar id4 = CalendarBuilder.builder().july().fourth().year(1776).build();
Calendar tomorrowNoon = CalendarBuilder.builder().tomorrow().noon().build();
Simple as Date but with the power of Calendar - much nicer. Be warned, this still doesn't remove the other failings of Calendar but it does make it less painful than pulling nose hairs but still as painful as hitting your silly bone, a little tingly and sometimes you even laugh. Don't expect the problems with Date/Calendar to get resolved any time soon. Date was Java's first attempt at working with temporal data but it was very flawed. Calendar was introduced in Java 1.1 and it fixed some of Date's ills but introduced a whole new set of problems. Now JSR-310 is set up to fix all of Date and Calendar's flaws but I'm not holding my breath. Some of the smartest people around created Date and Calendar and they couldn't get it right. I expect JSR-310 to make some good progress toward a better temporal model but I suspect that it will keep some warts and sprout several of its own. But if you have to work with Calendar I would strongly suggest a Fluent Calendar Builder until JSR-310 rides in to the rescue.
Wednesday, January 7, 2009
Java/J2EE Web Developer Looking for Job
Well, I'm now unemployed. Okay to be accurate I'll be unemployed Monday morning. I was working on a contract to hire gig and the contract ran out but the hire never materialized. What is the lesson learned from this? Don't depend on a contract to hire to pull through, always keep your options open. I got burned but learned.
I was really depending on getting hired on full time but now, I'm suffering jobless stress or whatever its called when you totally panic because you no longer have any income. My first reaction was to run out an cancel all of my extraneous expenses; cell phone, home phone, long distance, internet, gas, electricity, water, oxygen. Then my more level headed wife stepped in and calmed me down enough that I could think somewhat clearly. I did cancel my long distance but kept the phone and downgraded my cell phone service. That will help but it's not going to be enough. I will need to get another job, preferably in IT but if times get too tough I'll have to dust off my old server apron.
Don't get me wrong I don't believe any job is beneath me but I've upped my living standard a bit since I last was a server. I don't mind pulling it back but that still doesn't stop me from feeling a little anxious - strike that, a lot anxious.
This will probably end up being a great opportunity but right now the going is pretty rough. If anything its only hardened my resolve to pay off my debts quick, fast and in a hurry. Debt is a
serious weight that just drags you down to the depths.
So if anyone in Colorado is looking for a skilled Java/J2EE developer and you think I would be a good fit, I'm all yours.
I was really depending on getting hired on full time but now, I'm suffering jobless stress or whatever its called when you totally panic because you no longer have any income. My first reaction was to run out an cancel all of my extraneous expenses; cell phone, home phone, long distance, internet, gas, electricity, water, oxygen. Then my more level headed wife stepped in and calmed me down enough that I could think somewhat clearly. I did cancel my long distance but kept the phone and downgraded my cell phone service. That will help but it's not going to be enough. I will need to get another job, preferably in IT but if times get too tough I'll have to dust off my old server apron.
Don't get me wrong I don't believe any job is beneath me but I've upped my living standard a bit since I last was a server. I don't mind pulling it back but that still doesn't stop me from feeling a little anxious - strike that, a lot anxious.
This will probably end up being a great opportunity but right now the going is pretty rough. If anything its only hardened my resolve to pay off my debts quick, fast and in a hurry. Debt is a
serious weight that just drags you down to the depths.
So if anyone in Colorado is looking for a skilled Java/J2EE developer and you think I would be a good fit, I'm all yours.
Thursday, December 4, 2008
Where did that come from?
Have you ever tested code and some inexplicable error keeps happening over and over even though you can swear that you removed or corrected the offending code. I can't count the times this has happened to me. I just worked my way through this very problem.
I was working on some javascript and I kept getting an error about a function/class not being a constructor. I kept changing code and adding alerts but I could not figure out why FF or IE couldn't identify my function. I went so far as to delete everything from the function and leave a lone alert. Still no luck. After hours of hair pulling, which is hard since I have very little hair, I finally discovered the problem. Two scripts on the page had the same name. Problem was that while I was importing my script the other script was magically being pulled in via an ajax/eval. So the import of the script went something like this HTML -> import script 1 -> script 1 has a dependancy on script 2 -> script 1 import script 2 -> script 2 has a dependancy on script 3 -> script 2 import script 3. Sounds simple enough right, well it would be if the HTML page either imported all of the necesssary scripts or even if you had a nifty dojo like require function so that scripts could explicitly import their dependancies. Oh no, what I had to deal with is some monkey writing a utility function that pulls in all of the scripts I could ever possibly need for every possible HTML page. That means that every script written for any portion of the site gets pulled in; lets see that's 76 scripts with 4 duplicates, 74 I don't even use or need and 3 of those are libraries like DWR and ProtoType, great libraries but I don't need them imported for every single page on the site.
Lesson: Fight the erge to bring the entire arsenal of weaponry to every fight. In other words stop trying to predict what will be needed for the future, let the very smart and talented developers who come after you decide what tool they need to solve their problems. Your code will be smaller, easier to read and best of all easier to modify. Poeple suck at predicting the future and the sooner developers understand this and write their code for what is and not for what might be the sooner you will stop writing impossibly complex and useless code.
I was working on some javascript and I kept getting an error about a function/class not being a constructor. I kept changing code and adding alerts but I could not figure out why FF or IE couldn't identify my function. I went so far as to delete everything from the function and leave a lone alert. Still no luck. After hours of hair pulling, which is hard since I have very little hair, I finally discovered the problem. Two scripts on the page had the same name. Problem was that while I was importing my script the other script was magically being pulled in via an ajax/eval. So the import of the script went something like this HTML -> import script 1 -> script 1 has a dependancy on script 2 -> script 1 import script 2 -> script 2 has a dependancy on script 3 -> script 2 import script 3. Sounds simple enough right, well it would be if the HTML page either imported all of the necesssary scripts or even if you had a nifty dojo like require function so that scripts could explicitly import their dependancies. Oh no, what I had to deal with is some monkey writing a utility function that pulls in all of the scripts I could ever possibly need for every possible HTML page. That means that every script written for any portion of the site gets pulled in; lets see that's 76 scripts with 4 duplicates, 74 I don't even use or need and 3 of those are libraries like DWR and ProtoType, great libraries but I don't need them imported for every single page on the site.
Lesson: Fight the erge to bring the entire arsenal of weaponry to every fight. In other words stop trying to predict what will be needed for the future, let the very smart and talented developers who come after you decide what tool they need to solve their problems. Your code will be smaller, easier to read and best of all easier to modify. Poeple suck at predicting the future and the sooner developers understand this and write their code for what is and not for what might be the sooner you will stop writing impossibly complex and useless code.
Monday, December 1, 2008
Evolving: Coding Monkey to Software Craftsman
As an IT professional I hear a lot of things that make me cringe. Yesterday I heard an old school mantra. "Our code is pretty bad because we didn't have time to clean it up." I can't count the times I've heard this same statement uttered, either exactly or in spirit.
It blows my mind that in the age of agile development that people are still cowboy coding. The days of mindless hacking must end; IT needs to mature into a formal scientific discipline. Would you ever hear an architect say, well I was just experimenting, I meant to get the foundation complete but I wanted to make sure the roof worked first. While the physical examples of architecture can go a long way to describe a software developer's work the metaphor can become strained, but the point is valid. When building code you must always be cognizant of what, how and why of your problem domain: What are you building, how are you building it, why are you building it. If you keep all three of these questions in mind your development won't slip into cowboy coding. Better yet, practice TDD and you won't have to keep these principles in memory.
Test Driven Development guides you through th big three questions about any code you write. You write the test to meet the user's story and then the code almost writes itself. For example, if you have a user story that a user wants a way to figure out what day of the week they were born (I know its pretty contrived). You first write a test that guarantees that if someone were to be born today that whatever calculation you use in your code will return the correct day of the week. Then come up with a few random test cases, your own birthday, the current President's birthday, your spouses birthday or whatever. Finally, come up with some edge cases, what happens if someone were born on Feb 29, 2004, what about someone born before the Gregorian Calendar took affect. Then if you write code to pass these test you will of answered all three vitals; what are you writing: a solution for determining the day of the week for a given date, why are you writing it: to meet the user's requirement for a date tool, how are you going to build it: take in a date spit out the day of the week.
Another step in becoming more than a coding monkey is desire. As a developer do you sometimes find yourself falling back on what you know, on what is easy. That lethargy will never evolved your simian tendencies. A monkey has it easy they don't have to worry about lay-offs or that their knowledge going stale; but we developers have to constantly be worried about these real threats to our career survival. Developers are knowledge workers and our one and only commodity is our knowledge so why would you allow it to rot? Every line of code you write you should be pushing yourself to do it better (clearer, more concise) than you did on the last line of code. Refactoring is great for fixing smelly code, but what we need to have is a desire to prefactor: fixing smelly code before its written. The best developers I know never say, it isnt' as good as I could do but its good enough; instead I hear them say, I did the best I could but I know I can do better. The best developers have a desire to improve their craft. I just finished reading a great post How to be an expert, by Kathy Sierra on the blog Passionate that describes this idea much better than I ever could.
Most IT shops are broken, but there are solid ways to improve and even fix a lot of the problems. We, the developers, just need step up and realize that we are part of the problem but we can be part of the solution. Stop being a coding monkey and become a software craftsman.
It blows my mind that in the age of agile development that people are still cowboy coding. The days of mindless hacking must end; IT needs to mature into a formal scientific discipline. Would you ever hear an architect say, well I was just experimenting, I meant to get the foundation complete but I wanted to make sure the roof worked first. While the physical examples of architecture can go a long way to describe a software developer's work the metaphor can become strained, but the point is valid. When building code you must always be cognizant of what, how and why of your problem domain: What are you building, how are you building it, why are you building it. If you keep all three of these questions in mind your development won't slip into cowboy coding. Better yet, practice TDD and you won't have to keep these principles in memory.
Test Driven Development guides you through th big three questions about any code you write. You write the test to meet the user's story and then the code almost writes itself. For example, if you have a user story that a user wants a way to figure out what day of the week they were born (I know its pretty contrived). You first write a test that guarantees that if someone were to be born today that whatever calculation you use in your code will return the correct day of the week. Then come up with a few random test cases, your own birthday, the current President's birthday, your spouses birthday or whatever. Finally, come up with some edge cases, what happens if someone were born on Feb 29, 2004, what about someone born before the Gregorian Calendar took affect. Then if you write code to pass these test you will of answered all three vitals; what are you writing: a solution for determining the day of the week for a given date, why are you writing it: to meet the user's requirement for a date tool, how are you going to build it: take in a date spit out the day of the week.
Another step in becoming more than a coding monkey is desire. As a developer do you sometimes find yourself falling back on what you know, on what is easy. That lethargy will never evolved your simian tendencies. A monkey has it easy they don't have to worry about lay-offs or that their knowledge going stale; but we developers have to constantly be worried about these real threats to our career survival. Developers are knowledge workers and our one and only commodity is our knowledge so why would you allow it to rot? Every line of code you write you should be pushing yourself to do it better (clearer, more concise) than you did on the last line of code. Refactoring is great for fixing smelly code, but what we need to have is a desire to prefactor: fixing smelly code before its written. The best developers I know never say, it isnt' as good as I could do but its good enough; instead I hear them say, I did the best I could but I know I can do better. The best developers have a desire to improve their craft. I just finished reading a great post How to be an expert, by Kathy Sierra on the blog Passionate that describes this idea much better than I ever could.
Most IT shops are broken, but there are solid ways to improve and even fix a lot of the problems. We, the developers, just need step up and realize that we are part of the problem but we can be part of the solution. Stop being a coding monkey and become a software craftsman.
Technical Interview Questions
Have you ever taken a technical interview that went terribly? I just did, and it was horrible. I was asked questions I had no clue how to answer, questions that I barely knew or had limited exposure to and finally questions I knew but answered incorrectly because I was so nervous about the previous bad answers I had given. The worst part is I incorrectly answered questions that I have asked interviewees in the past. So instead of crying over spilled milk I decided to learn from this experience.
First, asking a bunch of random technical questions may seem like a good way to quiz a prospective employee, it really just strokes the questioner's ego and doesn't necessarily give you a true picture of what the candidate is capable of. Do you really care that a candidate has memorized the entire Java API and can tell you the method name, signature and optimal use for any random class, abstract or interface; or do you care more that a candidate can access and understand the JavaDoc API? Is it more important that a candidate can give a detailed treatise on the definition of polymorphism or do you care more that a candidate understands the concept and can put it into practice. Let me elaborate, I had a youth minister once who could spout off any verse in the Bible, he had nearly memorized the whole thing, but when you asked him the meaning of a verse and not the verbatim dictation he was at a total loss.
Second, if you must ask raw technical questions, take the time to order them from simple to complex. Once the candidate starts missing question after question you can reasonably gauge their skill level by the last question(s) answered correctly. Plus you might be able to cut an interview short for a candidate that doesn't meet a minimum requirement, therefore saving your day and not pressing salt into the candidate's wound. Don't bombard the candidate with a slew of random questions from subject to subject. It only shows the interviewers lack of time spent preparing for the interview, and it also gives insight into how the company may work. A scattered interviewer means a scattered brain means a scattered organization.
Third, understand that the candidate may be very nervous; they are after all interviewing for their livelihood, and will sometimes make obvious mistakes. Lead them to correct answers, don't try and trick them. An interviewer who would expressly set out to trip up a candidate is a worthless human scavenger. I'm not saying answer the question for the candidate but sometimes they need a little help to get the ball rolling.
If you are an arrogant, self aggrandizing prig, then nothing will stop you from thinking that the best hires are those that have memorized some abstruse features of Java (http://softarc.blogspot.com/2006/10/my-favorite-java-developer-interview.html). All I can say is, 'congratulations in hiring MENSA.' I personally want to work with talented people who are there to solve business problems not quibble over the esoteric technical aspects of Java.
First, asking a bunch of random technical questions may seem like a good way to quiz a prospective employee, it really just strokes the questioner's ego and doesn't necessarily give you a true picture of what the candidate is capable of. Do you really care that a candidate has memorized the entire Java API and can tell you the method name, signature and optimal use for any random class, abstract or interface; or do you care more that a candidate can access and understand the JavaDoc API? Is it more important that a candidate can give a detailed treatise on the definition of polymorphism or do you care more that a candidate understands the concept and can put it into practice. Let me elaborate, I had a youth minister once who could spout off any verse in the Bible, he had nearly memorized the whole thing, but when you asked him the meaning of a verse and not the verbatim dictation he was at a total loss.
Second, if you must ask raw technical questions, take the time to order them from simple to complex. Once the candidate starts missing question after question you can reasonably gauge their skill level by the last question(s) answered correctly. Plus you might be able to cut an interview short for a candidate that doesn't meet a minimum requirement, therefore saving your day and not pressing salt into the candidate's wound. Don't bombard the candidate with a slew of random questions from subject to subject. It only shows the interviewers lack of time spent preparing for the interview, and it also gives insight into how the company may work. A scattered interviewer means a scattered brain means a scattered organization.
Third, understand that the candidate may be very nervous; they are after all interviewing for their livelihood, and will sometimes make obvious mistakes. Lead them to correct answers, don't try and trick them. An interviewer who would expressly set out to trip up a candidate is a worthless human scavenger. I'm not saying answer the question for the candidate but sometimes they need a little help to get the ball rolling.
If you are an arrogant, self aggrandizing prig, then nothing will stop you from thinking that the best hires are those that have memorized some abstruse features of Java (http://softarc.blogspot.com/2006/10/my-favorite-java-developer-interview.html). All I can say is, 'congratulations in hiring MENSA.' I personally want to work with talented people who are there to solve business problems not quibble over the esoteric technical aspects of Java.
Success is Failure. Failure is Success.
My company just went through a major production release and the only good thing I can say about it is, "Thank God it's almost over - hopefully." It has been one emergency after another, each more critical than the last. The executive team sent out a corporate wide email congratulating everyone's hard work and dedication. They also claimed that it was a total success with only a couple of challenges left to resolve. Either they are incredibly naive, incredibly lied to or just crazy.
I am just a lowly developer but I consider a release that limits our customers ability to effectively work with our system a failure; a complete failure. As always I can't go into detail as to what went wrong but I can reflect and try to identify why.
First, a corporate culture that cultivates deception and evasion is BAD and will always end the same way; badly. How does a company encourage such fraud? Mistakes always have a cause, but it takes a healthy corporate culture to look for the root of the mistake instead of the mistake maker. People are more apt to divulge mistakes and issues if they feel that they will not be harassed incessantly. Lets face it, everyone makes mistakes, any honest person hates making mistakes, nobody wants to admit they made a mistake, but if you feel confident that your mistakes will not be used against you in a court of blame, you are willing, if begrudgingly, to admit them as soon as they happen. The company I work for is okay at not flashing the light of shame on mistakes but it still has a long way to go.
Second, a common, unwavering and attainable goal is vital to identifying success and failure. A common goal is necessary to map the course of a all but the most trivial corporate initiatives. Without a common goal you might as well be herding cats, that is unless herding cats is your goal. To get everyone in the company going in the same direction they must know what that direction is. A common goal is necessary so that everyone has an objective way of identifying how well they are doing, or how poorly.
An unwavering goal is necessary in the same way that a common goal is but for a different reason. A common goal gets everyone going in the same direction, but an unwavering goal keeps them going and gives them constant feedback of their progress. A goal that keeps changing, for whatever reason, be it a revaluation of progress or a change to meet market needs is flux, and goal flux in a major project is a killer. If everyday you come to work you spend time discovering where the capricious decisions of executives are, then you're never able to make a conscience assessment of your progress. Did all that work you did yesterday, or last week, get you closer to the goal; If you don't know what the goal is from day to day how can you ever know?
An attainable goal is one that all stake holders can agree on. If every goal, initiative and time line arrives to the masses from on high, why in the hell would you expect anything but peasant work? The people who are doing the work must have a say in what is and what is not attainable. I realize that every executive wants it yesterday, and every developer would work an eternity to improve a sort algorithm but that shouldn't mean that a reasonable agreement can't be made, and a reasonable goal can not be forged. While reasonable is in the eyes of the beholder, I don't believe that should negate an attainable goal. Attainable goals will probably never make both side happy, a project will always take too long in the eyes of management, and will always be impossibly short for the developers. A goal must, I repeat, must be negotiated between all interested parties otherwise it is a dictate that will end up being a very quick pile of crap or a very slow pile of crap, but in the end it will always be a pile of crap produced by a bunch of pissed off developers who have no skin in the game (Thanks Darren for that apropos line).
Third, waterfall is dead; long live waterfall. If you are fortunate enough to work for a company that is truly Agile, congratulations you lucky S.O.B. If you are like most of the IT slobs out there you are still stuck with the drowning waterfall methodology. If you can, and by God try as hard as you can, adopt as much agile as you possibly can within the constraints of the falls. I know, I know, the purists would have you believe that you are either Agile or you are not. I don't believe in such hard and fast rule. I'm stuck in the Niagra Falls of waterfall methodology but I still practive test driven developement, collective ownership and simple design. I've tried several times to get continuous integration incorporated, and thus far I haven't had anything that can be called success, but I'll be damned if that's going to stop me. With every project I am getting my group closer and closer to being Agile.
Finally, if any of this sounds familiar, well, I'm sorry, but you are not alone. There are plenty of people in exactly the same boat as you are. Don't give up, you got into IT because you love solving problems and boy howdy is this ever a problem that needs solving. Keep fighting the good fight and tell me how it went, good or bad. Good luck.
I am just a lowly developer but I consider a release that limits our customers ability to effectively work with our system a failure; a complete failure. As always I can't go into detail as to what went wrong but I can reflect and try to identify why.
First, a corporate culture that cultivates deception and evasion is BAD and will always end the same way; badly. How does a company encourage such fraud? Mistakes always have a cause, but it takes a healthy corporate culture to look for the root of the mistake instead of the mistake maker. People are more apt to divulge mistakes and issues if they feel that they will not be harassed incessantly. Lets face it, everyone makes mistakes, any honest person hates making mistakes, nobody wants to admit they made a mistake, but if you feel confident that your mistakes will not be used against you in a court of blame, you are willing, if begrudgingly, to admit them as soon as they happen. The company I work for is okay at not flashing the light of shame on mistakes but it still has a long way to go.
Second, a common, unwavering and attainable goal is vital to identifying success and failure. A common goal is necessary to map the course of a all but the most trivial corporate initiatives. Without a common goal you might as well be herding cats, that is unless herding cats is your goal. To get everyone in the company going in the same direction they must know what that direction is. A common goal is necessary so that everyone has an objective way of identifying how well they are doing, or how poorly.
An unwavering goal is necessary in the same way that a common goal is but for a different reason. A common goal gets everyone going in the same direction, but an unwavering goal keeps them going and gives them constant feedback of their progress. A goal that keeps changing, for whatever reason, be it a revaluation of progress or a change to meet market needs is flux, and goal flux in a major project is a killer. If everyday you come to work you spend time discovering where the capricious decisions of executives are, then you're never able to make a conscience assessment of your progress. Did all that work you did yesterday, or last week, get you closer to the goal; If you don't know what the goal is from day to day how can you ever know?
An attainable goal is one that all stake holders can agree on. If every goal, initiative and time line arrives to the masses from on high, why in the hell would you expect anything but peasant work? The people who are doing the work must have a say in what is and what is not attainable. I realize that every executive wants it yesterday, and every developer would work an eternity to improve a sort algorithm but that shouldn't mean that a reasonable agreement can't be made, and a reasonable goal can not be forged. While reasonable is in the eyes of the beholder, I don't believe that should negate an attainable goal. Attainable goals will probably never make both side happy, a project will always take too long in the eyes of management, and will always be impossibly short for the developers. A goal must, I repeat, must be negotiated between all interested parties otherwise it is a dictate that will end up being a very quick pile of crap or a very slow pile of crap, but in the end it will always be a pile of crap produced by a bunch of pissed off developers who have no skin in the game (Thanks Darren for that apropos line).
Third, waterfall is dead; long live waterfall. If you are fortunate enough to work for a company that is truly Agile, congratulations you lucky S.O.B. If you are like most of the IT slobs out there you are still stuck with the drowning waterfall methodology. If you can, and by God try as hard as you can, adopt as much agile as you possibly can within the constraints of the falls. I know, I know, the purists would have you believe that you are either Agile or you are not. I don't believe in such hard and fast rule. I'm stuck in the Niagra Falls of waterfall methodology but I still practive test driven developement, collective ownership and simple design. I've tried several times to get continuous integration incorporated, and thus far I haven't had anything that can be called success, but I'll be damned if that's going to stop me. With every project I am getting my group closer and closer to being Agile.
Finally, if any of this sounds familiar, well, I'm sorry, but you are not alone. There are plenty of people in exactly the same boat as you are. Don't give up, you got into IT because you love solving problems and boy howdy is this ever a problem that needs solving. Keep fighting the good fight and tell me how it went, good or bad. Good luck.
Tests? We Don't Need No Stinking Tests!
I've been banging out test after test and it is so awesome to see the results. I'm still not fully doing TDD because its so new to me that I'm still writing a little code then a little test. Slowly but surely I'm starting to flip it around to doing a little test doing a little code. In fact, its been going so well that I've started to go refactor happy. I see some poorly written code, I write a test, make sure it passes and refactor. I know, I know, there should have been a test in place and writing tests for exiting code is dangerous because you tend to write the test to the code not the code to the test; but I have to do the best I can with a code base starting with 0% code coverage. Its now up to 1.3% that's not too bad considering there are 323,658 lines of code.
I think my skill with writing tests is starting to improve as well. I've read that when you first start to do TDD that you should aim for 100% code coverage but as I mature in my understanding of the goal and purpose of the tests, I've come to believe that 80% or more is acceptable. I test the crap out of classes that have serious business logic and I tend to only hit the happy path for classes that support that business logic.
By Friday I should be ready for my first iterative release. Since I don't have management buy off for XP I'm just going to release it to the Test environment and see if I can convince anyone else to take a look at it. Then maybe I can begin to convince people that seeing results sooner and making decisions on reality rather than on assumptions is far superior to how we've developed code in the past.
I think my skill with writing tests is starting to improve as well. I've read that when you first start to do TDD that you should aim for 100% code coverage but as I mature in my understanding of the goal and purpose of the tests, I've come to believe that 80% or more is acceptable. I test the crap out of classes that have serious business logic and I tend to only hit the happy path for classes that support that business logic.
By Friday I should be ready for my first iterative release. Since I don't have management buy off for XP I'm just going to release it to the Test environment and see if I can convince anyone else to take a look at it. Then maybe I can begin to convince people that seeing results sooner and making decisions on reality rather than on assumptions is far superior to how we've developed code in the past.
Everywhere I Look, I See Scared People
I've been trying to implement some Agile practices at work but at every turn I'm getting shot down. I try to implement rigorous unit testing and I hear, "I don't know, we may not have time to implement unit testing." What this is really saying: 'I don't know… We may not have time to create quality code’. I try to set up a CI machine and I'm told that machine is going to be flashed and donated. What that says to me: 'CI isn't important to us because we can always fix defects later.' I try to do iterative development and am told, "We need to wait until all requirements are in and signed off before we can begin developing." What that says to me, 'we expect our BA's and customers to be clairvoyant and know exactly how the system, they've never seen, will work.' I could go on and on; suffice it to say that becoming Agile is going to be like parting the Red Sea - both requiring an act of God.
I've been so frustrated that only one or two people at work truly see the benefits of Agile development. They are a huge help but even they are getting shot down. We have started to practice XP in secret. While this works it really is difficult to try and implement Agile without the support of the stake holders.
The frustrations of trying to adopt XP has made me wonder why it the world is everyone afraid of trying Agile even though the current waterfall system produces nothing but abysmal failure after abysmal failure; and the only conclusion I have is that they are just scared. Scared of change and scared of the unknown. What is worse is their fear of blame; whether real or imagined people are truly scared of being blamed for trying to improve the entrenched development process. It baffles me completely. I guess it is the developer in me who is always trying to solve a problem that can't understand keeping up appearances for a process that is obviously and irrecoverably broken.
All I can hope is that my continuous vigilance and determination will someday pay off and shed everyone’s fear of success. I guess I expected to meet some resistance implementing XP but I didn’t realize my biggest resistance would be fear.
I've been so frustrated that only one or two people at work truly see the benefits of Agile development. They are a huge help but even they are getting shot down. We have started to practice XP in secret. While this works it really is difficult to try and implement Agile without the support of the stake holders.
The frustrations of trying to adopt XP has made me wonder why it the world is everyone afraid of trying Agile even though the current waterfall system produces nothing but abysmal failure after abysmal failure; and the only conclusion I have is that they are just scared. Scared of change and scared of the unknown. What is worse is their fear of blame; whether real or imagined people are truly scared of being blamed for trying to improve the entrenched development process. It baffles me completely. I guess it is the developer in me who is always trying to solve a problem that can't understand keeping up appearances for a process that is obviously and irrecoverably broken.
All I can hope is that my continuous vigilance and determination will someday pay off and shed everyone’s fear of success. I guess I expected to meet some resistance implementing XP but I didn’t realize my biggest resistance would be fear.
Subscribe to:
Posts (Atom)