The Source for Java Technology Collaboration
User: Password:



Janice J. Heiss's Blog

Community: JXTA Archives


Where the Software Met the Road

Posted by hiheiss on May 19, 2006 at 03:53 PM | Permalink | Comments (0)

It's day two of JavaOne '06, and I’m over at the Slot Car Racing Programming Challenge area, where the track is heating up. Developers are standing in line, some for the 20th or 30th time! to see if their latest tweaks will pan out as they hoped. A lot has been happening here. The ABC Morning News guys were here with their cameras. Developers are taken with the chance of being onstage with James Gosling and spending some time with him. Gosling himself has been trying out the slot cars off and on for a few days. Some contestants admit that the slot car race brings them back to their childhood. Developer aren’t exactly closet game junkies.

I approach one, who asked to be referred to as “Turtle,” and ask him if this is harder than he expected.

“It’s very difficult,” says Turtle. (Yes, the name gives away something about his times.) “I have no experience with real-time. There is a lot of tuning, a lot of unknown variables – every car runs a little different. So even if you tweak it right for one car, it may not work for the next. This is about my 15th attempt and I’ve missed two sessions already.” (I’m beginning to understand why he doesn’t want his real name used.) “I’m getting better each time, and finally made it into turn three.”

When I ask him how this is affecting him he says he wants to build a race track in his home. “This is a lot of fun. Once your car runs, the times are posted for your machine and you can figure out how fast your car is going at each sensor point. You could copy and paste this if you wanted, but it would be preferable if they gave you all of your races together so you could analyze all of the numbers.”

Turtle informs me that the man standing next to him is tied for the lead. His name is Peter Whitfield.

“I’m probably the worst Java programmer here – I’m more of a manager than a programmer,” admits Whitfield. “It will be embarrassing if anyone looks at my code. I have no experience with real-time Java, though 20 years ago, I worked with real-time systems. This is a lot of fun and a good opportunity to see how the real-time Java stuff works. It’s easy.” Different strokes for different folks.

Peter -- who is quite generous with his time as he keeps eyeing the monitor above the track listing the names of who's in the lead along with who is currently racing -- completed the race in 25.49 seconds somewhere around his 20th trial and estimates that maybe 10 or 12 people out of 100 have made it to the finish line without crashing. Clearly the hardest thing is just making it around the track. I ask him the secret to his success.

“Keep it simple -- do the absolute minimum necessary to get the result,” Whitfield explains. “There are guys doing some very sophisticated algorithms but I have not actually modified the sample algorithm at all, I’ve just been changing the parameters. Nothing in this application has been hard. I have an engineering background rather than a pure software development background and this is about manipulating voltages to control the speed, and that’s second nature to me. So my background helps. I have only now started changing the way the real-time stuff works. Until now, I’ve only changed the parameters of the way the speed changes as it goes around the track, so a lot if it involves trying to figure out how, if I change the voltage in one place, it affects the speed in another. That’s what people are missing -- they don’t understand how if they go too fast in one part of the track, it will make the car unstable later. The Java side of it is very easy to pick up because we are given a sample program. We have not had to set up the framework for it. Real-time programming is about understanding physical systems; it's not as abstract as writing UI software. So you need to understand the physics of what you are trying to do and the timing.”

I ask if he spends a lot of time visually contemplating the track. “Absolutely – I stare at the track trying to understand where things happen. It’s a spatial thing and physical thing. I can run the same program 10 times and get different results each time. There are 5 different cars that all perform differently. We don’t know which car they will run, so we can’t tune it for a specific car. The challenge is to write software that is in tune with the reality of what you are trying to make happen.”

Peter went on to say: “I learned that I don’t program in Java often enough, so I hope people aren’t looking over my shoulder when I look up Google to figure out how I do multi-dimensional arrays. You need to be aware of where you are putting your thread to sleep and where it will wake up and if you are doing it in more than one place you need to think of the different permutations and where it can all happen.”

And what else is Peter doing at JavaOne?.. “I’ve spent way too much time here. I don’t have a boss so I can sit here and just have fun.”

