Posts

Showing posts from April, 2011

Computus in scala and java

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 <- 2000.until(1000000)) { println(pretty_computus(year)) } println(System.currentTimeMillis()-start) } def golden(year:Long):Long = { year % 19 + 1 } def century(year:Long):Long = { (year / 100) +1 } def solar(year:Long):Long = { (3 * (century(year) /4) ) -12 } def lunar(year:Long):Long = { ((8 * century(year) +5) / 25) - 5 } def letter(year:Long):Long = { 5 * year / 4 - solar(year) - 10 } def epact(year:Long):Long = { (11 * golden(year) + 20 +lunar(year) - solar(year)) %30 } def correct_9006(year:Long):Long = { val epact_val = epact(year) if (epact_val < 0)

Amazon EC2 Collapse and designing for cloud computing

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

How important is the devops movement

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

Parsing RSS in java and Jruby

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();

If it's stupid but it works, it's still stupid, it just also happens to work

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

Simple software estimation guidelines

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