You can use (partition-by identity [1 1 2 2 3 3 4 4]) From .core

@U04BQTA73C2 Thanks! One more question, how can I turn the returned list, from partition-by into a vector? Tried (into [] (partition-by identity [1 1 2 3 3 4 5 6 7])) but it only converted the outer list.

Or, is it possible to make partition-by return vector?

I’d do:

(->>
(partition-by identity [1 1 2 2 3 3 4 4])
(mapv vec))

@U04BQTA73C2 Thank you, so much! This was so helpful!

Sure 😁

I thought I'd take a shot at converting this to a transducer:

(into [] (comp (partition-by identity)
               (map vec)) [1 1 2 2 3 3 4 4])

Kit largely builds on Luminus which is pretty mature at this point, and it is getting use in production today. Kit is designed that the core of it is extremely light, when you make the base project all it creates is an HTTP handler and the router. Things like migrations can be added to the project as need arises. I recommend watching this intro for Kit as it explains the general structure, how Integrant is used, and shows how to add features as you go https://www.youtube.com/watch?v=DFzukK5-rpU

working through an intro project can also be helpful https://kit-clj.github.io/docs/guestbook.html

It's probably also worth noting that Luminus and Kit aren't really "frameworks" in the traditional sense you find in other languages -- they are curated collections of libraries that work well together, and the templates behind Luminus and Kit are mostly ways to "automate" a lot of the boilerplate code needed to wire those libraries together.

I don't particularly like some of the libraries that Luminus and Kit have standardized around so I still prefer to build web apps "from scratch". I prefer Component over Integrant, for example.

One big reason for the choice to use Integrant in Kit is that it plays really well with Aero allowing describing the whole system using a single EDN file. All the configuration and resource declarations are described in a single place making it easy to see all the relationships, and set flags for dev/test/prod configurations there.

I do think these kinds of projects provide less value for seasoned devs though. If you already have a set of libraries you like to use, it’s easy enough to make your own template around them. The main goal is to hopefully remove some barriers for newcomers and make some choices that will get them set on a good track.

We've just switched to Aero at work (from our two(!) custom configuration libraries that we built over the years) and it is very nice.

yeah I like it quite a bit as well, it makes really good use of reader macros

If we ever replace our custom SQL migration code, I suspect we'll adopt Migratus 🙂

Back to @U0DCK21EJ’s original Q: the libraries that are curated into Luminus and Kit are heavily used in production -- and are far more widespread than just in the Luminus and Kit templates.

that makes sense -- I've built my own version of things that do things like migrate SQL schemas and such. If there's any library I'm looking for, it'd be for single sign on and things like that

my experience with clojure frameworks and most clojure libraries is that I have to read most of the code my app touches to figure out issues in documentation, or I have to put debuggers in the framework code, just to figure out if I'm doing something wrong, or the framework has a bug. it is very hard to determine what side a bug lies on in this case. so if you find yourself trusting the documentation of your current framework, and you aren't constantly running into framework bugs, you should probably not switch.

so the other thing I noticed is that Leiningen seems to be on the out, and there's lots of clojure tools and deps.edn. Is that the trend?

depends what you are trying to do. lein, boot, and deps have pros and cons

well, I've got a few different projects in flight... one is a personal one, published to heroku. The others are more like microservices, notebooks, and little data science environments shared with my team

I personally prefer deps. but I have not seen many clojure libs use deps

If you have projects based on Leiningen that are working, continue using lein in those projects. For new projects, I would recommend the Clojure CLI and deps.edn because that has the support of the core team. The 2022 State of Clojure survey (published back in June) showed that Leiningen usage had dropped from 94% in 2018 to 69% by this year while deps.edn has grown to 64% (it was only introduced in 2018).

trying deps out is pretty pain free compared to switching web frameworks. so, try it out. you can both lein and deps in the same project

We started with lein back in 2010 because it was the only option. We switched to Boot in 2015 because Leiningen was too limited for the sort of programmatic build stuff we needed at work, but we ran into limitations and bugs in boot and switched to the CLI in 2018. It works well for us -- we have 134K lines of Clojure in a monorepo with 170+ deps.edn files (we have a lot of subprojects!).

yeah I'm kinda worried that clojure cli/tools/deps is going to leave lein in the dust, and it will be like 2004 and ant-vs-maven, or later maven-vs-gradle

maven-vs-gradle probably a better analogy

I think over time you will see lein usage continue to decline. It's served us well.

The original creator and maintainer of Leiningen moved on to other tech. I'm not sure how active the current maintainer is. But Leiningen is very mature and stable at this point so as long as someone is able/willing to update it to run on new JDKs and with new versions of Clojure, it'll continue to be useful into the future.

ahh

FWIW, the #C0AB48493 channel and the #C6QH853H8 channel both have about 1,000 members, give or take.

now we're getting to the ground truth on what's been going on in the tools department, with the clojure core team and investment going into clj tools/deps, plus the ability to have gradle-style flexibility, seems like a winner

anyhow, I'm going to watch the video and walk through the guestbook example to get a feeling on some of these library choices

the whole integrant/mount thing reminds me of when the Spring framework came out

Component is another of those and predates both. It's what we like to use at work. There are several others that also manage state lifecycle.

if you have a project that works already there might not be a lot of value migrating it over.

Wild guess but have you tried to input milliseconds instead of seconds?

how to use milliseconds?

(DateTime. (* 1000 1671913688))

Also you used tick for deriving the seconds value of now but you then use clj-time for DateTime and probably this is why they expect something else as input.

Ohh great that works

Is there any way we can get with the milliseconds form tick?

As this code (DateTime. 1671913688) is in our common service where we are receive input from java & clojure its working fine with the value receiving from java the problem is only when we send the value form clojure

> Is there any way we can get with the milliseconds form tick? I have no idea. Please read the docs, you chose the library so you have to know where they are. You can always divide by 1000 to get seconds... or vice-versa... You can divide and multiply in any part of your system.

Thanks for your help @U028ART884X 🥳

If you are new to Clojure, you'll find the #C053AK3F9 channel more likely to give you more in-depth answers (and you'll be less likely to be told to go read the docs 😁). The assumption in #C03S1KBA2 is that you already know what you're doing.

> multiply in any part of your system Don't do multiplication because sometimes the milliseconds will matter and it will be a bug if you truncate them to seconds and them multiply by 1000 to get milliseconds. You'll lose precision (also with milliseconds/seconds you already lose time zone).

Okay Will check is there anyway can get the milliseconds 👍