I'm curious to hear what this community sees as pros and cons of leetcode. If people are willing, I'd like to hear in thread comments simple summaries of what people like or not about leetcode. (I don't think this question would lead to flame wars or anything, so please don't prove me wrong about that 😛 )

artificial code puzzles/challenges that bear no resemblance to real world work disrespect the applicants time and intelligence and cause undue stress while proving nothing whatsoever about a prospective hire's actual ability to perform the job in question

at best it's a waste of time and money, at worst it's protectionism and gatekeeping, and either way it's a poor signal to prospective applicants about a company's attitude towards its employees

ah. I was assuming that the main usage of leetcode is by people learning how to code for the first time. But I do know that it's used in interviews as well. I agree about avoiding leetcode for interviews. I would think leetcode still serves a place for people learning to code. As I am beginning to learn clojure now, if there is any leetcode-like thing that uses clojure, that seems like a fun way to become familiar with the basics of the language, personally. Not that leetcode would replace building personal projects as a way of learning the language though.

Codewars and exercism both have Clojure I believe, and without the same attachment to use as an employee testing method.

I think I will write an article to describe my reasons. In short, I think that companies prefer Leetcode because it's tasks/puzzles are more relevant. In my experience, while Leeocode's middle difficulty task tries to find out that dev knows that HashMap query by key is O(1) effectively, Codewars's task tries to find out, if dev knows a lot of math formulas. And both Leetcode and Codewars are good in providing concise examples. For example, I first solved https://www.codewars.com/kata/513e08acc600c94f01000001/clojure with about 15 lines of code, but found that there is a better solution with just 4 lines with better performance:

(defn valid [v]
  (int (max 0 (min 255 v))))

(defn rgb [r g b] 
  (apply format "%02X%02X%02X" (map valid [r g b])))

leetcode is a much less interesting eurler project https://projecteuler.net/ but i think leetcode is pretty good for people who want to get into programming and want to explore some basic concepts.

None of this discussion belongs in #clojure -- it might be appropriate for #jobs-discuss in terms of the validity of employers using it, or #off-topic -- @UL05W6AEM Feel free to repost your Reddit link in #off-topic but I'm deleting it from here

I'm also deleting the lead post in this thread as being off-topic for this channel (esp. since it is now responding to posts that have been deleted).

Hello, @U07FCNURX. Is there a possibility to watch files on disk and make stasis reload them? I'm not sure this is in the docs.

But I'm probably missing something.

Make sure you're using functions in the site-index map. If you post your code I can take a look.

Yes, absolutely. Use stasis/serve-pages . https://github.com/magnars/stasis#serving-live-pages-locally

Use clojure tools logging. It's a facade over a few different logging libs and the consumers can set their preference

Don't make a choice. If you use that they can use whatever they like

But also, just don't have logging is a good option. Instead of logging, return important events/errors to the user of the library and let them choose what to do, log or not, for example.

@U0K064KQV Returning out-of-band information like running times and such via function returns instead of logging it is just so darn inconvenient. And I am not using this for reporting important events and errors. I already do that via exceptions mostly. This is for trace information. User of my library might feel that certain callbacks and such they registered with me should be fired in their scenario but they don’t. Trace level logs allow them to trace the decisions made by the library.

It might be a personal preference, but I really hate libraries that log.

You said you already support callbacks, why not add a trace callback, pass it a function that it calls on each trace with the details, user can do what they want with it, even log it.

I can't imagine some library that logs without giving configuration. Lots of libs I would for sure want to log

If they provide config, and properly make the log dependencies optional, so they don't always bring them in, sure. I still think its an annoying way to debug a lib.

If they have a callback, I can just pass a fn that prints it and now I can debug from the REPL, no log files involved

I do wonder if tap> could be something that can get traction here. As I understand, it is mostly meant for debug-like info, could be a simple way for libs to report debug events by having an option to tap>

The introduction of the feature does say: > tap is a shared, globally accessible system for distributing a series of informational or diagnostic values to a set of (presumably effectful) handler functions. It can be used as a better debug prn, or for facilities like logging etc.

I would find that limiting. Logging lets me set levels on each message to curate how much information comes. This level is also configurable per namespace. I can have fatal level info from my sql library but debug level information from my http client. Tap would prevent that

I can also have multiple outputs: files, consoles, etc and each at different levels

Don't think tap prevents that, you can tap whatever you want, you can easily tap a map like: {:level :fatal, :ns foo.bat, :msg "something something"}

Then add-tap and do whatever you want with that, log them, filter some of them, print them, etc.

It looks like next.jdbc does what I was first suggesting: https://github.com/seancorfield/next-jdbc/blob/7d5ee09e793720ed4f650dbc3762a3130f030296/doc/getting-started.md#logging You can provide a callback for logs, and then you can do whatever you want, like print them to out, don't actually need to log them to a file.

Anyways, I don't think either ways are objectively better, so just a preference. I personally favor what next.jdbc does, letting the user inject its own function for traces and do whatever it wants with it. But defaulting to tools.logging will probably be fine in most cases, since people will likely use it or use Timbre, the latter having support for tools.logging as well.

That said, I'd setup your dependency so you don't force people to have tools.logging. Like don't bring it in as a deps, maybe use a requiring-resolve only if people turn on logging, and expect the user to add tools.logging to their deps.

So people who don't want it are not force to have it as a deps just to use your lib.