DEV Community: Даниил Пронин

Как установить купленный WarCraft III: The Frozen Throne в 2025 году?

Даниил Пронин — Thu, 07 Aug 2025 16:46:23 +0000

Так случилось, что в детстве мне удалось купить два диска с WarCraft III: Reign of Chaos и The Frozen Throne. Два диска с лицензионными ключами на внутренней стороне коробки.

Фотка не моя, нашёл в интернете - сейчас я уже и не помню, где они. Но мои были точно такими же.

Когда у меня появился интернет, я зарегистрировал оба кода в профиле на сайте battle.net.

Спустя ещё несколько лет (где-то в 2018, кажется) я захотел поиграть с друзьями в варик по сети. У меня уже был макбук тогда. На battle.net я обнаружил, что скачать игру не получается - ссылка не работала. А на торрентах официальную сборку под мак найти не удалось. Тогда я поиграл в пиратский репак через BootCamp, маки были ещё на Intel.

И вот спустя ещё несколько лет Blizzard выпускают WarCraft: Reforged. Сразу же подумалось, что WarCraft III они полностью удалят отовсюду, а купивших его будут гайлайтить кнопкой "купи рефорж".

Но нет, у меня в профиле на сайте battle.net всё ещё есть обе купленные игры. В самом низу страницы Игры и подписка есть обе игры, и ключи к ним. И ссылка "Загрузить" возле каждой.

Ссылка ведёт на страницу Как установить Warcraft III: Reforged и Warcraft III: Ледяной Трон, на которой есть четыре ссылки: две игры под Windows, и две под macOS.

Я скачал The Frozen Throne, запустил Downloader_Warcraft3_The_Frozen_Throne_enUS.exe, и меня встретило странное окно, предлагающее сохранить куда-нибудь http_404_webOC, или открыть его.

Я его сохранил, и тогда вылезло следующее окно, предлагающее выбрать папку:

Я выбрал, и скачивание началось, но без режима Peer-to-peer. И верхняя часть окна сломана.

По окончанию загрузки меня встретило напоминание о том, почему я купил два диска, а не один.

Скриншот на русском, так как он был сделал чуть позже по хронологии событий. Просто представьте, что он на английском.

Кнопка "Купить" ведёт на страницу https://eu.shop.battle.net/en-us/product/warcraft-iii-reign-of-chaos, но по ней ожидает только разочарование:

Со страницы Как установить я скачал Reign of Chaos, и мне удалось установить обе игры, и они запустились.

Но на английском языке.

А я хочу ту самую локализацию: никто не смеет мне приказывать!

Русский язык

Я погуглил, и вспомнил, что переключить язык установленной игры никак нельзя. Только удалить и / или установить поверх русскую версию. Полный установщик.

(Есть смутные воспоминания, что были какие-то патчи, которые тогда регулярно выходили, вечно ломая доту, но не уверен, что были языковые патчи.)

Вот все ссылки с той страницы:

https://us.battle.net/download/getLegacy?product=WAR3&locale=enUS&os=WIN
https://us.battle.net/download/getLegacy?product=W3XP&locale=enUS&os=WIN
https://us.battle.net/download/getLegacy?product=WAR3&locale=enUS&os=MAC
https://us.battle.net/download/getLegacy?product=W3XP&locale=enUS&os=MAC

Если в ссылке поменять enUS на ruRU, то скачается русская версия.

Для RoC и TFT под Windows нужны вот такие:

https://us.battle.net/download/getLegacy?product=WAR3&locale=ruRU&os=WIN
https://us.battle.net/download/getLegacy?product=W3XP&locale=ruRU&os=WIN

По ним скачиваются Downloader_Warcraft3_Reign_of_Chaos_ruRU.exe и Downloader_Warcraft3_The_Frozen_Throne_ruRU.exe - загрузчики, после работы которых будут скачаны папки War3-1.27-Installer-ruRU-ROC и War3-1.27-Installer-ruRU-TFT.

Учитывая, в каком это всё отвратительном состоянии, мне кажется, что я просто обязан теперь всё скачанное выложить на торренты. Однажды Blizzard точно доломают и без того хромой и косой процесс доступа к лицензионной игре. (Интересно, Battle.net всё ещё работает в ней?)

Видеоролики

Я точно помню, как TFT запускается: сверху спускается правая часть главного меню с кнопками. Но у меня игра при запуске показывает сначала чёрный экран, а потом меню уже на своём месте, без спуска. Но это я переживу.

