About
The official blog of Team Mach-II and is the best place to stay up to date on all things Mach-II.
Categories
This Week in Mach-II: Loggers and Modules
Yet another week of great blog post posts from our wonderfully smart and talented community. I believe I owe Mike a round of bourbon after he gets done with the custom logger series and Brian gets something - I don't know what he drinks.
Building a Custom Logger Series
New Team Mach-II memember, Mike Rogers, has started an in-depth series of blog posts on building an IRC logger using Mach-II's logging package. Mike, I raise a tumbler to you.
Mach-II Deployment with Apache Ant
Mike Rogers on a roll and talks about Mach-II and deployement with ANT.
Using CKEditor with Mach-II and JQuery
Yet another Mike Rogers post where he discusses using the Mach-II form library, CKEditor and JQuery.
Mach-II and Module Config Files
Brian Klaas's second post in a series on his thoughts and methodology of building Mach-II modules.
Posted 11/18/09 @ 7:39 AM by Peter J. Farrell
Open Source: Is Build It Bigger Faster a Sound Long Term Design Plan?
Recently, I was discussing the state of economics with my brother. He is really into history and economics (having a degree in it) and offered an interesting opinion on regarding the run down state of several metropolitan cities in the US. Recent research suggests that the present of graffiti, broken windows and litter increses the pretty crime in the area. If you are intested, below is a link to an article about this theory (a link to the full article at Science magazine is not available):
http://www.newscientist.com/article/dn16096-graffiti-and-litter-lead-to-more-street-crime.html
It's called the "broken window" theory and whether you believe it or not is the crux of this blog post. The most interesting problem is that when the "broken window" events occur in the US that the more well to do (think wealthy) leave the area and leave the problems behind instead of participating to fix them. The US itself has a small or rather large (ironic) problem of having a large amount of undeveloped land that allow for urban sprawl. Countries such as Japan do not have the area in which to continually push urban environments out. This encourages people to participate and fix problems instead of leaving the area so they can be ignored. I've sort of dubbed this the "build it bigger faster" theory since you can just build bigger without addressing the shortcomings of your archtictural plan. Notice that it is not the "build it better" theory.
Great "Mach-II and ColdSpring for N00bs" Article by Ollie Jones
Ollie Jones has written up a great post on his blog entitled "Mach-II and ColdSpring for N00bs." It's excellent information, very thorough, and very well presented. He even includes a zip file of his basic setup that you can download.
Thanks Ollie! I'm sure this will be extremely useful to a ton of people starting to learn Mach-II and ColdSpring.
Removing Event-Handlers Programmatically
In a recent application of mine, I have a large collection of test event-handlers that we use to test certain application functionality (such as javascript). While very useful for us when developing the application, we do not want to deploy these event-handlers when the application is deployed to our production environment. So what are the options?
- Manually comment out the event-handlers when deploying (very messy, error prone, possible security concern if forgotten)
- Programmatically remove the event-handlers when the application is deployed to a production environment (best solution because a computer does it for us)
I thought it would nice to share this code with other Mach-II users so I wrote up a short wiki entry that demonstrates how we did it. It even includes a working sample code that you can use and shows off some nifty new features in Mach-II Simplicity (1.8), so read Removing Event-Handlers for Security Purposes wiki entry now. You never know when you'll need this bit of code.
Posted 8/11/09 @ 3:50 PM by Peter J. Farrell
Philosophy: Our decisions on what CFML engines we support
At cf.Objective() 2009 just a few weeks ago, I was asked why does Mach-II 1.6 support ColdFusion MX 7 since CF9 is so close. I was kind of perplexed by the question to be honest, but without knowing some history it does seem like a strange decision. So why does Mach-II 1.6.1 (the latest stable as of May 2009) which is the maintenance release for 1.6.0 support ColdFusion MX 7? The answer is a simple one. Planning for the 1.6 release cycle started in the December of 2007 and during our development cycle Adobe had barely released ColdFusion 8 (which was released on July 30, 2007).
We want to support everybody as far back as possible, but our normal rule of thumb is to support back two versions (or as far back as Adobe provides official support for in the case of ColdFusion). However, our development cycle does not match up with the release cycle of the big three CFML engines and therefore our rule is not a hard and fast rule. For instance, Mach-II 1.8 will still support ColdFusion MX 7.
I know people will say why not just drop support for 7? There are few points about that:
- While ColdFusion 9 is coming, it's not here yet and not everybody will be able to upgrade immediately (economy / money). Plus, there are many people still on MX 7.
- One of Mach-II biggest tenants since the inception of the project is backwards compatibility (BC) and we want people to use the framework as much as possible as long as they have a relatively recent version of a CFML engine.
- Not all CFML engines support all features. This is actually something that most developers do not have to worry about because they write their applications to be deployed one favor of a CFML engine. Most developers just use one engine or another for developing their applications and don't really care about compatibility.
- You cannot use this sexy new feature in the language. What features in ColdFusion 8 does the framework itself need to leverage to new "cool" stuff that are not available in MX 7?
The last point is interesting one to make, because when use this as a rebuttle most people say stuff like:
- You can't use onMissingMethod()
- ColdFusion 8 is faster than MX 7
- ColdFusion 8 has threading
Ok, good reasons for the needs of your application, but name a place in the Mach-II framework core that we need onMissingMethod()? Maybe your application needs it, but Mach-II's features do not need it. That point is more about your application's functionality. The framework itself isn't missing stuff to "innovate" on.
Yes, ColdFusion 8 is faster, but that again is a need of your application. Internal speedy for the sake of the framework core does not impact what features we can offer; it affects the application you might built on top of it.
The last point in regards to threading you might have gotten me a bit and yes, there a few place where threading would be nice in the framework, but it's not required. In the end, we wrote a things called the thread adapter which allows us to run code in certain places threaded, but downgrades to serial processing if the engine doesn't support it. Since it's all automatic, it's nothing you have to worry about -- you either have the ability granted to you application, but gracefully downgrades if you don't. You can read about how to use the threading adapter on our wiki if you are curious.
The main point is that the framework core code itself is not suffering from the lack of onMissingMethod, interfaces or anything other new features that CF8 or Railo or Open BD offers. Actually, the framework core code itself is doing rather mundane things like shuffling data around mostly so you can develop your applications faster and do the fun stuff instead of pushing the form or url scopes about. All the sexy stuff that your application does is stuff you write.
Lasly, Team Mach-II wants to support all the major CFML engines - ColdFusion, Railo and OpenBD (official support for Railo is coming soon). Why would we want to do this? Because we're cross CFML engine compatibility sadomasochists...not! Because Mach-II should be able to run anywhere. It should not be reason why you cannot not use Mach-II for you new application -- because you use an engine that we don't support. If you have major CFML engine with a relatively recent version, we should support Mach-II on it. Plus, you would not believe the amount of emails I receive about LylaCaptcha asking me if I support ColdFusion 5 and if I have any plans to support it (Lyla itself is a CFC that uses Java, none of which CF5 supports -- so it is a no go anyways). So it goes to show you that there is wide variety of users using older versions.
Call us a stick in the mud for supporting the framework on "old" CFML engine versions. I call it being pragmatic -- at the moment there isn't anything that one CFML engine offers in the terms of features that we absolutely need to implement sexy new feature K or Y yet. Only good reasons are a compelling way to make good decisions otherwise it's just a decision for the sake of making a decision.
Mach-II: History, Philosophy, and Community
Since there's been a bit of a stir about the state of CFML frameworks recently, and having been in the middle of this sort of thing four years ago (was it that long?) with Mach-II, it seemed an appropriate time to share some thoughts that have been fermenting in my head as well as in discussions on the Mach-II team for quite a while. Specifically I'd like to share with everyone some of the philosophy underlying the Mach-II project, our development process, why we do things the way we do, and ultimately why we do what we do.
First, however, a note about open source.
Hey, Hey, My, My: Open Source Can Never Die
First and foremost, once something is made open source it can never die. It's out there and if it's truly open source, you can do whatever you want with the code, in perpetuity. But when the discussion of frameworks comes up, almost without fail several people involved with the discussion make a statement along the lines of, "But what if I build my applications on Framework X and Framework X goes away? WHAT THEN?"
Frankly I just don't understand this sentiment. I always wonder if the person making the statement thinks that every application running on a particular framework that exists in the world is tied into a powergrid controlled by a large switch, and if the framework authors decide to not continue development on the framework, they can flip this big switch and cause all Framework X applications to break.
Of course it sounds silly when I put it that way, but it highlights the important fact that you aren't betting the farm, or your career, or anything else when you choose a framework. You're picking a tool for a particular job, and as I said above, that tool never goes away. It may change over time but the open source framework you're using, in that version and on that project, will run that project until you choose to do something different with it.
Even if you standardize on a specific framework (which I highly encourage people to do), if you architect your applications well, changing frameworks is not the massive upheaval people probably think it is. Chris Scott, Adam Lehman, and I built LitePost a few years ago to make the point that the same business logic (and in some cases views) can be used regardless of the MVC framework you choose. And again, you only have to worry about this if you choose to change frameworks.
To make my previous point in a slightly different way, even if a framework goes away your existing applications may never need to be touched. Frameworks have many benefits, but hassle-free maintenance is arguably the biggest one. If an application runs fine on an old version of a framework and you don't have any reason to upgrade, then don't! At least you have the benefit of knowing that when something does need to be changed it was built in a standard way that anyone knowing the framework can decipher immediately. This is a lot more than can be said for applications that were written using no framework at all out of fear of what might happen to the framework in the future.
In short, whatever framework you choose, if it works for you for the application you're writing in the here and now, then no fear of what might happen in the future should deter you from choosing to use a tool that, much like framework discussions in the CFML community, can never die.
With that out of the way, let's get a bit of a Mach-II history lesson and peer into the future to see where Mach-II is going.
Mach-II History
Mach-II was first introduced in 2003 by Ben Edwards and Hal Helms. It was originally planned to be a new branch of Fusebox that would take advantage of CFCs, and was even originally named Fusebox MX. Ben and Hal quickly realized, however, that Mach-II was something altogether different from Fusebox and it needed a new name to reflect that fact. (If you're interested in seeing what Ben Edwards had to say about Mach-II in its early days, here's a nice interview that Fusion Authority did with Ben in 2003. For even more Mach-II history, check the history page on our wiki or our "10 Questions About Mach-II" blog post.)
A lot has changed in the six years since Mach-II was released. Most visibly the personnel has changed. Ben and Hal built an absolutely fantastic, clean, rock-solid foundation that Peter, Kurt, and I have been able to run with since Ben and Hal graciously handed the project over to us in July of 2007. Since Peter and I were heavily involved with Mach-II for two years prior to that (ever since Peter's Is Mach-II Dead... post in June 2005), we felt humbled yet confident being put in charge of the new phase in the long life of Mach-II.
So Mach-II has been around for six years, and we're still in the 1.x version number range. What's up with that? We discuss version numbers with every release, but as a general statement we decided early on to avoid "version number inflation," meaning every time we put a couple of new things into Mach-II we don't increment the primary version number. This also reflects our history quite well. We are still building on the great foundation of the 1.0 (and pre-1.0) release, and the true sign that it is such a great foundation is reflected in the fact that we can continue to cleanly add new features big and small to Mach-II without having to undertake any ground-up re-writes.
In recent versions of Mach-II we've introduced some big marquee features--things like modules, caching, logging, the dashboard, and others--but the fundamentals of Mach-II have remained relatively unchanged over its now-long history. This is good for us as the stewards of Mach-II, because in our opinion radical and rapid change to frameworks that people depend upon in their daily development work isn't wise. More importantly it's good for our users, who can rely on the sound foundation of Mach-II as they explore the new features we add with each new release.
As we approach a 2.0 release of Mach-II, we can look back and see that yes, a lot has changed in six years. We can also look forward to a 2.0 release and say with confidence that the best is yet to come.
Mach-II Philosophy
Mach-II's source code has been available since it was first released, but in my opinion the project has only really become a true open source project in the last three years. By that I mean that having source code available for an application does not magically make it an open source project in a philosophical sense.
The philosophy of everyone involved with the development of Mach-II is that open source projects need to be open in every way. That's the only way open source works well, that's the only way everyone can participate effectively, and that's the only way the project can flourish. Participation by the users and community around the project at every phase is vital to the success of an open source project, so if a project is defined by closed-door development, long periods of silence, and "big bang" style announcements, to us that flies in the face of the spirit of open source.
This is why we (seemingly foolishly to some) announce ideas for features when they're little more than notions in our heads. This is why once our ideas germinate we document them and make them publicly available through our Specification and Feedback Process (M2SFP), which to us is the most vital phase of development. This is why we have nightly builds and encourage people to put the code through its paces early and often. This is why we have a publicly editable wiki, a public bug tracker, a public mailing list ... I hate to use this word since it's become so overused as the prototypical corporate buzzword, but it really is all about synergy between Team Mach-II and our wonderful, whip-smart, sometimes gracious sometimes cantankerous users. ;-)
We develop Mach-II for you, but without your constant feedback, Mach-II would not be a success. We want to build what you need, and the only way we can do that is by letting you become a vital part of the process. We depend on this, and for everyone who has contributed to Mach-II in even a seemingly very small way over the past six years, know that it is greatly appreciated, it did have an impact, and it has absolutely made a difference in what we do and how we do it.
Mach-II: We're Community Driven!
In short, open source is much more about community than about the source code. "Community driven" isn't a catch-phrase on our t-shirts. Well, actually it is, but it's not just a catch-phrase on our t-shirts: it's how we do what we do, and why we do what we do.
Community doesn't happen overnight, and this is why we're so excited about the future of Mach-II. There's been a big upswing in participation from our community in recent months, and we want to encourage more and more of that. Give just a little and you'll have a huge impact, as many already have and many more do every day.
So how can you help us help our community? Get involved! You can ...
- Request a new feature. We can't possibly think of everything people would like to see in Mach-II. We may say no at first. Convince us. ;-)
- Tell us about a bug, no matter how obscure.
- Don't fear the wiki! Fix a typo, improve some wording, or contribute entire FAQs or articles.
- Share code samples or sample applications.
- Present on Mach-II at conferences or to your local user groups.
- Help a co-worker or fellow developer learn Mach-II.
At the risk of overstating things, without an active community, open source projects die, which again is why we try our best to think "community" with everything we do. If you see ways in which we could improve on this, or anything else we do, we absolutely want to know!
I'll close with yet another thanks to our wonderful community of users--strike that--contributors. Simply by using Mach-II you're contributing to the continued success of the project, and for that we can't thank you enough.
Onward and upward to Mach-II 2.0!
10 Questions About Mach-II
This was originally slated to run as an article in SitePoint but since it's been delayed indefinitely, we're posting it here. Enjoy!
1. Give your elevator pitch: summarize the essence of Mach-II in a sentence or two.
Mach-II is an event-driven, object-oriented, implicit invocation, MVC framework for CFML that is focused on handling the basic plumbing of CFML applications.
Buzzword overload? Let's try something simpler: Mach-II is designed to give CFML developers a high-performance, extensible, proven framework they can use build highly flexible, highly maintainable applications.
2. Let's dig a little deeper: tell us more about the main features.
The main feature and characteristic of Mach-II is that it's an object-oriented (OO), event-driven framework. The event object is at the core of everything that happens in a Mach-II application. This makes things very handy for developers because all URL and form variables involved with any request automatically get put into a single event object, and data can also be put into the event object programmatically. The net result of this is that developers never have to worry about the scope in which their data will exist, because all data for the request is always going to be contained in this single event object.
One thing that sets a Mach-II application apart from procedural CFML applications is that all actions in a Mach-II application are event announcements, so there is no concept in a Mach-II application of linking to a specific CFML file. The big advantage here is flexibility. Events are announced, either in the URL or programmatically, and this subsequently kicks off a series of developer-defined actions for that event, such as data processing or gathering data and displaying it to the user.
As events are announced in the application, the developer has total control over what occurs during the course of the processing of that event, and the details of what occurs during the event are defined in XML configuration files. This gives developers a great deal of flexibility in the handling of events. The benefit of this approach is if something about the event handling needs to change, Mach-II is highly flexible and allows for what we like to call "low impact maintenance." What this means is that developers can make changes, even relatively major ones such as the flow of an event, without negatively impacting the application as a whole.
Mach-II also has several extensibility features that allow developers to layer additional functionality in their applications in a highly modular way. Filters and plugins, for example, have been in Mach-II since the first version of the framework, and more recently we've added modules, subroutines, and XML includes for even greater extensibility.
Filters can be applied on a per-event basis and allow for an event to be short-circuited based on the runtime state of variables. One use of a filter might be to determine whether or not a particular user can view a particular record in a database. This user might have access to view some data but not other data that is accessed via a common event announcement, but by applying a filter to this event, the user's ID could be checked to see if the user can view the record they are trying to view. If they can't, the event processing can be stopped for particular records, while it would be allowed to continue for records to which the user does have access. Because this logic is implemented in a filter, the filter can be layered on top of an event without having these security and flow concerns infiltrating the business logic.
Plugins are similar to filters in that they offer a way to layer functionality on top of events, but unlike filters, plugins are automatically executed on every event as opposed to being applied to specific events. Plugins are great for things like security, because a plugin can be added to an application that would stop users who are not logged in from accessing any events other than a login screen. This is a great way to apply security to an entire application in one place, which means security can easily be adjusted for the entire application. Plugins also offer access to specific execution points during the course of an event, so developers have extremely granular access to be able to execute code and any point during the course of the event.
Modules are a new extensibility feature of Mach-II and allow for entire sections of applications to be built independently of one another, yet all still be part of the same parent application. This is a great way to build large-scale applications because independent teams can work on separate sections of the application such as accounting, reporting, authentication, etc. and not have to worry about things like conflicting event names. This is also a great way to scale the size of Mach-II applications because new modules can easily be added to existing applications without disturbing existing functionality.
To summarize, the biggest features of Mach-II are its event-driven architecture and its extensibility. This philosophy has allowed us to grow the framework over the years, and also allows developers to easily grow their Mach-II applications.
3. How did Mach-II come about and what was the reason for creating it? How are you involved?
Mach-II was originally developed by Ben Edwards and Hal Helms in 2003, and is the original OO framework for CFML. Mach-II was originally called "Fusebox MX" because it was intended to be a Fusebox-like framework that would leverage the new object-oriented capabilities of CFML when CFCs were added to the language. Soon after starting on development, Ben and Hal realized the framework was turning into something completely different from Fusebox, and decided to rename it Mach-II. The "II" in the name actually stands for "implicit invocation," which is one of the core architectural principles of Mach-II.
In 2005, Hal and Ben asked Matt Woodward to become the release coordinator for the next release of Mach-II, and soon thereafter Peter Farrell was added as a contributing developer on the project. Matt recently transitioned into a new role on the project of community manager and contributing developer, and Peter is now the lead developer. We also added Kurt Wiersma to the core development team, and this team is responsible for all Mach-II releases since version 1.1.0, which was released in 2005.
In 2007, Peter's company, GreatBizTools, LLC, became involved with the project and now offers commercial support and official training for Mach-II. Peter, Kurt, and Matt developed and delivered the first official Mach-II training prior to the cf.Objective() conference in 2008, and this training will take place in other locations throughout the year. For example, we offered an abbreviated version of the training at the BFlex/BFusion conference in Bloomington, Indiana in September, 2008, and have plans for complete training courses in other locations in the U.S. We are currently running a survey to get feedback on where in the United States people would like to see Mach-II training held.
Peter, Kurt, and Matt continue to serve as the core Mach-II team, but we are in the process of expanding the team a bit so we can offer even better community support and improve the quality and quantity of our documentation. For example, we added Brian FitzGerald as the Wiki Manager recently. We'll have even more to say about this soon.
4. When should a developer seek out Mach-II? what has it got going for it?
Probably the biggest thing Mach-II has going for it is how much is eases the pain of maintenance. If we as developers do our jobs well, the biggest chunk of time in the lifespan of our application isn't the development phase, it's the maintenance phase. Mach-II helps speed up the development process because developers don't have to reinvent the plumbing for each new application, but where Mach-II really starts to shine is when changes need to be made to the existing features of an application, or when new features need to be added.
Because of the way Mach-II applications are architected, and because of the flexible nature of the event-driven concept, it's quite painless to make rather radical changes to an application. The panicked thought of "If I touch this, what's going to break?" that we've all had as developers simply isn't a concern because of the modular nature of Mach-II applications. This of course means that existing features can be changed as much as necessary and new features can be added, and the only piece of the application that will be impacted is the piece that's being changed. This gives developers a great deal of freedom and confidence when making changes to existing applications.
Developers should also seek out Mach-II if an application that started small is getting larger and becoming difficult to maintain. I'm sure we've all been in this situation as well, that what was supposed to be a quick prototype is now a heavily used production application and users are clamoring for new features. If the application was initially designed as a prototype, chances are expanding and maintaining the application wasn't part of the original architecture. With Mach-II an application can start small and be developed quickly, but also have infinite extensibility through things such as filters, plugins, and modules. Applications rarely get smaller over time; they always grow!
In short, if developers are losing sleep over maintaining their applications because they've become fragile, or they're concerned about how to expand their applications over time, Mach-II is designed to address these concerns.
5. What are the pre-requisites for using Mach-II? Is there any prior knowledge that would help new users? Does it use any other frameworks that could simplify or complicate things?
Developers coming to Mach-II should have a decent understanding of OO principles, because developing a Mach-II application more or less mandates that developers be doing OO development as opposed to procedural development. Since we should all be doing OO development at this point anyway, we don't see that requirement as a bad thing. That being said, we always tell people that diving into Mach-II is not a particularly good way to learn OO development, and this is also why in our training courses we spend the better part of a day on general OO concepts because having a good grasp on OO is very important to being successful with Mach-II. It really isn't as daunting as it sounds, however. Most people who've taken Mach-II training have told us they got up to speed very quickly with the fundamental OO knowledge we provide in our training courses.
Mach-II does not rely on any other frameworks directly, but many developers leverage ColdSpring in conjunction with Mach-II, and this is a very powerful combination. Mach-II is specifically designed to be easily extensible, and this is illustrated through the ease with which other frameworks such as ColdSpring, and object-relational mapping (ORM) frameworks like Transfer can be leveraged within Mach-II applications. To integrate ColdSpring with Mach-II, for example, it's as easy as enabling one of Mach-II's property CFCs.
In Mach-II 1.6 we added comprehensive and powerful caching and logging functionality that both can be used as standalone frameworks outside of the context of Mach-II. While these aren't technically separate frameworks, this again points out how we build everything in Mach-II in a very modular way. This allows the core framework to stay as clean and lightweight as possible while allowing for powerful extensibility, and things like caching and logging can be added without getting into the guts of the framework itself.
6. What sets Mach-II apart from other frameworks?
I think Mach-II's long history is a big thing that sets Mach-II apart from other frameworks. Mach-II is the original OO framework for CFML and has continued to innovate while remaining true to the ideal of keeping the core framework small and offering extensibility through its architecture. Ben Edwards did a fantastic job of creating a rock-solid core for the framework that we've been able to build on over the past several releases. Every time we add a new feature and see how elegantly this can be accomplished we realize how fundamentally sound Mach-II is at its core.
The other major thing we feel Mach-II has going for it is its extensibility features. This started with filters and plugins which have been available since the first versions of Mach-II, and these features offers developers simple yet powerful ways to extend the framework in their applications. In more recent versions of Mach-II we've added things like property CFCs and modules, and the new caching and logging features in Mach-II 1.6 follow this same model. Modules in particular are very helpful on large applications because developers can break applications down into logical sections, develop them independently, but have them all interact as part of a single Mach-II applications. Mach-II users building large applications have told us time and again that modules are their favorite architectural feature of Mach-II.
7. Are there any great examples of Mach-II "in the wild"?
Plenty! Mach-II has been around for a long time now and has very wide adoption. To give some examples, parts of adobe.com are built in Mach-II, including the very high traffic "Site of the Day" section. Numerous internal applications at Adobe are also built on Mach-II.
An example of a recent high-profile site launch is TunesBag.com, which is an extremely high-traffic and innovative music sharing/social networking service based in Austria. It's received a lot of press recently in both the U.S. and Europe, and according to Hansjoerg Posch who created TunesBag.com, Mach-II "rocks!"
Mach-II is also powering the ambitious ground-up creation of a content management system at Forum Communications Interactive - FCI. Forum is media company with large network of mid-western newspapers and few a radio/TV outlets. In the case of this, FCI is using Mach-II to build a custom CMS that will be used by all media properties websites for effective advertising and content management. Of course the amount of traffic newspaper web sites receive is quite high so they are taking full advantage of the new caching features built into Mach-II 1.6.
Mach-II is used heavily in numerous commercial applications, particularly where maintenance of large CFML applications had become an issue. One example of this is Unitrin Specialty, which is part of Unitrin Group, a company that had over $3 billion in revenue in 2006. Unitrin Specialty is a major high-risk auto insurance company. They use Mach-II to handle their online payments and this accounts for 65% of the company's total payments. Mach-II-powered applications also handle claims, reports, policy management, and numerous other processes. According to one of their developers, the use of Mach-II "drastically cut down on maintenance time" as well as the time it takes to introduce new features into their system. This is great to hear because that's exactly what Mach-II is designed to do.
Government agencies and educational institutions are also heavy users of Mach-II. Examples of government and educational agencies using Mach-II include applications at the Environmental Protection Agency (EPA), NASA, Johns Hopkins Bloomberg School of Public Health, the United Nations and many others. At the EPA they're developing all their new business systems in Mach-II and are also converting all their old applications to Mach-II. This is a great example of the power of a framework, because once everything is standardized on Mach-II, developers can hit the ground running when working on any application even if they didn't build the application originally.
Johns Hopkins Bloomberg School of Public Health uses Mach-II as the "backend glue" for their training and education applications, which are, quoting one of their developers, "used by thousands of public health professionals every year, helping to improve the quality of life for millions of people worldwide." We take great pride knowing that Mach-II is a part of this effort.
UN Environment Programme is using Mach-II for their library/archive of graphics on sustainable development and environment. It is currently their most popular site and receives a fair bit of traffic. The application survived a Reddit/Stumbleupon/Digg onslaught earlier this year and we've been told the only problem that occurred was that the "[network] pipe got flooded for a few hours."
Other examples of Mach-II in the wild include Allura Direct, a Canadian vacation rental portal with 70% of their applications currently on Mach-II 1.6 and plans to be 100% on Mach-II by the end of 2008; avonthor.com, a rapidly developed Mach-II site that leverages modules for the secure administrative portion of the site; Monument Snowboards, which uses Mach-II to power their CMS; and DuroDesign Flooring, a specialty flooring company that manufactures green flooring and uses Mach-II for their website, which serves over 3 million requests a year on a small VPS server.
To cite just a couple of other examples, Creori, Inc. uses Mach-II in the majority of their projects. Mach-II drives their ecommerce engine which powers sites such as SeaVees and Friend or Foe. They are about to launch a completely rewritten version of the ecommerce engine using the new features of Mach-II 1.6. They also built a CMS in-house using Mach-II.
There are numerous other examples of high-profile public Mach-II applications, but hopefully these serve as a good cross-section of the types of companies using Mach-II and the benefits they're experiencing. Mach-II performs extremely well on high traffic sites, and the new caching features in Mach-II 1.6 take Mach-II's performance strengths to the next level. We were excited to see the number of developers and companies writing applications on Mach-II 1.6 even before it was released as a beta. The early uptake was crucial in improving the framework during the development cycle and allowed us to catch any defects or edge cases early.
8. What about licensing, community, support and documentation?
Mach-II is completely open source and free to use, and is released under the Apache 2.0 license, which means CFML developers can use Mach-II on all types of projects, both commercial/closed source as well as open source. Open source licensing can get confusing, so the bottom line is Mach-II is free to use for any CFML application.
One of the things we pride ourselves on with Mach-II is our community and our support. The Mach-II Google Group has 550 members and is still growing strong, and Team Mach-II provides as much support as we possibly can through the Google Group. We're also expanding Team Mach-II to include some of the community members that have done a fantastic amount of work on the documentation housed on our rapidly growing wiki. Documentation can always be improved of course, so once the final version of Mach-II 1.6 is released, we're beginning a "tools down" phase of the project and focusing exclusively on documentation and sample applications.
As mentioned earlier, GreatBizTools also offers commercial support and training for Mach-II, which in our opinion is very important for both the Mach-II project and our users. In some corporate environments open source projects are seen as a negative due to the lack of commercial support, so making commercial support available for Mach-II has proven very helpful in addressing these concerns. We've already have numerous companies take advantage of this with great success. The group and on-site training we offer is another aspect of this, because we want our users to be successful with Mach-II over the long term.
9. What's coming up in the future for Mach-II?
We're going to continue getting people information on new features as early as we can, which we feel is vital to the transparency and openness of truly open source projects. As we did with Mach-II 1.5 and 1.6, for Mach-II 1.8 and 2.0 we will release feature specifications as soon as they're more or less fully baked in our heads, but before we've written any code. This lets Mach-II users give us feedback very early in the development process so that we can make changes to the specifications as needed to better meet the needs of our users. We firmly believe this is the best way to run an open source project, particularly an open source framework project, because developing features in a back room somewhere and announcing them when they're completely coded is not good for us or for Mach-II users.
The other thing we're going to do with future releases of Mach-II is do smaller releases more frequently. Mach-II 1.6 (currently in RC2 with a final release very soon), even though it's only a "dot release" in terms of the version number, introduces caching, logging, and numerous other new features, so it's a very big release of Mach-II. Future releases will focus on smaller pieces of functionality, getting them fully developed, and releasing them so we can get new features in the hands of our users much more quickly.
In terms of future releases, we have a maintenance release, which will probably be version 1.8, targeted for release early in 2009. Following that we'll begin work on Mach-II 2.0, for which we have some very cool features planned. We'll make our initial specifications on these new features available as soon as we work out some of the details, and then the all-important feedback loop with our users can begin.
10. Where can people find more information about Mach-II?
The official web site is at http://www.mach-ii.com, where people will find great articles, tutorials, sample applications, and numerous other resources. We also have a Trac site, wiki, and Subversion repository available at http://trac.mach-ii.com. We plan to transfer all our documentation to the wiki over time, so those interested in Mach-II will want to bookmark that site. People can also join the Mach-II Google Group. It's a low-traffic, high-quality group where people can feel free to ask any and all questions about Mach-II.
