Re: Idiomatic program for someone new to Clojure

[aditya....@gmail.com]

I'd try to separate the "I/O or side-effecting" parts from the "purely data 
processing" parts. This makes the program much easier to test --- the 
"purer" the code, the better it is. This also helps tease apart 
domain-agnostic parts from domain-specialised parts, which is useful, 
because domain-agnostic parts tend to be generalisable and thus more 
reusable.

I'd also avoid mixing lazy functions like `map` with effectful things like 
`GET` requests, because 
: https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects

I've taken the liberty to rearrange the code, and rename functions to 
illustrate what I mean.

(defn pipeline-api-endpoint ;; lifted out of `fetch-pipeline` 
  [project-name]
  ;; knows how to translate, or perhaps more generally, map, a project name 
to a project URL format
  (str "https://example.com/go/api/pipelines/"; project-name "/history"))

(defn http-get-basic-auth ;; instead of `fetch-pipeline', because now this 
operation doesn't care about a specific type of URL  
  [well-formed-url] ;; it can simply assume someone gives it a well-formed 
URL.
  (client/get well-formed-url
  {:basic-auth "username:password"})) ;; we'll see about this 
hard-coding later

(defn pipeline-build-count ;; now this only cares about looking up build 
count, so no "GET" semantics
  ;; assumes it gets a well-formed response
  [{:keys [body] :as response}] ;; destructuring for convenience and 
function API documentation
  (-> body
  (parse-string true)
  :pipelines
  first
  :counter))

(defn fetch-pipeline-counts! ;; ties all the pieces together
  [project-names]
  (reduce (fn [builds project-name] 
   ;; uses reduce, not map, 
because: https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects
(conj builds
  (-> project-name
  pipeline-api-endpoint
  http-get-basic-auth
  pipeline-build-count)))
  []
  project-names))


Now... It turns out that fetch-pipeline-counts! is a giant effectful 
process, tied directly to http-get-basic-auth. We could try to lift out the 
effectful part, and try to make it a pure function.

(defn http-get-basic-auth
  [well-formed-url username password]
  (client/get well-formed-url
  {:basic-auth (str username ":" password)}))

(defn http-basic-auth-getter
  "Given basic auth credentials, return a function that takes an HTTP 
endpoint, and GETs data from there."
  [username password]
  (fn [well-formed-url]
(http-get-basic-auth well-formed-url
 username
 password)))

(defn fetch-pipeline-counts-alt
  [pipeline-fetcher project-names]
  ;; Easier to unit test. We can pass a mock fetcher that doesn't call over 
the network.
  ;; In fact, we can now use any kind of "fetcher", even read from a DB or 
file where we may have dumped raw GET results.
  (reduce (fn [builds project-name]
(conj builds
  (-> project-name
  pipeline-api-endpoint
  pipeline-fetcher
  pipeline-build-count)))
  []
  project-names))

(comment
  (fetch-pipeline-counts-alt (http-basic-auth-getter "username" "password")
 ["projectA"
  "projectB"
  "projectC"
  "projectD"])
 )

A closer look might suggest that we're now describing processes that could 
be much more general than fetching pipeline counts from an HTTP endpoint...

Enjoy Clojuring! :)

On Monday, December 14, 2020 at 10:51:52 PM UTC+5:30 jamesl...@gmail.com 
wrote:

> Very cool everyone. This is exactly the kind of feedback I was hoping for. 
> I'm going through Clojure for the Brave and I hadn't made it to the macros 
> chapter yet. That single threading macro is pretty sweet!
>
> Thanks everyone!
>
> On Monday, December 14, 2020 at 11:00:02 AM UTC-6 brando...@gmail.com 
> wrote:
>
>> Hey James,
>>
>> Another small suggestion is you can just pass println to map, since it 
>> takes 1 argument in your case.
>>
>> (map println (sort builds))
>>
>> But here, since you just want to perform side effects, maybe run! would 
>> be a better function to use.
>>
>> (run! println (sort builds))
>>
>> This would cause it to return just one nil. Clojure is a functional 
>> language, and every function returns a value. You'll see the return in 
>> your REPL, but if the program is run in another way, such as packaged as a 
>> jar, you would just see the print output.
>>
>> - Brandon
>>
>> On Mon, Dec 14, 2020 at 8:42 AM Justin Smith  wrote:
>>
>>> a small suggestion: you don't need to nest let inside let, a clause
>>> can use previous clauses:
>>>
>>> (defn get-latest-build
>>>   [pipeline]
>>>   (let [response (fetch-pipeline pipeline)
>>> json (parse-string (:body response) true)
>>>[pipeline] (:pipelines json)]
>>>   (:counter pipeline

Re: Idiomatic program for someone new to Clojure

[aditya....@gmail.com]

On Wednesday, December 16, 2020 at 3:12:22 AM UTC+5:30 jamesl...@gmail.com 
wrote:

> So I think I can answer my first question. That particular line in 
> `pipeline-build-count` is doing associative destructing 
> <https://clojure.org/guides/destructuring#_associative_destructuring>. 
> And you didn't have to do the `as response` but like you said in your 
> comment, you are just doing that to sort of document the method. That sound 
> about right?
>

Yes it's "associative destructuring". The main purpose of destructuring is 
to conveniently bind a name to a value found somewhere inside a data 
structure. The additional benefit is that it also serves to document the 
function API, which IDE tooling can surface.

The term "destructuring" sounded heavy when I first tried to grok it. It 
got easier when I started thinking of it like visually matching shapes (of 
name bindings) to shapes (of data). Sort of like a fancy mask or a cookie 
cutter pattern. To illustrate:

;; If I see this:

(let [[a b c & others]
  [1 2 3 4 5 6]]
  ;; do something
  )

;; I visualise the effect of destructuring as:

1  2  34 5 6
|  |  |   ( )
v  v  v  v
[a  b  c & others]
 

> On Tuesday, December 15, 2020 at 2:33:08 PM UTC-6 James Lorenzen wrote:
>
>> Also, your program works great though it only returns a list of the 
>> latest build numbers without the project name. I'm trying to think of how I 
>> could include that but I'm not seeing it. The fetch pipeline response does 
>> include the project name so I could just return it and the counter; so I 
>> could return a tuple? or just two values (I think clojure can support 
>> that). I'd rather just thread the project-name through though.
>>
>
There are at least two ways to do this. In both cases, I'd favour returning 
a hash-map, instead of tuples. 

One way is to modify `pipeline-build-count` like this:

(defn pipeline-build-count
  [{:keys [body] :as response}]
  {:project-name (:the-key-for-project-name body)
   :latest-build-count (-> body
   (parse-string true)
   :pipelines
   first
   :counter)})

The other way is in the fetch-pipeline-counts function. Something like this:

(defn fetch-pipeline-counts-alt
  [pipeline-fetcher project-names]
  (reduce (fn [builds project-name]
(conj builds
  {:project-name project-name
   :latest-build-count (-> project-name
   pipeline-api-endpoint
   pipeline-fetcher
   pipeline-build-count)}))
  []
  project-names))

If the name is the only relevant detail that matters, then either way is 
fine. However, I'd modifying the pipeline-build-count function, because it 
has access to all the information about a pipeline, and we may want to 
process and/or pass through more of it later.

 

> Thanks for all the help! I'm learning a ton.
>>
>
Cheers :)

On Monday, December 14, 2020 at 11:35:15 PM UTC-6 aditya@gmail.com 
>> wrote:
>>
>>> I'd try to separate the "I/O or side-effecting" parts from the "purely 
>>> data processing" parts. This makes the program much easier to test --- the 
>>> "purer" the code, the better it is. This also helps tease apart 
>>> domain-agnostic parts from domain-specialised parts, which is useful, 
>>> because domain-agnostic parts tend to be generalisable and thus more 
>>> reusable.
>>>
>>> I'd also avoid mixing lazy functions like `map` with effectful things 
>>> like `GET` requests, because : 
>>> https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects
>>>
>>> I've taken the liberty to rearrange the code, and rename functions to 
>>> illustrate what I mean.
>>>
>>> (defn pipeline-api-endpoint ;; lifted out of `fetch-pipeline` 
>>>   [project-name]
>>>   ;; knows how to translate, or perhaps more generally, map, a project 
>>> name to a project URL format
>>>   (str "https://example.com/go/api/pipelines/"; project-name "/history"))
>>>
>>> (defn http-get-basic-auth ;; instead of `fetch-pipeline', because now 
>>> this operation doesn't care about a specific type of URL  
>>>   [well-formed-url] ;; it can simply assume someone gives it a 
>>> well-formed URL.
>>>   (client/get well-formed-url
>>>   {:basic-auth "username:password"})) ;; we'll see about 
>>> this hard-coding later
>>>
>>>

Re: [ANN] Discontinuing 4clojure.com

[aditya....@gmail.com]

Thanks to all the 4clojure maintainers and contributors, and special thanks 
to you, Alan for keeping the lights on for so long. 

4clojure helped me as I muddled through learning Clojure almost eight years 
ago (good grief, eight years!). At the time it was perhaps the only 
beginner-accessible _and fun!_ way to get introduced to the language. Being 
able to see other peoples solutions was a huge part of the learning process 
--- exposure to other peoples' ideas and thought process is so precious.

It's been a great run. I feel happy-sad but also hopeful that, like great 
art, it finds a new life in a new way.

Live long and prosper \\//_
On Monday, July 5, 2021 at 1:56:05 AM UTC+5:30 Alan Malloy wrote:

> TL;DR: Turning off 4clojure.com by the end of July 2021
>
> Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
> 4clojure.com over the last week. The old decrepit system 4clojure runs on 
> has finally gotten out of date enough that I can't even figure out how to 
> get it recent enough that SSL certs will auto-renew anymore.
>
> In principle I could start from scratch on a new server and move 4clojure 
> over, but I won't. 4clojure has been piggybacking along on a server that I 
> use for personal reasons, and over the years I have less and less reason to 
> keep paying for that server - it's now pretty much just 4clojure costing me 
> an embarrassing amount of money every month because I haven't wanted to 
> disappoint the community by shutting it down. This SSL thing is just what 
> made me finally pull the trigger.
>
> I don't have a specific EOL date in mind, but sometime near the end of the 
> month, since that's the billing cycle. Until that time, 4clojure still 
> works, as long as you don't mind clicking through the security warnings - 
> it really is still me hosting the site, and since the connection is still 
> HTTPS (albeit with an invalid cert) I think that means your data is still 
> safe. If you have solutions to problems you're proud of, you've still got 
> some time to print them out and put them up on your refrigerator.
>
> I'm not seeking new maintainers. I'd feel uncomfortable handing over a 
> database with so many email addresses and password hashes in it to anyone. 
> The service has had a good run - just over a decade since the first 
> release 
> .
>  
> I hope you enjoyed it during that time.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/79ae9a04-adab-4fdd-8ca1-2c7a81867139n%40googlegroups.com.

