jay's old blog

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

Creating a Console Project

When you learning to code in c sharp, you almost always need to start by creating an empty console project. Most folks would already know this. However, just in case, you don’t know, here is how you would do it.  

  1. Open Visual Studio (of course) 

  1. File New > Project 

  1. On the left side, select Visual C# 

  1. Then in the middle window, select 'Console Application' 

  1. Give a name (or leave the default name as it is) 

  1. Choose a directory location (or leave the default location as it is) 

  1. Click OK  

Here are some pictures to help you out. Also find the project 'Types_1' on github which will show you the basic ropes about types.  

Once you have finished typing your code, you will then have to two steps. 

  • Build the project. This is done by pressing Ctrl + Shift + B. Or you can be lazy (and not use shortcuts) and select the build option from the menu. Build > Build Solution. 

  • Assuming there are no errors (you can ignore some warnings or all of them), you can then run it. As always, I prefer the keyboard shortcut which is 'F5'. If you are feeling really lazy today, you can tap on the 'Start' button with the green play symbol just below the Build option on the menu.  

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

Thoughts on immutability and immutable

When you working with types, particularly value types, you are bound to run into the word 'immutable' and 'immutability'. They are both similar words in the same sense 'able' and 'ability' are related and similar.  

Immutable (usually in connection with an object) is a feature where in, once an object has been assigned a value, it cannot be changed. It is sort of like, suppose you buy a diamond (which also means you are filthy rich and congratulations on being that). Now, using conventional tools, there is no possible way you could change the shape and size or anything else about that diamond after you have purchased it and walked out of the diamond shop. It cannot be changed. It's...immutable. 

To put it more simply, it is sort of like a constant. For instance, the value of 'pi' is the same no matter where you go and use. The color 'green' is always green and cannot be changed. We can endless examples like this but I will stop at that.  

How does immutability work in a programming scenario though? Here is an example that I have borrowed from the msdn site.  

Value types are by design immutable but reference types can also be immutable. For instance, string, despite being a reference is definitely immutable. I am going to use string objects as an example and show how immutability works. 

Here is some code for our purpose. 

  1. string b = "study" 

  1. b = b + "nildana" 

When you look at lines 1 and 2, you are probably thinking, 'okay. b had the word 'study' in it, and then after line 2, it changed to 'study nildana'. That means, b has changed and hence not immutable or mutable' 

On the outset, it does feel that way, and I don’t blame you or hold you responsible for thinking that way. If you remember your types and objects and references, you will notice that reference types only hold a reference and not the actual value. So, in line number 1, when we write "study", an object of type string has been stored in heap memory somewhere and a reference to that has been assigned to b. In line number 2, we have proceeded to create another string object called "nildana" and then proceeded to 'concatenate' it with what b is referencing i.e. "study".  

Thanks to the concatenation, a new string which contains "study nildana" is created, and then its reference assigned to b. 

So, in those two lines, three distinct string objects were created. Once they were created (and a value assigned), they were never modified because of the immutability nature of string type. Rather than saying 'they were never modified', it is better to say 'the design of string types prevents them from being modified'.  

Now, it won't be a stretch to imagine that you are thinking, 'man, why bother with this mutable and immutable stuff?"  

The answer is yes and no. For starters, immutability is one of those things that are part of the package. When you declare a value type or use something like string, they just come with immutability. It's like when you go out shopping for a new puppy. You know by default that all the puppies are cute and you will end up falling in love with all of them. 

However, as your programming expertise increases and you build even more complicated code, you will run into scenarios where you have to ensure that your object (and its values) are not tampered with during runtime. You want that absolute confidence that, come what may, your object that has a certain value, will remain so throughout its object lifecycle. That is when you start thinking hard and long and strong about mutability and you start doing stuff.


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

Enumerations

One of the value types that we discussed earlier were enumerations or enums for short.  

Enums are a special case of types that you may either use way too much or not use them at all. Still, on projects that lend themselves to enums, there are extremely useful and reduce a lot of workload, confusion. Enums are one easy way to have 'readable constants' that can be used across the project. 

Suppose you are building an app for your college. At the time of writing the code, your college has 10 departments. However, you have a feeling that perhaps, in the future, your college may end up having 12 departments. At the same time, you also want to make your code extremely readable. You don’t want to use global variables (the worst thing a developer can do is use global variables) which could be easily modified elsewhere and cause unexpected app behavior.  

Under these circumstances, you will use an enum called "college_departments" and assign a value of 10 to it. Now, throughout your project you can use college_departments and the value of 10 immediately becomes available.  

