Dustin's Pages

Saturday, December 31, 2016

This post is my personal and opinionated assessment of some of the most significant developments related to software development in 2016. This is my tenth year for this annual post and my previous years' assessment are available for 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, and 2007. As with these previous years' assessments, this assessment of 2016's major developments in software development are obviously biased, opinionated, and limited to my perspective.

10. Tumultuous Year for Java

Java and the JVM are used by a significant percentage of software developers worldwide. With the increasing adoption of Java 8 and the enthusiasm Java 8 has helped to reinvigorate among Java developers, Java SE and the JVM seem well positioned for the future. Unfortunately, Java EE faced more issues in 2016. 2016 saw the rise of the Java EE Guardians in response to a lack of news from Oracle regarding the future of Java EE. Oracle eventually did respond in advance of JavaOne 2016 with plans for Java EE 8 being more cloud and microservices oriented. Oracle has also stated that their survey of Java EE developers has shown that REST and HTTP/2 support are of prime importance.

Although the DevOps concept has been around for a while now, it's gained popularity with the "suits" (management) and the term is thrown around in all types of contexts. Software product vendors emphasize how their products continue to DevOps and software development requisitions and job listings are filled with references to experience with DevOps.

The term "Internet of Things" (IoT) has been around for a while and even discussed in mainstream media for a while, but the concept seems to come up in many different technology-related articles and posts in 2016. Because the IoT concept is related to Big Data and Cloud Computing, it is not surprising that it becomes a more prevalent topic as those related topics become increasingly prevalent. The rise of IoT also brings with it significant new privacy and security risks while also bringing convenience to users.

Cloud Computing remained a hot topic in 2016. In the article Why the cloud? In 2016, it was the lure of the new, Eric Knorr writes that "incredible new features all pre-provisioned and waiting for you in the cloud" was the primary reason for enterprises moving to the cloud in 2016. Knorr writes about the cloud offerings' support for machine learning, IoT platforms, serverless computing, and containers management. The IBM blog post The top 10 Thoughts on Cloud articles of 2016, states, "Much of the cloud computing news of 2016 focused on exponential growth in need and demand, which will reach into the following year and beyond."

Related to both Cloud Computing and Big Data is the concept of Fog Computing, which also seems to be slowly gaining momentum in 2016.

3. Microservices

Although I see "Docker", "containers", "Big Data", "Cloud Computing" and similar terms all over the software development blogosphere, I don't think there's a more prevalent topic in that sphere than "microservices." Bilgin Ibryam has written that microservices are a commodity and concludes, "In the Microservices world things are moving from uncharted to industrialized direction. Most of the activities are not that chaotic, uncertain and unpredictable. It is almost turning into a boring and dull activity to plan, design and implement Microservices. And since it is an industrialized job with a low margin, the choice of tool, and ability to swap those platforms plays a significant role."

The microservices architecture approach has been used by enough organizations over enough time now to start sharing lessons learned and best practices. In fact, many of the underlying ideas behind microservices have existed for much longer than the term itself. In the post Working with microservices framework still a challenge in 2016, Tom Nolle writes, "Technology innovation is often hampered by fast-moving waves of hype that confuse senior management with benefit claims that can't be met early in a technology's evolution. Microservices really took off as a concept in 2016 and have been vulnerable to premature expectations." Knoll writes about some positive developments in microservices that helped mitigate this: association with private clouds and with containers and the move toward statelessness in microservices. Knoll also writes about misuse of microservices contributing to a negative experience with them.

Without putting much effort into verifying it, it felt like I could not browse software development headlines on related social media sites such as DZone without seeing at least one (and often many more) story on Docker or other Linux containers. Serdar Yegulalp's InfoWorld article 2016: When Linux containers became mainstream states, "In truth, 2016 wasn't The Year of the Container. That was 2015, when the possibility and promise of containers came along and knocked IT for a loop. But not everyone wanted creative disruption. Many folks wanted dependable, reliable infrastructure, and they saw in containers a method to do so that had never been done before. The good news was that despite all the momentum around containers in 2016, major parts of the ecosystem began to stabilize. The novelty's worn off, but in a good way - it means there's now more attention on how to do containers right, not merely to do them at all."

I really, really wanted to not have this be the #1 software development in 2016 after having a version of this in the top two spots in recent years (2012, 2013, 2014, and 2015). Unfortunately, the events of 2016 made it impossible for me to bump software security related issues from the #1 spot of developments in software development.

Fahmida Y. Rashid's recent InfoWorld article asks, "Do developers really care about security?" We obviously need to care. I would love to see Software Security not be my #1 development in software development in 2017 and not even be in my top ten, but it's difficult for me to see that happening.

Honorable Mention

The following did not make my top ten, but nevertheless saw major developments in 2016.

There's no shortage of programming languages targeting the Java Virtual Machine as their runtime and some of them (Scala, Groovy, Clojure, Ceylon etc.) seem to have found success with JVM developers. Without any empirical basis for it, my feeling is that Kotlin may have enjoyed the most coverage and percentage rise in adoption in 2016. This could just be perspective, but JetBrains' purchasing of advertisements on key software development web sites and evangelism of its employees and fans/customers seem to have contributed to Kotlin being mentioned time and time again on the software development sites (especially those with JVM focus).

Scala 2.12.0 (and Scala 2.12.1) was released in 2016 with the Scala 2.12 compiler "completely overhauled to make use of the new VM features available in Java 8." Scala 2.12 requires JVM 8 runtime because "Scala 2.12 is all about making optimal use of Java 8's new features." A less rosy outlook on Scala 2.12 can be found in the post New Scala Release Falls flat.

The Scala Center at EPFL was announced in 2016 as "an open source foundation for Scala" that "will engage with developers in the open-source community in the effort to improve the language, its tools and its documentation" and "will also help developers learn the language through massive open online courses, seminars and other activities."

Like me, most developers I know are generally positive about open source and the possibilities it enables. We have benefited numerous times from a wide variety of open source products. However, nothing is perfect and open source has its own issues. We were reminded of this somewhat dramatically in 2016 when Azer Koçululiberated all of his modules from NPM after a trademark dispute over kik (now known as hek). It was actually unpublishing of left-pad from NPM that caused the ruckus.

One interesting note about these stories related to open source issues is that each of these has been addressed through steps that take advantage of the code in question being open source. Because these projects were open source, others in the community were able to fork the projects when they did not like their direction or replace the essential code when removed code broke things.

There's been a lot of buzzout of Google about progressive web apps. The author of the post What are Progressive Web Apps? opens that post with the only slightly exaggerated, "By now, you’ve probably heard that Progressive Web Apps are the future of all mankind. They’ll bring world peace, end hunger, save the rainbows and unicorns, bring balance to the force, and a whole lot more. In the process, they might even push the mobile web forward, bring parity to web and native apps, and help mobile developers reach more users beyond the confines of the app stores." That same post provides more clarification of progressive web apps, "On the whole, Progressive Web Apps describe a collection of technologies, design concepts, and Web APIs that work in tandem to provide an app-like experience on the mobile web."

JavaScript continues to be a widely used language, in large part because of its ability to run in web browsers (and on mobile devices) and on the server. Craig Buckler has written in the post JavaScript: 2016 in Review and concludes, "it's increasingly difficult to keep pace with the latest trends, frameworks and recommendations. Developers struggle when faced with a plethora of options to evaluate. My advice: don’t try to keep up. It's impossible. Whatever system you bet on today will be superseded by something better tomorrow. ... There's only one absolute certainty: JavaScript itself. Learn the language first and keep building on your knowledge. Your experience will help you understand how each framework operates so you can make an informed choice. That choice may be to forego frameworks altogether." This quote tells how far JavaScript has come; the last thing I would have wanted to do when starting with JavaScript many years ago was to use it without a framework to hide all of the idiosyncrasies and corners of the browser DOMs.

Although JavaScript, like Java and other programming languages, seems to have countless frameworks, React seems to me to be the one getting the most attention in the JavaScript community when not counting Angular. The project facebook/react currently has a very slight edge over angular/angular.js in terms of stars rating on GitHub.

The State of Rust Survey 2016 highlights some of Rust's wins and some things that need to be improved. A book on Rust was published in 2015 and two more are scheduled for 2017. The O'Reilly e-book Why Rust? can currently be downloaded in PDF.

On the Tiobe Index, "Google's Go is TIOBE's programming language of 2016." In other words, Tiobe found that Go was "the programming language that has gained the most popularity" in 2016. Go ended the year in the 13th overall popularity spot with familiar languages such as Java, C/C++/C#, Python, JavaScript, Perl, and PHP still ahead of it overall. The Tiobe page provides explanations for Go's rise in popularity: "The main drivers behind Go's success are its ease of learning and pragmatic nature. It is ... about hands-on experience [and] Go has built-in support for concurrency programming. More and more customers of our company TIOBE are adopting Go in an industrial setting." Of course, everyone has their own definition of how to measure language popularity. Tiobe's site explains their methodology at a high level.

Much has happened in the world of software development in 2016. In this post, I have looked at a small subset of these developments. I may add a few more honorable mention items in the next week or two, but wanted to get this published while still in 2016.

Friday, December 9, 2016

As I've worked with legacy Java code over the years, I've run into subtle logic and performance issues that could be traced back to improperly overridden Object.equals(Object) methods. Although the concept behind the "equals" method is seemingly simple, Josh Bloch points out in Effective Java that "Overriding the equals method seems simple, but there are many ways to get it wrong, and the consequences can be dire. The easiest way to avoid problems is not to override the equals method, in which case each instance is equal only to itself." In this post, I look at one of "the many ways" to get an equals(Object) wrong: failing to compare exactly the same characteristics of the two objects being evaluated for equality.

The next code listing is for class MismatchedFieldAccessor. This class's equals(Object) method is flawed because it compares the class's direct attribute someString to the value retrieved from the other object's getSomeString(). In most Java classes, comparing a class's field to its accessor/get method will work properly because the accessor/get method simply returns the associated field. In this example class, however, the accessor/get method does more than simply returning the field and that makes the comparison of the field to the get/accessor method in the equals(Object) method inconsistent. (Note that the idea of having a "get" method do this type of thing is not being recommended here, but merely exists as a simple-to-understand example.)

The second unit test makes use of the handy EqualsVerifier library to identify an issue with this equals(Object) implementation (emphasis added):

java.lang.AssertionError: Reflexivity: object does not equal an identical copy of itself:
dustin.examples.brokenequals.MismatchedFieldAccessor@0
If this is intentional, consider suppressing Warning.IDENTICAL_COPY
For more information, go to: http://www.jqno.nl/equalsverifier/errormessages
at nl.jqno.equalsverifier.EqualsVerifier.handleError(EqualsVerifier.java:381)
at nl.jqno.equalsverifier.EqualsVerifier.verify(EqualsVerifier.java:367)
at dustin.examples.brokenequals.MismatchedFieldAccessorTest.testEqualsWithEqualsVerifier(MismatchedFieldAccessorTest.java:36)

This post has covered one of the many ways in which an equals method can go bad if not carefully implemented, reviewed, and tested. Fortunately, the fix for this particular problem is easy: always compare the exact same field or same method's returned object of the two instances being compared for equality. In the example used in this post, comparing the two "someString" fields directly would have made the "equals" method work properly.