development

Install different gems in Docker container

Snippet

I have a development environment that is used locally within docker containers, and deployed to a Heroku-like environment, which has a different setup than the local Docker setup. When running locally in Docker containers, I want to install debase and the ruby-debug-ide gems, so that I can use RubyMine locally, but these are not needed when deployed to the development instance. The deployment does not use the Docker / docker-compose files, so I'm okay with having them be local-development specific.

The trick I found was to use groups in the Gemfile.

In my Dockerfile, I'd call out the groups with the --with={groups} arguments:

RUN bundler install --with=development,docker

group :docker do
  gem 'debase'
  gem 'ruby-debug-ide'
end

Local Mail Server During Development

Snippet

Sometimes, you need to send email during software development, and you need to be able to receive the email, even if the addresses are fake (say, to @example.org) and what have you.

The node package, fake-smtp-server is a handy tool for providing a server to receive the mail, and an interface for viewing the email that was sent.

https://www.npmjs.com/package/fake-smtp-server

Install globally on a system with:

npm install -g fake-smtp-server

Start it up:

fake-smtp-server

If you want to have it on port 25 as most mail servers expect, run as root:

sudo fake-smtp-server -s 25

View the emails received (by default) at

http://localhost:1080

You can change that port, too:

sudo fake-smtp-server -h 8888

A few other configurations, and an API. Great little tool.

Usage:
  fake-smtp-server [OPTIONS] [ARGS]
 
Options:
  -s, --smtp-port [NUMBER] SMTP port to listen on (Default is 1025)
      --smtp-ip [IP]       IP Address to bind SMTP service to (Default is 0.0.0.0)
  -h, --http-port [NUMBER] HTTP port to listen on (Default is 1080)
      --http-ip [IP]       IP Address to bind HTTP service to (Default is 0.0.0.0)
  -w, --whitelist STRING   Only accept e-mails from these adresses. Accepts
                           multiple e-mails comma-separated
  -m, --max [NUMBER]       Max number of e-mails to keep (Default is 100)
  -a, --auth STRING        Enable Authentication
      --headers            Enable headers in responses
  -k, --no-color           Omit color from output
      --debug              Show debug information

Vicious cycle, this

Blog

Back when I worked at PDI, my group was in constant battle with the production engineering team. There were never more than four of us in the lighting TD group, and at least five in the PE group. It seemed we were always butting heads with half the group.

The fundamental difference between the two groups was that my group was trying to get work done, while the PE group was trying to build an infrastructure "the right way." The Right Way™ often meant "don't do anything until we build it and say it's okay to use," which inevitably took two weeks longer than my group had time. We were in production and production had schedules and we didn't have time to wait. If the tools weren't coming, we built the tools. If the problems weren't being solved, we solved them. Seems simple on paper.

Despite the near constant head-butting, I, thankfully, became good friends with Kevin Cureton who worked in that group. I miss Kevin a lot. I miss talking to him. I miss solving problems with him. I miss his stories and adventures and expertise and laughter. He has moved on from PDI to EA and I think from there, too. I don't know exactly where, as I've lost touch with him. I'm deeply saddened by this fact.

Kevin often went to bat for me when there was some conflict, and defending me when I was doing something totally bizarre but effective.

Thinking of the group, of the five people in it who I recall, I butted heads with 3 of them. One was a dick, one was an idiot and one was just clueless. Of the other two, one was Kevin, and therefore awesome, the other was Mitch Amino, who I liked very much, even though he was quiet and I think sometimes thought of me as near insane.

During one particular incident, I had wandered up to the PE group's area and told them I had implemented some feature that I no longer recall what it was. One of the PE group's people whose name I don't recall, waited until I left, then exploded about how dare I do this or that or something, that I didn't know what I was doing, what the frack did I think I would accomplish?

Kevin listened to his coworker rant. After he had calmed down, Kevin politely pointed out that I and my group keep about forty lighters from asking the five of them question after question after inane and clueless question. If the four of us weren't there, the five of them would have to provide support for the forty lighters that sat downstairs and have considerably less knowledge than I or my group did. Kevin then asked, did his coworker want to support forty lighters, because he sure as heck didn't want to.

The ranting coworker shut up.

And was pleasant to me after that.

I noticed the change and asked Kevin about it. He told me what happened, and I was grateful that I went from head-butting 60% of the group to head-butting 40% of the group. Very grateful. As grateful as Kevin's coworker was, because I was saving this guy many, many hours of work.

I think of this story as I sit on the other side. I know I should be grateful when I look at the modules being written in Drupal and see the modules that I have on my to-do list already written, just there for me to download. The modules that have been on my to-do list for over a year, sometimes more. I should be glad that someone else has put forth the effort so that I no longer have to.

And eventually I'm sure I will be happy and grateful for the modules and the completed work. But right now, I'm a little bitter that I wasn't able to actually write them. That my to-do list is a mile long and never seems to get shorter. And when I realize I finally have the time to these projects, I don't have the motivation.

Vicious cycle, this.