No Title

Hampta Pass Trek

Vignesh Sarma K — Tue, 18 Jun 2019 16:07:40 +0530

Hampta Pass is a beautiful crossover trek in the Himalayas where you cross over from the rich lush green meadows on the Kullu/Manali side to dry stark high altitude desert of Spiti Valley. I went through this trek in late July of 2018. The trek itself was organized by IndiaHikes. Since I am writing this after almost a year from the time of actual events, I have forgotten many of the details. But I will try to jott down all the useful info that I remember and there will be some pics as well!

Getting there

The basecamp for this trek was Manali. To get to Manali you could directly fly into Kullu airport but its not a big airport and had only flights from Delhi. So another option is to fly into either Delhi or Chandigarh and drive to Manali. This is the option we ended up with. We reached Manali late at night stayed in the same hotel as trekking group was to meet.

Camp 1 - Jobra

Next day by after noon the whole group was assembled, had our lunch and were ready to go. The first stretch of the journey was by vehicle and was some distance away. From there we had a short walk to the first camp at Jobra.

This was the view at the camp and the yellow tents were ours for the night. By far a most breath taking view for so little effort. Like an image of a mountain that as a kid you drew up so many times come alive.

Sleeping in congested tents is not the most natural for urbanites who are used to wide mattresses and lack of lighting is another pain. Thankfully we had water in the restroom tents and it wasn’t too cold yet. Small luxuries do matter.

Camp 2 - Jwara

Next day we set off leaving the view and camp behind but towards the mountain that we had been watching until then. We walk around it. The day is hot and bright, sky is blue and we are following the river. There are many minor waterfalls along the way and we finally cross the river to our next camp.

Jwara camp is surrounded by mountains on all sides specifically one of the sides has a steep cliff. You see a lot of Himalayan birds and on those cliffs. We are slowly but surly passing the tree line as well.

Camp 3 - Balu ka Ghera

Next day is somewhat easier and shorter trek. This would be the last stretch of Kullu region before the day of the pass. The day starts sunny and hot but soon there are signs of rain and slight drizzles. Few hundred feet short of the camp it starts raining heavily, so we run into the tents. In a while rain clears but the sky remains cloudy.

The cloudy sky late in the evening looked magnificent, trying to hide the sun but not quiet succeeding. The meadow is carpeted with flowers, but there are no more trees in sight.

At this altitude there is constant threat of AMS and there is Oxymeter reading in the morning and evening. No one was affected too seriously.

Camp 4 - Shea Goru

The day of the Pass. We had our packed lunch and lot of water. It was a long walk to the pass and the highest point of the whole trek. Climbing down from the pass to the other side is really steep and treacherous. But you have this beautiful view to nudge you on. This is probably the best view of the whole trek followed by the view at first camp. The camp here is also located at a very nice spot near yet another river. Lot of near by spots to hike around and once again meadows carpeted with flowers. This is where I caught all the horses grassing in perfect coordination.

Camp 5 - Chhatru

Next day morning it had once again started raining and everything was wet and moist and horrible and beautiful all at the same time. First task of our day was to cross the river on barefoot to start on the last stretch of the hike. The river was at least 15ft wide and 2-3 feet deep and freezing cold. We crossed the river holding hands and making a human chain. As soon as we crossed over we were desperately drying our feet and pulling on fresh socks, but since it was still drizzling and meadow as still wet, we didn’t get far in our attempt to get dry. We jumped a bit, ran a bit in our attempt to warm up. Then we started walking, long walk down to the next camp in wet clothes freezing and uncomfortable. By around noon we were at the final camp and the rain had let up. We had a road trip to Chandratal lake to close of the day as the last part of the trek.

The empty rocky landscape of Spiti was beautiful against the backdrop of clouds and rain. It was a long drive along a rough and rocky road.

Return

Last night in tent, and we had a whole day of driving to get back to Manali. We stayed at the same hotel as the first day in Manali. We had an extra day to explore the area. We checked out the narrow back alley and bright shops of Manali Bazaar and did a long zip-line. It was nice to take a bath and sleep in a bead again. We got a late night bus back to Chandigarh.

The trek was long and tedious on the last stretch due to the weather, but overall very much a worth while experience.

Water Jug Rewrite With Haskell Part I

Vignesh Sarma K — Fri, 04 May 2018 22:46:18 +0530

History

