Работал два года в режиме 10-12 часов в день + выходные когда требовалось, пару раз на двое суток оставался. Полежал месяц в больнице. Работаю на другой работе 8 часов в день, в выходные отдыхаю, зарплата такая же. Скучно не стало, приоритеты теперь другие.
Подход автора вызывает уважение, выбранное техническое решение я бы назвал удачным. Однако, на мой взгляд, это не совсем тот товар, который нужен молодым родителям. Более востребованы качели, в которых ребенок лежит пристегнутым днем, на кухне, под присмотром молодой мамы и укачивается. А мама в это время готовит себе поесть или просто сидит переводит дух.
Много слов из предметной области, но сути нет. Поэтому от себя напишу несколько принципов:
0) начальник, как самурай, рано или поздно должен принести себя в жертву (уволиться).
1) вокруг люди — с парнями из своего отдела надо иметь хорошие отношения. Организовать совместные мероприятия, выбить бюджет у директора. Например, боулинг. Но не как награда за релиз, а просто как общее мероприятие. Общаться с каждым отдельно хотя бы иногда. Быть в курсе их жизни. Не бывает плохих людей, бывают неподходящие работники. Об этом необходимо всегда помнить.
2) Делегировать. Это означает поручать задачи и наделять полномочиями. Начальнику все равно остается много дел, в основном, административных, которые нельзя делегировать.
3) Контролировать. Проверять все — ход процесса, проверять качество кода, хотя бы выборочно. Парни должны не на словах знать, что вам важно что и как они делают.
4) Нести отвественность — все, что делают подчиненные, это то, что делает твой отдел. Если кто-то косячит, вина на тебе. Если успех — успех общий. Тебя должны хвалить не начальники, а парни в ответном слове, тогда все идет правильно.
5) Следить за дисциплиной — правила должны быть едины для всех. Один плохой работник за месяц портит работу всей команды. Чистить команду неприятно, но нужно уметь.
Допустим, все тизеры близки по качеству привлечения целевых посетителей.
Количество показов при этом для разных «аудиторий» будет разным, хотя бы потому, что «аудитории» разные по численности. Оставив самые продающие, вы скорее всего, оставляете только те тизеры, которые таргетированы на самый массовый сегмент пользователей соцсетей… Или не так? :)
Да бросьте, версии для обычной разработки совершенно ни к чему. У вас разве несколько разработчиков одновременно выполняют задачи, связанные с изменением БД? Речь ведь о Битрикс — бОльшая часть задач все-таки в рамках API. Если делается новый сложный модуль, все равно один человек отвечает за структуру данных иначе будет бардак. Ежедневных бекапов и скрипта срочного бекапа и локального восстановления вполне достаточно.
У Вас ошибка в самом начале этой схемы. На управление версиями нужно тратить ресурсы. Следовательно управлять версиями нужно только тех файлов, которые изменяются и для которых это критично. Если бы у вас дизайнеры постоянно исправляли картинки товаров и вам нужно было сравнивать все версии, их нужно было добавить в репозиторий. Очевидно, что такой необходимости нет. Картинки интерфейса — да, добавить нужно, но это явно не 60Гб. Чтобы утащить картинки на dev сервер и на машины разработчиков нафиг не нужна система контроля версий. Нужен rsync, который умеет качать только те картинки, которые изменились или добавились (он вообще много всего умеет, например, скорость скачивания ограничивать свою).
Вот мой рецепт разработки и развертывания апдейтов на Битрикс (проверен годами):
1) git;
2) исключено из репозитория — все, кроме файлов, которые разработаны или кастомизированны. Исключения хранятся в .gitignore, который включен в репозиторий;
3) у каждого разработчика виртуалка с сервером и сайтом на локальной машине;
4) каждый разработчик изменения pushит в bare репозиторий;
5) по расписанию, ведущий разработчик собирает dev сервер и отдает его тестировщику на сутки. На следующие сутки все что принято тестировщиком pullится с рабочего сервера;
6) для разработчиков и для dev сервера есть скрипты (там две строчки на rsync) которые позволяют все отсутствующие локально картинки, видео и прочий контент с рабочего сервера скачать. Аналогично с БД. На самом деле мы качаем БД с реплики, а картинки с ненагруженного зеркала (до кластера пока не дошло), но можно и с рабочего, с такой посещаемостью это должно работать, если там не полная ж… со скриптами.
PS: публикация изменений на рабочий сервер занимает редко более 10 секунд (это когда ооочень много изменений).
Вряд ли это можно назвать показательным замером. Включенный мобильник не взяли на борт самолета из соображений безопасности (и правильно, кстати). И поехала эта посылка как нарушитель стандартного процесса как придется (а может кто из работников специально «наказал» умника). То что Почта России не эффективно работает мы все уже знаем. Наверное, немалую долю в неэффективность добавляет отсутствие системы управления исключениями (а это для любой системы губительно).
В том то и дело, что в СССР гораздо больше людей думали и добивались качества чем сейчас. Сейчас все стремятся побыстрее выйти на рынок, захватить рынок, побыстрее вывести новый продукт, побыстрее его заменить. В СССР не было идеальным обществом, но культа потребления в нем не было. Справедливости ради замечу, что и в Европе качество было заметно выше чем сейчас. Мерседесы раньше по миллиону киллометров ездили без кап. ремонта. А сейчас даже понятия кап. ремонт нет — 3-4 года и давай новую покупай. Разучили нас с вами ценить качественные вещи, другие ценности сейчас.
Та история:
Слово rulezz со значением «очень хорошо» произошло от радости, которую испытывали фидошники от чтения и публикации сообщений в эхе RU.LEZ, созданной для общения лезбиянок.
В свою очередь, SUXX со значением «очень плохо, отстой» произошло от разочарования, которое постигло фидошников от чтения эхоконференции, в которой они ожидали увидеть порнуху — SU.XX. По факту, эха оказалась посвящена игре в крестики-нолики.
На самом деле, эти слова появились раньше, чем появилась Fidonet.
Четко помню объяснение «как на самом деле появились слова SUXX и RULEZZ». И ведь я долго в это верил, пока не понял, что Бивис и Батхед вряд ли читали русские эхи :).
Не совсем понятно, почему вы полностью от SQL баз отказались в своем проекте. Мы сейчас используем SQL базу в интернет-магазине и собираемся mongo прикрутить для ряда задач. Очевидно, что хранить характеристики со значениями, отдельно для каждого товара в ней значительно удобнее, равно как и выборки товаров по значениям характеристик делать. Но древовидные структуры типа каталога товаров и критически важные данные — заказы, пользователи, цены, я бы оставил в SQL.
Еще можно локально на сайте хранить остатки товаров и списывать их локально при создании заказа до момента обновления остатков из базы 1С. Так в Битрикс, например, сделано (точнее там при добавлении в корзину, что не совсем правильно для больших магазинов).
Как решение для старта — хорошо. Недорого и решены основные задачи. Однако опасно держать весь бекэнд на сайте. Единая база это заманчиво, однако если упадет, то упадет все сразу, вместе с розницей. Второй риск — трудно модифицировать решение под бизнес-задачи. С ростом, бизнес будет требовать от вас функционала, который есть в 1С УТ — например, второй, третий и т.д. склад, планирование поставок, стандартные отчеты, документы и т.д. Вам придется писать аналог 1С УТ на сайте, что долго и дорого.
Искренне надеюсь, что PayPal принесет в нашу страну сервис высокого качества. Хотя бы процессинг пластика… Сейчас ситуация удручающая — либо сервис плохой, либо менеджмент, либо и то и другое.
А что, хорошая идея, организовать сервис для проверки на вредоносный код. С вирусописателей брать деньги за анонимность, с антивирусных компаний брать деньги за раскрытие информации. И заработок и благое дело.
автоматический мониторинг должен быть, по-хорошему, распределенным — «другая» площадка на которой он запущен так же ненадежна, как площадка основного проекта. А если мониторинг «лежит», то он не нужен;
днс должны быть правильно настроены и расположены — к сожалению, это не для всех сисадминов очевидно. Нельзя располагать все днс внутри одной сети (тем более, внутри локальной сети компании, которая по определению менее надежна, чем средненький хостинг). Чтобы изменить адрес сервера надо иметь свой днс и менять именно записи, а не адреса ДНС в настройках домена у регистратора. В первом случае изменения почти мгновенные, во втором — до 6 часов.
0) начальник, как самурай, рано или поздно должен принести себя в жертву (уволиться).
1) вокруг люди — с парнями из своего отдела надо иметь хорошие отношения. Организовать совместные мероприятия, выбить бюджет у директора. Например, боулинг. Но не как награда за релиз, а просто как общее мероприятие. Общаться с каждым отдельно хотя бы иногда. Быть в курсе их жизни. Не бывает плохих людей, бывают неподходящие работники. Об этом необходимо всегда помнить.
2) Делегировать. Это означает поручать задачи и наделять полномочиями. Начальнику все равно остается много дел, в основном, административных, которые нельзя делегировать.
3) Контролировать. Проверять все — ход процесса, проверять качество кода, хотя бы выборочно. Парни должны не на словах знать, что вам важно что и как они делают.
4) Нести отвественность — все, что делают подчиненные, это то, что делает твой отдел. Если кто-то косячит, вина на тебе. Если успех — успех общий. Тебя должны хвалить не начальники, а парни в ответном слове, тогда все идет правильно.
5) Следить за дисциплиной — правила должны быть едины для всех. Один плохой работник за месяц портит работу всей команды. Чистить команду неприятно, но нужно уметь.
Количество показов при этом для разных «аудиторий» будет разным, хотя бы потому, что «аудитории» разные по численности. Оставив самые продающие, вы скорее всего, оставляете только те тизеры, которые таргетированы на самый массовый сегмент пользователей соцсетей… Или не так? :)
Вот мой рецепт разработки и развертывания апдейтов на Битрикс (проверен годами):
1) git;
2) исключено из репозитория — все, кроме файлов, которые разработаны или кастомизированны. Исключения хранятся в .gitignore, который включен в репозиторий;
3) у каждого разработчика виртуалка с сервером и сайтом на локальной машине;
4) каждый разработчик изменения pushит в bare репозиторий;
5) по расписанию, ведущий разработчик собирает dev сервер и отдает его тестировщику на сутки. На следующие сутки все что принято тестировщиком pullится с рабочего сервера;
6) для разработчиков и для dev сервера есть скрипты (там две строчки на rsync) которые позволяют все отсутствующие локально картинки, видео и прочий контент с рабочего сервера скачать. Аналогично с БД. На самом деле мы качаем БД с реплики, а картинки с ненагруженного зеркала (до кластера пока не дошло), но можно и с рабочего, с такой посещаемостью это должно работать, если там не полная ж… со скриптами.
PS: публикация изменений на рабочий сервер занимает редко более 10 секунд (это когда ооочень много изменений).
Слово rulezz со значением «очень хорошо» произошло от радости, которую испытывали фидошники от чтения и публикации сообщений в эхе RU.LEZ, созданной для общения лезбиянок.
В свою очередь, SUXX со значением «очень плохо, отстой» произошло от разочарования, которое постигло фидошников от чтения эхоконференции, в которой они ожидали увидеть порнуху — SU.XX. По факту, эха оказалась посвящена игре в крестики-нолики.
На самом деле, эти слова появились раньше, чем появилась Fidonet.