Re: Switch devops environments via namespaces

[aditya....@gmail.com]

So from an ops point of view, I like your first approach; viz. pass the 
environment parameter explicitly.

I prefer being explicit about every single invocation of any ops task.

The namespace solution, while being "legal", causes the configuration to 
become implicit, one has to look at the REPL prompt to "know", rather than 
be confident that we told the function exactly where to call.

>From a Clojure sensibilities point of view, what was stateless (explicit 
param) becomes stateful (implicit global state with def server). This can 
cause all manner of subtle issues, e.g. accidentally referring to the var 
instead of the resolved var in some service function.

Personally, I would go with your original approach, because it forces me to 
slow down a little and pay attention, while I'm typing, every single time. 
This is in service of human error mitigation. I would say the explicit 
workflow is close to the "pointing and calling" method 
https://en.wikipedia.org/wiki/Pointing_and_calling

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/b6713010-47cc-4bd6-8073-d9d5d681d62cn%40googlegroups.com.

A Web Stack Special Interest Group?

[aditya....@gmail.com]

Hello, thoughts about the Clojurish web stack have been bouncing around in 
my head for a while now. In recent months, I've noticed an uptick in 
conversations about the same. Maybe it's recency bias. Maybe not. The 
"boring business web app" is where the money is, after all.

