Прочитав статью, я вспомнил, почему мне не понравилось работать с аутсорс разработкой. Когда-то я работал в стартапе и у нас не хватало ресурсов, чтобы доставлять фичи. Мы заказали часть проекта в аутсорс компании. В итоге, весь код, при первой же возможности весь код, который нам написали аутсорс разработчики, был переписан. Потому что с точки зрения выполнения задачи, придраться было не к чему – все работало, как и задумывалось. Но код был такой, что поддерживать это всё было совершенно невозможно.
И читая про ваш подход "нормально будешь делать в продукте, а раз ты аутсорс, то делай так, чтобы отдать и забыть", я для себя понимаю, что заказывать разработку у вас бы не стал.
Мне кажется, что перед "берешь и пишешь хороший код" пропущено несколько очень важных других этапов, как-то:
берешь и долго учишь операторы и реактивных подход работы RxJs, попутно страдая. Потом страдаешь, пытаясь комбинировать то что успел выучить и тратя в X раз больше времени на решение, казалось бы, простой фичи, которая в имеративном стиле реализуется двумя if
разбираешься в DI, как это все работает и зачем нужно, потому что до этого вроде и без него все работало
Досмотрел этот тред и после всех этих обсуждений типа "да тут надо подтюнить в конфигах и обернуть в все в функцию, которая будет пропатчивать что-то, чтобы ворнинги не сыпались" начальное утверждение "да mobx в тысячу раз проще" выглядит уже не таким однозначным =)
Спасибо за цикл статей, с большим интересом прочитал и, на сколько это возможно было, вник в многопоточность в ноде, не смотря на то, что в текущей моей фронтэндерско/фуллстечной действительности это вряд ли когда-то пригодится.
Это перевод, поэтому, наверное, лучше задавать вопросы в оригинальной статье. =) Но вообще там раскрыто дальше:
Управлять повторным рендерингом компонентов, например, можно, пропуская через пайп только те события, возникновение которых подразумевает необходимость в повторном рендеринге.
Меньше ререндеров – больше производительность. Логика, видимо, такая.
Я скорее к тому, что если фреймворк для решения довольно простой задачи вынуждает использовать намного более сложный путь с кучей оверинжениринга (а навешивание и удаление хэндлеров событий при помощи intersection observer вместо того, чтобы сделать делегирование выглядит крайним овериженирингом), то что-то идет не так.
Есть такой приём, называется event delegation. Он использовался еще во времена jQuery. Позволяет избежать лишних обработчиков событий, а также сложностей с тем, чтобы эти обработчики навешивать и убирать. Один обработчик сразу на все несколько тысяч элементов.
На тестовой странице КриптоПро подписание проходит удачно.
В госуслуги не заходит.
Установка Chromium более старой версии не помогает.
По поводу п.7 не понял – там описано как переустановить сертификаты, если перестало работать.
Спасибо, но перед тем как спросить я погугли по теме :). Этого кода там больше нет. И в другой ветке форума написано, что то, ссылку на что вы дали, уже исправили. И исправленного кода тоже в js на сайте я не нашел.
Также видел предположение, что дело в старом криптопро. Поставить пятую версию тоже не помогает.
Что-то у меня идет не так. При проверке подписи в личном кабинете ФНС проверка повисает с ошибкой: failed to sign hash: invalid algorithm specified. (0x80090008)
У кого-нибудь было такое? В чем может быть проблема?
Прочитав статью, я вспомнил, почему мне не понравилось работать с аутсорс разработкой. Когда-то я работал в стартапе и у нас не хватало ресурсов, чтобы доставлять фичи. Мы заказали часть проекта в аутсорс компании. В итоге, весь код, при первой же возможности весь код, который нам написали аутсорс разработчики, был переписан. Потому что с точки зрения выполнения задачи, придраться было не к чему – все работало, как и задумывалось. Но код был такой, что поддерживать это всё было совершенно невозможно.
И читая про ваш подход "нормально будешь делать в продукте, а раз ты аутсорс, то делай так, чтобы отдать и забыть", я для себя понимаю, что заказывать разработку у вас бы не стал.
Мне кажется, что перед "берешь и пишешь хороший код" пропущено несколько очень важных других этапов, как-то:
берешь и долго учишь операторы и реактивных подход работы RxJs, попутно страдая. Потом страдаешь, пытаясь комбинировать то что успел выучить и тратя в X раз больше времени на решение, казалось бы, простой фичи, которая в имеративном стиле реализуется двумя if
разбираешься в DI, как это все работает и зачем нужно, потому что до этого вроде и без него все работало
А зачем?
Досмотрел этот тред и после всех этих обсуждений типа "да тут надо подтюнить в конфигах и обернуть в все в функцию, которая будет пропатчивать что-то, чтобы ворнинги не сыпались" начальное утверждение "да mobx в тысячу раз проще" выглядит уже не таким однозначным =)
Спасибо за цикл статей, с большим интересом прочитал и, на сколько это возможно было, вник в многопоточность в ноде, не смотря на то, что в текущей моей фронтэндерско/фуллстечной действительности это вряд ли когда-то пригодится.
Тоже пришёл посмотреть, как так получилось что пост из 2010 оказался у меня в ленте вдруг.
Мне кажется, стоит об этом упомянуть в тексте, чтобы было понятно, для чего вообще весь этот оверхед с настройкой module federation нужен.
А чем это удобнее, чем динамически вставлять
<script>со ссылкой на нужный бандл?Адрес можно брать json, сгенеренный тем же webpack.
Не сочтите за троллинг, но из статьи действительно не понятно в чем тут простота.
Меньше ререндеров – больше производительность. Логика, видимо, такая.
А конкретно, пункт e)
В госуслуги не заходит.
Установка Chromium более старой версии не помогает.
По поводу п.7 не понял – там описано как переустановить сертификаты, если перестало работать.
Пробовал в разное время, не помогает
Спасибо, но перед тем как спросить я погугли по теме :). Этого кода там больше нет. И в другой ветке форума написано, что то, ссылку на что вы дали, уже исправили. И исправленного кода тоже в js на сайте я не нашел.
Также видел предположение, что дело в старом криптопро. Поставить пятую версию тоже не помогает.
У кого-нибудь было такое? В чем может быть проблема?
Вот это устойчивый к воздействиям кирпич с большим аккумулятором =)
А S750 – вполне компактный, в меру защищеный телефончик.