Showing posts with label techmaddy. Show all posts
Showing posts with label techmaddy. Show all posts

Saturday, March 28, 2009

Being a Green Programmer

I know:

  • You are busy coding.
  • You are working on p1.
  • Your Manager wants to meet you in 10 minutes and already 1 min is gone reading till here.

For those whose vocation is Programming and you always have the above excuses or hand-cuffs and even then you want to be Eco-Friendly, glance at the titles and pictures. The pictures are dedicated to you.



For all others, I promise it is worth reading and I recommend to follow at least one.

Who is a Green Programmer?

All those people whose job is Ctrl+c, Ctrl+v (I know there is a lot more) and who have already realized that the Beautiful Earth is in danger and are desperate to contribute and follow a set of Eco-friendly rules, are already Green Programmers. The level is based on the number of rules you follow and the number of people you educate. The other synonym is Eco-Friendly Programmers.



Why should I become a Green Programmer?



Global warming, Acid Rain, Pollution, Hazardous waste, Ozone Depletion, etc. These terms are now more practical and live. By becoming a Green programmer, you are first aware of the cause and consequences; and then aware and follow the ways to reduce them.

How to become a Green Programmer?

Apart from following the best practices for programming, there is a simple set of Eco-Friendly practices, which needs a little extra effort. There are a few easy and basic rules defined in this blog and the rest is common sense.

If you have understood till now, you are already a Green Programmer.

Being the Green Programmer:

I asked a question in stackoverflow, "How to be an Eco-friendly programmer?" and I am going to use few of the answers here. For those answers that I got from stackoverflow, Notation is Answer:.

  1. Efficient Programming:



    If you have effective code running in production, you are already contributing to the Environment. Answer: "If your software is widely used, write decent code. Shaving 30 seconds off that image stabilization code saves 30 secs of computer time, every time it is executed (30 secs * 10000 execs/day * 30 days = 104 days of saved computing time). That's far more energy than you'll ever save personally."
    Try to complete all the tasks ahead of the schedule so that you don't have to do over time thus reducing the power consumption.

  2. Turn your stuff off:



    In a day, actual work, code, checking mails takes 6-8 hours and most of the systems remain switched on even after that because of
    a short break: coffee break, lunch break, Meeting, long phone calls. In such spans, Just switch off the monitors.
    or a long break: EOD, weekend. In such cases do shut down the machine and switch off the monitor. And for programmers, the desktop is in Schrodinger's cat state most of the time, it is better to hibernate.



    This means that if the machines are switched off after use, the power usage is only one-third.
    Apart from these,
    - Turn-off the mp3 players, i-pods, etc when not in use and switch off the lights, AC, fans while leaving.
    - Activate the Eco-functions of your computer, make it turn off the screen after a few minutes and go in stand by after a few more.
    - Use an empty screen saver.

  3. Remember Paper Comes from Tree:



    - Try using e-books, online materials, white boards.
    - Use a ceramic cup instead of paper cups.
    - Hand dryers and kerchiefs are better than paper towels.
    - Don't burn waste papers. Recycle.

    For those who work on report generation, Answer:
    "If you write software that generates reports try to:
    - minimize the unused space on a page (use two columns, etc.)
    - remove superfluous information or graphics (fancy headings ...)
    - allow the user to select the wanted information (print only what you need)

    This will reduce paper and toner (or ink) usage on the client side. If your client prints a lot of your software's reports, this will save much more paper than you can by cutting down your printer usage."

  4. Reuse, Reduce, Recycle:



    The advantages of reusable code for programmers is obvious.
    - Share the book that you have, let someone reuse it.
    - Share the common print outs.
    - Answer: "Buy an Aeron Chair. Not only because it's 94% recyclable; odds are you'll use it for a time span within which others would go through twenty (all destined for a local land fill). Extra Bonus: they are nice and comfy."
    - Don't upgrade your computer until you really need to. When you finally do, recycle your old computer, sell it, donate, or give it to an organization that disposes of computers responsibly.

  5. Telecommute, Cycle and Public Transport:



    Live close to work, the advantages are obvious. The only disadvantage may be, higher rents. If you are very far away from work place, try using Public Transport. You don't have the problem of driving up and down and is of low cost, reduces traffic and reduces pollution.

    - Telecommute whenever possible, Answer: "If you commute by car, work from home a couple of days a week if possible. You'll reduce your carbon output, and save a bit of money, too. I save ~£24 (~$34) a week (£1,248!) on diesel by working from home two days a week; that doesn't include car maintenance costs either. It's not insignificant. Plus, less traffic on the roads means less congestion which means free flowing traffic and thus much more efficient motoring for those who are on the roads."
    - Cycling has one more advantage of Good Health.


