Defense programs have built-in checkpoints, with formal reviews and document deliveries more suitable for waterfall than agile. Agile programs find creative ways to make things work.

Journald is a log data storage and collection system. Here's an overview of Journald, and why it's great, with a glance at Syslog issues and Journald improvements.

Check out how to get up and running with JBoss Enterprise Application Platform 7! This comprehensive video will get your going with JBoss EAP 7.

Developers can write applications to Couchbase using many different languages and multiple SDKs. This post explains how to deploy and access a NoSQL database from JBoss EAP 7.

A list of what kinds of defects are most easily detected by automated testing, reducing the workload of your QA teams.

How to get a task running on a separate thread to finish early, or make that task responsive to such a finish request.

A review of how to express dates in JavaScript, using a junior programmer's code as an example.

It's commonly said that everyone does Agile differently. In my experience, it's also common to do basically whatever you want and call it Agile. It can be useful to occasionally reset and examine what canonical Agile recommends.

Things I learned on my path from a Technical Lead to a Scrum Master. My transition flowed from ScrumDude, to ScrumMom, to finally Scrum Master.

A look at how to implement the command pattern in the Spring framework.

Check out these Reactive trends on the JVM, including a look at what Reactive is, patterns, and event logging.

Insights on how to make an average velocity concept a powerful tool for your Agile team.

Apache Struts 2 and SpringMVC, these two are the most popular and much talked about Java web frameworks today. Many of you might have worked with both of these frameworks, but which is one is better to use? What are the basic differences between both of these frameworks? Well, Apache Struts 2 is an elegant and extensible framework that is used for creating enterprise-level Java web applications. It is designed to streamline the development cycle, starting from building to deployment and maintenance of the application. In Struts, the object that is taking care of a request and routes it for further processing is known as “Action”. On the other hand, Spring MVC is a part of a huge Spring framework stack containing other Spring modules. This means that it doesn’t allow developers to run it without Spring, but the developers can run the Spring Core without Spring MVC. The Spring MVC (Model View Controller) is designed around a DispatcherServlet, which dispatches the requests to handler with configurable handler mappings, view resolution and theme resolution. While the objects responsible for handling requests and routing for processing in Struts called an Action, the same object is referred as Controller in Spring Web MVC framework. This is one of the very first differences between Spring MVC and Struts2. Struts 2 Actions are initiated every time when a request is made, whereas in Spring MVC the Controllers are created only once, stored in memory and shared among all the requests. So, Spring Web MVC framework is far efficient to handle the requests than Struts 2. If we talk about the features, Struts 2 and Spring MVC framework caters different level of business requirements. Let’s take a look at features offered by both of these frameworks. Struts 2 features Configurable MVC components, which are stored in struts.xml file. If you want to change anything, you can easily do it in the xml file. POJO based actions. Struts 2 action class is Plain Old Java Object, which prevents developers to implement any interface or inherit any class. Support for Ajax, which is used to make asynchronous request. It only sends needed field data rather than providing unnecessary information, which at the end improves the performance. Support for integration with Hibernate, Spring, Tiles and so on. Whether you want to use JSP, freemarker, velocity or anything else, you can use different kinds of result types in Struts 2. You can also leverage from various tags like UI tags, Data tags, control tags and more. Brings ample support for theme and template. Struts 2 supports three different kinds of themes including xhtml, simple and css_xhtml. On the other hand, Spring MVC framework brings totally different set of features. Spring MVC features Neat and clear separation of roles. Whether it is controller, command object, form object or anything else, it can be easily fulfilled with the help of a specialized object. Leverage from the adaptability, non-intrusiveness and flexibility with the help of controller method signature. Now use existing business objects as command or form object rather than duplicating them to extend the specific framework base class. Customizable binding and validation will enable manual parsing and conversion to business objects rather than using conventional string. Flexible mode transfer enables easy integration with the latest technology. Customizable locale and theme resolution, support for JSPs with or without Spring tag library for JSTL and so on. Leverage from the simple, but powerful JSP tag library known as Spring tag library. It provides support for various features like data binding and themes. Of course, Struts is one of the most powerful Java application frameworks that can be used in a variety of Java applications. It brings a gamut of services that includes enterprise level services to the POJO. On the other hand, Spring utilizes the dependency injection to achieve the simplification and enhance the testability. Both of these frameworks have their own set of pros and cons associated with it. Struts framework brings a whole host of benefits including: Simplified design Ease of using plug-in Simplified ActionForm & annotations Far better tag features OGNL integration AJAX Support Multiple view options and more However, the only drawback with Struts 2 framework is that it has compatibility issues and poor documentation. On the other hand, Spring MVC provides benefits like: Clear separation between controllers, JavaBeans models and views that is not possible in Struts. Spring MVC is more flexible as compared to the Struts. Spring can be used with different platforms like Velocity, XLST or various other view technologies. There is nothing like ActionForm in Spring, but binds directly to the domain objects. Code is also more testable as compared to the Struts. It is a complete J2EE framework comprising of seven independent layers, which simplifies integration with other frameworks. It doesn’t provide a framework for implementing the business domain and logic, which helps developers create a controller and a view for the application. However, like any other technologies or platforms, Spring MVC too suffers from several criticisms related to the complexity of the Spring framework. Final Verdict Either framework is a great choice. However, if you’re looking for the stable framework, Struts 2 is the right choice for you. On the other hand, if you’re looking for something robust, SpringMVC is perfect. Ensure that you review your exact requirements before choosing the framework!

