jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

A Song of Ice and Fire – Book 1 – Game of Thrones

[This blog post is rated A for Adult. If you are less than 18, don’t read] 

[Spoiler Alert if you havent watched Game of Thrones or read Game of Thrones] 

I like reading. I really do. I have previously written about books I have read recently. After having read The Stand ( a door stopper if I have ever read one, even more of a stopper than Order of the Phoenix) I wanted to read something epic. Something that will be as epic as Lord of the Rings (which I am yet to read) but even longer than that. Something I can read for a long time.  

That is when I decided to pick up the 'A Song of Ice and Fire' series. Of course, when you read on Amazon Kindle, you don’t pick up anything. Rather, you simply download and read :P Still, I prefer the word pick up. Game of Thrones is an odd book series (I realized after a while) to pick up. It has to do with the fact that Game of Thrones is such a big series on HBO. It's almost impossible to avoid game of thrones spoilers.  

Perhaps the most important spoiler was the fact that main character from the first book was portrayed by Sean Bean. I don’t know about you but Sean Bean almost always dies in almost all of his roles. If it is a series, he dies in the first movie or the first season itself. Seriously, his casting was perhaps the biggest spoiler ever. Normally I should not be complaining about it. A lot of spoilers get spoiled because of internet. Then, there are movie trailers that spoil key plot points. 

Here, I am particularly incensed because, the author of this series, Mr. Martin, is 'the most famous fictional serial killer' of our times. That means, he has a penchant of killing of key characters to 'throw off a savvy reader'. You see, a lot of authors like to give what is called 'plot armor'. For instance, we all know that harry potter can never die. Of course he cannot because his name is on the book for heaven's sake. Yet, what if Rowling killed off Harry Potter in the first book? That would take balls. No correction. That would take some steel balls. 

Mr. Martin, well, he does have steel balls.  

So, coming back to the whole spoiler thing, I already knew that Daenerys Targaryen will have dragon babies. I already know that Joffrey will die at some point and same goes to Jon Snow. I also know that Cersei will be paraded naked at some point in the series. Let me see, what else do I know. I also know that Daenerys will take a second husband. The weird part is, I don’t even watch the Game of Thrones TV show. I just happen to know these facts because I read a lot on the internet. The worst part is YouTube. Now that Google somehow knows that I have been reading Game of Thrones (although I use Bing) and now YouTube shows key scenes from the Game of Thrones TV series.  

Come on Google/YouTube, stop spoiling the series for me. Not only this, the TV series has already overtaken the books. That means, the TV shows is now spoiling all the faithful readers of upcoming books. It's like, spoilers are now a part of life and there is no mystery left. Phew! 

Anyway, all said and done, I just finished the first book, A Game Of Thrones. 

For me, the book was a quick read. It did not really take as long as I thought it would take to finish. It reminds me of Ramayana and Mahabharata a lot. In fact, it’s the exact same thing. At its core, like the book's title suggests, the entire narrative is about different families who are fighting for the so called 'iron throne'. A king is dead and then people are conniving to figure out who will get that throne. There are tons of families in the book. There are like hundreds of named characters and like actual history, many of them have similar names. The point of view keeps changing, so we are always getting different viewpoints from different characters. There is also a lot of death (like I mentioned earlier, anybody can die unlike other books. Mr. Martin, the guy with steel balls) and lots of sex. Although, the book does not seem to have as much nudity as the TV show. It's understandable of course. Boobs means TV viewers. 

What I liked about the book were its setting. A world where seasons last for years. That’s pretty cool. Then, the characters. A lot of characters are so morally uptight, they border on stupidity. Then there are characters who are clearly evil, they keep crossing that line multiple times. For instance, there is this one occasion where a guy casually pushes a young boy casually off a building to a certain death. Young girls ( and boys) are casually raped, mutilated and killed. Whores are everywhere and men simply have as many children as they want. Women are no less lustful either.  

