среда, 4 июля 2018 г.

Сдвиг массива влево на N элементов

Есть ряд способов сдвинуть массив влево на N элементов. Можно взять и сделать N сдвигов по одному элементу, получив квадратичную сложность. Можно создать целевой массив по размеру исходного и вычислить положение каждого элемента после сдвига. Хорошо, но скорость линейна, затраты по памяти - тоже.
Если чутка подумать, то можно придумать реализацию, которая мутирует массив и дает линейную скорость и константные затраты по памяти. Но есть один очень элегантный способ – из 3-х строк на основе чудо Span of T из System.Memory:
public static void RotateLeft(int[] input, int direction)
{
    input.AsSpan(0, direction).Reverse();
    input.AsSpan(direction).Reverse();
    input.AsSpan().Reverse();
}
Идея такая: чтобы сдвинуть массив из K элементов на N элементов влево, нужно перевернуть первые N элементов в массиве, затем последние K - N -1 элементов, а затем перевернуть весь массив:
// direction == 2, input.Length == 7
input.AsSpan(0, direction).Reverse();
// [2][1][3][4][5][6][7]
input.AsSpan(direction).Reverse();
// [2][1][7][6][5][4][3]
input.AsSpan().Reverse();// [3][4][5][6][7][1][2]

Получается два прохода по массиву, но зато с читабельностью решения все очень ОК.

вторник, 3 июля 2018 г.

Welcome, так сказать, back:)

Мне вот тут подумалось, что блоггинга мне не хватает. Причем не очень хочется писать чего-то длинное и сильно умное. Для этого, у меня теперь на английском блог есть. Хочется чего-то простого и легковесного, типа журнала живого. Вроде бы есть всякие Г+ и фейсбуки, но их формат мне все равно не нравится. Если захочешь чего-нить своего потом найти там, заморишься.

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

Вот и сейчас просто хочется поделиться загадкой, которую вчера решал:

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

пятница, 20 октября 2017 г.

Анонс конференции DotNext 2017 Moscow

Пришло время очередной конференции DotNext Moscow и организаторы предложили их поддержать, на что я с радостью согласился. Итак, промокод TeplyakovPromo дает скидку в 10%.

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

День 1

1. Андрей Акиньшин – Поговорим про performance-тестирование

Андрей – один из авторов популярной микро-бенчмарк фреймворка BenchmarkDotNet, который в этом году (если не ошибаюсь) присоединился к .NET Foundation и является маст-хев тулом для всех любителей пооптимизячить.

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

· Бенчмаркинг

· Автоматизированное тестирование потребления памяти определенным куском кода

· Автоматизированная валидация производительности путем запуска интеграционных тестов и сбора телеметрии

В моем текущем проекте, например, весьма серьезное внимание уделено последнему пункту, когда система прогоняется на тестовом сервере с разными сценариями, а анализ ведется путем анализа телеметрии.

2. Сергей Быков – Назад в будущее: построение эффективных облачных сервисов с помощью Orleans

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

3. Дино Эспозито – I have a microservices architecture and I didn’t know

Опять-таки, тема не моя, но Дино – это очень именитый спикер, и тема весьма наболевшая.

4. Марк «Я могу и ФП, и ООП» Сииман – From dependency injection to dependency rejection

Этот доклад я бы ни за что не пропустил. Макр – известный спикер, автор книги “Dependency Injection in .NET”, а ныне активный участник F# Community. Это значит, что Марк понимает, как ОО, так и ФП миры, что позволяет ему выбирать лучшее из двух и вдумчиво объединять эти парадигмы (ИМХО, лучший подход из всех возможных – ОО-компонентизация и «слоеность» + ФП реализация компонентов).

5. Raffaele Rialdi - Runtime code generation techniques in real life scenarios

Тема генерации кода во время исполнении мне близка и я ею достаточно часто пользуюсь в работе. Одним из таких примеров является оптимизация фабричного метода по созданию объектов, описанная в посте Dissecting the new() constraint in C#: a perfect example of a leaky abstraction. Даже в моей практике набралось с десяток примеров, и я бы с радостью послушал об опыте других.

6. Karel Zikmund – High Performance Networking in .NET Core

Однозначный маст-визит для всех, кто интересуется разработкой высокопроизводительных приложений в .NET. Karel работает в команде .NET Core и хорошо знает, о чем будет говорить. Сейчас идет серьезный пуш в сторону low-allocations и в целом high-performance для всего сетевого стека и других ключевых компонент.NET.

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

День 2

1. Егор Бугаенко – TDD вверх ногами

Как вы, наверное, знаете, у меня весьма однозначное отношение к тестированию и весьма неоднозначное отношение к TDD. А тут такой повод! Егор – весьма интересный спикер, который отличается несколько необычными взглядами на общепринятые вещи. Я не знаю (вру, знаю), что будет на выступлении, но интересная точка зрения автора и интересный доклад гарантирован.

2. Вагиф Абилов – Akka Streams для простых смертных

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

3. Валерий Петров – Модель памяти в .NET

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

Ну а если эта тема не интересна, то есть смысл обратить внимание на доклад Володи Кочеткова Побеждая инъекции.

4. Денис Иванов - Apache Kafka и рективные микросервисы на .NET Core

Денис смог собрать кучку buzzword-ов в теме доклада, но я бы пошел на него ради того, чтобы послушать о реальном использовании .NET Core в продакшне.

5. Виталий Езепчук – Поединок: .NET Core против Java

Идея доклада – огонь: сравнить два популярных ран-тайма. Я понятия не имею, как можно провести честное сравнение, когда у этих двух сред столь разная история, и столь разный набор плюсов и минусов. Java славится значительно бОльшим числом различных оптимизаций в ран-тайме, в то время, как в CLR есть поддержка обобщений и значимые типы. К сожалению, я могу предположить результат сравнения, но последить за таким поединком не отказался бы.

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

Организаторам – респект, а вам – отличной конференции!

среда, 6 сентября 2017 г.

Структура управляемого объекта. Части 1 и 2

Что-то я забросил публикацию аннонсов своего англоязычного блога, что не хорошо. Исправляюсь.

Так вот, меня всегда интересовали несколько моментов с точки зрения структуры (layout) объекта: почему управляемый указатель указывает в середину объекта? Почему object header хранится по негативному индексу и что же именно может храниться в заголовке объекта?

На первый вопрос ответ дается в первом посте: Managed Object Internals, Part 1. Спойлеры: причина историческая, хотя есть и определенные сведения о том, что причины были связаны с эффективностью.

Во втором посте – Managed Object Internals, Part 2. Object header layout and the cost of locking в деталях рассматривается структура object header-а, а также концепция thin lock-ов. Интересно, что thin lock-и мало где описаны и о них мало кто знает. Thin lock – это более оптимальная реализация блокировок, добавленная в CLR 2.0, которая позволяет синхронизироваться на объекте с нулевыми (практически) накладными расходами за счет сохранения информации о блокировки внутри object header-а.

четверг, 24 августа 2017 г.

О книге Ф. Друкера «Эффективный руководитель»

Неспособность сконцентрироваться на чем-то более вменяемом, привели меня к чтения очередной около менеджерской книги. На этот раз, книги «Эффективный руководитель» Друкера.

Друкер

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

Но, как это часто бывает, что-то пошло не так.

Ну, для начала, первое издание книги написано 50 лет назад. Что само по себе ничего не значит. Дядюшка Брукс поведал нам о своей истории 42 года назад, и ничего, помимо некоторых технических архаизмов, книга сегодня заходит просто на ура.

ЦИТАТА: Еесли и существует какой-нибудь главный секрет эффективности, то это концентрация.

У Друкера архаизмы проявляются в нескольких вещах. Многие примеры идут из 60-х, что неплохо, само по себе. Но часто отсылки идут к истокам и решениям, принятым в 20-х годах, в таких компаниях как Bell Telephone System или General Motors с последующим анализом их влияния на современность. А вот современность по меркам книги – это и есть те самые 60-е. Нет ничего плохого в анализе действий Макнамары, Эйзенхауэра или Кеннеди, но мне их сложно анализировать, поскольку я недостаточно хорошо знаю то время. Моя «современность» начинается несколько позже. Значительно позже.

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

Но самая главная проблема книги, ИМХО, это количество пространных рассуждений.

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

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

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

Что грустно, поскольку хороших-то мыслей в книге достаточно.

ЦИТАТА: Руководитель, подбирающий в организацию людей без недостатков, в лучшем случае наберет посредственный персонал.

Вот, как раз хороший пример, связанный с подбором персонала.

ЦИТАТА: Эффективно работающие руководители знают, что их подчиненным платят за выполнение работы, а не за то, чтобы они радовали своих начальников.

Но ведь хорошо!

ЦИТАТА: Эффективные руководители редко питают иллюзии относительно того, что две посредственности добьются такого же результата, как один блестящий работник. Им известно, что, как правило, двое посредственных работников работают даже хуже, чем один хороший, так как они просто мешают друг другу.

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

ЦИТАТА: Подбирая кадры, нужно обращать внимание на сильные стороны сотрудника в какой-либо одной области, а не на посредственные навыки во многих сферах.

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

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

понедельник, 14 августа 2017 г.

О книге Джона Сонмеза “The Complete Software Developer’s Career Guide”

Если честно, у меня не совсем однозначное отношение к автору книги – Джону Сонмезу (John Sonmez). Это довольно известный парень, автор пары книг, 55 курсов на Pluralsight (о чем он напоминает не менее 10 раз в своей последней книге), автор блога SimpleProgrammer.com и ютюб канала Simple Programmer. Он «вышел на пенсию» в 32 и «отдыхает» в свое удовольствие, работая на себя часов по 8 в день.

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

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

Теперь к книге.

По словам автора, книга “The Complete Software Developer’s Career Guide” покрывает все аспекты карьеры программиста: начиная от обучения и поиска работы, заканчивая продвижением по службе и началом своего дела.

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

Поиск работы. Очевидно, что для разработчиков с разным уровнем некоторые знания будут неактуальны. Если вы уже давно работаете, то вопросы выбора колледжа или код-кампа будут, интернатуры, поиска первой работы и т.п. будут не актуальными. Хотя если у вас есть детки, то, вполне возможно, эти сведения будут не бесполезными.

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

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

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

· Обзор чего-то нового, чтобы понять, что можно решить с помощью этого.

· Понять, как начать это что-то использовать.

· Узнать 20% этого нового, чтобы покрыть 80% юз-кейсов.

Обзор мира разработки ПО. Раздел мало полезный для профессионального разработчика.

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

Я обратил внимание, что корпоративные культуры, промоушены и другие вещи, связанные с карьерой, сильно отличаются «здесь» и «там». Если в Киеве сидение на месте уже является достаточным основанием для повышения зарплаты, то в больших конторах в Штатах это не так.

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

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

Очень понравилась мысль о любимом местном понятии “work/life balance”. Джон советует не противопоставлять эти два понятия, а сделать работу неотъемлемой и приятной частью своей жизни. Да, идеальная работа бывает лишь в сказках, но в наших с вами силах сделать ее разумно-приятной.

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

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

Собственный бренд и саморазвитие.

И тут Остапа понесло.

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

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

Для меня блоггинг также является осью саморазвития и основой сети общения.

Помимо блоггинга, автор рассматривает и другие моменты: менторинг, публичные выступления, домашние проекты, чтение книг и статей.

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

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

Сомнительные моменты.

Как и любая другая книга, книга Джона не идеальна. Есть некоторые моменты, с которыми сложно согласиться. Например, Джон тратит десяток-два страниц убеждая в важности одежды. Дескать, нужно одеваться на два уровня выше своей текущей позиции. Но у меня, например, бос моего боса моего боса ходит в шортах (это Brian Hurry) и ничего. Я совсем не чувствую, что одеваясь в костюм ты произведешь лучшее впечатление.

Еще автор советует, очень советует, найти профессионального писателя резюме. Ну, сомнительно это для меня.

Да и водички с повторениями тоже прилично.

Главный вывод/мотив книги.

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

И не рассчитывай на быстрый результат. Его не будет. Не будет быстрого продвижения по службе. Не будет сразу же восторженных комментариев к вновь созданному блогу. Даже посетителей толком не будет. Ничего. Это нормально.

Наберитесь терпения. Пусть сам процесс доставляет удовольствие и результат придет.

Вердикт: чтиво.

вторник, 21 февраля 2017 г.

Оптимизация типового пути исполнения

Роясь недавно в исходниках TPL Dataflow я заметил некоторый паттерн: многие функции разбиты на две. Основная называется обычным образом, AddElement или что-то в этом роде, а вторая – AddElement_Slow.

При этом мне очень понравилась причина, по которой это дело делалось: эта оптимизация позволяет заинлайнить метод в типовом кейсе. Казалось бы, а есть ли в этом толк? И, как оказалось, что есть (я бы удивился, если бы камрад Тауб решил бы использовать подобную оптимизацию не проверив, что она имеет смысл).

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

Ну, и подробности, у меня в англоязычном посте: “A common execution path optimization”.