Use Shopify. All of this is taken care of for you.

Disclaimer: I work for Shopify.

VS Code.

@shredEngineer it's not his browser history that he should be worried about, it's the web server logs. The request will be logged and the password will be stored in clear text. If the logs fall in the wrong hands then it's a bad day for everyone.

42 and still learning; also I wouldn't give up programming for anything else.

Sounds like your company is lacking a proper code review process.

@azzuwan It's funny that I actually had a rant that talks about almost this exact topic (but coming from a CQRS/ES angle):

https://www.devrant.io/rants/225640

I strongly believe that "rich" OO domain models are the wrong way to go about modeling the world. I prefer a more functional approach, where entities are "anemic" and get threaded through functional units that implement business logic use cases.

@undefined I can understand why some people prefer dynamic typing. Static type systems can sometimes get in your way while developing, requiring you to fully specify interface contract types, which is not sometimes desirable, e.g. in situations where you are building a framework that has to infer types at runtime based on user-defined schemas. It's much easier to deal with this kind of problem in a dynamic language. Dynamic languages also lets you "monkey patch" base library classes, a useful feature that has to be dealt with extreme caution, and sometimes gets abused in a bad way.

Overall, though, I still believe the benefits of type systems outweigh the cost you pay when trying to make the compiler happy. One particular language that I started enjoying recently is F#, which is statically typed, but require less type annotation than C#, making the code more readable and easier to write (not always), among many other benefits.

@h3ll I know we could go on forever, my point was to share my frustration with the devrant community. Thanks for sharing your thoughts.

The primary resources I found were some presentations from Chris Richardson, blog articles from Lev Gorodinski, Jimmy Bogard, and Debasish Ghosh, and of course Greg Young. There's also a google group for CQRS/DDD.

Overall there's a niche community, but it's fragmented and they follow similar but different tracks. I feel if this paradigm will take off, it needs a big force (read: google, microsoft, facebook, etc) behind it, which I don't see happening any time soon. So I'll be over there in my corner trying to figure this out.

@hasselsoff I'll admit that I suck at interacting with the tech and open source community, let alone start an initiative around my ideas. I thought of starting a blog, but I still lack the experience to back my ideas. That's why I'm still in the research phase. Maybe one day.

As for Elixir and Erlang, I've heard some good things, but haven't explored them yet. I guess many devs are suffering from language/framework proliferation fatigue, and I'm no exception.

(cont) lagom, akka, cassandra, kafka, samza, datomic, etc may help inspire me, but I'm still trying to find the design philosophy and the associated principles and patterns that transcend all those technologies, and bring many of those ideas together. Kind of similar to how relational algebra embodies a way of thinking about and modeling and querying data; then choosing a sql database becomes a secondary concern.

@h3ll those are nice examples of frameworks or tech that attempt to go into some of the directions i mentioned. What I'm after is not yet another stack. I'm after a design philosophy that accentuates the domain and makes the use cases it's trying to serve prominent, instead of being buried down and eclipsed by what the framework or tech forces you to do.

Yes persistence is always going to be important, but you need to think that, e.g., immutable events is what should be stored, not mutable entities. Now should i use a sql store to store events? Maybe. But it's secondary to the main concept.

The same for the domain itself. DDD favors rich domain models, but i think this makes domain entities complex and may lead you to put logic that serves many use cases in the same object. I favor a functional approach where entities are "anaemic" and they get threaded through functional units, each implementing a separate use case.

@h3ll I came across lagom in the past but didn't spend time investigating it. I'll check it out.

And don't get me started on microservices. It's a nice idea for some organizations, but I think it's been taken too far.

I value simplicity that results from separating logic from data. Microservices seem to take OO to the extreme where every class is a service.

@h3ll glad that there are others who think in the same way.

The various concepts are well known, but in isolation. The CQRS/ES community is small but it does exist. The FP and immutability community exists across many languages and frameworks. Reusable domains are basically hexagonal architecture. Where I don't find resources is functional domains and authorization, and of course tying everything together.

I think this tells me that my view of the world is not mainstream, but that it's based on somewhat well defined, but isolated, ideas.

Maybe you're afraid of commitment?

The breadboard and the wire look like a ... never mind.

@bp85 then definitely don't do it.

FWIW, I've been using ruby + bash on (ubuntu on) windows for a while now without any problems.

This should be tagged NSFW.

That wouldn't be an issue for those using dynamic languages. Oh wait .. damn you linter!

@dyedgreen Thank you. I can finally put a name to it.

VS Code

@danglingPointer here it means developers who care about unit tests only, not some other group separate from the developers who wrote the code