Thoughts on the code from the frontal lobe
My take on software engineering. Y'know?
Thursday 4 June 2009, 2:46 AM
A Peek into the JavaOne 2009 Classrooms
As an attendee of the 2009 JavaOne Conference, I was eager to drilldown into the latest and greatest Java technologies and technical session offerings.
Accordingly, I thought I’d start off by attending a session dedicated to the Java Platform SDK Version 7 (TS-5363). Unfortunately, to my despair, when I approached the designated classroom, I found that this session had been canceled.
Although I was a slightly disappointed, I knew that there where many other sessions to choose from. With only a few seconds to spare, I meandered along and found myself in a session entitled "Script Bowl 2009: A Scripting Languages Shootout" (PAN-5348). As a traditional Java applications developer, this session would have been my least favorite topic to explore. However, to my surprise, I found this session to be an interesting and excellent overview of the most popular and powerful Scripting Languages.
Basically, as with any piece of software or hardware, choosing a suitable Scripting Language depends upon the technical and business requirements; moreover, in this session, five major Scripting Language gurus battled it out. First of all, Groovy was presented; and for those traditional Java developers (such as myself) Groovy may be well suited as it has a Java-like syntax yet it is also agile and dynamic. Additionally, Groovy provides features that are currently unavailable in Java such as closures and regular expressions.
Secondly, the JRuby guru took the stage and praised JRuby for its reflective, dynamic and interpreted object-oriented concepts as well as all the interoperability with Java platform applications and existing Java user applications.
Third, there was a Jython demonstration, and for those Python programmers who are dedicated to the Python syntax but would like to utilize the plethora of Java Classes instead of Python modules, Jython could possibly be the antidote.
Fourth, the Scala representative showed off its code magic, and for those who prefer concise code, Scala provides the benefit of a short syntax and static typing which results in a boost in productivity. Scala is likewise seamlessly integrated with the Java libraries and existing Java application code.
Finally, Clojure (the newer kid on the block) was revealed. As it turns out, Clojure can very beneficial to concurrent programming in which deadlocks must be avoided. Actually, having worked on Artificial Intelligent systems that utilized both Lisp and Java, I found Clojure, given it’s similarities to Lisp, to be the most interesting of the Scripting Language that were discussed here.
After having my Bowl of Scripting Languages, I proceeded to find a session that was better suited for my interest so I selected a session entitled “Small Changes in JDK Release 7” (TS-4060). As the title suggests, changes and enhancements to the JDK are most likely to be release candidates if they are relatively small. This small partiality combined with a broad applicability predilection exists to ensure source compatibility, binary compatibility, and behavior compatibility. Currently, there are still 120 possibly proposed good language enhancements waiting to be born (or aborted).
So what language changes are we likely to see in SDK 7 and beyond? I’ll highlight a few that were of particular interest to me:
1.) Automatic Resource Termination – this change would eliminate the requirement of the developer to clean up his or her used resources. In particular, resource closing with those messy try-finally blocks or try-try-finally-finally blocks could be completely avoided. Great news, right?!
2.) The Diamond Operator < > – this enhancement would eliminate the need to retype the Generics on both sides of the assignment statement. Instead of repeating the full Generics syntax on the RHS of the statement, the developer would simple type < > on the RHS and the datatype would be implied from the LHS.
3.) Improved Exception Handling – this change allows developers to catch multiple exceptions in a single try-catch. For example, the following single statement would catch all three types of exceptions:
try { …
}
catch (NamingException, RemoteException, CreateException exc) {
…
}
Again, I view this one as a fantastic change - using a separate
try-catch for every possible exception gets rather cumbersome and
tedious.
4.) String Switch Statement - this change allows developers to define a switch statement based on the String type. For example, the following code would now be legal:
String input = “string”;
switch (input){
case "string":
System.out.println("I am a string!");
…
I personally feel that the String Switch enhancement was long overdue and I can’t wait to start employing it!
Well, now that’s a lot to look forward to! Additionally information on SDK Release 7 can be found on Joseph Darcy’s Project Coin website.
Accordingly, I thought I’d start off by attending a session dedicated to the Java Platform SDK Version 7 (TS-5363). Unfortunately, to my despair, when I approached the designated classroom, I found that this session had been canceled.
Although I was a slightly disappointed, I knew that there where many other sessions to choose from. With only a few seconds to spare, I meandered along and found myself in a session entitled "Script Bowl 2009: A Scripting Languages Shootout" (PAN-5348). As a traditional Java applications developer, this session would have been my least favorite topic to explore. However, to my surprise, I found this session to be an interesting and excellent overview of the most popular and powerful Scripting Languages.
Basically, as with any piece of software or hardware, choosing a suitable Scripting Language depends upon the technical and business requirements; moreover, in this session, five major Scripting Language gurus battled it out. First of all, Groovy was presented; and for those traditional Java developers (such as myself) Groovy may be well suited as it has a Java-like syntax yet it is also agile and dynamic. Additionally, Groovy provides features that are currently unavailable in Java such as closures and regular expressions.
Secondly, the JRuby guru took the stage and praised JRuby for its reflective, dynamic and interpreted object-oriented concepts as well as all the interoperability with Java platform applications and existing Java user applications.
Third, there was a Jython demonstration, and for those Python programmers who are dedicated to the Python syntax but would like to utilize the plethora of Java Classes instead of Python modules, Jython could possibly be the antidote.
Fourth, the Scala representative showed off its code magic, and for those who prefer concise code, Scala provides the benefit of a short syntax and static typing which results in a boost in productivity. Scala is likewise seamlessly integrated with the Java libraries and existing Java application code.
Finally, Clojure (the newer kid on the block) was revealed. As it turns out, Clojure can very beneficial to concurrent programming in which deadlocks must be avoided. Actually, having worked on Artificial Intelligent systems that utilized both Lisp and Java, I found Clojure, given it’s similarities to Lisp, to be the most interesting of the Scripting Language that were discussed here.
After having my Bowl of Scripting Languages, I proceeded to find a session that was better suited for my interest so I selected a session entitled “Small Changes in JDK Release 7” (TS-4060). As the title suggests, changes and enhancements to the JDK are most likely to be release candidates if they are relatively small. This small partiality combined with a broad applicability predilection exists to ensure source compatibility, binary compatibility, and behavior compatibility. Currently, there are still 120 possibly proposed good language enhancements waiting to be born (or aborted).
So what language changes are we likely to see in SDK 7 and beyond? I’ll highlight a few that were of particular interest to me:
1.) Automatic Resource Termination – this change would eliminate the requirement of the developer to clean up his or her used resources. In particular, resource closing with those messy try-finally blocks or try-try-finally-finally blocks could be completely avoided. Great news, right?!
2.) The Diamond Operator < > – this enhancement would eliminate the need to retype the Generics on both sides of the assignment statement. Instead of repeating the full Generics syntax on the RHS of the statement, the developer would simple type < > on the RHS and the datatype would be implied from the LHS.
3.) Improved Exception Handling – this change allows developers to catch multiple exceptions in a single try-catch. For example, the following single statement would catch all three types of exceptions:
try { …
}
catch (NamingException, RemoteException, CreateException exc) {
…
}
Again, I view this one as a fantastic change - using a separate
try-catch for every possible exception gets rather cumbersome and
tedious.
4.) String Switch Statement - this change allows developers to define a switch statement based on the String type. For example, the following code would now be legal:
String input = “string”;
switch (input){
case "string":
System.out.println("I am a string!");
…
I personally feel that the String Switch enhancement was long overdue and I can’t wait to start employing it!
Well, now that’s a lot to look forward to! Additionally information on SDK Release 7 can be found on Joseph Darcy’s Project Coin website.
Wednesday 4 June 2008, 7:50 PM
Finding the rationale behind IBM Rational: notes from the classrooms
To kick off my learning objectives while attending the IBM's 2008 Rational Software Developer Conference, I decided to approach the session offerings in the same fashion as I would if I were going to develop a system. As such, I started my day by attending the Requirements and Analysis (RA01) session.
After all, shouldn’t all system development start with requirements analysis?
From this session, I gathered that IBM engineers are pretty much focused on addressing many of the requirement analysis issues that have been haunting me. One challenge that I have been contending with in my recent experience is how to best convey system requirements to my customer.
Reconciling this issue has been rather challenging as customers don’t generally want to spend the time to review the massive amount of text (i.e. “The system shall…”) that is found in the typical requirements document. Likewise, customers don’t generally understand UML so simply showing them UML diagrams may not necessarily solve the problem either.
To assist with these issues, the IBM engineers suggested several options including incorporating Storyboards, Simulations, and Model Business Processes which can all be integrated into your IBM' Rational RequisitePro requirement management tool.
Speaking of RequisitePro, IBM also mentioned that a new beta release of RequisitePro will be available shortly. Along with ReqWeb enhancements and the integration of an open source reporting option, in this release, we are going to be blessed with enhanced security at the package and view levels.
Having worked as a government contractor in cleared environments for years, this enhancement has numerous beneficial implications. As you might imagine, being able to create views for various levels of sensitive compartmental information securely can provide requirement analysis opportunities for engineers according to varies rules, roles and clearance levels. To date, in my experience, if an engineer does not have the all clearance credentials at the highest level of the system, the engineer is forbidden to work on any component of the system.
Other interesting requirement related news coming from this session was that the IBM engineers are committed to supporting and continuing the development of their recently acquired Telelogic DOORS. In fact, along with the Rational RequisitePro, IBM engineers are working toward the eventual integration of DOORS into the Jazz collaboration platform. This is good news because when it comes to requirement analysis “One size does not fit all.” The rationale behind Rational’s commitment is that DOORS is well suited for large scale projects with government compliance while RequisitePro maintains its lead with IT compliance. Good news for all, don’t you think?
Moving on with my sessions, I decided to broaden my base knowledge in Use Cases by attending the Use Case for Complex Applications and Systems-of-Systems (BPM02) course. As I’ve worked on extremely complex signal processing programs, I was eager to gain insight into how to develop more effective Use Cases.
First, the IBM instructor outlined the huge distinction between a Process and Use Case. I’m sure I’ve confused these technical terms before. It was noted that Process is not a cause and effect relationship; moreover, it is a fallacy (post hoc ergo propter hoc) to assume that it does. The example of this fallacy given was the common notion that lightning causes thunder. This notion is in fact incorrect as, although thunder may be correlated to lightning, thunder is actually caused by the movement of air due to the temperature differences causing vibrations in the air, hence causing the noise. Consequently, the IBM instructor simply defined a “Process” as a set of actions.
Image source: Morguefile
On the other hand, a Use Case was described as a complete usage of a system. The purpose of the Use Case is to represent the real goals of the user. The simple example given was a “Drive to work” Use Case. Driving to work can be decomposed into operations such as “Start your car”, “Step on the gas”, “Turn the steering wheel” etc. however, the complete usage and real goal of the user is to drive to work.
All the activities that are performed to achieve the real goal of the user are actually Operations of the “Drive to work” Use Case. These Operations, however, can become Use Cases for Systems-of-Systems or lower level Use Cases. This process of decomposing was defined as Recursive Modeling.
So how far do you decompose? Well, until you have an independent unit that you can build from. For me, the Base Case in Recursive Programming comes to mind. Of course, I was always told that using recursion was a bad; nevertheless, I suspect recursion has its place here.
After all, shouldn’t all system development start with requirements analysis?
From this session, I gathered that IBM engineers are pretty much focused on addressing many of the requirement analysis issues that have been haunting me. One challenge that I have been contending with in my recent experience is how to best convey system requirements to my customer.
Reconciling this issue has been rather challenging as customers don’t generally want to spend the time to review the massive amount of text (i.e. “The system shall…”) that is found in the typical requirements document. Likewise, customers don’t generally understand UML so simply showing them UML diagrams may not necessarily solve the problem either.
To assist with these issues, the IBM engineers suggested several options including incorporating Storyboards, Simulations, and Model Business Processes which can all be integrated into your IBM' Rational RequisitePro requirement management tool.
Speaking of RequisitePro, IBM also mentioned that a new beta release of RequisitePro will be available shortly. Along with ReqWeb enhancements and the integration of an open source reporting option, in this release, we are going to be blessed with enhanced security at the package and view levels.
Having worked as a government contractor in cleared environments for years, this enhancement has numerous beneficial implications. As you might imagine, being able to create views for various levels of sensitive compartmental information securely can provide requirement analysis opportunities for engineers according to varies rules, roles and clearance levels. To date, in my experience, if an engineer does not have the all clearance credentials at the highest level of the system, the engineer is forbidden to work on any component of the system.
Other interesting requirement related news coming from this session was that the IBM engineers are committed to supporting and continuing the development of their recently acquired Telelogic DOORS. In fact, along with the Rational RequisitePro, IBM engineers are working toward the eventual integration of DOORS into the Jazz collaboration platform. This is good news because when it comes to requirement analysis “One size does not fit all.” The rationale behind Rational’s commitment is that DOORS is well suited for large scale projects with government compliance while RequisitePro maintains its lead with IT compliance. Good news for all, don’t you think?
Moving on with my sessions, I decided to broaden my base knowledge in Use Cases by attending the Use Case for Complex Applications and Systems-of-Systems (BPM02) course. As I’ve worked on extremely complex signal processing programs, I was eager to gain insight into how to develop more effective Use Cases.
First, the IBM instructor outlined the huge distinction between a Process and Use Case. I’m sure I’ve confused these technical terms before. It was noted that Process is not a cause and effect relationship; moreover, it is a fallacy (post hoc ergo propter hoc) to assume that it does. The example of this fallacy given was the common notion that lightning causes thunder. This notion is in fact incorrect as, although thunder may be correlated to lightning, thunder is actually caused by the movement of air due to the temperature differences causing vibrations in the air, hence causing the noise. Consequently, the IBM instructor simply defined a “Process” as a set of actions.
Image source: Morguefile
On the other hand, a Use Case was described as a complete usage of a system. The purpose of the Use Case is to represent the real goals of the user. The simple example given was a “Drive to work” Use Case. Driving to work can be decomposed into operations such as “Start your car”, “Step on the gas”, “Turn the steering wheel” etc. however, the complete usage and real goal of the user is to drive to work.
All the activities that are performed to achieve the real goal of the user are actually Operations of the “Drive to work” Use Case. These Operations, however, can become Use Cases for Systems-of-Systems or lower level Use Cases. This process of decomposing was defined as Recursive Modeling.
So how far do you decompose? Well, until you have an independent unit that you can build from. For me, the Base Case in Recursive Programming comes to mind. Of course, I was always told that using recursion was a bad; nevertheless, I suspect recursion has its place here.
Thursday 8 May 2008, 12:13 AM
JavaOne: notes from the classroom
This blog continues the reports I’m making on perceptions of JavaOne which I am attending this week in San Francisco.
'
TS-6623 More Effective Java
Following my session experience previously detailed in my husband Adrian Bridgwater’s blog, I decided that it might advantageous to get some insight into becoming a more effective Java developer.
From this session, I took away several good practices to help my Java become more effective. First, I realized the benefits of using Enum types versus using Bit Fields. As a former C, C++ developer, I have always been very comfortable using Bit Fields (i.e. long[], long [] [] ) to represent Enums and EnumMaps. But, what I didn’t consider when using this representation was that:
1.) Bit Fields are not typesafe as there isn’t a namespace associated with them.
2.) Bit Fields do not scale beyond 64 bits.
3.) Iterating over Bit Fields is a rather tricky logic.
4.) Bit Fields can be cryptic and difficult for your fellow developers to maintain.
On the other hand, by using Enums, Jumbo Enum Sets and EnumMaps, all of the above issues are reconciled with the same fast system performance as if I were using my old-style Bit Fields.
Also, this session provided me with some insight into using generics, which was fantastic as I haven’t had a lot of practice with the generic specification. One handy mnemonic that I learned that will surely be useful is PECS (Producer Extends Consumer Super). PECS can help you remember when to employ ‘extend’ and when to employ ‘super’.
Finally, this session suggested the use of 'Lazy Initialization' when appropriate. 'Lazy Initialization' involves delaying the initialization of an object until the value is actually needed. If you want to insure a higher performance or you want to reconcile an initialization circularity, you should definitely think about this tip! I know I am!
- - - - - -
TS-5581 Upcoming Java Programming Language Changes
Moving forward with my learning objectives, I thought it was beneficial for me to push ahead and attend the upcoming Java Programming Language Changes session. This session provided me with insight into the evolutionary process as well an inkling as to what the possible new features might be.
To start with, a definite distinction was illustrated between an Application and a Language. The key difference is that an Application is rich with many features and a Language is pure and simple with few features. Moreover, creativity in a Language design can be deleterious.
To insure that the Language maintains its purity, I became aware of the three conditions that must always be adhered to. These conditions include:
1.) Respect the Past – insure that adding, modifying or removing new features does not break existing features.
2.) Respect the Future – insure that you leave room for the syntax to breath.
3.) Respect the Model – insure that the model maintains its principles with respect to OO (classes), Interfaces (Abstraction) and Actors (IPC).
Following these purity conditions, this session relayed four principles of a language evolution. These principles are as follows:
1.) Language evolution should encourage high-level languages.
2.) Language evolution should encourage code clean – more code readers than writers.
3.) Language evolution should encourage the use of static types - increases confidence in code.
4.) Language evolution should be cognizant of the fact that the language is more widespread than the APIs, which are often deprecated.
Lastly, to everyone's anticipation, this session sketched out a few of the possible new features that may be soon incorporated into the Java Programming Language. Some of these features include extensions in annotations, a multi-catch statement, a safe re-throw and a great focus on modularity in terms of packages, access controls and interfaces.
To aid with the new modularity feature, a new restricted keyword is suppose to be incorporated. This new keyword is 'module' and it is expected to be released in SE7! By using 'module', developers can create modules at the top-level package level. How exciting is that?!?
- - - - - -
I hope to report tomorrow on the below…
TS-6589 Defective Java Code: Tuning WTF Code into a Learning Experience
'TS-6623 More Effective Java
Following my session experience previously detailed in my husband Adrian Bridgwater’s blog, I decided that it might advantageous to get some insight into becoming a more effective Java developer.
From this session, I took away several good practices to help my Java become more effective. First, I realized the benefits of using Enum types versus using Bit Fields. As a former C, C++ developer, I have always been very comfortable using Bit Fields (i.e. long[], long [] [] ) to represent Enums and EnumMaps. But, what I didn’t consider when using this representation was that:
1.) Bit Fields are not typesafe as there isn’t a namespace associated with them.
2.) Bit Fields do not scale beyond 64 bits.
3.) Iterating over Bit Fields is a rather tricky logic.
4.) Bit Fields can be cryptic and difficult for your fellow developers to maintain.
On the other hand, by using Enums, Jumbo Enum Sets and EnumMaps, all of the above issues are reconciled with the same fast system performance as if I were using my old-style Bit Fields.
Also, this session provided me with some insight into using generics, which was fantastic as I haven’t had a lot of practice with the generic specification. One handy mnemonic that I learned that will surely be useful is PECS (Producer Extends Consumer Super). PECS can help you remember when to employ ‘extend’ and when to employ ‘super’.
Finally, this session suggested the use of 'Lazy Initialization' when appropriate. 'Lazy Initialization' involves delaying the initialization of an object until the value is actually needed. If you want to insure a higher performance or you want to reconcile an initialization circularity, you should definitely think about this tip! I know I am!
- - - - - -
TS-5581 Upcoming Java Programming Language Changes
Moving forward with my learning objectives, I thought it was beneficial for me to push ahead and attend the upcoming Java Programming Language Changes session. This session provided me with insight into the evolutionary process as well an inkling as to what the possible new features might be.
To start with, a definite distinction was illustrated between an Application and a Language. The key difference is that an Application is rich with many features and a Language is pure and simple with few features. Moreover, creativity in a Language design can be deleterious.
To insure that the Language maintains its purity, I became aware of the three conditions that must always be adhered to. These conditions include:
1.) Respect the Past – insure that adding, modifying or removing new features does not break existing features.
2.) Respect the Future – insure that you leave room for the syntax to breath.
3.) Respect the Model – insure that the model maintains its principles with respect to OO (classes), Interfaces (Abstraction) and Actors (IPC).
Following these purity conditions, this session relayed four principles of a language evolution. These principles are as follows:
1.) Language evolution should encourage high-level languages.
2.) Language evolution should encourage code clean – more code readers than writers.
3.) Language evolution should encourage the use of static types - increases confidence in code.
4.) Language evolution should be cognizant of the fact that the language is more widespread than the APIs, which are often deprecated.
Lastly, to everyone's anticipation, this session sketched out a few of the possible new features that may be soon incorporated into the Java Programming Language. Some of these features include extensions in annotations, a multi-catch statement, a safe re-throw and a great focus on modularity in terms of packages, access controls and interfaces.
To aid with the new modularity feature, a new restricted keyword is suppose to be incorporated. This new keyword is 'module' and it is expected to be released in SE7! By using 'module', developers can create modules at the top-level package level. How exciting is that?!?
- - - - - -
I hope to report tomorrow on the below…
TS-6589 Defective Java Code: Tuning WTF Code into a Learning Experience
