понедельник, 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”.

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

О «маркировке» объекта во время сборки мусора или Рихтер был не прав

Сегодня речь пойдет о бесполезной, с практической точки зрения, информации о внутренностях CLR и сборщика мусора.

Многие из нас изучали внутренности .NET и CLR по книге Джеффри Рихтера “CLR via C#”. Книга просто замечательной, глубокая, детальная и очень точная. Но, как это обычно бывает, даже Рихтер иногда ошибается (пусть и в деталях).

Вот цитата:

When the CLR starts a GC, the CLR first suspends all threads in the process. This prevents threads from accessing objects and changing their state while the CLR examines them. Then, the CLR performs what is called the marking phase of the GC. First, it walks through all the objects in the heap setting a bit (contained in the sync block index field) to 0. This indicates that all objects should be deleted. Then, the CLR looks at all active roots to see which objects they refer to. This is what makes the CLR’s GC a reference tracking GC. If a root contains null, the CLR ignores the root and moves on to examine the next root.

Any root referring to an object on the heap causes the CLR to mark that object. Marking an object means that the CLR sets the bit in the object’s sync block index to 1. When an object is marked, the CLR examines the roots inside that object and marks the objects they refer to. If the CLR is about to mark an already-marked object, then it does not examine the object’s fields again. This prevents an infinite loop from occurring in the case where you have a circular reference.

И что же здесь не так?

пятница, 3 февраля 2017 г.

О “вреде” книг: напутствие любому программисту

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

Мне сложно судить о современном программистском образовании в России/Украине (эта тема также поднимается в статье). У меня самого нет специализированного образования (я по образованию «специалист» в области систем автоматизированного управления), да и с момента получения оного прошло уже довольно много времени (19 лет с момента поступления в университет). Но мне явно есть что сказать по поводу самообразования и использования книг в этом процессе.

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

среда, 1 февраля 2017 г.

Исследуем new() ограничение в C#

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

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

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

Я уже несколько раз затрагивал вопрос реализации одной довольно простой возможности языка C# - ограничения обобщений new(), что она, дескать, реализована через Activator.CreateInstance (да и то, не всегда;), подробности – в оригинале!).

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

Так вот, у нас на проекте, активное использование new T() весьма быстро вылезло в профилировщике, было починено с весьма заметным приростом end-to-end времени исполнения. Там мы прикрутили простое решение на основе деревьев выражения и про это забыли.

А не так давно на ru.stackoverflow.com был задан вопрос по поводу кодогенерации и примеров ее применения, что дало дополнительную почву для размышлений на эту же тему. В результате были перекопаны следующие вещи, чтобы добиться эффективности кастомного активатора равных вызову делегата вида () => new CustomNode():

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

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

Понятное дело, что подробности – по ссылке: Dissecting the new() constraint in C#: a perfect example of a leaky abstraction.

З.Ы. Я надеюсь, что читать такое введение интереснее, чем просто увидеть ссылку.

З.Ы.Ы. Пожелания, предложения и все такое, всячески приветствуется.

четверг, 19 января 2017 г.

Ретроспектива 2016

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

Как известно, 2016-й был непростым годом (четный год таковым быть не может) и по блогу это заметно. За прошлый год можно было заметить следующие тренды: я начал заниматься ErrorProne.NET (правда потом забил), в начале года я допилил Code Contracts и с тех пор только принимал пул рекветы (все еще не знаю, что делать с поддержкой VS 2017), начал блог на английском, ну и написал полтора-два десятка статей на разные темы.

Теперь об этом и другом, более подробно (с)J