posted on monday, july 10th, 2017
with tags
pushover and
rails
last updated on friday, july 7th, 2017
For the majority of the past five years,
Pushover
has run on one physical OpenBSD server.
It does have a hot spare hosted with another company in another part of the country,
but usually everything has been served from just one machine at a time.
Its MariaDB database is replicated in a master-master configuration over a secure
tunnel between the servers so that either node can become active at any time.
When I wanted to take the primary server down for upgrades or the server's
network provider was having routing troubles, I would update DNS for various
pushover.net entries to point at the other server's IPs where all of the
components were already running.
Within seconds, traffic would start hitting the secondary server and within a half
hour, everyone would be using it, allowing me to take the primary server offline
as long as I needed.
posted on saturday, june 24th, 2006
with tags
rails
Carl woke me up early this morning by jumping around on my chest.
I got ready and drove back down to Chicago for day two of RailsConf.
The first session of the day for me was Obie Fernandez's Thoughtworks on Rails
which was a broad overview of the rails projects that Thoughtworks has done for
its customers after introducing it into their development environment.
Nothing too technical, but useful to see the lifecycle for a rails app from the
point of meeting with the customer to creating "stories" as they put it, to
coding individual pieces, to quality assurance testing, to final deployment.
I couldn't help but think about how many people are involved in these "normal"
development processes versus things at DLS where one developer has to take a
request from another staff member and develop, code, test, and deploy an entire
app himself.
I woke up at the crack of dawn and drove to the Wyndham in Rosemont for
railsconf 2006.
I registered and got some free crap, grabbed some food and found a seat in the
ballroom.
Dave Thomas gave a keynote presentation about the big three things that he
thinks Rails needs to become better.
For my first session I opted for Introduction to Capistrano by Mike Clark,
just because the other two didn't really look very interesting.
Mike's presentation was pretty good and I picked up a few ideas for using cap
that I hadn't thought of before (namely for basic system administration tasks
not related to Rails).