If we choose conformance to actuals as the definition for the “rightness” or “goodness” of an estimate, we’re certainly encouraging overestimation. It’s easier to overestimate and then waste effort as needed to be “accurate” than to underestimate and try to hit a possibly impossible target. Those who ask for estimates using this definition know this, so they are likely to arbitrarily cut the estimate in order to put pressure on development and prevent padding.
Successful, long-lasting movement have a clear manifesto outlining goals and principles. Many DevOps adopters may not be aware of the DevOps Manifesto (created by Jez Humble @jezhumble) nor how successful DevOps requires keeping a clear focus on principles, practices, and value (instead of infrastructure tooling).
Why shouldn’t you test private methods? Because the fact you’re asking the question means the method shouldn’t be private – it’s a piece of independent behaviour that warrants testing. The hard choice, the design decision, is where you stick it.
Let’s face it; not everyone has been there and done that, when it has come to Distributed Development. And if you have, there is a high probability that you were probably in a distributed team, you mostly worked with one group or the other, but not both. These words I will probably keep repeating in the future, but I’m not apologising for them: Never be Complacent.
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Matt Butcher, Lead Cloud Engineer at Revolv, Inc, author, and teacher at Loyola University Chicago.
This week in the link roundup: Intel joins the smartwatch arms race with a $100M purchase, Facebook looks to go into low-orbit, Flexcoin shuts its doors, PHP gets a renaissance, a programmer finally admits his limitations, we learn that God created the universe on Rails, and Jurassic Park comes to your browser.
A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.” That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.
The code snippet is rather straightforward, iterating over a loop and generating classes at the runtime. When facing an Error, the code above is well prepared to catch it and print out the stacktrace. Apparently, the situation is a bit more complex than this - half an hour later I found myself still staring at a somewhat different error message. I
Many organizations require a secure infrastructure. I’ve yet to meet a customer that says that security isn’t a concern. But, the decision on “how secure?” should be closely associated with a risk analysis for your organization.
It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not.
Applying Agile methods to an organization on an enterprise level can be difficult. In order to ensure product quality, minimal time-to-market and increased value, avoid these mistakes when embarking on this transformation.
It's a well known deficiency of most existing sampling Java profilers that their collection of stack traces has to happen at a safe point. A while back Jeremy Manson open sourced some proof of concept code where calls are made to the AsyncGetCallTrace JVMPI method which avoids the need for threads to reach a safe point in order to read their call trace. I've taken this code dump and started converting it into a usable open source project.
Sometimes you want to set the state of your project back to a previous commit, but keep the history of all the preceding changes. You want to make a commit that reverses all the changes between your previous commit and the current HEAD.
In particular, we current have over three thousands tests, and they take hours to run. We are doing a lot of stuff there “let us insert million docs, write a map/reduce index, query on that, then do a mass update, see what happens”, etc.