Jelle Klap wrote:Aw, the only limericks I know all star a man from Nantucket...

I know a few of those too. All comical, none clean.

Amazing! What a treat!

I would absolutely love to go to Devoxx. However, I have a couple of practicalities to get in order before I can officially accept the ticket so keep your eyes peeled here on Monday just incase I can't make it and it's offered up to the next worthy winner.

Happy Days!!

Thanks Jaikiran, I figured it'd be something like that. I've updated the Wiki with the rules.

Cheers
Tim

Howdy folk,

I stopped by the competition Limerick thread this morning to dish out some cows for my favourite poems but it turns out I can only grant one cow per day! I had to revoke a cow (sorry Fred) so I could grant it on my very favourite limerick.

Is this one cow limit just a Rancher thing? Or is it for all user types? Either way we should document it, which I'd be happy to do of course.

I'm assuming that you have consulted Google before arriving here? What have you found so far? What have you tried out?

Matt Kidd wrote:the depth and breadth of what Java can do is virtually anything

That is pretty much true. So the question you need to be answering is "what does your company need Java to do?".

It would be interesting for you to learn the reasons behind this already made decision to go with Java. As opposed to say C#, Ruby, Scala, Erlang, Python, or <insert other favourite language here>. A conversation has already taken place that has concluded with "Okay so that's settled, we're moving to Java because.....". You need to find out what that "because" part was.

You need to know who your audience is, you say "everyone else" but who are they? Sys Admins? Sys Support? Sales? HR? Directors? BAs? Middle Management? Window cleaners?
You need to know what questions that audience are hoping to get answered by attending your session.

When a company is recruiting they are not just looking for someone who can do the job advertised. They are looking for someone who they think will fit into the culture of the company, i.e. someone they think the existing team members will get on with. Unfortunately if I received your resume that exhibited the kind of attitude you're putting across here I would likely file it in the bin. As much as you may dislike the "game" of recruitment and job hunting, if you want to win then you need to play it to a certain degree. If your attitude is "This HR recruitment stuff is nonsense, this is me, take it or leave it" then I'm afraid more often than not people will probably leave it.

(a side note: J2EE hasn't been called J2EE in over a decade. It's called Java EE now. Be careful not to make your experience look irrelevant by careless naming. Unless of course your experience was in the late 90s / early 00s then calling it J2EE is perfectly valid)

Edit: Grammar fail

Fred, I take your horrible code and I raise you this little gem:

The choice of names confuse things significantly.

Scott, some of our team would be a bit young to get that reference. One of my colleagues didn't even know who John Cleese was! I nearly went home in disgust (it was 10am).

Dieter, that's brilliant! I'm sold on the Honey Badger of Badass Practice (of Badassness?).

Perhaps complement it with a regular Badger of Buffoonery.

Jelle, I understand your viewpoint on this and would not be looking to assign "blame" in a malicious manner. As you say, that would be terrible for moral within the team. Taking your example, if you had a naff and flakey system that just failed for the craic at seemingly random intervals for no good reason then I don't think it would be fair to start finger pointing if you happened to be the last person to touch it. That would suck. I've worked with that sort of system too.

I'm intending to use the 'mascot' as just a bit of a laugh for those really silly mistakes we all make. Things like "this & that" when you meant "this && that", or the old favourite "thisString == thatString" instead of "thisString.equals(thatString)".

Dieter Quickfend wrote:I believe you are thinking of an integration test.

Not in this example no. The "Unit" in my test is a collection of classes that work together to perform a single function. It would become an Integration Test if I were to actually send that message over the wire using Tibco to some other machine or process. But in this case I am not, so I'd still call it a Unit Test.

I think of "integration" as an interaction with some system outside of the application. Things like a database, a web service, an external message system, pretty much anything that requires a separate system to be up in order to operate. I do not necessarily consider the interaction between two classes an integration point unless it represents a communication between two logically different parts of the application, although in that case I might term it more of an "end to end" test.

Call it whatever you like really. If it works for you then go with it.

You could encapsulate that rule out easily enough in a couple of ways. If you only need that rule inside this particular class then you could extract it as a private method like so:

Of if you're going to need that rule to be available to other classes then you can extract it into it's own class like so:


Getters and setters are mutation and access methods that simple get or set the value of a class member. Your method that decides whether some int is less that 6 is not a setter or a getter, it's just a function.

In a program where you want to do something "once or more" times then you'd use a do/while loop. So to ask the user for the pencil length repeatedly until length is greater than 6 you'd say:

Of course I am expecting an int to be entered and am making no attempt to handle any other type of input.

Alternatively you could use a combination of a monospaced typeface with some "&nbsp;" For example the following BBCode

[tt]
&nbsp;&nbsp;&nbsp;&nbsp;1
&nbsp;&nbsp;&nbsp;&nbsp;2
6 7 3 8 9
&nbsp;&nbsp;&nbsp;&nbsp;4
&nbsp;&nbsp;&nbsp;&nbsp;5
[/tt]

gives you:


    1
    2
6 7 3 8 9
    4
    5


It's a bit clunky and horrible to write in the editor. But it does work.

You need to provide a return statement for all termination points out of the method. In your example you have not provided a return statement for when the if condition is false, i.e. OffOven is not less than 3.


As a side note: Java coding convention has method names and variable names as camelCase. So your syntax should be:

Joanne Neal wrote:Kudos to Tim Cooke

Thanks. This is a lot of fun.
I'm also taking full advantage of the fact that nobody said you can't enter more than once....

Great stuff so far. Keem 'em coming!

(Added flags for shameless promotion of my own thread)

I'm not suggesting that this is the right solution, but that site is done using Joomla. Using a CMS (Content Management System) might be a consideration if you're not savvy enough to build one completely yourself. Be aware though that CMS's are not without their limitations.

Another development team in my office have a "Beaver of Technical Incompetence", a soft toy plush beaver, that they assign to any dev in their team that does something a bit daft. It's all done in good humour of course and is the source of many a good laugh.

I think it'll be good fun to introduce something similar into our team but I can't think of what thing to use as the 'mascot'. Perhaps even have two mascots, one to be awarded for doing something good, one for doing something silly. Animals are a favourite because it's easy to buy a soft plush version of it, but it can be anything really as long as I can find something physical to represent it. I'd like to have something that sounds funny in itself but I can't think of much. "The Badger of Brilliance", "The Ferret of Foolishness". You know, that sort of thing, but better.

Suggestions welcome. May your imagination have no bounds.

I'd start with the Solr mailing list and IRC channel http://lucene.apache.org/solr/discussion.html

PM = Purple Mooseage (the Ranch's version of a Private or Personal Message). Check at the top of the forum page (or bottom if you're on a mobile device) for "My Purple Mooseages".

A particularly 'special' thought process has gone into that snip of code.

Sometimes the forum gets spammed and a Mod will delete the post. It looks like this is the case in this instance. I've seen this happen before a few times.

Why not start at your current company? Talk to your supervisor and tell him/her about these things that interest you. Perhaps there's some opportunity to learn about them there.

Vinod, that doesn't have to be the case. There could be multiple main methods in a single java codebase.

Monica, if you have multiple main methods then you have multiple entry points into your application. You now have the added complexity of understanding why that is and what each is for.

I'm glad you've solved your own problem. In the interest of sharing and making the most of this thread I invite you to run through what the problem was and how you solved it?

Yes it does. But this actually happens.

In extreme cases the compiler optimisation Mike mentions may bring about undesirable results. Say we have a loop in our code that is spinning waiting for some other value to change:

On the face of it this loop will spin until ref.getVal() returns something other than zero. But let's say ref.getVal() returns 0 tens of thousands of times in a row. The compiler optimisation will shortcut this loop to

At runtime the code is no longer looking at ref.getVal() at all so if it ever changes our code will not see it.

Granted the chances of this issue coming up in general development is very very low indeed. But it's an interesting consideration nonetheless should you be writing code that does this.

The line between what we call a Unit Test and an Integration Test is often difficult to identify. Let's take the example you give where you're writing code that reads and writes to the file system:

When writing a unit test for this I don't really want it to actually touch the filesystem because it's slow and there might be permission problems on the current platform which then leads to flakey tests which fail sometimes and not others. So in this case you can do as Dieter suggests and work with an OutputStream (mockable interface) rather than File (un-mockable final class). Or I think there is some library available that gives you an in-memory representation of a file system which allows you to actually read and write quickly in your tests. (I can't remember what it's called, sorry)

You're also going to need an Integration Test to verify that your code does actually write and read the file to and from the real filesystem. For this you're going to need to make sure the environment is set up correctly with directories created with correct user permissions granted on them.

Unit tests need to be quick as those are the ones you run repeatedly all day long on your local development environment. Integration Tests are run less frequently, once a day perhaps, and are run in an environment that is as close to production as is feasibly possible.

Mike makes a bunch of really valid points here. Although I have to disagree with the following statement from Dieter:

Dieter Quickfend wrote:A Unit test will never use real other classes. All dependencies are mocked. If a unit test uses other classes, it's not a unit test, it's an integration test

That suggests that the hard definition of a "Unit" in a Unit Test is a single class.

I think the definition of a Unit is a bit more flexible than that. I see it as a logical unit within your application which may consist of a single class or multiple classes. For example, the product I develop at work has to publish messages on a Tibco bus. So I have a "unit" that takes a message in the format of our domain model and translates that into a Tibco format to be sent down the wire. My Unit Tests here will be to ensure that if I put in domain object A then I get out Tibco message B. As it happens there are a handful of classes and things in the middle that actually make that happen but I do not necessarily have any unit tests for those individually. My "unit" in this case is the code that translates the message from format A to format B. I don't really care at this point how many classes are involved.

The purpose of having unit tests in your code is to give you the ability to refactor safely. In my example above, I am now free to completely change how I implement building those messages but as long as my tests pass then I know I'm building those messages correctly. If I had unit tests around each individual class in there with Mocks for every interaction with other classes then I would be encasing my code in concrete. I'm now writing tests to specify the implementation. I don't want that. I want tests to specify the functionality.

Only way to know for sure is to fire it up yourself and see if it runs satisfactorily. Any response you get here is going to be at best an educated guess, at worse a wild stab in the dark. Unless you get really lucky and find a developer who has been too tight to buy new hardware inside this millennium. (Quite unlikely that last one)

Far too generic. We'll end up with a huge single topic with multiple refactoring discussions in it. How would that be useful? How would you search it? How would we talk about it? "Oh that particular refactoring was discussed in the 'Refactoring' topic on page 74". It's just not manageable at all. It's akin to saying "Shouldn't we put all our code in main? It's all just code after all right?"

I agree that discussing refactoring is a valuable thing to do but we should do it one problem at a time, one topic at a time.