APIs are a hot topic at RootsTech, and have opened up a whole new world of data sharing in genealogy. In this introductory session, you will learn the basic concepts behind APIs, web services, and mashups, and also gain an understanding of how these can be used in genealogy.
For the regular family historian or genealogy librarian, no programming experience required!
apidays LIVE LONDON - OpenAPI-driven API development lifecycle at Adyen by Al...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
OpenAPI-driven API development lifecycle at Adyen
Aleksei Akimov, Head of APIs at Adyen
API TESTING:Application programming interface (API) testing is a sort of software testing that involves testing APIs both directly and as part of integration testing to verify if they fulfil functionality, reliability, performance, and security expectations. API testing is done at the message layer since APIs lack a graphical user interface. The API is directly related to their functionality, performance, and security.
apidays LIVE LONDON - OpenAPI-driven API development lifecycle at Adyen by Al...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
OpenAPI-driven API development lifecycle at Adyen
Aleksei Akimov, Head of APIs at Adyen
API TESTING:Application programming interface (API) testing is a sort of software testing that involves testing APIs both directly and as part of integration testing to verify if they fulfil functionality, reliability, performance, and security expectations. API testing is done at the message layer since APIs lack a graphical user interface. The API is directly related to their functionality, performance, and security.
apidays LIVE LONDON - Discovering API Version differences with ease by Jaap B...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
Discovering API Version differences with ease
Jaap Brasser, Developer Advocate at Rubrik
POST/CON 2019 Workshop: Design, Develop, and Mock APIs with PostmanPostman
Learn how to collaboratively plan and design APIs to establish a single source of truth for your API lifecycle. This workshop will focus on building Collections to represent APIs from the point of view of both producers and consumers of an API. We will show how you can use API schemas (OpenAPI/RAML/GraphQL) in Postman, manage versions of collections, and document them. We will also deep-dive into Mock Servers, and show how you can use them in your development.
APIs Are Forever - How to Design Long-Lasting APIsLaunchAny
Teams often struggle with balancing the complexity of legacy applications, limited time, and limited resources when designing APIs. The result is often the release of less-than-ideal API design that meets the immediate needs of the client but misses opportunities for longer-term value. This talk explores systems design and domain-driven design (DDD) for API design thinking and how to apply this technique to your design process to create a clear, well-designed, long-lasting API. Presented at API Strategy and Practice 2015
Postman Visualizer lets you render a custom view of the data returned from your APIs. You can turn complex API responses into beautiful, interactive visualizations, right within the Postman app. These can then be easily shared with collaborators via Postman collections.
In this webinar, you will learn how to:
- Import a Visualizer template
- Map your data to a graph or chart
- Create and share Visualizer templates
apidays LIVE Paris - Exploring an API with Blocks by Larry Klugerapidays
apidays LIVE Paris - Responding to the New Normal with APIs for Business, People and Society
December 8, 9 & 10, 2020
Exploring an API with Blocks
Larry Kluger, Lead Developer Advocate at DocuSign
Ultimate Guide to 30+ API Documentation SolutionsBill Doerrfeld
An API is only as good as its docs, so here is the most comprehensive list of documentation solutions for web APIs to date. These tools convert your Swagger, API Blueprint, RAML, WSDL, or other API specifications into static documentation or interactive API explorers that accelerate developer onboarding. This list covers open source software, licensed software, and API references generated within API management solutions. All will help in generating customizable HTML and CSS to display API methods, parameters, values, requests, responses, code samples, and more.
Postman Public Workspaces: The First Massively Multiplayer API Experience | W...Postman
In this webinar Postman’s Kin Lane Nick Tran and Joyce Lin walk you through the basics of the new public workspaces functionality, and discuss the “massively multiplayer” aspect.
API standards, from SOAP to REST to GraphQL, have evolved to meet the needs of API providers and developer consumers. They make APIs "intuitive" by making them predictable. When product designs bump up against the constraints of standards, you can choose to force a fit or, you can break from convention and invest in educating developers about your choices. Through case studies (including Facebook's Open Graph and Slack's workspace apps project), we'll examine the tradeoffs, consequences, and some learnings about how to get your developer community to come along with you.
The slides provide a quick overview of the API Economy trend. The slides provide summary information, a list of trends to watch and links to additional resources
apidays LIVE LONDON - Discovering API Version differences with ease by Jaap B...apidays
apidays LIVE LONDON - The Road to Embedded Finance, Banking and Insurance with APIs
Discovering API Version differences with ease
Jaap Brasser, Developer Advocate at Rubrik
POST/CON 2019 Workshop: Design, Develop, and Mock APIs with PostmanPostman
Learn how to collaboratively plan and design APIs to establish a single source of truth for your API lifecycle. This workshop will focus on building Collections to represent APIs from the point of view of both producers and consumers of an API. We will show how you can use API schemas (OpenAPI/RAML/GraphQL) in Postman, manage versions of collections, and document them. We will also deep-dive into Mock Servers, and show how you can use them in your development.
APIs Are Forever - How to Design Long-Lasting APIsLaunchAny
Teams often struggle with balancing the complexity of legacy applications, limited time, and limited resources when designing APIs. The result is often the release of less-than-ideal API design that meets the immediate needs of the client but misses opportunities for longer-term value. This talk explores systems design and domain-driven design (DDD) for API design thinking and how to apply this technique to your design process to create a clear, well-designed, long-lasting API. Presented at API Strategy and Practice 2015
Postman Visualizer lets you render a custom view of the data returned from your APIs. You can turn complex API responses into beautiful, interactive visualizations, right within the Postman app. These can then be easily shared with collaborators via Postman collections.
In this webinar, you will learn how to:
- Import a Visualizer template
- Map your data to a graph or chart
- Create and share Visualizer templates
apidays LIVE Paris - Exploring an API with Blocks by Larry Klugerapidays
apidays LIVE Paris - Responding to the New Normal with APIs for Business, People and Society
December 8, 9 & 10, 2020
Exploring an API with Blocks
Larry Kluger, Lead Developer Advocate at DocuSign
Ultimate Guide to 30+ API Documentation SolutionsBill Doerrfeld
An API is only as good as its docs, so here is the most comprehensive list of documentation solutions for web APIs to date. These tools convert your Swagger, API Blueprint, RAML, WSDL, or other API specifications into static documentation or interactive API explorers that accelerate developer onboarding. This list covers open source software, licensed software, and API references generated within API management solutions. All will help in generating customizable HTML and CSS to display API methods, parameters, values, requests, responses, code samples, and more.
Postman Public Workspaces: The First Massively Multiplayer API Experience | W...Postman
In this webinar Postman’s Kin Lane Nick Tran and Joyce Lin walk you through the basics of the new public workspaces functionality, and discuss the “massively multiplayer” aspect.
API standards, from SOAP to REST to GraphQL, have evolved to meet the needs of API providers and developer consumers. They make APIs "intuitive" by making them predictable. When product designs bump up against the constraints of standards, you can choose to force a fit or, you can break from convention and invest in educating developers about your choices. Through case studies (including Facebook's Open Graph and Slack's workspace apps project), we'll examine the tradeoffs, consequences, and some learnings about how to get your developer community to come along with you.
The slides provide a quick overview of the API Economy trend. The slides provide summary information, a list of trends to watch and links to additional resources
The 90s were disruptive for traditional business models in the race for a web presence, today, application programming interfaces (APIs) are the new must-have for the companies to their customers and community. What has changed? Social Networks, Social Commerce, Social Content and the extensions of that: Facebook, Twitter, Amazon and eBay, leading us to the generational culture of "simple": User Applications Intelligent and targeted conveyed by Apple, Android, and other Store. Mobile devices are the new appendix and our applications are the currency of exchange….
Application programming interfaces (APIs) function as
the digital glue that connects applications, systems, and
services, and they’re playing a key – and increasingly
important – role in digital transformation. Here are three
things you need to know about APIs. Get the complete guide: http://bit.ly/2a5SAVu
The API Economy is here and it is driving the next generation of digital banking. Learn how the face of banking is changing with rapidly evolving fintech and how API Management is going to make a difference.
Many API programs get launched without a clear understanding as to WHY the API should exist. Rather, many are focused on WHAT the API consists of and HOW it should be targeted, implemented and leveraged. This presentation focuses on establishing the need for a clear WHY proposition behind the decision. The HOW and then WHAT will follow from that.
This presentation also uses the history of the Netflix API to demonstrate the power, utility and importance of knowing WHY you are building an API.
KPIs for APIs (and how API Calls are the new Web Hits, and you may be measuri...John Musser
How do you measure API success? What KPIs do APIs need? What mistakes should I avoid? Find out what you should, and shouldn't, be measuring as part of your API program in this Business of APIs Conference NYC talk. Dive into a breadth of API metrics, the 6 keys to better API metrics, and the traps to beware of (the important do's and don'ts). Also real-world API case studies show who measures what.
Marketing research project conducted for Pizza Hut Pakistan as part of MBA Marketing Research course final project.
Main objective to determine whether to continue deals menu, reduce it or expand it. Secondary Objective was to do a Usage and Attitude Study and a Consumer Satisfaction Survey.
A lecture discussing the use of some popular Web 2.0 tools for online collaboration.
Originally posted as a Google Presentation, hyperlinks lost in conversion:
http://docs.google.com/Presentation?id=dgsbm7jn_35dcmp8rcj
Learning spaces continue to evolve as web tools further erase the physical walls of classrooms, libraries and other educational settings.
This presentation examines the use of LibGuides, a web 2.0 content management and information sharing system from Springshare designed specifically for libraries but being used at Passaic County Community College as a collaborative tool for courses.
This hosted service offers opportunities to create and share reusable content, tagging, widgets, embedded video, RSS, and easy integration with other tools like Delicious and Facebook.
The slides of my speech at App Promotion Summit #APS2014
Can be used as a cookbook to build deep linking!
Video available here: http://www.thinkmobile.fr/blog/deep-linking-at-app-promotion-summit
Atmosphere Conference 2015: The 10 Myths of DevOpsPROIDEA
Speaker: Seth Vargo
Language: English
Although not officially coined until 2009, DevOps ideals have been explicitly discussed since at least 2006. Recently, however, the term "DevOps" has gained increasing popularity across a variety of fields and industries. DevOps is not a development methodology or technology; DevOps is an ideology. It is a way to facilitate organizational prosperity and growth while increasing each individual employee's happiness along the way. As DevOps has gained in prominence, a gap has been created between the original definition of DevOps and this new "enterprise-ready" buzzword.
For organizations beginning DevOps practices, this talk will provide a 10,000ft view of DevOps and how you can properly implement DevOps practices in your organization. For organizations that are currently practicing DevOps, this talk will cover common pitfalls, ways to sustain a happy culture, and new tips to foster organizational prosperity.
Visit our website: http://atmosphere-conference.com/
The modern library web environment consists of multiple content sources and applications that perform essential functions that often overlap and could potentially create a fractured user experience. For example, content in a library’s Drupal website may be replicated in LibGuides or WordPress blogs. Search functionality in a discovery platform may be replicated in a federated search tool or the ILS OPAC. This presentation provides tips, tackles technical and political challenges to building a single web experience for users, discusses solutions and use of APIs (application programming interfaces), provides concrete examples, and more.
Building a Simple Mobile-optimized Web App Using the jQuery Mobile FrameworkSt. Petersburg College
Presented June 8, 2012 (Online) at the 'Access by Touch: Delivering Library Services Through Mobile Technologies' conference sponsored by Amigos Library Services.
Description: By the end of 2012, it is expected that more than 80% of the world’s population will have access to a smartphone. Your library users will assume that your library can be accessible from anywhere, at any time, and on any device. Now is the time to be ready! During this webinar, you will:
- learn what a mobile framework is.
- acquire best practices in mobile Web development.
- understand the various technologies (HTML, CSS, JavaScript) and how they work together to build mobile Web apps.
- recognize the differences between native and web apps.
- have an opportunity to continue to work with Chad after the webinar to demonstrate what you learned.
- gain access after the webinar to a free Web server so you can see your mobile Web app live.
Engaging a Developer Audience: Documentation and MoreAnya Stettler
Sample code and documentation are important when engaging a developer audience, but what are the guidelines? How can you maintain consistent tone across languages, platforms, and levels of developer experience? We'll compare some leading developer documentation sites and discuss strategies for keeping documentation and sample code content consistent, comprehensive, and concise.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
zkStudyClub - Reef: Fast Succinct Non-Interactive Zero-Knowledge Regex ProofsAlex Pruden
This paper presents Reef, a system for generating publicly verifiable succinct non-interactive zero-knowledge proofs that a committed document matches or does not match a regular expression. We describe applications such as proving the strength of passwords, the provenance of email despite redactions, the validity of oblivious DNS queries, and the existence of mutations in DNA. Reef supports the Perl Compatible Regular Expression syntax, including wildcards, alternation, ranges, capture groups, Kleene star, negations, and lookarounds. Reef introduces a new type of automata, Skipping Alternating Finite Automata (SAFA), that skips irrelevant parts of a document when producing proofs without undermining soundness, and instantiates SAFA with a lookup argument. Our experimental evaluation confirms that Reef can generate proofs for documents with 32M characters; the proofs are small and cheap to verify (under a second).
Paper: https://eprint.iacr.org/2023/1886
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
APIs 101: What are they? What do they have to do with genealogy?
1. What are they? What do they have to do
with genealogy?
Colleen Greene, MLIS
RootsTech Conference | Salt Lake City, Utah | February 13, 2015
This work is licensed by Colleen Greene under a CreativeCommons Attribution-NonCommercial 4.0 International License.
www.colleengreene.com
2. Librarian: Systems,Academic,
Newsroom, Public
Web Developer:Wordpress, OU
Campus, Omeka, HTML, CSS,
Javascript, PHP, XML, XSL
Content Strategist: Information
Architecture, Marketing, Public
Relations, SEO, Social Media
Genealogist & Historian
API & Mashups Nerd
@colleengreene
3. Tech-interested non-coders
Code-dabblers (no heavy lifting required)
Programmers & coders who want to learn how to
explain APIs to real people
Those who want to try out API sessions at future
RootsTech conferences
Those who want to learn how real people would like to
be able to use APIs
4. MyWebsite &Tutorials: www.colleengreene.com
Updated syllabus & slides: http://bit.ly/cgreene-
rootstech2015
Practice “Sandbox” Facebook Group (through March):
https://www.facebook.com/groups/apis101.rootstech20
15/
New REAL Facebook Group: New “APIs for Genealogy”
Facebook Group (permanent):
https://www.facebook.com/groups/genealogyapis/
Your IFTTT account
6. How many of you use APIs?
How many are confident you use APIs?
How many aren’t sure if you use APIs?
How often do you use APIs?
A few times a year?
Monthly? A few times a month?
Daily?Throughout the day?
7. Application Programming Interface
Allows systems to talk to each other
Allows systems to open and share data
Allows systems to open & share functionality
Allows 3rd party applications to be built upon a
particular system
9. Web Service: A method of communication between
two electronic devices over a network (Wikipedia)
Mashup: A web page or a web application that uses
content from more than one source to create a single
new service displayed in a single graphical interface
(Wikipedia)
CRUD: In computer programming, create, read, update
and delete (Wikipedia) [think in terms of actions on records]
Protocols: How data is packaged and exchanged
between systems, SOAP+XML vs. REST+JSON [think in
terms of different formats of Gedcom]
10. Breaks down data silos
Real-time*
interoperability
“Easy” data
exchange > sharing
& syncing
Vs. Database
export/import (think
Gedcom)
Everyone doesn’t have to
keep reinventing the
wheel
Fun cool multimedia
mashups
Mobile, mobile, mobile
Apps, apps, apps
*Not necessarily instantaneous; can set limits.
13. NEVER just “set it and forget it”
ALWAYS changing > can break your site or workflow
Can disappear at ANY time
Terms of Use can change at ANY time
Can be limits placed on the number of records or
transactions over time
NEVER make my examples your sole backup solution
(one tool in toolbox)
14. YES, unless want data to remain in silos
YES, if want your data-driven product to remain
relevant in the market
YES, for the same reasons that FREE tools like
Wordpress, Blogger, Facebook, Google Drive, etc. are
worth it
YES, if like me, you like to get your nerd on
16. Facebook social sharing button uses Facebook’sGraph API, which
ensures that that my blog post’s featured image, title, and crafted
excerpt are displayed on Facebook.
17. Custom Google Map
embedded in a post on
my family history blog.
Any changes I make to
the map automatically
get updated on my blog.
Must be a public map.
18. Data entered in Darren Lythgoe’sTNG site dynamically
populates a custom Google Map for each of his ancestors.
Data is not entered via the map itself.
25. IfThis,ThenThat
Runs completely off APIs
Learn and visualize the concepts of APIs, without having
to know how to code
Will provide you with some practical everyday
productivity applications for doing, sharing, and
preserving your genealogy
Sign up for a free account
35. Make your own blog posts part of your research or how-
to notes system, you put a lot of work and time into
those posts!
Ever deleted an old blog, and then wish you hadn’t?
Want to delete an old long-neglected blog, but don’t
want to lose the information in those old posts?
36. It isn’t perfectly
formatted, but it does
the job!
• Adds in extra blank
lines between
paragraphs
• Forces all images to
left-align
View my Evernote file
Each new Blogger post creates a new Evernote note
37. View my Evernote file
Self-hostedWordpress blog
post to new Evernote note
It isn’t perfectly formatted, but
it does the job!
• Note that my blog RSS feed
is displaying theWordpress
Featured Image twice.
• Adds in extra blank lines
between paragraphs
• Forces all images to left-align
38. Surname categories/labels or to surname Groups
Place categories/labels to place-basedGroups
Interest group categories/labels to interest Groups
39. What to notice:
• No blog images
• Different Recipes link in
different manners to the
original blog post
Testing two different Recipes
41. Must be authenticated in IFTTT with Instagram and
Facebook
Please post photos to Instagram using #RootsTech
Group: https://www.facebook.com/groups/apis101.rootstech2015/
42. Must be authenticated in IFTTT with Facebook
Might need to be made a Group admin
Must be authenticated into your Evernote/Dropbox/Drive
Post more #RootsTech Instagram photos or post in the
Facebook Group
Group: https://www.facebook.com/groups/apis101.rootstech2015/
43. Some channels only allow one account to be linked (i.e.,
Facebook,Twitter, Instagram,Wordpress, Blogger)
Not all channels support 2-way exchanges (i.e., can only
post to Evernote)
A recipe can only include 1 trigger, but can set up
sequential recipes (i.e., iOS Photos > Dropbox, Dropbox
> Evernote)
Many recipes do the same thing or with just a slight
variation > test several at a time until you find your
favorite (set up sandbox sites or folders)
45. Interested in a hands-on computer lab next year at
RootsTech, or a hands-on workshop at another
conference?
Interested in a facilitated Q&A session at RootsTech
next year for regular genealogists and the vendor API
developers present, to share your ideas, questions, or
frustrations?
Interested in a series of Google Hangouts?
Give this feedback to RootsTech and FGS, email me , or
share your interests in the new “APIs for Genealogy”
Facebook Group.
47. New “APIs for Genealogy” Facebook Group:
https://www.facebook.com/groups/genealogyapis/
Colleen’s website / blog / tutorials:
www.colleengreene.com
Lynda.com (see syllabus for specific courses)
MOOCs & web tutorials (see syllabus for specific links)
ProgrammableWeb (blogging about all things APIs)
Hinweis der Redaktion
This session idea came out of RootsTech 2014, where I attended Innovators Day and the Developers Track for most of the conference. So many sessions were devoted to the topic of APIs, and these sessions were appropriately identified in the course descriptions with developers as the intended audience and with a ranking of intermediate to advanced technical knowledge. Yet these classes were pretty packed with non-developers who either thought they had more advanced technical skills than they really did (don’t we all?!), or who were simply curious and eager to learn. Sitting in the audience, I kept hearing people asking “What’s an API?”, yet not a single API session explained this. Consequently, I saw people grow frustrated and walk out mid session.
So this session is a primer, an introduction to the concepts of and uses for APIs, particularly in genealogy. For regular genealogists. It is a technical topic, so I do have to use some technical talk. But, I try to keep that to a minimum, and use analogies that should be understandable to the average genealogist.
My intent is for you to be able to gain a general understanding of and appreciation for APIs, and how they impact your genealogy work. And also to give the more adventurous of you some hands-on real life take away use cases that you can apply to your day to day genealogy research, writing, and organization.
First off, I need to point out that I am not a computer programmer. I am a web developer, and a very techie librarian. To many of you, the terms computer programmer and web developer may sound synonymous… but to those who work in my world, there is a big difference. The people at this conference who are teaching the other API sessions ARE programmers. They do much more heavy lifting than I do, including building APIs. I build the web applications that USE and play with APIs. The fun stuff.
So if you are a programmer, particularly a programmer who writes APIs, you are still welcome here. But please don’t ask me any questions about building or modifying APIs; for that I have to refer you to the other API sessions here. However, perhaps you’ll learn how to better “talk APIs” to the average person.
For those who are attending in hopes of learning how to build APIs, I do have some Next Steps resources listed on my syllabus at the end of this slideshow. However, I strongly urge you to attend (this year or next) the more advanced API sessions offered here at RootsTech.
And for those who simply want to learn more, or do some more in-depth hands-on learning and playing, I encourage you to state such on the feedback surveys that RoostTech will send out after the conference, or that’s currently loaded into their mobile app. And to email me with those suggestions. Because that will let us know your interests for future RootsTech workshops and presentations.
My syllabus will get updated after this conference, to include the various links and use cases demonstrated in this session. It has already been updated mid-conference, so if you downloaded or printed it prior to arriving here, I suggest doing so again.
Over the next month, I will also post a series of short video screencast tutorials on my website demonstrating the tools and uses cases presented.
For those of you who want to try out some of the Facebook Group use cases, but don’t want to “clutter up” your real Facebook Groups, I have set up a practice Sandbox group that will remain up through the end of March. Don’t annoy your genealogy society, surname group, or interest group by practicing these things out on a real Facebook Group used by others. That’s what the Sandbox is for. Simply request to join it, I will approve you, and I will bump you up to an Administrator since some of the examples require you to be a Group admin.
And finally, I list a REAL Facebook Group, “APIs for Genealogy”. This is a brand new PERMANENT Facebook Group where anyone can post questions, share examples, suggest tips, etcetera.
Even if you don’t know what an API is, or what specifically it does, chances are you already use APIs almost daily. If you have a smart phone, you use APIs. If you use Facebook, you use APIs. If you sync your genealogy database to something like Ancestry.com or FamilySearch, you use APIs.
Now for the big question… what exactly is an API?
For those who are more visual learners, a very basic diagram of how web APIs work. Yes, there are some non-web APIs, but since web APIs are what most people use (especially those of us doing genealogy), that is our focus in this session.
I promised to use as little technical jargon as possible, but I do have to introduce a few terms that you are likely to hear often in conversations or presentations about APIs. You can find a ton of information online if you care to go into depth more about any of these terms.
Web Service and APIs are often used interchangeably, which is not necessarily accurate. But for our purposes, please excuse me if you do hear me refer to once of these API examples as a web service. Same with mashups. Mashups have a much broader meaning, but in terms of web mashups, we couldn’t have those if it weren’t for APIs.
The only reason I draw our attention to CRUD, is for those who want to dabble further in learning how to build or work in a more technical capacity with APIs. Also to help all of you understand why not all apps or APIs provide the same type of functionality. Some APIs may only allow their data to be retrieved and viewed (for example, like “read only” files). While others may also allow their data to be modified, such as adding new records, editing a record, or deleting a record. Think about some of the FamilySearch mobile or desktop apps you might already use, and how some only allow you to retrieve and view records (instead of adding or modifying a record).
Every discussion here at RootsTech about APIs will most definitely include terms like SOAP and XML, and/or REST and JSON. So I just want you to have a basic understanding of their role in APIs. These are not programming languages. These are more like GEDCOM; formats for HOW data is packaged and exchanged between systems. Your GEDCOM files contain your genealogy data. GEDCOM also comes in different formats. When I export a GEDCOM from my Family Tree Maker database, it is formatted a bit differently than how something like RootsMagic or TNG formats and uses GEDCOM. SOAP+XML and REST+JSON are different standards for containing and exchanging data. These different types of containers do not talk to each other. Therefore each system has to decide on which type of container and exchange method it wants to use.
So WHY are APIs so popular, and why are APIs discussed so much here at RoostTech?
APIs break down data silos. If you recall from the slide defining APIs, I mention that they allow different systems to open up their data, expose it to each other, and exchange that data. Think about how FamilySearch records are now findable when using Ancestry.com.
APIs also allow for “real time” dynamic interoperability. Real time exchanging of data, and reach time sharing of functionality. When using two different systems that talk to each other via APIs, the lag time between these two systems is usually pretty brief (if noticeable at all). HOWEVER, note the asterisk next to “real-time.” Real-time does not always mean instantaneous. Some API providers (the system that is opening up an sharing its data with another system) place limits on how much or how often its data can be used. It requires a lot of resources (servers, bandwidth, staffing, technical expertise, etc.) to make APIs available. So some providers only allow their API to be used (“called”) every so many minutes, or only allow a certain number of calls(i.e., records to be requested or updated) over a set period of time. If you are a Twitter user and remember when Twitter used to experience a lot of Fail Whales, that was due to their APIs getting overwhelmed.
Coinciding with the concept of real-time interoperability, is what appears (at least to us end users) to be a much more easy exchange of data with using APIs. I put the term easy in quotes, because as any API provider (such as FamilySearch, Ancestry, or Facebook) can tell you… building out a scalable and sustainable API model for heavy use is not easy. As mentioned in the previous point, making APIs available requires a lot of resources. But to we normal people, APIs make things EASY to share and to sync data. Prior to things like APIs and data harvesting protocols such as the Open Archives Initiative (a subject for another session!) data had to be exchanged by exporting and importing a database. A big pain. To use an analogy with which most of you are familiar, think about exporting and importing your GEDCOM files. Yes, we still all have to do that sometimes. It’s never pretty, and it often leads to corrupted, missing, or mismatched data. Now think about how you sync your Family Tree Maker with your Ancestry Member Tree, or your RootsMagic with your FamilySearch FamilyTree. Isn’t that a lot less painful?
Another major plus for APIs is that there are now a lot fewer wheels that need reinventing. APIs allow third parties to use the same data (instead of collecting their own silos of data), and to share similar features and functionality. Instead building new apps on top of exiting apps, which extend or enhance functionality instead of competing against each other. Think about the suite of Partner Products that work with FamilySearch. Through FamilySearch’s Partnership program, other apps can simply build out cool new tools that work ON TOP of FamilySearch. A big win for us!
APIs have opened up a world of super cool super fun multimedia mashups, a few examples of which we will demonstrate here. And we could never have the variety of mobile apps (for smartphones and tables) that we do if if weren’t for APIs.
Do any of these logos look familiar to you? How often do you use these services? Guess what, these all either provide or use APIs that you employ daily.
Can you guess which is the most popular API?
According to Programmable Web, at the end of 2014, the most popular APIs of all time were 1) Facebook, 2) Google Maps, and 3) Twitter.
How about these logos? At least some of these should look very familiar to genealogists, and refer to products you probably use daily.
Examples previously mentioned already in this presentation include syncing Family Tree Maker with your Ancestry Member Tree, or syncing RootsMagic with FamilySearch’s FamilyTree.
These APIs do NOT all work together, and some are much more “open” with exposing and providing access to their APIs than others are.
I have to stress the points of caution that need to be taken when working with APIs. We are now (even unknowingly) extremely dependent upon APIs to carry out daily activities. Yet one cannot ever actually DEPEND on APIs.
Why?
APIs can change at any time. The API provider might go under, might decide to change its terms of use, might decide to start charging for its API, or might simply change its API code. When this happens, it can break your website, block your access to data or functionality, and break your workflow.
Months ago, when RootsTech first put out the call for proposals for this 2015 conference, my proposal specified two particular tools to teach, demonstrate, and visualize the concept of APIs: Yahoo Pipes and Google Code Playground. Yahoo and Google are major companies, not some rinky dink start-up in a basement. Yet when it came time for RootsTech to require a syllabus from presenters last November, pretty much all of the API examples I used to depend on in Yahoo Pipes no longer worked, and Google had simply done away with (without any explanation) its Code Playground. I was left high and dry, and panicked. I had to quickly come up with a Plan B, which thankfully still works as of today and is still free as of today.
This scenario doesn’t just happen to free API tools. It can happen when you pay for API access as well. Libraries often face this dilemma. At my job at a university library, I am facing this exact situation with one of our key vendors (Springshare) and two of its products we heavily use: LibGuides and LibAnswers. I will show the LibAnswers example in the demo part of this session. But my library is in the midst of upgrading to the newest version of both products. For two years, since redesigning our library website, our website has made heavy use of these APIs (particularly LibAnswers) throughout the pages of our website that are published through our XML-based content management system. Almost every single page on our library website “calls” and displays LibAnswers API code. Yet when the vendor released this latest (major) version upgrade, they changed how their API interacts with XSL. When I upgrade our LibAnswers product this spring, their API will literally break every single page on our library website that calls their API. Neither I nor my content management system vendor can make the two work together; we have to do this via a very ugly clunky “hack” (iFrames, for those who are web developers… nails on the chalkboard!). So my big task this next month is to work with (read that as “beg and plead”) my LibAnswers vendor to rewrite their API code to play nicely with our content management system. If this were a free API provider, I wouldn’t stand much chance of making that happen. But we pay for their product and their support (plus, Springshare provides phenomenal development support), so I am expecting (read that as “hoping”) they will make every attempt to help us out.
Treat what you do with APIs exactly how you SHOULD treat your own research notes and data (I said should, not what you actually do in practice). NEVER EVER EVER rely upon just one source. We are taught to seek multiple sources to corroborate facts. We SHOULD all backup our saved research files, and back them up to multiple places (there’s sessions here on that!). And you should never build out a website, blog, or workflow that depends solely on an API.
With all of this being said, I have to also stress that you should NEVER rely on a single one of the solutions demonstrated in my use cases to function as your real or SOLE backup. Remember… no SOLE backups. Multiple backups. Each of these use cases we discuss or try out should function as just one of many tools in your genealogy toolbox.
So…. Now that I’ve scared you into being cautious about depending upon APIs, you might be asking if APIs are even worth the risk?
Unless you want to continue using genealogy web services and apps like we used to have to do in the past (logging into a bunch of different sites to view or save records, manually retyping all of our data between services and apps, constantly exporting/importing/cleaning up GEDCOM)….. The answer is YES.
Do you use Facebook? Do you use a free blog tool? Do you use a free email service like Gmail or Yahoo? Do you save your research to free cloud storage apps like Google Drive, Dropbox, or Evernote? Do you save your precious photos on free photo storage and sharing sites like Facebook, Flickr, Picasa, and Instagram? Then you’re already taking the same risk you take when depending upon APIs. And you’re also reaping the same benefits. But hopefully, you do not depend solely on any single one of these services to store, organize, share, and publish your research.
Remember… no responsible genealogist justifies a single source as sufficient evidence to support a fact. Therefore, no responsible genealogist should depend upon a single API, web service, or tool to support your research and work!
Now, enough with the heavy learning. Let’s have some fun!
This is a very basic example of APIs in use, and one that many of you probably already employ on your websites and blogs. Or at least use everyday when visiting other sites on the web. The example on the left points to the social sharing buttons that display on every single post in my family history blog (actually, every single one of my blogs). Each of those buttons “calls” and works with the API for each respective web service: Facebook, Twitter, etc.
I will elaborate on this more explaining how it works with Facebook. On the blog post on the right, note the Facebook button surrounded in a purple box. The blue number displayed next to that button displays the number of times (at the time of this screenshot) that this particular blog post has been shared by someone (anyone) on Facebook --- whether on a personal Profile, on a brand organization Page, or in a Facebook Group. That number will increase each additional time the post is shared on Facebook. The button I have integrated into my Wordpress blog “calls” on Facebook’s API to query and display the number of shares on Facebook. Note that this API tells us ONLY the number of shares; it does not tell us WHO shared the post.
When one clicks on that Facebook button to share my post (the left example), you see the example on the right. This is what the post looks like when shared on Facebook. Some of you probably do this daily, many times a day. When that button is used to share the post, it is again “calling” on Facebook’s API, this time to write to Facebook in a manner that allows that share to get recorded in the count displayed next to the social sharing button on my blog post.
You have all probably done this at some time, whether sharing a blog post, news article, web page, etc. But, think back to the types of links you have shared on Facebook, and how sometimes no nice visual image or thumbnail (or even the wrong thumbnail) shows up when you post a link. Or how sometimes the wrong title or the wrong snippet (description) show up when you share a link. But in my example, the specific image I want from the post, as well as my hand-crafted title and post snippet, all correctly show up when I share the post. That is because these social sharing buttons (as well as a good quality optimized Wordpress theme) work specifically with Facebook’s Graph API (they have many different types of APIs), and the Graph API is what feeds the specific tags on Facebook’s end that populate the featured image, title, and description.
Now keep in mind that each one of those social sharing buttons calls a different API, each time a post is shared on each respective web service. Each “call” is talking to a different server, across a different distance. Each call to a different server slows down the load time on my blog. That is true of ANY type of API service implemented on a website. This is one of many tradeoffs necessary when using an API. The more API-dependent “bells and whistles” you put on your website or blog, the slower your blog will load. Sometimes frustrating and driving away traffic. But that is a topic for another presentation.
Here is another example with which you are probably already very familiar (and may be using on your own sites), but probably didn’t realize utilizes an API. This is a very basic embedded custom Google Map that I have added to one of my family history blog posts to illustrate some of the places associated with that blog post.
I LOVE LOVE LOVE Google Maps. I am a big time map nerd, and can spend HOURS working on maps – exploring maps for places my ancestors are associated with, as well as building and updating my own custom Google Maps to illustrate the same. And I use these heavily in my family history blog, because as you already know, maps are an excellent tool for genealogy. For a single ancestor or family, I often plot out various places associated with their lives: place of birth, place of death, place of marriage, residences, place of work, etc. This is particularly helpful to illustrate a migration pattern, say for example, to illustrate how one of my ancestral families emigrated from Missouri, across the plains, over the high Sierras, and then across the Central Valley, all in a single generation.
If you click on the “Custom Google Map” link, you can see the original native map on Google Maps, where I input the data. If you click on the link to my blog post, you can see that custom map within my blog post. From either spot, if you click on those red markers, a piece of descriptive information (and oftentimes, a relevant image) will be displayed about my family history. On the Google Maps end of that map, anytime I add, edit, or delete a new marker, the change is automatically displayed on the version of that same map that is included in my blog post.
Adding this map is done through a process called embedding. You may already have experience with embedding Google Maps, YouTube videos, Flickr albums, Facebook photos, Tweets, Instagram photos, etc. Embedding allows you to easily (with no coding experience) copy and paste a block of code into a web page or blog post to display the desired item. If that source map, video, photo, etcetera is completely deleted (off YouTube, Facebook, etc.) the version on your web page or blog post will also disappear. The data that is exchanged between the two systems (the map and map points, the video, the photo, etc.) is exchanged via an API provided by that source organization.
Playing with custom Google Maps and its APIs is one of the topics I would love to teach here in a hand-on workshop. So if this is an interest of yours, please note this in the feedback survey sent out after the conference or available now for each session in the mobile app. And send me an email request!
Do you happen to use (or have you seen) Darren Lythgoe’s TNG (The Next Generation of Genealogy Sitebuilding) product? The link on this slide will take you to Darren’s demo site, and he is doing in-person demos in the Exhibit Hall. It is an excellent product, which I have used off and on for years.
One of the coolest features of TNG is its use of the Google Maps API. Like the previous example from my blog, TNG displays custom Google Maps throughout the entire website. Each ancestor gets a dedicated web page. And anytime a location is specified for an event (birth, death, marriage, residence, etc.) that location is added to that ancestor’s map. The screenshot above shows you a few basic events for a single ancestor. Like my blog post example, each event is displayed through a numbered marker. Follow the hyperlink to view this on Darren’s demo TNG website.
Unlike my blog post example, however, this data is not entered from the actual (native) Google Maps interface. The data is entered from within TNG, and then updates things on the Google Maps end. My blog post example simply “reads” (from our earlier CRUD explanation) from the Google Maps API. TNG writes to and modifies the data exchanged with the Google Maps API (the “create”, “update”, and “delete” part of CRUD).
This is a screenshot of a YouTube video embedded into one of my family history blog posts. As just discussed, this is done through that easy copy and paste code, but also through YouTube’s API.
My maternal grandfather was orphaned as an infant and again as a toddler, separated from his older brothers, led a hard life with a foster family who never wanted to adopt him, and spent his adult life knowing nothing about his family or family history. He is the reason I became a genealogist. But unfortunately, not until after he died. So he never got to learn what I have discovered about his ancestors.
This is a blog post about the Buffalo, New York orphanage he and his brothers were placed in after their father died, and were still living in during the 1930 US Census and then when their mom died. The orphanage has been long closed (much of it burned), and is rumored to be slated for demolition. My family and I will NEVER get to walk inside this place, and may not ever get to see it even just from the outside. I am obsessive about finding and collecting photos and memories others have posted about the orphanage.
So you can imagine my joy when I stumbled across these video walk-throughs of the orphanage that someone else posted on YouTube! Which I of course, have to include on my family history blog to share with my family and with anyone else with ancestors from that orphanage. Like the Google Maps embed example, I am able to “read” the video data (including the built-in video player) via the Google Maps API.
But like any third party web service with content provided by and published by someone other than me, I have no control over that data. If YouTube goes under, or if the person who published it to YouTube decides to delete the video, make it private, or turn off the feature that allows others to embed the video, I am lost. I lose this extremely valuable genealogical record. I lose my ability to vicariously walk where my grandfather crawled and learned how to walk. That is the risk and tradeoff for depending upon a a web service and an API.
Unless, of course, I violate someone else’s intellectual property rights (don’t tell Judy Russell!), and use a hack app that allows me to download and archive for safekeeping (I did not say PUBLISH or SHARE) a YouTube video. I am not advocating for or endorsing that course of action. Just pointing out our own helplessness when depending upon APIs. Remember.. I said NEVER depend solely upon an API for your data or workflow.
Just like the YouTube example, this is a photo slideshow that I have embedded into my family history blog, showing photos I found on Flickr of my grandfather’s orphanage. The slideshow player and the data (the photos and attributed metadata) are made available through the Flickr API.
And just like the YouTube scenario, I lose these valuable records if Flickr goes out of business or if the photo owner takes down their account, deletes the photos, makes the photos private, or turns off the feature that allows others to embed the photos. Unlike YouTube, though, photo contributors can opt to allow others to legally download each individual image, and even to legally re-use (publish and share) those images by putting those images into the public domain or assigning a Creative Commons license (I am on Judy Russell’s good side again). If you look at the title slide for this presentation, I have assigned a Creative Commons license to this presentation (as well as my syllabus). I also assign a Creative Commons license to all of my photos that I upload to Flickr.
You can also choose to break the law and force-download images that Flickr account owners do not permit as allow downloads with re-usable licenses. But then you have to content with Judy Russell.
This example is that big horrible nightmare I mentioned earlier that I get to deal with at my work for a good month (and most likely, much longer). This is how I take advantage of the LibAnswers API by integrating it into almost every page on my academic library’s website.
LibAnswers is a web service that allows patrons to submit questions or comments to our library via a dedicated email address, or through an embedded question form. A team made up of librarians and staff from every operational area of the library receive those questions. Each incoming record generates a ticket that allows us to track the issue and the conversation associated with that issue (a paper trail, accountability, and issue statistics). The person in whose area of responsibility the question or comment falls responds to the question or comment.
The system also functions as a searchable knowledge base of Frequently Asked Questions. Our librarians and staff build out FAQs for questions they regularly get at the service desks (research help, circulation questions, etc.) as well as in research instruction sessions. When we see incoming questions or comments happening over and over again, we build out an FAQ for this. Every single public FAQ is categorized under one or more categories (topics), much like blog posts. Google Analytics is integrated in our LibAnswers, allowing us to see which FAQs receive the most visits (hits or traffic). Using the LibAnswers API, I am able to feed these categorized lists of FAQs (ranked in order of popularity via Google Analytics) into every relevant page on our main website. The screenshots above illustrate this. The screenshot on the left is of our live LibAnswers web service (the native interface) for all FAQs pertaining to the category of “Borrowing” (i.e., checking out books, course reserves, interlibrary loan, late fees, etc.). The screenshot on the right shows the top 10 “Borrowing” questions displayed in a bullet list on one of our web pages under the “Related Questions” heading. Just looking at that web page, one might think that someone had manually typed and built that bullet list, as well as the hyperlinks that lead back to the corresponding answer on our native LibAnswers interface. Updating that list as the 10 top questions change over time. But that would be a LOT of work, a HUGE amount of work. It’s how we used to have to do things BEFORE the days of APIs and reusable content. The API system allows me to dynamically “call” that list of top Related Questions, pretty it up in a list, store a single line of code in one spot in our content management system, and then push that list out (updated anytime a rank or a link changes) across ALL related web pages in a task that takes about 5 minutes to set up. That is the beauty of working with APIs!
Of course, as I explained under the Caution discussion, once I upgrade our LibAnswers system to their newest version, this will break on every single one of our library web pages that uses the API code. That is almost ALL of our library web pages. Unless and until the API provider (our LibAnswers vendor) is willing to modify their API code to play nicely with our XSL-based content management system.
By the way, every sizable genealogy archive or library should be using LibAnswers. It is an excellent high quality product, at an amazingly reasonable price, and comes with phenomenal customer and technical support.
We have already talked about FamilySearch’s API program quite a bit by this point. I simply want to exemplify the types of third party apps (approved Partners) that work on top of the FamilySearch API. This is only a sampling; visit that web page to see the ever-expanding list of web-based, desktop, and mobile products.
If you are already experiencing a bit of information overload by this point, I will just quickly refer to RootsMagic as an example. If you use the desktop or mobile version of RootsMagic to view and update records on the Family Tree, you are using the FamilySearch API. When you view their list of partner products, pay attention to the icons that note what type of functionality each individual app provides for interaction with Family Tree. Some just view data (Read), while others allow you to add (Create), Edit (Update), or Delete records – different levels of CRUD interaction.
And one final example of yes, another Google Maps API – just because it is my very favorite API, and one of my very favorite mashups – Historypin.
Historypin is a crowd-sourced (public user-contributed) digital archive. Individual users, as well as museums, archives, and libraries contribute content by “pinning” it to a specific location and time. The “location” part utilizes the Google Maps API. The timeline mashup allows you to view all pinned items in a specific location, over different spans of time. Content can be added or viewed through a web browser, or via mobile apps.
This particular mapped location displays digital objects that have been pinned in and around the area of Brooklyn, New York. Clicking on any object will display information about that object, as well as a larger view of that object. Use the Google Maps controls on the top left to zoom in and out of a location.
Like the TNG example, items are added to, edited on, or deleted from custom Google Maps through the Historypin interface; not through the actual Google Maps interface (like what you saw on my blog post example).
Following are just a handful of sample use cases that can be employed in your daily genealogical work.
To learn about additional use cases, be sure to follow my professional blog at www.colleengreene.com. Our new “APIs for Genealogy” Facebook Group is also a great place to learn about new uses cases, as well as to share some of your own! Starting in March, I will start posting regular short single use case video screencasts as well.
The tool that we are using to demonstrate the concept of APIs, and with which to provide you some real-life takeaway use cases for your own work, is IFTTT, which is an acronym for If This, Then That. Pronounced like “gift” without the “g”. IFTT is a (currently free) web service that is completely run off of APIs. It will allow you to visualize how APIs are called, retrieved, and displayed, without having to try to understand the actual API codes or know any programming.
You must create a free IFTTT account, and be logged in to it, in order to view the various features and functionality discussed here.
IFTTT was launched in 2011, and I use it daily in my research notes and notes organization.
If you’re wanting to get your hands dirty learning and playing with API programming, check out the resources to learn more that I post at the end of these slides.
IFTTT hinges together conditional statements that are called Recipes. This diagram from the IFTTT help documentation helps to visualize and dissect how Recipes work. If Condition #1 (the “this” or Trigger) happens, then it executes something (the “that” or Action).
The building blocks of Recipes are what are called Channels. These icons are a sampling of the 160+ channels currently available on IFTTT, and should look somewhat familiar to you. Each Channel is a specific web service (Gmail, Evernote, Facebook, etc.) that makes its API available through IFTTT.
These Channels are what are know in API jargon as API Providers or API Consumers. Some of these web services (like Facebook) allow Recipe “cooks” to both read and write to its API (remember that CRUD explanation from earlier?). While other web services (like Evernote) only allow one-way communication with its API. Evernote only allows Recipe cooks to write to its API (create Actions within Evernote); it does not allow Recipes to read from its API (take data out of Evernote, and use it another web service).
Use the link provided to access the Channels library on IFTTT, and see all of the different web services available for use. More get added each week.
IFTTT Channels include a variety of mobile web services too.
When you select a Channel, IFTTT will require you to Activate that Channel. After clicking on the Activate button, you will be prompted to log in to your own account on that particular web service (if an account is required, such as for email or Facebook) and authenticate your Channel. Some Channels, such as RSS Feeds, do not require authentication.
To quit using a particular Channel, just Deactivate it.
Once your have activated a Channel, you can start using it in Recipes. Since this example uses both Instagram and Dropbox, IFTTT will want you to activate both of those Channels.
Recipes are stored in Recipe libraries. When logged in, you will see a “Browse” link in the top navigation menu, which will allow you to review and select from public Recipes that other IFTTT cooks have created and chosen to share. The “Browse Recipes” link on this slide takes you to that library.
Every Recipe you add (whether active or not) gets stored in your personal Recipes library. This can be accessed from that same top navigation menu, using the “My Recipes” link.
Recipes can be created on the website, as well as using the mobile apps.
The easiest way to get the hang of using IFTT, and in particular how different Recipes behave, is to start by simply using public Recipes shared by others.
When you follow that “Browse” link on the main menu to access the public Recipes library, you will see a variety of access points for finding public Recipes.
The Search box at the very top will allow you to search for Recipes by Channel name. Try typing in the name of one of the Channels you already activated. In the example above, that would be Instagram. Instagram, as of this date, has almost 11,000 Recipes available! By default, Search results seem to display Recipes by rank – according to the number of times a Recipe has been marked as a favorite. The Search results show a visual icon for each Recipe, the web service logo associated with the IF part and also with the THEN part. In this case, our Recipe is using Instagram to do something to Dropbox. Next to each Recipe icon is the name of the Recipe, the name of the Recipe author, the number of times that Recipe has been added by other IFTTT users, and the number of times it has been marked as a favorite. While viewing the Search results, click on the Recipe icon to access that Recipe.
Going back to browsing that full public Recipe library, note the other access points for finding public Recipes.
Collections are Recipes that serve a particular purpose (type of mobile device, Road Trips, the Beach, etc.). I have asked IFTTT to add a Genealogy collection, or at least the ability to categorize Recipes so that other genealogists can easily find and share Recipes that are useful for doing genealogy.
IFTT features different types of Recipes on the public Recipe library home page. They also display the top Trending Recipes, as well as Recipes broken down into DO action items and IF conditional items.
If you hop back over to the main Channels menu and select a particular Channel, you’ll see that a selection of Popular recipes are displayed on each Channel page.
But what about if you want to create a brand new custom Recipe?
Clicking on that button will take you to the Recipe builder screen.
You will first be prompted for a THIS condition (the Channel from which you want something to happen). This will bring up that now familiar looking Channel menu, from where you need to select the desired THIS Channel.
Next the “Choose a Trigger” screen is displayed. Triggers are the number of different THIS conditions that a particular Channel’s API service allows IFTTT users to utilize. So the number of available Triggers varies from Channel to Channel. Review ALL available Triggers (including the descriptions) to identify the one you want for this particular Recipe.
Once you have selected a Trigger, you are prompted to Complete the Trigger Fields. Trigger Fields are a set of parameters available for that particular IF function. The Fields will display some common language help text. Once all desired Fields are completed, click on the Create Trigger button.
Now it’s time to populate the second part of your new Recipe – the THAT action. Like you did for Choosing a Trigger, select your desired THAT Channel for the Action, review the list of available Actions, and select the desired Action.
Just as you did with the Trigger Fields for the IF part of your new Recipe, fill out the Action Fields for your THAT Action. Default names, content, and paths are usually provided for each Action Field. You can keep the defaults, or if you are comfortable enough, modify them.
I almost always change the File name to something that makes sense when I come back across my personal Recipe in the My Recipes library.
I frequently change the target folder path if I am saving to Dropbox, Google Drive, or Evernote – usually a default folder if I want to go back in and clean it up (like applying Evernote Tags), or a default folder for this purpose (ex: IFTTT) in my Drive or Dropbox.
I RARELY change the actual content Field in an Action, so I highly recommend you leave this alone until you are much more familiar with the various web services parameters available in IFTTT Channels. This Action content Field is where you can see the different parameters associated with that Action’s API. IFTTT utilizes its own syntax however, instead of displaying the raw code.
Click the Create Action button when done. This will display a visual representation of your new Recipe. If it does not visually appear like it will carry out what you want to do, go back and modify it. Otherwise, select Create Recipe to finish designing your new personal Recipe.
Your new personal Recipe will not be displayed at the very top of your My Recipes library. Note how to the bottom right of each Recipe icon, IFTTT tells you when the Recipe was created, when it was last run, and how many times it has been run.
From this view, you can also:
Turn the Recipe off, or back on.
Check the Recipe, if you want to confirm it is correctly working. Although keep in mind that you the initial IF item has to get executed in order for the Recipe to run, and that some APIs might have a little bit of a lag time.
View the Recipe Logs to see each time a Recipe has fired or misfired.
Edit the Recipe if you want to make changes to it. I frequently go back in to apply a more helpful Title or Description.
Now finally… on to our first actual use case!
Since we are in the midst of two concurrent genealogy conferences here, we are starting off with a conference or event use case. When I organize an event (or even just attend an event), I like to follow the Twitter conversations (back channel) that reference that particular event. If you serve on your genealogy society’s conference, seminar, or programs committee, it can be extremely valuable to curate and archive those conversations to use as feedback for planning future events, doing outreach to existing and potential members, networking with other societies and genealogists, and to share with your board or marketing team.
So this use case follows the official hashtag for the FGS 2015 conference “#FGS2015”. Here we will search for and curate all public Tweets (from ANY Twitter user) that reference the #FGS2015 conference hashtag. We will then archive these in a cloud storage service, where we can also share that document with others in our society. Dropbox, Google Drive, and Evernote are some examples of cloud storage sites we can utilize on IFTTT.
If you want to play around with this Recipe yourself, select a Twitter hashtag along the lines of just “#genealogy” if you don’t have a specific one in mind.
I opted to go with Dropbox for this #FGS2015 example. If you click on the public link button, you can view the actual publicly shared file in my Dropbox account. But this screenshot will give you an idea of how this particular Recipe archives those Tweets to a single text file in my Dropbox account.
I set up this test Recipe on February 9th, shortly before the conference began, and I turned it off on February 12th, during the conference. Tweets are displayed with the oldest at the top, newest at the bottom. Each Tweet is separated by a series of dashes.
This screen should help you follow the particulars associated with this test Recipe. Refer back to slides 30 and 31 if you need a refresher on these screens.
At the top is my personal Recipe icon. Note the Twitter and Dropbox logos, as well as the description underneath.
Under the Recipe icon is the Trigger menu, where we are telling Twitter to DO something (IF) a search across Twitter discovers any new Tweet referencing the “#FGS2015” hashtag.
Note the Action menu on the right, and each Action Field.
I replaced the default Recipe title with one that makes more sense to me (for a file name in my Dropbox account).
I did not modify the default syntax in the content field.
I opted to go with the default file path to create a new Dropbox folder for purposes of teaching this session. But if I were doing this for my society, I would point the folder path to my real folder path (something like: FGS/Conferences/2015 Conference/Feedback).
I have included a link for you to view my now public Recipe, that I have shared with the entire IFTTT community in the public Recipes library.
Think about how handy it would be to be able to categorize “genealogy” Recipes. Then other genealogists and genealogical societies could quickly identify useful public Recipes that they could implement for themselves.
Another common use case that I employ daily in my genealogy work is this scenario – using IFTTT to create READABLE archived copies of my blog posts in one (or more) of my cloud storage services.
Why?
Although I run daily SQL backups of my self-hosted Wordpress blog databases, and generate a weekly XML post export of any Wordpress.com or Blogger-hosted blogs, those SQL and XML backups are not readable to the human eye. I can recover my data by exporting it into another blogging platform, but until it’s live in a new platform, those backups and exports don’t do me a lot of good. However, I cannot stress enough how critical it is to regularly backup your websites and blogs… but that is the topic for another class.
What might some of the reasons be for wanting a readable archive of every blog post?
Have you ever deleted a much-neglected stagnant blog, and then later changed your mind? I have! But having kept an archived readable copy of each prior post allowed me to cheat and recreate those posts with the original date and time stamps…. Because, yes, I had even deleted the old XML file of exported Blogger posts since I thought I was done with that blog.
Have you been wanting to delete an old stagnant much-neglected blog, but want to save copies of the posts for your research or reference files? I am in that same boat now, with a quilting blog for which I just don’t have the time or energy anymore to sustain. Yet, I spent a lot of time writing up tutorials and patterns in those posts, so I want to keep those in my patterns files in Evernote. I just don’t want the blog up anymore.
Do you put a lot of analysis and time in to your blog posts? I do! These should be a valuable part of your genealogy research notes! Clipping a readable copy of each family history blog post to my Evernote account allows me to incorporate those posts into my existing research system.
Sometimes when you do a blog export and then import it into another system (i.e., Blogger to Wordpress, or Wordpress.com to self-hosted Wordpress.org), the post formatting isn’t always totally clean. I like having these readable archived copies on hand to refer to when cleaning up post-migration.
If you want to take extra caution, create multiple Recipes to archive each blog post to a separate cloud storage system. I send mine to Evernote as well as Dropbox.
In this example, I am archiving readable copies of Blogger blog posts to my Evernote.
Each time IFTTT detects a new blog post published from my Blogger channel (only ONE Blogger blog can be tied to your Blogger channel) – the IF item – THEN a new Note is created in my Evernote account. I opt to send these to my default Evernote Notebook, instead of specific genealogy-focused Notebooks, because I like to do a little bit of post-Evernote import cleanup on each blog Note.
Note how the Recipe uses my blog post title as the title for the new Note. In the Recipe Actions fields, I tell the recipe to apply the “CJR” Tag, which is the Tag I use in Evernote for anything pertaining to my CJRoots (Colleen & Jeff’s Roots) family history blog. All hyperlinks on the blog post come through in the Evernote copy, as do all images. Oddly, this screenshot is a view of that new Note in my desktop Evernote Mac client, and you can see that the formatting is a little bit wonky in that preview wndow… extra spacing is added, and the images are all left-alighted instead of center-aligned. But if you click on the link to view my actual Evernote file in a web browser, you can see that the import came through nice and clean.
What sort of post-import cleanup do I do this new Note?
Add the appropriate surname, place, or topic Tags that I use in all of my genealogical Notes.
Add internal Note links when appropriate (I maintain a master research log Note for each ancestor or relation).
Create an internal Note link TO this new post Note, from the appropriate ancestor research log Notes (I’m so bad at remembering to LOG my research each day).
File the new blog Note under the appropriate Notebook. I only keep 2 Notebooks for ALL of my family history research: one Notebook for my side, one for my husband’s side.
Please heed my earlier warning at the start of this presentation about NEVER EVER EVER making these workflow solution use cases your ONLY backup source for data. These are just one of many tools you can and should be utilizing to archive and preserve your precious work.
This is a similar example, but from the REAL version of my family history blog – a self-hosted custom Wordpress blog. I only used a Blogger copy as a demo for this presentation.
While IFTTT does have a Wordpress Channel, like the Blogger Channel, only a single Wordpress blog can be attached to the Wordpress Channel. If you only have one Wordpress blog or website, no problem. But, if you’re a chronic over-blogger like me, you will be faced with the dilemma of having multiple Wordpress sites to connect to IFTTT.
The workaround?
Use the Feed Channel to accommodate additional Wordpress or Blogger blogs. Unlike the Wordpress or Blogger Channels, the Feed Channel can handle as many RSS feeds as you want. Instead of copying the RSS feed into the Channel settings, you do this at the Recipe level, adding a new Recipe for each RSS feed you want to use.
Click on my live Evernote file to view the archived blog post in Evernote in your web browser. Again, it’s not perfectly formatted, but it’s readable and useable. For some reason, my Wordpress Featured Image comes through twice… I am troubleshooting this issue. However I’d rather get that image twice that not have it displayed at all. Extra spacing is added between paragraphs, and the images were all left-aligned upon import into Evernote. Not a big deal. Still usable.
Facebook’s API Channel provides a wealth of use cases for genealogical work. I’ve noted some in this slide.
Since we’re already talking blog posts, we’ll stick with blog posts for this example too.
I am a member of (and administrator for) a lot of Facebook Groups. Too many! But, some are quite useful to my genealogy work. Like surname member groups. So I automatically cross-post my surname-related blog posts to the appropriate surname Facebook Group. While I find ALL of my surnames fascinating to read about, I know that my Gann relations are really only interested in my blog posts about the Gann family. Same with my Nieto side of the family. And my Flanagan side of the family.
Both Wordpress and Blogger allow you to generate topic-specific RSS feeds. In Wordpress, these are called Categories. In Blogger, they are Labels. I utilize the appropriate Channel (usually the RSS Feed Channel in my case, since I blog about ALL of my surnames) to send a copy of the appropriate surname posts to the respective surname Facebook Group.
If your society has a membership Facebook Group, or any special interest group Facebook Groups, this would also be a good use case for you.
These screenshots display two examples from two different Recipes. If you recall from my initial discussion introducing IFTTT, Recipes that might (when looking at the Recipe icon) appear to be identical can yield a slightly different Action (or result).
Each Recipe displays just the title and summary of the published blog post, with a link to the full post on the live blog. Yet the left example displays the full RSS feed link at the bottom of the summary. The Recipe output on the right generates a “Continue Reading” link that directs the reader to the full live blog post. And sadly, no images come through on the Facebook Group posts. But if you look at the example on the left, underneath of the RSS feed link, you can see the URL for my blog post’s Featured Image (a photo of a headstone for Walter Scott Gann). I am still working through various Facebook Group Recipes to try to identify one that will post the actual Featured Image, instead of just a link to that image.
Again, harkening back to the notion that Recipes which look similar can generate a slightly different Action… some Facebook Group Recipes require one to be a group administrator, while others simply allow one to be a member. Always read the Recipe description and Action content field closely, and always test. Don’t just assume a Recipe works the way you think it will. I frequently test out a few similar Recipes to find the one I want to keep.
If you were fortunate enough to attend my live presentation, this is the part where we walked through a use case demo on the big screen.
If you’re just now catching the archived version of my presentation, you will have to wait for me to publish my video screencast demos. But I do encourage you to try these demos out on your own.
Even those who attended the live presentation are encouraged to try these demos out on your own… we had too little time to really allow class attendees to play at IFTTT in class, and I had to quickly run us through the demonstrations.
Since this presentation was offered at the RootsTech conference, we had a real-time active RootsTech opportunity to use in this demo. This particular Recipe searched across Instagram for all public images that were tagged with the “#RootsTech” hashtag (the IF condition). It THEN automatically published any new such-tagged Instagram photos to the test Sandbox Facebook Group that I set up for this class.
Now, before you create this Recipe, you will need to activate your Instagram channel and join the class Sandbox Facebook Group.
Why the class Sandbox Facebook Group? So you can play around without cluttering up your REAL Facebook Groups. But if you prefer to play in those and clutter them up, then go for it. This Sandbox group will get deleted after March 31, 2015.
Another good use case for you to try out on your own is archiving all new posts from a Facebook Group to a cloud storage service like Evernote. Again, you are welcome to join and test this out in the class Sandbox Facebook Group if you want.
Why archive Facebook Group posts? Again, for use as research notes. Some of my surname Facebook Groups are pretty active, and share some valuable family history leads. I want to capture all of those in my Evernote research system, file them in the appropriate Notebook, and apply the appropriate Tags.
If your society or special interest group maintains a Facebook Group for members, you might want to archive these conversations in your favorite cloud storage service to preserve the institutional memory, and share that folder or note system with your fellow board members or interest group leaders.
We have touched on and discussed all of these points throughout this presentation. However, they all warrant another reminder.
This presentation was meant to convey the basic concepts of APIs, how they are used by many of your daily web service providers, and to give you a set of hands-on takeaway tools that you might be able to use in your own work.
But, this is just the tip of the iceberg!
There is so much potential for continued incremental learning experiences at upcoming conferences, or even as a hands-on workshop through your society or interest group.
If you want to see more of this topic, especially some hands-on workshops, at next year’s RootsTech or FGS conferences…. tell them! Conference attendees all received an email survey from RootsTech and/or FGS. Use that opportunity. The RootsTech mobile app has a Submit Feedback option built into each session. Find this session in your schedule on the mobile app and provide that feedback. If it’s too late to reply to those surveys, email RootsTech or FGS. Or hit them up on their Facebook or Twitter pages.
The NextGen Genealogy Network hosts educational Google Hangouts, which would be a great venue for sharing 1 or 2 quick next steps or use cases.
Join the new “APIs for Genealogy” Facebook Group to learn about upcoming learning opportunities.
And definitely feel free to email me with your feedback. Knowing your interests or specific questions will help me craft presentation and workshop ideas for future conferences, webinars, or video tutorials. I am happy to answer your questions or entertain your ideas. If I can’t provide you with a specific answer or resource, I will find someone who can.
You can also reach me via the new “APIs for Genealogy” Facebook Group!
But, most of all, it is important that you practice, try things out, and continue to learn!
Join the new permanent “APIs for Genealogy” Facebook Group. This is NOT the same thing as the class Sandbox Facebook Group. This permanent one is a virtual water cooler where anyone can post questions, share tips, showcase examples, etc.
Follow my professional blog for tips and tutorials.
And see the updated syllabus for suggestions on Lynda.com tutorials, as well as online courses and web tutorials.
Thank you for your time!