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

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

Когда Александр Флеминг вернулся из отпуска летом 1928 года, и обнаружил в своей лондонской лаборатории стол, заражённый плесенью Penicillium notatum, он начал новую эру превосходства науки над природой. С тех пор антибиотики, как открытые им лично, так и множество других, открытых благодаря его работам, спасли миллионы жизней и избавили огромное количество людей от страданий. Но с самого начала этой эры учёным было известно, что ей придёт конец. Они просто не знали, когда именно.

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

Сап, хабр. Возможно, людям, начинающим изучать arduino, будет интересно, как легко и быстро организовать передачу информации между микроконтроллером и Java приложением. Данная связка открывает кучу интересных возможностей по сбору и обработке данных с датчиков, управлению различными свистелками-перделками, а также созданию своих первых IoT проектов.

Недавно на просторах интернета наткнулся на весьма простую библиотеку Java-Arduino Communication Library. Не найдя публикаций на эту тему здесь, решил поделиться с вами опытом использования. Для работы нам понадобятся установленные Arduino IDE, IntelliJ IDEA, Java SE Development Kit и, собственно, сам микроконтроллер (я тестировал на китайской Arduino Nano и Strela на базе Leonardo от Амперки, на обоих все все работало отлично).

В этой серии статей Альваро Виделла (соавтор книги «RabbitMQ in Action», предыдущие места работы: Apple, VMWare, EMC) поделится тем, как он попал в мир программирования. Он никогда не изучал IT в университете, но нашел способ обойти это.



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

В моем родном городе Дурасно, Уругвай, моя жена работала часами напролет за жалкие $160 (USD) в месяц. Да, это 1920 $ в год. Мы оба пожертвовали нашим временем, чтобы я смог стать учителем и нашел работу получше, потому что мы мечтали о лучшем будущем.

Разбросаны ли простые числа по числовой оси подобно рассеянным ветром семенам? Разумеется нет: простота — это не вопрос случайности, а результат элементарной арифметики. Число является простым тогда и только тогда, когда ни одно меньшее положительное целое число кроме единицы не делит его нацело.

Но на этом история не заканчивается. Распределение простых чисел выглядит случайным, с неравномерными разрывами и скоплениями, которые выглядят довольно хаотично. Если и существует какая-то схема, то она непостижима. На самом деле, простые числа выглядят достаточно случайными, чтобы можно было сыграть с ними в кости. Создайте список последовательных простых чисел (допустим, начав с 11, 13, 17, 19,... ) и разделите их по модулю 7. Другими словами, разделите каждое простое число на 7 и сохраните только остаток. Результатом будет последовательность целых чисел из множества {1, 2, 3, 4, 5, 6}, которая выглядит почти как результат нескольких бросков правильной кости.

$$

Хотите внедрить или доработать функцию поиска? Вам сюда.

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер Elasticsearch: с поиском сегодня всё просто».

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

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

Цель статьи

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

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

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

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

В гольфе выигрывает тот, у кого меньше очков.

Применим этот принцип в Android. Мы собираемся поиграть в APK-гольф и создать приложение минимально возможного размера, которое можно установить на Android 8.0 Oreo.

Базовый уровень

Начнём с дефолтного приложения, который генерирует Android Studio. Создадим хранилище ключей, подпишем приложение и измерим размер файла в байтах командой stat -f%z $filename.

Затем установим APK на смартфон Nexus 5x под Oreo, чтобы убедиться, что всё работает.



Прекрасно. Наш APK весит примерно полтора мегабайта.

Часть 1. Линейные структуры

Массив

Когда вам нужен один объект, вы создаёте один объект. Когда нужно несколько объектов, тогда есть несколько вариантов на выбор. Я видел, как многие новички в коде пишут что-то типа такого:

// Таблица рекордов
int score1 = 0;
int score2 = 0;
int score3 = 0;
int score4 = 0;
int score5 = 0;

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

// Таблица рекордов
const int NUM_HIGH_SCORES = 5;
int highScore[NUM_HIGH_SCORES] = {0};

Будет создан буфер из 5 элементов, вот такой:



Заметьте, что индекс массива начинается с нуля. Если в массиве пять элементов, то они будут иметь индексы от нуля до четырёх.

Компания EDISON Software профессионально занимается разработкой Android-приложений. Вот некоторые крупные проекты:

• Мобильные приложения виртуального сотового оператора
• Бронирование билетов на мероприятия
• Сервис доставки банковских уведомлений на смартфоны
• Приложение Vivaldi для работы с электронной библиотекой

Полезные статьи на Хабре по Android:

• Разработка быстрых мобильных приложений на Android. Часть первая
• Разработка быстрых мобильных приложений на Android. Часть вторая
• Шишки и грабли Android-разработчика за 2 года

(Пост из серии «просмотреть и добавить в избранное»)

