In my attempt to organize myself and somehow find a way to do the things I do in a more effective manner, I found myself buying David Allen's "Getting things DONE".
Here's what pointed me to it.
http://www.43folders.com/2004/09/08/getting-started-with-getting-things-done
Saturday, December 29, 2007
Wednesday, December 12, 2007
Vehicle Hunt...
Looking for the perfect used car is quite a difficult task. Here are some useful information
Some of the web sites that were very helpful were,
www.cars.com - very good used/new vehicle search. Very good search results. Most of the vehicles were good.
www.autotrader.com - fair decent search results
www.kbb.com - useful in getting a rough idea on how much the vehicle is worth.
www.carfax.com - extremely useful in getting the history of a vehicle (accidents, owners, emission tests, etc)
Here are some of the lessons I learnt along the way....
1. Do your homework on the vehicle you select (includes reading user reviews and carfax records)
2. Test drive it and see if it drives as well as it looks :)
3. See as many as you can. Having options is always a good thing.
4. Try your best to stick to your budget. (remember you have other costs as well; insurance, registration, inspections, car care stuff and other gadgets)
5. Always negotiate. You never know when you will strike the best deal. Dealers always talk the talk! Don't fall for it. Make your offer and walk away. They WILL call you back.
6. Get your vehicle inspected by the agents before you purchase it.
Some of the web sites that were very helpful were,
www.cars.com - very good used/new vehicle search. Very good search results. Most of the vehicles were good.
www.autotrader.com - fair decent search results
www.kbb.com - useful in getting a rough idea on how much the vehicle is worth.
www.carfax.com - extremely useful in getting the history of a vehicle (accidents, owners, emission tests, etc)
Here are some of the lessons I learnt along the way....
1. Do your homework on the vehicle you select (includes reading user reviews and carfax records)
2. Test drive it and see if it drives as well as it looks :)
3. See as many as you can. Having options is always a good thing.
4. Try your best to stick to your budget. (remember you have other costs as well; insurance, registration, inspections, car care stuff and other gadgets)
5. Always negotiate. You never know when you will strike the best deal. Dealers always talk the talk! Don't fall for it. Make your offer and walk away. They WILL call you back.
6. Get your vehicle inspected by the agents before you purchase it.
Sunday, October 14, 2007
Moving to Milwaukee....
I'm back in the US of A, and this time its going to be for a while. New project, new setup, new way of life.
So far I'm enjoying the transition from student life to work life. A few things are harder getting used to again. Like,
- The nightly calls with my off shore team
- The busy days filled with meetings
- Handling conflicting personalities
Whereas, I enjoy,
- Getting paid again !!! woohoo..
- Being in the midst of solutioning an enterprise architecture
- The challenge of constantly having to push to learn new technologies and methodologies
In addition to the work aspect, the whole experience of settling down is exciting. Starting from the search for a place to stay, buying a bed, getting my SSN, applying for my drivers license to buying a car... and many more to come..
So far I'm enjoying the transition from student life to work life. A few things are harder getting used to again. Like,
- The nightly calls with my off shore team
- The busy days filled with meetings
- Handling conflicting personalities
Whereas, I enjoy,
- Getting paid again !!! woohoo..
- Being in the midst of solutioning an enterprise architecture
- The challenge of constantly having to push to learn new technologies and methodologies
In addition to the work aspect, the whole experience of settling down is exciting. Starting from the search for a place to stay, buying a bed, getting my SSN, applying for my drivers license to buying a car... and many more to come..
Monday, July 23, 2007
Interview questions (2)
1. How would you write your own garbage collector ?
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
3. Write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number
4. Given a n by n matrix or integers, where each row is sorted in ascending order and each column is sorted in ascending order. Find a particular number in that matrix.
5. Write a basic compiler simulator
6. Given a sentence, write an algorithm that would reverse all the letters in teh sentence.
7. The same sentence, write an algorithm that would reverse all the words in that sentence.
8. When would you use a hashmap, hashset, linked list ?
9. Questions around serialization - why ? how to serialize, how to prevent serialization
10. Concurrency - dead locks, prevention of deadlocks, race conditions
11. Web apps - req/response, vs sessions, how do web servers keep track of sessions, why would you use pooling
12. Threads - whats a thread local, why would you use one, what do you need to be aware of when using threads
Other questions
- Why would you use materialized views.
- Joins, self joins, hierarchical queries
2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
3. Write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number
4. Given a n by n matrix or integers, where each row is sorted in ascending order and each column is sorted in ascending order. Find a particular number in that matrix.
5. Write a basic compiler simulator
6. Given a sentence, write an algorithm that would reverse all the letters in teh sentence.
7. The same sentence, write an algorithm that would reverse all the words in that sentence.
8. When would you use a hashmap, hashset, linked list ?
9. Questions around serialization - why ? how to serialize, how to prevent serialization
10. Concurrency - dead locks, prevention of deadlocks, race conditions
11. Web apps - req/response, vs sessions, how do web servers keep track of sessions, why would you use pooling
12. Threads - whats a thread local, why would you use one, what do you need to be aware of when using threads
Other questions
- Why would you use materialized views.
- Joins, self joins, hierarchical queries
Wednesday, May 30, 2007
Team Dynamics - part 1
I'm pretty sure this is going to be the start of a series of notes on my experiences with the various teams as they progress through the project.
Communication:
My most favorite team (i shouldn't be saying this), but in my eyes the most strongest team, started out really well. They were very eager to do the right thing, and produce results. They worked cohesively to capture requirements and produced a very good requirements spec.
However when we started the design phase we started experiencing certain crucial problem which actually hampered their progress.
- The team was too enthusiastic in churning out code that they didn't think through the design thoroughly. They were quick to start coding certain sections of the code. While coding they realized there were gaps in their design. This resulted in many many discussions around certain areas of the design which were not thought out properly, which resulted in a lot of rework. This was probably due to the fact that they had to produce both a Java api and a C++ api as well.
- There was a serious communication gap. What i mean is that each person interpreted the design in their own way. They did not stop to debrief and consolidate their understanding. This too was a major reason for the many design discussions.
Result: They didn't achieve the level of efficiency they would have liked to achieve. This resulted in them falling back on the schedule.
How we overcame it :
- Took a step back. Went through the design, step by step without taking anything for granted.
- Ensured that we all had the same understanding.
- Shared the effort of documentating the sequence diagrams.
Communication:
My most favorite team (i shouldn't be saying this), but in my eyes the most strongest team, started out really well. They were very eager to do the right thing, and produce results. They worked cohesively to capture requirements and produced a very good requirements spec.
However when we started the design phase we started experiencing certain crucial problem which actually hampered their progress.
- The team was too enthusiastic in churning out code that they didn't think through the design thoroughly. They were quick to start coding certain sections of the code. While coding they realized there were gaps in their design. This resulted in many many discussions around certain areas of the design which were not thought out properly, which resulted in a lot of rework. This was probably due to the fact that they had to produce both a Java api and a C++ api as well.
- There was a serious communication gap. What i mean is that each person interpreted the design in their own way. They did not stop to debrief and consolidate their understanding. This too was a major reason for the many design discussions.
Result: They didn't achieve the level of efficiency they would have liked to achieve. This resulted in them falling back on the schedule.
How we overcame it :
- Took a step back. Went through the design, step by step without taking anything for granted.
- Ensured that we all had the same understanding.
- Shared the effort of documentating the sequence diagrams.
Monday, May 28, 2007
Service Data Objects
One of the projects i'm involved in requires us to design and implement a generic "data container" such that any client could use it to store and retrieve data. Thats not all, if required, the data in the data container should be serializable in the form of either XML or some other defined format. In addition to that, the data container should be inter-operable, that is once serialized a different client (c++ or java) should be able to de-serialize it and use the data within. Pretty interesting stuff.
While performing my initial research for the design and implementation, i came across 2 strong technology contenders. JaxB and SDO. Ideally you cannot compare the two as they serve two different purposes. But i will explain why i used those names in the next section.
JaxB provides a very easy way to bind data to XML in a static manner. That is, the objects have to be generated before hand and included in the classpath. Once an XML document is received the JaxB api allows us to deal with objects rather than xml elements. However, we had to provide the client the flexibility to create objects dynamically - on the fly. Therefore, for dynamic object creation, there was no way we could have the classes ready before hand. Therefore static binding will not satisfy this flexibility requirement.
This is when i came across the Service Data Object spec. SDO's are built for this purpose - to contain data. And after more research, i found out that all SDO implementations (IBM, Apache and a few others ) are based on EMF (Eclipse Modelling Framework). EMF provides the facility for both static and dynamic binding. Therefore with SDO, a client could create an object on the fly, generate an XML out of it (no XSD required) and vice versa. Pretty cool.
While performing my initial research for the design and implementation, i came across 2 strong technology contenders. JaxB and SDO. Ideally you cannot compare the two as they serve two different purposes. But i will explain why i used those names in the next section.
JaxB provides a very easy way to bind data to XML in a static manner. That is, the objects have to be generated before hand and included in the classpath. Once an XML document is received the JaxB api allows us to deal with objects rather than xml elements. However, we had to provide the client the flexibility to create objects dynamically - on the fly. Therefore, for dynamic object creation, there was no way we could have the classes ready before hand. Therefore static binding will not satisfy this flexibility requirement.
This is when i came across the Service Data Object spec. SDO's are built for this purpose - to contain data. And after more research, i found out that all SDO implementations (IBM, Apache and a few others ) are based on EMF (Eclipse Modelling Framework). EMF provides the facility for both static and dynamic binding. Therefore with SDO, a client could create an object on the fly, generate an XML out of it (no XSD required) and vice versa. Pretty cool.
Sunday, May 20, 2007
Deciding on subversion access priviledges...
As part of setting up the infrastructure for development we had to set up and configure subversion as our source control repository.
My initial thoughts were to provide read write access to all developers to all projects. My rational behind this was that, we were all adults and that there has to be some discipline when checking in code. As in no one would check in broken code.
However, after speaking to some of the team members it became apparent that most developers were new to this concept of working with a code repository and that they most probably would lazily check in code without ensuring their changes would cause a break in the build. Therefore, lets give each developer access to only their section of the codebase (frontend, backend etc).
Ok, thats understandable. i can live with that. After all prevention is better than cure :P
However there was another school of thought that brought up this very interesting proposal. Since these developers were new to this practice, why not give very specific access privileges. I.e. class level. Wow... i had never thought of this.
Personally, i don't think this is practical at all. It would be a nightmare trying to manage access privileges as developers finish a particular class and want to add/edit another class. And wouldn't this be a serious bottleneck to development ?
Interesting argument.. how far can you go with prevention ?? :P:P
My initial thoughts were to provide read write access to all developers to all projects. My rational behind this was that, we were all adults and that there has to be some discipline when checking in code. As in no one would check in broken code.
However, after speaking to some of the team members it became apparent that most developers were new to this concept of working with a code repository and that they most probably would lazily check in code without ensuring their changes would cause a break in the build. Therefore, lets give each developer access to only their section of the codebase (frontend, backend etc).
Ok, thats understandable. i can live with that. After all prevention is better than cure :P
However there was another school of thought that brought up this very interesting proposal. Since these developers were new to this practice, why not give very specific access privileges. I.e. class level. Wow... i had never thought of this.
Personally, i don't think this is practical at all. It would be a nightmare trying to manage access privileges as developers finish a particular class and want to add/edit another class. And wouldn't this be a serious bottleneck to development ?
Interesting argument.. how far can you go with prevention ?? :P:P
Subscribe to:
Posts (Atom)