It will cost a little more than the cheap ones on Amazon, but you get fully locally-hosted setup and their camera controller is running linux. You can swap in your own hard-drive for storing recordings. No subscriptions, and setup is pretty easy. Their technical support is top-notch - it's a small company and their engineers know the equipment well. No relationship, but I a customer.
Personally, I like Zulip way better than Slack because of how it does message threads: _channels_ that have conversations in _topics_ "makes sense" to me.
Pros: Server maintenance is blissfully minimal. Message threading that actually works. No server issues or downtime in the past 4 years. (Every time I see a HN "Slack is down" posting, I smile to myself and continue my work day...) It runs great for ~50 employees on an AWS t3a.large instance. Importing all the company's previous messages from Slack worked perfectly.
Cons: If you have people used to Slack, there will be resistance / a learning curve. Knowing, "when do I create a topic?" takes practice. The mobile and desktop apps are not as polished as Slack's. Not as many integrations as Slack. You have to know enough to manage and secure a server yourself.
The Zulip devs accept Github donations, btw, if anyone cares to support their work. (We do; no affiliation other than we're happy to have a private, self-hosted alternative.)
edits: punctuation and adding that instance was a ".large"
I've been using it professionally for a little over two years as well. At a basic level, it's doing basic API / CRUD pages but, combined with the Phoenix framework, it feels like my time is much more effective (maybe 10% boilerplate, 90% business logic).
On a more advanced level, it also drives websocket communication for our web app, making two-way communication both simple and fast. We also take advantage of its multi-process facilities to drive long running tasks (cron jobs, long-running HTTP requests to slow services, data batching and analysis...) all within the same tool.
It's paid dividends distilling what would otherwise be a complex setup of various tools, each with their own communication interfaces and failure modes, into one simpler system.
Elixir is not "general purpose" like C, Python, or Rust might be, but it doesn't pretend to be. But for writing maintainable, robust, distributed and fault-tolerant systems that do networking, I love it.
I worked as a programmer for a smaller California county court system for about five years, and have seen something very much like this play out before (both in my county and others).
I can't comment on the Tyler product or their training directly; maybe they really are a rock star outfit. But if this is like past attempts, this project has all of of the worst of aspects of software development risks and none of our more "modern" methods to mitigate them.
The court employees - most of whom would _not_ be considered very computer savvy - probably had a lot of training directly with Tyler but are struggling with a system that a) doesn't meet their needs, b) changes years (decades?) of ingrained workflow habits and terminology, and c) may be much slower than what they used to have.
Observations from past projects like this:
* at it's heart it's a database CRUD app, but with hundreds of tables and thousands of fields and business "logic" encoded (in more database fields) to help with validation and workflow
* most of the above fields need to be fully customized for each county, so add in tables and logic to modify your UI on every screen
* this software was not built for Alameda county, but re-purposed from use elsewhere. Terms and concepts for how the law worked in the state this was originally built for may or may not apply here.
* "usability" success metric: "do all 50 fields on the page accept input and save data in less than 60 seconds?" (i.e. no concept of real HCI usability design at all)
* iteration process: waterfall. Vendor sits with court subject experts for 2-3 months, documenting all of the workflow. They customize their product to meet those needs, and a month later show a build that does this. Court can't use it yet (deployment locally would cost way too much), but they've printed out hundred of pages of screen shots to help document how it could be used. Hire external consultants to help with this process. Repeat until a) court money runs out or b) someone's reputation will be tarnished if the system doesn't launch
* There is no staging environment. Deployment is on local hardware only (no cloud). No bug tracker exists that the court can see. Builds are not automated, and "maintenance" may cost the court additional money.
* importing previous cases: worst ETL job you can imagine. Take data from an aging mainframe database that may or may not have any relational integrity at all, and try to plug it into a system as described in point 1
* administrative overhead: your county is given money from the state to do this, and then no choice about which vendor or software to use (because the state wants to roll this out in _all_ counties... each of which is very different from one another, even in CA)
tl;dr This is a horribly difficult software update, subject to the worst practices in our industry.
Personally, I don't think blaming court employees for "clerical errors" is fair at all - not that those haven't happened, but (from my experience) these are hard working people who care about justice yet have really lousy software that impedes their job.
I'd love to see a company do this software right - custom build, real iterative development hand in hand with the users. The Courts really needs it, they've never experienced a high quality product in this area, and the inefficiencies affect the wider economy (because civil matters are faster to resolve).
From Adam Langley, who works at Google on their SSL stack, on his post "How to botch TLS forward secrecy":
In the case of multiplicative Diffie-Hellman (i.e. DHE), servers are free to choose their own, arbitrary DH groups. <snip> ... it's still the case that some servers use 512-bit DH groups, meaning that the connection can be broken open with relatively little effort.
Satire is well and good, but i can't grok #9. Interviews in a hot tub? So... even for the women? Or is it used preferentially for high pressure engineers only (whom of course are all men)?
It may be just me, but I can't see the HR department in any state being okay with that. And if it's not for interviews... what's it for?
It will cost a little more than the cheap ones on Amazon, but you get fully locally-hosted setup and their camera controller is running linux. You can swap in your own hard-drive for storing recordings. No subscriptions, and setup is pretty easy. Their technical support is top-notch - it's a small company and their engineers know the equipment well. No relationship, but I a customer.