Meant to replicate the feeling of the “new arrivals” section of a used bookstore. You sign up under the casual, steady, or addicted plans, then we send you three to five books at a time. These books are arbitrary and basically unselected (we track to make sure you haven’t already received the book, but that’s it). Do what you want then send them back and we’ll send you another three/five books.
Alternatively, donate books to us. We’ll send you a box to ship them in and maybe even give you a month free or something.
Actually, that would be an effective way to start up: people send in their books and get up to that many books back for free.
The differences between the plans are the number of books sent at once and the frequency with which we ship books. Casual is one shipment of three books per month, while addicted is eight shipments of five books per month. There is an extra plan where they pay by the shipment, calculated to only be useful for people who need more than eight shipments per month.
A generalized service for polling a HTTP resource so you don’t have to.
The Observer Server has a list of URLs to hit, how frequently to hit them, and who to tell once they’ve changed. Observers register with the server and maintain a persistent TCP connection (to avoid NAT issues; can possibly be changed once IPv6 actually happens).
Example ideas: FOAFster (distributed Friendster/MySpace/Facebook using FOAFs); RSS reader; Campfire implementation; a 4chan plugin for Firefox.
This can be made easier with libraries for various implementations; a libobserver for C; an observer.js; a Ruby gem probably called something irrelevant like Golden Hawk; pyObserver for Python; and so on.
An Android finger server, client, and editor, with callbacks.
Edit your .plan file, and serve it “from your phone” (really from a remote server). Also finger other users either by phone number or username@server.
On update of your .plan it can run a series of callbacks: tweet, FTP the .plan, ssh-execute a path passing .plan as stdin, perform a HTTP POST passing the .plan as an argument, and other ideas like this.
All mail clients for Android suck; this one sucks less.
This MUA will start as IMAP-only, but is otherwise largely inspired by mutt. The main UI is the mail index, which shows a super-condensed, threaded list of all emails, showing only the subject. However the email under the cursor becomes expanded to have a reasonable amount of padding, plus the thread is automatically expanded. Use right/left to move in/out of the thread, and up/down to move between threads. Long-press on a message to have the option to delete, reply, reply all, copy, move, tag (in the mutt sense of tagging), untag.
The index menu offers “new”, “tag”, “settings”, “about”, “change folder”. When something is tagged (again, in the mutt sense) the menu also has “untag” and “perform on tagged” (or shorter). You can tag by specifying a pattern (much like T in mutt) and similarly mass untag in the same way. On all tagged messages you can delete, move, copy (much like ; in mutt).
Composing a reply (or new email) autofills the from, subject, Cc, To. It also gives you the option of adding custom headers. The body of the email is pre-filled with the text you are replying to, and your cursor is placed at the bottom. Your sig is automatically added.
Server app/infrastructure layout: how IRC clients (and all network clients) should be done
IRC bouncers exist but are the least possible thing that could work, and it shows. Instead it should work like this:
The client-controller runs on your VPS, where your screen session or bouncer currently runs. It is interacted with entirely through IRC clients. These clients tell the client-controller which servers to connect to, but also which channel to show in the client, where they last read, which plugins and bots to run, what to search for in the current channel, and everything else that clients do currently. This should all be done on the client-controller instead, and the client becomes a view into that client-controller.
IRC is a free-for-all of customizability, so the client-controller needs to handle custom plugins, but it also needs to be replaceable. It must speak a simple and documented protocol and use libraries extensively (libirc, but also … libircclientcontroller?).
Something similar exists in Smuxi currently but it is locked into .NET. C’mon.
Upon more reflection it makes sense for most client-server networked tools to exist like this. Imagine using w3m to follow along with Epiphany; liferea to follow Google Reader; Evolution to follow mutt; and so on.
Initial setup: username and password, or API key. Then you see a list of your projects. Selecting one shows exceptions for that project, with tabs for the different environments. The menu here allows you to view resolved exceptions instead, to change project, to manage settings, and to view the about screen. Selecting an exception shows the details: backtrace, environment, similar exceptions. The menu there allows you to mark it resolved and to view more details in the browser.
An Android-app mockup generator that makes it easy to prototype a user experience without full functionality.
The main screen is four panes. The leftmost pane is all the available widgets (buttons, text entries, spinners, etc); to the right of that is the current screen’s layout as a tree; to the right are the properties for that widget; to the right of that is a real-time update of the screen. Users drag from the widget pane to the layout tree pane.
You can set the onClick for any clickable widget (which is everything, I think), and point that at a new screen.
A plugin infrastructure is supported, tied in with Android Parts. Also have integration with a community Web site for sharing these mockups.
A centralized place to share JARs and Android Libraries for building your app. The Java community is unlike any other I’ve seen in that they don’t reuse code well. No CPAN-like place, no big presence on Github, etc. This Web site attempts to fix that, for Android.
Visitors can search and find JARs written by others they can download or purchase. They can search on license, maintainer, organization, minimum Android SDK, tags, name, description. They can additionally search using a command-line tool (like the `gem’ command for Ruby) or an Eclipse plugin. Android Parts also hosts Javadoc and CI for any open source packages.
Once signed in (via OpenID) a maintainer can add a new package or add a new version of a package.
Presents one app per day. This app’s only criteria is that it’s beautiful; it doesn’t need to be new, indie, functional, free, or anything else. It just needs to be beautiful. From the screen you can view the app in the market (or one-button install it using the market), swipe left/right to see the prior/next day’s beautiful app, or view a menu with “suggest” and “about” as options (along with “prior” and “next”), both of which open a toast.
Web app/Internet service: c2dmer. Better name pending.
C2DM is a great way to send data to an Android device, but requires you to run your own server. This is a Web service that lets you configure a data source and maybe a little language for manipulating it, then it sends C2DM data to your app.
