Saturday, March 27, 2010

Rockers or Programmers

Recently I thought about this comparison… In the programming world there is this level of people who are a kind of “celebrities” within the developer community - they’re widely known, they have thousands of readers of their blogs, they have thousands of followers on Twitter, they speak on public events in front of thousands of people around the world… All of that just screams for a comparison with the equivalent in the show biz world - rock stars!

So… I’m proud to present the first EVER comparison between rock stars and programming stars! afterwards judge for yourself what you wanna be.

Comparison

Rock Star

Programming Star

Look

0000263739_150

microsofts-early-days

Shown in public on

Concerts, TV, Radio, newspapers, magazines

Conferences, podcasts, programming magazines

Known internationally

Yes

Yes

Chances of being recognized in the grocery store

Almost with complete certainty

Rarely

Charisma

Yes

Yes

Tools

Microphone/Guitar/Drums/other instrument

Microphone + computer + projector

Write

Lyrics

Code

Average annual salary

Millions of dollars

Hundreds of thousands of dollars

# of Twitter followers

Millions

Tens of thousands

# of people attending a single show/talk

Tens of thousands

Thousands

Way to the top

Hard work for years/American Idol

Hard work for years
(Simon Fuller, if you read this, what about a “Programming Idol” show?)

Sex

So much that they’re sorry about that when they grow old.

I don’t know. Unlike rock stars, they don’t share this information.

Drugs

Yes. A lot.

No. Geeks do not do drugs. Most of them at least.

Alcohol

Yes

Drink beer from time to time

Tour the world

A few months a year

A few days/weeks a year

Own

A crib, a private jet, a collection of cool cars

A powerful laptop with SSD and two 24’ screens

Can install Win7

No

Of course, they’ve done that multiple times already

Eat bats during shows/talks

Yes

No

Have tattoos

Yes

Mostly not, it hurts to get them done.

Have two eyes, two ears, one mouth and one nose

Yes

Yes

And the winner is………… I don't know, do you?

Anyway in the end we’re all human and therefore have a chance to become stars.

Go ahead and shine!

by Shay.

Wednesday, March 24, 2010

Interviews with Average Programmers

Books that interview luminous, high-profile programmers seem to be popular right now.  Titles like “Coders at Work“, and “Secrets of the Rockstar Programmers“  have interview-style formats in which various programmers generally regarded to be some of the best in the industry are asked questions about how they got their start, and where they think the industry is headed, etc.

Still, however, it’s impossible for me to read these books and not wonder how I would answer some of these questions myself even though the answers would only likely be worthy of an “Interviews with Mundanely Average Programmers” at best. Since such a book will never likely be written, I thought I would interview myself here for laughs.

Note that the following is intended to be taken as lighthearted and humorous. Any resemblance to anyone’s actual life or experience, including my own, is entirely coincidental (although I do own “Teach Yourself Java in 21 Days“).

———————————————————————————–

Interviewer: How did you first get into programming?
me: Well, I was meeting with my Career Counselor one day to figure out what I should do with my EE degree.
Interviewer: Oh so you have a degree in Electrical Engineering?
me: Eh? No, ‘English Education’. So anyway, he had this problem with his computer — he couldn’t open an email attachment or something. Anyway, I somehow got it open for him, and he said I was pretty good at that, and that I should go into computers. So here I am.

Interviewer: Well, yes, many programmers don’t take the conventional route and get a CS degree. So tell me,what languages do you know and use regularly?
me: Oh, lots.
Interviewer: Specifically, can you name a few?

me: Sure. I’m most comfortable with Java 2 , but I also know Java 1.4, Java 5, even some Java 6. I know Java Swing and of course Java Collections pretty well. Some Java Servlets too.
Interviewer: Ok, those are all the same language. Do you know anything else besides Java?
me: Er lang–
Interviewer: Oh, Erlang, really? What have you done with Erlang?
me: No sorry, I was starting to say to myself, “Err, languages besides Java…”. I’ll have to think on it some more.

Interviewer: Ok, well let’s move on then. What’s the most complicated piece of code you’ve implemented?
me: Oh that’s easy. One time I had to sort a list of numbers, so I did a sort in one line.
Interviewer: Really!? You implemented a sorting algorithm in one line of code? That’s very impressive. Donald Knuth would be proud.
me: Who?
Interviewer: The father of modern computer science and the author of the seminal “The Art of Computer Programming” series.

me: Yeah well if he likes sorting, he should check out Java Collections, one of the languages I know. You can do a sort with just “Collections.sort()”, and then it sorts the collection you give it. Boom. Sorted. One line.
Interviewer:
me: If you give me his email I can let him know where to find it–
Interviewer:

