Brandon's Notepad

February 13, 2018

Agile: Online Resources

ShortURL: http://wp.me/pb7U7-2SJ


This is a list of interesting articles and videos concerning Agile Software Development. I have read, watched, or listened to each one. They have been added here because I found the content useful, either in my current situation or for future discussions. Expect the list to grow.


Articles

The articles and ‘blog posts listed below are grouped by topic, but the topics are in no particular order. I tried to find the originating article for a topic (if possible) and then list below it (indented) other articles that respond to or built upon it.

Videos

At the moment, the list of videos is less-stringently organized than the articles in the previous section. The reason is that there are far fewer videos worth watching than there are articles to read, and I tend to favor long videos, which shortens the list even further.


 

Advertisements

January 30, 2018

Agile: A Conversion Story

ShortURL: http://wp.me/pb7U7-2SK


This is the story of how I became an Agile convert. After sixteen years of denial, I finally opened my eyes to the benefits of this wonderful framework. Writing this post was a very humbling experience. I was seriously tempted to blatantly rip off Kubrick and title this post How I Learned to Stop Worrying and Love the Scrum.


My first exposure to Agile was sometime in 2001 in the form of XP (Extreme Programming). I was active on several developer discussion forums at the time and XP started coming up as a topic more and more frequently. One of my favorite discussion points was the need for proper traceability from concise, structured requirements to design elements and ultimately to code. XP, with its paper-based story cards strewn about on tables or cork boards and then entombed in boxes or banded stacks when the project was over, seemed to mock the sheer beauty and efficiency of a well-maintained requirements database that could be easily searched and reported upon. And paired programming? What a waste of developer hours! Why dedicate two people to a single programming task? What kind of coder needs someone constantly looking over his shoulder and critiquing every little typo anyway? I conceded that such foolishness may be tolerable for small applications or short-term engagements, but it would never work for real applications, the stuff of corporate I.T. projects that took many months or even years to deliver.

I happily ignored Agile for many years after that. Doing so was easy, as none of my clients or employers used any of the Agile frameworks, that is, until about four years ago when the new CIO at my company started talking about it…a lot…and not as a joke. No one in the department seemed to be taking him seriously, so I dismissed the notion that it would actually take hold, but I also knew that I could no longer flat out ignore Agile. If the CIO was talking about it, then I had to make sure he (and everyone else) knew that adopting it would be a mistake. I didn’t want to look like I wasn’t willing to be a team player, but I also didn’t want to throw away all of the hard work we had invested in creating a very stable and controlled development environment. That CIO left the company within a year. An interim CIO seemed to like the Agile concept, but admitted openly that he had no plans to change the strategic direction of I.T., preferring to “keep the lights on” and let the permanent replacement call the shots. Whew! We were safe. So I thought. The new permanent CIO, though not heavy in development experience, arrived already convinced of the efficacy of Agile.

Any attempt to derail Agile at this point would have been what we call a serious CLM (career-limiting move). It was time to adapt. But how? Our development, test, and release policies and procedures were hardly what you might call Agile-friendly. Frankly, our Project Management policy read like an excerpt from the PMBOK. I had no idea what this was going to look like or where to even start, When one consultant started managing his development team using Scrum, I asked to shadow him so that I could learn more about how Agile was supposed to work. I admit, I would not have been disappointed had I found evidence confirming my previous notions about Agile, but I attended the team’s events with an open mind and tried to leave my skepticism at the door. By the time he left for his next assignment, I still wasn’t convinced that Agile was going to be the right fit for our department, but I had learned enough to understand how it might work if everyone got used to it and agreed to play the game.

My biggest takeaway from this exercise was that, in terms of software development, Agile wasn’t significantly different from traditional development (i.e. the waterfall methodology), in that requirements still had to be gathered, software designed, code written, the product tested, and user documentation produced. What was radically different was that it severely limited the scope of these activities for a specified, short-term period of time; thus, it allowed for course correction at any point should (read: when) requirements change.  I learned that requirements needn’t be quite so formal or design so rigid, and that documentation can be limited to a sane amount that might actually be read again later. I still felt like a lot of useful information — mostly artifacts from the development process useful internally in many ways — was going to be lost in the process.

