The number of organizations investing in Scala is exploding, and for good reason. Scala combines Object Oriented and Functional capabilities as well as immutability, which makes it an extremely powerful foundation for applications that need to run at massive scale. This series of blog posts on Scala aims to bridge the gap between theory and practice by focusing on something that is not easily found on the open internet: Actual examples of functional concepts being used in production, at scale. We’ll even give you code samples! Part 1 of the series dives into something that’s near and dear to all of us: how to incorporate error handling as a primary concern with a minimal level of effort.
Disclaimer: This series assumes that you have a basic knowledge of Scala. You’ll still be able to read most of the examples if you don’t know Scala, but you might miss some nuances.
JBoss EAP 7 has recently been fully Java EE 7 certified. For most developers this essentially represents serious commitment from Red Hat towards commercial support for Java EE 7. As many of us know, WildFly (the upstream community project for JBoss EAP) was one of the earliest Java EE application servers to get certified against Java EE 7. There are already numerous publicly known adoption stories for Java EE 7 on WildFly. However, a lack of Red Hat commercial support for WildFly had been a show-stopper for many - particularly very large enterprises. JBoss EAP removes this hurdle and is bound to be a further boost to Java EE 7 adoption. In my view JBoss has ranked for many years as one of the best Java EE implementations and with significant adoption. That said, one of the most valuable characteristics of Java EE is the rich implementation choices it offers (and hence the freedom from vendor lock-in).
JBoss EAP 7 joins the Java EE 7 compatible ranks of GlassFish 4, WildFly, WebSphere Liberty Profile 8.5, WebLogic 12.2.1, Hitachi Cosminexus and TmaxSoft JEUS. All of the Java EE certified offerings are always listed on the official Java EE compatibility page. For some perspective, few other open standards such as SQL have as many available implementations as Java EE 7 already has (and this is bound to only just keep getting better).
Truism: Source code is for people, not machines. So... minds with a rather different (and legit-globally state-dependent) cognitive architecture than a von Neumann machine. That includes all your current and future colleagues, your future self, anyone who might conceivably use your library in the future... and if your code is open-source, everyone from now until the heat/cold death of the universe.
So naming things in a human-readable ("self-documenting") way is important. And it's not easy (1, 2, 3, 4, 5, 6...). Getting it right can feel like a semi-unpleasant responsibility, like anything else that takes you out of that creative coding flow; but we've all scratched our heads (or gritted our teeth, or glared viciously) at someone else's opaque, idiosyncratic, or just confusing naming conventions ("Is this the same as that except that this has an underscore and that doesn't?? But the code looks different!... I think?")
This is a temporary post that was not deleted. Please delete this manually. (ddae0643-8b1c-4107-80be-282fe283e924 – 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Apache PDFBox 2 was released earlier this year and since then, Apache PDFBox 2.0.1 and Apache PDFBox 2.0.2 have since been released. Apache PDFBox is open source and Java-based, so it is easy to use with wide variety of programming language including Java, Groovy, Scala, Clojure, Kotlin, and Ceylon. Apache PDFBox can be used by any of these or other JVM-based languages to read, write, and work with PDF documents.
Apache PDFBox 2 introduces numerous bug fixes in addition to completed tasks and some new features. Apache PDFBox 2 now requires Java SE 6 (J2SE 5 was minimum for Apache PDFBox 1.x). There is a migration guide that details many differences between PDFBox 1.8 and PDFBox 2.0, including updated dependencies (Bouncy Castle 1.53 and Apache Commons Logging 1.2) and "breaking changes to the library" in PDFBox 2.
The JSON-B (Java API for JSON Binding) specification has recently released a public review draft. For those unaware, JSON-B is one of the key APIs slated to be included in Java EE 8. It is a very high level declarative, annotation-based API for processing JSON. Java EE 8 is also scoped to include an important revision of the lower level JSON-P (Java API for JSON Processing) specification.
These two APIs together are extremely important in making JSON a first class citizen of the standard Java platform, just like JAXP (Java API for XML Processing) and JAXB (Java API for XML Binding) did many years ago for XML. With these two APIs in place, Java developers can simply think of JSON as yet another Java serialization format. No more third party libraries and no more configuration - things will simply work out of the box when it comes to processing JSON. In my view these APIs are so critical they should indeed be moved to a modular Java SE release, much like JAXB and JAXP are already a part of Java SE.
Ceylon has featured a modular architecture from the start. Not just for Ceylon users who write modules, but also within the Ceylon distribution. Historically we used to have very few modules, that were directly related to separate Git projects. Adding a new module meant a new repository and lots of changes in the build. Naturally, as the project grew, each of those modules also grew, and got new third-party dependencies, and occasionally adding a feature in one module was made tremendously easier by just adding that "one more" dependency between distribution modules, resulting in a big spaghetti graph of distribution modules that is common in older/evolved systems.
As we initially expected most Ceylon users to run their code using the
ceylon run command, we figured that since they have the Ceylon distribution installed, it does not matter if they depend on more modules from that distribution than strictly necessary. Those modules had to be there anyway, so it would not save any bandwidth to reduce those dependencies.
JayWire is a small, easy to use magic-less Dependency Injection library for Java 8. This article is a short tutorial on how to get started using it in projects of any size from small single- to large multi-module ones.
Interestingly enough, the key feature of JayWire is not that it can supply objects as dependencies to other objects, nor that objects may be defined to have a scope (such as singleton scope, request scope, etc.). These are all supported by every other DI framework out there.
The Google GitHub-hosted project AutoValue is interesting for multiple reasons. Not only does the project make it easy to write less Java code for "value objects," but it also provides a conceptually simple demonstration of a practical application of Java annotation processing. The auto/value project is provided by Google employees Kevin Bourrillion and Éamonn McManus and is licensed with an Apache Version 2 license.
The AutoValue User Guide is short and to the point and this conciseness and simplicity are reflective of the project itself. The User Guide provides simple examples of employing AutoValue, discusses why AutoValue is desirable, short answers to common questions in the How Do I... section, and outlines some best practices related to using AutoValue.
/** * This post is intended to be a 101 quickie for the less experienced. * It does not provide new or innovative ways of solving a certain problem, * just summarizes a topic the way I see it. * **/
This is a topic many have already talked about (a lot), but it still pops up from time to time. Strangely enough, not only in case of junior developers.
You are given a constructor full of business logic; it opens files, sockets, creates message queues etc. Usually it looks something similar to the snipped below:
Optional class were introduced in order to prevent NullPointerException, but method get() used to retrieve the value inside the Optional might still throw a NoSuchElementException.
Different name, same issue?
A recent article about various ways to implement structural pattern matching in Java has triggered my interest:
Today we bring you a new Grails Quickcast, where Grails Core Team Member James Kleeh brings together Grails and Angular. In less than ten minutes, you’ll learn how to use Grails to build a simple reactive site in Angular.js. The Grails Quickcast is brought to you from OCI and DZone. You can get more Grails info at grailsblog.ociweb.com.
This Quickcast walks you through using the Angular Scaffolding for Grails to build a fully functional web app, using a simple blog format for demonstration. The tutorial explains how to have Grails set up a REST endpoint and all the Angular modules needed to get the web app running.
SOLID (single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion) is a set of principles popularised by ‘Uncle’ Bob Martin that aim to guide developers in implementing good software design. The principles define how Object Oriented classes should relate to each other in order to create a codebase that is flexible and able to accommodate ongoing change.
The first of these, the Single Responsibility Principle (SRP) states that -
[This article was first published on the XP2016 blog in April 2016.]
Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of “Professional” or “Certified” (but ironically not both) schools of Scrum training. But it was not always so.
What led to the plethora of practises, religion and superstition that surrounds modern “agile” methods? What follows is an amalgam of what may have happened. It is the result of my conversations with a number of early agile practitioners along with my own experiences as both an in-house and contract developer during the 1990s. It is, as they say, “based on real events”.
The earliest agile projects, or at least those projects whose participants would describe them as agile, started with a single constraint:
We will deliver something, fully-functional, into production, in 12 weeks. What’s more, we won’t just fly blind for that time, we will sprint to halfway, pause, course-correct, then sprint to the finish.
So the first sprints were six weeks long. One sprint, pause, another sprint, release what we have. Nowadays this seems like an insane amount of time to run without checking in with the plan. Six weeks without even a showcase? That’s irresponsible! Back then, in the early 1990s, it was considered equally insane but in the other direction. Six weeks? You can’t possibly do anything meaningful in six weeks! This was in an era when 18 months between releases was pushing the envelope, and a multi-year software project on a monster Gantt chart, with a single release at the end after many months of integration and further months of testing, were the norm in large organisations.
Chris Matts, product and portfolio management consultant and father of Real Options, uses the term “breaking the model” for introducing a constraint that exposes inadequacies in the status quo. “I’m sure we could improve this system of work, so how could we break the model?”
If you ask a team to target 16 months instead of 18 months for the release, they will try to do whatever they do now but harder. They might start working longer hours or occasional weekends, cutting corners here and there, squeezing a few percent more out of their practises at the expense of their health or sanity. When you introduce a constraint of a 12 week release with a showcase halfway through, they have to radically rethink their approach. They expect a feature to take months to analyse, design, code and test. All these activities are specialised and we batch them up, so we do all the analysis and then start on all the design. Frameworks like RUP blurred the boundaries, so “construction” was supposed to start while “elaboration” was still ongoing, but the all-or-nothing thinking was still steeped in its civil engineering roots and RUP was distorted into another heavy gated process.
Waiting for the analysts to finish all the analysis and the architects and senior programmers to finish the high-level design and functional specifications clearly wasn’t going to work. “12 weeks? This is crazy!” People assembled themselves into cross-functional teams that could autonomously analyse, design, code and test a single feature. The features themselves were sliced into work bundles that could be reasonably achieved in six weeks with some kind of business outcome at the end. Monthly status meetings weren’t going to cut it in a six week “sprint” so they started meeting more frequently. Weekly at first, and then daily as they realised how much they could drift in a week. “Six weeks? This is nuts!”
These people had never had to collaborate with the other disciplines before. Requirements were handed from analyst to technical architect in a formal ceremony involving the shedding of blood and the summoning of the Governors. Similar ceremony surrounded the hand-off of detailed functional specification from architect to humble programmer, and so on down the line. There was suspicion, mistrust, but mostly ignorance of the other roles.
The mavericks who had suggested the 12 week release found themselves in a coaching role, helping the people work together as a team, identifying and removing impediments, making suggestions as the team organised itself around this new way of working. If the daily huddle was like a rugby Scrum, then this person was the Master of the Scrum.
Similarly, most of the team had never thought about the end users of the systems they were building. The programmers were too busy converting the functional specifications in their in-tray into code modules in their out-tray, the testers were too focused on working through the test specifications and keeping to the testing schedule, and so on. So another role emerged, owning the holistic view of the software product, a Product Owner if you will. This person would help the team members understand how their work contributed to the product as a whole, and how this product would deliver value to the wider business. This meant the team could make trade-offs of options for the technical solution, prioritise which features made sense to deliver first, and which ones went together.
The first release wasn’t an impressive affair, but it was a release, and it contained actual working features. And the team was hooked! They had transformed a business need into a set of features that met that need in less time than they used to spend writing the requirements document! No wonder they started calling themselves “hyper-performing”. Nowadays we might think of a six week sprint or only releasing once per season as primitive, but back then it was truly game-changing. And then a funny thing happened.
There are two ways a community defines itself. A centred community forms around a set of values or ideals. You can be closer or further from the centre but there is no sense of “exclusion”. A bounded community defines itself by boundary markers. These may be specific words they use, clothing they wear, ceremonies they carry out or foods they eat or avoid. Adherence to these boundary markers determines whether you are inside or outside the community.
Bounded communities tend to obsess about the boundary markers and can lose sight of the original values and goals of the community. It is easy to attach a political agenda to the boundaries, which is when religious or tribal factions emerge, then they use the boundaries to justify censure or even violence. More extreme factions adopt more extreme boundary markers, and any violation of this increasingly involved code is denounced as heresy. This is also an effective way to grow the community. Membership of the community is seen as desirable, or in extreme cases as necessary for survival. “Swear allegiance to us or die, heretic!”
Bringing this back to software methodology, one of the most effective boundary markers is certification. You either have a certificate or you don’t. You are one of us or you are not. Once the tribe grows large enough, certification is seen as a valuable end in itself. The more certified professionals we have, the more capable we are, surely? The lucrative nature of providing certification means the certifying body are happy to reinforce this belief.
Boundary markers often start out as good advice that a community adopts. Eating pork or shellfish in the Middle East in biblical times was a fairly risky thing to do! And draining the blood from an animal before eating it–a trait common to Jewish and Muslim faiths–would have been a good way to remove most of the dangerous bacteria in an age when people knew little about food hygiene or health.
Checking in with the team every day makes sense to keep on track, and having a short list of upcoming work means everyone can see what the latest priorities are. But these good ideas have morphed into rigid structures and ceremonies.
These days Scrum has become the dominant agile method. For anyone who has been in the industry less than 15 years, “Agile” has always existed, and mostly as some variant of Scrum. Teams made up of testers, analysts and developers are normal in many companies, and most people have a decent idea of what they are building, why and for whom. Having a Scrum Master in this context is anomalous, as is the idea of a Product Owner, so we find ourselves in a situation where the tail starts to wag the dog.
A team with a Product Owner absolves itself of responsibility for product prioritisation decisions because the Product Owner does all that. The Scrum Master takes on more of a traditional project manager role, tracking and reporting progress, and cajoling the team to go just a bit faster, try just a bit harder, as though they wouldn’t think to do that on their own.
That doesn’t mean we don’t need coaching, or we don’t need product prioritisation. Product ownership is a team activity, in the same way code ownership is a team activity. If the entire team doesn’t have a sense of ownership of the product and its purpose, how can they be genuinely self-organising around that purpose? Having a product specialist to coach the team is as valuable as having a testing specialist to coach the team in testing. The failure mode is to absolve responsibility onto that specialist, which systemically depletes the team’s capability in that area.
The original motto of Scrum was “inspect and adapt”. These days I see little inspecting and adapting and much blind adherence to process. Maybe it is time to cast a critical eye over each of your “agile” practises and ask yourself a few questions:
What is the intent of this practise? What should it give us? Is the way we are practising it giving us that outcome? How else could we get that outcome in this team, in this context? Is it even relevant to us?
Once you start asking these questions you will see your process through a different lens. Now you can inspect and adapt. Now you can start to train your Agile.
Amazon AWS starts our day with the availability of their Elastic Network Adapter. This is more infrastructure from Amazon in their quest to have you own no IT hardware. On Ayende @ Rahien, we have another database internals post, this one about managing records. This post really starts to show how complex database systems are for the simplest use cases. Johanna Rothman continues her Product Owners and Learning series. This installment, as much of her content, is something everyone should read.
As always, enjoy today’s items, and please participate in the discussions on these sites.
Packaging is one of the underrated features of Java. We use common sense to put things here and there, after some time everybody knows where certain things go and nobody cares anymore. Well, as long as it doesn't slow you down, it doesn't shock newcomers, and everybody on the team is fine with it, you should be just fine. Nothing wrong will happen. In the end, IDEs are so smart that it only takes a few clicks to reorganize the whole project. But we can do better! We can really benefit from a good package structure.
You don't have to start with a reversed domain. You should, but you don't have to. You can use camelCase, you can even use underscores and numbers! Only one thing is important: CONSISTENCY. Decide on a certain convention for the project and stick to it. Everybody_hatesInconsistencies_or_atleastIdo.
Working with the ZAP API recently I found myself writing code like this:
The API was constructed around the idea of key/value pairs, and often returned objects that had to be cast to more specific types, which forces you to add a lot of boilerplate code for simple tasks like getting the ID of the last scan. Still, code like this was getting out of hand.
This week saw me finally taking time to analyze our code base with Sonar. In particular, I was made aware of plenty of issues regarding floating-point arithmetics.
Those of you who learned Java in an academic context probably remember something fishy around FP arithmetics. Then if you never used them, you probably forgot about them. Here’s a very quick example of interesting it turns out to be: