https://stackoverflow.com/a/30971255 ?

yeah i can do it locally; i want a view like this on github

oh

missed that 😄

Dno if it can be done, but it sounds interesting. Looking forward to hear how!

me too 😄

the github PR "files changed" view is hierarchic these days, so can you not just browse/review the changes you care about ?

the commits are mixed into the trunk already, with other irrelevant commits interspersed

the folder distinction is how i want to elide them

i can browse to a folder, and i can click history, and that's great. now i want a diff of some of the commits i see in that history

I don't think you can do that from the standard GitHub UI; however, . opens a VS code editor in-browser on the repository & branch that is currently checked out. You might be able to see the diff you want there (but I'm not using VS code, so I don't know if it has the same features as the desktop app and I can't find it right now in the web version).

thanks!

dunno about GH support but, in the absence of that, you could use the local diff to put those changes onto a new branch, and review that as a regular PR ?

Why would it not? 😄

The real power move is to always deploy on fridays

dunno… but the state of DevOps changed a lot in the last decades. With a good CI/CD pipeline + k8s + advanced deployment strategy deploying at ~10 times/day become feasible…

the mantra is something like “if it is painful, do it more until it no longer hurts”

(the 10 times/day figure is for large org though)

I mean, if you’re deploying 10 times a day and not firefighting every night, I guess Friday would be no different

ya, that’s exactly what I’m referring to - progress in DevOps changes sth (prod. deploy) from risky to ordinary

still, having to firefight on Friday ruin any holiday mood

(you may decrease the risk, but it can’t go to 0, right?)

I don't like it. Cuts your deployment window down by 20%

That sounds like a lot, 20%, but perhaps the quality of life that you gain is equally “a lot”

wait. technically, if your company adopted the 4-day work week (!) and Friday is “off”, then it will be trivially true, no?

That's optimizing quality of life over a short time horizon

You’re just making Thursday the new Friday, in which you don’t want to deploy.

this… lol

I want the quality of life from beating the competition and retiring to a consultancy position drinking margaritas on the beach. Or something

that’s true, but I think one motivation for avoiding near weekend deploy is because weekend holiday is perceived as “scarce”

I guess you can keep Fridays free from deployments, while focusing on bringing down the post-deploy firefighting to a minimum, or to some threshold that you think is fine for Fridays, then include Fridays.

Wait, my comment was only regarding the 4 day work week. I think it’s an OK idea to have Fridays free to do all kinds of other things than deploying. You can be productive without deploying.

but with increasing weekend holiday length the relative scarcity decreases, making the risk not hurting as much

But this approach is pernicious Maybe we should avoid deployment past 3pm?

Wouldn't want to ruin our evenings

It's a question of what you're optimizing for

of course 🙂

Errything’s a compromise.

also, the concept of “production deploy” seems tied to the web 2.0 paradigm. Maybe the game will change somewhere in the far future, I dunno :man-shrugging:

Actually, I’ll make this “Today’s truism”: Every choice is a compromise.

At Ardoq we deploy whenever. But. You have to be prepared to deal with the fall out of the deployments.

I'm not fond of compromises. I prefer accepting that everything is a system of trade-offs. Semantics maybe. 😃

Not meaning that you’re alone in fixing b0rken stuff, but rather that you keep an eye on the logs/monitoring etc. So if you’re happy doing so on Friday evening, feel free to deploy.

As I work with many clients I'd say it depends but in general with a good CI/CD pipeline, automated alerting, containerisation and infrastructure as code I frequently deploy last thing on a Friday quite safely (for example, done this for last two clients)

Conversely, if you can’t deal with the fallout during Monday, don’t deploy Monday morning.

@U0ETXRFEW tomato tomato to me 🙂

To me compromise feels like someone is loosing. Trade-offs feel like I trading to get the best deal. Could be because I live in Sweden which means compromises is the default way of solving anything. 😃

btw, does company/client let consultant touch the production system, or it is advice/dev env. only?

I work on Prod systems all the time in clients

Huh, that interesting 🙂 I do agree that “trade-off” possibly has slightly more possible connotations than “compromise” in a Danish context. Or at least in the context of my brain.

One is a slightly more green tomato.

from an outsider/third culture view: “trade-off” is when you’re explicitly losing something to gain something else. It’s mostly individualistic. “compromise” is more like everyone have to lose something, but then everyone gain something in a collective, intangible manner (e.g. public goods). It is fundamentally a sociological phenomenon.

@lemontea I guess that's very close to where I am coming from.

also, I read somewhere on internet: “market economy: you know it is fair when everyone feel like the price is a bit unfair to them”

Hmmm, I think I disagree. 😃

that’s some rather subtle recursion (or two recursion?) right there…

best not to think about those stuff on Friday XD

how about a nice cup of coffee instead

I wouldn't want to be beholden to EU laws and regulations actually

true and for some companies it is important that their data is stored in the EU and not by a US company. your requirements are probably very different, ymmv

Absolutely, when you deal with compliance and customers' data. But there are a ton of clients who don't hold anyone's data and can be happy to operate in a different location It would also be nice to make self hosting easier for clients

👍

Imagine a sort of remote management console in Clojure, where you can deploy your stuff and interact with the entire environment via the repl

What is "this"?

"this" is what you see in the screenshot 🙂

https://github.com/lambdaisland/launchpad/pull/3

That’s brilliant!

I implemented this once using Graal's C API. It is indeed very dirty and it also didn't work in all cases, but you may have covered those edge cases with these hacks ;)

good thing to bring more area to be “dynamic” and hence workable with clojure’s REPL-driven style (e.g. your typical webapp may use env. variable for config)…

@U07FP7QJ0 Will you also support cd (changing the current working directory?) Both would be interesting for bb, people have been asking for this since they are used to this in python ;)

Too bad I can’t just plug this into my work project. We’re too deeply entrenched in other stuff to just make a quick switch.

@U04V15CAJ try this and see if it works for you: https://www.javadoc.io/static/com.github.jnr/jnr-posix/3.0.42/jnr/posix/POSIX.html#chdir-java.lang.String-

Might be better to attack our particular problem; some particular creds time out, and the creds are a part of our set of env vars. I don’t feel that we really need reloadable env vars otherwise, though it’d always be a boon.

jnr-posix is great, it's a project by the JRuby people because they had to emulate a lot of the stuff that CRuby does and that Java doesn't want you to do.

jnr-posix doesn't work with graal.

here is the older bb issue: https://github.com/babashka/babashka/issues/849

that's too bad

Here is the implementation I had for graal: https://gist.github.com/borkdude/335c9911cabf4db6d47cc772b4c69d4d#file-setenv-java-L23-L32

I think with some effort based on your hacks it could be made to work

but those warnings scare me a little ;)

the cleaner way, at least for regular JVM, is to implement a Java Agent that redefines ProcessEnvironment. That should also be more portable between JVMs.

Graal has something like this called Substitutions where you can redefine classes for the native image. Pretty much a last resort as well

1. site is great and I really like its idea, but I think it is not the same thing as yada. My internal schema for the “state of the art” of clojure backend is sth like: classical but somewhat legacy -> luminus; semi-modern, API server oriented -> pedestal; fully modern and next-gen/future while remaining general purpose: yada

I don't disagree

site has a more narrow focus and is kind of a niche tool (doesn’t make it any less great though): it is more like an “auto-gen, generic API server”. The basic use case is when you’re doing your usual RESTful API server, and suddenly realize in the middle that your RESTful conformance is so much that there is actually almost no custom logic apart from standard CRUD

2. Don’t know how to express this gently. But a recurrent theme across generation seems to me to be that Clojure is great at quickly innovating in a pinch, but could improve on the long term maintenance, low key work kind of things…

that being said, for the specific case of juxt/yada, if I’m not mistaken it is a corporate sponsored project based on “mutual benefit”. So it is understandable if their internal priority/situation changed and yada is no longer all aligned with their interest

They still take PRs though

so I think they're open to contributions, of other people are interested enough in working on it

