gvaughn's bloghttp://www.java.net/blogs/gvaughn
enNaked Objects Exposedhttp://www.java.net/blog/gvaughn/archive/2003/10/naked_objects_e.html
<!-- | 0 --><p>I think I now have a handle on what makes <a href="http://www.nakedobjects.org/">Naked Objects</a> interesting. I had previously perused the site and came to the preliminary conclusion that it's just a generic UI framework. Last night at the <a href="http://www.pragmaticprogrammer.com/cgi-local/pragprog?DallasPractitioners">DFWPP</a> (Dallas-Ft.Worth Pragmatic Practitioners) meeting I got to hear <a href="http://pragprog.com/pragdave">Dave Thomas</a> talk about Naked Objects (and believe me, it is a topic rich with double entendres). It helps me to think of Naked Objects in a parallel manner to TDD (Test Driven Development).
</p>
<p>On the surface TDD looks like it is primarily a means of testing. The 'aha' moment happens when you invert your thinking. TDD is primarily a design tool, and secondarily a testing method. It ends up that testable code is more cohesive and loosely coupled, and that's the major benefit. My 'aha' moment with Naked Objects happened when I began to see it as primarily a design and requirements gathering tool, and secondarily a UI framework. Coding in Naked Objects style promotes minimal temporal coupling (the GUI is modeless), complete business rules in the business objects (none of it hanging in the GUI layer), and explicit relationships between business objects (so the GUI knows what can be dragged and dropped onto what).
</p>
<p>So, just as TDD taught us that <em>testable</em> code is well designed code, so now Naked Objects are teaching us that <em>naked</em> (or maybe <em>strippable</em>?) code is well designed code. Also in a parallel vein, we know that the unit tests from TDD are rarely going to be a sufficient amount of testing, so also the GUI of Naked Objects is rarely going to be a sufficient GUI. Just as the more traditional functional, system, and user acceptance tests can be added to a TDD-built system, so too can a more traditional menued, or script-driven GUI be added to a Naked Objects-built system.
</p>
<p>Dave will be giving that Naked Objects talk (and also one on Coupling! I warned you about the double entendres) at the <a href="http://www.nofluffjuststuff.com/2003-10-atlanta/index.jsp">Atlanta Java Software Symposium</a> this coming weekend. Come if you can! &lt;shameless-plug>You can even hear me speak on JMX, IO Performance Tuning, and Expressive Code there too.&lt;/shameless-plug></p>
http://www.java.net/blog/gvaughn/archive/2003/10/naked_objects_e.html#commentsWed, 22 Oct 2003 21:43:13 +0000gvaughn231981 at http://www.java.netJMX and Jinihttp://www.java.net/blog/gvaughn/archive/2003/09/jmx_and_jini.html
<!-- | 0 --><p>
About a month ago, I wrote about <a href="http://weblogs.java.net/pub/wlg/286">using JMX to manage JavaSpaces and Jini services.</a> Now I've found an article by Frank Jennings doing it inside out. He's <a href="http://www.sys-con.com/java/articleprint.cfm?id=2201">discovering a JMX server via Jini</a>. I'm glad to see people combining Jini with J2EE.
</p>
<p>
I wonder.... if you combined both approaches, would that create a tear in the fabric of spacetime?</p>
http://www.java.net/blog/gvaughn/archive/2003/09/jmx_and_jini.html#commentsJiniWed, 10 Sep 2003 02:15:01 +0000gvaughn231437 at http://www.java.netMission Impossible: Requirementshttp://www.java.net/blog/gvaughn/archive/2003/08/mission_impossi.html
<!-- | 0 --><p><em>Mr. Big Shot at AverageCorp has just given a four sentence vision statement of a new software project. Your mission, if you choose to accept it, is to understand what in the world he's talking about and make him happy with the resulting software.</em></p>
<p>
<em>This blog entry will self destruct in 30 seconds....</em></p>
<p>
This entry is a follow-up to my <a href="http://weblogs.java.net/pub/wlg/356">Fundamental Problem with Extreme Programming</a>, the great comments it generated, and Philip Brittan's <a href="http://weblogs.java.net/pub/wlg/361">XP, User Champions, and Software Vendors</a>. It's great seeing the conversations flow. It helps me to refine my own ideas as I get feedback from a larger group than just the folks I meet in person. I've also recently read a <a href="http://www.codeproject.com/books/1590590082_5.asp">free requirements chapter</a> of Christopher Duncan's book, <a href="http://www.showprogramming.com/TheCareerProgrammer.asp">The Career Programmer</a> which I've just added to my reading list.</p>
<p>
Like Philip, I have been in a situation with a self-appointed project champion who knew the business and was extremely interested in software. It was great to develop on that project for a while, but things went south very quickly when she started throwing around political clout she didn't really have and ended up leaving the company. Be aware of the failure mode of this approach. We became scapegoats when she left even though we'd done everything she asked of us.</p>
<p>
I've known very few software projects that fail due to technical reasons. It's almost always political. It is usually an issue of either not understanding the business needs, or writing the software to please the wrong person(s). Because of this, focusing on optimizing the efficiency of the pure development effort, like XP, doesn't really help the underlying issue. Those of us typically introverted, logic-ruled developer types are going to have to determine to learn something about corporate politics. Yes, I actually believe that though I do not relish it.</p>
<p>
What this means is that we're going to have to identify the head person that needs to be happy with the software, get some high level of understanding of what it'll take to do that, plus get him to delegate the details to someone or some group that we'll spend a lot more time with to wring out the details. Convincing him to spend his business people's time on this is going to require something akin to espionage. We've got to get inside his head and figure out how to present things in such a way that they further his individual goals. Also, keep in mind that his personal goals may not always be in line with just improving the corporation's bottom line (the logical position we techies like to argue from). In some cases, he'd get more political clout by having control of a bigger budget. We've got to learn what motivates him and adjust our approach based upon this knowledge</p>
<p>
I'm not advocating dishonesty, but we techies need to step out of our navel-gazing tech-only mode and learn something about those topics that we typically say with a sneer on our face or while rolling our eyes -- politics, marketing, business processes, chain of command, etc. This is going to vary from project to project, and therefore a one-size-fits-all, the true cost of requirements are in your face, approach of XP doesn't work. It can work in the rare case you've got a project sponsor who's open to it, but your toolbox needs to have more options available to you.</p>
<p>
I also have the feeling that demonstrating to the business sponsors that we know what they want politically in addition to the software technicalities, and learning to speak their language can also help with the issue of having our jobs outsourced. The real issue of requirements is figuring out what it'll take to please the person in the right political position. Enterprise software is never developed in a political vacuum, and we can either choose to accept that fact and work within its framework, or continue in our frustration and gripe amongst ourselves at how things <em>should</em> be done.</p>
http://www.java.net/blog/gvaughn/archive/2003/08/mission_impossi.html#commentsBusinessWed, 13 Aug 2003 20:46:13 +0000gvaughn231508 at http://www.java.netFundamental Problem with Extreme Programminghttp://www.java.net/blog/gvaughn/archive/2003/08/fundamental_pro.html
<!-- | 0 --><p>Matt Stephens gives some <a href="http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp">strong arguments against Extreme Programming</a>. It's a long article, but worth a read if there's just something about XP that doesn't <em>feel</em> right to you. Now, I think he does go off into rant mode in places (and he's also trying to sell you something), but the article was helpful to me to really put my finger on the fundamental problem with XP.</p>
<p>
XP requires too much of an investment from the business. Even aside from the obvious on-site customer that XP requires (and Mr. Stephens makes a good case that the best you'll get is a junior person) there's the regular unfinished (and unpolished?) versions of the software they're expected to use and give feedback about in the Planning Game every few weeks. There's also the ideal of the business users working to develop the acceptance tests.</p>
<p>
It's like watching sausage being made. Business users are not techies, and generally don't want to become techies. They want the software, and they want it with a minimum of <em>their</em> effort. The overall development efficiency that XP is built around actually decreases the business users' efficiency in doing their own job during the development. They find it tiring to think like a techie and answer all the detailed questions about how various requirements interact and handling all sorts of 'what if' scenarios.</p>
<p>
Please, don't misunderstand me, gentle reader. I do respect XP. It has served as the spark that got people (me included) thinking more about Agile methods in general (though the <a href="http://bossavit.com/thoughts/archives/000115.html">ideas go back much further than that</a>). I've written in more detail about <a href="http://gigavolt.net/blog/2003/04/30#xporagile">why I choose to associate myself with the Agile movement rather than XP</a> before. The gist of which is best explained by comparing XP to Free Software (FS) and Agility to Open Source Software (OSS). XP/FS adhere to uncompromising purity of their ideal. Agility/OSS agree with those ideals, but realize compromises must be made in the name of practicality. XP/FS have actually become special cases of the broader Agility/OSS categories.</p>
<p>
I guess I'm just a practical sort of guy.
</p>
http://www.java.net/blog/gvaughn/archive/2003/08/fundamental_pro.html#commentsBusinessTue, 12 Aug 2003 04:06:01 +0000gvaughn232524 at http://www.java.netJavaSpaces Still Alivehttp://www.java.net/blog/gvaughn/archive/2003/07/javaspaces_stil.html
<!-- | 0 --><p>I've long watched the JavaSpaces and Jini community because it is such a great technology, but sadly from a work experience standpoint, I haven't had a chance to really get my hands dirty. That's still the case, but I have new hope. <a href="http://www.jpower.org/documentation/">JPower </a> has released a free (as in beer) JavaSpace JMX component. It runs in any JMX container. It offers hot deployable JavaSpaces, backed by persistent storage via JDBC, and optional security via SSL. Coming in the next release is a Jini services container.
</p>
<p>
This is a really great (and subversive) idea. I wish I'd thought of it. I'm noticing a lot of work down below the level of J2EE. In some sense, it seems that J2EE has been developed backwards. Servlets came along first which is at the presentation layer, later EJB's came along for business logic. Next came CMP Entity Beans warts and all. Now JDO seems to be taking over the mindshare for persistence. However, the lower layers of infrastructure came later, or at least showed up with very little visibility. JNDI is an important layer that showed up with EJBs. Later came JMX, and then app server vendors worked furiously to build the foundations of their products on JMX. That's where the real low level foundation exists today. Aspect Oriented techniques (or Interceptor oriented if you prefer) are being using to more modularly implement much of these underpinnings.I also hear that Jini is even being used in some places for clustering of the app servers.
</p>
<p>
The subversive part (and I use that in the fondest sense) is now using JMX to get JavaSpaces and Jini in the picture as peers of the JMX managed web and EJB containers. JPower is the first I've heard of this, but I'll bet it won't take long for other vendors to do the same. Later on Sun might even catch up and make them part of the J2EE spec.
</p>
<p>
I'm excited that this might be the first step taking JavaSpaces and Jini to the mainstream. Go JPower!
</p>
http://www.java.net/blog/gvaughn/archive/2003/07/javaspaces_stil.html#commentsJiniTue, 29 Jul 2003 23:53:26 +0000gvaughn231887 at http://www.java.netHow to Become a Java Guruhttp://www.java.net/blog/gvaughn/archive/2003/07/how_to_become_a.html
<!-- | 0 --><p>
I'm probably preaching to the choir here, but hear me out just in case. I'm not speaking from the position of having already achieved guru status, but I think I've got a handle on the path to get there. Correct me if I'm wrong.
</p>
<p>
Find some giants, and stand on their shoulders, to co-opt Isaac Newton's famous quote. I don't mean this as a way of keeping someone else down, but instead building upon their insight and work. Become aware of what's offered in the Java libraries you work with, be it J2EE, J2SE, or J2ME. There's lots of good stuff in there that often gets overlooked. Case in point: the other day I was doing a methodology exercise of breaking a feature into individual tasks. The feature was logging into a J2EE application. Out of about six groups particpating in the exercise, mine was the only one that had a tasks of learning the basics of <a href="http://java.sun.com/products/jaas/">JAAS (Java Authentication and Authorization Service)</a> and configuring it in the appserver. All the other groups were ready to write their own custom login logic. I've never used JAAS before, but I've read an overview and knew it was commonly supported in J2EE containers (It's actually now part of J2SE 1.4.) and was specifically intended to be a reusable login service.
</p>
<p>
Now, the first time learning and using a new API may not save you any time over a scratch custom implementation, but it will save time the second and subsequent times you need to use it. Think over the long term about all these APIs you've had some experience with and how much faster you can do the well known pieces of your application. That frees up more time to work on the truly unique aspects of the particular application. Not only that, but coworkers will notice your experience and start coming to you for advice and you'll be able to help the speed of your entire team.
</p>
<p>The real key is having an awareness of what's already been written. There's several ways of doing this. For the official stuff, look at the Java optional packages, read the spec for J2xx, visit jcp.org. Visit hubs of open source packages: jakarta, sourceforge, and now right here at java.net too. Subscribe to an industry journal, a developer's journal (and once you have those, take a few minutes every now and then to see what's being advertised for commercial tools and frameworks). And last, but not least, read weblogs. They're full of pointers to all sorts of great tools you'd never otherwise hear of.
</p>
<p>There really is a mountain of information out there, but you're main job is to skim off the top. Mostly you're looking to find out what a product/tool/framework <em>can</em> do. Don't get immediately bogged down in <em>how</em> to use it. You can learn that later if/when the time comes. Initially look into those things that interest you and/or might be useful to you in the near future. Later you'll start to branch out.
</p>
<p>For some concrete examples, lately I've had a great time with <a href="http://java.sun.com/products/JavaManagement/">JMX</a> and <a href="http://java.sun.com/products/jndi/">JNDI</a>. JMX has allowed me to write and then reuse a component with zero code changes. JNDI has become by favored tool for promoting loose coupling and easy unit testing. In just now looking up that JAAS is now a part of J2SE, I also discovered <a href="http://java.sun.com/j2ee/javaacc/">The Java Authorization Contract for Containers</a> which I need to look into! Catch you later.</p>
http://www.java.net/blog/gvaughn/archive/2003/07/how_to_become_a.html#commentsJ2EEWed, 16 Jul 2003 23:07:21 +0000gvaughn231672 at http://www.java.net