Hello.

Claude Breadboard Kit - a simple way to interface with the Claude API

I explored using LLMs for checking web API browser compatibility. Existing LLMs struggle with outdated data, so I experimented with MDN's Browser Compat Data (BCD). Initial trials using raw BCD JSON with GPT-4 had limitations. To improve this, I converted the BCD into English descriptions of API support and loaded it into a Polymath instance. This allows natural language queries about API compatibility across browsers, like "Is CSS Grid supported in Safari, Firefox, and Chrome?" or "When was CSS acos available in Chrome?". The results are promising, but further refinement is needed to ensure accuracy and reliability.

I've created a tool called "Now Stable" using Browser Compat Data (BCD) to help developers determine when web APIs become stable across different browsers. This addresses the challenge of keeping up with browser updates and helps developers confidently choose APIs for their projects. The tool allows users to select their target browsers (e.g., Chrome, Safari, Firefox) and see a chronological list of when APIs became available across those browsers. I'm looking for feedback on how this tool can be improved and how developers would use this data.

The pace of change in web development, particularly with APIs and browser updates, is overwhelming. The constant deprecation and breaking changes cause friction and highlight a lack of empathy for developers struggling to keep up. While frequent updates are important, the current model, exemplified by Chrome, feels too aggressive. This blog post will explore this tension, examining whether we've pushed developers too far, and discuss strategies for a more sustainable pace of change. It will also touch on platform-specific resources like web.dev and the challenge of balancing innovation with support for the broader developer community.

The web's organic growth, with examples like Google Maps' early API and widespread embeddability, leads to questions about its current design. Would we recreate this structure today? Likely not. This suggests a need for change and migration, but how can this complex transition be managed effectively, especially considering the scale and interconnectedness of the web?

As a data-driven manager, I needed a way to track the performance of our team's numerous NPM packages. Frustrated by the lack of an obvious API, I discovered a hidden gem in the NPM registry documentation. Using this, I created a Google Sheet with custom functions to pull download stats directly. The sheet allows you to track both scoped and non-scoped packages, view data in a table or column format, and easily create charts to visualize trends. Check out the linked sheet and accompanying code to build your own NPM downloads dashboard!

I created a micro-service for generating friendly project names using Zeit's serverless functions and a dictionary of safe words. It's deployed and available at https://friendly-project-name.kinlan.now.sh/. You can use the API endpoint (/api/names) to get random names, specify the number of names with the 'count' parameter, and even customize the separator character. The project is inspired by Glitch's project naming and aims to simplify project creation on Zeit.

This blog post discusses how to integrate Webmentions into a statically generated website built with Hugo, hosted on Zeit. Static sites lack dynamic features like comments, often relying on third-party solutions. This post explores using Webmentions as a decentralized alternative to services like Disqus. It leverages webmention.io as a hub to handle incoming mentions and pingbacks, validating the source and parsing page content. The integration process involves adding link tags to HTML, incorporating the webmention.io API into the build process, and efficiently mapping mention data to individual files for Hugo templates. Finally, a cron job triggers regular site rebuilds via Zeit's deployment API, ensuring timely updates with new mentions.

In the early days of mobile web development, Google Gears played a pivotal role in shaping the APIs we use today. It introduced concepts like local caching, local databases, and background processing, which paved the way for modern APIs such as AppCache, WebSQL, Geolocation, and Web Workers. While WebSQL and AppCache have been replaced by IndexedDB and ServiceWorkers, respectively, the legacy of Gears is undeniable.

The Page Lifecycle API introduces lifecycle states to the web, giving developers control over how their web apps respond to browser actions like tab unloading and backgrounding. This addresses the historical lack of lifecycle management on the web, which has hindered resource optimization, especially on low-powered devices. The API defines system-initiated states for hidden or inactive tabs, allowing browsers to limit resource consumption. Developers gain control through new APIs and events, enabling them to save state before the browser reclaims resources, such as memory, battery, and network. This collaboration between developers and browsers ultimately improves the user experience by increasing web page reliability and responsiveness.

I've always been fascinated by the potential of the web as an API, an idea I first encountered through Michael Mahemoff's work with microformats and CORS. While technologies like Web Intents explored similar concepts, they proved more complex. The core idea remains powerful: enabling direct client-side interaction between websites to bypass the complexities of server-side integrations. Although CORS is widely supported, its complexity hinders adoption. With the rise of client-side generated sites, the need for decentralized integration is stronger than ever. Tools like Comlink, by abstracting the complexities of postMessage and MessageChannel, make it easier to expose and consume client-side APIs. I demonstrated this with a simple example integrating a pubsubhubbub endpoint with a push notification service. This approach offers several advantages, including simplified data transfer, offline capabilities, and secure, controlled exposure of functionality. Looking ahead, I envision a future where every website exposes a consistent, discoverable API, enabling a more interconnected and modular web experience.

