That's true! But there are two reasons I didn't go that route:
1) I wanted to build this ;)
2) Slack's IRC integration does not mark messages as read until you exit the IRC client. (Granted, mine doesn't mark them as read at all, but -- it _can_!)
I upvoted this comment because I really like the idea of "I built this because I wanted to". I like the idea of Show HNs as an "I made this thing for me, and not for any other reason". Thanks for posting your project!
> But there are two reasons I didn't go that route:
My biggest issue is that Slack doesn't allow non-paying accounts (I forget what they call the tier - "guest" account or something) to use the IRC gateway.
There's one project I'm involved with that moved its support channel from Freenode to Slack. I used to idle in the channel 24/7 thanks to ZNC, and now I have to actually log in through the web interface every time I want to ask a question. It's their loss, too, because I'm also no longer as available to answer other users' questions.
If you run a software project, please, please, do not host your support channel on Slack. I don't want to have to request an invitation just to join the channel, and I don't want to have to either download and open the Slack app or use their web interface[0] just to ask a question or answer other people's questions.
[0] Their web interface has really terrible performance, and last I checked, their Linux "app" was just a webview around said web interface, with equally terrible performance.
At the company I work for, we don't have a paid Slack account for our team, but I remember at least one of my coworkers using his regular IRC bouncer to connect to Slack.
Maybe they changed the rules since the last time you checked?
2) is a pretty good point actually, maybe slack could integrate that in their backend - basically if the irc client is set as away do not mark read.
if not or returns from away, make all buffers read.
Not too hard and would be quite convenient (im not a slack user, but if i become one, id like that in case i log in the webui later..)
I was building something similar in Go for the exact same reason so looks like there is validation for the product at least! Great work on shipping, incredibly well commented and clean.
Thanks, appreciate it! I considered Go for this too, but wanted to use PHP because you don't see too many curses PHP apps around, and I wanted to observe one for myself ;)
There's only a couple of things that stood out to me as suboptimal:
- PHP ncurses is not well documented beyond just function signatures. Of course, curses itself is well documented, and ncurses functions map one to one with the PHP extension, so that wasn't really that bad.
- I should have separated my classes and built a PHAR (PHP archive), but I got lazy.
- There's the portability comment I've made a few times already
But other than all that, PHP did its job perfectly. Easy to write, read, and organize.
Right. Hard to argue with that. But if you're going to say that to me, then you'll also need to tell that to everyone releasing software that gets installed via `npm install -g` or `gem install`, too!
i was all interested until i saw PHP. That's not a dis on PHP. It's just that PHP is so not the right tool for the job for a command line client. Sure, it appears you can coerce it to do that but... it's designed for embedding in web pages. that's what it's good at. if you want to write command line tools, write them in a language that's actually designed with stuff like that in mind.
I actually intended to write a comment in the README about my choice of language, but as things go, I forgot.
This was, first and foremost, an educational pet project for me. I /like/ building things in the wrong language. Hell, I run a blog called "Machine Learning in JavaScript", and I can't tell you the amount of criticism I've gotten over the years along the lines of "wrong tool for the job!".
I was actually surprised how well this worked in PHP. The only issue is that the ncurses PHP extension, not being compiled by default in most package managers' PHP distribution, does force you, the user, to take an extra step in installing it. That is unfortunate.
That would be a grave issue if I saw this as a product, but since it's a pet project, I see that as totally acceptable :) I actually never even intended to release this publicly!
That's not the issue here. You could have written that in shell script it wouldn't matter. Just that PHP(+ all the extensions required) makes it more difficult to deploy for someone who just want to try out your project.
This reminds me of people who say: "JavaScript is designed for embedding in web pages. Node.js developers are crazy too."
The Right Tool for the job is not the same for everyone. Unless you can state exact reasons what makes PHP bad and something else a better replacement, this is only PHP-bashing we see on HN all the time.
P.S. I wrote many ncurses clients in PHP, C and C++ and did not see much advantage in any of them. Unless there's some special requirement, I'd still pick PHP's duct-tape hashmaps/arrays over anything any other language has to offer.
Actually I see PHP's duct-tape interface as an advantage. It allows you to express the data structures and manipulate them in less verbose manner, which results in less code, which is easier to debug and maintain.
You're the only person in here who criticized my use of PHP that I actually agree with.
I never intended to release this app, and wanted to build it in PHP for fun, so I stuck with it.
But you're absolutely right on the portability problem. I do agree that, had deployment been an actual interest of mine, PHP would be the wrong language for this.
that sounds harsher than i meant it. My point was more a) use the right tool for the job and b) if you do use the right tool people will be more interested in actually using and supporting it.
I can cut down a tree with a belt-sander but trying to convince other people to do the same isn't going to go over well.
For me, my go-to tool for stuff like this is Python. It's been a while since I've done an ncurses tool with it though, I'm not sure how painful/unpainful it would be. It's easy to install on Windows, and generally just works out of the box on OSX and Linux.
