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

С этой же проблемой столкнулся и я, когда примерно два года назад пришел в Тинькофф на позицию Junior Frontend Developer и погрузился в мир Angular. Поэтому предлагаю вам короткий рассказ о пяти вещах, понимание которых очень облегчило бы мою работу на первых порах.

В Яндексе – идеальные для ИТ отцы-основатели… а какую позитивную книгу о них и об идеологии Яндекса Соколов-Митрич написал… Но что в Яндексе сложилось за несколько лет «внизу»? В этом посте последняя ссылка показывает – полный мрак.
Второй пример – Магнитом управляет такой умный и правильный Сергей Галицкий (почитайте его интервью), но «внизу» творится какой-то ад: «Мы не рабы» кричат его сотрудники.

Почему так? Что же за злой рок преследует большие компании?

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

Даже в этом идеальном случае у неё имеются, причем со временем усиливаются, следующие негативные свойства:

1. Усиление строгости при движении приказов сверху-вниз.
2. Положительная обратная связь и искажение отчетности при движении информации снизу-вверх.
3. Уменьшение взаимопонимания с ростом количества промежуточных звеньев между сотрудниками.

Далее рассмотрим их подробнее и сформулируем:

4. Советы сотрудникам, идущим работать в большие компании.
5. Своё собственное скромное мнение, почему Яндекс всё ещё хорош на фоне многих других.


Движение сверху-вниз приказов и всего прочего. Вы же не ожидали увидеть здесь другую картинку?

Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

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

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

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

^{Photo by Kevin Horvat}
Все 12 лет своей карьеры я работал с .NET и был крепко привязан к Windows и проприетарным инструментам разработки. Но, спасибо Microsoft, .NET Core все изменил и теперь разрабатывать для .NET можно почти на чем угодно и в чем угодно. Дело за малым — перетащить на Core свои проекты. Не так давно я решил и этот вопрос и завел трактор для полного переезда на Ubuntu.

Результат очень понравился — все взлетело, разрабатывать легко, а Docker и Kubernetes сделали процесс переезда намного легче. Но из-за слабого знания ОС, bash и запутанности вариантов установки некоторых инструментов (например, того же Docker) изначальная настройка заняла больше дня. То есть процесс довольно долгий и местами запутанный.

Дабы сэкономить время будущему себе и тем, кто также планирует попробовать разработку под Linux, я оформил все в виде скриптов. Их можно запустить на чистой Ubuntu и они все настроят пока ты сидишь и пьешь чаек. Также, при желании, их легко допилить под свои нужды.

Если для вас это звучит полезно — добро пожаловать под кат.

В нашем новом выпуске разработка для Авроры, Дубай Молл в смартфоне, тренды UX-дизайна, инструменты HTML5-разработки, доходы 1% топовых издателей, которые получают 93% денег всего рынка приложений. Интересный дайджест у нас получился!

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

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

Подробно о преобразовании асинхронного кода, осуществляемого компилятором

Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.

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

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



У журнала есть четко фиксированный день рождения — 24 сентября 1956 года. В этот день увидел свет первый номер журнала «Веселые картинки» — первого советского журнала для дошкольников.

Счастливым (и многодетным) отцом было постановление партии и правительства «О развитии детской литературы и детской периодики», вышедшее в начале 1956 года. Через несколько месяцев после его появления количество детских журналов в стране удвоилось — уже в сентябре в компанию к «Мурзилке», «Пионеру» и «Костру» добавились «Юный техник», «Юный натуралист» и «Веселые картинки», выпустившие свои первые номера.

Привет, хаброжители!

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

В наше время развернуть в облаке свой вебсайт с доменным именем второго уровня можно бесплатно. Вам интересно как? Читайте дальше.

Предлагаю вам разобрать то, как можно создать гостевую книгу на ASP.NET Core (с reCAPTCHA) и захостить ее бесплатно на довольно известном облачном хостинге (да, с ограничениями, но для персонального вебсайта с не особо большим трафиком годится вполне)

Уже несколько лет твержу себе — у всех вещей должно быть своё место. И вот сколько твержу, ровно столько же забываю на рабочем столе штуки, которые для работы никак не нужны. Выбрасываю лишнее, структурирую важное и складываю в кучки всякое, но каждый раз всё замусорено до основания. И мне надоело.

Потому что ну как же выкинуть тот красивый блокнот с логотипом компании (пятый в очереди на использование) или наконец-то унести домой давно забытый квадрокоптер. В итоге всё начинает выглядеть так:

Рабочее место редактора

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

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

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

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

Необходимое вступление

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

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

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

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

^{Этот перевод появился благодаря хорошему комментарию 0x1000000.}

В .NET Framework 4 появилось пространство System.Threading.Tasks, а с ним и класс Task. Этот тип и порождённый от него Task<TResult> долго дожидались, пока их признают стандартами в .NET в роли ключевых аспектов модели асинхронного программирования, которая была представлена в C# 5 с его операторами async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, разработанных для улучшения производительности асинхронных методов в случаях, когда издержки на выделение памяти нужно принимать во внимание.