FizzBuzz Enterprise Edition
fizzbuzz.enterprises
fizzbuzz.enterprises
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.
We have a proprietary method for up-converting it before bidding on military contracts.
But there are so many flavors of CSV file to choose from. So I’d have to make that pluggable too.
Because of course
I'd really like to see the microservice version of that.
It misses Cucumber BTW
* 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.
Event based programming in technology like stack is more appropriate for this kind of problem domain...
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.
Are these skills only attainable from years of real-world experience?
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.
[1] https://github.com/tonyedgecombe/functionalfizzbuzz/blob/mas...
I award you Best Use of Dynamic.
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)
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
Pick the programming language of your choice.
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.
> "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.
Also, far too few classes with the word "Context" in the name.
Eh... this guy is right, ant is better.
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.
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?
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.
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.