A list of fun and, oftentimes, true quotes about DevOps and software development.

A definition of verification and validation in regards to automated testing, and a guide to using them in your workflow.

A brief history of story points, and why they're not as useful as they may seem at first glance due to the complexity they introduce.

An analysis of how much of DZone's audience lives up to the lofty goals of the Agile Manifesto.

You’re sitting at your desk, trying to “track” down a bug that’s been reported, when it happens. The hunt takes you into some method that inspires you to do a double take. It’s about 1,200 lines long, it has switch statements nested three deep, and you think (but you aren’t sure) that it does the same thing two or three times in a row for no particular reason. You look at the source control history and see that this is another “Bob special.” After seeing this, you start thinking about finally having a long overdue talk with Bob so that you don’t have to keep cleaning up these messes. That sure won’t be a fun talk. So how do you approach it? Philosophically Speaking Let’s be clear about something up front. Getting really good at telling teammates that their code is littered with problems is like getting really good at breaking into your car after locking yourself out of it: it’s tactically useful in the moment but indicative that you need a better overall strategy. Your goal shouldn’t be to master gently telling coworkers about their bad code but rather to make the mastery unnecessary. And I say that not as some kind of meta cop-out, but rather to put your strategy into context as an attempt to start or further a relationship. “Getting really good at telling teammates that their code is littered with problems is like getting really good at breaking into your car after locking yourself out of it.” Tweet This Quote When you’re part of a team, someone on your team who is committing bad code is a failure of everyone on the team—yourself included. So as you prepare for the intervention you’re planning with the person in question, keep in mind that you aren’t some kind of neutral crime scene investigator, sizing things up antiseptically. You’re part of the problem, and you share in the responsibility. Your team. Your code. Your problem. The good news is that if you approach this conversation constructively, you’re taking the first step toward fixing the problem, the code, and thus the team. So the key is making it constructive. 5 Ways to Not Make Code Criticism Constructive Before I go into detail about how to approach this conversation, I’ll give you a quick rundown of 5 things not to do. Don’t have the conversation when you’re frustrated or angry. Instead, wait until you’re calm and rational. Don’t get into this unless there’s a demonstrable problem. If you and he just have different casing preferences or something, the tension you create is probably going to nullify the benefits of standardization. Cosmetic coding standards and other relatively minor concerns can and should be addressed with automated static analysis. Don’t rely on seniority or status in any way. There’s no faster way to breed resentment than forcing people to do things they don’t agree with “because you say so.” Don’t expect to revolutionize someone’s entire approach in a single sitting and make the conversation a marathon affair. You want to have a clear and relatively concise message so that you get your point across without exhausting the other person. Improvement will happen over the long haul. Finally, don’t say that the code is “” That’s a useless, subjective way to categorize. Everything in software is about trade offs, so what you want to do is show Bob that he’s paying for quick and dirty coding with maintenance headaches for the rest of the team. Build A Constructive Code Strategy and Environment You’ve already prepared a bit by reading what not to do, so now it’s time to complement that with what to do. There needs to be three main components to this preparation: (1) the gaps you want to address (2) the support for your argument (3) the outcome for which you’re hoping. These three things are going to frame the discussion you intend to have. The gaps are actual, specific problems with Bob’s code. You don’t want to stroll over to Bob’s desk, pull up a chair, sit on it backwards and say, “So, Bob, you’re pretty bad at this programming thing…great talk!” You need to decide what tangible items you want to address during this discussion. What’s the most egregious source of problems? Is it the gigantic methods? The nested switch statements? The duplicate code? Pick one or maybe two of these things to cover. Just as you don’t want to be critical and vague, you also don’t want to be critical and devastatingly specific, reading off 95 of Bob’s greatest coding flaws like some kind of departmental Martin Luther. There may be 95 things wrong with Bob’s code. But if you want to fix all of them, it’s important to lay the groundwork for a mentoring relationship because you’re definitely not going to fix all of them in one day. Building Support: Do Your Research. Let’s say that you’ve decided to focus on method length as the topic to address. The next thing to do is build support for your argument. It’s a lot more credible to cite some supporting studies or widely respected industry figures on the matter than to march over to Bob and declare that his methods are too long. Build a case with evidence for the principle that you want to cover, and then also find specific, problematic instances in the code base to discuss. The last thing you want is to be hand-wavy about the problem—you want to be able to point at it and say, “for instance, this right here is a really big method.” The Outcome Should Be Actionable Having picked your issue and built a case, the last thing to do is choose an outcome toward which to steer the conversation. So you’ve shown Bob a giant method that he wrote and convinced him of the evils of giant methods. “Uh, okay,” he’ll say. “So what now?” Decide ahead of time that you want to work together to break the method into X number of smaller methods or that you want to leave the code in a state where no refactored method is longer than Y lines. Whatever it is, pick something actionable so that you and Bob can cap the conversation off with a joint win. Be courteous At this point, you’re ready to have the hard conversation. If you do it right, it won’t be nearly as hard as you might think, and it will serve as a productive starting point for a series of subsequent conversations that will be easier and perhaps even pleasant. This article originally appeared at SmartBear's Blog, written by Erik Dietrich.

Get a crash course in understanding microservices and the difficulties in implementing them.

Git offers several types of workflows. Learn what they are and which type is best suited for your specific purpose.