Water jug problem is a famous problem commonly found in AI texts. There are few different version of it like these:

I also had to do the same problem in my own college days. At the time I was learning python and thought it might be an interesting problem to solve with python. Looking at the code now I feel embarrassed. Am not even sure how I got it working. Rewriting it in python seems rather uninteresting now. Rather using a static functional language like Haskell seamed to make it more interesting. Obviously once you look at the code you will realize currently I don’t know much of Haskell either.

Rather than trying to solve the problem in one shot, I decided to limit the initial version some what.

Updated Problem

There can be some Water Jars, with any given capacity. The challenge will be to start from that to reach the given final state which will be get some specified quantity of water in these Jars. These Jugs have no measurements. But you know the full capacity of the Jugs.

As a starting point max number of Jars will be limited to two.

Data

One of the most interesting things about writing in a language like Haskell is how Types and data become powerful design tools. So to start with let us define Jug and State which is the combination of Jugs.


-- WaterJug.hs
-- Jug capacity, holding
data Jug = Jug Int Int deriving (Show, Eq, Ord)
-- State left right
data State = State Jug Jug deriving (Show, Eq, Ord)
-- Problem initial state, destination state
data Problem = Problem State State deriving (Show, Eq, Ord)
-- StateMap, type alias
type StateMap = M.Map State [State]
emptyJug :: Int -> Jug
emptyJug c = Jug c 0
newProblem :: Int -> Int -> Int -> Int -> Problem
newProblem rc lc r l = Problem (State (emptyJug rc) (emptyJug lc)) (State (Jug rc r) (Jug lc l))

The deriving ensures that we can have reasonable string representation for these objects, they can be equated to each other, ordered etc.

All these types we created using data are tuples. They can only contain two arguments. They are also positional.

emptyJug function can be used to create an empty Jug of any given capacity.

newProblem function can be used to define a problem which include jug capacities and the final state we want to achieve.

Possible Operations on Given Jugs

Given two Jugs you can do 6 operations. Depending on what state each Jugs are in only some of these operations will be valid at any given state.

The operations are

given a Jug that has liquid less that full, it can be made full.

forRightFull :: State -> Maybe State
forRightFull (State (Jug rc rh) lj)
| rc <= rh = Nothing
| otherwise = Just $ State (Jug rc rc) lj

Given a Jug that is non empty and the other Jug has some space left, Some of the liquid can be poured from this to the other one.

forRightToLeft :: State -> Maybe State
forRightToLeft (State (Jug rc rh) (Jug lc lh))
| rh == 0 || lc <= lh = Nothing
| otherwise = Just $ State (Jug rc (rh -liquidToTransfer)) (Jug lc (lh + liquidToTransfer))
where
liquidToTransfer = if maxCanPour >= rh then rh else maxCanPour
maxCanPour = lc - lh

Given a non empty Jug it can be emptied.

forRightToEmpty :: State -> Maybe State
forRightToEmpty (State (Jug rc rh) lj)
| rh == 0 = Nothing
| otherwise = Just $ State (empty rc) lj

These operations can be replicated on second Jug as is except the Jugs should be reversed. interchange is a function to help with that.

interchange :: (State -> Maybe State) -> State -> Maybe State
interchange f (State rj lj) =
case f (State lj rj) of
Nothing -> Nothing
Just (State rj' lj') -> Just (State lj' rj')

operations for the left written using operations for right and interchange.

forLeftFull :: State -> Maybe State
forLeftFull = interchange forRightFull
forLeftToRight :: State -> Maybe State
forLeftToRight = interchange forRightToLeft
forLeftToEmpty :: State -> Maybe State
forLeftToEmpty = interchange forRightToEmpty

Few interesting things to note here. All the action functions have the same signature. interchange takes a function as first parameter and we are partially applying it giving us the exact type signature we required. There common type allows us to put all these functions in a list. An important feature we will be using next. We use option(Maybe) type which allows us denote irrelevant actions on given state.

Compute Next States

Given any State, you can apply all these functions to get all the possible next State we can take the Jars to. I ended up doing that like so:

getNextState :: State -> [State]
getNextState s = catMaybes $ map (\f -> f s) toNextStates
where
toNextStates = [forRightToLeft, forRightToEmpty, forLeftFull,
forLeftToRight, forLeftToEmpty, forRightFull]

toNextStates is a list of the functions that were defined in the previous section. The only way all these functions can be put in a single list is if they have the same signature.

