- The History of Version Control (Francis Irving) — concise history of the key advances in managing source code versions. Worth it just for the delicious apposition of “history” and “version control”.
- BrowserID — Mozilla’s authentication solution. BrowserID aims to provide a secure way of proving your identity to servers across the Internet, without having to create separate usernames and passwords each time. Instead of a new username, it uses your email address as your identity which allows it to be decentralized since anyone can send you an email verification message. It’s currently implemented via JavaScript but hopefully it will be built into the browser in the future. (via Nelson Minar)
- A Look Inside Mobile Design Patterns — Sample chapter on how different apps handle invitations, from a new [O’Reilly-published, huzzah!] book on mobile design patterns. (via David Kaneda)
- Node Toolbox — concise compendium of resources for node.js development.
"design patterns" entries
Contrasting architecture patterns with design patterns
How both kinds of patterns can add clarity and understanding to your project.
Developers are accustomed to design patterns, as popularized in the book Design Patterns by Gamma, et al. Each pattern describes a common problem posed in object-oriented software development along with a solution, visualized via class diagrams. In the Software Architecture Fundamentals workshop, Mark Richards & I discuss a variety of architecture patterns, such as Layered, Micro-Kernel, SOA, etc. However, architecture patterns differ from design patterns in several important ways.
Components rather than classes
Architectural elements tend towards collections of classes or modules, generally represented as boxes. Diagrams about architecture represent the loftiest level looking down, whereas class diagrams are at the most atomic level. The purpose of architecture patterns is to understand how the major parts of the system fit together, how messages and data flow through the system, and other structural concerns.
Architecture diagrams tend to be less rigidly defined than class diagrams. For example, many times the purpose of the diagram is to show one aspect of the system, and simple iconography works best. For example, one aspect of the Layered architecture pattern is whether the layers are closed (only accessible from the superior layer) or open (allowed to bypass the layer if no value added), as shown in Figure 1.
Figure 1: Layered architecture with mixed closed and open layers
This feature of the architecture isn’t the most important part, but is important to call out because if affects the efficacy of this pattern. For example, if developers violate this principle (e.g., performing queries from the presentation layer directly to the data layer), it compromises the separation of concerns and layer isolation that are the prime benefits of this pattern. Often an architectural pattern consists of several diagrams, each showing an important dimension.
The art of design patterns
Communicate more efficiently, concisely, and accurately.
Download a free copy of An Engineering Manager’s Guide to Design Patterns, a brain-friendly report that shows you how object-oriented design patterns are ideal for solving specific problems in application design.
If you haven’t had the pleasure of viewing Hal Abelson & Gerald Sussman’s 1986 MIT introductory computer science course, you owe it to yourself to set aside a few hours to view it. “1986?”, you say — “Could that really be relevant to my work today?” Unless you came through MIT or a similar program that teaches from their seminal book The Structure and Interpretation of Computer Programs, I’d bet you are most likely going to learn a few new things (even if you consider yourself a seasoned software developer).
Play the video, and right away you might be surprised, as Abelson, in the first five minutes of the class, states that not only is computer science not a science, it doesn’t have all that much to do with computers. Rather, Abelson suggests, computer science is more of an engineering discipline, or perhaps even an art; and, rather than being concerned with computers, computer science is more an exercise in creating imperative knowledge and managing complexity.
Anyone who has ever been late on a software development project (who hasn’t?) can relate to this. Software development starts to feel more like an art or craft when the best you can do is roughly estimate the size and scope of a job and then cross your fingers and hope for the best — certainly, it is at times like these when our field doesn’t feel like much of a science. And, for anyone who has worked on a project of moderate size, at some point you find complexity staring you in the face. All too often our first designs, and our code, turn into the dreaded big ball of mud (yes, that is a technical term).
Read more…
3 easy reasons why you’ll move your business to the cloud
Migrating to cloud-native application architectures leads to innovation.
Editor’s note: this is an advance excerpt from Chapter 1 of the forthcoming Migrating to Cloud-Native Application Architectures by Matt Stine. This report examines how the cloud enables innovation and the changes an enterprise must consider when adopting cloud-native application architectures.
Let’s examine the common motivations behind moving to cloud-native application architectures.
Speed
It’s become clear that speed wins in the marketplace. Businesses that are able to innovate, experiment, and deliver software-based solutions quickly are outcompeting those that follow more traditional delivery models.
In the enterprise, the time it takes to provision new application environments and deploy new versions of software is typically measured in days, weeks, or months. This lack of speed severely limits the risk that can be taken on by any one release, because the cost of making and fixing a mistake is also measured on that same timescale.
Internet companies are often cited for their practice of deploying hundreds of times per day. Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.
The elasticity and self-service nature of cloud-based infrastructure naturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed. Eventually we can measure the answer to Lean guru Mary Poppendick’s question, “How long would it take your organization to deploy a change that involves just one single line of code?” in minutes or seconds.
Imagine what your team… what your business… could do if you were able to move that fast!
Variations in event-driven architecture
Find out if mediator or broker topology is right for you.
Editor’s note: this is an advance excerpt from Chapter 2 of the forthcoming Software Architecture Patterns by Mark Richards. This report looks at the patterns that define the basic characteristics and behavior of highly scalable and highly agile applications, and will be made available to download in advance of our Software Architecture Conference happening March 16-19 in Boston.
Available now!
The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for both small and large, complex applications. The pattern is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is important to understand each one to know which is best suited for your particular situation.
Think Functionally to Simplify Code
Let the environment do more of the work
Functional programming keeps growing. While it has long been a popular topic in academic circles, and many of my CS-educated friends wonder why it took me so long to discover it, the shift in approach that functional programming requires made it a hard sell in the commercial world. As our computers have become more and more powerful and our problems more complex, functional programming approaches and environments seem better able to shoulder those loads.
Neal Ford, Meme Wrangler at ThoughtWorks, has been showing developers how to shift from classic imperative models to cleaner functional approaches. I was lucky to get to talk with him at OSCON, and we’ve also posted his OSCON talk, with many more concrete code examples.
Insights on speaking, writing, and working with MongoDB
An interview with Rick Copeland, the author of MongoDB Applied Design Patterns
At a recent MongoDB SF event, I had a chance to meet Rick Copeland. He was in town and stopped by the event to sign copies of his book, MongoDB Applied Design Patterns. While I am not Rick’s editor, I approached him to see if he would be okay with me filming the book signing as well as participating in a follow-up written interview. He agreed. It was great to catch a bit of footage of the event as well as have a chance to ask Rick about how he started working with MongoDB, why he wrote the book, and how he balances a busy schedule filled with working, writing, and speaking.
How did you get started working with MongoDB?
Rick Copeland: I started using MongoDB at Sourceforge in 2009. Just before I came on board, the decision had been made to base the next generation of SourceForge on MongoDB instead of relational databases. The driving factors behind this decision were some internally-conducted benchmarks and a developer love of the document-oriented model.
How you can stop trashing PHP code
Design patterns for PHP
William Sanders (@williebegoode) is a Professor of Interactive Information Technology at the University of Hartford and author of over 40 technical books! His latest book with us is Learning PHP Design Patterns. We recently sat down to talk about design patterns and how they can help create reusable code and save you valuable time. You can also check out more from Bill at his website.
- Why use design patterns for PHP? [Discussed at the 0:28 mark.]
- Big programs and lots of code can become unwieldy [Discussed at the 2:06 mark.]
- Mobile devices and PHP design patterns [Discussed at the 5:30 mark.]
- Bill talks common design patterns and how they help [Discussed at the 7:25 mark.]
- How to start using design patterns with PHP [Discussed at the 10:15 mark.]
You can view the entire interview in the following video:
Related:
Four short links: 19 December 2011
Version Control, Web-based ID, Mobile Design, and Node.js Tools
Four short links: 4 March 2011
Javascript AR, Android Patterns, Node.js Book, and SMS Platforms
- JSARToolKit — Javascript port of the Flash AR Toolkit. I’m intrigued because the iPad2 has rear-facing camera and gyroscopes up the wazoo, and (of course) no Flash. (via Mike Shaver on Twitter)
- Android Patterns — set of design patterns for Android apps. (via Josh Clark on Twitter)
- Preview of Up and Running with Node.js (O’Reilly) — Tom Hughes-Croucher’s new book in preview form. Just sorting out commenting now. (via Tom on Twitter)
- #Blue Opens for Business — a web app that gets your text messages. You can reply, and there’s an API to give other apps read/write access. Signs the text message is finally becoming a consumer platform.
Four short links: 1 March 2011
Controlling Standards, Async Persistence, Javascript Patterns, Social Mechanics
- Implementing Open Standards in Open Source (Larry Rosen) — Companies try to control specifications because they want to control software that implements those specifications. This is often incompatible with the freedom promised by open source principles that allow anyone to create and distribute copies and derivative works without restriction. This article explores ways that are available to compromise that incompatibility and to make open standards work for open source. (via Sam Ruby)
- Easy WebSocket — simple Javascript client for WebSockets. (via Lucas Gonze on Twitter)
- Essential Javascript Design Patterns — updated book of Javascript design patterns.
- Social Mechanics (Raph Koster) — a taxonomy of social mechanics in games. See also Alice Taylor’s notes. (via BoingBoing)