• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S (2.3.1) - Passed 375/400

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After exactly 4 weeks to the day, my score was posted in the certification database:

General Considerations: 100 88
Documentation: 70 70
OOD: 30 30
GUI: 40 27
Locking: 80 80
Data Store: 40 40
Network Server: 40 40


This score came as quite a surprise to me, as shortly after uploading the assignment, I found quite a few things I wish I had done differently, including what I thought was a bug in my locking manager.

Most perplexing though was my GUI score. I had seen many other ranchers get this score, and so I decided to spend a little extra time on the GUI. I think that in order to get full points, the search would need to be more flexible (i.e. checkbox for case sensitive search, etc), and possibly a user friendly JTable (sorting by column, etc). I also did not implement the Observer pattern as in Monkhouse's DVD project.

As for General Considerations, well, if I knew what that meant, then I might have a chance of figuring out what I didn't do properly...


These are the tools I used and would recommend to anyone:

1. Eclipse (I used Mac OSX, which means Java 5)
2. Ant to automate the build, rmic, javadoc, packaging, etc
3. Testing classes to test locking and concurrency
4. Head First Design Patterns
5. Effective Java
6. Monkhouse/Camerlingo SCJD book

By far one of the most useful tools I found on this site was the testing harness to bombard your app with threads calling random sequences of create, update, etc. If written correctly, this will expose a lot of potential problems with threading and locking.

I read Monkhouse's book and tore apart the sample code. The DVD project is a lot more complicated than your project needs to be, so instead of using that application as a template, I would say make your solution as lean and simple as possible, drawing on the DVD project for some implementation ideas.

As for the essay test, it really is no sweat. Mine was 4 questions that I could have answered in my sleep and elaborated on indefinitely. Here is a great site to help you prepare:
http://www.informit.com/articles/article.aspx?p=101594&redir=1&rl=1


Special Thanks: To Andrew/Terry again for the great book. To Bert/Kathy for HFDP and the SCJP book. And most of all to all the fellow ranchers for their suggestions and ideas.


As a side note, I am now preparing for SCWCD with Bert/Kathy's HF book. One thing that was awesome, is that the MVC architecture of my SCJD project allowed me to transform it into a web application very easily by swapping out the Controller with Servlets, and using JSP/HTML instead of the Swing JTable. I am now building on to the project chapter by chapter and learning a lot about JSP/Servlets in the process.

All in all this was a solid learning experience, I really enjoyed working on the project.

Any ranchers feel free to ask me for any advice, etc. Seeing as this is my first post, I realize that it is time to start giving back to the community.

Good luck to all!

B.T.
 
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Brock and good luck with your next certificate.
 
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well done! Congratulations!
 
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good job!

Thanks for the informIT site, good stuff. And also thanks for the tip on JTable sorting, I was fedup of improving my code and decided not to do it.. and finally did it because of your post.. It was actually a lot simpler than I thought!!

- 1 line: setAutoCreateRowSorter(true);
- And use the method "convertRowIndexToModel" when reffering to a row..

=> Again thank you for advice and for providing me the motivation I was lacking..

Regards,
Alex
 
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats!
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Brock,
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congratulations Brock.

I have a question about the test classes. I'm using JUnit. A problem arises when test a private method of a class. Usually, I declare my test class as a inner class of the class to be tested. This way, the test class can access any member of the testee class. However, since Sun doesn't allow you to use any libraries not from Sun, this stategy doesn't work.

Another way is to put all the test classes in a separate source directory and declare the test and testee classes in the same package, but this need to change private methodes in the testee class to default access to allow the test class to access them.

My question is: will sun think this change as a design flaw and reduce the score?

How did you handle this problem?

Thanks

Liao
 
Brock Toon
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Liao Yang,

I would say it is a design flaw if you have to change your code in order to accommodate your testing. I did not use JUnit for this project, but you should definitely have your testing fixtures in a different source directory.

Personally, I would not feel the need to directly test the private methods, but instead test the package-level access methods that call them, and have sufficient logging to provide more information.

I would think that exposing a private method just so that it can be unit tested would be an anti-pattern of some kind.

If you feel you absolutely must directly test your private methods, your other options would be to have the nested test class (as you are doing), which you would have to remove before submission.

However if you have so much logic in your private method that makes you believe it should be unit tested, I would suggest you think about refactoring your design. You may be better off creating a new class.

Finally, you could also experiment with Reflection to get the test results you need. I have never done this myself, but the java.lang.reflect API should offer you some creative ways to keep your unit tests in a different source folder and still test private methods, without writing messy temporary nested classes.
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I agree, a well spreaded belief/method is to only unit test your public methods. This end up testing your private methods indrectly anyway! (because they *must* be called from public methods somewhere...).

I recently read web page where the author suggested a new technique where he writes a public static method in his classes to execute his unit tests. I would think that the developpers would update the tests cases a lot more having it in front of their eyes when modifying the source code.Perhaps some similar trick could be used to test the private methods..
Unit tests - Static method trick (tip7 out of 10)

This is however, NOT AN OPTION for this certification, you don't want to submit your code with some leading edge debatable new school of thoughts..

So basically, only test your public method, and indirectly everything will be "unit tested".

Regards,
Alex

[ December 13, 2007: Message edited by: Alex Belisle Turcot ]
[ December 13, 2007: Message edited by: Alex Belisle Turcot ]
 
liao Yang
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Brock and Alex, Thank you very much for your reply.

Yes, I'm convinced that testing the public methods is enough and private methods will be tested indirectly. And I like the idea that a private method need to unit-tested, it is better to split or introduce a new (helper) class.

Best regards

Liao
reply
    Bookmark Topic Watch Topic
  • New Topic