61–70 of 126 posts
I'm a matrix - really via riot client - user, but never used zulip...Can anyone cite 1 or 2 big benefits of using zulip over matrix clients? I'm genuinely curious.
For me it's Zulip Topics - they make it very easy to organize the communication. You have channels and they contain topics. This is one of the most useful features of Zulip.
Most features of all chat clients (riot, slack, mattermost, rocket.chat, zulip) are pretty similar.
But of course that's not to say that there is anything wrong with the quality of the product being promoted here.
Earlier quoted context omitted.
You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.
Is this a common workflow? Googling suggests almost religious feelings about this.
i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load.
however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks:
https://medium.com/@fredrikmorken/why-you-should-stop-using-...
the classic example of a rebase pitfall is:
a) you branch from master,
b) on your feature branch, develop a feature utilizing dependency x,
c) meanwhile, on master, another developer removes dependency x,
d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.
As someone who follows technology closely, I find it a bit frustrating that chat is making such little progress, and that for our communication we've essentially moved from federated email to silo-based chat solutions (which is hardly a feature), and lock-in that comes with these. How is "IT" going to save the world if we get stuck like this as a profession? I suspect one problem is that at universities there is no c…
"Zulip now has an IRC bridge powered by matrix.org"
We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?
How is a basic database, cache and queue too much?
Earlier quoted context omitted.
A more specific slack channel (and I assume mattermost channel) is a thread that you can add people to any time and they will immediately have history. Or put in the inverse, a Zulip thread that is too general is a channel with information overload and becomes useless. Does the nesting have intrinsic value over simply more top level channels?
Mattermost has threads inside channels as well, but they end up underused since posts need not be to any specific thread. The idea is you subscribe to a channel, but then any post to the channel needs to also have some sort of logical subject.
Zulip, used well, ensures that the messages are partitioned into different conversations, so you can easily do things like skip to the bottom of a long thread to see if it ends in a satisfactory resolution, without missing the unrelated question that you need to answer.
How well does the Hangouts integration work? I found it involved too many steps when using Hangouts in Slack
What are the steps involved? For us, it's "tap the phone icon in the top right".
We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?
It took us 10 minutes to run a production-ready Zulip server. The installation script handles everything without any issues. https://zulip.readthedocs.io/en/latest/production/install.ht... > just to run a chat Don't overlook the fact that this is a scalable and stable solution used by many companies with thousands of users for each instance. I would have my doubts about the project if it wouldn't use those components…
As someone who follows technology closely, I find it a bit frustrating that chat is making such little progress, and that for our communication we've essentially moved from federated email to silo-based chat solutions (which is hardly a feature), and lock-in that comes with these. How is "IT" going to save the world if we get stuck like this as a profession? I suspect one problem is that at universities there is no c…
For what it's worth, Zulip is one of a few projects to support federated chat. From the linked document: "Zulip now has an IRC bridge powered by matrix.org"
See: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
(not saying this is the case here, just that it shouldn't be a concern)
Earlier quoted context omitted.
It took us 10 minutes to run a production-ready Zulip server. The installation script handles everything without any issues. https://zulip.readthedocs.io/en/latest/production/install.ht... > just to run a chat Don't overlook the fact that this is a scalable and stable solution used by many companies with thousands of users for each instance. I would have my doubts about the project if it wouldn't use those components…
I certainly believe it’s scalable, but I have a hard time seeing the need for two caching products, a queue and a db just to get it to start.