Test Driven Development (TDD) is a development process based on very short testing and coding iterations where the test code for a block of functionality always precedes any actual implementation. A test should be written to fail before coding any sort of implementation; this follows the Red-Green-Refactor idea. I have been exposed to TDD in the past year or so and actually practiced it a little without knowing it while working on college projects.

The development team I belong to consists of Christian Hargraves (a strong proponent of TDD) and me. As a team we’ve been trying to do TDD and pair programming at least a couple of times a week. Our pattern is for one developer to write the unit test and create any classes or methods required to simply make the code compile and the test fail. At this point, the other developer takes the helm and does the bare minimum to make the test pass. He then writes the next failing test. The result is that the simplest solution is implemented first. This cycle continues until both developers are confident that the functionality will meet all the requirements and that the tests are all passing. This method of development is often referred to as ping pong programming.

Add Comment

The concept and advantages of a paperless office were first introduced in 1975, and since that time, the quest to achieve the pure paperless workplace has been ongoing. Despite advances in technology, many of our business processes still include passing paper from person to person.

Tasks such as purchase requests, hiring provisioning, and order tracking are some examples of paper forms that historically require manual handling. These forms that are passed from person to person risk being misplaced, delayed in the depths of a cluttered desk, or even destroyed accidentally. All too often, these are single-copy instances that are not backed up electronically or stored in a central location where it is easily retrievable. There are many theories as to why we haven’t made the change to be paperless, such as the concept of affordances; it appears that paper will be around for awhile longer.

Add Comment

New Year

2010 is shaping up to be a banner year for the community. We have some exciting things planned, including the first LDSTech Developers Conference. Those who are interested in coming to Church headquarters, learning about development tools, and getting to work on volunteer development projects are invited to attend. Please mark your calendar for April 1 and 2. Registration and more details will be available in February.

Add Comment

Meetinghouse Webcast technology provides an alternative to travel for stake conferences, regional conferences, firesides, and training meetings by allowing local units of the Church to webcast these meetings over the internet to other locations.

Learn more by watching the overview video below:

Additional Resources

• https://tech.lds.org/wiki/index.php/Meetinghouse_Webcast
• http://tech.lds.org/forum/showthread.php?t=2724&page=6
• http://tech.lds.org/forum/showthread.php?t=3414&page=2

Add Comment

Web services have become common place in today’s connected world. Companies like Google, Amazon, eBay, Microsoft, Yahoo, and Twitter expose Web services to allow other developers to build on top of their infrastructure. In the consumer world these Web service APIs have allowed for a variety of fascinating “mash-ups” of data. In the business world, Web services have allowed for greater intra-company and inter-company (Business to Business or B2B) communication. What used to be done through TCP, FTP, and custom file formats can now be done with HTTP and XML.

In the early days of the Internet, a group backed by Microsoft started work on a standard called SOAP, a foundational layer for Web services. In the early days when people talked about building or consuming web services they were inherently talking about SOAP-based web services. Through the years SOAP has continued to evolve. The WS-* family of specifications provides greater support for reliable messaging, transaction control, and security. However, the increased functionality comes with a cost. A common criticism of SOAP is the complexity and overhead that come with it. Supporters have tried to counter these criticisms through better tooling and frameworks to abstract away the underlying complexity.

Add Comment

Although the Church has more than 500 properties, from camps to lodges to ranches, there isn't a single content management system that centralizes all Church property information. Instead, many of the Web sites are independent of one another, inconsistent with each other and often incomplete, and maintained by different groups. When you try to locate a property, it can be hard to see the specific rules, availability, cost, activities, and amenities from one property to the next.

Add Comment