catMaybes filters out all the Nothings and takes out the Just values. Thus leaving us with actual/relevant changes.

Finding relevent states

Now given a starting state and final state, we try to find all the possible states between them. The allStates function is a kind of wrapper for the inner allStates' function. allStates calls the inner functions with a correct set of initial arguments, which implements most of the logic.

allStates :: Problem -> StateMap
allStates (Problem i f) =
let
allStates' :: State -> S.Set State -> StateMap -> StateMap
allStates' current queue m
| S.null queue = m
| otherwise = allStates' next queue'' m'
where
ns = getNextState current
-- insert current state and its possible transitions to the StateMap
m' = M.insert current ns m
queue' = S.delete current queue
-- filter out all the states that have already been visited.
new_q = S.fromList $ filter (\s -> M.notMember s m) ns
-- if final state is in one of these, we dont care for other transitions
-- from that point
queue'' = if S.member f new_q
then queue'
else S.union queue' new_q
next = head $ S.toList queue''
in
allStates' i (S.fromList [i]) M.empty

You can think of the where clauses as being executed top to bottom. In reality though they are all lazy and could be executed as and when the need arises. So order has no meaning.

Is there a possible path from initial to final state?

Once we have the StateMap we should be able to find if there is a possible path from initial to final state. For that we flatten out the values of StateMap and check if the final state is one of State.

isPathPossible :: Problem -> StateMap -> Bool
isPathPossible (Problem _ f) m = S.member f $ S.fromList $ concat $ M.elems m

Find Paths from Initial to Final State

Once we know there is a path, we walk the StateMap depth first to find possible paths to the final state. We look at this like a tree with initial state as the root node. When we find a path that reaches the final state we add that to possible paths and continue with our search. One of the optimizations we do is, if we find cycles, ie same state being repeated we end our search on that branch. Similarly if a state is not in StateMap once again we end our search on that branch. In all other cases we fold over next states and call findPaths' recursively. findPaths and findPaths' are similar to allStates and allStates' in that findPaths is mostly a limited wrapper over the inner function which implements most of the logic.

findPaths :: Problem -> StateMap -> [[State]]
findPaths (Problem i f) m =
findPaths' [i] []
where
findPaths' :: [State] -> [[State]] -> [[State]]
findPaths' (x:xs) ps
-- we have found a cycle, return the routes we have found
-- and end the search on this branch
| x `elem` xs = ps
-- found a full path, add that to routes and end branch
| x == f = (reverse $ x:xs):ps
| otherwise = case M.lookup x m of
Nothing -> ps
Just ls -> foldl (\ps' l-> findPaths' (l:x:xs) ps') ps ls

Shortest of the Paths

Now that we have a bunch of candidates for paths to final state, its time to find the shortest one. For that we just compare the length of each of the paths like so:

shortestPath :: [[State]] -> [State]
shortestPath ps = foldl (\a x -> if (length a) > (length x)
then x else a) (head ps) (tail ps)

Putting it all together

Now we have all the pieces to solve a given Problem.

solve :: Problem -> Maybe [State]
solve p = if isPathPossible p ss
then Just $ shortestPath $ findPaths p ss
else Nothing
where
ss = allStates p

The returned type is a bit interesting, it says given a Problem maybe we have a solution to get from initial to final state. :)

Conclusion

To conclude for now let me present a simple REPL session.

> :l WaterJug.hs
> solve $ newProblem 4 3 2 2
Nothing
>
> solve $ newProblem 5 3 4 0
Just [State (Jug 5 0) (Jug 3 0),State (Jug 5 5) (Jug 3 0),State (Jug 5 2) (Jug 3 3),State (Jug 5 2) (Jug 3 0),State (Jug 5 0) (Jug 3 2),State (Jug 5 5) (Jug 3 2),State (Jug 5 4) (Jug 3 3),State (Jug 5 4) (Jug 3 0)]
>
> solve $ newProblem 4 3 2 0
Just [State (Jug 4 0) (Jug 3 0),State (Jug 4 0) (Jug 3 3),State (Jug 4 3) (Jug 3 0),State (Jug 4 3) (Jug 3 3),State (Jug 4 4) (Jug 3 2),State (Jug 4 0) (Jug 3 2),State (Jug 4 2) (Jug 3 0)]
>

Next time we will try to solve this for n jugs.

Vagrant & Saltstack Quickstart Tutorial

