Clojurians Log v2

I've got a fair amount of experience in the "Clojure web" space; don't hesitate to ask any question if something is blocking you. I can't give you more time if that's the blocker, but otherwise I'd recommend trying to write some code over watching more videos. (I understand that "time available for listening" is not the same as "time available to sit down and code".)

Thank you for your offer, @gaverhae. At the moment my biggest issue is time and energy allocation. In addition to supporting myself - I build websites for a living - I'm a full time caregiver for my father. So time and energy are pretty limited. In addition to watching/listening to videos and podcasts when I can I try to do some Clojure everyday. My progress is slower than I'd like, but I'm happy with it given the circumstances.

Well, thank you for reminding me why I don't watch his stuff. He has a tendency to talk way too much and say way too little. And quite a bit of said things will be wishy-washy things like "you gotta have boundaries". The main points of the whole 73 minute talk: 1. Don't propagate concepts farther than needed. E.g. don't push HTTP-related stuff deeper into your code than handlers, don't push DB-related stuff outside of functions that retrieve data, etc. 2. There should be a judicial separation of concerns (yes, also wishy-washy, but I myself would be thrilled to learn if there are any concrete universal steps to achieve it in a context-independent way) 3. Faster tests are better 4. Relying in frameworks should not be the default 5. Use IoC - e.g. don't make the core of your app access the DB directly, instead provide it with a set of functions to be called to get the required data (could be as narrow as get-user-by-id, could be a generic query that doesn't tie you to the fact that you're using a DB That's it, that's the whole talk. Useful parts of it, anyway. IMO, of course.

Oh, and there's a point on which I vehemently disagree with him. "You don't want to test your whole system" - yes I do. I can abstract everything to hell and back, have 100% test coverage, and then the real app breaks because of some stupid race condition or something like that. Components should be testable in a more or less independent way, but it doesn't mean that you don't need to test the whole thing.

Disclaimer: I haven't watched this particular talk, but I do know that "Uncle Bob" has given lots of dubious advice in the past, so I'm inclined to be skeptical. But honestly, I'd say when you're starting out, it doesn't even necessarily matter if the advice for "building clean, scalable systems" is perfect advice and should be followed 100% of the time in a production system. If you're learning you're not building a production system! My advice is "don't worry about it too much." Just think about what you want to do with Clojure and try to do it, and get specific advice about specific problems when you get stuck rather than general principles like "clean architecture." I think the best thing to do is just try to https://tonsky.me/blog/concrete-vs-abstract/ rather than get hung up on whether you're doing things the "right" or "clean" or "scalable" way. Your first drawings won't be perfect when learning to draw. Don't expect your first apps to be.

The most interesting part to me was not relying on frameworks and focusing on the problem(s) you're trying to solve and that that should be decoupled from a framework if you use one. I know people have very mixed opinions about him and his thoughts on programming. I don't know enough to have strong opinions about any of this. Regardless, it was worth listening to while cooking. I'm not big on hero worship or dogma and find a lot of people - famous and well regarded ones that that - to be full of poo. So I try to take just about everything with a grain of salt. I also find I do learn things from people that I vehemently disagree with. It helps me sharpen my thinking about things and sometimes I even change my mind. In the end, I think Bruce Lee nailed it: "Absorb what is useful, discard the rest". Thank you for the thoughts and the link @p-himik and @afoltzm. I appreciate critical minds!

Regarding frameworks - in general, it's a good point, but it's also full of nuance. Especially given that the word "framework" doesn't have a well-defined meaning that everyone adheres to. If you're certain that a particular framework will be a net positive for a project, just use it. If you have serious doubts, just don't use it at all. If you're somewhere in the middle, maybe build an architecturally toy version of your app and see if the framework is suitable for that. Otherwise, you risk rejecting something you could've benefited from, writing a lot of boilerplate that's already been written, only to then discard it and end up using the thing you'd rejected at the start.

That makes a lot of sense. From what I've read Clojurists tend to not be big into frameworks. I'm aware of Luminus, Kit, and Biff but they seem to be not quite as "full featured" as Rails and Laravel (the two I have the most, but not a lot, of experience with). I can also see that leaning on a framework could be good for businesses and organizations to keep some continuity between developers. But that's not something I can speak to from experience. I do have some apps I want to build, but I'm mostly doing this for fun. The more I learn the more fun I have. Even better if what I'm doing changes how I think about things. Clojure's already done that and I'm still getting comfortable (wrestling?) with the basics.

@afoltzm from the article you linked: "The advice is simple: don’t solve a problem you don’t have." This is very true and extends well beyond programming. There are a few people in my life that would be better off if they internalized this. Thanks for the link.

> The most interesting part to me was not relying on frameworks and focusing on the problem(s) you're trying to solve and that that should be decoupled from a framework if you use one. Robert Martin spent a lot of time in the Rails world when Rails was new and attracted a lot of beginning "Rails" (not "Ruby") developers. He's a consultant so I presume he's done a fair bit of cleaning up after those. I think that colours quite a bit the emphasis he puts on writing "business logic" outside of "frameworks". https://www.youtube.com/watch?v=WpkDN78P884 of his had quite an impact on my way back when, though I was fairly new then and hadn't discovered Clojure yet. I'm not entirely sure what I'd think about it today. If you're browsing for general advice and contrarian viewpoints to form your own opinion, I'd also suggest listening to https://www.youtube.com/watch?v=lz451zUlF-k, who is pretty much the only person I know of who deliberately tries to gather empirical evidence on software architecture. He disagrees with Robert Martin on a lot of topics.

Thank you for the links I appreciate it. I'll definitely check them out. I'm mostly interested in learning about Clojure at the moment. I don't have much of an agenda beyond that, though I do have some webapps I'd like to build. I'm a ways off from that though for a variety of reasons. The video I posted showed up on my Youtube feed and a few commenters called it a must watch. Admittedly, the top comments were old, but it was enough to get me to throw it on while cooking. Most of the programming videos I'm watching these days are Clojure specific.