mike.mainguy

In the spirit of the holiday, I figured I would try my hand at writing computus in scala and java. For those who aren't aware, computus is the algorithm used to compute which day easter falls on. First, the scala version: object Computus { def main(args: Array[String]) { val start = System.currentTimeMillis() for (year 11)) || (epact_val ==24)) { epact_val + 1 } else { epact_val } } def n_whatever(year:Long):Long = { 44- correct_epact(year) } def fix_n(year:Long):Long = { val n=n_whatever(year) if (n 31) { "April " + (day_of_march -31).toString() } else { "March " + day_of_march.toString() } } } and now the java version public class JavaComputus { public static void main(String[] args) { Long start = System.currentTimeMillis(); for (long i = 2000; i 11)) || (epact_val ==24)) { return epact_val + 1; } else { return epact_val; } } ...

As I'm sure most tech geeky folks now know, Amazon EC2 had a massive outage yesterday. This affected numerous online applications and web sites totally unrelated to amazon.com. My favorite new word is currently cloudpocalypse. Many folks have decided that "cloud computing" is the next golden hammer that will solve any and all computing problems. I hate to rain on their parade (pun intended), but at least from my perspective, "cloud computing" primarily provides the ability to acquire cheap and fast computing infrastructure, have it online quickly, and scale it massively. EC2 is GREAT for that, as a matter of fact, there probably isn't anything nearly as powerful and complete on the market right now. Note that I didn't include the word "reliable" anywhere in my value proposition. Don't trust a cloud provider to be reliable, to quote Amazon's own CTO "Everything Fails all the time" . The important thing to consider w...

My short answer is: "very". My Long answer Follows: Devops is a reaction to a common problem in software development. It's referred to here as a "wall of confusion". I've blogged on this before and anybody who has ever worked in a shop with two different teams (ops vs dev) you will likely understand the problem very well. Inherently, Ops wants stability and dev wants change. I believe the recent push for "agile" in IT organizations has aggravated this problem to an extreme in some places. This aggravation has been because the focus of agile has been on the DEVELOPMENT of software, but not the OPERATION of software. To clarify how these responsibilities are typically divided: DEVELOPMENT Perspective Make new features for customers Get it done quickly Get it done cheaply Move on to next thing Don't worry too much about the future or past… Live in the NOW OPERATIONS Perspective Fix the messes created by development Prevent ...

I've been playing around with some rss feed parsing and decided to contrast the ruby way with the java way. First, the java way import com.sun.syndication.feed.synd.*; import com.sun.syndication.io.*; import java.net.URL; import java.util.List; public class RssJava { public static void main(String[] args) { long start = System.currentTimeMillis(); int total = 0; int entries = 0; try { SyndFeedInput input = new SyndFeedInput(); SyndFeed synFeed = input.build(new XmlReader(new URL("http://mikemainguy.blogspot.com/feeds/posts/default"))); for (SyndEntry entry : (List ) synFeed.getEntries()) { entries++; List contents = entry.getContents(); for (SyndContent content : contents) { total += content.getValue().split(" ").length; } } } catch (Exception e) { e.printStackTrace(); ...

Two phrases really are irksome to me: "If it's stupid, but it works, it ain't stupid" and "If it ain't broke, don't fix it" They bother me not because I disagree with the intent, I wholeheartedly understand and agree with the sentiment. My problem is that they are often used to justify cutting corners and generally producing inferior products in order to avoid fixing problems that customers might not detect. First off, I'm not foolish, I understand nothing is perfect. I understand that software will have bugs, cars will have problems, and sometimes judicious use of duct tape is the best solution. BUT When you don't acknowledge "quick fixes" as such, this inevitably lowers what people think the baseline level of quality should be. In my experience this has a cumulative effect of causing the next "quick fix" to be of even lower quality because it's just a "little worse" than the previous stupid sol...

As software developers, a common problem we face is trying to estimate how long it might take to build some idea still locked in a customer's head. Many legacy, high ceremony processes try to use highly precise measurement systems (man-hours etc) to measure this. A problem with this approach is that they very often fail or give deceptive results because of their inability to account for a confidence factor and changing events. Put another way, these methods are precise, but inaccurate. Many agile frameworks attempt to fix this by decoupling the estimation process from reality. They do things like use "points" or "high medium low" and then use historical data to adjust velocities based on actual performance. This approach has the advantage of acknowledging uncertainty and the inherent inaccuracy estimation often contains, it has a major flaw in that advance resource planning and scheduling can become a nightmare. My approach is to blend of both these appro...