I recently released a simple API to un-shorten URLs. A few people wanted a super-simple interface to this, so I whipped one up: https://keita.blog/unroll/. Enjoy!
Some notes about the tools I’ve used:
Just like the service that runs the API, the UI is also open-source. Hack away!
As a small side project, I recently launched a “link unroller” service. This is a very simple service. You give it a URI, and it follows any redirect chain for you. Then it spits out the final URI via a friendly JSON API.
Give it a spin:
https://unroll.kbys.me/unroll?uri=http://bit.ly/1QZ6acT
Basically, all you do is send a GET request to:
https://unroll.kbys.me/unroll?uri=<URI to unroll>
Done. If there are no problems, you will get a JSON response:
{
"uri":"http://bit.ly/1QZ6acT",
"unrolled_uri":"https://keita.blog/",
"redirect_path":[
"http://bit.ly/1QZ6acT",
"http://keita.blog/"
],
"error":false
}
The unrolled_uri parameter is the final link in the chain, and the redirect_path is an array of the links that were traversed.
If you’d like to take a look at the code, make some contributions, or submit some bugs, please head over to the GitHub page.
Technical details:
Policy details:
Cache-Control or Expires headers present in the response.
I recently released my first app on the Mac App Store, Toki, and I decided that talking about the inner workings of the sync mechanism I’m using would not only be interesting, but helpful for me to think about some of the problems I’m having[footnote]This is inspired by the “Vesper Sync Diary” series of blog posts by Brent Simmons[/footnote].
Toki uses an App.net sync mechanism that I’ve been thinking about and working on for a while — I thought that Toki would be a good low-profile app to test out some ideas in real-world use.
Although Toki is a production app, the sync portion is not feature-complete yet. I’m working on ironing out the basic bugs (planned to be released in 1.0.1 and 1.0.2 releases), before moving on to the more advanced features. My “end goal” for the App.net sync mechanism is an open-source multi-platform library that anyone can use in their own app to use the App.net backend to keep their objects synchronized[footnote]There already has been some work been done with a Ruby-based command-line client.[/footnote]. From now on (and until I think of a better name), I will call this sync mechanism “App.net Object Sync” or “ADNOS”.
ADNOS uses the private message / channel feature of the App.net API, using a channel for the app namespace, and a message representing each object.
There are two fundamental steps of the sync protocol (as of version 1.0.2, still in development):
This has some limits, some inherent in the protocol, and some inherent in the App.net backend:
These limits are pretty much unavoidable. I work around the rate-limiting problem by queueing sync up requests, and pausing the queue when X-RateLimit-Remaining gets dangerously low. The queue is re-started after X-RateLimit-Reset elapses. Any app that plans on using ADNOS will want to be aware of these limitations before implementing it.
And, now for the features I’m planning on implementing (in no particular order):
I’ll be writing more as I progress. I hope to get some sort of open-source library out there in the near future.
In the past few weeks, I’ve found myself demonstrating how to do things on my computer for other people. You know, screenshots, screencasts, the like.
I ran into a small problem: Most of the people I need to teach don’t understand English.
And my default user interface is in English.
So, I ran into this little trick:
$ [path to app]/Contents/MacOS/[app name] -AppleLanguages '([language code])'
That little bit of Terminal code will launch that app in the specified language code you entered, if supported by that application. For those of you who don’t have 10 terminal windows open at any given time, don’t worry! I’ve made something for you too. 🙂
Drop an app onto “langchooser”, and it will show you all the languages that app supports. Choose the language, then click “OK”.
Now, I can continue with my screenshots and screencasts without having to switch user accounts! やったー！
A few days ago, I posted a small JavaScript snippet.
Retina, Please! is that JavaScript snippet on steroids. It is a combination of JavaScript and PHP to allow your Retina users to only download Retina images, while non-Retina users only download the standard-resolution version.
Check it out: https://github.com/keichan34/KKRetinaPlease
WordPress Theme Writers: just require it in your functions.php. I may package it into a real plugin later on.
I’ve tested it with CakePHP as well.