S0ER

В воскресенье в Питере в баре "Время N" будет выступление группы Эргот - https://vk.com/ergoth_23 Так как мне доктор прописал power метал на ночь, для укрепления здоровья и бодрости духа, а еще потому что выступать будет Ден, я решил что славный город навещу, пару денечков погощу. Так что если есть желание, то подтягивайтесь. И да, в субботу стрима не будет )

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

Суббота 10:00 по Мск. Субботний стрим от Соера https://youtube.com/live/uP10jWlREEc?feature=share

Про корректное сравнение Самое сложное в анализе - это научиться правильно сравнивать. Большая часть программистов любит сравнить тёплое с мягким и в итоге получить вывод, который не имеет ничего общего с объективностью. Сейчас очень много заявлений по типу "нейросеть никогда не заменит ххх", под ххх понимается любая специальность на ваш вкус. При этом критерием сравнения выступает потенциальная сложность некоторых задач, но это некорректное сравнение. Правильное сравнение, в данном случае, это некий модифицированный тест тьюринга. Нужно фокус группе предлагать принять работу из двух вариантов, где один сделал человек, другую нейронка. Имея срез таких выборок по разным задачам, можно понять насколько нейросеть готова заменить человека на данный момент. А имея исторический срез можно легко проследить тренд. Судя по реакции общественности, тренд явно не в пользу человека. Но это неточно.

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

Про конспекты Мои опыт заключается в том, что лучше писать тематические конспекты, по разным темам, чем конспекты по книгам. Например, лучше завести конспект по шаблонам проектирования и дополнять туда мысли из разных источников (со ссылкой на источник), чем прочитать три книги по шаблонам и по каждой книге зафиксировать свои мысли. Я люблю конспекты. У меня по всем архитектурным стримам есть конспект (посмотреть можно вот тут - https://s0er.ru/workbook ), и в Naris я тоже стараюсь продвигать идею создания своей базы конспектов. Потому что ведение конспектов способствует развитию мышления и умения выделять главное. Это очень помогает в работе программиста, особенно в анализе и проектировании. #мысли

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

Выложил mp3 запись стрима в Яндекс.Музыке. Не уверен, что это удачное решение - выкладывать аудио-дорожку стрима. Что скажите, делать так или не стоит?

Еще одна попытка начать писать подкасты или хотя бы выкладывать аудио дорожки стримов. https://music.yandex.ru/album/11685869

Эмерджентность Эмерджентность или эмергентность в теории систем — наличие у системы свойств, не присущих её компонентам по отдельности; несводимость свойств системы к сумме свойств её компонентов. Хорошее слово, которое хрен выговоришь, но теперь, в связи со страшилками вокруг AI, нужно экстренно его учить и использовать в речи. ChatGPT продемонстрировал удивительную эмерджентность, нужно признать, что по факту ожидания были куда скромнее. А сейчас и код пиши, и рецепты для домохозяйки, и умные тексты для новостей. Вот такие чудеса.

Требования на разработку ПО Существует классическое разделение на три уровня требований: - Бизнес требования - Пользовательские требования - Проектные требования Эти требования обрабатывает бизнес-аналитик, для этого он должен напрямую общаться с пользователями и заказчиками софта. Бизнес требования Это требования которые бизнес хочет удовлетворить в результате разработки программного обеспечения. Обычно эти требования выражаются в виде задач и целей (вспоминаем про тактическое и стратегическое планирование). Не видел программистов, которые бы вникали в бизнес требования, с ними в основном работают аналитики и архитекторы. И это та еще головная боль, потому что сильно оторвана от технической стороны вопроса. Пользовательские требования Это то что от системы хотят получить пользователи. Они выражаются в вариантах использования и пользовательских историях. Тут надо не путать с "вариантами использования", которые есть в чистой архитектуре Роберта Мартина, там это чисто технические решения, здесь это описание взаимодействия действующего лица и системы. Пользовательские истории в обязательном порядке доводятся до программистов, так как это способствует погружению в задачу и обеспечивает лучшее понимание проблемы. Проектные требования Это те самые функциональные и нефункциональные требования, которые предъявляются непосредственно к разрабатываемому софту. Чтобы не запутаться нужно помнить, что функциональные требования - это требования, которые описывают поведение сисетмы и обычно начинаются со слова "должен" или "должна". Нефункциональные требования описывают свойства системы, и обычно их называют "-илити свойства" (contrability, scalability и т.д.). Так же функциональные и нефункциональные требования могут быть сделаны на уровне "частных решений", которые разрабатывают архитекторы, работающие на уровне кода или сами программисты. Там немного другие особенности, так к нефункциональным требованиям удобно относить инфраструктурные зависимости, которые неудобно содержат в функциональной части, так как это нарушает уровни абстракции, использующиеся в проектировании. #мысли #теория

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

Выложил старое видео "Нужны ли пет-проекты программисту": RuTube | VK Если нужно еще какие-то старые видосы выложить, то пишите в комментарии.

Ох уж эти программерские будни...

Один из исследователей описал ключи активации Win95 для ChatGPT, а тот недолго думая создал ему нужные ключи. Оказалось, что 1 из 30 ключей, созданных AI, активировал win95. Проблема возникла в том, что ChatGPT не умеет проверять некоторые математические ограничения, наложенные на ключи. Прекрасно то, что ChatGPT не признал факт генерации ключей, да и кто его посадит? Он же памятник! ) https://xakep.ru/2023/04/03/chatgpt-win95/

Структуры кода и данных Структурное представление кода основано на Теореме Бёма — Якопини, они доказали, что любой исполнимый алгоритм может быть представлен в виде трех структур: - последовательность - ветвление - повторение (циклы) структурный подход упростил доказательство корректности кода, и позже Дейкстра очень сильно критиковал подходы, которые включали в себя безусловные переходы с использованием goto, одна из причин - это разрушает структуру кода и усложняет доказательство корректности. Понимание того, что код - это структура позволило абстрагироваться от кода и сосредточиться на взаимодействии (логике), так появилась архитектура на уровне кода и элементарное разбиение на подпрограммы (функции), а в дальнейшем стало основой развития парадигм программирования. С точки зрения данных, структуры показывают способы организаци и взаимодействия информации. К простым структурам принято относить списки, деревья, массивы и тому подобные вещи. Интересно, что структуры отображать абстрактно, например в виде схем, то структуры кода во многом похожи на структуры данных, поэтому можно говорить, что в компьютере все есть данные и код, и пользовательская информация. Это хорошо видно на моделях организации памяти, там сегменты разделены условно, и данные от кода "на глаз" не отличить. Грамотный специалист должен понимать, что обсуждение "структуры кода" - это разговор про архитектуру, а обсуждение структуры данных - это про моделирование и хранение информации.

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