FireGM: в данном случае кода не будет, потому что это базовая возможность языка и вам её нужно понять самому, а во вторых потому что мне лично этот роутинг не нужен, мне нравятся классические хандлеры.
memba: Проверяйте наличие запущенного приложения идентификатор которого записан в pid файл:) Да и в Linux /etc/init.d/ со start-stop-daemon решают эту проблему классическим способом, в Windows свои сервисы... а универсально - проверять самому (если есть такая возможность).
Зато красивый, автор сюриалистически пытался показать сразу всё и красивую мультяшную тень и само солнце в облоках, просто его нельзя было показать за кадром:)
tex0: по своей сути они в одной категории, levelDB пока не использовал, поэтому по описаниям это тот же Berkeley DB + N функциональности в комплекте, более коммерческий расчёт на больший объём данных с большей сложностью. В любом случае - это надо на практике выяснять, читать код, читать документацию, ну в общем... читать и думать.
Илья Босенок: "поддерживать нативную работу с JSON =)" ну раз так... значит в следующий раз так кому-нибудь из представителей 1С на конференциях и скажу:)
Ладно, давайте по порядку. Коммерцию я разделил на три группы по степени вовлечённости.
1. те у кого это основной и технологичный бизнес
- технологии - это их основной вид деятельности
- у них как правило свой штат сотрудников, свои технологические компетенции
2. те у которых есть некий товар или поставщики и его просто нужно представить
- опыта технологических продуктов почти никакого и уж точно в данной специфике
- основная задача - показать товар, получить заказ, сделать корзину и оплату
- в качестве исполнителей могут быть кто угодно, качество самого разного уровня, поддерживают это разные люди, хаотично, не системно
- обычно стараются сделать дёшево, а стоимость владения пугает больше чем стоимость разовой работы
3. те у которых есть реальный магазин и к нему хочется сделать веб-версию
- есть компетенция именно в торговле, хотят что бы офф-лайн бизнес был представлен в сети
- как правило более "бизнесово" подходят к решению задачи, стараются купить продукт, интересуются интеграторами, покупают или арендуют сервера
- таким заказчикам важна модульность, что бы части системы можно было заменить без знания программирования, а обратившись к другому интегратору, например.
Группы условные, вторая и третья группа действительно похожи, но имеют ряд отличий.
Приведу пример из сферы мытья посуды в ресторанах:
1. нанимают людей, учат гигиене, разрабатывают и проверяют методологию чистки посуды, подготавливают полностью работающее место, нормы, стараются ничего не забыть и соблюдать САНПИН, у них, как правило, каждый повар знает кто и как моет посуду да и вообще чистота везде, а если что-то где-то не так, то да, это именно "не доглядели"
2. нанимают одного-двух мойщиц посуды, дают им что есть, вот какая страшная кухня была на такую и нанимают, нет решётки у вытяжки - так никто и не подумает, тоже и с посудой... и работников кухни кормят там же где посуду моют в сторонке и точно сказать чистая и на сколько чистая это посуда - не могут без махинаций
3. нанимаю клиринг-сервис, смотрят кто в их городе может оказывать такие услуги... перекладывают задачу, делегируют её почти полностью, смотрят что те скажут и смогут предложить. Если они предложат перестроить весь закуток для мытья посуды - то прислушаются, в 50% случаях купят это как услугу, если им пообещают сделать всё так-то и так-то, главное что бы их освободили от проблем с соблюдением правил за приемлемые (и не всегда маленькие) деньги.
По поводу того кому что нужно. Все люди разные и нужно, как правило, немного своё. Да фильтрацию товаров, но каждый видит её по своему, да поиск по товарам, но опять таки каждый по своему. Всё в нюансах.
По поводу коробочных решений. В целом может быть да, потребности похожие. Реализации разные. Представления разные. Вы, возможно, предлагаете делать модуль который можно будет 100500 настроить под все особенности каждой компании, но кому-то более важно что бы:
1. работало быстрее чем универсальный комбайн
2. работало и настраивалось предсказуемее (только то что нужно конкретной компании) и ничего лишнего
3. было понятным конкретному заказчику
И вот, вы уже идёте в разрез по желаниям. Кому-то конкретное решение понравится, а кому-то нет.
Как вы видите кооперацию? Расскажите чуть подробнее. Интересно.
Там проблема со скудностью функционала, например нет возможности вставить данные и получить уникальный ключ - ключ надо вычислять заранее и решать вопрос с колизиями самостоятельно.
Подходит как маленький кирпичик большой системы, но работает шустро, это да. Если на то пошло можно обратить внимание на LevelDB, правда там уже несколько далеко не одинаковых реализаций.
Смотря какая база данных. Представьте N миллионов мелких изображений, каждое очень маленькое.
В файловой системе:
1. есть разумный лимит на количество файлов в одной директории - способ бороться: разбивать на вложенные подкаталоги по хеш-функции
2. сложность в горячем дублировании - либо всё в RAID либо копии каталогов с частью горячих файлов, особенностью является - необходимость за всем уследить, а так не проблема
3. накладные расходы на хранение действительно мелких файлов (читаем про блоки, сектора файловой системы)
4. всё равно нужна какая-то база которая знает о файлах
5. нужно время от времени удалять и синхронизировать файлы если есть несколько копий горячих файлов
6. нужен алгоритм горячих файлов, встроенного в файловую систему вроде бы нет:)
В базе данных заточенных под файлы (их ещё иногда объектными базами называют):
1. файлы хранятся в больших блобах
2. индексирование мета-инфорации о файлах в классическом БД виде
3. простое удаление, перемещение, обновление
4. часто быстрый и распределённый доступ (если бд это позволяет)
5. проще дописывать дополнительный функционал
Но сферически картинки в базе - это конечно да, идиотизм.
AlikDex: база данных занимает 6 гигабайт? Так это не много. Тут есть что и как пошардировать. Вот если бы проблема была такой: 600 гигабайт и индексы не влезают в оперативку - было бы интересней.
Илья Босенок: часть из того что вы описали не просто реализовать в виде коробочного решения что бы подходило абсолютно всем, всем хочется уникального подхода.
Илья Босенок: В общем-то таким и должен быть обычный интернет-магазин + ещё пунктов 30 как минимум:) Условно интернет-коммерцию можно разделить на группы:
1. те у кого это основной и технологичный бизнес
2. те у которых есть некий товар или поставщики и его просто нужно представить
3. те у которых есть реальный магазин и к нему хочется сделать веб-версию
Про 1С - могу посоветовать начинающим (но амбициозным магазинам) не связываться с ним и пойти по вашему пути - долго, зато с прогнозируемым и зависимым только от самих себя результатом.
Было бы интересно почитать и другие ваши мысли о том что скрывается за фасадом действительно хорошего интернет-магазина. Вы не ведёте профильный блог?
Илья Босенок: могу только порадоваться за вас:) Что именно пишите в данном случае? Классический интернет-магазин или всё таки что-то интересное? Golang-ведь это позволяет - делать что-то не такое как обычно.
Zverienish: мы за китайцами никогда не поспеваем во многих highload'ных сферах, это нормально. Скоро будет новый Highload++ и обещается пару китайцев из Allibaba Group, так что советую сходить:)
Плюс писать исключительно системные утилиты - не сильно эффективно, вы так язык программирования почти не раскрываете по потенциалу. Хотя смотря что вы под утилитами имели в виду:)
shakawkaw: поищите VPS/Dedicated с возможностьд подключиться по BGP, сам хостинг обойдётся +- 3т.р., за BGP 3-6т.р. (цены двухлетней давности, сейчас либо дороже либо дешевле). Ну а дальше дело техники.
qucer: нужно понимать следующее отличие пакетов от пакета main:
1. в package main вначале выполняются все функции init(), а потом main(), функций init() может быть несколько - выполняются в произвольном порядке, но обычно по мере следования, можно разложить по нескольким файлам и это будет полностью нормально.
2. в package main функция main() является основной, в ней вы по сути запускаете все нужные механизмы, пишите какую-то минимальную логику их работы, init() помогающая функция, принято использовать для инициализации чего-угодно, но не для написания бизнес-логики как в main()
3. в прочих пакетах init() служит для инициализации компонентов для конкретного пакета, а не всего приложения в целом. Можете посмотреть пример инициализации image/jpeg https://golang.org/src/image/jpeg/reader.go
4. в прочих пакетах функции main() нету, точнее вы можете её создать, но смысл её будет как у любой обычной функции.
Отсюда приходим к изоляции пространства пакета от пространства приложения (package main) и к изоляции между пакетами как таковыми. Функции init() в package main могут использоваться для передачи в пакеты всех необходимых данных (поитер на базу к примеру), либо тоже самое может происходить в функции main() всё того же package main. Внутри пакета делать инициализации для напрямую не связанных пакетов - бессмысленно и не правильно.
Глобальных переменных в Golang в обычном понимании нет... но да, из package main вы передаёте доступ к данным в другие пакеты и они ими пользуются - в этом плане переменные можно назвать "глобальными", но пока вы их не передадите (по поинтеру или копированием) в пакетах их видно не будет (по этому они не глобальные).
Про плюсы: на самом деле смотрите как вам удобнее. Если будете перегружать кодом main() - будет печально отлаживать. А по части того где передавать поинтеры на что-то "глобальное" вроде базы в пакеты - это сугубо на ваше усмотрение. Просто в одной варианте вы сделаете это один раз mypackage.DB = DB, а в другом будете делать каждый раз при создании нового объекта из пакета obj := package.New(DB)
Про стиль ООП, на самом деле Golang очень хорош в своём подходе к объектно ориентированному программированию, просто не всем нравится:) И к вопросу инициализации это вообще не имеет почти никакого отношения.
Андрей Краснобаев: ну вот и отлично. Но всё таки присмотритесь к языку Golang более подробней, он на очень многое способен и на очень многие вопросы уже есть как ответы на stackoverflow.com так и всё необходимое в стандартной библиотеке (благо поиск и документация по ней очень хороши). Та часть о которой вы спрашивали почти такая же как в Си (я про сигналы, форки и прочее в таком духе), вообще много похожего.