Я взял себе китайский мини-комп с пассивным охлаждением, установил на него Proxmox, роутер, Home Assistant, Adguard, пару виртуалок для работы, и всё это на 16 gb RAM.
Anton3232, Вы и папку из которой билдить программу, и куда ложить экзешник, всегда можете указать в параметрах go build.
Чтобы вы не страдали в этой операционной системе для геймеров и вирусов, я вам рекомендую установить WSL (Windows Subsystem for Linux), изучить хотя бы минимальную базу по Линуксу, и запускать команды как все нормальные люди. По-моему, новый терминал в Винде, да и сами редакторы кода поддерживают WSL. Посмотрите видосы на ютубе, как это сделать, там полно их. Дело в том, что на последнем этапе собрать экзешник для Винды будет проще, чем страдать вот так, спотыкаясь на каждом шагу.
А когда будете в Линуксе в WSL, вы сможете создать в корне проекта файл Makefile и там прописать все длинные команды в виде шорткатов. И сможете сами себе создать шорткат make todo-list, который будет запускать команду go build с кучей опций.
P.S. По-моему, какая-то пародия на команду make есть где-то и для Винды. Но это не точно.
Алексей Уколов, С другой стороны, если оно слишком быстро отработает, то мы снова столкнёмся с этой проблемой. Если у автора проблема именно с повторяющимися запросами, то лучше пусть эти 10 секунд так и пройдут, и Redis сам удалит ключ. В этом случае лучше озаботиться генерацией вот этого самого уникального ключа, чтобы он отлавливал именно те запросы, которые точно дубли с точки зрения автора, и пропускал другие. А для этого не стоит удалять ключ в случае успеха.
Зато в случае ошибки как раз и надо удалить ключ, ведь ошибка может быть вызвана не только неверными данными, но и сбоем сети и т.д. И тут ждать 10с будет неверно.
Вечно Крайний, Если вы хотите именно такой подход, то тут будет всё намного сложнее.
handler.php должен запускаться вебсервером как обычно.
handler.php должен просто складывать сообщения с телом запроса в очередь.
worker.php должен быть отдельным процессом и только читать по очереди те сообщения, что в неё пуляют handler.php. Он должен сам проверять, было ли уже такое сообщение или нет и принимать решение о том, отправлять ли данные дальше или игнорировать их.
worker.php должен быть единственным, запускаться самой операционной системой и находиться под наблюдением supervisor, чтобы тот его перезапускал, ежели он упадёт.
Проблема с этим асинхронным подходом в том, что handler.php не знает результата работы worker.php, т.к. они живут в разных вселенных.
Я обычно решаю эту проблему установкой специального сервиса Mercure (mercure.rocks), к которому браузер клиента коннектится и ждёт сообщения от бэкенда по каналу SSE (Server Sent Events). И мы из worker.php будем кидать сообщения обычным http запросом в этот самый Mercure, а он будет раскидывать эти сообщения всем подключённым к нему браузерам.
Сложно? Да, сложно. Но с отдельным и единственным долгоживущим worker.php только так...
101-s,
Рекомендую Wordpress + WooCommerce потому что это одновременно и быстро сделать, и специалистов самого разного уровня как грязи в деревне в осенний день. Так же есть множество плагинов для интеграции с различными "системами учёта", платежными системами, службами доставки и т.д. и т.п. Есть ещё момент UX. Современный покупатель - фифа капризная. И если ваша корзина и шаги оформления заказа будут сильно отличаться от того, к чему он привык, то многие просто не дойдут до конца оформления заказа, если там что-то сильно особенное. Поэтому такие популярные связки как WP+WC очень знакомы покупателям своим процессом оформления именно потому, что таких магазинов чудовищное количество. А узнавание - это очень хорошо для продаж.
Если ваш вариант первый, и у вас уже есть ИМ, то вы абсолютно точно до мельчайших деталей знаете, что вам мешает и чего вам не хватает. И в случае, если готовое решение не будет иметь нужного вам конкретного функционала, то придётся "бороться" с этим готовым решением при помощи каких-то "хаков". Ведь и сила и слабость коробочных решений в том, что у них своё видение и свои принципы, которые могут отличаться от вашего видения и ваших принципов. Поэтому, когда вы точно знаете, что вам нужно, лучше написать магазин с нуля конкретно под ваши нужды. Самый главный недостаток такого решения - это то, что магазин будет крайне сложно дорабатывать, если изначальный разработчик исчезнет. Вариант WP + WC лишён такого недостатка. Поэтому выбирать нужно только надёжную команду с многолетним портфолио.
Squora, Тогда вам вот ещё момент: если будете брать MacBook Pro, то рассмотрите вариант уже с процессором M4 Pro, а не просто M4. Это иногда путает людей, и они берут более дешёвый вариант, который мало чем от Air отличается. А вот процессор M4 Pro - это точно новый уровень и точно увидите разницу
Squora, Вот, кстати, хорошее видео с более подробным разбором разницы между Air и Pro. Там есть ряд неточностей, но это реальный толковый программер, и его советы можно учитывать. https://www.youtube.com/watch?v=UwjBQpdSjsA&t=201s
Squora, Только видео может забить диск такого размера. Никакие репозитории даже близко не подберутся к 512.
А как я уже писал, для видео лучше купить NAS. Я к своему домашнему NAS подключаюсь извне через VPN, и могу смотреть свои видосы из любой точки мира
Squora, Вам стоит ещё учесть, что Маки не сильно падают в цене на вторичном рынке. И если вам "в будущем" чего-то не будет хватать, то продадите этот и купите новый. А ведь вот это нехватающее "в будущем" может и не наступить вовсе. Зато ворчание о том, что ноут не такой лёгкий и удобный как Air, и я за это неудобство ещё и доплатил, наступит в первый же день использования
Squora, Внимательно подумайте, что такое огромное вы будете хранить на ноуте, что вам не хватит 512 SSD.
Я давным-давно купил себе Synology NAS, и всё кино и смонтированное видео хранится там.
У меня мильон проектов, я вообще не думаю об экономии места и каким-то образом мне этой памяти с головой хватает.
512 SSD + NAS - и нет проблем
https://www.jetbrains.com/help/webstorm/how-to-use...
Главное - Node установить внутри WSL. Насчёт гита не знаю, возможно, лучше снаружи.