Что такое технический долг?

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

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

О фронтенде

От своего руководителя, который успел побыть фуллстек-разработчиком сегодня услышал следующее:

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

Что такое DevOps?

На позапрошлый пост мне сделали замечание, мол автоматизировать деплой должны не разработчики, а некие девопсы. Что же это за люди такие? Давайте разбираться.

В статьях с определением DevOps чаще всего фигурируют такие слова, как agile-практика, философия, набор методик для достижения синергии между людьми из разных сфер: разработчиков (Developers) и специалистов сопровождения (Operations), вовлечение и понимание процессов друг друга и совместное планирование релизов.

Для разработчика в компании, использующей DevOps, подразумевается владение такими навыками, как CI/CD, контейнеризация, оркестрация и продвинутое использование серверной ОС. То есть помимо написания кода нужно также иметь полное представление о том, как этот код доходит до пользователя.

В DevOps не подразумевается (!) наличие в команде продвинутого админа, зовущегося DevOps-инженером, который владеет вышеперечисленным. Такой подход как раз говорит о полном отсутствии DevOps культуры.

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

​​Медитации

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

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

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

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

С наступающим, дорогие подписчики!

​​А какой список запрещенных слов в вашей компании/команде?

О научных статьях.

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

1. Resilient Distributed Datasets: A Fault-Tolerant
Abstraction for In-Memory Cluster Computing. Вводная статья в основную структуру данных фреймворка Apache Spark.
2. The Google File System. Статья описывающая принцип работы GFS - распределенной файловой системы, разработанной в компании Google. Свою систему они не выложили в открытый доступ, но по этой статье была разработана HDFS, являющаяся одним из основных компонент экосистемы Hadoop.
3. Bigtable: A Distributed Storage System for Structured Data. Похожая на предыдущий пунк история с технологией из гугла, описанной в статье, по которой сообществом был произведен аналог - HBase - NoSQL хранилище больших данных.
4. Kafka: a Distributed Messaging System for Log Processing. Кафка

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

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

Подписывайтесь, https://t.me/ismalife, здесь говорят правду.

Почему не нужно читать техническую литературу

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

- Даже если есть проблема и книга в которой написано как ее решить, зачем читать 400+ строк сопутствующей воды, рассчитанной на массового читателя, когда есть спецификации, мануалы и референсы?

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

- Эгокастинг. Любой из нас читая умную книгу склонен замечать только те факты, которые соответствуют устоявшейся точке зрения и отбрасывать контраргументы.

Почему нужно читать техническую литературу

- Лучший способ для новичка погрузиться в предметную область. Самые крутые в своей области книги быстро становятся своего рода библиями, как например "Thinking in Java" или "Learn python the hard way"

- Книги содержат емкую выжимку знаний и опыта суперзвёзд индустрии, собираемых ими годами, как например "Refactoring" Мартина Фаулера или "Clean architecture" Боба Мартина

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

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

Люблю такое

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

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

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

#управление_проектами #TL;DR #сарказм

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

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

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

Итак, это мой манифест новой методологии ведения проектов под названием ЗДРАВЫЙ СМЫСЛ (ЗС)

1. С точки зрения методологии ЗДРАВЫЙ СМЫСЛ в постоянно меняющемся мире целесообразно планировать работу на короткие сроки, что-то в районе двух недель. Такие сроки назовем ЗАБЕГИ.

2. Очень полезно приходя на рабочее место сообщать коллегам свой прогресс по задачам, дабы оперативно решать возникшие проблемы. Эти мероприятия будут иметь название УТРЕННИК.

4. Оценивать задачи при планировании человеку проще в относительных единицах измерения, нежели в абсолютных. Я решил назвать их поэтично - ОЧКИ ИСТОРИЙ.

5. Чтобы планирование протекало в интерактивном режиме и люди могли оценивать задачи независимо друг от друга можно нанести ОЧКИ ИСТОРИЙ на карты и дать этой игре говорящее название, например ПРЕФЕРАНС ПЛАНИРОВАНИЯ.

6. В конце каждого забега команде полезно собраться и обсудить свои проблемы с целью выработки эффективного решения хотя бы одной из них, такие встречи можно было бы назвать РАЗБОР ПОЛЕТОВ.

Также опционально доступна возможность использования таких ролей в команде, как ВЛАДЕЛЕЦ ПРОДУКТА и МАСТЕР ЗДРАВОГО СМЫСЛА.

Внедряйте методологию ЗДРАВЫЙ СМЫСЛ в своих проектах!

Урбика в партнёрстве с Greenpeace Russia перезапускает карту раздельного сбора мусора: https://beta.recyclemap.ru/.

«Recyclemap часто становится точкой входа в тему защиты окружающей среды: это самый популярный онлайн-проект Greenpeace в России. Мы создавали инструмент, который станет проводником в новый вопрос, и проектировали новый продукт с добротой и заботой. Делая продукт понятнее и проще, мы снижаем порог входа и расширяем сообщество осознанных потребителей.»