Tuesday, September 9, 2008
While I haven't yet tried this with Rails, I did make a recommendation (after using it myself) that we switch some of our simpler new CRUD applications to use grails. Heck, why screw around manually wiring in spring/hibernate/etc when you can use grails and get all kinds of neat things for free?
The first problem we're struggling with in grails is that there are some cool and super ways to get things done, but because we can always revert to java, most people just do it the "java way". This means we've forsaken the safety of compile time checking and gained ... nothing.
The second problem is that, even if one decides to forage into the groovy/grails way of doing things, there is more than one way to do it^4 and our code begins to look a lot like hacked together perl modules. The newness of the language is a pitfall for folks who absolutly require it to have been done before
Sunday, July 20, 2008
I wonder why google uses python so extensively. I've used it for a number of things and find it very useful, but it just doesn't seem to have the momentum in corporate america of the "big J". On the other hand, it has tremendous street cred and is embedded in tons of open source tools.
I found an interesting writeup here: Python at Google (Greg Stein - SDForum) it looks like google architects from the ground up and the guys on the ground said "python works for us".
Saturday, July 5, 2008
The exciting thing is the ability of portlets to communicate with each other, the down side seems to be this is not a core portal capability (certainly not from a client side perspective). Some interesting reads are:
This latter link is a better statement of my problem.
Sunday, June 22, 2008
It was very interesting to see the perspective of the consultants who taught the class. The material was very relevant and the discussions with my peers in our organization where good. By the middle of day two I really began to question the point of the class. Much of what was discussed was very necessary for a consulting organization and I would argue has value in any IT department, but I'm not sure it was solving problems we need solved.
In discussion after the class, one major problem we need to address is what I call the "road to nowhere" problem. We're furiously building solutions, setting standards, generally doing a bang-up job getting things done; but we're not sure where we're going or worse yet, if anyone else is going to want to go there also. Adding to the problem, we are not sharing our findings with our peers (or are doing it inconsistently) so we're solving the same problems over and over again.
I've started making noise about getting serious about our document management and information organization. We cannot be successful without this and it is much more fundamental than "architectural thinking".
Tuesday, May 13, 2008
So now we have a situation where we have an 80 hour development effort saddled with 20 hours of meetings, status reports, use case writeups, blah blah blah. None of which is actually used for actual development and none of which enhances the interaction with the customer. There is a sore need to bring the agile process into the fold of SDLC and start espousing that Agile IS SDLC, just a different version from waterfall.
Friday, May 9, 2008
I recently proposed we open source some software we are writing. I did this it's a pretty cool concept and we cannot afford any developers. I went and spoke with a few of my cohorts at other companies and they thought it would be a cool project to work on, but our company cannot currently afford to pay these folks.
Hmmmm, what to do? I know! we'll make the core infrastructure of the project open-source.... perhaps get a free version of Jira/confluence and start building a communnity around it.
This has the benefit of getting some (potentially) high quality developers to work in it for free, and additionally if I leave, I get to use this software at my new location. From my employers perspective, they will still get fixes after I leave (it's open source, everyone will right?). This sounds like such a win win win situation that I was excited to share this idea with my team.
Needless to say it did not fly well and a somewhat blank stare was about all I got. I see it will take some more wrangling to drum up support for this, there was not a huge amount of support for the concept.
Monday, May 5, 2008
Tuesday, April 29, 2008
As a prime offender, I kept my mouth shut, but certainly had a few pointed questions I really wanted to ask. It's great to SAY we should all be on time for every meeting, and we should respect everyone's opinion, but DOING that is a little more problematic.
In the past, I personally had an average of about 3 hours of meetings per day. These were recurring, scheduled meetings, that I typically sat in and listened to other people talk. Truly there was probably about 2 hours of meetings per week that I actually had conversations and constructive/useful information that was communicated.
I actually think the problem should be turned around and we should make sure that meetings are useful. To me, a 1 way dissemination of information is best served by an email message. Meetings should be reserved for face to face interactive discussions. If you routinely have to say "we don't have time to talk about that right now" then you probably don't need a meeting because you don't want a discussion, you simply want to dispense with information or instructions.
Monday, April 28, 2008
Sunday, April 27, 2008
Frankly, I was stunned. I was told the meeting was to discuss what sort of hardware we needed and where it was going to be deployed.... Suddenly I'm asked to justify using JBoss instead of websphere to a bunch of fairly skeptical folks who where VERY interested in using websphere at all costs (for some reason).
Well, I stammered and stumbled since I wasn't really prepared to answer this and I could almost hear the folks on the other end of the call tapping their fingers on the table, waiting expectantly for my answer for them to instantly debunk.
I stopped for a full minute, my entire mind switching gears from "what sort of hardware/capacity might we need" to "why do you want to use JBoss instead of Websphere".
I then proposed the obvious thing (to me) "Well, Jboss is free".
Of course this was a ridiculous reason for using software. I was promptly schooled on how we would NEVER, EVER deploy FREE software, we absolutely MUST pay for it. After all, who would support it?
So I was a little bit shaken (not stirred) and had to think about it. To me, it is really great to be able to actually diagnose production problems by looking at the source code and figure out what went wrong. Most closed source companies don't really like you doing that (unless you pay them a WHOLE LOT of money).
This paper goes into some depth explaining how nonlinear functions can be used to analyze disaster response. I got increasingly interested as I realized that, in some ways, information technology has parallels to disaster response. More importantly, nonlinear math has a huge potential to help analyze and solve many information technology problems.
I did a little more research and stumbled upon this gem and began reading it:
Organizations and Chaos: Defining the Methods of Nonlinear Management
Book by H. Richard Priesmeyer; Quorum Books, 1992. 258 pgs.
This is written by the same person who did the disaster response paper and is a compelling read. The reason it's so interesting to me is that these problems have exact correlations to many problems I see with software development. For now, I'm going to finish this book and I'll follow up later with some 3/4 baked ideas.
Friday, February 8, 2008
We've seen some pushback from people who seem to think that they always know exactly what is going on, so there's nothing in it for them. After all, we have a daily status meeting to review everyone's changes, we print off all our status reports and go over them on by one. What could be simpler?
I'm not sure how to explain the value proposition of a wiki to folks who think that a daily status meeting is the most effective way to keep everyone informed.
Sunday, January 27, 2008
If you don't understand, but are trying to market things on the web or design a web interface, please read the following:
Craptastic examples include most, if not all the big-box retailers:
Nicely done stretchy design is: