5 ms·

Why do people talk like this is some impossible feat for IRC? 1. Have a bot that's in the channel from the start 2. cd into the bot's log directory and type p

by okasaki 11y ago

Why do people talk like this is some impossible feat for IRC? 1. Have a bot that's in the channel from the start 2. cd into the bot's log directory and type python -m SimpleHTTPServer 3. put the url into the channel topic How do some developers fail to rise up to this level of problem solving? I am amazed.

enraged_camel 11y ago
I'm a developer. The problem is not that I'm "failing to rise up to this level of problem-solving". The problem is how much free time I have, and whether I can afford distractions from my main project to fiddle with IRC and get it to do what I want. We use Slack because "it just works". You get invited, you join, and BAM! You're done. There is one uniform client for all platforms and a bazillion integrations already developed for you. And creating your own is usually a simple matter of sending a POST request to a channel's webhook using a unique token. Essentially it comes down to this: IRC is a protocol that requires a fair amount of research and configuration to make it do exactly what you want it to do. Slack is a product that comes with the vast majority of features most teams need. That's why a ton of people are gravitating towards the latter.
xanderstrike 11y ago
But that's substantially less useful than Slack's search utility. Believe me, I've spent my fair share of time grepping IRC logs and it certainly works up to a point. What you describe is a pretty lightweight, low-utility solution (are you really going to download six months/a year/10 years worth of logs and depend on your browser's search?). Plus, keep in mind there are other people besides developers. There are product managers, UX engineers, designers, translators, and any other number of people who might not be familiar with grep and would otherwise not need to be. Assuming that only developers need to chat is pretty naive.
enjo 11y ago
What if I didn't have the foresight to put that bot into the channel in the first place? Or what happens when the bot goes down? So now I really need to build some alerting into it so that someone can restart the thing when it dies, or the server is upgraded, or it's moved.. because I'm losing valuable history along the way. Or I can just use Slack. The snark about developer skill is an interesting one, as you failed to actually solve the problem in your hypothetical.
- okasaki 11y ago
  Seems you've only explored failures for the IRC option. What happens when Slack closes? Or they change their payment plan? Or they decide that they don't like your project? Or they're acquired by Microsoft and stop supporting your OS? What if a rogue Slack employee spies on your chat and steals your secrets?
- chris_wot 11y ago
  So slack manages everything for you with their service. They ensure their logger is always running, their web services is always available and a Miriam of other things. What you want is to outsource your messaging service. If you want this to be managed in-house, you must monitor the service as well. You can outsource IRC as well however, and they'll manage the boys and infrastructure for you. Not sure if I understand what the issue truly is here!
ebiester 11y ago
Can it be done? Sure. Should I take the time to create a solution that not only works for me, but is a pleasant user experience for my entire organization? That is a piece of work that is bigger than "python -m SimpleHTTPServer". Or, I can trade money for a team that is actively solving the problem already. Or, people who care could get a group together to tackle the inadequacies of IRC for the business use case as mattermost is trying. But let's not pretend that IRC fits the Slack use case well.
vonklaus 11y ago
> How do some developers fail to rise up to this level of problem solving? It does seem to solve the problem of how to set up a channel log in IRC but I sort of find this quite a narrow redefinition of the problem. The problem could also be: * What is the best technology to use for collaboration? * What kind of software and tooling is in line with our project philosophy. I don't find either this comment, nor the one it is in reply to something that can be applied more generally. This is, at best, solving a problem that is a component of a much more expansive problem.

by okasaki 11y ago

enraged_camel 11y ago

I'm a developer. The problem is not that I'm "failing to rise up to this level of problem-solving". The problem is how much free time I have, and whether I can afford distractions from my main project to fiddle with IRC and get it to do what I want. We use Slack because "it just works". You get invited, you join, and BAM! You're done. There is one uniform client for all platforms and a bazillion integrations already developed for you. And creating your own is usually a simple matter of sending a POST request to a channel's webhook using a unique token. Essentially it comes down to this: IRC is a protocol that requires a fair amount of research and configuration to make it do exactly what you want it to do. Slack is a product that comes with the vast majority of features most teams need. That's why a ton of people are gravitating towards the latter.

xanderstrike 11y ago

But that's substantially less useful than Slack's search utility. Believe me, I've spent my fair share of time grepping IRC logs and it certainly works up to a point. What you describe is a pretty lightweight, low-utility solution (are you really going to download six months/a year/10 years worth of logs and depend on your browser's search?). Plus, keep in mind there are other people besides developers. There are product managers, UX engineers, designers, translators, and any other number of people who might not be familiar with grep and would otherwise not need to be. Assuming that only developers need to chat is pretty naive.

enjo 11y ago

What if I didn't have the foresight to put that bot into the channel in the first place? Or what happens when the bot goes down? So now I really need to build some alerting into it so that someone can restart the thing when it dies, or the server is upgraded, or it's moved.. because I'm losing valuable history along the way. Or I can just use Slack. The snark about developer skill is an interesting one, as you failed to actually solve the problem in your hypothetical.

okasaki 11y ago
Seems you've only explored failures for the IRC option. What happens when Slack closes? Or they change their payment plan? Or they decide that they don't like your project? Or they're acquired by Microsoft and stop supporting your OS? What if a rogue Slack employee spies on your chat and steals your secrets?
chris_wot 11y ago
So slack manages everything for you with their service. They ensure their logger is always running, their web services is always available and a Miriam of other things. What you want is to outsource your messaging service. If you want this to be managed in-house, you must monitor the service as well. You can outsource IRC as well however, and they'll manage the boys and infrastructure for you. Not sure if I understand what the issue truly is here!

ebiester 11y ago

Can it be done? Sure. Should I take the time to create a solution that not only works for me, but is a pleasant user experience for my entire organization? That is a piece of work that is bigger than "python -m SimpleHTTPServer". Or, I can trade money for a team that is actively solving the problem already. Or, people who care could get a group together to tackle the inadequacies of IRC for the business use case as mattermost is trying. But let's not pretend that IRC fits the Slack use case well.

vonklaus 11y ago

> How do some developers fail to rise up to this level of problem solving? It does seem to solve the problem of how to set up a channel log in IRC but I sort of find this quite a narrow redefinition of the problem. The problem could also be: * What is the best technology to use for collaboration? * What kind of software and tooling is in line with our project philosophy. I don't find either this comment, nor the one it is in reply to something that can be applied more generally. This is, at best, solving a problem that is a component of a much more expansive problem.