A few months passed and I continued to monitor the growing use of Agile within the development teams. By this time, most of them had latched onto Scrum terminology in particular. Overall, things didn’t seem to be going well. The teams were struggling with many different things, and it was becoming obvious that most of them were not truly adopting the Agile mindset. Then a golden opportunity arose! I managed to volunteer to be the Scrum Master on one of the teams. “As long as it doesn’t interfere with your regular duties,” my boss said as he gave me permission to fill the role temporarily. The project was failing and the team disjoint, so I figured it was going to be a serious opportunity to experiment and see what Agile could do to improve the situation.

The first sprint was rocky and I spent half of my time figuring out how to produce a proper burndown chart in the task management system we had selected. With the second sprint I began every daily scrum with the burndown chart on the large screen in the conference room. The (positive) impact this made on the team was shocking. Tired of watching me update tasks with hours spent and hours remaining, the team started keeping their own metrics up-to-date sometime in the third sprint. By the fourth sprint, we were “flying by instrument” as I like to put it. It was beautiful! The sprint backlog (in hours) was at about 85% of capacity, leaving a little wiggle-room for error, and we trended downward more-or-less as one might expect. I’d love to report that the project had made a sweeping turn just in time and became a stunning success, but sadly, it did not. Despite the great strides the team had made, it was not happening fast enough, and management pulled the plug on our experiment. The software was eventually released for production use, late, using conventional project management, but I walked away with a completely new perspective. I finally understood why and how Agile worked! I was no longer a critic, but an advocate.

Within two months, half of the department (including myself) had been formally trained and I jumped fast at the chance to be on the Agile transformation team that would be responsible for the formal adoption of Scrum. Half a year later, I earned my certification. Looking back, it amazes me how quickly my view of Agile changed so completely. I have since learnt a great deal beyond what was covered in training, but I will have to write about such things another day.


 

January 19, 2018

Agile: My Journey

ShortURL: http://wp.me/pb7U7-2SF


About a year before I wrote this post, I set out on a journey that I was not expecting to take. I became seriously involved in Agile software development, the Scrum framework to be more specific. Prior to that time, I was not only completely uninvolved, I was an outward opponent of Agile as a result of my initial exposure to Extreme Programming (XP). What changed? Where am I headed now? That’s all part of my story.

This is a work in progress. If you find what I have posted so far to be interesting, please feel free to follow me on Twitter and/or WordPress.com.


My Journey

In the spirit of Agile, I’ve decided to document my journey in the form of stories, the sum of which constitute an epic. Cute, eh? No, I didn’t plan for it to happen this way. The stories have just emerged. This is the landing page. As I publish the parts of my story, I will link the posts to the list items below. This will take time. I am still on the journey.

  • My conversion story
  • Why Agile Works
  • I think I’m missing something here…
  • A (Hard) Lesson in Writing Stories
  • Let Them Eat Cupcakes
  • more to come…
  • The Agile Blogger

I also plan to post an Agile reference page, which I will probably link in this space.

My Goal

As with all of the content on this site, my primary goal is to record my personal notes on this topic for later use. A secondary goal is to make this information available to anyone who may find it useful. Another huge personal benefit is that the preparation required to write on this topic almost ensures that I will ingest the material

Why Now?

So, why am I writing about Agile in 2018? It’s been seventeen years since the Agile Manifesto was penned, and even then, some of the Agile variants had already been in use for ten years or more. Agile isn’t new anymore, it’s not the next big thing. In the grand scheme of things, I arrived on the Agile scene quite late and I am far from being an expert (yet). The answer is that this post (and its related content) is as much about me and my experiences as it is about Agile itself. I’d like to think that this makes the material unique, but I know that I am following where many other developers have already trod. Nonetheless, I hope that writing my thoughts will provide value.


 

December 27, 2017

The vi Text Editor

ShortURL: http://wp.me/pb7U7-2QA
Home > My Lists > Technology > Software Development References > The vi Text Editor


User Guides & Tutorials

Tips & Tricks

  • Insert contents of another file into current file using :r filename
  • Open second file in split window using :sp or :vsp. Use Ctrl+w to switch between window panes.

September 14, 2017

TFS / VSTS Customization

ShortURL: http://wp.me/pb7U7-2DL


I started working heavily with Microsoft Team Foundation Server (TFS) in the summer of 2016 and may be migrating to Visual Studio Team Servcies (VSTS) in the not-so-distant future. The need to customize TFS operations was almost immediately obvious, and the complexity of the customization only increases in proportion with the use of the tool. This page is a (growing) list of links that I’ve found useful.


Runtime Environment Variables

Environment variables are available for use during both build and release operations. These are my go-to references when I need to figure out how to get to runtime data.

Marketplace Extensions

The Visual Studio Marketplace offers many useful extensions for TFS & VSTS. Some implement or extend features such as dashboards, but the ones I’m most interested in (at least for now) are the build and release tasks. Like apps on a smart phone, these little gems eliminate the need for writing extensive scripts to compile code and deploy products. I’ve found it important to check the Marketplace often for new items as well as for updates to extensions already in use.

Favorites

Futures

Forgo

  • Hopefully, I won’t have to add any extensions in this section.

Custom Scripts & Extensions

If you can’t find what you need in the Marketplace, you can always write your own deployment scripts and extensions. These can be published or retained for internal use only, your choice. Here is a list of useful resources for beginners.

Extensions

Powershell

REST API

More to come…


February 11, 2016

ITIL: Service Strategy

ShortURL: https://goo.gl/IwRcCr


To master a body of knowledge means to internalize it and become so intimately familiar with it that the student becomes the teacher. This post was started as a place to capture my notes about the Service Strategy stage of the ITSM model, and with the date scheduled for my ITIL Foundations exam still weeks away, there is already discussion at the office that my team may offer a series of short introductory classes on various aspects of ITSM. That’s why I shifted gears, now less interested in posting yet another set of topical outlines and bulleted lists, and more focused on synthesizing the material and presenting it in my own words, thereby making it more interesting and memorable.

Disclaimer: I wrote this page to capture my perception of the ITIL material, not to provide adequate guidance for passing the ITIL exams. Moreover, this page has been written (so far) without the use of the official ITIL Foundation 2011 Syllabus; therefore, the information may be incomplete.


Service Strategy Overview

The entire ITIL framework is a roadmap for converting IT into a service-oriented business. Of course, external service providers have existed for a long time: web hosting, e-mail, IT outsourcing, and the like. Converting the internal IT department into a more-or-less independent entity is another thing altogether, and can be quite a paradigm shift to many. Service Strategy is the stage of ITSM that most resembles the job of senior management in any given organization. It is the ‘business’ of doing IT.

Purpose. The purpose of Service Strategy is described in the literature as the four P’s: perspective, position, plans, and patterns. (I’ve personally never found mnemonics like this one very helpful, and I only mention it here because it is in common usage.) These are the same concepts found in strategic management textbooks. Perspective is another word for vision, describing the business in terms of customers and services offered. Position basically refers to market position, and includes that which makes the organization unique. Plans and patterns are similar in that they relate to the forward motion of the organization. Patterns refer to the things that the organization does on an ongoing basis, core competencies if you will. Plans are more strategic in nature and focus not just on staying in business, but growing and transforming it.

Objectives. Having a vision is great, but a business must have a concrete foundation if it is expected to survive. If the four P’s constitute the vision/mission statement, then the objectives of Service Strategy is akin to a business plan. The vision must be stated, but the details of how the business plans to get there must be articulated in concise detail. The services to be offered, the value they represent for the customer, how they will be funded and delivered, and what assets will be required are the same sort of details that a bank wants to know before making a loan to a start-up company in any industry.