I'm excited to share the latest addition to the Shape Detection API: the Text Detection API! This API allows you to detect text within images in real-time, right in the browser. It's still experimental and currently works on Chrome Canary for Android, but it opens up amazing possibilities. Imagine real-time translation, assistive technologies for parsing image content, or even grabbing URLs from slides at conferences. I've built a demo where the API detects text, draws a box around it, and reads it aloud when clicked. Check out the code and demo to experiment yourself. I can't wait to see what you build with this!

I'm excited to share that barcode detection is now available in Chrome Canary via the Shape Detection API! This feature, along with QR code detection, offers a standardized way to access device hardware and bridge the physical and digital worlds. It's especially useful for mobile, eliminating the need for special apps just to scan barcodes. The API is simple: use BarcodeDetector.detect() with an image input to get a promise resolving to a list of barcodes. I've already integrated this into my QR Code Scanner App, and the ability to use it in worker threads is a huge bonus. It's a very promising addition to the web platform and I'm looking forward to seeing what people build with it!

I'm excited to share a new, simple API for sharing on the web called navigator.share! It's available in Chrome Dev Channel on Android and allows websites to connect with native apps for sharing. This is a step towards a better inter-app communication system, simplifying sharing and potentially extending to other app interactions. You can try it now on my blog by clicking the share button. I've updated my blog to use it, falling back to my existing solution if the API isn't available. Check out the ChromeStatus page and other linked resources for more information and give us feedback!

Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.

This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.

We've done a lot of work using Github in the recent past and here is some of the work that we have optimised.

I've run hackathons and learned they're not for winning customers. They're not about startups or brand awareness. They're about learning and improving your product. Treat them like beta tests where developers help find bugs and make your platform better. Focus on making your platform valuable and easy to integrate with. Reward developers for providing feedback, not just cool demos.

Web Intents is a new project designed to solve the problem of web application integration. Inspired by Android's intent system, it allows developers to build features without needing to integrate with every possible 3rd party service. Web Intents lets users choose their preferred service for actions like image editing or sharing. The project has been revised with a simplified API to make integration easier for developers, requiring minimal code. Service registration is done via a new tag, and client initiation is also streamlined. Check out the examples at http://examples.webintents.org/ and share your thoughts as we work with Mozilla to refine this game-changing approach to web development.

In this follow-up tutorial, we enhance the "Post to Buzz" Chrome Extension by adding a share count to the browser action button. This involves making cross-domain requests to the Buzz API's buzzCounter endpoint. We've updated the manifest file to include necessary permissions and added code to background.html to handle tab changes and URL updates. The code retrieves the Buzz count for the current URL and displays it on the browser action button, providing users with real-time feedback on share activity. This subtle update enhances the user experience and provides valuable context within the extension.

Back in February, I presented at TwitterDevNest about getting data in and out of Buzz. The slides are now available on SlideShare. I covered WebFinger, OpenID, Buzz feeds, Pubsubhubbub, and Salmon. I also promised to open-source the demo code, which I'll be pushing to Github later today (covering most of the topics except Salmon).

I'm excited to announce the launch of FriendDeck, a new tool inspired by TweetDeck that enhances the FriendFeed experience. Built on Google App Engine and using jQuery, FriendDeck lets you create persistent searches to track topics in real-time, rather than just seeing your friends' posts. This is particularly helpful for monitoring developing events, as demonstrated by Neville Hobson's use of FriendDeck during the US Airways Hudson River landing. FriendDeck supports a simple query language for searching by keyword, user likes/comments/friends, URLs, domains, and FriendFeed rooms. It also allows posting to FriendFeed directly from the application. Each deck auto-refreshes every minute, and new features like inline commenting are coming soon. Check it out at www.frienddeck.com!

I've integrated Topicala into Facebook, allowing users to search the internet without leaving the platform. Check out the app at http://apps.facebook.com/topicala/. It's easy to use, requires no personal data, and was a breeze to develop. I'd love to hear your feedback!

I've released a new, open-source Microformat parser for .NET, available on Codeplex! This stream-based parser uses a flexible XML configuration to define how microformats like hCard and rel-tag are extracted from HTML/XML, allowing for easy adaptation to spec changes. The provided C# code example demonstrates the simplicity of using the framework to read and process microformat data. Feedback and contributions are welcome!

