Привет, Хабр! Меня зовут Даша Фролова, я редактор команды спецпроектов в МТС Диджитал. А по совместительству — мама шестилетки и трехлетки, которые внезапно моими стараниями влюбились в космос, знают, в каком порядке расположены планеты Солнечной системы и где находится Море Кракена. Еще они знают, что солнце нельзя потушить из пожарного шланга — этот вопрос почему-то волновал сына больше всего.

Возможно, кто-то сейчас фыркнул: мол, да в 6 лет я уже и побольше о космосе знал. Но в нашем детстве не было Твайлайт Спаркл, Гвен Стейси, Синего трактора и еще 100 500 персонажей из виртуальной вселенной, с которыми сейчас конкурирует Вселенная вполне себе реальная.

Отодвинуть девайсы на задний план нам помогли книги, хотя выдержать баланс между «не переутомить» и «не проваливаться совсем в развлекалово» было сложно. Отлично помню реакцию детей на очередные «астрономия — это одна из древнейших наук» и «представляет собой шар, расположенный в центре сферы»: моментальная потеря интереса, позевывания и «а может, лучше все-таки мультик?». Некоторые книги не заходили с первой страницы, другие уезжали на дальнюю полку после первого прочтения (и до сих пор там лежат), а третьи стали практически настольными: мы лазим в них постоянно. В итоге читать про космос стало прикольным хобби, а любимый супергерой дочки — уже не Эльза, а Юрий Гагарин.

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

Если вы вращались в англоязычном информационном пространстве, типа Реддита, в 2020–2021 годах, то наверняка видели посты, рекламирующие игру с достаточно интересным содержанием. «Самый реалистичный симулятор вторжения пришельцев», «Геополитика в вашей песочнице», «Проложите новый путь человечества» и всякие другие громкие слоганы. Так рекламировали Терра Инвикта — амбициозный проект Pavonis Interactive (ранее известные как Long War Team), где они попытались смешать несколько очень разных игр — 4Х стратегию, геополитический симулятор и игру о колонизации Солнечной системы. Какой получилась первая полновесная игра команды, которая ранее занималась только разработкой модов? Давайте посмотрим.

Будет совсем чуть-чуть спойлеров!

Лента или лист Мëбиуса — верный друг всех адептов занимательной математики. Это неориентируемое гладкое двумерное многообразие можно без труда вложить в трёхмерное пространство, склеив из бумажной полоски, а потом эффектно разрезать на потеху публике. Но кого можно удивить лентой Мёбиуса на Хабре? Знаем, клеили, резали! Но всё же, я надеюсь подарить вам ещё несколько незаезженных топологических инсайтов на эту тему. Более того, в ней есть ещё что изучать, и я поделюсь с вами двумя относительно недавними исследованиями ленты Мёбиуса, опубликованными в 2010-м и 2014-х годах.

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

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

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

Все наверно помнят, что любой алгоритм можно представить в виде трех видов алгоритмических конструкций, следование, ветвление и повторения? А иногда еще добавляют, что эту теорему выдвинул и доказал Э. Дейкстра в 70-х гг. прошлого века, в том числе, включая широко распиаренный якобы запрет на использование операторов goto.

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

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

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

Фидбэк от команды оказался позитивным, поэтому я решил поделиться знаниями и с сообществом.

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

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

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

Привет! Провели финал IT’s Tinkoff Solution Cup 22 апреля. Шесть треков, нестандартные задачи и призы. У нас получилось собрать офлайн много крутых разработчиков и близких по духу людей, порешать задачи и пообщаться с коллегами.

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

Эта статья является переводом материала «Immutable architecture».

В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.

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

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

Тонкости Queryable Provider

Queryable Provider не справляется вот с этим:

 var result = _context.Humans
                      .Select(x => $"Name: {x.Name}  Age: {x.Age}")
                      .Where(x => x != "")
                      .ToList();

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

 var result = _context.Humans
                      .Select(x => "Name " +  x.Name + " Age " + x.Age)
                      .Where(x => x != "")
                      .ToList();

Особенно болезненно править баги после включение ClientEvaluation(исключениe при вычислении на клиенте), все профайлы автомаппера должны быть подвергнуты жесткому анализу, на поиск этой самой интерполяции. Давайте разберемся в чем дело и предложим свое решение проблемы

В этой статье мы рассмотрим, как писать чистый, легко тестируемый код в функциональном стиле, используя паттерн программирования Dependency Injection. Бонусом идет 100% юнит-тест coverage.

Дисклеймер

Начинаем с теории

Прошло уже достаточно времени с выхода обновленного Angular. В настоящее время множество проектов завершено. От "getting started" множество разработчиков уже перешло к осмысленному использованию этого фреймворка, его возможностей, научились обходить подводные камни. Каждый разработчик и/или команда либо уже сформировали свои style guides и best practice либо используют чужие. Но в тоже время часто приходится сталкиваться с большим количеством кода на Angular, в котором не используются многие возможности этого фреймворка и/или написанного в стиле AngularJS.

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