On Sunday, 7 December 2014 at 15:46:59 UTC, John Colvin wrote:
> On Sunday, 7 December 2014 at 15:44:55 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote:
>>> Haha, oops. I meant 40 hours * 5 days a week * 50 people = 10000 man hours of work. Still a lot.
>>
>> The long work hours is why the US is ahead of Europe.
>
> IIRC the country with longest working hours in the EU is Greece.

On the same statistical oddity, France has an extremely high productivity per hour. Mostly because people work longer than the official hours.

These stats are so screwed up by the different policies in each country and the way people cheat them that I'm not sure we can conclude much from them.

On Monday, 8 December 2014 at 04:09:19 UTC, deadalnix wrote:
> On Sunday, 7 December 2014 at 15:46:59 UTC, John Colvin wrote:
>> On Sunday, 7 December 2014 at 15:44:55 UTC, Ola Fosheim Grøstad wrote:
>>> On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote:


> On the same statistical oddity, France has an extremely high productivity per hour. Mostly because people work longer than the official hours.

Well, that is true. "If 24 hours aren't enough (to finish the task), then you could work at night, too".

On 2014-12-05 03:47, ketmar via Digitalmars-d wrote:

> and what i also can't grok is "test-driven developement". ah, we spent
> alot of time writing that tests that we can't even run 'cause we didn't
> start working on the actual code yet. it's splendid! we didn't start
> the real work yet and we are already bored. i don't believe that this
> is a good way to develop a good project.

I kind of agree with this. But one thing I do think test driven development works good for is when fixing a bug. Then it's a good idea to start writing a failing test that shows the bug, then fix the bug and see the test pass.

-- 
/Jacob Carlborg

On 2014-12-05 10:27, Paulo Pinto wrote:

> Yes, but they cannot test everything. GUI code is specially ugly as it
> requires UI automation tooling.
>
> They do exist, but only enterprise customers are willing to pay for it.

It depends on what you mean with "GUI". I've been using Capybara with PhantomJS and Selenium for GUI testing in web development. They're all free.

-- 
/Jacob Carlborg

On 2014-12-07 15:20, Dicebot wrote:

> To give some examples from personal experience of what frustrates me in
> typical OOP testing approach:
>
> Imagine we have a simple cache class that internally communicates with
> external dht:
>
> class Cache
> {
>      private DhtClient client;
>      this(string addr) { this.client = new DhtClient(addr); }
> }
>
> Now we want to test it which implies adding mock client. Canonical way
> do it is by dependency injection and interface:
>
> class Cache
> {
>      private IDhtClient client;
>      this(IDhtClient client) { this.client = client; }
> }
>
> And know what? This just plain sucks. Not only you are now forced to
> modify yoru application code in many places to just comply to
> test-related changes that don't help actual app. You also introduce
> unnecessary interface indirection potentially killing inlining
> opportunities in the process.
>
> Same stuff with policy approach:
>
> class CacheT(DhtClient)
> {
>      static assert (isDhtClient!DhtClient);
>
>      private DhtClient client;
>      this(string addr) { this.client = new DhtClient(addr); }
> }
>
> alias Cache = CacheT!DhtClient;
>
> Effectively the same code as sample 1 and makes no difference for rest
> of the application. And how would I test it?
>
> alias TestCache = CacheT!StubDhtClient;
>
> No changes to application, no extra indirections, same effective testing
> coverage. Much better.
>
> And, of course, any utility functions that contain complex logic are
> better moved to free functions so that those can be tested with no
> relation to other code at all.

One of the few advantage with dynamic typing and duck typing. Just make sure the object has the correct API then it can be of whatever type you like.

With Ruby it's also very easy to add methods on the fly, change existing ones and bypass private. Features that can be very handy when writing tests.

-- 
/Jacob Carlborg

On 2014-12-07 11:52, Sebastiaan Koppe wrote:

> I am curious how you would write tests without mocks.

It depends on how the code looks like. With code that has no external dependencies, i.e. no networking, I usually assume that the entire system works 100% correctly except for the part of the system I'm writing a test for.

-- 
/Jacob Carlborg

On 2014-12-06 16:11, Russel Winder via Digitalmars-d wrote:

> http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript

And then something like PhantomJS [1], a headless browser, to run the tests in.

[1] http://phantomjs.org

-- 
/Jacob Carlborg

On 4 December 2014 at 13:47, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me:
>
>
> !…other languages like D and Go are too new to bet my work on."
>
>
> http://www.teamten.com/lawrence/writings/java-for-everything.html
>

Actually, I kind of saw it more as an argument to use only one language.  And in a way I've fallen into that pit too, where:

1) Everything written by the devs I support at work is in Java.

So when it comes to new technologies, anything that isn't in Java becomes a maintenance burden on me, so eJabberd backend becomes Openfire, some perl IMAP scripted interface becomes Apache James, etc - because these Java tools integrate with little work.

This occurred naturally out of the systems team I spearhead departing from the developer role it was in the past.

2) Write everything in Python.

Whilst not strictly true, it's just so happened to be the go-to language for anything that is needed for pulling statistics, graphs, etc...

Whilst the body of work I do is part in Ruby thanks to our entire
infrastructure being managed by Puppet.  When it came to writing
programs and tools - ie: An interface to Ceph.  Python was just more
readily available than D, including on:
- Officially supported ceph interface.
- Boto for the S3 gateway interface.
- Pygal for zero-to-awesome on generating SVG graphs for usage analytics.
- More trust in python's json serialisation capabilities than D's std.json.


I could spend time writing new libraries and interfaces for what I want to do, but at the end of the day, I found myself sticking to what was already supported, in the language that just so happened to have everything required already written.

On Sunday, 7 December 2014 at 23:22:21 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Dec 07, 2014 at 04:58:23PM +0000, via Digitalmars-d wrote:
>> On Sunday, 7 December 2014 at 16:08:27 UTC, H. S. Teoh via Digitalmars-d
>> wrote:
>> >Hahaha... you're right, I'm not thinking straight. OK, so it's 40*50
>> >= 200 man-hours per week. Hmph... I'm about two orders of magnitude
>> >off.
>> 
>>  log10(40/8) = 0.6989700043360189 orders of magnitude…
>
> Yes, and now I get to hang 0.3948500216800940239 of my head in shame
> instead.
>
>
> T

What I gather from all the posts about code reviews and testing is that it's a solid mess out there, and the bigger the company the bigger the mess. I'm pretty much the only guy who works on the code at the moment and sometimes feel a bit bad about failing to update this or that (unit) test (simply because I lack the time). On the other hand the code and the programs are constantly being tested in the real world and are very stable.

This might be due to the fact, that I "unit test" a lot during development (code a little, test a little). It is also down to the fact that the D compiler often helps me and warns me immediately. It's not so easy to get away with dodgy code in D.

Regarding the working hours, it is hard to measure efficiency in working hours when it comes to software development. Sometimes a major improvement takes only one or two hours of highly concentrated work (after which the brain is wrecked). Sometimes a stupid little problem takes a whole day to sort out. And let's not forget that programmers often tend to think about how to solve a certain problem after work. I often found it more efficient to shut down the computer and go home than to keep on trying to find a bug when I'm already tired and annoyed. The next morning (with a fresh head) I often spot the bug immediately. Or I think of the right solution on my way home. Mere working hours don't count.

On Mon, Dec 08, 2014 at 11:22:45AM +0000, Chris via Digitalmars-d wrote: [...]
> What I gather from all the posts about code reviews and testing is that it's a solid mess out there, and the bigger the company the bigger the mess. I'm pretty much the only guy who works on the code at the moment and sometimes feel a bit bad about failing to update this or that (unit) test (simply because I lack the time). On the other hand the code and the programs are constantly being tested in the real world and are very stable.

Sounds like you're actually in a pretty good state, compared with the rest of the industry out there! :-P


> This might be due to the fact, that I "unit test" a lot during development (code a little, test a little). It is also down to the fact that the D compiler often helps me and warns me immediately. It's not so easy to get away with dodgy code in D.

Yeah, D does fix a lot of the flaws with C/C++ that allow you to shoot yourself in the foot and then erase all evidence of it. While D does have its own share of dark corners, it's generally very pleasant to work with, and does encourage good coding style.


> Regarding the working hours, it is hard to measure efficiency in working hours when it comes to software development. Sometimes a major improvement takes only one or two hours of highly concentrated work (after which the brain is wrecked). Sometimes a stupid little problem takes a whole day to sort out. And let's not forget that programmers often tend to think about how to solve a certain problem after work. I often found it more efficient to shut down the computer and go home than to keep on trying to find a bug when I'm already tired and annoyed. The next morning (with a fresh head) I often spot the bug immediately. Or I think of the right solution on my way home. Mere working hours don't count.

Yep. I have experienced this many times. Sometimes repeatedly trying to attack a problem eventually gets to a point where my brain is just overwhelmed and cannot make any further progress, but when I take a walk and relax for a few minutes, my subconscious brain clears up and suddenly the solution pops into my head seemingly out of nowhere. I've had occasions where I wake up in the middle of the night with the solution in my head -- at least once, I actually got up at 6am and drove to work just to implement what I became convinced was the fix, and found that it in fact was, whereas many hours of intense concentration the day before got me nowhere.


T

-- 
The early bird gets the worm. Moral: ewww...