The Open Source Frameworks I use
0 Comments Published by Tahir on Tuesday, July 31, 2007 at 12:14 AM.
Free and Open source frameworks are popular in Java developers, because they always come to make life easy. I am listing here the F&OS frameworks and libraries that I am using in my work. My this post is reply to The Codist.
- Tomahawk - I have used some of tomahawk controls in JSF
- Hibernate - with this ORM, thinking in objects is easy for me
- DWR - it make easy to use AJAX in my application
- Log4J - for loging purpose I use this
- YUI - YUI is a revolution, it comes with so many JavaScript based controls to be use in web
- Jakarta-commons - I am using some of commons in my work like DbUtils, Email, File Upload and Logging
- Apache Velocity Engine - for text generation and working with templates I use velociy
- AspectJ - to use AOP in Java, AspectJ is my choice, I am in the way for having full command on it
Labels: Technical
After switching on the PC, before checking official emails, its time to take some fresh technical bites. Which I love to take. These are some sites that I visits daily before starting my work...
- Javalobby.com
as its name, its a lobby of Java programmers, contain discussion on socio-technical issues and tips and tricks section.
- del.icio.us
Many times, I found some very good articles, mostly I found articles on personality development.
- TheServerSide.com
More advanced towards Java. The news section of TSS is great place to know architecture and design things. There are some very good ebooks available there also. And the video cast of different events and interviews of geeks are superb.
- Slashdot.org
Good technical news website
Labels: Technical
An interesting article I found on [1]. Here I have pasted some of the points, making myself how many I can implement. Which ones if any would you adopt from this list...
I will realize that design patterns are a guide, not a religion.
I will bother to research the security issues relevant to my work.
I will spend an hour teaching a child the rudiments of programming, even if it's just "Hello World" in JavaScript.
I will learn how to use Unicode.
I will not respond to requests for help by informing the questioner that they are not only asking the wrong question, but should change the language they program in and/or their OS to Linux distribution.
I will create one bona-fide playable game, even if it's Tic-Tac-Toe 2007.
I will recognize that not all programs are self documenting, and that this is why comments were invented.
I will contribute to an open-source project because they need my skills, not because I like the project.
I will explain my grep patterns in comments.
I will be nice to the people who pay me.
I will go back and do something interesting with all my failed, half-finished projects.
I will not use the term "Alpha" when what I really mean is buggy, untested, crap-tastic software.
I will always write Ajax that degrades gracefully (or I will realize that Ajax site navigation is the new "skip intro" of internet design).
I will not try to learn a new language. Instead I will surprise everyone by programming something completely unexpected in one I already know.
I will write ten lines of code everyday for someone I love.
I will stop writing apps that are just giant, nested loops and releasing them as popular software packages. (Here's looking at you, Wordpress theloop.php.)
I will learn how to write a script that emails me errors instead of sending everything to /dev/null.
I will finally pay for all of the shareware apps that I use daily. No, really.
[1] blog.wired.com/monkeybites/2007/01/new_years_resol.html
Compiled by Rob Beschizza, Mike Calore, Scott Gilbertson and Joel Johnson
I will realize that design patterns are a guide, not a religion.
I will bother to research the security issues relevant to my work.
I will spend an hour teaching a child the rudiments of programming, even if it's just "Hello World" in JavaScript.
I will learn how to use Unicode.
I will not respond to requests for help by informing the questioner that they are not only asking the wrong question, but should change the language they program in and/or their OS to Linux distribution.
I will create one bona-fide playable game, even if it's Tic-Tac-Toe 2007.
I will recognize that not all programs are self documenting, and that this is why comments were invented.
I will contribute to an open-source project because they need my skills, not because I like the project.
I will explain my grep patterns in comments.
I will be nice to the people who pay me.
I will go back and do something interesting with all my failed, half-finished projects.
I will not use the term "Alpha" when what I really mean is buggy, untested, crap-tastic software.
I will always write Ajax that degrades gracefully (or I will realize that Ajax site navigation is the new "skip intro" of internet design).
I will not try to learn a new language. Instead I will surprise everyone by programming something completely unexpected in one I already know.
I will write ten lines of code everyday for someone I love.
I will stop writing apps that are just giant, nested loops and releasing them as popular software packages. (Here's looking at you, Wordpress theloop.php.)
I will learn how to write a script that emails me errors instead of sending everything to /dev/null.
I will finally pay for all of the shareware apps that I use daily. No, really.
[1] blog.wired.com/monkeybites/2007/01/new_years_resol.html
Compiled by Rob Beschizza, Mike Calore, Scott Gilbertson and Joel Johnson
Accessing a selected row from h:dataTable
0 Comments Published by Tahir on Saturday, July 28, 2007 at 12:32 AM.
Javascript to Select One Radio Button
JSF Code of h:dataTable Table on JSP Page
We will use valueChangeListener for this, as when user check the radio button we will get the binded value of bean. It is one coulmn.
onclick=”selectOne(this.form , this)” >
Page Bean Code
This the page bean code, and here is the valueChangeListener method.
public void handleRadioValueChange(ValueChangeEvent valueChangedEvent)
{
try
{
// here we got the selected row of dataTable
this.creditCardDataBean = (CreditCardDataBean)getTable1().getRowData();
selectedCardId = creditCardDataBean.getCardId();
}
catch (Exception e)
{
e.printStackTrace();
}
}
public HtmlDataTable getTable1()
{
if (table1 == null) {
table1 = (HtmlDataTable) findComponentInRoot(”table1″);
}
return table1;
}
public static UIComponent findComponentInRoot(String id) {
UIComponent ret = null;
FacesContext context = FacesContext.getCurrentInstance();
if (context != null) {
UIComponent root = context.getViewRoot();
ret = findComponent(root, id);
}
return ret;
}
Labels: Java, Jave Server Faces, Technical
Programming is complicated stuff, but a lot of what makes a good programmer isn't all that different from the earliest learning we did in school.
1. Share everything.
Use open source where possible, and contribute to it when you are able. The collective wisdom of the entire community is better than the limited vision of a few large companies.
2. Play fair.
Give other technologies, frameworks, methodologies and opinions a chance. Don't think your choices are the only ones that work. The other choices may very well be better than yours; it doesn't hurt to check them out with an open mind.
3. Don't hit people.
Like #2, don't attack people just because they happen to use .Net or Java or PHP (I learned my lesson there!). Sometimes they might be more usable and useful than you think. You can learn a lot more from someone when you are not pounding them to a pulp.
4. Clean up your own mess.
Strive to deliver code that works. Never expect QA to find all of your bugs for you. Test your code often, both narrowly and broadly.
5. Don't take things that aren't yours.
Follow the licenses for stuff you use, don't just steal it and claim innocence later.
6. Say you're sorry when you hurt somebody.
Code reviews are a good but rarely used idea. Mentoring programmers with less experience than you helps the entire team. Just don't criticize people openly. Learning is not belittling people. Sometimes people will listen and sometimes they won't. Sometimes you might learn a lot from people you think are inferior to you.
7. Wash your hands before you eat.
Try to understand things before you set out to write code. Do prototyping, check out examples on the web, talk with other folks who do it, or even just play around. Architecting something you've never done before or worked with is tough cold turkey. The end result will work much better if you start with a clue.
8. Flush.
Don't be afraid to replace, rewrite, refactor or give up on something that is crap. Sometimes "when in doubt throw it out" is the best philosophy. Never fall in love with your code.
9. Warm cookies and cold milk are good for you.
Yes, programmers should be well supported in their work environment. A good chair, a quiet place to work, a decent computer and tools that make coding better and easier are essential. Managers should act as umbrellas to keep the crap from flowing down to the programmers. As a programmer, don't accept a life of lowly servitude. If the employer treats you poorly then find one who treats you better.
10. Live a balanced life - learn some and think some and draw and paint and sing and dance and play and work every day some.
I like Google's deal where 20% of your time is devoted to whatever you think it worth working on. Employers should (discretely) offer nap rooms or game rooms or some kind of chillout environment. Programming is hard mental work; sometimes you really need to give your brain a rest. Refuse to routinely work 80 hour weeks as the quality of your work will wipe out any gains in hours.
11. Take a nap every afternoon.
Working 24 hours a day doesn't make you more productive. Take breaks, go home, take a real nap. Often I have solved nasty problems by going home, and the solution came to me as I was driving away, or the next morning.
12. When you go out in the world, watch out for traffic, hold hands and stick together.
Community is good for the soul; read blogs, learn about new languages or frameworks, participate in discussions and see what other people are doing. Just doing your job isn't going to make you a better programmer. Keeping your head down means you will eventually be obsolete.
13. Be aware of wonder. Remember the little seed in the Styrofoam cup: the roots go down and the plant goes up and nobody really knows how or why, but we are all like that.
Every day something new and wonderful appears in the programming (and technology in general) world. Check it out. Be amazed. Learn something new everyday. It keeps your mind fresh, your options open, and your skills up to date. If you think programming is boring or dead then you may need a new career.
14. Goldfish and hamsters and white mice and even the little seed in the Styrofoam cup - they all die. So do we.
Code goes stale and dies. Sometimes you just have to bury it and do it again. Fight against keeping terrible code bases around just to save money.
15. And then remember the Dick-and-Jane books and the first word you learned - the biggest word of all - LOOK.
You won't learn anything at all if you don't try. Everything I learned in programming came from trying new stuff and generally playing around. Every morning I read a lot of sites to see what is happening in the programming world; I have been doing this since my first job in the early 80's (when it meant reading catalogs and magazines).
See, programming is easy when you look at it through 5-year-old eyes.
Reference: http://thecodist.com/fiche/thecodist/article/all-i-need-to-know-to-be-a-better-programmer-i-learned-in-kindergarten
1. Share everything.
Use open source where possible, and contribute to it when you are able. The collective wisdom of the entire community is better than the limited vision of a few large companies.
2. Play fair.
Give other technologies, frameworks, methodologies and opinions a chance. Don't think your choices are the only ones that work. The other choices may very well be better than yours; it doesn't hurt to check them out with an open mind.
3. Don't hit people.
Like #2, don't attack people just because they happen to use .Net or Java or PHP (I learned my lesson there!). Sometimes they might be more usable and useful than you think. You can learn a lot more from someone when you are not pounding them to a pulp.
4. Clean up your own mess.
Strive to deliver code that works. Never expect QA to find all of your bugs for you. Test your code often, both narrowly and broadly.
5. Don't take things that aren't yours.
Follow the licenses for stuff you use, don't just steal it and claim innocence later.
6. Say you're sorry when you hurt somebody.
Code reviews are a good but rarely used idea. Mentoring programmers with less experience than you helps the entire team. Just don't criticize people openly. Learning is not belittling people. Sometimes people will listen and sometimes they won't. Sometimes you might learn a lot from people you think are inferior to you.
7. Wash your hands before you eat.
Try to understand things before you set out to write code. Do prototyping, check out examples on the web, talk with other folks who do it, or even just play around. Architecting something you've never done before or worked with is tough cold turkey. The end result will work much better if you start with a clue.
8. Flush.
Don't be afraid to replace, rewrite, refactor or give up on something that is crap. Sometimes "when in doubt throw it out" is the best philosophy. Never fall in love with your code.
9. Warm cookies and cold milk are good for you.
Yes, programmers should be well supported in their work environment. A good chair, a quiet place to work, a decent computer and tools that make coding better and easier are essential. Managers should act as umbrellas to keep the crap from flowing down to the programmers. As a programmer, don't accept a life of lowly servitude. If the employer treats you poorly then find one who treats you better.
10. Live a balanced life - learn some and think some and draw and paint and sing and dance and play and work every day some.
I like Google's deal where 20% of your time is devoted to whatever you think it worth working on. Employers should (discretely) offer nap rooms or game rooms or some kind of chillout environment. Programming is hard mental work; sometimes you really need to give your brain a rest. Refuse to routinely work 80 hour weeks as the quality of your work will wipe out any gains in hours.
11. Take a nap every afternoon.
Working 24 hours a day doesn't make you more productive. Take breaks, go home, take a real nap. Often I have solved nasty problems by going home, and the solution came to me as I was driving away, or the next morning.
12. When you go out in the world, watch out for traffic, hold hands and stick together.
Community is good for the soul; read blogs, learn about new languages or frameworks, participate in discussions and see what other people are doing. Just doing your job isn't going to make you a better programmer. Keeping your head down means you will eventually be obsolete.
13. Be aware of wonder. Remember the little seed in the Styrofoam cup: the roots go down and the plant goes up and nobody really knows how or why, but we are all like that.
Every day something new and wonderful appears in the programming (and technology in general) world. Check it out. Be amazed. Learn something new everyday. It keeps your mind fresh, your options open, and your skills up to date. If you think programming is boring or dead then you may need a new career.
14. Goldfish and hamsters and white mice and even the little seed in the Styrofoam cup - they all die. So do we.
Code goes stale and dies. Sometimes you just have to bury it and do it again. Fight against keeping terrible code bases around just to save money.
15. And then remember the Dick-and-Jane books and the first word you learned - the biggest word of all - LOOK.
You won't learn anything at all if you don't try. Everything I learned in programming came from trying new stuff and generally playing around. Every morning I read a lot of sites to see what is happening in the programming world; I have been doing this since my first job in the early 80's (when it meant reading catalogs and magazines).
See, programming is easy when you look at it through 5-year-old eyes.
Reference: http://thecodist.com/fiche/thecodist/article/all-i-need-to-know-to-be-a-better-programmer-i-learned-in-kindergarten
Labels: Technical
How to make an executeable jar
0 Comments Published by Tahir on Saturday, July 21, 2007 at 12:35 AM.
Delivering desktop application developed in java, its very interactive that you give your software in a executable jar, rathe giving .bat files (running java
To do that, try these steps.
First, jar all of your class files and let Java create it's own manifest. First, make sure you are in the directory of your class files:
jar cvf MyJarFile.jar *.class
You would replace MyJarFile.jar with whatever you want the jar file to be named. Then, create a regular text file with this:
Main-Class: MainClass
Make sure you hit enter at the end. The file has to end with a carriage return. Say you name the text file ManifestUpdate.txt. Make sure you save it in the same directory as all your class files.
Then do this:
jar umf ManifestFile.txt MyJarFile.jar
This essentially updates the current Manifest file in your .jar file with the contents of the text file you created. Again, go through the JAR tutorial. It will help you out a lot!
http://java.sun.com/docs/books/tutorial/deployment/jar/
