The Joys Of Programming

Zelos wrote:
Edit: Ah, hrm, it looks like they did it because FolderBrowserStyles is a protected enum for some reason.

The only feeling worse than complaining about code and then realising it's actually correct is complaining about code and then realising it was you that wrote it ;-)

That's a good feeling! If you're not looking at old code you wrote and thinking, "ugh, I can't believe I wrote this" than you are not growing and learning. You might as well become a manager or executive. I'm always happy to find bad code I wrote, as it gives me a chance to practice my refactoring skills, which tend to be more useful than plain developing anyway.

Mixolyde wrote:
Zelos wrote:
Edit: Ah, hrm, it looks like they did it because FolderBrowserStyles is a protected enum for some reason.

The only feeling worse than complaining about code and then realising it's actually correct is complaining about code and then realising it was you that wrote it ;-)

That's a good feeling! If you're not looking at old code you wrote and thinking, "ugh, I can't believe I wrote this" than you are not growing and learning. You might as well become a manager or executive. I'm always happy to find bad code I wrote, as it gives me a chance to practice my refactoring skills, which tend to be more useful than plain developing anyway.

That's my approach too, although when it's code I wrote last week...not as happy.

SixteenBlue wrote:
Mixolyde wrote:
Zelos wrote:
Edit: Ah, hrm, it looks like they did it because FolderBrowserStyles is a protected enum for some reason.

The only feeling worse than complaining about code and then realising it's actually correct is complaining about code and then realising it was you that wrote it ;-)

That's a good feeling! If you're not looking at old code you wrote and thinking, "ugh, I can't believe I wrote this" than you are not growing and learning. You might as well become a manager or executive. I'm always happy to find bad code I wrote, as it gives me a chance to practice my refactoring skills, which tend to be more useful than plain developing anyway.

That's my approach too, although when it's code I wrote last week...not as happy.

Hey, you are just growing and learning really fast!

It has come time for my team to address some lacking areas in our test coverage, and one of them is our DAOs. Our current tests do exercise the full functionality of the DAOs, but the schemata for the tests are handwritten instead of using our Liquibase changesets. When we tried using our Liquibase changesets against the testing-only in-memory H2 database, we realized that there are still some rough edges in H2's compatibility with PostgreSQL (e.g. USAGE is not recognized as a privilege in H2).

I'd love to hear how other people have approached testing their DAOs; advice for my particular situation is most welcome. We're targeting PostgreSQL and would like to stay open to the idea of using some vendor-specific functionality (e.g. hstore data type). The DAOs are based on JDBI's SQL Object API. My current thoughts on how to improve the testing include
1) Run Liquibase changesets against a PostgreSQL database, then let Liquibase infer how best to create an equivalent H2 database by feeding it a connection to the fully-updated PostgreSQL database
2) Try HSQLDB in place of H2 and see if its compatibility is better
3) Run tests only against PostgreSQL but tune the server for testing (fsync and full_page_writes off, tablespace on ramdisk, whatever else it might take)

Bear in mind that this is just for continuous integration -- there would be a separate test run with a realistically-tuned PostgreSQL instance. Whatever the solution ends up being, it needs to be equally effective for local development machines and a central CI server (the latter being a potential source of frustration for option #3, unless the tuning is successful or we can somehow put multiple testing databases in a round-robin or something).

...

On a lighter note, here's a post that can't help but start an editor war: Just Use Sublime Text.

If you are running tests against an actual DB, then I would say that you don't need to unit test the DAOs. I would separate the logic of building your data objects from the SQL code so you could unit test that logic with mocks without testing SQL statements themselves. Then leave the rest to integration testing.

kazar wrote:

If you are running tests against an actual DB, then I would say that you don't need to unit test the DAOs. I would separate the logic of building your data objects from the SQL code so you could unit test that logic with mocks without testing SQL statements themselves. Then leave the rest to integration testing.

So you're suggesting that I just test my ResultSetMapper implementations and verify that they can build proper domain objects given a mocked ResultSet with acceptable values? I like simple options, simple options are good!

Cyranix wrote:
kazar wrote:

If you are running tests against an actual DB, then I would say that you don't need to unit test the DAOs. I would separate the logic of building your data objects from the SQL code so you could unit test that logic with mocks without testing SQL statements themselves. Then leave the rest to integration testing.

So you're suggesting that I just test my ResultSetMapper implementations and verify that they can build proper domain objects given a mocked ResultSet with acceptable values? I like simple options, simple options are good! :D

Yes, testing against a real database is an integration test, not a unit test.

Don't buy into the 100% code coverage hype either. I have found there is almost no value in unit testing the DAO layer. If it breaks, it's immediately apparent that it breaks, and it's almost always not a code issue (you forgot to apply a sproc, etc).

Spend time building integration tests instead... build up tear down valid data, and test your deployment scripts. More value there.

What's a good book/tutorial for backbone.js?
Also, Spring.
And GWT.

I have been semi-schooled by a job applicant with my brain-bender matrix search problem thing. Well, she hasn't proven the runtime yet, but she has given a very simple solution and I had to look at it and realize that even though I thought it wasn't linear, it is in fact linear. Doh! Now we'll see if she can prove it. If so, nice work! (She was a business major and a CS minor, so I suspect she may not be able to prove it formally, but she might be able to do better than "I think the worst case is ...")

TIL: 3^{log_2 N} = O(N) Duh. I should have known that.

Hypatian wrote:

I have been semi-schooled by a job applicant with my brain-bender matrix search problem thing. Well, she hasn't proven the runtime yet, but she has given a very simple solution and I had to look at it and realize that even though I thought it wasn't linear, it is in fact linear. Doh! Now we'll see if she can prove it. If so, nice work! (She was a business major and a CS minor, so I suspect she may not be able to prove it formally, but she might be able to do better than "I think the worst case is ...")

TIL: 3^{log_2 N} = O(N) Duh. I should have known that.

I'd love to see her solution after my insanely convoluted one. My boss actually figured out your solution pretty quickly, but my other senior engineers think I'm cruel for asking the question.

bandit0013 wrote:
Cyranix wrote:
kazar wrote:

If you are running tests against an actual DB, then I would say that you don't need to unit test the DAOs. I would separate the logic of building your data objects from the SQL code so you could unit test that logic with mocks without testing SQL statements themselves. Then leave the rest to integration testing.

So you're suggesting that I just test my ResultSetMapper implementations and verify that they can build proper domain objects given a mocked ResultSet with acceptable values? I like simple options, simple options are good! :D

Yes, testing against a real database is an integration test, not a unit test.

Don't buy into the 100% code coverage hype either. I have found there is almost no value in unit testing the DAO layer. If it breaks, it's immediately apparent that it breaks, and it's almost always not a code issue (you forgot to apply a sproc, etc).

Spend time building integration tests instead... build up tear down valid data, and test your deployment scripts. More value there.

Depends on what you include in your DAO layer. Though if you have anything really worth testing in there it might be time better spent refactoring that out of the DAO rather than unit testing it.

Bonus_Eruptus wrote:
Hypatian wrote:

I have been semi-schooled by a job applicant with my brain-bender matrix search problem thing. Well, she hasn't proven the runtime yet, but she has given a very simple solution and I had to look at it and realize that even though I thought it wasn't linear, it is in fact linear. Doh! Now we'll see if she can prove it. If so, nice work! (She was a business major and a CS minor, so I suspect she may not be able to prove it formally, but she might be able to do better than "I think the worst case is ...")

TIL: 3^{log_2 N} = O(N) Duh. I should have known that.

I'd love to see her solution after my insanely convoluted one. My boss actually figured out your solution pretty quickly, but my other senior engineers think I'm cruel for asking the question.

False alarm. Math is hard, let's go shopping!

3^{log_2 N} is not O(N). In general: a^{bx} = {a^x}^b, and log_a x = log_b x / log_b a. Combine those, and, a^{log_b x} = a^{log_a x / log_a b} = {a^{log_a x}}^{1/log_a b} = x^{1/log_a b} So if log_a b is < 1, then it's bigger than linear. In this case, log_2 3 is less than 1, so it's bigger than linear.

Some examples with friendly values for a and b to test our intuitions:

4^{log_2 x} = 4^{log_4 x / log_4 2} = 4^{2 log_4 x} = {4^log_4 x}^2 = x^2.

2^{log_4 x} = 2^{log_2 x / log_2 4} = 2^{log_2 x / 2} = {2^log_2 x}^{1/2} = sqrt(x).

Heh, was going to correct Hypatian, but I see the math shone through in the end.
LET YOUR MATH SHINE
LIKE A DIAMOND RING...

duckilama wrote:

What's a good book/tutorial for backbone.js?
Also, Spring.
And GWT.

We're putting together (well, in theory, time permitting) a program for Jr Devs to learn JS, using some of the posts on JavascriptIsSexy.com as a guide. The articles are clearly written, with nice examples, and they have a post on Backbone.js as well, so you could try that.

Garden Ninja wrote:
duckilama wrote:

What's a good book/tutorial for backbone.js?
Also, Spring.
And GWT.

We're putting together (well, in theory, time permitting) a program for Jr Devs to learn JS, using some of the posts on JavascriptIsSexy.com as a guide. The articles are clearly written, with nice examples, and they have a post on Backbone.js as well, so you could try that.

I find online tutorials in general to be more useful than books for most newer technologies, at this point.

boogle wrote:

Heh, was going to correct Hypatian, but I see the math shone through in the end.
LET YOUR MATH SHINE
LIKE A DIAMOND RING...

Yeah. It made me feel double-stupid. Fortunately, I hadn't sent my "Hmm, I think you're right, that is linear." reply to the candidate yet. Don't want to let my air of infallibility fade before we even make them an offer...

Has anyone here had a chance to tinker with Dart? A new "structured web programming platform": http://www.dartlang.org/

It compiles to javascript, or runs on its own VM, and I think was developed at, or with, Google. It has some actor model and asynchronous communication handling features for concurrency.

Hypatian wrote:
boogle wrote:

Heh, was going to correct Hypatian, but I see the math shone through in the end.
LET YOUR MATH SHINE
LIKE A DIAMOND RING...

Yeah. It made me feel double-stupid. Fortunately, I hadn't sent my "Hmm, I think you're right, that is linear." reply to the candidate yet. Don't want to let my air of infallibility fade before we even make them an offer...

For little things like that a quick wolfram alpha/mathematica sanity check is never a bad idea.

Pure evil:

@bradwilson: JavaScript co-worker prank: add "undefined = 3;" to the bottom of jquery.js. :)
Pirate Bob wrote:

