Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Wed, 13 Apr 2011 06:39:49 -0700 True/False http://vijaykrishna.posterous.com/truefalse http://vijaykrishna.posterous.com/truefalse This is about a debate i had with my manager off late. We were discussing about converting the bool values of True/False that we get from the service to appropriate values such as Success/Failure or Yes/No or Active/Inactive, depending upon the context. That is when i commented that True/False are generic (and thus, they should be replaced with more specific values like the ones we were discussing). That was not the debate itself. But he somehow claimed that True/False are the same as Yes/No. I was a little appalled at hearing this. Although i could not pin point it to him then and there, and he won the debate, i knew that there was something wrong about that whole notion. And i could not help but think about it. And the more i thought, the more did it became evident to me, that True/False is associated with Fact, while Yes/No is associated with Agreement. I was still not convinced, and went on to search for the meanings of Yes and True. My ideas were confirmed and this is what thefreedictionary.com had to day about the two words: The meaning of Yes as given at thefreedictionary.com ::
yes  (y
Media_httpimgtfdcomhm_bkgaq
s)
adv.
It is so; as you say or ask. Used to express affirmation, agreement, positive confirmation, or consent.
n.pl.yes·es
1. An affirmative or consenting reply.
2. An affirmative vote or voter.
tr.v.yessedyes·singyes·es
To give an affirmative reply to.
interj.
Used to express great satisfaction, approval, or happiness
  The meaning of True as given at thefreedictionary.com ::
