This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (5)
- # beginners (136)
- # boot (1)
- # bristol-clojurians (6)
- # cider (46)
- # cljs-dev (172)
- # cljsrn (35)
- # clojure (82)
- # clojure-china (2)
- # clojure-dev (9)
- # clojure-dusseldorf (1)
- # clojure-finland (15)
- # clojure-italy (54)
- # clojure-norway (4)
- # clojure-russia (6)
- # clojure-spec (19)
- # clojure-uk (61)
- # clojurebridge (1)
- # clojurescript (55)
- # community-development (23)
- # cursive (7)
- # datomic (19)
- # emacs (10)
- # events (4)
- # fulcro (108)
- # graphql (7)
- # hoplon (1)
- # leiningen (7)
- # lumo (14)
- # off-topic (68)
- # onyx (23)
- # parinfer (8)
- # portkey (40)
- # precept (11)
- # re-frame (5)
- # reagent (40)
- # ring-swagger (5)
- # shadow-cljs (58)
- # specter (5)
- # tools-deps (37)
- # unrepl (13)
- # vim (9)
- # yada (12)
I don’t do much graph work, but I have a graph problem. I have an undirected graph with a set of nodes that I want to consider to be roots, and would like to find all nodes that are not connected to those roots. I’m playing with loom and it’s easy enough to build the graph but none of the fns seem obviously correct to do what I’d like. Any tips?
Mark roots, push connected nodes into a stack, mark everything in the stack, mark connected nodes, etc. Don’t push any nodes onto the stack that are already marked. When the stack is empty unmarked nodes are unconnected.
@tbaldridge: do you know of a good resource for "programming in datascript exercises" ? I'm looking for a resource that would have 100 exercises of common problems in CS, and solutions of how they would be solved in datascript. Most datascript resources seems to cover the basics, but never quite reach the level of "datascript idioms" or "datascript mastery"
@donaldball https://github.com/armstnp/advent-of-code-2017/blob/master/src/advent_of_code_2017/day_12_jgrapht.clj - Fiddled with JGraphT during Advent of Code, they've got a solver for that kind of problem;
This snippet builds the same kind of undirected graph. You can make short work of the problem by adding artifical edges between each root, making all the roots and their connected nodes join in a single set; all remaining nodes not in that set are by definition not connected to the roots.
For a lighter-weight dependency, you can implement it by hand with a disjoint set lib
Thanks y’all, with loom the fn wound up being pretty simple: https://gist.github.com/dball/b1489171d8f4e55af1716534190bdc64
I'm building a webapp, which offers new users a free trial. I don't want users to be able to get more free trails via creating more fake email addrs. Thus, I want to force "one phone # -- one free trail." Now, I could send SMS verification and paty those fees -- but is there some way to leverage an external api (whatsapp? telegram? signal?) where they do the auth and guarantees me unique phohne numbers ?
IMO it’s not worth the effort @qqq . Just make a good app, tie it to the email, and trust your users. Most people have no problem paying for quality products. And you’ll never stop the pirates
@tbaldridge: I think you're right. Per unit time, it's better spent making the software better so the user base will grow by X%, rather than trying to fight the X% of jerks who would never pay anyway.
Hey everyone, I am currently trying to figure out problems which developers face ? any one want to help me out . i have few question
My biggest problem is the lack of a paid StackOverflow. I want a resource where I can post request for sample code to do FOOBAR, attach a bounty, and get working code.
@qqq so something like provided a test, the first code to pass the test would get the bounty, and the code only is visible for the one who put the bounty on?
I’ve read “out of the tarpit” and really enjoyed it. Any suggestions for other papers of that nature?
And this also goes a bit into the same subjects shown in the paper https://www.youtube.com/watch?v=O3tVctB_VSU
Thanks @tbaldridge — any other suggestions for things a bit closer to the daily practices? I’m joining a new team and I’d like to woo them into paper reading a bit. Out of the tarpit was quite approachable even for someone who hasn’t ready any papers since uni days 15 years ago…
digs into Erlang a bit, but it's a good overview of how they deal with fault tolerant systems.
wow. in the paper describing the correctness of the tools in erlang > At the time of writing the largest of these projects is a major Ericsson product, having over a million lines of Erlang code. This product (the AXD301) is thought to be one of the most reliable products ever made by Ericsson.
The paper was written in 2003? Erlang was first written in 1986 by engineers at Ericsson, so it wasn't exactly a "all-in"
But yeah, for what it was designed to do, Erlang is really good at it. My only complaints with the language is that I don't often need to do those things.
Erlang works best with message rates and small message sizes a few hundred bytes or so. So it baffles me when people want to write web servers with it where the headers alone are 1KB.
> The language started as an experiment to add concurrent processes to Prolog sounds right up your alley
Apparently they got the compiler written fairly quickly. According to Joe Armstrong: "the hardest part was the pattern matcher. That was 10k lines of code, and there was only one code comment about half way through that said 'now for the hard part'"
reminds me of this comment that was in emacs' display code below an ascii skull and cross bones > BEWARE!! All ye who enter here: Most of the code in this module is twisted beyond belief! Tread carefully. If you think you understand it, You Don't, So Look Again.
well some erlang http servers can nearly match nginx in terms of performance atm (depending on the scenario of course)
there's a lot of dirty tricks internally to avoid message passing everywhere, but it works
Once the design of the JAM was complete I started a C implementation of the virtual machine—which was soon abandoned ader Mike Williams read some of my C code—ader which I worked on the compiler. Mike Williams wrote the virtual machine emulator and Robert Virding worked on the Erlang libraries.
Yeah, in Erlang most of the IO can be done using lists (and malformed ones to boot) to boost performance — this maps almost directly to the system IO calls rather than having to build a big string in user land and copy that over to the OS.
Regarding iolists, here is an exploration: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1-building-output-efficiently/
https://deeptalent.com/blog/tenure-length-tech-titans-compared/ <-- is this accurate? most people I've talked to tend to stick with a company for 4+ years, but anecdote != global data
@qqq It seems unlikely that someone here has already done a similar data analysis on such a large data sample as the authors, and can refute the article's claims based upon their own knowledge.
Anecdotally, I recall hearing that around 1999-2000 time frame, the average time for engineers to stay at one company was around 14 months, and the only reason it was that long, instead of shorter, is because typical contracts include a clause that you vest 0 stock options until working at the same place for 12 months.
So at the time of that Internet bubble, people on average were sticking around long enough to get 1 year's worth of vested stock options, then moving on.
There are a lot of contract positions in the tech industry, too, which I would guess tend to have shorter average durations at one company. The article you linked does not mention whether they tried to separate out contract positions from full time positions.
https://hackerlife.co/blog/san-francisco-large-corporation-employee-tenure https://insights.dice.com/2017/08/22/tech-jobs-last-2-years-study/ other sources seem to also suggest short tenures
They say that their sample only includes people who say they worked at, then stopped working at, one of the companies they listed. It does not include people who started working at, and continue to work at, those companies.
They would still have the same issues of "position changes while remaining at the same company" to handle. Not sure it would be significantly easier for LinkedIn vs. other people.
probably also depends on what stage of careers they tend to hire at. You kinda need to bounce around a lot at the beginning to get decent pay raises in tech. I guess once that starts to plateau you can stick to one company longer…also you probably know what you like more
I'm at my fourth company in 6 years. And the first one was a large one, and we had a peer group of about 15 people, and they are all gone by now. It seems how bigger the company, how faster people leave, maybe because they feel less commented to the company.