mike.mainguy

There are two widely known laws in parallel computing that are counterpoints to each other, but with thought they can be applied together to achieve dramatic improvements in parallel computing. They two laws are Amdahl's Law and Gustafson's Law . Roughly speaking, Amdahl's says you cannot speed a system up by parallelization to be faster than the the slowest portion. Using a simple metaphor, if you have a car, a bicycle, and a turtle, when traveling in a pack, you can only move as fast as the turtle. The counterpoint to this is Gustafson's law, which roughly states that for parallel problems, adding more resources can increase the net work completed. Using are above metaphor, if we add more turtles (or cars or bicyclists) we are still increase the amount distance travelled per unit time. I do apologize to Computer Scientists as this is a very rough approximation, but this way of thinking about the situation can help us understand how to use some trickery and sl...

P rior to writing code, I will search the internet, I will ask intelligent questions, and I will realize that many of the answers I get may not be correct. I will test the answers and validate them before repeating it to someone else. I will not reinvent prior art without adding value R evision control tools are my staple, I will live and die by version control tools. Distributed, Centralized, Lock and Release, or Update and Commit...they all work and they are the foundation upon which I build everything. I will strive to learn how to use these tools to manage branches, tags, and how to properly share my code with my fellow programmers which whichever tool my team happens to use O n all fronts I will respect the code that already exists and seek to understand why it is the way it is G iving credit when due, I will respect my peers, those who are less skilled, and those who are more skilled. I will not assume I'm smarter than everyone else, nor will I assume that esoteric a...

Often we are hampered because we think of a "simple solution" and it ends up being "simple to think about" but very complicated in practice. Something as simple as "Dig up the rock poking out of the front yard" seems really simple. All you need is a shovel and some ambition right? ...until you realize the rock is a 5 ton monster that, in fact, the utility company drilled a hole through to route your gas line. Sometimes, as in this case, it might be better to do the more "complicated solution" i.e. go to the store, get some dirt, and cover the rock up, and plant new grass... because the "first/simplest" thing you thought about has some unknown complexities. Put another way..."simple to think about" doesn't equate to "simple to execute".

I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...

I recently had a need to install varnish on Centos. While it's very simple, a key step missing from the official instructions is to install the epel-release . Not sure why yum can resolve the dependency on Centos, but the following steps worked for me: sudo yum install epel-release sudo rpm --nosignature -i https://repo.varnish-cache.org/redhat/varnish-4.0.el6.rpm sudo yum install varnish

Working in the field for a while, I find that new folks in the field have a problem with refactoring. I think the primary problems are: Code without tests is dangerous and frankly scary to refactor It's really easy to copy/paste code, and if you don't have to support and bug fix things, the merits of clean and concise code are lost While I don't claim to fix anything, here's a quick guide on how/why to refactor (for complete newbies):

Don't take it personally is an oft repeated platitude I hear repeated in the work environment. While I think it's unhealthy to take problems at work and things out of your control as personal affronts, I think a healthy dose of taking personal ownership of your work is "a good thing" (tm). I say this because the counterpoint to not taking things personally is not giving a damn and I think this is a far worse situation than folks who are personally invested and passionate about their work. In my experience, the most successful folks I've interacted with take a very deep personal interest in their life's work. They are passionate, appropriately loyal, and care a great deal about the quality of the product or service they provide. Folks that punch the clock, point fingers, and skip home after their "8 (or so) hours of physical presence" are huge problem and all too often a key source of low quality work and cumbersome process. More dangerously...