I wonder if people would like to put heads together to come up with 
*something* general-purpose that helps people understand + construct + 
apply web things built by community members over the years.

Personally, I'm not convinced that a One True Framework is the solution. 
However there might be opportunity to out-framework all the framework-heavy 
communities by making a way to construct one's own framework.

The "constructor" might spit out a "standard recipe" that could be: "Ring + 
Compojure" or "Ring + Reitit" or "Kit" or "Duct" or "Sitefox" or "Donut" or 
"Pedestal" if the user feeds in well-specified requirements that match one 
or more of said framework/library collection. Or, it might run us through a 
decision tree to incrementally expand requirements into a project on disk 
(a clj-new template, but created incrementally).

AND, as m'colleague Kapil insists (and I agree) it should be a "full 
system" system... have us covered from parts assembly to production 
deployments.

/Explanations/ would be a key feature of such a constructor; Why this and 
not that? How to wire X and Y together? What are some example use cases? 
The explanations would be sourced from source repos.

Basically, this thing would respect and support the diversity and 
inventiveness of the Clojure web ecosystem /while making it accessible/ to 
the masses. The innovation is distributed, but the composition is 
centralised. This sort of thing is definitely in userspace and not language 
maintainerspace. IMHO, SciCloj is a great example of a special interest 
group that's doing yeoman service.

I'm not sure if I'm making any sense, but I'm sure smarter people that I 
have struggled enough to have had ideas of their own and if they come 
together, they might conjure up a very creative solution. What I *am* 
confident about, is that this is a *complicated* task, but not a complex 
one.

Anyway, I just wanted to put this out into the clojureverse and see what 
happens.

May The Source be with us,
- Adi

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/a4c539f4-6d42-4920-a5cf-2469064e1516n%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

P.S. I'm sorely tempted to cite names / references that have informed and 
inspired me, but that will put people on the spot.

So whomever is interested in this line of thinking may self-identify by 
replying to this thread, with their current state of the art thinking 
(videos, essays, books, frameworks etc.).

Here's some of my stuff on these lines, for example:

   - Clojuring the web application stack: Meditation One 
   
<https://www.evalapply.org/posts/clojure-web-app-from-scratch/index.html#main>
   - Riff: A "mycelium-clj" for the Clojure ecosystem? 
   <https://www.evalapply.org/posts/mycelium-clj/index.html#main> 
   - Grokking Libraries in Clojureland 
   
<https://github.com/adityaathalye/slideware/blob/master/Grokking%20Libraries%20in%20Clojureland.pdf>
 
   (PDF). 
   - Which Clojure codebases should I read? How and why? 
   
<https://www.evalapply.org/posts/which-clojure-codebases-to-read-how-and-why/index.html#main>
 
   
On Thursday, October 24, 2024 at 2:17:03 PM UTC+5:30 aditya@gmail.com 
wrote:

> Hello, thoughts about the Clojurish web stack have been bouncing around in 
> my head for a while now. In recent months, I've noticed an uptick in 
> conversations about the same. Maybe it's recency bias. Maybe not. The 
> "boring business web app" is where the money is, after all.
>
> I wonder if people would like to put heads together to come up with 
> *something* general-purpose that helps people understand + construct + 
> apply web things built by community members over the years.
>
> Personally, I'm not convinced that a One True Framework is the solution. 
> However there might be opportunity to out-framework all the framework-heavy 
> communities by making a way to construct one's own framework.
>
> The "constructor" might spit out a "standard recipe" that could be: "Ring 
> + Compojure" or "Ring + Reitit" or "Kit" or "Duct" or "Sitefox" or "Donut" 
> or "Pedestal" if the user feeds in well-specified requirements that match 
> one or more of said framework/library collection. Or, it might run us 
> through a decision tree to incrementally expand requirements into a project 
> on disk (a clj-new template, but created incrementally).
>
> AND, as m'colleague Kapil insists (and I agree) it should be a "full 
> system" system... have us covered from parts assembly to production 
> deployments.
>
> /Explanations/ would be a key feature of such a constructor; Why this and 
> not that? How to wire X and Y together? What are some example use cases? 
> The explanations would be sourced from source repos.
>
> Basically, this thing would respect and support the diversity and 
> inventiveness of the Clojure web ecosystem /while making it accessible/ to 
> the masses. The innovation is distributed, but the composition is 
> centralised. This sort of thing is definitely in userspace and not language 
> maintainerspace. IMHO, SciCloj is a great example of a special interest 
> group that's doing yeoman service.
>
> I'm not sure if I'm making any sense, but I'm sure smarter people that I 
> have struggled enough to have had ideas of their own and if they come 
> together, they might conjure up a very creative solution. What I *am* 
> confident about, is that this is a *complicated* task, but not a complex 
> one.
>
> Anyway, I just wanted to put this out into the clojureverse and see what 
> happens.
>
> May The Source be with us,
> - Adi
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/c56f3352-04f3-4059-83d8-7f763c1e7f13n%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

