Clojurians Log v2

Hello everyone! I'm a Rails dev but I want to use ClojureScript for an SPA with Rails backend. I wonder if some of you here are in a similar setup.

@raymond150 it doesn’t sound too common but certainly doable, assuming the Rails backend serves some kind of JSON api. You won’t find any obstacles but certainly no support from either Rails or ClojureScript.

I’m no Rails expert but I thought it had tight integration with some of the common frontend frameworks, so I’m curious to hear what your use case is

@orestis Thanks for the reply. I'm new here so you're the first person I got in touch with. 🙂

ClojureScript can be used with any backend technology. I’ve seen it used with Rails as well. @raymond150

An update on M1 performance numbers, now with Azul OpenJDK with native Arm64 architecture. Jetty starting goes from 51s (intel Mac) to 29s (native arm) - Rosetta was 68s. Cljs build time goes from 67s (intel) to 22s (native arm), Rosetta was 55s.

So pretty impressive numbers @alexmiller

Startup times of just plain Clojure go from 4s under Rosetta to a hair under 1 second in native.

How much of that could be attributed to faster ram and/or ssds?

@orestis Also saw some major speedups with Azul on M1. Had to drop REBL to run it though—there’s no JFX for Arm.

Luckily, shadow-cljs has a pretty good explorer built in, with support for tap>.

My benchmark was a Nippy conversion of a large data structure—went from 181ms to 45ms (as compared to my old MacBook, and x86).

Sounds compelling. I'll reconsider switching to linux if Apple manages to come up with beefier machines...

The major problem I have with Apple right now is the abysmal I/O in Docker

Speaking about Docker, they're still working on that as well right?

Yes, it's still a wip.

I ordered myself a mac mini m1 for my audio/video processing. My day-to-day coding, development machine is a beefy intel running Arch.

Opening up any sort of video in Final Cut Pro results in what sounds like a jet engine taking off in my room.

With a M1, tranquility should be restored...

@dominicm there’s a ton of benchmarks out there that go into this. My takeaway is that those machines are solidly as fast or faster than desktop machines that cost multiples... on some workloads. Most reviews annoyingly focus on AV which seems to be hardware optimized so not very relevant for programmers. But it seems that the whole experience is super smooth so for people who have only one machine it’s seems a compelling buy. The next iteration should show what’s possible for the real MacBook Pro line.

I’ve seen some anecdotal comparisons of compiling Rust (or compiling with Rust), where M1 has come out looking good.

for staging environment, what abbr do you prefer, stage or staging?

test, stage, prod. or test, staging, prod

staging

we use the word beta for this

we use ‘dev’, ‘staging’, ‘prod’

staging as I/we have used it implies that the data is real and might even be migrated

I wonder what other people’s semantics are!

we use beta only for internal demo-ing

we dev everything against live, need to update a stored proc, log onto the prod db, modify the source and f5. EVERY F5 is terrifying an adventure 🙂

Ive been going on for 3 years wanting prod / dev / test seperation but its never happened yet. Apparently its all too hard / too complicated.... Just be careful is easier 😡

I hope someone somewhere names their branches in greek alphabetical order (alpha, beta, gamma, delta, epsilon, zeta… etc)

It would make me happy.

I've also wondered if there is any difference between staging and qa (do people perceive these as different things). The projects where I've been part of have usually had dev, qa and prod. Some people use staging but I've never get used to that.

And to be clear, qa has been test-like environment (using test data) but more stable than dev.

Is there a difference between UAT and Staging? (We have UAT and not staging and we use UAT both for user testing and also for us to deploy changes to prior to their going to production.)

We have an in-house QA team as part of IT, and they do their tests on Staging, and if it passes, we put it on the UAT server, and folks from the business side test it.

Generally if version n is in UAT, version n +1 is in Staging.

If we're talking about names, like part of a dns name, where instances have been deployed, we use branch names and git hashes. The branch name is an alias that refers to the latest git commit on that branch name. We also use beta to refer to whatever it is we plan to roll into production. If we're talking about names for configuration profiles, like use the settings from configuration profile X, we only have production and testing.

