This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (108)
- # announcements (4)
- # aws (11)
- # babashka (39)
- # beginners (199)
- # calva (12)
- # clj-kondo (17)
- # cljs-dev (1)
- # clojure (115)
- # clojure-dev (9)
- # clojure-europe (98)
- # clojure-italy (17)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-seattle (7)
- # clojure-sweden (6)
- # clojure-switzerland (5)
- # clojure-uk (15)
- # clojurescript (41)
- # code-reviews (36)
- # conjure (7)
- # datomic (1)
- # emacs (1)
- # events (1)
- # fulcro (26)
- # graalvm (2)
- # helix (35)
- # jackdaw (2)
- # jobs (9)
- # jobs-discuss (5)
- # lambdaisland (2)
- # meander (24)
- # off-topic (80)
- # pathom (22)
- # pedestal (1)
- # portal (20)
- # re-frame (3)
- # releases (1)
- # reveal (13)
- # rewrite-clj (1)
- # shadow-cljs (8)
- # specter (5)
- # sql (4)
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.
Startup times of just plain Clojure go from 4s under Rosetta to a hair under 1 second in native.
@orestis Also saw some major speedups with Azul on M1. Had to drop REBL to run it though—there’s no JFX for Arm.
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...
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.
@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.
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)
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.
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.
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.
@dharrigan At least you didn't end up with "dev", then local dev vs live dev becomes very confusing.
@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.
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
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
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)
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
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.
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.