start new:
tmux
start new with session name:
tmux new -s myname
#!/usr/bin/env ruby | |
#/ Usage: <progname> [options]... | |
#/ How does this script make my life easier? | |
# ** Tip: use #/ lines to define the --help usage message. | |
$stderr.sync = true | |
require 'optparse' | |
# default options | |
flag = false | |
option = "default value" |
If you're writing web applications with Ruby there comes a time when you might need something a lot simpler, or even faster, than Ruby on Rails or the Sinatra micro-framework. Enter Rack.
Rack describes itself as follows:
Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.
Before Rack came along Ruby web frameworks all implemented their own interfaces, which made it incredibly difficult to write web servers for them, or to share code between two different frameworks. Now almost all Ruby web frameworks implement Rack, including Rails and Sinatra, meaning that these applications can now behave in a similar fashion to one another.
At it's core Rack provides a great set of tools to allow you to build the most simple web application or interface you can. Rack applications can be written in a single line of code. But we're getting ahead of ourselves a bit.
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
desc 'rolls back migrations in current branch not present in other' | |
task :rollback_branch_migrations, [:other_branch] do |t, args| | |
load "#{Dir.pwd}/Rakefile" | |
branch_migrations = BranchMigrations.new(args.other_branch) | |
puts ['Rollback the following migrations', branch_migrations, 'y,n? '] | |
next if %w[no n NO N].include?(STDIN.gets.chomp) | |
Rake::Task['environment'].invoke |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');
Those suck for maintenance and they're ugly.
A quick overview of the node.js streams interface with basic examples.
This is based on @brycebaril's presentation, Node.js Streams2 Demystified
Streams are a first-class construct in Node.js for handling data.
Think of them as as lazy evaluation applied to data.
This gist aims to explain the difference between stubs and mocks and when each should be used. For an introduction to stubs and mocks, start somewhere else, like here.
Stub: used to isolate the object under test from its dependencies, preventing the test from being influenced by code outside the object. This way the test can't be made to fail or be broken by code which is not part of the specific functionality being tested. Stubs also lead to less code being run, which helps keep tests fast. A stub has no expectations. It doesn't care if it is called or how many times.
For example, you might stub out a message sent to a database connection if all you are trying to test is the type of the method's return value.
package io.scalac.conductr.example | |
import akka.actor.ActorSystem | |
import akka.http.scaladsl.Http | |
import akka.http.scaladsl.server.Directives._ | |
import akka.stream.ActorMaterializer | |
import akka.stream.scaladsl.{Sink, Source} | |
import scala.concurrent.duration._ | |
import scala.concurrent.{Await, Future} |