I find it very useful to talk to my dog. When I have a problem I'm banging my head against, just explaining it to him from first principles makes my head "click". When that works, his dog treats are billed as "consulting".
The anti-nuclear area, at least in Western Europe, had historically a very high correlation with those who held sympathies for a certain very large nuclear power who would have strategically benefited from an anti-nuke sentiment that would avoid another nuclear power's weapon deployment in EU bases. But I'm sure it is a coincidence.
Imagine when you receive millions of events per day -- the ones that arrive out of order, the days when delivery time goes up and up again, the days when oauth fails renewing keys... it's meant to be a lot of fun.
Compare to a sad websocket that just stays connected, you receive everything in order and you don't need an harness with tunnels every time you want to test something in dev.
Interesting to see the SDK making chat/bot integration simpler, but there's a whole other dimension to Teams integration that this doesn't touch: telephony.
The company I'm at has been been building call analytics for Teams since 2021 (QueueMetrics Live). A long-time customer migrated their entire phone system to Teams during the pandemic and asked my boss if we could follow them there. We said "in principle, yes": the Graph API exposes telephony events, so it seemed doable.
It was doable. It was also far harder than anybody expected. The Graph API gives you raw call records, but it doesn't model concepts like "wait time in queue" or "lost call" or "failed agent attempt", and whet it does, nowhere it written HOW. You have to reconstruct those from sequences of low-level events. We ended up building the whole processing pipeline in Elixir because we needed to handle the real-time stream reliably at scale. After a long beta and a few million calls processed, we got to GA. I was dabbling in Elixir at the time, I put it on my CV, and it was noted. In a sense, I owe Teams my current job (though I ended up on a different team, so I'm mostly referring coffee-mug lore here).
We set out to track queues and auto-attendants (that's our bread and butter from the Asterisk world), but we discovered we were seeing everything — inbound, outbound, Teams-to-Teams, even calls with other companies with their internal ids. You can get a complete picture of someone's telephony activity regardless of whether they work in a contact center or just use Teams as their phone. Most of the boring config (names, groups, codes) comes straight from Graph, which is nice.
Like it or not, a lot of enterprises are quietly moving their entire communications (including telephony) to Teams. When they do, they lose the monitoring and analytics they had with their old PBX. That's a real gap, and the Graph API — despite its limitations — gives you something to fill it. But I have a feeling that "3 lines of code" won't cut it. :-)
Actually, both will, as they are not separate within the LLM. The thing is, one is a style issue, the other content. You can express original ideas and still use a lot of em dashes, or produce slop with a lot of typos in it.
I have a pet-peeve with this. As a non-native English speaker, I find it very useful to dictate multiple notes, in different languages, and have the LLM produce clear English prose out of it. The prose may be LLM-generated, but I edit it when needed to make sure that the contents is 100% mine.
It's like dictating to a typist like they did in the 60's - he will make sure that your letter looks professional and will fix your grammar, but you will sign the letter. This is totally different from LLM spam, the kind that inflates a sentence into a three-page article full of nothing.
So - is it a problem if the language reverts to a mean? that is the point of a shared language, right?
...and does no harm for unfixable bugs. It's the logical equivalent of "switch off and on again" that as we know fixes most issues by itself, but happening only on a part of your software deployment, so most of it will keep running.
I do the same thing - Instead of going first to an unknown site that might (will?) be ad-infested and possibly AI generated, so that a phrase becomes a 1000-word article, I read the comments on HN, decide if it's interesting enough to take the risk, and then click. If it's Medium or similar, I won't click.
Hey, coming out feels good - I thought I was the only one.
Just my two cents - the worst pieces of tech I ever worked with in my 40+ year career were Hibernate (second) and XSLT templating for an email templating system around 2005. Would not touch it with a stick if I can avoid it.
Related: Retrocampus BBS is a dial-up BBS you can call with your Videotel terminal in Italy... or access with your browser right now - https://bbs.retrocampus.com/
Of course I'm not suggesting at all that you waste an otherwise perfectly productive day playing Zork I-II-III or Hitchhiker's on it... ;-)
Let me put into personal context: I have loved PKD's work for almost 40 years now, and I think I have read all that I found from him or about him. This said, good prose is different from the one he turned out. Compare him to his friend "ELRON" - now he was a master storyteller. Compare him to - say - Stephen King. He's not playing in the same league, maybe not even the same game. OTOH they did not have what he had - he was. great writer in spite of his often poor prose.
Wonderful writer? let's face it: he was a mediocre writer, but had such powerful ideas/visions/themes (you name them) that you, as a reader, are hooked to his stuff.
Rewriting the Elixir parser for QueueMetrics live for Teams, my company's service to keep track of call and queue statistics for Microsoft Teams telephony, in a way that's better than the PowerBI examples that come in the box. It's at https://www.queuemetrics.com/teams.jsp?lid=H990
It's quite a mess as we have to aggregate multiple data sources that come with their own timing and sequence issues - plus we are seeing massive adoption so resource usage will be interesting for v2.
The plus side is that building massively parallel and redundant services in Elixir is, if not actually fun, at least more feasible than in other environments.