This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (2)
- # babashka (11)
- # beginners (107)
- # calva (6)
- # cljsrn (18)
- # clojure (180)
- # clojure-australia (6)
- # clojure-europe (54)
- # clojure-losangeles (9)
- # clojure-nl (4)
- # clojure-uk (13)
- # clojureladies (1)
- # clojurescript (57)
- # clojureverse-ops (1)
- # consultantsdirectory (1)
- # cursive (48)
- # datomic (11)
- # defnpodcast (3)
- # degree9 (1)
- # deps-new (5)
- # depstar (21)
- # docker (2)
- # fulcro (15)
- # helix (32)
- # kaocha (1)
- # lsp (21)
- # malli (15)
- # meander (15)
- # news-and-articles (2)
- # nextjournal (1)
- # off-topic (42)
- # pathom (3)
- # podcasts (1)
- # polylith (73)
- # protojure (1)
- # re-frame (43)
- # reagent (1)
- # releases (1)
- # restql (1)
- # schema (1)
- # sci (1)
- # shadow-cljs (23)
- # spacemacs (7)
- # sql (5)
- # tools-deps (42)
- # vim (15)
- # xtdb (3)
Does a csrf token need to be contained in the html page content? Does making an ajax request that returns a csrf token after page load defeat the purpose?
Yes, or at least I don't see that approach working, because presumably you could request that csrf token without passing one in. Then http://evil.com could do that also, then send a bad request passing the token.
I realised a weird feeling of mine that I sometimes misinterpret. It typically comes up when I’m designing a program at a high level, top down, in terms of wishful thinking. The feeling can be described as my brain running in circles (sometimes it’s just walking or crawling though). Like a snake biting its own tail. I think it happens when I try to combine or unify things that don’t belong together in an attempt to simplyfy some model as in “everything is an X” or “this other thing is just an X with a Y”. I’m not sure why I have that instict in the first place, it certainly seems natural in some sense, like pattern matching? On one hand I feel like this is a strength of mine, I love seeing similarities in concepts and people have said that this is a bit of a defining characteristic of mine. I think it can have a lot of value. For example it is not unheard of that different fields have similar concepts, or shapes, but name them and maybe combine them differently, and recognizing this can lead to deeper understanding, because there might be solutions in some area that also apply to another but isn’t understood in their terminology or practice. But the other side of the coin is well, the above. In the worst case it is hard to let go of running in circles because I’m driven by a motivation to find these valuable paralells or new ways of modelling something. In less severe cases it simply blocks me of understanding something that might seem trivial, because I already tried to make a connection that may not seem to exist. I think this is very closely related to the type of job we’re doing. Mapping to and modelling processes and data in the small and large. Or at least it is part of it. Thinking about this and discussing this issue with other people might help. Can you relate? Is there a name for it? What do you think are good activities or strategies to exploit the value of this type of thinking and to mitigate the cost?
Can relate. I can't keep many balls in the air at a time, need a way to reduce things down. In terms of value gained, that's very specific to what's being done. But I think it's safe to say that you need to make it personal, what do you stand to gain or lose.
I definitely have the same tendency. Don’t have anything particularly helpful but looking for cognition research around conceptual metaphor might turn up the kind of thing you’re looking for. Ultimately I feel like I don’t really understand most things, software or otherwise, until I have metaphors to relate them to other things and sometimes those end up being superficial and sometimes incredibly valuable and not always immediately apparent which is which.
The book "element's of clojure" touches on this topic in a way.
It sounds like you’re describing “generalization”. I would highly recommend “How to solve it”. It’s applied to solving math problems, but the problem solving techniques are generally applicable. It covers lots of problem solving techniques.
The two main issues I see with generalization is putting a square peg in a round hole ( generalizing when it doesn’t actually apply) and conflating the interface that represents the generalization with a specific instance that conforms to the generalization
> I can’t keep many balls in the air at a time, need a way to reduce things down. @U0DJ4T5U1 Oh this might actually be one of the driving factors as well that I didn’t reflect on enough. But it certainly is part of the problem. I think one way to solve that specifically is to just write the damn code as dumb as it happens to be, and then play with it until understood. Then one can rewrite and design the thing correctly. Doing is understanding! > metaphors @U015879P2F8 Metaphors can sometimes help to break through something or understand some new aspect of it for sure. Then there is the other side of the coin where they become too dominant and distracting. I read Elements of Clojure, but I feel I didn’t understand it really in its entirety even though it is a short book. I might revisit it sometime again, I think the author is incredibly smart and was really onto something there. @U7RJTCH6J I think generalisation is what I was trying to get at, and a huge part of this (the other one being the above “can’t juggle too many things”. I have the book and I look forward to read it. I think I put it closer to the top of my list, seems attractive!
A concrete example of a generalization mistake is the large java interfaces. Instead of lots of small interfaces, streams and collection have interfaces with large numbers of methods. To create an instance, it’s not uncommon to have to stub multiple unnecessary methods.
In my experience, where the urge to abstract/generalize prematurely really gets me into trouble is when I'm operating in an unfamiliar setting, when I don't have background knowledge and I'm trying to hold all the concrete cases I'm thinking about in my head alongside the hazy abstraction that I think I'm reaching towards. This feels unproductive and frustrating because while it seems like work, in actuality all I'm doing is overloading my working memory by trying to juggle too many things at once. https://www.manning.com/books/the-programmers-brain talks about the impact an overwhelmed working memory can have on the practice of programming.
I'd also recommend Daniel Jackson's paper https://groups.csail.mit.edu/sdg/pubs/2015/concept-essay.pdf because it tries to balance the obvious need for concepts in organizing software with the also-obvious caveat that concepts for concepts' sake are not helpful. He suggests grounding concepts in "a single compelling purpose."
Oh I like the term “operational principle” because it really touches on the practicality of something in a very direct sense. One way to get out of overthinking things is to “operationalise”, meaning to break something down into actionable steps. It really helps to get going when one is out of flow. Focusing on what you “do” instead of an idea is the key here. It is also reflected in guidelines, where a short explanation or advertisement of a thing is proposed “you can do X and then you do Y so Z happens” to convince yourself or others of its utility. Thank you for the suggestion @UFTRLDZEW!
I was also going to mention a book of Daniel Jackson's from last year called Design by Concept, but it seems to be out of print. I'm wondering if the content of the book he apparently published this year https://press.princeton.edu/books/hardcover/9780691225388/the-essence-of-software is essentially the same.
@UFTRLDZEW I think the crave to generalize is a problem in our industry, and one I think I see in smart, but inexperienced people. IMO we tend to look for generalizations, which again IMO complicate matters, rather than writing code to the specifics at hand. I seem to remember a booking system where everything was an object which belonged to another object and so forth. Which is super general, but for the use case of a resort, hotel, and room, was way too general.
So, with experience comes the ability to judge when to solve the general case and when to only deal with the specifics of the task at hand.
And, lastly, I really don’t like it when devs say oh, we can make this generic thingamajigger. Then I know we’re in for some useless abstraction which doesn’t really solve the specific problem we need to have solved.
@U04V5VAUN I'm reminded of Nathan Marz's essay http://nathanmarz.com/blog/suffering-oriented-programming.html: > There's a certain evolution most programmers go through. You start off struggling to get things to work and have absolutely no structure to your code. Code is sloppy and copy/pasting is prevalent. Eventually you learn about the benefits of structured programming and sharing logic as much as possible. Then you learn about making generic abstractions and using encapsulation to make it easier to reason about systems. Then you become obsessed with making all your code generic, with making things extensible to future-proof your programs. > > Suffering-oriented programming rejects that you can effectively anticipate needs you don't currently have. It recognizes that attempts to make things generic without a deep understanding of the problem domain will lead to complexity and waste. Designs must always be driven by real, tangible use cases.
I was taught systems (cybernetics specifically) before programming, and one emphasis was the balance of making distinctions (all information takes the form of some distinction) and generalizing (being able to generalize means strategically removing distinctions - pretending things that are different are instead the same - for ease of modeling)
@U051SS2EU Interesting, what sort of strategies did you learn?
@UR37CBF8D that's pretty big and open ended to answer here... the main focus was on making analogs (where an analog has the right parts and relationships to model some system) and using systems to find tools from one domain that could help solve problems in another domain.
Would anyone like to work on some open source issues with me? I'm looking at a clj kondo ticket at the moment.
which ticket are you looking at, friend?
Lol. I appreciate that, you would obviously be very helpful. ;). I'm also curious to see how other people tackle issues. Move through code, etc.
@U3ES97LAC I'll link in a second. Taking a walk.
@U3ES97LAC this is the issue, which i see borkdude commented on. https://github.com/clj-kondo/clj-kondo/issues/426 I understand the instructions, but not how it would fit within the implementation. Specifically, i'm not sure how to conditionally branch to the "after loop" state. Getting into the code I assume this would happen in clj-kond.imp.analyzer/`analyze-call` but i'm not confident. I'm also not sure how to gain confidence, which is maybe the larger issue :0.
@U9VP9VCE6 ping me when ever you have time this week 🙂
@U0DJ4T5U1 a hint: after analyze-children all of the children nodes are analyzed. if you would in the analysis of one of the children perform a side effect, then you would see that side effect after you have analyzed the children
@U04V15CAJ thanks, ill look into that function. I thought calling that would have the same issue as find-children as it would walk the tree (children). Which was already been done by some other control flow, which is where i assumed i needed to inject the matching logic.
well, the children are analyzed in
analyze-like-let, it doesn't matter, as long as they are processed. but after the processing the side effect will have happened.
The children nodes are analyzed only once. But during that analysis, there are side effects.
do we need to save where the
recurs occur? or is that somehow handled automatically?
@U3ES97LAC I recommend checking out how that is done for all other linters, there's abundant examples of that
Okay, thanks 😄