S0ER

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

Как же надоели эти "словоплеты", которые работают по шаблону "вам этого не нужно". Может быть я сам знаю, что мне нужно, а что нет? Если есть хороший пример (в чем я сильно сомневаюсь), то расскажи, а не вот это все про "я такой гуру сейчас тебе все объясню". https://youtu.be/x5mod9gyKmY?si=9cgL7gFNv2RdINdz

Попытка взять с комьюнити больше денег у Unity не получилась, ребята вовремя одамались и дали заднюю - https://blog.unity.com/news/open-letter-on-runtime-fee На мой взгляд Unity - это крутой движок, который используется не только для игр, но и для визуализации разного рода исследований в ai. И его прелесть как раз в разумной политике оплаты, не надо ничего ломать.

Запускаю сбор тем на субботний стрим. - задавайте в комментах вопросы на ЗЭН - давайте ссылки на свое репо для ревью - кидайте интересные новости и темы для обсуждений

Интересный вчера получился разговор. Много говорили про физическое и логическое время. Понимание того, что время - это весьма условная штука, позволяет лучше понять понятия согласованности и синхронизации данных. Особенно клёво, что вспомнили часы Лэмпорта. Эта тема в свое время сильно меня зацепила. Спасибо ребятам за интересный диалог. Рекомендую посмотреть стрим в записи, ссылка постом выше.

Зачем собирать софт из исходников Если откинуть факт того, что мое привзвание совпадает с моей профессией и мне просто интересно собирать софт из исходников, то вторая причина - это поддержка когнетивной гибкости. Решая привычные рутинные задачи очень быстро скатываешься в регидность, а мне этого не хочется. С точки зрения "пользы", сборка из исходников помогает в следующих вопросах: - получение информации об архитектуре программы, понимание функционального разеделения обязанностей, понимание технической реализации и т.д. Сборка OBS помогла мне лучше понять как работает приложение - это кайф; - автоматизация и более глубокое понимание инструментов сборки, форматов исполняемых файлов, работы библиотек и т.д. - оптимизация софта под себя, например, в OBS я выкидываю ALSA, убираю DeckLink, ставлю другой аудикодер, убираю Python скриптинг (отавляю только Lua) и т.д. - добавление отладочной информации, обычно в репо лежат оптимизированные сборки, в сборке с отладочной инфой можно легко дебажить ошибки, которые в том же OBS случаются довольно часто, так я смог подобрать более "горманичную" сборку, которая меньше валится - работа с гитом, в том же OBS юзаются сабмодули, и это боль когда нужно собрать какую-то специфичную версию OBS (например, не ночную сборку, а стабильный релиз) - работа с версионированием и организацией работы OpenSource, это очень полезный опыт - смотреть как работает сообщество, как выпускаются новые релизы, как в целом вся эта кухня крутится. В общем, сборка из исходников - это как подтягивание, базовое упражнение для любого соера.

Сборка из исходников - это прекрасно Есть две вещи, которые должны пугать вас больше всего на свете - обновление операционной системы и сборка из исходников программного обеспечения. Каждый раз, после очередного обновления, я узнаю что-то новое о себе, своих зависимостях и о том почему айтишники самые бессердечные люди на свете. Сегодня у меня на десктопном линуксе сломалась OBS Studio, которую я собираю из исходников. Так как совсем недавно я менял видео карту, то я связал эти два события вместе. Даже не берусь подсчитать сколько раз переустановил бедные драйвера от Nvidia, пока не доагадался, что неплохо бы почитать логи (логи всегда нужно "почитать" - это источник знаний обо всем сущем вокруг вас). После чтения логово я хлопнул себя по лбу со словами "Иван Иваныч...". Потому что понял, что nvidia совсем не при чем, а я долблюсь головой о стену, вместо того, чтобы просто подумать. На причину проблему меня натолкнула следующая строка в логе "libmbedcrypto.so.7: невозможно открыть разделяемый объектный файл". На самом деле тут все просто - некоторые библиотеки в системе собираются из AUR с использованием исходников, если какая-то библиотека собралась, а потом произошло обновление системы, то надо пересобрать все зависимые библиотеки, иначе поплывут зависимости. В данном случае проблемной была библиотека RIST, для которой и нужен libmbedcrypto, а эта библиотека в свою очередь нужна для OBS. Найти библиотеку, которая зависит от libmbedcrypto самая сложная задача, но она легко решается благодаря интернету. Ну а дальше дело техники - пересобираем RIST, пересобираем OBS и все работает like a charm... А Nvidia тут не при чем.

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

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

Принласили на канал "между скобок" будем обсуждать главу из книги Distributed Systems (4th edition) by Maarten Van Steen, Andrew S. Tanenbaum https://www.youtube.com/live/Y8AKctQSsg0?si=RbSHOUen7-NJObd

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

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

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

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

Знай свои активы и умей их применять Под активами я понимаю любые ресурсы, которые можно прямо или косвенно превратить в деньги. А деньги - это универсальное мерило всего материального (и нематериального тоже. кстати). Я до недавнего время не очень понимал какими ресурсами располагаю. Нет, я понимал, что могу работать, делать проекты, оказывать консультации, но не понимал, что все мои ресурсы сводились к выполнению работы на кого-то. Т.е. не создавал активы от слова "совсем". Для меня главным моим ресурсом были мои знания. Но я их использовал не самым эффективным способом, потому что работа, которую я выполнял, не масштабировалась и не приводила к созданию активов. Чтобы знания стали масштабируемым ресурсом их надо преобразовывать в продукты, а не работу. А вот продукт уже можно мастштабировать и монетизировать. Кроме знаний у меня оказался еще один замечательный ресурс, который я не использовал - медийность. Этот ресурс появился благодаря каналам и блогам, которые я не воспринимал всерьез, потому что не особо собирал обратную связь, а потом оказалось, что мои видео смотрят и обсуждают очень крутые ребята. Вывод из этой истории такой: - нужно использовать знания не для работы, а для создания продуктов - нужно использовать не только очевидные ресурсы, но и искать те о которых ты не подозреваешь (для этого надо активно смотреть вокруг, а не замыкаться в себе любимом) - нужно нетворкатся и не бояться высказывать свое мнение Мысль капитанская, все это знают, но кто использует? Напишите в комментах какие ресурсы вы превратили в активы, а какие висят на вас тяжким грузом )

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