me: Say, aren’t you going to ask me how I would move Mount Fuji? I have a pretty good answer, I think.
Interviewer: What? No, this isn’t a job interview.
me: It’s a trick question. You can’t move mountains. That’s the answer.
Interviewer: Well, I think that might be the point of the question.  I don’t think it has “an answer” . So anyway–

me: So I got it wrong then. Does this mean the interview is over?

Interviewer: No, I wasn’t — you asked yourself that question. Anyway, let’s keep this thing going. What are your thoughts on Pair Programming? Do you practice it often?

me: Absolutely not. I mean, don’t get me wrong, I don’t judge others for doing it. I mean, have I been tempted? Sure. But, I’m a happily married man and–
Interviewer: Ok, let me stop you there. I’m pretty sure we’re not talking about the same thing.  Let’s just skip a few of these questions here. Ok, here’s a safe one: What are some of your favorite tech books?

me: Oh, probably “Teach Yourself Java in 21 Days” stands out. It got me up to speed in my first language, Java 2, and very quickly too I might add. I actually read most of it in 20 days, so I figure I’m probably ahead of the curve somewhat. I’ve always scored pretty high on reading comprehension. I also have one of those books with a picture of an animal on the cover about XML. Oh! That’s what I was trying to remember from your ‘what languages do I know’ question! I know XML too.

Interviewer: I’m not sure XML is really a language–
me: Ok, sure, no problem. Just keep me down for Java Servlets then.  In fact, maybe count it twice. I know it pretty well.

Interviewer: Sure, well, I’m not keeping score. It was just meant to spark conversation. Well scanning down the rest of my questions here, I think I can anticipate most of your answers. So why don’t we just cut it short here. Thank you for taking the time to talk to me.
me: Did I get the job?
Interviewer: Once again, this wasn’t a job interview.
me: Dang. That always means “no”.

Tuesday, March 23, 2010

H2 Database

SQL Database written in pure and 100% Java. It can be used as embedded, server, or in-memory database. Batteries included; I mean, it comes with a web-based admin console to manage your databases. And the performance? Men!! Speed of light. OK, that's exaggeration. The thing is, performance comparison is hard to get right due to many factors. But if you're in the to-see-is-to-believe camp, I suggest that you test it yourself and see how it's jaw-dropping performance outshines its competitors. I will not say anything more about H2. I want you to try it yourself and feel the euphoric experience that leaves you loving your job as a software developer. But I have a bit of warning, though: When you touched H2 Database, you would never look back again to JavaDB/Derby.

Comparison to Other Database Engines

image

Monday, March 22, 2010

20 Best Free sites to learn JQuery

jQuery is a lightweight, cross-browser compliant, and extremely powerful JavaScript framework. jQuery enables you to add interactivity and increased functionality to your website., jQuery is much useful because it can help you to create animations and interactions. jQuery has provided the necessary tools to create stunning websites without having to much worry about accessibility issues.

Due to its compatibility, cross browser support and light weight it is one the most popular JavaScript framework, leaving behind Mootools, Scriptaculous, Prototypejs etc.

For keeping up with jQuery, we present 20 Best Websites For Free jQuery Tutorials that have been providing some astonishing demos and step by step guidelines, such that a beginner can master his skills of jQuery easily.

Following are the Websites that will provide you tutorials which will cover the fundamentals of the jQuery library which you apply with ease.

1) jQuery.com

2) Catswhocode.com

3) Css-tricks.com
4) LearningjQuery.com

5) DavidWalsh.name
6) WebDeveloperjuice.com
7) Tutorialzine.com

8 ) Prodevtips.com
9) Codrops

10) Hv-designs.co.uk
11) jQueryfordesigners.com

12) Marcgrabanski.com

13) Net.tutplus.com

14) Buildinternet.com

15) Sohtanaka.com

16) W3schools.com

17) JQuery Howto

18) Roseindia.net

19) Webdeveloperplus.com

20) Coldfusionjedi.com

Friday, March 19, 2010

Drop Shadow With CSS For IE

One of the most common CSS effects is using shadows in various ways. Before, we needed to resort to images, but now we can offer this to all major web browser with CSS!

Web browser support

Believe me or not, but all of these web browsers we can offer shadows with CSS:
  • Firefox 3.5+
  • Safari 3+
  • Google Chrome
  • Opera 10.50
  • Internet Explorer 5.5

The standards way

As we all know, a majority of the web browsers implement features in a standardized way, while others don’t (although they are getting better at it). Previously, in the W3C specification CSS Backgrounds and Borders Module Level 3 box-shadow was described, although at the moment, it’s not in there for some things to be discussed further. Anyway, this is how the implementation looks:
1: .shadow {    
2:     box-shadow: 3px 3px 4px #000; 
3: }

