Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Tue, 05 Apr 2011 06:46:48 -0700 Coding (vs) Logic 1 http://vijaykrishna.posterous.com/coding-vs-logic-1 http://vijaykrishna.posterous.com/coding-vs-logic-1 Yes sir!! it is a battle of clans! Today all thoughts all ideas are going to come down here. And i am holding nothing back. It is a great war this. In the world of software development there are those believe that it is the Coding that matters more than the logic! startling claims indeed. And maybe that is the reason why they have been loosing as well. Logic undeniably is ultra important when it comes to developing software. Those who somehow claim that coding skills can outshine logical abilities, obviously have issues with their logic. But then i sat down thinking all these years and more so in the past few months, thinking if there was/is any logic in what they said. Can coding truly be as important as the logic, where it is built upon that very logic? That was the question going through my head. And that is when i realise that, i was asking the wrong questions. While the theme was the same all through... code vs logic, the concept or the understanding behind their relation was wrong. The real question is this: Can coding truly be as important as the logic which are nothing but mechanical transformations of each other? And with great thought and pondering, i think yes! In fact, Logic and Code are equally important in the whole process of software dev, and this is irrefutable. You see, like i mentioned above, code is nothing but the mechanical transformation of logic. While logic addresses the solution to a problem, coding addresses the solution to the problem of rendering that logic. Logic is devoid of syntax. It is concerned with the mechanics of how a given issue or problem can be resolved. And hence, it is a more universal phenomena. Be it programmer, a manager or an army General, all use logic. They all render it in their own manners. The General does it with Battle Formations, a Manager with Resource Allocation Charts and a Programmer/Coder does it with Code. So, Code like a Battle Formation or a Resource Allocation Chart, is a tool to render the logic used to win a battle or solve a problem. If this use itself is not logical, then there will be issues. If the troops are not commanded properly by their battalion commanders then the army will loose. If the junior managers do not follow the charts properly to allocate resources, then there will be surplus at one place and scarcity at another. If the code is not used correctly then exceptions and bugs will occur. Its that simple. Now do you get the point? Let me put it in a single statement:
Logic renders the solution to a problem, while code renders that logic.
Thus, without the code, you cannot go out to kill the problem. Logic alone is not the answer. So its time that the two clans ack this and greet each other with open arms and paramount respect. Then i thought about how one should go about dealing with logic and coding. I guess that there will always be infighting between the thinkers and coders in any team. Of course the successful bunch are both: coders and thinkers. But coming back to the point, to avoid the natural conflict between logic and code, it is best to isolate the processes. Yes, there is no innovation in this age old idea, i agree. But i am talking blunt firmness. Isolate the two process completely. Do not even think about one when u are busy working on the other. My manager and mentor in my firm has been telling me this right from day 1:
When you are working on the logic/design for a problem, do not think of how it will look in code."
I guess he forgot with the second part to such an apt statement. Never think of the problem and its logic or its design when you are coding. Even though you know that something is wrong, trust it blindly. Get the bugs right. Resolve the issues. Once the code is running and is rendering the given logic then get back to the logic development and enhancement. There is no point shuttling between the code and logic design. Imagine if a General were to do that in a battle: 1. Come up with a Battle Formation. 2. Send the troops in to battle in that formation and the associated orders. 3. "OOOPS!!!" Realise that the Formation and Orders were wrong. 4. Call the troops back, which is half way through the battle. Here we are assuming that a lot of loss has already taken place. 5. Goto step 1, if you have not already lost the battle or if all your soldiers are not already dead. See the issue with the toggle approach if it were employed in a battle. Treat everyday software development as a battle. You are bound to make more profits by making and selling better software than you are making and/or selling right now.

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
Thu, 17 Feb 2011 17:37:25 -0800 Code Integration http://vijaykrishna.posterous.com/code-integration http://vijaykrishna.posterous.com/code-integration It has been a week of thorough introspection and rough hours at work. With ever changing requirements and demands of the software world and its clients, i guess any developer goes through this phase early in his career. The phase where he not only has to produce good code but also keep changing it as per those requirements, and fast!! And all the while, you have to produce bug free code. So what is the secret? How do you keep writing good error free code, with the fast paced changes? Well, let me break the bad news to you: No one can write bug free code in its entirety with significant changes in the software model/requirements being made every other day. But here is the good news: You can reduce the number of bugs by being careful about the changes that you incorporate in your software/code. And this whole process of being careful is called Integration testing. For those of you who treated STQA (Software Testing and Quality Assurance) with little or no respect during your engineering/undergrad days, bear this in mind: You will regret it, for that is the final barometer of a good coder. So, if you did not pay enough attention to that aspect of development, you still have the time. And yes, it is an integral part of code development itself. While many may feel that it is the job of the testers to actually test out code, i fundamentally disagree. Until and unless every form of testing, which the testers do at a more sophisticated level, starts at the developers' desks at a very basic and rudimentary level, you can never produce good software. Never! Don't testers have to learn programming languages, in the basics, to start testing the code? Then why can't developers get some basic levels of testing done at their own end? And it really does not have to be a very daunting task. Here are two very basic guidelines anyone can use to get that basic testing done right from the very beginning: Assuming you are a decent coder, most of the mistakes you will make is while integrating features or different code modules with your software. Take care when you do this. Remember integration of code is not a mathematical addition of the number of lines of code in both modules. Rather, it is the multiplication, or the product of the number ways the data streams going in and out of both these modules will start to interact with each other. How these data paths join together gives rise to new scenarios, which you would not have considered before. Try finding those scenarios. There is always something new. And that is where most bugs reside. It is easy to work in a localized context and develop small modules of code. The idea should always be to think of how, what you code will, effect the over all scheme of things. The other equally important way to counter unforeseen issues in such integrations is to write decoupled code as far as possible. Thus, in its pure essence, a lot of trouble can be averted, if one were to write independently functional code, to begin with. There should be a middle ground (fragments of transformers) where the mappings or collaborations between these sets of independent modules of code should be performed. This also localizes the errors as well. If the modules by themselves are working well, (and this can be unit stress tested), then all you really need to look at as a developer/tester is how the transformer code is really doing. Thinking of your code structure in this way will also give you some ideas about how software should be designed. These are two very radical approaches, one which relies on the fundamentals of testing, while the other relies on the foundations of designing principles. While most coders i find crib about not being able to be a part of the designing process, i wonder how many of them design their own small modules of code, in the best manner possible. Coding is least about writing lines of text in a particular computer language which generates fancy outputs. It is about writing good logic, in a readable manner, which can be well managed thus resulting in easy verifications. I think that every piece of code deserves all of these elements to their core. No Exceptions!!

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, 16 Feb 2011 17:20:52 -0800 SRS: Software Requirement Specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications I was finally able to clean up my comp today off all the trash i had accumulated over the years in college. Saved up a lot of space!! :D That is when i found this rather interesting document worth having a look at. It was a simple straight forward guideline to writing an SRS. I used it while documenting my analysis and design aspects of my final year project. It is to the point and comprehensive to say the least. I guess one such document should always be by your side while working on any project. :) I could never quite locate the true source of this document. It was a life saver for me. So here is the link to it: SRS.pdf Hope this helps you in your documentation and analysis of your projects. 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, 03 Feb 2011 18:16:07 -0800 A Coder's Handwriting http://vijaykrishna.posterous.com/a-coders-handwriting http://vijaykrishna.posterous.com/a-coders-handwriting This is a phrase coined by i-don't-know-who. But this is a phrase used my a colleague of mine at office. When ever there is any issue in the code on the TFS, instead of doing a history check and the past check-ins, this guys identifies the author of that code based on its "handwriting". Interestingly enough more often than not, he is correct. And surprisingly enough, when you think about it for a minute, there seems to be some sense in his method. Any coder, no mater how much he has coded, or whom he codes with, has a basic style of coding. It may change over time. That is because a lot of factors effect how one writes code. The kind of software one uses to write code. The sort of framework/technology/language someone is working with or how much they know about it, the kind of practices one uses while coding, which involve, comments, regions, proper grouping of a particular kind of data variables and methods and the names used for those. Its a sum total of everything. And that is what i think my colleague means. Now every one has their own hand in coding and it keeps changing from time to time, more in the early days of work. But, as you go on, it stabilizes. Or so i guess. You can teach a coder how to use comments, and how to put everything in regions and how to make sure that he uses the same naming conventions everywhere. But there are so many things out there, (hell...even the kinds and number of commenting styles can overwhelm you at times) that it is only human for a coder to pick up a subset of all those standards and notations. Mind you, not all those standards are the best for any and every kind of scenario. But, those such as using comments to write the steps in your code, or place the methods in the probable sequence in which they will be called, or using access modifiers whether required or not, really help in the process of coding well. Many will beg to differ with me at this point, and i do not blame them. For i, myself believe that logic is the most important thing for a coder and everything else comes later. But, having such habits is not a bad thing really. Having comments is good for your own logic building. You really do not have to keep looking at the code and deciphering it, in order to understand what you have done. If you were to write the steps of your logic in comments, then the next time you open your code, you can just pick up from where you left, without dwelling into the code too much. This way you are not wasting time in revising on old stuff but actually moving on to new logic or logic enhancements. And it also makes it easier for someone who has to give you ideas/suggestions/reviews for your code. He can then actually understand what you have written. What is the point of writing good logic with poorly understandable code? Its like writing a new idea on paper with a doctor's handwriting. No one will understand your idea. Not because it was a complex idea, but because your handwriting sucked and your words were difficult to read. Writing neat code also conveys a clarity of thought. I think the reverse psychology also works here. What i mean is that a good coder with a clear mind will in all probability write clean code with proper naming conventions. Similarly, if you were to force yourself to use clear naming conventions you actually begin to have a clear understanding your own code. And that is the first step to good coding with sound logic development. Still not convinced? Look at it this way: You write code for your understanding, not the computer's. The computer will always convert your code to its own language which happens to be the binary, something you cannot not understand anyway. So whom are you writing that code for in a high level language, if not for yourself and your understanding?

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, 24 Jan 2011 17:25:02 -0800 Overlaying UI Controls/Elements http://vijaykrishna.posterous.com/overlaying-ui-controlselements http://vijaykrishna.posterous.com/overlaying-ui-controlselements The overlaying of UI Elements or controls is something all UI Developers and Designers do. While it may be pretty useful, it can bring a lot of questions on efficiency, ease of code and logic. So, lets get down to basics: Why have overlaying or overlapping controls? Well, for one, i have been using it a lot for variable functionality. It basically means making your UI possess a different set of UI elements or controls altogether, offering radically different functionalities in varying scenarios. One in specific is having a ComboBox (drop down menu) on top of a Read-only Textbox. This can be used in a form to great effects. While the user is entering a new Form, there might be a predefined selected set of values which he might have to select from for a given field in the form. But, after saving it once, the selection should no longer be accessible and the value of the field should be permanent for the entire lifetime of the form. To do something as simple as this, we firstly create two different UI elements. Then to manage which appears when, we set up flags or conditions and toggle their visibility. And finally, we manage the communication between these two controls. So let us see the pros and cons of this approach. Pros: 1. It is an obvious logic. 2. With care can be implemented flawlessly, so to say. Cons: 1. Since, quite often you only manage the visibility of the controls, you end up loading two controls where one should suffice, making the UI more bulky. However, this can be negated if the controls are dynamically created. But, this increases back end code and the conditional logic, which decides which control should appear, has to be all the more fail-proof. As, if the logic goes wrong at any point, you have not created that control and the code that is dependent on that control will then start throwing errors, and you will probably take time to track down the root of the issue. 2. If the logic behind the visibility conditions is complex, then there is every chance that the code will fail, time and over again. 3. You have to write more code come what may. You either have to write extra code in the UI markup where you have to define the control. Or like i pointed out in Con 1, you have to make the code behind bulky. 4. The data communication between the two controls, which i refer to as synchronization has to be good at all times. It simply must not fail. The chances of which are very high. So the big and small of all this is that, you have to write more code, which is definitely not localized, which increase of the probability of bugs and make their (read bugs) detection slightly tedious, all this subject to the complexity of the conditional logic and the data to be synchronized. Why go through all this. And mind you this was a very specific and simple case, where you are dealing with two very basic controls: the ComboBox and the TextBox and two very basic data structures: the List of Strings and String. Imagine if things were to get complicated, like they normally do. So what are the possible solutions you ask? Let me draw out a few and let me try and generalize them to a set of similar scenarios. 1. Simple Solution: Keep both controls visible, do not overlap them. This way at least you do not have to manage their visibilities or dynamic creations and that is one thing less to be managed in your conditional logic. 2. Simpler Solution: Redesign the ComboBox so that it acts as a TextBox as per your control logic. One way of doing this is disabling its drop-down after the 1st save. Another method is to populate the combobox's drop down with only one item, i.e. the one that was selected in the form's 1st iteration. This way, you have eliminated the  need for an extra control. There is no need to carry out data sync as there is only one control. The amount of things depending on the control logic has reduced drastically. Overall you are looking at a drastic code reduction and refactor. 3. Difficult and Context-based Solution: Design your UI in a manner which does not invite such situations. Now, that you know such cases can drop up in a UI, spend some time in designing the UI well, before hand. And this is what needs to go into core UI designing. Not the looks necessarily. The usability, the implementation, the functionality. Hence, the big and small is to either keep both the control which eliminate the tough and critical task of managing their visibility or creation+destruction. And to eliminated Data Sync which is another critical task. You should in essence try and make the Data and till an extent Control Visibility, independent of the conditional logic. If not that, keep the dependency to a minimum as they are critical for the UI, simple. There are other cases as well. Such as, toggling between icons, one says List View and the other says Tile View. Keep both icons, what is the harm? Another case is to overlap a password box on top of a regular text box with a check-box which say "show". One stores the password in plain-text and is invisible if the check box is not checked, while the other keeps in the star or dotted fashion and is visible by default. This enables the user to see what he is typing, by simply checking the check-box. Why have it? Make him retype the password. Hiding context menus items, when they are not required on a page for a particular context. Disable them. There are 5 other simpler methods of doing things for a given task. Pick one, they do not look that bad. Simplicity is a virtue.

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
Mon, 17 Jan 2011 18:03:23 -0800 Defensive Coding http://vijaykrishna.posterous.com/defensive-coding http://vijaykrishna.posterous.com/defensive-coding I will keep this short and simple. Today a senior of mine uttered this phrase, when i was talking ab0ut spanning out null checks all over the code. He said that it will be defensive coding and i soon realized why. The moment you have null check for everything in your code it becomes a little difficult to track down the root of the issue. While your code will be all running and may never break down, there will be issues which will look so mysterious to you that you will end up wasting an entire day just trying to debug one of them. So, while i am a proponent of exceptional handling, may i remind of the golden line: "everything in moderation". Let me give an example of how Defensive coding can be counter productive. I was debugging my code today when i started encountering object refs in my mapper functions i wrote to map the service objects to the UI objects. Now, at first glance i cursed myself for not doing the correct exceptional handling at this level. But, then i went about finding the source of the object ref. As it turned out that even after narrowing the possible issue to one function, i realized that i was using that mapper at 3 different places with in that function!! Thus, i had to debug at each place and figure it out. It was not a one glance thing. And it became so difficult simply because i had done a lot of exceptional handling in all these cases and then the odd case of corrupted was plauging me which was showing its true colors due to a missing fragment of a if-condition (4 conditions were already being tested for, and an extra 5th was now necessary). Its easy to say that the code should have handled it. But, why in God's name was such data being provided in the 1st place. Cross checks are good. But, they should not be overdone. With every stage the flows through there should lesser number of null checks required. Checking for null values or doing exceptional handling for a particular scenario or case, at the DB layer, service level and UI is plain waste of time and a level of redundancy you must avoid. Not, more than twice. It is a huge task to keep a thorough track of this, but i think that this is just another and better coding practice. Don't you?

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