Matthew Mead

Technologist and Maker

Technologist and Maker

About / Blog

Spikes in Everyday Life – Deck Lattice

By Leave a Comment

Extreme Programming (XP) defines a concept called a spike. A spike is an activity to find out answers to a touch technical or design problem. Extremeprogramming.org defines a spike as:

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.

When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.

So a spike should be the minimum work required to demonstrate the suitability of the solution, reduce the risk and help estimate the overall effort. Now to a problem outside of programming…

I’ve been meaning to replace the battered wooden lattice around the base of my deck that is attached to my house for several years. I was planning to use a plastic material (plastic lattice sheet and accompanying edging with a pre-cut channel) rather than wood so it is maintenance free and doesn’t rot. I used this plastic lattice and edging the previous year on a project, but was not happy with the way I assembled the lattice to the frame to form a panel.

I realized I was procrastinating on the deck lattice replacement project because of my previous mediocre experience with the plastic material coupled with the fact that I was not sure how long it would take, how much material I needed, what it would cost, and most importantly how I would anchor the finished panels to the base of the deck.

Furthermore, underneath the deck there are no vertical supports on the edge of the deck to which I could screw the panels. As a result, I was not sure how to fabricate and install the appropriate vertical supports without making this a huge production. And I also wanted to make sure the decorative panels were built to last and didn’t fall because they are not secured properly.

Then it occurred to me, I really needed to do a spike to better understand what I was up against. To remove the unknown, determine the effort involved and material needed. I had some scrap lattice and frame left over from my previous project, so I assembled a small panel the way I thought I wanted to do the whole deck. Given that it was a spike, I was prepared and expecting to throw out the panels I was building, just like I would do with code on an agile development project.

When I positioned my first panel in place below the deck, it fit beautifully and I was able to find two excellent and easy locations to secure vertical posts to which the panel was screwed. I was feeling good, but realized that the panel I installed was different from all the other locations and that it was likely easier to install. So, just like with software, if you find your spike does not represent the true unknown, you need to continue the spike. So I decided to continue building a second panel that would be installed in a more typical and potentially more difficult location.

After building the second panel, I held it in position and pondered how the heck to install it without any vertical supports. At this point, it would have been extremely helpful to have a pair carpenter to collaborate with on ideas, but I was out of luck, I was alone. After inspecting the way the panel met the bottom of the deck I realized an easy and hidden way to use metal strapping to secure a post just about anywhere I needed a post. Using this technique, I was able to successfully and easily screw the second panel to its supports. At this point I felt I learned enough and brought the spike to an end.

description

Photo of one installed panel that was built during the spike

With the information I learned from the spike, I was able to estimate the materials needed, the cutting I had to do and the time to cut, assemble and install. Given these discoveries I knew how much it was going to cost and roughly how long it would take to build and install the remaining panels for the deck.

Just like with code built in a spike, I ended up discarding the first two panels I built during the spike because I built them with an emphasis on experimentation and was not concentrating on quality.

The most significant benefit from the spike was the pressure lifted from my shoulders by just committing to do a single panel in a spike and letting go of the complexities for the remainder of the deck skirt. Just like in a software spike, I only addressed the problem under examination and ignored all other concerns. That shift in mindset was freeing!

Open Source Software (OSS) Evaluation

By Leave a Comment

There are differences in evaluating and comparing open source software (OSS) products, as opposed to commercial packages. A number of key OSS criteria are also described. This information is based on years of experience at Redpoint , using OSS and evaluating both open source and commercial software for clients.

Evaluating OSS effectively requires different criteria than the ones used for commercial software. Commercial software selection techniques and tools are inadequate in making informed choices about OSS. Different OSS products will have strengths in different functional and technical areas. Some are growing and vibrant with strong growth in the developer and end-user community, others may be stagnant.

The traditional commercial software evaluation process involves establishing software requirements/functionality evaluation criteria, reading industry analyst reports, meeting with sales and technical pre-sales teams and negotiating licensing and support costs. An in-depth evaluation of commercial software will involve talking to a few reference customers and reviewing the financial stability of the software vendor and the longevity of their product.

Much of the information that is used for the commercial software evaluation is obtained from the software vendor’s sales team. When evaluating OSS, there typically aren’t any sales teams, no on-site demos by the sales team, no glossy sales brochures that highlight product advantages, no advertising and, as a result, the process needs to be different. Also, unlike commercial software, it is not always easy to determine who else is using an OSS product.