Further you cannot assign a value to enum (outside of the enum definition) and nor can you do increment or decrement operators. All in all, you get the benefit of a global constant value (which can be changed later) without the headache of a global variable. 

Check the code Enums_1 to see enums in action.

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



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

Types of Types

I love the alliteration in the title of this post. 

In the previous post, I was talking about types in the simplest sense. Deep programming though will require more than just the basic understanding of types. In fact, a lot of conventional programming training (as provided by engineering colleges where I come from) sort of skip the different categories of types that are available 

The knowledge of types categories may not seem all that important in the initial days of programming, they take up a lot of significance when you dig deeper. With that in mind, here are the three categories. 

  • Value types 

  • Reference types 

  • Pointer types 

One thing I would like to say is that Pointer types are never used. The reason is obvious if your remember your days of doing pointer manipulation in C. A pointer contains the actual location of the memory (like its address) where a particular type's instance is stored. Manipulating memory locations is never ever a good idea. It is sort of like trying to jump into that enclosure where they are keeping a collections of zoos. Further, the animals have not been fed for the day yet.  

So yeah, don’t use pointer types kids and girls and guys. 

So, when you are programming you are essentially limited to two categories of types – value types and reference types.  

Value Types 

Value types are those category of types that contain the actual value in them. This might seem strange now (what do you mean, they contain the actual value? Obviously the type instance will contain its value...what else could it contain?), but once you read through reference types, you will see what I am trying to say.  

Value types are types such as structs and enumerators (of course we will dig into them in a future post). For instance, int type is a value type. So is decimal type and double type. Obviously, user defined structs are also value types. However, if I know a few things about programming (and I do know a few things), you probably won't be using structs all that much. You may end up using the built in, standard struct like Point but building own struct is something you may not do all that much. 

So, what defines a value type? 

Value types always hold the actual value. This is where they get their name from. How does this work really? Here is a simple example. You have wallet in your pocket. In that pocket you are keeping thousand rupees. To be more specific, you have 10 notes, each with a face value of rupees 100. If were to think of your pocket as an instance of the type pocket, it is a value type because it actually contains the 1000 rupees that belongs to you. 

In addition to this, they cannot be nulled (assigned a null value). That means, when you create an instance of  an int, even if you want to, you cannot make it null. Obviously, if you really  and very badly want to make a value type null, you do have an option but we won't go there now. 

Value type assignment (where you copy the store value from one instance of a value type to another) copies the actual value. Again, this may seem obvious but you will appreciate and understand the difference once you have looked at the reference type discussion below. 

Value types don’t lend themselves well to derivation of new types. That means, you cannot create new types by using existing value types. Creation of new types is the bedrock of object oriented programming and this is a feature of reference type, which will be discussed below.  

Each value type comes with its own default constructor that will assign a standard, fixed value. This makes it possible for you to create a instance of the type and then call upon the default constructor and let it assign the standard default value for you.  

Reference types 

Hopefully, once you go through this, you will re-read the entire blog post to really appreciate the differences between reference and value types. 

Reference types don’t hold the value they are supposed to hold (in direct contrast to what value types do). Instead of holding the actual value, they hold a 'reference' to the location in memory where the actual value is stored. Let's go back to the pocket example that I used when describing the value types. In the exact same pocket, you have your wallet. The wallet contains a debit card (which belongs to your bank account). Your bank account has 1000 rupees. In both cases, as a person, you have or own thousand rupees. Earlier (value type) your wallet actually contained 1000 rupees. Now (reference type), your wallet contains a debit card which has the 'reference' to the 1000 rupees in your bank account.  

Before we go into the unique features of reference types, lets look at how the reference type and value type differ, especially when it comes to security.  

Continuing with our discussion on wallet and holding money, suppose you lost your wallet. If you were following the value type model of keeping your money, along with your wallet, all of your money is lost. However, if you were following the reference type model of keeping your money, you lost your wallet but not your money. Your money is still in your bank account and the person who stole your wallet cannot access your money. All you have to do is collect a new debit card and your money is still yours.  

This is just one instance of why reference types are the ones you will use the most when building your application. As you learn more (and we add more blog posts) you will see why this is the case.  

With this intro, lets dig in and find out the features of reference types. 

Reference types don’t hold a value at all. They hold a reference to the object that has been instantiated. For example, if you are defined a class or an interface or a delegate (each of these things you will learn more later) and use them to create an instance. Suppose this class has ten different int values. The object would not actually contain the ten int values. Rather, the object would contain a reference to this data or data set, so to speak.  

Along with (one of many) the security implications (or benefits) of using reference types, another usefulness is that multiple objects can refer to the same data. So, the changes made by one object will be available to the other object and vice versa. Going back to our wallet in pocket example, it is possible to have two debit cards connected to the same bank account. The changes made by one card will affect the money in the account, and the same goes to the other debit card. 