i see… speaking of which, pedestal is also showing its age… a) the official site doesn’t look that newbie friendly, and b) getting pedestal to production would still require significant amount of “foundational” work - glue codes, customising it for more realistic use case… it seems?

btw, sth I did in anger before: https://github.com/lemonteaa/abc

(with a pretentious name 😉 )

I think pedestal is officially supported by someone at Cognitect though

Clojure projects in general don't care a lot about marketing via flashy sites I think ;)

flashy sites not mandatory indeed. For many smaller clojure library, having all the docs concentrated on github repo’s README.md “works” and is indeed a source of joy to me

YAWF (yet another web framework)

but this pattern doesn’t seem to work as well for larger ones

Why though?

I think the key is organization - the content/material itself is good enough

but discoverability can have an outsized impact

maybe it’s coz I have rather limited “working memory”

i.e. same material, but need to cross reference several pages, each one on a very specific subsection. VS all info I need collocated in one neat page

@ben.sless I actually tried to do a web search for a library named YAWF in response to your comment lol

Yet Another Documented Async-framework

I think what I really want to say is this: Clojure’s “library over framework” idea have merits, but in real life someone will need to do the glue code work. If that work is too large, it will become a material disadvantage compared to competing languages who are “battery included”

and no, it is not a matter of “ability”, but “cost”

Why can't we settle on one?

I don’t think there need to be only one though

what I have in mind is something more “loose”/“informal”

like base libraries + “templates”

so it’s just like luminus, but updated to reflect current trends

It's either that or we have standard APIs, a bit like what ring does, but for everything

those standards could be just files with specs and/or protocols, then everyone can implement

a problem I can foresee with “standards” is that it can become a contentious hot-zone

How so?

the marginal utility from 0 -> 1 is the most significant

so say if there’s at least 1 example with all battery included and kept up-to-date, it will already be in a much better shape

users who disagree with the particular arrangement in that templates are free to customize it or start from scratch

Here is an exploratory standards thing: https://github.com/clj-easy/tools.misc Note: this is not being worked on

ppl may have divergent or even conflicting/mutually exclusive use case that makes agreeing on one standard api… “difficult”

@lemontea Have you tried out kit?

no… from a quick glance it looks like luminus except updated in some part to be more modern, is that correct?

yes, it's luminus, but more dynamic, you can add features to it after you've generated your initial template

I made a gist of my comments here: https://gist.github.com/malcolmsparks/bcfdcd9ae51e69aa3018c04d48f8749b

@U050CTFRT Thanks for the write-up!

I think they're still using yada at my old job. They (former we) have been running it for years without issues. It's a bit of a shame that the momentum yada had is stalled, I recommended it to all my Clojure friends. But I get where you are coming from. Thanks for the great project.

ya aware of that… too shy though 🙈

they are extremely nice people, say hi from me ;)

“from me”? @@

😮

whatever ;)

@U04V15CAJ just took a quick look… seems that channel have been long dead?

I think @U050CTFRT still monitors that channel, but if nobody speaks up, nothing will happen

and Malcolm is lovely and friendly

not sure what to say (I’ve mostly said all I know at the moment already)

but let me try I guess

wait a moment

(do some errands)

We are still using Yada... 🙃

Haven't gotten it to work with aleph 0.5.0 yet though

My former workplace is also still using yada (I think) and we haven't had many issues with it

We almost went with pedestal but chose yada because of docs and batteries

that’s good. One question: what about GraphQL?

https://twitter.com/borkdude/status/857979807358910464

in pedestal there’s lacinia which is rather well supported I think

At my previous job we implemented graphql-like but based on RDF / sparql. GraphQL was kind of limiting ;)

so it’s custom code?

I'm mostly bragging here since I didn't personally implement that

yes

ya, I can imagine some kind of “pass-thru” to xtdb

but even with graphql stuff you will write a lot of "custom" code when writing the resolvers

though that’d be exactly “framework territory”

ya, depends on use case? e.g. If your web app is public facing/consumed by external third party, and third party insist on using GraphQL as they don’t know clojure