I've been exploring Windows Live Writer plugins and hit a snag: the API doesn't let plugins access the post's text. This severely limits plugin functionality, preventing things like automated tagging or microformat integration. I've raised this issue on the Windows Live Writer forum and with Microsoft's Joe Cheng, emphasizing the need for text access to enable a wider range of plugins. I encourage other developers to voice similar concerns to Microsoft.

My BBC Programme Calendar to iCal mashup, which converts BBC program data to iCal, works seamlessly with Outlook 2007. Users can easily import program schedules by navigating to their account settings, clicking the internet calendars tab, clicking "new", and entering the URL of the desired program. For example football fans can import the data for the footie http://www.kinlan.co.uk/bbc/football.

I've always been a fan of Yahoo's developer APIs due to their generous usage limits and flexible terms. However, recent changes to their T&Cs are concerning. They now prohibit displaying ads alongside Yahoo API results unless they're Yahoo Ads, and they forbid showing Yahoo search results next to other search engines' results. This impacts sites like Topicala.com and gada.be, as well as many example applications using Google AdSense. While their RSS feed search terms seem more lenient, allowing aggregation with other results and ads, the overall tightening of restrictions stifles innovation. I've updated Topicala.com to use the RSS feed as a workaround. I'm disappointed with Yahoo's approach, as proper attribution should be sufficient, especially when sites like mine prioritize Yahoo results. Until the licensing becomes more flexible, I can't recommend Yahoo's APIs.

I'm building a hierarchical tag directory for Topicala and need your help populating it. You can add tags via the web interface or by using the API: http://www.topicala.com/api/add/[TagName] to add a new tag and http://www.topicala.com/api/add/[ParentTag]/[ChildTag] to create parent/child relationships. Your contributions will eventually allow users to filter search results more effectively.

I've created a tool that converts BBC program listings into iCal format, allowing you to subscribe to a calendar of your favorite shows. Just add the program keyword to the end of "http://www.kinlan.co.uk/bbc/" (e.g., "http://www.kinlan.co.uk/bbc/breakfast") to get the iCal feed. You can then add this feed to Google Calendar, MS Outlook, or other calendar applications to stay updated on program schedules. I'm still developing this, so feedback and suggestions are welcome!

My tag directory has a cool new feature: Amazon product integration! It pulls book data from Amazon AWS related to each tag. Right now, it adds links to relevant products, but I'm thinking of adding images soon. This latest addition brings the total number of Web 2.0 APIs used in my mashup to four, including Delicious, Yahoo Search API, and Google Blog Search RSS. Check out the examples for tags like RDF, RSS, and Mashup to see it in action.

This post is a follow-up to my earlier one about using SOAP requests in ASP.Net to access the eBay API. I've finally figured out how to make it work! A few key things to note: most requests need the "version" attribute, some require the "DetailLevel" attribute, and you'll need an eBay Authentication Token (a cryptographic hash) for security. When using the WSDL URL, remember to include query string parameters so eBay knows what to do. I've included some sample C# code demonstrating how to build the request URL, set credentials, and handle the response.

I'm exploring the eBay API using ASP.NET and SOAP. It's proving a bit cumbersome due to its monolithic structure. Ideally, each API call would have its own WSDL and SOAP interface for easier management. Currently, I'm stuck on generating a User Token for authentication, having tried my developer account, regular eBay account, and a new account without success. Any advice on obtaining a User Token would be greatly appreciated!

I'm puzzled why Microsoft's new Feed Manager API is COM-based instead of a managed API. Given their push for managed code in Vista and .NET's excellent XML handling, a managed API for RSS (which is XML-based) seems logical. It's frustrating to need interop to use this new feature.

I recently discussed the lack of retail web service APIs for major companies like Tesco, Dixon's, and HMV. I've since discovered an ASDA Soap API on maskell.uk.com. I'm impressed by this development, though I'm uncertain how it's implemented (possibly screen scraping). Check it out!

I was excited about the eBay API becoming free, hoping to build programs around it. However, I'm struggling to find a compelling project idea. Integrating it into my blog isn't feasible due to eBay's dynamic nature, and static integration wouldn't benefit my SEO. A potential idea is an AJAX interface for the Amazon books I feature, but my lack of commission potential is demotivating. My programs usually serve my needs first, like my AJAX Tagger, which helps me provide more info to readers. If I come up with any good eBay API ideas, I'll share them here.

I explored XAML databinding with Amazon's REST API, inspired by a Channel 9 RSS reader example. The XAML code fetches data from Amazon and displays it. A key challenge was handling Amazon's default namespace, requiring a NamespaceManager for correct XPath queries. The provided example demonstrates the basic functionality, and it can be expanded upon.

eBay has introduced a free API access program called the Unified Pricing Scheme. This is a significant change that opens up opportunities for developers, like myself, who were previously hesitant to use the API due to usage fees. This new scheme enables thousands of developers to experiment with the eBay API without cost.

I've updated my AJAX Tagger to Version 2! This release adds a simple but useful feature: you can now manually add your own tags in the tag list panel. This is really helpful when the Yahoo Developer Term Extraction API isn't sufficient for tagging, like when you need specific tags such as "C#" and ".Net".

I'm exploring how to improve the relevance of Yahoo Term Extraction API results. My initial question to Yahoo revealed that their system uses a semantic network to relate words and phrases. I'm experimenting with a two-step process: first, extract terms without a query to identify the most relevant term, and second, use that term as a query in a second extraction to refine the results. This might improve relevance, though it doubles the number of API calls. I plan to test this in my DeliTag and AjaxTag applications.

My Wikipedia-based AJAX Tag and AJAX Tag 2 scripts were temporarily broken due to an issue with Yahoo's service. Big thanks to the Yahoo developer team, especially Toby Elliot, for quickly resolving the problem! Of all the Web 2.0 APIs I've used, Yahoo's has the most helpful and responsive support.

I've been exploring the Amazon Web Service API, comparing its REST and SOAP interfaces. Initial impressions suggest the REST API is significantly faster, especially compared to my experiences using the SOAP API with C# and Web References. However, it's worth noting that these observations aren't based on rigorous testing and the different environments (Windows Forms vs. a Linux server on a fast network) could be influencing the perceived performance difference.

I reported two issues with the Yahoo API over the weekend: one regarding the result number restriction not working as expected and another about the contextual term extraction API failing to process text after encountering HTML tags. Yahoo responded promptly on Monday, confirming that one issue is a bug being addressed and the other has already been fixed. I'm very impressed with their responsiveness and quick turnaround.

David Sifry of Technorati reports impressive blogosphere growth, doubling every 5 months and reaching 19.6 million blogs by October 2005. Around 70,000 new blogs are created daily, though spam blogs account for 2-8%. Sifry's data also shows a staggering posting rate, with 700,000-1.3 million new posts daily. While acknowledging Sifry's valuable contribution, I'd like to see more discussion regarding Technorati's API strategy and how they plan to leverage it for future development. Specifically, I'm interested in how Technorati is engaging with the community and incorporating user feedback, especially regarding feature requests on their Wiki.

James Manning left a comment on my blog post about compression, pointing to a Microsoft article about built-in decompression support in .NET 2.0 for SOAP replies. While I appreciate the comment, Yahoo APIs don't use SOAP, so it won't be helpful in that context. However, this information could be useful for working with Amazon APIs, which do have a SOAP interface.

The MSN Search API is now available. I haven't explored it fully yet, but here are some useful links: Why MSN Search?, the MSN Search API download, the SOAP service description, and the developer registration form (requires a .Net Passport). The API appears to be a SOAP service, so I'll likely need to create a proxy for direct calls. The download includes documentation and sample projects. You'll need an application ID, similar to Yahoo's. If you know how to use SOAP with JavaScript, please email me!

I'm trying to be more diligent about documentation, but PDC distractions and the new MSN Search API have me sidetracked. The API's SOAP format and seeming redundancy with existing RSS search options make me question its value. Maybe I'll integrate it into AJAXTagger v2 if I can avoid feature creep. Check out my blog for MSN Search and Start.com developer program resources.

Microsoft's Start.com has launched a new developer API, possibly using the ATLAS framework (precursor to ASP.NET AJAX). It seems to focus on creating JavaScript-based "Gadgets," similar to RSS consumers, that need to be hosted on a server. The API also requires enabling cross-domain data sources in Internet Explorer, a topic I've discussed previously.

This post compares the query limits of free search APIs from different providers. It highlights that MSN Search API reportedly allows up to 10,000 queries per day, but whether that limit is per API or in total is still unclear. The post also notes that Google's Search API allows 1,000 queries per day, Yahoo's APIs allow 5,000 queries per API per day, and Amazon's allows a generous 86,400 queries per day (calculated as 1 query per second). More investigation is needed to confirm the exact limit for MSN.