While c sharp as a language provides some built in reference types (dynamic, object and string), most of the time you will be creating your own reference types, mostly in the form of classes that you define. Same goes to defining your own interfaces and delegates. Of course, it goes without saying that the string reference type will also find a lot of use in everyday programming.  

Lastly, I made a big deal about value types not getting a null value. With reference types, of course you can have a null value. That's because a reference object can point to nothing. Later it could be assigned a reference and it will start pointing at something. Then, later, it could be made to not point at anything or something else entirely.  

Heap and Stack 

Considering the differences between what value and reference types actually store, there is also a different way they are managed in memory.  

Value types are usually small data items (like int) and hence need fast storage. That is why value types are stored on the stack. On the other hand, reference types hold references which aren't exactly small data items, and are stored on the heap. Although the discussion of stacks and heaps are for another day, the important thing to know about them is the role of the garbage collector (which is responsible for destroying objects in memory once their usefulness is over). The garbage collector constantly monitors the heap, where as the stack has nothing to do with it.  

So that is our introduction to types. Understanding of types is extremely important. Read and re-read this blog post multiple times and only move to the next posts after you are very clear about everything.


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

Which type to use

After our discussion on types, the first question that will come to your mind is probably, when to use what type? 

There are some general guidelines to this which you can use (of course, these are guidelines and can and should be broken as per your own wisdom but I will come back to this later). The best way to decide between value and reference type is to check if it can be a value type object. If it's not a value type object, then it has to be a reference type.  

To decide on a object being a value type, you will see if (these are pretty much the same guidelines you would in official msdn books as well as online material. I am simply copy pasting them here) Imagine declaring an int when you are reading these requirements and it will make more sense. 

  • Object is small – this means, the object is expected to store small values.  

  • Object is logically immutable – ah, immutability. It’s a complicated concept but the gist is something like this. When you create a new object, and then you assign it a value, that value sticks with that object from its birth to its death. It cannot be changed no matter what. Immutable objects are essential when you are working in a multithreaded application and you really want to be sure that some objects will never be affected once they have been assigned a value. Check this post dedicated entirely to immutable for more details. 

  • There are many objects. You have lots of them. Meaning, you have many objects that contain small data.  

 

These guidelines make sense because, you should remember that value types are stored on stacks which are small and have no connection with the garbage collector. By nature, stacks are small in size but provide faster access to memory. Being commonsensical, you know that as things grow big, they get slow and hence need more management. By reverse logic, when things are small, they can be fast and need little management. So, when you know for sure that the actual data that you are storing is small, you simply go for value types. Of course, when you want to make things 'thread safe' and want to take advantage of the immutability features, you want to go with types again.  

Having said all the above, it is important that I add that, there is no such thing as 'solid' guidelines. As you grow and learn as a developer you will make up your own rules. 

For instance, at the time of this writing I have this rule that I should not use the mouse for anything. I must the keyboard (that means memorizing endless amount of shortcuts until they are assimilated as muscle memory) for everything! My colleagues think I am crazy but I know that a day will come when I will be working on 4 monitor workstations and I don’t wish to handicapped by having to grab the mouse for everything. 

Now that the guidelines are over, you know when to choose value types. If a type cannot be slotted to value type, you simply go with a reference type. It's as simple as that.


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

structs and classes

Once you have gone through the essentials of types, you will go about creating new value types as well as new reference types. When you are creating new value types, you are invariably creating struct types, and when you are creating reference types, you are creating class types 

Due to the way, value types and reference type designed, there are some things that struct and class can do, some that only struct type can (or cannot do) and some that only class type can (or cannot do). Understanding these distinctions can also help you figuring out which type you want to create for your project.  

If you are like me, it is possible that you may have never used struct (except may be when you taking baby steps in programming with Turbo C compiler and C language which only had struct) and have only used classes. I keep thinking why that is the case, and perhaps the reason is the nature of programming languages such as c sharp, Java and C++. All these languages are object oriented, so most books and trainers tend to focus on the object oriented stuff such as inheritance.  

That brings me to the primary distinction between creating your own struct type and class type. In a struct, you can do all the usual stuff (which is create fields/properties and define methods) but you cannot inherit a struct or let it be inherited. In other words, struct types stand alone. In addition to this, you cannot define your own empty (no parameters) constructor either.  

Going in the same thread of thinking, if inheritance is not part of the picture, so much of the object oriented magic (or headache depending on how your day is going) is thrown out of the picture. However, there will be scenarios where you would enjoy a non-object oriented type. When such a scenario strikes, you should use struct and you will be that much better off with it.  

