Live data from Hacker News

Fizz Buzz: Enterprise Edition

github.com

161–170 of 171 posts

Re: Fizz Buzz: Enterprise Edition

#161

Can someone tell me why Java seems so to have developed into this kind of chaos? It isn't just enterprise java, has anyone looked at the Apache java projects lately? Tens of thousands of lines of dependency xml (that often doesn't even work because of incompatible common dependencies), three different built systems (ivy, ant and maven), abstraction for classes that have just a single concrete version, dependencies th…

Your fallacy here is that: Enterprise programmer -> Java Developer Java Developer -/-> Enterprise programmer The correct question is: What madness has infected Enterprise developers (and why do they all use Java)?

It is not as common these days, but the "enterprise bug" pops up with C++ sometimes as well. "Enterprise C++" doesn't look quite the same as "Enterprise Java" (generally the build tools/system/etc are not particularly enterprisified), but when you see it you'll recognize it as the product of a similar mind by it's distinct smell.

Re: Fizz Buzz: Enterprise Edition

#163
post #146

Earlier quoted context omitted.

>dynamically typed languages leave that information hidden because it is inferrable (or irrelevant). So do good, high-level statically typed languages, i.e. the kind with type inference. Like Scala or ML.

indeed. Scala's type inference system is truly beautiful. lets hope it catches on and becomes a widely adopted feature of the next generation of languages.

If you want to see a really beautiful type inference, take a look at Hindley-Milner. Not only is it global (it infers all the types in your program) but it's also surprisinlyg simple--it's basically just a straightforward constraint satisfaction problem.

In particular, take a look at how it has been extended by real languages, especially OCaml. OCaml has some very cool sub-typing features but manages to maintain global inference, unlike Scala. (Largely by choosing structural rather than nominative sub-typing.)

So some languages have had better type inference for longer than Scala has been around.

Re: Fizz Buzz: Enterprise Edition

#164

Earlier quoted context omitted.

Ha! You think any enterprise IT shop is going to trust an open-source product like Subversion with their mission-critical source code? It would be in Perforce or MS Team Foundation Server.

Eh, Perforce is too pleasant if we are really embracing enterprise; makes it too easy to do sensible things like use a git client. No, it has got to be SVN for maximum pain.

The merge tool (p4merge) is a dream, I shoehorn it into any VCS I use including TFS.

Re: Fizz Buzz: Enterprise Edition

#165

Earlier quoted context omitted.

Ha! You think any enterprise IT shop is going to trust an open-source product like Subversion with their mission-critical source code? It would be in Perforce or MS Team Foundation Server.

Eh, Perforce is too pleasant if we are really embracing enterprise; makes it too easy to do sensible things like use a git client. No, it has got to be SVN for maximum pain.

You can use a git client with SVN pretty easily. Git is a far better SVN client than SVN is.

Re: Fizz Buzz: Enterprise Edition

#166
post #53

I've often wondered - is it the language that spawns this or the mindset of the developer (or both?) I see this primarily in Java or .NET shops - massive layer upon layer, code generation, factories, classes, etc. - when a simple architecture would be best. Why do we get these insane things to begin with? What's going on? It feels sort of like premature scaling (what if we have millions of programmers - we need more…

I wonder too. I write a very atypical brand of Java (I like to think of it as "unencumbered Java"). I sometimes even use public fields instead of accessors (o, the heresy). My best guess would be that you often need to refactor you code to include some of the patterns showcased in the repo (factories, for instance). So developers try to future-proof their project by using those patterns everywhere. This is obviously…

Public fields for immutable objects are fine, but adding thread safety later is difficult if you use them.

Re: Fizz Buzz: Enterprise Edition

#167
post #139

This seems to be implemented in a single programming language without any dependencies on legacy systems. A truly enterprise-grade system talks to PL/SQL stored procedures. Or it would, if the DBAs had written the stored procedures. But they haven't responded to your ticket request yet. And when they do, it will be with a mostly irrelevant question delaying actual work for another week. by which time their manager wi…

Also it would be nice to configure the strategies with XML. Plus it would be super helpful to have jar plugins for new strategies. And seriously, there's no SOAP interface? This is hardly usable then. Also how the heck am I supposed to build this without Ant and batch and shell scripts to call Ant? Plus once you get ant files you can integrate it with Hudson. And package this as an EAR and add some user authenticatio…

You're right. There are so many issues with this, on top of the ones mentioned.

No serious enterprise-grade software today would do without leveraging Maven, annotations, IoC, AOP...

And why isn't the UI decoupled from the business logic? What happens if one day another team in the organization needs access to Fizz Buzz? Writing their own Fizz Buzz would be extremely redundant (even dangerous), and if anybody changed the logic of Fizz Buzz it would have to be changed in multiple places at the same time: a simple change like making "Fizz" print every fourth time instead of every third time would make every Fizz Buzz team go through architecture, various change management meetings and at least one weekend deployment. And all of this would have to be coordinated to make sure it all happens within a single change window (assuming this could even be rolled out in a "big bang" situation).

No problem. IT solves this problem easily with the seamless integration of EJBs, or SOA (as mentioned), or a modern plug and play ESB. There are multiple ESB vendors, each with their own advantages and disadvantages, so best practice advises organizations to create a working group comprised of all the stakeholders of the organization with the aim of reaching a consensus on the best product to use and the best way to move forward with this (it's more than likely the whole company will want to move to an ESB platform quickly because everybody likes to leverage and everybody likes things that are seamless). The team does not have to be very technical (the brochures and online PDFs explain things very well). Plus anybody inside the organization who thinks they need to participate should be involved.

On another note, the programmer who decided to take the initiative and write this needs to have a one-on-one with his or her manager immediately. Even organizations that value proactivity will find problems with this: there is a strict violation of at least one of the basic principles of enterprise software. I don't see any constants defined and everybody knows that "the enterprisocity of an application is directly proportionate to the number of constants defined."

http://thedailywtf.com/Articles/Enterprise_SQL.aspx

This would never get promoted through change management. Why hasn't anyone in-house written an Eclipse plug-in for this yet?

Re: Fizz Buzz: Enterprise Edition

#168
post #139

Earlier quoted context omitted.

Also it would be nice to configure the strategies with XML. Plus it would be super helpful to have jar plugins for new strategies. And seriously, there's no SOAP interface? This is hardly usable then. Also how the heck am I supposed to build this without Ant and batch and shell scripts to call Ant? Plus once you get ant files you can integrate it with Hudson. And package this as an EAR and add some user authenticatio…

You're right. There are so many issues with this, on top of the ones mentioned. No serious enterprise-grade software today would do without leveraging Maven, annotations, IoC, AOP... And why isn't the UI decoupled from the business logic? What happens if one day another team in the organization needs access to Fizz Buzz? Writing their own Fizz Buzz would be extremely redundant (even dangerous), and if anybody changed…

Thank you, yes, I forgot so many things. And most important, where is the test suite for this? I'd expect at least 80% line coverage and would like to see a coverage report to dive down into the specifics. Additionally, it would be nice to have some performance numbers as a base line for sizing, and timing of each method.

Further, what's the license on this? I'm afraid even if it's LGPL I can't go near this.

Re: Fizz Buzz: Enterprise Edition

#169
post #123

This seems to be implemented in a single programming language without any dependencies on legacy systems. A truly enterprise-grade system talks to PL/SQL stored procedures. Or it would, if the DBAs had written the stored procedures. But they haven't responded to your ticket request yet. And when they do, it will be with a mostly irrelevant question delaying actual work for another week. by which time their manager wi…

There should also be other applications that do almost exactly the same thing but display the information in a slightly way but use a completly different code bases.

Interesting. I see a need for an adapter library and maybe some runtime configuration settings to choose your preferred, underlying fizz-buzz library.

Re: Fizz Buzz: Enterprise Edition

#170
post #109

This seems to be implemented in a single programming language without any dependencies on legacy systems. A truly enterprise-grade system talks to PL/SQL stored procedures. Or it would, if the DBAs had written the stored procedures. But they haven't responded to your ticket request yet. And when they do, it will be with a mostly irrelevant question delaying actual work for another week. by which time their manager wi…

At the very least we can have a FizzBuzz table with a FizzBuzz field and the following records: 3 5

And access it using Hibernate.
Post reply on HN