• Фреймворк для простых проектов на jQuery
    –1
    >для статичных страниц, где есть работа с данными из БД через выгрузки/загрузки через AJAX

    взаимопротиворечивые тексты по разные стороны от запятой :)

    >Переводить на какой то фреймворк проект не дают, по той простой причине — придется изучать его всей команде.

    Та при чем тут, блеать, фреймворк.
    Если код не рефакторить, то каша будет и на нем.

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

    Если это глобальная переменная, то смысл создавать через new?

    П.С.
    Только это вряд ли фреймворк, а датабиндинг. :)
  • Установка и оптимальная настройка Nginx + LAMP (CentOS 7)
    0
    Но вы не шаред хостинг и выключили (не пользуетесь). :)

    Смысла в Апаче 0. :)

    Только память жрет.
  • JSX: антипаттерн или нет?
    –1
    Приехали.

    Пропагандисты говорили, что DOM медленное говно, а их поделки — д«Артаньяны.
    На деле же поделки оказались сами говном. :)
    А-ха-ха. :)
  • Установка и оптимальная настройка Nginx + LAMP (CentOS 7)
    0
    В догонку.
    Если client_body_timeout это между 2-мя операциями чтения, то увеличивать до 100 не нужно было. :)
    Можно было оставить 25. :)
    По умолчанию 60 сек.
  • Когда нужны исключения
    0
    >не работают в multi-threaded окружении

    1. PHP, Node.JS — однопоточные. :) Нам можно :)
    2. А если войти в критическую секцию, то, кмк, все должно работать. Но сложновато. Как и любой другой многопоточный код. :)
  • Установка и оптимальная настройка Nginx + LAMP (CentOS 7)
    +1
    apache под nginx нужен для .htaccess на шаред хостинге.

    Но это не случай автора, он .htaccess вроде отключил.
  • Установка и оптимальная настройка Nginx + LAMP (CentOS 7)
    0
    >Ответил в начале статьи.

    Но на самом деле вы проксируете не только php… :)

    >Почему?

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

    Тем более вы кодировку по умолчанию указываете на двух серверах.
  • JSX: антипаттерн или нет?
    –1
    i360u с ними спорить бесполезно.

    Им нужны технологии, которые позволяют не думать и ни за что не отвечать. :)
    Все то, что делает эта ерунда, можно реализовать с помощью дополнительной пары строчек кода, когда появились тормоза.
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    Собственно ответ дан в комментах:
    https://habrahabr.ru/post/310952/#comment_9832094
    https://habrahabr.ru/post/310952/#comment_9832244

    Расчитано, грубо говоря, на дебилов, которые не осилили имеющиеся технологии.
    За таких программистов скоро будут толченую картошку жевать. :)

    Нужно больше абстрактных фабрик по производству фабрик.
  • Трамплин вызова магических функций в PHP 7
    0
    Сервер случайно не на винде? :)
  • Разработка взаимодействия с пользователем мобильных устройств — ключевые принципы
    0
    1. Ну то есть, чтобы быдло (небыдло, основная ЦА) больше кликало (в т. ч. пытаясь что-то сделать и не смоч) и смотрело рекламы :)

    2. А показатели сродни средней температуре по больнице :)
    Некоторые статьи разбивают на 10 страниц (а самые упоротые — фотогалерею делают постранично :) ).
    Сиди, блеать, кликай, генерируй хиты, трать свое время и траффик.
  • Микросервисы: пожалуйста, не нужно
    0
    >Специально для вас: Greg Young — Stop Over-Engenering

    Мне влом смотреть 50 минут.
    Вы хотите сказать, что я проповедник оверинжиниринга? :)

    Вроде во всем спорах, в т.ч. с Вами, я выступаю против него. :)

    >в этом случае микросервисы превращаются в распределенный монолит. У вас узкое место (одна база данных) так и остаются.

    Плевать.
    Нам что завести 2-100500 баз данных с пользователями для каждого микросервиса, который с ними работает?
    Выйдет что-то на постном масле. :)

    Блин, в прошлом моем комменте
    «С таким успехом монолитом нельзя считать 2 системы, работающие на одном фреймворке. :)»
    следует читать так:
    «С таким успехом микросервисом нельзя считать 2 системы, работающие на одном фреймворке. :)»
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    То есть вся эта мода расчитана на людей, которые не умеют программировать сами? :)

    Таки да.
    Большинство знают инструмент поверхностно.
    А такие оптимизации нужны крайне редко.

    Но при этом зп на фреймворках (особенно модных) выше.
    Но программист ни за что не отвечает.
    Кивнул в сторону фреймворка и свободен.
    Это jquery | DOM | React.js тормозит и свободен.
    Печально, что кто-то принимает решение строить приложение на монструозной архитектуре.
    Это некомпетентность или что? У меня на прошлой работе начальник хотел, чтобы у него было больше программистов в подчинении, типа он ими руководит и ему положена большая зп. :)

    Нельзя все тянуть под одну гребенку.
    Универсальный инструмент не даст выигрыш по всем пунктам.
    Где-то выиграли, а где-то проиграли.
    Нужно с умом использовать текущий инструмент, если есть серое вещество в голове, а не шарахаться с технологии на технологию, потому что так все делают. :)
    Перепиши/отрефакторь существующее решение, если с ним есть трудности и будет тебе профит (в подавляющем большинстве случаев, если текущая технология не такой же буллшит :) ).

    П.С.
    Это касается фреймворков не только JS.
    П.П.С.
    Я также противник мейнстримовых фреймворков PHP. :)
  • Разработка взаимодействия с пользователем мобильных устройств — ключевые принципы
    0
    >как полезным, так и интуитивно понятным

    Вам десктоп мордокниги понятен? :)
    Он скорее всего умышленно непонятный.
    А быдло (небыдло) им пользуется. :)

    >1. Не допускайте перегруженности

    Вот как раз интерфейс Оффиса 2к3 можно было легко настроить под себя. К интерфейсу 2к7+ я так и не привык (он стоит только на работе, дома он нафиг не сдался). :)

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

    А некоторые «профи» говорят, что те же хлебные крошки придумала сотона мохнатая. :)

    >4. Разрабатывайте сенсорные элементы управления такими, чтобы они были удобными для пальцев

    Да, только не нужно эту лапатость переть на десктоп, потом приходится после редизайнов прописывать пользовательские стили. На 1366*768 влезает мало инфы.

    А раньше пользовались стилусом и всех все устраивало :)

    Многие пункты относятся и к десктопу :^)
  • JSX: антипаттерн или нет?
    0
    Вам не кажется, что настолько много гибкости мало кому нужно? :)
  • JSX: антипаттерн или нет?
    –2
    1. Оказалось, под капотом там куча ерунды типа
    https://habrahabr.ru/post/311226/#comment_9831732

    Зачем?

    2.
    а) просто сцепил (сконкатенировал) бы строки, зачем усложнять? :)
    б) тут иногда говорят, что типа сервер может возвращать для скорения уже откомпилированный шаблон/готовый html.
    Капец, а не проще с помощью jquery ajax-ом дернуть страничку / api и обновить нужный DOM?

    Это псевдопрограммирование. :)

    П.С.
    Спасибо хабру, что при отрицательной карме нельзя вставлять код, очень удобно всем.
    Наказали, так уж наказали.
  • Трамплин вызова магических функций в PHP 7
    0
    Почему Вас интересует реализация? :)
    Мне все равно.
    Откройте исходники.

    Вызов несуществующей функции / debug_print_backtrace() в самом внутреннем __call() выводят правильную информацию.

    П.С.
    В прошлом комменте Вы сомневались, будет ли реальный трейс. :)
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    Возможно оно мне и не нужно.

    Я просто не понимаю, где же улучшение, а особенно скорости, если все наоборот. :)

    >Слишком много интерактивности и динамики в интерфейсе — JS код на базе jQuery было очень страшно открывать — не то, что править.

    Это ж не проблема медленного DOM :)
    Нужно было просто отрефакторить код на jquery, так как со временем могли действительно навешать кучу событий и все превратилось в мусор.
    У меня на проектах тоже достался вермишелеподобный код во некоторых местах.
    Но при желании его можно легко отрефакторить и ускорить.

    >jQuery и прямая работа с DOM'ом подходит не всем проектам.

    А не всегда и нужно работать прямо.
    Есть куча оптимизаций. Самые простые:
    1. Не дергать 100500 раз $('selector').some_operationsN(), а сохранить $('selector') в переменную и работать с ней.
    2. Обновлять DOM не кусочками, а допустим сразу аккумулировать в переменную таблицу и вставить ее в DOM.

    У меня тоже бывали тормоза, когда нужно было скрывать/показывать определенные столбцы довольно большой таблицы. Тормоза только в ИЕ (сейчас проверил на меньшем наборе данных (уменьшилось кол-во строк), ИЕ6 не тормозит). Но я не думаю, что React быстрее это сделал бы. :)

    Против Node.js ничего не имею, просто не использую.
    Это немного другой стиль разработки, более сложный.
    Ну и мой весь код на php.
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    Действительно, я не Вам задавал вопрос раньше, а в других темах. :)
    А сейчас тоже не только Вам.

    Просто это не первый мой вопрос, на который не было ответов (правильных) в нескольких темах.

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

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

    А вообще какая разница что это: отмасштабированный монолит / чистейший микросервис.
    Разве отмасштабированный монолит не может в придачу общаться посредством очереди кроме балансировки по урл?

    Главное, чтобы задачи решало.

    У кого-то микросервисы могут ходить в одну базу / писать/читать одни и те же файлы.
    У кого-то все изолировано (как при использовании сторонних API).
  • Установка и оптимальная настройка Nginx + LAMP (CentOS 7)
    +3
    >Nginx, Apache

    Зачем 2?

    >Настраивать сервер как Вы уже поняли, будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев.

    Корелляции тут 0. :)

    >Установим кодировку по умолчанию:
    charset utf-8;

    Вряд ли так стоит делать…

    >Перенаправить запрос Apache:
    proxy_pass http://localhost:8080/;

    проксировать следует только php.

    >Читать заголовок запроса клиента не более 10 секунд:
    client_header_timeout 10;

    Мобилки могут сказать привет :)

    >client_body_timeout 25;
    и
    client_max_body_size 8m;

    У клиента должна быть скорость интернета от 2,6 mbps.

    >Если клиент не принимает ответ более 8 секунд, сбрасываем соединение:
    send_timeout 8;

    Опять мобилки :)

    Забыли прописать хост по умолчанию… :)

    >Отключаем обработку большого количества запросов в одном соединении:
    KeepAlive Off

    Почему?

    >Подключить mimetypes:
    <IfModule mime_module>
     TypesConfig /etc/mime.types


    Зачем, статику ж отдает nginx?

    >Закрываем доступ к .htaccess:
    <Files ".ht*">
     Require all denied


    Лучше на nginx закрыть…
  • Микросервисы: пожалуйста, не нужно
    0
    Везде нужно подходить с умом.
    А то заставь дурака богу молиться. :)

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

    На самом деле это микросервис :)
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 3: добавляем авторизацию и обмен данными с API
    0
    Задаю вопрос повторно:
    Объясните, пожалуйста, почему в последнее время стало модно говорить, что DOM тормозит?
    Что вы такого с ним делаете? :)

    А всякие AngularJS и ReactJS, якобы борясь с DOM тормозами, сами тормозят еще больше :)

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

    В PHP не в произвольную, есть разумные ограничения.

    >Вот теперь заказчик сам вам сказал, где следует породить исключение в написанной для него программе

    Не в этих ли случаях их использовали, давая указанные вами пояснения? :)
  • JSX: антипаттерн или нет?
    0
    Оба представленные способы неправильные. :)
    Первый — на ровном месте писать код, который ничего не делает.
    https://hsto.org/getpro/habr/post_images/9fa/b88/49a/9fab8849a56fd96c3e4f02a998ecad37.png

    Второй — шаблонизатор на ровном месте, когда можно обойтись нативным js.

    Это как заставить дурака молиться богу. :)
  • Трамплин вызова магических функций в PHP 7
    0
    Используйте xml_parser_create().
    Он на порядок (-ки) быстрее распрасит, и памяти меньше жрет.

    Но парсер нужно почти писать самому. :)
    При этом в результирующий массив пихаем только то, что реально нужно, а не весь мусор.
  • Трамплин вызова магических функций в PHP 7
    0
    Все норм :)
  • Трамплин вызова магических функций в PHP 7
    0
    Тоже плюсую за отчет. :)
    Партите с помощью xml_parser_create()? Какой размер файла?
  • Javascript-фреймворки: должен остаться только один
    0
    А в мордокниге написали. :)
    Да и куча их появилась в последнее время. Их же кто-то написал. Или их написали идиоты, которых потом уволили за это? :)
  • Javascript-фреймворки: должен остаться только один
    0
    >Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.

    А как же микросервисы и зоопарк из сопутствующих технологий тому же Реакту? :)
  • Javascript-фреймворки: должен остаться только один
    0
    У меня на работе одна из самых нагруженных админок-одностраничек Украины на ExtJS.
    В чем вообще трудность? :)
  • Javascript-фреймворки: должен остаться только один
    +1
    Просветите, пожалуйста, что для чего больше подходит. :)
  • Как мы чуть не потеряли 5 000 000 гривен в месяц из-за «неправильного» хостинга: история клиента
    0
    >— если бы не отличались, не морочились бы.

    Клиенту выделяется ВДС или это шаред хостинг?
  • Как мы чуть не потеряли 5 000 000 гривен в месяц из-за «неправильного» хостинга: история клиента
    0
    >Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.

    Чем же они отличаются от других высокопрожорливых? :)

    >ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно

    Перейти с арендованного SAS на арендованный SSD.

    >Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях

    Возможно.

    >С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.

    Это было 5 лет назад? Ок.
    Если архитектура гнилая, то, когда она упрется в один сервер, ее трудно будет масштабировать.

    >Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности,

    Я не понимаю, как оно мигрировало, что недомигрировало.
    Если недомигрировало, то хостеру нужно начитстить место, который он ест.
    Если же оно домигрировало, то мои предыдущие опыты говорят, что хостером все удалялось нафиг (может они сохраняли инфу какое-то время у себя, хз).

    >Речь идет о фактах

    Я о самом утверждении «облака решат все ваши проблемы».

    Также вы не ответили об отличиях облаков от классических технологий.
  • Как мы чуть не потеряли 5 000 000 гривен в месяц из-за «неправильного» хостинга: история клиента
    0
    Можете кратко написать, что вы вкладываете в слово «облако».
    И чем оно отличается от вдс/выделенного сервера.
  • Как мы чуть не потеряли 5 000 000 гривен в месяц из-за «неправильного» хостинга: история клиента
    +2
    >Всех наших битрикс-клиентов мы выносим в отдельные сервера, где есть только битрикс-клиенты.

    Какая разница, кто где есть? :)

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

    Блеать, вы же жили в арендованном сервере…

    >Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
    + рисунок внизу.

    Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
    Не проще было сразу на SSD перейти?

    Попахивает рекламой хостера. :)

    >Вот это падение на отечественном хостинге «всего лишь на 3 минуты» выстраивало большую очередь к нашей БД, подвисали все пользователи и система 1С могла за эти 3 минуты выбить блокировку

    У вас просто гнилая архитектура.
    С ростом эта проблема опять вернется :)

    >было заметно, что хостер не рассчитывал на то, что все клиенты единовременно будут на все 100% использовать арендуемые ими мощности.

    Можно подумать, там одни юрики хостят свои бизнес-процессы. :)

    Какие именно мощности вы арендовали?

    >Комментарий от SIM-Networks
    Такие задержки, чаще всего происходят, когда на сервер рассчитанный, скажем на 5 клиентов провайдер размещает 10 клиентов, в (наивной) надежде, что они никогда не будут использовать все свои (уже купленные ими!) мощности. Мы считаем, что если клиент купил место, купил запас мощности – то пустует оно или нет – это уже клиента, и он может делать с ресурсами все что захочет.

    Скорее всего перепроданный сервер будет дешевле.
    Но не факт.

    >И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.

    Но вы же на ссд переехали только у своего любимого иностранного хостера…

    >Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).

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

    Нужно было самим мигрировать.

    >В воскресенье в обед реструктуризация новой полки еще не была закончена

    Что это такое?

    >Перефразируя эту мысль можно сказать: если вы развиваетесь – считаем что нужно идти в облака.

    Хватить толкать маркетинговый бред.

    >Мы снова хотим расширяться, так как нам уже не хватает мощности, и серьезно рассматриваем вариант с облаком.

    Вы же уже в облаке, нет?

    П.С.
    Дочитал до конца, это хостер сам себя хвалил :)
  • Структуры данных для самых маленьких
    0
    Хм, а у меня тупил сам парсинг и памяти много жрало. :)
    Поэтому и использовал xml_parser_create.

    Это ж ООП.
    Чего вы хотели :)
  • Y Combinator: Что нужно сделать еще до взрывного роста
    0
    Корототыш :)

    >Затем им надо создать продукт, который очень понравится пользователям. Только после этого они должны сфокусироваться на росте.

    Как же они растут, если они не нравятся пользователям? :) Реклама?

    Сэм Альтман — родня Семену Альтману? :)
  • Занимательная математика командной строки
    0
    Скорее всего, данный код однопоточный.
    Запустите несколько потоков.