• Vim Server, ZSH and Tiles
• Vim Sessions

You can find lot of posts on the internet which try to tell you how to improve the ways in which VIM is used. Well, here is another one.

Vim Server, ZSH and Tiles

A Vim instance behaves as a server in which files can be opened through remote applications. Read :help client-server of Vim to know more about this. I generally keep multiple Vim sessions running, described by task they are related to. A typical workspace has one instance of Vim running and multiple terminals around it. Lets call this workspace for project foo. So the name of Vim instance server will be foo:

vim --servername foo

And any file will be open in this server, using this command:

vim --servername foo --remote-silent bar.hs


+-----------------------+
|           |~$         |
|           |           |
|           |-----------+
|    Vim    |~$         |
|   Server  |           |
|           |-----------+
|           |~$         |
|           |           |
+-----------------------+

How this helps:

• Lets me keep a well defined separation on various projects I am working on. The list of files in the buffer per instance remains short and manageable.

• Also each instance can have its own project specific environment - current directory, python virtual environments etc.

For easing all this up, I use a set of helper functions in my zshrc:

# Set the name of vim session the terminal is tied up to
eset(){
    export VI_SERVER=$1
}

# Fire up a new server according to the argument supplied
vs(){
    eset $1
    vim --servername $VI_SERVER
}

# Open up the files in the environment Vim server.
es(){
    vim --servername $VI_SERVER --remote-silent $*
}

# Reuse Vim ZSH completions for vim completions
compdef _vim es

Vim Sessions

Having multiple instances is great, but I don’t want to set each up every time I need resume working. For this I use Vim Sessions, which allow the current Vim state to be stored over the disk.

vim-session plugin will help you manage sessions easily. It is well integrated with Vim client-server.

From docs:

When you start Vim with a custom server name that matches one of the existing session names then the matching session will be automatically restored.

• The API
  • Functionality
  • Reliability
• Developing a client

It is nowadays customary of companies to expose parts of their infrastructure to the public, in the form of an (API) Application Programming Interface. Hackers can utilize these to develop innovative apps and products.

I have been working over exposing an API to the internal codecheckers for Interviewstreet for some time. A beta version of this is up now and we are accepting registrations on an invite basis. Post a request for invite here: http://api.interviewstreet.org/accounts/invites/

The API

The API is up at api.interviewstreet.org. It provides a HTTP based format agnostic interface. You can use any of these popular formats: json, xml, yaml, pickle. JSON is the default. Format can be specified by appending .<format> to the url. Eg:

http://api.interviewstreet.org/v1.0/submission.xml?key=2&token=snr34je9n52tY32fJh8teLRl3z4h0wbl

for talking to the API in xml format.

Functionality

The functionality provided is straight forward. It asks for the programming language (supporting over 15 languages), the program to evaluate and the testcases to run that code against.
As results to the evaluation, it will tell you if the code was successfully compiled, how it ran against all your test cases and the outputs it generated.

Reliability

This API is pretty reliable. It is a django front end to the system that is used internally. It is well maintained and regularly tested. In fact, it has already had a successful run with Overnite, a night long programming event conducted under Kshitj (IIT Kharagpur’s technical Fest).

Developing a client

If the language you are using supports basic HTTP request, developing a client to interact with the API is simple. The documentation explains how to use it against curl. Here is a python implementation using urllib2:

import urllib2
import json
import random

url = 'http://api.interviewstreet.org/v1.0/submission.json?token=your-api-token'

# A demo submission
submission_data = {
    'source': 'print 111' #prints 111 in python,
    'hash': "your-random-submission-unique-hash",
    'testcases': [
        'case1\n',
        'case2\n'
    ],
    'lang': 5 #This is python
}

request = urllib2.Request(url)
request.add_header('Content-type', 'application/json')
response = urllib2.urlopen(request, json.dumps(submission_data)).read()
key = json.loads(response)['key']


# Getting the result

response = urllib2.urlopen("%s&key=%s" %(url, key))
result = json.loads(response.read())['result']

## Do whatever with the result

The API is undergoing modifications, so it is currntly down.

All the stuff which runs over ssh (like scp, git etc.) also work the way they are supposed to, following the ssh configuration.

To get this to work you need to have corkscrew and netcat (the swiss army knife) already installed.

Here is how it goes:
File ~/ssh/config:

# Let me access local remotes directly.
Host 127.0.0.1, 10.*
    ProxyCommand none

# Github lets you ssh over port 443 too, utilize that instead of tunneling
# through remote computer
Host github.com
    Hostname ssh.github.com
    User git
    ProxyCommand corkscrew 10.3.100.211 8080 %h %p
    Port 443
    Hostname ssh.github.com

# Let me ssh onto my ec2 instance, which has full network access, through a
# http proxy.
Host ecc.rohanjain.in
    ProxyCommand corkscrew 10.3.100.211 8080 %h %p
    Port 443
    ServerAliveInterval 600

# All the rest should connect through an ssh connection over the ec2 instance.
Host *
    ProxyCommand ssh -q -a -x -p 443 ecc.rohanjain.in nc %h %p

I really like the convenience posting in this way provides to me. The functionalities that were present over there were to much overkill and completely invisible to the public, so better save the processing power required to render the content every time the page is accessed.

After the setting up of this, I expect a considerable increase in my blogging frequency.

Updates

Now I have shifted to the haskell based site generator, hakyll instead of jekyll.

• Using custom apps and modules
  • Modify contrib
  • Forget contrib
• Using unaltered django modules
  • wsgi
  • htaccess
  • django-multisite

The first thing the title triggers in the mind is the django sites framework. Well this post is mostly related to that but suggests its utilization in slight different way. As we can get from the docs in every implementation of the sites framework you have to hardcode the SITE_ID in your settings.py file. So it assumes that you have multiple django projects or at least multiple settings.py files which will be used as the django settings module for the process. So basically it provides us to share database between multiple sites which is a nice feature.

For our case which is, we want to use a single django project to across multiple domains while presenting altered versions of content dependant on the originating domain (the domain names cannot be hardcoded as the number of domains is dynamic too.), we have to do something different to get this level of dynamicity. I did sone research about this on the #django IRC, stackoverflow and google. Here are some complete/incomplete ways I found out to achieve this.

Using custom apps and modules

These ways would need us to define many custom models and middleware, hence a lot of work. The domain management would be done by the django project itself through middleware which use the HTTP_REQUST header and hence every request will be processed to obtain the information required to do database queries and render the views. So these methods looks like bit safer but would cause a performance decrease.

Modify contrib

This is the rather easier way which involves modifications of code of some django contrib apps here and there. Just copy the apps from django->contrib folder to the project directory and modify them to accept request as argument give out results according to the HTTP_HOST and Sites database. Also change all the imo reference of these apps from django.contrib.app to app.

Forget contrib

Another way would be to forget the contrib apps and write your own custom similar ones from scratch. This may be a better way for long term projects which require highly customized and special functionalities. But it will require us to write a lot of code, though the existing modules can be used for reference.

Using unaltered django modules

If we are successful in doing this it will probably let us build our project in much less lines of code and using the already existent django contribs as is. So if we don’t modify django modules then what do we modify to achieve the dynamicity.

wsgi

This is what we could do: First define multiple settings files in some pattern so that they can be matched according to the domain name, say settings_domain.py. Now if the deployment is done using wsgi script (generally in this) format. In the wsgi script we have to call the respective settings_domain.py according to the accessing domain name. So this seems pretty good but it can be dangerous. As we are setting a global variable (os.environ['DJANGO_SETTINGS_MODULE']) it is not at all a thread safe method. If there are two requests close enough this may pose dangerous effects. Unless we are not able to make sure that a new fork / new wsgi demon will be created per domain. So maybe one could suggest to write a good wsgi script which could handle this.

htaccess

Yet another way would be to make the .htaccess file dynamic, if it is possible. I don’t have any idea if I could write an apache config file that would trigger the correct wsgi file (which triggers the correct settings one). Maybe one could suggest a way of doing this (through regex?). To me thiss seems the best way which would trigger a corresponding process for each domain.

django-multisite

This is a django application I found (Source: https://github.com/shestera/django-multisite) which utilize thread locals to dynamically define the SITE_ID setting according to the request domain. I have tried this and is actually working but as the django documentation has pretty clearly warned against its use, I am in doubt if it is a safe way.

Till now I am still unclear of what method to implement among the above or some other one. There are some pros and cons of all the methods.

I apologise if I have written something wrong, these all are only some methods I have found out while searching the web and discussing on the groups, so please specify if there is any mistake or you can suggest something related to this.

• Technical Info
• Updates

Sometimes, being too lazy to use the type, you might wish for some other way to interact with others. Well there is one and quit an interactive and entertaining one, a whiteboarding interface, i.e. the people involved in chat can do collaborative drawings, play games, convey emotions not possible by typing etc. It can have some bigger implementations like teaching, presentations many more utilities can be innovated.

There is already a small implementation of this feature in yahoo by name doodle. Seeing its utility one might wonder why this brilliant feature is not implemented with the widely used chat protocol, XMPP (Google Talk is based on XMPP)? Well I cant find out why not.

So, we have taken an initiative. Our group (Me, Sanket Agarwal and Pankaj Singh) is working for implementing this feature with the XMPP protocol, at least for pidgin users.

Technical Info

Project Repository: http://github.com/crodjer/pidgin_whiteboard
Updates: Project updates

This project involves building a basic implementation of the protocol specified in, http://xmpp.org/extensions/xep-0284.html, using the SVG graphics specified in, http://www.w3.org/2000/svg. Both together define the standards for our work.

We hope to provide the following features:

• Simple whiteboarding drawing Lines, Polygons, Circles and Free Curves.
• Fancy Texting
• Image Sending
• This will provide users with a more enriching experience.

I am really excited about this project as it would be one of my initial contributions to the great open-source community. Till now it have been a fine ride of purpling, jingling and jabbering with pidgin.

Updates

29 Nov 2010
Work resumed after a brief pause. The target now is to integrate shared XML editing with jingle and add more features to the whiteboard graphical gui.

10 Nov 2010
Our Proof of concept is ready. All the basic features of whiteboard are now incorporated. A usable implementation now exists. You may fetch and compile the code from the git repository (Address mentioned above). This is how it looks:
A Snapshot.

9 Nov 2010 Syncing of whiteboards is up. The whiteboards are updated as the two users draw using their brushes. So a responsive interface is present. Just some small bug fix and feature additions remain now.
Screenshot

6 Nov 2010
Now session initiate and accept integrated (popping up of whiteboard on both ends). Slight change in way of implementation, use of libjingle is now on a hold, creating a custom whiteboard message format for session management for now. Code in dcrodjer branch of the above git repository. A screenshot of the code working: Image for session implementation

24 Oct 2010
A whiteboard interface initiates. This is how it look like:
Image 1
Image 2