Hacker News new | past | comments | ask | show | jobs | submit login
FizzBuzz Enterprise Edition (fizzbuzz.enterprises)
168 points by Ethcad on May 10, 2018 | hide | past | web | favorite | 70 comments

I am surprised that the Enterprise edition is missing the option to export as an Excel file, eagerly waiting for future releases.

Our issue is that we hired an intern to code FizzBuzz, and he mistakenly coded it as divisible by 3 for Fizz, divisible by 4 for Buzz, and divisible by 13 for FizzBuzz. Now, our sales force runs on this modified FizzBuzz. We cannot simply accept an additional unvetted FizzBuzz, even if it strictly adheres to the standard.

This version on GitHub looks solid, but it needs an Enterprise Compatibility Mode that loads an external emulation mode for modified Fizz, Buzz, and FizzBuzz values in order for adoption to take place.

Anxiously awaiting your pull request.

Sorry, the change has been made internally but publishing it would violate our internal legal policies.

I cannot publish any source codes or share designs that would violate employer confidentiality or disclose protected commercial IP.

You can buy that as an add-on, a consultant will install that within only a few months.

Of course it goes without saying, ongoing support will cost you extra.

When you do add Excel functionality, please ensure that it supports Excel 95 fully, as we need it to be compliant with our bidding solutions for government contracts.

We have a proprietary method for up-converting it before bidding on military contracts.

Also, we'll need you to supply an on-site support technician to handle any issues that may arise.

And LDAP authentication.

Surly a full x.500 implementation not this hippy open source nonsense :-)

After AD auth and SSO.

If I didn’t have twelve other things going on right now, I would totally file a PR for that.

But there are so many flavors of CSV file to choose from. So I’d have to make that pluggable too.

since we're at this, fizz buzz in css https://jsfiddle.net/yf68emtn/

I didn’t know I needed this to exist in the world until you said it. I think we found our new Steve Jobs. How do you feel about working with Jony Ive?

The documentation is not Enterprise Ready™; it still contains a description of what the product actually does in an accessible location. For proper compliance, this description should be in a PDF whitepaper that will only be mailed to you after providing your e-mail address and phone number.

That pdf whitepaper won’t actually explain how to use it. It will describe the synergy of the experience of using it, give three real world customer stories of how it is used (without actually explaining how), and then end with a link to a documentation site that redirects to a login screen that it will take two weeks to get past because your account rep can’t get the right team on the line to approve your account for access.

And don't forget to fax a signed copy of the NDA!

The PDF whitepaper should also be an image instead of text to prevent anyone from using find or selecting text.

Yeah, to be fair, just by being on GitHub there are issues. Ideally, it should be sat on Visual SourceSafe or something in a server on an industrial estate somewhere.

It should probably be sent via Fax to be sure.

Real Enterprises would print out the PDF and scan it back in and then delete the original.

The Github issues list is the real gold mine: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...


I'd really like to see the microservice version of that.

Just run it from the docker.

Too easy. You'd need to split it up into at least 10 services, it's called microservice for a reason.

But most of them are not for enterprise grade code. No enterprise is using React or Java 10. Maybe docker, but the project addresses the real enterprise problem: using Java and in its most ugly form (including using Spring).

It misses Cucumber BTW

Guy who loves* Spring here. Curious what you think I'm missing out on...

* I'll grant you that I find Spring Boot to be a blessing and a curse, but that's not what you're talking about, I assume.

>add blockchain

Because of course

I eagerly await the day all this blockchain stuff is considered legacy enterprise cruft.

I've enjoyed some interesting blockchain related ideas recently, most of them start off quite innocently but then comes the "but we want to use smart contracts" and I'll tell them that there is no need and it would add unnecessary complication "but if we can use the blockchain it will be worth more" -__-

Looking at the problem statement, this should be built in a Reactive style of programming and more event based. What if we need to scale this to infinite numbers for millions of clients ?

Event based programming in technology like stack is more appropriate for this kind of problem domain...

> What if we need to scale this to infinite numbers for millions of clients?

I worked for a company where an internal tool for, at the moment, a dozen users was designed to be more scalable than the actual product. The product was used, without major problems, by hundreds of millions of users. So we had a team of 14 people to build something that previously was done by one guy in an already maintainable way.

The server was also divided into several components to mimic a micro-service architecture. Even that no one else was using any of the services and it made deployment cumbersome.

To cut a long story short, the company has a-lot-of-money to throw at problems. So waste is not a big deal. I moved on, as it was boring to work that way.

Many backend developers feel proud of their complex architecture. Simplicity is seen as "not being professional".

For the client side of that app, there was just one guy. He was also acting as scrum master because he had spare time.

I've faced a similar situation, where a team I came to work on mid-project had designed a microservice architecture where a WordPress front-end talked to some "middleware" (a total misnomer since it was actually a REST API) which in turn talked to a bunch of other intermediate services which in turn talked to the CRM, an accounting system, and other third-party systems. Most of the "middleware endpoints" simply forwarded the calls to other services. Any feature that required a new endpoint usually meant deploying changes to three different systems.

I'm appalled that this piece of junk that has the audacity to call itself "enterprise grade" does not employ an industry standard dependency injection framework. 22 appearances of 'new' in the codebase - you gotta be kidding me! I cannot recommend to license this application for deployment at my company unless its code is thoroughly refactored to use Dagger or at the very least Google Guice.

I can't even tell if this is sarcasm or not

Where/how does one learn to structure programs like this? Obviously I won't write fizzbuzz like this, but the point is it won't occur to me to structure a fizzbuzz solution like this. And if I can't produce such a structure for the dead simple case, then I can't trust myself to be able to architect an actual complex system where one does need to apply all these abstractions.

Are these skills only attainable from years of real-world experience?

people loves enterprise architecture jokes but all starts with some questions: what if I need to use the client datasource for the input numbers? what if a client ask to send the output to a network endpoint? to a printer?

so you start decoupling things. this here is played for fun, but if you need to build something that lasts 10 years across a multitude of clients instead of just as an one off project those question starts to be legitimate.

You should first learn about design patterns and then read Patterns of Enterprise Architecture by Martin Fowler. The book basically outlines how to think like this.

Just research SOLID and IOC and practice these in combination with a Java or C# or other OOP-inspired language. That will get you pretty close.

Effective Java is the best book I've read on the subject.

I love this project (having worked in a Java shop for a few years), but it does sadden me that it fails to compile. That would complete the joke.

This is clearly a hoax - there are no UML diagrams there (not up to date with the code - to be clear about this).

Big fan of fizz buzz. Edited / wrote / collected a (free open source) book titled "FizzBuzz (1, 2, Fizz, 4, Buzz,...) by Example - There's More Than One Way To Do It" [1] in the Yuki & Moto Press incl. functional, object-oriented, code-golf, and many more styles / versions. Happy fizz buzzing.

[1] https://yukimotopress.github.io/fizzbuzz

If you want another I did it purely with Lambdas in C# [1].

[1] https://github.com/tonyedgecombe/functionalfizzbuzz/blob/mas...

My python teacher asked us an implementation of the factorial function.

I did almost the same as you, bootstrapping almost every constructs in python lambdas, and then, before handing it to him, I put it all on one line.

But I'm a good person, in a comment above that line, I copy pasted the same line with 'lambda' replaced by 'λ'.

(I did not use church numerals and there were no strings involved)

wow, you weren't kidding. you bootstrapped all your constructs from pure lambda-calculus!

I award you Best Use of Dynamic.

I found it a useful exercise for teaching Rust: https://chrismorgan.info/blog/rust-fizzbuzz.html

On a more serious note.

What is the alternative to the OOP IOC SOLID multiple layers of abstraction way of doing things? Is this really the go to architecture for enterpire - or more appropriately, large projects? Why is it the go to architecture -- what are the alterntives? Suppose we're discussing a project in a non-typical OOP language (not Java/C#/C++), what is the architure of choice there?

Asking this as a junior developer

> Is this really the go to architecture for enterpire - or more appropriately, large projects?

You have to understand that the context in which this kind of architecture is needed is high-turnovers environments. Basically, in the 90's, managers at big corps - IBM, ATOS, etc... asked the question : "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

The answer to this is to heavily compartimentalize everything. Your manager tells you that you must implement a very particular behaviour in a very particular class ; you aren't meant to know what's happenning in other parts of the system.

I'd like to reframe this a bit:

> "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

What's really happening here is "how can we fire a whole team, hire a whole another team and have the new team be as productive as the old team was?"

You might think documentation, clean architecture, avoid feature creep etc... but what's really happening is that the old team is not productive by any absolute measurement.

I'd give a shot at this: https://fsharpforfunandprofit.com/

Pick the programming language of your choice.

No "Chain of possibilities" pattern?

Also, far too few classes with the word "Context" in the name.

Is there any technical paper on this somewhere on arxiv? I was trying to implement one of my own without all the enterprise abstractions and now I am stuck.

To me the best part of this is the Issues. "Change in business requirements" is probably my favorite

The Code of Conduct is a nice touch.

I don't think that part is a joke.

not over engineered by the least bit.

Too real...

And this is why I will never work in Enterprise again.

While Enterprise is always the go to for things like this, I think any time non technical people get involved in technical decisions the fun time begins. Just today I was told that I wasn't allowed to implement something in python just because it's "a scripting language"

I got that one too a couple of times. Always from people who have no understanding of tech or even interest in clean code or open source.

The enterprise developer seems to be people who don't even care about programming language because they don't feel strongly one way or the other about it, since they write shitty code anyway and don't have any passion for nice code.

That's terrible. What's worse, though, is when a supposedly technical manager, one who was actually an engineer once upon a time, micromanages at that level. I've seen it more than once.

If theoretically a developer chose to develop something in Python in my company that would be an automatic no. There are multiple reasons:

You would add an another language to support from the development to the operational support like monthly security updates. And that's a major risk and most companies won't take it.

If you leave the company then the company may have potentially unsupported app with noone capable of supporting it.

And seriously why would you pick python? Why not perl? Why not ruby?

The operational support you note is definitely something that should be evaluated, but if there is a "hard no" policy in place that is a negative indicator about the engineering organization to me.

Generally having a small number of implementation languages in use shouldn't be an issue. In fact, languages are tools and some are better suited than others to certain uses. If an organization supports products of even modest complexity odds are multiple languages and other technologies are required in order to make it work properly.

You are making the unwarranted assumption that Python isn't already used in the company.

> And seriously why would you pick python? Why not perl? Why not ruby?

FWIW, Python is the 4th most popular language on the TIOBE index (after C, C++, Java). It's not likely that $COMPANY is already using Python than Ruby or Perl.

I don't think anyone claimed that there are no valid reasons to decline a request to use Python.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact