Thursday, February 2, 2017

learn programming (or to become a programmer)

Programming is an interesting exercise. Sometimes at work, I discover a problem. And a good chunk of my time goes into figuring out a solution to fix it. When I discover a challenge in the piece of code I am writing or the solution I am implementing, it becomes more exciting.

But programming isn't everyone's cup of tea. There are good many articles and forum posts which say what the programming profession is and if programming is the right job for you. Here are few links to that effect:

I highly recommend you continue reading this post after visiting the above links.

Here are some less-mentioned guides about how to go about learning programming:

1. The more you realize what a computer actually is, the more comfortable you might be with learning how to write programs. Its not really writing code or compiling more of figuring out the answer to why write programs?

2. It also helps to think of a computer as an IO (input/output) machine. It is designed to accept certain kinds of input, do some processing and calculations, and output to a set of destinations. The most common of destinations is a computer terminal (or a computer monitor).

3. Get a general sense of how software works? Is it interactive? Does it require human interaction? If the software does not need human interaction, and it works, how the hell does it work?

4. Its not about a language, or the best language. The language is only a vehicle for you to get programming. The language alone doesn't tell the computer what to do. But it is important to figure out what the computer is capable of...and how that language can achieve all that. Step 3 is sort of important here. As you do this, you slowly figure out how a computer actually works.

Now if all this sounds like something you are not bound to like...then don't get into programming. Its not your thing. There are loads of other career choices to make - it need not have to be related with what you studied in college. But it has to be something you enjoy doing.

If you are a novice programmer probably the best place to get started might be
CodeAcademy. Most of the programming languages come with a developer environment (or an IDE). Here you can learn any language without that hassle. If you are just starting out, keep the next thing as a to-do item at the back of your mind...probably when you achieve a certain level of proficiency writing simple programs you can have a go at this: find an answer to what makes a web application different from a desktop application?

All the best.

Tuesday, January 3, 2017

konva js - a fork of kineticjs - a javascript 2d graphics/animation library

I've been exploring KonvaJs for a while. And I like it. I've done some pretty awesome animations using this library too.,output

The more you use the library, the more you'd want to make a custom shape. And there is a solution for that. However, that talks about manually drawing shapes using the 2d canvas primitives. But, you'd also want to re-use what is already offered by the library. Konva docs currently don't have a say about how to do this.

I may have found a hack. It may not be elegant when you think it. But it will do...

Here is my git repo if you are interested in code for an example.

Ps: you'll need npm and gulp to run it.

Sunday, June 19, 2016

a web interface to mongo? good or bad idea?

Its a bad idea.

Been exploring mongo db recently. I had experimented with it before briefly. But recently it was more of a quest to get a question answered.

Why build a HTTP interface to MongoDB?

You can scale without the overhead of installing mongo db driver software. It does not sound all that cool, but I guess that it is the only benefit.

Otherwise it isn't a good idea to expose it. Imagine, if that particular client (which talks to your database via http) is given to the end-user; people could potentially corrupt data.

That being said. I still like the former idea. I had recently written an email server in c# that generated enormous amount of logs. Plus, it also had to serially pump data somewhere. I just fancied the idea: why not do it over http?

However, I decided I won't go that road. I still fancy the idea, however, I do feel its not efficient or fast enough. Because you want to minimize the number of operations first hand. If I did it over http, the cycle of operations go like:

  1. Establish socket connection to the target server
  2. Acquire the socket stream
  3. Write data (to send) to stream
  4. Flush the stream
  5. Close the socket
In C# (or any other framework of choice) most of these are abstracted by the libraries I use; hence I don't have to do everything, just I've to ensure I compose the data, and call the http api's correctly. But inevitably those 5 things happen beneath the hood. 

I rather opt for a connection oriented approach. Something in the lines of:
  1. Open socket
  2. Acquire streams
  3. Reuse those streams as many times as needed
  4. Dispose of those streams when done and close the socket.
This eventually means I've to ensure that the driver libraries are bundled properly with my app. But for now that is just the road to go...

I did however, come across a python implementation of a http interface to mongo db (from their website itself). Immediately found out it was broken. And I am a bit disappointed. People say, that when there is no recent commit on a github source repository, it eventually means that that software is obsolete. They are usually right...

However, there is an intent. A curiosity I have to answer. Hence I forked the repo. Hacking up the source to make stuff work. So far I've understood why its broken, and I've taken small steps to fix it too. But that isn't my objective though.

Friday, March 6, 2015

Matrix permutation

I came across this interesting problem when I was solving a coursera assignment (8-puzzle) on Algorithms & Data Structures. This isn't related to the 8-puzzle where you need to visualize the solution as a game tree data structure.

I think this is related to the game tree.

Consider you have a \(2 \times 2\) grid where there is an \(X\) in one of the squares. You can make children of that figure only by moving \(X\) it to the adjacent square either left, right, top, bottom. How many iterations do I need to ensure that \(X\) has been through all the locations. It is possible that you can get the \(X\) in a previous position by making a child of child (from the previous iteration: avoid such repetition.

Here is a figure that shows the case for the grid in question:

This is a very trivial example. What could be the solution for a larger grid?

Wednesday, February 25, 2015

writing code for doing combinations

Combination is a common problem in mathematics which deals with different ways via which we can select r objects given n, where r < n. So we have n distinct objects and we can't have repetitions. For e.g., if we are to select 3 letters from the string ABCD, we have the following


So there are a total of 4 ways of selecting 3 objects.

Perfectly follows the formula,
\[{n \choose r} = \frac{n!}{r! \times (n-r)!}\]
A more simplified version of the above formula is,
\[{n \choose r}= \frac{n(n-1)(n-2)...(n-r+1)}{r!}\]
This is actually better for computations.

But how to write code to output the various selection as we've done above?

I'd take to pseudo code but you can't implement the pseudo code in one language and see the results immediately. Hence I've taken to python. I am not python-biased...I just like the simplicity of expressing logic. It models pseudo code fairly well...

There are better ways to write can use a generator instead of a loop that creates and returns an array. "Generator" is a concept that is available on most of the popular programming languages. You can explore my other gists to see how this is done in python and java.

Meanwhile, happy programming.

Friday, November 21, 2014

javascript promises

I used to wonder what are promises for a long time...then I saw a video regarding the topic...and one thing comes to mind...

Code Cleanup...

Or rather, it aids in easy understanding, readability, and thus making it more manageable.

Now here is my explanation. I assume you have worked with jQuery show, hide, fadeIn, fadeOut api's. Here is how a fadeIn works.

  var d = $('#div').hide();
View in js bin - example 1

This is a simple example. However, there is an overload for fadeIn which enables us to execute code once the animation completes as shown in the below example...

  var d = $('#div').hide();
    d.fadeIn(5000, function(){
      alert('fadeIn completed');
View this in JS Bin - example 2

Now say there are few elements you want to show up one-after-another. Shown below is the traditional way of coding for this requirement:

 $('input').click(function () {
  $('#li1').fadeIn('slow', function () {
   $('#li2 ').fadeIn('slow', function () {
View in JS Bin - example 3

You can see there are a lot of nested callbacks. At a look its hard to follow what is happening. Imagine writing the same for a variable number of li elements...

Here is the refactored version that uses promises:


 var fadeInFunc = function (obj) {
  var deferred = $.Deferred();
  obj.fadeIn('slow', function () {
  return deferred.promise();

 var funcWrapper = function (obj) {
  return function(){
   return fadeInFunc(obj);

 $('input').click(function () {
View in js bin - example 4

So we had to write a bit of deferred functions and function wrappers...hence there is a bit of extra code...But it tries to convey, what our objective was...

Or if you completely lost the point rename funcWrapper to fade try reading the code again...

Or doesn't it?! Do share your thoughts...

There is a lot more to promises than what's shown here. You should go check the jquery page on $.Deferred() usage and various scenarios.

If you are in a mood to be tested with what you've gained from reading this post, I suggest you try writing code to sequentially fadeIn variable number of li elements...

Happy coding...

Tuesday, March 25, 2014

making testable database access layer

Although I am a C# developer, the principles advocated here can apply to any language/platform. 

Why is testing important?

The question is very subjective and its answer depends on the profile of the person asking.

If its a product manager, he'd probably answer, testing is something done to see if the product works fine (in a very broad sense so the end-user/business function is not impeded).

If its an independent tester trying to answer this question; he'd have various responsibilities which sort of answer these questions:

  • are all the use cases of the product are satisfied?
  • has the product or software satisfied all non-functional requirements?
  • etc..
So for one such person described above, testing is important to ensure if the software does what its designed to do. 

Now, if you happen to be writing a lot of code, and "you" ask this all good probability it means you are a novice software developer. 

If this is disheartening to learn, take solace in the fact that you reading this post is some indication you want to achieve professional excellence. "You want to write good code". :) But, be warned, being a software engineer/developer encompasses a much greater responsibility than just writing good code.

So what is testing to a developer/software engineer?

I'll digress a bit here to say something about writing testable code "in general". Many of the projects that people land into these days are not exactly new development, or, from-the-scratch deal. Of course, this is a decision, a senior manager/architect has to decide. This decision affects project schedules. People actually start with fixating the schedules first. These things are usually negotiated after engaging with client/end-users, or, decided after studying market trends where people decide a suitable release date. After the schedules are fixed a conscious decision is made on the amount of engineering required and level of quality that is acceptable.

Therefore, not every software development can afford to be engineered well enough, and, thereby, the level of quality will also show itself that way.

As a software engineer/developer, writing testable code ensures that your code does what it is supposed to do. Therefore, we have to carefully plan and foresee what sort of inputs should go into a particular program, what inputs make sense, and what inputs will fail, etc. We are also trying to see if the program does exactly does what it is supposed to do (without errors).

Testing your data access layer (DAL)

Here is a small idea to help you understand how testing your DAL works. Say you are writing a blog engine. One crucial thing to test for might be, to see if the submitted blog post is saved in database correctly. The database identifies each post with a unique postID. Your test procedures would be:
  1. to "post" a blog (with title and post body) to database and retrieve its postID.
  2. retrieve a post with the above postID
  3. check if the post title and post body match with what you started with.
If you happen to encounter error anywhere in the above steps it means your code fails, and you have to investigate further.

Repository pattern - independently testing your DAL

We are going to focus on segregating all your data access to another layer (DAL). So that your application code need not concern itself with directly talking to the database. There are multiple advantages to this - one of them is being able to test it independently. 

So suppose we take the blog engine as an example. We'd design our dal as follows:

1. Entities and interfaces first

public class BlogPost
 public int PostID { get; set; }
 public string PostTitle { get; set; }
 public string PostBody { get; set; }
 public List<Comment> Comments { get; set; }
 public DateTime PostedOn { get; set; }
 public User BlogUser { get; set; }

public class Comment
 public int CommentID { get; set; }
 public strimg CommentText { get; set; }
 public DateTime CommentedOn { get; set; }

public class User
 public int UserID { get; set; }
 public string UserFullName { get; set; }
 public string UserNickname { get; set; }

public interface IBlogEngine
 void InsertPost(BlogPost newPost);
 void AddComment(Comment newComment);
 List<BlogPost> GetPosts();
 BlogPost GetPostById(int PostID);

2. Concrete implementation

public class BlogEngineMsSql: IBlogEngine
 public void InsertPost(BlogPost newPost)
  int newPostId;
  //SQL server data access code...
  //new post id is retrieved from db somehow...
  newPost.PostID = newPostId;
 //other implementstions follow

3. Test code

public class UnitTest1
 public void TestBlogInsert()
  BlogPost testPost = new BlogPost() { 
   PostTitle = "test",
   PostBody = "test",
   BlogUser = new User() { UserID = 123, UserNickname = "Mock", UserFullName = "Mock" }
  IBlogEngine db = new BlogEngineMsSql();
  var id = testPost.PostID;
  var post = db.GetPostById(id);
  Assert.AreEqual(testPost.Title, post.Title);
  Assert.AreEqual(testPost.Body, post.Body);

So in this example, we've created a simple blog engine. Note the interface and its concrete implementation. (For now assume its Sql Server specific code). The use of an interface allows us to mask the underlying implementation. In other words, I can make my application code completely unaware of the db implementation like this:

IBlogEngine db = BlogEngineFactory.GetMsSqlInstance();

...or even better, if I used some DI pattern:

IBlogEngine db = BlogEngineFactory.GetEngineInstance();

This way my unit test code is independent of the underlying db implementation.

The repository pattern is simply the act of exposing or channelling your database access code via interfaces. The dual advantage of this is,

(a) you can write test code which is fairly independent of the underlying implementation, and
(b) enforces a modular approach.

If tomorrow we want to run the same tests against an oracle database, we just add the corresponding dal assembly in our project and run the tests. If we are using some dependency injection, we'd change our application configuration to reflect likewise.

This decoupled nature, allows us to write test code, and, the actual implementation code, in parallel. And in theory, no person should write both; he should write code for any one - either the implementation or the test code. But if you are stuck with yourself, then the only go is to write the tests first, then actual implementation. This should progress incrementally, method after method. You write a test for the method; write the implementation, test it; fix errors and re-test, else move to the next method, and repeat as necessary.