Vignesh Sarma K — Tue, 17 Mar 2015 20:56:46 +0530

This post is translated / inspired from very well written Vagrant & Ansible Quickstart Tutorial. I was very much surprised that I couldn’t find a similar article which created some thing use full to get started with saltstack. The style of the article is very interesting in that it starts setting up a simple LAMP stack. As the article progresses the requirements for the stack are also changed and more features of ansible are exposed. This is the style I will try to follow.

I professionally use puppet, but am in general more inclined to the python ecosystem. This is one of the reasons that got me interested in Ansible and Saltstack. As I was researching both the frameworks this article Moving away from Puppet: SaltStack or Ansible? comparing them got me leaning towards Saltstack. Since the above article explain why you might want to use Slatstack better than I possibly could, lets just get our hands dirty.

Salt and Vagrant

Ensure that a recent version(> 1.3.0) of Vagrant is installed, in older version you will have to install salt support to vagrant as a separate plugin. Vagrant will automatically download and install salt on a given machine so you don’t need to install it separately.

Basics

We will start by creating a new directory to hold our project.

mkdir -p ~/Projects/vagrant-salt
cd ~/Projects/vagrant-salt

Next, we can use Vagrant to create a new vagrant file based on the latest ubuntu image.

vagrant init ubuntu/trusty64

You should now have a file called Vagrantfile in the root of the directory. This contains some basic information about the box you want to provision, and then a whole bunch of commented out stuff you don’t need to worry about now. Remove all of the commented lines, so you’re left with the bare minimum:

Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
end

We’ll need a way to access our webserver once it’s provisioned, so we’ll tell Vagrant to forward port 80 from our box to port 8080 on localhost. To do that, add the following line just before end:

config.vm.network "forwarded_port", guest: 80, host: 8080

Now, there is one last thing we need to do to configure Vagrant, and then we’re finished with it. We need to tell Vagrant that we want to use Salt as its provisioner, and where to find the commands to run. To do this, add the following lines to your Vagrantfile, again, just before end:

 config.vm.synced_folder "salt/roots/", "/srv/salt/"
config.vm.provision :salt do |salt|
salt.minion_config = "salt/minion.yml"
salt.run_highstate = true
salt.colorize = true
salt.log_level = 'info'
end

Once you’ve done that, the entire contents of your Vagrantfile should look like this:

Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.synced_folder "salt/roots/", "/srv/salt/"
config.vm.provision :salt do |salt|
salt.minion_config = "salt/minion.yml"
salt.run_highstate = true
salt.colorize = true
salt.log_level = 'info'
end
end

Basic Terms

Salt is more similar to Puppet than Ansible in that it tries to get the server to a specified state that you have described in your configuration. This is usually divided into smaller SaltStates that describe a single thing. A SaltState tell Salt how to achieve a state like setting up Apache as a service. Inside the state you will be able to specify how to install it using aptitude or what configuration to use etc.

Normally salt runs in master slave mode. But here we are going to do master less setup. Minion is the terminology used for slaves in salt.

First State

Create a new file salt/minion.yml with the following content:

master: localhost
file_client: local

To install a LAMP stack, there are four basic steps we need to take:

Update Apt Cache
Install Apache
Install MySQL
Install PHP
Setup A PHP file to serve.

That’s kind of all we need to do. We’re using an ubuntu box, so all of that can be done via apt. To do that, we need to use SaltStack’s pkg module. pkg module abstracts common package related actions like install and remove between different system package managers. Any specific commands for a package manager will still be in a specialized salt-state. We also don’t need to explicitly call apt-get update, that’s also internally taken care of by pkg module. We will also use file module to create a simple php file for testing.

Add a file salt/roots/top.sls

base:
'*':
- base

Since we are using vagrant and we only have one host its ok to put star * on where to run. - base is what we are going to run on those servers.

Add a file salt/roots/base.sls

apache:
pkg.installed:
- name: apache2
mysql:
pkg.installed:
- name: mysql-server
php:
pkg.installed:
- name: php5
/var/www/html/info.php:
file.managed:
contents: '<?php phpinfo();'

In the terminal vagarant up and you should see output similar to the following.

That’s it. If all you wanted was a working LAMP server, you now have it.

And load it in your browser at http://localhost:8080/info.php and you should see everything working as expected.

Refactoring