Scope. All service organizations should have a strategy, even if they operate within a larger organization (such as an internal IT department). It is good to keep in mind that the strategy focuses on two main concerns: how will the organization meet its customers’ needs, and how will the resulting services be managed and maintained?

Value Creation. Ultimately, services will only be used if they provide value, which can take on various forms, from cost reduction measures (such as outsourcing) to value-add items (such as product differentiation). Value comes from the conversion of assets (both tangible and intangible, resources and capabilities) into goods and services. Value must be clearly presented in terms of business outcomes that the customer understands. In a nutshell, the service organization is constantly on the ‘buy’ side of a build-versus-buy cost-benefit analysis. At the same time, the service organization must stay in tune with the customers’ needs and always work toward fulfilling them, even when those needs change. Flexibility can be vital to staying competitive. Of course, these statements are true for any service organization, not just the information technology service provider. Turning the IT department into a profit center (as opposed to the traditional cost center) will drive efficiency and effectiveness. How does the customer perceive the value of a service? Economic value is usually based on a reference point, the cost of the old service that the new service will replace, for example, or even the price of similar services offered externally. This amount is adjusted based on the perceived benefits and costs of switching. The new service may provide many benefits, but at the cost of giving up one or two key features. It is always important to know if there is a gap between what the customer values and what the service organization thinks it is providing.

Risk Management. Customers will usually purchase a service if they don’t want to own the costs and risks of providing the same service to themselves. The service provider must now identify and assess potential risks.

Service Types. Services that are customer-facing may be basic or “core” services or they may enhance a core service and thus differentiate the service provider from the competition. Services that support a customer-facing service but are not visible to the customer are called enabling services. For example, an online e-mail service is a modern commodity, but a feature that presents communications as aggregated conversations instead of individual messages is an enhancement that differentiates the service from other online e-mail services (at least until they all provide that feature as core). The underlying database, the network infrastructure, and even the third-party virus scanner used by the e-mail service are supporting or enabling services.

Service Strategy Processes

As with all of the ITSM stages, great emphasis is placed in the processes of Service Strategy. Different texts order the five SS processes differently. I’ve chosen to order them in what seems to be a natural progression.

Strategy Management. Without the formation of a strategy, the service organization would lack direction, and some or all of the following would not be implemented.

Portfolio Management. An investment portfolio includes a number of varying financial instruments that, in aggregate, help the investor achieve certain investment goals. Some portfolios reduce risk through diversification, whereas others help protect investment dollars from inflation. This concept has been extended into the project management space, as each project in the portfolio has an estimated net worth and return on investment (ROI). A service portfolio is the same concept applied to the mix of services offered by a service provider. The portfolio includes not only the services that are currently being offered (i.e. the Service Catalog), but also services being developed (the Pipeline) and services already retired. Moreover, procedures must exist for determining which services should be added and which should be retired, and when. A business case can be written for each proposed service addition or modification. The documents that describe all services are stored in a configuration management system comprised of several different data sources.

Financial Management. Services are not free to offer. They have operating costs associated with them that can be reasonably predicted at the time the services are designed. Of course, an initial investment is required to design a new service and to implement it in the operating environment of the customer. And it should go without saying that no business should enter into a new deal if there is no hope of turning a profit from it. Some services cost more than they are worth, and some service providers have a propensity to get in over their heads when committing to dead-end service offerings. It can be very costly to implement someone’s ‘good idea’ for which there is no actual demand. Without a financial management component, the service provider may take on significant financial risks such as these with little or no hope for recovery of investment. Financial Management assists in the valuation of services, and provides information needed for demand modelling and the optimization of provisioning activities. This process also ensures compliance with accounting principles, regulations, and reporting requirements as well as the establishment of good budgetary practices and the billing and collection of revenues from the customer if applicable.

