mikehaggard

Unless of course they invent their own WhatsApp, as many other regions have done. I mean, WeChat anyone? Chinese people refuse to use anything but that.

>But suggested for a new project ?

I'm seeing this a lot. If you browse the site the article's on you'll find some more examples.

The moral of the story is that "we" all think Java EE is very enterprisey and that it's anti the popular trend (which is AngularJS, Node.js, or were those popular yesterday?), and meanwhile a couple of startups are being very productive and able to start quickly with modern Java EE because "nobody" has realy noticed that Java EE slimmed down so much and got so much more productive.

I agree with what you say. Certainly would have had a bit more value if the article had elaborated on whether they used anything else. I feel the interviewer should have asked about that. Even a "no, we didn't" would have been valuable. Now we know nothing.

That said, it DOES mean that they have been happy with Java EE and have been so happy that they choose it again for their latest startup.

Contrast this with a typical startup where engineers always seem to hate whatever they used before and are like children in a candy shop for having the opportunity to use whatever we think is cool here.

> I think it just lacks a new MVC module as an alternative to JSF.

In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem

That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.

>setting thresholds on method / class sizes seems quite arbitrary and potentially harmful. Splitting a method into n different ones, none of which is called more than once is setting up the code for opportunistic reuse and obscures it's true function.

Sometimes, but in general I don't agree.

If the functions are made private and giving appropriate names than it's really a way of self-documenting code, which helps.

Suppose you have:

    some_function() {
        // Calculate interest
        // 100 lines of code

        // Apply tax
        // 120 lines of code

        // Store results
        // 30 lines of code
    }

Then the need to have those "banner comments" there already indicate it might be a good idea to decompose the function into:

    some_function() {
        calculate_interest(...);
        apply_tax(...);
        store_results(...);
    }

It's not just about reuse, but about documenting what each section of code does, and about limiting interactions between arbitrary sets of variables. Functions are create boundaries (assuming they don't intensively use global variables or class instance variables when part of a class)

>Variable names: foo or bar are probably not useful method names for data structures. e is similarly not useful when compared to exception. Be as verbose as you need (depending on the language). Expressive variable names make it easier to understand code when we have to revisit it later.

I so agree with this!

Properly named variables is perhaps THE first line of defense against bad code. Too many developers think they are concise and having little code if they only abbreviate their variable names enough.

Honestly, "em", "erg", "fc" and "sc" may make perfect sense to use, but it's a form of obfuscation to future developers (including your future self).

Other pet peeve; adding things to variable names that don't add anything meaningful.

E.g.

"usersList"

Does your code really care that it's a list? Should the reader be pointed at this each and every time. I much prefer just using:

"users"

Clear, to the point, and readable.