Screaming Penguin

The Java Language Specification

kebernet — Sat, 14 Aug 2010 03:33:19 +0000

Snoracle is suing Google. From the header of the Java Language Specification:

Sun Microsystems, Inc. (SUN) hereby grants to you a fully paid, nonexclusive, nontransferable, perpetual, worldwide limited license (without the right to sublicense) under SUN's intellectual property rights that are essential to practice this specification. This license allows and is limited to the creation and distribution of clean room implementations of this specification that:
(i) include a complete implementation of the current version of this specification without subsetting or supersetting;
(ii) implement all the interfaces and functionality of the required packages of the Java 2 Platform, Standard Edition, as defined by SUN, without subsetting or supersetting;
(iii) do not add any additional packages, classes, or interfaces to the java.* or javax.* packages or their subpackages;
(iv) pass all test suites relating to the most recent published version of the specification of the Java 2 Platform, Standard Edition, that are available from SUN six (6) months prior to any beta release of the clean room implementation or upgrade thereto;
(v) do not derive from SUN source code or binary materials; and
(vi) do not include any SUN source code or binary materials without an appropriate and separate license from SUN.

Nevermind all of this... I read the patents Snoracle is suing on. Only one of them MIGHT apply to Android: unified memory addressing for polymorphic classes. The rest are about Classload security, which Android doesn't do.

Prediction: Google settles for a tiny amount (<$2m) and changes Android to use a proper MOP anyway, paving the way for Ruby and Python on the platform as first class citizens.

How carriers and device manufacturers are screwing up Android devices

charlie.collins — Tue, 20 Jul 2010 12:58:26 +0000

I love Android. I like the open nature, the architectural approach, and the way the project is managed by the OHA and the AOSP.

What I don't love so much is how carriers and handset manufacturers like to load up new devices with crapware like this:

That's the new Samsung Captivate. Arguably the best Android device AT&T has in its in store lineup (the Nexus One is fantastic, but it's not an in store average consumer choice, and the end is near anyway). In fact the Captivate is one of the best Android phones period, hardware wise. It's got a fantastic large super AMOLED screen, the fastest GPU in any Android phone out right now, a 1GHz CPU, HD video capabilities, Bluetooth 3.0, and it's thin (the thinnest Android device out right now) and light yet feels very solid in your hand.

With all that going for it, what's the problem with the Captivate? Well, it's all that crapware above that CANNOT BE REMOVED (not easily, not by your average consumer). Not only do I not want it, some of it is borderline underhanded gougeware. Several of those apps will *not work on wifi* and if you click into them once they automatically add on features that have additional monthly charges that you get auto-subscribed to (recurring until you unsubscribe). Most of the AT&T apps are also just plain confusing because they duplicate stock Android apps. Why the hell do I need the AT&T music app and the AT&T navigator? Oh, yeah, again, because they force me to use the carrier network (more charges) and they rope me into other AT&T services. Another downside is that AT&T has chosen to disallow the installation of third party apps from outside of the Android Market, that's not a huge problem for most consumers, but it's still a bummer for people that want more choices.

And, you get a bunch of great new contacts too.

One top of the app debacle, and the contact mangling (I'll add those if I want them, thank you) you can also see from the screen shots that you get a different theme and home screen (Launcher) than stock Android too (it's blue and grey, and has different icons, etc.). Apparently, this is the Samsung "TouchWiz" UI.

The colors in the theme actually aren't that bad. The problem is that many built in Android apps expect the stock theme and apparently themselves have colors and graphics customized for it, so it makes for an uglier and less seamless UI overall. That's arguably an issue with said apps (like the Market), but still, it's there. It's not as bad as some other carriers, but the real problem is that it's not what I want and I don't have a choice.

As another example, I also recently got an HTC EVO 4G from Google I/O (thanks Google!). This is also a very impressive hardware device. But, dissapointingly, it's saddled by even more crapware from HTC and Sprint. No, I don't want "Sense UI," thanks, and I don't want your NASCAR app either (or the 30 or so other nonsense apps you stuck on the EVO).

The issue is choice. Sure, some people might want that stuff, but others don't. Don't make your apps part of the system install, and or at least allow me to uninstall them. Also, why not an easy "wipe to stock Android" option (with minor mods for the carriers network, and carriers policies enforced if need be, rather than a full frontal assault of crapware).

It's one of the strengths of Android that carriers and manufacturers *can* do this stuff. It's one of the reasons they likely chose Android in the first place. But that doesn't change the "choice" aspect. Let the consumers decide if they want your "enhanced" UI, and your apps, don't require it.

Carriers (and handset manufacturers) are giving Android a black eye with this "you gotta swallow our stuff" approach. Most consumers aren't going to realize the difference and may not know it's not Android, and or are going to be confused by it. It's a shame, but sadly, it's not unexpected.

Android: Use the ViewHolder Luke, and Larry, and Curly, and Moe

charlie.collins — Sat, 03 Jul 2010 21:54:01 +0000

This is going to be a quick hit blog post about the Android "ViewHolder" pattern. This is a pattern that many people seem to be at least vaguely familiar with, but not very many actually use (based on open source Android applications and examples/books, etc.).

First some background. Larry, Moe, and Curly were characters from . . . ok, not that much background, but to really make use of the ViewHolder with Android you do need to know what the ListView widget is (a helper for managing views of lists), and that ListViews and generally backed by Adapters (adapters provide data for lists and build views for said data, they can be made from lists of stuff in files, or from in memory arrays, or from databases, and so on).

An example of a ListView in action is seen in the screen shot below.

This screen is taken from the DevNexus 2010 demo application I wrote for a conference I attended and spoke at this year. This particular ListView is basically a navigable list of the presentation abstracts and speakers. We will look at the code behind this screen, complete with ViewHolder, coming up. First a bit more background.

You are probably at least vaguely familiar with ListView/Adapter and the related concepts if you have done any Android development at all. ListView is *very* powerful and helpful widget. Nevertheless, ListView's are often misused and abused because there are so many options and settings and patterns that surround them. I don't have time to go into great depth on ListView itself, but for the quick hit I promised I want to address 2 key things to keep in mind when working with ListViews:

Creating views is expensive, you don't want to inflate or manually create new views for every view on the list. ListView can re-use views, if you let it.
Even if you are re-using views, you also don't want to find child views by id (findViewById) every time, because that is expensive too.

I would say that 90% of Android examples or open source apps I see (or developers I talk to) do the first item there properly. Depending on the adapter in play they are re-using views. It's pretty simple, use the "convertView" on simple adapters like ArrayAdapter (which we will see coming up) and use the "newView" on more involved adapters like CursorAdapter. I would also say that the same high percentage of examples and open source apps *do not* use the ViewHolder to avoid trips to findViewById. If your list is small, this might not be a big deal, but if the list is large it can make a difference in terms of frame rate, resource usage, and performance (which equals better experience for the user, longer battery life, etc.). Also, it's a good habit to be in even with small lists, more efficient code is better, especially on a mobile platform.

So how do you do this stuff? Well, here is the Adapter from the aforementioned DevNexus 2010 application to demonstrate:

   class ViewHolder {
      private TextView view1;
      private TextView view2;
   }
   
   private class PresentationAdapter extends ArrayAdapter<Presentation> {

      LayoutInflater vi = (LayoutInflater) PresentationList.this.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
      private final ArrayList<Presentation> presentations;

      public PresentationAdapter(final Context context, final int resId, final ArrayList<Presentation> presentations) {
         super(context, resId, presentations);
         this.presentations = presentations;
      }

      @Override
      public View getView(final int position, final View convertView, final ViewGroup parent) {
         // re-use the convertView, try not to recreate objects here or inflate every time (expensive)
         // also use the "tag" with the "view holder" pattern to avoid findViewById every time
         View v = convertView;
         if (v == null) {
            v = vi.inflate(R.layout.list_items_item, null);
            ViewHolder viewHolder = new ViewHolder();
            viewHolder.view1 = (TextView) v.findViewById(R.id.list_item_above);
            viewHolder.view2 = (TextView) v.findViewById(R.id.list_item_below);
            v.setTag(viewHolder);
         }

         Presentation p = presentations.get(position);
         if (p != null) {
            ViewHolder viewHolder = (ViewHolder) v.getTag();
            viewHolder.view1.setText(p.name);
            viewHolder.view2.setText(p.speaker);            
         }
         return v;
      }
   }

The complete code for the DevNexus application (for context), is here. What we are focusing on above is the Adapter to the ListView. Within it we see that we are making use of the convertView if present to grab our subsequent views, and to populate our own internal ViewHolder representation. If the convertView isn't present, then we do the extra work of inflating our views and building our ViewHolder.

The "convertView" is a convenient helper object provided to you by the framework specifically for re-use (if the framework is ready to provide it, the first item in the list will have a null convertView, hence the check, and the work only if it is null). The framework knows the views that are passing by, and as it recycles them it hands you one that you can "convert."

So what is the ViewHolder? Well, that's really just a simple object we have created (using a package scoped inner class) that stores child views (though you could store anything there, that is all we need for this example). View objects have a "Tag" property that you can use to store any object. If you are getting recycled views anyway, it's very easy and helpful to just stick child views you need *there* and retrieve later, as opposed to calling "findViewById" to pull views from resources for every view in the list. Really this just saves us the findViewById calls. That might not seem like much, but again, in large lists it can cut down on overhead.

A little further down in the code, after we get past creating the convertView in the case that it's null, we see where we use the ViewHolder to get a reference to our subsequent child views, and set stuff (in this case just Strings, but could be anything).

This is a simple example, and I certainly won't promise that it's perfect, but hopefully it does help to explain what ViewHolder is, and why it's useful (and a little about re-cycling views in general).

Software Superstition (Notes on UX/UI from Shortyz)

kebernet — Sun, 27 Jun 2010 06:39:17 +0000

So this is something that has been stewing in my head for a little while, but it still isn't fully baked. Forgive me if it goes a little sideways.

As readers of this space know, I maintain Shortyz, a crossword app -- client, really -- for Android on the market. Honestly, this started out as a "scratch your own itch" FLOSS project for me, but has actually kind of taken off. It is one of the best reviewed "games" on the Market, and the user base is rapidly approaching what can be properly called the tens of thousands.

Lately I have been making a lot of changes to the UI. Nothing I would have considered major, but of course the feedback is generally negative. This I like to call the "Facebook." Any UI changes will pass without acknowledgement from the people that like it, and inspire vitriol from the people that don't. A great example: Recently I changed the progress bar on the browse list view from the stock Android ProgressBar style:horizontal, to a vertical one along the left edge with some color codes. This was actually how I wanted it originally, when I discovered Android doesn't include a style:vertical on ProgressBar (WTF?). Anyway, it makes skimming long lists of puzzles for incomplete puzzles easier, IMHO, and the color coding adds new information about the NYT puzzles. Moreover, I borrowed a lot from Twicca, which I think does a good job of showing that you can make something that looks like "Android" without looking bad. Of course, I get 22 emails from people who hate it, and one from people(?) who like it. Still, I think it is better.

There has been a lot of people who complain on the Market about the lack of Zoom control. Of course, there is a Zoom control, under the Long-Touch context menu on the playboard. I thought this made perfect sense. Long touch is part of the Android metaphor, and I support it everywhere but one place in the app for various functions, but people still don't get it. Is that because Long Touch is a broken action type? I don't know, but it pisses me off when others don't support it. This is kind of tangential, but it does make one significant point: Users don't use the app the way you intend them to. Ever.

The point about superstition comes with something that came up today in the comments on the app. I added a Double-Tap toggle between your standard Zoom setting, and a "Fit to Screen" Zoom (as well as a proto pinch zoom on Froyo). This seemed natural to me because this is kind of how the browser's "Zoom to DOM Element/Zoom Out" mechanic works. I'm not introducing a new action to the user, just copying one that is likely familiar.

The thing I learned is that users learn your software in a very human way:

"Ilan" said that I had confused "Double Tap to change directions" [direction here being across or down] and "Zoom." Actually, the Zoom function was the first time double tap was ever even recorded as an action in the game. To change directions, you can press "Space" on the soft or hard keyboard, or tap the current cursor box. Now a double tap anywhere on the screen previously would change the current cursor box, then change directions, but these were actually two separate actions as far as the app code and design were concerned. This user, however, had interpreted this as "Double Tap changes direction."

We all know users don't read. I have help text. I have all the things you are supposed to have, but some people have a model in their head, and that is how the software should work. The last major upgrade, I implemented four different movement strategies based on the feedback I had gotten on how movement on the board should work. The original version was based on how I wanted it to work, but it became clear there were different camps. That update eliminated ALL of the complaints in my inbox about the movement pattern. The lesson here: Users will play with settings, but they won't read help text. Joe Nuxoll advised me at JPR that my app already had too many user settings. He was wrong. Even if you create a setting to make something idiotic, users will play with it and realize how the default works and go back. They will never read your text about how the default setting works.

But, more importantly, giving these customizations can eliminate "software superstition." That is, the user getting the wrong idea about how the software actually works. Maybe they read that one liner about what the setting does. Maybe they don't. However, you have now given the user a one variable experimental basis to form a new "scientific" (as opposed to "superstitious") mental model of how the software works.

Gmail Disabled - UPDATE

boredatwork — Wed, 16 Jun 2010 12:11:42 +0000

Until today, I would have questioned why anyone would pay for an email service. With all of the free options, specifically Gmail, why would you bother to shell out money for a service. Now I am wondering if I still agree.

Yesterday, I received a phone call from my wife explaining she was locked out of her Gmail account with no explanation. There was a message, explaining to come back at a later time to try again. In addition, there was an option to receive a verification code through SMS or with a Voicemail which I assume you are supposed to be able to submit for an authorization to access your account. The problem we found was we couldn't get to a screen where we could enter the verification code for approval. I found one place where I could dispute there issue, though have no way to verify it was received and will be reviewed. This morning we checked again and the only message we received after attempting to login was "Your Account Has Been Disabled". Of course, this being a free service, they have the right. I believe it is also mentioned in the "Terms of Service" agreement they post when signing up for an account.

Like many folks out there, my wife uses her account for communication, an address book and a file repository. The obvious thing we can say is you should always be responsible and back up important information, though my guess is that is not a common practice.

As I am guessing there are 100's of millions of Gmail accounts out there, it is difficult to provide phone support. At least give an option to download contacts to provide an alert that your account will be disabled in X days. It is free, so I guess you have to live by their rules. Ideally, I would like to get access back, though there are few options left to get assistance. I was thinking about camping out in front of the local Google office until someone helps me; though I am guessing they would call the police at some point.

On a final note, I really enjoyed seeing the "Drink Diet Coke to Gain Weight" in the right rail of the page and is still getting comments after five years - actually five years to the day. Of course the "Lego Porn!" story will always beat it out.

UPDATE: Appears all is resolved with patience. She had her account comprimised and sent a ton of emails to her entire address book at once. Google automatically assumed spam and shut the account down. Appears they do follow-up when you submit an issue form.

TotSP comment issues

charlie.collins — Mon, 14 Jun 2010 16:51:58 +0000

Because of a plethora of douchebags on the interwebs who like to post spam comments here (even with various forms of captcha on, they just do it manually) I have disabled comments for non authenticated posters.

Also, you can't get a new account right now ;). For technical reasons, with a bit of laziness mixed in, TotSP can't send email at the moment.

Until I get the email issue fixed, and account authentication rolling, it will be only existing users that can post comments. After I get the account stuff squared away, new users can either sign up to post comments, or I may make them moderated before they show up.

(The current email thing is because AT&T sucks ass, even more ass than you previously thought they were capable of. Thanks AT&T for blocking port 25, then when I call technical support first asking me what a port is, and next vehemently telling me you don't block any ports. To which I responded, really, a second ago you didn't know what a port was, how do you know you don't block them? Asshole. Then finally after a long hold period telling me you do block it and won't lift it, even for a customer with 10+ years of service, paying for a static IP.)

Kebernet working on 2D/3D graphics for Android in Practice - woot!

charlie.collins — Sat, 12 Jun 2010 15:31:59 +0000

Cooper (kebernet), is doing the 2D/3D chapter for Android in Practice for us (because I know nil about that stuff). The other day he sent me this, just in a hey "check this out" sort of way:

Cooper is awesome, that is all.

HP and WebOS

kebernet — Thu, 03 Jun 2010 00:16:41 +0000

So HP CEO had this quote making the rounds today:

We didn't buy Palm to be in the smartphone business. And I tell people that, but it doesn't seem to resonate well. We bought it for the IP. The WebOS is one of the two ground-up pieces of software that is built as a web operating environment…We have tens of millions of HP small form factor web-connected devices…Now imagine that being a web-connected environment where now you can get a common look and feel and a common set of services laid against that environment. That is a very value proposition.

I completely agree with him. The thing is, in the "PC" market (read: Win32) HP is a dominant player now. They have locked up the the consumer market, and the shift in the whole world is that the consumer market is now the driver in technology, not the "Enterprise."

But what WebOS has going for it is striking. Sure, the Pre is a good phone. The people I know that have one love it. It is web-centric, which is a huge advantage. The advantage, though, isn't just in dev pool...

HP has talked about slates, and sure, that makes 100% sense. They fired MS after Balmer demoed their slate just months ago. First, MS has never gotten serious about metaphor shifting (see Windows for Pen Computing, Surface, Courier). Second, HP at their scale needs to own more IP in the game. HP has introduced their TouchSmart PCs which are basically Win32 boxes with a custom shell layer. Still, the chasm between Win32/WIMP apps and Touch apps is huge. WebOS gives them a lot of new room to play. A good WebOS app can run on the Pre or a Slate with WebOS backed by Linux. It could run on a Win32 TouchSmart machine backed by, let's say, Cygwin as a POSIX layer.

Google threw down the gauntlet to reinvent the "First Screen" (TV) at I/O this year. They and Apple and (somewhat) HP are going to fight over the third screen (Phone/PDA). Apple wants to add a "Fourth Screen" with slates, and Android is chasing them. The big thing here is, HP is the only company that is really in a position to drive recreation of the "Second Screen" (PC). Frankly, I ranted about this before, I think the iPad would have been more compelling if it ran MacOS with UIKit as a layer and LLVM to crossover between "touch" and "WIMP"
apps. I think HP is serious about this as a mode. Replacing the proprietary TouchSmart crap with the (much less proprietary) WebOS layer, but still having a cluster of apps targeted at touch UIs that you can run on a PC is a big deal. Moreover, combined with a new slate business and the Pre, it gives the first serious play across the space, and HP has hugely more marketshare than Apple on that "Second Screen" space already. They could use that to move into the third and fourth screen markets in a big way. Particularly if they can drag the enterprise market with them.

Time to put on the long pants, nerds

kebernet — Mon, 24 May 2010 22:35:24 +0000

Via Chris Adamson: The Geek Test

My scores:

Comics: 1/7 (just not my bag)
TV: Clean sweep
Anime: 5/7
Computers: Sweep
Film: Sweep
Gaming: 6/7
General: 6/7

FroYo is pretty sweet

kebernet — Sun, 23 May 2010 02:43:22 +0000

I am really enjoying it so far. Lots of little changes. Contacts greatly improved. Comes with bundled Twitter app (though I still prefer Twicca) the Twitter app includes a sync source so you can merge contacts and get popup on heads. The JIT and V8 make everything feel just a little bit snappier. The new Market app is 1000% improved with update subscriptions and a bloody "Update All" button. Still need some improved tools on the developer side.

Oh, and I can watch TheDailyShow.com on my phone. SUCK IT!

Curated Computing Sucks

kebernet — Thu, 20 May 2010 05:07:43 +0000

John Gruber, in his infinite cluelessness quotes:

Kontra:

Our museums are not football-field sized warehouses where art objects are indiscriminately dumped and our magazines and blogs are not amorphous containers of randomly selected articles. Our classrooms, restaurants, hospitals and indeed all our civilized institutions are firmly reliant on curation of one kind or another. The goal should be for curators to compete, not for curation to be declared illegal and unholy by the “open” zealots.

★

See, this is the problem. We are comparing "The Internet" or "Computing" to museums, which are uber-constrained by space. The real analogy is to the library. Librarians aren't and don't want to be "curators." The ideal is "everything, ever" is available, and the librarian is a guide. Want information on the latest ornothological research? The librarian is your guy. Want to know about the craziest of Japanese Otaku fetishes? The librarian will get you there.

"Curataion" is about artificial scarcity and, frankly, stupid in the modern world. This is why Google wins at Internet. Because they are all about tweaking for the edge case search. They are a guide, not a curator. Curators are dead or dying. Have you ever actually used Mahalo?

A Tale of Two (and more) Apps

kebernet — Thu, 29 Apr 2010 22:57:26 +0000

This is based on a Lightning talk I gave at the Java Posse Roundup 2010 and again at the GTUG-Atlanta metting for April 2010.

I love crossword puzzles.

In the time before time, I would stop at my local coffee shop and purchase a copy of the New York Times. I would flip to the crossword and with the classic "double fold" begin the crossword puzzle. Mobile devices soon took over the world, and subscribing to the electronic version soon made much more sense than killing all those trees. Last fall, I switched from the orchards of Cupertino to an Android device, alas, there was no good way for me to do the New York Times puzzle on my way to work anymore. Time to start a project.

I developed the original version of Shortyz for Android (named in honor of, and with apologies to, Will Shortyz of the NYT) in about three weekends. It had a number of usability issues and was rough around the edges, but it was "Good Enough for Me." Unfortunately, because of stolen laptop I lost some progress on the source and my market signing key (yeah, I know). So I decided to "do it right." Forgoing the Android classes I implemented my own two-dimensional scrolling, touch handling and rendering code. Now I am quite happy with the results.

Life is good. I am doing crosswords all the time! Enter other people. Pam Fox from Google emails me and asks about a version for Google Wave. Josh Marinacci of Palm IMs me and asks for a WebOS version. To borrow from jwz: "Some people when faced with a problem say, 'I'll use GWT.'" Unlike other technologies, I still only had one problem.

The new Shortyz code was much cleaner. I had implemented a Playboard class as the Controller of my MVC application and was completely independent of the UI code. I moved my IO classes out of the same package as my Model classes, created a .gwt.xml file, and like that, I had the core of a GWT application. Implement a new UI and I am good to go.

Starting with my Android code, I had a playable web application in about five hours. Not bad, but like the first version of the Android code, I had some annoying usability issues and it was a little sluggish. After another day of work, I changed the UI code from using a play->render cycle like the Android app to use a more traditional MVC data binding system (based on Gwittir), and the performance problems were mitigated.

The next step was to take the web app and make it work everywhere! This is where Gin, a Google Guice DI for GWT apps, was key. My initial web app used a client side persistence mechanism to store play data (HTML5 LocalStorage, Gears, DOM Persistence, Flash). This works great for a standalone web app or a gadget, but for a Facebook version or Wave, I need alternative strategies. For my iGoogle version and Wave, I also need to make requests through the gadget.io API. Gin and Guice made this a breeze. Each of my versions simply becomes a new EntryPoint (or Gadget) class, a new Injector, and a new Module definition with the appropriately implemented service classes.

The real challenge game developing the Wave version. While Apache Shindig makes doing local development of Gadgets easy, there isn't an equivalent local harness for Wave gadgets, so you end up having to do a full build and deploy cycle to work on it. There are also some things that aren't clear from the Wave API docs that creep up, such as the maximum size allowed for the State object. After a solid 40 hours of work, though, I had a co-op play Wave gadget with player colors, remote cursors and nice playback support on the Wave.

So what is the take away here? "Extreme Source Compatibility" is a real thing. This is a Java application running on "Everything But The Java Platform" with the bulk of the code easily reused. Each subsequent version of the app took only a few hundred lines of code to get running. There are some important things to keep in mind. First, making sure your business logic and data models without dependencies on lots of external code is important. Since my Model layer was simple POJOs and my Controller layer pretty much just java.lang and java.util, there was a zero-hour ramp up time to make it work. Cleanly separating this code is also important. Since my input handling code and UI code was cleanly separated, this was much easier than it could have been to do the port. Finally, Guice rocks. While a lot of us in the "enterprisey" world understand the testability advantages of using a DI framework, many rarely have to provide lots of alternate implementations of classes. When you need it, though, it is amazingly handy to have a simple way to re-compose your whole application. Best of all, bugs I fixed in the core library while working on the web version rolled right into the original Android version unmodified.

As an interesting aside: GZipped, the GWT version is about the same size as the Android version; both are less than ~100K for the download. Custom code for each version makes up about 10% of the total LoC, with the exception of the Wave version where it is closer to 25%.

Quick colophon:

Wave for GWT via CoboGWave: http://code.google.com/p/cobogwave/

Gadget Support: http://code.google.com/p/gwt-google-apis/

Gin, Guice for GWT: http://code.google.com/p/google-gin/

Data binding, local storage and JSON serialization: http://code.google.com/p/gwittir/

Multiplayer Shortyz for Google Wave

kebernet — Wed, 21 Apr 2010 05:38:27 +0000

For those of you that use Google Wave (crickets) , you can now cooperatively solve crossword puzzles with your friends with Shortyz for Wave .

Celebrating Confederate History

kebernet — Wed, 14 Apr 2010 04:48:32 +0000

At one time, over a century ago, Republicans were all about kicking the ass of seditious bigots.

The TI-85 is a computer, the iPad is a calculator

kebernet — Wed, 14 Apr 2010 02:52:10 +0000

If it isn't Turing-complete (by policy) it is a calculator.