X-linking to some chatter over at r/Clojure, where I X-posted this email.

https://www.reddit.com/r/Clojure/comments/1gfjkiy/a_web_stack_special_interest_group/
 

On Thursday, October 24, 2024 at 6:50:40 PM UTC+5:30 Fabio Dias Francisco 
wrote:

> I know what you mean, in terms of web framework, idk, but I had to go just 
> that route and build myself my own data processing framework. There was 
> nothing for that purpose that was truly native, so I used my knowledge of 
> many frameworks like that, and built my own.
>
> On Thursday, October 24, 2024 at 9:47:03 AM UTC+1 aditya@gmail.com 
> wrote:
>
>> Hello, thoughts about the Clojurish web stack have been bouncing around 
>> in my head for a while now. In recent months, I've noticed an uptick in 
>> conversations about the same. Maybe it's recency bias. Maybe not. The 
>> "boring business web app" is where the money is, after all.
>>
>> I wonder if people would like to put heads together to come up with 
>> *something* general-purpose that helps people understand + construct + 
>> apply web things built by community members over the years.
>>
>> Personally, I'm not convinced that a One True Framework is the solution. 
>> However there might be opportunity to out-framework all the framework-heavy 
>> communities by making a way to construct one's own framework.
>>
>> The "constructor" might spit out a "standard recipe" that could be: "Ring 
>> + Compojure" or "Ring + Reitit" or "Kit" or "Duct" or "Sitefox" or "Donut" 
>> or "Pedestal" if the user feeds in well-specified requirements that match 
>> one or more of said framework/library collection. Or, it might run us 
>> through a decision tree to incrementally expand requirements into a project 
>> on disk (a clj-new template, but created incrementally).
>>
>> AND, as m'colleague Kapil insists (and I agree) it should be a "full 
>> system" system... have us covered from parts assembly to production 
>> deployments.
>>
>> /Explanations/ would be a key feature of such a constructor; Why this and 
>> not that? How to wire X and Y together? What are some example use cases? 
>> The explanations would be sourced from source repos.
>>
>> Basically, this thing would respect and support the diversity and 
>> inventiveness of the Clojure web ecosystem /while making it accessible/ to 
>> the masses. The innovation is distributed, but the composition is 
>> centralised. This sort of thing is definitely in userspace and not language 
>> maintainerspace. IMHO, SciCloj is a great example of a special interest 
>> group that's doing yeoman service.
>>
>> I'm not sure if I'm making any sense, but I'm sure smarter people that I 
>> have struggled enough to have had ideas of their own and if they come 
>> together, they might conjure up a very creative solution. What I *am* 
>> confident about, is that this is a *complicated* task, but not a complex 
>> one.
>>
>> Anyway, I just wanted to put this out into the clojureverse and see what 
>> happens.
>>
>> May The Source be with us,
>> - Adi
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/664d1446-2a60-4199-b6c1-d0aed6fcb067n%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

Okay, TIL: noj! https://scicloj.github.io/noj/

They appear to be doing this very thing, but for the data + science 
ecosystem!

I wonder if the web ecosystem can steal their playbook.

On Thursday, October 31, 2024 at 11:47:09 PM UTC+5:30 aditya@gmail.com 
wrote:

> X-linking to some chatter over at r/Clojure, where I X-posted this email.
>
>
> https://www.reddit.com/r/Clojure/comments/1gfjkiy/a_web_stack_special_interest_group/
>  
> On Thursday, October 24, 2024 at 6:50:40 PM UTC+5:30 Fabio Dias Francisco 
> wrote:
>
>> I know what you mean, in terms of web framework, idk, but I had to go 
>> just that route and build myself my own data processing framework. There 
>> was nothing for that purpose that was truly native, so I used my knowledge 
>> of many frameworks like that, and built my own.
>>
>> On Thursday, October 24, 2024 at 9:47:03 AM UTC+1 aditya@gmail.com 
>> wrote:
>>
>>> Hello, thoughts about the Clojurish web stack have been bouncing around 
>>> in my head for a while now. In recent months, I've noticed an uptick in 
>>> conversations about the same. Maybe it's recency bias. Maybe not. The 
>>> "boring business web app" is where the money is, after all.
>>>
>>> I wonder if people would like to put heads together to come up with 
>>> *something* general-purpose that helps people understand + construct + 
>>> apply web things built by community members over the years.
>>>
>>> Personally, I'm not convinced that a One True Framework is the solution. 
>>> However there might be opportunity to out-framework all the framework-heavy 
>>> communities by making a way to construct one's own framework.
>>>
>>> The "constructor" might spit out a "standard recipe" that could be: 
>>> "Ring + Compojure" or "Ring + Reitit" or "Kit" or "Duct" or "Sitefox" or 
>>> "Donut" or "Pedestal" if the user feeds in well-specified requirements that 
>>> match one or more of said framework/library collection. Or, it might run us 
>>> through a decision tree to incrementally expand requirements into a project 
>>> on disk (a clj-new template, but created incrementally).
>>>
>>> AND, as m'colleague Kapil insists (and I agree) it should be a "full 
>>> system" system... have us covered from parts assembly to production 
>>> deployments.
>>>
>>> /Explanations/ would be a key feature of such a constructor; Why this 
>>> and not that? How to wire X and Y together? What are some example use 
>>> cases? The explanations would be sourced from source repos.
>>>
>>> Basically, this thing would respect and support the diversity and 
>>> inventiveness of the Clojure web ecosystem /while making it accessible/ to 
>>> the masses. The innovation is distributed, but the composition is 
>>> centralised. This sort of thing is definitely in userspace and not language 
>>> maintainerspace. IMHO, SciCloj is a great example of a special interest 
>>> group that's doing yeoman service.
>>>
>>> I'm not sure if I'm making any sense, but I'm sure smarter people that I 
>>> have struggled enough to have had ideas of their own and if they come 
>>> together, they might conjure up a very creative solution. What I *am* 
>>> confident about, is that this is a *complicated* task, but not a 
>>> complex one.
>>>
>>> Anyway, I just wanted to put this out into the clojureverse and see what 
>>> happens.
>>>
>>> May The Source be with us,
>>> - Adi
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/e0ef4a5d-fa26-4646-afc2-e16fe1dbd5adn%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

On Friday, November 8, 2024 at 9:39:53 PM UTC+5:30 Daniel Slutsky wrote:

Hi!

Thanks for mentioning Noj.
I'd be glad to discuss it if you have any questions or ideas.


Thanks for all the hard work (often thankless!) of not only organising a 
niche community, but also driving/helping projects like noj.
 

Basically, it is collecting a stack of libraries with documentation and 
integration tests.
We approach it by generating tests from documentation. This way, we verify 
the docs are correct (and also enjoy a way to write some kind of literate 
tests).
https://scicloj.github.io/clay/#test-generation


Yes, I noticed. It's a good idea worth stealing!

I'll pop into the SciCloj Zulip for noj-specific questions. Right now I'm 
on the hammock, just letting thoughts swirl in my head.

RDF / open-graph style metadata has been on my mind [1] for a while, 
especially to make LLMs *reliably* useful for pattern-matching / grunt work 
tasks. I'm so glad for Luke VanderHart's recent Conj talk [2]. Now I can 
point people to an actual expert who knows what he's talking about! 
 