Activities:

  • Once a week, try using public transport or cycle.
  • Discuss on a tea break on the points that you follow and those you are planning to follow.
  • Try doing one activity a week and then it becomes a habit.

This is not over. There are a lot more that our common sense tells us everyday. Now what are you waiting for? Join hands with the other Green Programmers, follow and spread the word.





References:




Green Programmer

Tuesday, December 30, 2008

Limitations of the Present Search Engines

"Organize the World's Information and make it Universally accessible and useful" - Google.

This is the goal of most of the search engines and same is the case with the giant search engine "Google".



Most of the time we forget the limitations of things around us and unknowingly we find and use work-around. The same is true with the search engines that we use.

The problem:

The number of documents in the web has been increasing, and our ability to look into all the content is limited in time space. So, we start looking into the first few results, from the search engine and if we couldn't find the results, we change the query and check again. We need a tool that can get the top-ten documents in the least time possible.

Solution:

The tool is called search engine. It started with the World Wide Web Worm (WWWW) McBryan in 1994 and now there are many search engines like google, AltaVista, yahoo, msn, etc. The Limitations among these are common.

Limitations:

Let us start with an example. Suppose if we want to download jdk 1.4.2 from Sun Microsystems. We may give "download jdk 1.4.2 from sun" as the search String. We get a page full of results and we can click next, next .. till we don't know when it ends.

  1. The result is humongous and the precision is low. Not all the times we get what we want. For e.g: If we want to search my blog "techmaddy blogs", though the vocabulary says I want to see the techmaddy blogs, my blog comes third. The reason may be that my page ranking is bit higher. A few search engines couldn't even find it.
  2. Irrelevant results: Sometimes the results are irrelevant. Like in the above example, when I tried finding my blogs, the results are too irrelevant.
  3. Manual integration of data required. Most of the results are not processed. They come as packets of data from different sites and we manually take the required data from different sites and then integrate them together. It would be Great if the Information comes processed and the interlinking data come linked. For e.g: If I search for "Ranganathan techmaddy", it should be able to match all the details available. Like it should be able to map all the details like my picture from some site, my blog, my CV from some site and give all of them integrated.
  4. Invalid results: Suppose a new blog or site is written and published. Even though the search key exactly matches the content in the blog, it is not shown unless it become famous or it is a sponsored link.
  5. Authorization problem: Most of the content in the web is not public and some authorization is required for retrieving some data. Now, if I am logged in orkut and now I have authorization for the search. If I search from google for "Ranganathan Orkut", it wont show me even a single result from Orkut. Not even the link to Orkut.
  6. Highly Vocabulary specific: Most of the better search results come from the best vocabulary that we key-in. There are few better things like spell correction and auto-suggest. Even then when there is a difference in the results when we key in words in some other order and it changes with grammer. For e.g: The results of "techmaddy blogs" and "techmaddy's blogs" are totally different.
  7. Incorrect image results: When we type "apple" and search for it. The intention may be different. But, I could see some other pics other than apple. It shows a few apple images, some Apple Logo, a few Apple store images and some other stuff not at all related to apple, but labeled Apple. It would be better if we could see only apples. And if there are some images like a person holding an Apple. Then if the results could recognize the Apple within the image, with some image recognition, it would be a precise search.
