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

Как я всё это ненавижу. Работу, начальника, программирование, среду разработки, задачи, систему, в которую они записаны, подчиненных с их соплями, цели, электронную почту, интернет, социальные сети, где все поразительно успешны, показушную любовь к компании, лозунги, собрания, коридоры, туалеты, лица, рожи, дресс-код, планирование. Я ненавижу всё, что происходит на работе.

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

Привет, Хабр. Недавно я выпендрился в комментариях и пообещал подробно ответить на вопрос о том, как дизайн-система упрощает взаимоотношения и нейтрализует конфликты между дизайнерами и верстальщиками (разработчиками). Плюс рассказать о некоторых вариантах стандартизации именования слоёв. Вот и отвечаю. Подробно. Про сетки. Про компоненты. Про иконки. Про язык. Про БЭМ. Про «фигмин» слэш и её же плагины. Про артборды и вьюпорты. Про типографику. Про стили и палитры. Про эффекты. Про экспорт растра. Про «мультиплеер». Про распределение обязанностей. Ну и немножко «о жизни, вселенной и вообще». Осторожно, трафик: внутри много картинок, есть gif-анимации. А ещё много, действительно много нудного текста. Я предупредил.

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

Архитектура

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

1. Поведение (behavior) — функции и задачи, которые программа (компонент, сервис) выполняет.
2. Архитектура — этот термин в большей мере о изменении приложения.

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

И вот как строить эту архитектуру, как избавится от головной боли при маленьком изменении требований от PM’а, или от стейкхолдера: об этом и поведает книга

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

Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.

Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.

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

Дорогие товарищи инженеры и будущие инженеры, сообщество Метархия открывает набор на бесплатный курс «Основы программирования», который будет доступен на youtube и github без всяких ограничений. Часть лекций уже записана в конце 2018 и начале 2019 года, а часть будет прочитана в Киевском политехническом институте осенью 2019 года и сразу же доступна на канале курса. Начало курса 3 сенября. Опыт предыдущих 5 лет, когда я делал более сложные лекции, показал необходимость лекций и для самых начинающих. В этот раз, по многочисленным просьбам студентов, я постараюсь добавить много материалов по основам программирования и, по возможности, абстрагировать курс от JavaScript. Конечно большинство примеров останутся на JavaScript, но теоретическая часть будет гораздо шире, и не ограничится синтаксисом и API языка. Часть примеров будет на TypeScript и C++. Это не курс по голому JavaScript, но фундаментальный курс по основам программирования, включая основные концепции и шаблоны проектирования для разных парадигм, функционального, процедурного, объектно-ориентированного, обобщенного, асинхронного, реактивного, параллельного, мультипарадигменного и метапрограммирования, а так же основы структур данных, тестирования, принципы построения структуры и архитектуры проектов.

Программистам вроде меня, которые пришли в C# с большим опытом работы в Delphi, часто не хватает того, что в Delphi принято называть ссылками на класс (class reference), а в теоретических работах – метаклассами. Я несколько раз натыкался в разных форумах на обсуждение, проходящее по одной схеме. Начинается оно с вопроса кого-то из бывших дельфистов на тему того, как сделать метакласс в C#. Шарписты просто не понимают вопроса, пытаются уточнить, что это за зверь такой – метакласс, дельфисты как могут объясняют, но объяснения краткие и неполные, и в итоге шарписты остаются в полном недоумении, зачем всё это нужно. Ведь то же самое можно сделать с помощью рефлексии и фабрик класса.

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

Вы задавались когда-нибудь вопросом, как в играх наподобие Super Meat Boy реализована функция реплея? Один из способов её реализации — выполнять ввод точно так же, как это делал игрок, что, в свою очередь, означает, что ввод нужно как-то хранить. Для этого и многого другого можно использовать шаблон Command.

Шаблон Command («Команда») также полезен для создания функций «Отменить» (Undo) и «Повторить» (Redo) в стратегической игре.

В этом туториале мы реализуем шаблон Command на языке C# и используем его для того, чтобы провести персонажа-бота по трёхмерному лабиринту. Из туториала вы узнаете:

• Основы шаблона Command.
• Как реализовать шаблон Command
• Как создавать очередь команд ввода и откладывать их выполнение.

Библиотеки .NET Core — один из самых популярных C# проектов на GitHub. Неудивительно, с учётом его широкой известности и используемости. Тем интереснее попробовать выяснить, какие тёмные уголки можно найти в исходном коде этих библиотек, что мы и попробуем сделать с помощью статического анализатора PVS-Studio. Как думаете, удалось ли в итоге обнаружить что-нибудь интересное?

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

