Как правильно писать?

🐹 — Jaeger.
🦌 — Jagermeister.

Насколько плохим должен быть код, когда ты стартап?

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

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

Но для меня один из самых любопытных вопросов: «А есть ли примеры стартапов, которые умерли (или были к этому очень близки) из-за плохого кода?».

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

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

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

И вот в этом, по-моему мнению, кроется ключевой скилл senior-разработчика: понять, когда надо действовать ради краткосрочных целей, а когда вкладываться вдолгую. Всё как на фондовом рынке, честное слово.
_______

Благодарим автора поста — СТО Сашу Андронова. Подписывайтесь на его телеграм-канал, там он ещё много чего интересного рассказывает.

Когда ты стартап: 🙈 — код может быть любым, главное, чтобы работал; 🦁 — код сразу надо писать по-нормальному.

Словарь редких IT-терминов #15: Пигануть — по-свински пингануть в общем чате сообщением, которое можно было бы написать и лично.

Как и где вы читаете технологические новости/статьи?

Facebook, Twitter, HackerNews, VC, официальные блоги GitHub и Microsoft Azure. Всё это агрегируется в RSS-подписках или в соцсетях. При этом всё равно часть контента полезна, а часть нет.

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

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

Пробник будет ждать вас здесь.

Хотите инструмент для кастомного сбора ленты новостей?

🙏 — да;
❌ — нет;
😼 — у меня есть такой инструмент.

Псс, третий митап по теме data engineering «DE or DIE #3» на подходе.

Когда: следующий четверг (16.07), с 19:00 до 21:00 MSK.

Будет жара — ребята рассмотрят один целиковый кейс от дата инженеров из Додо Пиццы (Ксения Томак, Михаил Кумачев, Дарья Буланова) и Solution Architect из Databricks (Иван Трусов).

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

***
Облако слов (стек используемых технологий) для привлечения внимания:
— Cloud provider: Azure.
— Data Source: Azure MySQL DB.
— CDC pipeline: Kafka Connect + Debezium + Azure Event Hubs.
— Processing: Spark + Spark Streaming on Databricks.
— Storage layer: Delta Lake + Azure Data Lake Storage.
— CI/CD: GitHub Actions + Databricks REST API.
— Implementation language: Python.
***

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

Анимация Android: как сделать плавные переходы фрагментов?

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

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

Сегодня вышла статья нашего Android-разработчика Василия Малеева о проблеме и анализе вариантов её решения. Мы не дадим вам серебряную пулю против всех монстров, но покажем, как можно изучить конкретного, чтобы создать пулю специально для него. Разберём это на примере того, как мы подружили анимацию смены фрагментов с Bottom Sheet.

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

— Кому задавать вопросы? 
— А можно подойти к директору? 
— Где туалет?

***

Таким выглядит мир новичков в компаниях, где нет онбординга.

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

Нужен ли разработчику онбординг в новой компании или выплывет сам?

🛩 — конечно, нужен;
🏊🏼‍♀️ — справится сам.

Словарь редких IT-терминов #16: Хейтергейст — хейтер, который шумит и абьюзит в твоём сообществе/рабочем чате.

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

Словарь редких IT-терминов #17: Бейсбаг — ты отбиваешь баг как можно дальше и, пока другая команда с ним разбирается, стараешься успеть убежать домой.

🐞 — проблема не на нашей стороне.
⚾️ — никогда так не делаю.

Если мозг давит на вас изнутри и постоянно требует каких-то новых знаний — отведите его на онлайн-курсы.

Мы считаем, что учиться и развиваться нужно постоянно. А ребята из OTUS могут в этом помочь, к тому же у них есть для вас подарок — скидка 5000р. на любой открытый курс (промокод DODO_LETO20 действует до 31 августа 2020). 

Наши разработчики проходят курс в OTUS и готовы поделиться фидбеком.

Что понравилось:
— Много новых знаний. А если в голове только обрывочные знания по предмету, курсы помогут собрать их в структуру.
— Большое количество практики и домашки — это круто, сильно помогает в наработке опыта. Жрёт неимоверно много времени, но незаменимо для освоения навыков и изучения материала.
— Практики, инструменты, библиотеки, которые рекомендуют преподаватели курса, точно стоит изучить.

Что оставило вопросы:
— Домашки много, и она большая (на выполнение может уходить по 5-10 часов в неделю), возможно из-за этого у преподавателей не всегда хватает времени на детальный фидбек и прожарку по ней.
— Некоторые занятия хотелось бы заменить на самостоятельное чтение документации.
— С некоторыми преподавателями было проще, с некоторыми сложнее, но это чистая субъективщина.

***
Выбрать курс и получить скидку.
Посетить их уютные бесплатные вебинары.

Автоматическое управление памятью в .NET

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

Какие темы разберём:
— Сборка мусора.
— Поколения кучи.
— Механизм финализации.
— IDisposable и дескрипторы системных ресурсов.

Если у вас лапки и вам это пока сложно, идите на экскурсию-знакомство с .NET для начинающих.

#dotnet #csharp #developer #it #NETFramework

22 июля — всемирный день мозга (World Brain Day)

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

Аня Перова переплела свой опыт с последними результатами научных исследований и получилась крутая статья.

Заботьтесь о своём мозге, чтобы он позаботился о вас!

А вы знаете правила заботы и ухода за мозгом?

🧠 — конечно.
🧟‍♂️ — не думал об этом.

Всех с пятницей!

Как тестировать без документации?

Так и подмывает ответить «Никак!» и закончить пост, но это не тот случай. В эпоху «Работающий продукт важнее исчерпывающей документации» тестирование продукта без этой самой документации — важный навык для QA. Ловите подборку из трёх советов, которые могут помочь, как на собеседовании, так и в жизни.

1. Исследуйте продукт. Исследовать продукт можно разными способами.

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

2. Разбирайтесь в коде продукта. Есть мнение, что код — лучшая документация. Я с этим утверждением согласен. Если не умеете читать код, не проблема, попросите разработчика посидеть вместе с вами, почитать код и ответить на вопросы. Тут важно помнить, что код — это документация того, как продукт работает сейчас, а не того, как он должен работать на самом деле.

3. Сделайте минимальную документацию самостоятельно. Посидеть в паре с разработчиком хорошо, но вряд ли вы запомните всё с первого раза. Да и наличие знаний только в голове QA и разработчиков — не очень хорошая практика. Напишите чек-листы, майндмэпы со сценариями, автотесты. Так у вас появится актуальная документация вашего продукта.

Что в итоге?

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

В заказной разработке проблем с документацией нет, там всегда есть ТЗ, которое фиксирует договоренности с заказчиком. ТЗ встроено в процессы.

В продуктовой разработке всё немного иначе. Идеальным местом для документации может быть тестовая документация. QA на этапе тестирования видят, что получилось и могут зафиксировать это в виде тестов. Тестовая документация автоматически встраивается в процесс обеспечения качества продукта. А при грамотном подходе к организации тестовой документации получится отличный справочник по вашему продукту.
_______

Мы не смогли найти никакую статистику по наличию в компаниях документации и её качеству. Если вы знаете такую, то скиньте, пожалуйста, в комменты.

Автор поста: Евгений Иванченко. ❤️