The Joys Of Programming

Dr.Ghastly wrote:

Oracle is killing Java.

Sure, but I haven't that stop anyone from using it. I'm not taking a stance for any kind of language wars, simply saying I haven't seen it get any less popular.

How is Java UI these days?

Our parent company develops a Java app and the UI is just plain bad.

SixteenBlue wrote:
Dr.Ghastly wrote:

Oracle is killing Java.

Sure, but I haven't that stop anyone from using it. I'm not taking a stance for any kind of language wars, simply saying I haven't seen it get any less popular.

Oh I know I'm just saying Oracle buying Java was the worst thing to happen to the platform.

Dr.Ghastly wrote:
SixteenBlue wrote:
Dr.Ghastly wrote:

Oracle is killing Java.

Sure, but I haven't that stop anyone from using it. I'm not taking a stance for any kind of language wars, simply saying I haven't seen it get any less popular.

Oh I know I'm just saying Oracle buying Java was the worst thing to happen to the platform.

Very likely.

Quintin_Stone wrote:

How is Java UI these days?

Our parent company develops a Java app and the UI is just plain bad.

Honestly, I haven't done desktop UI in 4 years or so but it wasn't great then. I doubt it's much, if any, better now. Our UI wasn't bad, but it took a lot of annoying work. .NET crushes Java there.

Yeah, their Java app side-by-side with our slick WPF is just... embarrassing.

I've forgotten why they/we are moving towards .NET. I remember it seeming a valid reason when I asked. I like .Net. I like Java. I love Visual Studio, especially for creating UIs. I loathe Eclipse with the heat of a thousand hot suns. For anything.

Language choice is not that important to me. I'm really looking forward to getting into TDD, Agile, CI, and they're using some cool data store that's not tabular. I think he said it's a columnar data store, which allows full database analytics without precalculated aggregates. I think.

Can't wait to start!

Yes, Visual Studio >>>>> Eclipse.

I was finally getting around to self-congratulation as well. Sorry Ducki, not trying to steal any thunder.

I got a new job about a month ago here: http://www.nebraskaglobal.com/

No phones at developer desks. REAL project managers. Estimates that include time for UNIT TESTS AND REFACTORING (more on that in a sec). Stocked kitchen. Unlimited vacation policy. Great benefits.

One of the things we make is this: http://eliteform.com/

However, I am not working on a cool project like that. I'm currently developing a run-of-the-mill mobile web app for a contracting client.

But.... I'M BUILDING IT IN .NET AND VISUAL STUDIO NOT PHP OH THANK GOD!

I missed you C#. I missed you Visual Studio. I missed you intellisense. The whole shop is completely Microsoft. I have my issues with Microsoft, but when someone is footing the bill for good machines, current software, and maintaining a solid infrastructure, it can make for a very nice place to program.

I never wrote a unit test before this job. I am now REQUIRED to write unit tests in conjunction with every method. It can be hard. It can be slow. It can be VERY inconvenient, but I'm probably writing the best software of my life, even if the project itself isn't really cool.

We architect our software according to the IDesign methodology outlined here: http://channel9.msdn.com/Events/Tech..., using WCF and Service oriented architecture. This can also be hard, and slow, and inconvenient, but it really keeps code organized and manageable.

I can't even begin to describe how much information has been dumped into my brain this month. I'm kind of worried I'm going to go in one day, and they're going to realize I'm and idiot and tell me to hit the bricks.

I am starting to think that unit tests are not a good thing. I am glad that all these new jobs are requiring it, but in the past 3 years, I have yet to be on a team where people know how to do a unit test. Most unit tests seem to be integration tests that go to databases and other services and take 30+ minutes to run (which means nobody runs them and they are never at 100% success). Maybe I have just had a string of bad luck, but I hope that these jobs you have aren't going to be the same.

Lex Cayman wrote:

I never wrote a unit test before this job. I am now REQUIRED to write unit tests in conjunction with every method. It can be hard. It can be slow. It can be VERY inconvenient, but I'm probably writing the best software of my life, even if the project itself isn't really cool.

The reason I mention this is because of what you said here. Unit tests are not hard. Writing them is not slow. They actually speed up development since you have less defects later in the development cycle and help define when you are "done". But the key is making sure that they are unit tests (testing a unit of code, not multiple units). Integration tests are hard and slow. I am not familiar with .NET but in Java I like to use Mockito as a mocking framework which makes it really easy to mock external method calls. Hamcrest is a really nice assertion framework too.

Quintin_Stone wrote:

Yeah, their Java app side-by-side with our slick WPF is just... embarrassing.

Babytown frolics?

Unit tests are not a bad thing. Crappy devs writing unit tests are. But crappy devs writing any code is a bad thing. Just part of the industry sadly.

One thing my team *must* do is write good unit tests. Unit tests are code reviewed like other code. Using the database as part of a test is verboten; all entity objects and data access objects are mocked. We use Mockito and Powermockito (sparingly) along with JUnit for all server-side code, QUnit is our Javascript test framework called as part of our build process using the qunit-maven plugin. Tests for a project must all pass; the CI server will reject a build where the unit tests fail. Having a build fail because of a failed test is shameful and the devs know it and make sure it does not happen to them (usually). We use Sonar to track test coverage in the Java code, projects/modules that fall below a certain percentage get extra love and care to get that number back up (depends on the project/module but we shoot for approx. 80-85% coverage, more seems like diminishing returns). The tests must run fast and must be part of all builds; I am sure some of my folks circumvent this for day-to-day stuff but they know they will feel the wrath of God if they screw up and check in a pom that circumvents the tests.

I am not dogmatic about most stuff, but I am about unit tests. New devs who come on board sometimes chafe at first but the very first time it saves their bacon, they usually get it. If they don't I either try to educate them or I get rid of them if they are recalcitrant. But I try very hard not to hire devs who don't already know the value of unit tests.

Generally, unit tests have to be ingrained into the culture of the company in order to be successfully utilized. If they are not valued then there is little reason to even bother writing them. I figure we pay an overhead cost of approx. 1.25x normal project time for doing unit testing. It costs time to write and maintain unit test code but we save time in fewer defects during a QA cycle, so the cost is not prohibitive in my opinion. And we end up with better code so the next crazy thing the business dreams up to shove into a product is easier to implement with lower risk. And that is the bottom line: a code base without unit tests is riskier to work with.

tboon wrote:

(sweet nothings)

It's nice of you to flirt with me, but I'm married, man.

I have to write mocks for every unit test. I can't tell you how many times I've heard "If you don't have a mock, then it's actually an integration test."

I've also found it's a heck of a lot easier to test and debug a piece of code by running the unit test over and over than firing up the whole solution, clicking my way to the point in the app where the functionality gets used, stopping debugging, making a change, and doing it all over again.

kazar wrote:

The reason I mention this is because of what you said here. Unit tests are not hard. Writing them is not slow. They actually speed up development since you have less defects later in the development cycle and help define when you are "done". But the key is making sure that they are unit tests (testing a unit of code, not multiple units). Integration tests are hard and slow. I am not familiar with .NET but in Java I like to use Mockito as a mocking framework which makes it really easy to mock external method calls. Hamcrest is a really nice assertion framework too.

Unit test can be hard and slow if you've never written them before. My first 20 tests were very hard and slow, the last 40 have gotten progressively easier.

duckilama wrote:
tboon wrote:

(sweet nothings)

It's nice of you to flirt with me, but I'm married, man.

Aww, shucks.

Congrats on the new gig, by the way. Lex too. That should have been my lead.

tboon wrote:
duckilama wrote:
tboon wrote:

(sweet nothings)

It's nice of you to flirt with me, but I'm married, man.

Aww, shucks.

Congrats on the new gig, by the way. Lex too. That should have been my lead.

Thanks!
And congrats to you, too, Lex!

tboon wrote:

Unit tests are not a bad thing. Crappy devs writing unit tests are. But crappy devs writing any code is a bad thing. Just part of the industry sadly.

One thing my team *must* do is write good unit tests. Unit tests are code reviewed like other code. Using the database as part of a test is verboten; all entity objects and data access objects are mocked. We use Mockito and Powermockito (sparingly) along with JUnit for all server-side code, QUnit is our Javascript test framework called as part of our build process using the qunit-maven plugin. Tests for a project must all pass; the CI server will reject a build where the unit tests fail. Having a build fail because of a failed test is shameful and the devs know it and make sure it does not happen to them (usually). We use Sonar to track test coverage in the Java code, projects/modules that fall below a certain percentage get extra love and care to get that number back up (depends on the project/module but we shoot for approx. 80-85% coverage, more seems like diminishing returns). The tests must run fast and must be part of all builds; I am sure some of my folks circumvent this for day-to-day stuff but they know they will feel the wrath of God if they screw up and check in a pom that circumvents the tests.

I am not dogmatic about most stuff, but I am about unit tests. New devs who come on board sometimes chafe at first but the very first time it saves their bacon, they usually get it. If they don't I either try to educate them or I get rid of them if they are recalcitrant. But I try very hard not to hire devs who don't already know the value of unit tests.

Generally, unit tests have to be ingrained into the culture of the company in order to be successfully utilized. If they are not valued then there is little reason to even bother writing them. I figure we pay an overhead cost of approx. 1.25x normal project time for doing unit testing. It costs time to write and maintain unit test code but we save time in fewer defects during a QA cycle, so the cost is not prohibitive in my opinion. And we end up with better code so the next crazy thing the business dreams up to shove into a product is easier to implement with lower risk. And that is the bottom line: a code base without unit tests is riskier to work with.

This is basically where we're at with a few inferior aspects. We DO hit MongoDB in our unit tests right now. I was just talking to the other main dev on the project today about replacing that with mocks, but honestly I don't mind as it is right now. It's very fast. It's not ideal, but all of the aspects I want tested are still tested so I haven't complained.

We have code coverage metrics in our CI, but we don't actually enforce them. I keep any packages that I'm working on as high as reasonably possible, but it's not across the board.

I think I've written more unit tests in the last month than I have in my entire life. It's been great. Much love for Mockito.

Lex Cayman wrote:

I've also found it's a heck of a lot easier to test and debug a piece of code by running the unit test over and over than firing up the whole solution, clicking my way to the point in the app where the functionality gets used, stopping debugging, making a change, and doing it all over again.

This too. In fact, I use a test as my first way of running any new code. While it's not exactly test driven development it still forces me to build that structure right away.

Dr.Ghastly wrote:
SixteenBlue wrote:
Dr.Ghastly wrote:

Oracle is killing Java.

Sure, but I haven't that stop anyone from using it. I'm not taking a stance for any kind of language wars, simply saying I haven't seen it get any less popular.

Oh I know I'm just saying Oracle buying Java was the worst thing to happen to the platform.

Think how much worse it would be if Sun hadn't let the GPL genie out of the bottle before Oracle got their hands on it.

tboon wrote:

Unit test stuff.

tboon, I wish I was working on a team as you describe. If it were run like that, then unit tests wouldn't be bad. It is so rare to find a team that runs things like that. I have pitched everything you said to my team many a time and it always falls on deaf ears (I changed teams twice and cities once because they won't change and each new team has the same crappy unit tests). I am starting to think changing companies is the right answer.

I've been the unit testing and code coverage evangelist at work for the last year or so and it seems to be working. It scares me that people on my team used to say things like "I'm blocked on development because I can't get to my screen in the UI flow yet".

I don't do full test-driven development, but I generally interleave coding and tests - finish a class, then write the tests. 70% decision coverage seems like a good compromise to aim for.

After three days of trying to fix a bug, I found a note from a former co-worker in the code. "Since table and model are out of sync, it causes (exact bug we've been working on), but I don't have time to fix it properly, so I'll just catch it here."

http://www.youtube.com/watch?v=2uaPZ...

Zelos wrote:

I don't do full test-driven development, but I generally interleave coding and tests - finish a class, then write the tests. 70% decision coverage seems like a good compromise to aim for.

This is what I've been doing lately too. It works really well. Sometimes I'll break it down to even finish a method, write a test.

A contributing factor to bad tests is the 100% coverage movement.

You should put tests around significant production code. Things like presenter bindings, frameworks, databases, and very simple (1-2 line) methods (ex: CRUD operations) are extremely low value adds for unit tests.

My 2 cents

Agreed 100% . That's why we try for 80-85%, depending on the project, and not dogmatic about hitting a concrete number. It does make more work (mostly for me) to make sure that what needs to be tested is covered but better than having a bunch of BS tests lying around slowing down builds but adding little value.

I agree. Even my company is constantly pushing to keep track of test coverage and they accomplish a higher number by doing end to end "unit" tests. Then I find one of these tests is taking a minute to run so I delete the test and our coverage drops 5% and I get every manager on my floor coming to me asking why the coverage dropped so much. Quality unit tests never seem to be important, just the numbers.

This is a general problem since so much of what we do cannot be quantified. So we make up metrics. Back when I started in the late 80s, the metric was LOCs. I worked with one guy who consistently could churn out 2kLOCs/day. That 1.99kLOCs were complete and utter rubbish meant nothing.

Bugs found vs bugs fixed. Defects per line written. Test coverage. Lines of comments. Comment density. I've seen all these used as metrics for judging the "health" of a project. And they all were stupid because they were used in isolation. Metrics like test coverage are important but only in context of other things (LOCs are just BS, I'm glad the industry has gotten past that). Unfortunately, management does not (usually) understand the context, they just generally want numbers to look at and compare.

Enter Burn Down Charts.

kazar wrote:

I agree. Even my company is constantly pushing to keep track of test coverage and they accomplish a higher number by doing end to end "unit" tests. Then I find one of these tests is taking a minute to run so I delete the test and our coverage drops 5% and I get every manager on my floor coming to me asking why the coverage dropped so much. Quality unit tests never seem to be important, just the numbers.

Try explaining that a unittest should cover a general case and not several specifics that were caused by PMs running data through a system before it was fully bootstrapped.
Well, at least I'm not on that project anymore. They gave it to another team and the only sh*t I have this sprint is 'assisting the transition' to a team that virtually refuses to ask questions or attempt to understand why decisions were made. (Ending this before I get exceptionally ranty about this, I know the IRC peeps have heard enough)
Great.

People always seem to forget the cone of uncertainty.

I have been (and still am) fairly disgruntled about my workplace, because the company has been acting a bit boneheaded... but I will say that the past two days have been pretty fun, getting me into some nice new territory.

Yesterday: figured out how to correctly install a new cryptographic provider and not break its signed JAR when creating the shaded "fat JAR" that our Dropwizard web service runs out of. Also a nice installment in our weekly craftsmanship group, where one of our senior research-y devs showed off his outside project for a TRS-80 emulator.

Today: learned how to use Guice for method-intercepting annotations and for assisted injection (a.k.a. autowired factories). Once tboon helped me get past an initial hurdle with how to fit various frameworks together [thanks again!], I've found Guice to be elegant and powerful.

Also, if anyone does (or wants to do) pair programming, the ScreenHero app (OSX, Windows 7 and 8) is really quite wonderful. In short, it allows two people to share a screen, but each has their own cursor, and the "guest" can interact directly with a program running on the "host" computer (with some sanity measures, like restricting typing to one person at a time). No more passing the keyboard back and forth, no more pointing to the screen, no more telling someone what to type and getting them confused about spaces/hyphens/capitalization. Works with dual monitors, you can specify whether to share a particular window or a whole screen, and is free. It's not a do-everything app -- no voice chat, only one-to-one connections, etc. -- but for what it does, it's really incredible.