- How badly do you want a MacBook Air?
- Rails, and now Java, in the cloud
- BUGbase: A Small Change in Plans
- Toys for Techies: BUG
- When Languages Interfere
- Three New Products from the Bindows Folks
- Google Android: Initial Impressions and Criticism
- Android SDK: It's a Java API
- Java Flawed on Leopard
- Static Path Analysis and Embedded Systems
May 14, 2008 | Comments: (0)
How badly do you want a MacBook Air?
At least partially in response to my coverage of TopCoder last week, I have been getting a spate of programming contest and community announcements. ZocDoc is an API for doctor appointments. Appistry Enterprise Application Fabric (EAF) is a grid-based application platform for the development and deployment of scalable applications in Java, Spring, .NET or C++.
Notice what these two have in common:
Tuesday, May 13, 2008
ZocDoc Announces Developer Contest - Win a MacBook Air!
Today, ZocDoc kicked off a contest for software developers to create new applications that help patients book doctor appointments anywhere on the web. ZocDoc users have frequently requested integrations into popular applications and devices such as Facebook and iPhones, among others.
The contest, which runs from now until August 1, 2008, challenges developers to build the application that will most benefit patients looking for a doctor. A new API allows developers to pull data from ZocDoc such as doctor and dentist information, practice locations, pictures, URLs and available appointment times, which can be integrated into custom mashups and applications. The developer of the application that benefits the most users (as measured by appointments made) wins a brand new MacBook Air!
If you are a developer, visit the ZocDoc Developer Center to register for the API.
Join Appistry's Peer2Peer Developer Community and you could win a MacBook Air
Appistry Enterprise Application Fabric (EAF) dramatically simplifies the process of developing, deploying, and managing highly scalable and reliable Java and Spring applications.
Now, with Appistry EAF Community Edition, anyone can experience the benefits of Appistry EAF for FREE. Your Peer2Peer membership allows you to:
- Download Appistry EAF Community Edition at no cost
- Utilize it on up to 5 servers or 10 CPU cores for an unlimited amount of time (no expiration)
- Use it for development, testing, even production deployment of applications
It's easy to get started - join the Peer2Peer Developer Community today to download the free software and access developer resources such as tutorials, on-line documentation and support forums.
You could win a MacBook Air when you join Peer2Peer
Hmm. This is the computer that my high-school classmate Steve Levy (or possibly his wife) accidentally threw out with the newspapers.
Posted by Martin Heller on May 14, 2008 11:11 AM
May 06, 2008 | Comments: (0)
Rails, and now Java, in the cloud
I had a conversation today with David Abramowski, CEO of Morph Labs. We were supposed to talk about how Morph Application Platform, which uses Amazon EC2 and S3 for on-demand cloud computing and storage along with its own routing and provisioning infrastructure, compares with Google App Engine, which uses Google's own cloud infrastructure. That part of the conversation was short, though, because beyond the fact that they're both on-demand cloud computing platforms, the two have nothing in common. I was put in mind of Shakespeare sonnet 130, My mistress' eyes are nothing like the sun.
Google App Engine, as I've discussed previously, currently supports only Python for an implementation language and BigTable for a (join-less) database, with Django and a simpler Python Web framework developed at Google both on offer to structure a Web application. I can't yet speak to what deployment is like on Google App Engine, as I signed up too late to get into the beta.
Morph currently uses Ruby on Rails as its framework, and PostgreSQL as its database. Today's announcement at JavaOne was for a beta release of Morph Application Platform for Java, developed in collaboration with Webtide. Abramowski expects the beta to fill up in a couple of days.
I was actually more interested in the Ruby version of the Morph Application Platform than the Java beta for my own projects. I've signed up for a free developer account. I've run into a snag subscribing to the DevCenter service that will let me access an "AppSpace," but I imagine that will be fixed before long, and I'll be able to say something about the service first-hand. It almost has to be better than the Rails hosting experience I had at TextDrive, now called Joyent.
Meanwhile, two user quotes from the Morph Web site:
"Morph is a great service. Deployment is simple. I give them lots of points for ease of deployment. They can help you scale as they are using Amazon's services on the back end."
- Justin Ball from www.justinball.com
"Morph AppSpace is the best experience we've ever had for Rails deployment. We can scale to as many app servers as we want in minutes, and then scale back as demand changes. We are also happy about the effortless deployment and the amazing client support. The Morph guys were helpful before, during, and after. From now on, we'll be using Morph AppSpace in releasing all our new applications."
-Jim James, www.mytripscrapbook.com
Posted by Martin Heller on May 6, 2008 01:03 PM
January 19, 2008 | Comments: (0)
BUGbase: A Small Change in Plans
The BUG system, which I discussed last Tuesday, will go on sale Monday at the BUG Labs store. It won't be exactly what was previously announced, however.
In an email, a company spokesman explained the change of plans:
This (the picture at the top left) is the BUGbase "Hiro P" model. It's what the first batch of BUGbase units will look like, and is much like the BUGbase we've been promoting, only with a minor aesthetic change to the front panel and no onboard 802.11 wi-fi.
Why no wi-fi? The issue extends from developing a set of open source wi-fi drivers, and we had to make a decision on our first production run - either ship early with no wi-fi, or delay the ship date until the driver issue was resolved.
However, to compensate the Hiro P customers, we will be offering them a BUGwifi module *at cost*, and we will also be giving them a *free* BUGvonhippel module. Additionally, we will be extending the early adopter program to the new batch of wireless-enabled BUGbases.
More about this can be read in the announcement we just issued on BUGblogger: http://www.bugblogger.com/2008/01/what-about-wifi.html
The wi-fi driver issue sounds similar to the one I encountered when I reviewed the Mandriva Flash 2008 in December. To get wi-fi working on that system, I had to download a small firmware file directly from Broadcom.
Posted by Martin Heller on January 19, 2008 08:11 AM
January 15, 2008 | Comments: (0)
From http://www.buglabs.net/products:
BUG is a collection of easy-to-use electronic modules that snap together to build any gadget you can imagine. Each BUGmodule represents a specific gadget function (ex: a camera, a keyboard, a video output, etc). You decide which functions to include and BUG takes care of the rest letting you try out different combinations quickly and easily. With BUG and the integrated programming environment/web community (BUGnet), anyone can build, program and share innovative devices and applications. We don't define the final products - you do.
The BUGbase (an ARM CPU and lots of interfaces) and four BUGmodules (GPS; Digital Camera/Videocam; Touch-sensitive, Color LCD Screen; and Accelerometer, Motion Sensor) will be available later this quarter. Four more BUGmodules are promised for Q2, but as one of them is a teleporter I would take that with grain of salt.
The software is Open Source and has a Java-based SDK:
BUG is built entirely with open source software. BMI, the BUG Module Interface, attaches devices to the BUG. Device-based services and applications are dynamically available based on which modules are connected to the BUG. Higher up the stack is Java, which hosts a service-oriented component runtime called OSGi. Java and OSGi make creating new BUG applications simple and intuitive, as BUG applications are essentially one or more bundles. In addition, each BUGmodule launches an OSGi bundle which in turn creates services for other components to consume. BUG applications are created using the BUG SDK (internally named Dragonfly), and are shared with other developers and users through BUGnet, our online community.
When I contacted BUG Labs about review units, they pointed me at "Dragonfly, the Eclipse-based BUG SDK, which includes a virtual BUG emulator."
The "getting started" guide is at http://bugcommunity.com/wiki.
Posted by Martin Heller on January 15, 2008 06:34 AM
December 14, 2007 | Comments: (0)
I've learned a lot of languages, both human and computer. When I learned Latin in High School, it mostly helped my English. When I learned German, I had both help and interference from my knowledge of Yiddish; ditto for when I learned Dutch. Similar things happened with Russian (college) and Chinese (grad school), although that wasn't quite the same mechanism: my brain would sometimes serve up a word from a different language than the one I was trying to speak.
As I mentioned Wednesday, there are some common constructions that have different meanings in the different languages that were inspired by C. The new object constructor isn't the only place where subtle errors can occur if you get confused.
On the other hand, learning Pascal back in the day mostly helped my Fortran. Learning many different assembly languages didn't seem to cause any interference: writing assembly language was such a painstaking process that I could usually remember what processor I was writing for at the time.
I hear from people who would rather write Java or C# than mess with JavaScript. They're the kind of people who like tools like GWT and Script# and Volta. I also hear from people who would much rather write JavaScript than Java or C#.
Do you program in more than one language? On balance, does already knowing one programming language help you to learn another, or do the languages interfere with each other and cause you to make errors? Do you find yourself preferring one language over another?
Discuss.
Posted by Martin Heller on December 14, 2007 08:18 AM
November 30, 2007 | Comments: (0)
Three New Products from the Bindows Folks
The Ajax developers at MB Technologies have been busy, and now have posted three new products on their Web site: a Bindows gauges library toolkit, BindowsFaces, and the Bindows 4.0 Beta.
The Bindows gauges library toolkit (of which some sample images are at left) is completely free, and comes with a gauge wizard and a free subset of the Bindows Ajax library. The actual gauges are done with vector graphics and are fast enough to be used for soft real-time displays. Try it out online yourself.
Did I mention that it's free?
The BindowsFaces library, as you might guess from the name, brings Bindows-based Ajax capabilities to Java through JSF. It's for Java Faces programmers who'd prefer not to get their hands dirty with JavaScript or go through a compilation step. According to Ran and Yoram Meriaz, who demonstrated these products for me prior to the launch, BindowsFaces "is better than GWT or Oracle ADF." Obviously, they're biased, but it does look interesting. They say that the technology used to create BindowsFaces could now be used to marry other server technologies to the Bindows client libraries. BindowsFaces is a new component of Bindows 4.0.
The Bindows 4.0 beta "probably makes Bindows the most advanced professional Ajax framework in the market," according to the Meriazes. Again, take that cum grano salis, but the primary design goal of Bindows 4.0 is to add the "ability to define a fully working application without writing a single line of JavaScript." To join the 4.0 beta program, contact sales@bindows.net.
Posted by Martin Heller on November 30, 2007 01:29 PM
November 13, 2007 | Comments: (0)
Google Android: Initial Impressions and Criticism
Over at Javalobby, Jilles van Gurp, a Java developer who works for Nokia, posted some detailed comments about Android based on his initial impressions of the SDK. Basically, he criticized Google for re-inventing too many wheels: the Java profile implemented in Android isn't compatible with any of the existing flavors of Java. On the other hand, he's happy that it's an open platform, and thinks that the planned use of the Apache 2.0 will offer some hope.
What do you think?
Posted by Martin Heller on November 13, 2007 03:01 PM
November 12, 2007 | Comments: (0)
I guess I shouldn't be surprised, since Google has been advertising heavily for Java developers with device experience: the much-hyped Google Android Open Handset SDK is basically a Java API. In addition, it supports XML-based layout files, and contains a variety of development tools.
What tools? An emulator, an Eclipse plug-in, a debug monitor, a debug bridge, an asset packaging tool, an interface description language, SQLite, a trace visualizer, a disk image generator, a bytecode translator, and an Ant script creator.
What does "Hello, World!" look like as Android code? Basically this:
public class HelloAndroid extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
TextView tv = new TextView(this);
tv.setText("Hello, Android");
setContentView(tv);
}
}
There are four building blocks to an Android application:
- Activity
- Intent Receiver
- Service
- Content Provider
I'm oversimplifying, but an activity is a screen, and an intent moves from one activity to another. An intent receiver is an event handler. A service is long-lived non-UI code. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.
For more, read the Android documentation and download the SDK.
Posted by Martin Heller on November 12, 2007 11:33 AM
November 01, 2007 | Comments: (0)
I know that my esteemed colleague Tom Yager loves OS X Leopard to death, but if you're a Java developer or a user of Java applications, Leopard may not be for you, at least not yet, and possibly not ever. Here's the skinny, courtesy of Michael Urban of JavaLobby, who says "So Long Apple, the Party's Over:"
...as we have remained loyal to Apple, Apple has basically spit in our face. Not only did Leopard not ship with Java 6, but Apple, in typical fashion, apparently thinks it has no obligation to its customers to inform them about why the plans changed, and when (or even if at this point?) Apple will ever have a working copy of Java 6. Apparently, Apple has even been just deleting threads in their forums where people are complaining that Java 6 doesn't exist, rather than actually respond to them and let them know if there is any kind of time line for Java 6. But wait... It gets worse...
Java 5 on Leopard is so broken, that some of it is flat out unusable. For example, I recently tested an application I wrote that uses Java2D for image zooming. On Linux, Windows, and on Java 5 in OS X Tiger, it worked fabulously. The scaling and zooming are very smooth. On Leopard, it is not even usable. It's slow, and manages to rescale during zooming at about 1 frame every 5 seconds. Working with IntelliJ IDEA in Leopard has been no picnic either. On a fairly regular basis, it will seem to just hang for 10 seconds or more and then start working again. I suspect the garbage collector is having problems, but once again, these are problems that did not exist in Java 5 with the previous version of OS X.
Caveat upgrader.
Posted by Martin Heller on November 1, 2007 07:34 AM
September 28, 2007 | Comments: (0)
Static Path Analysis and Embedded Systems
In my posting about embedded systems on the 19th, I asked how companies could guarantee the reliability of complicated embedded systems. One set of generic guidelines for this comes from Barry Boehm of USC: see, for example, the Software Reduction Top 10 List.
I know of three vendors addressing this in the embedded space: Coverity, Klocwork, and Parasoft. One technique that all three of these vendors use is static path analysis.
In response to my question about guaranteeing reliability, I got this email from Gwyn Fisher, CTO of Klocwork:
There are software assurance compliance standards that require mission critical systems (e.g. avionics) to provide validation that they've inspected every code path, normally through a combination of manual and automated techniques. This is about as close to a reliability guarantee that exists today, from a software assurance perspective. This is expensive but can be effective for small systems, however, for large, multi-million LOC embedded systems it becomes a more difficult problem to solve. It will always be hard to guarantee reliability for systems of this size and complexity but organizations are engaging in aggressive risk reduction strategies through the use of advanced code analysis techniques. These complement traditional testing techniques and code review methods and provide feasible and cost-effective means that allow an automated tool to at least investigate all code paths for a wide variety of potentially debilitating errors (including difficult to test areas of a system such as error handling routines). The tool makes decisions on which paths are feasible or not, hence worthy of further inspection, enabling the right balance between scalability and intelligent code and defect coverage. If a system can be made free of programming errors through this type of automation, then further along in the development process is subject to rigorous runtime testing, organizations can go a long way to dramatically reducing the risk of field failure and increasing the reliability of business and mission critical embedded systems.
Most developers spend the majority of their time on the true path. Most designers spend most of their time laying out what should happen on the true path. Peer code reviews focus on reviewing the main paths in a system. Most QA organizations spend most of their time testing that the true path does what it’s supposed to do. What about the rest of the system?
Static analysis brings the potential for agnostic coverage:
- Test the false path just as well as the true path
- Validate that the false path doesn’t lead to failure, even in the most “corner” of edge cases
- Ignore a developer’s / designer’s instinct to rigidly peer review only the most “core” of the available code paths – review all feasible paths at all timesThis should be a strong notion for embedded software, since field failure can be very expensive. With current testing techniques it's very difficult to test "edge cases", so static analysis enhances testing coverage for embedded software.
Posted by Martin Heller on September 28, 2007 07:54 AM
September 26, 2007 | Comments: (0)
Belated Notice Department: WORA vs WOTE
Way back in February, in response to an ignorant-sounding comment to a previous posting, I talked about how Write Once languages have never quite done it for me. As is often the case, I tried to restrict myself to my personal experience rather than generalize from that.
Today, while searching for another article I'd written, I came across this lengthy response to that little blog post: Keep an Open Eye » Programming Languages Dynamics.
InfoWorld blogs don't accept track-backs, because otherwise we bloggers would spend all our time killing track-back spam. So this is the first I've seen that essay from March. JBSurveyer raised a bunch of interesting issues, although he also read my posting as being much more generalized than I intended, and tended to put a lot of words in my mouth that I never said.
I'd be happy to reopen the discussion here. Have any languages that claim to be write-once fulfilled their promise? Why or why not?
Try to stick to your personal experience, though. I'm not interested in political pronouncements, or in cheap shots against vendors.
Posted by Martin Heller on September 26, 2007 11:15 AM
July 17, 2007 | Comments: (0)
Cologne Java IDE Shootout: Rashomon
One of my favorite films of all time is the 1950 Kurosawa classic Rashomon. In this movie, a horrible crime is committed in the woods of Japan, and we see it recounted from the point of view of each character, including the victim's ghost. Each one puts a completely different slant on what happened.
There was a Java IDE shootout in front of a user group in Cologne early in July, with presentations about the NetBeans, Eclipse, Oracle and JetBrains IDEs. Reading the articles and blogs of the participants is like watching Rashomon.
The NetBeans article on the event has the title Java and Developers are Winners of IDE Shootout, but emphasizes the NetBeans presentation by Roman Strobl, and makes it sound like NetBeans dominated the event. It also mentions that, as planned, there was no announced winner of the event. Strobl's own first-person blog about the event is here.
Ann Oreshnikova, Marketing Directory of JetBrains, blogged briefly about the event, deferring to the other participants' blogs for details. Her summary:
Not to sound immodest, but my general impression was that IntelliJ IDEA proved to be the best Java IDE not only to the audience, but to the opponents as well
.
Even as pacifists, we still shot them all down.
Oracle's Frank Nimphius called his blog entry JUG Cologne: IDE Bashing - And the Winner is ….; he compared the 30 minute presentations to speed dating.
Michael Hüttermann, the organizer of the event, recounts in IDE Shootout: Roundup that:
The event was absolutely thrilling and the first one in the world hosting the four leading Java IDEs in one session with their official representatives! Beside that never before Eclipse joined one session or stage with competitors. This is a milestone for the whole Java movement!
According to Hüttermann, Oreshnikova's German is "fantastic".
Finally, an audience member, Mark Masterson, a self-proclaimed "hard core IDEA fanboy", blogged about the event, pulling no punches about his opinions.
When doing IDE reviews, I perpetually face the problem that JetBrains faced in this event (and in their sales efforts): How do you compare free products with commercial products? At what point do the free products cost your company money in lost productivity? How much better does a commercial product have to be to make up for its up-front cost in increased developer productivity?
My usual approach is to try to calculate ROI, but I can tell you that it's really hard to do. I usually wind up having to make generalizations about "full-time" or "professional" developers, but in fact every situation is different, and there is no right answer.
Rashomon.
Posted by Martin Heller on July 17, 2007 06:50 AM
May 09, 2007 | Comments: (0)
Is it a case of being in tune with the zeitgeist, or of great minds thinking alike? For whatever reason, Microsoft's announcement of Silverlight last week at MIX07 was followed by Sun's announcement of JavaFX this week at JavaOne.
So, what is JavaFX, and why should we care? According to Sun, JavaFX is "a new family of products based on Java technology designed to enable consistent user experiences, from desktop to mobile device to set-top box to Blu-ray Disc."
To be more specific, Sun says:
- The JavaFX product family leverages the Java platform's write-once-run-anywhere portability, application security model, ubiquitous distribution and enterprise connectivity
- JavaFX initially is comprised of JavaFX Script and JavaFX Mobile
- JavaFX Script is a highly productive scripting language for content developers to create rich media and interactive content
- JavaFX Mobile, Sun's software system for mobile devices, is available via OEM license to carriers, handset manufacturers and others seeking a branded relationship with consumers
It feels like déjà vu all over Again, to quote Yogi Berra. I didn't go to JavaOne this year, or MIX07: the fact is, I rarely go to conferences at all any more. But at one of the early JavaOne conferences that I did attend, Sun announced Java ME, which was going to extend the Java platform down to PDAs and cell phones. I bought a Palm V at the conference that came with an early build of Java ME. The Palm served me well for several years, but I soon lost interest in Java ME.
JavaFX Mobile sounds a lot like what Java ME was supposed to be. For that matter,JavaFX Script sounds a lot like what JavaScript was supposed to be. So what's new here?
In a word, media. Sun's headline for JavaFX is "Dynamic Interactive Content on Any Device". Yes, JavaFX is very much in the spirit of Silverlight and Flash, but of course with a Java-centric twist.
Interesting times...
Posted by Martin Heller on May 9, 2007 09:04 AM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
