Adventures in Software

AiS 41: Scrum Doesn't Suck (repost)

Wed, 2 Apr 2008 04:22:00 GMT

Repost due to phantom audio track in previous encoding.

AiS 40: Microsoft Office Developers Conference

Mon, 18 Feb 2008 05:23:00 GMT

Derek, Ricky, and I attended the Office Developers Conference in San Jose, CA. There we competed in the national Infusion Sleepless SharePoint Developer's Competition. After the all-night coding competition, we enjoyed the ODC.

At the Bill Gates keynote, I had the opportunity to ask "What is the next killer app?" The answer was that it is not one app as it has been in the past, but the ability to quickly develop custom applications. I agree completely.

We presented our solution during the ODC, with Rock Band playing in the background. Even though we didn't have all the pieces working perfectly, our story really came together. We presented our solution with confidence, and the judges seemed genuinely impressed.

During the keynotes of the second day, they announced the winners. Apparently the judges were impressed, because team Strongbad took the grand prize! We had the rest of the ODC to celebrate our victory, learn even more about SharePoint, and play some Rock Band.

If I ever have the opportunity to compete in this kind of event again, I'll jump at it. The skills I learned and the people I met will stay with me for a long time. Winning is just icing.

AiS 39: Infusion Sleepless Roadshow

Fri, 1 Feb 2008 06:45:00 GMT

The Infusion Sleepless Roadshow was an intense weekend of SharePoint training and competition. It was a thrill to participate.

I'd like to thank Infusion for presenting the event, and Microsoft for being a fantastic host. In particular, from Infusion:

Sheldon Fernandez
Nadeem Mitha
Devon Jones
Rory Richardson

And from Microsoft:

Zain Naboulsi
Chris Koenig

And special thanks to my teammates:

Derek Sanderson
Ricky Ma

AiS 38: Use Cases

Thu, 24 Jan 2008 06:57:00 GMT

Ivar Jacobson codified Use Case Analysis in 1986 as a way of expressing functional requirements. Since that time, the technique has been improved and formalized. It is now part of the Rational Unified Process.

Why should I write use cases?

Use Cases help the systems analyst or software designer to understand the system under construction.
Help customers understand the system being built. Users can validate that the use cases are correct.
Use cases are an easy to understand and interpret way of communication the functionality of a system to an implementor.

What goes into a use case?

