Pawel Piwowar

Greenhorn
+ Follow
since Feb 12, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Pawel Piwowar

The situation, you described, when there is not time to execute all unit tests, indicates that there is a bigger problem with your project.
Since all build is made in one go, I presume, the project is not modularised properly.
So the only long-term solution IMO, should be refactoring: dividing it into small modules, built independently.

At the beginning you can try identifying the code which changes rarely. For example any utilities you created for your project, like XML, file, sql or JNDI operations.
Since you made separate module including such utilities, your main project will be smaller and faster to build and test.
Module containing utilities will be built much rarely, only when necessary. The main project will use it as compiled jar stored in repository.
You can also modularise your application by business domains, i.e. each module contains functionality for different domain, like: accounting, sales and so one.
This way, since you finish work on one functional module, it is no longer changed and tested. You build and test only the part of your application which is currently developed.
It will fix the problem of long build including long unit testing. Maybe it is not easy solution, but will give you many more advantages, like easier maintenance, higher quality and so on.

13 years ago
Hello,

Your findCar() method must return something, should not be void.
Since you fix this, the class could be tested with code like that:




You can create similar tests for other methods.
Repeating code, like creating new instance of ParkingLot could be moved to separate method annotated with @Before
13 years ago
You can modularise your project with parent and child modules. Each module can be a parent for another modules as well. This way you don't have to put everything into single pom.xml.
Another approach is dividing your big project into smaller independent projects. Each of them producing its own artifacts (jar for example) placed in repository. Your main project becomes smaller and simpler, using artifacts already present in repository. Its not only a remedy for complex poms, but also for making your application easy to maintain. In case of Gradle build I would recommend similar approach.

Concerning scripting, do you really need it ? For typical tasks like unpacking dependencies or creating EARs, you can use plugins (http://maven.apache.org/plugins/index.html) . Which is simpler and more reliable then creating your own scripts. Or you can create his own plugin in Java, which give you more flexibility and control (JUnit tests for your plugins) then writing scripts.
However if you insist to write scripts in groovy, you can also do it, by using groovy-maven-plugin.
13 years ago
Hello,

I've been using Maven for several years in different enterprise projects and could recommend it to you. I do not have any experiences with Gradle, so could not tell you which one is better.
However I can assure you that if you choose Maven, you will not be disappointed. You can quickly configure your continuous build environment using Maven together with Nexus and Hudson.
All of them are great products easily installed and maintained.
There is also another nice feature of Maven: plugins written in Java. There are lot of thems: for example for managing dependencies, starting application server, sql operations.
If is not enough, you can always write your own plugin, which is easy and well documented.

And one more thing, as I can see on Gradle site, the last version is 1.0-milestone-3.
In case of Maven the last version is 3.03, You can also choose version 2.2.1 (I'm currently using it).
If you start a commercial project using stable version is a must IMO.

I hope this will help you making your decision
13 years ago

can you let me know the name of the book "Mark Cade"



Sun Certified Enterprise Architect for Java™ EE Study Guide, Second Edition
By: Mark Cade; Humphrey Sheil
It seams that also A is correct , So IMO the correct answers are: A, D,E. Only B and C are evidently wrong.

According to Cade/Sheil book the list of non-functional requirements is following:
Performance
Scalability
Reliability
Availability
Extensibility
Maintainability
Manageability
Security

The rest from you list like "capacity" can be treated rather as system characteristics, not a non-functional requirement.

Anyway you should not worry to much about this type of questions. the real exam contains more interesting, scenario-type questions.
So, for you it is enough to understand the definition of every non-functional requirement.

BTW, such mock tests quite often contain wrong or not clear answers. I used ePractize and the percentage of doubtful questions/answers was at quite high level (about 5-10 %).
I had no more than 70-75 % results on ePractize tests, but reached 87% on real exam
Hello Tomek,

I don't see a big problem here. Your inventory system should simply know about the orders created for auctioneering application.
It should use additional property for each part, called : "expected number of items", and make predictions based on this property, not on the real number of parts on stock.
This way, the second user will not make duplicated order.

Similar solution is also used by Banks, where you have "book balance" reflecting balance from accounting system and "available money" which includes all transactions that were executed, but not booked yet.
(For example when you pay with credit card, the transaction is booked after 1-2 days in accounting system, but the amount is immediately included in "available money") .
This way when you try to make new transaction, the "available money" is checked not "book balance". Your account is protected from withdrawing more many then you have on a account.

Regards,

Pawel
I think the entry from Humphrey Sheil blog answers your question : http://humphreysheil.blogspot.com/2009/06/slides-from-javaone-bof-on-scea-exam.html#c8421713752901304123

RE: fragmenting the class diagram, I genuinely advocate against this and do so quite strongly. Fragmentation by itself is not the issue, but almost all candidates who do fragment, never provide a joined-up view clearly showing that their multiple class diagram fragments fulfil the business problem laid out in the domain model. Specifically, they lose many marks because association and multiplicity information between entities.

Finally, I believe that the complexity of the assignments in the exam don't require fragmentation.



So, for me the answer is clear : For SCEA assignment its better to make single diagram, if you have a big number of classes which could not fit on one diagram, it could only indicate that your solution become to complex (for SCEA needs) and you should simply reduce the number of your classes.
I think it is better to create simple and elegant solution, without going to far into details, and making a huge project, containing many fragmented diagrams.
Of course in case of real projects such fragmentation is inevitable, however SCEA assignment is much simpler than real project and following SCEA authors tips is a good idea IMO.
Congratulations and thanks for sharing your experiences.
Also thanks for the link to Humphrey Sheil blog with Chapter 9 of JEE Study Guide. Unfortunately in PDF version, which I bought from Safari Online, diagrams in this chapter are not readable (I already reported this problem to Safari Online and they promised to solve it). I compared the solution from this book and ePractize study lab for SCEA II/III, and in my opinion it is more clear. ePractize divides nearly every diagram into smaller parts (most probably because of limited space of their application), which makes them harder to read.

Regards,

Pawel Piwowar
Hello,

Which example assignments for SCEA II/III would you recommend. So far I checked following:
- ePractize Labs Part 2/3, it contains 6 mock projects
- Scenario from Mark Cade/Humphrey Sheil JEE Study Guide (chapter 9)
- Enterprise JavaBeans 3.0 by Bill Burke, Richard Monson-Haefel (Chapter 21: EJB Design in the Real World )
I found each of them useful, however there are significant differences between them.
For example Mark Cade class diagram uses annotations like @Stateless @Entity, while others : <<Stateless Session Bean>>
Additionally Cade placed all classes on one large diagram, but ePractize used one general diagram and several more detailed ( for each tier like WEB , EJB ).
Burke is also using one general class diagram close to this presented by Cade.

My question is: do anybody of you have experiences with solutions presented above, or could recommend something not listed by me ?
Which one is the best, it terms of matching the SUN reviewer expectations ?


One more thing regarding PDF version of this Java EE Study Guide book.
Some diagrams, for example class diagram on page 172, are not readable at all.
They are compressed bitmaps and apparently the compression was too high. I'm going to report this problem to Safari.
Hello,

Regarding Java EE Study Guide by Mark Cade, Humphrey Sheil, I partly agree with Gurvinder opinion.
The book is indeed quite short (but has 217 pages, not 150) and cannot be used as only book for SCEA exam.
I also agree, that it should be cheaper. 40$ is to much for such tiny book.
However it is not a bad book and in my case it really helped me.
I just read a chapter from this book and then used another more specialised book, or articles from Internet for more detailed study.

If someone doesn't want to wait for printed version, another option is buying electronic PDF version.
Its cheaper and can be downloaded immediately from safaribooksonline.com for 29$ .
Its worth mentioning that the book contains also one chapter for part II/III of SCEA (example scenario and solution).

Regards,

Pawel Piwowar
Question 1: Your answers seem to be correct.

Question 2:
1-D : Symmetric encryption could be used for data exchange after initial asymmetric key exchange, see explanation here : http://www.suse.de/~garloff/Writings/mutt_gpg/node3.html
2-B
3-C
4-A : Digital signature : message digest generated using hash algorithm (for example SHA-256) is encrypted with user private key and attached to the message. The receiver of the message will be able to decrypt this digital signature using sender public key. If he succeeded, it means, that the signature was indeed generated by a sender. Then he can generate the hash from the message and compare it with the original hash value (decrypted in previous step). If they match, it means, that the message was not changed during transmission and it was send by a sender.
Digest value is used here because asymmetric encryption is expensive and operating on short hash values instead of the whole message is much quicker.

Regards,

Pawel Piwowar