Совсем недавно ребята из XDA-developers заглянули под капот утекшей сборки новой, ещё не анонсированной, версии Android. Давайте посмотрим, что они там нашли.

Кто чем занимался в праздники, а мы читали прогнозы CRM-ного рынка. Начали мы патриотично и ввели в Яндексе «crm 2019 прогноз», но получили… свою же хабровскую статью от начала 2017 года на 4 месте выдачи. Первые три тоже немного не о том. Ну что же, пошли по англоязычным сайтам — там трендов оказалось пруд пруди: от отчётов аналитических агентств до Forbes. Мы прочитали всё, что было на первых двух страницах выдачи, отсеяли маркетинговую шелуху, выделили тренды и загрустили. Это другой, дивный мир, в котором рубятся по поводу, какой будет AI в CRM в 2019 году. У нас же соотечественники рубятся, в основном, о том, сколько будет стоить АИ, но другой — АИ-95. И это не хорошо и не плохо. Просто мы идём другим путём.

Давайте нальём себе чаю или кофе и почитаем, что ждёт CRM в мире в наступившем году, а заодно прикинем, что ждёт CRM в России. Местами даже захватывающе!


Fallout 4. Ну что, по кофейку?

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

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

На эту тему – нафига? – очень много сказано во всяких книжках, статьях, видео и т.д. Вас эта информация, я думаю, не вдохновляет. Лично меня эта мотивационная масса тоже не впечатляла, когда я сам, несколько лет назад, задавался тем же вопросом. Ко мне тогда не книги, а люди, вполне конкретные приходили и говорили: ты – руководитель, у тебя коллектив, ты должен использовать передовые методы, чтобы превратить коллектив в команду.

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

А я вот, за каким-то хреном, в один прекрасный момент стал использовать. Почему? И почему вы не используете?

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

22 и 23 ноября в Москве прошла очередная конференция DotNext 2018 для любителей .NET. Меня зовут Максим Смирнов, я руковожу центром компетенций .NET в Альфа-Банке и хочу представить вам текстовую версию одного из интервью, взятых в кулуарах DotNext.

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

Сколько в Альфе вообще .NET и для чего он нам нужен

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь людей. Она для тех кому интересна наука и для тех, кому интересна жизнь. А поскольку жизнь наша сложна и, по большому счёту, непредсказуема, упор в книжке делается, в основном, на теорию вероятностей и математическую статистику. Здесь не доказываются теоремы и не даются основы науки, это ни в коем случае не учебник, а то, что называется recreational science. Но именно такой почти игровой подход позволяет развить интуицию, скрасить яркими примерами лекции для студентов и, наконец, объяснить нематематикам и нашим детям, что же такого интересного мы нашли в своей сухой науке.



В этой главе мы рассмотрим закон бутерброда и организуем целое исследование с применением метода Монте-Карло, и анализа размерностей. И, наконец, развенчаем популярный миф о том, что именно масло является причиной этого закона подлости.

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

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

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

Кварцевыми часами в этот раз мы и займемся. В качестве пациента — наручные часы Луч Белорусского производства, которые мне подарили в незапамятные времена.

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

SELECT hour(datetime), somename, count(*), sum(somemetric)
from table
where datetime > :monthAgo
group by 1, 2
order by 1 desc, 2

Время от времени самые разнообразные подобные запросы начинают появляться, и если один раз стерпишь и поможешь — увы, обращения будут поступать и в будущем.

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

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

Так вот — это умеет делать расширение PipelineDB

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


— Меня зовут Антон, я работаю разработчиком интерфейсов в команде партнерских интерфейсов Яндекс.Маркета. Cегодня я хочу поговорить про типографику в вебе.

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

До были платформеры и простенькие каркасные 3D игры с мультяшной графикой. После появились все более и более реалистичные FPS.

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

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

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

До не было DOOM, а после…

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

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

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

Ну, давайте начнём с объяснения задачи!

“Хьюстон, у нас проблемы”, — устало раздалось в мозгу, пытающемся в ночи продраться сквозь Datasheet IMU MPU-9250 от InvenSense. Когда все слова в отдельности понятны, но взаимосвязь их запутана до невозможности. Началось всё с параметра LSB, про который я только смутно помнила, что в переводе это Least Significant Bit. Дальше пошли “Resolution”, “Sensitivity”, а ещё дальше я поняла, что получающийся текст уже можно озаглавить “Datasheet для чайников”.

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