А не переживу я то, что в видеороликах есть звук, но нет видео.

Проблема в том, что с Windows 11 не поставляется тех кодеков, которые нужны игре. Решается проблема установкой K-Lite Codec Pack. Я решил подстраховаться, и скачал Mega. Эх, если бы кто знал, какой именно кодек нужен игре.

macOS

Самое интересное для меня сейчас - это работа всего этого же, но на маке.

Я скачал скачиватель RoC под Mac, но он отказался запускаться

И есть даже подозрение, что это даже не из-за того, что программа скачивания была написана под архитектуру Intel, а я пытаюсь запускать её на Apple Silicon (M1). Есть же Rosetta 2. Скорее всего это из-за того, что она 32-битная, и тут уже надо начинать какой-то пердолинг с эмуляцией.

Пока я не разобрался с этим, но интерес и желание есть. Дополню статью, если разберусь. Какой-нибудь Game Porting Toolkit 2, или что-то с Rosetta 2.

Можно ли заменить базы данных Notion с помощью Obsidian?

Даниил Пронин — Sat, 23 Mar 2024 17:57:50 +0000

Я очень активно пользуюсь базами данных в Notion для организации связных данных. Связывать множество таблиц между собой — отличный способ организовать мою свадьбу, например. Или все внутренние дела страйкбольного клуба (я был секретарём).

Но отсутствие нормального оффлайна в Notion жёстко вставляет палки в колёса. А ещё он иногда разлогинивает. Не очень такое способствует задачам вроде "быстро накидать пару идей", достав телефон из кармана — нажав на иконку Notion, я часто видел либо экран входа, либо попытку синхронизации (например, когда я в лифте), в общем — я стал чаще пользоваться Apple Notes.

И вот пришёл хайп на Obsidian. Мол, он заменит Notion. Ладно, попробуем.

Obsidian обеспечивает оффлайн организацией всех данных в файлах Markdown. Локально. Синхронизация — через Dropdox, например. Или любое другое облако, хоть собственный сервер NextCloud или ownCloud.

Ладно, что там с БД? В Notion это пушка просто, миллион фич и всё отлично работает. А есть ли такое у Obsidian?

У Obsidian по-умолчанию только голые файлы Markdown в папках. Чтобы навернуть что-то посложнее, надо ставить плагины. Этим он и славится — кто угодно можно создать плагин, и все смогут им пользоваться. Стек — веб-страница.

Поищем:

На реддите сразу ошарашивают:

НЕТ ВЫ НЕ ДОЛЖНЫ ПЫТАТЬСЯ ЗАМЕНИТЬ ОДИН ИНСТРУМЕНТ ДРУГИМ

(первый же развёрнутый ответ, который говорит мне, что вопрос просто так не решится — сворачиваю, читаю дальше)

Database Folder

Ок, выглядит как то что нам нужно. Поставим его и его зависимость DataView.

Выглядит сомнительно.

Типы колонок вроде те что надо:

Тут и Relation, и Rollup, и формула.

Попытаюсь перетащить мою табличку модов для майнкрафта.

Ок, сразу вижу, что не хватает типа колонки для ссылок. Ладно, надеюсь, Markdown сам поймёт, что текст в ячейке это ссылка.

Выглядит либо как что-то сломанное, либо как результат неквалифицированного труда.

Ладно, заполним несколько строк:

Дальше с этим плагином возиться мне как-то не хочется.

Что там ещё есть из плагинов?

MAKE.md

Скриншоты на сайте более обнадёживают. Попробуем.

Немного потыкавшись, становится понятно, как с этим работать:

создаём Space (или New Space from Note)
переключаем Files на Table View

С этого момента становится похоже на Notion.

Добавляя колонки, сразу же наблюдаю баг: если ввести её имя, потом выбрать тип — меню закрывается, ничего не появляется. Нужно сначала создать колонку с дефолтным типом, а потом поменять его.

Заполняя первую колонку, нахожу следующий: теги не добавляются. Ок, попробую вместо тегов сделать Option с функцией Multiple.

Следующая проблема: галочка "Multiple" нажимается только если целиться в галочку, но подсвечивается вся строка меню, намекая, что нажимать можно в любом её месте.

Следующая проблема: вот это вот меню постоянно появляется, и уже в виде нескольких копий, что понятно по чернейшей тени под ними:

Мда.

Ладно, попробуем заполнить ещё две строки.

Вводить теги становится сложновато

