I’d like to talk to you today about the Future of APIs - our future.
Most people, many of them here today, are quite optimistic about the future of APIs. And, I must admit, I, too, think we have an incredible opportunity before us; that the future offers amazing potential.
Who knows, maybe I’ll finally get that jetpack that I was promised as a young member of the "Rocket Age!"
However, my optimism is tempered by frustration and disappointment. Why?
Because I am concerned that some of us are ignoring not just the lessons of the past, but also the likely mistakes of the future. I’m worried that we’re missing opportunities before us today that will help us mold and shape our shared tomorrows.
I think we are too focused on the here-and-now and that we are too willing to lower our gaze from the far horizon and to look instead at the gifts around our feet. Forgetting that the technological gifts we have today are here due to the forward-thinking, risk-taking, and experimentation of those who came before us.
I fear that we sometines forget that we are not actually as tall as we think we are. That, in fact, our expansive view is the result of our standing on the shoulders of the giants who came before us.
In short, I think we’re squandering our future.
So I want to talk about that future. Now.
In hopes of encouraging us to look up, look ahead, and start to create that future today. And, in order to do that, I want to reach back into the past. Because I think the past can inform us, remind us, and help us to craft a better tomorrow.
There’s a well-known quote on this topic.
Santayana penned this quote as part of his five volume "Life of Reason" series which he wrote during his tenure at Harvard University. Among his students were T. S. Eliot, Robert Frost, Gertrude Stein, and W. E. B. Du Bois.
This quote also appears at site of the Auschwitz Concentration Camp from WW II. It’s a powerful perspective on the past.
But I’m here to talk about the future. And it’s why I prefer this quote instead:
Think about that for a moment. What mistakes are the future are we ignoring? This is the question I put to you today. This is the challenge. Because when we can recognize future mistakes, we can avoid them. We can, as it were, "jump ahead" or "advance an extra grade" in the school of life.
So, here we are the dawn of a new century. One with all sorts of new technological and social challenges ahead of us. And I’d like to encourage all of us to make Miller’s warning out watchword. It’s my hope that it is his challenge that will shape the generations of creative thinkers, inventors, and entrprenouers of the 21st century.
Ok, let’s start our journey on the road to recognizing future mistakes. And let’s do it by, oddly enough, looking back into the past. Back more than 100 years ago - to the late 1800s - when the world was undergoing an incredible transformation.
near the close of the last century was Alexander Graham Bell’s telephone was transforming the world. While there were a number of other people working on similar projects, it is Bell that the history books remember and credit with most of the success. At first the telephone seen as a marvel, but only a novelty of teh age.
At first, it’s utility was thought to be limited to a small segment of society; government officials and the rich.
However, in relatively short order, the telephone quickly became a powerful tool in the arsenal of newspaper reporters who saw it’s potential to change the speed of information around the globe. Instead of threatening the future of print media, the telephone was seen as a way to improve the quality and accuracy of information in the newspaper. Technically this started with the advent of the telegraph some thirty years before, but the intamcy and immediacy of the telephone greatly sped up the process.
It took some time, but soon another population found the telephone invaluable: business. Telephones expanded the reach of markets, decreased the need for expensive travel, and increased the speed at which information flowed (including information used to buy and sell perishable goods).
And eventually, individuals started installing telephones in their own homes. Telephones made it possible for families to begin to move farther apart and still seem close, increased opportunities for social connection, and spreading information throughout local communities.
The telephone had arrived. In fact, early figures show that telephone adoption rates were incredible. Installs went from 50k in 1900 to almost 6M in 1910. Ten years!
And with this explosion of communications came an entirely new concept: The Communication Network.
The idea of a "network" was not entirely new. In the early 1800s we built the Train Network. In the mid-1800s we created the Telegraph Network. But the Telephone Network of the early 20th century was orders of magnitude more distruptive and influential.
Telephones offered the promise of "instant communication" and invoked in people’s imagination a network that was, for all intents and purposes alive.
This nervous system - this network of telephones - represented a major technological advance. But it also represented a problem; one that occurred many times through the history of innovation. All the advancement, all this achievement depended not on sleek machinery, but on overworked humans.
Brief side note: The first telephone operators where young boys, not women. These boys had come from the ranks of telegraph offices but, it turned out they were seen as unreliable and troublesome.
In fact, it was in my home city of Cincinnati, OH that W. H. Eckert the head of the local telephone company fired all the boys and hired over sixty women to staff the switchboards.
So, it turns out that the marvel of the age was powered by humans dashing about plugging lines together by hand. Each connection between two parties required human intervention. This reliance on humans was just assumed in the beginning. In fact, it was considered an essential feature of the network; a kind of safety valve. A governor on machines.
This was so much a part of the thinking on how machine worked that even in the early 1950s and 60s, as computer networks began to develop, this dependence on humans was considered so important as to be acknolwedged in the very name of these early systems.
The first network of military RADAR computers was created in the 1950s and was known as the SAGE Network. SAGE stood for Semi-Automatic Ground Environment.
In the early 1960s, the first widely deployed computer network for business was The Semi-Automatic Business Research Environment. You might recognize it by the word SABRE.
Why was it so important in the early days to label them "Semi-Automatic"? And what was it about this historic dependence networks have on human intervention that is important for us to consider when we think about the future of APIs?
To continue, I need to tell you the other story I wanted to be sure to cover today. This one reaches back even farther into the past. All the way back to the last half of the 18th Century - 1770 to be more exact. Near the end of the Age of Enlightenment. To the House of Hapsburg in Austria and the court of Maria Theresa.
Due to a series of military and family cirsumatancdes, Maria Theresa was Austria’s monarch at a time when it was deemed unacceptable for women to rule. Technically, she shared the throne w/ her husband Francis the I and, after this death in 1765, with her son until her death in 1780. But, in truth, it was Maria Theresa who was the power behind the House of Hapsburg for close to 40 years.
By the way, you may not recognize the name of Maria Theresa of Austria, but I bet you would recognise her youngest daughter named Maria Antonia. After she married her French suitor, she changed her name to Marie-Antoinette. Now, Marie-Antoinette is famous for several things.
One of the more famous is the attribution of the meme "Let them eat cake." although it turns out unlikely she ever actually said that, the meme has stuck over the centuries.
Anyway, Marie Theresa entertained many skilled inventors and illusionists in her court at Schönbrunn Palace. At one of these events a rather prodigous inventor, Wolfgang von Kempelen, was in attendance. As he watched a magician name Francois Pelletier perform his tricks (most of which involved the use of magnets), he was somewhat appalled at the guillibility of those in the audience and he quickly and easily debunked Pelletier’s tricks.
This amateurish display prompted him to announce to her Highness and all in attendance that, in no more than six months time, he would return with a truely remarkable illusion. One that would baffle anyone who attempted to explain it. His illusion, he claimed, would be truely magical.
Now, Von Kempelen had a reputation as a skilled thinker, engineer, and inventor. He spoke several languages, designed bridges, bulidings, steam-engines, even an early form of a typewriter. His boast was not taken lightly and all waited for his return six months hence to see what he would come up with.
What he brought with him upon his return was a huge contraption he called the "Chess-Playing Automaton." He told her Majesty that it was a machine that would play chess and always win. It was an incredibly elaborate and ornate with a life-sized maniquine dressed in Turkish garb, holding a long smoking pipe in one hand and manipulating a full-zsized chessboard with the other.
 There were three compartments, each opening up to reveal part of the apparatus.
It should be noted that the use of Turksih garb for the manequine was a cheeky move. Von Kempelen was well-aware that the Hapsburgs had a long history of war with the Ottoman Empire and that Austrians continued to despise the Turks as a people. Von Kempeleon was a master showman.
All accounts of the event at Schönbrunn Palace indicate Von Kempelen’s illusion was a hit. The machine won every chess match it played with anyone who wished to challenge it - usually within 30 minutes. Those in attendance were astonished and her Highness was most impressed. After this single performance, Von Kempelen dismantled the machine and put it into storage, resisting requests for additional appearances of this "Mechanical Turk" as it was then called.
However, in 1781 - ten years after he unvieled his illusion, Maria Theresa’s eldest son, Emperor Joseph II, ordered Von Kempelen to re-assemble the Turk and, after a special performance in Vienna, to embark on a tour of Europe.
His tour took him to Paris, where - along with a number of well-know chess masters - the machine was pitted against the Grand Duke of Russia, The Duke of Bouillon, even Benjamin Franklin played a round while Franklin was in Paris as US Ambassador to France. From Paris, the machine went on to London, Liepzig, Dresden, and Amsterdam. Eventually, Von Kempelen was able to return home after more than ten years of touring. He, again, placed the machine into storage and there it stayed until his death in 1804.
Throughout the thirty years of the machine’s display no-one could figure out how it worked. At every opportunity "experts" were invited to attend and inspect the device during performances. Von Kempelen invited them to bring magnets, lodestones, any other items they wished in order to test his machine. On one occasion a "spiritualist" came to view the machine and aftger only a few minutes she left the room in horror saying that it was a vessel for ghosts and demons.
As we now know, the Turk was operated by a chess-playing human hidden inside the cabinet. Von Kempelen used common misdirection in the construction of the box to make it appear it was full of gears when, in fact, the gears where only a thin facade that hid the open compartment with a small chair, a viewport, and levers with which to operate the manequin.
The "ghost in the machine" was a human all along. And the ghost would continue to haunt the machine.
After Von Kempelen’s death, an enhanced version of the machine - one that included the ability to yell our "Check" whenever the machine had cornered the opponent’s King - continued traveling, with various owners, for the another 50 years. Along the way it spent a great deal of time in the United States and attracted the attention of Edgar Allen Poe, who published an article about the device in 1836.
By the mid-1800s several aticles and even books about the Mechanical Turk were published. There was one that focused, not just on the machine, but on it’s inventor Von Kempelen. And one of his more interesting inventions was a "speaking machine." A device Von Kempelen completed not long before his death in 1804.
This machine had a keyboard in which produced audible speech through a series of bellows. While crude in 1804, a greatly improved version was reconstructed by Sir Charles Wheatstone in 1837. Wheatstone was another prodigious inventor. He perfected the English concertina, an early form of the microphone, and was even involved in the creation of telegraph machines in the mid 1800s.
It so happens that one of the people avidly following Wheatstone’s work and writings was a young inventor by the name of Alexander Graham Bell.
And that brings us back to where we began…
One of the things Alexander Graham Bell insisted upon when he created his telephone is that the devices NOT be sold in pairs. This was a problem for a number of his early backers. It made no sense to them to sell a customer a single telephone. They thought "No one will buy a single telephone. They won’t have anyone to talk with!" Of course, this turned out to be another stroke of genius from Bell. If they were sold in pairs, each time a customer wanted to call someone else, they’d need another telephone!
Now, to us, having a telephone on your desk at work for every person you want to call seems silly, right? But, in fact, this "selling in pairs" is the exact model we use for Web Services.
Each time we create a service (publisher), we create an API (consumer) and each time we want someone to use our service, we get them to add another `telephone to thier desktop. Pretty soon our desktop looks like this:
Well, actually, our desktop looks like this, right?
And that is a problem we need to fix.
It’s important to remember that we solved this problem for documents back in the late 90s.
And we have improved that one receiver over the last fifteen years…
But that’s old news. We’re not in the Age of documents anymore and this receiver is coming up short. We need a new one that works in the same general way with all the services out there, not just one, and not just the ones we know about today. It needs to work with services that haven’t even been invented yet.
But we don’t have this yet. Instead, every time we want to add a new service, we need humans to build us a dedicated client app and we need to install that app. In fact, it’s worse than that. Once we install the dedicated app, we have to keep installing it over and over again. Each time a new feature is added to the service we need a new version app. It’s as if we had a telephone on our desk at work and then, when a new feature was added, we needed to update the phone dial.
Do this enough times and the phone gets to be really hard to deal with.
But we do that all the time today, right? We keep installing the same app multiple times - whenever the service tells us to - all in hopes that finally it will have all the features we need.
Because, right now we need human intervention to make all this API stuff work. The API Economy is a gigantic Mechanical Turk.
Think about it. Each time someone wants to set up a new "conversation" between a service and a client app, they need to get an "operator" to make the connection for them.
And each time the service changes that means we need to start a new "conversation" and we need to do it all over again. This is crazy and it has to stop.
One of the things we learned from Von Kempelen and his chess-playing Turk illusion is that people love the mystery. They want to believe in the magic. And we certainly have lots of "magic" around us.
But it’s important that we not get caught up in the illusion. That we remember that, for now at least, quite a bit of our API Economy remains dependent on the direct laobr of thousands of unseen individuals; people "underneath the tabletop" working the levers for us in order that we can enjoy the magic.
These are the "ghosts in the machine" - the labor that makes it all possible. And there are limits to this illusion. Like Von Kempelen’s Turk, we are, sooner or later, bound to be shown up for the charlatan’s that we are. If we want to move the API Economy to a point where it is truely scalable and sustainable, we must rid ourselves of this belief in ghosts and magic.
The telephone network was able to achieve this. As early as 1920, Panel Switches began to appear. They were mechanical; they threw latches to complete connections.
In the early 1960s electronic switches appeared using wire relays to complete the connections.
And it was in the 1970s that we start to see fully digital switching gear for telephone connections.
Now, that’s close to 100 years between the invention of the phone and fully digital switching. But it’s less than fifty years after the telephone is invented before the first automated switches are widespread. That’s just over two generations.
For another example, the first Robotic Arm was patented in 1954 by Devol and Engleberger. Within five years this robot (called the UNIMATE) was installed at a General Motors assembly plant in New Jersey.
Ford’s first moving assembly line appeared in 1913.
Again, that’s about two generations between the the Turk-style work and automation. Two generations.
Now let’s look at our world - the World Wide Web.
in 1993 The Organization for Nuclear Research (also known as CERN) announced that the World Wide Web - as designed by Tim Berners-Lee - was free for all to use. Twenty years ago this year. That’s one generation - in human terms.
But there are some who think that a "generation" should be computed differently in this digital age. Estimates of the "generation rate" of the Internet to be between five and seven years. IOW, one "human" year is equal to five "Internet year." At that rate, we’re now wrapping up our fourth generation. Four generations and we’re still dependent on the same assembly lines, manual labor, and switchboard operators we relied upon at the very start. That’s a bummer.
But maybe the estimates don’t mean much here. Maybe we should stick to using the same measure as all the others. In that case, we’re only one more generation away from truly automating the Web and scaling the API Economy past the limits of human labor. Does that sound right? Do we need to wait another twenty years before we break free of manually editing each API every time it changes?
I hope not. I’d hate to think of the kind of world where we have tens of thousands mechanical turks operating behind the scenes all over the world propping up our API Economy. What would that be like?
The author H.G. Wells had a pretty strong opinion of what our future would look like if we forced not just the ghosts, but the machines themselves into an underground paraellel existence.
As stark as his vision was, it showed a clear understanding of the possible dangers of ignoring the ghosts in the machine. While I don’t think we’re heading for this kind of dystopia, I do think some of us continue ignore the humans that power our lives today. And I worry that we’re not always doing as much as we can to elminate the ghosts.
So what can we do? What tangible work is before us that allows us to pay heed both Santayana and Miller?
First, we need to internalize the lessons from UNIMATE.
UNIMATE worked well because it did one thing and one thing well - it handled large metal castsing and welded them to vehicle chassis. It didn’t polay chess or speak. It did an important job that relieved humans of dangerous work.
UNIMATE embodied a principle that became central to the Unix operating system 15 years later.
We need to create services that do one thing and do it well." We need to stop tyring to create crazy telephones.
We need to stop releasing services "in pairs." and to do that, we need to pay attenion to the second-half of McIlroy’s 1978 quote:
We need to stop trying to stuff more humans inside Mechancial Turks.
Instead, we need to create services that work via automated switching.
We need to stop pretending every service is on an island.
We need to start thinking and acting like we’re all in the same boat together.
We need to design and implement services that, from day one, inter-operate. We need to create modular, plug-able, composable services and enable client applications to use these components as they wish.
And again, I have to say that the hardware world is ahead of this again. A company called PhoneBloks has released a design idea where the smart phone is fully customizable via a set of inter-operating parts.
Users can assemble and re-arrange the parts to optimize the smart phone for their needs. Upgrade the camera, less storage for more battery life, etc. This is do-able today.
And we can do it, too. In fact, since we work in software (not hardware) we could do it faster, cheaper, sooner. If we commit to this vision of inter-operable services based on automated generic switching instead of custom-built APIs we can solve this problem in less than 20 years. We can all have Jetpacks!
We havde all the talent and skill right here in this room to make this happen. We just need to sieze the day and charge ahead. We have the opportunity to skip ahead in class,
To avoid the mistakes of the future,
and to build a world where (closing line needed here)
Thank you.


The Michaels Companies, Inc.
Software Development Engineer
Backend API Development – Michaels.com Ecommerce (Feb. 2021 – Aug. 2022)
-
Participated in the design, development, improvement, test, and deployment of the high scale backend services for the entire online shopping experience.
Third-party Service Integration (Nov. 2021 – Aug. 2022)
Java
SpringBoot
Python
Redis
Apache Airflow
Datadog
Google Tag Manager
-
Participated the integration of the third-party service including Affirm (financing), Attentive (text message), Fusion 92 (promotion), Tibco (loyalty), and SheerID (ID validation) etc.
-
Took part in the implementation of the global third-party service admin portal. Helped to create Java Spring tool package for third-party API metric/usage/access/defect/data analysis.
-
Led the development of the data retrieving APIs and data uploading/syncing up pipelines for 3rd-party service data access.
-
Introduced cache system to store the frequently accessed data and avoid the entire list traverse. Greatly reduced the average API data retrieving time from 1000ms to 10ms.
Shopping Cart Development (Feb. 2021 – Oct. 2021)
Java
SpringBoot
Redis
Cassandra
Google Spanner
MongoDB
Kafka
Jenkins
Google Cloud
-
Designed, developed, tested, and deployed of the shopping cart system and RESTful APIs using Java, Spring Boot including initialize shopping cart, add/remove product, change quantity, inventory check, etc.
-
Worked with the front-end team to discuss API design such as HTTP method, request/response format, and error handling, etc. Under the premise of realizing functionalities, optimized the structure of request and response (params/JSON), reduced the amount of transmitted data and achieved faster API access.
-
Incorporated Kafka as message broker and data buffer for decoupling checkout and shopping cart microservices. Implemented shopping cart cache with Redis which increases performance and reduce response time by 92%.
-
Cooperated with the DB team to migrate item table from MySQL to MongoDB using primary-secondary mechanism. Constructed the new shopping cart table schema and index strategy. Managed to merge the separated shopping cart tables (course products, project products, and SKU products) into one standalone table by normalizing the optional tables and extracting the same entities. Reduced the average API long queries from 3 times to 1.5.
-
In charge of: using (TDD) Junit and Mockito to keep unit tests light and non-invasive, using SonarLint for code style check, writing swagger API doc, conducting the CI/CD pipeline from dev to QA, and integrating Datadog for API monitoring.
iOS Mobile Development (Dec. 2020 – Feb. 2021)
iOS
Swift
Objective-C
XCode
UIKit
RxSwift
SDWebImage
SnapKit
Alamofire
-
Worked on a 16-people mobile development team to design, develop, test and deliver Michaels apps in an agile development cycle. Participated in the start-up of iOS team. Collaborated with team members to research different mobile development frameworks (hibernate vs native, storyboard vs SwiftUI), iOS programming languages (Swift, OC), decide coding style, code structure pattern, version-control flow, third party libraries, and CI/CD pipeline.
-
Contributed critical, shared components to multiple features of the mobile app including reusable UI component library, global data transformation, presentation, cache, persistence, and network communication library, etc.
-
Closely worked with backend team to discuss API design and requirement, and UI/UX team to design and integrate the app’s UI and prototype using Sketch and Figma.
-
Responsible for the development of instore scan & go app from scratch. Implemented the use of WIFI SSID, Bluetooth beacon, and Geofence to improve the user's instore status detection speed. Researched common barcode formats, and compared Apple's official Vision barcode scan solution with Google's MLKit solution to improve scanning and product information retrieving speed.


{% extends 'base.html' %} {% block title %}Reset password{% endblock title %} {% block content %}
A mail has been sent to your email. Click on the link to continue


It's better to import models that you will user, since it won't visually collide with django.db.models
I would suggest absolute imports as py3 get's rid of relative.
from . import models
it's better to import models that you will user, since it won't visually collide with django.db.models
I would suggest absolute imports as py3 get's rid of relative/p>


MotoGP, Crutchlow falls in love with 2-stroke: at Motegi on Lawson's NSR500
PHOTO. Cal rode the world champion bike in 1989 at Honda Thanks Day: "The bike was fantastic but I can’t imagine racing one in 1989"
by GPonePHOTO. Cal rode the world champion bike in 1989 at Honda Thanks Day: "The bike was fantastic but I can’t imagine racing one in 1989".


New-World
Disembark and have an adventure!
Start Playing Now!
Play.NewWorld.mc
Play
Forum
Discord
Facebook
Reddit
Server List A