Install youtube-dl
:
brew install youtube-dl
pip install youtube-dl
and run the following:
# Compiled source # | |
################### | |
*.com | |
*.class | |
*.dll | |
*.exe | |
*.o | |
*.so | |
# Packages # |
#!/usr/bin/env bash | |
# 2018-06-18 updated: mail.ru changed internals | |
# 2017-09-22 original idea: https://novall.net/itnews/bash-skript-dlya-skachivaniya-fajlov-s-mail-ru-cherez-konsol-linux.html | |
URL="$1" | |
DST_FILE="$2" | |
[ -z "$DST_FILE" ] && { | |
echo "Syntax: `basename $0` <url> <dst_file>" >&2 |
Это есть первая задача, которой я занялся, делая этот сервер.
Причина? Просто я солидарен с этим мнением:
Я твердо уверен, что внедрить логирование в уже готовую программу без изменения архитектуры приложения – невозможно . Точнее внедрить можно, но тогда лог будет настолько страшным и неудобочитаемым, что остается посочувствовать тем администраторам, которые будут с ним работать.[1]
.git | |
.gitignore | |
/doc | |
.yardoc | |
coverage | |
jsdoc | |
/tmp | |
/log | |
Dockerfile | |
Dockerfile.prod |
Английская версия: https://evilmartians.com/chronicles/bootstrap-an-intervention
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент h1.title
, на него сработают все правила для тегов h1
и все правила для класса .title
. Так как весь html состоит из тегов, то правил которые п
Vagrantfile | |
# -*- mode: ruby -*- | |
# vi: set ft=ruby : | |
Vagrant.configure('2') do |config| | |
config.vm.box = 'ubuntu/trusty64' | |
config.vm.hostname = 'rails-dev-box' | |
config.ssh.username = "vagrant" | |
config.ssh.password = "vagrant" |
"AdvancedNewFile", | |
"Alignment", | |
"All Autocomplete", | |
"BracketHighlighter", | |
"CJSX Syntax", | |
"Colorsublime", | |
"ESLint", | |
"FileDiffs", | |
"Gist", | |
"GitSavvy", |
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.