true  (tr
Media_httpimgtfdcomhm_ofrij
)
adj.tru·ertru·est
1.
a. Consistent with fact or reality; not false or erroneous. See Synonyms at real1. See Usage Note at fact.
b. Truthful.
2. Real; genuine. See Synonyms at authentic.
3. Reliable; accurate: a true prophecy.
4. Faithful, as to a friend, vow, or cause; loyal. See Synonyms at faithful.
5. Sincerely felt or expressed; unfeigned: true grief.
6. Fundamental; essential: his true motive.
7. Rightful; legitimate: the true heir.
8. Exactly conforming to a rule, standard, or pattern: trying to sing true B.
9. Accurately shaped or fitted: a true wheel.
10. Accurately placed, delivered, or thrown.
11. Quick and exact in sensing and responding.
12. Determined with reference to the earth's axis, not the magnetic poles: true north.
13. Conforming to the definitive criteria of a natural group; typical: The horseshoe crab is not a true crab.
14. Narrowly particularized; highly specific: spoke of probity in the truest sense of the word.
15. Computer Science Indicating one of two possible values taken by a variable in Boolean logic or a binary device.
adv.
1. In accord with reality, fact, or truthfulness.
2. Unswervingly; exactly: The archer aimed true.
3. So as to conform to a type, standard, or pattern.
tr.v.truedtru·ing or true·ingtrues
To position (something) so as to make it balanced, level, or square: trued up the long planks.
n.
1. Truth or reality. Used with the.
2. Proper alignment or adjustment: out of true.
Here is the funny bit: the word "true" could not be found in the meaning of Yes and vice-versa. And this is the investigative nature i guess any engineer must have in order to do well. that is the truth... yes?

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Thu, 03 Mar 2011 18:19:42 -0800 What has to go wrong, will go wrong http://vijaykrishna.posterous.com/what-has-to-go-wrong-will-go-wrong http://vijaykrishna.posterous.com/what-has-to-go-wrong-will-go-wrong In a software development process, there are always roadblocks, detours, U-Turns, poor pathways and long hopeless drives which seemingly lead no where. It happens in all kind of firms, big and small. It happens in the development in all kinds of systems, simple and complex. What has to wrong, will go wrong, and there is very little you can do to avoid it. But you can manage it well, if you are prepared. But here is the funny bit, most of your preparatory skills come with experience. So do not get upset if you do not find the IT industry the way you thought it would be. Its not a perfect world, and this walk of life is no exception. While coders in larger and more well established institutions do not realise this, simply because they are shrouded by the proceedings of the requirement analysis and design phases too well. There needs to be a major upset in the project for the coder to actually feel it. Its only the managers who realise it first and always, as and when the shit hits the fan. I guess that is why they are managers. And that is where they are important. While coding is fundamentally about good logic building abilities, software development is about good logical foresight. You really need to see what will go wrong even before it does. The idea is never to think of the known possibilities. It is to figure out the less obvious and make good preparations for the unexpected. Mind you i am not talking about major or minor bug fixes. I am talking about founding in the architectures and the fundamental designs of the system. I am talking about not getting the requirements correctly, or not converting them to the correct data and logic flows. There is always an element of error, which cannot be avoided, but it has to be minimized. Some of the best ways to do them is maintain modularity and flexibility in everything, right from the design to the code that you develop. Working in a startup has helped me realize this very early in my career. People do not badger about those two things with no rhyme or reason. There is good reason to it. And better you are at doing something like that, better you will do in this business of software. Having blabbed about the IT industry and its flaws so much, let me let you in on another piece of information. The client is a greedy lazy pig! I cannot put in simpler terms. He wants more, always, than what he already has. And, he will never work hard at understanding his own demands and requirements, leave alone telling them to the person in front of him. He will sit there like the Google search engine, waiting for you to ask the right questions for him to come out with the right answers, if he is willing. Google, an artificially intelligent piece of code, is kinder in that respect. Let me let you on the last secret of this trade. Even if you were to get a fantastic client who were to understand and convey his demands well, and you were able to get the right architectures and designs in place, and all this was followed by some fantastic coding which rarely ever produced any minor bugs (if at all), you are still liable for changes, due to the changing dynamics of the businesses for which most softwares are being developed these days, at least the money minting ones. AT first I would curse these hurdles and crib about the imperfections with which we go about engineering software solutions. Then, right when i got stuck in my most horrible pot hole along the road to a good development process, i realized that this is where the real fun is. Its is never about how hard you hit, its about how hard you can get hit, and keep moving forward. How much you can take and keep moving forward. So take my advice, if you are stuck in one such pothole, and get up, because that is how some of the best software is written. This is the element of adventure in this career, enjoy it.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Mon, 28 Feb 2011 17:54:33 -0800 Pages, Views and Popups - Data Flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows I think i have written a few posts on popups and the issues with layer development before. Today, I was encountered with another classical situation involving Pages, views and pop-ups. And for a change i was invited to be a part of the debate. The scenario was as follows: We had a page, which was in all essence a master page dealing with the background service. This page fundamentally had a tab control with every tab's container having its own control. Now each of these controls led out to one or more popups (again effectively more controls). The issue was to treat the controls as controls and try to relinquish them of all Svc calls. Mind you at this stage no calls were being made from any of the controls but we just wanted to come up with a solution where in we could once and for all decide a standard protocol by which we could completely avert situations involving svc calls being made from the controls. After a good length of discussion we got to the following structure: Svc <> Page <> View Mode control <> Edit Mode Popup The idea was to manage data flows in this simple scheme of things. After some more nut cracking we came down to the following 2 alternatives: A) Svc <> Page <> View Mode control <> Edit Mode Popup This basically suggests that the data coming in to the page from the Svc should be passed on to the page as it is, the page to the View Mode, and the View Mode to the Edit mode and similarly all the way back. Fundamentally, each entity will interact only with the one in front of it and the one behind it. That is, the page will never interact with the Edit pop up directly, the View mode will never interact with the Svc, ie make Svc calls. B) Svc <> Page <> {View Mode control, Edit Mode Popup} In this arrangement, the Page can now interact directly with the View and Edit controls. That is the only difference between this and the previous arrangement. Now for anyone to understand the implications of either arrangements, i need to highlight the interactions between a control and the page. The control will have all the buttons to actually perform operations by the user. But they will not be any Svc calls emerging directly from the control itself. On a button click, the control will raise a Button_click event which will be handled in the page by the required Svc call. It may seem complex, but if you have read my previous posts, which i mentioned earlier in this post, then you will realise that with such an arrangement you have actually decoupled a UI fragment from the data processing unit (the page) and data supplier (the svc). With that, you can actually use the same control in a similar context with a different svc and processing unit, giving similar data. Similar interactions will exist between any two controls as well. Now with that out of our way, let me get to the point. In arrangement A, the work is distributed across the entities. There isn't a lot of control resting in one place. A fair amount of modularity will be introduced with that approach. And hence the over all code will be neat and clean. But if a change is required it will have to be done at multiple locations. While in arrangement B, with the page interacting with both the View and Edit controls, the Page will end up managing a lot of Events that will get raised by double the number of controls as compared to that in A (assuming that each View Control has an Edit control). This will localize the code, resulting in the reciprocal of arrangement A. The code will be difficult to manage with so much happening in one place, and hence the code can get ugly. Mind you with effective code management this can be resolved. But at the same time, if there is an error or change in the way the data is processed, there will only be one place where all the changes will have to be made. Which will anyone pick is a matter of great debate and discussion. The correct answer depends entirely on the situation at hand. I picked one of them based on the existing code structure, so that is an important parameter while making such decisions. And for those who will suggest that should merge the View and Edit modes: solve the problem, don't change the requirements.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Wed, 19 Jan 2011 17:45:50 -0800 Contrast http://vijaykrishna.posterous.com/contrast http://vijaykrishna.posterous.com/contrast [caption id="" align="aligncenter" width="500" caption="The CPU behind the white monitor is better"]
Media_httpfarm5static_fxkvj
[/caption] Interesting pic for today. Took this at my desk at office. At a friends b'day part. ;) Cheers!!!  

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Tue, 18 Jan 2011 17:43:19 -0800 A Pop-Up Story http://vijaykrishna.posterous.com/a-pop-up-story http://vijaykrishna.posterous.com/a-pop-up-story This is a tale of what i did at work today. It was lousy in a few ways but educating in many others (its all about perspective). Well, i was doing a lot of code refactoring today and it was truly, and no jokes here, truly a good leaning experience. The theme of today's lesson was simple, Encapsulation. In more elaborate terms, i learnt that service calls should not be made from pop ups. Why? Well, no one has given me any clear reason so far. But somehow it makes sense. A pop up is something very intermediate, right? Its primarily used for peripheral functions. All the actions of uploading data, giving out warning and status messages figures in pop ups. So why should you be making service calls from it? Apart from that, there is another reason why you should not be doing something like that: a pop up is essentially a control as well. Any control you ever make has to be under all circumstances independent of anything else. If there is anything that needs to be passed on or from the control, define and use public properties or information hooks off the control or in this case a pop up. This allows you to create controls which can be used in more than one place. A lot of UI developers ask what that perfect design is, and i answer in terms of re-usability of that control or UI element. Today i learnt the nuances behind making reusable controls. And there is no great hard work or intelligence involved what so ever. It is just a matter of being deliberate and particular about a few simple rules:
  • i will not use any UI element of a control directly.
  • i will not pass or extract any information from any UI element inside that UI control directly.
  • if i have to set or get information or make configuration changes, i will do so via publicly defined properties which i will use as my birth right. ;)
  • and i will set all my UI elements as private so that i never get to use them even if my evil mind tries to do otherwise. ;)