The next setup for us here is to reduce the repetitiveness of this code. pkg and many other salt modules allow you to give a list of item to apply this module to. For example in case of pkg we can rewrite the piece like this.

install required packages:
pkg.installed:
- names:
- apache2
- mysql-server
- php5
/var/www/html/info.php:
file.managed:
- contents: '<?php phpinfo();'

We reduced three separate states to just one. You can test it works by running vagrant destroy followed by another vagrant up in the root of your project.

Modularize

Usually, when you’re installing packages for a new server you want to do more than just install the packages - you probably want to configure them too. You might want to tell apache to use /vargrant instead of /var/www/html (which is the default location for vagrant to mount the current directory), or install php_mysql and php_pdo so you can access your MySQL Server from PHP.

There are two ways you can split this base module.

Conculsion

Unlike many other infra automation tools you don’t need to know many salt specific terminologies. Salt has very minimal concepts. Unlike Ansible there is no special roles. You just split it into modules and arrange the files as you see fit.

Faster Django tests

Vignesh Sarma K — Sat, 29 Jun 2013 11:41:14 +0530

Tests in django can quickly get annoyingly slow as you build up more and more tests. Two thing I found that significantly improves performance are:

Switching the test database to something like sqlite.
Run test concurrently.

Both of these can be archived fairly easily.

##Using different database for testing

Using sqlite during testing is fairly easy. This is specified in answer 1 and answer 2. Since sqlite is now part of the python standard library you don’t need to install any thing new. In your settings.py file add

#Django 1.3 and 1.4:
if 'test' in sys.argv:
DATABASES['default'] = {'ENGINE': 'django.db.backends.sqlite3'}

This significantly increases the performance of tests. According to answer 2 django automatically creates the databases in memory if the database used is in sqlite.

##Running tests concurrently

I had been looking for a way to do this for quiet a while now. Then recently an article on Pycoder Weekly about running tests concurrently set me on the right track.

First you will have to install concurrencytest:

$ pip install concurrencytest

Now to customize it for django add this class and related imports in a path that is accessible to django.

from django.test.simple import DjangoTestSuiteRunner
from django.utils import unittest
from concurrencytest import ConcurrentTestSuite, fork_for_tests
class MyTestSuiteRunner(DjangoTestSuiteRunner):
def run_suite(self, suite, **kwargs):
return unittest.TextTestRunner(
verbosity=self.verbosity, failfast=self.failfast).run(
ConcurrentTestSuite(suite, fork_for_tests(4)))

Also update your settings.py file to set this as the test runner like so.

TEST_RUNNER = 'path.to.MyTestSuiteRunner'

This has some covets though, each test case should be completely independent of each other. If you have some external file or resource that is shared read and written on to, this could case some of the tests to fail.

Clojure Java Inter-op and Google Drive Api - Part I

Vignesh Sarma K — Fri, 28 Jun 2013 01:42:14 +0530

One of the biggest advantages of Clojure claimed by its community is its interoperability with java. I decided to take take them on there word and test it out with Google drive api, and see how flexible and native it feels.

We will convert a simple program given on the main documentation page of Google Drive api page to a Clojure program. First we will try to keep it as same as there implementation having least amount of changes. Later we will try to make it more Clojure like, by using its native libraries and using Google libraries to a minimum.

You will have to do the basic setup form this page. May be even give a quick look a the java implementation, because we will be following it quite faithfully.

Setup

First you should create a new lein project:

$ lein new sample-drive app

This will create a set of files and some basic stuff. Now you will have to add some dependencies add required libraries to the project.clj file. You should be able to find this file at the root of the new project lein created for you. Change it to look some thing like this.

(defproject simple-drive "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.5.1"]
[com.google.oauth-client/google-oauth-client "1.15.0-rc"]
[com.google.http-client/google-http-client-jackson "1.15.0-rc"]
[com.google.apis/google-api-services-drive "v2-rev79-1.15.0-rc"]]
:main simple-drive.core)

google-api-services-drive is the the only library explicitly mentioned on the download page. But the other (google-oauth-client, google-http-client-jackson) are dependencies. You could use third party libraries that provide similar functionality like, clj-oauth2.

Another interesting not is we are getting them from maven repositories, which are essentially cpan or pypy like function for java. And the fact that we are even able to leverage that from Clojure is amazing.

Program

The program itself is a single function in the given sample, but will split it up slightly so that we can keep the main program in a single let statement. Much of the code is java directly converted to clojure.

