Когнитивные измерения

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

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

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

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

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

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

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

Последние 10% задачи стоят первых 90% или проблема приближения к цели.

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

В случае с созданием новых фич работает примерно так же, позади уже 90% работы, есть небольшая усталость, но хочется доделать, сделав "рывок".

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

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

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

Закрывать фичу всегда на свежую голову, еще раз окинув взглядом сделанное.

И тогда все будет хорошо, без рывков и выгораний.

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

Заметил, что в пятницу мало активности и в кружочках. Видимо, не я один такой "уставший". Так что всех у кого была продуктивная неделя - "С пятницей!". Отдыхаем, восстанавливаем силы для новых свершений.

Что предпочтет настоящий соер в качестве отдыха? Конечно же лучший способ расслабиться и отдохнуть - это непринужденное чтиво перед сном. Очень хорошо подходят мануалы и спецификации.

Я, например, читаю спеку на EcmaScript - это очень расслабляет и гарантирует глубокий, спокойный сон.

Фрагментация времени

Я в последнее время постоянно пытаюсь придумать как дефрагментировать свое свободное время. Получается так, что у меня то тут, то там есть по 15-20 минут свободного времени, в течение дня это может быть пара часов, которые можно было бы использовать для чего-то осмысленного.

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

Чего скажите, утопия или все же планирование может помочь?

Сэкономленные деньги !== заработанные

Ради фана посчитали сколько денег потребуется компании на свободном рынке, чтобы построить продукт уровня Naris.

В качестве целевых показателей взяли:
- процесс разработки;
- архитектура;
- разработка и сопровождение.

Получилось, что на сегодняшний день Naris стоит примерно 20 млн. рублей.

Основная статья затрат - заработная плата. Если ты сам являешься человеком-оркестром, то можно сильно сэкономить.

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

В такие моменты остается лишь сожалеть, что нельзя сэкономленные деньги взять налом.

Внеочередной стрим https://youtube.com/live/Uf2s7kDWM38?feature=share

Найди всех соеров на фото и напиши в комментариях сколько их.

Upd. Ну вы блин даете... Там на экране ноута скрин с моим интервью у Котелова... Статья тут не при чем.

Источник: https://t.iss.one/kotelov_love/653

Скриптинг

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

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

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

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

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

Для "дев" режимов, скритинг используется в плагинах разработчика (например, DevTools от ангуляра используют точки подключения через DOM). Можно писать свои собственные плагины, которые позволяют визуализировать стейт приложения или делать отладку. В свое время Ден Абрамов делал плагин для демонстрации возможностей Redux (Time Machine).

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

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

#знания #мысли

Формирование привычек

"Скажи мне какие твои привычки и я скажу тебе кто ты" - я бы так перефразировал известное утверждение. Давно обратил внимание, что целей добиваются не самые упорные или мотивированные, а те кто упорядочил свою жизнь, приведя ее в гармонию со своими целями. Рекомендую посмотреть главу книги "Движение короткими шагами" (https://platform.soer.pro/#!/pages/book) там я более полно разворачиваю эту мысль.

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

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

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

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

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

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

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

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

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

План дело хорошее, но там есть разочарование если что-то не сделал, типа "должен", а в случае с привычкой ну не сделал и не сделал.

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


#мысли

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

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

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

При этом автору видео респект, это не её вина вина, что индустрия буксует не в том направлении.

https://youtu.be/WoqrUn-0usA?si=h5mrjOEWv5mu2b2G

Леша делится опытом о том почему делиться опытом - это круто. Я считаю, что делится опытом не только круто, но единственно правильно. А еще очень важно всегда работать над собой и качать хардскилы!
Смотрим и наслаждаемся - https://www.youtube.com/watch?v=qod9Xgp6Sps

Запись стрима: "Как бороться с синдромом самозванца"
RuTube | VK

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

Теорема аппроксимации

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

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

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

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

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

Из всего сказанного нужно сделать три важных вывода:
- нейронные сети с одним внутренним слоем вполне способны решать большую часть задач;
- проблема одного внутреннего слоя - сложность обучения;
- архитектура нейронной сети позволяет упростить процесс обучения и лишь в некоторых случаях добавляет "мощность" для решения задачи.

#теория #нейронки

Знай свои активы и умей их применять

Под активами я понимаю любые ресурсы, которые можно прямо или косвенно превратить в деньги. А деньги - это универсальное мерило всего материального (и нематериального тоже. кстати).

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

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

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

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

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

Мысль капитанская, все это знают, но кто использует? Напишите в комментах какие ресурсы вы превратили в активы, а какие висят на вас тяжким грузом )

Завышенные ожидания от архитетуры

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

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

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

Спустя время, конечно, приходит осознание как много сделано, и как на самом деле все работает. Но если хочется "сразу", то ничего не получится.

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

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

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

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

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

Дима, который SSV, забанил меня в своём телеговском чате. Никогда такого не было и вот опять.

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

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

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

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

В общем, встречайте - NarisApp новое название проекта.

NarisApp - это обучающий проект, в котором все процессы выстроены по-взрослому, а заявку на участие может подать каждый желающий. Самая большая ценность участия - это глубокое ревью кода, иногда очень глубокое.
Само приложение - это информационная платформа с элементами обучения. Как раз NarisApp я использую на platform.soer.pro