The second annual FamilySearch Developer’s conference was held on Wednesday, March 11 at Brigham Young University. Web and application developers from around the world came together to learn about the FamilySearch Application Program Interfaces (APIs) and to see what other developers are doing.

Conference attendees learned about new and updated FamilySearch Application Program Interface from FamilySearch engineers, and best practices from current community developers. Conference sessions were divided into three tracks: FamilySearch API, Third Party Libraries, and Emerging Models and Technology. The “Emerging” track included presentations about the new Catalog API, Timeline API, Rich Client Frameworks, Persistent Identifiers, and a new model for online citations.

Add Comment

For the last few years, Ruby on Rails has been one of the most talked-about Web application development frameworks. The popularity Rails has enjoyed isn’t without merit—the “coding by convention” idea it helped make popular was beneficial to Web development in many ways.

Coding (or configuration) by convention allows you to concentrate more on what your application is supposed to do rather than how to get it configured properly, which makes development easier and allows you to be more productive. In my own experience, developing an application and getting it into production with Rails was faster than anything I’d used before.

Add Comment

In today’s tough economic times, we have been challenged by Church leaders to do more with less. Doing more with less does not mean that we need to spend longer hours at the office taking quality time away from our families to get the work done. Instead, it means we need to be smarter in how we work. We need to leverage available resources including the skills and abilities of Church members. The implementation of such a project is much more difficult than it sounds.

Before we could engage members on a project, we had to share several tools and refine processes. Our preparation included building a license agreement, creating a wiki, deploying a source version control tool, defining an issue-tracking program, setting up a “sandbox” server and ensuring data protection. Here are some of the specific tools and processes.

In today’s tough economic times, we have been challenged by Church leaders to do more with less. Doing more with less does not mean that we need to spend longer hours at the office taking quality time away from our families to get the work done. Instead, it means we need to be smarter in how we work. We need to leverage available resources including the skills and abilities of Church members. The implementation of such a project is much more difficult than it sounds.

Before we could engage members on a project, we had to share several tools and refine processes. Our preparation included building a license agreement, creating a wiki, deploying a source version control tool, defining an issue-tracking program, setting up a “sandbox” server and ensuring data protection. Here are some of the specific tools and processes.

Individual Contributors' License Agreement

A prerequisite for participation on any Church project is for individuals to review and agree to the Church’s Individual Contributor’s License Agreement. This agreement is meant to protect both the Church and the individual from legal action resulting from source code, artwork, or other contributions. To contribute, follow the steps outlined under the “Requirements for Participation” section on the Wiki home page.

Wiki – https://tech.lds.org/wiki

We use a wiki to collaborate on specifications, design ideas, and functional requirements allowing us to create requirements documents and easily update them in an open forum.

Subversion – (example) https://dev.lds.org/svn/{project}

To access and collaborate on source code, we needed to deploy a source version control tool. There are many products available, but we have chosen Subversion. With Subversion, we can easily track source code changes, create tags for different versions, and create branches of projects. In addition to Subversion, we have built a custom administration module that allows us to create new Subversion repositories and maintain the permissions for various projects.

JIRA – https://tech.lds.org/jira

Once we have the project defined via the wiki, and a place to store source code, we need a tool that allows us to keep track of all of the tasks, bugs, and features of the software. The Church uses JIRA, an issue-tracking program, internally. A new instance was deployed that will allow us to track all of the issues and bugs around the various community projects.

Community Development Server – (example) http://tech.lds.org/{sandbox}

To test our software with the community, we needed to set up a server where we can deploy applications. This server, which we are calling the “sandbox” server, will host development builds and will automatically kick off builds of the projects so that developers and testers can see their work integrated with other people’s work.

Member and Leader Data APIs

It is very difficult to ask the community to help us build applications without providing access to membership or leadership data. However, because of privacy and security concerns, we cannot allow access to real membership data. We have, therefore, created some membership and leader application programming interfaces (APIs) that will access fictional member and leader data but will access real data when an application is deployed within our production environment. We have also created a tool that we call CODA (COmmunity DAta) that will allow the community to type in and create fictional data to help us maintain and update our sample data set.

Maven Repositories – http://dev.lds.org/javarepo/

Many of the projects we sponsor will require the use of the LDS Church Java Stack. The stack can be created using Maven and the Church’s Maven repository. This same stack code is used in many of the Church’s applications. You can read more about the Church’s Java Stack by visiting the LDSTech Wiki Java Stack page and the Stack Site.

We hope to streamline the process of engaging individuals engaged in helping us build more products. This will result in more products being built that will benefit members of the Church worldwide and will also help Church employees do more with less.

Add Comment

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open plan office to facilitate such communication. An open plan office environment makes collaboration much easier. Communication is clear and open between all members of the team. In our agile development environment, it is important that we get things done quickly with a partnership between designers, developers, and QA. Because of our workspace, there aren’t geographic divisions between different groups. Each environment has strengths and weaknesses. I really like this open plan office because it encourages communication, team unity, and the spirit of agile development.

Question

What is your current position at the Church and what are your responsibilities?

Answer

I am a FamilySearch support engineer for third party developers. Software engineers from around the world are connecting to FamilySearch data through our RESTful Web services. I help companies and engineers learn about
our API and integrate their products with our systems.

More specifically, my responsibilities include:

• Giving presentations at conferences and Webinars
• Writing sample code and documentation
• Recruiting developers to the FamilySearch Developer Network
• Networking with key individuals in genealogy industry
• Troubleshooting API bugs
• Maintaining the FamilySearch Developer Network Web site

Add Comment

Read more...

With a chief information security officer and key roles established for policy and training, engineering and operations, risk assessment, and security testing and compliance, we are ready to execute on opportunities, challenges, and expansion that await the Church.

Leadership and Governance

Which is more vital to security in an organization: the right people or the right conceptual-framework? The Trusted Computer System Evaluation Criteria (TCSEC), also known as the Orange Book, on computer security for the Department of Defense was first published in 1983 by a team of top scientists at the National Security Agency (NSA). Its groundbreaking information was considered useful for almost two decades, a singular accomplishment in the realm of technology. While the right people and the right criteria are both important, leadership and the staffing of key roles have been vital to beginning a new age of information security at the Church. While working at NSA, the INFOSEC chief scientist mentioned to me that no matter how great or important any produced criteria were, the criteria would only be sustainable as long as the right people were attracted, retained, and cultivated by the organization. At the Church, we are now beginning to adopt recognized standards and implement a governance framework that increases accountability and improves results. Leadership and governance is the cornerstone of our information security.

Add Comment

LDS Philanthropies operates as a department of the Office of the Presiding Bishopric with the responsibility to correlate, encourage, and facilitate voluntary philanthropic contributions—beyond tithes and fast offerings—to The Church of Jesus Christ of Latter-day Saints and its affiliated organizations and activities. For Church members, LDS Philanthropies provides a way to make charitable gifts to Church institutions and priorities.

Add Comment

FamilySearch announced today its second annual conference for software and Web application developers and its inaugural FamilySearch Software Awards. The 2009 FamilySearch Developers Conference will be held on Wednesday, March 11, 2009, in conjunction with the Brigham Young University Computerized Family History and Genealogy Conference in Provo, Utah. Attendees can register online at familyhistoryconferences.byu.edu/familysearch.

The 2009 FamilySearch Developers Conference provides a unique forum and opportunity for developers of genealogy-related desktop and Web applications to meet with other professionals who use similar development technologies to confront common technical challenges and share effective solutions. Conference attendees will learn about new and updated FamilySearch web services from FamilySearch engineers and best practices from current community developers.

Add Comment

Copiers have long been useful in enabling local units to communicate with and inform members of necessary things, such as programs, lessons, minutes, talks, certificates, phone number and address lists, and roles. All of these would either disappear or become far more time-consuming and expensive if not for today’s copiers and multifunctional devices (MFD).

Since 2005, for the U.S. and Canada, the Church has instituted a copier purchase program. Purchased copiers have been placed in all authorized meetinghouse locations in the United States and Canada. Under the direction of the Presiding Bishopric, this new program replaced the former leasing program, and is administered cooperatively by the Materials Management Department (Purchasing Division), and the Physical Facilities Department (facilities management groups). These groups work with the Headquarters Copier Administration team to set standards, develop guidelines, choose vendors, and negotiate prices. Better and faster copiers or MFDs have been purchased at a much lower cost than would otherwise be possible.

Add Comment

Processes are an important part of every business. A well-defined process can help the security, quality, and cost savings of a product or service rollout. However, some ugly side effects can result from even the best-planned processes. I've identified three general problems that creep up in many processes. I hope that we can come up with innovative solutions to make our processes run smoothly.

Square Peg, Meet Round Hole

One of the biggest problems with many processes is that they take a “one-size-fits-all” approach. For example, if your business is used to handling large projects, and a small one comes along, you may end up spending much more time, money, and effort forcing the small project through the large project process – an ugly side effect. This has happened recently on one of my projects. It took months of effort before we could even start the development. The process effort far surpassed the amount of work the project required.

Add Comment