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 DevelopmentI 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 the
iPhone," 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
GlassFish,
NetBeans, 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 the
Apache 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 JavaA 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 JavaAlthough 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 DevelopmentThere 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 Programming,
Donnie Garvich documents 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 post called
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 Slogging,
Rajiv 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?).
ConclusionI 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.