Business Relationship Management. As the name implies, the role of the business relationship manager (or what I’ve always called an account rep) is to maintain the relationship between the service provider and the customer. It is not enough, however, for this manager to ensure that the two entities simply stay in communication with one another at least occasionally. Customer satisfaction is the real focus here. The manager must understand the value being provided to the customer, identify new and changing customer needs, and ensure that the service provider adjusts as necessary to meet these needs. Feedback from the customer (including compliments and complaints) is one obvious source of information the manager can draw from, but changes in the customer’s industry, as well as changes in technology should also be monitored. Business Relationship Management falls on the strategic end of the spectrum, whereas Service Level Management is far more operational in nature.

Demand Management. Services cannot be stored in inventory like physical goods can. Costs are incurred and revenue generated as services are consumed. Therefore, the service organization should avoid generating too much (excess) or too little (insufficient) capacity. Analyzing patterns of business activity can help predict the demand for individual services. Uncertainty in demand is a risk.

Conclusion

Nothing in the Service Strategy literature should come as a surprise to someone who has studied business in the university. The contents are a mishmash of topics from strategic management, marketing, cost accounting, and microeconomics. In fact, some of the example scenarios I read were in the context of running a hotel or other common type of business. It appears that ITIL basically expresses what non-IT service organizations already do in an IT context.


September 8, 2015

ITIL: Foundation Certification

ShortURL: https://goo.gl/hyYnAu


ITIL has become very popular at work, so I am currently studying for the ITIL Foundation certification. This page was created to capture my notes, not only on the exam material itself, but also on my approach to learning it.


Approach

Several of my coworkers have passed the ITIL Foundation exam after only a few days of instructor-led training, and I’m a fairly good test taker, so I figured that I’d try self-study first. At work we have access to CBT modules, which are often helpful. Before diving into that, however, I wanted to get an idea of what the material should look like, partly to gain some external verification that the CBT was covering the same topics that I’d see on the exam. To this end, I started watching introductory videos on YouTube. I quickly found that the ITIL training materials are diagram-rich, so I started collecting links to the same or similar diagrams on the Web. I also procured a few additional resources, both online and in print. Finally, producing this page forces me to know the material well enough to organize and present it.

Resources

Lynda.com. At work, we have access to Lynda.com, which includes a 7.75 hour ITIL Foundation course presented by Mark Thomas. I enjoyed this course thoroughly. The material is covered in a very logical, methodical way that is easy to follow. Mr. Thomas is obviously very passionate about the material he is presenting. His style gives him away, as he speaks like many other SVP/C-level executives I’ve known in the past. I highly recommend the course, and I think that this course alone is worth more than the fee for a one-month subscription to Lynda.com.

YouTube. As mentioned above, I started by viewing introductory videos on YouTube, primarily to get familiar with the basic ITIL concepts. Here are a few of the more noteworthy choices:

The last video, recorded by Jesse of Bit2Brain, contained some good insight into the experience of taking the exam. It was comforting to hear how the exam isn’t necessarily difficult depending on your experience, and that this certification is truly meant to be entry level. Incidentally, Jesse highly recommended Mark Thomas’ course on Lynda.com. That’s all I really needed to hear before diving in.

Axelos ITIL Glossary. Alexos is the official accreditor of ITIL. They have made available online Glossaries of Terms in a variety of languages. This is very handy, as I reference the definitions to specific terms in my notes here instead of pasting the text directly.

Print Materials. I obtained two print resources at the office:

  • Passing your ITIL Foundation Exam published by TSO (The Stationary Office), Crown Copyright 2009
  • ITIL Foundation (June 2014 ed.) by Global Knowledge Training LLC, copyright 2014

The former covers the 2009 update of ITIL v3, and not the (current) 2011 update, but it looks like the differences are minuscule. The latter is used in the Global Knowledge training course, which is the one my coworkers attended. The material strictly adheres to Axelos guidelines and even contains a printed version of the glossary.

Test Bank. I have considered, but have not yet decided to purchase access to Kaplan’s ITIL 2011 Practice Test.

Exam Overview

The following is a distillation of what I understand the exam to be like. I will reserve details for additional posts linked herein.

