Чек-лист по выживанию сайта



    В последнее время я как-то подозрительно часто наблюдаю примитивнейшие однотипные и довольно легко решаемые проблемы на самых разных web-проектах. Разные базы, разные языки, разные сферы деятельности и схемы монетизации. Всех их объединяет одно — лозунг «бизнес не дает переписать». Продолжающийся или только-только оконченный этап рапид-разработки растущего и агрессивно отжимающего у конкурентов долю рынка проекта родил огромную кучу т.н. «говнокода». Сомнительные архитектурные решения либо уже приносят кучу проблем, либо обещают их в будущем, но работают. Поток новых требований не дает времени навести порядок даже в инфраструктуре, не говоря уже о коде. Если вам такая ситуация знакома — добро пожаловать под кат поностальгировать, поучиться чему-то новому и/или поучить нас. Кому поржать, а кому и поплакать.

    «Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.


    Проблемы №1: база.


    Самые неприятные проблемы на любом web-проекте всегда связаны с базой данных. Все остальное мы легко умеем скейлить — от DNS-balancing до директивы upstream в конфиге nginx. «А как же кластеризация?» — спросит вдумчивый читатель. В этом-то и проблема. Я в третий раз наблюдаю кластер насилуемых баз данных. Дважды MySQL и однажды MongoDB. Индексы не настроены, таблицы (коллекции — какая разница?) не чистятся, зато проплачены недешевые серваки под кластер. И в основном эти серваки заняты разгребанием непроиндексированных данных и построением неиспользуемых индексов во имя энтропии.

    Особенно распространена эта группа проблем в конторах, практикующих модную нынче тенденцию отделения backend-разработчиков от админов/DevOps/NOC.

    Почему страшно держать базу в уставшем состоянии? Да потому что потеряете к чертям все: заказы, клиентов, SEO page rank. Да и зачем хостеру переплачивать?

    Лично у меня, испорченного нищим детством, сразу же возникает крик души: не платите хостеру, заплатите лучше мне.

    Еще из прекрасного: при наличии под ногами штормящей уставшей базы, и как следствие — несколькосекундный response у веб-сервера практически на всех страницах — проводить перформанс импрувмент, старательно не трогая базу.

    Проблема «n+1»


    Оказывается, есть два крупных типа изнасилования базы, хотя еще пару месяцев назад об этом, самом смешном из них, лично я и не подозревал. Вы слышали о «проблеме n+1»? Я вроде припоминаю что-то такое в глубоком юниорском детстве. В жизни бы не поверил, что что-то такое может прорваться на прод коммерческого проекта. Проще всего проблему можно характеризовать псевдокодом:

    list = db.query('SELECT * FROM products;')
    for (item in list){
          orders = db.query('SELECT * FROM orders WHERE product_id = ?;', {product_id: product.id});
          ...
    }
    

    Идентифицируется проблема легко. Берем полный access log веб-сервера и query log базы данных за один и тот же период, и тупо сравниваем по объему. Если 50MB access log превращаются в 20GB query log — проблема идентифицирована. Из плохих новостей — вам придется модифицировать код, а там врядли вас ждет что-то хорошее, при таком-то отношении к базе.

    Лозунг проблемы: webdev — это всего лишь преобразование действий пользователя в запросы к базе данных и вывод результатов. Все.

    Наиболее сильно проблемой страдают go-программеры со своими горутинами. В меньшей степени она присуща адептам рельс, видимо привыкшим, что ActiveRecord на себя обычно берет такие проблемы. И встречается у php и js кодеров.

    Сюда же можно отнести запросы вида:

    SELECT p.*, ( SELECT count(*) FROM comments WHERE product_id = p.id) comment_count FROM products p WHERE author_id = ?;
    

    Господа, это — не один запрос. Это тоже «n+1». Особенно прекрасный отсутствием LIMIT. Менять на JOIN (подзапрос с GROUP BY) — тоже не сахар, но если с индексами — жить можно. А вообще — это два запроса и сджоивание на уровне кода. Руками, если ваш ORM этого не умеет. Хотите — я дам либу для этого.

    Проблема с индексами


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

    Идентифицируется проблема тоже просто: качаем, например, dev.mysql.com/doc/mysql-utilities/1.5/en/mysqlindexcheck.html или www.percona.com/doc/percona-toolkit/2.1/pt-duplicate-key-checker.html, запускаем, смотрим на длину списка лишних индексов. Если их много — база на проекте неухоженная, обязательно нужно проверять запросы. Если не нашли — включаем unindexed query log (в зависимости от типа базы по разному, гугл в помощь) и смотрим его. Если и тут ничего криминального — можем условно считать индексы проставленными аккуратно и перескакиваем к следующему шагу. Хотя опыт подсказывает что принцесса в большинстве случаев именно в этом замке.

    Если же хоть один из вариантов дал выхлоп — готовьтесь к тяжелой и кропотливой работе. К сожалению, придется не только проставлять индексы где возможно, но и модифицировать код. Для MySQL, у которого в EXPLAIN SELECT нельзя получить «ROWS examined», вам понадобится полный query log (long_query_time = 0). Если эти данные грамотно агрегировать, то можно получить приятную статистику. Мне, например, нравится параметр sum(Rows Examined) — он показывает насколько данный тип запросов штормит базу. И еще — соотношение 95-х персентилей по параметрам «Rows Examined» vs «Rows Sent». Он показывает насколько данный тип запросов может быть оптимизирован. Аггрегатор можно написать самим или заюзать www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html. Но будьте предельно внимательны и аккуратны — ошибки в аггрегации приведут к куче потраченных впустую усилий. Применяйте декартов принцип универсального сомнения — любой механизм агрегации, в корректной работе которого вы не убедились лично, дОлжно считать потенциально глючным.
    И не забывайте о ненулевой стоимости пересчетов индексов. Иногда лишний индекс страшнее отсутствующего. Минимизация количества используемых индексов — это первая задача, с которой столкнется, например, игнорирующий закон «если вы хотите использовать RDB таблицу для организации очереди — не используйте RDB таблицу». Но не последняя. Очередь прекрасно строится на механизмах
     SELECT FOR UPDATE ... SKIP LOCKED; 
    имеющихся уже и в PostgreSQL, если кому интересно.

    Наиболее часто непонимание индексов встречается именно среди php-разработчиков. Если мне не будет лень — я таки закончу обучающую статью на тему «чего не могут индексы и почему» для любителей PHP.

    Оптимизация размеров таблиц


    Еще помните утверждение, что недешевые серваки заняты исключительно увеличением энтропии — пересчетом неиспользуемых индексов и разгребанием непроиндексированных данных? Добавьте сюда безосновательно разросшиеся таблицы — и вы получите картину, соперничающую своей безжалостной дорогостоящей бесполезностью со Сколково или с оруэловской войной с целью утилизации перепроизводства. Позицию №1 в рейтинге самых очевидных и технически бездарных из всех известных мне причин разрастания таблиц занимает желание хранить устаревшие данные вечно. Например, в соцсети почему-то хранят удаленные сообщения вечно. Почему-то в основной, далеко не низконагруженной, таблице. И да, в той же самой базе.

    Решение: как насчет дополнительной базы c префиксом zip? таблиц? mysqldump? backup?
    Страшное: я встречал проекты, на которых из-за принципа «хранить вечно», нельзя было сделать ALTER TABLE из-за раздутости высоконагруженных централизованных таблиц. Как можно обеспечивать работу такой таблицы? Выдать штатным экстрасенсам бубны и истово молиться за здравие таблицы всем остальным? Зачем так жить?

    Джоины


    Запрос к 10 таблицам в вебе в продакшне может служить поводом для увольнения его автора и ревьювера, ИМХО. Господа, юнион, джоины и подзапросы 3-го уровня вложенности — это неплохой способ повыпендриваться. Или поискать что-то для себя в базе. Но никак не способ общения с бд хоть сколько-нибудь нагруженного проекта.

    В том числе и из-за локов. Локи становятся проблемой задолго до того, как вы увидите дедлок в error логе. Да, количество локов можно сократить при единообразной сортировке условий типа parent_id IN(сортированный список id).

    Ваша СУБД гарантировано не знакома с бизнес-логикой вашего же приложения и может только попробовать догадаться как именно будет лучше всего вытащить вам данные из десятка запрошенных таблиц. Знаете это только вы. Что, построить хеш-индексы в php и сджоинить два массива данных в памяти не сможете? А с библиотекой? Если не найдете — я покажу свою.

    Проблемы с централизацией таблиц


    В достаточно сложной асинхронной системе, в которую превращается любой крупный веб-проект, база и/или ее таблицы становятся ресурсами, поскольку являются блокерами для одних типов операций во время выполнения других типов. Например — пересчет индекса блокирует использование этого индекса и уж точно блокирует еще один пересчет.

    Словом «ресурс» почему-то принято обозначать исключительно хардварные характеристики используемых систем — CPU, bandwidth, RAM. Но определить постоянный или пиковый недостаток таких ресурсов достаточно просто, корректные инструменты — munin/monit/sa+sar/htop и/или умеющий этим всем пользоваться грамотный админ — расскажут вам о ситуации все за небольшие деньги и в весьма приемлемые сроки.

    Но вот относиться к таблицам в реляционной бд как к ресурсам никто почему-то не пытается. А ведь это — очевидное решение. Если UPDATE-запрос на таблице приводит к пересчету индекса, то ни один использующий этот индекс SELECT до окончания пересчета (ну или во время переключения, если вы верите в ровные руки авторов своей СУБД) выполнится, увы. В PostgreSQL при использовании immutable tuples любой UPDATE приводит к пересчету всех индексов таблицы.
    UP1: по утверждению terrier PostgeSQL хорош для тех, кто умеет его готовить. Uber ошиблись и злобствуют. Не так чтобы очень удивительно. Помните утверждение Эйнштейна о бесконечности Вселенной?

    В MySQL на первый взгляд все не так страшно. Но грамотно организованная высоконагруженная таблица несет в себе именно один-два важнейших индекса, и большинство апдейтов все равно приводит к их пересчетам. Зачем вам одна таблица на все типы продуктов?

    Решение: создайте таблицу products2, обеспечьте непересечение значений ее первичного ключа с исходной таблицей. Наслаждайтесь. Если же какой-либо более-менее массовый тип продукта отличается по структуре от остальных — сама нормализация бд требует от вас всунуть его в отдельную таблицу.

    Страшное: люди, любящие централизовывать таблицы, отличаются тягой к цетрализации (микро)сервисов при построении архитектуры. Не для них, видите ли, сказано «не инкапсулируйте в сервисы, инкапсулируйте в классы». На выходе получается то же самое — куча bottleneck с неочевидными причинами существования мешают скейлить систему при увеличении объемов данных и/или нагрузки.

    Лозунг: не инкапсулируйте в сервисы, инкапсулируйте в классы

    Проблемы №2 — код


    На любом проекте любой программист всегда считает весь код говном, кроме того, который он пишет прямо сейчас. И то — не всегда.

    Видимо, количество хорошего кода во Вселенной — величина неизменная. Какой-нибудь закон сохранения, как с массой-энергией или с деньгами. Поэтому когда программист пишет хороший код — какой-нибудь код в этот момент становится плохим.

    Так что сверх минимума заморачиваться на качестве кода не стоит. CodeSniffer плюс code review на первом уровне code quality должны удовлетворить любые субъективно-оценочные критерии «читабельности» кода.

    Глубже — хуже: лишние слои абстракции почему-то не отсекаются на этапе code review. Так же как и over-pattern-usage. Вы знаете когда нужен синглтон? Чтобы ограничить доступность ресурса, доступ к которому уже организован через создаваемый неуникальный экземпляр класса. Если синглтон пишется с нуля — вы получите в итоге антипаттерн в большинстве случаев. Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн. Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код. Скорее всего причиной можно считать то, что репозитории используются в stateless режиме — как группа функций схожего назначения. В отличии от конкурирующего с ним паттерна ActiveRecord, в котором сразу ясно что именно является состоянием.
    При этом, на удивление, более простые и реально помогающие правила SOLID не используются. Да что там SOLID — не используется даже инкапсуляция из определения OOP. Такое ощущение, что веб-девы помнят что такое инкапсуляция только на собеседованиях.

    Решение: показать, как правильно выстроенная иерархия именно интерфейсов (помните, проектируй на уровне абстракции?) позволяет создавать гибкие и легко дописываемые приложения.

    Лозунг проблемы: лишние слои абстракции — это отстой. Думать надо не паттернами, а головой.

    И да, вы же сами программисты. Вы верите, что бывают программы без багов? Все используемые вами инструменты — это тоже слои абстракции, только архитектурно-сервисные. Webdev — это превращение действий пользователя в запросы к бд и вывод результатов. Объясните мне где в этой формуле прячется apache? Вам действительно нравится видеть рассеянный по куче .htaccess-файликов роутинг?

    Проблемы №3 — фронт


    Самый презираемый класс программистов — яваскриптовики. Шутки про this. Отличительные признаки проектов, у которых фронтенд в стиле а-ля нулевые — куча подключаемых файликов и/или JQuery в смеси c ExtJS, и/или свой MVC велосипед, навевающий на мысли о раннем backbone.js. То есть — абсолютно неподдерживаемый код, неоправданно дорогостоящий на любых модификациях, априори глючный и костыльный.

    Решение: нормальный, es2015 javscript. Одностраничное приложение с роутингом, а не куча конфликтующих jQuery плагинов и условий. Единая точка входа. Постепенный эволюционный перезд, начиная с роутинга. Обоснованный и вдумчивый выбор архитектуроопределяющих технологий. Например, TypeScript противоечит самой идее JS: анархия, раздрай и полный бардак высококачественной рапид-разработки. ИМХО конечно же.

    Проблемы №4 — окружение


    Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки. Ну так мы ж и не дизайнеры. Ну тут продолжать не стану, не холивара ради статью кропаю.

    Я не понимаю как можно разработчику настраивать свое дев-окружение не самому. Да, пусть новичок пару дней сам пострадает с установкой проекта. Ну так сразу будет виден его уровень: по задаваемым вопросам и нерешенным самостоятельно проблемам. Точно так же новичок и сам многое о проекте поймет.

    Я не понимаю как можно кодить с выключенными ворнингами. Бесплатное раннее обнаружение ошибок не нужно? Неужели действительно проще нанять еще один отдел тестеров?

    Я не понимаю как можно жить без бета-площадки. Где же будут пастись эти лишние отделы тестировщиков? Как обеспечить zero-time-deployment без беты я не представляю тем более.

    Я не понимаю как можно без zero-time-deployment. Контору че, не штрафуют за downtime сайта?

    Я не понимаю как можно держать проект в продакшне, не имея настроенной системы интеграционных тестов. Что, сложно поставить Jenkins и всунуть скрипт, который раз в час будет логиниться / регистрироваться / проверять почту / покупать / продавать и паниковать при ошибке на почту / смс / хипчат? Неужели не хочется узнавать о проблемах не от клиента? Ах, да не штрафуют.

    Я не понимаю как можно держать весь код вместе с конфигами в веб-руте? А вы точно везде deny from all прописали? Не тянет перепроверить?

    Я не понимаю как можно раскручивать сайт, у которого несколько секунд время загрузки страницы. Это же дорого!

    На этом перечень решаемых с технической точки зрения проблем заканчивается. Дальше начинаются…

    Проблемы организационного характера.


    Далеко не все из них решаемые, к сожалению.

    Проблема №0: коммуникации.


    С бизнесом можно разговаривать только на языке бабла. Он не восприимчив к красоте решений, нормализации базы, CAP-теоремам и прочим IT-ценностям. Он понимает деньги и сроки.

    Решение: подобрать из беклога несколько таких задач, чтобы можно было и обосновано и честно заявить клиенту, что эти задачи будет дешевле имплементировать на переделанной системе, даже с учетом переделки. Если ты не можешь подобрать и обосновать перечень задач — уйди мальчик, тебе еще рано переписывать систему. Задачи, если что, лучше подбирать посвежее — клиента к ним тянуть будет сильнее. Да и не придется отвечать на вопрос «почему решились только сейчас?».

    Лозунг: бизнес никогда не дает переписать. Пишите сразу нормально.

    Проблема №1: управленчество


    Говнокод сам по себе не рождается. Посмотрите на микромягких — авторитарный стиль управления Билла, позволяющего себе орать на подчиненных и срывать им сроки, родил настолько идиотские архитектурные и/или технологические решения, что даже конечные пользователи понимают, что страдают от их последствий. Отличителным признаком проблемы можно считать фразу «все программисты всегда хотят все переписывать. Мы не будем».

    Что делать: убеждать. Например, через статьи на хабре. Или уходить. Это — единственная проблема, которую нельзя решить системно без топора.

    К этим же проблемам можно отнести «централизацию людей» — самые толковые люди настолько заняты и контролируют столько вещей, что не могут вникнуть ни в одну из них. И вечно надо ждать принятия ими решения. Ну чем не bottleneck?

    Решение: микрокоманды.

    И да, продолжая параллели с архитектурой приложения — лишние слои абстракции здесь тоже sucks. Back in USSR, когда на каждого работягу два управленца. Ну так у них труба нефтегазовая была. И есть.

    Чем меньше ушей на пути информации от источника требований до их осуществителя — тем лучше. А то получается как картинка-история с качелькой. И пара отделов лишних нахлебников — менеджеров, занятых войной с JIRA / Redmine и/или выполнением распоряжений других менеджеров.

    Самое главное — не опускать руки. Ведь, возможно, вы в самом интересном этапе — написание платформы устаканившегося денежного проекта. Прекрасная строка в резюме если что, а пока — замечательная финансовая подпитка. Предаставляете, например, как поднимет вашу ставку небрежно брошенная на собеседовании фраза «избавился от несколькотерабайтной базы»?

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

    Подробнее
    Реклама
    Комментарии 188
    • +4
      Если UPDATE-запрос на таблице приводит к пересчету индекса, то ни один использующий этот индекс SELECT до окончания пересчета (ну или во время переключения, если вы верите в ровные руки авторов своей СУБД) выполнится, увы. В PostgreSQL при использовании immutable tuples любой UPDATE приводит к пересчету всех индексов таблицы.

      Непонятно, что вы имеете в виду. Что такое «пересчет» индекса? UPDATE, конечно же апдейтит индекс, но это вполне уживается с SELECT'ом.

      The core PostgreSQL system obtains AccessShareLock on the index during an index scan, and RowExclusiveLock when updating the index (including plain VACUUM). Since these lock types do not conflict, the access method is responsible for handling any fine-grained locking it might need. An exclusive lock on the index as a whole will be taken only during index creation, destruction, or REINDEX.

      https://www.postgresql.org/docs/9.6/static/index-locking.html

      Если под «пересчетом» вы понимаете REINDEX, то нет, конечно же при UPDATE никакой REINDEX не делается.
      • 0
        Под пересчетом индекса я подразумеваю ситуацию, в которой большое количество SELECT запросов при встрече с большим количеством UPDATE-запросов создают затык. Если вы расскажете как этого затыка избежать — вы мне окупите все усилия на написание этой статьи.
        • 0

          Насколько я понимаю обычно путь джедая к светлой стороне такой
          1) Замена update -> insert & delete
          2) Если первый пункт не помог, аккумулирование изменений в очереди/кэше и отложенный multi insert/ multi update
          3) Если же объем модифицирующих запросов на столько велик, что ничего не помогло, надо уходить с MySQL. Здесь сложно что то посоветовать куда уходить. Для примера можно посмотреть Cassandra, Click House итд

          • +3
            INSERT не приводит к пересчету индексов? То есть поток INSERT на таблицу не замедлит поток SELECT?

            И перед сменой основной СУБД я бы все-таки попытался выжать поболе из используемой. А то все технологии со своими минусами, а с минусами этой мы вроде хоть знакомы.
            • +3
              У INSERT… DELETE vs UPDATE откуда преимущества вообще? Кроме меньшего количества самих запросов. Uber по-моему свалила с PostgreSQL из-за иммутабельности tuples и вытекающих из этого проблем с оверпересчетом индексов при апдейтах даже непроиндексированных полей. И зашкаливания объемов бинарного лога, что увеличивает стоимость синхронизации серверов в кластере.
              • +2

                Сейчас погуглил, не нашел подтверждению пункту 1, так что можно его считать не актуальным. Если не хочется возиться с новой технологией можно рассмотреть вариант репликации master/slave. Пишем в master читаем со slave. Правда при большом объеме модификаций возможно отставание реплик. В 5.7 появился cluster https://dev.mysql.com/doc/refman/5.7/en/faqs-mysql-cluster.html

                • +1
                  да-да-да. именно о таком подходе я писал
                • +1
                  и вытекающих из этого проблем с оверпересчетом индексов при апдейтах даже непроиндексированных полей.

                  Это не так. По неизвестной причине уберовцы написали просто вызывающе неверную информацию в своей статье и она, к сожалению, пошла в народ. При апдейте непроиндексированных полей срабатывает HOT-оптимизация и индекс не трогает ( с 2007 года так). Вообще в той статье убера, наряду с несколькими действительно разумными аргументами, есть несколько просто WTF-points.
                  • 0
                    any proof? я читал об этом не у них.
                    • +1
                      sure.
                      HOT (Heap-only tuples) is a major performance feature that was added in Postgres 8.3. This allowed UPDATES to rows (which, owing to Postgres's MVCC architecture, are implemented with a deletion and insertion of physical tuples) to only have to create a new physical heap tuple when inserting, and not a new index tuple, if and only if the update did not affect indexed columns.

                      https://wiki.postgresql.org/wiki/Index-only_scans#Interaction_with_HOT

                      Ну и собственно, все что угодно по запросу «hot-optimisation postgres», это же не какой-то секрет
                      • 0
                        Спасибо! делаю UPDATE.

                        А по умолчанию опция выключена? Или они там в Uber совсем тормозят?
                        • +1
                          По умолчанию включено, но оптимизация срабатывает тогда, когда новая строка находится на той же странице, что и старая ( помним, что при апдейте создается новая строка, так как они иммутабельны ) и возможно для повышения вероятности срабатывания нужно пошевелить параметр fillfactor ( подробнее здесь)
                          В случае убера мы можем попытаться предположить, что у них там большое количество индексов на таблице и большинство апдейтов все-таки затрагивают проиндексированные колонки, но это догадки.
                          • 0
                            помогает?

                            я правильно понял что Uber уехали с PostgreSQL из-за проблем с пересчетом индексов? не разобрались как настроить? Такая очевидная справка?
                            image

                            или системные проблемы с пониманием СУБД?
                            • +1
                              помогает?

                              Безусловно.
                              В убере, по-моему, отдел БД просто любит движуху, вот и мигрируют туда-сюда. Не удивлюсь, если завтра они начнут переезжать куда-нибудь на VoltDB.
                • –1
                  преимущество в том, что ненадо делать поиск по всей таблице. Это огромное преимущество
              • +1
                Скорее всего ситуация, когда большое количество SELECT запросов встречается с большим количеством UPDATE-запросов в одной и той же таблице — архитектурный просчет на этапе проектирования конкретной БД.
                Нужен практический пример, когда вы столкнулись с такой ситуацией в реальной жизни.
                Скорее всего можно предложить другую архитектуру хранения и использования данных для такого случая.
                • 0
                  Вы уверены что это именно ошибка? Есть конкретные примеры решения такой архитектурной ошибки? Ну кроме уже предложенного выше способа «пишем в мастер, читаем со слейва».
                  • 0
                    Я ни в чем не уверен, до тех пор пока не понимаю сути конкретной, а не абстрактной проблемы — и я об этом написал. Сначала дайте конкретный практический случай этой проблемы (именно это я предложил выше), а уже потом спрашивайте какие есть варианты ее решения!
                    • 0
                      Площадка-интернет-магазин с редактированием товаров продавцами онлайн. Как архитектурно верно избежать встречного потока SELECT — UPDATE и связанного с встречей замедления обоих потоков?
                      • 0
                        Вделать журнал обновлений, а не модифицировать саму строчку
                        • 0
                          Какие фреймворки поддерживают прозрачную работу с данными в базе и еще находящимися в журнале? Потому что если такой поддержки нет, все бонусы от использования этого фреймворка нивелируются и начинается тотальный изврат.
                          • 0
                            Незнаю, работу с журналом я делал руками
                          • +1
                            INSERT в журнал обновлений встречается с SELECT по тому же журналу.

                            Стоимость развязки SELECT — INSERT чуть выше, чем SELECT — UPDATE, не согласны?
                            • 0
                              Insert происходит в другую таблицу, и в результате у нас селект не страдает
                              • +1
                                Кому нужен журнал, по которому не делается селект?

                                Ваше предложение пока что конкуриет по своей непродуманности с развязкой через кластер: UPDATE на мастере, SELECT со слейва. Надеюсь, не надо рассказывать почему такая развязка не развязка?
                                • 0
                                  Всем кто может позволить себе задержку актуальности списка. Интернет магазин отличный пример
                            • 0

                              Как в такой схеме реализовать, к примеру, поиск товара по описанию, если описание — в журнале?

                              • 0
                                у меня поиск был отдельным сервисом, со своей базой, которая обновлялась асинхронно. Тоесть поиск отставал от актуальной информации, но апдейт элементов в нем происходил сразу пачками, тоесть вместо 10 апдейтов был всего один.
                            • –1
                              Так вроде же все очевидно — надо разделить потоки на две таблицы.
                              Выборка товаров для покупателей должна происходить из одной таблицы (user_table), а изменение-добавление продавцами в другой (main_table).
                              Периодически, по мере накопления изменений в main_table данные программно компилируются в один большой запрос типа:
                              INSERT INTO user_table (key_field, field_1, field_2, ...)
                              VALUES (key1 , ...), (key2, ...), (key3, ...), ...
                              ON DUPLICATE KEY UPDATE
                              field_1 = VALUES (field_1), field_2 = VALUES (field_2), ...
                              

                              для синхронизации таблиц main_table и user_table.
                              • +1
                                На всякий случай добавлю — подразумевается конечно, что в запрос синхронизации попадут только данные последних изменений в товарах требующих синхронизации, а не вся таблица полностью. И как уже писали выше, небольшой лаг между внесением изменений и их появлением на фронте — для интернет магазина совершенно не критичен.
                                • 0
                                  просто bunch?
                                  теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
                                  • +1
                                    просто bunch?
                                    Да
                                    теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table?
                                    Да, но я не стал бы ее называть журнальной, скорее это основная таблица, а user_table — просто ее копия и желательно, чтобы она была вообще на другом сервере для изоляции буферов БД.
                                    и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
                                    Да. Особенно если запустить его в отдельной транзакции. Такой подход даст существенную экономию на операциях слива буферов изменений в сравнении с кучей отдельных запросов «однострочных» изменений.
                                    • 0
                                      Куча однострочных UPDATE в отдельной транзакции при отключенной переиндексации сработает не так же?
                                  • 0
                                    Я правильно понимаю суть идеи — мы создаем вторую точку встречи на промежуточной таблице main_table и размазываем «нагрузку встречи» между двумя точками?

                                    Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.

                                    Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
                                    • –2
                                      Кхм. Это практически стандартное решение, когда у нас множество апдейтов и селектов. Вы наверное не понимаете насколько insert дешевле update. insert просто вставляет запись, update же сначала ищет запись и т.п.
                                      • +1
                                        да-да-да, я вааще не понимаю чем INSERT… ON DUPLICATE KEY UPDATE… дешевле UPDATE. И в этой ветке обсуждается не журнальная таблица, а промежуточная.

                                        А насчет дешевизны INSERT в контексте пересчета индексов уже отписывался
                            • +2
                              Почему? Вполне обычное OLTP. Тут главное, чтобы SELECT и UPDATE были короткими.
                        • 0

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

                          • 0
                            Примеры?
                            • 0

                              Например, я работаю с odoo и там в основном кастомизация, с нуля никто не пишет.
                              Что бы, как вы написали, разбить таблички для продуктов, нужно перелопатить тысячи и тысячи кода.


                              Максимум, что помогает — денормализация)

                              • 0

                                Я бы назвал сильную связанность минусом yii2.

                            • 0
                              Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн.

                              Слабая связанность, гибкость и расширяемость, лучшая читаемость и переиспользуемость — это теперь зовется «атипаттерн»? SOLID, не?
                              Самый презираемый класс программистов — яваскриптовики

                              У Вас какие-то комплексы на этот счет? Так-то адекватные люди не разделяют коллег по языку программирования.
                              Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки.

                              А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать? Или только «мы ж и не дизайнеры»?
                              • +1
                                Я бы даже сказал, есть не очевидный плюс windows платформы. После всех набиваний шишек, в вашем git репозитории точно уже не будет:
                                — внезапных проблем с \r \n
                                — проблем с путями "\"
                                — проблем с путями, отличающихся лишь регистром
                                и даже больше, на ходу вспомнилось пока это
                                • +2
                                  Я бы отнес это к минусам, но холиварить отказываюсь, если что.
                                  • +1
                                    Какие-то двойные стандарты получаются на мой взгляд.
                                    Вот вы ниже в ответ на
                                    А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать?

                                    пишете
                                    А линукс заставляет думать. И уметь.

                                    А тут получается если нужно задумываться про разные разделители путей, новой строки и регистрозависимость файловой системы — это минусы.
                                    • 0
                                      разделители путей и тип новой строки — это такие смешные проблемы, что я, простите, о них уже и не вспомню. надеюсь, никогда.

                                      посыл изначально был о том, что под линухами даже конечным пользователям приходится решать проблемы, достаточно сходные с деплоем web проекта, к примеру. как мимнимум тренирует навыки StackOverflow-driven-development.
                                      • 0
                                        По вашим словам и на правах шутки.

                                        Вы говорите, что заниматься проблемами линукса лучше чем делать реальную работу, так как они похожи
                                        • 0
                                          да-да-да. и даже местами идентичны.
                                  • 0
                                    Простите, но какие из этих проблем у вас возникали не под Windows?
                                    Я вот с переходом на Windows испытываю проблемы:
                                    1) С кодировкой (да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866 на выдаче VC компилятора)
                                    2) Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
                                    3) После шиндовспрограммистов приходится долго и муторно править регистры путей, а бэкслэши вместо слэшей у всех остальных ОС добавляют смеху, ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет.
                                    Итого: если у вас сервера на винде — могу вам только посочувствовать, а если на *nix, то вы огребёте проблем при деплое после разработки на винде. Где тут профит я не вижу.
                                    • 0
                                      В этом и плюс, после Windows у вас в проекте не будет таких проблем, когда будут приходить другие Windows программисты, т. к. вы сами эти проблемы и решите.
                                      • 0
                                        Ещё раз — проблемы будут на деплое. Или я должен следить за всеми? Или код под диктовку писать чтоб никто не косячил? Да и невозможность таких «ошибок» явно лучше их исправления.
                                        Я вообще негативно отношусь к Windows и Windows программистам так как считаю, что хорошее ПО должно быть кроссплатформенно и для этого сейчас есть всё, что необходимо, а разрабатывать под виндой это как кактус есть хотябы потому, что консоль и кодировки.
                                        • +1
                                          Хуки на гите, отсутствия в проекте файлов вида *.lua и прочее — вот это всего не будет, потому что наличие windows разработчика означает что проект собирается и работает под windows.
                                          Не очень понял чем работа в Windows мешает кроссплатформенности. Наоборот, если вся команда на linux, кто тогда делает порт на Windows?
                                          Консоль… вы можете поставить любую консоль. Bash, powershell, etc
                                          Как и окружение. Все прекрасно настраивается, кастомизируется. Заметьте, Linux из коробки тоже не огонь.
                                          • –1
                                            К сожалению, наличие windows-разработчика на проекте чаще означает корявые коммиты в CVS и прочие проблемы, чем их отсутствие.
                                            • 0
                                              Ну то есть вы говорите «давайте будем снисходительны к программистам под виндой». Ну как бы ок, я понял. Вы даже вероятно правы по поводу того, что в кроссплатформенном ПО проблемы всё равно придётся решать.
                                              Чтож, пусть каждый пишет где ему нравится, я как и прежде буду считать, что это АД.
                                              А Linux из коробки (без GUI) для серверов норм.
                                              • +1
                                                Ну вот я снисходителен к Linux разработчиком, чьи проекты не запускаются на Windows из репозитория, хотя должны, т. к. используют кроссплатформенные инструменты. Логично ожидать подобного.
                                                • 0
                                                  Лучше пинать обоих, может начнут писать нормально =)
                                                  Вообще смотря на чём, я сталкивался только с C++, так вот кто-то мне уже тут говорил, что если писать в соответствии со стандартом, то никаких проблем не будет, а платформозависимые функции стандартом не назовёшь, не говоря уже о неопределённом поведении.
                                        • –2
                                          да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866

                                          А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных? Если хоть выбрать любую из них, то потом в крокозяблы превращаются даже маны… Интересно, зачем вообще в настройки добавляют опцию, которая не работает? :-)


                                          Что же до проблем с кодировкой на винде — то на самом деле проблема не в винде, а в американских разработчиках, которые эти кодировки игнорируют. Почему-то мои программы проблем с кодировками не испытывают.


                                          Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.

                                          Не путайте Windows и Notepad. Это немного разные программы.


                                          ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет

                                          На самом деле понимает, только надо не забывать заключать пути в кавычки.

                                          • +1
                                            А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных?

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

                                            Мне сложно говорить за всех, я тут в установщиках стабильно наблюдаю кракозябры. И повторюсь про VC компилятор, IBM866 ни в какие рамки, пришлось использовать английский, иначе не лечится.
                                            Не путайте Windows и Notepad. Это немного разные программы.

                                            Я вас, вероятно, огорчу, но разработчик один и Notepad входит в стандартную поставку без возможности выпилить. Да и были программы (за давностью лет не помню какие), которые делали то же самое.
                                            На самом деле понимает, только надо не забывать заключать пути в кавычки.

                                            К сожалению часто берутся относительные пути, а комбинации '\' и '/' винда не приветствует даже с кавычками. Во всяком случае у меня не вышло, но может руки неоттуда?

                                            Вообще всё это холивар, который по факту не приведёт к моей любви к этой ОС или вашей ненависти. Вы либо работаете только с Windows, либо не программист, ну я не знаю других причин почему её можно любить.
                                            • 0

                                              На самом деле есть еще вариант кросс платформенного приложения под Win/OS X + веб сервисы. Разрабатывать под винду из под Wine то еще "удовольствие". Для комфортной разработки под OS X так или иначе желателен мак. Зато весь веб стек заводится с полпинка на Windows. Вопрос c консолью тоже закрывается очень легко. У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие. Сейчас вот появилась еще Windows Subsystem for Linux. Вопрос \n vs \r\n тоже закрывается прямо при установке git (checkout \r\n push \n). Раньше еще был плюс в виде Notepad++ — на глаз один из самых быстрых редакторов в плане открытия файла. С выходом VSCode это уже не так актуально.
                                              Правда есть один нюанс. win10 ужасно не стабильная и тормозящая ось. А вот win7 была вполне себе ничего

                                              • –1
                                                Зато весь веб стек заводится с полпинка на Windows

                                                Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
                                                А если это был упрёк, что веб-стэк трудно завести где-то ещё, то вы снова сильно ошибаетесь, на windows его завести по моему опыту сложней всего в сравнении с другими ОС. И да, win10 невозможно пользоваться, я уже второй месяц в этом убеждаюсь.
                                                Раньше еще был плюс в виде Notepad++

                                                Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.
                                                У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие

                                                Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.
                                                • –1
                                                  Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.

                                                  Ну и в чем в таком случае проблема?

                                                  • 0
                                                    Вы это к чему написали? Проблемы описаны выше — наличие у Windows ряда исключительно собственных решений, которые приводят к конфликтам при разработке и не только. А IDE и редакторы тут вообще не при чём.
                                                    • 0

                                                      К тому, что вы вольны не использовать эти решения, если они приносят больше проблем, чем пользы.


                                                      Если вы используете JetBrains или Sublime — то наличие в винде кривого Notepad вашей проблемой не является.

                                                      • 0
                                                        Если бы в команде работал только я проблем бы не было вообще, но крайне редко над продуктом работает один разработчик.
                                                        • 0

                                                          Этот разработчик волен не использовать эти решения, если они приносят больше проблем, чем пользы.


                                                          Если он выбрал такие решения, а сопутствующие проблемы перегружает на других разработчиков — это проблема не винды.

                                                  • 0
                                                    А если это был упрёк, что веб-стэк трудно завести где-то ещё

                                                    Нет как раз наоборот. Веб стэк легко завести на чем угодно OS X/Win/Ubuntu/CentOS итд


                                                    Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.

                                                    Я лично без проблем заводил под Win node.js, php/nginx, php/apache, golang, rust(правда на ранних версиях была проблема с openssl), java бэкенд. Мне кажется это покрывает процентов 80 всех вариантов


                                                    Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе.

                                                    JetBrains тяжеловат, плюс к тому будучи написанным на java работает на любой оси. Sublime — да, неплох


                                                    Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.

                                                    мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.

                                                    • 0
                                                      мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.

                                                      Вы не в ту сторону подумали. Права, согласовать, заставить с этим работать всех разработчиков (когда ты один на Маке, целевая Android, но тестовый интерфейс на Qt должен работать на винде, ибо частично тебе с базой «помогает» Windows-программист). Не тривиальная задача настроить сборку в три платформы с минимумом доп утилит и одним методом, ещё и чтоб это работало у каждого в своей IDE.
                                                      • +1

                                                        По вашему комментарию (https://habrahabr.ru/post/329478/?reply_to=10241628#comment_10241608) понял о чем Вы говорите. Да с C++ есть проблемы в области кроссплатформенности. Есть какие то подвижки в правильном направлении (например при использовании CMake) к унификации, но в плане организации сборки, нормального кроссплатформенного решения я не нашел. Хотя мне кажется здесь проблема глубже. В С++ не хватает общего пакетного менеджера и нормального управления зависимостями. Может быть если бы приняли модули в 20 стандарте стало бы проще организовать сборку

                                                • 0
                                                  а комбинации '\' и '/' винда не приветствует даже с кавычками

                                                  Ничего подобного, они работают в любых сочетаниях.

                                                  • 0
                                                    C:\Users\rucku>Xcopy /Y /E "../rucku/SDK.h" «F:/»
                                                    0 File(s) copied
                                                    C:\Users\rucku>dir

                                                    07.04.2017 13:34 204 709 SDK.h

                                                    C:\Users\rucku>Xcopy /Y /E "..\rucku\SDK.h" «F:\»
                                                    ..\rucku\SDK.h
                                                    1 File(s) copied

                                                    Конечно, работает, только не везде видать.
                                                    • 0

                                                      Если Вас интересует именно вопрос копирования можно использовать http://gnuwin32.sourceforge.net/


                                                      c:\GnuWin32>cp ../GnuWin32/readme.txt ./var
                                                      
                                                      c:\GnuWin32>cp ..\GnuWin32\readme.txt .\var

                                                      Обе команды делают одно и то же
                                                      Есть еще cygwin, MinGW32 и WSL

                                                      • 0
                                                        Мы говорили про консоль Windows или как поставить линуксовый софт/виртуалку? Накатив кучу софта все могут, а вы попробуйте убедить пяток разработчиков, которым это всё до лампочки, что надо это ставить. Или пользуйтесь тем, что есть по умолчанию.

                                                        Я серьёзно сталкивался с этой проблемой и серьёзно решал её через родные средства (за исключением make/cmake).
                                          • +1
                                            «У меня нет комплексов, я просто хочу делать это только с тобой» (с) «От 180 и выше».

                                            А вообще-то имелась в виду ситуация, когда бекенд-разработчики презрительно относятся к фронтенд-разработке. Особенно это комично в случаях, когда последние получают больше.

                                            По поводу Dependency Injection — покажите как вы его используете. И сколько программистов и пилят именно тот код, в котором используется DI?
                                            • +3
                                              Мы например используем одну доменную область для веба и для мобилок. Без ди это был бы угар, ад и содомия. А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу. И без ди очень трудно отслеживать общие объекты. Хотя может это и не так заметно в пхп, где все живет только с запросом.

                                              + очень удобно подцеплять, отцеплять декораторы и перехватчики
                                              • +1
                                                А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу

                                                это отсылает к аргументу phgrey
                                                и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x.
                                                .
                                                Если потратить на solid немного больше времени — начинаешь замечать, что часть принципов противоречит друг другу, и тянет архитектуру приложения в разные стороны. D тянет в слабую связанность, но на связность влияет скорее отрицательно. S повышает связность, но может негативно сказываться на связанность.
                                                D+S+O дают много лишних интерфейсов, связанных с абстракцией реализации, а не абстракцией предметной области.
                                                D+S+O+I легко нарушают kiss & yagni. Всё равно приходится идти на некоторые компромиссы.
                                                А еще DI одинаково легко развязывает слои приложения и превращает код в di-лапшу из интерфейсов и реализаций, наследующих друг друга.
                                                • 0

                                                  Зачем конфиг-то? Достаточно настраивать DI в Composition Root.

                                                  • +1
                                                    Конфиги это наследие прошлого, и тех кто везде хочет поздного связывания. Хотя это надо очень и очень маленькому функционалу и в редких случаях.

                                                    Я напримар использую автоконфигурирование, после явную регистрацию через код для сложный моментов. После идет конфигурация через конфиг файл, но мне это потребовалось всего один раз за всю карьеру(по сути это было больше для тестера, что бы он мог сравнивать несколько конфигураций кода, когда ему нужно было. когда было принято решение это улетело в автоконфигурацию)
                                                  • 0
                                                    Безусловно каждый принцип можно довести до сумашествия. В этом и задача, что бы найти баланс и не проседать по любому из пунктов.
                                                  • 0
                                                    вы абсолютно правы, DI обретает дополнительные плюсы при использовании в долгоживущем приложении.
                                                • –1
                                                  А линукс заставляет думать. И уметь.
                                                  • +2
                                                    Vagrant :)
                                                    И никаких проблем. Вообще. И шрифты в IDE приятные, да и в прочих программах тоже :) Ну да, нужно всего-лишь хотеть чуть чуть разобраться и может быть где-то потратить час на то что-бы исправить какую-то шероховатость один раз потому что разработчики оголтелые маководы и на линуксе у вас будет та же самая проблема :D

                                                    Серьёзно, оголтелые маководы последнее время становятся хоть и мелкой, но назойливой проблемой.
                                                    • +2
                                                      Маководы — братья по unix. Я там kernel panic вот этим вот глазом видел. И GNU tools там в норме. И brew есть. И путь нормальный.

                                                      Если пользователь Windows разобрался с vagrant — то это наш человек, просто зачем-то насилующий себе разум.

                                                      Линуксоиды, по какой-либо причине юзающие иногда Окошечки — игры, фотожаба, мультимедиа, ie — не в счет.
                                                      • 0
                                                        Пришлось однажды «братьям по UNIX» передавать пинок в Slack с подписью
                                                        git config --system core.ignorecase false
                                                        
                                                        потому что они умудрялись в одной директории называть файлы с однотипными префиксами а-ля OneTwo* в названии всеми возможными комбинациями заглавных букв.
                                                        • 0
                                                          не совсем понял проблему:
                                                          OneTwoABBASD — рандом или цикл, не? к /tmp не приучены?
                                                          или OneTwoCamelCase в именах файлов напрягает?
                                                          • +1
                                                            Все яблочные ФС — case-insensitive, в отличии от + git init/clone по умолчанию на маках включает ignorecase. Начинаешь сборку или хуже — деплой, и удивляешь товарищей об отсутствии файлов.
                                                            • 0
                                                              Тут надо отметить, что HFS+ имеет режим case-sensitive и система вполне нормально на ней работает.
                                                              Есть очень небольшое количество приложений, которым от этого сносит крышу (например Steam).
                                                          • 0
                                                            Я если че и сам_snake_case_предпочитаю. Но с psr дружу без нервов.
                                                        • –4
                                                          Вот бы винда наконец-то на ядро линуха перешла.
                                                          • 0

                                                            Лучше бы наоборот. Конечно, за исключением win32k.sys, или где там сейчас GUI спрятан.

                                                          • 0
                                                            по поводу «разобраться» — согласен на 300 процентов. Просто к некоторым проблемам привыкаешь и однажды при dist-upgrade просто лень гуглить.
                                                            • +1
                                                              Docker же :)
                                                            • –4

                                                              Линукс заставляет тратить много времени. И это дорого. Очень дорого.


                                                              Бизнес понимает только язык денег, не так ли? Как вы обоснуете удорожание разработки минимум в два раза?


                                                              Для веб-разработчиков на Виндах есть родной (читай: не тормозящий в виртуалке) IE/Edge. На маках Safari. А ещё там всякий фотошоп, и куча утилит, большая часть которых на линуксе не работает или не поддерживается. Что веб-разработчику искать на линуксе не представляю.

                                                              • –4

                                                                Типичный хабр: обоснованных возражений по сути нет.

                                                                • +1
                                                                  ага. глупцам и наглецам тут грустно
                                                                  • –4

                                                                    Однако, это не мешает таким фанатикам минусовать комментарии со здравым смыслом, когда аргументов у них совсем нет (самих заминусуют).

                                                                    • +2
                                                                      Установка серверного софта — одна команда в консоли, правка пары конфигов (обычно разработчику даже не нужна) и ещё команда на перезапуск сервисов. Если понадобится что-то специфичное — можно в процессе установки инструкцию админу писать, благо на сервере тот же линукс. Браузеры — лис и хромиум, никаких виртуалок под них не надо. IDE нынче кроссплатформенные; psd открывается gimp'ом, для вёрстки этого вполне хватает, если очень нужен именно фотошоп — под вайном он работает; что за «куча утилит, большая часть которых на линуксе не работает» — ума не приложу. А ещё рабочее место выходит дешевле, поскольку не нужно покупать лицензию на винду.
                                                                      Лучше обоснуйте свой тезис про потраченное время, я как-то не замечаю чтоб из-за выбора оси я тратил по четыре лишних часа в день.
                                                                      • –4

                                                                        Вы ветку вообще читали? Какое это отношение имеет к фронтент-разработчикам?!


                                                                        Браузеры — лис и хромиум

                                                                        А-ха-ха, тра раза!


                                                                        psd открывается gimp'ом

                                                                        Сразу видно, что вы не открывали типичный PSD гимпом. Он половину информации теряет.


                                                                        А ещё рабочее место выходит дешевле, поскольку не нужно покупать лицензию на винду.

                                                                        Разработчик, умеющий в линукс обходится куда дороже.


                                                                        Покажите реальный баланс, а не рассуждения диванного теоретика.


                                                                        Лучше обоснуйте свой тезис про потраченное время…

                                                                        Вы это про какой?

                                                                        • 0
                                                                          frontend в ветке не упоминался. только в вашем профиле
                                                                          • –2
                                                                            Ветка началась с [комментария](https://habrahabr.ru/post/329478/#comment_10234706):
                                                                            Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки.
                                                                            А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать? Или только «мы ж и не дизайнеры»?
                                                                            Веб-разработка — синоним фронтенд-разработки. Зайдите на любой сайт вакансий и вы это увидите. Если вы называете бэкендеров, которых обычно называют соответственно языку разработки, то у вас каша в голове. Надо чётко говорить, что вы имели в виду.

                                                                            Потому что изначальный тезис опровергается всей практикой. Почему если это так круто и дёшево никто так не делает? Именно потому, что невыгодно иметь админа на каждого веб-разработчика.
                                                                          • 0
                                                                            Везде вижу «веб-разработчиков», и не вижу «фронтенд».
                                                                            Вы это про какой?
                                                                            Линукс заставляет тратить много времени. И это дорого. Очень дорого.
                                                                            • –4

                                                                              Это синонимы, если вы не в курсе.

                                                                              • +2
                                                                                То есть если я пилю серверную часть для SPA или приёмник платежей от paypal/qiwi/whatever — я не веб-разработчик? Вот те раз! И мне по-прежнему интересно, куда же меня «линукс заставляет тратить много времени».
                                                                                • –3
                                                                                  Нет, вы бэкенд-разработчик. Откройте любой сайт вакансий и посмотрите кого там ищут на веб-разработчиков. Фронтендеров. На бэкенд так и пишут: или бэкенд, или конкретный стэк. Ну и да, уровень вашей аргументации типично-хабровский: ни одного обоснования и факта, одни домыслы.
                                                                                  • –3
                                                                                    Что и требовалось доказать. Контраргументов никаких, давайте минусов наставим.
                                                                                    • 0

                                                                                      На сайтах вакансий одно время языки Си, С++ и 1С считались одним и тем же языком.

                                                                                      • –1
                                                                                        Это типа контраргумент? Тут вся ветка полна таких глупостей от оппонентов в напыщенных комментариях.
                                                                • +4
                                                                  Так стек же весь с пол оборота заводится, например docker-compose проект расшарил в команду и у всех одинаковое окружение, все инструменты нативные и работают как надо, костыли никакие не надо. На windows 10 помню пытался настроить окружение для разработки, но там постоянно что-то приходилось подпирать костылями, потому как все работало не совсем так. WSL конечно сглаживает эту проблему, но не до конца.
                                                                • +2
                                                                  Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.

                                                                  Если репозиторий не нагружать лишними функциями, то вполне себе рабочий вариант. Репозиторий должен кэшировать результаты и выполнять запросы в базу. Все остальное лишнее. Мне кажется куда более часто встречающаяся проблема это увлечение god object и не умение найти баланс в делении кода на атомарные логические сущности

                                                                  • 0
                                                                    Скорее всего причиной можно считать то, что репозитории используются в stateless режиме — как группа функций схожего назначения. В отличии от конкуриющего с ним паттерна ActiveRecord, в котором сразу ясно что именно является состоянием.


                                                                    При активной работе над кодом нескольких программистов зачастую приходится специально договариваться по вопросу какие функции считать лишними, а какие — нет. В AR действительно получается проще договориться что к чему относить.
                                                                  • 0
                                                                    Вот же оно — решение всех проблем!
                                                                    Просто нужно следовать статье.
                                                                    Ну, в общем то я тоже за все хорошее, против всего плохого.
                                                                    Поддерживаю в этом.
                                                                    Но думаю, не стоило все сваливать в одну кучу.
                                                                    Попробуйте написать по каждому пункту по отдельной статье, с примерами и нормальной аргументацией, тогда может быть гуд.
                                                                    А в таком виде, это просто метнуть лопатой на вентилятор.
                                                                    • 0
                                                                      это чек-лист тащемта
                                                                      • +3
                                                                        Тащемта — это что означает?
                                                                        А где, собственно чек лист?
                                                                        • +1
                                                                          тут еще один зануда проходил, говорил что правильно — чек-лист.

                                                                          ну вот же — 1, 2, 3, 4 — списки проблем которые нужно проверить. с пояснениями.

                                                                          тащемта в основном используется в смысле «вообще-то». И вы так спрашиваете, как будто это что-то плохое.
                                                                          • +5
                                                                            Спросил, потому, что встретил первый раз.
                                                                            Чем ваше «тащемта» лучше «вообще-то» мне не понятно, зачем бессмысленно коверкать язык не понятно. Вроде любители албанского поутихли. Ну это так занудство.
                                                                            Про чек-лист.
                                                                            Вот у человека проблема некая, с сайтом (или про что ваша статья?)
                                                                            Прочитал он ваш «чек-лист» и что сможет сделать?
                                                                            Да ничего.
                                                                            Чек-листы они очень конкретны и по очень узкой теме делаются, если вы их использовали, должны понимать. Своего рода памятка.
                                                                            От слова «чек», галочка.
                                                                            Проверил, чекнул, поставил галку.
                                                                            У вас не чек лист.
                                                                            У вас статья «О наболевшем».
                                                                            Какую галку человек должен поставить на разделе «Управления»?
                                                                            Типа, Проверь управление.
                                                                            Сразу вопросы. Кто этот чел, проверяющий? Владелец бизнеса, программист?
                                                                            Ага, проверил. Не микрокоманда. Микрософт.
                                                                            И что?
                                                                            Бежать к руководству с предложениями изменить разработку?
                                                                            Или срочно увольняться оттуда?
                                                                            А куда рвануть? В Гугл?
                                                                            Самому не смешно?
                                                                            • +1
                                                                              это не албанский, а прикольная опечатка. оказывается, ее можно использовать для выявления холиварщиков.

                                                                              что делать? внимательно перечитать комментарии и искать специалиста. я могу двух показать. договариваться об удаленном аудите за сколько скажут.

                                                                              не можете? обнять коленки и плакать.
                                                                              • –1
                                                                                Так и напишие статью:
                                                                                У вас косяки с сайтом(или чем там еще), ответ — ищите специалиста.
                                                                                Коротко и смысла столько же.
                                                                                Да, впрочем ваше дело, графоманьте дальше, не обращайте внимание, вам всяко лучше знать, как составлять чек-листы.
                                                                                • 0
                                                                                  если не холиварить — у специалистов можно учиться. гуглить что там тебе советуют. смотреть, пробовать. понимать. даже спрашивать.

                                                                                  это мне чек-лист если что.
                                                                                  • +1
                                                                                    что делать неспециалисту? учиться задавать вопросы на английском языке.
                                                                                    в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.

                                                                                    ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.
                                                                                    • 0
                                                                                      готовить так кстати тоже можно
                                                                                      • 0

                                                                                        Это все приходит со временем… :) Без боли не приходит облегчения.

                                                                        • –1
                                                                          Спасибо за статью. Такие замечания обычно предлагаются в личке, однако я бы хотел оставить его публично, в надежде чтобы его увидело большее количество людей, ничуть не пытаясь задеть чувства автора и прохожих (а вдруг).

                                                                          Если можно, заголовок бы подправить: «чек-лист» пишется через тире. Это составное слово, такое, как всем известное со школы «диван-кровать», они всегда пишутся через тире, ибо правило гласит:

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

                                                                          Замечаю просто сейчас в последнее время какую-то нездоровую тенденцию к их употреблению исключительно в таком виде, что, если честно, реально вымораживает. Ладно бы если изначально они писались бы верно, то тенденция пошла бы правильная, как это часто бывает, однако кому-то стоило начать писать не верно, с тех времен и клонируется… Заранее благодарен!
                                                                          • 0
                                                                            Разве «чеклист» — не заимствованное из английского слово «checklist»?
                                                                            В русском с этими дефисами в заимствованных словах что-то странное.
                                                                            Вот взять хотя бы «дедлайн» вполне можно употреблять отдельные части самостоятельно.
                                                                            Но дефис не пишут.
                                                                            • 0
                                                                              В правилах увидел и другой пункт, касающийся уже непосредственно заимствованных слов, который точно в кассу: «сложные существительные с иноязычными элементами», но время редактирования коммента уже истекло к тому времени.

                                                                              А насчет дедлайна — да, согласен, так уж завелось, так все и пишут. Но в любом случае, никак не раздельно)
                                                                            • 0
                                                                              они всегда пишутся через тире, ибо правило гласит: "… пишутся через дефис"

                                                                              Что-то я не понимаю...

                                                                              • 0
                                                                                Вот и первый прохожий, чьи чувства задел) Вы правы, дефис, моя ошибка.
                                                                            • 0
                                                                              Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.
                                                                              Автор, можете аргументировать более развернуто? Согласен с предыдущим комментарием: если не пихать в репо все подряд методы, код получается вполне чистым.
                                                                              • 0
                                                                                просто труднее согласовать что именно считать «всем подряд»
                                                                              • +2
                                                                                Запрос к 10 таблицам в вебе в продакшне может служить поводом для увольнения его автора и ревьювера, ИМХО. Господа, юнион, джоины и подзапросы 3-го уровня вложенности — это неплохой способ повыпендриваться.

                                                                                Не очень понял альтернативу. Вот есть данные, лежат в 10 таблицах, надо их всех показать.


                                                                                Вместо запроса к 10 таблицам делать 10 запросов?

                                                                                • 0
                                                                                  да. хотите сравнительные результаты нагрузочного тестирования?
                                                                                  • +2

                                                                                    А можно какие то пруфы данного утверждения? Просто если с подзапросами я согласен, то join при правильном проектировании БД обычно проблем не вызывает. Обычно на мускуле самая большая проблема group by. Уже на 20млн записей посчитать статистику становится проблемой

                                                                                    • 0
                                                                                      Я не совсем вас понял: вы просите пруфы у предложения нагрузочного тестирования? Или у утверждения с ИМХО?
                                                                                      • 0

                                                                                        Хочется хотя бы на пальцах понять на каких объемах и каких индексах у join c 10 таблицами начинаются проблемы

                                                                                        • +5
                                                                                          Не верь никому, кроме бога, мамы и нагрузочного тестирования.
                                                                                          • 0
                                                                                            как насчет скрина с абсолютно идиотским планом запроса с тупым использованием некорректных индексов от планировщика MySQL?
                                                                                    • +7
                                                                                      Простите, я правильно понимаю, что вы предлагаете вытащить данные из 10 таблиц, передать их по сети, реализовать через сторонние библиотеки на другом сервере хеш соединение в памяти… и утверждаете, что это быстрее, чем нативная реализация СУБД? Я пользуюсь PG и могу точно сказать, что соединения в базе быстрее. И слабо верю, что в MySQL оно работает сильно хуже
                                                                                      • 0
                                                                                        Абсолютно правильно понимаете. Более того — я уже наблюдал результат такой оптимизации. Дважды. Про постгрес верю, но хочу спросить — на каких объемах данных и нагрузках?

                                                                                        Не сразу понял про соединение.
                                                                                        • +4
                                                                                          Даное утверждение бред. Движки БД заточены на join. У mysql были проблеми с подзапросами (спигнул с него в достаточно давно на более взрослие БД. Поетому не скажу на сегодня, надеюсь исправили. Но и ето легко решалось временними таблицами). Но если правильно написать запрос и план будет логичним — никакой внешний движок не получит прироста при прочих равных условиях.
                                                                                          Положительний результат можно било получить только в условиях полного «топорного» использования БД.
                                                                                          • 0
                                                                                            пруф, результаты тестирования, объемы, нагрузки
                                                                                            • +6
                                                                                              эм, а где в статье пруф и результаты тестирования?
                                                                                          • +2
                                                                                            Могу сказать, что у меня идут запросы с агрегациями по соединениям таблиц, в каждой из которых около миллиона записей. Соединяются от трех до пяти таких таблиц. Соединение идёт по покрывающим индексам и почти не трогает сами таблицы, то речь менее чем о сотне мс. Суть в том, что агрерация идёт в pipeline mode по покрывающим индексам и на клиент уходит компактная свертка результатов в пару сотен строк. Если же делать по-вашему, то нужно выкачать несколько миллионов строк с дисков, отослать их на другой сервер и там повернуть ту же самую свертку в памяти в компактную таблицу, но без кучи оптимизаций по работе с общими буферами PG и буферами ОС. Если хотите, напишите предложение по тесту, я его прогоню по-своему и по-вашему.
                                                                                            • +1

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


                                                                                              Напомню, речь шла не о редких аналитических запросах, а об основных запросах веб-приложения к базе. Такие запросы нельзя держать настолько сложными.

                                                                                              • 0
                                                                                                У вас в статье не шла речь про веб приложение, вы давали общие рекомендации. Я же вам привёл данные из работающей системы медицинских заказов на целый край. И это не редкий аналитический запрос, а типовая проверка для заказа направления между медицинскими учреждениями. Такие данные нельзя хранить отдельно и обновлять, они должны быть актуальны на любой момент времени. И они как то держатся настолько сложными и отлично работают в продакшене. Если вы пишите практики для простых веб приложений, то и указывайте об этом. Реальные промышленные системы обычно на порядок сложнее.
                                                                                                • 0

                                                                                                  У меня в статье?


                                                                                                  И, кстати, не вижу никаких причин, по которым данные, хранящиеся отдельно, не могут быть актуальными в любой момент времени.

                                                                                                  • 0
                                                                                                    Приношу извинения, автор не вы — пятница вечер))
                                                                                                    Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
                                                                                                  • 0
                                                                                                    это моя статья и там в названии сказано что она про сайт))))

                                                                                                    система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.

                                                                                                    и какая, если не секрет, нагрузка на систему?
                                                                                                • <