Следите за обновлениями поста, анонсы событий на вторую половину месяца будут добавлены позднее.

Во вторник, 11 декабря, мы проводим очередной митап. На этот раз наша встреча будет посвящена JavaScript-разработке.

Начинаем в 19:00, территориально — Большая Полянка, 2/10, стр.1 (Corporate Innovations Hub)

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

Под катом — темы докладов от четырех наших спикеров.

Introduction

Do you remember the snake game from childhood, where a snake runs on the screen trying to eat an apple? This article describes our implementation of the game on an FPGA¹.

Figure 1. Gameplay

В Сколково отгремела двенадцатая по счету HighLoad++. Конференция собрала больше 3000 участников, профессионалов в области работы с высоконагруженными системами. Коллеги обменивались опытом построения и развития архитектуры крупных проектов, говорили о базах данных, системах хранения, системном администрировании, нагрузочном тестировании, эксплуатации крупных проектов.
Мы традиционно принимали активное участие в HighLoad++. В этом посте я хочу поделиться материалами докладчиков от Авито, впечатлениями от конференции. И рассказать, что это за странный синий бак на этом фото.

Началось все, как водится, с ошибки. Я первый раз работал с Java Native Interface и делал в C++ части обертку над функцией, создающей Java объект. Эта функция — CallVoidMethod — вариативна, т.е. помимо указателя на среду JNI, указателя на тип создаваемого объекта и идентификатора вызываемого метода (в данном случае конструктора), она принимает произвольное число других аргументов. Что логично, т.к. эти другие аргументы передаются вызываемому методу на стороне Java, а методы могут быть разные, с разным числом аргументов любых типов.

Соответственно и свою обертку я тоже сделал вариативной. Для передачи произвольного числа аргументов в CallVoidMethod использовал va_list, потому что по-другому в данном случае никак. Да, так и отправил va_list в CallVoidMethod. И уронил JVM банальным segmentation fault.

За 2 часа я успел перепробовать несколько версий JVM, от 8-ой до 11-ой, потому что: во-первых это мой первый опыт с JVM, и в этом вопросе я StackOverflow доверял больше, чем себе, а во-вторых кто-то на StackOverflow посоветовал в таком случае использовать не OpenJDK, а OracleJDK, и не 8, а 10. И лишь потом я наконец заметил, что помимо вариативной CallVoidMethod есть CallVoidMethodV, которая произвольное число аргументов принимает через va_list.

Что мне больше всего не понравилось в этой истории, так это то, что я не сразу заметил разницу между эллипсисом (многоточием) и va_list. А заметив, не смог объяснить себе, в чем принципиальное отличие. Значит, надо разобраться и с эллипсисом, и с va_list, и (поскольку речь все-таки о C++) с вариативными шаблонами.

Для записи трёхмерных поворотов программисты графики используют кватернионы. Однако в кватернионах сложно разобраться, потому что изучают их поверхностно. Мы просто принимаем на веру странные таблицы умножения и другие загадочные определения, и используем их как «чёрные ящики», поворачивающие векторы так, как нам нужно. Почему $$ и $$? Почему мы берём вектор и превращаем его в «мнимый» вектор, чтобы преобразовать его, например $$? Да кому это интересно, если всё работает, правда?

Существует способ описания поворотов под названием ротор, который относится к области и комплексных чисел (в 2D), и кватернионов (в 3D), и даже обобщается до любого количества измерений.

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

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

Было бы здорово, если бы начали вытеснять использование и изучение кватернионов, заменяя их роторами. Заменить их очень просто, а код останется почти таким же. Всё, что можно делать с кватернионами, например, интерполяцию и устранение блокировки осей (Gimbal lock), можно сделать и с роторами. Но понимать мы начинаем гораздо больше.

Адаптировано из нашей будущей книги «Рефакторинг UI»

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



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

Термин «современный C++» часто используется как синоним выражения «код, использующий новый стандарт C++». Здесь «новый» может означать что угодно от C++11 до C++17, или даже то, что уже сейчас доступно из C++20. Я думаю, что современный C++ — это нечто большее, не ограничивающееся добавлением флага -std=c++17.