I'm continuing my rant about Technorati. While my posts eventually get indexed, I agree with Zoli Erdos's point about their terrible communication. Technorati desperately needs better customer support, including a FAQ or knowledge base. Emailing the CEO shouldn't be the only way to get a response. While I appreciate Technorati's free service and API, the lack of support is a major problem.

I've just finished creating a proxy script that allows access to the Yahoo Content Analysis API Term Extraction service from any browser, bypassing cross-site scripting issues. It works by taking a POST request, forwarding it to Yahoo, and returning the XML response. The code (Perl) is included in the post, and I've successfully tested it with IE6, IE7, and Firefox. Feel free to email me if you have any questions.

This blog post introduces a Perl proxy script that leverages the Yahoo Related Suggestions API. Given a search term, the script queries Yahoo and returns a list of related search terms. This can be used to enhance search functionality by providing users with additional relevant search options. An example is given using the term "Kinlan" and the post links to a previous entry describing a proxy for the main Yahoo search API. The provided code snippet demonstrates how to construct the API call using LWP and CGI, requiring a valid Yahoo App ID.

I've previously mentioned the .NET Image Filter Library, and I highly recommend it to anyone interested in learning about programmatic image manipulation. The library is well-documented in an easy-to-follow CodeProject article by Andrew Krillov. You can find it here: Image Processing Lab and Motion Detection. I even created a fisheye filter for this API, which you can find here: Fisheye Example

I'm excited about Technorati's new REST API for blog post tags! It lets developers display all the tags used on a site, which is super helpful. I've even created a simple tool using the API to show all the tags I've used on my site: http://www.kinlan.co.uk/cgi-bin/SiteInfo.pl. The API is easy to use and provides useful stats. I'm already thinking about how to incorporate it into my next project. Great work, Technorati!

This is the fourth installment of my AJAX application development journey. I integrated the Technorati API, focusing on the Tag Query to gauge keyword popularity and refine tag selection for better exposure. While the API was helpful, it lacked features like tag ranking and related tags, and the TagQuery's slow performance forced its removal. Future development will involve optimizing the TagQuery (limiting results or using an asynchronous call manager) and potentially requesting a lightweight metadata interface from Technorati.

The Feedster API has potential, but it's unclear what its purpose is. It would be more useful if it allowed content searches and provided metadata about searches, such as the number of blogs or pages a term appears in. Additional features like showing top searches and providing search result counts could be valuable. The current API requires a private key, which necessitates a proxy script for security. A simpler authentication method like Yahoo's Application ID would be preferred. Despite some limitations, the ability to publish search results as an RSS feed is a nice feature.

My first foray into Ajax was a mixed bag, yielding both valuable lessons and frustrating setbacks. On the plus side, it sparked a deeper understanding of asynchronous coding, cross-browser compatibility (especially between Firefox and IE), and the potential of APIs like Yahoo! and Technorati. It also reignited my interest in Perl and prompted reflection on my blogging practices. However, the application fell short in several areas: it lacked search functionality, didn't reduce bandwidth, had a poor visual design, and wasn't user-friendly or impactful enough to generate feedback or traffic. Moving forward, I'll share my design process and desired improvements, starting with a clear requirements document. I'm eager to learn from this experience and create a more effective application.

This blog post presents the results of my initial experiment with Amazon Web Service. I've compiled a list of various products, including books and a DVD, with links to their respective pages on Amazon.co.uk. This appears to be an early exploration of the possibilities of integrating Amazon's product data.

I'm exploring different web services, particularly for UK retailers like Tesco, Asda, or Virgin. I've tried Amazon's, which is decent, and Yahoo's, which I like. Ebay's looks interesting, but I'd rather not pay. I'm also looking at Alexa's and Google's. It's tough finding good resources on this, especially for UK retailers. I'd love to see APIs from companies like Tescos, Asda, Dixons, and others. If you know of any good web services, especially in the UK retail space, please share!

I've been exploring Amazon's SOAP API and Yahoo's REST API and I'm quite impressed with both. I'm thinking about ways to make these two APIs interact and will share my ideas in a future post. I've also been working on using REST in .Net 1.1, which is a little tricky but possible, thanks to Martin G. Brown's work. The process involves using an XSD of the response, running it through XSD.exe to generate a Dataset object, and then processing the results. It's a similar concept to WSDL, but without the automatic stub generation. I'll post some Yahoo API code examples soon. I plan to look into Google's API as well, even though it's in beta with usage restrictions.