mike.mainguy

The MACH Alliance is a consortium of ISVs and SIs that advocate for a particular approach when building/integrating modern platforms. One gap/misunderstanding I keep bumping into is the intent behind MACH. In general, it's a technosophical approach to how PLATFORMS are build, run, deployed, marketed, not really well suited for large organizations who are simply trying to USE these platforms. Therefor I propose a "MACH TEN" Addendum TEN is an acronym that adds some context to adopting MACH platforms to use in your organization. These are high level recommendations I enccourage folks to take into consideration before jumping under the bandwagon. :p Transparent Pricing and contracts are computable, if special terms are negotiated, that's OK, but I shouldn't have to tell you my budget before you tell me how much you cost How I integrate/use your platform is easy to find, I don't need special training, I can just RTFM and begin using your system ...

An anti-pattern is a commonly recurring software design pattern that is ineffective or counterproductive. One architectural anti-pattern I've seen a number of times is something I'll call the "Through the Looking Glass" pattern. It's named so because APIs and internal representations are often reflected and defined by their consumers. The core of this pattern is that the software components are split in a manner that couples multiple components in an inappropriate manner. An example is software that is split between a "front end" and a "back end", but they both use the same interfaces and/or value objects to do their work. This causes a situation where almost every back end change requires a front-end change and visa versa. As particularly painful examples, think of using GWT (in general) or trying to use SOAP APIs through javascript. There are a number of other ways this pattern can show up... most often it can be a team structure...

I have a couple of quick notes for any aspiring java architects. Please read them carefully and think about them. Adding layers is BAD In general, you don't need extra layers until you need them. At that point, add a new layer (but only in necessary places). Create "standard" layers just adds complexity, makes maintenance more expensive, and ultimately fosters copy/paste coding and discourages developers from thinking about what they're doing. An example of a good time to add a layer is when you need to hide complicated operations behind a facade because low level database transaction management is being done in the same place as the code that determines which screen should be displayed next. Too many developers heard "layers add flexibility/scaleability/whatever" and started adding layers to every situation that has an arbitrary division of responsibility... I've worked on systems where adding a table column to be displayed in a CRUD applicatio...

I've written in the past about change control processes and how they relate to agility. Taking things to the next level, there's a bigger issue that needs to be addressed. There are essentially two radically divided camps on what value IT Governance provides for enterprise software. These camps are: #1 the business camp which is tired of hearing excuses about why they are losing millions of dollars of business because IT cannot deliver a solution in a timely manner and #2 The IT camp that is tired of the business camp requesting crazy stuff and causing millions of dollars of unnecessary support costs. Camp #1 thinks governance is an excuse for IT/process wonks to slow things down or foot drag instead of delivering solutions. Camp #2 thinks governance is a way to reign in the business folks who believe that unicorns and pixie dust cause fully configured computers and network infrastructure to magically appear over night. I hope its obvious that both camps are spectacula...

An anti-pattern is a commonly occurring pattern that is ineffective. There is an architectural anti-pattern I like to call "Through the Looking Glass". This is when a system is broken into pieces or layers, but the pieces are cut perpendicular to the direction that the team and the business require. A common example is when a set of screens used to access a database system is split system into "front end" and "back end" components. This "front end" and "back end" split ONLY makes sense if the back end can identify thier required interfaces before the front end is designed. If the "back end" requirements are being driven by the "front end" screens and/or systems, then this split is either #1 wrong or, at a minimum #2 premature. Most often, new systems need a front end to identify APIs that need to be used... it's more economical to build the system in such a ma...

Technology decisions are difficult and it often seems that architects and developers resort to throwing darts to determin which solution they should use for many problems. A tool I like to use to help figure out the best solution is a simplified decision matrix . When used fairly, this simple tool enables us to quickly and visually determine which solution is best given our success measures. As an example, lets pretend we're going to pick a server platform. In this, effort, we have some specific things we care about: security updates - Does the solution have automatic and timely notification of security issues and an automated way to patch the server. modern versions of applications supported - as a criteria, which version of ngnix does the package support In the interest of simplicity, we're going to assume that other essential factors such as cost, compatibility with specific software and other issues have already been applied. We then take this information, select ...

I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...

Among many software architects and pundits, Message Queue solutions have a lot of press about being a highly scaleable solution in comparison with RPC based solutions. From what I can see, the biggest problem with most comparisons is that they start with the premise that one or the other of these two approaches is superior and then spend time trying to make a compelling argument why they are correct. I'm going to throw my hat in the ring on this issue and offer a high level guide for folks who don't have the time or energy to dig into queuing theory or debate with ivory tower architects about the issue. You'll note that scaleability is not even a factor. This is deliberate as scaleable and performant solutions can be built using either pattern. There is an interesting performance comparison that seems to indicate that the performance characteristics are very similar for both approaches. I WILL point out that simple http-based RPC solutions DO have fewer middleware re...

I read with interest an article about the mentality behind nosql nosql-vs-rdbms-let-the-flames-begin.html . From my perspective, this debate isn't really a debate and I've written about similar things before. If you stop for a moment and think, it seems obvious that giving up a relational model and giving up ACID compliance reduces overhead. It should also be obvious that you are giving up things that many people for many years have thought are really important. To a person selecting an underlying database implementation, part of your decision making process needs to take these things into account. Here's a quick list of things to consider: How important is speed? (how long can we wait for one operation to finish) How important is scaleability? (how many operations must we be able to do at one time) How much money can I spend? (Can I spend a $200,000 on a honking server?) Who is going to support this system? (A bunch of developers, a bunch of dbas, or both?) How big...

I heard this statement today and it stopped me in my tracks... It came from a developer who was trying to explain to me why it was a good thing to embed our job postings as static files in our main corporate website. "After all, it only takes 15 minutes to get the new files and deploy the new version of the application" he continued. "After all, how often will they change?" I had to resist the urge to say "sooner than you might think"... At that point I should have realized that perhaps this guy was unreachable . I say that because when I attempted to explain my position he just waved me off and immediately stopped listening and started doodling on his notepad. Upon reflection, a number of problems were evident: I have done a really bad job explaining the value of using reusable components or what a "service" is I have done bad job of explaining why decoupling the content of an application from the code is a good thing I have forgotten that I ...

I supposed the title of my previous post was a little bit misleading. The original (OK version 2) of that code actually didn't cache anything, but just acted as a reverse proxy to resize images. I added some code to perform some rudimentary caching. You can now add cache=1d to have the browser cache the image on the local disk for 1 day. Similarly there are other combinations:. To cache for 1 week add: cache=1w To cache for 2 hours: cache=2h What this means is that after the browser initially loads the image it will hold it on disk and not request it again for the amount of time that was specified. This doesn't apply if the user hits "reload", but works great for normal navigation. Warning This means users won't see a new copy of the image unless they explicitly hit "reload". You may need to use unique urls for changes to images once you start do this. example (cache for 42days and resize to 256x256: <img src="http://mediacache.appspot.com/...

Ever needed resized images on your site but didn't really want to run batch resize operation? Did you try setting the css settings to resize the image, but realize you where totally hosing your low bandwith users (or generally killing your user experience to begin with). In response to these problems (and the general expense of tools like scene7) I began building a google app engine cloud computing service that will do this and ultimate enable caching. It is essentially an intelligent reverse proxy that will enable image transformation and caching via google app engine. As an example, suppose you want to see the following image on your page But you want it resized to 150px wide One way (the css way) would be to apply style="width:150px" and you would get the following: <img style="width:150px" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDJu46SDigVQUkrf_LtMuFWkm935LJ4SuqHIhwKwtLPy_Z4n5Ey-v_bdRTK7N83LoAlevsAtHAjopQcTt1gSjazArRm2_lK4li...