Marcus Jastrebowski

Ranch Hand
+ Follow
since Nov 15, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marcus Jastrebowski

From what I have seen so far in various literature, the term "component" does not have precise definition. Just as you mentioned, I have seen a jsp page referred to as a component; but I have also seen a collection of classes defined as a single component. The term 'component' can be pretty much anything, and therefore it conveys very little useful meaning. At least to me. Anybody, please correct me if I am wrong in this.

Also, you can read what wikipedia crowd have to say about it.

I particularly like this statement:

A component is an object written to a specification. It does not matter what the specification is...



[ February 23, 2008: Message edited by: Marcus Jastrebowski ]

The big deal is really more a matter of having something that is "official" that represents proof directly from a third party that you are not claiming credentials to which you are not entitled.
I don't see why anyone would do so, but it isn't really that hard to make something that looks like a score report (and I, personally, refuse to divulge my scores to employers/clients).



Hi Theodore,

Thanks for this explanation. So should I infer that the "official" credentials are impossible, or should I say very hard, to cheat, crack, beat or duplicate without permission by an unscrupulous job seeker?

Actually, this is all very interesting. In my past life, over several years, I was responsible for hiring Java developers, but the issue of cheating on resume was never my biggest concern when finding qualified employees. Any inconsistencies/discrepancies usually surfaced early during interview, conversations, follow-up assignments and through careful profiling of candidates. As for documentation, on occasions, I asked to see college transcripts of somebody who claimed to have had exceptionally high GPA. But perhaps I was naive and only very lucky to have hired some great people, and perhaps there are some really skillful java con artists (actors) out there. I have never met one though!

Cheers,
M
At the risk of sounding obtuse, really what is the big deal about the "published credentials"? I would imagine that indicating your SCEA status on your CV/Resume is sufficient for the purpose of employment seeking. Your certification status is after all easily verifiable, I would guess by doing a screen print from results database, or showing off the paper certification Sun sends us, etc.. I certainly do believe that SCEA certification is a great accomplishment, and I am not trying to diminish it at all (in fact that's why I'm studying), but I really don't get the idea of published credentials at all. Perhaps it's the cynic in me! Or is there maybe some special magic touch that Sun applies in the process of publishing credentials? Is it especially pretty, shiny, or otherwise attractive looking? It seems that Sun thinks so... Hence the price. Could somebody enlighten me what I would miss if I chose not to publish my credentials? I'm relatively new here, so I don't quite get it I guess

Cheers.
As I'm thinking out loud and talking to myself , I can see one more twist to this analysis. The CEO said in the interview they had four turbojets. Implicitly, these are usually smaller cramped airplanes, and it is very unlikely that anybody would offer first class seatings on such planes. As a consequence, a particular Equipment on a particular Flight (looking at the Business Domain Model diagram again), may or may not have two classes. Some Equipment must have only the "coach" class. It depends I guess.
Good point about the class. The 'Price Itinerary' use case is woefully incomplete in a sense that it does not explicitly state that the pricing model is also based on classes. In fact not a single use case mentions anything about the class concept anywhere (a major omission!). Only in the interview w/CEO/CIO, we learn that these 2 service classes exist: "first class" and "coach". As you correctly said, extending the business domain model, a class must be associated with a seat 1-to-1 (an assumption based on common knowledge, not stated explicitly in req's).

Personally, I am thinking I would not try to complicate our analysis by injecting the class pricing into that unfortunate muddled statement that started this thread. But if you look at the the basic flow of Prepare Itinerary use case, the first sentence should have had the customer selecting the class -- together with all the other things (departure city, time, date, etc.). Again, my assumption here must be based purely on a common-sense domain knowledge and the end-user reasonable expectations of online ticket reservation systems. So, once the user initially selects the class (and all the other options), the system should only build, and display, the itinerary based on these initial customer choices.

Hey, do not worry about not flying planes! You are lucky in Europe you guys have outstanding and efficient inter-city train transportation system (in US there's nothing like that). And much of "train-to-plane" reservation system concepts should be quite portable, I think.

Cheers!
M
I agree, it is very good to discuss the problem domain, as long as Andrew doesn't jump in and cuts down on all the fun. But I think we are still good.

Anyway, the more I read and think about Part II, the more I see that they (Sun) have purposefully introduced a lot of ambiguity, uncertainty and incompleteness into the assignment. All we can do now is assume, assume, assume. Then justify. In my mind, I have decided to prioritize certain conflicting information in the following way (from highest to lowest):
(1) The Diagrams: Business Domain Model and Use Case Diagram.
(2) Four detailed use case descriptions.
(3) Interview with CEO/CIO.
I am not saying that I am going to disregard what the two big kahunas are saying. But I am going to look at that interview with a grain of salt in the eye. Of course I might be completely wrong, so be it.

Cheers!
Yep. I can see the dilemma. I have just been thinking about it myself, and here is my attempt to analyze and reconcile the seemingly conflicting or ambiguous requirements.

1. CEO/CIO interview says the following: flat prices per destination and per class.
2. But the Use Case to Price Itinerary says the following: price each segment of the itinerary and add the prices together to come up with the cost.

These two conflict! The problem I think is the imprecise vernacular used by the two sources of information. Number one says 'destination' and number two 'segment'. I tell you the way functional requirements are elicited is more an art than a science and almost always requires many follow-ups... which we cannot do here. Myself, I am going to assume in my analysis that the CEO really meant to say 'segment' when he blurted out 'destination'. My feeling is that the use case documentation (number 2) is slightly more strict and trumps the interview which seems to me a rather loosy-goosy single exchange... I would also think that the "Business Analyst" (presumably a specialist in the field) must have done many of such interviews before writing the use case, so it should be more accurate.

To sum up, I assume that each segment indeed has a flat price, but not necessarily the final destinations (unless it comprises just one segment). Without making this assumption, I cannot see how I can submit the part II -- and I really would like to do that.

Let me know if my thinking makes sense to you, or not.
Hi Marcel,
Don't know if you found the answer yet. I have also found that statement ambiguous (I presume this is all done intentionally by Sun). But the good news is I found good discussion and clarification in this old thread.
Hi Tanveer,

Here's my thinking: I believe you should start your BDM analysis with the Itinerary, because the Customer first gets the Itinerary not the Flight. So in the example you just proposed above, the Customer's Itinerary would consist of 3 segments: A->B, B->C, C->D. Each one would be given an individual Flight number. These associations might seem rather strange to us and might not necessarily be the common business practice in any real-life airline reservation systems. But that is an assignment we've been given, and I do not think we should attempt to read between the lines or make any other unwarranted assumptions. (And I suggest you forget about a "leg" because that concept is undefined here.)

Cheers,
Marcus
[ February 11, 2008: Message edited by: Marcus Jastrebowski ]
I am planning to take SCJP 5.0 (310-055) soon. I thought that I had read somewhere within this vast forum that there were problems with the Drag-and-Drop (D&D) questions on the real exams at Prometrics: Some people reported that when any previously answered D&D questions were being re-opened for review, then the previously submitted answers were lost.

Could anybody please confirm that this behavior continues to be a problem, or has this bug been resolved and fixed?

Thanks much,
Marcus
LATEST UPDATE:

All is good now. I got a nice email reply from Whizlabs containing the license activation key... Apparently, there is some order order processing delay, but otherwise Whizlab support is quite efficient replying to support email inquiries. Very nice.
I have purchased Whizlabs 5.0 preparation kit about half an hour ago and made an instant payment with PayPal (got a receipt). I was expecting to get the license number immediately but this did not happen. I did not receive any confirmation email. I have sent an email inquiry to Whizlabs, and I am hoping for some reply soon so that I can activate my trial version. (I am located in US.)

I wonder if anybody else has had any problems with getting the license (activation key) from Whizlabs? Any ideas?
I am having a problem clearly understanding the difference between nested versus inner classes. One example explanation I have seen in K&B is that static inner classes are actually nested classes. Hmm... But, my problem here is that the words "inner" and "nested" seem (to me) like virtual synonyms -- hence my confusion with the Java terminology.

Could someone clarify the distinction between these two -- as it applies to Java? And why is such distinction being made at all?

Thanks,
marcus
[ December 11, 2007: Message edited by: Marcus Jastrebowski ]