So, what might you have eaten for lunch? How about during college? Or late-night coding sessions? I still eat Ramen noodles!

Momofuku Ando ring a bell? Didn’t with me either. How about “Ramen Noodles?”

At the age of 96, Momofuku died this past Friday (6 Jan 07). And to think, the day before he had Chicken Ramen for lunch with Nissin employees!

So, next time you grab that 3-minute meal while you are waiting for a compile or contemplating that next great solution, say a short prayer of thanks to Momofuku and send best wishes to his family.

Three passes at building as simple of a system as we could to allow for a dynamic JSP based on a 2-dimensional menu matrix… Tabs across the top, selecting one and you get various left nav tabs. Select a left nav and you get a list of those objects and the data for the first one in the list. The idea was to maintain the menu system in a database table to allow ease of change. First implementation was very bulky and expensive — too many files!

Many late nights… 103 deg fever for Lee. After second failed attempt, Lee says “I’m out of ideas.”

That scared me… Lee out of ideas? He’s one of the best we have! He’s one of “our guys.” You know the kind. Ask him anything, and he can offer help or a solution or just get it done!

I kept trying to bring the solution back to simplesville. So the next morning I set out with pen and paper and went back to the drawing board. We have a two-pronged object model, with a 1..* between the two top core objects. Then simply other “stuff” hanging off of those root objects via associations. The menu system is merely a way to ease the navigation through the various parts of the system.

Turns out Lee was also mulling it over during the day. At about 4 o’clock, we chatted on the phone. “You go first,” he said. So I explained my approach. We were on the same wavelength. At about 8 o’clock, we meet in IRC chat a bit. I go off to do some other parts of the app, Lee starts in on the ideas we had discussed.

A few hours later, he’s got it working! One small slice, mind you… But Lee cracked the puzzle! We’re using older EJB and struts 1.0, so we were not able to iterate over the bean to automate the JSPs.

Got it down to a pattern for {1 EJB, 1 form bean, one JSP, and one action} per class. And all CRUD functionality is possible.

Third time’s a charm, as they say (whoever they are — let me know if you know).

Paul posits:

Logically speaking, I can’t see why, if any tool were *really* good at forward-engineering, one would ever want to reverse-engineer. The “round-trip” tools I know are there because they do a good job of organising and re-organising the gross structure of the code as models, but can’t do anything with the fine detail of the code.

Scott Ambler tossed out the case where folks that are visually oriented would appreciate reverse engineering the code [into models].

I added: one might want to use reverse engineering of

machine-generated source to:

• see what the code looks like in a different view(s).
• see code added manually outside of generator
• check for compliance with intentions of the fwd engineering tool

Paul’s reply tends to lead me to think that Paul is making his points based on an assumption that the “(near) perfect” tool to go from some higher form (modeling+?) to source code is in existence. That this tool automagically forward engineers perfect code — hence why would you need to reverse engineer the code? An analogous situation to source code being forward engineered into assembly code.

I’m no computer scientist, but someone help me out here. I would surmise the leap from source code to assembly code being one of nearly a mathematical proportionality. That is, the source code — being of a higher order language — is merely a more compact form of an equivalent expression in assembly. Sort of like multiplication is a shorthand notation for lots of addition statements.

The breakdown occurs as the model-to-source code paradigm is considered. Paul’s view may be one of the “Holy Grail” of modeling tools that can capture any type of application and all of its complexity at some level higher than simple source code, yet be able to generate the requisite code to have the application run.

I think we have a long way to go before this tool crosses our computers!

And I don’t mean with LSD… In a post, Juha-Pekka postulates the following:

• “My personal opinion is that roundtripping is a recipe for trouble. “
• “Still I need to ask what is the value of having a rectangle symbol in a digram and an equivalent class in a file.”

When I first laid eyes on an ad for Together/C++ in 1994 that promised code and diagram were always in sync, I spent $1200 of my own money and bought it sight unseen.

Not having accurate diagrams that represented the code was a problem… Though I had powerpoint templates for Object Modeling and excel spreadsheet templates for sequence diagrams, these always seemed to get out of sync with the code after a while. This is quite likely worse than having no diagrams at all! (Kind of like a map with an error might be worse than no map at all… depending if the road now goes through a man-made lake.)

Think of round-tripping a class diagram as follows:

• edit the code, the diagram automatically reflects the change.
• edit the diagram and the code is immediately updated.

Sounds like a visual editor to me… always in-sync diagram and code.

Much like we represent bytecode and assembly with higher-order languages (i.e., things like source code), another level up of representation of the same thing can be useful.

At least I found in-sync round-tripping useful for the past dozen years. Others’ experience may vary.

A given software problem can be solved in more than one way.

