Fizz Buzz: Enterprise Edition | Hacker News Reader

Fizz Buzz: Enterprise Edition

github.com

318 pointsgeetarista166 comments

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 will be offsite at OracleWorld and won't be able to approve the changes.

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

Awesome! :)

And access it using Hibernate.

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.

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 authentication too, probably single sign on. Also needs some log4j. And there are probably all sorts of unforeseen bugs and style issues, so it needs Findbugs and Checkstyle integrated.

If it were truly Enterprise worthy it wouldn't be in github, but im perforce or, better yet, ClearCase.

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?

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.

Startup edition:

    * provision one ec2 instance per number to check
    * assign numeric order based on uptime in msec using zookeeper
    * serve result via json
    * render it on the client.

Don't forget about the RESTful interface to the application.

first of all restful and json are not really welcome. do your JAX-WS first and then we can talk about these new silly things.

Good point. Those fizzy SOAP requests need to be signed too. Enterprise Security and all.

No, step #1 is to put up a launchrock page promising FizzBuzz'd numbers and seeing how many signups you can get.

Maybe they will use Heroku instead of EC2

It is done in node.js with the latest something.js fad that provides event-driven async MVC interfaces in Coffee script or something like that

Also, they will have 100% code coverage (thanks Uncle Bob) but will fail at launch since nobody bothered to test it for more than one user.

* import multiple javascript libraries titled as their filename.

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 abstractions!) combined with misuse/misapplication of design patterns.

You'll never* see stuff like this in Ruby on Rails, JavaScript, Python projects, etc. I'm curious how one goes from a simple, elegant program to over-engineered monstrosities.

* Hardly ever. I haven't in > 7 years.

Part of it is "customers want it", part of it is because people are taught "abstraction is good", rather than "abstraction can be useful".

So folks abstract everything, because they don't stop to think about whether it makes sense.

You know, just in case the day comes when they need to send requests using carrier pigeons instead of TCP. They never stop to think whether "in a world where we need carrier pigeons, would this app be useful anyway?"

Part of it is "customers want it", part of it is because people are taught "abstraction is good", rather than "abstraction can be useful".

"Object-oriented abstraction is going to change everything."

"Yeah, abstraction is good."

Have to agree there... but without having to support/supplant multiple systems simultaneously, or in support of rigid testing, it doesn't make much sense.

In the former case, it's usually easier to rewrite than write a new, compatible abstraction... in the latter, with simpler more custom interfaces, testing can be smoother than a lot of frameworks for these things.

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 a terrible idea.

Now for the bitchy part, why does no one ever speaks about the good sides of Java?

Because people who know the good side of java have jobs.

I generally go by the saying, baring any existing req's that abstraction patterns would help with:

'Code to use, Refactor to re-use'

  So developers try to future-proof their project by using those patterns everywhere.

Something I've seen a lot (and been guilty of myself) is trying to fix the problems of past projects in new projects before they crop up.

A better solution is to not be afraid of refactoring (tests help here) so you can solve the problems when they become a problem, not create complication before.

> Now for the bitchy part, why does no one ever speaks about the good sides of Java?

Cause at some point most of them got tired to preach about Java and continue to do great work vs worrying what other people think.

Look around: NetFlix, Yammer, Twitter, Google are all using Java to power either their infrastructure or apps. Nobody blogs about it because "It Works" ;)

The rest blogs how they keep jumping between wagons :P

this joke thing isn't really about Java as a language though. its about a very weird/bad and surprisingly common design anti-pattern. Java was used to do this joke because its utterly typical for this type of work, but certainly you can have this kind of disgusting enterprisey garbage in just about any programming language.

nobody makes jokes at the expense of well written Java software because its well written. we all know that the language is perfectly fine, and in alot of ways quite good, when it is used by sensible engineers.

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

Sharepoint integration or it's ilk pretty much creates necessity for layers. Hide bad code behind layers is the enterprise motto.

I almost feel like, as a programmer, you can get "calibrated" to a certain level of architecture or designed-in flexibility, and then any time you have to code something "lesser", you end up adding architecture and boilerplate until it looks like the things you're familiar with.

Look at the HTML5 IndexedDB API, for example: obviously designed by someone "calibrated" to coding web browsers, not someone calibrated to doing web scripting.

I agree with you. It seems like Java programmers at enterprise ignore Cohesion vs Coupling tradeoffs. Every class and abstraction they write is so tightly coupled which causes issues when debugging or just trying to figure out how to add a feature enhancement without writing more classes. Working as a software engineer, it sucks looking at a 1000 lines of code to do something simple that can be done in 10 lines elsewhere --> means that OO is not the right way to go about things sometimes.

I've worked on a couple of these systems over the years and I think it's a combination of the philosophy of those languages: http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...

And partly a correlation between the type of company that chooses a "proper", statically typed, "enterprise ready" language and the type of company that hires "safe pair of hands" programmers who value predictability over getting stuff done.

Must be the mindset. I've seen plenty of straightforward, well written C# code with none of this garbage. I'm sure it's the same with Java. And you would see plenty of Ruby code written in this kind of style if Ruby was popular in enterprise software development.

I agree with that. For example, Azure storage is pretty straightforward and simple to use [1]. Or LINQ, which is part of the .NET framework and is beautifully simple to use.

It's a blind insistence on caution.

There are thousands of things one might want to do in the future, and many managers "prepare" for each and every change they can conceive.

I've seen this done in a PHP project (to the extent that it is possible), so I'm pretty sure it is the mindset of the developer.

Dynamic typing is much maligned these days, but it allows you to abstract without nearly so much boilerplate.

Statically typed programs are longer because they contain more information.

they don't contain more information. they contain more explicit declarations of that information. dynamically typed languages leave that information hidden because it is inferrable (or irrelevant).

When the programmer is the one that has to be doing the inference you refer to, there seems to be a good argument that the speed advantage you refer to is only apparent in programs small enough to conceptualize in their entirety.

>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.

Boilerplate is not an inherent feature of static typing - just look at Haskell or Scala.

It's environmental, largely driven by a) the need for cost certainty, and thus the susceptibility of non-technical management to the allure of the Bag Of Magic Beans sales pattern (see also: the fungibility of skilled work fallacy); and b) the need for risk abatement in large organizations.

I've always found it most useful to think of this sort of garbage as an effort to hedge against terrible communication. Sure, it's likely to be a load of blood sweat and tears spent on useless tangential silliness; but one time in a hundred, the plastering of abstraction over ill-definied abstraction will allow a team to anticipate one step ahead in the chain of ever-shifting requirements, and thus, earn back a few hours and a tiny shred of dignity.

Nobody really likes this crap. But the life of the mean programmer is a grim one, indeed. Ultimately, the problem is that nobody really knows how to write software.

Not to defend the indefensible, but why not make a couple of discussion points...

If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.

Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.

It all comes down to testability. In statically typed languages like C# and Java, it's very hard to test a class in isolation without abstracting hard links between classes, segregating interfaces, inverting dependencies and so on.

You can write "simple" systems in those languages that have the code purity you're looking for, but they won't be very testable.

In the dynamic languages you mentioned, you have duck typing and testing is a walk in the park.

From what I see it is usually well intentioned but not exceptional developers trying to write "good code".

They know some sort of abstraction is called for, but they end up picking abstractions which are actually a net negative for code complexity, rather than a positive. If you have enough of these developers then it devolves into code very much like the OP.

There is also a resistance to large refactorings which "clean house" of these sort of abstraction errors in enterprise teams and a lack of developers with the skill (and balls) to do it. So this cruft tends to accumulate.

"Nobody ever got fired for buying IBM."

If you are new to an organization, do you rock the boat and fight for code-reviews for nice looking code, or do you bite your tongue and and write enterprise code to make everything go smoothly, from an administrative standpoint? You are not going to be scolded and forced to defend yourself for the enterprisey code, even if it ultimately was the wrong choice.

Writing "enterprise" code is "safe".

Then angularJS dropped. Now we see it there as well.

[disclaimer: I am programming a service in angularJS for the client and SpringMVC for the server. My code looks exactly like this. I cry myself to sleep every night.]

Honestly, I'm not sure where it comes from... I tend to bypass/rip out this kind of obfuscated crap from projects wherever possible... "Microsoft Enterprise Library" is about the bane of my existence... I've only seen two projects in the 11 or so years of .Net development where it was a good use case.

Lately, for smaller one-offs, utility scripts etc.. NodeJS is my tool of choice. Even where it isn't the fastest choice, it tends to be one of the easier choices without going to a language the rest of the systems don't use (JS is used on the web, so web devs need to know it anyway)...

/fizzbuzz.js/ for(var i=1;i<=100;i++)console.log(!(i%3)&&!(i%5)?'FizzBuzz':!(i%5)?'Fizz':!(i%3)?'Buzz':i);

You need a certain mindset to start using a newer technology, and that mindset won't make you prone to write enterprizy code.

Or, in other words, the place that makes that kind of architecture won't allow the developers to touch anything that's not Java or .Net.

Amateur hour. Serious Business this is not. Where are the tests? The Inversion of Control? The logging? The analytics system? Documentation? Architecture diagrams? Someone should either fire or promote this engineer immediately.

And he should have used a CHAIN OF RESPONSABILITY pattern instead of the IF/ELSE to handle each case , and the FOR loop should have been handled by a STATE PATTERN , finally the system.prints require a full BUILDER to decouple datas from rendering triggered by COMMANDS , that work is indeed "amateurish" , especially without a SERVICE LOCATOR.

This is obviously bogus. Where are the XML configuration files?

This needs at least 70 maven dependencies.

It's just not enterprise if it's not relying on an internally modified version of maven that drops compatibility with the outside world.

Don't you know that auto-wiring dependencies changed everything? Look at how much more concise this is now without all that XML...

Wow. There were pull requests that were accepted to this project:

https://github.com/Mikkeren/FizzBuzzEnterpriseEdition/pulls?...

The potential for more funny is great here.

My favorite:

Change <= to < and ==

"One-liners lead to unclear code that has too much responsibility crammed into too little space. It's better to do less per line and keep the code readable. This changes the very complex and ambiguous operation <= into two separate, easily understood operations < and ==."

Last week my colleagues and I realized that the official, Zend-provided, XML-based communication system that allows our PHP middle-end to talk to our RPG-based backend doesn't allow you to return any character string that includes a less-than symbol.

One of our routines returns a SQL string.

Sometimes SQL strings contain less-than symbols.

After much handwringing and an official bugfix that fixed nothing whatsoever, we decided on the next-best solution: all instances of `where foo < bar` must be generated as `where foo != bar and foo !> bar`. I shit you not, that is a not-greater-than operator.

http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/index.jsp?to...

I may sound frustrated, but I'm not. We all had a good laugh at the workaround and got back to work. This sort of thing is sometimes known as "job security".

why not just use 'where bar > foo'?

Ugh, I really don't feel like explaining. :P

Long story short: bureaucracy.

Please note that GitHub no longer supports Internet Explorer versions 7 or 8.

How ironic. This covers so many enterprise programmers with locked down Windows PCs.

Twitter stopped supporting both a while ago as well.

Github's analytics probably says something else.

What are the chances that a company that locks down on IE will let them use github

In my case, it lasted for about 4 months.

Of course, a really industrial-strength FizzBuzz would be in an SVN repo.

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.

Sometimes they don't have a say. I've worked with several large fortune 500 companies who use SVN, regardless of how much the IT Department objected to it.

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.

If you think SVN is 'maximum pain' then you haven't tried out the full array of actually bad VCSes. SVN is fine, if a little outdated-feeling.

Three words: Microsoft Visual SourceSafe.

Rational from IBM!

I worked at uni that wanted to push this onto the CSIT students :| Such a horrible dept

Besides the "modern" VCS's, I've used SVN, CVS, Perforce, and done both manual patch management and patch management with Quilt. I am sure there are some VCSes out there I would hate more than SVN if I used them, SourceSafe I'm sure, but I would honestly use any of those others I just listed before SVN again. Yes, I consider SVN to be a devolution of CVS.

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

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

This would be hilarious if it weren't so painfully accurate for some code bases I've had the misfortune of working with.

This is my day job in a nutshell. Somewhere around the 5th folder click I couldn't decide if I wanted to laugh or cry.

Cry. You wanted to cry.

I did cry a little. Hit too close to what is sometimes home[0].

[0] https://plus.google.com/u/0/111011776153281260419/posts/GWdk...

how?!?

It's not so accurate with codebases I've worked on in that the indenting is far too regular. Naming convention seems consistent throughout, as well.

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 that are old and no longer supported (I'm looking at you Apache Gora). Hell, find the download link on most Apache java project sites. Now find the one for the source repository.

What madness has infected Java developers?

(Sadly, I've recently had to start doing a bunch of big data work with hadoop, possibly the most fractured and poorly documented open source project ever created)

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.

Where is the Spring dependency injection stuff? You can't just hard code all your Factories in FizzBuzz.java, you need to specify everything using XML so you can switch Factories without going through a recompilation.

Exactly. No Spring, no Maven...I mean, come on. Plus, I'd like to see some Camel routing defined for sending my crucial FizzBuzz results to various endpoints.

Oh yeah, and what about when I want to run scheduled FizzBuzz? Obviously I need Quartz, which requires...more XML!

Let's not get into the necessity of making a FizzBuzz OSGi bundle - we'll tackle that in the next iteration.

Sounds like a typical Gemfile.

This is terrifying. It's like a docu-horror flick for programmers. I actually felt depressed, anxious, frightened, and dispaired going through that code.

I think a lot of programmers in the enterprise world are consultants and paid by the hour or day. That means longer it takes to solve a problem and then later support it the better. You are paid more for working on the project longer. That naturally drives people to create elaborate schemes for simple problems and make more money.

I give another example where goals and rewards are misplaced. India has a serious Cow problem. Every city in india has thousands of cows roaming freely on the streets. New Delhi, india's capital decided to solve this problem by hiring workers who would take this cows from the streets , put them in trucks and move out of the city. They get paid for the number of cows they collect every day. Guess what happens ? They release the cows next day into the city so that they can collect again and make money.

Anywhere there are goals and rewards misplaced, inefficiencies will creep up.

This is how I learned Java in software engineering. Simplistic if/else logic transitioned to enterprise madness. It left a bad taste for most of us in the program.

If you are a teacher in this position, provide fleshed out source/examples of enterprise software/requirements and have the students extend the functionality. Using minimized examples to prove the concept leads to rebellion/disgust.

I love this. I just wish it was a joke. This is a daily reality for so many of us.

do you put .java. in your package names? That one stood out as really strange (others were par for the course)

What if you have projects in other jvm languages?

never having been in such a situation, I wouldn't know, but this is the first time i'm hearing of people putting java within the package name (for something that's not part of the java namespace)

scala!

I haven't actually seen java in package names, but I can easily imagine the conversation where some over-planning architecture astronaut decides that the project may need code in another language in the future (without bothering to worry about if that language even uses Java style packages) and so they better make a directory that is specific for the Java code so they can keep the other code separate, if they need to add more languages in the future.

I've not seen it directly in the package names, but I've definitely seen project hierarchies with source/java even though no other languages were used (or going to be used, for that matter).

To be fair, src/main/java is often the default places build systems look for code. I'd rather use that then complicate my build scripts.

There's also src/main/resources, src/main/webapps, and possibly other dirs that can go in there that aren't other languages.

Funny, but a little too obvious.

What if you did a Poe's Law version of this? That is, try to create the most contrived parody of a solution to FizzBuzz possible, but one which still fools at least 50% of interviewers into thinking it's a legitimate response.

That would just be a script to Google for the FizzBuzz solution.

The obviousness is probably to avoid flames.

I'd love to see a branch of this with your suggestion, though... and maybe a script that would automatically generate a file structure that reflect the namespace of serious business with which one is interviewing. You know, for fun ;)

Haha, i remember this new java guy at my (games)company that implemented his version of a skill/weapon system and in the end had like 20 Different Classes/Interfaces/Abstract Classes/Factories. It worked, but was horribly over engineered and much harder to understand than a much simpler version we made out of it.

Abstraction makes code harder to read, so use it wisely!

I got about 4 levels deep in the folder hierarchy before I got disgusted and had to close the tab.

If you want to turn this into a SaaS solution, I would be happy to donate the domain FizzBuzzAPI.com to your cause. I think the community would really benefit from being able to offload the overhead of solving FizzBuzz problems to an external service.

IMO this doesn't make the cut because they didn't externalize the Strings "Fizz" and "Buzz".

I had a bunch of fun coming up with terrible ways to write FizzBuzz a little while back. My favorites, in Python https://gist.github.com/daeken/1e3c680c20da98c680c4 and C https://gist.github.com/daeken/15769d83b66974335f78

# That inspired me to have a bit of my own fun. Here's my awful Python take on it.

[(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n)) for n in range(1,51)]

That python code made me cringe. decorators, parsing, compiling and evals? You win.

No metaclasses or descriptors though, still needs some work.

Oh, you want metaclasses? How about this?

print(type("",(),{"__call__": lambda self, start, end: [(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n)) for n in range(start,end+1)] })()(1,50))

Here's my python version that uses the y-combinator: https://gist.github.com/sirpengi/3443999

I can't tell if some of the obviously missing patterns are accidental or just representative of that usual type of code with all of the wrong patterns and none of the right ones.

    *Ticket 23145gwy54fvdr*

    Variable names do not follow standard.
    Revise and submit to Q&A.

It's rather cumbersome that you have to initialize all those factories in FizzBuzz.java. You should probably be using an Inversion of Control system.

But what if you wanted to swap out your IOC container? I think you'd have to inject your container using an InversionOfControlFactory pattern

How is anyone supposed to tell this is a spoof when things like this

  '  sum = sum + i
  Array.SetValue( Text.Append( "GetSum", GetSum_Locals), "sum", Array.GetValue( Text.Append( "GetSum", GetSum_Locals), "sum" ) + Array.GetValue( Text.Append( "GetSum", GetSum_Locals), "i" ) )

- http://wiki.smallbasic.com/Simulating%20Local%20Variables.as...

unironically exist in a language "aimed at bringing "fun" back to programming. By providing a small and easy to learn programming language in a friendly and inviting development environment, Small Basic makes programming a breeze"

Just so I never have to answer it again for an interview, I wrote a specification and implementation for FBaaS (FizzBuzz as a Service):

http://github.com/tomjakubowski/fbaas https://github.com/tomjakubowski/fbaas/tree/sinatra

Accepting pull requests! I've had a couple mind-blowing contributions in obscure languages, my favorite being a provably correct Fizzbuzz service written in Coq:

https://github.com/tomjakubowski/fbaas/tree/coq+hs+wai

Where's the xml configuration and dependency injection? (I'm a java programmer primarily myself and thought this was hilarious)

It's all fine, you just need a better IDE. :-)

Where's the build script?

Gradle build script of course!

refactored:

class F{public static void main(String[]a){for(int i=0;i++<100;)System.out.println((i%3>0?"":"Fizz")+(i%5>0?i%3>0?""+i:"":"Buzz"));}}

That's great, but we're here to make fun of "Enterprise" programming and anything associated with it. Now you come along and give us this simple example that works.

I bet it would still be better in Javascript or Ruby because those are the only two languages that I know and everything is better as a web app anyway.

To truly be enterprise it needs a Maven build and JavaDocs.

Want to see this kind of stuff done entirely seriously? Search for solutions to the "Thoughtworks rover" problem. When you see a class for each direction you might be heading, you know you're on the right track.

my colleagues had to come round to my desk to see what it was I was laughing about. Don't remember the last time looking at code made me laugh.

This is missing Spring config! How could is possibly be considered a real enterprise app without at least half of its logic encoded in XML!

I'm disappointed. They could have removed the if/else blocks by dynamically selecting the strategy and abstracted the loop. B-

;)

Tempted to send this to my Java colleagues.

lol, cracked me up.

I met some c# guy who did the whole enterprise thing in his version, but it wasn't tongue in cheek at all.

in my head I went, this is why the whole ms enterprise stack sucks balls. the sad part is that they actually think it's good to abstract away something really simple.

EDIT: removed the link, sorry for offending you dude

"in my head I went, this is why the whole ms enterprise stack sucks balls."

Brilliant. So, if some random programmer built some way-over-complicated Javascript solution, would you think that the entire web platform "sucks balls"?

"the sad part is that they actually think it's good to abstract away something really simple."

Who is they? Microsoft, this random c# guy or all c# programmers? If you answer anything but "random c# guy", I'd like your evidence please.

Also, let's see some of your code please. Not fizzbuzz. I wanna see some of your real life code.

The problem isn't random programmers, it is a culture and tool ecosystem which says that this is the right way to do things. If it were just one random programmer, there would be nothing to complain about.

If some guy decides to write his website in his own dialect of Visual Basic, that isn't really being inflicted on anyone but his employees. The deeply-nested StrategyFactory stuff is an infection which worst affects languages like Java and C# (recruiters call it "OOP") because those communities do not strongly reject it.

So, you should be able to show me dozens of tools that are the default choice within these ecosystems, that make programmers build things in this way.

Can you please name some tools and tell us how they say this is the right way to do things?

Why do JAVA, C# (and the like) IDE's have such complex feature sets? Is it not a reflection of the complexity that those ecosystems require for maintaining your code?

Which feature set? The core of these IDEs is a debugger that is highly integrated with a text editor. Is there a problem with that? IDEs often show me the files that are in the project. Another common (core) feature is code completion. Also, integration with common source control systems. Too complex yet?

You didn't mention XCode. Why not? It has all of those features. So, it must be the non-core feature of IDEs that makes one seem complex and the other not. Which features are you talking about?

I concede you make a good point. Most of the features you listed I end up using via command line rather than it being integrated directly in my editor. Maybe part of what i see as complexity is just my cheese being moved. However, and correct me if im wrong, IDE's are more popular with "powerhouse" OOP languages in general. I always thought that it was because navigating these types of projects with just a simple text editor was too cumbersome without the editor being aware of context.

Really?

Eclipse, Netbeans, Maven, JUnit, JLog

J2SE libraries - pretty much all of them

Apache libraries

Hibernate

J2EE libraries

The list is endless

Even Google App Engine manages to be way more convoluted in Java than in Python or Go, it's not even funny

These are all defaults and you are forced to use them, right?

Furthermore - does this really help the argument that "the whole ms stack sucks balls" or even "the whole java stack..."?

I use Netbeans[1] and Eclipse all the time, and I don't write Java code like that. Then again, I write GUI's by hand in swing, so .... there is that.

[1] edited from Netflix. I use Netflix all the time, too!

Netflix? I think you mean Netbeans maybe =)

I don't write java code like that as well (and I don't use swing) but sometimes is unavoidable due to the ways the libraries are structured.

so overcomplicated javascript is not overcomplicated?

i just started working on microsoft enterprise garbage. ever had to deal with sharepoint, dynamics?

even microsoft developers say you're doomed when you're being put on a sharepoint project.

I just codereviewed code for 2 different dynamics contractors. Both highly recommended by microsoft. both of them had high levels of abstractions, but the end result was tightly coupled anyway.

Their javascript was written the same way. The real joke of it was that I had never done anything of the likes.

Want some of my real code from many years ago? go through mplayer/ffmpeg

edit: as pekk said the problem is cultural

Say what you want about the culture but I've found MS's stack to be quite good with the right team. It's got some great features. LINQ in particular springs to mind.

There are plenty of terrific systems built atop that stock. StackOverflow is implemented in ASP.NET, for instance.

dude! microsoft is not just enterprise. they have the biggest r&d lab with some really awesome shit going on.

linq is made by the haskell guy. well the haskell guy was a microsoft guy. but you get the idea. it did not grow inside of the .net enterprise culture. it grew outside of it. I never had any qualms about c# as a language. but that's also not what we're discussing.

just like f# is wonderful. but it too did not grow inside, but outside. they're being really smart about tying it into the enterprise as much as possible therefore guaranteeing it's future though.

I agree

I'll take C# over Java any day. Hands down.

It has its warts, sure, but it's night and day. I can't pin it down, but the C# libraries seem much more natural to me.

Of course, if the team culture is not good, it's going to be messy, either in Java, C#, Python, etc

Your comment offends me, but on a light note, for every 1 developer doing the enterprise overengineering crap, there is a dozen of us C# guys who are doing the opposite where I work.

it shouldn't, it has nothing to do with you, as much as it has something to do with best practice in c#

Show us the best practice that resembles this FizzBuzz solution.

Also, I'll be waiting to see some code that you think is great.

You're really taking this personally, aren't you?

No. I honestly want to see some of this great code that I keep hearing about.

It's just hilarious to me when people think their shit doesn't stink and so I rub their faces in it.

Have you seen the code for Node.js? It's fucking disgusting. Yet everybody around here can't get enough of it. Seriously...I'd love to see how some of these developers would deal with enterprise requirements. I think the problem is that they just don't understand that business is chaos, it's not like building some pie-in-the-sky single-purpose social media application.

It's quite common in these parts to be honest to piss on .net/Java 'enterprise' code.

Many of the folks here haven't seen what kind of systems banks and other big companies work with, so they have this little start-uppy world view with tests and orm's and the like, where vulnerabilities in their software are touted as 'the price to pay for being agile', so it is very hard for them to understand some of the practises in big companies. Now sure, I've seen some bad code in there as well, but I also seen a lot of bad code in Rails projects (heck, before the idea of fat model skinny controller, most of rails programmers had controllers the size of the moon, then cam fm-sc and now models are enormous, but in rails 4 we will have concerns which I'm sure will result in same clusterfuck, and the interesting thing is, before fm-sc, rails folks said 'yeah, controllers are supposed to be like that', then with fm-sc 'no no, it's like this now', and now we get to concerns and will be the hot topic, and they keep rewriting and rewriting and touting how .net/java devs don't know what they are doing, while these devs have code in production and still in development for decades (well, java at least) in systems they can't even imagine the complexity.

tl,dr: stop assuming .net/java devs are shit and you are the best for using rails or python, chances are, you suck as much as them.

In all fairness, banks in general have shit security and willfully ignore good security practices. I can configure my Facebook account to have better security than most banks.

No, C# best practices look nothing like this. I have no idea what happens in Sharepoint land or deep in the enterprise and MS Office stacks, but the core of .Net is not over-engineered to this level. Factories, FactoryFactories, and XML-configurable dependency interjection frameworks are nowhere to be seen.

And rails security is why the whole rails stack sucks balls. the sad part is that they actually think it's good to be agile on something critical

See, easy to over generalise.

Edit: And amazingly just 12 minutes ago: https://news.ycombinator.com/item?id=5395645

As soon as I seen the factory pattern here I had a flashback.

Great parody.

He forgot to mavenize the project...

This may be Enterprise Quality but without UML diagrams our Architects are not going to be able to understand or use the code.

Are you offering support contracts? MegaCorp Management requires that we have paid support, the more expensive the better.

Nothing new here...

https://groups.google.com/forum/?fromgroups=#!msg/alt.humor.... [1997]

So can this automatically be distributed to multiple servers? Impressive.

Can you get this into a Maven repo? I'd like to include it via my pom.xml, I have some numbers that need FizzBuzzing and they always say great developers never repeat the work of others.

God... this is particularly painful because I remember first seeing this in a thread on boards.4chan.org/g/... and now, several months later, here it is on hacker news.

So, so good. I hope it includes at least one undocumented legacy code nightmare for true authenticity.

Needs more Internal Frames.

Please open your issues at https://github.com/Mikkeren/FizzBuzzEnterpriseEdition/issues...

And contribute your fix.

Reply on news.ycombinator.com