Tuesday, December 26, 2006
Elegant Solutions and Learning
Tuesday, December 19, 2006
Todays technology
Today’s technologies are so complicated, no one person can know everything there is to know about any one of them. Do you “know Java”? Yeah, right. Which “Java” is that? Whichever part of Java you know, it’s only a small slice of Java technology. You need to communicate with others in order to leverage their knowledge of the technologies you’re using. And you need to communicate to your teammates your knowledge of the technologies you know and create. And you need to explain to others how to use your code. You need to document your own API’s. When you write a program, what you’re really doing is communicating to another human what it is you want the computer to do. Programming is about communication, just like any other form of writing.The thing is, coding is also a communication skill.
Good Design and Coding
Understanding is as important as coding. Spend as much time thinking about your design as you do coding it. Never code around a design flaw. If you get stuck, always go back to the drawing board. But then follow through with your conclusions.
Flow and design: Code is more than a series of statements. It is also a relationship of parts. Stepping through your code with a debugger is not how to understand what it does. You must understand the design as well. Don’t think like a debugger, or your code will be incomplete. Think abstractly as well as concretely.
Together belongs together; separate belongs apart. Good Design = High Cohesion + Loose Coupling. Parts that work closely together, keep close to each other. Parts that work separately, keep apart. The bad thing about global data is that it couples code in one part of the system to code in another part. Passing around a massive structure does the same thing. Even passing around a reference to a single variable does the same thing.
Only relevant coding standards are effective. Indentation, brace style, spacing, blank lines, these all communicate information. Use a consistent style that tells future programmers how the design works.
Maintaining unused code is more expensive than rewriting it. You need to maintain unused code, modify it, tweak it. But you cannot test it, because it is unused. You cannot know whether unused code still actually works. This is an unnecessary burden. Delete unused code, even if you may need to use it again someday. You can always write it again if you need to.
Comments tell why, not what or how. Add comments to explain why the code does what it does. Never add a comment to describe what the code does or how it does it. Instead, use descriptive function and variable names. If you need a comment to tell what or how, your design is flawed.
Saturday, September 16, 2006
Mock Objects for Unit Testing
Monday, August 14, 2006
What makes one a Senior Developer?
- Experience in interviewing candidates and making hiring recommendations.
- Experience in managing a team of intermediate/junior developers.
- Experience in estimating development time and bringing projects in within the given estimate.
- Experience in high-level architectural design.
- Solid knowledge of and experience in at least two different programming languages.
- Knowledge of the issues related to (but not necessarily experience with) all aspects of a software system including network, GUI, database, security.
- The ability to evaluate and offer recommendations on new languages/technologies/frameworks.
- The ability to think outside the box or go beyond existing solutions.
- The ability to coach/mentor new hires.
Monday, August 07, 2006
Qualified for the Summer ladder Tennis playoff
Rank | Points | Player | Win-Loss |
1 | 331 | Brian Cudney | 14-1 |
2 | 319 | Karthik Shanmugam | 11-7 |
3 | 318 | Alan James | 9-4 |
4 | 303 | Devang Shah | 10-15 |
5 | 300 | Joe Montagnino | 11-4 |
6 | 297 | Geoff Sessa | 10-1 |
7 | 285 | Taylor Busby | 9-2 |
8 | 282 | Adam Bernstein | 7-5 |
9 | 281 | Sameer Shaik | 9-5 |
Sunday, August 06, 2006
Law of Conservation of Time
The amount of time you have, always remains constant.
Wednesday, June 28, 2006
My Name in a Website
Wednesday, June 14, 2006
Developer requirements
Learn to focus on the customer requirements rather than the technology. That might mean become a subject matter expert in the end user application. you must be able to focus on the business problem the client/customer wants to solve. If you can see the problem/need from the customer's perspective, be able to suggest process improvements, AND be able to recommend the appropriate technologies to assist in those improvements, you'll be in demand. Discussing requirements with a client, articulating issues to a higher up, or even just giving guidance to and managing jr. developers - all require consistent and concise communication skills that can make a great developer even more valuable. You have to understand the business of the customer enough to be able to talk to them, ask the right questions and finally develop the piece of software they expect.
Next to technical experience, business experience is becoming more and more important. If you have other non IT related skills like communication skills, coaching skills, ... then this also adds extra value to you as a software developer.However, the basis of a good software developer is and stays a solid (technical) knowledge and experience of software development. Additionally we have to pick up other skills and experience in business related areas, communication, planning, organization of a project, ... So, I think in the future we software developers will spend less time on coding while we have to keep up the effort to get the code quality better.
In the end, I think the job of a software developer will be "richer" because we are able to do more then just develop software.
z/os was Request process overview
Request Process Overview
The following steps describe the J2EE application flow:
1. A client application sends a request to access the J2EE application.
2. The request is received by the Web server which immediately passes the request to the Web server plug-in.
3. The Web server plug-in chooses a server to handle the request based on the resource being requested, identified by its Universal Resource Locator (URL), and forwards the request.
4. The WebSphere for z/OS daemon routes the request to the application control region based on the context root in the URL. (i.e. ibi_html or ibi_apps)
5. The control region checks that the request is authorized and places it on the Workload Manager (WLM) queue. If necessary, WLM starts a procedure that is used to start a new servant region address space in response to the queued request. WLM then passes the request to the servant.
6. Servant is the J2EE app server containing a JVM
It locates and loads the J2EE components from the configuration HFS and starts the applications.
7. Request is handed to Web container within the server, routing it to the proper servlet, based on request’s URL
a. Servlet class is loaded by the dynamic class loader.
b. The Java Naming and Directory Interface (JNDI) looks up data sources required by the servlet.
c. Data retrieved from one/many sources and returned to servlet.
d. Servlet sends output stream directly or sends data to JSPs.
o Response: HTML,XML, generated as a response
o Sent back through WebSphere plug-in to Web server.
8. If J2EE application component needs to access corporate data: uses connector (resource adapter) to communicate with the Enterprise Information System (EIS) such as CICS or IMS.
ForwardSourceID:NT000145DE
Thursday, February 02, 2006
Setting Goals
Learning should be a driving force. Most important goal is to never stop learning.
Take care of your health. If you don't have your health, you don't have anything.
Increasing the capability level of each individual on the team and help to sustain this growth.
Continue to progress in the carreer and increase visibility on the team.
Sometimes, it is not about setting goals but simply living in the moment.
Lastly but not the least, have fun.
Wednesday, January 04, 2006
Simple Java test
Provide a small snippet of code, less than 10-20 lines (you can actually do it in 2-3), that will produce a consistent memory leak. |
Wednesday, December 14, 2005
Team Leader Characteristics
Your motto needs to become “Communicate the obvious.” Don’t assume anybody knows anything. Say it out loud and send lots of email. Tell those you report to what you’re doing. Give everybody bad news early. If you have an integration environment that goes down, stand up and announce that it is down. Don’t assume others are going to notice it. Ask who is going to get it running again. Announce to the group that so-and-so is working on it. Ask so-and-so to tell you when it is working again. Announce to the group when it is working again. Etc. Run daily stand up meetings and go around the room and ask three questions: What have you done since the last stand up? What is preventing you from doing whatever is on your plate today? What will you be working on today? Keep these stand ups short and sweet. Break out into one-on-ones with people if they have issues that need to be worked. The important thing is to make sure everybody hears what’s going on within the team and has a chance to contribute things like “did you know there’s a library that already does that?”
Acknowledge the team’s accomplishments and hard work. There’s a ton of humility that comes with being a leader. You’ve got to admit that you can’t get it done yourself, and put yourself at the mercy of your team to do the bulk of the work. You need to thank them sincerely, and often publicly, for their contributions. Don’t know what to thank them for? “Catch them doing something right.” That is, just as you’d go through somebody’s code with a fine toothed comb while criticizing it, do the same but look for clever code, well documented code—whatever’s important to you. Find the good things they’re doing and stand up and say “you did a good job on this.” One of the most rewarding experiences you’ll gain from leading people is the feeling you get when you thank them for their work. When times are tough, sometimes it’s what keeps you coming in the morning.
Don’t ever humilate your colleagues. If you discover some bone-headed code that crashes the system repeatedly, always leave a side door open for escape. Talk to the programmer privately. Programmers are people too...you don’t know if something big is going on in their personal life. We all have problems. When you respect your team as people first, you will be able to count on their support, even when you don’t think you need it. The best way to gain approvals, from department heads, customers, quality groups, etc., that DONT respond to those requests, is to ask for rejection in writing. In other words, email your requests for approval stating that “unless otherwise noted in writing by so-and-so date, we will proceed with the following <purchase> <feature> <whatever>. CC everyone that is relevant. You will get what you need, or at least, you’ll have a tight documentation trail should problems arise in the future.