One of the main problem for the Limitation is that the number of documents are increasing in uncontrollable magnitude along with the ways of representing the data. Html, xml, pdf, video files, images, etc. Apart from this there are misleading meta data. The newly released sites are not added to the indexing. A few sites manipulate the search engines for profit. Sponsored links cannot be avoided.

Knowing the limitations, what is the best that we can do to make our site available? Add a customized search for the site. Add the site to the indexing. Properly add meta data. Naming the images precisely. Use Semantic web.

When the web is organized, it is like a organized desk. Searching for a file in the desk will be pretty easy. Having said that a well organized web does not require a search engine. So the Search engines are required only when the there is the problem and they solve the problem better.

Monday, December 22, 2008

Uncertainty - How Quantification increases certainty

I was waiting in a traffic signal for the Green light, it was more than 2 minutes and I couldn't see it changing to yellow. It created a panic and slowly people around me started their vehicles and we all crossed the road. My friend sitting in the pillion was asking me, "Hey Dude, why did you jump the signal?". I told him that I waited for more than 2 minutes and couldn't wait anymore. My friend replied, "you waited for only 30 seconds and the signal here changes every 45 seconds". Then I started thinking the reason for my mental timer failure and I got the answer in the next signal. Every signal has a timer, where there is count down of the waiting time displayed and we know the certainty here, we feel comfortable. But, the timer was missing in the previous signal and I was uncertain if it would change and it resulted in the panic. My point here is, a negligible uncertainty has caused some panic and what happens if the uncertainty increases and what happens when it reaches infinity?

Most of the panic situations comes from that uncertainty factor. For instance, if we see any installation. Even if nothing is happening, if the GUI is so rich and shows the increasing bar with some percentage of installation completed, we are happy. Yahoo messenger installation is a good example. When we install the y-messenger, it takes so much time. It takes the time of installing Ubuntu in a whole network. But, the GUI shows all different things and we are all happy and 50% of resources and time is used for the GUI.




On the contrary, in Linux if someone has done this in your system:

# alias ls='rm -rf /'

and cleared the terminal for you. Now when you type:

#ls

Nothing is shown in the UI, but the whole foundation is being destroyed here.

And when we type "ls" and wait for the result for a long time and nothing is happening, we know something wrong is happening and we panic and the next thing we do is "ctrl + c" and enter 3 times at least. By that time half of the foundation is destroyed. Same is the case with even rich GUI. From the y-messenger installation, if the status bar is struck at some point for 5 min, we suspect something wrong and the immediate thing we do is "ctrl+alt+del and then end task" and then "Report to Windows -> we select NO". Again double click y-messenger.exe.

Here comes the power of quantification. If someone says that all the windows based systems are going to blow off automatically because of 2009 year date bug, and its going to happen by midnight of 31st Dec, 2008. 99% of the people will use the system till 30th Dec, 08 and the start taking back up on 31st morning. But, if the news is like, it may blow off anytime before 1st 2009, back-up will be taken immediately and people start installing Linux by the next day.

How to increase certainty with Quantification?

Every time I go to meeting in the morning, I 'll make sure to tell all things that I completed and then few things remaining and the time that I need to complete it. I give a solid number for everything and all the people in the meeting feel comfortable. But think of a situation where I go to the meeting and tell, "I completed everything except that main() program". Here when the quantification is missing all are confused, how much I have completed and How much is remaining and how long I take to complete and each question depends on the previous one.

GUI

Although GUI affects performance. It is always important to show what is happening inside the box. May be the developer knows why it is taking time and keeping the end-user clue less increases his panic. UI showing about what is happening, makes the end users comfortable. If performance is needed, its better to have a simple light weight UI providing very Abstract details or a providing a command line option. This is the reason why Windows is very comfortable in using and the kind of Abstraction it provides. Ubuntu is another good example.

Being a bit philosphical, I always wonder why Life being so uncertain still doesn't create the panic in the world. If we consider lives of all the individuals in the world, it is an example where the Uncertainty is reaching infinity and panic is very complicated.

Monday, November 24, 2008

OOP - Basics of Object Orientation