I talk to a few other contestants waiting their turn. Jonathan O’Keefe, who does database programming, is trying out real-time for the first time. And there is Ulrich from Denmark who does web applications and GUI stuff and business logic, and Michael from Germany who does desktop programming and Carl, an American, from a company called Triego Network Security, who manages security information. None have experience with real-time. The line ebbs and flows at various times, but there's always someone racing, and there are a lot folks sitting in front of the machines set up for them on which they work on their real-time programs.

Only Carl admits to big ambitions. “At first,” says Carl, “I was over-complicating it by treating it like a J2ME product, but if you are very conservative about the objects you allocate, you can treat it as a regular Java program. You have to keep it simple and not allocate anything in the loop or you will run out of memory. I’m going to try to knock someone off the leader board -- I’ve just started with the base program so there is a lot of room for improvement.”

Carl sees uses for real-time Java at his company, Triego. “We do some close to real-time work and try hard to keep our GC under control and use a concurrent generational collector, so the real-time Java technology is very interesting. We could find a lot of use for this technology in the work we do. It’s interesting and the applicability of the predictability of execution time is great.”

As I walk away, I see that Robert Chu is tied with Peter Whitfield’s 25.49 seconds time while Richard Yee is third, at 26.18, and Rivera (I don't catch his first name) is fourth at 28.60. I wonder if any of these folks will be in the top three when James Gosling gives his keynote on Friday morning. Time and times will tell.

Stay tuned. The winners will be announced and compete one final time at the Gosling keynote on Friday. Should be a lotta fun!

Finally, here's a story about the Slot Car Racing Programming Challenge yours truly wrote over on java.sun.com:

The 2006 JavaOne Conference Slot Car Racing Programming Challenge
http://java.sun.com/javaone/sf/slot_car.jsp


And, in the form of shameless self-promotion, here's an interview that I did not far back with Sun Distinguished Engineer, Greg Bollella, on real-time Java:

Programming in Real-Time Specification for Java (RTSJ): A Conversation with Distinguished Engineer Greg Bollella
http://java.sun.com/developer/technicalArticles/Interviews/Bollella_qa2.html



Here we go! JavaOne is almost here!

Posted by hiheiss on May 10, 2006 at 08:14 PM | Permalink | Comments (0)

Among the topics currently scheduled for my editorial beat:

-- The Slot Car Programming Challenge wherein developers get to test their skills with Real-Time Java. Standard 1/24 scale cars run around a track with 80 sensors spread along its length with a power supply controlled by an A/D converter driven from a workstation. Contestants have to write software that controls the car while going as fast as possible. The sensors are simple photocell gates like those used to detect paper moving through a printer. The Real-Time Java program senses the track position of a slot car and sets the voltage to the track -- and thus the speed of the car. Attendees with the 3 shortest lap times will have a final run-off during James Gosling’s keynote on Friday.

-- The activities of Tommy, the autonomous, unmanned Java technology-powered robotic dune buggy, who will be making myriad appearances. Tommy's software is built on a Java technology-based platform called the Mobile Autonomous X-bot (MAX) developed by Perrone Robotics, Inc. (PRI). PRI-MAX runs on the Java Platform, Standard Edition (Java SE, formerly known as J2SE), and uses the Java Communications API, while Tommy's microprocessors rely on a hardware-based Java Virtual Machine (JVM) running Java Platform, Micro Edition (Java ME, formerly known as J2ME).

-- The always-lively discussion at the Fireside Chat wherein JavaOne conference Alumni get to engage with Java luminaries.

-- Sun’s Project Tango which addresses interoperability between applications built on Microsoft's Web Services Communications Foundation (WCF, a.k.a. Indigo) and those built with Sun's Java Web Services technologies.

-- SOA and developments in open source.

-- Twelve Reasons to Use NetBeans Software.

Plus numerous other sessions, along with exhibits in the Pavilion and the flexibility to go where the action is. I already feel sleep deprived!



RTSJ and the JavaOne Slot Car Challenge

Posted by hiheiss on April 07, 2006 at 02:04 PM | Permalink | Comments (0)

I recently conducted an interview with Sun's Greg Bollella that debunks some myths about the difficulties of Real-Time Java and touts the coming Slot Car Challenge at JavaOne, which will give developers a chance to write some RTSJ code and see if can guide a slot car around a track with speed and accuracy -- it should be fun. Greg believes that "The Slot Car Challenge at the 2006 JavaOne Conference will prove that anyone can program with RTSJ,” and insists that programming in Real-Time Java is "more like bicycle science than rocket science". Anyone want to ride the bicycle?

Conscientious Software

Posted by hiheiss on March 30, 2006 at 03:35 PM | Permalink | Comments (1)

Conscientious Software: Part One of a Conversation with Sun Microsystems Laboratories' Ron Goldman Here's a rich IMHO interview with Sun's Ron Goldman by yours truly. Ron's a senior staff engineer at Sun Labs who is working with Richard Gabriel to envision a new software model. As we move into a world of massive software interdependence where standalone apps are on the way out, Ron wants to develop ways to make "large systems more robust, stable, and better able to take care of themselves." He wants software to start using cpu cycles "to actively monitor its own activity and environment, to continually perform self-testing, to catch errors and automatically recover from them, to automatically configure itself during installation, to participate in its own development and customization, to pay attention to how humans use it and become easier to use over time, and to protect itself from damage when patches and updates are installed." Are you enticed by his vision?...

Meet the Engineer Q&A on java.sun.com

Posted by hiheiss on March 10, 2006 at 04:54 PM | Permalink | Comments (0)

Please check out this Q&A:

http://java.sun.com/developer/Meet-Eng/ohair/

I did with Kelly O'Hair, senior staff
engineer in JDK (Java Development Kit) Core Serviceability.

He was really fun to interview.

Asked if he ever feels a sense that he's
created something beautiful when
he writes code, O'Hair said,
"Well, more like 'not ugly.'
There's a gray zone between ugly
and beautiful. Simple is beautiful."

Kelly is a java.net blogger so check out his blog
too to get to know him better if you haven't already.



Shale: The Next Struts?

Posted by hiheiss on June 29, 2005 at 09:57 PM | Permalink | Comments (4)

I'm at TS-7393 along with a pretty packed room of, I estimate, 700+ attendees. All the sessions that I've gone to have been well attended with a serious but enthusiastic-looking group of folks it appears who ask smart questions in the Q & A's. The session is titled "Shale: The Next Struts?" with Sabreware's David Geary and Sun's Craig McClanahan. Craig is Strut's inventor and David, Struts template tag library inventor, which was the inspiration for creating Tiles, one of Struts most popular features. Shale is the new kid on the block in the web application frameworks space, with David and Craig being two of the three leading original contributors on Shale. A lot of people want to know: What's the deal with Struts and JavaServer Faces (JSF), and Struts and Shale? A lot of uncertainty surrounds the topic. It is impossible to predict where it is all headed

McClanahan presents the rationale for Shale. Shale is unique among web application frameworks in that it starts by assuming that JSF exists. Recognizing that with a little tweaking you can turn JSF into a completely functional web app framework, he decided to see if something as popular as Struts could be created. So he proposed Shale as the architecture for Struts 2.0 to Struts developers, which did not entirely sit well, given the focus on backwards compatibility and support for existing Struts users. They did accept Shale as a Struts sub-project, so it is officially part of the Struts environment. The idea is to grow a community around Shale that is already used to the idea of using web app frameworks in developing. He is quick to point out that Shale has zero direct relationship with the Struts 1.0 code. Shale is all new code based on the assumption that JSF exists; it skips the step of re- implementing the features that are already there, like validation and request processing.

Features in Shale include web flow, so developers can organize a dialogue that is longer than a request but shorter than a session. There is client-side and server-side validation but with JSF components. Shale is integrated with Spring to enable transparent use of Spring's bean factory to create managed beans. David Geary has been extracting Tiles out of the Struts core, so it is independent of the underlying framework and can be used by any framework more easily. Shale will take advantage of that. Primary subtrees is another way to perform reuse that will function through a specialized library called "Play". McClanahan pointed out that a lot of people dislike Struts because it likes JavaServer Pages (JSP). JSF likes JSP as well, but JSF has components as a Java API, and developers can plug in a different view handler to use something different. With Shale, they've created an environment that looks like Tapestry with a standard HTML file for the markup presentation. It has a test framework to make it easy to test the view controller and other implementations.

He is quick to point out that, although they could use Shale to create another JSF component library, that is not their goal. The components they are creating are only ones that interact directly with the framework's facilities. Anyone's JSF components will work in Shale - why reinvent the wheel? The five tags within Shale are: token tags to catch duplicate submits; a subview for extra value-add services for a dynamically included page as well as the main page; a commonsValidator tag used to integrate the commonsValidator rules; a validator script so developers can point to the Java script so they don't have to load it on every page. and a clay tag used for parameterized subtrees.

JSF as an architecture has extension points that Shale takes advantage of. The Spring integration is a custom variable resolver and looks at the first word in an expression like "customeraddress.city" -- if a customer does not exist will create the bean for you. By default, JSF will look in the managed beans definitions, but the extension checks for a bean factory as well. Similar facilities enable access to the Java Naming and Directory Interface (JNDI) context. The navigation management is encapsulated in a specialized dialog navigation handler. A specialized view handler enables developers to treat a Tile name as a view ID to reduce work

So where is all this headed? McClanahan presents three scenarios. First, it is possible that Struts developers will see that Shale is becoming popular and choose it as Struts 2.0. Second, it could become a separate Apache project - synergy exists with the Apache MyFaces community that is building both an implementation of JSF and some interesting components to go with it. All of the JSF-related things could be encapsulated into a single project. A third possible future is aware of how long it takes to build a Java standard in the Java Community Process (JCP) - almost two years to build JSF 1.0. Shale can be seen as an experiment to see if its facilities make sense in a future JSF release, perhaps in JSF 2.0 time frame. The future is unclear and ultimately in the hands of developers.

An Interview with Craig McClanahan

http://java.sun.com/developer/technicalArticles/Interviews/jsf_mc Clanahan.html

David Geary's Blog

http://jroller.com/page/dgeary

Craig McClanahan's Blog

http://blogs.sun.com/roller/page/craigmcc

A Cool MP3 Player at the SwingLabs Exhibit

Posted by hiheiss on June 29, 2005 at 10:19 AM | Permalink | Comments (1)

I’m at Exhibit #1111, Swing/Labs JDesktop Network Components (JDNC). It’s a Sun Microsystems project that allows experimentation with extensions to existing Java Foundation Classes/Swing API components, new JFC/Swing components and various desktop related technologies like Java 2D, AWT. I’m talking now with Sun’s Roman Guy, who explains, “We experiment with a number of projects containing JDNC and Swing components, all of which sit on top of Swing and add extra features, like transparency or animation. There are data-aware components that make it very easy to find data from a database or an XML file, directly to the UI. You have almost nothing to do -- everything is done for you in the code. You just choose the source of code and – that’s it.”

The source code is available on java.net, (http://www.java.net/) as part of the LGPL license. The idea is to explore new ideas in Swing components that may one day be part of the JDK, like various filtering, highlighting and searching features. “It’s a playground for the Swing team,” explains Guy.

Next to Roman, is Sun’s Richard Bair, operating a SwingLabs desktop network component demo, who explains, “We’ve created a music player that reads the music libraries of a very popular music player and will play any MP3 file that you have in your library. The interesting thing we’ve done is show off some of the cool features in our Swing X project, especially the data binding. First, you see the finished project, a nice music player with ‘play,’ ‘previous,’ and ‘next’ buttons and a search field. We have a lot of music and custom cell renderers and so on. On Thursday, June 30, this will go public as: joplin.dev.java.net – Joplin, as in Scott Joplin, is the name of our music player. We have a list of music and a collapsible panel -- you click a button and the music screen comes down as an animated effect. As you select different songs, you notice that the title, album, and artist genre info get updated.”

The screen displays a cool album cover.

“It looks fancy for a demo, but a lot of it is stock components from the Swing X project we put to use here,” says Richard. “We have a JX image panel component, which is nothing more than a component that knows how to extract the image art from an MP3. It’s pretty simple stuff. This table is a normal JX table and a little browser that lets you walk in 3D through all of the album covers in your music library. It’s all implemented in Java 2D, very fast. Once you get your song, you can listen to it. Another screen was written in Java 2D, we call Zoomy; this panel can be retrieved from another open source project on java.net that is called ping.dev.java.net. A search field enables you to filter by artist, album, genre and song. This will be part of James Gosling’s keynote on Thursday.”

Neat – I got a sneak preview.

Great work! Let’s hope it finds its way into the JDK. And don’t forget Gosling’s Thursday morning keynote.



Celebrating Java Technology Through Art

Posted by hiheiss on June 29, 2005 at 10:14 AM | Permalink | Comments (3)

It’s so inspiring to watch gifted artists at work. Their art is alive with color and imagination. Sun brought six gifted artists to the 2005 JavaOne Conference with the goal of raising $5000 for the Foundation for a College Education (FCE) of East Palo Alto, California, which Sun has supported for ten years, about as long as Java technology has existed. All during that time, Sun employees have volunteered their time tutoring students to help them become the first of their families to graduate from high school or college. This year, silent auctions take place until noon every day of the JavaOne conference through Wednesday and then Wednesday night the live auction occurs at the After Dark party from 7:45 to 8:15 in Hall A prior to comedian Dennis Miller’s performance.

What exactly is Java-inspired art? The idea is that Java developers are also artists who call upon inspiration and the creative imagination in creating their code, an insight that Sun’s Richard Gabriel has articulated as well as anyone. (http://java.sun.com/features/2002/11/gabriel_qa.html) The presence of the artists at the 2005 JavaOne Conference implicitly confirms what Gabriel says:

’Writing software should be treated as a creative activity. Just think about it -- the software that's interesting to make is software that hasn't been made before. Most other engineering disciplines are about building things that have been built before. People say, "Well, how come we can't build software the way we build bridges?" The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built. Someone says, "Oh, let's build a bridge across this river. The river is this wide, it's this deep, it's got to carry this load. It's for cars, pedestrians, or trains, so it will be kind of like this one or that one.’ They can know the category of bridge they're building, so they can zero in on the design pretty quickly. They don't have to reinvent the wheel.”

Gabriel points out that we’ve only been building software for 50 years and each time we do it, it’s fairly new. Gabriel says we should train developers the same way we train painters and poets. Sounds good to me.

The artists:

Tim Gaskin of San Francisco(http://timgaskin.homestead.com/index.html) said this about his work: “Besides the fact that I am first and foremost a colorist, my paintings are about how celebrities stand at premieres wearing hundreds of thousands of dollars worth of clothes and jewelry and get their picture taken in front of logos which are then sent out all over the world. They represent brands, and even become them because they are so overexposed."

Graffiti artist VULCAN, from the South Bronx area of Manhattan, has work exhibited in the Graffiti Hall of Fame (http://www.graffitihalloffame.org/) in New York City.

New Yorker Eric Orr, (http://www.bravemind.com/ericart/ericartindex.html) also a noted graffiti artist, got his start painting graffiti on the New York subway system. Orr, who has made a name for himself as a graphic artist designing logos for entertainers, boasts an impressive list of clients, including Afrika Bambaataa, The Cosby Show, Public Enemy, Fat Joe and Jive Records.

From crayons to krylon, Leon “Tes One” Bedore (http://www.tesone.net/main.html) has been creating art on walls for the majority of his life. Tes One became a serious street artist in 1992, painting murals and graffiti art throughout the Tampa Bay, Florida, area. In 1999, expanding on his natural artistic abilities in line with the computer age, he began to develop compelling graphic design and web pages for a number of clients. Now, he combines all that he knows from his street-art roots and his digital design profession to create art that accurately reflects his perspective on the world around him.

Brian Ermanski or “BE” of Manhattan, often described as a naïve/ignorant/outsider artist and downtown living NYC legend, has sold more than 70 of the 110 paintings he has produced to date.

Casey O’Connell, currently of San Francisco by way of Florida, recently came to the attention of John Doffing, curator of The Start SOMA Gallery in San Francisco, where all of the paintings in her first group show sold.

Come watch artists in the midst of their creative process. I'm really tempted to bid on some of this art myself.



A Pragmatic Application of SOA (Service-Oriented Architecture)

Posted by hiheiss on June 29, 2005 at 10:06 AM | Permalink | Comments (1)

Over at TS-1640 Pragmatic SOA: A Case Study, with developers Ashok Mollin, Ashesh Badani of Sun Microsystems, Inc. and T.N. Subramaniam, Director of Technology at RouteOne LLC Inc. Ed Ort (http://weblogs.java.net/blog/edort/archive/2005/06/pragmatic_soa.html) and Tim Bray (http://www.tbray.org/ongoing/) of Sun are blogging the session in greater detail. I will be doing a story on this for java.sun.com in a month or two so stay tuned. For now, a sneak preview.

RouteOne provides a web-based Credit Aggregation Management System (CAMS) created to accelerate the automotive finance process for dealers and their finance sources. The session presented “a real-world implementation of an SOA project at RouteOne LLC and helps explain the architecture and various best practices, design patterns, standards, and technologies involved in building an end-to-end business solution.” The presenters define Service Oriented Architecture (SOA) as “an integrated software infrastructure and design approach, leveraging Web computing standards, for delivering business functions as shared and reusable services.”

A lot of people regard SOA as a real challenge, in part because it typically involves both substantial organizational change, in addition to new ways of organizing IT. It seems like a situation in which developers have to be, not only technically sharp, but good listeners who can understand the culture of the company they are working with. Creating a shared service requires technical design prowess — architects have to know who, when, and where in the business process, services will be consumed. And then there is the whole history of ERP enterprise resource planning, in which some CIOs and IT managers experienced a lot of growing pain involving expensive projects that required changing processes across the enterprise as part of automation. It has not always worked out. Some people fear that SOA will bring a lot of pain to companies because it may be bigger than an ERP implementation. So businesses are sometimes understandably cautious. There can be a lot to rethink: development methodology, business impact, infrastructure, budget, organizational design and more.

Another challenge involves creating high-level business components that can be re-used and re-configured. One problem is that the requirements that yielded the original component interface were different enough from the new ones so that they required the re-write of substantial functionality.

The basic approach of Sun’s Ashok Mollin and Ashesh Badani, along with RouteOne’s T.N. Subramaniam, seems sensible and cautious: Projects need to generate ROI in 12-18 months so start small and be opportunistic. Minimize disruption to existing infrastructure; reduce risk with fewer web services initially while climbing the skill curve. Wrap legacy/existing applications using adapters + WS; Java and .NET interoperability. Evolve into a flexible, standardized architecture; does not mean “rip and replace”. Foster cultural change to encourage reuse. Take a top down approach – let the business drive!

They addressed several critical problems:

Single Sign On

Transparent login from lender portal

Get Dealer Information

Accessing volatile dealer information at runtime

Import Credit Application

Start the process on another system – DSP

Orchestration

Maintain state and coordinate document exchange in long running transactions with Lender

A summary of their “Pragmatic SOA wisdom:

Start simple, don’t let the “alphabet SOAup” overwhelm you.

Let business identify the service.

Think XML documents not objects.

Use SOAP as an envelope, but not for binding.

Use WDSL 2.0 for description not code generation.

Think asynchronous conversations.

Use WSBPEL to orchestrate the process.

Use JBI for integration.

Keep learning, this is not finished.

Question as I left: Did the large Java developer audience there come away enthusiastic about SOA? There certainly were a lot of smart, probing questions in the brief, casual q &a after this session, if that's any sign.





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds