This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (1)
- # aleph (9)
- # announcements (22)
- # beginners (59)
- # boot (8)
- # calva (1)
- # cljdoc (7)
- # cljs-dev (10)
- # cljsrn (9)
- # clojars (10)
- # clojure (23)
- # clojure-dev (6)
- # clojure-europe (3)
- # clojure-italy (26)
- # clojure-nl (3)
- # clojure-seattle (1)
- # clojure-spec (46)
- # clojure-uk (85)
- # clojurescript (97)
- # core-async (13)
- # cursive (3)
- # data-science (10)
- # datomic (156)
- # duct (34)
- # emacs (37)
- # figwheel (3)
- # figwheel-main (9)
- # fulcro (59)
- # hyperfiddle (4)
- # immutant (1)
- # jackdaw (3)
- # jobs (1)
- # off-topic (112)
- # parinfer (1)
- # qlkit (2)
- # re-frame (1)
- # reagent (35)
- # ring-swagger (2)
- # shadow-cljs (104)
- # spacemacs (9)
- # speculative (12)
- # tools-deps (30)
- # yada (10)
the idea being that developers usually have a bunch of ports in use (e.g. running multiple projects) but all projects usually want to use port 3000, and 3449 for figwheel. It seems like a dev would love to be able to navigate to http://google.local/ rather than http://localhost:3003
I'm considering making port numbers random in edge, or perhaps updating a .edn file at the root with port claims so that projects don't fight each other.
found two references to something that looks remotely useful, SRV records, and also people fiddling with iptables
--to-destination (which accepts ip:port)
I wouldn't even mind something like "java process [Google] is using port 3030, save for next time?"
k8s/docker solutions do this, either by creating an overlay ip network or binding extra ip addresses to an existing interface and then iptables or similar to bridge... perhaps there are some tools from that space which can help?
Yeah but they (Docker containers) do it kinda differently, don’t they? You can have 10 containers all thinking they’re available on on 80, where in fact they’re available on localhost:2080, localhost:2090 (or whatever) and so on
depends @lady3janepl - that is one possibility, but EKS (AWS managed k8s) binds extra IPs from the VPC to the network interface and gives each pod it's own IP, so the container really does get port 80 on that IP
right, but the same solution is quite workable - add extra IPs to your network interface
Edge could have a component which always runs on port 3000. If there's something already on 3000, it will connect to it. I guess it will need to check again every minute or so. The "master" will provide a portal to all registered applications. Application is pretty broad, and can be any url of interest, eg devcards. The master will be in charge of ports, but will write them to a known location so that new masters can start utilizing the file without interruption. The master will be in charge of syncing the hosts file.
This is the part where you all tell me this is a terrible idea and that I shouldn't do it...
I'm just wondering what problem it's solving. Is this something that trips you up a lot? It sounds quite complicated
My colleagues get annoyed that they have port collisions when working on multiple projects simultaneously.
I suppose it's the old 'argument from personal incredulity' thing, but I can't remember having that issue myself. Is this a technical solution to an organisational problem (i.e. just tell people to configure their ports differently)?
@conor.p.farrell this might be because we have a lot of projects, and developers work on multiple of those projects. Yeah, we could create some document somewhere as a "port registry" and every project has to register the ports in use there. Seems like it's unlikely to happen though. People forget/don't realize, whatever.
then you have to change the port later, which means everyone who's "used" to the old url now has to switch to a new one.
I think the solution is to give people laptops with a smaller amount of RAM so they have to close one project before opening the other
we had a similar issue with docker containers and assigning 'predictable' ports to them that would clash across projects, e.g something like elasticsearch could be mapped as 39200 -> 9200.
a solution we arrived at was allowing
docker-compose auto assign a port on the host to a defined port on the container and then a leiningen plugin that uses the
docker-compose.yml to discover the auto assigned ports for those containers and sort of inject them into the system
would be trickier for the likes of figwheel because we're not mapping to anything in a container, unless you could also let figwheel auto assign its port and once the repl starts up/the system starts, pop open a browser tab on that port from the repl?
according to this it isn't 100% sure: https://quoteinvestigator.com/2011/09/08/640k-enough/
re: JVM versions. We use Java 8, but are trying to get everything running on 11. That XML binding module thing that @dominicm mentions has been by far the biggest problem. First it was included, then it was optional now it has been removed entirely. Project Jigsaw has a lot to answer for.
I always thought it was rather strange that Java 9 was the first ever release to break backwards compatibility. Seems like a way to ask for trouble.