I was working with Web API for one of my new projects, when suddenly I got this error message: "the server responded with a status of 405 (method not allowed)" when I tried to delete a record through API. I began to scratch my head, and finally, I came up with a solution.

Many departments with "agile" operations are full of whiteboards-turned progress updates. Here's a look at the concept of "information radiators."

Taking the SCIPAB approach for starting conversations and presentations for agile use cases.

A sample "team manifesto" to help craft your company culture in the direction you want it to go in.

Learn various performance considerations when building your own analytics systems

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.

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.

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.

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.

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

From time to time I’ve been heard to say: “Agile is Punk.” But I’ve never explained myself. I’ve also been heard to say things life “Agile is about democratising the workplace” but I’ve never explain myself there either. Let me try… What I mean when I say this is: Agile (software development) has a lot in common with Punk rock. To me the important thing about punk rock was that it was about people trying it - music, their own thing. Anybody trying to play music, anybody forming a band, anyone who had a novel idea trying to get a record contract. Yes, even if they couldn’t play an instrument they could have a go, and who knows, maybe they would learn as they went. (I should say that while I’m old enough to have been around when punk was I’m not old enough to have been there. Both post-punk and post-disco influences were at work in the New Wave music which was common when I came music listening.) Punk had a democratising effect on music. Music has aways been of the people, anyone can listen, anyone can try to sing - although I’m not very good at it even I can try! But the music industry was something different, performing, recording - there were barriers there! Punk tore down barriers. Punk opened up the recording industry. Punk opened up music. Agile opened up the software process industry. Before Agile official software processes were pretty locked down. You had to be an academic or expert/consultant to dabble in that space. Programmers who worked in under official software processes were on the receiving end. Agile said: “Your opinion is important too.” In truth music has always was been open to everyone, just not the recording industry. And in software development processes were open to anyone, most programmers did not work under an official process, mostly it was common practices which, if they worked, were probably more effective than official ones. Unfortunately these unofficial work practices came with guilt: because we did not do it the way the books said we should. When faults occurred we blame ourselves for “not doing it properly”. Agile says: “Everyone involved with software development should have a voice in deciding how to work, it can be improved and you don’t need to be an expert, academic, consultant or certified member of some body to express that view.” That also makes it democratic. I don’t mean democratic in the sense that we all get to vote, I mean democratic in the sense that it is power is vested in the hands of the collective people. Everyone has a voice, everyone can participate, and those who hold executive power do so by the will of the people. Agile is about giving everyone a voice. Like Punk that means accept that those who don’t have much skill are also entitled to a voice. Funnily enough, I’ve long held that any punk band that made a second album weren’t punk anymore because they were part of the industry, they were now experts! The same is true with Agile, hang around for long enough (like me) and you are no longer an outside but an insider, an expert. Increasingly we see Agile heading outside of software development. When this happens it becomes necessary to ask: What is Agile? My answer is: Democracy. Agile is about valuing everyone, agile is about giving everyone a voice, agile is about putting the power to change the workplace (process, systems, norms) into the collective hands of the people who work there. Yes at times it feels revolutionary, but there are fellow travellers, it is all a Theory-Y movement.

Written by Jim Magers for LeadingAgile. When I’m teaching an agile bootcamp class and talking about work in process, I always make a point (usually multiple times) to tell the attendees that agile is about finishing work…not about starting work. I reinforce this by pointing out that you can have a glorious looking burndown chart for the duration of the sprint but completely fail in your mission to meet your commitments and finish stories. The team can be burning down hours beautifully on a daily basis, with the remaining task hours looking like they are tracking right along the ideal line, and then boom… It’s closing time for the sprint and no stories actually got completed. Remember that notion of building working, tested software? Didn’t happen. The team started too many stories at once and ended up not being able to bring any of them across the finish line when the bell rang. This notion of finishing work applies to sprint planning as well. If you short-change the time it takes to do good sprint planning, and the team meanders off to begin writing code and test plans too soon, there is a risk that the team is going to struggle to be successful. Remember what we do in sprint planning. Consider velocity, and load the sprint backlog with high priority stories from the product backlog. Check. Determine capacity for the team to work on sprint tasks over the coming sprint. Check. Break stories into tasks and determine who is doing what. Check. Make sure the work is going to fit. Check. Commit to the work. Check. But what can happen when you don’t take the time to thoughtfully break down tasks and estimate hours of effort? Consider the following burn down chart. In this example, the team left sprint planning thinking that they were committing to 830 hours. But just two days into the sprint they discovered additional task hours and instead found themselves in the awkward position of actually needing almost 1200 hours of capacity to complete the committed stories. Guess what…they did not have 1200 hours of capacity to give, especially since they were now a full two days into the work. In looking more closely at their burndown chart over the course of the two-week sprint, it took them almost 6 days of work to get back to the point where they had 830 hours of work left to do. Six days just to get back to where they thought was their starting point when they concluded their sprint planning meeting. And surprise, they didn’t finish the sprint successfully. So, don’t short-change the value that good sprint planning affords. Yes, it takes time. Yes, it can seem tedious. Yes, the team is anxious to get started. But good sprint planning pays dividends. Remember that it is about finishing work, and not about starting work.