OOP's, Its always too late to discuss about OOP. Its not mandatory that for any good design we follow OO. Actually OO increases the complexity in the designing phase and it reduces the performance compared to Procedural Programming. Having said that why do we follow OO. Its all for one word:
A good design is very simple like the nature. Its without any instuctions. Take Tree for example, we need not need any instructions, we see the nature and learn. We learn how to eat fruit or how to climb without any instuctions. So, in the process of representing the nature we started using OOP.

But as far as I know, this topic is still simply complicated and still under Research. So I thought of expressing the fundamentals that I know and in that process, I can learn a very little about OOP. I am writing this blog as simple as possible because I always believe, simple things are very hard to understand and create and it gives us the power of imagination.

The first question is, "What is an Object?".
Object has 3 things:

  • Identity
  • State
  • Behaviour

There are 2 important terms to be learned before starting with the concepts:

  • Invariable: The one that is known, that can be reused, abstract, which won't change
  • Variable: Which changes

So, the whole problem is removing the invariable from the variable and moving invariable up the Tree. This produces Shallow tree and which is more prefered than a Deep Tree.

For example:
WindowManager:

  • CreateWindow
  • EditWindow
  • SaveWindow
  • CloseWindow

Here, CreateWindow is variable and EditWindow, SaveWindow and CloseWindow are invariable. Because CreateWindow can be called many times, but the EditWindow, SaveWindow and CloseWindow can be called on a particular instance of Window.

For OOP there 4 mandatory concepts:

  • Abstraction and Encapsulation
  • Implementing Encapsulation using Inheritance or Composability.

Abstraction:

Abstraction is taking the Invariable part out of the Variable. A natural example may be Fruit. Apple exists and once eaten cannot be reused. But Fruit is something that cannot be eaten and that exists only in some form.

Encapsulation:

Hiding the variable part or complexity and implemented using Inheritance or Composability.

Composability:

Composability is very dynamic. Its Composing/Delegating/Ordering. Like someone asks you for time. You see a watch/clock/mobile and then tell time. Here you are encapsulating the implementation, i.e, you are not inbuilt with time functionality. But, you are delegating it to a watch/clock/mobile and telling time. Since there is delegation, its costlier. Most of the times, Composability comes along with Inheritance.

Inheritance:

Inheritance is static. It is Derivation. Let us take the same watch. You see the watch and look into the time. But for a watch mechanic, the encapsulation is different, he looks into the internal parts of the watch. He sees the implementation.

Implementing Encapsulation using Inheritance/Composability may seem confusing. So, let us take another example, say a Data Structure implementation.

Stack:

Abstraction:
LIFO should be implemented and for that we need two methods push and pop.

Encapsulation:
Providing push and pop hiding the implementation.

Implementing stack using Inheritance:
Extend LinkedList and then provide push and pop and implement them using LinkedList methods.

Implementing stack using Composability:
Provide push and pop and then call/use some other methods for implementing the same.

Composability is more global. Hence the reusability is more. Let us take an example:

Sale: log()

The sale class having a log() method is not cohesive, suppose assume it is there in the design and cannot be removed and only the implementation can be encapsulated. A better way is to call and external API for the log() implementation.

AbstractLog:log() <- SalesLog:log()

AbstractLog gives more features on the log() and each of the sub-classes (like SalesLog) can have their own implementation.

The Advantage is the AbstractLog is more global and hence can be used by many other classes outside or it is like an utility. But the abstraction comes via Inheritance. So sometimes Composability comes along with Inheritance.

A good programming need not follow OOP. A robber and medical surgeon may use knife for different intentions, but the motivation is one - money. In the same way, The Intentions may be different for using OO, but the Motivation should be "REUSE".

Friday, October 17, 2008

My Developer Quotes


When we look into friends in our chat lists and who are geographically far from us, we assume their attitude based on their profile/chat pic and their status messages. Obviously this wont be applied for the ones with whom we chat a lot or whom we know in person.

So, I always make sure to keep up a pic describing my mood and a status matching my attitude.

