Полезные ссылки
Алгоритмы
- [Введение в А](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: выделяем глобальный репозитарий для проекта
Иногда мы копируем папку с проектом на отдельную машину, а затем пытаемся использовать его в качестве мастер-репозитария.
Но при попытке сделать пуш в этот репозитарий нас подстерегает ошибка.```
$ 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.
Управление зависимостями проекта при помощи bower+composer
Отлично. У нас есть новая интересная идея для нового проекта. Садимся мы значит за клавиатуру и… Эм. А что “и”? Наш проект зависит от кучи библиотек и фреймворков: 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"
]
}
}
Включение TRIM на SSD с LVM/LUKS
Trim - это полезная ata-команда, которая препятствует деградации производительности SSD-дисков.
Но часто случается, что дистрибутивы не включают ее на разделах.
Первым делом надо ее включить на нативных разделах просто добавив опцию discard к записи в fstab.
UUID=397b890a-c661-47f4-bd2a-2260379f8c6f /boot ext4 defaults,discard 1 2
Как поступать с разделами, которые расположены на шифрованных томах или lvm?
Для lvm надо сначала разрешить проброс команды trim к дискам (он запрещен по дефолту).
Правим /etc/lvm/lvm.conf и меняем опцию issue_discards с 0 на 1.
issue_discards = 1
Проверяем
$ sudo fstrim -v /home /home: 54,4 GiB (58440941568 bytes) trimmed
Отлично. Но что если разделы расположены на шифрованном томе, который размещен в lvm?
Важно: включение trim для зашифрованных томов может ослабить безопасность шифрования! Так как по перемещенным блокам можно сделать вывод о том, какая файловая система используется.
В /etc/crypttab нужно добавить опцию allow-discard.
luks-xxx UUID=some-uuid none allow-discards
для debian-based дистрибутивов строчка немного меняется
luks-xxx UUID=some-uuid none luks,discard
Теперь надо пересобрать initramfs.
Для rpm-based
$ sudo dracut --force
У fedora 18 есть баг из-за которого нужно указывать пусть к crypttab
$ sudo dracut --force -I /etc/crypttab
Проверим, что ctypttab был успешно добавлен в initrd.
$ sudo lsinitrd |grep crypttab
Теперь нужно заставить систему отправлять trim для томов.
# echo -e "fstrim /\nfstrim /home\nfstrim /boot" > /etc/cron.hourly/fstrim