Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Sun, 20 Mar 2011 04:53:38 -0700 Ready Made v Ground Up http://vijaykrishna.posterous.com/ready-made-v-ground-up http://vijaykrishna.posterous.com/ready-made-v-ground-up Now this is a debate ragging in my head for quite some time now. I just completed a project for my college's website. The website was built using Drupal. We are now looking for a fully functional website for the college alumni. And there again, we are looking at Ning as a platform. Drupal wass used by a group of students to build a website. They did not have the time to build the whole thing from scratch. Why? Because they were busy with their projects and assignments. When it came to working professionals building a similar website, time became even more of a luxury than before and we moved towards a more ready made platform. And in all this i am not even talking about the time spent in developing the product. But like all software pros, i am talking about the time spent in testing it, making it bullet proof and then maintaining it. Now, this entails a lot of time. When you come to think of it, if and when someone starts paying you for something like this, it becomes a full time job. But then again, that is a big "if". At the same time, while working as a software pro, i realise the power that custom built software has. The flexibility that it has to offer is too much. You can change anything to anything. It gives you the power to do what ever it is that you want to with a website. Having said that, it requires time. Time which we do not have. So, have we finally come to a point where we are ready to be dependent on someone else all-together for our software solutions? I doubt it. We are still pretty much the same when it comes to wanting something: when and if we want it, we get it. So this is the real challenge in front of us today. We are at a point where we do not have the time to achieve the world, and we are also not ready to settle for anything less than that. And this is the most fundamental challenge we will face in the coming years and this issue or problem or what ever it maybe, will only compound and we have the information growth rate to thank for that. Software solutions from now on can not be addressing specific problems anymore. What does that mean? It means that we cannot restrict ourselves to a set of demands or requirements. While the work domain by itself may hardly change, the dynamics and needs will, and beyond changing, they will grow! This is where i have to divert a little and point out that the very purpose of requirement analysis from now on is not understand the requirements of the business that we are going to serve as software engineers, rather it is to preempt for ourselves, so that we can avoid changing the systems and code (which we provide as products), as far as possible. This brings me to another point about custom made software. You do not want to change it too much. It is true. When you write a piece of code, you do not want to keep modifying it too much. You would rather get it right the first time and be done with it. So in a very basic sense, the very purpose of the custom code is defeated. After all, what is the whole point of have custom software when you cannot, or would not like to bring in any change in it? So i guess all you need is to tweak existing systems. That suffices it seems. So there in lies the trick and the solution. I think there is not point writing software anymore. It is time to start writing meta software. Makes sense?

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
Sun, 06 Feb 2011 13:08:05 -0800 Login Issues http://vijaykrishna.posterous.com/login-issues http://vijaykrishna.posterous.com/login-issues The other day at office, there was some general talk on how people get some really retarded ideas when it comes to making a login process really secure. The particular feature that was in focus concerned the idea of temporarily deactivating a person's login after 3 unsuccessful tries. The simple issue with this method is thus: any one, can deactivate your account if he knows your user-id by making 3 unsuccessful log in attempts using incorrect passwords. This can make life hell for you. So, what are the possible work-arounds? Well, take a look at the core issue that you are trying to address by deactivating accounts after 3 unsuccessful login attempts. I think the core issue is to make it difficult for the person/bot who is trying to login, in case of 3 unsuccessful attempts. Now, try and understand this: the person or bot may not be the actual user himself. So the locality of the issue and its solution should be at the client side of the application where the login attempts are being made, not at the data level where the respective user information is being stored. In a nutshell, make it difficult for the person who is logging in by creating trouble at the UI not by completely deactivating the account itself from the DB. What are the ways to create hell at the UI? There are plenty of them. Off hand i can think of using a captcha after 3 unsuccessful attempts. See, now the entity logging in or trying to log in using a brute force attack will find it difficult to log in. Thus, you are not really creating the issue for the account holder. So, the next question in the pipeline is, how would you create more trouble? Here are a few suggestions: a) Disable the use of the keyboard while entering the credentials. Present the user with the virtual keyboard while entering the userid, password and the captcha. Why I say captcha is that you can use this method after 3 or 5 unsuccessful attempts after the captcha is initiated. This will force the use of the mouse making life miserable for the cracker, trying to crack into some account. b) Start using an audio captcha after a while. But, with this you are negating the users who might be deaf. But that is your call. c) Start asking all kinds of user related information such as the Date of Birth of the User, the Secret Question, etc. d) If all this does not work, send an Authentication code to his email id with which he has registered into the system. If none exists, then ask for a temporary one for the same, and keep asking for the email id on every failed login. This way you can actually keep a track of the kind of email ids being used and you can actually do some background check on the user himself. Mind you all these are ideas that have just bounced off my head. I am sure you can come up with more creative solutions for the same issue. Ofcourse, i would like it if the people, building software systems involving logins for my critical systems such as banks and may be online voting in the future, were not to use such methods. Deactivate the accounts or login credentials. Do so especially in the case of ATMs. That is why i guess we use them in the first place. ;)

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