^{Диск с музыкой. Работает почти как AudioCD.}

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

Спускаемся ниже по истории. Что было до этого? Факс. Он был аналогом современной электронной почты: сообщение передавалось мгновенно, вылезало из устройства и было готово к прочтению.

Идём глубже. Факса и телефона теперь тоже нет. Вы отправляете телеграмму. Как раз серьёзные телеграфные узлы были вытеснены с бэкбона телефонами. Биржи узнавали новости телеграммами. Британские журналисты из самых далёких концов света сообщали данные телетайпом. Вы могли вызвать любого человека на встречу телеграммой, которую бы отнёс специальный пацан на ваш почтовый коммутатор, а потом второй пацан – от другого локального коммутатора до адресата. Почти как сотовая сеть, только пинг больше.

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

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

Zsh — одна из лучших командных оболочек, обладающая впечатляющим набором возможностей. Однако, из‐за большого количества возможностей нет ничего удивительного в том, что некоторые из них проходят мимо внимания или возможность их применения для решения повседневных задач неочевидна. В этой статье будут рассмотрены как несколько «встроенных» возможностей zsh, так и примеры непростого кода, облегчающие жизнь.

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

Сегодня я предлагаю перейти к практике и покажу на примерах способы ручного профилирования (и даже «метод пристального взгляда». Будут так же рассмотрены инструменты для статистического профилирования.

Сегодня многие системы и языки программирования позиционируются как «мощные». Нельзя сказать, что это плохо. Почти каждый из нас считает это положительным свойством. Но в этом посте я хочу донести такую точку зрения, что во многих случаях нам нужны менее мощные языки программирования и системы. Но прежде чем продолжить, уточню: здесь будет мало оригинальных, моих собственных размышлений. Я буду излагать ход мыслей, возникший по прочтении книги Дугласа Хофштадтера «Гёдель, Эшер, Бах», которая помогла мне собрать воедино разрозненные идеи и мысли, бродившие в голове. Также большое влияние на нижеизложенный материал оказали пост Филипа Вадлера и видеозапись с конференции Scala. Ключевая мысль такова:

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

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

Наступает момент, когда системному администратору необходимо определить дату последнего входа в систему каждого из пользователей, а также подготовить список тех аккаунтов, которые этого так и не сделали. Если б Вы ранее не знали команду lastlog, то удивились бы, насколько легко и быстро она может предоставить Вам эти данные.

Написано по следам публикации Большие потоки трафика и управление прерываниями в Linux

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением Linux, а также приведены некоторые уточнения по поводу распределения прерываний.

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

В статье рассказывается о разработанной автором миниатюрной Java библиотеке, позволяющей коротко и наглядно определять конечные автоматы. Библиотека, назовем ее AkerFSM, доступна в Google Code.
В первой части статьи сформулированы предпосылки и требования к библиотеке. Во второй части приводится абстрактный пример использования библиотеки. В третьей части рассмотрены важные моменты устройства самой библиотеки. Четвертая часть посвящена рассмотрению упрощенного примера из реальной жизни, в котором с помощью конечного автомата задается поведение одного из контроллеров в GWT-приложении.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Эксплуатируются ли на работе наши самые ценные качества? Давайте взглянем на то, как наши сильные стороны оказываются впутаны в формирование плохих привычек, которые – если мы не изменим свою жизнь – вполне могут убить нас.

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

Привздохнув, произнесла:
«Как же долго я спала!»

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

Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.

Обратите внимание, в заголовке я написал «плохо документированные» а не «малоизвестные», поэтому тех кто в курсе прошу выкладывать в комментариях ссылки на членораздельную документацию, я с удовольствием добавлю в конце список.

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

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

Статья имеет довольно таки тезисный стиль. Более подробное содержание можно найти в приложенном внизу статьи видео с записью лекции по коллекциям Oracle.

Коллекции присутствую в том или ином виде в большинстве языков программирования и везде имеют схожую суть в плане использования. А именно – позволяют хранить набор объектов одного типа и проводить над всем набором какие-либо действия, либо в цикле проводить однотипные действия со всеми элементами набора.

Таким же образом коллекции используются и в Oracle.

Содержание статьи

• Общие сведения о коллекциях в pl/sql
• Типы коллекций
• Ассоциативный массив
• Varray
• Nested table
• Set operations с nested tables
• Логические операции с коллекциями
• Методы коллекций
  • Delete
  • Trim
  • Extend
  • Exists
  • First и Last
  • Count
  • Limit
  • Prior и Next
• Bulk Collect
• Цикл forall
  
  • Exceptions in forall
• Collection exceptions
• DBMS_SESSION.FREE_UNUSED_USER_MEMORY

Привет! В посте блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто просто любит читать интересные технические вещи. Рядом с каждой – пояснения, чем оно может быть нужно. Этот обзор, в отличие от других ежегодных, более технически-прикладной.

Начнём со «Справочника по инженерной психологии» Вудсона и Коновера.

«Справочник по инженерной психологии» — Вудсон, Коновер

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

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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

Декомпиляция — процесс воссоздания исходного кода декомпилятором

Недавно я задался вопросом: Какой декомпилятор лучше?
Начал мучить Google, экспериментировать. В итоге нашел отличное решение. Как декомпильнуть любую программу и получить рабочие «исходники»? Об этом в сабже.