Day 26 - Communication on Slack;

15 Mar 2017 100daysofwriting · communication · programming

Today, I wrote this

START REPOST

Other important things I learnt along the way

Listen to others, think before you start typing

Slack and IM make communication easy … and complicated. Let me explain:

1. Communication is easy if the parties communicating have a common goal, and are putting in a non-trivial amount of effort into keeping the conversation sane, unblocking themselves and getting to that common goal.
2. Communication is easy if the parties communicating have conflicting goals, but listen to the other party and are willing to change their stance if reasonable, technically sound arguments are posed.
3. Communication is easy if the parties communicating have opposite goals, are unwilling to change their stance, but would still comply with someone else’s opinion because of their inherent belief that the other person is more experienced than them.
4. Communication is complicated if one of the parties communicating is responding without reading and understanding the points being made in a discussion.
5. Communication is complicated if one of the parties doesn’t know enough to comment about something but still chooses to do so. See Dunning Kruger Effect
6. Communication is complicated if an inexperienced party pretends to know how often something might happen, despite the experienced party clearly explaining the reasons for their claim. (See Dunning Kruger Effect)
7. Communication is complicated if one of the parties is not interested in reading the points that are being made or have been made in the past by the other parties and their only interest is to propagate their own point of view, because of reasons such as: ease, naivete, lack of the required experience

If a solution approach seems complicated, Don’t shy away from it. Embrace it.

Does a proposed solution to a given problem sound very complex and extremely time-consuming? Don’t shy away from it. Try to get it done. Really try, spend your time (and money) doing it.

Most of the times, you will solve the problem. Or you will come really close to it! That’s good enough for the first time you do something complicated.

But a few of the times, things won’t work out. You ended up totally wasting your time. But is it really a waste of time?

You just discovered a very complex solution to a problem. If it is a common problem, why isn’t there an easier solution? Investigate, solve, spread the word. You just made life easier for a lot of people.

And in all the other cases, you just learned that something was very complicated. So complicated that you can probably share your experience about doing it, once you manage to crack it. That’s one hell of a story to tell everyone!

END REPOST

Okay, story time! About the second part. I can speak about it confidently because I have had it happen to me once, and I chose to embrace the approach and everything worked out fine in the beginning.

There was this one time, where I wrote a Rails application. It was called the mentorship portal. It is a portal to facilitate communication between Students and Alumni through the Student Alumni Mentorship Programme. I chose to write it in Ruby on Rails with help from Rahul Mishra. It was a pretty big Rails application and I was soon losing track of how the development was going, I learnt a lot more about Rails. But alas, deployment is where it really takes the centre stage.

The most famous method of deploying Rails on a LAMP stack seemed to be with Phusion Passenger. And thus, it began. You might want to let this song play in the background while you read the account. I have found that this song makes a lot of accounts a lot more fun to read because it is fast paced, and nostalgia wells up:

I installed Ruby and Rails on the server. Apache was already installed, I knew nothing about reverse proxying or apache configuration files till now. I knew that you had to define the root of your websites in the apache configuration files. That was the extent of my knowledge.

I was following a much older (and uglier) version of this doc on their website. The present documentation of this process seems to be really nice!

Installation went through smoothly. Though there are two challenges here that I would like to mention: The server didn’t have “full” internet, it is behind a HTTP proxy server. The server doesn’t have any mailing access, there are no other mail relays which have been configured to be used by default.

The most important step till now, is the addition of the VirtualHost tag to the appropriate configuration file. There was a bit of a struggle trying to find out exactly which one I wanted to add the code to. And I struggled a little bit more to understand what exactly would be the “replacements” that I would have to make to make the piece of code that’s there on their website to work.

The problem with replacements is that they don’t cover corner cases, like ours. We had a subdomain which had to be prefixed with www to be access from outside the institute network, and not prefixed with it to work from inside the campus. I see that the documentation still doesn’t cover the case on what to do for subdomains. I think we finally solved by adding a ServerAlias attribute inside the VirtualHost tag.

All in all, this must have taken about a week’s worth of 4 hours a day scratching my head about what to do, searching and going through a LOT of StackOverflow answers and reading the documentation again and again to try to find some hidden insight into what might be the problem: A did-you-know box that would magically tell me what I had missed.

(I realise now that I have made it sound a little bit too easy, perhaps! But considering that I am writing this 2 years after the fact, I am happy with the detail I could get.)

Oh, I forgot to mention that there was a blog post that I wrote then. Presenting Deploying on an in-house server (RANT) dated 1st May, 2015. I have really invested myself in ranting about deploying on in-house servers!

POST #26 is OVER