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
Wednesday, May 16, 2007
Interviews...
Over the last three weeks I've been interviewing with a certain company. The interview process has been very interesting. At each stage the interview questions just got harder and harder. I guess thats the norm. Its just that its been quite a while since i was subjected to this kind pressure, and to tell you the truth, i truly enjoyed it!
The questions ranged from data structures,
- Where they test your ability to select the most appropriate data structure to solve a problem
- awareness of common data structures and how you would traverse through them
To some really interesting algorithm questions like,
- write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number.
- 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.
The question is fairly straightforward. However, they are not looking for the regular question anybody would give. They are looking for the smarter ones who think about more optimized ways of executing this algorithm. Therefore, the next part is generally focused around complexity.
The last interview was the most toughest. It covered all areas including, scalability concerns, fault tolerance and fail over, performance and availability strategies. All in all, whatever the outcome, I thoroughly enjoyed the experience. All of my interviewers were very easy-going friendly people who had the knack of setting the interviewee at ease.
Heres a link i found pretty useful,
http://discuss.techinterview.org/?interview
The questions ranged from data structures,
- Where they test your ability to select the most appropriate data structure to solve a problem
- awareness of common data structures and how you would traverse through them
To some really interesting algorithm questions like,
- write an algorithm where given an array of numbers (ints) , find the number of pairs that sum up to a given number.
- 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.
The question is fairly straightforward. However, they are not looking for the regular question anybody would give. They are looking for the smarter ones who think about more optimized ways of executing this algorithm. Therefore, the next part is generally focused around complexity.
The last interview was the most toughest. It covered all areas including, scalability concerns, fault tolerance and fail over, performance and availability strategies. All in all, whatever the outcome, I thoroughly enjoyed the experience. All of my interviewers were very easy-going friendly people who had the knack of setting the interviewee at ease.
Heres a link i found pretty useful,
http://discuss.techinterview.org/?interview
Sunday, May 6, 2007
Microsoft Vista Review: It sucks !!!!!
Note: I am trying to be as unbiased as possible.
I installed Microsoft Vista two days ago and I'm already sick of it. I can't count the number of times its annoyed and frustrated me. This is perhaps the worst operating system i have ever used.
Please note that my machine spec isn't all that bad (1.5Gb Ram, T2400 1.83GHz Processor)
Installation procedure: Upgrade.
Here are some of my experiences,
- Ok, when you first look at it, it looks good ! They have done a pretty good job of *trying* to look like Mac. That is what drove me to install it. But don't be deceived!!!
- A simple right click is so unpredictable. If it does decide to appear, it appears in what seems like hours.. ok not hours but at least ~40-50 seconds - Not acceptable
- Out of the 6 times i have booted my machine, on two occasions the desktop rendering was weird. The icons had disappeared and there was no task bar.
- I have administrator privileges. On several times it displayed a dialog box stating that i have no privileges to access files on my disk. Ok, this was experienced while installing MS Office 2007 :)
- If i enable all the goodies and animations overall performance suffers drastically. I have now removed all of its fancy graphics and animation.
To top it all, its soo difficult to uninstall. I am now in the process of reformatting my machine and reverting back to XP.
Recommendation: STAY AWAY !!!
I installed Microsoft Vista two days ago and I'm already sick of it. I can't count the number of times its annoyed and frustrated me. This is perhaps the worst operating system i have ever used.
Please note that my machine spec isn't all that bad (1.5Gb Ram, T2400 1.83GHz Processor)
Installation procedure: Upgrade.
Here are some of my experiences,
- Ok, when you first look at it, it looks good ! They have done a pretty good job of *trying* to look like Mac. That is what drove me to install it. But don't be deceived!!!
- A simple right click is so unpredictable. If it does decide to appear, it appears in what seems like hours.. ok not hours but at least ~40-50 seconds - Not acceptable
- Out of the 6 times i have booted my machine, on two occasions the desktop rendering was weird. The icons had disappeared and there was no task bar.
- I have administrator privileges. On several times it displayed a dialog box stating that i have no privileges to access files on my disk. Ok, this was experienced while installing MS Office 2007 :)
- If i enable all the goodies and animations overall performance suffers drastically. I have now removed all of its fancy graphics and animation.
To top it all, its soo difficult to uninstall. I am now in the process of reformatting my machine and reverting back to XP.
Recommendation: STAY AWAY !!!
Saturday, May 5, 2007
The Grid Project Begins...
After much anticipation, the Citi-UCL collaboration project was finally launched on the 30th of April 2007. We had our preliminary meeting at Canary Wharf – Citi’s Investment Banking headquarters in London. This was followed by another meeting, at UCL, to further discuss the project scope, team organization structure and grading criteria.
We all decided to meet up after the project brief and proactively take the first steps towards launching the project. The Project Manager – Andy and Technical Lead – myself, were chosen to lead the team.
Since most of the team were fairly new to actually taking on and executing a project, I stressed on the importance of selecting and then adhering to a software development methodology (process) that would ensure that we engineer the project in an organized manner.
We swiftly began our project initiation activities,
- Formulating the team - dividing the team into 3 sub-teams. Each sub team was responsible for the requirement gathering, design and implementation of their sub-system.
- Researching and then defining a suitable software development process that would suit our project size and experience, and wouldn’t be that difficult to follow.
- Define templates that the team would use so that, all deliverables would be consistent.
- Define a problem statement, so that we could validate and clarify our understanding of the project, and act as a mechanism to trigger more discussion around requirement gathering
We all decided to meet up after the project brief and proactively take the first steps towards launching the project. The Project Manager – Andy and Technical Lead – myself, were chosen to lead the team.
Since most of the team were fairly new to actually taking on and executing a project, I stressed on the importance of selecting and then adhering to a software development methodology (process) that would ensure that we engineer the project in an organized manner.
We swiftly began our project initiation activities,
- Formulating the team - dividing the team into 3 sub-teams. Each sub team was responsible for the requirement gathering, design and implementation of their sub-system.
- Researching and then defining a suitable software development process that would suit our project size and experience, and wouldn’t be that difficult to follow.
- Define templates that the team would use so that, all deliverables would be consistent.
- Define a problem statement, so that we could validate and clarify our understanding of the project, and act as a mechanism to trigger more discussion around requirement gathering
Saturday, February 10, 2007
Thursday, January 18, 2007
Gale-force winds hit London...
Today was the most windiest day i have ever experienced! And it was. Turns out the Lords cricket grounds actually lost a roof.
http://news.bbc.co.uk/2/hi/europe/6274377.stm
http://content-sl.cricinfo.com/england/content/current/story/276833.html
http://news.bbc.co.uk/2/hi/europe/6274377.stm
http://content-sl.cricinfo.com/england/content/current/story/276833.html
Ruby...
I've just had my first experience with Ruby - the newest addition to the scripting world - and was quite impressed with it. Its quite amazing at how much you can achieve with such a few lines of code (this coming from a Java developer).
Ruby is a dynamic, object oriented programming language. Its syntax is quite intuitive and is fairly easy to learn. Simplicity seems to be the operative word when programming with it. A few more facts about Ruby,
- Interpreted
- Everything is an Object (no primitives.. i mean everything's an object)
- Single inheritance with mixings (i still haven't figured out mixings.. will update this when i do)
- It has some excellent support for collections and regular expressions
- Its free!!!
Something that really impressed me was the following code snippet,
hash = {1=> 'Ricky Ponting', 2=> 'Sanath Jayasuriya'}
hash.each_pair do |key, value| puts "#{key} is #{value}"
These two lines iterate through the hash and prints out the value to the console. How cool is that?
Ruby is a dynamic, object oriented programming language. Its syntax is quite intuitive and is fairly easy to learn. Simplicity seems to be the operative word when programming with it. A few more facts about Ruby,
- Interpreted
- Everything is an Object (no primitives.. i mean everything's an object)
- Single inheritance with mixings (i still haven't figured out mixings.. will update this when i do)
- It has some excellent support for collections and regular expressions
- Its free!!!
Something that really impressed me was the following code snippet,
hash = {1=> 'Ricky Ponting', 2=> 'Sanath Jayasuriya'}
hash.each_pair do |key, value| puts "#{key} is #{value}"
These two lines iterate through the hash and prints out the value to the console. How cool is that?
Saturday, January 13, 2007
JML: The good and the bad
Our most recent assignment was based on the design methodology design by contract. We were asked to use the Java modeling language (JML), an annotation based specification language for Java to ensure our programs were developed to specification.
Here are some interesting observations:
- The idea of JML is very good. Its a non-intrusive mechanism of testing code. The JML annotations can be added before or after the method is fleshed out. (although DBC advocates writing these assertions first)
Eg. JML assertions
//@ requires firstname != "";
//@ requires lastname != "";
//@ requires username != "" || username.length() >4;
//@ requires password != "" || username.length() >4;
//@ requires address != null;
//@ requires !(\exists Customer c; this.customerDB.contains(c);c.getUsername() == username);
//@
//@ ensures \result != null;
//@ ensures (\exists Customer c; this.customerDB.contains(c); c.getUsername() == username);
//@
public Customer addCustomer(String firstname, String lastname, String username, String password, Address address)
- Since these are annotations, it does not mess up and over complicate your methods.
- The syntax is fairly simple, anyone who knows Java can use it.
- Its lightweight and seems to combine well with JUnit.
- It would work well for projects with well defined design specifications. If the design spec clearly specifies the input parameters of each method and its return type, then these annotations can be added at the time of defining your method signatures (at design time).
- It ensures the "contract" is preserved with the use of pre and post conditions. It also ensures correctness is maintained with the use of invariants.
- I feel it actually can take out the customary housekeeping tasks of ensuring your input parameters are not null/empty.
Improvement Suggestions:
- The most important improvement, i believe, should be in their error messages. When a pre/post/invariant is violated the error that is displayed (a JML Exception) is quite cryptic.
Eg.
org.jmlspecs.jmlrac.runtime.JMLEntryPreconditionError: by method TaxiBooking.validateAddress regarding specifications at
File "TaxiBooking.java", line 129, character 28 when
'zipcode' is
This error is actually thrown when a precondition ensuring that the input zipcode parameter is not empty, is violated.
Looking at the error its quite difficult to understand which precondition was violated. Its up to the developer to display or throw an exception with a more meaningful message. Otherwise the software testers would not understand the results of the JML test and the JML tests would only be used by the developers.
- JML seems to be very feature rich. However figuring out all of its features and hunting down documentation to support that was very cumbersome. If they can improve on the documentation, moreover provide more examples, it would be very helpful.
- Better integration with IDE's. I did find an eclipse plug-in, however it was for an older version of eclipse which was not forward compatible.
- I did find it to be a little fussy when it comes to constructors. Perhaps i didn't use it correctly, but it complained when i simply instantiated an object and then used its setter methods to set its attributes. It worked fine when i passed all of its attributes in the constructor and then instantiated the object (which is quite messy in my opinion).
Overall i believe JML has the potential to become quite popular in the industry, provided the right support (IDE) and documentation is made available.
Here are some interesting observations:
- The idea of JML is very good. Its a non-intrusive mechanism of testing code. The JML annotations can be added before or after the method is fleshed out. (although DBC advocates writing these assertions first)
Eg. JML assertions
//@ requires firstname != "";
//@ requires lastname != "";
//@ requires username != "" || username.length() >4;
//@ requires password != "" || username.length() >4;
//@ requires address != null;
//@ requires !(\exists Customer c; this.customerDB.contains(c);c.getUsername() == username);
//@
//@ ensures \result != null;
//@ ensures (\exists Customer c; this.customerDB.contains(c); c.getUsername() == username);
//@
public Customer addCustomer(String firstname, String lastname, String username, String password, Address address)
- Since these are annotations, it does not mess up and over complicate your methods.
- The syntax is fairly simple, anyone who knows Java can use it.
- Its lightweight and seems to combine well with JUnit.
- It would work well for projects with well defined design specifications. If the design spec clearly specifies the input parameters of each method and its return type, then these annotations can be added at the time of defining your method signatures (at design time).
- It ensures the "contract" is preserved with the use of pre and post conditions. It also ensures correctness is maintained with the use of invariants.
- I feel it actually can take out the customary housekeeping tasks of ensuring your input parameters are not null/empty.
Improvement Suggestions:
- The most important improvement, i believe, should be in their error messages. When a pre/post/invariant is violated the error that is displayed (a JML Exception) is quite cryptic.
Eg.
org.jmlspecs.jmlrac.runtime.JMLEntryPreconditionError: by method TaxiBooking.validateAddress regarding specifications at
File "TaxiBooking.java", line 129, character 28 when
'zipcode' is
This error is actually thrown when a precondition ensuring that the input zipcode parameter is not empty, is violated.
Looking at the error its quite difficult to understand which precondition was violated. Its up to the developer to display or throw an exception with a more meaningful message. Otherwise the software testers would not understand the results of the JML test and the JML tests would only be used by the developers.
- JML seems to be very feature rich. However figuring out all of its features and hunting down documentation to support that was very cumbersome. If they can improve on the documentation, moreover provide more examples, it would be very helpful.
- Better integration with IDE's. I did find an eclipse plug-in, however it was for an older version of eclipse which was not forward compatible.
- I did find it to be a little fussy when it comes to constructors. Perhaps i didn't use it correctly, but it complained when i simply instantiated an object and then used its setter methods to set its attributes. It worked fine when i passed all of its attributes in the constructor and then instantiated the object (which is quite messy in my opinion).
Overall i believe JML has the potential to become quite popular in the industry, provided the right support (IDE) and documentation is made available.
Subscribe to:
Posts (Atom)