я недавно работал в большом проекте (микросервисная архитектура, если вам это о чем-нибудь говорит, порядка 50-70 отдельных микросервисов) - рассчитан на год-полтора разработки, постоянных разработчиков около 10-20.
все разработчики были найдены заказчиком через Upwork
пока работал - пришлось отказаться от участия еще в 2-х аналогичных по масштабности проектах (заказчики сами находили и предлагали).
maxt888:
перебивают только простые заказы. делайте сложные заказы - и у вас не будет проблемы с демпингом.
в моей сфере - нет с этим никаких проблем.
напротив - нередко назначаю ставку в 1,5-2 раза выше чем изначально предлагает заказчик. заказчик выбирает все равно меня. не в 100% случаев конечно. но оставшихся 10% сработавших ставок вполне достаточно, чтобы загрузить себя работой на полный рабочий день на пару месяцев вперед.
Сергей Зеленский:
Скорость передачи информации по сети интернет все равно заведомо ниже, чем скорость SSD.
И на одиночном пользователе никакого плюса в SSD по сравнению с HDD для статики не будет. Каналы связи весь эффект SSD сожрут.
Про статику и множество пользователей, одновременно желающих ее получить с веб-сайта - история другая.
Но статика у меня расположена на специализированном облачном хостинге, заточенном под только статику - это хостинг типа cloud storage (аналог Amazon S3).
И забота об правильном кэшировании - не моя забота. Этим занимается облачный хостер и делает это намного более масштабными объемами оперативной памяти, чем я мог бы себе позволить за разумные деньги. Облачные хостинги априори предназначены для высоких нагрузок, генерируемых множеством пользователей.
Разумеется, можно было бы и статику кэшировать в оперативной памяти, но это уже избыточно.
А вот кэширование в оперативной памяти того, чтоб обычно читается из базы данных - как раз целесообразно.
Видите ли, нагрузка, создаваемая ЛОКАЛЬНО обращениями плохо написанного движка веб-сервера к базе данных, несоизмеримо больше той нагрузки, что генерируют пользователи, запрашивающие статику ЧЕРЕЗ СЕТЬ ИНТЕРНЕТ. Причиной этого является банальная узость сети по сравнению с локальными интерфейсами доступа к диску сервера.
Да-да, я знаю, что современная сеть может быть даже быстрее дисков. Но это верно только для локальных сетей. Если же ваши пользователи значительно нагрузят ВНЕШНИЕ каналы связи к хостеру, он закономерно посчитает сие ДДОС-атакой.
Поэтому локальный доступ веб-сервера к дискам (работа движка сервера с базой данных) априори способен дать более высокую нагрузку. Почему?
Статика, получаемая для каждой страницы - это всего лишь последовательное чтение не такого уж и большого числа файлов. На других страницах часть статики повторяется и браузер обходится своим кэшем (общие для всех страниц стили, общий JS-код), даже не запрашивая ничего с веб-сервера.
База данных на диске у меня разумеется есть. Но 99,99% нужных для работы данных считываются оттуда сразу же после очередной перезагрузки сервера, что происходит раз в несколько месяцев.
Совсем без базы данных на диске не обойтись - информация о пользователях (сессии, корзина, данные для оформления заказа) дублируются (записываются) на диске помимо кэша в оперативной памяти. Но это мизерная нагрузка по сравнению с каталогом товаров, ведь 99% времени пользователи только то и делают, что шарятся по товару. А эта информация как раз полностью закэширована в оперативной памяти.
Сергей Зеленский:
У меня интернет магазин есть к примеру. 7000-8000 товаров на нем.
ВСЕ товары прекрасно умещается в оперативной памяти. Сделано агрессивное кэширование специально для этого.
Какой там будет диск - абсолютно неважно.
Скорость доступа у меня из оперативки все равно быстрее.
Цена использования хранилища складывается из двух составляющих — цены хранения и цены распространения контента. Цена хранения составляет 1 копейка за хранение 1 гигабайта данных в течение 1 часа. Цена распространения (исходящего трафика) составляет 1 рубль за 1 Гб трафика. Входящий трафик на хранилище бесплатен.
Плата за хранение взимается ежечасно по максимальному пространству, занимаемому в хранилище в течение часа с округлением до целого количества гигабайт. Плата за трафик взимается по накоплении целого гигабайта исходящего трафика без округления.
Нюанс - если просто пойти писать сайты без плана, то всю жизнь так и будешь писать простейшие гАвносайты за 3 копейки.
Опыт нужен, работать можно уже с минимальными знаниями.
Но при этом отказываться от "меньше денег, но работа под началом опытных спецов" не стоит. Это дает большой пинок под зад в плане повышения квалификации и более перспективно, хотя и намного менее приятно по деньгам.
После того как доллар скаканул, у kimsufi и пр. OVH имеет смысл смотреть только на dedicated.
Виртуальный же VDS сейчас в России обходится дешевле, чем заграничный и даже быстрее работает (разумеется, у нормального хостера, а у не у тех кто переуплотняет ресурсы без меры).
Max Kostinevich:
> Представьте, но ДА - товар сканируется, и это сразу проверяется в онлайне. Невероятно, не правда ли?
О том что это в принципе невозможно - я не говорил.
Я говорю - об весьма и весьма ограниченном использовании подобной модели.
У меня подобная вещь уже много лет как работает.
В розничной сети крупного продавца бытовой и компьютерной техники.
Почему?
1. Мало продаж в единицу времени.
2. Можно оформить продажу без интернета, ведь весь товар в зале. Потом, когда связь появится, зафисировать продажу задним числом в базе данных.
3. Упрощает открытие новых магазинов.
У другой моей знакомой крупной сети (800 магазинов) такого нет. Продажи оформляются на месте, а уже потом отправляются в центральный офис?
Почему?
Огромное число продаж в единицу времени. Ввести это потом задним число невозможно.
У подавляющего же большинства моих клиентов - нечто среднее: продажи в онлайн, но без веба. Никому не нужно создавать себе лишних проблем (мест, где возможны потенциальные проблемы).
Когда начали писать о программе Google по проведению дешевой и скоростной оптики по началу было не понял - а что тут такого, в РФ (не везде, но в очень многих местах) это норма.
Потом вник в тему - и выяснилось, что в среднем интернет в США очень поганый: очень дорогой и медленный.
teodor7teodor7:
CRM - не занимается учетом наличия товаров на твоих складах. Если CRM этим занимается, то это уже не CRM.
CRM занимается отслеживание взаимоотношений с ПОКУПАТЕЛЕМ.
Я назвал - в 97% вообще не используется автоматизация кроме самого веб-сайта (но на нем не всегда ведутся остатки).
И вы тоже путаете бухгалтерию и УЧЕТ ДЛЯ СВОИХ СОБСТВЕННЫХ НУЖД.
Знание сколько у вас товара на складе и сколько вы должны поставщикам - это не то, что в нашей стране обозначается страшным словом бухгалтерия, которого боятся программисты.
mishpak:
Возможно вам сумма показалась чрезмерной.
Но ситуация еще хуже - сумма названа в условиях, что УЖЕ СУЩЕСТВУЕТ оффлайн система, продающая билеты, к которой нужно прикрутить веб-сайт.
При создании веб-сайта нужно сделать так, чтобы билеты РЕЗЕРВИРОВАЛИСЬ МГНОВЕННО и ОДНОВРЕМЕННО на веб-сайте и в оффлайн системе.
Это нужно чтобы решить следующие проблемы:
1. Нельзя допустить продажи 2 билетов на одно место.
2. Казалось бы, - решение лежит на поверхности - просто резервировать часть билетов под продажу на веб-сайте. Но нельзя заранее резервировать часть мест для веб-сайта, так как:
а) Нет гарантии, что эти билеты будут проданы через веб-сайт и автобус не уедет полупустым. А ведь если автобусы после внедрения вашей системы будут уезжать полупустыми, то ваша работа очень не понравится руководству предприятия. Очень.
б) Нет гарантии, что на веб-сайт не набегут покупатели. И постоянное отсутствие билетов в онлайне и возможность их купить только через оффлайн кассу попросту дискредитирует систему онлайн-продаж и ей не будут пользоваться.
Решить проблему может только ОДНОВРЕМЕННАЯ МОМЕНТАЛЬНАЯ продажа (резервирование) билетов на едином сервере, который должны использовать и оффлайн-кассы и через веб-сайт.
Если касса располагается не в том помещении, где располагается сервер (а так и бывает обычно, так как билеты продаются одновременно в нескольких городах), то нужно огранизовать альтернативный канал на случай пропадания интернета.
Под альтернативным каналом я имею ввиду как второе подключение к другому интернет провайдеру, так и продажу (резерирование) билетов удаленными кассирами по телефону голосом.
То есть, когда сканируется штрих-код товара, то это все на сайт улетает и там проверяется в онлайне?
Вы серьезно?
Считаете, что владельцы/менеджеры на Западе такие идиоты, чтобы добавить себе рисков/задержек в организации технологической цепочи продаж?
Даю намек:
У нас интернет массово распространился позже чем в США, поэтому если у нас никого не удивить оптикой в спальные районы, то у них поскольку построено раньше, то даже в ИТ-шной Калифорнии ADSL - в порядке вещей.
да ты че
;)
я недавно работал в большом проекте (микросервисная архитектура, если вам это о чем-нибудь говорит, порядка 50-70 отдельных микросервисов) - рассчитан на год-полтора разработки, постоянных разработчиков около 10-20.
все разработчики были найдены заказчиком через Upwork
пока работал - пришлось отказаться от участия еще в 2-х аналогичных по масштабности проектах (заказчики сами находили и предлагали).