Pure evil:

@bradwilson: JavaScript co-worker prank: add "undefined = 3;" to the bottom of jquery.js. :)

I would strangle someone off in the parking lot if they did this to me.

SixteenBlue wrote:
Garden Ninja wrote:
duckilama wrote:

What's a good book/tutorial for backbone.js?
Also, Spring.
And GWT.

We're putting together (well, in theory, time permitting) a program for Jr Devs to learn JS, using some of the posts on JavascriptIsSexy.com as a guide. The articles are clearly written, with nice examples, and they have a post on Backbone.js as well, so you could try that.

I find online tutorials in general to be more useful than books for most newer technologies, at this point.

Is there a good online tutorial site out there that covers lots of languages and topics and updates regularly? I feel like there's a lot of disparate sites that never cover everything I want. As long as it wasn't too expensive, I'd be willing to pay a subscription or ala carte for something like that rather than books that eventually go out of date. And then you end moving them with you from apartment to apartment but never unpacking them.

Are you talking video, text or both?

I prefer text. It's easier to reference.

Have you considered Safari Books Online?

Ah. This looks interesting. I'm going to check out their library, see if it's worth subscribing to. Thanks for the tip.

bandit0013 wrote:

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

I know this is older, but I've not been keeping up on this thread for a while. I've seen what you're describing here. It's usually the result of using a tool like Cobertura to make sure you hit a certain percentage of code coverage. There's nothing wrong with this in and of itself. I really like tools that make sure you've hit most of the branches.

The problem is that if the number is really high and the team isn't disciplined about TDD (TDD will lead you towards high code coverage, IMO) then you end up testing accessor methods and other nonsense simply for the sake of hitting the code coverage number and passing the build.

trueheart78 wrote:

Ok, I want to formally learn C. I've got experience with C++, although that's from 3 semesters in college (circa 2004).

I've always wanted to get closer to the hardware, and after using Linux as much as I have, I'd like to focus on learning it.

Are there any references, whether books, online guides, etc, that can take me deep into the rabbit hole? Something not too try, preferably.

Honestly? My favorite way to brush up on my old C knowledge has been to get into Objective C. There are lots of books on it and it's fun to play with iOS development.

Okay, now for a question. I'm wondering if anyone knows of a good resource on when to use NoSQL databases and the data theory around them.

DSGamer wrote:

Okay, now for a question. I'm wondering if anyone knows of a good resource on when to use NoSQL databases and the data theory around them.

Most exists as a simple mapping of key -> value (really object you are storing).
You store things, things are accessed by keys, things have attributes, if you get a thing without an atribute then the atribute is Null. Atributes can be lists, strings, ints, etc or ... OTHER THINGS!

*EDIT*
Edited for correctness, because I am dumb and only use python to interact with all my datastores.

boogle wrote:

*EDIT*
Edited for correctness, because I am dumb and only use python to interact with all my datastores.

I was just messing with you, by the way. I got what you meant by None.