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

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

Порнография — дело прибыльное. Туда стекают огромные деньги, которые позволяют не только снимать контент, но и адаптировать сервис к требованиям современности. Здесь мы расскажем, как это делает Pornhub.

Главные вопросы работы с базой данных связаны с особенностями устройства операционной системы, на которой работает база. Сейчас Linux — основная операционная система для баз данных. Solaris, Microsoft и даже HPUX все еще применяются в энтерпрайзе, но первое место им больше никогда не занять, даже вместе взятым. Linux уверенно завоевывает позиции, потому что open source баз данных все больше. Поэтому вопрос взаимодействия БД с ОС, очевидно, о базах данных в Linux. На это накладывается вечная проблема БД — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.


Илья Космодемьянский (hydrobiont) работает в компании Data Egret, которая занимается консалтингом и поддержкой PostgreSQL, и про взаимодействие ОС и баз данных знает многое. В докладе на HighLoad++ Илья рассказал о взаимодействии IO и БД на примере PostgreSQL, но и показал, как с IO работают другие БД. Рассмотрел стек Linux IO, что нового и хорошего в нем появилось и почему все не так, как было пару лет назад. В качестве полезной памятки — контрольный список настроек PostgreSQL и Linux для максимальной производительности подсистемы IO в новых ядрах.

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

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

Помните, на Хабре в разделе GTD была любопытная статья от BarsMonster о том, что кроме лени, прокрастинации и проблем с планированием времени может мешать эффективной работе и жизни?
Если кто пропустил эту статью — очень рекомендую!

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

В этой статье я поделюсь с вами результатами своих изысканий.
Проводил замеры в небольшой квартире, торговом зале на 100 квадратов, а также в небольшой приёмной одной компании. Кому интересно, добро пожаловать под Cut (осторожно, траффик).

В сегодняшнем выпуске нашей рубрики Алексей Катаев рассказывает о том, как он научился читать по 17 книг в месяц, не тратя на это кучу времени, и рекомендует пять полезных произведений из разряда «нетленки», показавшихся ему наиболее полезными. А в конце — традиционная, но маленькая подборка ссылок из нашего рабочего Слака.

Научитесь выявлять их. Выработайте привычки избегать их.

Цель этой статьи не загнобить новичков за типичные ошибки, а научить выявлять их и избегать. Порядок перечисления – случайный.

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

Иногда бывает трудно объяснить простыми словами казалось бы банальные вещи: зачем использовать гит, в чем фишка инкапсуляции, зачем писать тесты, как планировать свой код, рефакторить чужой и т.д. Мне показалось, что в этой статье компактно собраны важные «гуманитарные» аспекты программирования. Что-то вроде морального кодекса, ориентира и мотиватора в принятии решений, связанных с написанием кода.

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

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

Много статей и сайтов сравнивают шрифты для программирования — всё это отличные ресурсы. Так зачем я опять поднимаю эту тему? Потому что сам всегда терялся в десятках шрифтов и не мог понять, какой лучше. Так что я опробовал много шрифтов и выбрал следующие для вас. Они довольно популярны и их легко получить. И самое главное, все эти шрифты бесплатны!

Я ранжировал шрифты по следующим показателям:

• Насколько различимы схожие символы, такие как 0O, 1lI.
• Легко ли читается шрифт (ширина строк, ширина/высота символов).
• И мои личные предпочтения!

Все скриншоты сделаны в VSCode на одном фрагменте кода. Если не обозначено иное, то везде установлен размер "editor.fontSize": 14.

Недавняя статья на Slashdot о программировании игр на ассемблере для Атари (Donkey Kong и я) напомнила об ассемблерных приложениях, которые я писал по молодости, и о компьютерах, которые у нас тогда были.

Поначалу я набирался опыта на DEC PDP-8, но самый кайф начался, когда появилась CP/M. CP/M изначально была «операционной системой для бизнеса», но ещё это была система, которую можно было позволить себе иметь дома, — серьёзная вещь для молодого подающего надежды гика.

Одним из ключевых нововведений СУБД Oracle версии 12.1.0.2 стала опция In-Memory. Основная её идея заключается в том, что для выбранных таблиц вы можете легко активировать dual-format режим, который объединяет стандартный для Oracle DB построчный формат хранения данных на диске и поколоночный формат в оперативной памяти.

Соответствующее преобразование и дублирование данных в память происходит автоматически. Лично для меня это было большой новостью, так как я занимаюсь разработкой хранилищ данных (DWH) и имел опыт работы с column-oriented DBMS Sybase IQ и HP Vertica, которые созданы для хранилищ и аналитики. А Oracle предложил Column Store плюс In-Memory плюс все возможности любимой СУБД! По сути, с этим решением Oracle вышел на рынок аналитических in-memory баз данных (кто не читал, рекомендую отличную статью на Хабре со сравнением баз данных этого класса). Идея Oracle очень многообещающая, но на практике на моих тестовых примерах результаты, к большому сожалению, не впечатлили. Было это в прошлом году и я решил подождать пока технологию усовершенствуют. После выхода очередного патча с улучшениями In-Memory Option я вернулся к этому вопросу. Для статьи был выбран более объективный тест, который при желании смогут повторить читатели.

Люди: — Эй, Тойота, мы тут посчитали, у вас из-за корявой электроники и софта 89 человек погибло с 2000 по 2010.
Тойота: — Да они сами виноваты, путают педали.
Люди: — Хьюстон, у нас проблемы.
NASA: — Ща разберемся, нам надо 10 месяцев и 3 миллиона долларов.
Люди: — На.
Тойота: — 3 миллиона мало, вот вам еще сверху кэшем.
(прошло 10 месяцев)
NASA: — Эй, Тойота, мы у вас пару ошибок в коде нашли, а точнее 7134 нарушения стандартов MISRA, рекурсию, функцию на 740 строк и 9000 глобальных переменных.
Тойота: — А у нас свои стандарты. А вы ваще на Луну летали?
NASA (публично): — Тойота ни в чем не виновата.
(Акции Тойота подскочили на 4,6%)
Люди: — Ну ё-моё.
(спустя 3 года)
Два американских тестировщика (у которых дедушки погибли в Перл-Харбор): — Нет багов? А если найдем?

Мы в Атласе любим, когда все находится под контролем. Это касается и всей серверной инфраструктуры, которая, с годами, превратилась в живой организм из многочисленных виртуальных машин, сервисов и служб. Появилась потребность наблюдать за жизненно важными аспектами IT-составляющей нашей деятельности: мониторить боевой сервер, отслеживать изменения системных ресурсов на виртуалках баз данных, следить за ходом бизнес-процессов и тд. Встал вопрос — как же этого добиться и главное какими инструментами? Стали искать какие-то готовые решения. Перепробовали кучу платных/бесплатных сервисов, которые, якобы, предоставляли бы нам "самую ценную" информацию о состоянии нашей системы. Но, в конечном итоге, все сводилось к каким-то непонятных диаграммам, схемам и цифрам, которые, по сути, для нас не имели никакой ценности.

Так мы пришли к пониманию, что надо собирать что-то самостоятельно. За основу решили взять самую гибкую и продвинутую систему, которую можно настроить для мониторинга чего и как угодно — Nagios. Настроили, поставили, работает — круто! Жаль только интерфейс сего чуда застрял где-то в середине 90-х, а нам хотелось, чтобы еще и визуальная составляющая была на уровне.

Недолгий поиск показал, что лидером среди решений по созданию красивых дашбордов является Grafana. Так и решили выводить весь наш мониторинг из Nagios на мониторах в виде красивых графиков в Grafana. Вопрос остался только в том — как их подружить друг с другом?

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой:

На прошлой неделе Phys.org разразился новостью: стартап LightOn предложил альтернативу центральным процессорам (CPU) и графическим процессорам (GPU) для решения задач анализа больших данных. Авторский коллектив базируется в университете Пьера и Марии Кюри, Сорбонне и всех прочих правильных местах во Франции. Решение основано на оптической аналоговой обработке данных «со скоростью света». Звучит интересно. Поскольку в пресс-релизе не было никаких научно-технических подробностей, пришлось поискать информацию в патентных базах данных и на сайтах университетов. Результаты расследования под катом.

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

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

Во многом благодаря активности фонда ReactOS не будет большой ошибкой предположить, что любой постоянный читатель Хабра слышал о весьма амбициозном проекте «свободного Виндоуcа». Я не стал исключением, и еще в ходе работ по созданию системы сборки для СУБД ЛИНТЕР идея включить поддержку этой операционной системы меня посещала не раз. Совсем недавно ее удалось воплотить в жизнь.



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

Добрый пятничный вечер, уважаемые читатели Хабра!

Коллектив разработчиков ReactOS представляет вашему вниманию свой первый совместный пресс-релиз с компанией ЗАО НПП «РЕЛЭКС».

Специалистами ЗАО НПП «РЕЛЭКС» успешно завершены работы по тестированию СУБД ЛИНТЕР Бастион на операционной системе ReactOS.

Замеры показали, что Линтер под управлением ReactOS дает прирост производительности на 10-15% по сравнению с Windows XP на идентичной аппаратной конфигурации. В ходе работ были выявлены недостатки в ОС, которые были оперативно устранены сообществом разработчиков при непосредственном и активном участии российского фонда ReactOS.

Иногда проблема с приложением выливается в небольшой кошмар, ребус. Назовите, как хотите. Хочу поделиться об опыте использования средств мониторинга разработчиками на одном из проектов. Хабр многолик и уже существуют десятки статей о продуктах, которые облегчают понимание происходящего: cacti — habrahabr.ru/post/179391; zabbix — habrahabr.ru/post/137641; collectd — habrahabr.ru/post/93205; штатные средства JVM — habrahabr.ru/post/147008 (дополняйте).

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

Спешим поделиться нашим прогрессом в разработке, в режиме ассорти.

Поддержка дополнительных файловых систем понравится человекам

Появилась поддержка разделов жестких дисков с FS Ext2, Ext3 и Ext4.

Просмотр раздела HDD-диска с файловой системой ext3 в reactos. Спасибо Peter Hater и Thomas Faber за их работу!

Browsing an Ext3 volume in @reactos. Thanks to Peter Hater and Thomas Faber for their work on this achievement! pic.twitter.com/U66m42hXQL

— Pierre Schweitzer (@HeisSpiter) 17 октября 2015