Be careful of google's search results

It has recently been in the news that there's lot of spam in search results. But I did not know it will really hit home so soon. I recently entered the search for delay Windows 7 activation. I got this link as the first result. But this should not have been the first result for this query. It refers to the original post on Windowssecrets.com. But that is not the main point.

The first link in the search result does not give enough details. Being a lazy person as I am I did not click on the link mentioned in that article and it cost me dearly. The article in question does not caution the user to only execute the necessary command at the end of one month period. it does however mention that the command can be a used maximum of four times. But I somehow missed that. So I kept issuing the command every two days. As a result the time to enjoy Windows 7 without activation was severely reduced.

Moral of the story is don't always trust the first result from Google. It is unfortunate that Google will show a less reliable article as the first result than the more detailed one. But that's the way it works in Internet sometimes. So be careful of it.

One Way to Negotiate Salaries.

There are different ways salaries are negotiated. Some companies give you salaries based on the salary at the previous company. Some people can negotiate salaries pretty much independently of their salary history. They go by market; if the market is hot and their demand is high the will ask for a big salary. If they cannot get their base salary high enough they will try to get a big bonus or some other perks such as stock options. But few people negotiate their salaries the following way. It can definitely earn them more, so try it. I definitely will at the next job offer I get.

The idea is to ask for a very low salary in the beginning, lets say just 1 c. Then take double that in the next month, 2 c. This will make HR people very happy although a bit surprised. They are not technical people so they will not dig deeper. So your paycheck will look like :

1. 1 c First month
2. 2 c Second month
3. 4 c Third month
4. 8 c Fourth month
5. 16 c Fifth month
6. 32 c Sixth month
7. 64 c Seventh month
8. $1.28 Eighth month
9. $2.56 Ninth month
10. $5 Tenth month (Rounding up)
11. $10 Elventh month (Rounding up)
12. $20 Twelfth month

So at the end of one year you will be getting a $20 paycheck. But it will be quite different in another year, you will make pretty fat paycheck at the level with the company's CEO, and in another year you will sitting on pretty good fortune and may not have to work anymore. You probably cannot work there anyway as that company will most likely be bankrupt.

New Way to Write Equals.

This is typical way to write the important equals method in java :

@Override
public boolean equals(final Object object) {
       if (this == object) {
              return true;
       }
       if (!(object instanceof MyClass)) {
              return false;
       }

       // now comes the real comparison of fields, foo, bar, etc.
       }

My idea is to refactor the later part of the comparison to another method :

public boolean equals(final MyClass myClass) {
       // Do the real comparison of fields, foo, bar, here.
}

So the original equals method becomes :

@Override
public boolean equals(final Object object) {
       if (this == object) {
              return true;
       }
       if (!(object instanceof MyClass)) {
              return false;
       }
       return equals((MyClass) object);
}

Benefit of having two equals is obvious, it keeps it simple and clear. In most cases equals will be only called with the object of same class only. In that case, it comes directly to the specific method, so it might be tiny bit faster as the instanceof is not being checked. Also first six lines of the method could be refactored into another method so the equals method

becomes even more compact.

Do Not Keep Same Password For All System

Recently google was subject of hacker attack. Actually, one friend of mine had it gmail account hacked. He not only lost access to his emails, fraudulent emails were sent to his contacts asking for money. It said he is stuck somewhere in Europe and needs money. I got one of those emails, but I knew it was phishing email and his email was hacked.

It is very usual to have many emails e.g. yahoo, gmail, aol, etc etc these days. It seems convenient also to keep same password for all system as it makes it easy to keep track of. But it can be very dangerous as well. If a hacker gets to know one password, he can gain access to all your emails and you have no way to reset as your backup email will not work either.

So although convenient, it is mandatory to keep different password for different systems. Also it is recommended to change the password every so often.

Uses of Breadcrumbs in Eclipse

   