Some characters are truly badasses, although, in a world where contests almost always involve dead bodies and a setting that encourages war at the drop of a hat, badasses are a given. What is impressive is that the bad guys are just as badass as the good guys. Then, there are no clear morality lines. The good guys aren't always good (like this good guy who happily lops off another guys head) and then bad guys who have their own reasons for doing something bad (like this woman who does incest because of tradition and also because her husband told someone else's name when they mated for the first time. Some of this stuff is just batshit insane!). 

Then, there is this truly awesome dwarf character. He is just...well awesome. He's like Batman, but he does not wear a mask. Nor does he have an impressive physical strength. He does not even have normal height and weight.I am really looking forward to see how far it gets to in the next books. I am also waiting to see how the wronged characters will fight back. Who will die and who will live. There are so many questions and that means, I will read the next book and see what happens next.  

Oh yes, I also want to read more about those fire breathing dragons and their relationship with their mothers. Then, those odd dead zombies and these creatures of the ice. The narrative is also like a huge web of threads. At any point of time, there are simply too many things happening. Now, I don’t know if we will have a LOST situation here. Many threads are simply left hanging (although I thought that the LOST series did give a satisfactory conclusion to most things) or they will actually be resolved. Given the infamous Mr. Martin book publishing delays, I should be pragmatic and understand that some threads may never be resolved.  

Overall, I have decided to buy the next book on Kindle. Get some answers. I also am hoping to avoid watching the TV series. At least until I read all the books. 

Follow me on twitter, facebook and instagram for more updates. Thanks!

We are giving up on Microsoft Mobile, UWP and Xamarin

For a long time study nildana has been a Microsoft Mobile house. Both from a consumer perspective and from a developer perspective. At one point our club had more than windowsphone users. We even had a Lumia 510!  

Of course, the windows phone story is well known. However, I always held hope for it. However, a point comes when you have got to give up the thing you want the most. Looks like we at study nildana have reached that.  

The reasons are several.  

  • The lack of new mobile (phones and tablets) hardware.  

  • The low market share of windows 10 on mobile hardware.  

  • Lack of clear upgrade path to existing Windows 8 hardware to Windows 10. 

From a developer perspective, all these is going to have an impact, and it already has.  

I had some hope when Microsoft bought Nokia but then Microsoft wrote it off. That was a bummer. 

Then, or rather now, Microsoft is talking about the UWP. I thought it would be cool too but I simply don’t see why folks and every day users (including me) would use an app on the desktop or the xbox one. While Windows 10 market share is decent, I don’t see it (and UWP) taking the world by storm. Perhaps five years from we  all machines are running Windows 10 (by then all windows 7 machines would have died), UWP will be important.  

So yeah, at this juncture, study nildana does not have the luxury of investing in UWP.  

Then, there is the promise of XamarinIt was pretty much a given that Microsoft would purchase it (and make it free). However, there are some minor niggles (like how you still need an apple computer to build apps through Xamarin. If I need an apple computer anyway, why build on Xamarin / Visual Studio at all?) that prevent me from being sold on Xamarin. I also am wary Microsoft’s strategy when it comes to mobile. They wrote of a 7 billion dollar purchase (Nokia) and what is to say that they won’t write off Xamarin (which is small change at 400 million)?  

So yeah, as a small club with no external funding, study nildana cannot afford to place it bets on Xamarin either.  

Essentially, as the guy who runs the show at study nildana, I must make some tough decisions. My decisions impact not only my life but also of the dozen or more interns I am guiding at any point of time.  

Perhaps, some day Microsoft Mobile strategy will pay off. For us at study nildana though it’s time to say good bye to it for now.  

Where do we go from here. Well, where do highly skilled divers go when deep water diving is banned? Sky diving of course ;) 

Follow me on twitter, facebook and instagram for more updates. Thanks!

Weak References

We have been discussing memory stuff for a while now. One last topic (for now) when working with memory are weak references.  

You know how if a item in the memory is 'live' (being referenced by a root item) it will never be cleared by the garbage collector. This is good because you don’t want to lose reference to something that is currently being used. However, what if you are working with large list that your project is using? Large lists (that are still referenced) will take up a lot of memory. Keeping them in the memory may be good in theory but the performance hit (memory usage) might not be worth it.  

Perhaps you don’t mind if these objects are cleared from memory everytime a garbage collection happens. If they are lost, its okay. You can just run another query from where you can simply build a new list and have it populated. You could simply check if it is still in memory before using it. If it is, you use it from memory. If it is not in memory, you simply load the stuff from the server or a file or from wherever the list was originally populated. 

The use case for this is pretty straightforward. If your application frequently uses lists that become populated with lots of data (and the list itself gets very long) it may become easier – performance wise - to simply reload the list rather than keep it in memory.  

Since I have not yet started blogging about lists, I am just going to leave the code out of this post for now. 

Follow me on twitter, facebook and instagram for more updates. Thanks!

Strings and stuff

Can you think of any program where you don’t use a string? I cannot. We are constantly working with strings. When learning programming, the first thing that we do is write the 'hello world' program which is about displaying a string. When working with web services, and data comes back in json, it’s a string. Everything and anything can be represented as a string. Numbers, decimals, date, weather, temperature and you name it. All of them can be represented as strings.  

That is why c sharp has a lot of  string related stuff to help you, the developer, reduce the workload related to playing with strings. Almost anything and everything related to strings (manipulating them, traversing them, building them and so on) is already available in .net and c sharp.  

Other blog posts will spend a little more time on focusing on specific string related features. Here, I want to emphasize on one simple thing. That is the fact that strings are immutable. What does that mean really? The thing is, once you create a string (and assign a value to it) it cannot be modified. It's sort of like a tattoo. It's set in shape until it dies.  

So, when you do  

string hello_world = "hello world";  

The string "hello world" will remain as its until it is no longer referenced and garbage collected. That means, the following statement will make you think. 

Hello_world_2 = hello_world + "there"; 

When executing this statement, a new string is created called "there". Then, the contents of "hello world" and "there" are copied over to another new string which will eventually contain "hello world there". Why did two new strings created instead of the original string modifying itself from "hello world" to "hello world there"? That would be simpler isn't it?  

On the outset, it would be simpler. However, the property of being immutable makes sure that the string object cannot be modified. This is a better way of dealing with strings because, as a developer, I know that once a string is created, it cannot be modified by any part of the program. This certainty allows me build thread save string related applications.  

I have not attached any doe to this blog post. We have already used strings many times in many our previous code repos.

Follow me on twitter, facebook and instagram for more updates. Thanks!


When discussing the basics of string earlier, I mentioned how each time you try to append a string to an existing string, a new string gets created.  

string hello_world = "hello world"; 

string hello_world2 = hello_world + "there"  

The second statement actually creates two new strings to make "hello world there" 

What if you do something like this 

for (int I =0;i<100;i++) 

hello_world_2 = hello_world2 + hello_world; 

By the time the loop finishes, a 100 string objects would have been created. That is crazy and is not practical in many scenarios. In fact I cannot imagine any scenario when this would be considered appropriate.  

When you are doing something like this, you use a StringBuilder, as the name suggests, maintains a buffer internally. So, when you append a string, it will join the buffer instead of creating a new string.  

Find code demonstrating the string builder. 

Follow me on twitter, facebook and instagram for more updates. Thanks!

String Formatting

Ah! The most useful part of displaying stuff. The thing is string formatting is a topic on its own. Like, you could keep getting better at it and there would still be something to write about.  


One of the first things I use when formatting a string is using the {position} thing. When you want to display a string which has to intersped with variable values, you may choose to concatenate them. This could get cumbersome when you wish to include too many variables. That is when you can use {} and you put a location value at that spot.  

The number inside the brackets indicates the location of the parameters on the right side of the console writeline. 

Culture Info 

The 'culture info' is an option that allows you to let the string method automatically display information in a culturally relevant way. For instance, when the culture is set to 'en-US' and a currency is being displayed, the string will be automatically formatted as dollars. This also applies to stuff like date and time which are all culturally sensitive 

formatting key 

Now, there is no such thing as a formatting key. I am just making this word because depending on the key, the display will change just like it does when a culture info component is attached. 

custom formatting key 

By default, some components have a default key to use. Like date objects have 'd', 'D', 'M' which accordingly change the display.  

Just like those formatting keys, you can build your own formatting keys that can be used to decide how the display works. Of course, you will use them with the tostring() definition.  

As always, you can check our code here that shows all these in action.

Follow me on twitter, facebook and instagram for more updates. Thanks!

String – Formatting – ToString

Another cool thing about string is that it has a default implementation of toString method. You have already seen this in action in many of our code samples. Just to refresh, if you were to use the tostring method with an int, you will get a string representation of that int value.  

Now, that is pretty cool. The same string method is available for every type (and hence all its objects) that you define. By default, it simply gives the type of the object. However, you are happy to override it, and make it give any string that you want. It is normal practice to give a string representation of your object. This is particularly useful when you are building json services or when you want other objects to get a string equivalent of the object in question.  

Of course, find the code that does this here.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Strings and Searching and Enumeration

Searching for a string within a search the most basic operation when working with strings. For that, .net has excellent facilities. 

Now that enumeration thing, we already discussed that in an earlier post, by way of the Enumerator interface. It goes without saying that string implements the enumerator interface and you can enumerate through it.  

For this blog post, things are pretty straight forward. So, I am going to ask you to go directly to our code repository to see how it works.  

And the code for string enumeration is here.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Fields and Properties

When you are defining your own type, you will create some fields. Something like this. 

class water_bottle 


private string hello; 

//method to get this field will come here 


Now that is a field of type int with the name 'hello'. That field can be accessed by a method (since the access modifier is private, and hence outsiders don’t have direct access) and do stuff with it. Making it private is a good design, and it's pretty neat. 

However, suppose, tomorrow you no longer wish to have 'hello' to be of type double. Perhaps, another custom type that you have defined. Then, it would become difficult to change. Further, perhaps, you want further control over how your data members are accessed. Perhaps your type may be derived by another type, and override some methods. Essentially you want to encapsulate, even more than what is already available. 

Bottom line, you wish to follow the design principles of object oriented development. If so, c sharp gives you properties which encapsulate the fields.  

Instead of the above code, you will do something like this. 

<code snippet here> 

Thanks to properties, you are now even more control in how your data is accessed by anybody including your own type definition methods. The get and set are called 'accessors'. They help you define how you get and set values from the fields. On the outset, it may look like methods. You may even argue that you could write a 'get' and 'set' method, mimicking this behavior. There is nothing wrong with that. In fact, you may very well do that.  

However, you can keep defining your own methods to get/set values, but what happens when you have hundreds of fields? Will you keep writing methods for each and every one of them? Of course, I have already described above the extra benefits. Overall, when you want fine grain control over your data, you are better off using properties than fields. 

Of course, I must note here that, using fields (without properties) is no crime and nor does it make your project design bad. In fact, some projects go with a combination of fields and properties. 

As always, find code in our repository here. 

Follow me on twitter, facebook and instagram for more updates. Thanks!

Explicit Interface Implementation

In our earlier blog post, we talked about the class heirarchy that comes with implementing interfaces and of course base and derived classes. 

One thing that I wanted to write separately was 'explicit' implementation of interfaces. By default, you do an 'implicit' implementation of interfaces. This is another one of those encapsulation stuff designe to hide methods from the interface. When you explictly implement an interface, the interface methods become unavailable to the to derived class objects.   

So, suppose, you have an Interface, I. class C implements I explicitly. You then proceed to create an instance of C, called c_1. You see, because of the explicit implementation of C (the type of c_1), c_1 will be unable to access methods of I. essentially, the methods of I are hidden from instances of C, even if th fact is that, it is C which is implementing I. 

Obviously, all this is confusing but find our attached code to see how it works. Here is our repo.

Follow me on twitter, facebook and instagram for more updates. Thanks!