Да, голосом я про это говорил, а в статье не упомянул. Но в целом появление гитхаб регистри мало что поменяло — можно было и до этого прекрасно ставит пакеты с гитхаба, используя теги или в худшем случае кеши. Минус только один — это не прокатывало для пакетов с этапом prepublish.
Чисто для справки — в одном из моих проектов сейчас 10.000 транзитивных зависимостей. Так что я знаю, о чём говорю.
Относительно ваших кейсов:
NPM виноват в настройке вашего VPN? А чем бы вам помог другой менеджер пакетов? Так проблема хотя бы решается при помощи переключения, прокси регистри или локального кеша нужного пакета. А вот в случае с deno — я не уверен, что проблему вообще было бы возможно решить — возможно, приложение бы падало, ничего не установив… Ну а в лучшем случае точно так же пришлось бы переключаться.
Ну так стандартная проблема мерджа. С кодом случается ровно то же самое.
Обычно это проявляется гораздо быстрее — ты быстро понимаешь по юнит тестам, что именно упало, и быстро видишь по лок файлу, кто виноват. Опять же, здесь косяк авторов пакетов, которые не указали корректный скоуп зависимостей через semver.
Опять же это обычно сразу видно на код ревью — ты мгновенно замечаешь, что был закоммичен левый пекедж лок. Хотя нет. Даже раньше. Если пользуешься npm ci на билд сервере, то он сразу расскажет про расхождение package.json и package-lock.json.
Ну и главное. Я не говорю, что решение идеально. Просто всё познаётся в сравнении. И из всего того дерьма для управления зависимостями, с которым я работал последние 10 лет, npm — просто конфетка. А в данном посте я говорю даже не про это, а про сравнение npm с тем, что придумали в Deno.
Зато мой бенчмарк имеет хоть какое-то отношение к вопросу.
И я его не искал, а взял первый попавшийся. В данном случае у меня просто нет "желаемого".
Серьёзно — как на основании фреймворков можно сравнивать ивент лупы? Сравнение на основании длины бороды авторов было бы и то более релевантным.
И ещё пара вещей, которые мне кажутся весьма очевидными.
Вы код libuv или tokio видели?
Там просто недостаточно простора, чтобы rust успел себя показать.
И даже если случится алгоритмическое чудо, и растовый вариант станет быстрее, то огромное комьюнити быстро заберёт это чудо и в libuv, после чего скорость сравняется обратно.
Да, я тут подумал — наверное, вы решили, что я говорю, что tokio теоретически не может быть быстрее libuv. Если что — нет — я говорю о том, что этого не будет на практике, по крайней мере, пока у libuv достаточно большое сообщество.
Для этого есть прокси регистри и артефакты сборки. Да и если уж на то пошло — можно точно так же упороться и класть в гит node modules, deno для этого не нужен.
Опять же, чтобы потерять исходники npm пакета — нужно, чтобы одновременно упал npm и github.
Полностью согласен, ротация обязательно должна быть — при этом в целом нет никакой разницы, какой архитектурой вы пользуетесь. Если вкратце:
1) Увеличивается bus factor;
2) Разные команды тащат свои лучшие практики;
3) Часто каждый следующий участник, который не понимает, как работает написанный до него код, разбирается и делает его проще;
4) Добавляется документация, становятся проще тесты, деплой и запуск;
5) Все разработчики получают знания о каких-то инструментах, которые применяют другие команды.
Главное — принять, что не существует какого-то сакрального знания, из-за которого над конкретным проектом должен работать только конкретный человек.
При этом, правда, у нас остаётся понятие code owners — это те ребята, которые готовы подхватить сервис в случае срочных проблем, и следят, чтобы другая команда не сделала код хуже.
Раз пять пытался придумать смешной комментарий про то, что даже сам термин "гостевой книги" ушёл в небытие уже лет 10 как… Но смешнее, чем заголовок поста в сочетании с тегами и 2019 годом — не выходит.
Вероятно, имелась в виду установка пакета с ключом -g, иначе непонятно, куда его ставит автор. Если же пакет ставится в проект, который исследуется, то этим самым меняется его древо зависимостей, что очень странно (я понимаю, что это демо, но всё же).
Кроме этого, совсем непонятно, зачем после установки пакет запускается через npx. Если так можно, то зачем его ставили локально? А если нужно ставить локально — то почему его не запускают локально?
В общем, пояснения о переводчика пригодились бы. Кстати, забавно, что переводится статья с английского, написанная явно русскоязычным автором. Смайлик.
Теперь по сути. Морда discovery в целом забавная и можно найти ей применения. Насчёт jora — вроде уже есть jq, чем, как вы считаете, jora лучше?
Видимо, вы невнимательно читали статью.
Основной целью как раз является решение вопроса SMM, а не оттока покупателей. Поэтому я и говорю, что система работает. Считать подход ущербным можно, но это совершенно другой спор.
Отток она тоже явно уменьшает, но насколько — этот вопрос неочевидный и вторичный.
Ну и мне просто любопытно — а как вы бы предложили удержать клиента, который не идёт на контакт и при первом прецеденте перестаёт пользоваться вашим сервисом? Надеюсь, ответ будет не "всё сразу делать везде идеально"...
У меня голова занята гораздо более важными вещами, чем решение куда переставить скидку.
Лайфхак — говорите "оставить". И не думаете об этом.
У меня есть стандартный алгоритм — подошёл, поставил корзину, " пакет не нужен, по куар коду, оставить, картой", получил продукты. Всё.
А те, кто играют в игру, те платят информацией о себе.
Я так понимаю, вы не пользуетесь сервисами гугла, яндекса, Амазона, интернет банкингом и смартфоном? Или сеть продуктовых магазинов с вашей точки зрения особо опасна?
У вас были какие-то случаи, когда люди молча выкидывали продукты, и не давали фидбек, и вы проецируете это на всех, и считаете, что система не работает. Не надо так!
Система отлично работает, пользовался ей пару раз, и это весьма мало, при условии, что закупаюсь там постоянно.
Ну и да — здесь речь шла не столько про то, чтобы получить фидбек, сколько про то, чтобы переместить его из соцсетей в магазины. Подозреваю, что чаще всего люди, которым лень отнести в магазин испорченный товар, и в соцсети постить не будут. Так что всё отлично работает.
Повторюсь — 99% разработки это Java, на которой можно писать и без эмулятора на древнейшем компьютере.
Дальше остаётся засунуть это в андроидный бойлерплейт и раскидать кнопочки — что тоже по большей части можно сделать без эмулятора. Можно даже проверить, что всё это добро собирается. остаётся совсем немного работы по отладке — но в целом и без этого можно уже послать код куда-нибудь на вакансию. Ещё можно одолжить у кого-нибудь телефон на последний этап. Или попросить кого-нибудь удалённо протестировать ваш apk.
Читать книжки — это важно, и можно в том числе читать книжки по разработке. Но для этого более рационально использовать что-нибудь вроде kindle — стоит дёшево, живёт вечно.
Для того, чтобы научиться разработке на Android… Вам не нужно устройство на Android… Достаточно эмулятора. А можно и без него, поскольку 99% нужных навыков это разработка на Java/Kotlin.
все эти разговоры, что где-то там забирают новичков с руками и ногами, что программистов не хватает… Где? Я не вижу.
Наша компания специально открыла офисы в нескольких городах в РФ, Украине и Белоруссии. И мы готовы брать джунов и обучать их. На этой неделе выходят два человека с почти нулевым опытом в Москву и в Тверь. И мы в этом ваще не уникальны. Скину в личку ссылку на вакансии, чтобы было понятно, что они есть.
Или они смотрят на меня, как на программиста с уровнем ниже 0.
А вот этого я не понял. А какое отношение вы ожидаете? С отсутствием какого-либо опыта вам предложат либо позиция джуна, либо тестировщика или суппорта с возможностью дорасти до разработчика.
Да, голосом я про это говорил, а в статье не упомянул. Но в целом появление гитхаб регистри мало что поменяло — можно было и до этого прекрасно ставит пакеты с гитхаба, используя теги или в худшем случае кеши. Минус только один — это не прокатывало для пакетов с этапом prepublish.
Чисто для справки — в одном из моих проектов сейчас 10.000 транзитивных зависимостей. Так что я знаю, о чём говорю.
Относительно ваших кейсов:
NPM виноват в настройке вашего VPN? А чем бы вам помог другой менеджер пакетов? Так проблема хотя бы решается при помощи переключения, прокси регистри или локального кеша нужного пакета. А вот в случае с deno — я не уверен, что проблему вообще было бы возможно решить — возможно, приложение бы падало, ничего не установив… Ну а в лучшем случае точно так же пришлось бы переключаться.
Ну так стандартная проблема мерджа. С кодом случается ровно то же самое.
Обычно это проявляется гораздо быстрее — ты быстро понимаешь по юнит тестам, что именно упало, и быстро видишь по лок файлу, кто виноват. Опять же, здесь косяк авторов пакетов, которые не указали корректный скоуп зависимостей через semver.
Опять же это обычно сразу видно на код ревью — ты мгновенно замечаешь, что был закоммичен левый пекедж лок. Хотя нет. Даже раньше. Если пользуешься npm ci на билд сервере, то он сразу расскажет про расхождение package.json и package-lock.json.
Ну и главное. Я не говорю, что решение идеально. Просто всё познаётся в сравнении. И из всего того дерьма для управления зависимостями, с которым я работал последние 10 лет, npm — просто конфетка. А в данном посте я говорю даже не про это, а про сравнение npm с тем, что придумали в Deno.
Зато мой бенчмарк имеет хоть какое-то отношение к вопросу.
И я его не искал, а взял первый попавшийся. В данном случае у меня просто нет "желаемого".
Серьёзно — как на основании фреймворков можно сравнивать ивент лупы? Сравнение на основании длины бороды авторов было бы и то более релевантным.
И ещё пара вещей, которые мне кажутся весьма очевидными.
Вы код libuv или tokio видели?
Там просто недостаточно простора, чтобы rust успел себя показать.
И даже если случится алгоритмическое чудо, и растовый вариант станет быстрее, то огромное комьюнити быстро заберёт это чудо и в libuv, после чего скорость сравняется обратно.
Да, я тут подумал — наверное, вы решили, что я говорю, что tokio теоретически не может быть быстрее libuv. Если что — нет — я говорю о том, что этого не будет на практике, по крайней мере, пока у libuv достаточно большое сообщество.
Зачем мне оправдывать результаты бенчмарки фреймворка?
Это не имеет никакого отношения к ивент лупу.
Даже такой бенчмарк ближе к истине.
У меня есть здравый смысл. А у вас есть бенчмарк по фреймворкам, который не имеет отношения к скорости ивент лупа.
И я не писал, что Rust реализация будет медленнее. Я писал, что в лучшем случае она будет не медленнее.
Не туда ответил.А ещё для эстетов есть ts-node.
Ага. Ещё был chakra core node и spider node. Но они оба RIP.
Не, тот же самый v8. На расте ивент луп, системные функции и прочая обвязка.
Для этого есть прокси регистри и артефакты сборки. Да и если уж на то пошло — можно точно так же упороться и класть в гит node modules, deno для этого не нужен.
Опять же, чтобы потерять исходники npm пакета — нужно, чтобы одновременно упал npm и github.
Полностью согласен, ротация обязательно должна быть — при этом в целом нет никакой разницы, какой архитектурой вы пользуетесь. Если вкратце:
1) Увеличивается bus factor;
2) Разные команды тащат свои лучшие практики;
3) Часто каждый следующий участник, который не понимает, как работает написанный до него код, разбирается и делает его проще;
4) Добавляется документация, становятся проще тесты, деплой и запуск;
5) Все разработчики получают знания о каких-то инструментах, которые применяют другие команды.
Главное — принять, что не существует какого-то сакрального знания, из-за которого над конкретным проектом должен работать только конкретный человек.
При этом, правда, у нас остаётся понятие code owners — это те ребята, которые готовы подхватить сервис в случае срочных проблем, и следят, чтобы другая команда не сделала код хуже.
Раз пять пытался придумать смешной комментарий про то, что даже сам термин "гостевой книги" ушёл в небытие уже лет 10 как… Но смешнее, чем заголовок поста в сочетании с тегами и 2019 годом — не выходит.
Матерь божья, я и не знал, что npx умеет локальные пакеты запускать — всегда использовал только для запуска пакетов из регистри без установки.
Вероятно, имелась в виду установка пакета с ключом -g, иначе непонятно, куда его ставит автор. Если же пакет ставится в проект, который исследуется, то этим самым меняется его древо зависимостей, что очень странно (я понимаю, что это демо, но всё же).
Кроме этого, совсем непонятно, зачем после установки пакет запускается через npx. Если так можно, то зачем его ставили локально? А если нужно ставить локально — то почему его не запускают локально?
В общем, пояснения о переводчика пригодились бы. Кстати, забавно, что переводится статья с английского, написанная явно русскоязычным автором. Смайлик.
Теперь по сути. Морда discovery в целом забавная и можно найти ей применения. Насчёт jora — вроде уже есть jq, чем, как вы считаете, jora лучше?
Видимо, вы невнимательно читали статью.
Основной целью как раз является решение вопроса SMM, а не оттока покупателей. Поэтому я и говорю, что система работает. Считать подход ущербным можно, но это совершенно другой спор.
Отток она тоже явно уменьшает, но насколько — этот вопрос неочевидный и вторичный.
Ну и мне просто любопытно — а как вы бы предложили удержать клиента, который не идёт на контакт и при первом прецеденте перестаёт пользоваться вашим сервисом? Надеюсь, ответ будет не "всё сразу делать везде идеально"...
Лайфхак — говорите "оставить". И не думаете об этом.
У меня есть стандартный алгоритм — подошёл, поставил корзину, " пакет не нужен, по куар коду, оставить, картой", получил продукты. Всё.
Я так понимаю, вы не пользуетесь сервисами гугла, яндекса, Амазона, интернет банкингом и смартфоном? Или сеть продуктовых магазинов с вашей точки зрения особо опасна?
У вас были какие-то случаи, когда люди молча выкидывали продукты, и не давали фидбек, и вы проецируете это на всех, и считаете, что система не работает. Не надо так!
Система отлично работает, пользовался ей пару раз, и это весьма мало, при условии, что закупаюсь там постоянно.
Ну и да — здесь речь шла не столько про то, чтобы получить фидбек, сколько про то, чтобы переместить его из соцсетей в магазины. Подозреваю, что чаще всего люди, которым лень отнести в магазин испорченный товар, и в соцсети постить не будут. Так что всё отлично работает.
Повторюсь — 99% разработки это Java, на которой можно писать и без эмулятора на древнейшем компьютере.
Дальше остаётся засунуть это в андроидный бойлерплейт и раскидать кнопочки — что тоже по большей части можно сделать без эмулятора. Можно даже проверить, что всё это добро собирается. остаётся совсем немного работы по отладке — но в целом и без этого можно уже послать код куда-нибудь на вакансию. Ещё можно одолжить у кого-нибудь телефон на последний этап. Или попросить кого-нибудь удалённо протестировать ваш apk.
Читать книжки — это важно, и можно в том числе читать книжки по разработке. Но для этого более рационально использовать что-нибудь вроде kindle — стоит дёшево, живёт вечно.
Для того, чтобы научиться разработке на Android… Вам не нужно устройство на Android… Достаточно эмулятора. А можно и без него, поскольку 99% нужных навыков это разработка на Java/Kotlin.
Наша компания специально открыла офисы в нескольких городах в РФ, Украине и Белоруссии. И мы готовы брать джунов и обучать их. На этой неделе выходят два человека с почти нулевым опытом в Москву и в Тверь. И мы в этом ваще не уникальны. Скину в личку ссылку на вакансии, чтобы было понятно, что они есть.
А вот этого я не понял. А какое отношение вы ожидаете? С отсутствием какого-либо опыта вам предложат либо позиция джуна, либо тестировщика или суппорта с возможностью дорасти до разработчика.