|
|
Friday, April 25, 2003
|
|
| |
A belated Easter egg question....
I was looking at the some code recently and I noticed that the author added a little easter egg in the code...(you know one of those things where if the user provides some special input something out of the ordinary happens)....My take is that I'm too busy to find the time to come with an easter egg so I've never added one...
So I was wondering how many of you put easter eggs in your code.....
6:06:08 PM
|
|
|
|
Thursday, March 27, 2003
|
|
| |
Testing private methods?
So how do people test private methods....my opinion is that you should test private methods at all. Adequate test coverage should cover these methods through testing of the public and protected methods that use the private methods. However....
I know some people that don't even use the keyword private at all....they claim that it makes it easier to test every method (they make the methods all protected and make sure that the tests for that class are in the same package)....
So how do you do it...if at all...???
8:08:52 PM
|
|
I just read Roy Miller's article on IBM developerWorks titled :Demystifying Extreme Programming: Winning with a pair and here are my problems with the article's key points. First of all the article states that the benefits of pair programming are below :
Reduces risk
Roy states "In addition, code written by a pair is almost always better than code written by an individual. Two heads really are better than one, especially for design decisions that affect the entire system". My argument is that it depends on the programmers skill and style. If you have an experienced programmer and a non-experienced programmer pairing than are two heads really better than one? I don't doubt that pair programming reduces risk, I doubt that it reduces risk any more than having good communication across a team of talented programmers. If you don't have talented programmers on your team, then you have other problems.....
Makes the team more productive
Again, I don't think that pair programming makes the team more productive. How do you measure productivity? Roy states, "When you feel like giving up, there's somebody else there to encourage you and keep you going. Teams are also less likely to neglect tests or other important details -- that alone increases productivity." Again, if you have a talented team of programmers who communicate well, the programmer having a problem will ask for help. There are code reviews to ensure that there is test coverage. Keep in mind....that when you have two programmers solving one problem, you could have two programmers solving two problems just as well. There is an oppurtunity cost involved that somehow disappears because Pair Programming advocates think that the code is better. Do two painters painting the same painting make the painting any better. I don't think that if I paired with Leonardo Da Vinci painting the Mona Lisa, it would have turned out any better....
Results in better code
Again....It all depends....Roy states, "Sometimes the simplest thing that could possibly work is hard until you get used to it. Pairing is a good example". I don't think Pair Programming is simple...nothing can be simpler than working on a problem and solving it by yourself....
Now don't get me wrong most aspects of XP are great....but Pair Programming only works if you have two programmers who are similiar in experience and style....
What are your thoughts...
8:05:34 PM
|
|
|
|
Thursday, March 20, 2003
|
|
| |
The size of the JRE?
While I was at the recent TriJUG meeting, the topic came up of the size of rt.jar. Here are my thoughts on this topic....Why is rt.jar so big....do awt and swing classes need to be a part of the core API. Why doesn't SUN just create an AWT.jar and a SWING.JAR and throw them in the jre/lib/ext directory? It's almost like Sun is saying oh...here is something cool (read XML parsing, awt, swing, regex, sound) let's throw it in rt.jar and make life a pain since you can't override those classes. Wouldn't make it easier to port Java to other platforms if they didn't have to worry about porting the all of of the ui classes. Isn't that what sun wants to have java everywhere?
Instead of having a one size fit's all strategy with regards to J2SE, they should have a smaller J2SE and let development teams within Sun release their extensions whenever they have an update and not wait make us wait...
These are just some ramblings...I needed a break from some SWT programming...What do you think?
Who knows....
5:15:45 PM
|
|
|
|
Tuesday, March 18, 2003
|
|
| |
A small Java pet peeve
Why does the Vector class throw an ArrayIndexOutOfBoundsException when all other List interface implementors throw IndexOutOfBoundsException? Doesn't this somewhat defeat the purpose of encapsulation, since by throwing ArrayIndexOutOfBoundsException, the Vector class is exposing it's internal implementation?? The ArrayList is also based on an array data structure....but it doesn't hint it by throwing the more specific exception. Why can't they deprecate the method and throw the correct exception?
In my humble opinion, no object should throw ArrayIndexOutOfBoundsException because this exception implies the use of an array not the use of an Object.
Sorry for my ranting on such a small insignificant subject....Oh well....What do you think??
5:53:40 PM
|
|
|
|
Monday, March 17, 2003
|
|
| |
TCK - What is it?
The TCK (Techonology Compatibility Kit) is a suite of tests that test an implementation of a Java Specification against the behavior of the RI (Reference Implementation). Note that I said that it tests behavior against the RI and not the specification. The purpose of the test suite is for Sun to ensure that your implementation of CLDC (for example) is compliant with the RI. In order to earn compliance, for example, you can't add any additional API that is not in the specification to your implementation. If I recall this is what Microsoft J++ did...But the real question is...what if you fail a test...In my experience I found that there are typically three causes for failing a test :
- The test does not test something in the specification. In this case, the test is testing an RI specific feature that is not required by the specification. Typically the specification is not clear but the test is included. In this case you can petition to have the test removed, since your implementation can still follow the specification but still fails the test..
- The RI is not compliant with the specification, but still passes the test since by definition an RI is the "reference" and therefore must be compliant with itself. My guess is that this occurs because the people writing the tests already have an RI and are basing the tests on the RI and not the specification. If the author of the RI makes a mistake the test will not catch it...Write your tests first!!!
- The test is accurate and your implementation does not comply....In this case you have to fix your implementation in order to be compliant....
Well anyways...those are my personal musings for the day....Off to the Triangle Java User Group meeting...
5:03:51 PM
|
|
|
|
Tuesday, March 11, 2003
|
|
| |
Comments yeah...what are they good for....
I was always taught that comments are good...hell in school..if I didn't comment that I got a lower grade...So how does this jive with some of the popular terms such as "self-documenting code" or "if you write readable code you don't need comments". I know that in XP they say that your code shouldn't require comments. I say they are WRONG!! And here's why....
Before we pass judgement...Let's see why we need comments. There are two basic reasons for having comments
- To describe what the code does
- To describe why the code does what it does
In the first case...I agree that writing good..clean code may substitute for comments...and if you still feel you need comments attempt to refactor so that the code is clear.
However, in the second case comments are definitely necessary...If you are using a non-obvious algorithm to solve a specific problem they although people reading your code may know what it does they don't know why? In this case a comment can be helpful. Especially in XP where there is no code ownership, someone else may be changing your code at a later date (maybe even the developer who wrote the code)and not fully understanding the algorithm. This is a recipe for disaster...
Tell me...what's your policy....
5:19:51 PM
|
|
|
|
Monday, March 10, 2003
|
|
| |
My 1st day review OO Analysis and Design Class. So far so good....Learned a lot about UML!!
Learned about Domains, Use Cases, and the various types of diagrams used to describe object states (state diagram), Object Interactions (Collaboration Diagram), and Sequence Diagrams. Learned the difference between a associative relationship (both types) and dependancies. Very good introduction of UML. Discussed Encapsulation, and the difference between overriding and overloading methods. Overriding is the replacement of another method with a method in a subclass that has the same signature. Overloading is having a method with the same name, but different signature in the same class. For example....public void add(int i, int j) and public void add(float f1, float f2)...I found this link from Sun about when not to overload methods...click here
The instructor recommended the following book (another Martin Fowler text...I just reviewed Refactoring a couple of days ago)...The book is called UML Distilled...you can buy it here. Please don't think that I'm some Martin Fowler freak fan or anything :)
If you have any ideas, web sites, or books that can help me learn more UML...just post a comment or something....
7:38:29 PM
|
|
|
|
© Copyright
2004
Peter Ghali.
Last update:
3/6/2004; 11:39:08 PM.
This theme is based on the SoundWaves
(blue) Manila theme. |
|
| March 2004 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
1 |
2 |
3 |
4 |
5 |
6 |
| 7 |
8 |
9 |
10 |
11 |
12 |
13 |
| 14 |
15 |
16 |
17 |
18 |
19 |
20 |
| 21 |
22 |
23 |
24 |
25 |
26 |
27 |
| 28 |
29 |
30 |
31 |
|
|
|
| Apr Apr |
|