That also means, if you are sure that you will be either inheriting a type or expect your created type to be inherited, then you are obviously going to create class types. 


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

Types – the core concept

When you are looking at programming (and working your way to become a developer) there are some basics you have to learn. Types, Methods and Classes. Everything else sort of builds on this.  

Types (sometimes referred to as variables) are like containers for the data that you wish to store, process, manipulate and anything else that you wish to do in your program (or project or solution or code file). To understand how types ( or variables) are like containers, let's take the example of a literal container. 

Suppose, you and your friends are going on a trip. Water is one of the basic items that you will pack with you. So, you buy a container big enough to carry enough water that will be sufficient for everybody who is part of the trip. In this case, the 'water can' is a type that can hold 'water'. Here water is the data that you are storing in a 'water can'. As the trip progresses, you will consume the water in the water can. Similarly, as your program goes through its motions, you will consume the data from the type. 

You may modify the contents of the water can (for example, you refill it when you take a stop at a hotel) during your trip. Similarly, you may decide to modify the data that is stored in this type as the program runs.  

Now, I am going to add one more detail that will make things a little more complicated but eventually simplifying things. Everytime I am mentioning the water can, I am not talking about the actual water can that is carrying the water during your trip. Rather, I am talking about the plastic that has been designed in the shape of a can with the sole purpose of carrying water.  

Similarly, when I talk of a type, I am talking about a 'data container' that has been designed with the sole purpose of storing a particular type of data. Which is also why, a type is not actually a variable. In fact, calling a type, a variable, would be wrong.  

So, what do we call the variable? What do we call the water can that is actually carrying the water. If my understanding is correct, we call the actual variable, an instance of the type. Going to our trip example, an 'instance' of the water can design is what is actually holding the water.  

Here is one more example 

