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


Ноам Чомски открыл, что люди обладают бессознательной способностью к языкам. За кадром осталось то, что люди именно так большинство языков и учат — бессознательно

Во сне люди, не умеющие сочинять музыку, писать стихи или прозу, могут сочинять музыку, писать песни или рассказы, которые будут казаться им гениальными произведениями ровно до того момента, пока они не проснутся — но при попытке их повторить, то есть, передать саму сочинённую музыку или сам сочинённый текст, а не впечатление от них, в точности — они начинают тут же ускользать, упорно отказываясь транслироваться в реальность. Ощущение, что они настоящие и рядом было, а мелодии или текста — не осталось. Тут уже поневоле задумаешься: а были ли они? Или спящий мозг не придумал что-то прекрасное, а сразу перешёл к симуляции ощущения, что он придумал что-то прекрасное? А наяву точно так же расползается и сам сон, изнутри него казавшийся достаточно связным. Но в сознании — чем точнее его пытаешься пересказать, тем бессвязнее он звучит. И тут уже понимаешь, что он и не был никогда связным, а только производил ощущение связности.

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

Прошло несколько месяцев с тех пор, как я здесь рассказал о своем проекте Qt-based библиотеки для сериализации данных из объектного вида в JSON/XML и обратно. Надо признать — реализация получилась, прямо скажем, спорной.

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

Я тимлид и моя задача — обеспечить продуктивную работу команды. Это непросто, поскольку готового рецепта успеха не существует. Конечно, есть признанные методологии: Agile, Lean, Value Stream Mapping. Они дают общие ориентиры и ценности, что уже неплохо, но это лишь ориентиры. А с конкретными решениями, будь добр, вертись сам. На то ты и тимлид.

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

Поиск в корпоративной информационной системе — уже от самой этой фразы вязнет во рту. Хорошо если он вообще есть, о положительном user experience можно даже не задумываться. Как перевернуть отношение пользователей, избалованных поисковыми системами, и создать быстрый, точный, понимающий с полуслова продукт? Надо взять хороший кусок Elasticsearch, горсть интеллектуальных сервисов и замешать их по этому гайду.

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

При этом сама фраза «Умный поиск» уже превратилась в баззворд и используется к месту и нет. Что же такого должна делать поисковая система, чтобы её можно было считать умной? Ультимативно это можно описать как выдачу результата, который на самом деле нужен пользователю, даже если этот результат не совсем соответствует тексту запроса. Популярные поисковые системы вроде Google и Яндекс идут дальше и не просто находят нужную информацию, а напрямую отвечают на вопросы пользователя.

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

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

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

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

Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json

О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.

На заре карьеры я работал в компании, которая выпускала систему управления контентом. Эта CMS помогала отделам маркетинга самостоятельно управлять сайтами, а не полагаться на разработчиков при каждом изменении. Система помогла клиентам сократить операционные расходы, а мне — научиться создавать веб-приложения.

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

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

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

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

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

Как считать хиты страницы google.com? А как хранить счётчик лайков очень популярных пользователей? В этой статье предлагается рассмотреть решение этих задач с помощью CRDT (Conflict-free Replicated Data Types, что по-русски переводится примерно как Бесконфликтные реплицированные типы данных), а в более общем случае — задачи синхронизации реплик в распределённой системе с несколькими ведущими узлами.

В этой публикации речь пойдет о том, как выполнить сборку C++ проекта, использующего GTest и Boost, при помощи Docker. Статья представляет собой рецепт с некоторыми поясняющими комментариями, представленное в статье решение не претендует на статус Production-ready.

Зачем и кому это может понадобиться?

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

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

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

Часть 1. Знакомство с Marching cubes

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

Вот пример из No Man’s Sky: видео.

Аналогичная техника применяется для отображения изображений с МРТ, metaball-ов и для вокселизации рельефа.

В этой части я расскажу о технике создания разрушаемого рельефа Marching Cubes, а в более общем применении — для создания плавного граничного меша твёрдого объекта. В этой статье мы начнём с рассмотрения двухмерной техники, затем трёхмерной, а в третьей части рассмотрим Dual Contouring. Dual Contouring — это более совершенная техника, создающая тот же эффект.

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

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

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

Давайте поговорим немного о каждом из этих качеств.

В наши дни, когда всякие нехорошие элементы так и норовят влезть в ваш трафик и как-то там напакостить, стало модным шифрование трафика. Начинание это благое и полезное, вот только делают его зачастую избыточно. Если шифрование трафика до доверенного сервера, типа своего VPS, — ваша единственная цель, то OpenVPN для такой цели слишком наворочен. Его долго настраивать, легко обнаружить, а главное — есть подводные камни, не зная которых можно получить такую ситуацию, что VPN стоит, а трафик идёт в обход. Всё это потому, что OpenVPN задумывался больше как средство доступа к маленькой сети через Интернет, а не для доступа ко всему Интернету.

18 мая 2018 года в Digital October состоится DevConf 2018. И мы решили пересказать некоторые интересные доклады с прошлогодней конференции. Там был доклад с несколько холиварным заголовком: "О чём молчит политрук: к дискуссии о переходе Uber с PostgreSQL на MySQL". В нем разработчик MySQL Алексей Копытов рассмотрел различия InnoDb и PostgreSQL на самом низком уровне, включая организацию данных, памяти и репликаций. Предлагаем вашему вниманию краткий пересказ доклада.

История вопроса

Uber перешел с MySQL на Postgres в 2013 году и причины, которые они перечисляют, были во-первых: PostGIS — это геоинформационное расширение для PostgreSQL и хайп. То есть, у PostgreSQL есть некий ореол серьезный, солидная СУБД, совершенный, без недостатков. По крайней мере, если сравнивать с MySQL. Они мало что знали о PostgreSQL, но повелись на весь этот хайп и перешли, а через 3 года пришлось переезжать обратно. И основные причины, если просуммировать их доклад — это плохие эксплуатационные характеристики при эксплуатации в production.

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

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.

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

(Изображение взято из статьи "12 Things to Help Large Organizations Do Angular Right" )

Данная публикация есть практическое осмысление статей "12 Things to Help Large Organizations Do Angular Right" (Victor Savkin, Co-founder of Narwhal Technologies (nrwl.io) и "Angular: Understanding Modules and Services" (Michele Stieven, Web Developer & JS enthusiast) через призму собственного опыта работы с фреймворком.

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

Если вы попали сюда по запросу типа «какого черта мой сервис воркер не работает на продакшене?», добро пожаловать под кат.

Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.

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

Привет всем! Предлагаю вашему вниманию перевод статьи Dr. Philip Hodgson (@bpusability в Twitter). Он имеет BSc, MA и PhD в экспериментальной психологии. У него за спиной более чем 20-летний опыт работы в качестве исследователя, консультанта и тренера по юзабилити, пользовательскому опыту, человеческим факторам и экспериментальной психологии. Его работа повлияла на продуктовый и системный дизайн в областях потребления, телекоммуникаций, производства, упаковки, общественной безопасности, веб- и медицинских областей для рынков Северной Америки, Европы и Азии.

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

В C# 7 наконец появилась долгожданная возможность под названием «сопоставление с образцом» (pattern matching). Если вы знакомы с функциональными языками, такими как F#, вы можете быть немного разочарованы этой возможностью в ее текущем виде, но даже сегодня она может упростить ваш код в самых разных сценариях.

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