Мой вариант решения проблемы.
Пять лет вместе со мной.
Но сделана была она на совсем уж таком древнем железе что даже есть ограничения на хранимые макросы по размеру (да, оно в памяти прямо клавиатуры хранит). И сейчас вышла версия 2.0, уже с условно безлимитом по памяти и редактором макросов на ПК.
Но покупал я не у них, а у ребят что 5 лет назад как раз, кстати, написали статью на Хабр о всех видах переключателей и клавиш. Ну и заодно открыли магазинчик нестандартных механических клавиатур. Доллар тогда был по 30, мне обошлось в 15к примерно, сейчас конечно подороже будет. Но, честно говоря, это одна из лучших покупок в моей жизни — все 5 лет я только на ней и пишу, ноутбуки не использую, так что проблем никаких.
Из главных бонусов отмечу что на большой палец у меня теперь не 1 пробел, а 12 клавиш, из них 11 уникальных. Идея поместить под большой палец энтер и бекспейс с делейтом — гениальная, действительно очень удобно. Собственно ещё есть ремап клавиш, можно переназначить все, макросы ещё, но из них у меня только один забит в память
docker-compose up --build
И ещё такой же с sudo в начале :D
Макросы хранятся в памяти самой клавиатуру, софт на десктопе не нужен. Бонусом USB разъемы 2 штуки и, для особых ценителей — можно поставить педали, 1 или 3 штуки. По мне педали не очень вещь, но кому-то может нравится.
Ну и для особых ценителей линукса — в комплекте клавиши с пингвинчиками.
Вижу что версионирование отдано на откуп отдающей стороне, с этим проблема значит всё ещё остается.
Также вижу что есть --lock флаг, который сохраняет хеш, вот это уже другой разговор, если всегда его использовать — будет хорошо, это плюс.
Но остальные проблемы не решены.
И у самого Deno есть список пакетов, которые именуются модулями, где для указания версии сейчас используется имя ветки в гите и по ней версия, это может быть удобно если всё будет на каком-нибудь гитхабе. Но есть нюанс — гитхаб из коробки поддерживает npm, а ещё Docker, Maven, NuGet, RubyGems через функционал пакаджей, то есть там уже это есть. Но не гитхабом единым, это да, однако Deno сейчас для них использует как раз таки гитхаб.
Всегда хорошо когда есть альтернативы, порождает здравую конкуренцию и развитие. Когда-то именно появление IO.js, форка ноды, подтолкнуло её к развитию, после чего они снова слились вместе и нода стала эффективно развиваться.
Но Deno пока всё ещё не выглядит как кардинальное улучшение или как сильный конкурент. Посмотрим как пойдет конечно, но выше уже написал про нюансы с импортами, например.
Node имеет официальный пакетный менеджер npm. У Deno такого менеджера нет, вместо этого он позволяет импортировать любой модуль с помощью URL.
А потом кто-то удалит очередной LeftPad и всё сломается. Или как в древней истории с jQuery, когда половина вебмастеров тупо ставила latest ссылку на CDN, куда попадала всегда именно последняя версия либы, но однажды jQuery выпустила следующую, мажерную версию, вроде 2.0, которая была без обратной совместимости, ибо ну логично, latest, последняя… и половина интернета в буквальном прямом смысле, без шуток, сломалась. Причем ладно если у сайта есть поддержка, а если это очередной сайт на бесплатном шаблоне или 5 лет уже сами менеджеры в интернет-магазинчике товары вносили… в общем боли было столько что в итоге команда jQuery заморозила latest ссылку на версии 1.0 и больше никогда не трогала, для последующих версий были уже свои латест.
И что в итоге? Deno наступает на эти грабли, осознанно, говоря что это лучшее решение! Да, это удобно во многих кейсах — просто импорт по ссылке, как в браузерах script src=«url», отлично, свой самодельный пакетный менеджер на коленке можно на раз-два сделать, тупо храня всё на своем серваке, облаке или где-то ещё, нет зависимости от одной компании… Но дело в том что у npm потому и нет каких-то особых альтернатив потому что это тупо удобно, ведь по факту никто не мешает любому сделать свой, со своими там командами, своими файлами, правилами, более того — такое делали и, возможно, будут делать. Но когда у тебя есть единый стандарт, единый поисковик — это удобно. А ещё запрет на удаление — ты всегда будешь уверен что ничего не сломается в один прекрасный момент. Добавим к этому строгое версионирование — если ты указал версию — ты уверен что ничего не сломается в ненужный момент потому что код не будет меняться, ты можешь зафиксировать версию. Либо чуть ослабить фиксацию и зафиксировать только мажерную, которая ломает обратную совместимость — тут уже на откуп разработчикам, но единый стандарт и единые правила дисциплинируют, к тому же лок-файлы добавляют ещё бонусов к фиксациям и единому окружению у разработчиков и на продакшене.
А вот механизм из Deno — не гарантирует. Не говорю уже про историю с jQuery. Также с мелкими пакетами на мелких сайтах — вполне могут ломать, вставляя зловредов. И сейчас можно, но текущая централизация всё же дает, пусть холиварно это звучит, всё же большую защиту чем пакет васи пупкина на его личном сайте, который кто-то добавит к себе потому что там удобная фича, а потом с этой фичей начнет вдруг подгружаться что-то новое, интересное и болезненное для того кто импортировал пакет, зато прибыльное для того кто это туда внедрил. Учитывая что при свежей сборке может прилететь что-то не то… Кстати, что-то ничего не было в описании этого механизма на предмет проверки целостности, хеша и вот этого всего. А ещё сейчас на странице пакета любой может зарепортить баг, есть ещё audit fix команда и прочее такое. Но кто сделает это на частном сайте в интернете?
В общем — на мой взгляд это очень плохой шаг, решением может стать только появление… подобия npm, только с загрузкой по ссылке-импорту. Но к чему мы меняем так кардинально, может просто добавить в npm такую функциональность?
Возможно я не прав и написал тут что-то не то, не понимая сути. Но тогда я буду рад если кто-то укажет где я не прав.
На самом деле такое уже было. У Facebook. Ну и у других соцсетей локальных, типа того же ВК. Зачем тебе сайт если можно сделать всё там? Владельцы соцсети сами сделают всё адаптивно, под все устройства, сделают мобильное приложение, защитят тебя от DDoS, дадут рекламную площадку, сделают всё-всё. Просто нужно быть внутри. Собственно так и вышло — не весь интернет туда уехал, но нормальный такой кусок, а некоторые не очень большие компании только в соцсетях и имели аккаунты, да и сейчас так. Но в Китае посильнее централизовали.
К слову, если так, очень-очень абстрактно подумать — Телеграмм то это клон этой Китайской штуки… Ну или не клон, лишь идейно, но суть и цель примерно та же. Надеюсь не обидел чьих-то чувств, но так, если взглянуть, покрутить-посмотреть — любопытно выходит, тренды интересные — во главе теперь общение, динамика, а не статическая информация.
В итоге и плюсы и минусы имеем — плюсы описал — платформа, дает тебе всё и сразу, бесплатно обычно всё кроме рекламы, которой всё и окупается. Минусы — они владеют тобой и могут закрыть твой бизнес очень быстро, особенно если ты только там и есть, ну и прочее. К слову, если так подумать, то iOS и Android, в некотором роде, тоже самое, вспомним с одной стороны недавние скандалы с внутренними платежами и Apple, с другой — доступ к миллионам клиентов. Скорее всего это будет бесконечная битва централизаций на разных уровнях. В Китае победили вот эти ребята.
Добавлю к вышеперечисленному — стейт машины.
Если писать классический бекенд, то маловероятно что это будет нужно. Но если это телеграм-бот какой-нибудь — уже более. А если какой-нибудь биржевой торговый робот — уже вполне себе так. Ну и всякие сервисные штуки что раз в какое-то время что-то делают и могут иметь стейты. В общем применений больше чем может казаться.
Когда-то я писал нечто на вот этом — opalrb.com
Это Ruby в браузере. И оно даже работало у меня в продакшене. Но лучше не надо.
Вообще это известная тема когда какой-то язык переводят в JS чтобы работать в браузере, будь то полная трансляция в JS или же с рантайм-движком, но что-то особо не слышно громких проектов которые бы это действительно полноценно использовали.
А так вообще были реализации полноценных виртуальных машин на JS, в которой можно запустить Linux, в которой можно запустить нужный язык или открыть браузер… нувыпонели. Но по продакшену всё же вопросы.
Телепортировали меня в 2013, тогда как раз был популярен этот компилер и проекты с goog.
Но спираль всё же развернулась, теперь TS силен и много проектов на нем, вот и до Closure Compiler докаталась волна.
Вообще забавно, с одной стороны исходниками, а не каким-нибудь байт-кодом скрипты распространяются в том числе чтобы код видеть, но во благо оптимизации, а иногда обфускации, оно всё же пережимается в нечто среднее, из которого исходный код особо не восстановишь, особенно после этого интструмента, весить становится мало, да, но ощущение что где-то по пути мы обманули самих себя. А потом ещё когда map файлы… в общем спираль крутится.
Так всё просто — есть проблема с одинаковым окружением. Кстати, решение этой проблемы сделало docker таким популярным, например. Тут типа того — разные версии пакетов, иногда и минорно, могут иметь разное поведение. И единственный адекватный кейс — всегда устанавливать именно то окружением что задумывалось разработчиком, иначе это будет порождать пляски с бубном на продакшене и прочее такое. Это плохо, уж лучше пакетов побольше, но всё же стабильная работа.
Ну и вторая причина количества пакетов вообще — любовь к мелкой модульности без таскания целых библиотек. Более того — некоторые популярные библиотеки представляют цельную версию и к ней по модулю на каждую входящую функцию — чтобы разработчик мог взять только одну или несколько, а не тащить с собой 100500 функций ради использования лишь одной. Разве это плохо? Вроде как очень даже хорошо. Ну а то что на npm сайте так много модулей — ну и что, больше выбора наоборот же.
В общем какая-то злая статья без понимания механизмов почему так. Не, конечно некоторые разработчики некоторых пакетов могут лишнее таскать, качество пакетов может быть сомнительным, как и эффективность — но так то это и в любом другом бывает, будь то Ruby или .NET экосистема. А с общим механизмом пакетов всё вполне себе.
Аналогичная проблема была лет 6 назад. Выводилась реклама, в том числе под свежеустановленным Linux, на всех страницах без https, правда с таким нюансом что на первом подключении ничего не было, но со второго и далее — баннеры, при этом судя по всему только на популярных сайтах в свободных от контента местах, ребята заморочились, да, возможно чтобы скрыть факт того что реклама не от реального сервиса. Проблема также оказалась в роутере, что-то туда было дописано извне, в моем случае был просто куплен новый, имелся в этом смысл, баннеры исчезли навсегда.
Возможно у автора аналогичная проблема, хотя всё же похоже больше на вмешательство провайдера.
Тут выше упоминался golos.io и свободу слова. Увы, прилетающие запросы от Роскомнадзора приходится исполнять и запрещённый контент оттуда быстро исчезает… но исчезает из выдачи, оригиналы навечно остаются в блокчейне и доступны через просмотрощик блоков, включая всю историю правок и всё всё всё. Но у голоса было несколько сайтов что выводили контент, был что не скрывал запрещёнку. Закончилось просто баном на территории России.
К слову, вышла новая версия этой штуки, но уже для всего мира, на базе нового блокчейна (но той же линейки, тоже графен). commun.com
Могу что-либо рассказать о мире таких штук как собственно бывший разработчик Голоса.
Но а так, как верно выше заметили — простым людям это не нужно, а для не простых — уже есть десяток проектов на все случаи жизни, но что-то вот доминирующего, который победил бы всех и был на слуху, что-то вот нет. Возможно потому что оно и не нужно. А то «потому что могу» делать всегда хорошо, но лучше сначала понять какую проблему оно решает и для кого, только не взглядом идеалиста, а взглядом прагматика. Но как техническая задача — это весело. Но может лучше присоединиться к существующему проекту?
Очень большое отождествление NodeJS и Express, хотя в названии именно NodeJS. Ну и код в примерах от 2014 года и ранее, так уже не пишут, для веба 5 лет это много, тем более революция с ES6/2015 превратила язык в почти другой.
Очень старые советы, пожалуйста, не применяйте их бездумно.
Или устанавливают правила. Либо поручают машине исполнить договоренность, но чтобы она соответствовала указанным инструкциям. Ну и ещё есть всякие там голосования делегатов за форки. В результате, абстрактно, это взаимодействие и машин и людей в некоторых из квантов времени. Суммарно всё конечно исходит от людей и договариваются люди с людьми, но через посредников-машин. Но это уже философские темы получаются.
Пять лет вместе со мной.
Но сделана была она на совсем уж таком древнем железе что даже есть ограничения на хранимые макросы по размеру (да, оно в памяти прямо клавиатуры хранит). И сейчас вышла версия 2.0, уже с условно безлимитом по памяти и редактором макросов на ПК.
Сайт производителя:
kinesis-ergo.com/shop/advantage2
Но покупал я не у них, а у ребят что 5 лет назад как раз, кстати, написали статью на Хабр о всех видах переключателей и клавиш. Ну и заодно открыли магазинчик нестандартных механических клавиатур. Доллар тогда был по 30, мне обошлось в 15к примерно, сейчас конечно подороже будет. Но, честно говоря, это одна из лучших покупок в моей жизни — все 5 лет я только на ней и пишу, ноутбуки не использую, так что проблем никаких.
Из главных бонусов отмечу что на большой палец у меня теперь не 1 пробел, а 12 клавиш, из них 11 уникальных. Идея поместить под большой палец энтер и бекспейс с делейтом — гениальная, действительно очень удобно. Собственно ещё есть ремап клавиш, можно переназначить все, макросы ещё, но из них у меня только один забит в память
docker-compose up --build
И ещё такой же с sudo в начале :D
Макросы хранятся в памяти самой клавиатуру, софт на десктопе не нужен. Бонусом USB разъемы 2 штуки и, для особых ценителей — можно поставить педали, 1 или 3 штуки. По мне педали не очень вещь, но кому-то может нравится.
Ну и для особых ценителей линукса — в комплекте клавиши с пингвинчиками.
Вижу что версионирование отдано на откуп отдающей стороне, с этим проблема значит всё ещё остается.
Также вижу что есть --lock флаг, который сохраняет хеш, вот это уже другой разговор, если всегда его использовать — будет хорошо, это плюс.
Но остальные проблемы не решены.
И у самого Deno есть список пакетов, которые именуются модулями, где для указания версии сейчас используется имя ветки в гите и по ней версия, это может быть удобно если всё будет на каком-нибудь гитхабе. Но есть нюанс — гитхаб из коробки поддерживает npm, а ещё Docker, Maven, NuGet, RubyGems через функционал пакаджей, то есть там уже это есть. Но не гитхабом единым, это да, однако Deno сейчас для них использует как раз таки гитхаб.
Всегда хорошо когда есть альтернативы, порождает здравую конкуренцию и развитие. Когда-то именно появление IO.js, форка ноды, подтолкнуло её к развитию, после чего они снова слились вместе и нода стала эффективно развиваться.
Но Deno пока всё ещё не выглядит как кардинальное улучшение или как сильный конкурент. Посмотрим как пойдет конечно, но выше уже написал про нюансы с импортами, например.
А потом кто-то удалит очередной LeftPad и всё сломается. Или как в древней истории с jQuery, когда половина вебмастеров тупо ставила latest ссылку на CDN, куда попадала всегда именно последняя версия либы, но однажды jQuery выпустила следующую, мажерную версию, вроде 2.0, которая была без обратной совместимости, ибо ну логично, latest, последняя… и половина интернета в буквальном прямом смысле, без шуток, сломалась. Причем ладно если у сайта есть поддержка, а если это очередной сайт на бесплатном шаблоне или 5 лет уже сами менеджеры в интернет-магазинчике товары вносили… в общем боли было столько что в итоге команда jQuery заморозила latest ссылку на версии 1.0 и больше никогда не трогала, для последующих версий были уже свои латест.
И что в итоге? Deno наступает на эти грабли, осознанно, говоря что это лучшее решение! Да, это удобно во многих кейсах — просто импорт по ссылке, как в браузерах script src=«url», отлично, свой самодельный пакетный менеджер на коленке можно на раз-два сделать, тупо храня всё на своем серваке, облаке или где-то ещё, нет зависимости от одной компании… Но дело в том что у npm потому и нет каких-то особых альтернатив потому что это тупо удобно, ведь по факту никто не мешает любому сделать свой, со своими там командами, своими файлами, правилами, более того — такое делали и, возможно, будут делать. Но когда у тебя есть единый стандарт, единый поисковик — это удобно. А ещё запрет на удаление — ты всегда будешь уверен что ничего не сломается в один прекрасный момент. Добавим к этому строгое версионирование — если ты указал версию — ты уверен что ничего не сломается в ненужный момент потому что код не будет меняться, ты можешь зафиксировать версию. Либо чуть ослабить фиксацию и зафиксировать только мажерную, которая ломает обратную совместимость — тут уже на откуп разработчикам, но единый стандарт и единые правила дисциплинируют, к тому же лок-файлы добавляют ещё бонусов к фиксациям и единому окружению у разработчиков и на продакшене.
А вот механизм из Deno — не гарантирует. Не говорю уже про историю с jQuery. Также с мелкими пакетами на мелких сайтах — вполне могут ломать, вставляя зловредов. И сейчас можно, но текущая централизация всё же дает, пусть холиварно это звучит, всё же большую защиту чем пакет васи пупкина на его личном сайте, который кто-то добавит к себе потому что там удобная фича, а потом с этой фичей начнет вдруг подгружаться что-то новое, интересное и болезненное для того кто импортировал пакет, зато прибыльное для того кто это туда внедрил. Учитывая что при свежей сборке может прилететь что-то не то… Кстати, что-то ничего не было в описании этого механизма на предмет проверки целостности, хеша и вот этого всего. А ещё сейчас на странице пакета любой может зарепортить баг, есть ещё audit fix команда и прочее такое. Но кто сделает это на частном сайте в интернете?
В общем — на мой взгляд это очень плохой шаг, решением может стать только появление… подобия npm, только с загрузкой по ссылке-импорту. Но к чему мы меняем так кардинально, может просто добавить в npm такую функциональность?
Возможно я не прав и написал тут что-то не то, не понимая сути. Но тогда я буду рад если кто-то укажет где я не прав.
К слову, если так, очень-очень абстрактно подумать — Телеграмм то это клон этой Китайской штуки… Ну или не клон, лишь идейно, но суть и цель примерно та же. Надеюсь не обидел чьих-то чувств, но так, если взглянуть, покрутить-посмотреть — любопытно выходит, тренды интересные — во главе теперь общение, динамика, а не статическая информация.
В итоге и плюсы и минусы имеем — плюсы описал — платформа, дает тебе всё и сразу, бесплатно обычно всё кроме рекламы, которой всё и окупается. Минусы — они владеют тобой и могут закрыть твой бизнес очень быстро, особенно если ты только там и есть, ну и прочее. К слову, если так подумать, то iOS и Android, в некотором роде, тоже самое, вспомним с одной стороны недавние скандалы с внутренними платежами и Apple, с другой — доступ к миллионам клиентов. Скорее всего это будет бесконечная битва централизаций на разных уровнях. В Китае победили вот эти ребята.
А вот по поводу let, const — всё же можно:
Блоки нам в этом помогут.
Если писать классический бекенд, то маловероятно что это будет нужно. Но если это телеграм-бот какой-нибудь — уже более. А если какой-нибудь биржевой торговый робот — уже вполне себе так. Ну и всякие сервисные штуки что раз в какое-то время что-то делают и могут иметь стейты. В общем применений больше чем может казаться.
Это Ruby в браузере. И оно даже работало у меня в продакшене. Но лучше не надо.
Вообще это известная тема когда какой-то язык переводят в JS чтобы работать в браузере, будь то полная трансляция в JS или же с рантайм-движком, но что-то особо не слышно громких проектов которые бы это действительно полноценно использовали.
А так вообще были реализации полноценных виртуальных машин на JS, в которой можно запустить Linux, в которой можно запустить нужный язык или открыть браузер… нувыпонели. Но по продакшену всё же вопросы.
P.S. Боже, как же я стар, 10 лет прошло…
Но спираль всё же развернулась, теперь TS силен и много проектов на нем, вот и до Closure Compiler докаталась волна.
Вообще забавно, с одной стороны исходниками, а не каким-нибудь байт-кодом скрипты распространяются в том числе чтобы код видеть, но во благо оптимизации, а иногда обфускации, оно всё же пережимается в нечто среднее, из которого исходный код особо не восстановишь, особенно после этого интструмента, весить становится мало, да, но ощущение что где-то по пути мы обманули самих себя. А потом ещё когда map файлы… в общем спираль крутится.
Так всё просто — есть проблема с одинаковым окружением. Кстати, решение этой проблемы сделало docker таким популярным, например. Тут типа того — разные версии пакетов, иногда и минорно, могут иметь разное поведение. И единственный адекватный кейс — всегда устанавливать именно то окружением что задумывалось разработчиком, иначе это будет порождать пляски с бубном на продакшене и прочее такое. Это плохо, уж лучше пакетов побольше, но всё же стабильная работа.
Ну и вторая причина количества пакетов вообще — любовь к мелкой модульности без таскания целых библиотек. Более того — некоторые популярные библиотеки представляют цельную версию и к ней по модулю на каждую входящую функцию — чтобы разработчик мог взять только одну или несколько, а не тащить с собой 100500 функций ради использования лишь одной. Разве это плохо? Вроде как очень даже хорошо. Ну а то что на npm сайте так много модулей — ну и что, больше выбора наоборот же.
В общем какая-то злая статья без понимания механизмов почему так. Не, конечно некоторые разработчики некоторых пакетов могут лишнее таскать, качество пакетов может быть сомнительным, как и эффективность — но так то это и в любом другом бывает, будь то Ruby или .NET экосистема. А с общим механизмом пакетов всё вполне себе.
Возможно у автора аналогичная проблема, хотя всё же похоже больше на вмешательство провайдера.
А в NodeJS удобно использовать этот сайт — https://node.green/
Как только LTS версия ноды делает шаг вперёд — самое время проверять чего добавили и изучать если что было пропущено.
BigInt уже там давно и лично продакшн код с ним писал, а вот например штуки с опциональным чейнингом посвежее.
А ещё можно наблюдать как в язык завозят приватные свойства и, судя по всему, скоро завезут и приватные методы.
Вообще там есть чего почитать и будущее прикинуть, один из мной любимых сайтов по фичам и развитию языка уже многие годы.
Тут выше упоминался golos.io и свободу слова. Увы, прилетающие запросы от Роскомнадзора приходится исполнять и запрещённый контент оттуда быстро исчезает… но исчезает из выдачи, оригиналы навечно остаются в блокчейне и доступны через просмотрощик блоков, включая всю историю правок и всё всё всё. Но у голоса было несколько сайтов что выводили контент, был что не скрывал запрещёнку. Закончилось просто баном на территории России.
К слову, вышла новая версия этой штуки, но уже для всего мира, на базе нового блокчейна (но той же линейки, тоже графен). commun.com
Могу что-либо рассказать о мире таких штук как собственно бывший разработчик Голоса.
Но а так, как верно выше заметили — простым людям это не нужно, а для не простых — уже есть десяток проектов на все случаи жизни, но что-то вот доминирующего, который победил бы всех и был на слуху, что-то вот нет. Возможно потому что оно и не нужно. А то «потому что могу» делать всегда хорошо, но лучше сначала понять какую проблему оно решает и для кого, только не взглядом идеалиста, а взглядом прагматика. Но как техническая задача — это весело. Но может лучше присоединиться к существующему проекту?
Очень большое отождествление NodeJS и Express, хотя в названии именно NodeJS. Ну и код в примерах от 2014 года и ранее, так уже не пишут, для веба 5 лет это много, тем более революция с ES6/2015 превратила язык в почти другой.
Очень старые советы, пожалуйста, не применяйте их бездумно.