Результаты правильно писать так — среди пользователей sitepoint.com наибольшей популярностью пользуется Laravel. А сами результаты лучше воспринимать в сравнении с прошлогодними результатами:
Lavavel -4.6%
Symfony +3%
Phalcon -14%
Более 90% голосов за фреймворк Nette отдали разработчики из Чехии
Для голосовавших из России (237):
Yii 2 — 53 (22%)
Yii 1 — 39 (16.5%)
Symfony — 39 (16.5%)
Laravel — 27 (11%)
3 человека из опроса признались, что используют Bitrix (2 из России и 1 из Украины)
Drupal так мало потому что такого варианта не было в выборе и люди дописывали его руками.
в принципе за такие деньги можно нанять человека который будет тебе готовить минимум на 2 года и не факт что эта рука отработает дольше и не будет требовать ремонта
уже лет пять как есть всякие облачные роутеры и тп с панелькой управления на сайте производителя.
а если понатыкать кучу таких устройст. то можно просто брать с них же инфу где был такой-то мак и в какое время
> тот IP-адрес, который вы найдёте в заголовках, принадлежит нашим прокси для сжатия
я думаю стоит добавить ссылку на официальный список адресов ваших прокси серверов
просто сгенерировал sql файл c bulk insert (вернее он был, просто округлил до 1м строк). есть еще pgloader он может быть даже побыстрее, но лично его не тестировал
попробовал вставить 1м записей в pg, в достаточно большую таблицу с десятком constraints и внешних ключей и с десятком индексов, (пару gist, пару функциональных + btree)
заняло 112 секунд в виртуалке на ноуте. при этом я получаю гарантированно связанную БД и весь процесс полностью транзакционный, ну и про отключение индексов — в pg их можно «собирать» параллельно, что хорошо походит для единовременной загрузки большого кол-ва данных
пользователь может открывать ваш сайт несколько раз, то есть открыв его второй третий и т.п. раз от опять будет скачивать 1мб шаблонов, в общем кроме крутящегося кружочка для интернет приложений лучше в таком случае ничего не отдавать в «index.html»
Кстати fetch api презентовано внутри Service Worker которые как раз для сложных случаев кастомного кеширования.
про «нежесткую типизированость» я уже в этом топике 3й коммент пишу, ладно доки не читать, но хоть комментарий на который отвечаешь.
по поводу order by:
1) postgres тоже бывает ошибается, но вот use index в нем нет, а в mysql есть хотя костыль да
2) решение тут простое — либо комбинированный индекс или оборачиваете свой запрос с одной сортировкой в select * from () as q order by f1, f2
В общем опять какие-то детские примеры превосходства pg, где транзакционный ddl, window function, with, условные индексы, gist (и другие не btree) индексы, индексы от выражений и т.п.?
В pg например having не работает для вычисляемых полей и все также берешь и оборачиваешь в подзапрос, или например update в pg работает всегда, даже если там тоже значение (с резервирование места, записью и т.п.), а mysql такое сама оптимизирует или отсутсвие в pg адекватного партицирования (проще какой нить pg xl настроить для этих целей) а в mysql из коробки и относительно удобно, но этож не значит что pg плохой после этого и его не стоит использовать.
Всё это по сути особенности конкретной БД. А, видимо, не зная их ребята уже заклеймили монгу и mysql и возможно через пару лет заклеймят также и pg и героически переедут куда-то еще (наверно на очереди что-то для bigdata).
Да и выбрав монгу, говорить что самая большая проблема это отсутствие схемы… это как минимум странно…
Только доступ не физический а программный, был продемонстрирован уход из песочницы NaCl, то есть вы можете открыть страницу в Chrome, ваш ноутбук зашуршит вентилятором секунд на 10 и у вас в системе уже стоит руткит.
Lavavel -4.6%
Symfony +3%
Phalcon -14%
Более 90% голосов за фреймворк Nette отдали разработчики из Чехии
Для голосовавших из России (237):
Yii 2 — 53 (22%)
Yii 1 — 39 (16.5%)
Symfony — 39 (16.5%)
Laravel — 27 (11%)
3 человека из опроса признались, что используют Bitrix (2 из России и 1 из Украины)
Drupal так мало потому что такого варианта не было в выборе и люди дописывали его руками.
тоже забавно
а если понатыкать кучу таких устройст. то можно просто брать с них же инфу где был такой-то мак и в какое время
я думаю стоит добавить ссылку на официальный список адресов ваших прокси серверов
77 дюймов, вроде не маленькая диагональ
хотя за такие деньги можно квартиру купить в регионах
заняло 112 секунд в виртуалке на ноуте. при этом я получаю гарантированно связанную БД и весь процесс полностью транзакционный, ну и про отключение индексов — в pg их можно «собирать» параллельно, что хорошо походит для единовременной загрузки большого кол-ва данных
Кстати fetch api презентовано внутри Service Worker которые как раз для сложных случаев кастомного кеширования.
по поводу order by:
1) postgres тоже бывает ошибается, но вот use index в нем нет, а в mysql есть хотя костыль да
2) решение тут простое — либо комбинированный индекс или оборачиваете свой запрос с одной сортировкой в select * from () as q order by f1, f2
В общем опять какие-то детские примеры превосходства pg, где транзакционный ddl, window function, with, условные индексы, gist (и другие не btree) индексы, индексы от выражений и т.п.?
В pg например having не работает для вычисляемых полей и все также берешь и оборачиваешь в подзапрос, или например update в pg работает всегда, даже если там тоже значение (с резервирование места, записью и т.п.), а mysql такое сама оптимизирует или отсутсвие в pg адекватного партицирования (проще какой нить pg xl настроить для этих целей) а в mysql из коробки и относительно удобно, но этож не значит что pg плохой после этого и его не стоит использовать.
Всё это по сути особенности конкретной БД. А, видимо, не зная их ребята уже заклеймили монгу и mysql и возможно через пару лет заклеймят также и pg и героически переедут куда-то еще (наверно на очереди что-то для bigdata).
Да и выбрав монгу, говорить что самая большая проблема это отсутствие схемы… это как минимум странно…
PS
1) STRICT_ALL_TABLES
2) InnoDB
с выходом 39 версии хрома это поддерживают уже больше 70% настольных браузеров