Итак. У нас море проектов, море виртуалок. И мы хотим как-то удобно с этим всем работать.

Мне по нраву выделять отдельную доменную зону для всех своих виртуалок и подключать к ней нужные адреса.

Предположим, что все проекты у нас будут собраны в доменной зоне *.dev (удобно же).

И каждый из них будет резолвиться по разным адресам.

Составим для себя список хотелок:

• машины поднимаются вагрантом или еще какой системой (это не так уж и важно)
• после появления машины в сети ее ip связывается с доменом проекта, который на ней крутится
• после завершения привязка уделяется

Начинаем хотелки реализовывать.

Ставим named

$ sudo yum install named

Заставляем его слушать только локалхост (он же девелоперский).

Для этого редактируем named.conf и добавляем в раздел options

    listen-on port 53 { 127.0.0.1; };  
    listen-on-v6 port 53 { ::1; };

Теперь нам надо подключить нашу новую зону.

Добавляем подключение описания в named.conf

zone "dev" IN {  
    type master;  
    file "named.dev";  
    allow-query {any;};  
    allow-update {  
        127.0.0.1;  
        ::1;  
    };  
};

В этом описании мы сразу же видим раздел allow-update, который позволяет удаленно изменять зону при помощи команды nsupdate. Разрешаем правку только с локалхоста.

Теперь непосредственно сам файл зоны прямого преобразования - /var/named/named.dev

$ORIGIN dev.  
$TTL 86400    ; 1 day  
@            IN SOA    dev. rname.invalid. (  
                4          ; serial  
                86400      ; refresh (1 day)  
                3600       ; retry (1 hour)  
                604800     ; expire (1 week)  
                10800      ; minimum (3 hours)  
                )  
            NS    dev.  
            A    127.0.0.1  
            AAAA    ::1  
*        IN    A    127.0.0.1

Последняя строчка нам нужна для того, чтобы все домены, для которых не прописан адрес резолвились на локалхост.

Все. Нам осталось перезапустить.

$ sudo service named restart

Проверяем

$ nslookup test.dev 127.0.0.1  
Server:        127.0.0.1  
Address:    127.0.0.1#53

Name:    test.dev  
Address: 127.0.0.1

Кдасс. А как нам связывать домен с адресом?

Для этого нам нужен скрипт.

#!/bin/bash  
TTL=86400  
RECORD=$1  
IP=$2  
(  
 echo "server dev."  
 echo "zone dev"

 echo "update delete ${RECORD} A"  
 echo "update add ${RECORD} ${TTL} A ${IP}"  
 echo "send"  
) | /usr/bin/nsupdate

Пробуем

$ ./named.sh test.dev 1.1.1.1
``````shell
$ nslookup test.dev 127.0.0.1  
Server: 127.0.0.1  
Address: 127.0.0.1#53

Name: test.dev  
Address: 1.1.1.1

Возможные проблемы:

• неправильно установлены права на папку /var/named
• неправильно указан адрес с которого можно обновлять зону
• запрет в selinux - решается выполнением shell $ sudo setsebool -P named_write_master_zones 1

Теперь можно настроить окружение так, чтобы при запуске виртуалки ее адрес обновлялся в файле зоны через скрипт в автоматическом режиме.

Алгоритмы