Any control is like a class, exposing a few functions and methods. It should only give just about enough access for the controller or user of the control to make it do what it is supposed to. How it does it and how it manages its own configuration should be its own headache. That is how good independent code with the least amount of dependencies can be written. There is nothing more destructive to a coder than to write code which is dependent with its environment. Any and all code and solutions should and have to be as generic and independent as possible. That is how you are able to replace chunks of code easily in case something goes wrong. It also gives you the independence to separate the code out and, develop and test it independently. I learnt it the hard way. I hope you pick it sooner. Cheers!

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Thu, 13 Jan 2011 17:51:06 -0800 The Attitude to Search http://vijaykrishna.posterous.com/the-attitude-to-search http://vijaykrishna.posterous.com/the-attitude-to-search Second Year of Engineering, boring lecture in motion, fed up. Some of us stand up to tell the teacher that we have no interest in enduring this ordeal. The lecturer tells us that in no event will she teach the on-going topics, which is recited out for us to register, ever again. We walk out and one of my friends says out aloud, "Google maar lenge", Hindi for "We will google it." And Google those topics we did. That is the attitude of search, one has to develop in order to survive this rough, competitive and demanding world. You have to embrace one fact of life: You cannot know everything, but the world will expect you to know it all. That is what demanding means. And you have to take it like that. So what do you do, to meet such demands? Do you try and know everything? Well, even if i could, i would not. Why, u ask me; well those are reasons devoid of logic so let us not go there. But, the point i am trying to make is simple: you cannot know it all. So what is it that you do best to cover up? You develop this unique ability to look for clues and search for the answers. Of course google has made it so much more simpler, but that is not the only source for solutions, and you need to find more accurate ones, with more effective results. As an IT professional, this is the single most important that i have learnt. There are too many technologies floating all over the place. And there are too many people master all of them. You cannot compete with them. Unless you have a trusted source which tell you the answers provided you know the right questions. This sounds a little like cheating in an exam. But this also sounds a lot like the old saying that has been repeated to us time and again: The answer lies in the question. Atleast at my workplace we are encouraged and sometimes forced to fend for yourselves when it comes to looking for answers. This very fact was also tested a little in our selection process. We were free to access any resource of knowledge available on the net. The fundamental idea was simple: get the results, one way or the other. While this post is philosophical in many ways and logical in few others, i took this day to state it so explicitly simply because i see that urge to search for answers either missing in many and dying in most. Develop this attitude to search for the unknown piece of knowledge, for it may be the only piece of true adventure that many will ever have.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Wed, 12 Jan 2011 17:58:10 -0800 Trivial Error http://vijaykrishna.posterous.com/trivial-error http://vijaykrishna.posterous.com/trivial-error Well, this is a post about how i made a real silly mistake when i could have easily avoided it. I want to share this experience so that others can gain something from it. So here is the Scenario: A classical integration of the services with the Silverlight UI. All calls are Asynchronous and hence all, of them have a get completed event handler. So, here is a page where i have to make 2 service calls and thus two event handlers. Service Call 1 (SvC1) was to get the data for the UI. Service Call 2 (SvC2) was to get a certain key value pair which would dictate the number and content of a set of check boxes in the UI. So in essence, i was using SvC2 to dynamically set up controls (i was using an items control). Mind you, SvC2 was never returning the controls it self, it was simply giving me the data, i.e the Label/Content property of the check boxes and their tooltip/description property. And yes, the UI has a standard New and Open scenarios. Here is what i did: I made the call to SvC1 first and set up the data context as required, ie the data context would not be set in case of a New Item creation. So, whether or not i was going to bind the data, i would be making the call. Then, irrespective of that, i make the SvC2 to get the data for the check box controls and then with the data-context (if given), and the data from SvC2, i create the controls. Now, why i say "if given" in the previous statement is because some of the check boxes would be clicked if the data context were given, else all of them would be false or not clicked. There is another issue, once i have created the check box controls, it will be very difficult to access them (they are inside the ItemsControl). I would rather make the controls, and assign the data to them in one go. I would not like to split these two tasks, for the sake of simplicity of code and its understandability. Here is what i should have done: I should have made the call to SvC2 first, which would have returned the list of data to be shown in the controls i.e  the check boxes. Then i should have called SvC1 on the Completed (event or on completion) of SvC2, and set the data context, i.e. bound the data with the controls. While doing this i should have set the items source for the check boxes, or, in simple words, i should have created the check boxes dynamically using the information i got in SvC2. This way, a) I would have gotten the data for the controls before hand, b) I would have made the check on the data-context requirement on the completion of SvC2 and before calling SvC1, and end up saving one SvC if required. Otherwise, i was making the SvC1 no matter what and then probably not end up using it and then call SvC2 anyway because it was being called on the get completed event handler of SvC1. c) And finally, i would still be able to create the controls and bind the data to them in one go. You may not be cutting trees by making an extra service call, but you sure are troubling some million electrons for it. :D So take care, use the Service wisely.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu