Redbooks residency:Day 2:September 5.

The last redbooks resident "Ron Townsend" came on board today. He flew in from Indianapolis. He had given a proof of technology for Wachovia for the printing solutions replacement system, and worked with David Weddle and Jerry Sienkewiz (Coincidence or what).
Framemaker/Writing English class (9:30-12:30). The instructor gave some background on "Kill" names for places around here ( Fishkill/Catskill ). It is terminology for Streams. Asked us to be wary of black bears,deers,chipmunks and poison ivy when doing outdoor activity. The lunch at IBM cafeteria was not much different from yesterday, it is turning out to be more monotonous.
The redbook may be titled: Integrating back-end systems through websphere using webservices.
Finalised the scenarios for the redbook. Topics covered could include:
1. WAS to CICS inbound/outbound with MQ and HHTP transport.
2. DB2 V9 (Viper client) Webservices between WAS and DB2. (Stored procedure and dynamic SQL)
3. WAS to IMS ( MFS based webservices and SOAP IMS gateway)
4. WAS to WAS ( WMQ,SIB, ESB....)
I am teamed to work with Ronald on 2 and 3. Sergio and Mario to work on 3 and 4.
Alex mentioned that he will be out for 2 weeks giving seminars and workshops in B'lore and Chennai,India. Came to know that his India trip was planned 2 months in advance. Beats me as to why he would schedule himself as a residency lead with such a conflict ( Bad planning???)

Quotable Quote: "What you did yesterday is history. What you promise for tomorrow is mystery. What you can deliver today is reality." - Anand P. Shah.

Redbooks residency:Day 1:September 4.

Checked into Residence Inn yesterday. Nice room with kitchen and seperated bedroom. Homely atmosphere and everything looked new ( probably newly remodelled room).
Morning breakfast ( Buffett) is free and had quite a good varietyof food. Drove to IBM site at which is behind the inn. Finished with Security and badging. Met two other residents from Sao Paulo, and Brazillia, Brazil ( Mario and Sergio ). It was a 11 hour flight for them from Brazil to US. Mario is IBM level 2 support for Banque De Brazil. Sergio was not really good in english.
Met with the residency leader Alex and Mike. Had lunch at the IBM cafeteria. The residency format is going to be fairly open and flexible which is nice that we are not really going to be constrained.
2 pm Orientation: Our residency leader Alex will be away for 2 weeks for some business trip. Mike will be taking over the residency project management. Tomorrow we are scheduled for 3 hour framemaker training. In the afternoon we will be finalising the scenarious for the redbook ( Hopefully we will have the 4th person checked in by then)

This site is where IBM makes its z/os machines. IBM System Z9 machine at the lobby. Not sure if it is a skeleton or working model though....
IBM System Z9 machine

The walls are decked with many many Redbooks published from this site on one side and many many redbook residency leaders on the other side.

The Redbooks library and current ITSO residents. ( See if you can spot me ...)

Quotable Quote: "We are what we repeatedly do. Excellence, then, is not an act, but a habit." –- Aristotle

Picture of the family at the entrance of our house.

The crocodile park heavily populated with one too many of these...

My daugther holding a python at the park.

At kovalam beach next to the park.

Quotable Quote: Never Rest on your laurels. Keep challenging yourself. Keep raising the bar and keep reaching new heights.

Accepted for IBM redbook residency

I will be doing a 6 week IBM redbook residency in Poughkeepsie, NY for updating the existing Websphere for Z/OS Connectivity handbook from Sep 4th to Oct 5th. This will provide an excellent learning opportunity. IBM Redbooks are developed through a unique residency program that teams IBM technical professionals with Business Partners, clients, and IBM product development staff. Depending on the market needs of a product or solution, a team of residents is chosen through a competitive nomination process and works at one of the IBM centers for two to eight weeks, devoted to developing IBM Redbooks.

Quotable Quote: You'll never have all the information you need to make a decision. If you did, it would be a foregone conclusion, not a decision” - David Mahoney

State championship Pinehurst Team picture

In our initial round, we played against teams from Hickory, Durham and Winston Salem. Lost to Winston Salem in a close match ( 2-3). Here is article about our team: http://www.ncadultleaguetennis.com/pdffiles/DayThreeStory.pdf

Our location in Wikimapia

http://wikimapia.org/#y=35387099&x=-80756700&z=17&l=0&m=a&v=2

Lake Norman USTA local league champion team

Was proud to be part of the Lake Norman USTA local league champion team. Our team won with a record 12-0 played at state championships at Pinehurst scheduled for 7/4,7/5 and 7/6.
here is my record:

	NORTH CAROLINA	2007 Lake USTA League Adult
Match Date	Winning Player	Opponent	Score	Match Type
3/8/2007	Karthik Shanmugam	Kevin Fontana	6-1, 4-6, 1-0	#2 Singles
3/13/2007	Karthik Shanmugam	Chip Aprile	6-1, 6-1	#2 Singles
3/20/2007	Karthik Shanmugam	David W. Stewart	6-4, 6-0	#2 Singles
3/22/2007	Karthik Shanmugam	Paul M. Begley	6-3, 6-3	#2 Singles
4/12/2007	Karthik Shanmugam	Default	6-0, 6-0	#2 Singles
4/24/2007	Karthik Shanmugam	David J. Walton	6-1, 6-1	#1 Singles
4/26/2007	Karthik Shanmugam	Jacob Lee Henault	7-6, 7-6	#1 Singles
5/1/2007	Karthik Shanmugam	Default	6-0, 6-0	#2 Singles
5/10/2007	Karthik Shanmugam Sanjeev Dange	Michael Baldelli Dale Kiel	6-1, 6-3	#3 Doubles
5/24/2007	Karthik Shanmugam Sanjeev Dange	Bob Santoli Rusty Pittman	6-3, 6-0	#3 Doubles
5/31/2007	Karthik Shanmugam	Dominique Falewee	6-4, 4-6, 1-0	#2 Singles

Developer tasks

Talk to customers and figure out requirements.
Define system architectures.
Create task estimates and help prioritize tasks.
Explore new technologies.
Brainstorm solutions when my team is stuck.
Make sure my team is running effectively.
Write code.

Few ways to gain leadership credibility:

1. Do the things other people don't want to (that's a big one in software industry).
2. Change your default way of thinking so that you consider everything to be your responsibility until it is otherwise delegated. That doesn't mean you do everything. That means you don't ignore something because "it isn't your job". THIS IS KEY.  Leadership = ownership.
3. Do what you can to remove roadblocks that are keeping others from progressing in their tasks.
4. Know your domain be it IT, software dev., networking, enterprise engineering, etc.
5. Complement or praise your peers. Giving praise is a sign of authority. It also makes people want you to be their leader.

On the other hand, leading does not mean:

1. You make all the decisions.
2. You force your opinion on the team.
3. You tell people what to do.

Good Traits

Good Attitude,
Willingness To Seek Work
Ingrained desire to Help others
Ability to fill in for superior/subordinate at all times.
Be the “go to” person for something

Tid Bits

The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.

You can't stay in one place and expect a logical "progression". It's your career, take control of it yourself or someone else will. Companies will always view you as the person they first hired. Start as an intern and 10 years later you'll still be seen as that intern. The solution is to move every time you upgrade your skills either by getting an advanced degree or some new special responsibilities and training.

Elegant Solutions and Learning

An elegant solution is one in which the optimal outcome is achieved with the minimal expenditure of effort and expense. The bells and whistles in some of todays electronics can easily get out of control resulting in the danger of complexity and customer alienation. Real learning is a cycle of questioning, experimenting and reflecting. Its how we convert curiosity into and innovative solution, so learning must BE the work, not something seperate from it. Learning triggers creativity down the line. Software services require people who are good bridging the gap between the needs of the businesses and the technologies that can make them more efficient or increase their revenues

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.