(ns simple-drive.core
(:gen-class))
(import '(com.google.api.client.googleapis.auth.oauth2
GoogleAuthorizationCodeFlow GoogleCredential
GoogleTokenResponse GoogleAuthorizationCodeFlow$Builder)
'(com.google.api.client.http FileContent HttpTransport)
'(com.google.api.client.http.javanet NetHttpTransport)
'(com.google.api.client.json JsonFactory)
'(com.google.api.client.json.jackson JacksonFactory)
'(com.google.api.services.drive Drive DriveScopes Drive$Builder)
'(com.google.api.services.drive.model File))
(require 'clojure.java.io)
;; you have to get your own from google as mentioned in the help page.
(def CLIENT_ID "SECRET_ID")
(def CLIENT_SECRET "SECRET_KEY")
(def REDIRECT_URI "urn:ietf:wg:oauth:2.0:oob")
(defn get-auth-code [url]
(println "Please open the following URL in your browser "
"then type the authorization code:")
(println (str " " url))
(read-line))
(defn insert-file []
(let [body (new File)]
(doto body
(.setTitle "Readme")
(.setDescription "A test document")
(.setMimeType "text/plain"))
body))
(defn do-the-stuff
[]
(let [httpTransport (new NetHttpTransport)
jsonFactory (new JacksonFactory)
flow (-> (new GoogleAuthorizationCodeFlow$Builder httpTransport
jsonFactory CLIENT_ID CLIENT_SECRET
(list (. DriveScopes DRIVE)))
(.setAccessType "online")
(.setApprovalPrompt "auto")
(.build))
url (-> (.newAuthorizationUrl flow)
(.setRedirectUri REDIRECT_URI)
(.build))
code (get-auth-code url)
response (-> (.newTokenRequest flow code)
(.setRedirectUri REDIRECT_URI)
(.execute))
credential (-> (new GoogleCredential)
(.setFromTokenResponse response))
;; Create a new authorized API client
service (-> (new Drive$Builder httpTransport
jsonFactory credential) (.build))
body (insert-file)
fileContent (clojure.java.io/file "README.md")
mediaContent (new FileContent "text/plain" fileContent)
file (-> (.files service)
(.insert body mediaContent)
(.execute))]
(println "File ID:" (.getId file))))
(defn -main
"This is the equvalent of public static void main."
[& args]
;; work around dangerous default behaviour in Clojure
(alter-var-root #'*read-eval* (constantly false))
(do-the-stuff))

Some of the stuff you might note, are that we have to explicitly import all the java inner classes. In java these are available to you if you just import the containing class. The whole program is written in a imperative manner, you set a whole bunch of variables, in between you do a few things. Instead of (new classname &args) we could have just said (classname. &args).

Checking Out Jekyll

Vignesh Sarma K — Fri, 29 Jun 2012 00:31:14 +0530

When I first saw the project Jekyll, the concept of generating static files form dynamic templates, and then displaying them instead of rendering templates each time seemed awesome and correct.But more than anything else it was the geekiness of it that attracted me the most. Here I am sitting in front of Emacs a typing this post, where if in another platform, I world have had to do it on some weird web-interface.

So I started creating my site in Jekyll, but soon I found that some thing was missing. Now I had to manually do all the styling, where in another platform, it could be handed over to a theme. But I did put a serious effort in trying to create my own style, and css files, but soon found that I had little taste and even less patientance for it.

At this point one day I was reading a blog, on some site and suddenly thought that the blog looked nice. A looking around to find on what blog engine it was built on lead me to octopress.org. With in a few minutes I was sure this was exactly what I was looking for.

Octopress has a simple but beautiful theaming system.With considerable selection. Octopress works with Jekyll, to create static pages, but also acts as a simplifying wrapper on Jekyll. So I started immediately, to setup the site in octopress,

About

Vignesh Sarma K — Sat, 07 Jan 2012 00:00:00 UTC

Who Am I?

I love to program, learn new technology’s, and working on them. I also enjoy a variety of movies and books.

Currently working at Concur with their authentication/authorization team. I have about six plus years of working with backend systems, building REST APIs, working with cloud technologies, etc. in various environments and languages. In the future, I would like to work on scaling distributed systems. I am interested in trying out different languages and proficient to a varying degree in Clojure, Scala, Rust, Haskell, etc.

My full resume can be found here