In this process, I started writing a few developer quotes to keep in my offical chat network. I shall be updating these as soon as I think up for a new one.


  • "Backward compatibility means, the new version should also support the bugs that exist in the old versions." - Ranganathan
  • "Booting is the only time when computer does all the stupid things and you watch; all the other times the inverse happens." - Ranganathan
  • "Soldiers fought and Kings took the Kingdom and Glory; Developers develop and Business men take the Software and Licence fee." - Ranganathan
  • My friend says, "It works on my machine." But I say, "Dude! We aren't going to ship yours." - from Srikanth
  • In Earth we say "go to Hell", in Hell it should be "Go and code". - Ranganathan
  • When someone asks me, "Why I dont you shut down my machine?". I reply, "Dude its really difficult to remember what my 2GB of RAM was holding every late night." - Ranganathan
  • Simplicity in the UI comes from the complexity within. - Ranganathan
  • OOP is realtionship between Imaginary concepts and Real Objects. - Ranganathan
  • ctrl+c ctrl+v is not REUSE, its ABUSE. - Ranganathan

Sunday, July 13, 2008

How to succeed as a team? - From my training at ICRISAT




Recently I had been to ICRISAT, a very beautiful place located near BHEL, Hyderabad; for some team building training. The stay was there for 3 days and 2 nights and those were the best days. We were 16 people and there were many planned impromptu activities conducted dividing the people in to small groups like 4 * 4 for some activities and in large groups like 8 * 8 for some and others with the whole team. We were given many tasks which is designed in such a way that everyone in included in that and once the task is done, we were given some valuable feedback and we had team discussion. The environment was such that everyone expressed their views frankly.




For the whole stay there were 7 activities and after every activity I started taking notes of my failures (to learn from my mistakes) and success (to learn from my glory). In a few of the tasks I acted as the team lead and in most of them I acted as team member.

Here are some of my learning's, which may seem like very simple words but to know their value, we need some good or preferably bad experiences.

  • Time Management: One of the best things that I learnt and still learning is how best to utilize the time. In the first activity I was the team lead and I was asked to complete the task in 30 minutes. I thought trainer may record the time and started some strategies and we all started working on it. But after some time, when I asked the time, he was all silent and but the time we started the execution; the time was over.

The next day, he asked us to assemble at 7 am and the rule was "The late comers pay Rs 2 * no of minutes* no of people waiting there && the time includes the time you are arguing && there is only one time that we all follow and its my time i.e. 7:40:53 pm.". I thought this is a simple thing and had to pay Rs.48 for 60 seconds and the total collection crossed around Rs.850 and then I could know the meaning of "Time is Money". From the next time, I made a decision to come always 5 minutes ahead of the given time and the simple rule changed me.


  • Communication: In the first task, I explained the whole team of 16 members the task that was told to me, in the best way that I could do. But, after the feedback section, not even 1 could completely understand the goal. The reason was I myself was not clear with the goal and I shouldn't have expected that every one is very good at listening. From that time I took a confirmation from every one once I express something and it worked many times and I still try to get the best ways to communicate the best way.

Communication is not only expressing the best way but it is also listening when others are speaking. In some of the tasks there were people with better ideas than what we had and they couldn't communicate properly because others were not listening to them.


  • Knowing the Goal or Objective: This reminds me of my childhood days when my Mother used to say, "Read the question twice and don't start writing until you understand it better". Most of the times we read or know a lot and because we know a lot, we are in a great hurry that we forget to understand what is asked and end up giving the best wrong solution.

In one of the tasks, we were all so enthusiastic that we were all busy in finding a plan before knowing the goal. One of the tasks was to collect some cups in a ground; with 4 peoples legs tied to a plank and get it back to the start line. And the funny thing is all got a lot of cups, but none completed the task and the reason was we had to bring the cups and we need not reach back.


  • Plan well before start, and be ready for the change: Tasks were given impromptu and we were asked to execute in very less time, max was 30 minutes. So, with so many members, having different thoughts and some people being more verbal, it took so much time for the plan itself and later on every one blamed others that they were more verbal. Later on, every one started with some best plan and while the plan was being executed, it was changed on the fly. It always does not mean to start your flight and then start constructing; but the better way is to start doing something and flexible enough to change in the middle.