Следующая проблема: в пустой ячейке колонки Option нет введённых в других строках вариантов.

Может, нужен другой тип колонки? Но нет, теги-то вообще не работают. Чепуха какая-то.

Цвет опции поменять нельзя:

Если это — лучшая альтернатива Notion, то я пока пас.

Пойду, поищу ещё.

Datacore

У проекта пока что есть только репозиторий, в описании которого нет ничего про установку плагина.

Скриншотов тоже нет.

В Community plugins тоже его нет.

DataLoom

Сразу позиционирует себя как то, что я ищу.

Не стал уже пытаться перенести моды, просто потыкал.

Вижу, что нет Relation:

Нажимается он неплохо, но без Relation и Rollup далеко не уедешь.

Projects

Немного не туда, но тоже таблица.

Правда, типов колонок вообще жесть как мало:

Вывод

Погуглив ещё немного, я нашёл на форуме Obsidian очень много таких же как и я. Некоторые предлагают одно из решений выше, некоторые просто ноют. Некоторые обсуждают решения вроде Siyuan, но это уже не Obsidian, там свой сервер поднимать надо.

Нет, я не могу заменить Notion на Obsidian. До свидания.

Vue 3 Composition API + socket.io

Даниил Пронин — Thu, 26 May 2022 08:48:32 +0000

Migrating from Vue 2 to Vue 3, you might want to start using Composition API.

If you want to use socket.io you can search 'vue 3 socket.io' and find vue-3-socket.io. You will see following in it's readme:

this.sockets.subscribe('EVENT_NAME', (data) => {
    this.msg = data.message;
});

But Vue 3 Composition API is about to use setup() or <script setup> and there's no this.

So you have to use socket.io directly, without Vue plugin:

socket.io.js

export const useSocketIO = () => {
    const socket = io('ws://localhost:3000')
    return {
        socket,
    }
}

MyComponent.vue

<script>
import { defineComponent } from 'vue'
export default defineComponent({
    setup() {
        const { socket } = useSocketIO()
        socket.on('welcome', () => { console.log('welcome') })
    }
})
</script>

But why not just export socket from socket.io.js and import it in a component? If I do that, I can emit events but cannot subscribe on them. Maybe it's because I use Quasar 2 with SSR mode.

Why you don't have to commit node_modules folder

Даниил Пронин — Mon, 04 Apr 2022 06:09:38 +0000

English | Russian

This note is an answer to questions you can guess reading Jack Franklin blog post.

No need for npm installs

Once you check your node_modules in, there's no need to run an install step before you can get up and running on the codebase

git works bad with a lot of files in repository. You can search “git performance many files” in Google and see a lot of info about this. For example: Just as git does not scale well with large files, it can also become painful to work with when you have a large number of files
Some packages are platform dependent. For example, development tools, such as dart-sass.
If you commit node_modules it means any developer can change any dependency with ease (it's called “monkey patching”), and this definitely will lead to a problem: when you will update this changed dependency, old changes will be lost, and you have to solve that. You never will be sure that dependency of certain version have the same code that you got initially.

This isn't just useful for developers locally, but a big boost for any bots you might have running on a Continuous Integration platform (e.g. CircleCI, GitHub Actions, and so on). That's now a step that the bots can miss out entirely.

Usually, CI is configured to cache dependencies to not download them all each time.
You can google it with something like “ci node_modules cache”.

Guaranteed replicated builds

Having your node_modules checked in guarantees that two developers running the code are running the exact same code with the exact same set of dependencies

This is a work for lock file — a file you have to commit in which your package manager (NPM/PNPM/Yarn) writes all needed info for each downloaded dependency for guaranteed replicated build.

If you open yarn.lock you can see something like this:

"@apideck/better-ajv-errors@^0.2.4":
  version "0.2.5"
  resolved "https://registry.yarnpkg.com/@apideck/better-ajv-errors/-/better-ajv-errors-0.2.5.tgz#b9c0092b7f7f23c356a0a31600334f7b8958458b"
  integrity sha512-Pm1fAqCT8OEfBVLddU3fWZ/URWpGGhkvlsBIgn9Y2jJlcNumo0gNzPsQswDJTiA8HcKpCjOhWQOgkA9kXR4Ghg==
  dependencies:
    json-schema "^0.3.0"
    jsonpointer "^4.1.0"
    leven "^3.1.0"

Yarn carefully recorded that package @apideck/better-ajv-errors is downloaded with:

version 0.2.5
by address resolved (direct link to .tgz)
hashsum was sha512-Pm1fAqCT8OE...
there was 3 dependencies

And so on for each dependency in node_modules folder. Next time while yarn install will run in project directory, all dependencies will be downloaded using yarn.lock information, not package.json. Therefore all development team and CI, regardless of platform (Linux/macOS/Windows) have the same files, the same code, with the same hashsums.

Yes, this can be managed by a package-lock.json file, or other tools, but I've seen all of them slip up rarely or allow a slight variation in a minor version number that causes issues.

This mistake is often made when, when deploying a project, the developer runs npm install, which installs packages based on information from package.json, not package-lock.json. To install packages from the lock file, you need to run npm ci.

Better awareness of the code you're shipping

I've been surprised at how more aware I am of adding dependencies when the git diff shows me the entirety of the code that is being added to the project. This has lead us to make contributions to tools to help reduce their file size on disk and have a better awareness of the impact a dependency will have on our bundle size.

When choosing dependencies, you can use special tools, and not just read miles of code.

Bundlephobia

It will show how much the dependency weighs, how much it will be with GZIP, how long it will be downloaded over slow 3G and medium 4G Internet, it will show the percentage of the composition of the sub-dependencies, what the dependency exports (if it is written in ES Modules), as well as what alternatives or neighboring packages it has. Here's [email protected]" rel="noopener noreferrer">example.
bundlejs.com

It will show exactly how many kilobytes of code will be added when importing like
```
import { map } from "nanostores"
```
Look at nanostores example.
npm.anvaka.com

It will show a graph of all dependencies in the form of a 2D or 3D graph. Look at Vue 3 example.

More consideration to adding a dependency because it's not invisible

I mentioned earlier that people see the noise in a git diff as a downside to adding dependencies to version control, and I do acknowledge that it can be a downside to this approach, but I've found that noise to often be a useful signal. Adding that one extra dependency because I don't want to write a few lines of code myself is something I used to do frequently - but now I'm much more considered because I can see the code that's being added and can reflect on if it's worth it.

You can read the code befure it added as a dependency to your project. GitHub repository for example. I strongly advise you to at least briefly look at the dependencies, the adequacy of the code, the number of open issues and the date of the last commit.

Note: this doesn't mean that we don't have dependencies! There are times where it is worth it to add a dependency - but seeing the code in version control has made me more considered about doing it - the cost is no longer invisible.

It was never been invisible.

You can manage the large diffs

There is no shying away from the fact that if a developer works on a change that adds a new dependency, there could be a lot of noise in the diff. One of our dependencies that we check in is TypeScript, and every time we update that, the git diff is huge and frankly not worth looking at (beyond the CHANGELOG). We've come up with a rule that helps us here: a change that updates node_modules may not touch any other code in the codebase. So if I update node_modules/typescript with its latest version, I will be warned by our tooling if any other folder outside of node_modules is changed.

You lead to a workaround.

This rule serves us well the majority of the time, because any work that relies on a new or updated dependency can be split into two changes:

Update the dependency

Use the dependency in the code

There are times where this doesn't work; updating TypeScript may require us to update some code to fix errors that the new version of TypeScript is now detecting. In that case we have the ability to override the rule.

And here are the consequences of using that workaround.

Protection from another left pad

The now infamous left_pad incident, where a popular npm package was removed from the repository all of a sudden, causing builds everywhere to break, would not have impacted a team who checked all their dependencies into git. They would still have to deal with the long term impact of "what do we do with this now unsupported dependency", but in the short term their builds wouldn't break and they wouldn't be blocked on shipping new features.

I remember that day when left_pad was removed from NPM. I worked in a digital agency on websites, and, of course, in all the projects for which I was responsible, left_pad was a sub-dependency. We solved this problem then in about half an hour when CI showed 404 when trying to download the package. I don't remember what exactly we did, but such a task should not be a challenge and a reason to make workarounds.

In the end, to protect your projects against exactly such problems, you can raise your proxy registry, for example, using Verdaccio. It will keep all copies of all downloaded packages.

Почему не надо коммитить папку node_modules

Даниил Пронин — Mon, 04 Apr 2022 06:01:52 +0000

English | Русский

Эта заметка — ответы на вопросы, которые могут возникнуть при чтении статьи Джека Франклина в переводе For Web.

Нет нужды в npm install

Если вы храните node_modules в git, вам не нужно отдельно устанавливать зависимости, чтобы запустить проект.

git плохо работает с большим количеством файлов в репозитории. Поиск фразой “git performance many files” показывает много полезной информации об этом. Например, вот: Just as git does not scale well with large files, it can also become painful to work with when you have a large number of files
Некоторые пакеты зависят от платформы. Например, инструменты для разработки, такие как dart-sass.
Если вы закоммитили node_modules, это значит, что у любого разработчика теперь есть лёгкий способ что-либо исправить в любой из зависимостей (это называется “monkey patching”), и это определённо точно приведёт к тому, что после обновления этой “исправленной” зависимости прошлое исправление будет перетёрто, и с этой проблемой придётся как-то разбираться. Вы вообще не будете уверены в том, что зависимость определённой версии соответствует тому виду, в котором она была изначально получена.

Это полезно не только для локальной разработки, но и для ботов на CI-платформах: они могут полностью пропустить шаг установки зависимостей.

CI обычно настраивают так, чтобы зависимости кешировались, и не устанавливались каждый раз с нуля. Гуглить фразой “ci node_modules cache”.

Гарантированно воспроизводимые сборки

Хранение node_modules в git гарантирует, что два разработчика запускают один и тот же код с одним и тем же набором зависимостей.

Эту проблему решает “лок-файл” — специальный файл, который нужно коммитить, в который пакетный менеджер (NPM/PNPM/Yarn) записывает о каждой скачанной зависимости все необходимые данные для гарантии воспроизводимой сборки.

Если заглянуть в yarn.lock, можно увидеть следующее:

"@apideck/better-ajv-errors@^0.2.4":
  version "0.2.5"
  resolved "https://registry.yarnpkg.com/@apideck/better-ajv-errors/-/better-ajv-errors-0.2.5.tgz#b9c0092b7f7f23c356a0a31600334f7b8958458b"
  integrity sha512-Pm1fAqCT8OEfBVLddU3fWZ/URWpGGhkvlsBIgn9Y2jJlcNumo0gNzPsQswDJTiA8HcKpCjOhWQOgkA9kXR4Ghg==
  dependencies:
    json-schema "^0.3.0"
    jsonpointer "^4.1.0"
    leven "^3.1.0"

Yarn заботливо записал, что он скачал пакет @apideck/better-ajv-errors:

версии 0.2.5
по адресу resolved (прямая ссылка на .tgz)
хеш-сумма файла была sha512-Pm1fAqCT8OE...
и у этого пакета было 3 зависимости

И так для каждой зависимости, размещённой в папке node_modules. И в следующий раз, когда в папке проекта будет запущена команда yarn install, зависимости будут скачаны не тех версий, что указаны в package.json, а те, что записаны в yarn.lock. Следовательно, у всей команды и на CI независимо от платформы (Linux/macOS/Windows) будет один и тот же набор файлов, один и тот же код, с одними и теми же хеш-суммами.

Да, этого можно добиться, используя локфайлы или другие инструменты, однако я встречал случаи, когда они не спасали от изменения минорной версии какой-либо зависимости.

Эту ошибку часто допускают, когда при развёртывании проекта у разработчика запускается npm install, который устанавливает пакеты по информации из package.json, а не package-lock.json. Чтобы установить пакеты из лок-файла, нужно запускать npm ci.

Лучшая осведомлённость о поставляемом коде

Я был удивлён тем, насколько я стал осведомлённее касательно зависимостей, когда стал видеть в диффе git весь код, попадающий в проект при их подключении. Это побудило нас поработать над инструментами, помогающими оценить влияние зависимостей на размер бандла и оптимизировать занимаемое на диске место.

При выборе зависимостей можно пользоваться специальными инструментами, а не просто читать километры кода.

Bundlephobia

Покажет, сколько весит зависимость, сколько будет с GZIP, как долго она будет скачиваться по медленному 3G и по среднему 4G-интернету, покажет в процентном соотношении состав под-зависимостей, что зависимость экспортирует (если она написана на ES Modules), а также какие у неё есть альтернативы или соседние пакеты. Вот [email protected]" rel="noopener noreferrer">пример.
bundlejs.com

Покажет, сколько точно в килобайтах будет добавлено кода при импорте вроде
```
import { map } from "nanostores"
```
Посмотрите это на примере nanostores.
npm.anvaka.com

Покажет график всех зависимостей в виде 2D или 3D-графика. Посмотрите на примере Vue 3

Более вдумчивое добавление зависимостей, потому что они больше не скрыты

Я уже упоминал, что шум в диффах воспринимается людьми как недостаток хранения зависимостей в git, и я признаю, что это действительно может быть проблемой. Однако для меня этот шум оказался полезным знаком. Раньше я часто подключал новые зависимости, просто потому что не хотел сам писать несколько строчек кода. Теперь же я гораздо внимательнее отношусь к добавлению новых зависимостей, потому что я могу увидеть добавленный ими код и решить, стоит ли он того.

Вы можете прочитать код и до того, как добавить зависимость в проект. Например, зайдя в репозиторий на GitHub. Крайне советую хотя бы мельком смотреть зависимости, адекватность кода, количество открытых issue и дату последнего коммита.

Примечание: это не означает, что у нас нет зависимостей! Бывают ситуации, когда подключить зависимость выгодно, но видимость кода в системе контроля версий сделала меня более осознанным — цена добавления зависимостей больше не скрыта.

Она никогда и не была скрыта.

C большими диффами можно справиться

Нельзя игнорировать тот факт, что добавление или обновление зависимостей может вызвать много шума в диффе. Одна из наших зависимостей — TypeScript, и каждое его обновление приносит огромный дифф в git, который, честно говоря, не стоит просмотра (за пределами CHANGELOG). Мы пришли к правилу, которое помогает в таких ситуациях: изменения в node_modules должны быть отделены от любых изменений в основной кодовой базе. Так что если я обновлю node_modules/typescript до свежей версии, наш инструментарий предупредит меня при обнаружении изменений за пределами node_modules.

Вы пришли к костылю.

Это правило помогает нам в большинстве случаев, потому что любая задача, требующая добавления или обновления зависимостей, может быть разделена на две части:

Обновление или добавление зависимости

Использование зависимости в коде

Иногда это не работает: например, обновление TypeScript может потребовать от нас исправления в коде ошибок, которые теперь обнаруживает новая версия TypeScript. В таких случаях мы отменяем правило.

И вот последствия хождения на костылях.

Защита от очередного left_pad

Печально известный инцидент с left_pad (популярный npm-пакет был внезапно удалён, ломая сборки проектов по всему миру) не затронул бы команду, которая хранит зависимости в git. В долгосрочной перспективе команде всё ещё пришлось бы разбираться с вопросом «что теперь делать с более не поддерживаемой зависимостью», но в краткосрочной перспективе их сборки бы не сломались, а релизы бы не были заблокированы.

Я помню тот день, когда left_pad был удалён с NPM. Я тогда работал в digital-агентстве на потоке сайтов, и, конечно же, во всех проектах, за которые я был ответственен, left_pad был под-зависимостью. Мы решили эту проблему тогда примерно за полчаса, когда CI показал 404 при попытке скачать пакет. Я уже не помню, что именно мы предприняли, но такая задача не должна быть вызовом и поводом городить костыли.

В конце концов, для защиты от именно таких проблем, вы можете поднять у себя прокси-реестр, например, с помощью Verdaccio. Он будет хранить у себя все копии всех скачанных пакетов.

migrate from nvm to asdf

Даниил Пронин — Mon, 04 Apr 2022 06:00:42 +0000

TL;DR

With ASDF, you can manage version of Node, Yarn, PNPM, PHP, Python, and more than 400 other tools, languages and binaries.

Uninstall nvm
Install asdf
Install nodejs plugin for asdf

Add legacy_version_file = yes to ~/.asdfrc file
Install gnupg
Install global Node version using asdf install nodejs lts

Set is as global default using asdf global nodejs lts
Open your project folder and install Node version mentioned in .nvmrc using asdf install

When you open this folder again, asdf will set this version automatically

Detailed manual

1. Uninstall `nvm`

No need to remove all installed Node versions one-by-one. They all are placed in ~/.nvm folder, so just remove it:

$ cd ~
$ rm -rf .nvm .nvmrc

Then, remove NVM initiation scripts from your .bashrc / .zshrc / etc.

Find this line:

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

You may have a Deeper Shell Integration script to install Node version as you cd into a folder.

To ensure NVM is successfully uninstalled, just find any nvm words into your run configurations.

To test NVM is properly uninstalled, just open a new terminal session and you should do not have any errors or warnings related to NVM.

Also, Node is not in your $PATH now, and you should see following in your command line:

$ node -v
command not found: node

2. Install `asdf`

Open "Download asdf" section of "Getting Started" page on asdf-vm.com and copy installation line. When this instruction was written, there was the following:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.8.1

You may have a different version since asdf will be updated in future.

Then, add initiating script to your .bashrc / .zshrc:

. $HOME/.asdf/asdf.sh

3. Install `nodejs` plugin for `asdf`

asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git

To allow using old .nvmrc files, add legacy_version_file = yes to ~/.asdfrc file

4. To start downloading Node you have to install `gnupg`

For macOS, simplest way is to install it using Homebrew, like this:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
(it takes some time to install Homebrew)
$ brew install gnupg
(it takes some time too)

For Ubuntu, you already have all requirements to use asdf.

5. Install global Node version

asdf syntax to install a tool versions is asdf install <plugin name> <version>, so run following:

asdf install nodejs lts

Then, set is as global default:

asdf global nodejs lts

After this, you can use Node again

$ node -v
v16.13.1

6. Install Node for your project

Open your project folder and run:

asdf install

Ready to go.

When you open this folder again, asdf will set this version automatically.

How to Mock an API with random data from NodeJS

Даниил Пронин — Mon, 04 Apr 2022 05:58:44 +0000

As a frontend developer, you often need data from an API. But sometimes the backend hasn't been set up by your team. In order for you to continue and mock your data, it's a good idea to not store your data structure on memory.

It's a good idea to start as soon as possible to talk with an external API where your data comes from. In this tutorial, I want to go through a minimal setup for mocking your data. After this, you should be able to extend it with your own data as needed.

Dependencies

In order to work with Node you need to have it installed on your machine. For the mac users I highly recommend to install it with NVM, because it will make it easier to update NodeJS in the future. (There is also a version for Windows).

Create a new folder to start for this project. Run npm init -y to initialize the folder with Node and it will create automaticly a package.json for you.

In order to create the mockserver we need 2 npm dependencies. json-server and casual so we run npm install json-server casual --save-dev in our project.

Base for the mock-server

Create a index.js and paste this code in it.

const jsonServer = require('json-server')
const server = jsonServer.create()
const middlewares = jsonServer.defaults()
const port = process.env.PORT || 3000
server.use(jsonServer.bodyParser)
server.use(middlewares)
server.listen(port, () => {
    console.log('JSON Server is running')
})

We include the json-server in order to use it. Then we create a server instance in the const server. With the middlewares we can set a few options like path to static files, CORS and few more. But here we just use it without and specific options.

The port is very important. If you want this to run on a server it will first search if there is any default port set for a Node server, otherwise it will pick port 3000.

We include the bodyParser and middleswarses by using server.use(). And after that we do a console log so you know the mock-server is running.

Generate data for 100 users

Create a folder /users and create a index.js in it.

First include the npm package casual in order to use it.

const casual = require('casual')

For specific language, if you don't want the english default:

const casual = require('casual').nl_NL

Than below it we need to export a module in order for use it in de index.js in the root later.

module.exports = () => {
    casual.define('user', function() {
    return {
        name: casual.first_name,
        surname: casual.last_name,
        address: casual.street,
        phone: casual.phone,
        email: casual.email,
        postalCode: casual.zip,
        city: casual.city,
        number: casual.building_number,
        id: casual.uuid,
    }
})
const data = {
    users: [],
}
// Create 100 users
for (let i = 0; i < 100; i++) {
    data.users.push(casual.user)
}
    return data
}

With casual.define we define a object with a type 'user'. So in order to create data for 100 users in 1 go, we create a for loop that will run 100 times and pushes a user in the user array in our data object.

After that we return the whole object so we can use that in the root index.js.

Create a /user endpoint

In order to get the data for 100 users, we need to create an endpoint for the mock-server. Paste the code below in the root index.js, before the server.listen() function.

server.get('/users', (request, response) => {
    if (request.method === 'GET') {
        const users = require('./users/index')
        response.status(200).jsonp(users())
    }
})

In this case we use server.get() for a get request. But we also could choose 'post', 'put', 'delete' and so on.

Run the mock-server

Now we are able to run that mock-server and get the data inside our frontend application.

Run node index.js inside the root folder of the project. Visit localhost:3000/users and you will see 100 users in the user array.

I hope this tutorial formed the base for you to generate more random data and expand your mock server. If you have any questions, please let me know in the comments.

Inside we check if the request was a 'GET' request. If so, we require our users script and call the function inside the response so you will see the array of random generate users.

Source: https://mrfrontend.org/2019/05/how-to-mock-an-API-with-random-data-from-NodeJS

Source: https://dev.to/mrfrontend/how-to-mock-an-api-with-random-data-from-nodejs-dda

Source: https://medium.com/mr-frontend-community/build-a-nodejs-mock-server-api-with-random-data-86303db9156a

Running Webpack Dev Server with HTTPS on developer machine using MKCERT

Даниил Пронин — Mon, 04 Apr 2022 05:51:23 +0000

1) Add local domain to /etc/hosts:

127.0.0.1 my-project.dev

2) Install mkcert
3) Create certificate for this domain:

➜ mkcert my-project.dev

Created a new certificate valid for the following names 📜
 - "my-project.dev"

The certificate is at "./my-project.dev.pem" and the key at "./my-project.dev-key.pem" ✅

4) Copy certificate .dev.pem and the key .dev-key.pem to project folder:

cp my-project.dev.pem path/to/my-project
cp my-project.dev-key.pem path/to/my-project

5) Add HTTPS options to Webpack Dev Server config:

devServer: {
    host: 'my-project.dev',
    https: {
        key: fs.readFileSync('./my-project.dev-key.pem'),
        cert: fs.readFileSync('./my-project.dev.pem'),
    }
},

Tested with:

webpack 4.28.4

webpack-dev-server 3.2.1

@vue/cli-service 3.5.3

mkcert 1.3.0 from Homebrew

macOS Mojave 10.14.6 (18G84)

Working with Docker and other unix-things on Windows like on macOS or Linux

Даниил Пронин — Fri, 29 Jan 2021 04:14:38 +0000

Install WSL 2
Install Ubuntu (or other distro) into WSL
Place your project files in Linux inside WSL using path like \\wsl$\Ubuntu\home\username\Work. You can access them from using Explorer since it's network location for Windows. Just Enter \\wsl$\ into location bar and you will see available WSL locations.
Open it in JetBrains IDE
Install Docker Desktop for Windows
Enable WSL 2 support in Docker Dashboard Settings
Open WSL Command Line, go to project folder and initialize Docker configuration. For example: docker-compose up -d.
Now you can see Docker Desktop give you access to containers you just build.
Now you can work with containers into JetBrains IDE Services pane, connecting to Docker daemon using "Docker for Windows" option.

TIP after installing Docker Desktop, you can notice you can open Docker frontend in browser, but not frontend from WSL (like npm run start). To fix that, create .wslconfig file in your home folder (C:\Users\username) and fill it:

[wsl2]
memory=4GB
swap=0
localhostForwarding=true

The key you want to change is localhostForwarding.

Found it here.

How to start map with HEV suit on?

Даниил Пронин — Sun, 20 Jan 2019 11:26:44 +0000

Quick guide using Hammer Editor 4.1, Build 6412, Source SDK Base 2013 Singleplayer [upcoming]

If you just put info_player_start and start map, you will have no the HEV suit: you cannot run, you have not crosshair, no flashlight, and so on. It's good if you want to give HEV suit to player after map is started, but you may want to start map with a battle.

The easiest and obvious way to do this is put item_suit entity right over the info_player_start entity, but you will start game with "logon sound" and hands animation, when Freeman takes HEV suit in the first time in Isaac Kleiner lab in City 17.

crook lvl 1

If you want to start map without hands animation and "logon sound", here's a short guide:

Create entity: point_servercommand
Name: give it any name, command for example
Create logic_auto entity
On Outputs tab, add new with button in bottom of the window
My output named: OnMapSpawn
Targets entities named: name of point_servercommand entity you created before
Via this input: Command
With a parameter override of: give item_suit

lvl 35 boss

In short, we create a trigger that runs when map is started, and it run console command to get a HEV. You can try type give item_suit in game console and will have the same.

DEV Community: Даниил Пронин

Как установить купленный WarCraft III: The Frozen Throne в 2025 году?

Русский язык

Видеоролики

macOS

Можно ли заменить базы данных Notion с помощью Obsidian?

Database Folder

MAKE.md

Datacore

DataLoom

Projects

Вывод

Vue 3 Composition API + socket.io

Why you don't have to commit node_modules folder

No need for npm installs

Guaranteed replicated builds

Better awareness of the code you're shipping

More consideration to adding a dependency because it's not invisible

You can manage the large diffs

Protection from another left pad

Почему не надо коммитить папку node_modules

Нет нужды в npm install

Гарантированно воспроизводимые сборки

Лучшая осведомлённость о поставляемом коде

Более вдумчивое добавление зависимостей, потому что они больше не скрыты

C большими диффами можно справиться

Защита от очередного left_pad