Eclipse has the breadcrumb feature for a while. It is immensely useful. One can turn it off or on by pressing Alt-Shift-B. It's main purpose is, of course, easy navigation. It makes it easy to navigate to different packages, classes or project without opening the package explorer view which takes up valuable space. But that is not the only use. Other uses are :

1. Quickly go to the beginning of a class. If you are in the middle of a long class and you want to go to the beginning of the class. To do this, just type Alt-Shift-B and which will put the focus on the breadcrumb and use the left arrow key to highlight the class names and hit enter.
2. Quickly go to other methods in a class. If you are in the middle of long class which has many methods and you want to go to some other method. One way to do it will be to use Ctrl-Shift-Up/Down which will take you to the next of previous method. One can also use Ctrl-O which will show all the methods. Yet another way is to type Alt-Shift-B and use the up/down arrow key to go to the desired method.
3. Quickly delete a method or the whole class. Before there was breadcrumb one had to go to the package explorer view or the outline view. Not anymore. One can just go to the breadcrumb and hit the delete key now.

Alternative to Getter/Setters Contd...

Looks like my last blog on this subject got some attention in dzone. It was pleasing to see those up votes. There were some down votes as well. I am trying to figure out why there were so many down votes. Probably they did not like the idea that a private field which have getter/setter can be treated just like a public field. Although essentially it is public but idea that you could directly access and change the field without going to through the getter/setters is not palatable to lot of people. If it walks like duck, quacks like duck, sometimes it is really not a duck! Some people pointed out getter/setters could be quite different from [return field;] and [this.field = field;] kind of code. In that case, one could provide explicit getter/setters. The annotation model will only apply to the most common case. In the lombok project also, this is the case the annotation will cover. Even then, I do not think java community, in general, will like the idea to treat private fields as public fields.

This was the idea my last blog that I was trying to push. Most of the other ideas presented have already been featured in the lombok project. Although it is not fashionable now, it might become in future.

What is not yet implemented in the lombok project is the Constructor annotation. This will really save lot of code clutter. This constructor annotation could have optional parameters to call super(), or some other method. e.g. init(), etc. If anyone has any comments or suggestions please post below.

Better Alternative for Getter/Setters?

Recently lombok project has created
quite a buzz. It is a very nice project which lets one put short and concise annotations in place of getter setters. There are other projects also which takes this approach which has similar annotations in place. With the annotations no explicit getter setters are not necessary and still other classes can call the getter setters as if they are there. The lombok project also fits into eclipse ide which makes the getter setters appear as code completion even though they are not there.

Could there be a better alternative? How about having annotation similar to lombok project and let's say they called @Getter & @Setter which will create the getter and setter implicitly so other classes can call the methods and not get compilation error. What if @Getter annotation makes the field public for reading purpose and @Setter annotation makes it public for writing purpose. So if a field is annotated with @Getter then one should able to do

• something = instance.field,

where instance is the instance of the class and field is a private field in the class. And if it is annotated with @Setter, one should be able to do

• instance.field= something.
  

With both @Getter & @Setter annotations, one will be able to use them essentially as public fields. Java IDEs will have to change to make this work. In particular, refactoring will probably be difficult, but it will be well worth the effort for the simplicity it brings.

In addition to not having the getter/setters, this will also make it apparent which fields are really private and which are modifiable and accessible. One does not need to scroll down hundred lines to see if there are getters setters for it. An optional body could be supplied to the annotations as well. But in most cases, simple return field (for getters) and this.field = field(for setters) will do.

The two annotations can be combined to one annotation called @GetterSetter. A @Data annotation can be created as well just like lombok project does which will make all private fields having @GetterSetter annotation. To be complete, a negative annotation @NotGetter @NotSetter can be applied to few fields which are not supposed to be accessible and modifiable.

Another useful annotation to cut code clutter can be to introduce @Constructor annotation which can be attached to a class. This can take optional parameters @Constructor(field1, field2, field3,..). There can be multiple Constructos with varying numbers of fields. This could be extended to equals, hashCode, and toString methods as well. For these methods, a template could be defined which will present in the classpath. I am not providing further details for simplicity.