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

Предметно-ориентированное проектирование (Domain-Driven Design, DDD) — это процесс тесной увязки программного кода с реалиями предметной области.Благодаря ему добавление в программный продукт новых возможностей по мере его развития становится таким же простым, как и при создании программы с нуля. Эта книга в полной мере соответствует философии DDD и позволяет разработчикам перейти от философских рассуждений к решению практических задач.

Disclamer: Я никогда в своей жизни не работал с CAD/CAM приложениями раньше, и, вдруг, пришлось. Принципы работы FreeCAD меня так восхитили, что это требует срочного поста на Хабр, чтобы рассказать другим.

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

Вступление

У меня возникла простая задача — сделать 3D модель своей квартиры. Не просто "стенки в размер", а все балки, выступы и загибы. Я попробовал одну, вторую, третью программу… Я отчаялся (началось с SweetHome3D, а закончилось blender и inkscape). Они все были чертовски неудобными. Среди программ, которые я попробовал, был и FreeCAD, который я пропустил по причине "нифига не сделать" и "не работает толком". После того, как я отчаялся, я пошёл по второму кругу. На этот раз, чуть больше читая документацию… И FreeCAD не только "взлетел", но и ещё и открыл для меня восхитительный новый мир точного векторного рисования, основывающегося на Constrains.

«А оно там делает магию»
кто-то из тех, кого я удалённо консультировал по Эластику.

Я всегда говорю, что верю в три вещи: мониторинг, логи и бэкапы.

Тема про то, как мы собираем и храним логи, достаточно полно была раскрыта в предыдущих статьях, тема про бэкапы в Elasticsearch — совсем отдельная история, поэтому в этой, возможно заключительной, статье цикла я расскажу как происходит мониторинг моего любимого кластера. Это не очень сложно (и не требует использования дополнительных плагинов и сторонних сервисов) — ибо REST API, предоставляемое самим Elasticsearch простое, понятное и удобное в использовании. Всего-то надо немного углубиться в его внутреннее устройство, понять, что означают все эти метрики, пулы тредов, веса распределения шардов по нодам, настройки очередей — и не останется никаких вопросов о том, что же за «магию» эластик делает прямо сейчас.



На недавней конференции Highload++ 2017 я рассказал о том, как строил кластер своей мечты, и говорил, что недостаточно просто построить сервис. Критически важно в любой момент знать, в каком он состоянии, причём контроль обязательно должен быть многоуровневым. Разбудите меня посреди ночи (отделу мониторинга привет!) — и через две минуты я буду знать, в каком состоянии находится кластер. Причём одна минута из двух уйдёт на подключение к корпоративному VPN и логин в Zabbix.

«Подготовленный человек тоже наступает на грабли.
Но с другой стороны — там, где ручка.»

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

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

• Статья первая: принцип работы квадратурного декодера + код для ардуино.
• Статья вторая: квадратурный декодер на stm32.

Задача: есть обычный китайский бесколлекторник, нужно его подключить к контроллеру Copley Controls 503. В отличие от копеечных коптерных контроллеров, 503й хочет сигнал с датчиков холла, которых на движке нет. Давайте разбираться, для чего нужны датчики и как их ставить.

Ликбез: принцип работы бесколлекторного двигателя

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

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

Фагнер Брек считает, что такое происходит потому, что эти проекты не реализовывали принципы непрерывной интеграции. В своей заметке, перевод которой перед вами, он пишет, что в известном ему случае кое-что нужно делать по-другому с самого начала:

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

Но как это сделать? Это фундаментальный вопрос, с которым каждому приходится столкнуть в программном проекте: всё изменится.

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

Здравствуйте ещё раз! Я прочёл её и мне показалось, что её можно продолжить.


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

1. Самые полезные функции (постинг и удаление постов) доступны только из мобильного приложения Instagram, эмуляция запросов сложна, так как надо вытащить из приложения ключ, который с каждой новой версией обновляется.
2. Web-версия обрезана, но радует, что в ней есть возможность лайкать, комментировать и удалять комментарии
3. Есть API, но процедура его получения удручающе долгая и спамерам и ботам такой путь точно не светит. Плюс было много моментов, когда соглашения в API менялись, что не всегда удобно.

На удивление, в русскоязычном сегменте интернета (и на Хабре в том числе) до сих пор крайне мало информации о PubNub. Между тем, основанный в 2010-м году калифорнийский стартап успел за последние семь лет вырасти в то, что сама компания называет Global Data Stream Network (DSN), а по факту – IaaS-решение, направленное на удовлетворение нужд в области передачи сообщений в реальном времени. Наша компания – Distillery – является одним из на данный момент четырех development-партнеров PubNub, но сказано это не пустого бахвальства ради, а чтобы поделиться с сообществом вариантом использования PubNub на примере demo-проекта, который требовалось создать для получение оного статуса.

Те, кому не терпится посмотреть на код (C# + JavaScript), могут сразу пройти в репозиторий на GitHub. Тех же, кому интересно, что умеет PubNub, и как это работает, прошу под кат.

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

[Прим. пер.: оригинал статьи называется GPU Performance for Game Artists, но, как мне кажется, она будет полезной для всех, кто хочет иметь общее представление о работе видеопроцессора]

За скорость игры несут ответственность все члены команды, вне зависимости от должности. У нас, 3D-программистов, есть широкие возможности для управления производительностью видеопроцессора: мы можем оптимизировать шейдеры, жертвовать качеством картинки ради скорости, использовать более хитрые техники рендеринга… Однако есть аспект, который мы не можем полностью контролировать, и это графические ресурсы игры.

Мы надеемся, что художники создадут ресурсы, которые не только хорошо выглядят, но и будут эффективны при рендеринге. Если художники немного больше узнают о том, что происходит внутри видеопроцессора, это может оказать большое влияние на частоту кадров игры. Если вы художник и хотите понять, почему для производительности важны такие аспекты, как вызовы отрисовки (draw calls), уровни детализации (LOD) и MIP-текстуры, то прочитайте эту статью. Чтобы учитывать то влияние, которое имеют ваши графические ресурсы на производительность игры, вы должны знать, как полигональные сетки попадают из 3D-редактора на игровой экран. Это значит, что вам нужно понять работу видеопроцессора, микросхемы, управляющей графической картой и несущей ответственность за трёхмерный рендеринг в реальном времени. Вооружённые этим знанием, мы рассмотрим наиболее частые проблемы с производительностью, разберём, почему они являются проблемой, и объясним, как с ними справиться.

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

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

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

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

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

Сказать, что Томас Мальтус был непопулярен, будет слишком мягко. Его современник из XIX века, Перси Шелли, уважаемый поэт, называл его евнухом и тираном. Уильям Годвин, философ и тесть поэта, называл Мальтуса «тёмным и страшным гением, всегда готовым уничтожить все надежды человечества» [его дочь Мэри Шелли придумала Франкенштейна и его монстра – прим. перев.]. Как позже писал биограф Мальтуса, он был самым ругаемым человеком своего века. Учитывая, что это был век Наполеона Бонапарта.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

Кому-то может показаться, что это начало какой-то детской загадки, но на самом деле это реальность. Ответ на нее Департамент Информационных Технологий.

Заранее говорю, что статья является лишь сводом информации. Каждый из вас может сделать собственные выводы.

[UPD]: ДИТ ответил в комментариях
[UPD]: ДИТ прислал официальный ответ
[UPD]: Сайты, которые указывают на связь компании Альтрикс и компании Тактик Лабс почистили, но интернет помнит все
Часть 2. Сначала они воруют, а когда ты побеждаешь, то тебя убивают

Взаимодействие человека с компьютером во многом опирается на графические элементы интерфейса, и цвет играет в этом процессе не последнюю роль. Как однажды сказал Pierre Bonnard: «Цвет не просто делает дизайн приятным для глаз, но и подкрепляет его».

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

Нам приходится работать очень напряженно: вредные начальники (не все), жесткие сроки, мозговые штурмы, решение самых разных проблем и, прежде всего, работа допоздна не лучшим образом отражаются на здоровье. Все вышеперечисленные обстоятельства приводят к депрессии, курению, «заеданию» стресса — словом, портят здоровье.

А от здоровья в конечном итоге зависит наша жизнь — и это главная причина что-то с этим делать. Вторая по важности причина — от этого зависит карьера. Часто разработчики жалуются, что у них болит спина — иногда настолько сильно, что они не могут сидеть за столом. У многих из-за постоянного использования клавиатуры и мыши проблемы с запястьями. Все это может сделать работу неприятной, а в худшем случае и невозможной. И дело не только в мелких недугах: такая работа без заботы о собственном здоровье может укоротить жизнь. Возможно, это звучит слишком громко, но давайте вспомним, что главная причина смертности в мире — сердечно-сосудистые заболевания. Кроме того, все больше распространяются такие заболевания, как диабет 2-го типа и ожирение. Образ жизни программиста способствует появлению этих проблем, однако в большинстве случаев их можно предотвратить с помощью физических упражнений и правильного питания. Мы рассмотрим причины этих и других проблем со здоровьем, а затем поговорим о том, как эти причины устранить.

Переведено в Alconost

Счастье разработчиков (сбалансированный индекс по шкале положительного и отрицательного опыта)

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

В соответствии с результатами опроса, опубликованными в марте 2017 года, разработчики программного обеспечения, в среднем, «слегка счастливы». Положительный индекс — хорошая новость для работодателей. Значит, усилия компаний не пропали зря. Но им ещё есть куда стремиться. Исследователи составили список основных причин недовольства программистов — эти факторы желательно свести к минимуму.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

У нас используется система управления проектами и задачами Redmine. Мы продолжаем допиливать ее под свои нужды, чтобы повысить удобство работы и расширить функционал. Очередной задачей стало ускорение поиска.

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