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

***

Я расскажу историю одного тестового задания. Немного длинную, но, надеюсь, интересную.

У нас в Ecwid все тестовые задания для инженеров выложены открыто на GitHub вот тут — github.com/Ecwid/new-job. Можно просто начать делать любую понравившуюся задачу, никого не предупреждая, а потом, когда сами будете довольны результатом, поделиться им со мной.

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

Качальщик нужно сделать действительно очень примитивный. Судите сами — ты ему список ссылок в текстовом файле, а он скачивает эти файлы и кладет в указанную папку на локальном диске. Должен уметь качать несколько файлов одновременно (в несколько потоков, например, 3 потока) и выдерживать указанное ограничение на скорость загрузки, например, 500 килобайт в секунду. Всё.

Прочитав небезызвестную книгу Ханка Райнвотера “Как пасти котов”, я пришёл к мысли, что, возможно, эта книга идеально подходит для выгула уже воспитанных обитателей “фауны программистов”. Однако что делать с только что окончившими ВУЗы новичками? Воспитание новоиспеченного разработчика (недопрограммиста) очень схоже с воспитанием щенка, который пока не понимает куда справлять нужду и как не гадить дома.

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

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

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

Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.



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

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

Изучая язык программирования C#, я сталкивался с особенностями как самого языка, так и его средой исполнения, *некоторые из которых, с позволения сказать, «широко известны в узких кругах». Собирая таковые день за днем в своей копилке, что бы когда-нибудь повторить, чего честно сказать еще ни разу не делал до этого момента, пришла идея поделиться ими.

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

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

Конструкции, или почему не ломаются вещи, Дж. Гордон
Прекрасная, хоть и очень длинная штука, которая рассказывает про сопромат простыми словами и почти для детей. Но на уровне жёсткого хардкора. По своей полезности для осознания физики вокруг может сравниться с не менее прекрасной современной «Квантовая вселенная. Как устроено то, что мы не можем увидеть» Брайана Кокса и Джеффа Форшоу. Рекомендую обе. Будет, что почитать в дороге, если вдруг почувствуете, что играть на планшете надоело. И о чём подумать, когда выяснится, что вся та фигня, которую вам давали на уроках химии, физики и прочего в школе и университете вдруг начинает выстраиваться в стройную теорию.

Evil by Design, Крис Ноддер
Один из лучших подходов к проектированию чего-то хорошего — это спроектировать сначала самое ужасное из возможного. Пользователь обычно не скажет, как сделать ему хорошо, но точно знает, как бывает плохо. Например, юзер не говорит «я хочу, когда нажимаю на ссылку напоминания пароля, там в поле уже была введена почта», зато вполне способен сказать: «слушай, меня дико бесит, когда логинишься, тебе показывают новую страницу про то, что пароль не подошёл, и, чтобы его восстановить, надо ещё один долбанный раз вводить почту». Вся книга Криса состоит из таких «тёмных» шаблонов, когда какие-то гады намеренно вводят вас в заблуждение. Он там очень переживает за этику, поэтому вступления лучше пропустить. Единственная в этом обзоре книга на английском, но довольно простом.

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Иногда при разработке программного обеспечения требуется встроить дополнительную функциональность в уже существующие приложения без модификации исходного текста приложений. Более того, зачастую сами приложения существуют только в скомпилированном бинарном виде без наличия исходного текста. Широко известным способом решения указанной задачи является т.н. “сплайсинг” – метод перехвата функций путем изменения кода целевой функции. Обычно при сплайсинге первые байты целевой функции перемещаются по другим адресам, а на их исходное место записывается команда безусловного перехода (jmp) на замещающую функцию. Поскольку сплайсинг требует низкоуровневых операций с памятью, то он осуществляется с использованием языка ассемблера и С/C++, что также накладывает определенные ограничения на реализацию замещающих функций – они обычно также реализованы на С/C++ (реже на ассемблере).

Метод сплайсинга для перехвата API-функций в Windows широко описан в Интернете и в различных литературных источниках. Простота указанного перехвата определяется следующими факторами:

1. целевая функция является статической – она сразу присутствует в памяти загруженного модуля;
   
2. адрес целевой функции легко определить (через таблицу экспорта модуля или функцию GetProcAddress).
   

Реализация замещающих функций на C/C++ при перехвате API-функций является оптимальным вариантом, поскольку Windows API реализовано, как известно, на языке C, и замещающие функции могут оперировать теми же понятиями, что и заменяемые.

Как правило, статьи о кешировании начинаются за здравие, а заканчиваются LRU кешем. Попробуем переломить эту тенденцию? Начнем с того, чем LRU плох, а закончим за здравие. Я надеюсь.

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

Психопаты — это не только злодеи из ужастиков и поучительных историй с Уолл-стрит. Мы ежедневно встречаемся с ними в офисе, и поначалу они кажутся нам обычными людьми. Одно исследование обнаружило: небольшая, но заметная часть бизнес-лидеров — 3—4% — подходит под клиническое определение психопата. Как защититься при взаимодействии с такими людьми?

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

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

Много раз я спрашивал себя, что какой IoC контейнер подойдет для того или иного проекта. Их производительность — это только одна сторона медали. Полное сравнение производительности можно найти здесь. Другая сторона медали — простота и скорость обучения. Так что я решил сравнить несколько контейнеров с этой точки зрения и взял Autofac, Simple Injector, StructureMap, Ninject, Unity, Castle Windsor. На мой взгляд, это наиболее популярные IoC контейнеры. Вы можете найти некоторые из них в списке 20 лучших пакетов NuGet и также я добавил другие по своим предпочтениям. Лично мне очень нравится Autofac и во время работы над этой статьей я еще больше утвердился, что это лучший выбор в большинстве случаев.

Здесь описываются основы IoC контейнеров, таких как конфигурация и регистрации компонентов. Есть мысль так же провести сравнение управления lifetime scope и продвинутых фитч. Примеры кода можно найти в репозитории LifetimeScopesExamples GitHub.

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

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

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

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

Оказывается, в свободном доступе есть интересная информация от HeadHunter о повышении фонда оплаты труда (ФОТ) в 2015 году. Со страницы проекта "Банк данных заработных плат" идет ссылка "Сравнивайте зарплаты вашей компании с рынком".

Прямая ссылка на pdf: Зарплаты в России. Итоги 2015 года.


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

И вообще, многим придут на ум уже затертые шаблоны:

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

Но эти выводы и советы слишком уж лежат на поверхности.
We need to go deeper.
Давайте посмотрим, насколько же глубока эта не кроличья нора…