fayak

#!/usr/bin/env bash

set -eEuo pipefail

MARKER_FILE_NAME="${DOCKER_PRUNER_MARKER:-DOCKER-PRUNER-MARKER-FILE}"
DOCKER_PATH="${DOCKER_PATH:-/var/lib/docker/overlay2}"

function _used_dirs() {
    for docker_obj in $(docker ps -aq) $(docker image ls -aq); do
        lowerdir="$(docker inspect "$docker_obj" | jq '.[].GraphDriver.Data.LowerDir' -r)"

Evshved

###Введение в веб-пространство: Что? Почему? Зачем?

• Самообразование веб-разработчика pdf Rus

###Новичкам:

• Крутой английский гайд, стилизованный под комиксы.
• Классический английский гайд от Michael Hart, существует русский вариант.
• Крутой русский гайд, знание английского не требуется, но рекомендуется.

matiaskorhonen

#!/usr/bin/env ruby

require "openssl"
require "time"

begin
  require "origami"
rescue LoadError
  abort "origami not installed: gem install origami"
end

derwiki

Adding an audit log to your Rails app

If you have any sort of administrative interface on your web site, you can easily imagine an intruder gaining access and mucking about. How do you know the extent of the damage? Adding an audit log to your app is one quick solution. An audit log should record a few things:

• controller entry points with parameter values
• permanent information about the user, like user_id
• transient information about the user, like IP and user_agent

Using the Rails framework, this is as simple as adding a before_action to your admin controllers. Here’s a basic version that I’m using in production.

mikhailov

events {
  worker_connections  1024;
}

http {
  default_type       text/html;
  access_log         /dev/stdout;
  sendfile           on;
  keepalive_timeout  65;

jdkanani

data:text/html, <style type="text/css">.e{position:absolute;top:0;right:0;bottom:0;left:0;}</style><div class="e" id="editor"></div><script src="http://d1n0x3qji82z53.cloudfront.net/src-min-noconflict/ace.js" type="text/javascript" charset="utf-8"></script><script>var e=ace.edit("editor");e.setTheme("ace/theme/monokai");e.getSession().setMode("ace/mode/ruby");</script>
<!-- 
For other language: Instead of  `ace/mode/ruby`, Use

Markdown -> `ace/mode/markdown`
Python -> `ace/mode/python`
C/C++ -> `ace/mode/c_cpp`
Javscript -> `ace/mode/javascript`
Java -> `ace/mode/java`
Scala- -> `ace/mode/scala`

mikhailov

# Nginx+Unicorn best-practices congifuration guide. Heartbleed fixed.
# We use latest stable nginx with fresh **openssl**, **zlib** and **pcre** dependencies.
# Some extra handy modules to use: --with-http_stub_status_module --with-http_gzip_static_module
#
# Deployment structure
#
# SERVER:
#  /etc/init.d/nginx                             (1. nginx)
#  /home/app/public_html/app_production/current  (Capistrano directory)
#

v1nc3ntlaw

# rbenv setup
export RBENV_ROOT=/usr/local/rbenv
export PATH="$RBENV_ROOT/bin:$PATH"
eval "$(rbenv init -)"

ordinaryzelig

I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").

Understanding MiniTest::Expectations

Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):

# minitest/spec.rb

module MiniTest::Expectations