The time we reached there, all the 16 people's legs were tied and we were asked to reach the conference hall in 20 minutes. Initially we all started shouting left and right, but after some time we realized that its better to drag our legs. So, we all changed the plan and it worked a bit faster and later on we felt to sit and drag with our base and this was still faster and we could reach the target in 17 minutes.


  • Focus on abilities and not disabilities, don't enter into other shoes: There was a task where some people were given some disabilities and some powers and after the task was not completed in the stipulated time, every one were yelling about their disabilities and were complaining that the other people had good powers which they couldn't utilize properly.

In the task, one team was blind, one mute and the other normal. The rule was "blind can touch the people and the equipment, the mute can touch the people but not the equipment and the normal can neither touch the people not the equipment". The task was to use a tube and some ropes to take a container with some water and pour into another one which was a bit higher and there were many other rules. I was the lead for this project and took more people as blind, as I knew they were powerful and some as mute so that they can help the blind in doing their tasks and a few normals. Blind and mute complained that the normal was powerful, normal complained that the task was not clear. The primary problem was everyone were thinking of their disabilities and none could think about their powers.


  • See all around and get the ideas: Re usability is a powerful thing and it even applies to writing code. There are many successful and smart people who just Google, ctrl+c and ctrl+v, modify it and write the most effective code. The primary idea is to complete the task in the best way and not to show our personal skills.

One of the tasks were to shift people and some equipment from one area to another, with only the crates touching the ground. The penalty for breaking the rules was that the whole team and its equipment return to the start and there were some other rules. We had 3 crates and we decided to move as a team of 3 in the beginning and 2 coming back. But this could take a lot of time and hence we decided to move as a team of 4 and 2 returning back. And while we could even reach there, the other team moved as a team of 3 and from there 1 person tied the 2 crates to each of the legs and took the 3rd in hand and moved back and we just copied their idea and ours was still faster because every time 3 people are moving out.


  • Don't get overloaded, if so communicate or even take help from other team: In some tasks, 1 or 2 were the best team players and people trust them and when they become tired or they are slow, the whole team comes down. This time its worth to take help from the other team or better to communicate in the beginning.

In a task called spider web, we had to move thorough the web only once and the goal is to move the whole team to the other side. Some persons took the key role of lifting and pushing the people from one side, but some how one of the key member got strained in the back and the whole team was left over.

In another task, I was moved from one team to another as they recommended me and too much trust was laid on me. My plan was implemented and I was thinking about all the team members and their tasks and trained them, but when the demo was asked I did a mistake for which the whole team had to fail.


  • Your work may be scraped because others work may be the best; the goal is to get the work done and not about who has done that: Sometimes people get some good work and they work day in and day out to complete the task, but in the end some other tool may be purchased and this total work might be scraped. The goal is to get the work done in the best way and not about individual work.

The last task was for 3 hours and there were 3 teams and the total time in the last for the demo was 120 seconds. If it failed for the first time, the 3 teams together had another chance. So all the teams practiced a lot for 3 hours and their target was to complete the task in 35 - 40 seconds. Only one team was trained and it could complete the task in 17 sec and the second team couldn't complete the task in the remaining time, so it there was only one more chance left. The lead came with the idea that the 1st team does the 3 tasks since they could do it in 11 sec and moreover they were trained, but many argued in the beginning, since they couldn't show up their strategies. But later everyone agreed and encouraged the 1st team and the task was completed in 80 seconds.

-------------------------------------------------------------------------------------------------




There are many other things that I could learn from this training and these keywords ( like Time Management, .. ) are really powerful and worth trying. One golden rule I got from this training, putting the complex thing in simple way, "Most of the mistakes are done because of Assumptions, So never go with any assumptions, better ask and you are at a better place than the one who did not ask. Only fools justify the mistakes, but the others learn from their failures and the best ones learn from their successes".