Monday, May 31, 2010

Grab Bag: Android, JavaFX, and the Allure of Software Engineering

There have been a few recent online articles and posts that I think deserve mention here. These are related to Android being good for Java, praise for the field of software engineering, and a sense of what Java developers think of JavaFX.


Software Engineering: High Pay, Low Stress?

A recent Yahoo! Finance posting of a Investopedia article (Five High-Paying, Low-Stress Jobs) list software engineering as one of their five jobs with high pay and relatively low stress. Some of us may not agree with the stress part, but it is not going out on a limb to say most of us do have less stress than a combat soldier (referenced in the article as an example of low pay and high stress). Under "Computer Software Engineer," the article states, "many software engineers can work from home, since their jobs can be done from practically anywhere. Software engineers also bring home steep salaries, normally ranging between $54,000-130,000 a year. There's nothing nerdy about that."

Another position closely related to software development also made this list of five professions proposed to be high pay and low stress: the technical writer. The other three careers on this list are civil engineer, physical therapist, and massage therapist.


Android: Bringing non-Java Developers to the Java Fold

One of the effects of the rapid rising popularity of Android-based telephones is the new entrants into Java's ecosystem of developers from non-Java environments. For example, the author of the blog post Android Development - Debugging Your App starts that post with the sentence clauses, "Coming from a Windows environment, specifically the .NET space," and then goes on to talk about debugging in Eclipse

The significance of this, of course, is that a whole new group of developers with little or no Java experience are now essentially working with Java itself as they develop Android applications and are using tools of the Java ecosystem such as Eclipse. Java may have originally been targeted at the web browser (applets) and may have in recent years become known as a technology for the enterprise space, but now it appears that it could be the Android-based handsets that bring standard Java (but not Java ME nor JavaFX) a growing base of users. Who would have predicted this before Android?


Java Developers on the Future of JavaFX

A recent Java.net poll asked the question, "Will JavaFX ultimately become a widely used rich client technology?" None of us have a crystal ball and these polls are obviously non-scientific, but I thought the responses were pretty inline with my own opinions based on talking to other Java developers about JavaFX. The respondents seemed to really consider the issue and provide a fair personal assessment. There were also several good comments added.

To the question of whether JavaFX will become widely used as a rich client technology, well over half of the nearly 370 responses were either flat-out "No" (18%) or the little less sure "Probably Not" (a whopping 40%!). About 16% of the responses were the tepid "Maybe" while about the same percentage were more positive and answered either "It's already widely used" (2%) or the much more realistic "The Version 1.3 Improvements Make it Likely" (14%). I don't see how anyone can think that JavaFX is widely used currently (unless the interpretation of "widely used" differs significantly from mine) and the results show that few legitimately believe that to be the case.

There are several observations from this poll. First, JavaFX still has more people thinking it won't become a widely used rich client technology than those who think it will. Second, I think this poll shows once again that the Java development community (or at least the members of the community who read Java.net and participate in the polls) are cognizant of what's happening around them. Third, the comments on this poll are really worth reading. I think they sum up pretty well some of the major concerns the majority of Java developers who think about rich client technologies have about JavaFX.

Monday, May 10, 2010

Online Resources: Android Development, Future of Java, Careers in Software Development

This was another week in which I ran across several blog posts and articles that I thought was particularly interesting and relevant. In this post, I reference these and quickly add my own thoughts on the various subjects. The topics covered by these posts I am referencing are quite diverse, but some common themes do underlie most of them. The individual topics covered include Android development, more on the future of Java, some "current Java" posts, and some insightful posts of software development career development.


Android Development

I recently upgraded to a Droid and have been more interested in Android ever since. There were several reasons for me choosing Droid, one of which was its Android SDK and the ability to leverage my Java experience in Android development as a hobby.