The first value describes the x-offset (could be a negative value as well), the second the y-offset, the third the radius of the shadow and the fourth the color of it. Opera 10.50 (currently only available on Windows) is the first web browser to have an implementation without a vendor-prefix, whereas Firefox, Safari and Google Chrome all need it for now. So, this code makes it work in all those web browsers:
1: .shadow {
2:  -moz-box-shadow: 3px 3px 4px #000;
3:  -webkit-box-shadow: 3px 3px 4px #000;
4:  box-shadow: 3px 3px 4px #000;
5: }

What about Internet Explorer?

Luckily enough for us, there are a couple of filters we can use to make this work: The DropShadow filter and the Shadow filter. The problem with the DropShadow filter is that the shadow is solid, and not fluffy as desired, although it offers easy values for X and Y. The Shadow filter on the other hand offers a nice shadow, but instead of x and y offset, we need to specify direction and strength the set the length of the shadow.
So, this is how we make it work in Internet Explorer:
1: .shadow {
2:  /* For IE 8 */
3:  -ms-filter: "progid:DXImageTransform.Microsoft.Shadow(Strength=4, Direction=135, Color='#000000')";
4:  /* For IE 5.5 - 7 */
5:  filter: progid:DXImageTransform.Microsoft.Shadow(Strength=4, Direction=135, Color='#000000');
6: }
7: 

The combined styles

This all the CSS for various web browser collected in one rule:

1: .shadow {
2:  -moz-box-shadow: 3px 3px 4px #000;
3:  -webkit-box-shadow: 3px 3px 4px #000;
4:  box-shadow: 3px 3px 4px #000;
5:  /* For IE 8 */
6:  -ms-filter: "progid:DXImageTransform.Microsoft.Shadow(Strength=4, Direction=135, Color='#000000')";
7:  /* For IE 5.5 - 7 */
8:  filter: progid:DXImageTransform.Microsoft.Shadow(Strength=4, Direction=135, Color='#000000');
9: }
10: 

Honorable mention: CSS3 Please!

An easy way to automatically generate these styles and others, cross-browser, is available in the excellent service CSS3 Please! by Paul Irish and Jonathan Neal. Just enter your value, watch its rendering, copy the code and you’re good to go!
A little caveat is that they are currently using the DropShadow filter for IE, but I’m sure that will be updated soon.

Harder When You Learn More

I remember after I hacked away my first server I thought that I was pretty much the sh*t.  Over the past months I’ve been learning more about hacking and programming just not really programming much.  I’ve started to look more into ‘proper’ coding techniques.   After learning more about OOP and optimization I now approach all my projects with a different mind set.  Something clicked today that made me realize that this year doing things ‘by the book’ is holding me back.  A quick example would be the first project I worked on… when I first started it I wasn’t worried as much about my coding style and I was actually progressing quickly but then over time I started to doubt that my code would be good enough for a commercial product so I stopped.

As most programmers know the more you learn the harder things get, I’m finding this to be true.  The more I learn about how I “should” code the less fun coding gets.

Wednesday, March 17, 2010

10 Things That Annoy Programmers

Programmers all have their pet peeves. Whether it’s scope creep, Hungarian notation, or smelly coworkers, we’ve come to accept that there are certain nuisances that come with our line of work. The following is a list of the top 10 things that annoy programmers, compiled from the results of my recent question on StackOverflow along with some of my own experiences:

10. Comments that explain the “how” but not the “why”

Introductory-level programming courses teach students to comment early and comment often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers seem to take this as a personal challenge to comment every single line of code. This is why you will often see something like this code snippit taken from Jeff Atwood’s post on Coding Without Comments:
1: r = n / 2; // Set r to n divided by 2
2: // Loop while r - (n/r) is greater than t
3: while ( abs( r - (n/r) ) > t ) {
4:     r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
5: }


Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it.
Now, consider the same code with a different commenting methodology:

1: // square root of n with Newton-Raphson approximation
2: r = n / 2;
3: while ( abs( r - (n/r) ) > t ) {
4:     r = 0.5 * ( r + (n/r) );
5: }


but at least we have a starting point.
Comments are supposed to help the reader understand the code, not the syntax. It’s a fair assumption that the reader has a basic understanding of how a for loop works; there’s no need to add comments such as “// iterate over a list of customers”. What the reader is not going to be familiar with is why your code works and why you chose to write it the way you did.


9. Interruptions

Very few programmers can go from 0 to code at the drop of a hat. In general, we tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it’s very hard to get into a programming zone when your train of thought is constantly being derailed by clients, managers, and fellow programmers.
There is simply too much information we need to keep in mind while we’re working on a task to be able to drop the task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back is often a time-consuming, frustrating, and worst of all, error-prone process.


8. Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

 
Scope creep turns relatively simple requests into horribly complex and time consuming monsters. It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:
  • Version 1: Show a map of the location
  • Version 2: Show a 3D map of the location
  • Version 3: Show a 3D map of the location that the user can fly through
Argh! What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours. Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.


7. Management that doesn’t understand programming

