Мне кажется, что важно не переборщить с эмпатией. Ведь если ты неискренне интересуешься делами коллеги, то и ответ будет формально-дежурный. А спустя какое-то время еще и раздражать начнет.
Довелось работать в одной распределенной компании с матричной структурой, где мой ресурсный менеджер жил в другом городе. В течение года в мессенджере он щедро отсыпал мне смайликов и скобочек. А когда я написал заявление об уходе, то в течение отработки хоть бы один смайлик прислал
Спасибо. Как уже отметили выше, проблема перехода на ARM заключается как раз в обратной совместимости и договоренностях с другими производителями железяк для компьютера.
Никогда нельзя исключать и человеческий фактор, ведь принимает решение об экспериментах в области применения ARM тоже человек — СЕО — а он может и не верить в ARM в силу субъективных суждений
Спасибо за статью, очень много полезной информации. В своих проектах я пришел к использованию специальный классов-DTO для обмена объектами и состоянием между компонентами на одной странице вместо множества Input() и Output().
Понятнее будет показать на примере.
Родительский компонент и код создания класса DTO. Тут компонент, который работает с принимаемым объектом. Иногда даже я вызываю в компонентах не собственные методы, а публичные методы таких классов-провайдеров данных.
Одним из плюсов считаю обленченную возмонжность тестирования класса-провайдера, а также "тонкий" компонент, который лишь отображает поля провайдера и вызывает его методы. Из минусов разве что велосипедостроительство и перформанс приложения — создание объектов для отрисовки и хранение в полях сервисов требует памяти, но это скорее интуитивное мое соображение.
Я не фронтендер, поэтому буду благодарен, если автор статьи или любой другой фронтендер посмотрит мой подход и либо похвалит, либо распишет минусы, которые не вижу я
Да, верно, не совсем очевидно стало, что было 43, а осталось 27, и все эти 27 представлены в статье. Спасибо за уточнение.
Спросил про публичность репозитория именно из-за того, что думал, что есть еще что-то в списке. Если же нет, то вопрос отпадет. Не знаю как другим читателям, но мне достаточно статьи и этой ссылки на hackmd. Спасибо
В списке правил есть конфиденциальная информация? Хочется прочесть все 43 пункта в репозитории. Планируете ли сделать репозиторий с правилами публичным?
В одном из интервью Егора спросили, почему он так радикально выдвигает тезисы, хотя его собственный код изобилует теми же паттернами и решениями, которые подвергаются критике. Егор ответил, что делает такие безапелляционные заявление намеренно. Будь формулировки вида "статические классы можно использовать, но лучше так не делать" не вызовут такого резонанса и не привлекут к себе внимания такого же, как "статические классы зло, и все программисты, использующие их, расписываются в своей непригодности".
Цитаты неточные, интервью было АйТи Бороде, если не ошибаюсь, но искать конкретные таймкоды не берусь
Хоть тут принято ругать подходы Егора Бугаенко, он уже писал в своей книге Elegant Objects о том, что геттеры и сеттеры — это не ООП и зря были добавлены в Java. Книга, в первую очередь, с примерами на Java.
Советую почитать эту книгу, и тогда не только в использовании геттеров/сеттеров появится сомнение, а код станет чище и "модульней" за счет применения большинства рекомендаций
мой ответ был на замечание, что можно было в примере сделать повторяемый рандом, а не "настоящий". Тогда в рандоме как таковом и смысла нет, и можно было бы подставить N раз разные числа, записанные в атрибуте [InlineData(1)]. Это пример из xUnit для .NET
Хорошая статья и примеры. Работа с цветом при оформлении веб-сайта для большинства разработчиков — это из области субъективного ощущения «нравится/не нравится», но от того и сложно придумать цветовую схему такую, чтобы она не повторяла другие сайты, знакомые авторам. Эта статья даёт хотя бы качественное обоснование выбора цвета. Спасибо
Имплементить OnDestroy не обязательно в компоненте? В примерах в статье и на Гитхаб нет этого интерфейса в ChildComponent, а в примере на сайте npm — есть
Спасибо за рекомендацию
Действительно так. Исправлю в статье. Спасибо за замечание
Мне кажется, что важно не переборщить с эмпатией. Ведь если ты неискренне интересуешься делами коллеги, то и ответ будет формально-дежурный. А спустя какое-то время еще и раздражать начнет.
Довелось работать в одной распределенной компании с матричной структурой, где мой ресурсный менеджер жил в другом городе. В течение года в мессенджере он щедро отсыпал мне смайликов и скобочек. А когда я написал заявление об уходе, то в течение отработки хоть бы один смайлик прислал
Спасибо, исправил
Спасибо. Как уже отметили выше, проблема перехода на ARM заключается как раз в обратной совместимости и договоренностях с другими производителями железяк для компьютера.
Никогда нельзя исключать и человеческий фактор, ведь принимает решение об экспериментах в области применения ARM тоже человек — СЕО — а он может и не верить в ARM в силу субъективных суждений
В оригинале "which manufactures chips for AMD and Apple today", поэтому тут опечатка. Уже исправил. Спасибо за замечание
Если М1 — красавчик, то почему оригинальная статья — реклама в худшем виде?
не очень понял отсылки к переработанному дизайну Кинопоиска и его резкому внедрению пару лет назад. gazpar, можете объяснить, пожалуйста
Чтобы не дублировать код "геттера" и "сеттера" переменной состояния
Спасибо за статью, очень много полезной информации. В своих проектах я пришел к использованию специальный классов-DTO для обмена объектами и состоянием между компонентами на одной странице вместо множества Input() и Output().
Понятнее будет показать на примере.
Родительский компонент и код создания класса DTO. Тут компонент, который работает с принимаемым объектом. Иногда даже я вызываю в компонентах не собственные методы, а публичные методы таких классов-провайдеров данных.
Одним из плюсов считаю обленченную возмонжность тестирования класса-провайдера, а также "тонкий" компонент, который лишь отображает поля провайдера и вызывает его методы. Из минусов разве что велосипедостроительство и перформанс приложения — создание объектов для отрисовки и хранение в полях сервисов требует памяти, но это скорее интуитивное мое соображение.
Я не фронтендер, поэтому буду благодарен, если автор статьи или любой другой фронтендер посмотрит мой подход и либо похвалит, либо распишет минусы, которые не вижу я
Да, верно, не совсем очевидно стало, что было 43, а осталось 27, и все эти 27 представлены в статье. Спасибо за уточнение.
Спросил про публичность репозитория именно из-за того, что думал, что есть еще что-то в списке. Если же нет, то вопрос отпадет. Не знаю как другим читателям, но мне достаточно статьи и этой ссылки на hackmd. Спасибо
В списке правил есть конфиденциальная информация? Хочется прочесть все 43 пункта в репозитории. Планируете ли сделать репозиторий с правилами публичным?
Затем, что не все хотят скачивать музыку на устройство
В одном из интервью Егора спросили, почему он так радикально выдвигает тезисы, хотя его собственный код изобилует теми же паттернами и решениями, которые подвергаются критике. Егор ответил, что делает такие безапелляционные заявление намеренно. Будь формулировки вида "статические классы можно использовать, но лучше так не делать" не вызовут такого резонанса и не привлекут к себе внимания такого же, как "статические классы зло, и все программисты, использующие их, расписываются в своей непригодности".
Цитаты неточные, интервью было АйТи Бороде, если не ошибаюсь, но искать конкретные таймкоды не берусь
Хоть тут принято ругать подходы Егора Бугаенко, он уже писал в своей книге Elegant Objects о том, что геттеры и сеттеры — это не ООП и зря были добавлены в Java. Книга, в первую очередь, с примерами на Java.
Советую почитать эту книгу, и тогда не только в использовании геттеров/сеттеров появится сомнение, а код станет чище и "модульней" за счет применения большинства рекомендаций
мой ответ был на замечание, что можно было в примере сделать повторяемый рандом, а не "настоящий". Тогда в рандоме как таковом и смысла нет, и можно было бы подставить N раз разные числа, записанные в атрибуте [InlineData(1)]. Это пример из xUnit для .NET
тогда можно на random.org сгенерить число в диапазоне и захардкодить его в юниттесте.
Хорошая статья и примеры. Работа с цветом при оформлении веб-сайта для большинства разработчиков — это из области субъективного ощущения «нравится/не нравится», но от того и сложно придумать цветовую схему такую, чтобы она не повторяла другие сайты, знакомые авторам. Эта статья даёт хотя бы качественное обоснование выбора цвета. Спасибо
Понятно, спасибо
Имплементить OnDestroy не обязательно в компоненте? В примерах в статье и на Гитхаб нет этого интерфейса в ChildComponent, а в примере на сайте npm — есть