There have been several recent interesting posts on Android development. Besides the obvious sources of information on Android development such as the Android Developers site (including SDK information, The Developer's Guide, the SDK API/Reference, and the Android Developers Blog), there are nice community-oriented sites as well. Android Development Matters is one such site where various articles, posts, and forum messages related to Android development are all collected in one location.

Tim Bray is a prolific blogger and having him on the Android team has led to an influx of Android-related information. For example, his latest post on the Android Developers Blog is called Be Careful with Content Providers and warns Android developers to use undocumented content providers to learn from, but to not base their applications on these. Based on his comments, these undocumented content providers sound similar to classes and packages that Sun included in its Java SDK releases to get things done internally, but did not want developers using directly. Like these Sun examples, the Android internal content providers could change or be dropped at any time.

Although I partially selected Droid because of my interest in creating Android applications at a hobbyist level and although I purchased a book on Android development, I haven't actually started developing my first Android application yet. This in mind, it was nice to read a very quick summary of what one does to create an Android application in Team Pi's A Step-by-Step Guide to Write Your Own Android App. That extremely concise summary boils down the essence of writing an Android application, but for just a little more investment of time, one can go to the original source of this information referenced at the end of the post: How to Write Your First Google Android Application. Of course, the Android Developers Guide section on Application Fundamentals has provides nice introductory information.

In Is the Android truly open source?Amy Vernon acknowledges that Android "is indeed more open than theiPhone," but is then critical Google for not being as open to outside decisions as they could be. I'm not sure if the author realizes that some of the most successful open source projects have been this way for some time now. SpringSource heavily controls the vision and future of the open source Spring Framework and Sun heavily controlled the decisions related to open source projects such as GlassFishNetBeans, and so forth. IBM has had similar influence in the earlier years of Eclipse development. Other examples include Google's support of several projects including the Google Web Toolkit and Adobe's sponsoring and guidance of Flex. Even theApache Software Foundation provides similar guidance and vision for its projects.

Most of us like to think of open source projects as being more than just source that we can view and possibly modify for our own needs. We like to think of the community providing input and coming up with the best results. This has even worked well in some limited cases. However, many of the successful open source projects (including those I just mentioned) seem to have benefited from a single vision of a controlling organization (be that SpringSource, Sun, IBM, Oracle, Apache Software Foundation, etc.). In even more practical terms, organizations like SpringSource and Sun have contributed substantial resources to these projects. Without these contributions, these projects would be nowhere near where they are today. Most of us know the disaster that often follows "designed by committee" (EJB 1.x and 2.x are great examples) and having a single guide for an open source project seems to be a common characteristic of many successful open source projects.

Although I believe that Vernon unfairly minimizes (even as she acknowledges its existence) the gap in "openness" between Android and iPhone, I think one of her statements is particularly important for all developers to remember: "I'm not a developer, so as long as the phone does what I want/need it to, I'm good with it." Too many developers waste time and creative energy arguing over the merits of their favorite operating system, their favorite web browser, their favorite RIA technology (Flash versus HTML5 and Apple versus Flash being among the latest rounds), etc. The sometimes difficult to swallow fact of the matter is that developers' preferences are secondary to the preferences of end users and clients. They don't care how it's implemented as long as it does what they want. No matter how cool or nice a new technology is, it won't necessarily win unless it brings noticeable value to the end user. In Android's case, the end user still typically doesn't care that the development behind Android is more open than it is behind iPhone. However, this difference in openness may ultimately help Android in the sense that more developers will be willing to build their ideas into viable applications on a more open system.


More on the Future of Java

A week ago, I posted a similar post to this one in which I referenced and discussed several posts from the blogosphere that were of particular interest to me. Many of these were related to discussions about the "future of Java." Just after posting that collection, I ran into the insightful post "Java Post Mortem with Gilad Bracha" that summarized two presentations by Bracha at JAX.de 2010. I like this post for a couple reasons. First, it is a nice summary and analysis of Bracha's main points. Second, I think the points are insightful. These include points such as "Java is going to stay but it is going to stay where you don’t want to look" and "Complicated is not a sign that you’re clever. It is a sign that you failed." This summary is well articulated and worth the small investment of time required to read it.

Joseph D. Darcy posted Project Coin: Multi-catch and final Rethrow, a post that looks at the exception handling improvements coming to JDK 7. Based on the comments on this post, the "final" portion seems the most confusing and controversial. Darcy's current (most recent post as of this writing) is Draft of Restarted "OpenJDK Developers' Guide" available for discussion and is specific to JDK 7 as well.

Jens Schauder's post The Question Isn't What is Going on at Oracle and Sun outlines some warning signs to watch for that indicate "that Java is turning into just another kind of COBOL." Schauder points out some ways to transition to other languages when it is time to actively move to languages other than Java if you have not done so already.

Back to Today's Java

Although reading about the future features of Java can be exciting, it is often more practical to learn about what we can do today and to learn from each others' experiences. Along these lines, I found the post How we solved – GC every 1 minute on Tomcat to be interesting. In this post, Sumit Pal discusses the non-standard -XX:+DisableExplicitGC option for the HotSpot JVM. The reader feedback is helpful and adds some background details as well. When I blogged that more developers should write blogs, this was the type of post I had in mind.

In Annotation or Not, the post's author enters the debate regarding when it is appropriate to use and not to use Java annotations. I think most of us welcome annotations to a certain degree and the main part of the controversy now seems to surround what is appropriate for annotations and what is not appropriate for annotations. As I discussed in the article Basic JPA Best Practices, I like how JPA allows you to use annotations but override them via external (XML) configuration as needed. 


Software Development Career Development

There were two online resources this past week that I thought were particularly thought-provoking in the area of career development for software developers. In the post 10 Ways to Suck at ProgrammingDonnie Garvichdocuments ten things that "are really just things that every good programmer should already know to avoid." Among these ten things, a few of my favorites are "Never, ever remove functionality," "Document NOTHING," and "Catch all errors -- and do nothing with them." These and several others on his list were all too familiar for me (because of others' misbehaviors, of course). As with many of the best posts, the reader comments and feedback messages were also generally useful and interesting and included some additional items that could have made this list.

I have blogged before about my appreciation for posts that require the poster to sacrifice personal pride to provide a lesson from which we all benefit. This happened for me this week in the reddit programming postcalled I am now practically unemployable by everything I read. Any advice? Although this is somewhat anonymous (its author is unemployed58), it is still admirable that this author was willing to lay some personal career details out there. This post is a reminder that software developers need to stay current. It's a little frightening, though, that this author has stayed current to a degree, at least at the hobbyist level, but has still found himself unemployed for two years.

I often think developers waste a lot of time chasing fads because of dysfunctional motivators such as resume-driven development, the magpie effect, and so on, but this post is a reminder that there are problems on the other end (never doing anything new or different) as well. The post's author ends with, "I apologize for the rant just feeling a little frustrated today." I don't think there's any need for an apology. In fact, I appreciate the fact that this was posted and can be a reminder for all of us. Some of the feedback comments on this post are also useful in terms of ideas for the original poster that might work for all of us to reduce the chance of ending up in that situation and to deal with that if/when it does occur.

In Programmer Tip: Work Less, Stay Focused And Say No To Random Meaningless SloggingRajiv Popat points out the need for most developers to creatively solve problems in reasonable amounts of time rather than slogging away for 14 hour days (perhaps a dialect of presenteeism?).


Conclusion

I cannot come even close to reading all the content related to software development that comes out online each week that looks interesting to me. However, the resources that I referenced in this post are ones that managed to grab my attention amid the noise and bustle of the blogosphere and which I can wholeheartedly recommend for busy developers to invest time in reading if the covered topic is of personal interest.