Бытует мнение, что бесконечно можно смотреть на огонь, воду и то, как другие работают, но есть и ещё кое-что! Мы уверены, что можно бесконечно говорить с Сашей goldshtn Гольдштейном о перформансе. Мы уже брали у Саши интервью перед JPoint 2017, но тогда разговор касался конкретно BPF, которому был посвящен доклад Саши.

На этот раз мы решили копнуть глубже и узнать фундаментальные проблемы мониторинга производительности и варианты их решения.

Вначале была Java (ладно, не то чтобы в самом начале… но наша история начинается именно здесь), шло время, и спустя 20 с небольшим лет умные ребята из JetBrains спроектировали и зарелизили Kotlin, «более лучшую» Java, универсальный язык, понятный, мощный и прозрачный.

В свое время Андрей abreslav Бреслав говорил, что Kotlin разрабатывался как удобный и предсказуемый язык. Тогда же прозвучало мнение, что в этом языке вы не найдете паззлеров (коротких кусочков кода, результаты выполнения которых оказываются неожиданными, пугающими или разочаровывающими). Ну что же, Антон antonkeks Кекс поколдовал в IDEA и кое-что все-таки накопал, да еще на наглядных примерах рассказал о своих находках в паре с Филиппом Кексом. Смотрите сами:



Под катом — подборка таких паззлеров и развернутые комментарии к ним. В основе материала доклад Антона Кекса (Codeborne) и Филиппа Кекса (Creative mobile) на конференции Мобиус 2017 (Санкт-Петербург).

Каталог услуг неразрывно связан с понятием ITSM и является важнейшим компонентом сервисного подхода. Необходимость в его создании возникает на этапе внедрения ITSM.

Это становится ясно из аналогий, которые приводит Шэрон Тейлор (Sharon Taylor), главный архитектор третьей редакции ITIL. Она сравнивает каталог услуг с iTunes или App Store для предприятий, онлайн-справочником и ресурсом для разработчиков одновременно. Разберемся с этой темой с помощью небольшого чеклиста.

Введение

В моих публикациях [1,2,3] подробно описана цепочка датчик – Arduino-интерфейс Python. В реальных условиях промышленного производства датчики находиться на значительном удалении не только друг от друга но и от места где осуществляется централизованная обработка измерительной информации. Логично передавать информацию от датчиков по компьютерной локальной сети используя хорошо разработанные сетевые технологии. Данная публикация написана в стили упражнения по сборке и настройке сетевого приложения с Arduino в домашних условиях.

Постановка задачи

1. Использовать библиотеку Arduino Ethernet с расширением Arduino Ethernet Shield для создания веб-сервера.
2. Создать удаленный доступ к Arduino с использованием сети вашего домашнего компьютера.
3. Использовать стандартный пример Arduino для обеспечения значений влажности и датчика движения с помощью веб-сервера.
4. Разработать веб-приложений с использованием Python.

Этапы решения поставленной задачи

1. Проектирование и создание аппаратных средств для использования Arduino и Ethernet Shield.
2. Запуск примера по умолчанию из среды разработки Arduino как начальную точку создания сервера.
3. Изменение примера для размещения вашего оборудования и повторного развертывания кода.
4. Разработка веб-приложений с использованием Python.

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

Оптимизация производительности издавна не даёт покоя разработчикам, представляясь своеобразным «золотым ключиком» к интересным решениям и хорошему послужном списку. Большую обзорную экскурсию по ключевым вехам оптимизации больших проектов  – от общих принципов до ловушек и противоречий —  на прошедшем JPoint 2017 провёл Алексей Шипилёв, эксперт по производительности.



Под катом — расшифровка его доклада.

Ровно 20 лет назад — 23 сентября 1997 года — в интернете появился Яндекс. Аркадий Волож, Илья Сегалович, Елена Колмановская представили на выставке Softool поисковую систему Yandex.ru. Открывали её, перерезав ленточку перед компьютером — потому что не понимали, как надо открывать сайты в интернете.

Тогда он состоял из 5 тысяч сайтов, на которых было размещено около 4 гигабайт текста. Люди подходили к демонстрационному компьютеру, пробовали задавать запросы и получали ответы. На тот момент Яндекс учитывал морфологию русского языка, расстояние между словами и умел ранжировать документы.


Это одна из последних лекций, которую прочитал iseg, сооснователь и первый технический директор Яндекса Илья Сегалович. Она посвящена истории Яндекса с того момента, как Илья и Аркадий Волож сели в школе за одну парту. Качество записи лекции не настолько хорошее, насколько бы нам хотелось, но содержание — бесценно.

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

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

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

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

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

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

С того времени, как Google сделал Kotlin новой любимой женой уже прошло достаточно времени. И сразу же после этого объявления наша команда начала новый проект полностью на Котлине. Проясню: не тестовый или просто внутренний проект, а новый модуль для живого приложения с 600+ тысячами активных пользователей в месяц. Какой опыт мы из этого извлекли? Что мы выиграли и что потеряли?