• [Введение в А](http://getpocket.com/redirect?url=http%3A%2F%2Fwww.redblobgames.com%2Fpathfinding%2Fa-star%2Fintroduction.html “Введение в А”)
• Введение в алгоритмы машинного обучения
• Diffbot - парсинг с элементами машинного обучения
• Машинное обучение - левелап
• Распознавание текста в FineReader

Python

• Развлекаемся с байт-кодом

PHP

• Парсинг PHP в Go - основа для построения статических анализаторов и других удобных инструментов

JavaScript

• Ядро ОС на v8
• AngularJS - стайлгайд для командной разработки
• Ribs.js - вичисляемые поля и биндинги для Backbone

Linux

• .bash_profile vs .bashrc - ключевое различие между этими двумя файлами
• Linux tricks.txt - немного любопытных советов для использования в консоли
• Что происходит когда вы подключаете USB устройство
• Код микроядра seL4

Git

• Debugging in Git with Blame and Bisect - ищем коммит с багом при помощи blame и bisect

Софт

• Плагин chrome для полнотекстового поиска по всем посещенным страницам (русский пока не умеет)
• OpenFOAM - инструментарий для вычислительной гидродинамики (небольшое вступление)

Arduino/Raspberry Pi и другое железо

• FM-трансмиттер на Raspberry Pi
• Touch-сенсор из яблок
• EMF-детектор
• Самодельный тепловизор
• Радиотелескоп своими руками

Всякое

• Как сделать так, чтобы бананы дольше оставались свежими (для велосипедистов самое то)
• 42.zip - этот архив содержит 16 зазипованых файлов, которые содержат 16 зазипованных файлов, которые содержат…
• Определение типа блокировки у провайдера

Иногда мы копируем папку с проектом на отдельную машину, а затем пытаемся использовать его в качестве мастер-репозитария.
Но при попытке сделать пуш в этот репозитарий нас подстерегает ошибка.``` $ git push origin master
Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 3.31 KiB | 0 bytes/s, done.
Total 17 (delta 4), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require ‘git reset –hard’ to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set ‘receive.denyCurrentBranch’ configuration variable to
remote: error: ‘ignore’ or ‘warn’ in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: ‘receive.denyCurrentBranch’ configuration variable to ‘refuse’.
To /project/path
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to ‘/project/path’

Вообще почему она возникает-то? Разве гит это не распределенная система контроля версий? Распределенная и даже чутка децентрализованная. Совсем-совсем распределенная. А это значит, что пушить изменения можно не только на одно хранилище, а вообще в любой репозитарий. Хоть чуваку за соседний комп. Таким образом разработчикии могут делиться своими наработками.

Но это подразумевает один нюанс: нельзя пушить в ту ветку удаленного репозитария с которой сейчас идет работа.

Суть сообщения в том, что в удаленном репозитарии ветвь, которую мы хотим запушить сейчас, активна (т.е. сделан чекаут на удаленной машине).

А значит и правки в эту ветвь якобы удаленной машиной вносятся (слава роботам!).

Способ первый. Мы заходим в репозитарий и просто чекаутим другую ветку проекта. Профит. :)

Способ второй. Мы узнаем, что существует два типа хранилищ: bare и non bare. Дефолтно при выполнении git init будет создано хранилище второго типа (и при чекауте чужого репощитария так же создается локальный non-bare репозитарий).

Bare значит, то это не рабочий репозитарий, а просто склад веток, куда каждый может пушить. И если мы попробуем поработать с ним напрямую (покоммитить), то нас ждет облом.

Гитхаб предоставляет хранилища именно такого типа.

Второй же тип - это репозитарии разработчика. Активная в данный момент ветвь блокируется на изменение от нелокальных клиентов.

А что делать?

Если реп у нас удаленный и для совместной работы - конвертируем его в bare

```shell
git config --bool core.bare true

Если нет - смотрим выше.

А еще можно сказать иниту, чтобы создавал bare сразу.

git init --bare

Unknown keycode 0x0

Вот такая веселая надпись будет нас ожидать в gnome если установлена раскладка отличная от en_*.

Это есть глобальная проблема большинства java-приложений в linux - в них не работаю горячие клавиши в раскладке отличной от латиницы (русской и любой другой).

От этого страдают все: и простые пользователи LibreOffice, и разработчики, которые вынождены пользоваться всякими разными ide, которые написаны на java.

Ага. А лечить-то как?

Для продуктов jetbrains существует два рецепта:

Добавить в idea.properties

-Dide.non.english.keyboard.layout.fix=true

Раньше работало, а теперь, увы, нет.

И второй способ, который можно использовать не только с jetbrains, но и с любым другим софтом на java.

Достаточно скачать маленький jar с гитхаба и следовать инструкции. Пока этот способ работает.

Проблема также замечена в smartsvn.

Отлично. У нас есть новая интересная идея для нового проекта. Садимся мы значит за клавиатуру и… Эм. А что “и”? Наш проект зависит от кучи библиотек и фреймворков: yii, angularjs, doctrine, twitter bootstrap и т.д.

Ок. Открываем браузер или папочку на диске (в которой все нам нужное скачано и рассортировано) и начинаем неспешно скачивать/копировать/распаковывать.

Мы моложцы, справились. Все скопировали, но только злобные разработчики пофиксили баги и выкатили новую версию своей библиотеки, фреймворка.

Пофикшенные баги - это всегда хорошо. Начинаем процесс скачивания/распаковки заново.

Страшный сон? Кошмар разработчика? Нет-нет, что вы! Стандартная процедура, через которую проходят много-много разработчиков. И даже не задумывыются, что все это можно автоматизировать, упростить и дать себе возможность наконец-то реализовать задуманный проект, а не заниматься tar -xf или zip -u, или что у них там еще.

А ответ-то простой - это bower в связке с любым другим менеджером для вашего любимого языка (composer для php, npm для nodejs и т.п.). Больше всего мне приходится иметь дело с php, поэтому опишу на примере composer.

Опять же. Почему bower и composer. Потому что первый - это менеджер для фронтенд-составляющей, а второй - для бекенда. Композером не слишком удобно пользоваться для управления зависимостями морды приложения.

Для начала нам нужно этот самый bower поставить.

$ sudo npm install -g bower

Лирическое отступление на тему “зачем нужна опция -g”.

Существует два варианта установки:

• глобальный: все модули размещаются в папке {prefix}/lib/node_modules , исполняемые файлы в {prefix}/bin : так же устанавливаются man-страницы
• локальный: все модули размещаются в папке node_modules текущей папки, а все исполняемые файлы - в node_modules/.bin : man-страницы не устанавливаются

Локальный способ стоит использовать тогда, когда вы точно знаете, что устанавливаемый модуль потребуется только вашему проекту. Чаще всего все используют глобальную установку чтобы все было доступно и другим проектам.

Теперь надо сконфигурировать его.

Конфигурация осуществляется посредством файла .bowerrc, который может опцию directory, которая показывает, куда складывать всё скачиваемое. Остальные опции можно глянуть тут.

{  
    "directory" : "web/vendor/"  
}

Теперь можно указать зависимости. Все это делается в bower.json.

{  
 "name": "Cool application",  
 "dependencies": {  
 "bootstrap": "*"  
 }  
}

Пакеты можно искать на сайте http://bower.io/search/.

Или прямо из консоли

$ bower search angular

Теперь мы готовы к тому, чтобы сделать первоначальную установку.

$ bower install

Теперь можно объединить bower и composer. При таком подходе на каждый запуск composer install или composer update будет выполняться запуск bower install, который обновит все библиотеки.

Просто добавляем в composer.json

{  
 // ...  
 "scripts": {  
 "post-install-cmd": [  
 "bower install"  
 ],  
 "post-update-cmd": [  
 "bower install"  
 ]  
 }  
}