161–170 of 176 posts
Gitter is a great idea in theory. In practice it's just been a place for my questions to go unanswered.
some gitter communities are pretty dead though.
Gitter is a great idea in theory. In practice it's just been a place for my questions to go unanswered.
This reminds me of something I want to share with HN. I've put a lot of thought into how technologists seem to forget to think about how their tools will be adopted and used in a collective sense. They seem to not design their tools for the end result. https://medium.com/@xpe/designing-effective-communication-67... > Can your product provide a great user experience for the group sizes and compositions you want to sup…
https://twitter.com/aurynn/status/882411143611924480
https://twitter.com/aurynn/status/882036680869371904
Confronting, but accurate.
Earlier quoted context omitted.
Does Gitter have federated servers using a standard protocol and a vast array of programmable extensions? None of these hosted solutions are even in the same league as IRC, and we are worse off for it.
As someone who has written an IRC server implementation, there is no standard protocol. There is an RFC, but no one implements it. Instead, each server uses its own mix of poorly documented pseudo-standards.
Earlier quoted context omitted.
IRC is not going anywhere but projects like neovim use gitter primarily while IRC is linked using a bot. They view the IRC chat in gitter. Dunno if Gitter is better than IRC as I have only used for help and support (for me) but Gitter was far easier to use than IRC. Just Login and start chatting. I don't think IRC is going anywhere either... We just have alternatives to freenode now in Gitter
> IRC is not going anywhere I don't know if this still holds true. I've been a IRC user for ~20 years and the current state is a fraction of the fraction of it was once before. Compared with the entire internet, it can already be considered irrelevant, imo.
Earlier quoted context omitted.
If people check in their node_modules, that's a good sign to stay away from the project.
What? Why? Why shouldn't I be able to run my entire application without relying on 3rd party distribution channels? Caching my dependencies in node_modules is perfectly reasonable to me. It's not like I'm getting binary diffs. It's Javascript.
If you want to mirror your dependencies, run an npm mirror subset or something. If that sounds crazy to you, that's because mirroring npm dependencies is unnecessary for virtually everybody.
Oh, and you are also making your .git folder 100x larger than it otherwise would be, making your initial download and on-disk sizes a lot bigger, which can also slow down other git operations. Not to mention the atrocious amount of noise whenever someone does a git blame, git log, git log -S, ...
In other words, checking in your entire dependency source tree in git is unnecessary, wasteful and annoying in the best case scenario.
> Gitter requires MongoDB, Redis, ElasticSearch and Neo4J Why use one database when you can use four!
Or maybe they should use the ever-so-performant MongoDB as their cache, that'll work out great.
Actually, scratch that, Gitter should probably store all its relational data in ElasticSearch because why use one database when you can use four?.
Earlier quoted context omitted.
This is actually the first real project I've come across that uses neo4j - thank you for pointing that out. Given the requirements, I actually think this project looks rather clean between the docker-compose-file and the npm dependencies. I very much doubt it can compete with Mattermost or Rocket.chat for self-host for small organizations - but I'm really happy to see this thing open sourced! I much prefer it to be o…
(Gitter Co-founder here) Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it. These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a…
Earlier quoted context omitted.
This is actually the first real project I've come across that uses neo4j - thank you for pointing that out. Given the requirements, I actually think this project looks rather clean between the docker-compose-file and the npm dependencies. I very much doubt it can compete with Mattermost or Rocket.chat for self-host for small organizations - but I'm really happy to see this thing open sourced! I much prefer it to be o…
(Gitter Co-founder here) Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it. These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a…
Earlier quoted context omitted.
Would you mind elaborating? As a user who would follow this instruction without thinking twice I'd like to understand better why this is a bad idea.
Two others touched on the sudo part but the global flag is as bad. So they have a gulp file that works with gulp "v1". Gitter goes bust (inactive), next year gulp is bumped to "v2", you want to try out gitter, gulp fails, you have to digg why. Another scenario is when another project asks you do the same, install gulp globally, but it actually means gulp "v0". Now you can't run to projects side by side. Global deps s…
This is very much v1 of the setup/instructions and would be delighted to improve them with any MRs or contributions. We'll certainly improve them ourselves over time as we get more people in less controlled environments adopting the project.
Earlier quoted context omitted.
(Gitter Co-founder here) Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it. These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a…
Why not get in touch with us and let us help you instead of dropping us?
I'm not going to be changing anything around the suggestions any time soon, but who should I get in touch with when I do?