На праздниках навайбкодила ещё и трекер времени (это другое приложение)
Теперь пользуюсь для работы )
Сначала попробовала так же, на wails: в принципе тоже всё заработало, но при внесении небольших изменений (например, свернуть в трей при закрытии) начались "прикольные" проблемы при внесении доработок.
Можно было вникнуть и сделать руками, но я решила попробовать навайбкодить ещё и на электроне.
Тут со сворачиванием в трей проблем не было. Но я решила добавить ф-ть выбора цветовой темы и тут началось 😁
Ничего такого, просто странное поведение + особенности с импортами.
Опять же можно вникнуть, но мне нужно было быстро сделать mvp, и я выбрала вариант попроще с двумя темами и переключением по константе пока что.
Выводы:
- прикольно вайбкодить мелкие приложения для себя - я бы не начала писать их с нуля
(кстати, пару раз делала подобные приложения на хакатонах, но до ума так и не довела)
- на электроне справляется лучше, т.к. он популярнее и такого кода в доступе больше (?) (но статистику не соберу)
- чем больше доработок, тем больше кажется, что проще вникнуть и сделать (частично) руками )
Позже пришла мысль, что можно было сделать совместимым с timetrap
Может доделаю, но это не точно )
Более ранний пост про трекинг времени, в том числе и с timetrap
Теперь пользуюсь для работы )
Сначала попробовала так же, на wails: в принципе тоже всё заработало, но при внесении небольших изменений (например, свернуть в трей при закрытии) начались "прикольные" проблемы при внесении доработок.
Можно было вникнуть и сделать руками, но я решила попробовать навайбкодить ещё и на электроне.
Тут со сворачиванием в трей проблем не было. Но я решила добавить ф-ть выбора цветовой темы и тут началось 😁
Ничего такого, просто странное поведение + особенности с импортами.
Опять же можно вникнуть, но мне нужно было быстро сделать mvp, и я выбрала вариант попроще с двумя темами и переключением по константе пока что.
Выводы:
- прикольно вайбкодить мелкие приложения для себя - я бы не начала писать их с нуля
(кстати, пару раз делала подобные приложения на хакатонах, но до ума так и не довела)
- на электроне справляется лучше, т.к. он популярнее и такого кода в доступе больше (?) (но статистику не соберу)
- чем больше доработок, тем больше кажется, что проще вникнуть и сделать (частично) руками )
Позже пришла мысль, что можно было сделать совместимым с timetrap
Может доделаю, но это не точно )
Более ранний пост про трекинг времени, в том числе и с timetrap
🔥12👍10👀2
Привет!
Январь уже прошёл, но я только пришла в себя и хочу поговорить о планировании 😌
Подводите итоги года / пишете планы?
Я - прям да (но не в публичном пространстве) Пишу по темам (типа работа, семья, поездки и тд) - что хотелось бы, потом - что получилось.
Формат свободный, может меняться от года к году. Для меня это просто способ структурировать мысли, порефлексировать, подумать, что я могу.
Без особых ожиданий, что всё получится, но направление задаёт нормально 💪
На что-то из планов забиваю: часто вполне осознанно, хоть и с сожалением. Но без самобичевания - чего и вам желаю.
В течение года будет 100500 обстоятельств, которые вмешаются в наши планы, это норм. Но также будут новые возможности и поводы, неожиданные приятные события. Это тоже норм.
В планы на год заглядываю нечасто, иногда смотрю в конце года удивляюсь, что некоторые пункты удалось выполнить.
Но планирование на месяц и на неделю организовано нормально, поэтому я помню, что делаю )
Как у вас? Планируете или живёте хаотично?
Январь уже прошёл, но я только пришла в себя и хочу поговорить о планировании 😌
Подводите итоги года / пишете планы?
Я - прям да (но не в публичном пространстве) Пишу по темам (типа работа, семья, поездки и тд) - что хотелось бы, потом - что получилось.
Формат свободный, может меняться от года к году. Для меня это просто способ структурировать мысли, порефлексировать, подумать, что я могу.
Без особых ожиданий, что всё получится, но направление задаёт нормально 💪
На что-то из планов забиваю: часто вполне осознанно, хоть и с сожалением. Но без самобичевания - чего и вам желаю.
В течение года будет 100500 обстоятельств, которые вмешаются в наши планы, это норм. Но также будут новые возможности и поводы, неожиданные приятные события. Это тоже норм.
В планы на год заглядываю нечасто, иногда смотрю в конце года удивляюсь, что некоторые пункты удалось выполнить.
Но планирование на месяц и на неделю организовано нормально, поэтому я помню, что делаю )
Как у вас? Планируете или живёте хаотично?
❤19⚡6👀3
Так, не дописала итоги 😁
Вот такими могу поделиться. В 2025 читала в режиме "лучше, чем ничего"
Решила ещё менеджерское добавить (why not) Технических совсем мало, но это было в других форматах.
В этом году хотелось бы больше технического, но увидим, насколько влезут именно книги (пока что у меня go 🌚). Софтовое тоже продолжу.
Сейчас читаю "Эффективный конфликт" (тут была рекомендация)
Как у вас с книгами? Читаете? (может и художку посоветуете? ))
#книги@anna_codes
Вот такими могу поделиться. В 2025 читала в режиме "лучше, чем ничего"
Решила ещё менеджерское добавить (why not) Технических совсем мало, но это было в других форматах.
В этом году хотелось бы больше технического, но увидим, насколько влезут именно книги (пока что у меня go 🌚). Софтовое тоже продолжу.
Сейчас читаю "Эффективный конфликт" (тут была рекомендация)
Как у вас с книгами? Читаете? (может и художку посоветуете? ))
#книги@anna_codes
❤12🤓4
👩💻🧑💻 DEV
На неделе пришёл привет с прошлой работы. У них новости: Major League Hacking поглотил DEV (и они сделали рассылку по старой команде :)
MLH - это лига студенческих хакатонов, фокусируются на обучении через практику.
Вот что я поняла после обсуждения с перплексити:
Насчёт акций - они предлагали опцион "на выход", а я не взяла, поэтому мне пофиг 😁
DEV продолжит работать как бренд, ещё планируют развивать forem, как универсальную опенсорсную платформу для сообществ.
Пока работала, тоже хотели развивать forem, но в итоге на это не хватило команды/денег и тд.
Видно, что фаундеры делают всё, чтобы не закрывать проект. Надеюсь, поглощение будет полезно для бренда/сообщества.
И мои тудушки в коде продолжат жить вечно 😈
#devto@anna_codes
На неделе пришёл привет с прошлой работы. У них новости: Major League Hacking поглотил DEV (и они сделали рассылку по старой команде :)
MLH - это лига студенческих хакатонов, фокусируются на обучении через практику.
Вот что я поняла после обсуждения с перплексити:
MLH (Major League Hacking) приобрело DEV (платформу dev.to), поглотив её как бизнес через покупку ключевых активов DEV
Привилегированные акционеры DEV получили выплаты от сделки.
Простые акционеры DEV (команда, фаундеры с обыкновенными акциями) ничего не получили, потому что пеосле выплат привелигированным денег не осталось
Насчёт акций - они предлагали опцион "на выход", а я не взяла, поэтому мне пофиг 😁
DEV продолжит работать как бренд, ещё планируют развивать forem, как универсальную опенсорсную платформу для сообществ.
Пока работала, тоже хотели развивать forem, но в итоге на это не хватило команды/денег и тд.
Видно, что фаундеры делают всё, чтобы не закрывать проект. Надеюсь, поглощение будет полезно для бренда/сообщества.
И мои тудушки в коде продолжат жить вечно 😈
#devto@anna_codes
DEV Community
A New Chapter: DEV is Joining Forces with Major League Hacking (MLH)
Hey everyone, I have some massive news to share today, and I couldn't be more excited to finally...
❤12🌚3👀2😱1
Forwarded from Occasional notes
Вышло второе издание кабана. Помню первое издание пару лет назад я читал взахлёб. Правда на русском. В новой версии обещают актуализированную информацию по архитектуре современных систем с учётом последних трендов с упором на облака и AI.
Что ж, посмотрим.
У кого есть желание почитать, пообсуждать?
Что ж, посмотрим.
У кого есть желание почитать, пообсуждать?
O’Reilly Online Learning
Designing Data-Intensive Applications, 2nd Edition
Data is at the center of many challenges in system design today. Difficult issues such as scalability, consistency, reliability, efficiency, and maintainability need to be resolved.... - Selection from Designing Data-Intensive Applications, 2nd Edition [Book]
❤🔥7👍5🔥3👀1
Forwarded from code_sisters Official
Итак, скоро близится важный для всех нас праздник и в его честь мы объявляем анонс нового митапа!
Елена Герман
📹 5 ошибок начинающих в data science и как их избежать
Если вы начинающая датасаентистка - этот доклад будет полезен вам, чтобы пройти кратчайшей дорожкой, избежав большого количества лишних шишек на лбу. А опытным - доклад поможет оценить пройденный путь
Екатерина Крупкина
📹 API и self-hosted: где возникают риски
Мы уже привыкли что ИИ плотно вошел в нашу повседневную жизнь и работу. Есть случаи отношения к ИИ как в близкой подруге, но где находится грань безопасности? В докладе поднимается важный вопрос разграничения - когда поднимать ИИ на своем железе а когда использовать API
Оксана Крымина
📹 Будем резать [граф], не дожидаясь [модельного] перитонита
Расскажет про дилемму усложнения - кажется что сложность это всегда хорошо. Чем больше параметров, тем больше выразительной силы! Но как определить критерий качества или понять - хорошо ли получилось?
Алиса Захтаренко
📹 Как находить работу в любых обстоятельствах (даже в иммиграции)
В этом докладе поговорим про текущую ситуацию поиска работы и что с этим можно сделать
_________
Трансляция будет онлайн, площадки уточняются. Все ссылки будут в канале кодсистерс. запись - постараемся.
В программе возможны изменения, но постараемся сделать все возможное чтобы вам было интересно! Приходите!
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
code_sisters Official
code_sisters это закрытое комьюнити программисток, созданное женщинами для женщин, чтобы объединить разработчиц независимо от уровня и стека. Заходи, перепишем культурный код вместе! @code_sisters_bot
❤11
Привет ✨
Поняла, что пока не хочу начинать полноценный книжный клуб - весной-летом много личных дел, да и гулять нужно.
Пока что просто почитаю птицу (Современный подход к программной архитектуре: сложные компромиссы), а кабана возьму попозже )
Буду постить ❤️ , если пойдёт хорошо )
Прочитала первую главу, мне норм. Цель книги - собственно, рассмотреть, как оценивать компромиссы и принимать решения в сложных ситуациях, без привязки к конкретным технологиям.
Зачем читать? Тоже принимать архитектурные решения.
Лучше понимать литературу по архитектуре. Разговаривать с архитекторами. Умничать 😁
В первой главе авторы дают основные определения - fitness functions, adr-ы, оркестровая и хореографическая координация, контракты, связность и связанность (я рекомендую каплинг и кохижен, чтобы не ломать мозг :)
Примеры в книге на основе саги о Sysops Squad (приложение типа хелпдеска).
Избранное определение от меня:
Функция пригодности (fitness function) - проверка, которая показывает, соответствует ли система нужным требованиям, и продолжает ли соответствовать после внесения изменений.
Пример - функция, которая проверяет наличие циклических зависимостей.
Даа, пока не зафорсишь проверку, соблюдать особо никто не будет (и речь не столько про архитекторов :)
Если хотите почитать параллельно - можем обсудить в комментах, можем созвониться разок в процессе/в конце. Пишите )
#книги@anna_codes #arch_hard_parts@anna_codes
Поняла, что пока не хочу начинать полноценный книжный клуб - весной-летом много личных дел, да и гулять нужно.
Пока что просто почитаю птицу (Современный подход к программной архитектуре: сложные компромиссы), а кабана возьму попозже )
Буду постить ❤️ , если пойдёт хорошо )
Прочитала первую главу, мне норм. Цель книги - собственно, рассмотреть, как оценивать компромиссы и принимать решения в сложных ситуациях, без привязки к конкретным технологиям.
Зачем читать? Тоже принимать архитектурные решения.
Лучше понимать литературу по архитектуре. Разговаривать с архитекторами. Умничать 😁
В первой главе авторы дают основные определения - fitness functions, adr-ы, оркестровая и хореографическая координация, контракты, связность и связанность (я рекомендую каплинг и кохижен, чтобы не ломать мозг :)
Примеры в книге на основе саги о Sysops Squad (приложение типа хелпдеска).
Избранное определение от меня:
Функция пригодности (fitness function) - проверка, которая показывает, соответствует ли система нужным требованиям, и продолжает ли соответствовать после внесения изменений.
Пример - функция, которая проверяет наличие циклических зависимостей.
Как архитектор сможет проверить, что разработчики соблюдают границы уровней? Одни разработчики могут не понимать важности паттернов, тогда как другие могут занимать позицию «лучше попросить прощения, чем разрешения»
Даа, пока не зафорсишь проверку, соблюдать особо никто не будет (и речь не столько про архитекторов :)
Если хотите почитать параллельно - можем обсудить в комментах, можем созвониться разок в процессе/в конце. Пишите )
#книги@anna_codes #arch_hard_parts@anna_codes
❤11🤓4
Вижу тренд на запасные каналы 😁
Завела сабстек и вк:
https://substack.com/@lightalloy
https://vk.com/anna_codes
(буду ли постить - не знаю, увидим)
Также KakaoTalk (lightalloy) - для лички.
Обзор какао от Насти
Не теряйте 😏
Завела сабстек и вк:
https://substack.com/@lightalloy
https://vk.com/anna_codes
(буду ли постить - не знаю, увидим)
Также KakaoTalk (lightalloy) - для лички.
Обзор какао от Насти
Не теряйте 😏
Substack
Anna | Substack
Backend developer and educator
👍9❤🔥3❤3
Наконец-то посмотрела "руби и ии в разработке"
Приятно послушать - Ваня рекомендует делать, что нравится, и получать удовольствие от жизни - не поспоришь 😏
Зацепилась за пару тем:
Как меняется роль разработчиков и менеджеров с ИИ, и что это значит для бизнеса:
Ваня упоминает, что никогда не воспринимал себя как кодописателя, а скорее как решателя проблем, поэтому не держится за "набор кода руками". В этом плане can relate, нет особых чувств, если код напишет агент.
Также интересно, что несмотря на то, что разработка становится быстрее, прирост в скорости доставки фичи небольшой, т.к. есть лаги между этапами при передаче от человека к человеку.
Развитие сотрудников (и себя в т.ч.)
- нужно не всем
- что там развивать, если нас заменит ИИ (ну что-то можно пока что)
- ИПР "сверху" vs с учётом интересов
Сергей говорит, что не любит, когда развивают, и что есть своё видение. Мне вот интересно, кто-нибудь это любит вообще? ))
Я думаю, тут либо "развитие не нужно", либо всё-таки есть своё видение. Тогда интересы нужно учитывать и смотреть, можно ли совместить с рабочими задачами, или уже отправить изучать в личное время.
Ещё обсуждали:
- что рекомендовать изучать детям с учётом изменений (физику и математику, как базу vs делать, что нравится)
- сложности на рынке - трудно найти работу, а работодатель может выбрать из кандидатов (ничего нового, но интересно соотнести со своим свежим опытом подбора)
- также ждём конфу в спб летом 🤞
саммари от YandexGPT
на этот раз качество среднее, но как инструмент рекомендую
Приятно послушать - Ваня рекомендует делать, что нравится, и получать удовольствие от жизни - не поспоришь 😏
Зацепилась за пару тем:
Как меняется роль разработчиков и менеджеров с ИИ, и что это значит для бизнеса:
Ваня упоминает, что никогда не воспринимал себя как кодописателя, а скорее как решателя проблем, поэтому не держится за "набор кода руками". В этом плане can relate, нет особых чувств, если код напишет агент.
Также интересно, что несмотря на то, что разработка становится быстрее, прирост в скорости доставки фичи небольшой, т.к. есть лаги между этапами при передаче от человека к человеку.
Развитие сотрудников (и себя в т.ч.)
- нужно не всем
- что там развивать, если нас заменит ИИ (ну что-то можно пока что)
- ИПР "сверху" vs с учётом интересов
Сергей говорит, что не любит, когда развивают, и что есть своё видение. Мне вот интересно, кто-нибудь это любит вообще? ))
Я думаю, тут либо "развитие не нужно", либо всё-таки есть своё видение. Тогда интересы нужно учитывать и смотреть, можно ли совместить с рабочими задачами, или уже отправить изучать в личное время.
Ещё обсуждали:
- что рекомендовать изучать детям с учётом изменений (физику и математику, как базу vs делать, что нравится)
- сложности на рынке - трудно найти работу, а работодатель может выбрать из кандидатов (ничего нового, но интересно соотнести со своим свежим опытом подбора)
- также ждём конфу в спб летом 🤞
саммари от YandexGPT
на этот раз качество среднее, но как инструмент рекомендую
YouTube
Иван Шаматов: Ruby, ИИ в разработке и карьера в неопределённом будущем
Заявка на доклад Saint P Rubyconf 2026
https://forms.yandex.ru/u/69b53f6d84227c436538552c/
В этом выпуске Heavy Tech Podcast в гостях Иван Шаматов — Ruby-разработчик с большим стажем, инженер-менеджер и один из организаторов питерской Ruby-конференции.…
https://forms.yandex.ru/u/69b53f6d84227c436538552c/
В этом выпуске Heavy Tech Podcast в гостях Иван Шаматов — Ruby-разработчик с большим стажем, инженер-менеджер и один из организаторов питерской Ruby-конференции.…
❤8👍6🤔2⚡1❤🔥1
Избранное из глав "птицы".
Глава 2. Разделение компонентов.
Архитектурный квант - условно сервис, который деплоится отдельно.
Хотя несколько сервисов вполне могут представлять собой один квант, и часто это делают:
Например:
общая база данных => у вас один архитектурный квант
общий ui => у вас тоже один архитектурный квант )
есть оркестратор запросов => мб у вас тоже один квант ))
Динамический coupling между квантами
3 "силы", которые формируют пространство для принятия решений:
- взаимодействие между квантами - синхронное (вызывающий ждёт, чтобы продожить) или асинхронное (не ждёт)
- согласованность - атомарные транзакции или приемлемо eventual consistency
- координация - оркестратор (есть сервис, к-й отвечает за координацию) или хореография (нет координатора)
Понравилась табличка с вариантами, особенно horror )
Глава 3
О том, что тестируемость, развёртываемость, масштабируемость, доступность, отказоустойчивость лучше у небольших сервисов.
Поэтому если у вас проблемы с финансами, нужно срочно перейти на микросервисы (немного утрированный пример из главы 😁)
Так то это так мб, но возникают другие проблемы, и как будет с той же тестируемостью у системы в целом?
Впрочем, учебные примеры часто бывают немного странными. Допустим, всё же нужно разделиться, посмотрим )
#книги@anna_codes #arch_hard_parts@anna_codes
Глава 2. Разделение компонентов.
Архитектурный квант - условно сервис, который деплоится отдельно.
Хотя несколько сервисов вполне могут представлять собой один квант, и часто это делают:
Например:
общая база данных => у вас один архитектурный квант
общий ui => у вас тоже один архитектурный квант )
есть оркестратор запросов => мб у вас тоже один квант ))
Динамический coupling между квантами
3 "силы", которые формируют пространство для принятия решений:
- взаимодействие между квантами - синхронное (вызывающий ждёт, чтобы продожить) или асинхронное (не ждёт)
- согласованность - атомарные транзакции или приемлемо eventual consistency
- координация - оркестратор (есть сервис, к-й отвечает за координацию) или хореография (нет координатора)
Понравилась табличка с вариантами, особенно horror )
Глава 3
О том, что тестируемость, развёртываемость, масштабируемость, доступность, отказоустойчивость лучше у небольших сервисов.
Поэтому если у вас проблемы с финансами, нужно срочно перейти на микросервисы (немного утрированный пример из главы 😁)
Так то это так мб, но возникают другие проблемы, и как будет с той же тестируемостью у системы в целом?
Впрочем, учебные примеры часто бывают немного странными. Допустим, всё же нужно разделиться, посмотрим )
#книги@anna_codes #arch_hard_parts@anna_codes
❤5👍4🤓1
Недавно закончила курс по Go от отуса.
Не было в моих планах, тем более курс "с нуля", но появилась возможность, и я решила воспользоваться.
Было интересно также с точки зрения проектирования курсов - как строится программа, как организовано обучение.
Формат такой: вебинары 2 раза в неделю по 2 часа по вечерам + домашки и проект. Пытаются в интерактив, но мне это не помогло, скучно. Может быть, формат не подходит, может быть, курс слишком базовый (на синкнетику же хожу нормально :)
В итоге можно сказать, что ни на одно занятие не сходила и не посмотрела в записи, кроме встреч по обсуждению проектов, qa-сессии и защиты.
Зато делала домашки. В начале курса идёт совсем база, установка, гит и тд - в итоге ничего не делаешь. Дальше одно упражнение по го и работа над проектом )
Проект можно взять свой или выбрать из предложенных.
Говорят, изначально на курсе были просто домашки, а уже потом проектная работа. Подозреваю, что в таком случае никто не успевал делать проект, и доходимость была совсем низкая.
С проектом лучше, но тогда нужно каждую домашку подтягивать под проект. Не всегда удобно с учётом того, что домашки сформулированы в стиле "надо сначала понять, что хотел сказать автор", а проверяющий преподаватель как будто не всегда в теме. Ревью формальное, особенно под конец. Ну я понимаю, смотреть пр со 100500 изменений... к тому же сколько их там у препода.
Возможно, стоило просто делать проект и не привязываться к дз. Но тогда не было бы ощущения завершённости курса, хотя сертификат всё равно дают в таком случае.
В итоге:
Было ли полезно? Да, научилась новому. Но из-за курса я отложила архитектуру, оказалось тяжко 💔
Изучила ли го? Нет, для этого надо писать для прода.
Могу ли писать для прода? Да, конечно )
Сам курс: с нуля я бы не рекомендовала, с приличным бэкграундом - тоже. С небольшим опытом пойдёт, если мотивируют дедлайны и нужна структура )
#go@anna_codes
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👀6👍2
На днях прошла очередная конференция Ruby Kaigi
Чуть позже сделаю обзор, а пока зацепилась за это:
Матц (и Claude) сделали spinel💎
Это AOT (ahead-of-time) compiler. Можно наконец-то делать бинарники из рубишных программ, пусть и с ограничениями.
Пользоваться можно так:
- ставите spinel (
- компилируете -
- запускаете
Кол-во фич ограничено, так что надо думать, что используем )
Сейчас, конечно, это проще - можно попросить llm написать код с учётом ограничений, или адаптировать существующий.
Помимо примера из ридми попробовала хелло-ворд и простую прогу, которая выводит текст в рамке.
Программы такого плана работают, как-нибудь попробую адаптировать то, что посложнее )
Пример:
Матц давно говорит о компиляции руби-кода, теперь проще двигаться в эту сторону. Посмотрим, что дальше 🍿
Поделитесь, если тоже попробуете 😉
#ruby@anna_codes
Чуть позже сделаю обзор, а пока зацепилась за это:
Матц (и Claude) сделали spinel
Это AOT (ahead-of-time) compiler. Можно наконец-то делать бинарники из рубишных программ, пусть и с ограничениями.
Пользоваться можно так:
- ставите spinel (
git clone + make deps + make)- компилируете -
./spinel hello.rb- запускаете
./helloКол-во фич ограничено, так что надо думать, что используем )
Сейчас, конечно, это проще - можно попросить llm написать код с учётом ограничений, или адаптировать существующий.
Помимо примера из ридми попробовала хелло-ворд и простую прогу, которая выводит текст в рамке.
Программы такого плана работают, как-нибудь попробую адаптировать то, что посложнее )
Пример:
text = ""
if ARGV.length > 0
text = ARGV[0]
end
lines = [text]
width = 0
lines.each do |line|
len = line.length
if len > width
width = len
end
end
top = "┌" + ("─" * (width + 2)) + "┐"
bottom = "└" + ("─" * (width + 2)) + "┘"
puts top
lines.each do |line|
puts "│ #{line.ljust(width)} │"
end
puts bottom
Матц давно говорит о компиляции руби-кода, теперь проще двигаться в эту сторону. Посмотрим, что дальше 🍿
Поделитесь, если тоже попробуете 😉
#ruby@anna_codes
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥13👍6👀2🔥1
Привет!
Сегодня пара материалов по конкурентности и параллелизму в Ruby (и не только).
Статья от Carmine Paolino (автора ruby llm)
- рубишный 101 по конкурентности и параллелизму: особенности процессов, ракторов, тредов, файберов
- как планируются треды и файберы, почему файберов можно запустить намного больше
- когда всё же есть смысл выбрать треды, а не файберы, несмотря на то, что они "тяжелее"
- цвет функций и его отсутствие (colorless в ruby и необходимость писать async/await в питоне и js)
- проблемы с ракторами и их экспериментальностью ✊😄
Понравились схемы и сравнение с другими яп.
Цикл статей о конкурентности и параллелизме в Ruby от JP Camara
Уже писала про него, с тех пор немного дополнил. Я думаю, если допишет, уже потянет на книгу.
Поделитесь в комментах избранными статьями по теме, особенно не рубишными ✨
#ruby@anna_codes
Сегодня пара материалов по конкурентности и параллелизму в Ruby (и не только).
Статья от Carmine Paolino (автора ruby llm)
- рубишный 101 по конкурентности и параллелизму: особенности процессов, ракторов, тредов, файберов
- как планируются треды и файберы, почему файберов можно запустить намного больше
- когда всё же есть смысл выбрать треды, а не файберы, несмотря на то, что они "тяжелее"
- цвет функций и его отсутствие (colorless в ruby и необходимость писать async/await в питоне и js)
- проблемы с ракторами и их экспериментальностью ✊😄
Понравились схемы и сравнение с другими яп.
Цикл статей о конкурентности и параллелизме в Ruby от JP Camara
Уже писала про него, с тех пор немного дополнил. Я думаю, если допишет, уже потянет на книгу.
Поделитесь в комментах избранными статьями по теме, особенно не рубишными ✨
#ruby@anna_codes
Carmine Paolino
Ruby Concurrency: What Actually Happens
Every 'what happens when' question about Ruby concurrency, answered with diagrams.
👍11❤6🔥4🤓3
Привет!
В понедельник 25.05 в 19:00 будет встреча с Владимиром Дементьевым, автором книги "Слоёные рельсы".
Обсудим второе издание книги, рубишные конференции, ещё что-нибудь. Можно накинуть тем в комменты, можно прийти и задать вопросы на встрече 😎
Ссылку приложу в понедельник, будет телемост.
#стрим@anna_codes #ruby@anna_codes
В понедельник 25.05 в 19:00 будет встреча с Владимиром Дементьевым, автором книги "Слоёные рельсы".
Обсудим второе издание книги, рубишные конференции, ещё что-нибудь. Можно накинуть тем в комменты, можно прийти и задать вопросы на встрече 😎
Ссылку приложу в понедельник, будет телемост.
#стрим@anna_codes #ruby@anna_codes
👍13❤7🔥4
Анна Буянова (Anna Codes)
Привет! В понедельник 25.05 в 19:00 будет встреча с Владимиром Дементьевым, автором книги "Слоёные рельсы". Обсудим второе издание книги, рубишные конференции, ещё что-нибудь. Можно накинуть тем в комменты, можно прийти и задать вопросы на встрече 😎 Ссылку…
telemost.yandex.ru
Звонок в Яндекс Телемосте
По ссылке вы сможете подключиться к звонку
❤7