You know soap? That you use to take bath or wash dishes (obviously you won't use the same soap to do both. That would be wrong) at your home. At the soap factory, there would be a metal template in the shape of the soap. Liquid soap will be poured into this template. Then, once it has cooled down, soap will be formed and packed. Later, the same template (probably hundreds of them) will be used to make the next batch of soaps.  

Here, the template (usually made of metal in the shape of the soap that is being made) is the type. Using this type, a number of actual soaps or instances are created. Each instance is identical to each other, they may be used by different people at different times during their operation. They are identical because they are all based off the same template i.e. type. Each soap, and hence the instance, will share common properties like color, shape and density. 

Similar to the above example, when you are building a program, you will be using a lot of 'instances' of different types. These instances are also referred to as objects or properties or variables. While each of these terms 'can' be used interchangeably, they are more suitable in a particular context. What I am trying to say is, these words – variable, instance, object, property – similar but not identical.  

Check out this github link where I use a simple type (int) and a few instances of said type to do simple addition. 


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

Very basics of debugging

Even if you are just starting out, you will need to know some basic debugging tools. In this post, I will list out some of the things that have helped me greatly and are invaluable in my everyday stuff. Note that, this is for beginners (as with the majority of content on this blog) and I have left advance stuff like Call Stack out of this post. 

Debug.WriteLine 

A lot of folks don’t like Debug.WriteLine. Especially, experienced developers. For me though, Debug.WriteLine is an extremely easy tool. It is a little time consuming but it's like an internal log. Also later, when I want to build a logging system, it is easy to retool it to something else as well. 

When you create a new project, normally 'using System.Diagnostics;' won't be there in the beginning of your code file. So, add 'using System.Diagnostics;' at the top of your code file to use Debug.Writeline. 

Here is an example of Debug.WriteLine. 

Debug.WriteLine("Main - The value of hello is -  " + hello3); 

There is no rule that you have to write your Debug.WriteLine contents like I have done above. However, it's a format I prefer. If you observe closely, my print statement (the stuff inside the "") has three parts. 

  • Main – this indicates the method in which the debug line is placed. This is especially useful when you have hundreds of methods and want to know exactly which method is putting out this particular debug message. 

  • A pleasant statement – in this case, I want to show the value of a variable called hello. So I have written an easy to read line here. 

  • The variable in question – I have included the variable in question. 

  • I also use a '-' to divide the three parts.  

 

Remember that you can have your debug message as long as detailed as you want. However, don’t go overboard with it. Keep it simple and short. 

Breakpoints 

The bread and butter of any coder are breakpoints. Breakpoints are literal points that you place to 'break' the flow of the program. Putting a breakpoint is easy. You locate a line where you want the execution to 'break'. Then you right click and select 'insert breakpoint'. 

Here is a photo for that.  

When you debug your project, you need to know what is going on with your variables, objects, what values do they currently hold and so on. All this information is available for you. 

You will also be using these two buttons quit often. 

  • F10 – go to the next step 

  • F11 – did deeper into the next step. F11 is something you use when you want to follow the program and see what it is really doing. For instance, let us say that the current step involves a call to a method. If you want 'deep dive' into the method itself, you will use F11. However, if you don’t care what exactly is happening in that method, you press F10 and you will be stepping over to the next step.  

Continue 

Even a simple program can have many steps that it performs. That means, if you have placed a breakpoint at an early part of the program, you will be pressing F10 for a long time until the program reaches its end point. 

So, what I normally do is I use multiple breakpoints, at places which are important. Then, when I encounter a break point I will only use F10 or F11 until I have looked or observed what I want. After that I will press F5 (which will resume normal execution) until the next breakpoint is encountered. Then, I will do F10 until I get what I want and then hit F5. I keep doing this. This way I am making the most of breakpoints but not wasting my time with useless F10 or F11 pressing. 

Watch 

As you breakpointing and F10ing and F11ing and Continuing, you will want to keep an eye on multiple variables or objects. This is easy. Just right click on a variable (after you have stopped because of a breakpoint) and then 'add to watch'.  

After that, as the program continues to flow, you can see all those variables and objects that you have added to watch, along with their values.


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

Pursuing an important certification

 We wrote about this previously and the exam in question is 70-483. 

Taking this as a opportunity, I have decided to Blog about their progress . Further, I will also blog about topics that might be useful to them, clarify doubts they have and include that could be useful to them. In addition to this, anybody who might be doing something could also find use from the efforts of these students, including future study nildana students who wish to do the same. 

Good luck to them, and me too.


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

Happy With Vodafone

Recently, I wrote my disastrous experience with Airtel Mobile. Thanks to the magic of number porting, I have now officially left my previous mobile partner Airtel, and joined hands with my old friend, Vodafone. Obviously I am pleased that I no longer have to carry two phones everytime I go for a cup of chai (check the airtel post for more details), and I thought I will take this occasion highlight two instances when prompt service from Vodafone made me a happy customer.  

Instance 1 

Way back, there was a time when I had a third number (dedicated to my technology club study nildana). I realized eventually that the investment in the third number was useless and decided to let it go. Unfortunately, times were bad and the bill crept up on that third number and eventually, Vodafone asked their collection agency to look into collecting the dues I owe them.  

The collection agencies are sort of like the folks who stand guarding the doorways at clubs. They aren't exactly polite and will get abusive if the occasion calls for it. Of course, things did not get to the abusive part for I promptly paid up the amount and assumed the issue closed.  

Things got ugly though.  

Three months later, I receive a email from the legal team that I have not cleared my dues. Obviously, this was a shock to me. I was being called from at least 3 different folks (each of them refusing to give me their office address) and each of them claiming that I haven't paid my dues. Eventually, I found out that, the collection agency that collected my money never made the payment. They decided to keep my money and as far as Vodafone was concerned, I was an absconding customer or a 'wilful defaulter'.  

Fortunately, the cash payment was actually an online NEFT transfer. I had solid proof that money was paid to that collection guy from me. I communicated all this to the collection agency and they said they have found that individual who ran away with my money. They said the issue has been sorted.  

Then, things got even more ugly a week later.  

Apparently the issue was not sorted, and now the collection agency has stopped answering my calls, and I was being called again my multiple individuals asking me to pay up!  

Then, as a last resort, I decided to go online and hit up Vodafone on their twitter channel. In less than 24 hours, the issue was resolved! Someone from Vodafone called me up, spoke with the legal team and with the collection agency and I was updated at each step. Awesome! 

Instance 2 

After the Airtel Moble disaster, I waited like a hungry hawk during the apocalypse for the 90 day porting limit to run out. Once that happened, I called up Vodafone and expressed my intention to port over.  

Here are the sequence of events. 

  • Called up Vodafone customer care. 

  • Requested for a documents guy to collect my documents. 

  • Documents guy comes and collects the documents. 

  • A sales manager keeps me updated about the port via watsapp, anytime I ask for a update. 

  • Number gets ported and the sales manager actually manages to activate the specific data pack I asked for. 

Back when I ported over to Airtel, not only did Airtel Mobile not bother to send anybody, they insisted that I walk to the nearest airtel store or forget about ever coming to Airtel Mobile network.  

So, what I see here two large companies. One of them (Airtel Mobile) has become so big that it does not care to take care of its customers. The other (Vodafone) despite its size, going out of its way and actually try and help the customer. 


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