Qualification Scheme. Do an image search on ITIL and one of the first diagrams you will see will resemble a pyramid. This is the Qualification Scheme, or at least that’s what it is called in the TSO book. I won’t go into detail about the various levels that must be obtained to become an ITIL Master, but I do want to point out two things. First, this exam covers the bottom layer only. Second, the content covered on this exam is obviously an overview of the five Lifecycle modules and does not appear to cover the Capability modules. The Foundation certification is designed for those who only need a basic understanding of ITIL and the Capabilities stream is the more in-depth of the two. Here are some examples of the Qualification Scheme diagram (with links to their sources):

Introduction to Service Management. More to come…

The Service Lifecycle

Like I said above, the Foundation exam is structured based on the Service Lifecycle and heavy emphasis is placed on its five stages and their various processes and functions and how they interact with one another. Here is a table of Service Lifecycle processes. For the exam, one should be familiar with the definitions found in the glossary for all processes. Those processes listed in italics should be studied in greater detail.

Service Strategy Service Design Service Transition Service Operations Continual Service Improvement
Read My Summary Coming Soon… Coming Soon… Coming Soon… Coming Soon…
  1. Strategy Management
  2. Financial Management
  3. Service Portfolio Management
  4. Demand Management
  5. Business Relationship Management
  1. Design Coordination
  2. Catalog Management
  3. Service Level Management
  4. Capacity Management
  5. Availability Management
  6. Continuity Management
  7. Info Security Management
  8. Supplier Management
  1. Planning & Support (TPS)
  2. Change Management
  3. Service Asset
    & Config Management (SACM)
  4. Release
    & Deploy Management (RADM)
  5. Service Validation
    & Testing (SVT)
  6. Change Evaluation
  7. Knowledge Management (SKMS)
  1. Event Management
  2. Incident Management
  3. Request Fulfillment
  4. Access Management
  5. Problem Management
  1. 7-Step Improvement Process

The stages of the Service Lifecycle are not strictly sequential, like the Waterfall SDLC in application development, but is partially iterative and partially holistic. Services are designed (SD), implemented (ST), and maintained (SO), but all within the scope of a core strategy (SS) and within a spirit of continuous improvement (CSI). Here is how the lifecycle is typically depicted:

Key Definitions

The following is a vocabulary list that I’ve compiled based on the recommendations made in my various study sources. Most of the sources gave more or less the same suggestions. I tried to form logical groupings, but this proved to be difficult considering that these concepts are interrelated in so many ways. Most if not all of the terms and phrases should be found in the ITIL Glossary.

Service (Core, Enabling/Supporting, Enhancing)
Outcome & Value (Utility & Warranty)
Service Management, Service Provider
IT Service & IT Service Management (ITSM)
Service Provider (Types I, II, & III)
Customer (Internal & External)
User / Supplier / Contract
Risk, Governance, Business Case, User Profile
Critical Success Factor (CSF)
Key Performance Indicator (KPI)
Metric, Vision, Mission, Objectives
Vital Business Function (VBF)
Pattern of Business Activity (PBA)
Business Impact Analysis (BIA)
Service Level Management (SLM)
Service Level Requirement (SLR)
Service Level Target
Service Level Agreement (SLA)
Operational Level Agreement (OLA)
Baseline (Performance)
Process / Function / Role
Assets (Capabilities & Resources)
Assets (Customer vs. Service)
Service Owner
Process Owner/Manager/Practitioner
CSI Manager

Event / Alert / Incident / Problem
Normal Service Operation
Incident (Model, Procedure, Major)
Known Error / Workaround
Escalation (Functional & Hierarchy)
Service Request

Service Desk
Technical Management
IT Operations Management
Application Management

Service Portfolio / Catalog / Pipeline
Service Design Package
Configuration Management System (CMS)
Configuration Item (CI)
Change Advisory Board (CAB & ECAB)
Change, Remediation Plan

Availability
Confidentiality
Integrity
Reliability
Resilience
Maintainability
Serviceability
Security

ITIL Infographics

I am a big advocate for using comprehensive infographics. “Put it all on one page if you can!” I say. So, here are a few diagrams that do just that

