Поучаствовал в дискуссии на Линкидин с одной участницей, которая написала пост про "Не верю людям, которые говорят, что работают по 8 часов в день - проверено собственным опытом и у меня так никогда не получается".
Там было упущено сразу два важных момента:
1) если ты никогда не работал по 8 и более часов в день, то для тебя действительно такая нагрузка является неподъемной. Это как прийти в спортзал и в первый день пытаться жать сотку, если ранее даже гантели десятки не пробовал поднимать. К нагрузкам нужно постепенно привыкать. Если бы авторка поста как я одновременно ходила в обычную школу и музыкальную, после занятий ездила работать на дачу и перед сном помимо уроков успевала читать интересные книги, то просто не существовало вопроса о непосильной сложности 8 часов кликать мышкой.
2) нельзя ничего мерять по своим силам и даже по силам своего окружения. Ведь так можно сказать, что все олимпийский призеры на допинге, ведь ты без допинга не сможешь достичь тех же результатов (да и допингом тоже не сможешь - значит все состязания подстроены). Если у тебя вдохновения хватает лишь написать парочку постов в интернете, так значит все эти Гюго, Дюма, Джеки Лондоны и Стивены Кинги на самом деле тоже не писали свои романы, а нанимали армии литературных рабов для титанического труда в сотню страниц.
Там было упущено сразу два важных момента:
1) если ты никогда не работал по 8 и более часов в день, то для тебя действительно такая нагрузка является неподъемной. Это как прийти в спортзал и в первый день пытаться жать сотку, если ранее даже гантели десятки не пробовал поднимать. К нагрузкам нужно постепенно привыкать. Если бы авторка поста как я одновременно ходила в обычную школу и музыкальную, после занятий ездила работать на дачу и перед сном помимо уроков успевала читать интересные книги, то просто не существовало вопроса о непосильной сложности 8 часов кликать мышкой.
2) нельзя ничего мерять по своим силам и даже по силам своего окружения. Ведь так можно сказать, что все олимпийский призеры на допинге, ведь ты без допинга не сможешь достичь тех же результатов (да и допингом тоже не сможешь - значит все состязания подстроены). Если у тебя вдохновения хватает лишь написать парочку постов в интернете, так значит все эти Гюго, Дюма, Джеки Лондоны и Стивены Кинги на самом деле тоже не писали свои романы, а нанимали армии литературных рабов для титанического труда в сотню страниц.
👍8👏1
Журнал инженера-программиста
Понемногу уже буду возвращаться. Клубок жизненных событий понемногу распутывается, а окружающий мир не стоит на месте и продолжает удивлять.
Зафиксирую текущие события:
1) Теща все никак не может оформить компенсацию за разрушенную квартиру. В день прихода комиссии (для фиксации степени ущерба) она закрыла свою торговую точку и половину дня прождала их визит. А когда вернулась на работу, то ей ближе к вечеру позвонили, что те готовы к ней прийти (но она бы просто не успела приехать).
В следующий раз такой накладки не будет, так как сегодня ночью во время самого массовой баллистической атаки (41 ракета в течении 40 минут) ее торговую точку сравняло с землей и она теперь снова безработная и может ждать комиссию в любое время.
2) Похоже, что мы зря делали операцию нашей кошке. Хотя все прошло хорошо и шов отлично зажил, но у нее начались проблемы с легкими - там оказались метастазы, которые разрушали легочную ткань. Дважды мы носили ее на дренаж жидкости, но она в конце-концов стала отказываться от еды и почти не пила. В этот понедельник мы с нею попрощались, а уже в четверг забрали с Новой Почти урну с ее прахом.
3) Моя отсрочка от призыва вернулась в Резерв+ и вероятность стать учасником "бусификации" стала существенно ниже (хотя в наше время ни от чего нельзя зарекаться).
4) Пока ми последние недели мучились с нашей кошкой, то сталкивались в ветклиниках с проблемой мобилизованных ветврачей. Даже в последний день, когда мы обзванивали службы ритуальных услуг для питомцев, мы далеко не сразу нашли тех, кто к нам приедет - часть телефонов была отключена, у некоторых было объявление, что в связи с мобилизацией всех сотрудников услуги прекращены до окончания войны.
5) Мои анализы существенно не изменились и все далеки от нормы, но имеют тенденцию к стабилизации. Например тромбоциты (норма 150-400) в течении месяца у меня по чуть-чуть уменьшаются: 723 -> 702 -> 667. Всего 10 показателей далеки от нормы. Даже если я месяц ел фальсификат вместо лекарств, то последствия хотя бы обратимы.
#войнаимир #offline #irl
Зафиксирую текущие события:
1) Теща все никак не может оформить компенсацию за разрушенную квартиру. В день прихода комиссии (для фиксации степени ущерба) она закрыла свою торговую точку и половину дня прождала их визит. А когда вернулась на работу, то ей ближе к вечеру позвонили, что те готовы к ней прийти (но она бы просто не успела приехать).
В следующий раз такой накладки не будет, так как сегодня ночью во время самого массовой баллистической атаки (41 ракета в течении 40 минут) ее торговую точку сравняло с землей и она теперь снова безработная и может ждать комиссию в любое время.
2) Похоже, что мы зря делали операцию нашей кошке. Хотя все прошло хорошо и шов отлично зажил, но у нее начались проблемы с легкими - там оказались метастазы, которые разрушали легочную ткань. Дважды мы носили ее на дренаж жидкости, но она в конце-концов стала отказываться от еды и почти не пила. В этот понедельник мы с нею попрощались, а уже в четверг забрали с Новой Почти урну с ее прахом.
3) Моя отсрочка от призыва вернулась в Резерв+ и вероятность стать учасником "бусификации" стала существенно ниже (хотя в наше время ни от чего нельзя зарекаться).
4) Пока ми последние недели мучились с нашей кошкой, то сталкивались в ветклиниках с проблемой мобилизованных ветврачей. Даже в последний день, когда мы обзванивали службы ритуальных услуг для питомцев, мы далеко не сразу нашли тех, кто к нам приедет - часть телефонов была отключена, у некоторых было объявление, что в связи с мобилизацией всех сотрудников услуги прекращены до окончания войны.
5) Мои анализы существенно не изменились и все далеки от нормы, но имеют тенденцию к стабилизации. Например тромбоциты (норма 150-400) в течении месяца у меня по чуть-чуть уменьшаются: 723 -> 702 -> 667. Всего 10 показателей далеки от нормы. Даже если я месяц ел фальсификат вместо лекарств, то последствия хотя бы обратимы.
#войнаимир #offline #irl
💔8❤4🙏3
This media is not supported in your browser
VIEW IN TELEGRAM
Захожу уже перед сном в комнату, включаю свет и краем глаза фиксирую быстрое движение по клавиатуре в сторону системника. Подсвечиваю туда фонариком и в ответ вижу перепуганные глаза-бусинки. Ловким движением руки мышонок был пойман в коробочку и уже через 5 минут выпущен на клумбу рядом с домом.
Это прямо флешбек из детства из 90х. Тогда я вечером зашел на кухню и увидел движение мини-чупакабры по кухонному столе в направлении плиты. Это был первый контакт с "подвальными беженцами", после которого мы часто видели мышей в нашей квартире и даже применяли мышеловки, чтобы переловить почти два десятка незваных гостей.
В детстве мыши забирались к нам в квартиру на третий этаж по вентиляции. Сейчас я живу значительно выше (можно задолбаться подниматься по лестнице, когда лифты не работают) и у меня вопросики к тому как этот мелкий мышонок умудрился к нам забраться - тоже по вентиляции (почему не остался на кухне с продуктами) или через открытое окно (как раз рядом со столом с компом)? Как вообще этот слабый юнец справился с такой тяжелой дорогой и почему не вышел у соседей на нижних этажах? Или он спускался с крыши? Путь вниз действительно намного короче и легче, но как он тогда попал на крышу?
#offline #irl
Это прямо флешбек из детства из 90х. Тогда я вечером зашел на кухню и увидел движение мини-чупакабры по кухонному столе в направлении плиты. Это был первый контакт с "подвальными беженцами", после которого мы часто видели мышей в нашей квартире и даже применяли мышеловки, чтобы переловить почти два десятка незваных гостей.
В детстве мыши забирались к нам в квартиру на третий этаж по вентиляции. Сейчас я живу значительно выше (можно задолбаться подниматься по лестнице, когда лифты не работают) и у меня вопросики к тому как этот мелкий мышонок умудрился к нам забраться - тоже по вентиляции (почему не остался на кухне с продуктами) или через открытое окно (как раз рядом со столом с компом)? Как вообще этот слабый юнец справился с такой тяжелой дорогой и почему не вышел у соседей на нижних этажах? Или он спускался с крыши? Путь вниз действительно намного короче и легче, но как он тогда попал на крышу?
#offline #irl
❤7
У Сергея Сыпачева вышло очередное вдохновляющее интервью - Конец эпохи 1С? Один промт — и готовая конфигурация за вечер
Рекомендую посмотреть, если кто-то живет в иллюзии, что ИИ все еще где-то там далеко и до сих пор не применимо в реальной работе. Тут человек, который далек от команды разработчиков платформы 1С и не обладающий их закрытой документацией, всего за один вечер в рамках лимитов недорогой подписки сделал упрощенный аналог платформы 1С, а потом по вечерам в один промпт делал портирование своих старых 1С-конфигураций на новую платформу. И это не просто работоспособно, но уже используется реальными людьми в реальном бизнесе!!!
Большой вопрос - почему, обладая мощью современных американских и китайских моделей, оригинальная команда 1С сидит ровно на попе и не закрывают тысячами открытые проблемы из багтрекера? Почему до сих пор прикрываются бутылочным горлышком "ручной обработки" пользовательских запросов и воздерживаются от требуемых правок платформы, когда рутину можно делегировать машинам?
#1С #ИИ #AI
Рекомендую посмотреть, если кто-то живет в иллюзии, что ИИ все еще где-то там далеко и до сих пор не применимо в реальной работе. Тут человек, который далек от команды разработчиков платформы 1С и не обладающий их закрытой документацией, всего за один вечер в рамках лимитов недорогой подписки сделал упрощенный аналог платформы 1С, а потом по вечерам в один промпт делал портирование своих старых 1С-конфигураций на новую платформу. И это не просто работоспособно, но уже используется реальными людьми в реальном бизнесе!!!
Большой вопрос - почему, обладая мощью современных американских и китайских моделей, оригинальная команда 1С сидит ровно на попе и не закрывают тысячами открытые проблемы из багтрекера? Почему до сих пор прикрываются бутылочным горлышком "ручной обработки" пользовательских запросов и воздерживаются от требуемых правок платформы, когда рутину можно делегировать машинам?
#1С #ИИ #AI
👍3🔥3
Не угадаете где я сегодня был и сделал этот кадр.
Нет не в компьютерном городе 🤓
Это был блошиный рынок, который собирается каждое воскресенье в парке имени Ивана Франка в Хмельницком. Нигде и никогда (даже в Киеве) я не видел настолько огромную барахолку.
Такое ощущение, что это одновременно филиал Петровки (старые книги, виниловые диски), Кардач (радиотехника, старые фотики и мобилки), Нивок (монеты и медали) и Андреевки (картины, бусы, керамика). Ощущение музея под открытым небом - униформа различных служб и их же служебные удостоверения, рядом боевые топоры и мечи, далее швейные Зингеры и прочие прялки, за которыми бесконечные альбомы с марками и значками, после которых ряды столового серебра. Продавцы музыкальных инструментов тут же дают живой концерт на своих баянах и барабанах. Ящики со старыми игрушками, среди которых Трансформеры, Барби и даже Тетрис. Финалочкой легендарный графинный набор "Рыбки" )))
Это просто нескончаемый набор идей и реквизита для художников, фотографов и режиссёров. И хоть я всего лишь простой программист, но даже я проникся духом этих артифактов истории. Нужно будет еще заглянуть, раз я тут задержался.
#offline #irl
Это был блошиный рынок, который собирается каждое воскресенье в парке имени Ивана Франка в Хмельницком. Нигде и никогда (даже в Киеве) я не видел настолько огромную барахолку.
Такое ощущение, что это одновременно филиал Петровки (старые книги, виниловые диски), Кардач (радиотехника, старые фотики и мобилки), Нивок (монеты и медали) и Андреевки (картины, бусы, керамика). Ощущение музея под открытым небом - униформа различных служб и их же служебные удостоверения, рядом боевые топоры и мечи, далее швейные Зингеры и прочие прялки, за которыми бесконечные альбомы с марками и значками, после которых ряды столового серебра. Продавцы музыкальных инструментов тут же дают живой концерт на своих баянах и барабанах. Ящики со старыми игрушками, среди которых Трансформеры, Барби и даже Тетрис. Финалочкой легендарный графинный набор "Рыбки" )))
Это просто нескончаемый набор идей и реквизита для художников, фотографов и режиссёров. И хоть я всего лишь простой программист, но даже я проникся духом этих артифактов истории. Нужно будет еще заглянуть, раз я тут задержался.
#offline #irl
1👍11
После вчерашнего поста кто-то обрадовался, что не смотря на регулярную баллистику по Киеву я все еще жив, кто-то получил возможность вспомнить легендарные книги о компьютерах из 90х, а кто-то видимо удивился наличию моего канала в подписках и отписался...
Но по настоящему интересным моментом прошлого поста был вопрос: почему я в Хмельницком???
Если честно, то понимаю отписавшихся - самому не очень хотелось пост за постом писать о том, что я жив, и снова жив, и в этот раз снова жив... И, не смотря на довольно любопытный опыт одной ночи в метро, где мы на платформе станции пережидали обстрел с несколькими тысячами других перепуганных киевлян, я не хотел превращать свой блог в военные хроники. Не хотелось все время примерять на себя роль "жертвы" вместо "исследователя" и вызывать жалость вместо восхищения дивным новым цифровым миром.
В связи с усилением обстрелов Киева баллистикой, от которой не умеет смысля прятаться и которая уничтожает цель в течении минуты после объявления тревоги (а иногда и вовсе без тревоги), в связи с анонсами скорого применения "Орешника" и заявление о вероятности использования ТЯО, а так же в связи с признанием руководства страны и столицы о неготовности встретить зиму, мы на семейном совете решили начать беречь нервы и сменить место пребывания на более мирную локацию.
Повторно ехать на западную границу желания не было - хватило опыта весны-лета 2022 года, когда пользуясь статусом "тыла" местные барыги обдирали нас и других беженцев (да и сейчас цены во Львове и Ужгороде даже выше чем в Киеве). Мы начали рассматривать Черновцы, но хорошей идеей показался и исторический регион Каменца-Подольского в Хмельницкой области, где местные замки и музеи не дали бы нам скучать.
Трястись полдня в автобусе до Каменца не хотелось, а билеты на поезда были раскуплены на месяц вперед. Когда мы стали рассматривать альтернативные маршруты, то обнаружили, что в Хмельницкий, как в областной центр, едет намного больше поездов и билеты доступны каждый день. А уже с Хмельницкого в Каменец есть уже местные электрички и автобусные маршруты. Более того, оказалось что даже есть полупустая комфортная скоростная электричка, которая ежедневно утром выезжает из Киева, в обед уже в Хмельницком, а потом вечером снова в Киеве.
Вот так мы попали в Хмельницкий, который своей расслабленной мирной и почти праздничной атмосферой настолько нас к себе расположил, что мы решили отменить все дальнейшие планы и перезимовать именно тут. Тем более что мы сняли отличную комфортную квартирку в пешей доступности от жд-вокзала и при необходимости время между "выйти из хмельницкой квартиры" и "зайти в киевскую квартиру" займет не более 6 часов со всеми пересадками.
#offline #irl
Но по настоящему интересным моментом прошлого поста был вопрос: почему я в Хмельницком???
Если честно, то понимаю отписавшихся - самому не очень хотелось пост за постом писать о том, что я жив, и снова жив, и в этот раз снова жив... И, не смотря на довольно любопытный опыт одной ночи в метро, где мы на платформе станции пережидали обстрел с несколькими тысячами других перепуганных киевлян, я не хотел превращать свой блог в военные хроники. Не хотелось все время примерять на себя роль "жертвы" вместо "исследователя" и вызывать жалость вместо восхищения дивным новым цифровым миром.
В связи с усилением обстрелов Киева баллистикой, от которой не умеет смысля прятаться и которая уничтожает цель в течении минуты после объявления тревоги (а иногда и вовсе без тревоги), в связи с анонсами скорого применения "Орешника" и заявление о вероятности использования ТЯО, а так же в связи с признанием руководства страны и столицы о неготовности встретить зиму, мы на семейном совете решили начать беречь нервы и сменить место пребывания на более мирную локацию.
Повторно ехать на западную границу желания не было - хватило опыта весны-лета 2022 года, когда пользуясь статусом "тыла" местные барыги обдирали нас и других беженцев (да и сейчас цены во Львове и Ужгороде даже выше чем в Киеве). Мы начали рассматривать Черновцы, но хорошей идеей показался и исторический регион Каменца-Подольского в Хмельницкой области, где местные замки и музеи не дали бы нам скучать.
Трястись полдня в автобусе до Каменца не хотелось, а билеты на поезда были раскуплены на месяц вперед. Когда мы стали рассматривать альтернативные маршруты, то обнаружили, что в Хмельницкий, как в областной центр, едет намного больше поездов и билеты доступны каждый день. А уже с Хмельницкого в Каменец есть уже местные электрички и автобусные маршруты. Более того, оказалось что даже есть полупустая комфортная скоростная электричка, которая ежедневно утром выезжает из Киева, в обед уже в Хмельницком, а потом вечером снова в Киеве.
Вот так мы попали в Хмельницкий, который своей расслабленной мирной и почти праздничной атмосферой настолько нас к себе расположил, что мы решили отменить все дальнейшие планы и перезимовать именно тут. Тем более что мы сняли отличную комфортную квартирку в пешей доступности от жд-вокзала и при необходимости время между "выйти из хмельницкой квартиры" и "зайти в киевскую квартиру" займет не более 6 часов со всеми пересадками.
#offline #irl
10👍12❤7
Хочу рассказать чем закончилось мое знакомство с концепцией Zettelkasten (она же "второй мозг"). Но сперва хотел бы подсветить причину своего интереса - отсутствие эффективной системы хранения информации.
Я - обычный человек, который не обладает ни скорочтением, ни фотографической памятью, ни прочими тайными суперсилами обладателей кубков ЧГК. А следовательно вокруг всегда намного больше материалов, которые я хотел бы изучить, чем времени на изучение. Да что там "изучить" - иногда не хватает времени даже просто бегло ознакомится.
Ранее я пользовался первыми сервисами закладок - удобная вещь, ведь можно иметь доступ к своим спискам сохраненного с дома, с университета, с работы или с компьютерного клуба. Потом появился Google Chrome, который помимо удобной эргономики и скорости работы удивил возможностью централизированной синхронизации данных профилей - я постарался перетащить сюда ранее сохраненные материалы.
Но с ссылками было несколько проблем: 1) для их чтения все равно нужно было выделять время, 2) теперь нужно было выделять время на просмотр кучи ссылок и выбор "чего бы почитать", 3) материал по ссылкам перемещался или удалялся. Последнее вообще обидно, так как в разделе изучения иностранных языков у меня до сих пор десятки ссылок на интересные материалы на форуме Duolingo, который закрыли более десяти лет назад (((
Раз ссылки показали себя не очень хорошо, то я решил сохранять статьи полностью. Начал с программы, которая была на каждом компьютере - Microsoft OneNote, и у которой были инструменты сохранения фрагментов прямо с сайтов. Помню, что у меня так накопилась большая подшивка полезных материалов, которую я иногда даже просматривал. Но я вел хранение не очень системно и там быстро образовалась свалка.
Как раз появился мегапопулярный Evernote и я решил начать с чистого листа. На этот раз я сделал разделы, а к сохраняемым материалам добавлял теги. Но развитие инструмента пошло куда-то не туда и разработчики стали агресивно требовать оформить подписку на свой сервис. В результате после очередной переустановки системы на ноуте я даже не стал заново ставить Evernote и обошелся только просмотром веб-версии.
Дальше начался настоящих хаос, частично спровоцированный наличием у популярных соцсетей своих мобильных приложений, из которых трудно или невозможно сохранить прямую ссылку на страницу - у меня стали копится сохраненные закладки в фейсбуке, твиттере, линкедине, инстаграме, тредсе и так далее. Иногда я пользовался функцией "Поделится" для сохранения ссылки - скидывал в сохранения в Телеграмм, в результате чего свалка стала образовываться уже и в Телеграмме, где я паралельно сохранял интересные сообщения из групповых чатов и из каналов.
В конце-концов я просто перестал сохранять ссылки, раз я их вообще не читаю. Я просто в браузере стал держать открытыми закладками страницы, которые хотел бы посмотреть. А если новые закладки переставали помещаться, то выборочно открывал видимые и или читал, или принимал решение о закрытии без чтения (всего же не прочитаешь). Казалось бы, что времени жизни страниц на закладках должно было хватать для чтения, но даже так временами открываемые страницы вели на отозванные ДНС или на закрытые проекты с постмортем и прощанием.
Собственно мой интерес к #Zettelkasten и #Obsidian был именно в этом контексте - т.е.еще одна попытка каталогизировать информацию и выработать систему, чтобы перестать терять интересные материалы и иметь к ним быстрый доступ. И первые попытки вновь оказались не особо удачными...
...А потом я услышал про концепцию LLM-Wiki от Андрея Карпаты и пазлики наконец-то сложились!
Я - обычный человек, который не обладает ни скорочтением, ни фотографической памятью, ни прочими тайными суперсилами обладателей кубков ЧГК. А следовательно вокруг всегда намного больше материалов, которые я хотел бы изучить, чем времени на изучение. Да что там "изучить" - иногда не хватает времени даже просто бегло ознакомится.
Ранее я пользовался первыми сервисами закладок - удобная вещь, ведь можно иметь доступ к своим спискам сохраненного с дома, с университета, с работы или с компьютерного клуба. Потом появился Google Chrome, который помимо удобной эргономики и скорости работы удивил возможностью централизированной синхронизации данных профилей - я постарался перетащить сюда ранее сохраненные материалы.
Но с ссылками было несколько проблем: 1) для их чтения все равно нужно было выделять время, 2) теперь нужно было выделять время на просмотр кучи ссылок и выбор "чего бы почитать", 3) материал по ссылкам перемещался или удалялся. Последнее вообще обидно, так как в разделе изучения иностранных языков у меня до сих пор десятки ссылок на интересные материалы на форуме Duolingo, который закрыли более десяти лет назад (((
Раз ссылки показали себя не очень хорошо, то я решил сохранять статьи полностью. Начал с программы, которая была на каждом компьютере - Microsoft OneNote, и у которой были инструменты сохранения фрагментов прямо с сайтов. Помню, что у меня так накопилась большая подшивка полезных материалов, которую я иногда даже просматривал. Но я вел хранение не очень системно и там быстро образовалась свалка.
Как раз появился мегапопулярный Evernote и я решил начать с чистого листа. На этот раз я сделал разделы, а к сохраняемым материалам добавлял теги. Но развитие инструмента пошло куда-то не туда и разработчики стали агресивно требовать оформить подписку на свой сервис. В результате после очередной переустановки системы на ноуте я даже не стал заново ставить Evernote и обошелся только просмотром веб-версии.
Дальше начался настоящих хаос, частично спровоцированный наличием у популярных соцсетей своих мобильных приложений, из которых трудно или невозможно сохранить прямую ссылку на страницу - у меня стали копится сохраненные закладки в фейсбуке, твиттере, линкедине, инстаграме, тредсе и так далее. Иногда я пользовался функцией "Поделится" для сохранения ссылки - скидывал в сохранения в Телеграмм, в результате чего свалка стала образовываться уже и в Телеграмме, где я паралельно сохранял интересные сообщения из групповых чатов и из каналов.
В конце-концов я просто перестал сохранять ссылки, раз я их вообще не читаю. Я просто в браузере стал держать открытыми закладками страницы, которые хотел бы посмотреть. А если новые закладки переставали помещаться, то выборочно открывал видимые и или читал, или принимал решение о закрытии без чтения (всего же не прочитаешь). Казалось бы, что времени жизни страниц на закладках должно было хватать для чтения, но даже так временами открываемые страницы вели на отозванные ДНС или на закрытые проекты с постмортем и прощанием.
Собственно мой интерес к #Zettelkasten и #Obsidian был именно в этом контексте - т.е.еще одна попытка каталогизировать информацию и выработать систему, чтобы перестать терять интересные материалы и иметь к ним быстрый доступ. И первые попытки вновь оказались не особо удачными...
...А потом я услышал про концепцию LLM-Wiki от Андрея Карпаты и пазлики наконец-то сложились!
Telegram
Журнал инженера-программиста
📚 Методология Zettelkasten
Еще за 40 лет до изобретения World Wide Web, немецкий социолог Никлас Луман фактически изобретает концепцию гипертекста, которую назовет Zettelkasten (ящик с заметками). Благодаря специальной методике ведения рабочих записей ему…
Еще за 40 лет до изобретения World Wide Web, немецкий социолог Никлас Луман фактически изобретает концепцию гипертекста, которую назовет Zettelkasten (ящик с заметками). Благодаря специальной методике ведения рабочих записей ему…
🔥3
О концепции LLM-Wiki я впервые прочитал на X (Twitter). Чтобы позже ознакомится детальнее, я заложил в закладки и... так там эта заметка до сих пор лежит непрочитанной 😅
Но чуть позже на DOU я прочитал не еще раз про эту концепцию, а уже про ее конкретную реализацию от Андрея Богдановича (некий чиновник одной из госинспекций) с ссылкой на GitHub - а этот материал уже можно было брать за основу💡
В виде голой концепции LLM-Wiki сразу решала вопрос с потерей информации из непрочитанных материалов. Так как тут LLM читает и анализирует абсолютно все - т.е. даже если у человека мало времени на знакомство с текстом, концепции из этого материала больше не пропадают, а аккуратно выделяются и логически связываются с другими ранее зафиксированными сущностями. Другими словами - вместо чтения статей десяти статей разных авторов на одну тему, вы в своей базе знаний получаете единую статью-компиляцию на заданную тему, в которой упоминаются мнения этих десяти авторов со ссылками на оригиналы.
Но тратить время на выгрузку всех статей в читаемом виде в inbox не хотелось и потому первым моим улучшением концепции стало добавление служебного \inbox\urls.txt , в который можно было закидывать пачки ссылок и они далее самостоятельно выгружались в базу в виде документов. На днях еще улучшил механизм - добавил склеивание результатов нескольких ссылок в единый документ для многостраничных статей, а для X добавил механизм выгрузки связанных твиттов для постов-тредов.
Мне понравилась идея у Богдановича, что входящие материалы могут быть на разных языках, но главным у него оставался украинский. Я сразу сделал себе дефолтными для ведения базы русский, а для поисковых тегов добавил украинский и английский. Но это все остается настраиваемо! Если есть желание добавить теги на польском, румынском и турецком, а саму базу знаний вести на казахском, то это правка буквально двух строчек в конфиге.
Как только я начал наполнять свою базу, то сразу отметил насколько разные материалы различаются по техническому уровню и квалификации авторов - очевидно что мнение индуса-нонейма не нужно обрабатывать с теми же приоритетами, что официальные материалы от вендоров (а сообщения из прес-релизов всегда тщательно перепроверять). Поэтому я добавил настраиваемую классификацию (т.е. предопределенные категории, которые можно отключать или наоборот еще сильнее расширять) и добавил в конфиг для каждой категории указания насколько можно доверять материалам, можно ли из материала пополнять глоссарий или просто записать как есть без обработки. Для ссылок это выглядит как предопределенные теги перед ссылкой, а для файлов автоматически создаются требуемые подкаталоги для загрузок.
В реализации от Богдановича оригинальные материалы из inbox/ в raw/ переносились самим ИИ на этапе импорта. Но мне это показалось странным - недетерминированное поведение самого агента плюс трата токенов. Поэтому у меня перед импортом добавлен этап подготовки, где Python скрипт скачивает статьи по ссылкам, вытаскивает содержимое мультимодальных файлов и так далее, а потом сам все размещает в raw/. В результате, для ИИ остается только проанализировать новое и записать в базу.
Поскольку я хотел иметь доступ к своей базе с различных устройств и поэтому разместил ее на своем Google Drive, то одной из первых задач стало отделение ПК-зависимых скриптов, библиотек и кешей (которые занимали очень много места) от самой базы знаний (база Obsidian).
Поскольку проект LLM-Wiki перестал быть просто коротким набором скриптов и скилов для ИИ и определенная база знаний уже набралась (которую было бы жать потерять), поэтому возникла необходимость в инструменте обновления. К проекту был добавлен файл манифеста с указанием всех служебных файлов и их хеши, чтобы при обновлении все файловые операции были максимально прогнозируемыми и безопасными (у скрипта обновления даже предусмотрен холостой запуск для предварительного просмотра плана обновления). Теперь обновление максимально простое - из каталога проекта запустить скрипт scripts\update.bat на вход которого подать путь к zip-архиву нужной версии с Github
====
Даже не знаю, что мне во всем этом больше принесло удовольствия - создание и развитие собственного ИИ-агента для ведения базы знаний, или что я наконец-то стал разгребать свои залежи ссылок и наконец-то закрыл большую часть закладок в своей браузере 😂
Если интересно ознакомится с результатом:
https://github.com/DementorAK/llm-wiki/
Но чуть позже на DOU я прочитал не еще раз про эту концепцию, а уже про ее конкретную реализацию от Андрея Богдановича (некий чиновник одной из госинспекций) с ссылкой на GitHub - а этот материал уже можно было брать за основу
В виде голой концепции LLM-Wiki сразу решала вопрос с потерей информации из непрочитанных материалов. Так как тут LLM читает и анализирует абсолютно все - т.е. даже если у человека мало времени на знакомство с текстом, концепции из этого материала больше не пропадают, а аккуратно выделяются и логически связываются с другими ранее зафиксированными сущностями. Другими словами - вместо чтения статей десяти статей разных авторов на одну тему, вы в своей базе знаний получаете единую статью-компиляцию на заданную тему, в которой упоминаются мнения этих десяти авторов со ссылками на оригиналы.
Но тратить время на выгрузку всех статей в читаемом виде в inbox не хотелось и потому первым моим улучшением концепции стало добавление служебного \inbox\urls.txt , в который можно было закидывать пачки ссылок и они далее самостоятельно выгружались в базу в виде документов. На днях еще улучшил механизм - добавил склеивание результатов нескольких ссылок в единый документ для многостраничных статей, а для X добавил механизм выгрузки связанных твиттов для постов-тредов.
Мне понравилась идея у Богдановича, что входящие материалы могут быть на разных языках, но главным у него оставался украинский. Я сразу сделал себе дефолтными для ведения базы русский, а для поисковых тегов добавил украинский и английский. Но это все остается настраиваемо! Если есть желание добавить теги на польском, румынском и турецком, а саму базу знаний вести на казахском, то это правка буквально двух строчек в конфиге.
Как только я начал наполнять свою базу, то сразу отметил насколько разные материалы различаются по техническому уровню и квалификации авторов - очевидно что мнение индуса-нонейма не нужно обрабатывать с теми же приоритетами, что официальные материалы от вендоров (а сообщения из прес-релизов всегда тщательно перепроверять). Поэтому я добавил настраиваемую классификацию (т.е. предопределенные категории, которые можно отключать или наоборот еще сильнее расширять) и добавил в конфиг для каждой категории указания насколько можно доверять материалам, можно ли из материала пополнять глоссарий или просто записать как есть без обработки. Для ссылок это выглядит как предопределенные теги перед ссылкой, а для файлов автоматически создаются требуемые подкаталоги для загрузок.
В реализации от Богдановича оригинальные материалы из inbox/ в raw/ переносились самим ИИ на этапе импорта. Но мне это показалось странным - недетерминированное поведение самого агента плюс трата токенов. Поэтому у меня перед импортом добавлен этап подготовки, где Python скрипт скачивает статьи по ссылкам, вытаскивает содержимое мультимодальных файлов и так далее, а потом сам все размещает в raw/. В результате, для ИИ остается только проанализировать новое и записать в базу.
Поскольку я хотел иметь доступ к своей базе с различных устройств и поэтому разместил ее на своем Google Drive, то одной из первых задач стало отделение ПК-зависимых скриптов, библиотек и кешей (которые занимали очень много места) от самой базы знаний (база Obsidian).
Поскольку проект LLM-Wiki перестал быть просто коротким набором скриптов и скилов для ИИ и определенная база знаний уже набралась (которую было бы жать потерять), поэтому возникла необходимость в инструменте обновления. К проекту был добавлен файл манифеста с указанием всех служебных файлов и их хеши, чтобы при обновлении все файловые операции были максимально прогнозируемыми и безопасными (у скрипта обновления даже предусмотрен холостой запуск для предварительного просмотра плана обновления). Теперь обновление максимально простое - из каталога проекта запустить скрипт scripts\update.bat на вход которого подать путь к zip-архиву нужной версии с Github
====
Даже не знаю, что мне во всем этом больше принесло удовольствия - создание и развитие собственного ИИ-агента для ведения базы знаний, или что я наконец-то стал разгребать свои залежи ссылок и наконец-то закрыл большую часть закладок в своей браузере 😂
Если интересно ознакомится с результатом:
https://github.com/DementorAK/llm-wiki/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3
Очень показательная причина моей нелюбви реализации сравнения/объединения конфигураций в 1C:EDT - постоянно вылазят изменения внутренней XML-структуры, которую без внешнего редактора никогда не увидишь.
Конфигуратор подобные "различия" чаще просто игнорирует или показывает отличие без уточнения, что отличается (в отчете по изменениям будет пусто) - по крайней мерее не нужно медитировать и играть в угадайку необходимости переноса подобных "изменений".
P.S. В ситуации на скрине из EDT была полной загрузкой обновлена конфигурация подключенной базы, в базе выполнены некоторые правки в режиме Конфигуратора, после чего выполнена попытка загрузки изменений назад в EDT
#будни #1с #edt
Конфигуратор подобные "различия" чаще просто игнорирует или показывает отличие без уточнения, что отличается (в отчете по изменениям будет пусто) - по крайней мерее не нужно медитировать и играть в угадайку необходимости переноса подобных "изменений".
P.S. В ситуации на скрине из EDT была полной загрузкой обновлена конфигурация подключенной базы, в базе выполнены некоторые правки в режиме Конфигуратора, после чего выполнена попытка загрузки изменений назад в EDT
#будни #1с #edt
Самая обычная бумажная книга учета - это пока лучший инструмент фиксации проектных изменений из всех, с которыми я сталкивался за свои более чем 20 лет стажа в ИТ!
За все эти годы я не видел идеального учета требований и описания проектных доработок. Всегда доступная информация была фрагментами - что-то в почте, что-то в мессенджерах, что-то в гугл-доках или на шарпойнте, а что-то вообще только голосом проговаривали на встречах после которых не то что фоллоу-аппов, но даже адженды не осталось...
Видел как в рамках одного и того же продукта комментарии к изменениям расползались по самому коду, по хранилищу конфигурации и по джире или подобным системам учета задач. Но чаще всего фрагменты с магическими числами или непонятные и нелогичные условия в запросах висят без каких-либо упоминаний кто и зачем это сделал.
Как результат, обслуживание проектных продуктов - это археологическое капание в легаси, которое идеально описывает мэмная картинка с Винни-Пухом, который перепачканный вылазит из черной лужи.
===
Только один раз все было ясно и понятно! Тогда я обслуживал бухгалтерские досовскими программами на Foxpro и у нас был один клиент, к которому за Киев нужно было ехать на автобусе. Бухгалтерия там состояла из классических Марьивановних, которые только-только сняли меховые шапки и едва начали экспериментировать с новыми понтами в виде накладных ногтей и выщипанных бровей. Рабочие машины были с маленькими пузатыми мониторами и клацающими механическими клавиатурами, а для печати - огромный матричный принтер. А еще нужно было каждый визит фиксировать в специальной книге учета модернизации ПО.
Да, это та самая волшебная книга!
По договору обслуживания каждый приходящий специалист был обязан зафиксировать в специальном журнале учета: ФИО, дату, цель визита, обнаруженные проблемы, перечень вносимых улучшений, какие именно правки в каких модулях и с какой целью выполнялись. Дополнительно мы в этот журнал вписывали теоретически возможные проблемные ситуации и как их решить в будущем. Эту книгу читали сами пользователи и пытались самостоятельно разобраться перед вызовов специалистов (так как вызовы были платными). По прибытию специалист сперва всегда брал этот журнал и смотрел кто какие правки недавно вносил и не могут ли они быть причинами проблем. И обычно информации из журнала было более чем достаточно даже для джуниоров (кем я был, когда приехал к ним в первый раз и увидел этот спасительный гросбух). А в самых сложных случаях можно посмотреть кто в базе ранее работал с подобной проблемой и позвонить за советом.
===
Согласен - немного слукавил 😅
Бумажная книга никак не может быть лучше документации в офисных документах или в специализированных учетных системах. Ведь тут нужно разбирать чужой подчерк и листать физические страницы, иногда слюнявя палец.
Вся магия там была не в инструменте, а в процессе!
За мою карьеру, это был единственный клиент, который настолько серьёзно подошел к документированию и включил требование наличия детального описания визита в процесс согласования его оплаты. Это вам не традиционные для таких случаях акты работ и листы учета рабочего времени, которые практически никто не читает, а потому которые по факту просто бесполезные бумажки. Тут заказчик точно знал что ему нужно и потребовал отчетность в удобном и полезном для него виде в рамках актуальных технических ограничений. Не удивлюсь, если сейчас у них уже Джира с Конфлюенсом.
За все эти годы я не видел идеального учета требований и описания проектных доработок. Всегда доступная информация была фрагментами - что-то в почте, что-то в мессенджерах, что-то в гугл-доках или на шарпойнте, а что-то вообще только голосом проговаривали на встречах после которых не то что фоллоу-аппов, но даже адженды не осталось...
Видел как в рамках одного и того же продукта комментарии к изменениям расползались по самому коду, по хранилищу конфигурации и по джире или подобным системам учета задач. Но чаще всего фрагменты с магическими числами или непонятные и нелогичные условия в запросах висят без каких-либо упоминаний кто и зачем это сделал.
Как результат, обслуживание проектных продуктов - это археологическое капание в легаси, которое идеально описывает мэмная картинка с Винни-Пухом, который перепачканный вылазит из черной лужи.
===
Только один раз все было ясно и понятно! Тогда я обслуживал бухгалтерские досовскими программами на Foxpro и у нас был один клиент, к которому за Киев нужно было ехать на автобусе. Бухгалтерия там состояла из классических Марьивановних, которые только-только сняли меховые шапки и едва начали экспериментировать с новыми понтами в виде накладных ногтей и выщипанных бровей. Рабочие машины были с маленькими пузатыми мониторами и клацающими механическими клавиатурами, а для печати - огромный матричный принтер. А еще нужно было каждый визит фиксировать в специальной книге учета модернизации ПО.
Да, это та самая волшебная книга!
По договору обслуживания каждый приходящий специалист был обязан зафиксировать в специальном журнале учета: ФИО, дату, цель визита, обнаруженные проблемы, перечень вносимых улучшений, какие именно правки в каких модулях и с какой целью выполнялись. Дополнительно мы в этот журнал вписывали теоретически возможные проблемные ситуации и как их решить в будущем. Эту книгу читали сами пользователи и пытались самостоятельно разобраться перед вызовов специалистов (так как вызовы были платными). По прибытию специалист сперва всегда брал этот журнал и смотрел кто какие правки недавно вносил и не могут ли они быть причинами проблем. И обычно информации из журнала было более чем достаточно даже для джуниоров (кем я был, когда приехал к ним в первый раз и увидел этот спасительный гросбух). А в самых сложных случаях можно посмотреть кто в базе ранее работал с подобной проблемой и позвонить за советом.
===
Согласен - немного слукавил 😅
Бумажная книга никак не может быть лучше документации в офисных документах или в специализированных учетных системах. Ведь тут нужно разбирать чужой подчерк и листать физические страницы, иногда слюнявя палец.
Вся магия там была не в инструменте, а в процессе!
За мою карьеру, это был единственный клиент, который настолько серьёзно подошел к документированию и включил требование наличия детального описания визита в процесс согласования его оплаты. Это вам не традиционные для таких случаях акты работ и листы учета рабочего времени, которые практически никто не читает, а потому которые по факту просто бесполезные бумажки. Тут заказчик точно знал что ему нужно и потребовал отчетность в удобном и полезном для него виде в рамках актуальных технических ограничений. Не удивлюсь, если сейчас у них уже Джира с Конфлюенсом.
👍4❤1
За последний месяц произошло много событий, но наиболее интересным является использование LLM для программирования на платформе 1С.
В августе я активировал бесплатную неделю для Claude от Antropic и не успел отменить подписку в последний день - так у меня для тестов появился оплаченный месяц Pro.
Итак к интересному.
У меня есть два параллельных проекта на разработку примерно одинаковых по размеру подсистем, но использую LLM я немного по разному. Для первого проекта у меня выгрузка в файлы, где модель по моим указаниям вносит правки, после чего я делаю загрузку из файлов. Во втором проекте у меня конфигурация с расширением развернуты в EDT, куда подключен EDT-MCP с полным доступом.
В обоих вариантах я получаю результаты, но модели при этом ведут себя по разному:
1) Если править файлы на диске, то Sonnet 5 показывает себя крепким мидлом с задатками сеньора - минимум ошибок, интересные предложения для улучшения эффекта от выполнимых задач. Ранее в рамках Google Pro у меня в Antigravity были доступны модели Sonnet 4.6 и Opus 4.6 - так тут просто небо и земля, Sonnet 5 намного-намного превосходит в интеллекте Opus 4.6. И самое восхитительное, что теперь для качественного 1С кода больше не нужно ни доступа к Синтаксис-Помощнику, ни к платформенной проверке на ошибки. Мелкие ошибки быстро исправляются, я о них сообщаю ИИ и тот фиксирует их в памяти сессии и специальном служебном файлике на диске, который я подключаю между сессиями.
2) При редактировании через MCP я использовал сначала Sonnet 5, а потом Opus 5 - не смотря на доступ к документации платформы и продвинутым внутренним механизмам контроля из ядра EDT, у меня стойкое ощущение, что работаю с глуповатым джуном. Я даже попробовал этот же проект на Fable от корпоративной учетки - не сильно лучше.
3) По данным Claude Code из расхода первого проекта 88% уходило на файловые операции, а все остальное на понимание и обсуждение проекта. Во втором проекте на выполнение MCP-вызовов ушло 97%
4) Задачи все же немного разные в проектах и потому некорректно прямое сравнение по токенам, но перерасход в проекте с MCP минимум в 10 раз больше. Я воспользовался встроенным скиллом "/anthropic-skills:explain-usage" и получил ответ: Большая выгрузка метаданных или скриншот формы остаётся в памяти беседы и перечитывается на каждом следующем шаге. Чем длиннее сессия, тем дороже каждый новый шаг.
В принципе логично. Отредактировать форму прямой заменой XML в файле и ее же отредактировать серией вызовов точечных инструментов через MCP с проверкой получаемого результата через снятие и анализ скриншотов - подобное просто безумно сравнивать и второе очевидно будет прожорливым до токенов.
Итоговый вывод.
У обоих методов свои недостатки, которые я в рамках этих экспериментов специально хотел прочувствовать на практике.
Уже есть понимание, что "золотая середина" будет как раз в разумной комбинации подходов. Когда в работу попадет третий проект, то я через MCP оставлю только справку, корневое редактирование метаданных и финальный линтер с анализом ошибок конфигурации, а все остальное будет только по прямому редактированию файлов из каталога проекта EDT.
#1с #edt #llm #mcp #vibecode
В августе я активировал бесплатную неделю для Claude от Antropic и не успел отменить подписку в последний день - так у меня для тестов появился оплаченный месяц Pro.
Итак к интересному.
У меня есть два параллельных проекта на разработку примерно одинаковых по размеру подсистем, но использую LLM я немного по разному. Для первого проекта у меня выгрузка в файлы, где модель по моим указаниям вносит правки, после чего я делаю загрузку из файлов. Во втором проекте у меня конфигурация с расширением развернуты в EDT, куда подключен EDT-MCP с полным доступом.
В обоих вариантах я получаю результаты, но модели при этом ведут себя по разному:
1) Если править файлы на диске, то Sonnet 5 показывает себя крепким мидлом с задатками сеньора - минимум ошибок, интересные предложения для улучшения эффекта от выполнимых задач. Ранее в рамках Google Pro у меня в Antigravity были доступны модели Sonnet 4.6 и Opus 4.6 - так тут просто небо и земля, Sonnet 5 намного-намного превосходит в интеллекте Opus 4.6. И самое восхитительное, что теперь для качественного 1С кода больше не нужно ни доступа к Синтаксис-Помощнику, ни к платформенной проверке на ошибки. Мелкие ошибки быстро исправляются, я о них сообщаю ИИ и тот фиксирует их в памяти сессии и специальном служебном файлике на диске, который я подключаю между сессиями.
2) При редактировании через MCP я использовал сначала Sonnet 5, а потом Opus 5 - не смотря на доступ к документации платформы и продвинутым внутренним механизмам контроля из ядра EDT, у меня стойкое ощущение, что работаю с глуповатым джуном. Я даже попробовал этот же проект на Fable от корпоративной учетки - не сильно лучше.
3) По данным Claude Code из расхода первого проекта 88% уходило на файловые операции, а все остальное на понимание и обсуждение проекта. Во втором проекте на выполнение MCP-вызовов ушло 97%
4) Задачи все же немного разные в проектах и потому некорректно прямое сравнение по токенам, но перерасход в проекте с MCP минимум в 10 раз больше. Я воспользовался встроенным скиллом "/anthropic-skills:explain-usage" и получил ответ: Большая выгрузка метаданных или скриншот формы остаётся в памяти беседы и перечитывается на каждом следующем шаге. Чем длиннее сессия, тем дороже каждый новый шаг.
В принципе логично. Отредактировать форму прямой заменой XML в файле и ее же отредактировать серией вызовов точечных инструментов через MCP с проверкой получаемого результата через снятие и анализ скриншотов - подобное просто безумно сравнивать и второе очевидно будет прожорливым до токенов.
Итоговый вывод.
У обоих методов свои недостатки, которые я в рамках этих экспериментов специально хотел прочувствовать на практике.
Уже есть понимание, что "золотая середина" будет как раз в разумной комбинации подходов. Когда в работу попадет третий проект, то я через MCP оставлю только справку, корневое редактирование метаданных и финальный линтер с анализом ошибок конфигурации, а все остальное будет только по прямому редактированию файлов из каталога проекта EDT.
#1с #edt #llm #mcp #vibecode
🔥3👍1🤔1
Уже второй проект на работе делаю в методике "парного программирования" с Claude Code. И сразу хочу отметить, что последние модели Sonnet 5, Opus 5, Opus 5.5 и Fable 5.1 уже превосходно знают платформу 1С и им для работы не нужны никакие дополнительные MCP со справкой.
Но пусть Claude и стал "программистом 1С", но он при этом самый настоящий джуниор и требует менторского присмотра. Чесно говоря, я так много не разжёвывал материал даже когда был наставником для сотрудников-людей.
Очень важно при ревью не исправлять самостоятельно ошибки логики, оформления кода или структуры элементов на форме, а каждый раз говорить ЧТО не так и ПОЧЕМУ это не правильно. Мы с Claude каждую ошибку рассматривает, описываем ее в правилах, а далее агент проходит по ранее сделанному и вносит правки во все похожие места.
Я слышал от коллег и читал в обсуждениях, что многие жалуются на говнокод от ИИ и потому отказываются с ним работать (не важно какая модель). Но ведь и живой студент-стажер без присмотра вам в базе может такого понаписывает, прикрываясь красивыми словами про SOLID и YAGNI, что потом поседеете.
#работа #ИИ #1C
Но пусть Claude и стал "программистом 1С", но он при этом самый настоящий джуниор и требует менторского присмотра. Чесно говоря, я так много не разжёвывал материал даже когда был наставником для сотрудников-людей.
Очень важно при ревью не исправлять самостоятельно ошибки логики, оформления кода или структуры элементов на форме, а каждый раз говорить ЧТО не так и ПОЧЕМУ это не правильно. Мы с Claude каждую ошибку рассматривает, описываем ее в правилах, а далее агент проходит по ранее сделанному и вносит правки во все похожие места.
Я слышал от коллег и читал в обсуждениях, что многие жалуются на говнокод от ИИ и потому отказываются с ним работать (не важно какая модель). Но ведь и живой студент-стажер без присмотра вам в базе может такого понаписывает, прикрываясь красивыми словами про SOLID и YAGNI, что потом поседеете.
#работа #ИИ #1C
👍7