Suffice to say, Developer A might require 5 times as much effort as Developer B. To add to that statistic, the design and code from Developer A might be 5 times the LOC, and much worse quality (maybe 5 times the complexity) — basically more expensive to maintain. Might as well add one more problem: the code from Developer A exhibited brittleness when attempting to extend the functionality.

However, both A and B products provide the desired functionality.

A project team or a company likely has both A and B type developers, but rarely has the opportunity to compare parallel solutions to the same problem.

How do you go about trying to get the best solution for your money at your company?

I filled in to teach Professor Meketon’s CSC class at Villanova University. We used a book by Ian Sommerville, titled

Paul makes a nice comment here regarding whether the “build vs. buy” simple example scales. His example revolves around less clear requirements for the “widget.”

“We still don’t know what we want, but now we don’t know how to get this package to do it for us either.”

Of course, one of the problems in this example is not knowing what is needed. My example of the millisecond resolution timer software package was based around very clear requirements and a very clear “domain of requirements” (I just made that up, but it sounds good). That is, not only did the commercial off-the-shelf (COTS) package meet my precise needs, it also supplied other features useful to me. Features like self-calibration for improving accuracy.

When the purpose isn’t clear, it can be difficult to find a package that meets your needs (or find too many). In addition, it can also be a case where you end up looking for a way to employ whiz-bang features just because they came in your COTS package.

I was IMing with a friend in the Dominican Republic tonight. He mentioned how great it is with the open source community to be able to get various products to solve problems.

“In the good ol’ days,” I jokingly opined, “you had to buy everything.”

“Or write it yourself,” he added.

“Key is to know what to spend time and resources on for a given project,” I noted.

Which brings me to a story. Years back, maybe late 80s, early 90s, I did a lot of real-time work on PC programs (in addition to real-time apps on supercomputers). The client I was moonlighting for needed a millisecond resolution timer to record time between image display and test subject making a keystroke. All to support Dr. John D’s research into human responses to visual stimuli.

So, I found some great assembly code that I could write to diddle with the 8250 Timer Chip (if my memory serves me correctly — and if it does, that is scary). Got everything working perfectly, shipped the application, grad students ran all sorts of tests using the software. Perfect.

About two weeks after releasing my application, I spotted a commercially available millisecond resolution timer package from Ryle Design (again, IIRC). Something like $49. I bought it immediately.

I couldn’t rip out my custom code fast enough and put in this new package. After all, unlike my timer code, this package:

• Was supported
• Had documentation
• Had more features (useful ones too)
• Would get the benefit if many users forcing improvements, bug fixes
• Would have future enhancements
• Was code I didn’t have to maintain!

Think about this the next time you choose to build versus buy — or in today’s modern computing landscape — use open source…

no, this isn’t rocket science… just a gentle reminder about why some practices are valuable.

now i am reminded why i had been pushing a team to get the “golden data” identified for a project 6 months ago. By “Golden Data” I mean that data which has been carefully selected — or hand crafted — to reveal elements of the application’s functionality. Though the novel technology for this project is a challenge and is by no means trivial, the data itself has been a big struggle as well, mostly due to inherent complexities in gnarly (a technical term ) health care systems’ actual databases.

you see, the application involves grabbing data from n-many sources, some of which may hold duplicates of other sources. in addition, there are certain key values that are deemed “sensitive” and must be handled properly so that only authorized folks can see the sensitive information.

so, there is a combination of code and rules and presentation magic, etc, that all have to jive. however, there also must be the proper data with which to reveal the intended logic. the code could be right, the rules could be right, but if the data is not right, nothing shows up. then starts the wild goose chase… is it the code? is it the rules? is it the presentation logic? or is it the data? or all of the above?

next time, i’ll be sure to emphasize that we have the precise knowledge of the data side of the equation to prove the existence — or not — of a feature.

Note to Self: write the test from the data side — not just code!

this evening, rye — one of two guinea pigs — seemed to be lethargic. we braced the girls for the ultimate likelihood… after all, gp’s don’t live too long.

i checked on rye earlier tonight. he was no better. i picked him up and cradled him in my arms. i used a dropper and gave him some water since they always drink us out of house and home. i stroked his fur, i looked in his eyes. he was shivering and i figured he wasn’t long for this world. i carefully returned him to a nice spot in his cage with some fresh pine shavings. i laid him down and made him comfortable, with his back against a wooden thing we have in the cage. his piggy brother, Poppy, seemed mildly aware of the distress.

just about an hour ago, i checked again. he had passed on to the other side. he is now where the grass is always green, carrots are forever showing up on the carpet of green grass, and a babbling brook brings fresh water by for all time. (well, actually, he is now in an amazon box, wrapped in a little towel, as i figure the girls will want to say goodbye.)

rye, we will miss your little piggy legs elevating your hot dog physique across our kitchen floor. we will miss your incessant audible reminders that your water bottle is empty. and we will miss your squeaks when we peel carrots or chop vegetables.

rest in peace, rye