Scott Shipp

Ranch Hand
+ Follow
since Mar 31, 2013
Scott likes ...
Eclipse IDE IntelliJ IDE Java Scala Ubuntu
Cows and Likes
Cows
Total received
12
In last 30 days
0
Total given
0
Likes
Total received
26
Received in last 30 days
0
Total given
29
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Scott Shipp

One alternative might be to implement an equals() (or deepEquals?) method in RumbaLabel that compares all the fields you care about and just check that partnr is equal to an instance of RumbaLabel with those values. The problem with such an approach, though, is that it would move visibility of what exactly is different out of the test, so I wouldn't recommend it.
2 days ago
It's because the underscore is a substitute character for a comma. It's easier to read long numbers when they're broken up. 123456789 is less readable to humans than 123,456,789. I think it was in Java 7, they allowed underscores in numbers to make larger numbers like this more readable. "1_234_" is therefore the same as writing "1,234," which is not a valid value. The compiler is trying to be helpful and indicate this. Just think of it this way: if you replace the underscores with commas, is it a valid number that makes sense? Otherwise you'll get the illegal underscore message from the compiler.

So minor nitpick: you can have more than one underscore, if your number still makes sense: e.g. 1_234_567 would be valid.
4 months ago
Wow! I never even thought of the naming of RuntimeException. That's pretty funny!
4 months ago
The way I think about dependency inversion is that it's more about whether your code is hardcoded against a concrete dependency (like a specific model of printer or a specific file system), or if it instead inverts this relationship and becomes itself dependent on an abstraction of the concrete dependency.  That sounds kind of confusing so think of it this way: you send a daily email with the day's total sales. So you write code that does a lot of stuff against "EmailSystem" and the code is completely dependent on email. Next, the boss decides she wants to get the day's sales total text message summary each day instead. What do you do? Copy/paste the code and find/replace "EmailSystem" with "SmsSystem"?

!No!

You instead make the code depend on an abstraction like "MessageSystem" and you supply a concrete implementation for each instance. The code is more resilient to change now, and when the boss decides now she wants to get it via a REST API call to her Internet-of-Things appliance in her house, you've got it covered.

So I'd look at things like InputStream or Writer as Java library interfaces that facilitate dependency inversion.
4 months ago
Was the question stated exactly this way? The class names given don't even follow standard Java conventions. I'd personally avoid the company from here on out if that was an interview question given to me.
4 months ago
Hey Mark, If your goal is to learn better problem solving skills, what if you dispensed with the languages altogether? I think you may only need a pencil and paper (or a whiteboard and marker) and go solve those problems without the overhead of the language at all. Use pseudocode as necessary. When you're confident in your solution, then come back to the keyboard and code it up and see. This approach has always worked better for me.
4 months ago
This would not be unlike the Singer, Songwriter, SingerSongwriter example in Effective Java, item 20. What Bloch says there would be applicable, and he's basically saying that you should use interfaces for Player and Coach, then if necessary, your "PlayerCoach" could implement both interfaces.
4 months ago

S Fox wrote:I have a class that I made which is like a custom data-type, and I'm trying to figure out how to tell java what makes each object unique for the purposes of adding them into a Set? Right now it's just adding everything.
I wanted to compare the objects by a String "name" for deciding the set membership.



Check out the information at the below links. Hope it helps

Java Trail: Object as a Superclass

Deep Dive (with a video)

Why you must override hashCode if you override equals

Helpful Stack Overflow discussion

4 months ago
Hey everyone the ebook is out now on informit.com. Print copies are supposed to ship on 12/29 and can be pre-ordered now.
4 months ago
Hey out there,

I am looking for book recommendations for books that cover practical mathematical and statistical methods for estimating, planning, etc. related to backend services. Let me know if anyone has recommendations. Something that covers topics like capacity planning, monitoring thresholds, queuing theory, etc.

One recent use case I had was to determine a good queue size for a service in a distributed system. I used a variation of Little's Law to figure out how certain queue sizes would impact a particular use case and come up with a range of milliseconds response time that downstream systems would have to have in order for us not to reject messages.

I have searched a lot online the past couple days and there are a number of books falling in this description, but its really hard to figure out if a book is just going to cover hard theory or if it actually demonstrates how to apply the theory in the field which is more of what I'm looking for.

Scott
4 months ago

Paul Clapham wrote:...maybe you could call that "recovering" anyway? I guess my point is that when an FTP exception happens, then having the application end abnormally isn't our preferred outcome. We would prefer to note that the exception happened, perhaps do something differently, but at any rate we want the application to continue on in a normal way...



Junilu Lacar wrote:The main thing to watch for, IMO, is copping out or worse, being lazy about checked exceptions. If you automatically wrap a checked exception with an unchecked exception and throw it back upstairs, then you have to ask if that's the right thing to do or if you're just being lazy and doing it for the sake of short-term expediency at the cost of long-term robustness of your design.



Paul / Junilu  --- I think the examples you give point out something really insightful which is that exceptions are very case-by-case. The Bill Venners article gives examples from the standard library that show exceptions being used quite differently, but they all make a lot of sense in context. So maybe the reason it is hard to come up with a general rule is that a general rule isn't very helpful and common sense needs to guide you?

Junilu Lacar wrote:Scott Shipp... you wouldn't happen to be the author of this article, would you? Just wondering because I had a discussion just in the past few days with someone off-Ranch about what you wrote there. Nothing bad, I assure you. The guy I was talking to was thinking about expanding on some of your points and he and I had a discussion about working on a follow-up article together.



Ha! Guilty as charged. It was inadvertently a polarizing article, which isn't what I intended at all, but there's a fair criticism in there. I now see that I started the argument wrong and half the people who read it didn't get any nuance out of it, just "don't use getters and setters." I also am planning a follow-up article at some point, about access modifiers and why I think the big jump from package-private to public in Java allows (maybe even encourages) essentially procedural style programming. The anemic domain model article from Martin Fowler is pretty near to what I had in mind when writing that one and maybe one day I can hope to learn how to express things as well as he does.

5 months ago

Campbell Ritchie wrote:Please give us a link to that article.



Sorry about that. I thought I had linked it but it looks like I somehow linked wrong. Here's the article on DZone.
5 months ago
Recently I read Grzegorz Piwowarek's article Java 8 - The Bad Parts which brought up the yuckiness of exceptions in streams. About the same time I saw a comment from Lukas Eder that the java community is unanimous that checked exceptions should be removed from the language (which is news to me). At the same time, I had a weird bug to fix at work where I found a checked exception being used for normal error handling (bad user input). To fix my story at work, I moved from a checked to a RuntimeException, since I reasoned that it is similar to an IllegalArgumentException. (Just that the illegal argument is passed in via a REST api).

But it all sent me down the path of re-reading some of the old checked vs. unchecked exceptions articles from James Gosling, Bill Venners, Brian Goetz, et. al. I actually got more confused and muddied as I revisited something that I thought I was fairly confident in.

My general rule has been something like:

- If I can imagine that the calling code can do something to recover from the error condition (besides retrying the same thing again!) and the error condition is reasonable to anticipate, then use a checked exception
- All other scenarios, use unchecked

I wonder what you all think about when to use checked vs. unchecked exceptions?
5 months ago

Stephan van Hulst wrote:It would be silly for a utility class for array operations, not to work on arrays.

String is an extremely low level data structure. It's not a good example of a high level application API.



So, my apologies, but I'm getting more confused. It sounds like the advice in question is actually centered on "public," "high-level" API's? Because at first you seemed to indicate it didn't matter if they were public or private, just a blanket "Don't use arrays in method signatures or return types. Use collections." I immediately thought of the examples I gave and wondered if you thought they were bad.

I'll throw in another fascinating topic. A lot of experienced developers actually say don't use collections, use specific / custom objects. Some of us are old enough to have lived through the introduction of List instead of Vector and HashMap instead of HashTable. We lived through the introduction of generics in Java 5. All of our APIs became screwed up, specifically because we used Java collections in them. Actually, now that I think about it, had we used arrays, we wouldn't have had the same problem. But nevertheless, advice I would give is to hide the fact of whether you are using Arrays, Vectors or Lists, and expose only the behavior you want the client to use through an object.

Another fascinating digression on this topic would be to consider the discussion in Item 25 of Effective Java centered on the differences in covariance and invariance between objects and arrays.

Personally, I feel that the space is too complex and there are too many nuances to issue any blanket generalities about using arrays or objects in method signatures. It takes a careful software craftsman to consider the context and make a (hopefully) wise decision. In the given example from the OP, I personally don't object to his use of an array there.

10 months ago