25 апреля в рамках «Дня тренинга МГУ 2020» Алексей Каптерев выступил с докладом про критическое мышление. Представляем вам часть 2 расшифровки лекции.

Часть 1 доступна по ссылке.

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

Основываясь на многолетнем опыте преподавания английского специалистам IT-сферы (программистам, бизнес аналитикам, тестировщикам, маркетинговым специалистам), я собрала список наиболее распространенных среди “айтишников” ошибок в английском языке.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

TL;DR: Нет

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

Почему? Давайте разбираться.

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



Для нас, как и для большинства современных компаний, вопрос обратной связи стоит довольно остро: когда, кому и как её правильно давать. Мы пробуем разные подходы. Недавно нашли интересный материал, которым делимся с вами. Под катом про принцип обратной связи «10/50/99», как помогать и не рушить.

---

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

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



Джон Уиллис — один из отцов DevOps. За плечами у Джона — десятки лет работы с огромным количеством компаний. В последнее время Джон стал для себя замечать специфические паттерны, которые имеют место быть в работе с каждой из них. Используя эти архетипы, Джон наставляет компании на истинный путь DevOps-трансформации. Подробнее об этих архетипах — в переводе его доклада с конференции DevOops 2018.

Релиз .NET Core 3.1 — хороший повод мигрировать свой проект с Framework на Core. Во-первых, это отполированная версия с долгосрочной поддержкой (LTS), т.е. её можно смело использовать в продакшене. Во-вторых, в третьей версии добавили поддержку WPF и WinForms, так что теперь появилась возможность мигрировать и десктопные приложения.

Мне стало интересно, какой прирост производительности можно ожидать от Core в самых базовых классах, которые максимально часто используются в коде. Например, коллекции List, Array и Dictionary.

Если вам тоже интересно, как и почему изменилась производительность основных коллекций в Core 3 — прошу под кат!

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

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

В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

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

Disclaimer: Я высказываю свое субъективное мнение на базе доступных данных. Мнение профессиональных вирусологов и эпидемиологов может отличаться от моего. В любой непонятной ситуации обращайтесь к материалам ВОЗ.

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

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

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

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

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

А недавно ко мне подошли коллеги и спросили “Ты понимаешь как работает квантовый компьютер? Можешь нам рассказать?” И тут я понял, что проблема со складыванием в голове целостной картинки есть не только у меня.

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

Писать ответы на статьи легко и приятно. Не надо часами корпеть над структурой статьи, достаточно следовать чужому плану и лишь внятно изложить мысли на бумаге. Тем не менее, рискну предположить, что критический взгляд «с другой стороны» на проблемы, поднятые в статье "Страх и ненависть в IT" уважаемым eugene_crabs, все же будет интересен. В роли адвоката дьявола, защищающего бесчеловечную системы выступаю сегодня я.



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

В конце статьи, по традиции, есть краткое содержание.

Вы читаете книги по саморазвитию, бизнесу или повышению эффективности? Нет? Прекрасно. И не начинайте.

Всё-таки читаете? Не делайте того, что в этих книгах предлагается. Пожалуйста. Иначе станете наркоманом. Как я.

Привет, Хабр!

Предлагаю вашему вниманию перевод статьи "Too Clean?" автора Robert C. Martin (Uncle Bob).



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

Глава 2. Марсианская мечта

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

В прошлый раз мы остановились на том феномене, что игра, которая изначально задумывалась как кооператив (например, D&D или многопользовательская песочница типа Space Station 13), почему-то может использоваться игроками совершенно по другому назначению, становясь пространством насилия и травли. Сегодня, соответственно, будем разбираться в том, как устроена детская (и не только детская) агрессия, как работает формат песочницы, что делает агрессия в песочнице (и вообще в игре) и как можно ей управлять.

Физика эмоции

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

Недавно я прочёл запись в блоге одного парня, который жаловался, что на интервью его попросили написать функцию, которая должна скопировать файл. Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:

---

Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.

Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.