we have gone with the ill-named "test" as the name of our staging environment

not my decision

that was rosetta vs. native on one machine

or maybe you are asking about the other comparison in the backlog?

We do 🙂 https://github.com/noprompt/meander #meander

You’ve successfully made me happy 🙂 thanks

I may not actually know what rosetta is 😁

I think "staging" named literally is the "staging environment before switching to prod". So it's kinda a "last step" in the process. I think meaning has been diluted. I generally favour the term "pre-prod" for this class of environments.

rosetta is a CPU compatibility layer for running x86 on non-x86 mac

@dharrigan At least you didn't end up with "dev", then local dev vs live dev becomes very confusing.

OH. I see. Okay.

@dominicm interesting, I always thought of it as "the deployment environment where you expect deploys to fail", and other environments (including UAT, pre-prod, production...) are protected from broken states by trying staging first

but that was just from the informal side of collaborating in a workplace, I never looked up a formal definition

in my mental image, "staging" something is setting it up and seeing if it looks like it would collapse - we would do this in physical construction, and if it would it's not too late to frame up and continue work

or in the performing arts world, you would "stage" a reading or rehearsal in order to apply mild stresses and see weak points

@noisesmith Maybe. This was just my interpretation of the word 😁 The meaning is super diluted from my experience.

yeah, it's most likely a pragmatic term describing a thing we want to do, not a technical term

and that means its meaning will skew as the way we do things does, and devops has evolved a lot in the last couple of decades

Now I’m resisting running around changing http://stg.whatever.com to http://dress-rehearsal.whatever.com

I mean, there's also staged readings, table reads...

it’s a rich vein for sure

and like all metaphors should be pretty airtight.

🎈

a smart person once told me that an analogy is a defensible metaphor (that is, contains certain specific relationships such that you can use it as a tool, and carries some indication of where it doesn't apply)

ztellman?

someone you wouldn't know, but I think both he and ztellman read the same authors (Norbert Weiner, Claude Shannon, Stafford Beer, Heinz Von Foerster)

ah. figured it might have been him based on analyzing a type of communication like that

it's a similar set of obsessions, systems and information theory coupled with an interest in literature

and more generally, seeking a general method for cross-discipline knowledge

(it gets very recursive)

I concur here. dev is anything local (in reality, I call my local development, local 🙂 ) For me, dev and local are synonymous. We have, outside of local (dev), just three environments, "play" (urrgh, dislike that name too), "test" and "live".

the distinction I was going for is that you have different stakeholders for different non production environments, in my experience the one people call "staging", if it exists, has the author of a change as a stakeholder, and it exists because there are failure modes that exist on real infrastructure that don't exist locally. it's the first networked system that new code sees, and a filter before the code sees other environments with other stakeholders (like the QA team and adventurous end users) who don't want to be bothered with random shallow bugs

I've never seen "staging" used as a name for the last system the code runs on before prod, except when there are no intervening layers

of course a lot of this nuance disappears if you don't do microservices, or your microservices are unusually well designed

https://www.fastcompany.com/90584382/slack-salesforce-antitrust

MS having been pushing Teams very aggressively lately. I took it for a spin at work because we are all O365 subscriptions and it is "okay" but it's not Slack -- but it's "free" for us, compared to paying for Slack. Luckily, we're a small enough company that Slack isn't very expensive but, still... I can see how MS will be able to stop Slack getting a foothold in any company that's run on O365...

It's terrible at scale. We had to use it for a while and it was not good to say the least.

The call feature in particular is quite glitchy

Good to know. We're only a dozen folks so I suspect it would be fine for us. We don't use Slack's call functionality -- we use Zoom -- so I suspect we wouldn't use Teams' call functionality either.

Zoom is definitely better. Meet is really good too (we use that)

yeah, Zoom is a lot better than Slack's call thing