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.
Fizz Buzz: Enterprise Edition
61–70 of 171 posts
Re: Fizz Buzz: Enterprise Edition
#62I'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 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.
Re: Fizz Buzz: Enterprise Edition
#63Nothing new here...
https://groups.google.com/forum/?fromgroups=#!msg/alt.humor.... [1997]
Re: Fizz Buzz: Enterprise Edition
#64I'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'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.
Re: Fizz Buzz: Enterprise Edition
#65 *Ticket 23145gwy54fvdr*
Variable names do not follow standard.
Revise and submit to Q&A.Re: Fizz Buzz: Enterprise Edition
#66Wow. 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
"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 ==."
Re: Fizz Buzz: Enterprise Edition
#67Re: Fizz Buzz: Enterprise Edition
#68Startup 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.
No, step #1 is to put up a launchrock page promising FizzBuzz'd numbers and seeing how many signups you can get.
Re: Fizz Buzz: Enterprise Edition
#69Haha, 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!
Re: Fizz Buzz: Enterprise Edition
#70This would be hilarious if it weren't so painfully accurate for some code bases I've had the misfortune of working with.
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.