В продолжение рубрики "конспект админа" хотелось бы разобраться в нюансах технологий ОЗУ современного железа: в регистровой памяти, рангах, банках памяти и прочем. Подробнее коснемся надежности хранения данных в памяти и тех технологий, которые несчетное число раз на дню избавляют администраторов от печалей BSOD.

В декабре прошлого года в переписке американских коллег по data science прокатилась волна обсуждения долгожданного черновика новой книги гуру машинного обучения Эндрю Ына (Andrew Ng) «Жажда машинного обучения: стратегии для инженеров в эпоху глубинного обучения». Долгожданного, потому что книга была анонсирована ещё летом 2016 года, и вот, наконец, появилось несколько глав.


Представляю вниманию Хабра-сообщества перевод первых семи глав из доступных в настоящий момент четырнадцати. Замечу, что это не финальный вариант книги, а черновик. В нем есть ряд неточностей. Эндрю Ын предлагает писать свои комментарии и замечания сюда. Начинает автор с вещей, которые кажутся очевидными. Дальше ожидаются более сложные концепции.

Проблема

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

В этом посте я бы хотел рассказать о своём опыте создания резюме: о предполагаемой целевой аудитории и деталях оформления. Оговорюсь, что я программист, в отделе кадров никогда не работал, так что к соображениям следует относиться со скептицизмом.

Я программист. По крайней мере так написано в трудовой книжке. Почти всё своё рабочее время я провожу в консоли и текстовом редакторе. Мне очень нравится bash. Почти год я жил в zsh, прислушавшись к советам своих многочисленных коллег и знакомых, но в итоге я вернулся в bash и ни капельки об этом не жалею.



Zsh красив, приятен, чертовски функционален, но, признаюсь честно, я не смог совладать со всеми его многочисленными настройками. Я хочу работать, а не бороться со своим рабочим окружением. Простой пример: пару раз из-за автодополнения zsh я удалял все директории и файлы в текущей директории — zsh просто ставил пробел между автодополненной директорией и введённой мною звёзочкой (я хотел удалить всё в выбранной папке). Помните тот эпичный баг с пробелом и удалении директории /usr? У меня было то же самое. Спасибо гиту, выручил в который раз.

Впрочем, дело не в zsh — будь я чуточку умнее, я бы с ним обязательно справился бы, и всё было бы хорошо, но мы, суровые программисты, будем использовать bash и vim, а гламурные zsh и textmate оставим хипстерам и прочим модникам ;)

Я не напишу ничего оригинального и универсального решения я не приведу, но мне всегда нравилось читать конфиги и описания других людей, а если к ним были приложены интересные картинки, так я вообще перечитывал эти статьи несколько раз. Надеюсь, вам тоже будет интересно.

Здравствуй, Хабр.
Большинство из нас так или иначе работает со строками. Этого не избежать — если ты пишешь код, ты обречен каждый день складывать строки, разбивать их на составные части и обращаться к отдельным символам по индексу. Мы давно привыкли что строки — это массивы символов фиксированной длины, а это влечет за собой соответствующие ограничения в работе с ними.
Так, мы не можем быстро объединить две строки — для этого нам потребуется сначала выделить необходимое количество памяти, а потом скопировать туда данные из конкатенируемых строк. Очевидно, что такая операция имеет сложность порядка О(n), где n — суммарная длина строк.
Именно поэтому код

string s = "";
for (int i = 0; i < 100000; i++) s += "a";

работает так медленно.

Хочешь выполнять конкатенацию гигантских строк быстро? Не нравится, что строка требует для хранения непрерывную область памяти? Надоело использовать буферы для построения строк?

От переводчика

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.

Сегодня существуют разные мнения по поводу успешности объектной технологии. С одной стороны, большинство современных mainstream языков программирования являются объектно-ориентированными, с другой стороны, нередко можно услышать критику ООП, дескать, объектно-ориентированное программирование «провалилось» и не оправдало тех надежд, которые были возложены на нее индустрией разработки ПО. Все, мол, ожидали наступления вселенского счастья в виде увеличения повторного использования, упрощения сопровождения, да и вообще, обещали, что думать придется кому-то другому, а я за это буду деньги получать.

Практически все, кому приходилось работать с backbone, представляют себе, что это за штука такая — Router. Конечно, в приложении можно обойтись и без него, но удобство работы с приложением сильно проиграет.

Итак, роутер определяет, какую функцию (контроллер) следует использовать, опираясь на URL в строке браузера. Или, если быть точным, на хэш. Т.е. вы могли понаставить в интерфейсе своего приложения ссылок вида:

<a href="http://myapp.com/catalog/#action1">Сделать что-то полезное</a>

или даже

<a href="http://myapp.com/catalog/#action1/42">Сделать что-то полезное с параметром</a>

и всё прекрасно работало. Пользователь, в свою очередь, мог сохранить каждую из этих ссылок, и, в последствии, перейти по ним, сразу же активировав нужную функциональность. Единственный негативный момент во всём этом великолепии — наличие символа "#" (решетка). Не то, чтобы она была плоха сама по себе, но читабельность и «красивость» (с задних рядов мне ещё кто-то про RESTful что-то подсказывает) URL она портила.

Чем дальше в лес, тем толще партизаны. Нет, не так. Чем старше веб, тем больше джаваскрипта

Клиентского кода в веб-приложениях с каждым годом действительно становится все больше. Подчас это десятки файлов с сотнями функций. И что делать, когда нам нужно поменять код, выполняемый по событию (например, клик по ссылке). Как его найти? Задавшись решением этой задачи, я придумал несколько разных вариантов. Каждый из них имеет свои плюсы и минусы. И в конце статьи я предлагаю метод, который мне кажется оптимальным.

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

Итак, предположим, что вы уже определились, что вам нужен именно демон. Что он должен уметь?

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

Отвязываемся от консоли

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

// Дальнейший код выполнится только дочерним процессом, который уже отвязан от консоли

Не могу не поделиться с общественностью прекрасным переводом статьи The Limoncelli Test: 32 Questions for Your Sysadmin Team

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

Задача — на минимальных ресурсах VPS развернуть хостинг нескольких не нагруженных сайтов. Сделать это быстро и удобно с минимальными проблемами в будущем и не падать на пиковых нагрузках.

Основные принципы:

1. ОС — Centos-6 86_x64 потому что стабильно, удобно и легко обновляемо.
2. Никакого самосборного софта. А то как говорится «командой make && make install любой дистрибутив превращается в Slackware.»

Существует большая разница между задачами непростыми и задачами сложными. Задача может не иметь эффективных решений в самых худших случаях, но может оставаться легко решаемой для большинства случаев, или для случаев, возникающих на практике. Поэтому общепринятые определения сложности задач могут оказаться относительно бессмысленными в терминах реальной сложности, так как две задачи могут быть NP-полными, но одна при этом в большинстве случаев может решаться быстро, а другая нет. Как следствие, важную роль в теории сложности играет понятие «сложности в среднем» (здесь под «средним» понимается математическое ожидание времени решения).

Чтобы проиллюстрировать центральную роль этого понятия, можно вообразить пять различных возможных миров (возможных — потому что еще не доказано, что они нереальны, и наш может оказаться любым из них) и посмотреть как условия в них будут влиять на информатику и жизнь вообще.

Многие слышали и пользовались замечательной утилитой nmap. Ее любят и системные администраторы, и взломщики. Даже Голливуд знает про нее — в фильме «Матрица» при взломе используется nmap.

Мы снова приветствуем вас на волнах Changelog FM, и сегодня у нас в студии — Ajenti 0.6.0.

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Доброго времени суток, Хабр!

Хотел бы рассказать Вам, каким образом я добился плавной смены цветов иконок при наведении на них курсора. Подобная проблема часто встречается на Facebook. Если иконка представляет собой синий силуэт на белом фоне, то при наведении курсора оба цвета меняются местами, причём происходит это мгновенно и выглядит немного резко. Мои эстетические чувства были задеты, и я разработал своё решение.

Не встретив на просторах Интернета чего-либо подобного, я взял на себя ответственность назвать этот метод SITH (Soft Image Transition on :Hover) — плавный переход изображения при наведении.



Под хабракатом Вы найдёте полное описание техники, весь код, несколько скриншотов и ссылку на демонстрационную версию.

Появлению этой методики способствовала воистину монстрообразная вёрстка элементов страницы на нашем проекте. Подумать только, для отображения одной кнопки требовалось до семи тегов на один элемент.

Выглядело это примерно так:



html

<div class="large_button"><br>  <span class="buttons submit_v2-button clickable"><br>    <i class="left left2"></i><br>    <i class="body"><br>      <b>В архив</b><br>      <i class="end"><br>        <i></i><br>      </i><br>    </i><br>  </span><br></div>

Видно, что запутаться в таком коде проще простого, тем паче, что вариантов кнопок на проекте накопилось не менее 30. Попытка создать такую кнопку на серверной стороне вызывала негодование у коллег «пехапистов».

Поэтому моей негласной задачей стало максимальное упрощение кода.