The name of the use case
An identification number that will uniquely identify the use case. This number WILL NOT CHANGE, even if the use case is modified or deleted. This is important for tracking history.
Actor - What actor or actors are going to be the focus of this use case?
Goal - What is the end result of this use case.
Preconditions - What must already be true about the actor or system before this use case is valid.
Triggers - What triggers this use case? A user inserting their ATM card? The predetermined nightly batch processing time? etc.
The Success Path - What happens when everything goes right with this use case. This description should start with the trigger and tell the story of how the state of the target system changes.
Alternate Paths - This section talks about what can go wrong and how the system will respond to those error conditions.
Post Conditions - This describes what state the system will be in once the use case has been executed to completion.
Business Rules - Call out any business rules that apply to this use case. (RE: I'm not sure about this one...I got this from Wikipedia...not sure I like it)

What is the scope of a use case?

How does a use case compare to a story in agile methodologies like Scrum?
Advantages of User Stories
Do I have to choose one or the other?

Should I strive for 100% feature coverage with use cases?

As a developer, if my company doesn't perform use case analysis, can I write use cases on my own?

When you have all of your use cases, what next? (discussion about dynamic behavior running through static strcuture)

Good Links:
Use Case Tutorial -- http://readysetpro.com/whitepapers/usecasetut.html

AiS 37: .NET Generics

Sun, 11 Nov 2007 04:54:00 GMT

.NET generics are useful for more than just containers. They are a powerful mechanism for code reuse.

We've used generic collections. Instead of just a list of objects, we can declare a list of Person. This is good, because the compiler helps us ensure that only Person objects are stored in the list. It also eliminates the unnecessary cast as we extract a Person from the list. And finally, this lets us type a dot after a list method and see the properties of a Person.

But the power of generics goes deeper than that. They let you declaratively compose types in order to create behaviors in relatively few lines of code. Instead of creating a custom class off in another file to perform a specific function, you can put together pieces right where you need them. This composition is declarative, so your intent is captured as concisely as possible. To get started, you need to master the syntax and learn a few basic patterns.

A strategy is a specific procedure for accomplishing a goal. The goal itself is expressed as an interface. The interface separates the consumer of the goal from its various implementations. By replacing the implementation, you can change the behavior of the system.

A policy is more general than a strategy. It is a generic set of rules with room for interpretation. When the strategy is itself generic, then it is a policy; it can be applied to several types.

A strategy or policy is chosen to accomplish its own goal. But a generic algorithm composes smaller snippets of code to accomplish a larger goal. Unlike a strategy, an algorithm has little value on its own. It must be put into context to be truly useful.

One algorithm can be written in terms of another. It can use the encapsulated code and alter its behavior. This lets us declare a new algorithm by composing existing ones, rather than implementing entire new classes.

A factory method wraps the constructor of a generic class so that the compiler can use type inference. When used appropriately, the syntax for expanding generics disappears.

AiS 36: Branching, Tagging, and Promotion

Thu, 16 Aug 2007 02:21:00 GMT

At Handmark, we use Subversion for source code control. Like most systems, it supports concepts like branching and tagging. The mechanics for each system varries, so check your documentation for those details. But a more interesting question is, how do you manage branches and tags? Where do you make your changes? What steps do you take when it's time to release?

There are essentially two schools of thought for branching: for features or for releases. We've chosen to branch for features and merge into the trunk to build a release. But another option would be to make all code changes in the trunk and branch at the point of release. You choose your policy based on where you will accept instability. If you can tolerate an unstable trunk, then branch for releases. If you need to isolate instability in the branches, then branch for features.

We've chosen to branch for features because our priorities change quickly. This strategy allows us to isolate changes away from each other, put them on hold for a time if necessary, and keep the trunk stable. All builds are performed from the trunk, so changes must be merged from their branches to the trunk prior to release.

Once we've build a release, it moves through various staging areas. A build starts in integration, moves to testing, and finally into production. At each point along the way, there are checks in place to ensure that it is ready to move forward. The pipeline is rigid in that no build may pass another on the way to production, and no build can move backward. If a build fails one of the checkpoints, it drops out of the pipeline. If we need to expidite a change to production, the build that's currently in the pipeline is dumped.

We find that this policy works best for our environment. It may or may not apply to yours. Choose the policy that fits your team, discuss it, document it, and stick to it.

AiS 35: Scalable Enterprise Applications

Tue, 7 Aug 2007 12:20:00 GMT

Russell Elledge and I have been conducting interviews at Handmark, looking for help on our Pocket Express and On Demand applications. In this office, we work on the server side, focusing on making these applications robust enough to handle the large numbers of cell phones that are out in the world. So one question that Russell likes to ask our candidates is as follows:

Name five things that you always do in a scalable enterprise application.

This is an open-ended question designed to create discussion and debate, as well as to test the boundaries of their experience. I thought we could all benefit from Russell's experience, so I asked him to answer the question. This is his list:

1. All information must be a transient in memory.
2. All information must be in a universally accessible data store or file system.
3. Use an RPC technology to force the creation of tiers in a system.
4. Use SOA where possible to help force vertical scalability.
5. Control your resources.
6. Author in administrative capability.
7. Seperate OLTP processing from reporting.
8. Optimize

AiS 34: The Interaction Layer

Thu, 26 Jul 2007 06:04:00 GMT

The three-tiered application is a ubiquitous pattern for a solid design. The three tiers are:

* User interface
* Business logic
* Data access

The dependency is straight down. The user interface depends upon the business logic. It feeds events from the user back into the business logic. It does not directly access the data. The business logic layer invokes the data access layer in order to read and write raw data from the database and other sources, like web services.

While this pattern successfully sheids the user interface from the raw data, it does not effectively sheild the user from the implementation.

Alan Cooper's book About Face 2.0: Essentials of User Interaction Design describes the difference between the implementation model and the conceptual model. The conceptual model is how the user thinks about the problem, and the implementation model is how the program solves it. The differences between the two cause confusion on the user's part, and bugs on the program's. The user interface's direct dependency upon the business logic means that the implementation of the business logic becomes visible to the user.

Here's my solution
On several occasions, I have had the need to insert a fourth layer into an application. Between the user interface and the business logic, I have added an interaction layer. In this case, the dependency is not straight down: the interaction layer does not completely hide the business logic from the user interface. Instead, the interaction layer is the entry point into the business layer. It fills in the gaps when the conceptual model differs from the implementation model, but it steps out of the way when the two coincide.

* User interface
* Interaction
* Business logic
* Data access

It is difficult to inject this layer after the fact, so I have resolved to put it in place on every application, whether it seems to need it or not. The application might really be what-you-see-is-what-you-get. But just in case you need to see something slightly different, the hook is in place.

AiS 33: Service Factory

Sat, 14 Jul 2007 04:17:00 GMT

Yesterday I attended a presentation at the Dallas .NET User's Group (ddnug.net). Norm Headlam presented the Microsoft Patterns and Practices Web Service Software Factory (or Service Factory for short). You can download this tool from http://msdn2.microsoft.com/practices. Follow the "Web Service Software Factory" link.

Norm demonstrated how the Service Factory generates a solution with a set of well-organized projects. It generates a service layer, a data contract, a business layer, and a data access layer. Each of these assemblies has one and only one role. The service layer defines the web service. The data contract defines the data types that are exchanged between the client and the server. The business layer contains all of your business rules. And the data access layer interfaces with the database.

No longer will you return a dataset from a web service. These layers are separated according to best practices.

Norm showed how the Service Factory offers ongoing guideance. It doesn't just generate this skeleton and leave you to fill it in. Instead, you right-click on your projects to add data objects, data containers, and service endpoints. As you work, the Service Layer keeps a log of your changes. And it gives you links to your most likely next step.

Web services are no longer generated from your code. Instead, your code is generated from your contracts. You can import a database schema as a data object in the data access layer. Or you can import an XML schema to generate an object in the data contract. This is not like NHibernate, where the data layer is generated at runtime from business objects. This actually does it the right way, where the stored procedures that your DBA authors are honored, and all code is generated at design time.

The only problem I have with Microsoft's Web Service Software Factory is the name. This is not a Software Factory.

According to the book (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools), a software factory is a set of tools that generate several products within a software product line. All products in a product line serve the same vertical domain. They are described using domain specific languages.

"Web services" is not a product line. It is a horizontal slice of software technology, not a vertical problem domain. And these tools, useful as they are, are not a domain specific language. I look forward to using Service Factory on a real project in the near future, but I will also continue to create software factories in the real sense of the term.

AiS 32: Computers Don't Crash

Wed, 4 Jul 2007 03:02:00 GMT

Colorful language is not terribly helpful in a bug report. The best quality assurance professionals document what they were doing, the expected behavior, and the actual behavior. The outstanding quality assurance engineers probe deeper to find patterns. Let me tell you about one such individual: Chris Sachnik.

AiS 31: The Switch

Wed, 27 Jun 2007 02:20:00 GMT

If you're new to the show, then welcome. If not, then you probably know that I am a Java programmer by day, and .NET by night. So it may come as a surprise to you that I have purchased a Mac. I got a 15 inch MacBook Pro. The "entry-level" version with a 2.2 GHz processor, not the 2.4. And certainly not the 17 inch boat that frankly should come with a set of trucks so you can ollie and rail slide your way to work.

If you are not new to the show, then you probably know that I am passionate about quality. I'm on a constant quest for quality in my own software and in the software that I use. I've heard it said that people who love software want to build their own hardware, but I didn't really understand that until I used my new Mac. This thing was built to run quality software.

For one thing, you have the specs. This, like I said, is a 2.2 GHz laptop. It comes with 2 Gig of memory and a 5400 RPM hard drive standard. You can't choose anything less and still have a MacBook Pro. Apple just won't let you. Other manufacturers sell similar specs for the money, but their stuff appears less expensive because you can buy less machine.

For another thing, you have the screen. This 15.4 inch monitor has a 1440x900 resolution. That's the same as the 22 inch panel on my desktop. Do the math ... the not new among you know that I love to do the math ... and you see that this screen is twice as dense! Apple won't let you see a pixely picture. There's a reason that Safari looks bad on Windows ... it was designed for a Mac!

So this is hardware worthy of quality software. It begs for quality software. In fact, if you write crappy software for the Mac, nobody will use it. The Apple community has come to expect a certain level of polish on their apps. Sure, some of them only go skin deep, but at least the effort is visible. I use an open-source instant messenger called Adium, and even this little app has the clean simple look of OS X. It even has a gorgeous little green duck icon that looks great sitting in the dock next to the Garage Band guitar. I'm a Java developer, so I know. You're lucky if we replace the coffee cup. And when I'm writing a Windows app, 16 colors and a copy of Paint is good enough.

But you know that I can't live without my .NET. Having written in C#, I never want to go back to C++. The Mono Project isn't keeping up, so I, of course, installed Boot Camp and Vista on this baby. And let me tell you, it runs Vista like a dream. I can't imagine the heat that the Boot Camp team gets in Cupertino for writing Windows drivers, but they did an excellent job.

Anyway, it's not my intent to become a Mac bigot or to convince you to switch. I just know quality when I see it, and the not new know that I'm all about the user experience.

My name is Michael L Perry, and I run Windows on the Mac.

AiS 30: Web Development Techniques

Wed, 20 Jun 2007 05:51:00 GMT

Charles Martin of Before You Are Gone (http://beforeyouaregone.com) shares some of his time-tested web development techniques. And we even make some up on the spot.

First, consider creating separate servers. You need at least four. Start with a development server where the team can first integrate their code and see if it works. Then deploy to a test server where your QA team can exercise it. Practice your deployment on a staging area separate from the others so that you can be certain that you can upgrade the current production release to the next one. Finally, of course, you have the production environment, far removed from the others.

For the love, don't develop in production!

Second, the separation of style from content is essential to modern web development. Always create a CSS file rather than embedding style within the page. Understand how specificity determines how styles are applied to elements of a document. And to test your CSS file, consider creating a single template page that includes examples of all elements that you use in the entire site. This gives you one place to look to see if your CSS change affects anyone else.

And third, configure your environment to report all Javascript errors. Web browsers are very forgiving by default. They have to be because of all the legacy code that is out there on useful sites today. Since you don't have a compiler to check for errors, you have to rely on the browser to perform that function. Let it tell you about all the errors on your pages, and test each page on all major platforms. Now that we have Safari for Windows, the Mac - and the iPhone - cannot be ignored.

AiS 29: The New Programming Model

Wed, 13 Jun 2007 04:20:00 GMT

Several recent events are converging on a common theme.

Windows Presentation Foundation brings new user interface possibilities to Vista. Silverlight delivers WPF to the browser. Microsoftâs surface computer letâs us interact with the computer on a near-tactile level. Steve Jobs announced that the programming model for the iPhone is Ajax in Safari. Apple ported Safari to Windows. And Google Gears allows you to run a web application while not on the web.

All of these events demonstrate that the new programming model is markup and script. This has been the programming model for Web 2.0, but it is now it is breaking out of the browser.

This programming model has some promise, but there is a dark side. This moves us away from computer science based in proof. The tools that we have chosen to use for the new programming model are usually dynamically typed. With the exception of C# in WPF, the scripting languages that we bolt on to the markup are neither compiled nor statically typed.

Static typing is not just a way to give us intellisense, but it is a way to express intent in the form of a contact. Type checking is one simple way for the compiler to check a contract. But wouldnât it be great if the compiler could do even more for us? Current research languages can prove that null pointers are not derefferenced. And with existing theorem provers, it is feasible to verify preconditions and post conditions at compile time. Despite the apparent evidence to the contrary, the web model is leading away from a path of increased productivity.

In addition, the web model does not support real-time collaboration. The best we can achieve with a request/response protocol like HTTP is rapid refresh. That solution is not scalable, and not feasible for many kinds of highly collaborative applications. And even when it works, the programming model forces developers to be aware of the fact that they are checking for updates. They canât just express the relationships among objects and leave it at that.

I see a new programming model on the horizon after the markup/script wave has passed. In this programming model, the code represents the relationships between objects, not the triggers that cause the next domino to fall in a Rube Goldberg machine made of script. The compiler and the runtime can work together to make inter-related objects behave in a provably consistent way.

Update Controls is the first step along this path. With this library, you express the relationships between your user interface components and your data. You say what is to be displayed; the runtime takes care of when. If the data is changed in one window, the library pushes that change to the others automatically.

The next step is a collaborative object model that pushes those changes across the wire. When that step is ready, data can be changed on one computer, and the effect will automatically appear on another. Best of all, application developers wonât need to code that behavior. They simply express the relationships among objects and the runtime makes it happen.

I hope you will be with me for the next few steps in our evolution. The future is rapidly approaching in which we bring great value to our clients. Itâs closer than you think.

WPF Microsoft Surface iPhone programming model Safari for Windows Google Gears Update Controls

AiS 28: Closure

Wed, 6 Jun 2007 05:01:00 GMT

A recent article in MSDN magazine introduces several new features of C# 3.0. The goal of these changes was to add query capabilities to the language. Lambda expressions were added so that the where clause could be written. Lambda expressions required type inference. Type inference allows for anonymous types. But anonymous types could not be stored without implicitly typed variables.

These features could not be added individually. Each feature brings capabilities to the language that are incomplete without the others. This is an excellent example of closure.

The idea of closure appears often in mathematics. The set of integers, for example, is closed under the operations of addition, subtraction, and multiplication. If you add, subtract, or multiply two integers, the result will be an integer. Introduce the concept of division, however, and the system is no longer closed. Now you need a larger set to express the possible outcomes. You need rational numbers. Introduce exponentiation, and now you need the reals.

In software, closure is often a consideration in language design. But it can also be applied to applications. The set of states that can be represented should be closed under the set of operations that the user can perform. If the user can perform an operation on the system that would put it in an invalid state, then that operation is a design flaw.

Join the panel as we discuss several issues from past experience that were solved or could have been avoided by applying the concept of closure.

http://msdn.microsoft.com/msdnmag/issues/07/06/CSharp30/

AiS 27: Mapping, Scope, and Partial Order

Tue, 29 May 2007 06:26:00 GMT

On the SSG oven software project, Raymond and I used several mathematical truths to prove that the design met the stated requirements. Three of those truths are mapping, scope, and partial order.

A mapping is a function from one set, called the domain, to another set, called the range. The range is not larger than the domain. If the mapping is one-to-one, then a reverse mapping exists and the range is exactly the same size as the domain. A hash is a many-to-one mapping, so the range is smaller than the domain. Therefore, no reverse mapping exists.

A scope is a context in which simpler objects reside. You can abstract the relationships among the enclosed objects as relationships among the scopes in which they live.

A partial order is a transitive relationship between objects in a set. It is not as restrictive as a full order, but allows for some independence. A partial order, because it is transitive, must be acyclic. Replacing a full order with a partial order can relax the constraints on a design, and give you room for optimization.

Your homework is to design an Integrated Circuit designer. Allow the user to build a component out of other components. Prove that your design does not allow the user to create a recursive cycle.

http://www.beforeyouaregone.com/
http://www.clipperz.com/

AiS 26: The Case for Proven Design

Tue, 22 May 2007 06:04:00 GMT

If youâve taken a course in analysis of algorithms, then youâve learned how to prove that an algorithm will have a certain result. Youâve proven that quicksort will terminate, that it will actually sort the list, and that it will complete in n log n time. But in the real world, all of the sorting and searching algorithms are already written. We no longer need to prove algorithms. Now we need to prove designs.

Cycle of discovery
Programmers tend to work in a code-test cycle. Weâll write some code, then weâll see if it does what it should. Then weâll go back and change the code and test again. The cycle continues until the feature is complete. This is a cycle of discovery. This is how we explore new things. This is the scientific process. This is not how other engineering professions work. Sure, it gets the job done, but itâs not the most efficient way to do it.

Agile development techniques put new labels on the cycle of discovery. Now instead of code-test we have red-green-refactor. But itâs still the same cycle. We donât know ahead of time that the code we are about to write is correct. We just keep typing until it works. In this world you donât know how close you are to the finish line until you cross it. How are we ever to estimate our work? Or mitigate risk?

Would you buy a house from someone who says, âletâs just keep nailing boards together until it looks like a buildingâ? Of course not. But most software is more complex than a house. It takes longer to build. It has more moving parts. Itâs more expensive. We should be doing at least as much as a home builder to ensure that we will deliver the right product, at high quality, on time, and on budget.

We can do that by proving our design.

Cycle of proof
In my day-to-day work, I follow a different cycle. Iâll learn the requirements of a feature, design the feature, code it once, and then fix bugs. I donât spin in a tight code-test cycle. Once I know what the design should be, I just sit down and write it all out. Sure, I may have bugs and typos, but they tend to be easy to fix. I may go days between compiles, but in the end I know that it will work. I know because Iâve proven it.

AiS 25: Case Study: SSG

Wed, 9 May 2007 04:55:00 GMT

Raymond and I have been working on a time crunch project for the past week. We take a break from our design work to discuss the project so far. We've been fortunate to work with an experienced team of professionals -- SSG -- who understand how to make a softawre project succeed.

SSG pulled together an exhaustive requirements document. This document is an outline-numbered list of line itens, each one describing one functional aspect of the system. The requirements document gives the team a common set of goals from which to work. It doesn't explain exactly how each of these functional requirements are met. That job is left to the user experience designers.

SSG hired a user experience design team to construct a conceptual model of the system and translate that into a series of wire frame designs. A wire frame shows the visual components that comprise a system, but don't attempt to make those components attactive. For that, SSG has hired user interface designers.

The user interface design team is skilled in graphics design. They provide the artistic talent to make the user experience look good. That leaves Raymond and myself on product development. We are primarily responsible for making the system work.

SSG was seeking a parallel workflow between user interface design and product development. They chose to use Windows Presentation Foundation to separate those two processes. However, Raymond and I decided that the introduction of such a new technology to such an urgent project would add too much complexity. So we advised that we use Update Controls instead.

Fortunately, we may be able to bring WPF back into the project after the demo. It seems entirely reasonable that a XAML document could lay out Update Controls in addition to the more typical components. This should give us the best of both worlds: parallel development tracks and isolation of user interface components.

One other developer is involved in the project. While Raymond and I are creating the user facing parts of the system, an employee of SSG is working on integration with custom hardware. To mitigate risk on this integration, we designed an interface ahead of time. The interface accepts memento objects instead of business objects to further mitigate the risk of changes to the interface. Whereas business objects are likely to change, mementos tend to be more stable.

The design and techonogy decisions that we've made are driven by not only the requirements of the system, but also the structure of the team that is building it, and the time table in which it must be delivered. In future episodes we'll delve into some of the detail of design and implementation, and let you know how the project is progressing.

AiS 24: Refactoring

Wed, 2 May 2007 06:16:00 GMT

Refactoring is the process of changing the structure of code without changing its behavior. Martin Fowler coined the term when he wrote the book on the subject. Not only does the book define refactoring and describe when to use it, but it also provides a catalog of recipes for refactoring code. By iteratively applying these transformations to a system, Fowler says that you can evolve the design of existing code.

I use refactoring in my day-to-day coding, but not in the way that Fowler recommends. I design my software systems up front. I don't expect the design to evolve into a good solution. However, I will often use the automated refactoring built into tools like Eclipse as a way to edit code. The tool is a faster typist than I am, and it won't make a mistake due to a copy/paste fumble.

Refactoring, as most agile development techniques, works best when you have a small team of talented developers working in uncharted territory. Agile techniques move the methodology out of their way and allow them to be talented. However, if you know where you are going, it is much better to draw up a plan to get there.

http://www.refactoring.com/
http://www.eclipse.org/
http://www.jetbrains.com/resharper/

AiS 23: XML Inside Out

Mon, 23 Apr 2007 02:51:00 GMT

XML is not a religion. XML is a tool. A religion tells you what is right and what is wrong. A tool is only concerned with what is useful.

At the 2007 Dallas Code Camp, I presented 4 different XML parsing strategies currently available in .NET. XmlDocument is easy to use and supports input as well as output, but it loads the entire document into memory. XPathDocument is just as easy and slightly faster, but it is read-only. XmlSerializer is the easiest of all since it works with the .NET type system, but it tightly couples your data types with the schema and doesn't support all schemas. And XmlReader is the fastest and most powerful, but incredibly difficult to use.

I added a fifth strategy called DeclarativeXmlParser. This library wraps XmlReader with a dot-chained schema declaration that makes XmlReader dirt simple to use. This library and the demonstration code used in the presentation are available at http://dirtsimplexml.com.

This presentation was inspired by work that I do at Handmark, and data provided by OAG. Additional information was found at Softartisans.

AiS 22: Website Attacks

Wed, 18 Apr 2007 04:25:00 GMT

Cross site scripting and SQL injection attacks both take advantage of vulnerabilities in websites. In the case of a cross site scripting vulnerability, data can be rendered to the browser, causing it to run unintended code. In the case of a SQL injection attack, data is executed by the database as SQL code. In both cases, input that a malicious user provides is interpreted in a way that the designer did not intend.

Both of these vulnerabilities are software defects. In both cases, data in a natural language is rendered as if it were a programming language. Web developers and designers need to take extra precautions to prevent this from happening. But what are the right precautions?

One solution is to validate all inputs to ensure that no script or SQL code is included. Unfortunately, this approach is nearly impossible to implement correctly. Any inconsistencies between the way the validator parses the input and the way the browser or database interprets it can leave a hole for a hacker to slip through. Furthermore, it may be perfectly valid for the data to contain HTML or SQL code. What if you are running a blog about software? Shouldn't you be able to post code to the blog?

A better solution is to escape the data. If you are converting a natural language string into SQL, you have to be sure to escape the quotes. In HTML, you must escape the angle brackets. Several tools are already at your disposal to perform the escaping function. Please take full advantage of them.

http://www.bitlbee.org
http://toc2rta.com
http://jakarta.apache.org/commons/lang
http://jakarta.apache.org/commons/codec
http://www.unixwiz.net/techtips/sql-injection.html

AiS 21: Getting Started

Wed, 11 Apr 2007 03:57:00 GMT

Each member of the panel got started in software because of something inside them. Some of us had a love of mathematics, some of us understood data, and some felt compelled in mysterious ways. Whatever drew us to software, we knew we had to follow.

Having found our calling, we've each taught ourselves the skills that we need day-to-day. We recognized that neither school nor employer is responsible for our training. We cracked books, installed compilers, and searched the web for the information we needed.

This path is a common one. It is still the way that most people find their way into computer programming. Formal training in software is not necessary. Some of the best programmers have been trained in accounting, electrical engineering, music, or mathematics. Many programmers get into software via other jobs, such as data entry, media, or support.

However you get here, it's not about the money. It's about the love.

Shameless plugs:
http://updatecontrols.net
http://d20universe.com
http://orbit1.com
http://beforeyouaregone.com
http://mallardsoft.com
http://mobilescannersofamerica.com
http://yahsaves.org
http://webcudgel.com

AiS 20: Process Alignment

Tue, 3 Apr 2007 04:04:00 GMT

All groups within a project team must be able to communicate in order for the team to succeed. The groups need to speak the same language, and for that they need a common tool set. A tool that one group is comfortable with might not translate into the work of the other group. A business analyst might be comfortable creating a mock-up in VB, but it is not the ideal tool for communicating with web developers. A picture is worth a thousand words. But that's because there are a thousand different interpretations of one picture. If the team shares a common language, that significantly limits the number of possible interpretations. The needs of the project, the culture of the workplace, and the resources available all contribute to the tool selection.

An agile process might be the right choice for your team, but be careful of the underlying assumptions. Agile methods assume that the cost for change remains constant over time (Beck, Kent. Extreme Programming Explained. Addison-Wesley, 2000). It assumes that management can tolerate dramatic changes to architecture later in the project, when the need for that architecture becomes apparent. Agile development requires the highest quality developers, who can recognize when those changes are necessary and make them quickly. If you don't have extremely tolerant management and extremely good programmers, don't use an extreme process.

The process and the architecture should both emerge from the needs of the business. In the case of Handmark, we aggregate content from multiple sources, each of which dictates the technology they use to deliver the content. Therefore, the process includes a New Technology and Content Plan. This document lays out the decisions made while researching the new provider and documents how the system will communicate with them.

The goal of an engineering process is the flow of information among the various individuals and groups on the project team. Each component of a process is an "IPO", input-process-output. In this way, components fit together like pieces of a work flow. With a good process, the team becomes an organism, where information is its life blood. Just like the different parts of the organism rely upon one another for survival, the project team relies upon each of its members to be successful. The right process makes this possible.

AiS 19: Engineering Processes

Tue, 27 Mar 2007 05:07:00 GMT

Carl Honore, author of In Praise of Slowness. Less is More
http://ted.com/tedtalks/tedtalksplayer.cfm?key=c_honore

The goal of any engineering process is to get a group of people on a complex project to work together. But the process should be as simple as possible. The process should never itself become the goal.

The process should facilitate communication. Put gates into the process in those places where information is handed off from one individual or team to another. The process should also promote progress. Give people ownership, responsibility, and the right to say "no". This empowers them and gives them pride in their work.

The key features of the Handmark Server Process are:

Define use cases to extract requirements.
Create an implementation plan to decide what needs to be done to implement the use cases.
Track changes in order to build a deployment plan.
Aggregate the changes to produce a build.
Review the build in operations prior to deployment to ensure that it is re-runnable.

AiS 18: Project Management

Thu, 22 Mar 2007 03:42:00 GMT

Berkun, Scott. The Art of Project Management
http://books.google.com/books?id=q1dJZv4Ycr8C&dq=the%20art%20of%20project%20management&psp=1

Project Management Institute
http://www.pmi.org/info/default.asp

AiS 17: Open Source Software

Tue, 13 Mar 2007 03:46:00 GMT

The panel continues the buy vs. build discussion with relation to open source software.

AiS 16: Buy vs. Build

Wed, 7 Mar 2007 05:59:00 GMT

Should you invest your money in off-the-shelf software, or write it all yourself? The full panel weighs in.

AiS 15: Abstraction

Wed, 28 Feb 2007 05:55:00 GMT

Michael and Raymond introduce Update Controls .NET, then dive into the concept of abstraction. An abstraction hides details so that you can solve problems at a higher level. A good abstraction hides the accidental complexity of the problem space, and reveals only the essential complexity of the solution. Abstraction is a key concept in the construction of Software Factories, which create abstractions within problem domains.

http://updatecontrols.net
http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, ISBN 0-471-20284-3

AiS 14: Lessons Learned

Wed, 21 Feb 2007 05:57:00 GMT

Anecdotes and stories from experience, and the lessons we've learned from them:

Deploy changes to a database and application simultaneously.
Define and stick to your process.
Don't forget your where clause!
Have a successful code review.
Manage dependencies.
Put a stop to scope creep.
Be agile ... but not too agile.
Think it through.
Don't stifle creativity.
Use patterns wisely.
Avoid tight coupling, especially inheritance.
Fear financial applications.

AiS 13: Object-Relational Mapping

Wed, 14 Feb 2007 04:11:00 GMT

The ideas of identity, mementos, and database design come together in a technique known as Object-Relational Mapping (ORM). While ORM frameworks cut initial development time, they do come at a price. Should you invest in a framework, or do it all yourself?

http://www.hibernate.org/
Hybernate, an ORM framework for Java and .NET

Fowler, Martin; David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford (November 2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 0-321-12742-0.

http://warpelican.com/?page_id=8
Big-O notation

AiS 12: Database Normalization

Wed, 7 Feb 2007 07:52:00 GMT

MySQL AB :: An Introduction to Database Normalization
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
A good description of database normalization to third normal form.

AiS 11: Data Transformation

Tue, 30 Jan 2007 03:19:00 GMT

The interview with DBA Chris Simonton continues.

DTS
Data Transformation Services
http://en.wikipedia.org/wiki/Data_Transformation_Services
A tool found in previous versions of Microsoft SQL Server to extract, transform, and load data. Since replaced by SQL Server Integration Services.

E. F. Codd
http://en.wikipedia.org/wiki/E.F._Codd
Mathematician who invented the theory of relational databases.

AiS 10: Database Administration

Tue, 23 Jan 2007 07:59:00 GMT

An interview with Chris Simonton, Database Administrator at Handmark. Strategies for database normalization, separation, and replication.

AiS 9: Advanced Unit Testing Techniques

Tue, 16 Jan 2007 03:09:00 GMT

Object Oriented Software Construction
http://archive.eiffel.com/doc/oosc/
A defnition and study of Contract-Based Programming.

Continuous Integration
http://en.wikipedia.org/wiki/Continuous_integration
The process of using automated nightly builds to discover integration problems early.

Hanselminutes
http://hanselminutes.com/
Scott Hanselman and Carl Franklin talk about all aspects of programming.

Depedency Injection
http://en.wikipedia.org/wiki/Dependency_injection
A pattern for depending upon abstractions rather than concrete classes.

Flow Analysis
http://en.wikipedia.org/wiki/Flow_analysis
A technique used in compiled languages to analyze the flow of logic through the source code.

NMock2
http://sourceforge.net/projects/nmock/
A mock-object framework for .NET. Creates test harnesses that let you set and validate expectations.

EasyMock
http://www.easymock.org/
A mock-object framework for Java. Scott Hanselman called this a "TiVo" for unit tests. Record your expectations, then replay them within the unit test. EasyMock works with intellisense, whereas many other frameworks do not.

Team System
http://msdn.microsoft.com/vstudio/teamsystem/
Microsoft's all-encompasing development engine. It includes source control, defect tracking, project management, and testing, among other features. Its unit testing framework is relatively poor when compared to NUnit, but it integrates into the build system.

ISerializable - MbUnit vs. NUnit vs. Team System
http://weblogs.asp.net/rosherove/archive/2006/09/24/MbUnit-vs.-NUnit-Vs.-Team-System-Unit-Testing-_2D00_-Choosing-a-unit-test-framework.aspx
A comparison of unit test frameworks for .NET.

AiS 8: Unit Testing

Wed, 10 Jan 2007 06:24:00 GMT

.NET Rocks!
http://dotnetrocks.com/
Weekly podcast with Carl Franklin and Richard Campbell.

DNR TV
http://dnrtv.com/
Video companion to .NET Rocks!

JUnit
http://www.junit.org/
The most popular unit testing framework for Java.
"Never in the field of software development was so much owed by so many to so few lines of code" Martin Fowler

NUnit
http://www.nunit.org/
Originally a port of JUnit to .NET, NUnit now takes full advantage of the platform, including attributes.

AiS 7: Techniques for Quality Improvement

Wed, 3 Jan 2007 05:33:00 GMT

User interaction design
Unit testing
Automated testing
Code generation
Contract-based design
Use-case analysis
Litterate programming

Episode 6: Datacenter Separation

Tue, 26 Dec 2006 03:52:00 GMT

Advice for keeping development and production servers separate.

Episode 5: Web Services

Tue, 19 Dec 2006 06:57:00 GMT

Lessons Learned about Web Services:

Lesson #1 - Don't put example code from books into production code.
Lesson #2 - Don't reinvent the wheel.
Lesson #3 - Don't jump on the early technology that is not fully proven.
Lesson #4 - Don't expect interoperability between programming platforms or libraries right out of the box (or in version 1.0).

Episode 4: Identity-Based Patterns

Tue, 12 Dec 2006 06:25:00 GMT

Java Enums:
http://www.javaworld.com/javaworld/jw-07-1997/jw-07-enumerated.html
http://www.javaworld.com/javaworld/javatips/jw-javatip122.html
http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Command:
http://en.wikipedia.org/wiki/Command_pattern

Easy Mock (Java only)
http://www.easymock.org/

NMock
http://nmock.org/

.Net port of Easy Mock
http://www.easymock.net/

Action command object:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/Action.html

Strategy:
http://en.wikipedia.org/wiki/Strategy_pattern

State:
http://en.wikipedia.org/wiki/State_pattern

Lex
http://en.wikipedia.org/wiki/Lex_programming_tool

Microsoft Windows Workflow Foundation
http://msdn.microsoft.com/workflow

AiS 3: Identity

Tue, 5 Dec 2006 05:44:00 GMT

Michael, Raymond, and Charles discuss the fundamental law of object -oriented programming: identity.

James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen: Object-Oriented Modeling and Design, Prentice Hall, ISBN 0-13-629841-9

http://en.wikipedia.org/wiki/Identity_%28object-oriented_programming%29

AiS 2: Design Patterns

Tue, 28 Nov 2006 06:22:00 GMT

Charles Martin. http://webcudgel.com
Raymond Jensen. http://jensensoftware.com

Erich Gamma, et al. Design Patterns. a.k.a. Gang of Four: http://en.wikipedia.org/wiki/Design_Patterns
Martin Fowler. Patterns of Enterprise Application Architecture: http://en.wikipedia.org/wiki/Martin_Fowler
Stelting and Maassen. Applied Java Patterns.
Steven John Metsker. Design Patterns in C#.
Ron Jacobs. ARCast. Patterns and Anti-Patterns for SOA. http://arcast.net
http://www.codeproject.com/
Microsoft Patterns and Practices. http://msdn.microsoft.com/practices/
http://www.patternshare.org/

AiS 1: User Interface Design

Tue, 21 Nov 2006 06:21:00 GMT

Michael talks with special guest Charles Martin, web designer at http://www.webcudgel.com. We discuss user interaction design as described in Alan Cooper's About Face 2.0: The essentials of interaction design. We talk about a poor user interface that we both worked on in the past, as well as a good one in the Hamachi VPN. We round out the conversation with a comparison of Windows vs. Mac.