Industry analyst reports on OSS are scarce and the information is usually limited. Typically, OSS evaluations focus on the few leading OSS initiatives such as Apache, Linux, MySQL, etc. When evaluating an open source software package, it is important to focus on the following categories:

  • Product Capabilities
  • Quality
  • Integration and Dependencies
  • OSS Community
  • Support

Product Capabilities

It is usually easy to identify and verify the capabilities of an OSS product. Most groups clearly document their features and exaggerations of their capabilities are not typical as they will generate support email and unfavorable discussions in their community. Also, these groups are typically looking for developers to implement their missing feature so they have an incentive to be honest about the capabilities.

Open source products many times have a different focus because of their origins or because of the influence of the developers that initially developed it. Also, OSS tends to evolve and sometimes take on different focus. It is important to consider the focus of a product and how it has evolved to get an indication of where the product may evolve in the future.

Although all OSS can be modified, it is important to understand what modifications are in-line with the product direction so they are within the upgrade path in the future. Most CRM OSS provides a mechanism to customize the software. However, the technique and range of customization that is allowed varies greatly among the products.

Quality

In addition to inspecting the code, development approach, documentation, build environment, testing strategy and general product literature, inspecting the bug database, which is usually public, is a good way to understand the number of bugs in a system. This will indicate the number of high-visibility bugs outstanding and the length of time it takes for typical bugs to get fixed.

Integration and Dependencies

Most OSS list the other OSS or commercial products with which they integrate. The products with which they integrate and the way in which the OSS integrates often says a lot about the general integration mechanism that is available in the product.

Product dependencies also give an indicator of how the product is intended to be integrated. Many times the dependencies are available explicitly from the OSS literature, other times it must be inferred by reviewing the installation and support documentation.

OSS Community

OSS projects can vary from a single developer to a distributed, world-wide, company-backed team. It is important to understand the project structure, its backing and its motivation. Some products are developed by commercial companies attempting to make their money from the customization, support and training. Other projects are only supported by key alliance partners that are a result of the OSS community.

Ideally the team is more than a single developer, but sometimes a very large, distributed team can hinder the ability for the product to have a clear, concise vision and to make targeted release dates.

The strength of the community is best gauged by the support and activity of the OSS wikis, forums and mailing lists. Typically, there are two mailing lists – one for users that includes help installing, upgrading, etc. and another list for the developers to discuss bugs, the roadmap, new features, etc.

Development Process and Source Code Control

The quality and development process is another important consideration for OSS that is not typically available for commercial software. The code can be reviewed and checked for adherence to general product and industry best practices and coding style.

The testing techniques used are also very important. Even if it is not documented, a quick check of the build script will typically reveal whether any unit testing is incorporated into the project. Overall, the software should have some documentation – both from an architectural and code-level perspective.

Even if you don’t plan to alter the OSS source code, it is important that the system can be built (i.e. compiled). Even if you don’t intend to contribute back to the OSS community, it is important to be able to rebuild the system if a show-stopper bug were encountered.

The release management techniques employed by the OSS development group is important. A quality product does not necessarily have a robust release process and does not necessarily have any easy upgrade path. A feel for the release process can be determined by reviewing the release notes with previous builds and determining whether frequent bug releases are distributed shortly after major product releases.

Support

The first level of support for typical OSS is by the community having access to the source. Many OSS bugs are identified and fixed by developers that use the product. Some fix and contribute back the fix to help ensure it is fixed in a future release, not because they feel they have to contribute to the community.

In order to perform fixes on the OSS source code, it must be logical, easy to understand and proper documentation must exist. Some documentation may be in-line in the source code and other documentation will vary from on-line to PDF format.

Most major OSS products have paid support options. This support can range from first-tier support, where the vendor will act as your first-line help desk, to second- and third-tier support where internal support will first attempt to identify and fix a problem before it is escalated to the paid support. The cost of the support decreases as the company takes on more initial support roles (e.g. help desk).

Paid support can range from typical commercial-style maintenance contracts to per-incident agreements. It is important to understand the typical turn-around time for support under the various support agreements.

Performance Testing RackSpace’s Mosso Cloud Files

By Leave a Comment

At Redpoint Technologies, we’ve been evaluating many of the services offered by leading cloud vendors in order to better understand where various cloud offerings are most appropriate. Like any technology, it is important to understand each offering’s strengths and weaknesses.

Today I executed some crude performance tests against the Rack Space Mosso Cloud Files offering. This is very similar to the Amazon S3 storage offering. It allows files to be uploaded to the Mosso cloud server where they can be later retrieved. The service offers no minimum or maximum in overall storage, but does limit individual files to 5GBs or smaller, and utilizes utility-style pricing.

Cloud Files optionally allows you to store your content on a content delivery network (CDN). A CDN is an infrastructure of servers located in different geographic locations that work together to rapidly deliver web content to users based on their geographic location. As a result, a CDN can dramatically increase the speed with which content is delivered/retrieved.

Major Considerations

Depending on your needs for uptime, Mosso offers what I’d consider the minimum availability with a 99.9% uptime guarantee for Cloud Files. This means the service may be down about 10 minutes per week or roughly 40.5 minutes per month. For many applications, that is acceptable, but for mission critical situations, this may not be enough.

The following table summarizes many of the considerations and the description for how these considerations are addressed by Mosso.

Consideration Description
Contracts and Minimums No contracts, no minimums.
Performance See performance notes below.
Cost Minimal: $.15 per GB of storage, $.22 per GB of bandwidth out, $.01 for requests (via control panel).
Security All traffic between your application and the Cloud Files server uses SSL to establish a secure, encrypted channel. This ensures that any data (usernames, passwords, and content) cannot be intercepted and read by a third party.
Availability Offers a 99.9% uptime guarantee. That’s about 10 minutes of downtime per week.
Backup/Redundancy Data is replicated to three locations.
Accessibility Access files via Mosso browser-based control panel or via programmatic API.
Language Support Supports PHP, Phython, Java and .NET via their API. See the developer API documentation

Performance

For an upcoming distributed, grid-based project, I’m interested in the speed with which I can upload gigabytes of data to a temporary storage location.

The performance of Mosso was decent when using their API, but dreadful when uploading via their web-based interface (but to be fair, the web interface is more for account management and less about use in a production system). The overhead of SSL was surprisingly minimal (as compared to raw FTP – see below as this was not an exact comparison).

I used a 24.9 MB bitmap file as my test file to measure performance for uploading files to Mosso (additional tests around downloading would be worth while testing as well). I tested uploading the test file via the Mosso web interface, using the Mosso API from a .NET application (see the c# console application code below) and to this blog site via FTP to have a non SSL benchmark.

I ran each test several times and throughout the day from my cable modem (which scores between 712 to 2550 Kbps in a browser-based connection speed tests). The results from each run were pretty consistent. On average, it took about 6.25 minutes to upload the 24.9 MB test file to Mosso via the Mosso web interface (control panel), about 3.5 minutes to upload the 24.9 MB test file to Mosso via the Mosso API using the below application and about 3.25 minutes uploading to this (shared .NET hosting) blog site using Filezilla.

The results were satisfying in that my raw FTP upload (to a non-Mosso server) were just a bit faster than the Mosso upload that uses SSL. In my brief testing the service was reliable and I like that the Mosso session could be cached indefinitely in a custom application (unlike the web interface that timed out my session after about 20 to 30 minutes of inactivity).

.NET Test Application

You can use the code below to create a C# console application that will upload a file to Mosso’s Cloud Files service. (Please note that you will need to purchase an account at Mosso prior to being able to run this code.) Prior to building/running the application, you need to add a reference to the com.mosso.cloudfiles .NET assembly that is included in the lib directory of the free download that includes the Mosso .NET sample code. And don’t forget to provide meaningful values for the string values in lines 16, 18, 20 and 22.

Although it would be easy to add an upload timer to the code below, I used a physical stopwatch to capture the time for my upload tests.




































Conclusion

In conclusion, you need to be strategic in thinking where you’d use a service like Cloud Files from RackSpace’s Mosso. We would use a service like Cloud Files for storing large files if we could queue them up and upload them asynchronously from our system. Or, perform a synchronous upload if the file was small enough.

From the Mosso’s marketing material, they state that Cloud Files is good for:

  • Backups/archives of your data
  • Serving images/videos (streaming data to the user’s browser)
  • Secondary/tertiary, web-accessible storage for your data
  • Well suited when amount of storage is difficult to predict
  • Simple point-and-click interface via Mosso Control Panel

But that it is not so good for:

  • Native support within your Operating System. It is not yet possible to “mount” or “map” the Cloud Files storage system as a virtual hard-disk on your computer.
  • Disk mirroring or backup solutions that require byte/block level differences. There are no concepts of “append” or “file locking” operations within Cloud Files.
  • Data can be organized into storage compartments called “Containers”, but they cannot be nested. Since there is only one top-level of Containers, you will not be able to upload a nested directory/folder structures into Cloud Files unless a transformation is performed to flatten the structure.
css.php