[1] Riffed about in "Mycelium Clj" 
https://www.evalapply.org/posts/mycelium-clj/
*In a world of concrete objects, steel frameworks bring sense and 
order. In a forest of composable tools, libraries and open-ended schemas, 
it would be the mycelia. A frustrated yet optimistic man muses "Might such 
a thing come to be?".*
... ... ...
*What I can't tell is if all this boils down to "Oh look, yet another 
internet rando witlessly reverse-engineered a cheap knock-off of RDF and 
the semantic web.". Or if it is something practicable within the little 
village (relatively speaking) of Clojureland.*
... ... ...
*(And then some specific properties of the hypothetical mycelium-clj, 
and some use-cases similar to "Please Mx. LLM, help me make a data stack 
for X, Y, Z purpose".)*

[2] Hell yes... "*RDF and the future of LLMs" by Luke VanderHart* 
https://www.youtube.com/watch?v=OxzUjpihIH4

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/3ac07461-dac6-4e43-943f-60fa40bcd47en%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

Fellow Gentlenerds... Help!

One is on the hook to deliver a workshop (late in Jan 2025), a "First 
Principles" mental model of web stacks; viz. how to construct one from 
scratch.

Pretty sure I've got this [0], *but* today's third cup of coffee says why 
not entice others to influence the workshop?

What better fodder for thought, than everybody's pet peeves and annoyances 
and WTF moments and gawdawful mistakes and "holy batman, why didn't anyone 
tell me /this/ three years ago???" table-flips.

So... professional and newbie *#Clojure* web developers in the haus, please 
complain.

Reply here, or email my.clojure.webdev.complai...@evalapply.org . Do it for 
you and I, as much as for others. So that not-you may selfishly learn from 
you and improve our lives, while you feel heard and seen... A win win 
situation, as they used to quip in B-School.
Needless to say, I will publish everything I can, for community use; such 
as blog post(s) [1], repo(s) [2], slide warez [3], and video recordings [4].

Aside: This is my favourite software engineering methodology; Talk Driven 
Development, which I know for a fact, many upstanding members of our mighty 
little community revel in 🤪 [5].

So, fire away please. Help me write everything now, so that I can rewrite 
everything at the last minute.

May The Source be with us,
- Adi.
References:
[0] The CFP proposal: 
https://confengine.com/conferences/functional-conf-2025/proposal/21251/composing-clojure-web-stacks-using-functional-first-principles
[1] Seven thousand words (uh, tokens, including code) already... good 
grief. https://www.evalapply.org/posts/clojure-web-app-from-scratch/
[2] Commit by commit progressive explanation: 
https://github.com/adityaathalye/usermanager-first-principles
[3] Where the slides are: https://github.com/adityaathalye/slideware
[4] Such as... https://www.youtube.com/@evalapplydotorg
[5] So many people have unabashedly confessed to step no. 10: 
https://www.evalapply.org/posts/how-to-give-a-conference-talk/ 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/21219bce-5de7-46be-ba48-5cea676cc627n%40googlegroups.com.

Re: Clojure in product. Would you do it again?

[aditya....@gmail.com]

Subscribed!

On Wednesday, December 4, 2024 at 9:59:49 PM UTC+5:30 Łukasz Korecki wrote:

> This is great, I've built two products using Clojure  and now I'm working 
> on expanding Clojure usage at my $DAYJOB
>  -  so it's always great to hear how others use Clojure "in real life".
>
> And yeah, if I had to do it again I'd definitely pick Clojure, at least 
> for the backend and scripting with BB.
>
> On Wednesday, December 4, 2024 at 4:48:09 AM UTC-8 Viktoriia Yarosh wrote:
>
>> Hi everyone,
>> We're launching a new podcast series on the real-world experiences of 
>> teams using Clojure in production environments. Our first episode features 
>> Kalle Korhonen, CPO at Quuppa, who shares insights on successfully 
>> integrating Clojure into a Java-based enterprise system. Our goal is to 
>> explore why Clojure, despite its elegance and capabilities, remains a niche 
>> technology, by speaking directly with teams who have taken the leap into 
>> production. 
>> Listen and share your thoughts: 
>> https://www.freshcodeit.com/podcast/we-are-writing-in-clojure
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/261ddb95-10bb-4ddb-8e6d-2a910013ebdfn%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

A "multiproject" style web stack architecture(?) that I've been toying with 
(which, I suspect. might prove to generalise for *any* stack - scicloj, 
fullstack, mobile etc...):

https://github.com/adityaathalye/clojure-multiproject-example

Clone the repo and call `bin/run_cmd.sh` helper utility from the root of 
the project to try it out.

The commit history thus far should tell the tale of another standalone web 
app got transplanted into the "multiproject".

It's all very alpha quality, so all critical feedback welcome!
On Wednesday, December 4, 2024 at 2:11:16 PM UTC+5:30 aditya@gmail.com 
wrote:

> Fellow Gentlenerds... Help!
>
> One is on the hook to deliver a workshop (late in Jan 2025), a "First 
> Principles" mental model of web stacks; viz. how to construct one from 
> scratch.
>
> Pretty sure I've got this [0], *but* today's third cup of coffee says why 
> not entice others to influence the workshop?
>
> What better fodder for thought, than everybody's pet peeves and annoyances 
> and WTF moments and gawdawful mistakes and "holy batman, why didn't anyone 
> tell me /this/ three years ago???" table-flips.
>
> So... professional and newbie *#Clojure* web developers in the haus, 
> please complain.
>
> Reply here, or email my.clojure.web...@evalapply.org . Do it for you and 
> I, as much as for others. So that not-you may selfishly learn from you and 
> improve our lives, while you feel heard and seen... A win win situation, as 
> they used to quip in B-School.
> Needless to say, I will publish everything I can, for community use; such 
> as blog post(s) [1], repo(s) [2], slide warez [3], and video recordings [4].
>
> Aside: This is my favourite software engineering methodology; Talk Driven 
> Development, which I know for a fact, many upstanding members of our mighty 
> little community revel in 🤪 [5].
>
> So, fire away please. Help me write everything now, so that I can rewrite 
> everything at the last minute.
>
> May The Source be with us,
> - Adi.
> References:
> [0] The CFP proposal: 
> https://confengine.com/conferences/functional-conf-2025/proposal/21251/composing-clojure-web-stacks-using-functional-first-principles
> [1] Seven thousand words (uh, tokens, including code) already... good 
> grief. https://www.evalapply.org/posts/clojure-web-app-from-scratch/
> [2] Commit by commit progressive explanation: 
> https://github.com/adityaathalye/usermanager-first-principles
> [3] Where the slides are: https://github.com/adityaathalye/slideware
> [4] Such as... https://www.youtube.com/@evalapplydotorg
> [5] So many people have unabashedly confessed to step no. 10: 
> https://www.evalapply.org/posts/how-to-give-a-conference-talk/ 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/4c10ab2e-da32-4165-8c6f-b26cab97258en%40googlegroups.com.

Re: A Web Stack Special Interest Group?

[aditya....@gmail.com]

On Tuesday, January 14, 2025 at 5:48:02 PM UTC+5:30 Dustin Getz wrote:

We have a "multi project" monorepo setup at Hyperfiddle called 
electric-fiddle, it's how we deploy our demos (with merged or isolated 
classpaths) while developing on a merged dev classpath, and with common 
deployment/build scripts. We've been incubating it for about two years and 
been through a few revisions, pretty happy with the current approach. We 
haven't published it yet but DM me and I can send you a private link


Yes; the Adrian "Monk" department of my brain sends delighted thanks for 
the offer! DM'd you.

Luckily, my brain also has a Grug Crood department. He hereby declares the 
"multiproject" sketch "done", so we can all move on with life ("For now.", 
says Monk)...

It has just enough structure and moving parts to cover Grug dept.'s 
requirements. The repo is updated, so is the README (with a quickstart, and 
even a rationale!): 
https://github.com/adityaathalye/clojure-multiproject-example ... Hopefully 
someone else finds it useful!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/clojure/2c0f42ea-dbe3-4777-bcf9-a0bcd51f118bn%40googlegroups.com.