Я не люблю такие обобщения. Да, что-то есть только в «двух столицах»: когда мы (JUG Ru Group) делали конференцию в Новосибирске, столкнулись с отсутствием нужного оборудования. Но в том же городе живёт известный многим Тагир lany Валеев, там он работает над IntelliJ IDEA, готовит крутые доклады и хабрапосты. И как тогда говорить, что там нечего делать?

Скоро мы проведём в Петербурге фестиваль TechTrain со слоганом «Узнай, чем живут другие», и там будут представлены многие IT-сообщества. А недавно в отпуске я ездил поездами по городам Транссиба, и фестиваль подал мне идею: в поездке узнать, чем живут айтишники в других городах, пообщавшись с активистами местных IT-сообществ. Я расспрашивал о их деятельности, о том, что в городе с IT, и о решении жить не в Москве. Делюсь с Хабром результатами.

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

Всем бородатое ку, товарищи!

Все мы знаем, что такое округление. Если кто-то забыл, то округление — это замена числа на его приближённое значение, записанное с меньшим количеством значащих цифр. Если спросить человека с ходу, что получится при округлении 6,5 до целых, он не задумываясь ответит «7». Нас со школы учили, что числа округляются до ближайшего целого большего по модулю числа. То есть, если в округляемом числе дробная часть равна или больше половине разряда целой части, то мы округляем исходное число до ближайшего большего.

Всем привет. На связи Омельницкий Сергей. Не так давно я вел стрим по реактивному программированию, где рассказывал про асинхронность в JavaScript. Сегодня я бы хотел законспектировать этот материал.

Но перед тем как начать основной материал нам нужно сделать вводную. Итак, давайте начнем с определений: что такое стек и очередь?

Стек — это коллекция, элементы которой получают по принципу «последний вошел, первый вышел» LIFO

Очередь — это коллекция, элементы которой получают по принципу («первый вошел, первый вышел» FIFO

Окей, продолжим.

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

Предыстория

Мне поступила задача по настройке CI. Было принято решение использовать трансформацию конфигурационных файлов и конфиденциальные данные хранить в зашифрованном виде. Зашифровать и расшифровать их можно с использованием Key Container.

Key Container

В каждой ОС Windows есть наборы сгенерированных ключей. Ключ генерируется либо на учетную запись, либо на машину. Ключи, сгенерированные на машину, можно посмотреть по этому пути C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Сюда и отправится ключ который мы создадим далее.

История о том, как простой парень из депрессивного региона России пытается заявить о себе — и о том, что стереотипы говно.

Привет. Меня зовут Даниял Деветов, я iOS-разработчик в компании FINCH. Пока я еще junior, но крепкий, я бы даже сказал «почти middle».

Родом я из города Махачкала, столицы солнечного и очень любимого мной Дагестана. Да, того самого Дагестана, откуда, по мнению многих наших соотечественников, родом только спортсмены и ребята, которые приезжают в Москву «порядок наводить». Это, конечно, мешает карьерному развитию — стереотипы такие стереотипы! Хотя, на самом деле, Дагестан вырастил много успешных людей в IT — вроде Тагира Магомедова из Uber и Камиля Насруллаева из Mail.ru.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

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

Содержание

• О разделяемых ресурсах
• Возможные проблемы при работе в многопоточной среде
  • Deadlock
  • Race-Condition
  • Busy-Wait
  • Thread Starvation
• Средства синхронизации
  • Interlocked
  • Monitor.Enter, Monitor.Exit, lock
  • SpinLock, SpinWait
  • Monitor.Wait, Monitor.Pulse[All]
  • ReaderWriterLockSlim
  • Семейство ResetEvent
• Выводы

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

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

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

А что если поезд попадёт в туннель? Тут высока вероятность того, что связь с интернетом прервётся и веб-приложение не сможет «достучаться» до сервера. В этом случае пользователю придётся перезагрузить страницу приложения после того, как поезд выедет из туннеля и соединение с интернетом восстановится.

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

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



Материал, перевод которого мы сегодня публикуем, посвящён разбору нескольких способов повторения неудачных запросов в Angular-приложениях.

Нет, чернобыльская радиация не навредила вашему ребёнку

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

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

«Первое, что нужно понять насчёт мини-сериала „Чернобыль“ от HBO, — писал журналист из The New York Times, — то, что довольно многое является выдумкой. Однако другое, и более важное его свойство: это не так уж и важно». Журналист отметил ту же неточность, что и я в прошлой статье на ту тему: «жертвы радиации часто по какой-то причине оказываются испачканными кровью».

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

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



Автор статьи, перевод которой мы сегодня публикуем, говорит, что хочет поделиться советами, которые помогут Angular-разработчикам сэкономить немного времени. Он собирается рассказать о подводных камнях Angular, с которыми ему (и не только ему) довелось встретиться.

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

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

Что же делать? Как работать с Игнатом? Добро пожаловать под кат!