The Big Picture.

Value Creation (Utility & Warranty).

Process Model.

Processes (ITIL v3).

Functions.

The Service Lifecycle (Alternative View).

RACI Model.

Cross-System Comparisons

COBIT. There are some obvious similarities here. A few graphics are available to show how COBIT functions map to ITIL.

Microsoft Operations Framework (MOF). Look familiar? Yep, Microsoft has created a framework of its own, claiming that it’s simplified process eliminates the problems of top-heavy ITIL. Sounds like a shortcut to me. The upside to this one is that it is free. Here is a comparison.

ISO/IEC 20000. From what I’ve read, ITIL and ISO 20000 are highly compatible.

Just For Fun

Who said ITIL can’t be fun? Here are a few pieces of “fan art” I’ve picked up along the way.

Periodic Table. I used to know the periodic table of elements by heart. I’m not sure I could use this graphic as a way to memorize ITIL, but it certainly is a neat idea.

Map of the ITIL Empire. This map has absolutely nothing to do with the ITIL framework, but it does spark an idea. Why not create a map like this one that shows the interactions between various ITIL functions and processes?

Mass Transit Map. This map, in the style used for mass transit systems, shows tops along the various processes. Interesting idea! I found another version as well.

More to come…

December 31, 2009

Beowulf Clusters

ShortURL: http://wp.me/pb7U7-3C
Home > My Lists > Technology > Hardware > Parallel Computing > Beowulf Clusters


The Beowulf Cluster is one of the reasons I jumped onto the Linux bandwagon in the late 1990s. The idea of making good use of old computers to solve real world problems fascinated me. As computers continue to shrink in size, price, and power consumption, the reuse aspect is less appealing than before, but the concept still draws me in from time to time. I only wish I could justify the cost of building one.


General Information

A Beowulf Cluster generally refers to a collection of consumer-grade computers connected by a local network that run parallel-processing applications. The typical Beowulf Cluster runs on the Linux OS and distributes processing tasks using either Message Passing Interface (MPI) or Parallel Virtual Machine (PVM) libraries.

Resources:

How To Build A Cluster

Building the cluster is half the battle (the other half is writing programs for it). Thankfully, there are a lot of how-to pages out there. Some cover just the basic steps while others provide more explanation and background information. It’s been interesting to watch them evolve over time to, in length, complexity, and style. Here is a sample:

Finally, this isn’t a how-to article, but it’s worth the read. Cluster Urban Legends: Build Your Cluster With Facts Not Fiction, written by Dr. Douglas Eadline in 2007, debunks some of the major myths and misunderstandings surround Beowulf Clusters. In short, it helps you determine if you are really building one for the right reasons.

Cluster Programming

So, you’ve built a Beowulf Cluster. Now what? Well, now You have to write programs for your cluster to solve all of the world’s complex problems. Beowulf Clusters are built for crunching numbers, not serving up web pages. That means they are used primarily in the sciences, though I can think of a few business applications that could benefit from the extra processing power (think derivatives pricing).

I have a lot more research to do in this area. Currently, I have only a link to some information about an old text book to offer. I need to add more tutorials to this list, especially in the use of MPI and PVM, and how to determine when it’s appropriate to use one over the other. Check back later or watch my Twitter feed for updates.

Real World Beowulf Clusters

Years ago, I started compiling a list of real Beowulf Clusters that had been built for various purposes. I still have the list, though some of the links are now gone or only available on the Wayback Machine Internet Archive. I was hoping to do a little write-up on each cluster on the list, but if that doesn’t pan out, then will just add the list in this section.

Humor

And of course, most scientists, engineers, and computer geeks are gifted with a great sense of humor (even if we are the only ones that understand our own jokes).


April 30, 2009

Software Development References

Filed under: Information Technology,List,Programming,Software Development — Brandon @ 7:05 am

Home > My Lists > Technology > Software Development References


Collections

Analysis & Design

Programming

Version Control

Compilation

Packaging

Other


Create a free website or blog at WordPress.com.