Compiling
Ok, so maybe there are some perks.
Management is not an easy job. People suck; we’re fickle and fragile and we’re all out for #1. Keeping a large group of us content and cohesive is a mountain of a task. However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).


6. Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. If you are working with an application that normal everyday people are using, you’re going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).
It’s not hard to see that this is something programmers dread doing. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? Documentation.
I think I can safely speak on behalf of all programmers everywhere when I say, “can’t someone else do it?“.


5. Applications without documentation

I never said that we weren’t hypocrites. :-) Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.
There is nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do. What’s the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I’ll just have to find out through trial and error! Ugh.


4. Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly. We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.


3. Vagueness

“The website is broken”. “Feature X isn’t working properly”. Vague requests are a pain to deal with. It’s always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. They don’t seem to understand that “it’s broken, fix it!” is not enough information for us to work off of.
Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply “fix it”.


2. Other programmers

Programmers don’t always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I’m just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:


  • Being grumpy to the point of being hostile.
  • Failing to understand that there is a time to debate system architecture and a time to get things done.
  • Inability to communicate effectively and confusing terminology.
  • Failure to pull ones own weight.
  • Being apathetic towards the code base and project
And last, but not least, the number 1 thing that annoys programmers…


1. Their own code, 6 months later


Don’t sneeze, I think I see a bug.
Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written that? Burn it! Burn it with fire!
Well, good news. You’re not alone.
The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is slightly out of reach. For me, this is the most annoying thing about being a programmer. The fragility of what we do is necessary to facilitate improvement, but I can’t help feeling like I’m one of those sand-painting monks.
Well, there you have it. The top 10 things that annoy programmers. Again, if you feel that I missed anything please be sure to let me know in the comments!



source (Written by Kevin Pang on August 28, 2008)

Tuesday, March 2, 2010

Send Mail in Java using SMTP

I was trying to send a mail from my JSP page. I had tried every way to make that code work. Later I found that I have to set  Mail Authentication, which lead me to solution.
Here is my SendMail cass, which you can implement in any Java application to send mail.
I have used a new Thread to send the mail, unless you do this the Thread which the mail sender was called will wait until the mail is sent due to this reason the whole program might halt for awhile
import javax.mail.*;
import javax.mail.internet.*;
import java.util.*;

public class MailSender {

private String email = "jason@gmail.com";
private String password = "****";
private String host = "smtp.gmail.com";
private String port = "465";
private String from = "jason@gmail.com"; // if needed this can be used to set the from e-mail address
private String toAddresses = "abc@gmail.com,cbn@yahoo.com";
private String ccAddresses = "aft@hotmail.com,abc@gamil.lk";
private String bccAddresses = "";


public void sendEmail(final String subject, final String message) {
new Thread() {
public void run() {
sendMail(email, password, host, port, "true",
"true", true, "javax.net.ssl.SSLSocketFactory", "false", toAddresses, ccAddresses, bccAddresses,
subject, message);
}
}.start();
}

public synchronized boolean sendMail(String userName, String passWord, String host, String port, String starttls,
String auth, boolean debug, String socketFactoryClass, String fallback,
String to,
String cc, String bcc, String subject, String text) {
Properties props = new Properties();
props.put("mail.smtp.user", userName);
props.put("mail.smtp.host", host);
props.put("mail.smtp.port", port);
props.put("mail.smtp.starttls.enable", starttls);
props.put("mail.smtp.auth", auth);
props.put("mail.smtp.debug", Boolean.toString(debug));
props.put("mail.smtp.socketFactory.port", port);
props.put("mail.smtp.socketFactory.class", socketFactoryClass);
props.put("mail.smtp.socketFactory.fallback", fallback);

try {
Session session = Session.getDefaultInstance(props, null);
session.setDebug(debug);
MimeMessage msg = new MimeMessage(session);
msg.setText(text);
msg.setSubject(subject);
msg.setFrom(new InternetAddress(from));
for (String aTo : to.split(",")) {
msg.addRecipient(Message.RecipientType.TO, new InternetAddress(aTo));
}
if (!cc.equals("")) {
for (String aCc : cc.split(",")) {
msg.addRecipient(Message.RecipientType.CC, new InternetAddress(aCc));
}
}
if (!bcc.equals("")) {
for (String aBcc : bcc.split(",")) {
msg.addRecipient(Message.RecipientType.BCC, new InternetAddress(aBcc));
}
}
msg.saveChanges();
Transport transport = session.getTransport("smtp");
transport.connect(host, userName, passWord);
transport.sendMessage(msg, msg.getAllRecipients());
transport.close();
return true;
}
catch (Exception e) {
e.printStackTrace();
return false;
}
}
}

class GenerateMailTest {
public static void main(String[] args) {
final MailSender sender = new MailSender();
sender.sendEmail("This is a test", "This is the content of test mail");
}
}