This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-18
Channels
- # admin-announcements (3)
- # alda (1)
- # boot (85)
- # capetown (4)
- # cider (10)
- # clara (16)
- # cljsrn (3)
- # clojars (35)
- # clojure (83)
- # clojure-austin (8)
- # clojure-brasil (4)
- # clojure-canada (16)
- # clojure-greece (2)
- # clojure-ireland (7)
- # clojure-russia (23)
- # clojure-spec (22)
- # clojure-uk (151)
- # clojurescript (97)
- # core-async (10)
- # cursive (1)
- # datascript (7)
- # datomic (21)
- # defnpodcast (13)
- # devcards (3)
- # emacs (4)
- # events (3)
- # hoplon (18)
- # juxt (4)
- # leiningen (7)
- # mount (4)
- # off-topic (2)
- # om (1)
- # onyx (30)
- # planck (6)
- # proton (81)
- # re-frame (3)
- # reagent (9)
- # rum (10)
- # spacemacs (1)
- # specter (6)
- # testing (7)
- # untangled (66)
- # vim (84)
- # yada (23)
Morning
morning.
I’ve actually managed an hour writing Clojure this morning before I’m about to ‘get real’ back to to an incredibly verbose, boilerplate-heavy project based on Spring 😕
Sounds like my life atm except I only get to review boilerplate-heavy project in Spring!
this channel just turned into a monty python sketch
When I were Lad I used to punch cards wit' fingernails....
I honestly think I'd prefer to eat gravel than maintain a 34kloc for a 3 entity crud application.
34kloc...luxury!
for 3 entities....
I'm reviewing...not writing mind, just reviewing 1.2 million LOC for app that calls onto backend services for t' business logic
Aye up @otfrom. Welcome t' Yorkshire
I think we've slipped into Monty Python sketch so clojure-and-now-for-something-completely-different?
COBOL..don't get me started on COBOL...that were proper language..
does COBOL have lexical closures @agile_geek ?
@mccraigmccraig: who needs lexical closures when you've goto's?
MOVE A TO B. SUBTRACT C FROM B. GOTO PARAGRAPH-A. It's that simple. All in 72 columns on a punchcard. Now that we're real programming.
holy crap - "In 1997, Gartner Group estimated that there were a total of 200 billion lines of COBOL in existence, which ran 80% of all business programs"
Yep. Some of my COBOL from 1988 is still running in NHS
with OO features landing in 2002, aren't we overdue for COBOL/FP ?
The core banking systems in my current client are predominantly COBOL with a bit of C.
and are pushing over 30 years old
...also these rarely, if ever, go wrong. Unless someone screws up the Scheduler to run them.
if it ain't broke...
Yep. It's the 100 layers of stuff around them that tends to have issues.
what about customers with non-ASCII characters in their names or addresses ?
ASCII, it's all EBCDIC and who wants customers with funny names anyway?
serious question - what do asian banks run on ?
I think most of mainframes support UTF-16 now
how does that get retrofitted to exiting programs though ?
Haven't written any COBOL for over 20 years but think they've extended it to interop. I suspect they'd have to recompile using new compiler and job done bit not at all sure.
There was a lot of small rework done around y2k for dates so may have been similar exercise
i suppose the advantage of COBOL over c* is that it's sufficiently managed that there is no chance of programs depending on the character width or pointer size
Correct
i don't think i ever had a good time with ActiveMQ
@korny: 😄 for Clojure work...on MongoDB just don't read Kyle's stuff on consistency (it'll give you nightmares)
And whether they can put a few nice safe night-lights to sooth them when the nightmares happen.
Mind you, it’s a nightmare on almost all distributed systems if you have a network split, as far as I can tell. Kyle’s blogs are almost all “this broke like X”. You canna change the laws of physics ^H^H^H^H^H CAP theorem
Yeah. Most of his objections are "the documentation said it will do X when network partitions but it did Y" rather than this works no matter what.
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads this was April last year so may have all been fixed but even with write-majority on a single node there could be data loss.
That was prior to version 3 release so all may have changed.
Reading his blogs has got me reading papers on Dotted Version Vectors and CAP theorem in general. You have to remember CAP theorem wasn't proposed until I'd been out of Uni for over 10 years so sometimes I have to catch up!
Write majority is actually OK for us, as long as you also set read majority, and make sure you handle manually the failures that can occur. And we don’t have a huge need for linearizability.
Main annoyance is the dubious claims in the docs, and the lack of docs, and the guesswork around “what does this setting mean”...
@korny I think you will be ok if you can relax rules on linearizability
the DB / Queue authors probably new to this whole CAP thing aswell.
Yeah, in the end we have a good-enough setup. The main thing we needed to get our heads around was using Arbiters properly, so we could still get a majority if we lost an AWS availability zone.
@glenjamin: the scary thing is most of the 'Architects' in large corporates are my age but stopped implementing any code 15 years ago and don't read papers or go to conferences other than the 'buy my products' variety.
My main annoyance is all these vendors (even open-source ones) who seem to see robustness and reliability as the least important thing, and speed benchmarks as their main goal. The queueing vendors also seem to start assuming you are sending non-persistent messages to a single non-replicated server, and then vaguely treat distributed persistent queues as an afterthought. 😞
I mentioned CAP to the lead architect on my 'big data' POC project and he said "What's that?"
@korny: because that's the easier problem to solve
@agile_geek: “Lead architect”, you say..?
I gather that the job market should be a little (read a lot) easier for me when / if I return from SE Asia if that’s the bar… 😉
@agile_geek: very true. Mind you, I remember IBM / MQSeries trying to deal with similar problems in the ‘00s - so maybe some of those architects at least have dealt with queues before 🙂
@maleghast: he was Lead Architect for the entire Digital Division of Bank.
about 50-60 'projects' a year but his minions didn't know what it was either
@agile_geek: you don’t need to know CAP in order to draw three boxes on a whiteboard
@korny: Hey I was living it that world too
re: optimising for speed not robustness - they also do that because bloggers and the like always love pointless microbenchmarks. I’m in massive debt to Kyle, because he seems to have made an impact with tests that look at “does this actually work” rather than “how fast is it"
MQSeries was a horrible nightmare to configure, and a massive money pit. But at least it was pretty rock solid once you sold your firstborn children to the IBM consultants.
Kyle's biggest impact is the number of vendors publishing their own Jepsen results.
Yeah - still hoping to convince these people to consider RabbitMQ. They are a bit unkeen because there’s a desire for “AMQP 1.0 compatible” when Rabbit decided to stop at 0.9 compatibility
so it’s like JMS/STOMP - the messages are specified, but what they mean are up to the vendor
Here's Kyle's Jepsen on RabbitMQ https://aphyr.com/posts/315-jepsen-rabbitmq not as bad as some but still food for thought
Yeah - it’s a bit mad, we were trying at one stage to talk to ActiveMQ with a QPID client, and realised that the client’s understanding of failover differed from the broker’s.
@korny sounds like you've an interesting bit of consultancy there though. Wish I had something like that to get my teeth into.
@korny: Yeah, what @agile_geek said 🙂
It is interesting. Mostly, we’re using Jepsen to test out alternative architectures and API usage - so we’re note trying to prove linearizability or anything that mature, we’re trying to say “with our current API usage, if a server goes down / a network split occurs, what sort of errors happen, and can we monitor for them and manually fix problems”. And then making architecture decisions based on actual tests rather than documentation. It’s a good approach, evidence-based architecture… especially when tools writers make daft claims.
Yep. It’s not really that new ground - people like Netflix have been doing it for a while. But definitely hope to encourage this elsewhere...
@korny do you plan to be brave enough to let lose Chaos Monkeys in live once monitoring in place?
It’s also a nice foot-in-the-door for clojure. Though Jepsen isn’t exactly a tool for people new to the language!
Anyway, I should get back to banging my head against why Java exclusive FileLocks are broken...
some more messaging fun: http://www.infolace.com/blog/2016/07/14/simple-spatial-windowing-with-kafka-streams/
@thomas: my ProCloDo meetup on Wed
@agile_geek: cool, let me check if I can come to that one. thanks
@otfrom: potential parentheses blindness and RSI if taking with CIDER
thomas: I'm not sure I'd really apply anything that was from agile_geek. I'd probably want to reduce it
age is really limiting my ability to do clojure/ruby/python etc
I just can't keep the whole codebase in my head anymore
whaddayamean can't type @otfrom ?
oh, duh! lol
Oh the double edged sword that is a pun in the English language
Just got back from a meeting with a client that might turn into consultancy that might then turn into building something in Clojure
Early days but we shall see
wooohoooo @agile_geek good luck!!!
@agile_geek: Good Luck!
Oh I was in full Salesman mode. Just waiting on a short statement of probs so I can respond with a SOW for the consultancy piece.
16 bits, 16 bits, when I were a lad we used t' code with a single bit....and the 1 was broken on ours. Sorry, lapsed into 4 Yorkshire men again for a second
you’d be lucky to get a bit ‘round our end. We only had qubits and we were never really sure what they said
but looks like @glenjamin is right, you can't get all the emojiis into UTF-16.
UTF-16 is just dumb because it doesn't do anything that UTF-8 doesn't already do, and it's particularly dumb as an in-memory representation... i think it can extend like UTF-8 @glenjamin