iLikeIt

Two days have passed after the announcement of iPad. A lot has been said, written, twitted about Apple's latest product. But I have something to add too.

There are three things I would like to say about iPad, that I haven't seen emphasized elsewhere. That's what this post is about.

1. One plane of interaction.

iPad will be the first product of its kind - a laptop size screen (almost) and a laptop size keyboard (virtual albeit) merged in one plane. All the laptops (and desktops) that we've ever used in our lives, have had two planes of interaction. A horizontal plane that takes keyboard input and a vertical plane that emits monitor output. With iPad these two planes are going to merge. I don't know if it is good or bad, but I think it's the first time and don't know how our brains will react to that change. We definitely imagined this is how our future interfaces will be, but now that such a product is here, we will actually know if that is what we want. Will we find it awkward that we now are doing both input and output in the same plane. I don't know. From the promos, it seems apple did a great job in keeping the keyboard simple. Let's see how that works out.

2. It's Apple Inside Out

It's the first time Apple has delivered a product that runs on a processor built by Apple themselves. That means, it's the first time that each and every part of iPad has been designed and built inside Apple. I think it's interesting in various aspects. 

It's every product designer's fantasy that he/she has control over every tiny piece of their product's component (own the whole stack). However only few in the computing industry have achieved that status. Think of Sony, Nintendo. Apple has joined their ranks. However, Sony and Nintendo's products are niche (gaming consoles or music gadgets), whereas Apple is building general purpose computing products. Moreover Apple gets design, they have a style and they have established a fan following. What this means is Apple is now all too powerful. They can use that power to reach newer heights in product design. On the flip side however, they can use this power to restrict access to their system. They have already shown it in the form of iPhone app store. Apple products excel in user interface, but they block every other kind of interface.

3. Future is here

Criticize whatever you want in Apple products, but one thing is undeniable - they are pushing consumer electronics into the future. And not just with lab prototypes, but with main-stream, mass-manufactured, affordable products. Designers have always thought of products like iPad, something that feels like a simple slate rather than a powerful computer. Few have created their own prototypes of the concept or even niche products (take graphics tablets from Wacom, Microsoft Surface), but Apple will deserve the credit for bringing such a futuristic product to our kitchens.


Footnote: 
In case you are wondering about where I am on the Apple fanboy scale:


I like Apple's products, though I won't call myself a Apple fanboy. I think they are the best designers of computing industry. I have owned only two Apple products so far, a 4th generation iPod and a Macbook. I've been pretty happy with them. I have never owned an iPhone, mostly because it is too restricted a device to play with. Android is the best choice for smart phones in today's date - open enough to play with and with good enough design that gets the job done.


Ads:
* CaseCrown Faux Suede Zip Sleeve Case (Black) to Carry the Apple iPad Wifi / 3G Model 16GB, 32GB, 64GB
* Apple iPad Soft-Shell Eva Foam Case by Protec (Silver)
* Archos 9 PC Tablet (Black)

ReaderScope v1.7 - Widget, new Icons and .... Ads

Last night I released ReaderScope v1.7.

It now comes with a simple yet useful home screen widget.

You can tap on the news and it will be opened in the regular viewer that you see in the main app. The icon in the upper left corner, opens the full app. The icon in the lower right corner refreshes the news items in the widget. This refresh icon however, will only work with the Value pack (previously known as Theme pack, it costs only $2.49)

v1.7 comes with more stylized icons. They are also made DPI specific, so users with high DPI devices (Droid, Nexus One), will see better icons now.



And last but not the least. In this version I added an Ad-bar on the news reading screen. It is part of the basic free app. You can get rid of it by installing the Value pack.

[If you have donated to ReaderScope in the past, you are entitled to a free unlock code of the value pack. I've sent them yesterday to all the three donors. If you haven't received them or having any troubles using them, please let me know.]

Let me know what you think of the new widget, icons and the ads.

Cheers!

on Git: tips for SVN users and Git in Dropbox cloud

I gave in to the hype of Distributed VCS and decided to learn Git about 6 months ago (No, it's not a hype, even for single person projects). I started managing my latest projects with Git. Learning Git was not a cake walk, but I put my faith in Git's promise of power and climbed the beginning slope of the learning curve. If you are switching to git after using Subversion for years, then this slope can be steeper. But now I am comfortable with my Git setup and starting to see the glimpses of power that git has to offer.

Here are few tips for subversion users shifting to Git, which could have saved me some agony when I was new.

1. How can I do svn revert in Git?

Believe it or not, but you do that with git checkout . When I first learned that, I was shocked. (And the best part is, the manpage of git-checkout talks about this functionality only in 3rd paragraph and in not so clear words). Over time you will find out that "checkout" is highly overloaded sub-command in git. Besides reverting your changes, it is used to switch to new branch, or create a new branch altogether. Its semantics are nothing like svn checkout. (The closest git analogue of svn co would be git clone, but not exactly)

2. What's all about branching being easy in Git?

Once your projects starts to grow beyond certain size, you appreciate the ease of branch management that Git provides. But it takes little effort to understand it. In Subversion, the central repository lies on a web server or a backed up disk partition. You as a user, "checkout" a local copy of it. In Git as well, there can be a center repository (but it's not necessary), however you do not checkout code from it. You as a user "clone" the entire repository. Because the entire repository is available locally, creating, deleting and switching between branches is very fast. Others don't see your branches unless you create a corresponding remote branch on central repository (check git push and --track option of git checkout to find out more about it)

3. Here are two useful git subcommands that I wish were more publicized, rather than documented like corner cases.

stash

When you start using multiple branches, more often than not you are faced with a situation where you have some uncommitted code in branch B, but to fix a customer reported crash you want to immediately switch to branch A. When I first faced this situation, all I could find was do a commit and switch the branch. After some later point I accidentally  came across 'git stash' and found how handy it was.

cherry-pick

You are working on some new feature in branch B and you find a critical bug while doing it. You find the  fix for it and you want to release it immediately without waiting for this feature to complete. Your releases are built from branch A (from which you create B). Commit your fix in branch B (don't include any feature code in that commit), then git the SHA id of that commit to cherry-pick.

4. git mergetool
Git has the most intuitive conflict resolution mechanism in the form of git-mergetool. Actually, I am not sure if it's git or (g)vimdiff that deserves the credit (or both). After doing merges across branches, if you end up with conflicts, then use git mergetool --tool=vimdiff (git may automatically prompt you for this). I have done some merges with Perforce in the past (they call it crossport, integrate, etc.), and suffice it to say it was bad enough for me to avoid that task altogether. But the three windowed diff view makes this task as intuitive as possible.

5. Best Git GUI I've found so far: Git-cola

6. Book recommendation: Progit (It's Free. It explains different use cases with examples and that helps a lot)

Now on to the second part of the post. Something that I discovered recently. First understand that, you don't need any central repository to git-fy your project. You have a directory of source files and you want to start tracking it with git, just do git init and you are good to go. git-add, git-commit, git branching all can be done after this point.

However, in little bigger use cases you need a central repository. In my case, I work on same project from two different machines located at two different locations. I could create my git repository on USB key and carry it around with me. But it's not reliable - media corruption, physical loss, theft - you get the point. So it's advisable to have your central repo in cloud.

I rented such service from repositoryhosting.com for $6 per month. They provide many other project management tools in the package too, but I primarily used it for git. Recently I started using Dropbox. Although Dropbox storage resides in cloud, they have done perfect job of exporting it as native file system. More importantly it works on all three platforms. So for all practical purposes (that I have covered in last two weeks at least), it's a native file system, but magically synced across different machines. So I just created the git clone of my git repositories in one of the folders inside Dropbox. I can now push and pull to/from this repository on different machines. See this post for detailed instructions.

Dropbox comes with 2GB of free storage and by doing some referrals you can stretch it up to 2.5GB. It's plenty for versioning source code files, don't you think? Be careful not to version big files though (release binaries for instance), you won't be able to free up space by removing them once they are in the repository.

I hope you found the git tips useful. Hoping to explore more of git.

Anti Asserts

I couldn't help but make this name up after I thought about it in that sense.

Putting Asserts at various points in your code is a good practice. With Asserts you express your assumptions about the state of your program at the particular point in execution. When the program runs, it verifies if your assumptions actually hold or not. Asserts are the simplest form of a test case.

Consequently, what I call Anti Assert is bad. Where Assert gives you an opportunity to test your assumption at certain point in code, Anti Assert will rob you off such opportunities.

Anti Asserts are more dangerous, because we introduce them unknowingly. Where Assert is one definite line of code, Anti Assert is essentially invisible or hidden under the guise of routine code logic.

So what is Anti Assert?

Simply put - it is the unnecessary checks that we put in our code, and more specifically the superfluous NULL checks.

Why call them Anti Assert?

This is how we use asserts.

// ...

TheObject obj = x.findObject();

assert(obj != null);

obj.performY();

// ...

In the above code, if under some scenario obj turns out to be null, then we will very likely learn about it during early development/testing.

And this is what I call anti-assert.

// ...

TheObject obj = x.findObject();

if(obj != null) obj.performY();

// ...

In this code we not only omitted the assert, but we did a null check before calling a method on obj. Doing a null-check before de-referencing is considered a smart thing (especially if it is the C/C++ code), but do you realize that this only postpones the disaster?

By doing a null check we avoided a failure while calling performY, but somewhere down the code path obj might still get dereferenced, and in worst case that will happen only on customer site.

The tendency to put such cautionary null checks is justifiable in C/C++ code. In the native code a NULL pointer dereferencing will lead to segmentation fault, and unless it happens on a debug build the developer won't know what went wrong. So the coders working in C/C++ or having a prior background in those languages will tend to introduce Anti-Asserts.

In Java or other managed languages, if a pointer turns out to be null, the worst that can happen is a program crash with well-defined stack trace. With proper mechanisms, such crash reports can be easily retrieved even from customer sites. So there is no justification for introducing Anti-asserts when coding in managed languages.

One way to avoid introducing Anti-asserts is understanding the API contract carefully. If an API function is not supposed to return null, then we shouldn't put a check for it. That way, if it indeed returns null, it will be exposed by a crash (with some luck during early testing). Or the best practice would be to put an assert, with an arrangement to remove it from production code. This thread on Stack overflow gives ample information on this subject.

This is not something new, but just a re-emphasis of what we already observe but fail to recognize.

Bono's top ten list

I just came across this op-ed piece by Bono for NY Times via my Twitter stream. It has so many quotable quotes that a simple retweet won't justify how much I enjoyed it. I would dare say this list is most interesting of the top-ten lists I have read during this turn of the decade. It includes topics from Social-Political solutions in Africa to Teleportation to Piracy to sexy cars.

Here are my favorite quotes, but I would hate it if you read them out of context, so read the full article too if you have time.

It hurts me to say this about democracy (and I know because my band is one), but rarely does majority rule produce something of beauty.

- On designing sexy cars. This has been said many times, but still many don't get it.

The only thing protecting the movie and TV industries from the fate that has befallen music and indeed the newspaper business is the size of the files.

- On piracy. I don't fully agree with the rest of Bono's comments in the same section though. 

By this accounting, your average Ethiopian can sell her underpolluting ways (people in Ethiopia emit about 0.1 ton of carbon a year) to the average American (about 20 tons a year) and use the proceeds to deal with the effects of climate change (like drought), educate her kids and send them to university

- On global warming. This is one fresh thought I've heard on the matter.

... if there’s a breakthrough in the Mideast peace process. The idea is an arts festival that celebrates the origin of the three Abrahamic religions: Judaism, Christianity and Islam. Every year it could be held in a different location; Jerusalem would obviously be the best place to start.

- On peace solutions in Middle east. Again very fresh thought.

Make Android speak your Twits with "TwitSpeak"

Happy New Year All.

I thought what could be a better way to wish Happy New Year than to release a new Android app ... and make the source open.

So here is a fun little app TwitSpeak.

Just tap the icon and it will read your latest twit to you. How's that? Give it a shot.

And as I said, the complete source code of the app is out in the open, under Android's favorite licese APL 2.0.

http://code.google.com/p/twitspeak

(Tip for developers: If you were looking forward to integrating Twitter in your app and found the OAuth tricky to implement, you have ready to use code now. and it is under APL 2.0. Go, grab it).

You can get it from Android Market or get the apk.