buru on brails

Type q
For more information about recording type :help recording in Vim

The answer to this question is so obvious for most hardcore geekoids that noone bothers to write about it. I had always used either pure X-less console or some sort of DE-specific terminal emulator (Konsole, GNOME Terminal, XFterm, LXterminal etc), but recently switched to Fluxbox and got bothered by annoyingly small default XTerm font. Luckily, this problem is easily solved:

1. Modify your ~/.Xdefaults file (create this file if it doesn't exist) adding the following lines:
   

   XTerm*font:     *-fixed-*-*-*-18-*
   XTerm*boldFont: *-fixed-*-*-*-18-*

   
   
2. Add the following command to your startup script (or run in terminal to check it out):
   

   xrdb -merge ~/.Xdefaults

3. Thats all!

.Xdefaults settings also affect aterm (XTerm's more advanced brother, which has some nice features like fast pseudo-transparency support and NeXT-ish scrollbar) and possibly other XTerm or rxvt-based terminal emulators.

Another less-known feature of XTerm is that it has GUI menus. Main menu is invoked with hold Ctrl + Left Click and font options menu with hold Ctrl + Right Click. Surely, you may modify font size from font options menu (see example below).

As you might already know, Google recently opened its Enterprise Marketplace - a centralized place for SaaS applications, integrated with GoogleApps. We at Comindwork integrated our service with GoogleApps long before the announcement, so, logically, we rushed to submit our service to the Marketplace, as it offered a powerful distribution channel.
However, to meet the requirements of Google Market, we should have implemented one more feature: login via Google's OpenID. This task proved to be tougher than we thought, so we decided to share its solution with fellow ASP.Net developers.
The trouble is that Google uses non-standard OpenID implementation. The only .Net OpenID library that supports Google's implementation is DotNetOpenAuth 3.4+
Here's how to make authentication work in a few simple steps:
1. Download DotNetOpenAuth 3.4 or later.
2. Set up a sample application named "OpenIdRelyingPartyWebForms". No need to open it in VS, just add it to IIS as a web site.
3. Modify sample's web.config
4. Run the sample, open loginGoogleApps.aspx, fill in the only form on the page with your Google apps domain and submit (if this doesn't work, try submitting your email instead of your domain, e.g. buru@bla.com instead of bla.com)
5. If the sample worked, copy loginGoogleApps.aspx and loginGoogleApps.aspx.cs to your application, modify it accordingly (for example, modify master page reference). Don't forget to modify your web.config if this page throws security exception. Also, don't forget to add DotNetOpenAuth.dll to your /bin directory.
6. Modify loginGoogleApps.aspx.cs Page_Load to handle the "domain" request param. Simple example:

protected void Page_Load(object sender, EventArgs e) {
    if(Request["domain"] != null && Request["domain"] != String.Empty) {
        this.OpenIdLoginBoxCtrl.Text = Request["domain"];
        this.OpenIdLoginBoxCtrl.ReturnToUrl = Utility.BaseUrl +  "loginGoogleApps.aspx";
        OpenIdLoginBoxCtrl.LogOn();
    }
}

7. Modify your application OpenIDTextBox handler to include your authentication logic. In the simplest case it will look like this:

protected void ProcessLoggedIn(object sender, OpenIdEventArgs e) {          
    string identity = e.Response.ClaimedIdentifier;
    var sreg = e.Response.GetExtension<claimsresponse>(); 
            
    // the association between your internal account and Google Apps account
    IExternalSourceInfo externalSourceInfo = GetExternalSourceInfo("OpenID",identity);

    if (!externalSourceInfo.Exists || !InternalAccountExists(externalSourceInfo)) {
        ProcessNoExternalSourceInfo(externalSourceInfo,identity,sreg);
    }
    else {
        LogIn(externalSourceInfo);  
    }
 }

8. Test it all. It should work, really :)
9. Add some security double-checks, like checking whether response comes from Google. Something like this:

if(!e.Response.Provider.Uri.AbsoluteUri.StartsWith("https://www.google.com")) {
    throw new Exception("hacker detected!");
}

Authentication via Google's OpenID is the first, but not the hardest step on a road to Google Marketplace submission. The integration process is specific to your application, but still, there are a few general rules you should remember:

1. Don't prompt Google Apps user for any new login and password during application installation, or Google will reject your submission (it is opposed to Google Marketplace policy). Just silently create an account in your system, using Google Apps' data. Authenticate this account only via Google Apps.
2. Use your application GoogleAppsConsumerKey and GoogleAppsConsumerKeySecret to retrieve user data. Example:

  string appName = "YourAppName";
  var requestFactory = new GOAuthRequestFactory(AppsNameTable.GAppsService, appName);
  requestFactory.ConsumerKey = "YourGoogleAppsConsumerKey";
  requestFactory.ConsumerSecret = "YourGoogleAppsConsumerKeySecret"; 
            
  UserService userAccountService = new UserService(appName);
  userAccountService.RequestFactory = requestFactory;

  UserQuery query = new UserQuery(domain);
  query.UserName = username;
  query.OAuthRequestorId = email;

  UserFeed feed = (UserFeed)userAccountService.Query(query);
  UserEntry user = feed.Entries[0] as UserEntry;
                        
  string firstName = user.Name.GivenName;
  string lastName = user.Name.FamilyName;

3. If your application have users from both Google Apps and outer world, implement a clear way to distinguish between those two kinds of users. Apart from obvious difference in functionality for different kinds of users, you'll need to track whether a user came from Google or not later on when payment system will be integrated with Google Marketplace (remember, when it happens, 20% of your revenue from Marketplace users goes to Google).

Well, I guess that's all you need to know to get started.

As for our own experiences with the Marketplace, it is rather promising. Comindwork is on the Marketplace and is doing pretty well. We're seeing constant registrations stream from the Marketplace, and it is growing over time. Still, it is small in comparison to our main registrations stream, but we expect it to grow faster when Google Marketplace goes out of beta.

Just got a crazy idea, which I couldn't fit in 140 characters or less, so posting it here.
What if humans are in fact the machines, constructed by a spiritual civilization of old? Just like we're creating robots and trying to enhance them with artificial intelligence, those spiritual beings created life as we know it and enhanced it with artificial model of their intelligence. Here's where our duality comes from: our "software" (spirit, intelligence) share a lot in common with that of our creators, while our "hardware" (physical body) has its own constraints.
What happened to our creators next? Maybe, humans destroyed them; maybe they got extinct by themselves; maybe they are still around watching us.
If we think of it this way, then to say our ancestors are monkeys is exactly the same as to say that intelligent robot's ancestors are toasters or refrigerators: surely, they have something in common, but it's the software what really matters, not the hardware.

Technically, both Maemo and Android run on Linux kernels. However, Maemo is a full Linux distro, based on Debian, while Android is a sole kernel with a few programs on top of it (namely, Dalvik virtual machine and Sqlite database). On Adnroid all applications run within Dalvik virtual machine, which is heavily optimized and modified version of Java virtual machine (JVM). I tried to analyze the benefits of each platform from the perspective of a software developer, as well as platforms' current "strategic position". If you are too busy to read all the details, there is a short summary paragraph at the end of each chapter.

Android vs Maemo from developer's perspective

Development.

Maemo SDK is Linux-only. It's not a problem for me (as Linux is my OS of choice), but it may be a problem for many developers. SDK works best on Debian or Debian-based distros (e.g. Ubuntu). Maemo is also a Debian-based distro, so SDK simply uses Scratchbox cross-compilation toolkit to build for both x86 and ARM architectures.
Maemo applications are developed in GTK+ using Hildon application framework. Naturally, the primary language of Maemo application development is C. Other languages can also be used, as GTK+ has bindings for many programming languages, including C++, Java, C#, Ruby etc. However, most applications will be developed in C, mainly due to performance constraints, which are especially actual for mobile devices. GTK+ itself is a bit archaic by today's standards, and although Hildon is specifically targeted for touch-screen interfaces, most of work is still done in GTK+ and good old C. Thus, the development platform is not on par with modern mobile application development environments such as iPhone SDK, Android SDK, or Palm WebOS Mojo SDK. This may change with Maemo 6 release (codenamed "Harmattan") when Qt libraries will be supported and Qt will become Maemo official application development framework. But this will happen somewhere in 2011, so for now Maemo application development is a step behind that of Android.
Update: As multiple commenters pointed out, Qt should be already used for Maemo application development. It's a modern way to develop cross-platform apps that will run on both Maemo and Symbian OS (as well as Windows/Mac OS X/Linux, although it may not be practical to use similar UI for both desktop and mobile software). The earlier Qt becomes official application development framework for Maemo and Symbian OS, the better.

Android SDK is available for Windows, Linux, and Mac OS X. Applications are developed in Java and the development platform is really easy to get into. It features XML (DSL) for GUI interface building, easy strings internationalization, app storage within SQLite database, background processes management etc. To make a long story short, it's how modern mobile application development platform should look like. The only downside is that all applications are in Java, and for some developers Java became the synonym of slowness (although it's not that slow on Android, as Dalvik VM is specifically optimized for running on it). For such developers, there is an option of using Native Android SDK, although its capabilities are very limited, especially in hardware access department.

Porting existing applications.

In this area, Maemo has a huge advantage over Android, as it's a full Debian based distro. With the help of Scratchbox Cross Compilation Toolkit many open-source tools can be compiled for ARM architecture. A number of command line utilities can be ported with a simple cross-compilation, GUI apps usually require UI rewrite, but anyway it's much easier to port open-source app to Maemo than to write it from scratch. Some of the famous open-source apps are already ported to Maemo: MPlayer, Pidgin, Gnumeric, Abiword and many others.
On Android, porting an open-source app from x86 Linux is almost as hard as porting an app from any other platform: all UI and logic has to be rewritten from scratch.

Summary: Development is easier on Android platform, while porting existing apps is easier for Maemo platform. 

Strategic position

Both platforms are aimed at the same vertical market: smartphones – MIDs – netbooks. Maemo is backed by Nokia alone, while Android is backed by Open Handset Alliance, whose members include Google, Samsung, LG, Motorola, HTC, Acer and others. Nokia may be the largest mobile phone and smartphone manufacturer on the planet, but it cannot compete with such a might. Thus, it's obvious that in the nearest future Android devices will outnumber Maemo devices by a large margin. There should be 18 Android devices released by the end of the year, while there will be only 4 Maemo devices released by that time (Nokia N770, N800, N810, N900). Even if N900 and new Maemo MIDs, and finally netbooks will sell better than their Android counterparts, the total install base of Android devices will grow faster than that of Maemo devices. The larger install base, the more OS is interesting for developers (assuming, it has a decent app dev platform). Nokia's main competitors - Samsung and LG - will use Android as a competitive advantage, and throw their development and marketing efforts behind this platform. Motorola is trying to save itself with its MOTOCLIQ aggressive pricing and MOTOBLUR Android software, and it has the chances to succeed!. Under the circumstances, Maemo becomes Nokia's main competitive advantage, so the company should throw its efforts behind it or lose market leadership. The position of fierce competition ensures the bright future for both platforms. However, which platform will finally win is another question, and perhaps the most interesting one. The logical winner is Android: it'll have larger install base in the nearest future; more developers will work on apps for Android; it is backed by powerful corporations, mighty Google among them. Nevertheless, there is a single power that can keep Maemo up float and possibly even make it prevail in the long term: open-source community. You'd argue: both Maemo and Android are open source. It doesn't matter. What matters is whether the platform could benefit from countless man-years of efforts, done by open-source community. Android benefits only from Linux kernel development and a small number of other open-source projects, all Android apps have to be written from scratch. Contrary to that, any open-source project which runs on Linux indirectly contributes into Maemo software ecosystem (as it can be relatively easily ported). Maemo has to use this to its own advantage, or it has no chance against Android. Thus, Maemo core developers should make this advantage even bigger by easing the process of porting open-source apps to Maemo, which can be achieved by migrating from ARM to x86 at some point.
Another advantage of Maemo is that it's more suitable for larger devices - MIDs and netbooks. Maemo was designed to run on MIDs, and it already proved its worth in this area. Being a Debian-based distro, Maemo will probably fit well on touchscreen netbooks as well. Android looks good on smartphones, but it remains to be seen whether it will be enough for netbooks. There is a chance that Android will succeed on smartphone market, while Maemo will prevail on MIDs and netbooks.

Summary: Android has better strategic position at the moment: Android devices will outnumber Maemo devices in the nearest future, it will also have more developers (better development platform + larger install base). Still, Maemo can win after all if it plays nicely with open-source community and utilizes its tremendous work. Another Maemo advantage is that it's better for MIDs and netbooks.


Post scriptum

Either Android or Maemo, Linux will win after all :)

Post post scriptum

As much as you may prefer Android, Maemo, or other smartphone OS, the ideal situation for smartphone market as a whole would be healthy competition between a few major platforms, not a single platform dominance. Maemo and Android are both open-source and overly good operating systems, so it will be good if they become those dominate platforms, not killing each other, but competing in equilibrium for years, bringing innovation along the way.


Update

For more insights and opinions on topic, please read the comments below and the article's discussions on Reddit, and Maemo Talk.
Summarizing the opinions, I've listed the following advantages of each platform:

Android advantages:

1. Binary compatibility between releases. Technically, it's byte code compatibility in Android's case. Maemo lacks it, which means hard time for developers with every new release.
2. Android is better positioned at mid-end smartphone market, where it will compete with Symbian OS.

Maemo advantages:

1. Better game development, especially cross-platform game development.
2. Qt can (and should!) be used for cross-platform development for both Maemo and Symbian OS, which equals developing with modern app dev framework for the largest smartphone install base.

Yet another update


The article was translated into Russian and posted on Habrahabr by one of it's users, and triggered an interesting discussion there (Habrahabr is Russian Slashdot-like community). So, if you know Russian, you might be interested in reading the discussion here.

While developing Facebook application I got stuck with "Session key invalid or no longer valid" error. Googling for it gave me lots of results, but not a single solution! So, after finally dealing with it, I decided to blog about it to help fellow Facebook developers and not to forget about the solution myself.

First of all, check out whether your app is authorized with Facebook by going to the following address in the browser window where you got the exception:

http://www.facebook.com/login.php?api_key=YOUR_APP_KEY&next=RETURN_URL

After that, you have to create Facebook API object to work with. Here's the example in C# (using .Net Facebook Developer Toolkit), principles for other platforms remain the same:


facebook.API api = new facebook.API();
api.ApplicationKey = "YOUR_APP_KEY";
api.Secret = "YOUR_SECRET_KEY";
api.SessionKey = HttpContext.Current.Request.Cookies["YOUR_APP_KEY" + "_session_key"].Value;
int userID = -1;
int.TryParse(HttpContext.Current.Request.Cookies["YOUR_APP_KEY" + "_user"), out userID);
api.uid = userID;



The key line of code here is the one when you're setting API session key. It is tempting (and natural!) to take the session key from request by using Request["fb_sig_session_key"], but for some mysterious reason this results in "Session key invalid or no longer valid" error. The only way to circumvent this ugly bug that I'm aware of is to take session key from cookie, not from request. That's it, after setting session key to "YOUR_APP_KEY_session_key" cookie I had no problems with this issue.
After that, just use the API object as usual. For example, in terms of .Net Facebook Developer Toolkit, use the following code to get a list your friends ids:


api.friends.get();


1. Fast. Vim may be hard to learn, but when you master it, you'll be editing fast, very fast. Typing with all 10 fingers, ultra fast navigation within file, numeric modifier for commands ("10dd" - cuts 10 lines), repeated commands with ".", macros, and zillions of key-combos at your disposal - all this makes Vim by far the fastest editor on the planet.
2. Good for health. With Vim you do not have to use mouse at all. Even if you're using Vim's graphical implementation like gVim or MacVim, you absolutely do not need to touch you mouse at all, everything is much easier and faster to do from the keyboard. Considering the fact that you use mouse very frequently in most of other programs, your right hand tires much faster than your left hand. With Vim, you may balance load on your hands - they will do similar things and tire in parallel. Thus, you'll avoid potential right hand joyents problems, which arise from frequent use of mouse.
3. Available everywhere. Vim is cross platform. It runs natively on UNIX and Linux. There are also GUI versions, adopted for major operating systems: gVim for Windows and MacWim for Mac OS X, they look and feel like native apps for these platforms. Thus, you can edit files with Vim on your Linux/Mac/Windows system, then ssh to Solaris or FreeBSD server and edit files with Vim there. It is so nice when favourite editor is available anywhere.
4. Extensible. Visit vim.org and see yourself - Vim has zillions of plugins readily available to greatly extend it's functionality. For example, vimfiles plugin extends Vim with all of the neat features of TextMate editor (like bundles, project browser, fast file search etc), effectively turning Vim into the best editor for Ruby on Rails programming (as it combines features of both Vim and TextMate). Vim has its own scripting language for extensions, and it is quite easy to create Vim extension yourself.
   
5. Cool! The coolness of Vim is like the coolness of Linux. It is hard to master, but when you do it, you feel like you've just got an elite status, a status which is impossible to gain with money, just to achieve with intellect and hard work. Surely, such kind of coolness is valuable only for geeks and nerds alike :)