By default, Rails applications build URLs based on the primary key -- the id column from the database. Imagine we have a Person model and associated controller. We have a person record for Bob Martin that has id number 6. The URL for his show page would be:
/people/6
But, for aesthetic or SEO purposes, we want Bob's name in the URL. The last segment, the 6 here, is called the "slug". Let's look at a few ways to implement better slugs.
| <!doctype html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1" /> | |
| <title>Enterprisify your Java Class Names! (by Hay Kranen)</title> | |
| <style> | |
| body { | |
| background: white; | |
| text-align: center; |
| # /etc/bash_completion.d/phing | |
| _phing () { | |
| local cur prev | |
| COMPREPLY=() | |
| buildfile=build.xml | |
| _get_comp_words_by_ref cur prev | |
| [ ! -f $buildfile ] && return 0 |
| class Module | |
| # We often find ourselves with a medium-sized chunk of behavior that we'd | |
| # like to extract, but only mix in to a single class. | |
| # | |
| # We typically choose to leave the implementation directly in the class, | |
| # perhaps with a comment, because the mental and visual overhead of defining | |
| # a module, making it a Concern, and including it is just too great. | |
| # | |
| # | |
| # Using comments as lightweight modularity: |
| var mongoose = require('mongoose'); | |
| var repository = function (modelName) { | |
| var self = this; | |
| self.Model = require('../models/' + modelName); | |
| self.FindById = function (id, cb) { | |
| self.FindOne({ |
Magic words:
psql -U postgresSome interesting flags (to see all, use -h or --help depending on your psql version):
-E: will describe the underlaying queries of the \ commands (cool for learning!)-l: psql will list all databases and then exit (useful if the user you connect with doesn't has a default database, like at AWS RDS)
See https://github.com/romainl/idiomatic-vimrc for an up-to-date version.
| #!/bin/bash | |
| sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport | |
| sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport |
| AllCops: | |
| RunRailsCops: true | |
| # Commonly used screens these days easily fit more than 80 characters. | |
| Metrics/LineLength: | |
| Max: 120 | |
| # Too short methods lead to extraction of single-use methods, which can make | |
| # the code easier to read (by naming things), but can also clutter the class | |
| Metrics/MethodLength: |
I fell in love with CoffeeScript a couple of years ago. Javascript has always seemed something of an interesting curiosity to me and I was happy to see the meteoric rise of Node.js, but coming from a background of Python I really preferred a cleaner syntax.
In any fast moving community it is inevitable that things will change, and so today we see a big shift toward ES6, the new version of Javascript. It incorporates a handful of the nicer features from CoffeeScript and is usable today through tools like Babel. Here are some of my thoughts and issues on moving away from CoffeeScript in favor of ES6.
While reading I suggest keeping open a tab to Babel's learning ES6 page. The examples there are great.
Holy punctuation, Batman! Say goodbye to your whitespace and hello to parenthesis, curly braces, and semicolons again. Even with the advanced ES6 syntax you'll find yourself writing a lot more punctuatio