Bugger, now wishing I'd started my career a couple of decades earlier

That's fun Salvin. Quite difficult, but fun.

You say this is an assignment but you don't say what level of programming your class is for. The reason I ask is because it will give us an idea of how elaborate your solution is expected to be. For example taking into consideration lift speed in mph, acceleration, deceleration, emergency stop, holding doors open, etc etc each add extraordinary complexity to your system and make it very difficult to complete. I'm going to make an assumption that this is an introductory or maybe second year programming module?

If so then I'd recommend simplifying things as much as possible and model time in steps and your elevator as a sequence of states where the transition from one state to another takes 1 step of time. For example: Given elevators A and B and floors 1 to 10

Time	Action	Elevator A	Elevator B
0	Call to level 3	1	1
1	Call to level 4	1	2
2		2	3
3	Elevator B occupant selects 2	3	3
4		4	2
5	Elevator A occupant selects 3	4	2
6		3	2

In this example I have made up some rules:

Elevators move 1 floor per time step

Occupants take 1 time step to enter elevator and select a floor

Your rules may be different but this is how I would start thinking about it.

Personally I wouldn't bother meddling with the Collection and Map interfaces. You would suppose that if the Optional type existed from the start then it would be employed over returning null but the reality is that it didn't and the language designers value backwards compatibility enough that it is unlikely to ever change.

I use Optional quite liberally when writing classes that interact with a database or some other volatile data source where the absence of data is expected.

Maybe, Maybe not. Parallelism comes with an overhead so isn't always faster.

Do you know that a single threaded solution will be too slow? If so then how fast is fast enough?

I'm with Carey on this one, I doubt a custom multithreaded solution will gain you much, if anything. Personally I'd implement the most straight forward thing possible that works.

Also to back up Carey's question on the requirements. I expect 'multi-threaded/parallel way' isn't actually a requirement but perhaps performance is? If so you need to know what that performance requirement is. Maybe a single-threaded solution is plenty fast enough.

What is Dapp?

I have not read Jeanne and Scott's book so can't comment directly on that, but Campbell and I were among the technical reviewers for the Bert Bates and Kathy Sierra OCA 8 Exam Guide so we are familiar with the exam. My best advice to you would be to write code, write code, and write more code. Programming is best learned by doing lots of programming, so when you are working through the study guide write out every single piece of code from every example and try to run them all. Really get into why the answers are what they are, and also why the wrong answers are wrong.

Does the message provided in the compiler error give you any clues?

I would only consider applying a versioning strategy to the public API of your system as a courtesy to your users providing backwards compatibility. How you organise your code behind that API is entirely up to you so do whatever makes the most sense to you and the other maintainers of the code (if any).

I don't think you're going to get someone to do your work for you. Perhaps you could review your options and report back your findings?

What were the pros and cons of each?

Which ones did you choose for each platform and why?

Yes thank goodness. Although I do still hear on the local news regularly enough "a man is in hospital following an attack in [north|west] Belfast by masked men in what is being described as a paramilitary style attack". Which is daytime radio code for getting shot in the kneecaps.

A side effect of all this is that our local hospitals are leaders in the treatment of orthopaedic trauma.

Very cynical Campbell.

Here in Northern Ireland masked men historically have a very different vibe.

In order to have a preference about anything you need to have an understanding on what makes one thing better than another thing in your opinion. For example a person might prefer an Alfa Romeo car because they value aesthetics above all else and want their car to look beautiful to them, however another person might prefer a Volvo because they value practicality above all else. Both are right for different reasons, so long as you have your reasons.

So think about that in the context of code. What do you value most? Readability? Performance? Maintainability? Maybe something else?

Do you think you can choose a favourite now?

There are actually a couple of different types of error going on here. The first are syntactical as Campbell points out although the extraneous semicolon is the first of two such errors (check your parenthesise very carefully too). The second is a runtime logic error relating to your array that you'll soon uncover once you have the program running.

We have listed out many resources in our OCA FAQ page that will help you study and prepare.

No hoarding. In fact we've gotten it down to going to the supermarket just once a week, then round to the local for perishables such as milk, eggs, and fruit (and more crisps and chocolate).

Since we have to exercise social distancing I find that going to the supermarket is a lot like playing pacman. The dots are groceries and the ghosts are other people.

You have told us absolutely nothing about your application so it's near impossible to offer any reasonable advice.

I've never used Magento so have little to offer on that topic other than to say I know people who love it, but we also get a lot of spam on this forum about it, so I have mixed feelings for it.

I expect one of our fellow Ranch staff members will recommend everything by Jesper De Jong

My bad, I didn't pay close enough attention to everything you posted. I assume this code you're working with at least compiles? If so then Null is defined somewhere.

Do you have a field defined in that class called NULL? Or a static import perhaps?

Later == Never

Well done getting it to work!

You can also achieve it without introducing state. This is what I was hinting at before:

How pleased I am to have seen this. I have some 1-Wire equipment in my home monitoring temperature and my very hacky way of interacting with it is via a Telnet session using an Expect script. It works just fine so long as the stars align but otherwise it falls over, which it does at least once a week. Perhaps my Java will be better than my Expect programming.

Thanks for the link Paul.

I would heartily agree with Richard on this one.

In my experience I am yet to encounter a project using Hibernate where the choice to use it has turned out to be the right one, and anecdotal evidence suggests in a lot of cases it's chosen for convenient when projects are in their infancy. Unfortunately by the time the project matures to where Hibernate becomes massively inconvenient you're very tightly coupled making ongoing development difficult and frustrating.

Usually the programming language and design are tools towards some other goal, but what you're suggesting is that demonstrating use of the tools is the goal and the application largely secondary. I'd suggest asking yourself very seriously why you're doing it.

When I did my masters some years ago our department staff offered loads of suggestions that would help them in their research interests. Do you have similar available to you?

Thanks Richard,

Oh yes that Michael Feathers book has been well studied over the years, in fact I'd go so far as to say it's one of the most practically useful books about programming I've come across.

Well the problem with raw collections is that you're never quite sure what the types are for the key and value of a map. In fact the type is not defined until you put the first item into it.

Clearly the original author of your code is expecting the value to be of type ArrayList but in your scenario it isn't.

The challenge is to find where the first map put operation is made with the unexpected type of value.

Sorry I'm not following you at all.

Unsure what you're asking.

Can you explain simply what you want to happen? What is happening? And what you think might be going on?

Does it compile?
Does it run?

Hello there,

I learned quite early on that a significant part of being a professional software engineer is having the ability to understand, reason with, and improve upon other people's code. Do you cover that aspect of real-world software development in your book?

Thanks, Tim

What you have here are recursive calls that recurse every time you enter something other than "Y" and "N", and the final output prints the value returned from the ask_user() function. Are you sure you're always returning a value from ask_user()?

Welcome to the Ranch! I believe this is not your first rodeo as CodeRanch book promo authors, so I should say welcome back!

Having read back over this discussion I realise that Junilu already posted this as a solution. I guess the two of us arriving at the same destination makes me feel a bit better than it's the right destination.

I figured it out. Turns out the answer was on the very page of documentation referenced by the OP yesterday, just a little further on down Spock: Combining mocking and stubbing.

Mocking and stubbing go hand-in-hand:


When mocking and stubbing the same method call, they have to happen in the same interaction. In particular, the following Mockito-style splitting of stubbing and mocking into two separate statements will not work:


As explained in Where to Declare Interactions, the receive call will first get matched against the interaction in the then: block. Since that interaction doesn’t specify a response, the default value for the method’s return type (null in this case) will be returned. (This is just another facet of Spock’s lenient approach to mocking.). Hence, the interaction in the given: block will never get a chance to match.
Note
Mocking and stubbing of the same method call has to happen in the same interaction.

So the "correct" way to do it is like this:

Personally I don't think it reads that well and prefer the Mockito-style they say won't work. Interestingly this is the first time I've encountered something in Spock I didn't like, otherwise I think it's a very nice tool.

Even just removing the interaction assertion makes it work ok for me. Makes no sense.

I have reproduced this in the Spock Web Console http://meetspock.appspot.com/

Haven't figured out what's up yet, but I'm very curious now.

I'm going to need to try a lot of this out so my next reply is more than guesswork. I'll get back to you in a while.