This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-10
Channels
- # announcements (5)
- # aws (18)
- # babashka (1)
- # beginners (81)
- # calva (7)
- # chlorine-clover (1)
- # cider (5)
- # cljs-dev (8)
- # clojure (125)
- # clojure-dev (1)
- # clojure-europe (31)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-norway (1)
- # clojure-spec (5)
- # clojure-sweden (1)
- # clojure-uk (31)
- # clojurescript (85)
- # code-reviews (1)
- # core-async (17)
- # cursive (39)
- # datomic (16)
- # emacs (1)
- # fulcro (6)
- # java (16)
- # kaocha (2)
- # luminus (4)
- # malli (2)
- # off-topic (65)
- # pathom (3)
- # re-frame (11)
- # reagent (5)
- # remote-jobs (1)
- # rum (5)
- # sci (10)
- # shadow-cljs (24)
- # spacemacs (4)
- # test-check (3)
- # tools-deps (22)
- # xtdb (15)
(defn call-super-method [instance name & args]
(when (nil? *calling-context*)
(throw (RuntimeException. "Cannot call a super method outside of an instance method.")))
(when (not= (:identity instance) (:identity (:instance *calling-context*)))
(throw (RuntimeException. "Super needs to be called on the original instance in the chain.")))
(let [{:keys [resolved-on]} *calling-context*]
(loop [resolution-order (mro (:class instance))]
(if (<= (count resolution-order) 1)
(throw (RuntimeException. "No next class found in the hierarchy."))
(if (= (:identity (first resolution-order))
(:identity resolved-on))
(loop [remaining-classes (rest resolution-order)]
(if (empty? remaining-classes)
(throw (RuntimeException. (str "No method named " name " was found.")))
(let [top-of-order-methods @(:methods (first remaining-classes))]
(if (contains? top-of-order-methods name)
(binding [*calling-context* {:instance instance
:resolved-on (first remaining-classes)}]
(apply (get top-of-order-methods name)
(cons instance args)))
(recur (rest remaining-classes))))))
(recur (rest resolution-order)))))))Working with data in Go like:
fileChecksum := content.(map[string]interface{})["vars"].(map[string]interface{})[checksumVar].(map[string]interface{})["value"].(string)contentMap := content.(map[string]map[string]map[string]interface{})
fileChecksum := contentMap["vars"][checksumVar]["value"].(string)I never really understood the unit test craze where everyone needs 100% unit test coverage. I'd argue that integration tests (rest / ui / system) have way more value and last longer too. Unit tests are pretty okay for libraries, but everything that is integrated into something needs more extensive testing without mocking all the things. Even though unit tests are like 1000 times faster I still prefer integration tests for them. The main reason I think is that integration tests test your application interface, which ideally should not change and if it changes it should only change in non breaking ways. This means, these tests will last for the lifetime of your application. While unit tests are often implementation dependent and will have higher turnaround compared to your integration tests.
this is something I have a lot of thoughts and feelings on 😄 yes, tests that are more towards the integration end of the spectrum are better at actually showing that your app/system does something useful. Some people only write end-to-end tests and are very happy with that. Some people are not, because they are - slower (not a good feedback loop) - harder to write (requires more setup and coordination) - tend to be more flaky (an unreliable test can be worse than no tests at all, as it sucks up mental resources) - often don't provide good feedback when they fail - need a lot of maintenance if your system is still evolving - can only ever cover a tiny subset of possible application states There's no one size fits all, there is often a sweet spot you can find where you are testing a pretty good slice of your stack without making it too hard on your self.
I do have too, mostly because my team recently decided to go with 80% code coverage for unit tests and I started thinking and reading a lot about it. This is after we had ~20% unit test coverage for code written in the last ten years. So, from my point of view a totally unreasonable goal. Anyway our overall product quality is pretty good, so that amount of unit test coverage seems to be pretty good, given the fact we have way more integration / system test overall. > tend to be more flaky (an unreliable test can be worse than no tests at all, as it sucks up mental resources) Because this is true, we work super hard on making them reliable and independent, so they fail as seldom as possible and if they fail, every developer can run that test on his machine without having to do manual steps. That makes integration tests a bit more bearable.
yeah and that's the thing, doing integration tests well means some people on the team investing a lot of time into having a good and reliable harness and patterns so people can just write and run them with minimal fuzz
That said, we have three QA people in our team, so we are in a pretty comfortable situation, but, it pays off in product quality.
Yes, unit tests are good for testing non trivial logic, integration tests provide more value for applications
Top comment from here: https://news.ycombinator.com/item?id=23778878 I tend to mentally divide code into roughly two types: “computational” and “plumbing”. Computational code handles your business logic. This is usually in the minority in a typical codebase. What it does is quite well defined and usually benefits a lot from unit tests (“is this doing what we intended”). Happily, it changes less often than plumbing code, so unit tests tend to stay valuable and need little modification. Plumbing code is everything else, and mainly involves moving information from place to place. This includes database access, moving data between components, conveying information from the end user, and so on. Unit tests here are next to useless because a) you’d have to mock everything out b) this type of code seems to change frequently and c) it has a less clearly defined behavior. What you really want to test with plumbing code is “does it work”, which is handled by integration and system tests.
In the context of an enterprise-y product, not all users of the web-app can do all the actions on all the things. So there’s a need for a permissions layer that can a) guard against improper usage of APIs (e.g. return Unauthorized codes) and b) can conditionally hide/show UI elements (i.e. if I can’t delete something, don’t show me a delete button, or show it disabled…). Are there example of good patterns of this that I can study?
In the context of a CLJ/CLJS app, it’s tempting to try and write the code in .cljc files but for a lot of this kind of logic you need DB access... and frontend can’t block on IO so the code needs to be async and it becomes crappy very quickly.
I’m currently thinking of a “permissions” API endpoint that the UI can use (using GraphQL, but the pattern applies to REST as well I think) that returns just various keywords that are fine-grained permissions. The logic of the calculation stays on the server, which probably means you can reuse the underlying code for both serving the UI and guarding the actual API actions.
In my experience fine grained permissions approach work really well. I generally use the structure -> Users have roles, and roles have permissions. Roles can be edited/added for fine grain permissions.
Yeah having roles be bags of fine-grained permissions makes so much sense: you can make new roles, you can assign roles to groups or individuals, you can combine roles and you get the union of permissions…
@bsvin33t That matches exactly what I mean and what I think brings the most test value...Thanks for that link
(defclass
Apple []
(fn [this]
(write-slot this :color "red")
(write-slot this :tasty "maybe")))
(add-method
Apple :color
(fn [this]
(read-slot this :color)))
(add-method
Apple :tasty
(fn [this]
(read-slot this :tasty)))
(defclass
RedDelicious [Apple]
(fn [this]
(call-super-initializer this)
(write-slot this :tasty "yes")))
(add-method
RedDelicious :color
(fn [this]
(str "Extremely "
(call-super-method this :color))))(def r (make-instance RedDelicious))
(def a (make-instance Apple))
(call-method a :color)
=> "red"
(call-method r :color)
=> "Extremely red"
(call-method a :tasty)
=> "maybe"
(call-method r :tasty)
=> "yes"this supports multiple inheritance with the same method resolution algorithm python uses
After billions of years of evolution life did not produce "multiple inheritance" (for n > 2). Seems like a good indicator that it's a bad idea
just because something hasn't happened by itself, doesn't mean it's a bad idea 🙂 this is the naturalistic fallacy in disguise (note, I am not disagreeing that it's a bad idea, it's just noting that this joke is not funny for me 🙂 )
if you define a species as things that can reproduce then I'd say it still counts as one species 🙂
@U051V5LLP I think you should ask a practicing biologist for a species definition for a nice surprise 🙂
anyway. I'm all in favor of side-stepping evolution to create novel things. one interesting example comparing planes to birds: evolution did not produce a titanium bird.
Well it’s also not strictly true (as far as I know, also not really a biologist) because horizontal gene transfer does exist, which would be a way of having multiple inheritance in biology. (I still don’t like it in code though) For a very dry reading of the subject: https://en.wikipedia.org/wiki/Horizontal_gene_transfer
oooh thanks for the info @UGFL22X0Q now if we could get a HGT library for clojure..
err, looks like we already have it 😛 > ...mechanisms of HGT such as https://en.wikipedia.org/wiki/Transformation_(genetics), https://en.wikipedia.org/wiki/Transduction_(genetics) and https://en.wikipedia.org/wiki/Conjugation_(genetics),
meta-comment. good way to learn something new: make a strong-headed/narrow-viewed comment without any qualifiers in a public forum 🙂
The meanings of the word "inheritance" are completely different here. Applying what we know about one to the other is highly suspect.
Ah, I see this point was already made above. I wouldn't say they have 0 to do with each other -- but it is more like an analogy than anything closer to "these are the same thing, therefore we use the same word for them"
A completely alternate view is that billions of years of evolution did produce multiple inheritance, because it produced humans, a few of whom invented multiple inheritance 🙂
All of our cells have mitochondria and bits and pieces from a ton of viruses over time.
yeah, now that you mention it, the theory is that multicellular organisms evolved when one single cell organism didn't digest the other, but started working together. so we have two sets of DNA in most of our cells.
You could even say it didn't produce multiple inheritance at all if 'n' is the number of species
hello everybody. I finished high school last year and I have decided to enroll in an institute of technology to study computing/informatics. my decision is rooted in the fact that I can only afford this (with the generous help of my hard working mother as well). I have a question regarding this. for those of you who are recruiters, are people from institutes of technology looked in a less favorable way in comparison to those that attended university. obviously there are more factors to consider when reviewing an application, but I'm curious to know how are non-university graduates perceived. ps: apologies for the grammar mistakes as English isn't my first language. I'm very much looking forward to everyone's input on the matter.
Recruiters really don’t tend to care, since they are in desperate need of people regardless, do your best to show that you can learn and do the job. I can almost guarantee you’ll be fine.
if you're sufficiently motivated and can show concrete results, you don't even need the formal credentials from what I've seen - it can affect the starting pay at your first job, but very quickly what matters is job performance rather than credentials (of course there's variance between companies, but in the US credentials are only looked at closely for juniors in my experience)
if the institute of technology can help you go for it, but think more about the skills you can prove yourself with, and less about the piece of paper you get
(I make 6 figures in the US, barely graduated highschool in an alternative diversion program for poorly performing students, never enrolled in higher ed)
For a first job, having some open source projects you can show as examples of your work is likely to carry significant weight. It doesn't have to be your own project that you started, either -- it could be good to show teamwork if you collaborate with others on an existing project, and demonstrate some ability that way.
Also, for a first job, a friend who you have collaborated with who is already employed and proved themselves helps too. You can build that kind of collaborative relationship at a tech school, a regular school with tech classes, or in open source.
and it's not just "networking" - it's building those collaborative skills so you can start doing the hard part - working with others, and working on goals that are shared and negotiated
As a hiring manager for about 25 years, my opinion is that your education doesn't matter once you're about five years into your career. Also, from my p.o.v. if hiring a new graduate, I wouldn't care whether you went to university or a tech institute or a polytech or any other "higher education" place. But I'm unusual in the hiring world, so I've been told.
the only thing that differs from my experience there is the 5 year cutoff, maybe it's because I used collaborators as job leads though
@U051SS2EU Can you elaborate? "about five" years of work experience seems to get everyone on roughly the same page (unless you're in a vertical that is comp sci heavy in some way).
I probably misunderstood what you meant
(seems to be a problem for me today -- everyone is misunderstanding me 🙂 )
@U016Z78BJ3W good luck with the comp sci/informatics course and good luck getting a job afterwards -- and I hope you continue to do Clojure for fun and keep checking in here as you go!