Matt Webb (Schulze & Webb) — FuelBand for alpha waves
I was waiting for a bus the other day, and had a pretty good time stand there, wool gathering, contemplating the world, thinking about the various things I needed to do, etc.
And on the bus after I thought: I don't give myself enough time to stop and think.
And then I thought: I don't give myself enough time to exercise either, and what I did in that case was buy a Nike+ FuelBand and monitor how many steps I take each day. (There was a surprise there: Factoring out exercise, there's a huge variation in my regular everyday activity, a four-times difference between quiet days and active days although they feel much the same.)
So I bought a MindWave from Neurosky which is a portable electroencephalography (EEG) headset with dry sensors. That is, it measures faint electrical activity on my head to read my brainwaves, and it's "dry" so I don't need to soak the sensors in saline or anything like that.
In theory it should be able to measure when I'm concentrating, when I'm excited/agitated, and when I'm relaxed.
It comes with a dongle to plug into my Mac so I can read the data from it using the MindWave developer tools. (In retrospect I should have bought the MindWave Mobile which uses Bluetooth and can also connect to the iPhone.)
It's a shame the MindWave doesn't store data itself -- if I want to get long-term readings then I will have to keep it paired with my Mac and store and analyse the data there.
Why? Because I'd like to wear this the whole time, and become more mindful of how much time - and for how long - I'm concentrating, reflecting, etc. And over time, being mindful of this, could I see whether I'm happier/more productive/more creative when I spend (say) regular time each day reflecting, or long periods of time on a single day concentrating, and so on.
Companies I would start if I wasn't doing this one:
The models currently in this space are exemplified by two companies, both based on Neurosky's technology:
- Home of Attention, which caters to managers for trainers and managers for education and self-improvement. In their literature there are phrases like :
You learn to relax at any time,
You learn how to use your concentration to access any required performance at an instant.
Other companies focus brain training on different sectors, and adjust their branding accordingly. - Toys and games, of which my favourite is the Necomini cat ears headset. These ears perk up when you see something interesting (food, a pretty boy), and fall when you relax. A neat toy... and done right it would be entertaining to see these in bars, although I have a feeling they're really a Hypercolor for checking people out.
Neurosky themselves have an app store.
But I think these companies are missing a trick. I'd like to introduce focus, good design, and vertical integration, and take lessons from successes like Nike+ and Foursquare.
I would love to take the Neurosky MindWave technology, have it store data for later syncing as a Bluetooth Smart Device, make it look great, wrap a FuelBand self-awareness and goals iPhone app around it, build in a mood tracking feature for feedback - maybe correlate it with email and calendar/todo list activity, Twitter/Facebook updates (for another mood datapoint), and Foursquare (for location) - and sell it as a headband.
You would share the time you'd spent reflecting each day on Facebook. There would be challenges, and self-awareness. I might bootstrap a distributed network of gym instructors for meditation (we'd have a marketplace for subscription yogis).
Kind of a cross between Brain Age (or Brain Training depending on your territory), FuelBand, product sales plus subscription services, quantified self, and mental well-being.
The really interesting stuff would happen when we start using machine learning across vast amounts of data from tens of thousands of individuals, all submitting brain wave and activity/mood data. We'd data-mine like crazy. What would we learn? It would be a little like 23andme, the data-mining + pathologies + gene sequencing company, and a little like Knewton with their personalised, adaptive learning. Maybe we would end up saying things like:
You know you need to be on top form in 5 days? We know from past behaviour and by looking at people like you that you need to spent 30 minutes more per day in uninterrupted quiet reflection in order to achieve this. Here's your goal. Go!
There's not quite a business here, not at launch... but after you find out what combinations of which mental states over a day promote what kind of behaviours, and you can help people be mindful of that? There's something really big there, I'm sure.
I wish I had more hours in the day.
Right now
I am using my MindWave and playing Blink/zone to explode fireworks whenever I blink. When I don't blink they don't explode, when I do blink they do. It works surprisingly well. It's a weird experience to have something I regard as so interior picked up by a computer.
Norman Walsh (Sun) — The short-form week of 8–14 May 2012
The week in review, 140 characters at a time. This week, 9 messages in 11 conversations. (With 1 favorite.)
This document was created automatically from my archive of my Twitter stream. Due to limitations in the Twitter API and occasional glitches in my archiving system, it may not be 100% complete.
In a conversation that started on Monday at 01:58pm
Wednesday at 10:05am
In a conversation that started on Thursday at 11:50am
In a conversation that started on Thursday at 03:39pm
In a conversation that started on Thursday at 03:51pm
Thursday at 03:56pm
In a conversation that started on Thursday at 03:58pm
Monday at 06:17am
Monday at 12:19pm
Monday at 05:23pm
Monday at 08:12pm
Amazon Web Services — Domain Verification for the Amazon Simple Email Service
The Amazon Simple Email Service (SES) makes it easy and cost-effective for you to send bulk or transactional email messages.
As I described in my introductory post (Introducing the Amazon Simple Email Service), you must verify the email address (or addresses) that you plan to use to send messages. The initial verification process must be repeated for each email address.
Today we are introducing a new SES feature. You can now verify an entire domain, and then send email from any address in that domain. In addition to saving you time and effort, this new feature now allows you to use Amazon SES in situations where you don't accept email at the From address, or when you don't know the From address ahead of time.
You verify a domain by creating a TXT record in the domain's DNS record using information that we provide you as part of the domain verification process. Most (not all) DNS providers allow you to create TXT records.
If you are using Amazon Route 53 to provide DNS service for your domain, the process is very straightforward; you can verify the domain using the AWS Management Console. Here's a tour...
The first step is to visit the SES tab of the console and add your domain to the Domains tab in the Verified Senders section:
If you are not using Route 53, the next step is to update your domain's DNS settings using the TXT record information displayed in the console:
If you are using Route 53, push the Use Route 53 button and select the domains and subdomains that you want to verify:
Either way (Route 53 or your own DNS provider), Amazon SES will verify your domain within 72 hours. Once the domain has been verified, you'll receive an email and the domain will be marked as "verified" in the console.
You can now send email from any address in the domain!
If you would like to learn more about domain verification, please sign up for the June 12th webinar: Using Domain Verification with Amazon Simple Email Service. The webinar is free but space is limited!
We have also changed the limit on the number of verified addresses and domains allowed per AWS account from 100 to 1000.
-- Jeff;
ProgrammableWeb — Gumroad Aims To Make Selling Items as Simple as Sharing Them
Ever tried to sell something on the Internet and hoped that the process was simpler than what it currently is? What if selling an item on the Internet was as simple as sharing the item for sale with your friends on the social web? Gumroad, a San Francisco based startup has adopted that philosophy and wants to take the pain out of selling an item on the web and it also provides the Gumroad API for its core features.
Gumroad simplifies the process of selling any item by doing things in a certain way. First, it wants you to sell your item to your friends, followers in the same way that you communicate to them i.e. by sharing that information. You do not need to setup any store. In case of digital items like MP3’s of your songs or an eBook, you can host the download in a secure download link and the buyer will be sent the link once purchase is complete. You set your pricing and gumroad takes a fixed cut of 5% and $.25 of the transaction cost.
Gumroad also provides an API to go with their web site. The Gumroad API currently offers the core functionality of authentication and setting up your items for sale. The API is REST based and uses JSON for its data format. Authentication is done by a secure HTTP call passing in the username and password. Once authenticated, you can perform various API actions to maintain your list of items for sell, including creating a new link, editing, deleting, enabling/disabling,etc.
For example, to create a new link for an item up for sale, do a POST to https://gumroad.com/api/v1/links with request parameters like name, url, price and description.
The API may be limited but it is good enough to get going and it won’t be long before developers would write mobile applications using them.
What do you think of the Gumroad approach to selling items on the web? Simple is definitely their forte and it would be interesting to see the traction they get in a few months from now.
Sponsored by
Related ProgrammableWeb Resources
Amazon Web Services — AWS Cloud Storage for the Enterprise
There are a lot of storage options available to AWS users -- Amazon S3, Elastic Block Storage, and the AWS Storage Gateway, along with ancillary services such as Amazon CloudFront for content distribution, AWS Direct Connect for dedicated network connections, and Amazon Elastic MapReduce for large-scale data processing.
Our customers are using these services to implement cloud-based backup, disaster recovery, and archiving for entire enterprises.
In order to help you make sense of all of these options and to give you a better sense of how AWS can help you, we have created a day-long event devoted to cloud storage for the enterprise.
The AWS Cloud Storage for the Enterprise event will take place on June 6th in New York, and will run from 10:00 AM to 5:30 PM. In addition to keynotes from Stephen Schmidt (Vice President, Security Engineering and Chief Information Security Officer for AWS) and Matt Tavis (AWS Solutions Architect), you will get to hear directly from AWS customers. Stephen will focus on the all-important question of data security in the cloud, and Matt will discuss the ways in which the cloud is transforming the storage strategies that our enterprise customers are putting in to play.
They'll also coever some lesser-known topics such as cloud-as-a-tier, NAS-like functionality with the cloud, long term data archiving with high performance record retrieval, high speed data transfer in and out.
The event is free, but you will need to register.
-- Jeff;
ProgrammableWeb — Why REST Keeps Me Up At Night
This guest post comes from Daniel Jacobson (@daniel_jacobson), director of engineering for the Netflix API. Prior to Netflix, Daniel ran application development for NPR where he created the NPR API, among other things. He is also the co-author of APIs: A Strategy Guide and a frequent contributor to ProgrammableWeb and the Netflix Tech Blog.
With respect to Web APIs, the industry has clearly and emphatically landed on REST as the standard way to implement these services. And for good reason… REST, which is generally implemented as a one-size-fits-all solution, is an excellent choice for a most companies who wish to expose their content to third parties, mobile app developers, partners, internal teams, etc. There are many tomes about what REST is and how best to implement it, so I won’t go into detail here. But if I were to sum up the value proposition to these companies of the traditional REST solution, I would describe it as:
REST APIs are excellent at handling requests in a generic way, establishing a set of rules that allow a large number of known and unknown developers to easily consume the services that the API offers.
In this model, everyone knows how to behave and it can be incredibly powerful. The API providers establish a set of rules and the API consumers must adhere to those rules to get what they want from the API. It is perfect, right? In many cases, the answer is obviously yes. But in other cases, as our world scales and the number of ways for people to consume digital content and services continues to expand, this one-size-fits-all model is likely to fall short.
The potential shortcomings surface because this model assumes that a key goal of these APIs is to serve a large number of known and unknown developers. The more I talk to people about APIs, however, the clearer it is that public APIs are waning in popularity and business opportunity and that the internal use case is the wave of the future. There are books, articles and case studies cropping up almost daily supporting this view. And while my company, Netflix, may be an outlier because of the scale in which we operate, I believe that we are an interesting model of how things are evolving.
Netflix is currently available on over 800 different device types, including game consoles, mobile phones, TVs, Blu-ray players, tablets, computers, and almost any other device that can stream video. Our API alone handles more than two billion incoming requests on peak days, which translates into almost ten billion real-time outgoing requests from the API to internal dependency services. These numbers are up by about 70x from just two years ago. Most companies do not have that kind of scale, but it is clear that with the continued growth of the device market more companies are resetting their strategies to be less about the public API and more about internal consumption of their own APIs to support device proliferation. When this transition occurs, the API is no longer targeting “a large number of known and unknown developers.” Rather, the key audience is a small number of known developers.
The potential conflict between the internal and public use cases is in the design of the API itself. Keep in mind that the design implications will not be problematic in many scenarios. It becomes a potential problem if the breadth of devices becomes so wide that the variability of features across them becomes substantially harder to manage. It is the breadth of devices that creates a problem for the one-size-fits-all API solutions.
If your target is a small group of teams with whom you have close relationships, the dynamics around the API change. For Netflix, we persisted on the one-size-fits-all REST model for quite a while as more and more devices got added on top of the API. But given our scale, one thing has become increasingly obvious. Our REST API, while very capable of handling the requests from our devices in a generic way, is optimized for none of them. This is the case because our REST API focuses on resources that are meant to be granular representations of the data, from the perspective of the data. The granularity is exactly what allows the API to support a large number of known and unknown developers. Because it sets the rules for how to interface with the data, it also forces all of the developers to adhere to those rules. That means that each device potentially has to work a little harder (or sometimes a lot harder) to get the data needed to create great user experiences because devices are different from each other.
The differences across these devices can be varied and sometimes significant. Here are some examples of variances across devices that may be challenging for one-size-fits-all models:
- Different devices may have different memory capacity
- Some devices may require a unique or proprietary format or delivery method
- Some devices may perform better with a flatter or more hierarchical document model
- Different devices have different screen real estate sizes which may impact which data elements are needed
- Some devices may perform better having bits streamed across HTTP rather than delivered as a complete document
- Different devices allow for different user interaction models, which could influence the metadata fields, delivery method, interaction model, etc.
Just think about the differences between an iPhone and your TV and how they beg for different user experiences. Moreover, the XBox and the Wii, both of which project to the TV, are different in the way users interact with them as well as in the hardware constraints, both of which may require different APIs to support them. When considering more than 800 different device types, the variance across them becomes overwhelming. And as more manufacturers continue to innovate on these devices, the variance may only broaden.
- Small number of targeted API consumers is the top priority
- Very close relationships between these API consumers and the API team
- An increasing divergence of needs across the top priority API consumers
- Strong desire by the API consumers for more optimized interactions with the API
- High value proposition for the company providing the API to make these API consumers as effective as possible
If these ingredients are met, then you have the recipe for needing a new kind of API.
Because of the differences in these devices, Netflix UI teams would often have to do a range of things to get around our REST API to better serve the users of the device. Sometimes, the API team would be required to extend the base service to handle special cases, often resulting in spaghetti code or undocumented features. And because different teams have different needs, in the REST API world, we would often need to delay feature development for some due to the challenges around prioritization. In addition to these kinds of issues, significant performance and/or architectural problems are bound to emerge. For example, these more granular APIs often result in chattier interactions between device and server or chunkier payloads, as I discussed in a previous post on the Netflix Tech Blog.
To solve this issue, it is becoming increasingly common for companies (including Netflix) to think about the interaction model in a different way. Rather than having the API create a set of rather rigid rules and forcing the various devices to follow them, companies are now thinking about ways to let the UI have more control in dictating what is needed from a service in support of their needs. Some are creating custom REST-based APIs to support a specific device or category of devices. Others are thinking about greater granularity in REST resources with more batching of calls. Some are creating orchestration layers, such as <http>ql.io, in their API system to customize the interaction. These are all smart and practical ways around the problem. But with the growing number of devices, the increasing urge for companies to be on as many of them as possible, and the desire for continued innovation across these devices, these various solutions are still somewhat restricted. They are still forcing the developers to adhere to server-side rules and non-optimized payloads in an effort to have a one-size-fits-all solution. These approaches are closer to the flexibility needed in that they are not as rigid as the typical REST-based solution, but when supporting as many devices as Netflix does, we believe they fall short for us.
For Netflix, our goal is to take advantage of the differences of these devices rather than treating them generically. As a result, we are handing over the creation of the rules to the developers who consume the API rather than forcing them to adhere to a generic set of rules applied by the API team. In other words, we have created a platform for API development. In my next post, I will discuss in more detail our implementation of this approach. In the meantime, if you are interested in helping us solve these and other problems, we are hiring!</http>
Sponsored by
Related ProgrammableWeb Resources
Uche & Chimezie Ogbuji — A Perspective on Life
Uche & Chimezie Ogbuji — The Lay of Analytics
Uche & Chimezie Ogbuji — Brief notes on upgrading a 2010 MacBook Pro SSD
ProgrammableWeb — API Strategy Lessons from Factual’s Upgrade of its Mobile/Local APIs
This guest post comes from Dan Woods, CTO and Editor of CITOResearch.com and co-author of APIs: A Strategy Guide. He writes about API Strategy and related topics.
Factual Inc, a company founded by ex-Googler Gil Elbaz that is creating a collaborative data platform, announced extensions to its Factual APIs today that are aimed at improving the ability to target advertising and provide other geo-based capabilities in mobile applications. The three new APIs, Geopulse, Reverse Geocoder, and World Geographies, fill gaps and extend the scope of Factual’s API portfolio. But the way that Factual thinks about its APIs also holds lessons for anyone who is mapping out an API strategy of their own.
Factual offers access to data sets for Global Places, U.S. Restaurants, U.S. Healthcare providers, and World Geographies. Factual’s first batch of APIs provided access to the foundational location data for 50 countries (the Core API), enabled entity resolution for a place (Resolve), and provided mappings to a place from dozens of sources such as Foursquare, Yelp, Eventful and so on (Crosswalk API). The new APIs help mobile app developers, advertising companies and demand side platforms target ads better in the mobile environment, and companies attempting to understand how to target ads:
Geopulse is an API that accepts a latitude and longitude and returns four different types of information, called pulses, related to that location:
- Factual Commercial Density: the relative density of businesses nearby
- Factual Commercial Profile: the types of businesses nearby
- Nearest: the closest Place in the Factual database.
- Demographics: Age, gender, race, and median income based on US census data (US only).
Reverse Geocoder is an API that converts a longitude and latitude into an address (US only) or region (49 other countries).
World Geographies is an API that provides the names and interrelationships between the world’s natural and administrative geographies — countries, cities, states, continents, regions, and time zones — enhancing the global 60 million businesses and landmarks Factual currently offers. The API provides approximately 6 million geographies and over 8 million place names in numerous languages.
All of these APIs are being released in beta. The Reverse Geocoder and World Geographies APIs fill gaps that developers of mobile and web asked have asked for.
The Geopulse API fills an emerging need to assemble as much information as possible related to a specific location. Instead of just knowing that you are at a specific location with a certain type of phone at a specifice time of day, the Geopulse API provides many more signals that can be used to improve the targeting of an ad.
“The signals were are releasing in GeoPulse are just the beginning,” Factual’s Eva Ho said. “In the future we will layer on top social signals and many other data sets that will further improve the amount of information that can be used by application developers or ad networks. Both groups are hungry for as much information as they can get.”
The way that Factual is gradually extending its APIs reveals a pattern that should be useful to product managers and designers of APIs or portfolios of mobile apps. The operative principle: Follow the value chain.
Often, when someone creates an API or a mobile app, the effort is a shot in the dark. Will anyone be interested? How will it make a difference? If the API or application takes hold, the next question is: What comes next?
Following the value chain means looking at what the API or mobile app is being used for. Ask not only what more can be done but what are the adjacent activities that are related? How can these be supported? Is there an emerging API economy of the sort my co-authors and I described in “APIs: A Strategy Guide”? If so how must the existing APIs grow and what new APIs are required?
The growth of Factual APIs follows the value chain created by mobile apps. First, the mobile and web apps needed information about places. This is where Factual APIs first took hold. The success of these apps lead to the need to offer better targeting of ads and other services. This is the mission of the APIs Factual announced today.
“Our early customer wins were all around web and mobile developers,” Ho said. “Their next big worry was how were they going to monetize their applications, and we realized that we needed to provide more data to enable that. Going into local targeting makes complete sense given that we started with this rich dataset of locations.”
While the first users of the APIs will likely companies who sell targeted ads, it is likely that companies who buy targeted ads will also use the APIs to figure out how to improve their rules for targeting.
Ho said that many more data sets are on the way. As these data sets create new applications, Factual will undoubtedly follow the value chain with new sets of APIs.
Sponsored by
ProgrammableWeb — 45 Coupons APIs: Groupon, 8coupons and US Yellow Pages
Our API directory now includes 45 coupons APIs. The newest is the Wishpot Coupon API. The most popular, in terms of mashups, is the Groupon API. We list 10 Groupon mashups. Below you’ll find some more stats from the directory, including the entire list of coupons APIs.
In terms of the technical details, REST and XML lead the way. It should be pointed out that only 30 APIs in this category have a protocol listed. Many providers in this space do not make their documentation openly available instead preferring to partner with developers before providing access. There are 29 coupons REST APIs. Our directory lists 25 coupons XML APIs and 23 coupons JSON APIs.
The most common tags within coupons are 38 shopping coupons APIs, 12 local coupons APIs and 12 deals coupons APIs.
On the mashup side, we list 12 coupons mashups. We named Frugalmate as mashup of the day yesterday.
For reference, here is a list of all 45 coupons APIs.
8coupons API: Local deals aggregator
AisleBuyer API: Mobile commerce services
AwardWallet API: Loyalty program management service
Best Buy BBYOpen BBYOffer API: eCommerce shopping services
BiteHunter API: Dining Deals Search Service
BuyDeals.in Local Deal API: Local Group Buy Aggregation Service
Bview Promotion API: Aggregate coupons for UK retailers
CardSpring API: Payment network service
CBS Local Offers API: Local Deals Listings
Cellfire API: Electronic coupon and discount service
CityPockets API: Daily deal and voucher aggregation service
Deal Magic API: List of Daily Deals
Dealinium API: Local deals aggregation service
DealsGoRound API: Online marketplace for daily deals
FindMeSpecials API: Find local specials and events
foursquare Merchant API: foursquare merchant platform
Getsocio API: Daily deal and group buying website platform
Grocery Server API: Grocery search engine
GroopBuy API: Local deals and group buying service
Groupon API: Group shopping service
Hyperpublic API: Geographic data collection service
Lifesta API: Deal buying and selling service
MasterCard Offers API: Discount, deals, and offers service
MerchantCircle.com API: Online marketing service for local businesses
Mphoria API: Deal providing service
MyDealBag API: Local deals aggregation service
OfferGrid API: Deal distribution service
OWS Coupons API: Coupon and deal feed
Paynoy API: Philippines deal service
Peixe Urbano API: Brazilian daily deals service
Pricecut API: Coupons, deals and price comparison service
RapidPoints API: Rewards program services for small businesses
RetailMeNot.com Community Ideas API: Online coupons and discounts
SideBuy API: Local deals and coupons aggregation service
Spotzot API: Deal targeting and loyalty program service
Sqoot API: Local deals aggregation service
StickyStreet API: Loyalty & Customer Management System
The Dealmap API: Local deals
ThinkNear API: Local marketing and advertising service
Tippr API: Daily deals aggregation service
US Yellow Pages API: US yellow pages telephone directory
Vouchers.Im API: Shopping coupons and deals services
Wishpot Coupon API: Coupon aggregation service
Yipit API: Local coupon aggregation service
Zixxo API: Online coupons
Sponsored by
Related ProgrammableWeb Resources
Daniel Glazman (Disruptive Innovations) — Planning du Jour 1
- matinée : piscine
- après-midi ? Re-piscine...
- soirée : choucroute
- prévisions pour jour 2 : antibiotiques et grog
developerWorks: Web Development — Improve your XSLT 2.0 stylesheets with types and schemas
developerWorks: Web Development — Introducing Riak, Part 2: Integrating Riak as a heavy-duty caching server for web applications
ProgrammableWeb: APIs — Raven Slingshot
precision agriculture business tool
ProgrammableWeb: APIs — Papirus
Task management, collaboration, and messaging serviceProgrammableWeb: APIs — MESSAGEmanager
SMS and email message monitoring service
ProgrammableWeb: APIs — UN Comtrade
United Nations Commodity Trade Statistics DatabaseCameron Moll — Regret.
Kathryn Schulz, as quoted by Maria Popova:
If we have goals and dreams and we want to do our best, and if we love people and we don’t want to hurt them or lose them, we should feel pain when things go wrong. The point isn’t to live without any regrets, the point is to not hate ourselves for having them… We need to learn to love the flawed, imperfect things that we create, and to forgive ourselves for creating them. Regret doesn’t remind us that we did badly — it reminds us that we know we can do better.”
Amazon Web Services — AWS Week in Review - May 7, 2012
Let's take a quick look at what happened in AWS-land last week:
| Monday, May 7 |
|
| Tuesday, May 8 |
|
| Wednesday, May 9 |
|
| Thursday, May 10 |
|
| Friday, May 11 |
|
| Sunday, May 13 |
|
Stay tuned for another exciting week!
-- Jeff;
ProgrammableWeb — Gecko Landmarks is Changing the Face of the Mapping Industry
Gecko Landmarks is working on an easier way of giving directions. The theory behind their madness is that “everyone thinks in landmarks”. They took this idea and ran with it. In fact they have run all over the world with this idea. They have now collected landmark data for every country in the world. Most of this data is now available in the Gecko Landmarks API.
Gecko Landmarks provides services that go further than landmark based mapping. They also provide personal and professional tracking services and Textor, which is an sms application that provides directions using landmarks.
The Gecko Landmarks API is designed for mobile internet companies that could use landmark data to allow their users access to easy to understand location information. The API uses HTTP calls and responses are formatted in JSON, KML, KMZ and CSV.
The Gecko Landmarks API is one of 140 locations APIs in the ProgrammableWeb directory.
Sponsored by
Related ProgrammableWeb Resources
Matt Webb (Schulze & Webb) — Science questions
SCIENCE QUESTIONS
- Is it true the human ear never stops growing?
- If the universe is infinite then why is so much of the night sky black?
- How come the biggest corn flakes are on the top of the pack and don't sink?
- Why do people imitate birds by whistling when birds don't have lips?
- Is it true that dogs see in black and white?
- Is it true that dogs die from eating chocolate?
- Is it true that dogs can see ghosts?
- Was there a dog jesus?
- If there wasn't a dog jesus, if a dog dies from eating chocolate, does a dog go to heaven?
- Or does the dead dog become a dog ghost?
- Is this why dogs can see ghosts?
- Because ghosts are dogs?
- And dogs are ghosts?
- Mountains, are they small or far away?
Amazon Web Services — Amazon CloudFront - Support for Dynamic Content
Introduction
Amazon CloudFront's network of edge locations (currently 30, with more in the works) gives you the ability to distribute static and streaming content to your users at high speed with low latency.
Today we are introducing a set of features that, taken together, allow you to use CloudFront to serve dynamic, personalized content more quickly.
What is Dynamic Personalized Content?
As you know, content on the web is identified by a URL, or Uniform Resource Locator such as http://media.amazonwebservices.com/blog/console_cw_est_charge_service_2.png . A URL like this always identifies a unique piece of content.
A URL can also contain a query string. This takes the form of a question mark ("?") and additional information that the server can use to personalize the request. Suppose that we had a server at www.example.com, and that can return information about a particular user by invoking a PHP script that accepts a user name as an argument, with URLs like http://www.example.com/userinfo.php?jeff or http://www.example.com/userinfo.php?tina.
Up until now, CloudFront did not use the query string as part of the key that it uses to identify the data that it stores in its edge locations.
We're changing that today, and you can now use CloudFront to speed access to your dynamic data at our current low rates, making your applications faster and more responsive, regardless of where your users are located.
With this change (and the others that I'll tell you about in a minute), Amazon CloudFront will become an even better component of your global applications. We've put together a long list of optimizations that will each increase the performance of your application on their own, but will work even better when you use them in conjunction with other AWS services such as Route 53, Amazon S3, and Amazon EC2.
Tell Me More
Ok, so here's what we've done:
Persistent TCP Connections - Establishing a TCP connection takes some time because each new connection requires a three-way handshake between the server and the client. Amazon CloudFront makes use of persistent connections to each origin for dynamic content. This obviates the connection setup time that would otherwise slow down each request. Reusing these "long-haul" connections back to the server can eliminate hundreds of milliseconds of connection setup time. The connection from the client to the CloudFront edge location is also kept open whenever possible.
Support for Multiple Origins - You can now reference multiple origins (sources of content) from a single CloudFront distribution. This means that you could, for example, serve images from Amazon S3, dynamic content from EC2, and other content from third-party sites, all from a single domain name. Being able to serve your entire site from a single domain will simplify implementation, allow the use of more relative URLs within the application, and can even get you past some cross-site scripting limitations.
Support for Query Strings - CloudFront now uses the query string as part of its cache key. This optional feature gives you the ability to cache content at the edge that is specific to a particular user, city (e.g. weather or traffic), and so forth. You can enable query string support for your entire website or for selected portions, as needed.
Variable Time-To-Live (TTL) - In many cases, dynamic content is either not cacheable or cacheable for a very short period of time, perhaps just a few seconds. In the past, CloudFront's minimum TTL was 60 minutes since all content was considered static. The new minimum TTL value is 0 seconds. If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. It will then make a GET request with an If-Modified-Since header, thereby giving the origin a chance to signal that CloudFront can continue to use the cached content if it hasn't changed at the origin.
Large TCP Window - We increased the initial size of CloudFront's TCP window to 10 back in February, but we didn't say anything at the time. This enhancement allows more data to be "in flight" across the wire at a given time, without the usual waiting time as the window grows from the older value of 2.
API and Management Console Support - All of the features listed above are accessible from the CloudFront APIs and the CloudFront tab of the AWS Management Console. You can now use URL patterns to exercise fine-grained control over the caching and delivery rules for different parts of your site.
Of course, all of CloudFront's existing static content delivery features will continue to work as expected. GET and HEAD requests, default root object, invalidation, private content, access logs, IAM integration, and delivery of objects compressed by the origin.
Working Together
Let's take a look at the ways that various AWS services work together to make delivery of static and dynamic content as fast, reliable, and efficient and possible (click on the diagram at right for an even better illustration):
- From Application / Client to CloudFront - CloudFront’s request routing technology ensures that each client is connected to the nearest edge location as determined by latency measurements that CloudFront continuously takes from internet users around the world. Route 53 may be optionally used as a DNS service to create a CNAME from your custom domain name to your CloudFront distribution. Persistent connections expedite data transfer.
- Within the CloudFront Edge Locations - Multiple levels of caching at each edge location speed access to the most frequently viewed content and reduce the need to go to your origin servers for cacheable content.
- From Edge Location to Origin - The nature of dynamic content requires repeated back and forth calls to the origin server. CloudFront edge locations collapse multiple concurrent requests for the same object into a single request. They also maintain persistent connections to the origins (with the large window size). Connections to other parts of AWS are made over high-quality networks that are monitored by Amazon for both availability and performance. This monitoring has the beneficial side effect of keeping error rates low and window sizes high.
Cache Behaviors
In order to give you full control over query string support, TTL values, and origins you can now associate a set of Cache Behaviors with each of your CloudFront distributions. Each behavior includes the following elements:
- Path Pattern - A pattern (e.g. "*.jpg") that identifies the content subject to this behavior.
- Origin Identifier -The identifier for the origin where CloudFront should forward user requests that match this path pattern.
- Query String - A flag to enable support for query string processing for URLs that match the path pattern.
- Trusted Signers - Information to enable other AWS accounts to create signed URLs for this URL path pattern.
- Protocol Policy - Either allow-all or https-only, also applied only to this path pattern.
- MinTTL - The minimum time-to-live for content subject to this behavior.
Tool Support
Andy from CloudBerry Lab sent me a note to let me know that they have added dynamic content support to the newest free version of the CloudBerry Explorer for Amazon S3. In Andy's words:
I'd like to let you know that CloudBerry Explorer is ready to support new CloudFront features by the time of release. We have added the ability to manage multiple origins for a distribution, configure cache behavior for each origin based on URL path patterns and configure CloudFront to include query string parameters.
You can read more about this in their new blog post, How to configure CloudFront Dynamic Content with CloudBerry S3 Explorer .
Andy also sent some screen shots to show us how it works. The first step is to specify the Origins and CNAMEs associated with the distribution:
The next step is to specify the Path Patterns:
With the Origins and Path Patterns established, the final step is to configure the Path Patterns:
And Here You Go
Together with CloudFront's cost-effectiveness (no minimum commits or long-term contracts), these features add up to a content distribution system that is fast, powerful, and easy to use.
So, what do you think? What kinds of applications can you build with these powerful new features?
-- Jeff;
PS - Read more about this new feature in Werner's new post: Dynamic Content Support in Amazon CloudFront.
Daniel Glazman (Disruptive Innovations) — Where is Daniel
Major lumbago and lots of pain, my back is completely blocked. Don't expect me to be fully available today, a visit to my osteopath has the highest priority right now 
ProgrammableWeb — 71 New APIs: Wishpot, Gecko and Optical Character Recognition
This week we had 71 new APIs added to our API directory including a social eCommerce platform, optical character recognition service, location information services, web marketing services and a mobile printing app. In addition we covered Involver’s launch of a groundbreaking social advertising optimization API. Below are more details on each of these new APIs.
ABBYY Cloud OCR API: ABBYY is a provider of OCR, document capture, ICR and language translations services. Their Cloud OCR SDK allows developers to integrate ABBYY's optical character recognition technologies for applications such as photograph and image conversion into searchable text. With the API, users can load images to the OCR server, process with necessary recognition and export parameters, obtain the results of processing. It uses HTTP calls and responses are formatted in XML.
Across Communications API: Across Communications is a web-based service that provides a platform and infrastructure for delivering messages from any computer connected to the Internet to a wide variety of communication devices. This allows users to integrate phone calls, faxes, SMS, ICQ, MSN, numeric pagers, and e-mail. Across Communications' SOAP-based APIs allow users to access many of their services programmatically.
ActPHP API: ACTPHP.COM LAMP is a web portal for web development centering on LAMP. The site offers a variety of learning resources categorized by Open source products, LAMP platform technologies, WEB front-end development and Website optimization SEO.The API allows users to create secure encrypted passwords and also check it against existing passwords. The API uses RESTful calls and responses are formatted in JSON.
Alau.me API: Alau.me is an iOS App referral-tracking platform designed by The Daily Tracker. It creates a short referral link for sharing. Then it can track how many downloads resulted from the link. The API is available with an Alau.me account. It exposes the general functionality of the URL generating and referral-tracking services. It is RESTful and provides JSON responses. Documentation is publicly available in an SDK.
AVANTSSAR API: Exposing services for integration into service-oriented architectures entails a variety of trust and security issues. It's important to validate both the service components and their composition into secure service architectures. The AVANTSSAR (Automated VAlidatioN of Trust and Security of Service-oriented ARchitectures) API allows users to validate service components as well as their positions in service-oriented architectures.
Bimshare Upload API: Bimshare is a sharing platform for engineering and architectural models. Users can upload 3D models of their designs and view them from an angle. Bimshare is designed to work in many browsers for professionals, students, and governments. Their API exposes the functionality for generating URLs with models can be hosted. It is a RESTful API and responds in JSON.
Blipfoto API: Blipfoto.com is a photo-sharing website. The site is designed for photographers to develop photo journals, personal projects, and community projects. Users may also use the site as a hosting service to share their photographs with friends and family. The Blipfoto API exposes the websites information for programmatic integration with other services and app development. It runs on a RESTful protocol and returns XML responses by default but can support JSON, JSON-P, and serialized PHP as well.
Breezy API: Breezy is a mobile printing app that allows multiple devices in a mobile workforce to print from designated machines. It allows users to print widely through a network of printing partners. It works on API with a simple SDK that allows for easy integration with new devices. The API operates on SSL and uses oAuth2 for securing integration.
Caspio Bridge API: Caspio Bridge is a cloud database platform used to build interactive web applications through point-and-click wizards. Users can build web forms, databases, and other enterprise management applications without the need for programming skills. The Caspio Bridge API allows third-party integration with existing Caspio applications and other cloud services.
Charities Commission API: The Charities Commission of New Zealand is a publicly available database of registered charities that serves to build public trust and confidence in the charitable sector. The Charities Commission API provides open data to large amount of charities, their annual returns and officer information. It uses RESTful OData URI querying to pull information from the database.
ChompOn API: ChompOn is a group-buying platform for publishers. It provides functionality for websites to integrate group-buying options and deals across a network of publishers. ChompOn also analyzes users’ social media for optimization. Their RESTful API exposes the platform’s structure for developers to expand publishers’ services on top of it, as well as for integration with other services. It can provide responses in JSON or XML.
Critsend API: The service provides email messaging and management, including sending messages to defined recipient lists, receiving messages, and reporting on inbound and outbound traffic. A tagging function allows categorization of messages to select them for special management. Customizable reports allow monitoring of sent messages, bounced messages, response rates, click rates, and other recipient responses.
API methods support defining and sending outbound mail, including recipient lists, message body, file attachments, etc. Methods also handle inbound mail with selective automated replies and redirects for human response. Reporting methods provide traffic summaries, statistics on recipient responses, and alerts of system events.
Da Button Factory API: Da Button Factory is an automatic hyperlink button generator. Users specify the text and parameters of their buttons, including font, size, shadow, and more. They must also specify image format output type. The Da Button Factory API exposes the entirety of the website’s functionality. Users specify the parameters of their desired buttons in the request URL.
Dubset MixSCAN API: MixSCAN is a music fingerprinting service provided by Thefuture.fm. It allows DJs to stream live mixes legally by identifying each song and attributing the correct authorship and rights. The API is a RESTful and job-based, meaning it provides a small packet of metadata before scanning the mix, and then stays open for further pinging as the mix plays. It provides responses in JSON.
eCoComa Shipping API: The eCoComa Shipping API allows users to retrieve real-time shipping rates from major carriers. Supported shipping carriers include FedEx, UPS, United States Postal Service (USPS), and DHL/AirBorne Express (DHL). This API operates via SOAP using the XML data format.
EMBL Structure Filter API: The EMBL Structure Filter API is useful for evaluating the locations of candidate short regulatory sequences in proteins which need to be accessible to interact with their ligand domains. To do so, it calculates an accessibility score, secondary structure score, and total score for each match of a regular expression in the query sequence provided by the user.
EnergyIQ API: The service is part of efforts by the U.S. Lawrence Berkeley National Laboratory to encourage benchmarking of building energy efficiency, with clear guidelines for actions to reduce waste and improve energy performance. It is intended both to process data in a way that supports decision-making and to provide access to raw data for an application's own processing.
API methods support direct retrieval of complete datasets as well as querying data for specific building types, sizes, locations, ages, and activities housed (e.g., education, health care, retail, general office, etc.). Requests can specify energy profile details of interest, units of measurement, and chart types for output data.
Exchange Network NAAS API: The Exchange Network NAAS API provides programmatic access to security and authentication methods for Environmental Information Exchange Network users. The Exchange Network is a partnership between States, Territories, Tribes, and the U.S. Environmental Protection Agency for the exchange of environmental information. The Exchange Network NAAS API is accessible via SOAP calls using the XML data format.
Excluded Parties List System API: The Excluded Parties List System (EPLS) provides information regarding entities declared ineligible to receive Federal contracts, subcontracts, or Federal assistance and benefits. This information may include names, addresses, DUNS numbers, Social Security Numbers, Employer Identification Numbers, or other Taxpayer Identification Numbers, if available and deemed appropriate and permissible to publish by the agency taking action. The EPLS API allows users to search this list programmatically.
FlashFoto Image Processing API: FlashFotoInc is an image processing service. They provide a variety of software for image manipulation and detection. These functions include people detection, background removal manipulation, cropping, and more. Their REST API provides access to many of the creative functions as well as data libraries and file management systems. It handles JSON and image data formats, such as JPG and PNG.
GAMEhud API: GameHUD is a video game monitoring and analysis service. Game developers can use it track user statistics such as returning or new users, unique machines, and where players are having difficulty. Their API package provides access to the functionality to three different components of the GameHUD service: machines, game sessions, and game events. The API uses HTTP calls and provides JSON responses.
Gecko Landmarks API: The Landmark API allows mobile companies to use landmark data and allow their customers to consume location information in text format. It takes a user's current position expressed in latitude and longitude, and returns the closest landmarks. The API uses HTTP calls and responses are formatted in JSON, KML, KMZ and CSV.
GEMET API: The service maintains a database of multi-language thesauri, i.e. collections of terms with semantic relationships such as equivalent in meaning, broader or narrower in meaning, or associated in some other way. It provides access to each documented thesaurus and to lists of thesauri. Maintaining thesauri across different languages helps to encourage interoperability through connections between terms expressing similar concepts in different languages.
API methods support retrieval of concept lists from one or more thesauri at multiple levels, either top-most concepts, all concepts, or subsets. Methods also support submission of one concept and retrieval of all concepts from the database related to the one in the request, including those in different languages.
GoalBit API: GoalBit is an open source video delivery platform that includes features such as live and on-demand content, premium and user-generated content, large scale and enterprise deployments and more. With the platform, users can manage all aspects of online digital media including ingestion and transcoding, storage, replication and backup, delivery and streaming, acess control and much more. The GoalBit Suit API allows users to access the content on the platform. The API uses RESTful calls and responses are formatted in JSON.
Gumroad API: Gumroad provides simplified online commercial transactions for content creators. When users post their creations to Gumroad, they are then given a point of sale URL that they can then share with their networks. Gumroad supports a variety of payment methods and takes a nominal commission from the transaction. Their RESTful API exposes users’ abilities to enable, modify, or delete their links and more. It responds in JSON.
InboxFever API: The service enables sending and receiving email, along with a feedback function for monitoring communication success, including creation and processing of email, open rates, link clicks within the message, bounce rates, deferral, and related statistics.
API methods support sending email, including recipient address lists, subject lines, message body, etc., as well as retrieving replies and in-bound email. Reporting methods allow access to statistics like messages sent and received, open and bounce rates, link clicks, etc.
Inuvo PPC Search API: Inuvo offers solutions that help advertisers drive transactions via clicks, sales or leads through various marketing channels. The Inuvo Platform gives advertisers the ability to create and manage campaigns, and allows web publishers with a way to monetize their advertising inventory. Partners can use the API to customize their implementation of the platform. The PPC API lets Inuvo, through a partnership with Yahoo, to provide a sponsored search xml feed giving publishers the opportunity to make money from site or application searches. Full documentation is not publicly available.
Involver Engagement Optimization API: Involver is a social media marketing platform used on Facebook pages and other social media platforms. The Engagement Optimization API allows marketers to optimize their ad campaigns by passing optimization data to the ad platform of their choice. With it social advertising platforms can pull page engagement data from the platform to optimize ad spend. Marketers can also optimize ad spend by integrating page management with their ad platforms using real-time response from their audiences. Public documentation is not available, developers should contact the provider for more information.
Keynote API: Keynote is a provider of Internet and mobile cloud testing and monitoring. Companies use Keynote to know how their web sites, content, and applications perform across browsers, networks, and mobile devices.
The Keynote API lets developers integrate and automate Keynote with other systems and services. Users can use the API to access Keynote measurement data and account information programmatically. With this data, developers can build their own dashboards, create custom reports and more. The API uses RESTful calls and responses are formatted in XML and JSON.
LAITS GMU Coverage API: The LAITS GMU Coverage API is a geospatial coverage retrieval service based on the OpenGIS Web Coverage Service Interface Standard. Types of data categorized as "coverages" may include satellite images, digital aerial photos, digital elevation data, and other phenomena represented by values given at each measurement point. The LAITS GMU Coverage API uses the XML data format and operates over SOAP.
LandslideCRM API: LandslideCRM is a customer relationship management system for enterprises engaged in online sales. This system provides real-time, anywhere access to leads, contacts, information, reports, and more. The LandslideCRM API allows users to access many of LandslideCRM's functions programmatically via SOAP calls.
LiveDocx MailMerge API: LiveDocx is a template-based document creation service. It allows developers to create word processing documents by combining user-defined Microsoft Word templates with data from disparate sources, such as XML files and databases. It is typically used to create professional, print-ready documents in DOCX, DOC, RTF, or PDF format. The LiveDocx API makes these functions available programmatically via SOAP calls.
Lunapic API: Lunapic is an online photo editing processor. Users can upload images from their computers or link image URLs to add effects, crop, and more. Users can also add multiple images to one project and create an animation. The API provides total access to the website’s functionality. Users can send requests including multiple parameters and actions.
Memopal API: Memopal offers cloud based online storage that tries to make storage more efficient. The technology behind Memopal looks for the similarities across all data that users upload, store those parts and then save only the changes that are made to that data. The simple API allows users to download files from their account. The API uses RESTful calls and responses are formatted in JSON.
Microsoft Office Research API: Microsoft Office Research is a feature offered in a number of different Microsoft Office programs. This feature provides access to resources such as dictionaries, thesauri, and various internet research web sites. The Microsoft Office Research API allows registered users to access these services programmatically via SOAP API.
Microsoft SensorMap DataHub API: SensorMap is a tool created by Microsoft to allow non-tech-savvy users to easily publish their data online in a format that is simple to query and is compatible with other data types. The Microsoft SensorMap DataHub API allows users to make realtime data available or to retrieve data from SensorMap.
MixRank API: MixRank is a spy tool that tracks users’ competitors’ advertisements. It provides analytics on where competitors buy traffic, which of their ads perform best, and more. The API provides access on-site information on ads, advertisers, and traffic sources. This allows developers to generate custom reports from queries to MixRank’s entire historical database. The API is currently private, but can be accessed by requesting permission from MixRank.
MokiMobility +MDM API: MokiMobility provides a cloud-based mobile device management (MDM) platform allowing developers to manage iOS and Android devices remotely. +MDM is a platform for developers to create single-purpose solutions for iPads and Android tablets. +MDM and it's APIs offer features such as: add/remove Wifi settings, add/remove apps, require passcodes, remote rebooting of Android tablets and more. Full documentation is not publicly available.
Molinspiration API: The service provides tools for cheminformatics such as generating images of molecules and modeling, processing, and manipulating molecular properties and structures. It works with SMILES notation to allow SDfile conversions and generate representations of molecules and fragments. The service can screen results based on molecular fragments and predict biological activity of compounds represented.
API methods support submission of compounds in SMILES chemical notation. Returned data include molecular characteristics needed to fully characterize and modify the compound specified in the request.
Mugshot API: The experimental service processes images from uploaded files or URLs and performs simple face detection. It displays coordinates for faces present in the image along with a browser-viewable version of the image with faces highlighted.
API methods support either uploading a file or specifying a URL along with a request to the service. Returned data include coordinates of faces within the images and URLs for viewable images with faces highlighted.
Northtext API: The service provides basic SMS text messaging integrated with marketing and campaign management functions for targeted management of promotional contacts. Functionality includes control of messaging activity by keywords defining groups of campaigns and accounts.
API methods support specification of message content, recipients (either single or bulk delivery), and timing of message delivery. Methods also support management of contact lists and campaigns, defined by user-assigned keywords.
OCLC EprintsUK API: OCLC (Online Computer Library Center) is a worldwide library cooperative, the purpose of which is to establish, maintain, and operate a computerized library network. The OCLC EprintsUK API focuses on authority control. Authority control is the practice of creating and maintaining index terms for bibliographic material in the library catalog.
Offorte API: Offorte is online quotation software that lets users create online proposals and quotes. Users can extend their proposals using social media, video, photos, notices and statistics. Offorte offers an API that allows customers to access their account data. Documentation is not publicly available.
Phospho.ELM API: Phospho.ELM is a database of experimentally verified phosphorylation sites in eukaryotic proteins. The database currently contains 8,718 substrate proteins from different species, covering more than 42,500 instances which are fully linked to literature references. The Phospho.ELM API allows users to access this database programmatically.
Pictaculous API: Pictaculous is a color palette generator service from MailChimps. Users can upload PNG, GIF, or JPG image files and Pictaculous will analyze their colors to return a fitting scheme. Pictaculous's services can also be accessed from a mobile device. Their API accepts binary file data from the acceptable image format types and returns a JSON encoded hex of recommended colors as well as a URL of the received image.
PositionMonitor API: PositionMonitor is an automatic page rank monitoring system. Users input their website’s URL and search keyword, and PositionMonitor will check its Google, Bing, and Yahoo ranks everyday. Over time, it will also graph the site’s movement. The API exposes the entirety of PositionMonitor’s functionality with fees for some higher level services such as research and webshots. It is a RESTful protocol that returns JSON results.
Sapo Galp Fast API: SAPO is a Portuguese Internet service provider whose main web site acts as a web portal featuring a directory of Portuguese sites. SAPO Services provides a large suite of web services and applications to developers worldwide.
The Sapo Galp Fast system allows users to accumulate point when they purchase gas at Galp stations. The points, accumlated via the Fast card, can be redeemed for services or products offered at partcipating service stations. The API lets users see what catalog items they are eligible to acquire, return customer data and return current points accumulated on a card. The API uses REST and SOAP calls and resposes are formatted in XML.
ScienceSeeker API: ScienceSeeker collects articles from science blogs around the world, allows users to find the latest science news and discussion on any topic. The database includes more than 1,000 blogs and 120,000 posts. The Search API lets users query the database using a number of sorting options such as title, summary, number of recommendations, or posts talking about a specific peer-reviewed article. Developers can integrate the functionality of the API with third party sites or applications. It uses HTTP calls and responses are formatted in XML.
Scripted API: Scripted is a service that provides blog content from a pool of registered writers. Business request a blog post on any subject or length, and Scripted matches the prompt to a freelance writer to produce the content. Their RESTful API exposes most of the sites functionality, for business and for writers. It responds in JSON automatically but users can request XML instead.
Simple Texting API: Simple Texting offers text message marketing services. The API gives users access to much of the functionality of the platform. Functionality includes the ability to send sms messages, receive inbox messages, check keyword availability, rent and configure keywords, configure forwarding, list contacts and more. The API uses RESTful calls.
SKOS Thesaurus API: The SKOS (Simple Knowledge Organization System) Thesaurus API provided by Oak Ridge National Laboratory is a tool for organizing knowledge and concept relationships. Users can provide a concept and then retrieve other concepts that relate to it. This API can be accessed via SOAP calls using the XML data format.
Skyttle API: Market Sentinel is a UK based company that provides clients with online conversation monitoring. Skyttle is Market Sentinel's text analytics engine. Skyttle extracts patters from textual data through the use of Natural Language Processing (NLP). The API can take text and turn it into constituent terms (meaningful expressions), entities (names of people, place and things), and sentiment terms. Languages supported are English, Spanish, French, German, Chinese, Swedish, Greek, Czech, Italian and Russian. The API uses RESTful calls and responses are formatted in JSON.
SMSGuys API: The service provides SMS text messaging in South Africa, either for bulk delivery or by individual messages. Applications can trigger delivery immediately or schedule messages for future delivery. The system maintains an address book with delivery numbers for each user account.
API methods support specification of message content and recipient, either an individual number or a list for bulk delivery. Messages can be routed for immediate delivery or scheduled for later delivery. Methods also support address book management, with contact list addition, updating, and delete.
St. Louis FRED API: The Federal Reserve Bank of St. Louis is one of 12 regional Reserve banks in the Fed System. The Research Division of the bank looks to promote quality economic research and contribute to economic policy discussions. In support of this goal, it has created APIs that let developers access the data stored on its web site.
The FRED API lets users query the Federal Reserve Economic Data (FRED) and Archival Federal Reserve Economic Data (ALFRED) databases to retrieve specific data. The requested data can be customized according to data source, release, category, series, and other preferences. The API uses RESTful calls and responses are formatted in XML.
Svpply API: Svpply is a social marketplace for users who want to share items they like or have purchased on the web. Users add items they find online to their Svpply bookmarklet that transfers the items to the public Svpply shop page. The API is RESTful and responds in JSON. Access to collections of products, permalinks, users, and more of the shop’s functionality is exposed through it.
Swiftype API: Swiftype provides search engines for websites. Developers can implant it on their website to design their own site-specific search results. Swiftype has autocomplete capabilities, search analytics, and customizable results. The API is a RESTful protocol and returns results in JSON. It can provides access to many Swiftype functionalities including indexing, searching, and more. The documentation includes Ruby and Python kits. Swiftype is currently available for free in beta, but tiered price structure is to come.
Thinkudo Enlighten API: Thinkudo Enlighten is a platform that allows companies to better understand the Chinese market. The platform provides users with social media analytics allowing for better decision making. Its API services provide Chinese text analytics, social media search, sentiment analysis and more allowing companies to create social monitoring dashboards. The API uses RESTful calls and responses are formatted in JSON.
TracksGiving API: Tracksgiving is a backend platform built to track charitable giving initiatives. Its goal is to add more transparency and accountability to the giving process. The TracksGiving APIs offer functionality for tracking donation logs, orders, and giving campaigns.
University of Toronto Libraries API: The University of Toronto Libraries API allows users to access its Library Management System, the documentation database used for managing and describing library holdings. The University of Toronto uses the Unicorn Library Management System provided by SirsiDynix. This system is accessible via API using SOAP calls.
Unofficial OpenTable API: Open table is an online restaurant reservation service. With the service users can make online reservations, read restaurant reviews from other diners, and earn points towards free meals. This API allows developers to access the data from OpenTable. Data includes finding single or multiple restaurants, along with information about that restaurant and URLs where reservations can be made. The API uses RESTful calls and responses are formatted in JSON.
Västtrafik API: Västtrafik is a public transport company in West Sweden that is responsible for public transport services including buses, trams, ferries and trains in the County of Västra Götaland. The site provides maps, planning services, timetables and more. Västtrafik offers journey planner and departure board APIs for public transport in West Sweden. The journey planner API exposes services including locations, trip, departure board, journey detail and geometry. It uses RESTful calls and responses are formatted in XML and JSON. The site and documentation are in Swedish.
Visual DataFlex Date Functions API: The Visual DataFlex Date Functions API allows users to retrieve the names of days and months in various languages. Users may also determine the default language ID for a system, or retrieve the IDs for other languages. This API can be accessed via SOAP calls using the XML data format.
Visual DataFlex ElfProef API: The Visual DataFlex ElfProef API allows users to perform ElfProef tests. This is a CRC (cyclic redundancy check) technique used as a test in Dutch electronic payments to determine if a bank account number is valid. It does so by adding the given number's digits and dividing by 11. Valid numbers will return an integer. This API can be accessed via SOAP calls using the XML data format.
Visual DataFlex ISBN Validation API: The Visual DataFlex ISBN Validation API allows users to validate ISBN codes that are either 10 or 13 digits long. Note that this API can only determine whether an ISBN number is potentially valid, not which book it is associated with nor whether it is even in use. This API can be accessed via SOAP calls using the XML data format.
Visual DataFlex Temperature Conversion API: The Visual DataFlex Temperature Conversion API converts temperature values from Celcius to Fahrenheit and vice versa. It can also determine windchill temperatures in either Celcius or Farenheit using the Steadman formula. This API can be accessed via SOAP calls using the XML data format.
Wishpot Coupon API: Wishpot is a social shopping service that lets users save and share things they find in stores or online. The items are then organized using online lists or registries that can be shared with others.
The Wishpot coupon service aggregates and normalizes a variety of coupons data sources. The Product Portals retrieve coupons from a single service. These coupons can also be queried via an API. The API uses RESTful calls and responses are formatted in XML.
Wishpot Price Alert API: Wishpot is a social shopping service that lets users save and share things they find in stores or online. The items are then organized using online lists or registries that can be shared with others.
The Wishpot Price alert engines enables any requester to track price changes and trigger alerts on specific URLs. The API uses RESTful calls and responses are formatted in XML.
Wishpot Publisher API: Wishpot is a social shopping service that lets users save and share things they find in stores or online. The items are then organized using online lists or registries that can be shared with others.
The Wishpot publisher API enables publishers to display and monetize products in their web and mobile properties. The API provides access and optimization for all the top CPC and CPA based product providers.
Wishpot Social Commerce API: Wishpot is a social shopping service that lets users save and share things they find in stores or online. The items are then organized using online lists or registries that can be shared with others.
The Wishpot Social Commerce framework enables developers to build social, mobile and web commerce applications. Users can build marketplaces, specific mobile shops, dedicated apps, and more. Cart and checkout scenarios are supported through PayPal. The API uses RESTful calls and responses are formatted in XML.
WorkingPoint API: WorkingPoint is a small business software solutions package. It provides a bundle of tools for accounting, invoicing, and tax and financial reporting. These tools are all accessible on business dashboard. The API exposes the invoice, bill, item, and contact functionalities. It is a RESTful API that returns JSON responses.
Yellowfin Business Intelligence API: The service provides performance tracking, charting, and reporting services with a variety of options for displaying and formatting business intelligence to support decision making. Charts and indicators can be assembled and embedded in multiple ways to meet varying needs for documenting business activity.
API methods support specification of input data sources and display formats, including time scales and user controls for aggregating data or drilling down to greater detail. Methods allow filtering of data to compose varying views for different audiences.
Sponsored by
Shelley Powers (Burningbird) — Homogeneity
homogeneity: noun
composition from like parts, elements, or characteristics
Not long ago, Molly Holzschlag tweeted an innocuous comment:
I'd love to see a woman or group of women edit the HTML5 spec. It'd make for an interesting social experiment. Certainly would be a first.
I re-tweeted her without additional comment, and that started a sequence of responses that surprised me in their vehement rejection of "positive discrimination"—as if the only way that women could possibly be involved in editing the HTML5 spec is because of the result of some kind of reverse discrimination.
Craig Grannel caught the byplay and sent me an email asking if I'd be willing to be interviewed for .net magazine, not only about the tweets, but comments I made about the W3C and sexism. Discussions on this topic have not gone well in the past, and I didn't expect any positive dialog from this interview, but as the saying goes: hope springs eternal.
The interview appeared in Call for greater diversity in web community. I thought that Craig did a decent job of taking my disjointed thoughts and punching them into a coherent whole, but I also decided to publish my full comments. There were a couple of points I made in my response that I wanted to emphasize.
> - How do you think the HTML WG would benefit from female leadership, or, at least, more women being involved? In what ways do you think the "dynamics of an all male leadership" have been negative?
I can't give you a sound bite, because there is a back story to these communications. I guess I'll have to trust that what I write will either not be used, or won't be used in such a way as to cause more problems.
Women are underrepresented in the tech field, but they're even more underrepresented in W3C working groups. Even with the recent addition of a woman to the TAG group, men in leadership positions in the W3C and in W3C working groups is disproportionate.
Unfortunately, women also underrepresented among the W3C representatives from the browser companies, which is why I believe the HTML WG is so badly skewed towards the masculine.
The group's entire focus the last few years has been on basically giving the WhatWG members representing a few of the browser companies whatever they want. The procedures put in place to demonstrate a more "egalitarian" viewpoint have actually done the opposite.
If you've followed along the effort over the years, the debacle over the longdesc attribute, an accessibility aid, is representative of how badly the change process procedures have failed.
And that might be one key to some of the problems women have had in the group. Most of the women participating in the HTML WG have come in from the accessibility movement, and the people interested in accessibility have long been recipients of disdain and derision--typically expressed outside the group, true, but impacting on group dynamics.
However, what happens in public concerns me less than what happens in private. I'm not the only woman who has received a "tsk tsk, must behave better" email from the HTML WG chairs and members. The chairs say they've sent emails of like nature to guys, too, but there's a different flavor to the communications--a patronizing tone that just sets my teeth on edge.
One time, I addressed some of my concerns in an email to www-archives--the dump hole for W3C communications--about my perceptions of sexism in the HTML WG group, and a W3C staff member wrote me to chastise--literally chastise me--telling me that he showed the communications that led to my emails to his girlfriend. and she didn't see anything sexist about them.
As if we women all think alike, like some kind of single celled organism that shows absolutely no differentiation.
Tell me something: do you think the exact same thing as all the men you know? Do you perceive writings the same way? Do you all share the exact same opinions? Then why the heck would any of you expect the same from women?
I actually did formally complain to W3C leadership about my concerns about the HTML WG and underlying, subtle sexism, and their handling of the complaint was appalling. They turned around and communicated my complaint to the HTML WG co-chairs, one of whom sent me a blistering email in response. It was impossible to work with the group after that, and I've had little respect for the W3C management since.
Now I'm greatly concerned, because I'm seeing the same disdain and patronizing attitude directed to an HTML WG member who has been with the group for years, fighting for accessibility. I've watched her become disillusioned, and go from being an active, engaged member, to someone who rarely participates at all.
It's not right.
Can more women in leadership help? I honestly can't say whether we could or not, but I'd like to think it would help to have more women in positions of responsibility and authority. At a minimum, we couldn't make it any worse that what it is. Frankly, the group is too homogeneous. It really doesn't represent the broader Web community.
> - You said: "How about encouraging more women to get involved, rather than chasing out most who were?" What did you mean by that? (Note: from some of the responses in your feed, I can certainly infer, but it'd be good to get your thinking on this.)
I don't want to speak for other women, I can only speak for myself.
I left the HTML WG group. I just couldn't handle the emails telling me to behave, the chastisement, as if I'm a little girl and they're all Daddy. I have better things to do with my time than be condescended to.
What's been frustrating about my decision to leave, though, is people telling me now that "If you don't like what's happening with HTML5, get involved", when I was involved at one time, and had to leave.
What's even more frustrating is an attitude I see from many men and women involved in technology, especially as it relates to the W3C: unless a guy points out that sexism exists, it doesn't exist.
Sexism isn't always overt. It isn't always some guy showing a slide with a naked woman's bum during a tech conference. Sexism can be as much slow erosion as sudden explosion. Women feeling as if we're ignored, that we're patronized, that our contributions weigh less--sexism is as much about subtle perception, as it is about blatant acts.
In my opinion, the W3C, in general, and the HTML WG, in particular, have problems with sexism.
And every time I say this, I get slammed. So here we go again.
Ian Devlin wrote what I felt was a disappointing response to the .net magazine article.
What I did have issue with however, was what I saw as the implied notion that a woman would be better at doing the job of HTML5 editor simply because of her sex.
Isn’t that just as bad as saying that a man would be better at the task at hand simply because he is a man? Such a comment would, quite correctly, cause uproar. Granted the implication probably wasn’t intended, but I think that it was this perceived attitude that started the debate.
No one ever implied that women would do better just because we're women. This was never said: in Molly's comment, in my responses, or in the article. The real focus in all of the remarks was on the lack of diversity in the W3C leadership, and among the working groups. Not only are women not well represented, but even among the men there is little diversity. Those who have defined the HTML5 spec display a remarkable similarity in thought and opinion, matched only by an almost complete lack of empathy.
Could women help? Good lord, we couldn't make matters worse.
There's a second component to my comments, though, that I wanted to re-emphasize: that sexism isn't always overt acts. In fact, I don't really care about overt sexism. Acts of this nature tend to self-implode, and they don't need me to light a match. No, it's the subtle form of sexism that bothers me. As I wrote in the interview response, subtle forms of sexism erode over time. There is rarely anything anyone can point to and say, "Aha! Sexism!" But in the back of you mind, there exists a feeling that no matter what you do or say, you won't be heard, your concerns will not be addressed, your input really isn't welcome.
You just kind of drift away.
Even now, when we have a fresh opportunity to discuss the issues, to address the lack of diversity in the W3C, our concerns are rejected as "positive discrimination". That's the same as saying how dare we hit that fist with our face.
Just as an aside: I did volunteer to be a co-editor of HTML5, back in 2008, I believe it was. My offer was rejected.
-
<script type="text/javascript">
//><!--
da2a.script_load();
//--><!
</script>
ProgrammableWeb — 16 APIs Used in 7 Days: Facebook, New York Times and Klout
This past week 9 new mashups were added to our mashup directory and 16 different APIs were used to build them. Some of the newer or less frequently seen APIs include 500px, Direct Textbook, Google Street View Image and HasOffers. The most often used APIs this week are Facebook, Flickr and Twitter. And the most commonly used types of APIs were Photos (3 APIs, 4 mashups), Social (3 APIs, 8 mashups) and Internet (2 APIs, 3 mashups). The list below shows which APIs were used by which mashups:
Basecamp used in SimplySubscribe.Me
Direct Textbook used in BookBargain
Facebook used in BookBargain, Picomp'it, SimplySubscribe.Me
Flickr used in Picomp'it, Statsr
foursquare used in SimplySubscribe.Me
Google Gmail OAuth used in SimplySubscribe.Me
Google Maps used in localiz.me
Google Spreadsheets used in Leaderboarded
Google Street View Image used in localiz.me
HasOffers used in hasLockers
Klout used in Leaderboarded
MailChimp used in SimplySubscribe.Me
New York Times Best Sellers used in BookBargain
Twitter used in BookBargain, Leaderboarded, Malva Weather, Moment
Mashups of the day:
And each day there is one mashup selected to be Mashup of the Day. Here are last week’s winners:
Sponsored by
ProgrammableWeb: APIs — Yellowfin Business Intelligence
Business intelligence reporting and dashboarding serviceFootnotes
News and views on Web development, from Web developers, Web-tool developer, Web-spec authors/editors
Subscriptions
Amazon Web Services
- Andy Budd (Clearleft)
- Andy Hume (Clearleft)
- Anne van Kesteren (Opera)
-
-
- Ben Buchanan (200ok)
- Bob DuCharme (Innodata Isogen)
- Cameron Moll
-
- Daniel Glazman (Disruptive Innovations)
- Dave Beckett (Yahoo!)
- Dave Shea
- David Heinemeier Hansson (Rails)
- David Megginson
-
- Derek Featherstone (Further Ahead)
- Doug Schepers (Vectoreal)
- Edd Dumbill (Useful Information Company)
- Elias Torres (IBM)
- Elliotte Rusty Harold
- Fiftyfoureleven
- Fumiaki Yoshimatsu (Amazon)
- Fuming
- Gavin Bell (Nature Publishing Group)
- Google Gears
- Hallvord R. M. Steen (Opera)
- Henry Sivonen
-
- Ian Hickson (Google)
- James Clark
- James Edwards (Brothercake)
- Jason Diamond (DevelopMentor)
- Jeff Barr (Amazon)
- Jeremy Keith (Adactio)
- Jirka Kosek
- John Boyer (IBM)
- Kevin Lawver
- Marcos Caceres (QUT)
- Mark Birbeck (IBM)
-
- Matt Biddulph (Hackdiary)
- Matt Webb (Schulze & Webb)
- Micah Dubinko (Yahoo!)
- Nicholas C. Zakas (Yahoo!)
- Norman Walsh (Sun)
- Ovidiu Predescu (Google)
- Paul Downey (British Telecom)
-
- ProgrammableWeb
- Gumroad Aims To Make Selling Items as Simple as Sharing Them
- Why REST Keeps Me Up At Night
- API Strategy Lessons from Factual’s Upgrade of its Mobile/Local APIs
- 45 Coupons APIs: Groupon, 8coupons and US Yellow Pages
- Gecko Landmarks is Changing the Face of the Mapping Industry
- 71 New APIs: Wishpot, Gecko and Optical Character Recognition
- 16 APIs Used in 7 Days: Facebook, New York Times and Klout
- ProgrammableWeb: APIs
- TauP
- Visual DataFlex Football Pool
- Visual DataFlex Country Information
- eCoComa Geo
- Teleportd
- SmartPea Grocery
- FAROO
- eCoComa Email
- eCoComa Domain
- eCoComa Convert
- eCoComa Video
- eCoComa RSS
- eCoComa Marketing
- Music Xray S2O Partner
- Budget Your Trip
- FixYa
- iOpenAt.com
- For Wanted
- Informatica Cloud
- HelloFax
- MasterCard PayPass Online
- Nimbuzz
- Travelocity
- Betfair Games
- Raven Slingshot
- Inbox25
- Papirus
- MESSAGEmanager
- DeliveryWatch
- SirsiDynix Symphony
- DRCOG
- Online Whois Lookup
- UN Comtrade
- New Dawn ACM
- Svpply
- Yellowfin Business Intelligence
- Ralph Meijer (Jaiku)
-
-
-
- Roger Johansson (456 Berea St)
- Ryan Sarver (SkyHook Wireless)
-
- Sam Ruby (IBM)
- Shelley Powers (Burningbird)
- Simon St.Laurent (O'Reilly)
- Simon Willison (Django)
-
- Tatsuhiko Miyagawa (Six Apart)
- Thomas Vander Wal (InfoCloud)
- Tom Coates (Yahoo!)
- Uche & Chimezie Ogbuji
- WHATWG blog
- Web Analyst
- Web-Graphics
-
- Yahoo! UI blog
- developerWorks: Web Development
- Export OPML | FOAF