Радикальная идея
前往频道在 Telegram
Субъективное мнение программистки с 7+ годами опыта о жизни и российском айти. Канал про фронтенд: https://t.me/margo_pro_frontend
显示更多266
订阅者
无数据24 小时
-17 天
+230 天
数据加载中...
吸引订阅者
十二月 '24
十二月 '24
+278
在3个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 23 十二月 | 0 | |||
| 22 十二月 | 0 | |||
| 21 十二月 | 0 | |||
| 20 十二月 | +1 | |||
| 19 十二月 | 0 | |||
| 18 十二月 | +2 | |||
| 17 十二月 | +1 | |||
| 16 十二月 | 0 | |||
| 15 十二月 | +3 | |||
| 14 十二月 | 0 | |||
| 13 十二月 | +1 | |||
| 12 十二月 | 0 | |||
| 11 十二月 | +1 | |||
| 10 十二月 | 0 | |||
| 09 十二月 | 0 | |||
| 08 十二月 | 0 | |||
| 07 十二月 | +2 | |||
| 06 十二月 | +3 |
频道帖子
Repost from Набока орёт в борщ | 🌋
Место женщины в IT
Публичная травля девушек, буллинг, преследование и хейт, оправдание домогательств и стеклянного потолка.
«Почему вы просто не отказали абьюзеру?», «то что вы боитесь подвергнуться изнасилованию — ваша проблема» — ожидаете ли вы такое увидеть в IT?
Мы копнули эту тему и ужаснулись как такое людоедское отношение к женщинам пропагандируют и оправдывают IT-блогеры с многотысячной аудиторией. Для того, чтобы показать «среднюю температуру по больнице» мы взяли за пример транслируемый сексизм лидера IT-сообщества накручивальщиков опыта (они же «волчья стая», которая занимается обманом работодателей).
Мы рассказали вам истории девушек, подвергнувшиеся сексизму и оставшихся с ним один на один.
Мы хотим, во-первых, показать вам, что это — не единичные кейсы, а системная история, и если с вами случилось что-то подобное, то это не ваша вина. Во-вторых, рассказать, что вы можете с этим сделать и где найти помощь, если понадобится. В-третьих, конечно, просто поорать вместе с вами, потому что невозможно держать в себе.
Вместе с нами высказались сильные и умные женщины:
– Мари Давтян, адвокат, вела дела сестер Хачатурян и Маргариты Грачевой
– Наира Парсаданян, руководительница психологической службы для пострадавших от насилия, работает с авторами насилия
– Марина Ментусова, гендерная исследовательница, написала две энциклопедии для девочек и мальчиков
– Елена Голяковская, кризисный психолог
– Катя Ло, расширяет права женщин на YouTube
– София Сидорова, IT PM, создала целую энциклопедию про женские права и насилие
– Марго Лукина, фронтенд-разработчица
– Наташа Давыдова, фронденд-разработчица, проводит благотворительные хакатоны.
Смотрите выпуск, делитесь с подругами, знакомыми и коллегами, и обязательно пишите в комментариях свои истории. Покажем друг другу, что мы не одиноки и вместе — сила.
🔗 Смотреть выпуск https://youtu.be/93d7ZdPGKBY?si=7DbRKNav3i_Www22
| 2 | Субстанция в JS. TC39 готовы вколоть активатор!
На днях посмотрели с женой Субстанцию и я так рад, что сделали это дома, потому что боюсь в кинотеатре стоял ужасный запах. Потрясающая роль шестидесятилетней Деми Мур не оставила равнодушным, и я ещё пол дня пел песню, что хотел бы жить на Манхеттене, и с ней делиться секретами. Фильм потрясающий, рекомендую, но сейчас не о нём.
Я почитал, что в TC39 ходят разговоры (и даже забавная преза есть) о том, что пора бы нам перестать мучать старичка ДЖо и назвать его матрицей JS0, и оставить в покое. А новые, классные, удобные и прогрессивные фичи пилить в новой его субстанции — в JS Sugar. Все как по фильму.
Предпосылки в целом здравые: браузерам тяжело пилить фичи, они не успевают за развитием, плюс есть ещё всякие компании, которые запрещают обновление браузеров, а ещё кроме браузеров есть всякие Node.js и прочие штуки, которые тоже вынуждены поддерживать вечно обновляющийся стандарт.
Короче, они все устали.
Тем более все поголовно всё равно используют всякие сборщики, транспиляторы, минификаторы, модификаторы и до браузера пользователя чаще всего доезжает какой-нибудь es5, если не es3 вообще. Чувакам обидненько, они старались.
Вот ребятки в коммите посидели, покумекали, и решили что так дальше продолжаться не может и пора колоть активатор пришло время сделать два языка: модный и стильный для разрабов, и стабильный и оптимизированный для юзеров. Превращение одного в другой нужно делать каждые семь дней решили доверить знакомым нам инструментам: бабелю, вебпаку и их друзьям. В целом — логично.
Как думаете, нормальная тема?
Я думаю, нормальная, с TS же хорошо всё работает. Будем просто на собесах ещё и это спрашивать 😄
P.S. презу зацени, и друзьям отправь — это топ! Вот так должен выглядеть документ века, меняющий историю!
© Счастливый тимлид | 255 |
| 3 | Радикальная идея! | 245 |
| 4 | Многие, особенно новички, думают, что главное на собеседовании - это решить как можно больше задач и ответить на как можно большее число вопросов. По этому поводу у меня есть радикальная идея - важно не то, на сколько вопросов ты ответил/не ответил, важно то, как ты рассуждал в процессе. Можно не ответить на вопрос - ведь все знать и помнить невозможно - но показать умение рассуждать, а это ценится гораздо больше. | 281 |
| 5 | ![[Бесплатно и только для женщин] Круглый стол-девичник: «Борщ, дедлайны, 2 декрета: как быть женщиной в современном мире и не](data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAARCAAoACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwC/cXJhfnAQEAk1Dc3MoutiPhCgIwB70y7lU3DRtGjY5+YVZ/c/Z45JY1B29MdKQxkFyxszK7chsZoa7UpKiv8AvkXJGOlVxeRSfIYQYjyPl4zVyFIHDSLEoLD5uOTTQNW3K1lcyyyLukLA8nge9FWYBEHIRFUg9hRQDI54bc3Ad927PboajvFc8LnZs/xqadEeX5nAb+EbsUs/lGERySqjsvBzSEUVOYgu8cdsVdhRlB/hBXqKri1EcQYzLtB654q5HJGVMaSKzgcihFS1ILaKFbklJJS/fPeio7VLj7ZlpIiozuVT0op6kuw+5hnmncKuEIGHz3FMntpnmhfblgAGIPHvRRRYL7Bd288lpsjT5vMzjI6Yplra3EV40rx8eXjgjk0UUrDJ7SKRJizowyMDpRRRTEf/2Q==){kind=small} [Бесплатно и только для женщин] Круглый стол-девичник: «Борщ, дедлайны, 2 декрета: как быть женщиной в современном мире и не сойти с ума»
Сначала нам диктуют, как жить и где работать. Потом говорят, что мы должны работать наравне с мужчинами, но не дают этого делать. А потом требуют совмещать быт и работу. Быть современной женщиной чертовски сложно. Быть женщиной в IT — почти нереально. Но мы справляемся. И вам расскажем!
13 спикерок собираются вместе 📅 5 декабря (четверг) в 19:00 (МСК), чтобы обсудить:
– Сексизм и мизогинию, как всех интересует наша матка на каждом втором собеседовании
– Как нас не только не поддерживают, но и максимально задвигают
– Как можно не нести вторую смену после основной работы, не варить борщи и не выслушивать «а у мамы борщ был вкуснее»
– Как складывается жизнь, когда уходишь из хреновых браков, и как нам страшно было из них уходить
– Как мы справляемся, когда остались наедине с детьми и своей карьерой, как быть работающей мамой
– Как быть не стандартной конвенциональной красоты и при этом быть любимой и счастливой
– «Не высовывайся», как женщине строить личный бренд, как справляться с хейтом за вещи, которые мужчинам дозволены и не вызывают вопросов
– И как можно быть собой и быть счастливой
– И многое другое
Невыдуманные истории женщин, о которых невозможно молчать, и наша Girls Power в действии.
❗️ Вход только для женщин. Включенная камера обязательна. Анонимов будем удалять со стрима, чтобы нам никто не помешал.
📅 Дата и время: 5 декабря (четверг) с 19:00 до 21:00 по Москве.
🎙 Спикерки: Леся Набока, Люда Пак, Наташа Гришина, Оля Федосеева, Марго Лукина, Наташа Давыдова, София Сидорова, Ира Мазаева, Надя Гнусина, Карина Жданова, Ангелина Зинченко, Настя Румянцева, Настя Никулина. Умницы, красавицы, великолепные экспертки.
🔖 Как участвовать: Через обязательную регистрацию https://careerfactory.timepad.ru/event/3138085/
❓ Задавайте вопросы и рассказывайте истории — оставляйте их в комментариях к посту, и мы обязательно обсудим их на встрече.
💬 Дамы, приходите сами и берите с собой подруг. Мы вас ждем. Мы вам рады ❤️🔥
#GirlsPower | 403 |
| 6 | Недавно увидела в твиттере пост, суть которого была в том, что если бизнесу не нужны тесты в коде - это значит, что бизнесу таки нужны тесты в коде, нужно просто их получше убедить. По этому поводу у меня есть радикальная идея.
Бизнесу действительно не нужны тесты в коде. Как и архитектура, как и чистый код. Бизнесу нужен рабочий продукт, который достаточно гибок, чтобы в него можно было вносить изменения. А вот для того, чтобы сделать гибкий, масштабируемый и рабочий продукт нам, разработчикам, нужны тесты, чистый код и архитектура.
Поэтому не надо перекладывать на бизнес свою ответственность за написание тестов, за проектирование, за чистый код. Наша цель, как профессиональных программистов - это отдать бизнесу рабочий продукт того уровня качества, о котором мы с бизнесом договорились. Если нам нужны тесты, мы пишем тесты. Если нам нужен рефакторинг, мы делаем рефакторинг. Бизнес не должно волновать, как именно мы достигаем результата, о котором мы с ним договорились - главное, мы должны соблюсти качество, требования и сроки.
P.S. И да, заранее закладывайте в сроки все те мероприятия, которые необходимы вам для достижения того качества, которое вы хотите соблюсти на данном проекте. | 1 222 |
| 7 | Обещала поделиться еще одной своей радикальной идеей, связанной с SOLID. Уже давно мне приходит в голову, что это не пять разных, совершенно не связанных между собой принципов, а один и тот же принцип, рассмотренный с пяти разных точек зрения. Этот принцип можно сформулировать следующим образом: используемые в коде абстракции должны в точности соответствовать требованиям к конкретной части системы. Давайте посмотрим повнимательнее.
Принцип единственной ответственности (SRP) говорит нам, что программный модуль должен отвечать за одного и только за одного актора. Этот принцип побуждает нас внимательно рассмотреть наши бизнес процессы и разделить функциональность таким образом, чтобы код, меняемый вследствие решений разных акторов, не находился в одном модуле.
Принцип открытости-закрытости (OSP) побуждает нас не вносить ломающие изменения в код, от которого зависят другие модули.
Применение принципа постановки Барбары Лисков (LSP) позволяет нам в полной мере использовать полиморфизм и работать с интерфейсом объекта, а не с его реализацией.
Принцип разделения интерфейсов (ISP) помогает нам регулировать количество зависимостей у модуля.
И, наконец, принцип инверсии зависимостей (DIP) позволяет нам зависеть в коде от абстракцией, а не от конкретных реализаций, что позволяет динамически подменять эти реализации “на лету”.
Таким образом, если соединить все это вместе, то получается, что при проектировании наших модулей мы должны:
1. В первую очередь продумать интерфейс, (LSP, DIP);
2. Этот интерфейс должен позволять создавать абстракции, изменяющиеся вследствие решений одного актора (SRP) и не позволять лишних действий (ISP);
3. Этому интерфейсу может соответствовать несколько реализаций (OSP, LSP, DIP), что даст нам возможность использовать полиморфизм;
4. Частота изменения этого интерфейса должна быть обратно пропорциональна количеству его зависимостей (SRP, OCP). | 561 |
| 8 | Кстати, чересчур гибкие и абстрактные компоненты вообще не имеют никакого смысла, потому что они ничего в себе не содержат и трудозатраты на конфигурирование такого компонента соразмерны с затратами написания логики с нуля в том месте, где необходимо использовать компонент | 590 |
| 9 | На прошлой неделе дискутировали с командой о проектировании одного из компонентов интерфейса - делать ли контент компонента абстрактным и передаваемым снаружи (через механизм children в React) или же захардкодить контент прямо внутри компонента, а на вход передавать некий конфиг, который может регулировать отображение контента. В первом случае мы сможем сделать наш компонент совсем абстрактным и можно будет рендерить в нем абсолютно любой контент, а во втором случае - контент компонента будет ограничен реализацией.
В качестве одного из аргументов в пользу первого варианта звучала фраза “Мы никогда не узнаем, как именно бизнес захочет этот компонент использовать”. По этому поводу у меня есть радикальная идея: вне зависимости от того, какой вариант вы в итоге выберете, невозможно адекватно спроектировать компонент в случае, если вы понятия не имеете, как вы его будете использовать. Для того, чтобы что-то запрограммировать, вы должны точно знать, как вы будете использовать этот компонент/класс/сервис/сущность. В институте на кафедре автоматизированных систем управления нам говорили, что для автоматизации какой-либо системы необходимо точно понимать, что за систему, собственно, вы автоматизируете. Если вы не знаете, как будет использоваться компонент/сервис/сущность/система, то первоочередная задача будет это прояснить, а для этого необходимо собрать требования к системе у бизнеса.
В нашем кейсе мы созвонились с дизайнерами, и они рассказали нам, что этот компонент планируется использовать далее с одинаковым или почти одинаковым контентом. Эта информация помогла нам однозначно выбрать второй вариант проектирования. | 540 |
| 10 | Недавно мы с Кириллом Мокевниным решили окончательно запутать людей на тему SOLID и вот что из этого получилось
P.s. И главное помните, что DIP и DI - это разные принципы.
Upd. Набираем 300 - 💡и делаем ещё один выпуск с Кириллом? | 470 |
| 11 | С огромным удовольствием посмотрела дискуссию о SOLID Кирилла Мокевнина и S0ER. По поводу SOLID у меня есть некоторое количество радикальных идей и сегодня я хочу поделиться с вами одной из них. Она звучала в ходе дискуссии, но мне хочется сделать на ней особый акцент. Я сформулирую ее следующим образом: не проект для SOLID, а SOLID для проекта.
Я периодически вижу, как начинающие разработчики, ознакомившись с принципами SOLID (и, будем честны, с любыми принципами вообще) начинают бездумно применять их везде - и где надо, и где не надо. Когда я преподавала на курсе об архитектуре фронтенд приложений, я говорила ученикам - никогда не применяйте принцип/паттерн/подход только потому, что так сказал какой-то умный дядя, применяйте, когда вы видите в этом реальный профит для вашего проекта. То же самое я советую вам: не отталкивайтесь от абстрактных принципов, отталкивайтесь от реальных нужд вашего проекта и вашей команды. Приведу несколько примеров:
❌ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что Мартин написал, что нужно соблюдать DIP
✅ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что у бизнеса есть планы на эксперименты с разными калькуляторами и поэтому удобнее не хардкодить конкретный калькулятор
❌ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что так сделано во всех библиотеках
✅ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что у нас может быть много разных вариантов нотификаций и так мы сможем использовать компонент в разных вариациях
❌ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что отображение - это зона ответственности компонента по SRP
✅ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что у нас есть дизайн система и мы должны зафиксировать варианты отображения компонента, чтобы он выглядел везде одинаково | 1 052 |
| 12 | За последние 4 месяца я трижды выступала с докладами и, как следствие, довольно много общалась с другими спикерами. Я с удивлением обнаружила следующее: многие спикеры рассказывают о себе в начале доклада не для того, чтобы слушатели поняли бекграунд, а для того, чтобы убедить слушателей, что их мнению можно доверять. Такое оправдание себя, дескать, я работал в бигтехе, а еще выступал на других конфах, поэтому я не могу сморозить херню (на самом деле любой может, конечно).
Друзья, у меня есть для вас радикальная идея: важно не КТО говорит, а ЧТО говорит. Если спикер - крутой перец и он рассказывает про какой-то подход, это не значит, что вам нужно срочно тащить его к себе. Вам нужно понять, в какой ситуации подход был применен, какой дал эффект и какая ситуация у вас. Если ваши ситуации схожи, тогда подход можно применить. Аналогично с менее известными спикерами. Короче, друзья: продуктивнее размышлять над идеей и подходом, чем над тем, достаточно ли сеньорный спикер про него рассказал. | 560 |
| 13 | На прошлой неделе прочла "Scrum" Джеффа Сазерленда. Делюсь с вами списком своих избранных цитат:
💡 Причина успеха методики проста. Я смотрел на то, как люди на самом деле работают, а не слушал то, что они говорят об этом.
💡 Любая задержка в рабочем процессе равно преступлению.
💡 Обнаружить ошибку как можно раньше и устранить.
💡 Планировать полезно. Слепо следовать плану - глупо.
💡 Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше (цитата из “Мифический человеко-месяц” Ф. Брукса).
💡 Дело было в базовой ошибке - и они ее не учли. Работники, ответственные за проект, считали, что можно спланировать все заранее.
💡 Карта - еще не живая местность.
💡 Сначала оценки работы колеблются от 400 процентов до двадцати пяти сверх реально потребовавшегося времени. Низкие и высокие оценки отличаются друг от друга в 16 раз. По мере того, как работа продвигается вперед, оценки все более приближаются к реальной величине - и так до того момента, когда уже нет никаких оценок, а есть одна реальность.
💡 Вместо того, чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта.
💡 Помните, мы говорим об оценках, а не о жестких планах.
💡 Главное, что нужно запомнить - порядок [задач в беклоге] постоянно меняется. Правильный порядок для нынешней недели уже не подойдет для следующей.
💡 Одна из плохих привычек, которая может появиться у компании из-за постоянно меняющихся потребностей рынка или из-за недопонимания руководством, в чем основная ценность - это приоритизация всего подряд. Любая мелочь становится делом первостепенной важности. “Тот, кто защищает все, не защищает ничего”.
💡 Я уже говорил о взятом из боевых искусств понятии “сюхари” (Shu Ha Ri). В состоянии Сю человек четко следует правилам, таким образом знакомясь со стоящими за ними идеями. В состоянии Ха человек начинает создавать собственный стиль, но при этом остается в границах обозначенных правил, лишь адаптируя их под свои потребности. В состоянии Ри человек окончательно избавляется от правил и создает саму идею. | 801 |
| 14 | Но ведь [framework name] сделает мое резюме дороже?
Часто разработчики считают, что чем больше технологий они знают, тем дороже они как специалисты. По этому поводу у меня есть радикальная идея: важно не столько то, ЧЕМ вы делаете, важно то, ЧТО вы делаете. Одна из основных болей при найме - это разработчики, которые пишут код, не приходя в сознание, не пытаясь понять, что за код они пишут и какую бизнес задачу они решают. Такой рабочий процесс потом отражается в виде строчек резюме “делал фичи, фиксил баги”. Какие фичи делались, зачем и для чего, какой это принесло результат и пользу бизнесу, неуточняется.
Главное, что вам нужно сделать, чтобы стать дороже, как специалист - это не изучать все подряд фреймворки, а начать разбираться в бизнес процессах компании и проекта, где вы работаете. | 756 |
| 15 | Стоит ли учить [framework name]?
Меня часто спрашивают, стоит ли что-то учить - какой-то фреймворк, какую-то библиотеку, паттерн, язык программирования и тд.
По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными.
Поэтому не нужно “учить” очередной фреймворк; однако изучение новых фреймворков, библиотек и языков помогает качать главный навык - навык программировать, отсюда вытекает следующее: нужно учить программирование, а это удобно делать при изучении новых фреймворков, библиотек, языков и паттернов. | 13 975 |
