О книге «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса знают, наверное, все, кто занимается программированием, причем многие — в основном из упоминаний в подборках и цитат в более современных статьях. Учитывая, что этот сборник практических советов для разработчиков скоро отметит двадцатилетний юбилей, тот факт, что его до сих пор приводят как источник ценной информации, вызывает уважение. Секрет прост: авторы, хоть и делали акцент на практической применимости своих подсказок, говорили по большей части о фундаментальных принципах построения рабочего процесса. Многие технические моменты, которые упоминаются в тексте, действительно давно устарели, но базовые подходы к разработке, тестированию, взаимодействию внутри команды и с аудиторией остаются актуальными.


Ниже вы найдете конспект первых четырех глав; речь в них идет об авторской концепции самообразования, основах прагматического подхода в программировании и правилах подбора инструментов. Книга очень удобна для «точечного» чтения: материал представляется в виде отдельных параграфов-подсказок, снабженных перекрестными ссылками. За рамками этого конспекта остались примеры из конкретных языков, разбор кейсов из авторской практики, те самые ссылки, упражнения на закрепление и некоторые забавные аналогии, оживляющие текст — так что рекомендую ознакомиться с оригиналом, если какие-то из тезисов вас заинтересуют. Приятного чтения!

Аве Кодер!

Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?

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

Мы уже рассмотрели механизм индексирования PostgreSQL и интерфейс методов доступа, а также один из методов доступа — хеш-индекс. Сейчас поговорим о самом традиционном и используемом индексе — B-дереве. Глава получилась большой, запасайтесь терпением.

Btree

Устройство

Индекс btree, он же B-дерево, пригоден для данных, которые можно отсортировать. Иными словами, для типа данных должны быть определены операторы «больше», «больше или равно», «меньше», «меньше или равно» и «равно». Заметьте, что одни и те же данные иногда можно сортировать разными способами, что возвращает нас к концепции семейства операторов.

Предисловие

В этой серии статей речь пойдет об индексах в PostgreSQL.

Любой вопрос можно рассматривать с разных точек зрения. Мы будем говорить о том, что должно интересовать прикладного разработчика, использующего СУБД: какие индексы существуют, почему в PostgreSQL их так много разных, и как их использовать для ускорения запросов. Пожалуй, тему можно было бы раскрыть и меньшим числом слов, но мы втайне надеемся на любознательного разработчика, которому также интересны и подробности внутреннего устройства, тем более, что понимание таких подробностей позволяет не только прислушиваться к чужому мнению, но и делать собственные выводы.

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

В этой части мы поговорим про разделение сфер ответственности между общим механизмом индексирования, относящимся к ядру СУБД, и отдельными методами индексного доступа, которые в PostgreSQL можно добавлять как расширения. В следующей части мы рассмотрим интерфейс метода доступа и такие важные понятия, как классы и семейства операторов. После такого длинного, но необходимого введения мы подробно рассмотрим устройство и применение различных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.

Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



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

Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.

Основная наша задача в проектировании, как это понятно из названия статьи, добиться разделения интерфейсов на Query и Command, чтобы впоследствии разделить бизнес сценарии на те, которые будут читать данные (Query интерфейсы) и на те, которые будут изменять данные (Command интерфейсы). А также обеспечить минимальное время ожидание (latency) на обновление данных, доступных через Query, после того как мы изменили данные через Command.

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

Мы продолжаем публиковать лекции курса «Проектирование высоконагруженных систем», который читается студентам Санкт-Петербургского Политехнического университета командой инженеров из Одноклассников в рамках двухлетней программы «Java-разработчик высоконагруженных приложений» проекта Технополис (совместный проект Mail.Ru Group и СПбПУ). В 2017 году были прочитаны и выложены 10 лекций (30 часов видео), но тема Highload настолько обширна, что за один семестр невозможно охватить всё. Мы лишь ненадолго погрузились в основные аспекты Highload-разработки, каждый из которых достоин отдельного курса. В этом году мы продолжаем закрывать белые пятна и представляем вашему вниманию набор из шести лекций на новые темы: начинаем с параллельных вычислений и livecoding первого этапа студенческого курсового проекта, после чего погружаемся в средства мониторинга и диагностики JVM, а потом переходим к проблемам отказоустойчивости. А после лекции о продвинутых алгоритмах, актуальных в высоконагруженных проектах, завершаем цикл лекцией о существующих подходах к репликации и об их применимости к разным задачам.

Первые десять лекций.

Список новых лекций:

1. Actor Model. Future. Reactive Streams (Вадим Цесько incubos)
2. Livecoding второго этапа проекта (Вадим Цесько incubos)
3. Мониторинг и диагностика JVM (Андрей Паньгин apangin)
4. Site Reliability Engineering (Антон Иванов keyplayer)
5. «Современные» структуры данных (Дмитрий Щитинин dormidoncheg)
6. Репликация (Дмитрий Щитинин dormidoncheg)

Мы начинаем публиковать курсы лекций Технополиса — образовательного проекта команды Одноклассников в Санкт-Петербургском Политехническом университете Петра Великого. Создание высоконагруженных приложений — это не только проектирование и написание кода, но и огромное количество других аспектов на всём протяжении жизненного цикла продукта. Мы пройдём по всему процессу создания и использования высоконагруженной системы. Особое внимание будет уделено особенностям эксплуатации, сетям, балансировке нагрузки, иерархии памяти, повседневным инструментам. Также поговорим о мониторинге, аудите и многом другом. Лекции курса читает команда экспертов под руководством ведущего разработчика в Одноклассниках Вадима Цесько.

Список лекций:

1. Введение (Вадим Цесько incubos)
2. Типовые архитектуры (Александр Христофоров)
3. Эксплуатация (Илья Щаников)
4. Сетевой стек (Дмитрий Самсонов dmitrysamsonov)
5. Балансировка (Андрей Домась)
6. Процессоры и память (Алексей Горбов)
7. Хранилища данных (Сергей Егоричев)
8. JVM (Андрей Паньгин apangin)
9. Мониторинг (Сергей Шарапов Sharapoff)
10. Облака (Леонид Талалаев)

Хочу поделиться полезными приемами работы с PostgreSQL (другие СУБД имеют схожий функционал, но могут иметь иной синтаксис).

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

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin'e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

Поехали!

Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

Вашему вниманию предлагаю перевод статьи Sacha Greif "Что же такое этот GraphQL?"

Если вы такой же, как и я, вы обычно проходите через три этапа, когда узнаёте о новой технологии:

• Отрицание: Ещё одна JavaScript библиотека?! Зачем? У меня уже есть jQuery!
• Интерес: Хм, наверное мне следует взглянуть на эту библиотеку...
• Паника: Помогите! Мне нужно изучить эту библиотеку прямо сейчас, иначе мои знания устареют!

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

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

---

Перевод. Автор оригинала Samer Buna. Оригинал статьи.

---

Когда я впервые узнал о GraphQL после долгого использования различных REST API, то не мог удержаться от твитов такого содержания:

Rest API превратился в REST-in-Peace API. Долгих лет жизни GraphQL

Примечание переводчика – Rest In Peace, RIP – распространенная эпитафия "Покойся с миром". Первое слово в ней пишется так же, как акроним REST.

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

Поймите правильно. Я не собираюсь обвинять GraphQL в убийстве REST или чём-то таком. REST не умрет никогда, также как XML будет жить вечно. Но кто в здравом уме станет использовать XML вместо JSON? На мой взгляд, GraphQL сделает для REST то же самое, что JSON сделал для XML.

Как развивается криминалистика, изучающая капли крови [чтение не для слабонервных]

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

Джонсон, работавший тогда главным криминалистом Лос-Анджелесского департамента окружного шерифа, изучил квартиру. На полу кухни лежали осколки керамики – остатки банки, в которой хранилась мука. Джонсон обратил внимание на два набора следов в муке, что говорило о том, что нападавших было двое. Одежда, которую достали из сундука, была разбросана у стены напротив кровати. Судя по взломанному замку, Джонсон смог понять, что замок открывали силой, возможно монтировкой. На замке тоже была кровь, и след из капель вёл к раковине, где нападавший вымыл руки.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

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

Это мой конспект, в котором коротко и по сути затрону такие понятия Kafka как:

— Тема (Topic)
— Подписчики (consumer)
— Издатель (producer)
— Группа (group), раздел (partition)
— Потоки (streams)

Kafka — основное

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

Apache Kafka – диспетчер сообщений на Java платформе. В Kafka есть тема сообщения в которую издатели пишут сообщения и есть подписчики в темах, которые читают эти сообщения, все сообщения в процессе диспетчеризации пишутся на диск и не зависит от потребителей.

На Хабре, по меркам старожилов, я совсем недавно, всего два года, но пишу активно, по возможности каждый день. Так вот, читая статьи, да и просто прокручивая ленту свежих публикаций как на Хабре, так и на GT, я понял, что многие просто не могут совладать с версткой текста и, как следствие, достаточно часто годные публикации хоронятся их же авторами из-за нечитабельности текста. Или отпугивает кривая КДПВ, или еще что произойдет.

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

Картинка Для Привлечения Внимания и выравнивание по левому краю

Так уж сложилось, что вся лента Хабрахабра выровнена по левому краю. По этой причине опытные авторы небольшие изображения оставляют слева или используют картинки шириной в 800-1000 px. Отдельно хочется заметить, что чуть ли не лучшим является соотношение КДПВ 2 к 1, т.е. изображения 800х400 px. Подобная пропорция позволяет SMM-щику соц. сетей не изгаляться с вашей картинкой (а то и вовсе искать что-то другое, более подходящее по размерам), а использовать оригинал, не нарушая задумки автора.

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

Квадрат

#square {
	width: 100px;
	height: 100px;
	background: red;
}

Многие начинающие художники горят желанием рисовать персонажей для игр. Но зачастую энтузиазм быстро гаснет, потому что создание персонажа — это ответственное дело, которым нельзя заниматься в отрыве от работы всей команды. Поэтому мы написали для вас руководство, как создавать игровых персонажей, на примере «Аллодов Онлайн».

Всё, что говорится в правилах, основано на огромном опыте разработки. Тут каждая буква имеет значение, и если вам показалось, что где-то есть ошибка или недосказанность, то лучше семь раз переспросить, чем сделать абы как. Ниже расписаны правила успешной работы в игровой индустрии. Если их не соблюдать, то ваша работа будет или недолгая, или неуспешная, или мучительная и для вас, и для заказчика. А если станете создавать персонажей в полном соответствии с этим руководством, то вас ждёт успех!