$ rails g model User
belongs_to
has_one
gem 'acts_as_tree' | |
gem "friendly_id", "~> 4.0.1" |
module Concerns | |
module MessagableWithData | |
extend ActiveSupport::Concern | |
included do | |
Message.class_eval do | |
has_many :message_data, | |
class_name: MessageData, |
You can break these rules if you can talk your pair into agreeing with you.
#!/bin/sh | |
# | |
# Usage: whenever.sh [pattern] [command] | |
# | |
# Executes a command whenever files matching the pattern are closed in write | |
# mode. "{}" in the command is replaced with the matching filename (via xargs). | |
# Requires inotifywait from inotify-tools. | |
# | |
# For example, |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
#Programming Manifesto
##Books Ruby
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
echo "deb-src http://archive.raspbian.org/raspbian/ jessie main contrib non-free rpi" | sudo tee --append /etc/apt/sources.list | |
sudo apt-get update | |
sudo apt-get install libmp3lame-dev | |
apt-get source darkice | |
cd darkice-1.2/ | |
./configure --prefix=/usr --sysconfdir=/usr/share/doc/darkice/examples \ | |
--with-lame --with-lame-prefix=/usr/lib/arm-linux-gnueabihf \ | |
--with alsa --with-alsa-prefix=/usr/lib/arm-linux-gnueabihf | |
make | |
sudo make install |