Если говорить про Laravel, то в нём есть определённые недоработки. В построителе запроса нельзя указать псевдоним таблицы, можно использовать метод from, но это не совсем то, что нужно. Очень неудобно использовать join, в статье это хорошо показано. Для формирования join'ов, where exists я использую свой трейт, который значительно облегчает написания кода. Кому интересно могу скинуть пример.
А вообще считаю ORM благом. Часто бывают ситуации, когда выборка может быть так или сяк, формировать эту строку запроса самому бывает проблематично. Очень длинную придётся написать "простыню" и наверняка в ней будет полно ошибок и много потенциальных "дырок".
Часто вижу, что разработчики сознательно идут на написания не оптимального кода, просто просто потому, что им лень писать лишние строчки, а вот ORM часто имеют инструменты, чтобы можно было писать краткий код, но при этом запросы к БД были оптимальными.
Говорят, что на ORM очень много уходит ресурсов серверов, но на самом деле основная трата ресурсов идёт за счёт неразумных запросов к БД. Когда за один запрос можно получить, то что делают ста запросами или неграмотными условиями выборки.
Многие программисты пишут обращения к атрибутам и функциям не отдавая себе отчёт, какие при этом происходят обращения к БД, но это проблема не ORM, а "кривых" рук.
Хочу сравнить Yii и Laravel. В Yii функционал разработан так, что думаешь попадание не в бровь, а в глаз. С одной стороны просто, а с другой стороны максимально удобно для разработки. Не хочу сказать, что Laravel плох, но как-то есть в нём недоработки. FormRequest - вообще неудобный, я полностью от него отказался в пользу своих классов. В миграциях не те настройки по умолчанию, которых хотелось бы иметь. Раньше нельзя было создать несколько миграций с одними теми же параметрами, например так: php artisan make:migration update_users_table . Как-то всё очень сложно. Много избыточных классов приходиться создавать. В Yii очень многое сделано для разработки MVC приложений. Очень удобно делать веб формы, табличные данные - в Laravel это делать нужно "ручками" или с помощью сторонних расширений. Когда пишу на Laravel , гораздо чаще думаю: вот бы сейчас функционал из Yii, а вот обратная ситуация бывает, но значительно реже. В Yii например не удобно проверять сложно структурированные данные. Есть внешний пакет, но он не совсем удобен.
Bitrix - это тихий ужас. Вместо MVC или web-api и использует метод "плюх". Вместо pdo myqsli, что небезопасно. Код жуткий, который с 90х, наверное ни разу не переписывался. И вообще такое ощущение, что Bitrix писали робинзоны, которые жили на не обитаемом острове в изоляции от другого мира.
WordPress, Drupal - ерунда, не годиться для разработки нормальных сайтов.
Мы использовали Ratchet , но веб сервер периодически "ложился". Потом мы вместо чистого nginx поставили openresty, в нем есть websocket'ы на базе языка Lua и теперь у нас счастье. Все работает намного быстрее стабильнее.
В Laravel, Yii для этого есть "жадная загрузка". Можно жадно загрузить не только профили пользователей, но и те данные, которые связаны с профилем. Есть возможность добавлять ограничение выборки и тд. Не понимаю зачем тут "изобретать велосипед".
// Как выполнить все эти запросы.
$users = Users::whereIn('name', ['Саша', 'Петя', 'Вася'])
->with('profiles')
->get();
// select * from users where name in ('Саша', 'Петя', 'Вася');
// select * from profiles where user_id in (4, 5, 8);
// Пример использования
foreach($users as $user) {
$user->name; // имя пользователя
foreach($user->profiles as $profile) {
$profile; // Профиль пользователя
}
}
// Другой пример
$users = Users::whereIn($ids)
->with([
'profiles',
'profiles.roles', //Если к профайлам привязаны роли и нам они тоже нужны
'images' => function ($query) {
// Получаем изображения привязанные к пользователю, но не все,
// а только аватарку
$query->where('type', 'avatar');
}
])
->get();
Не понимаю зачем при таких зарплатах it специалисту уезжать в Польшу. Можно хоть в родном селе жить удалённо работать скажем на Москву и будешь больше зарабатывать. И не надо учить чужой язык, отрываться от родных и друзей, а так же не придётся на себе ловить "косые" взгляды, как на человеке второго сорта.
Даже если мы научимся долетать до Марса, всё равно остаётся множество нерешаемых проблем. Нет нормальной атмосферы, высокий уровень радиации на поверхности, нет магнитного поля у Марса, чтобы защищать от ионизирующего излучения из космоса, холодно и тд. Можно конечно закопаться глубоко под грунт, но зачем тогда нужна такая колонизация? Все нормальные люди это понимают, уверен что и Маск всё это знает, вывод — всё это мошенничество.
Никогда бы не подумал, что кому-то может понадобиться взламывать тележки в магазине. Стоило ли ради этого писать такую длинную статью? Не знаю как в столицах, а в других городах в маршрутках можно оплачивать проезд только наличкой — этими самыми ненужными монетками. В некоторых магазинах терминалы эквайринга по различным причинам не работают. Как правило это следствие того, что магазины не хотят делиться своей прибылью с банками. Да и вообще оплата картой или телефоном более небезопасный способ оплаты чем наличкой. Тут конечно есть нюансы, но всё же. Обычно мы боимся воров и грабителей, но при использовании карты нам часто начинают угрожать и сами банки. Сколько случаев, когда после перевода денег от мужа жене с карты на карту, блокируются обе карты. Когда под сомнительными предлогами банки снимают деньги со счёта клиента. Конечно без банковских карт сейчас прожить не получиться, но забывать про наличку ещё рано.
Не понимаю как можно программировать не зная какие выполняются запросы? Такой ерунды можно наделать, простой пример: нам надо получить список элементов, скажем наименование статей, а так же получить к этим элементам информацию из других таблиц, пусть это будут авторы. Из одной коротенькой строчки кода может получиться совершенно разный результат, в обоих случаях всё будет работать. Только в одном варианте будет сделано два запроса, а в другом 1+количество элементов (статей). Здесь подробнее.
Очень часто без сложных запросов с подзапросами просто не обойтись и тут ORM не спасёт.
1. Даже если не будет запросов в БД в файлах index.php, то это не отменяет сомн других проблем таких как невозможность меня темы на сайте как перчатки, большое количество этих файлов, если на сайте много разнообразных страниц, не эффективные ajax запросы (запрашивается не только, то что тебе нужно и всё остальное, что есть на странице) и многое другое. Да и текст статьи хранить в таких файлах тоже нехорошо.
2. Не правда, даже с включенным кэшем сайты на Битриксе работают очень медленно.
3. Не уверен что это правда, но даже если и так, то сколько пришлось ждать это «счастья», во-вторых почему нельзя отобрать записи по другому полю? В БД данных такая возможность есть, в других CMS'ках где пошли чуть дальше одних только прямых SQL запросов то же есть.
5. Другие визуальные редакторы имеют свои нюансы, но во общем и целом работать в них комфортно и добавив к ним своих плагинов можно было бы реализовать свою архитектуру — песочницу, но почему-то в Битриксе так не сделали.
Битрикс это единственная CMS, где используется кодировка CP-1251 и в некоторых местах ты должен писать только на ней, но никак ни на UTF-8.
Могу возразить, например для Jooml'ы есть сторонний компонент — RSForm. Куча возможностей, прекрасно настраивается. Без знания программирования можно какие только ни какие создавать веб формы.
По поводу системы в которой всё есть. Некоторые вещи, такие как создание своих веб форм не работают или имеют весьма ограниченный функционал и поэтому не используются, а программисты ваяют свои «костыли».
Работал со многими CMS'ками (Joomla, OpenCart, WordPress, Webasyst, CSCart и тд) и фрейморками и могу с уверенностью сказать, что настолько чудовищно плохо не сделана ни одна CMS'ка, хотя и в них есть свои «странности». Перечислю некоторые вещи.
1. В Битриксе нет MVC, вместо него используется архиктектура «песочница». Я её называю метод плюх. Создаём пустой index.php и кидаем туда чего не попадя — контент, вызов компонентов, запросы к БД и тд. Так создаются страницы в Битриксе! Одного этого достаточно, чтобы забраковать эту систему. Неразделённая логика порождает кучу проблем: сложно и неудобно менять внешний вид сайта, неэффективные ajax запросы, много лишних файлов и тд.
2. Битрикс очень медленная и ресурсоёмкая CMS. На всех конференциях по Битриксу докладчики говорят, что скорость сайта очень важна и намекают на то, что Битрикс работает быстро. Сколько не встречал сайты на этой CMS все работали очень медленно.
3. В документации к Битриксу написана большая статья, что всю работу с БД лучше вести исключительно через ORM, а не прямыми SQL запросами. Здравая мысль, только ещё бы эта ORM была бы нормальной. Чтобы удалить или изменить несколько строк в БД надо запустить PHP цикл, который построчно выполнит нужную операцию, хотя все БД позволяют это сделать за одним запросом! Причём указать строку можно только через id, а если его нет, то надо сначала его получить.
4. Очень сложно и неудобно вести разработку на Битриксе. Частично это следствие выше названных проблем, но так же из-того что разработчики подходят весьма не гибко. Как-то раз мне нужно было чуть-чуть изменить корзину товара, но посмотрев сколько мне придётся сделать сопутствующих правок, пришлось от этой мысли отказаться. По этой причине не рекомендую веб студиям надеяться, что если они продадут сам Битрикс, плюс шаблон к нему они получат лёгкие деньги, даже если заказчику не нужны будут «перламутровые пуговицы». Кстати автор статьи не прав, программисты на Битриксе получают весьма неплохо, наверное это компенсация за все те мучения, которые они испытывают.
5. Очень плохо приходится и человеку, который добавляет информацию на сайт. Визуальный редактор там свой и его поменять никак нельзя. Работает он крайне плохо. HTML код получается сумбурным и «замусоренным».
6. Если что-то в Битрикс попадает оно там остаётся навсегда, старые методы не удаляются. Даже более того, если открыть свежий дистрибутив Битрикса, то можно встретить такие конструкции, которые рекомендовались ещё в PHP4. Например объявление атрибута класса через var.
Я преклоняюсь перед маркетологами Битрикса, что столь плохой продукт они ухитряются успешно продавать, а он стоит весьма недешево, при этом столько существуют полностью бесплатных решений. Да и вообще очень многие около компьютерные люди в России скажут, что Битрикс самая лучшая система для создания сайта.
Я ожидал, что будет очень много критических отзывов. Всё таки тяжело ломать крепко укоренившиеся стереотипы. Но ни как не мог предположить, что увижу столько критических замечаний на мою фразу: «Если крутить ногами педали, которые совсем не встречают сопротивления, то всё равно расходуется очень много сил...». Забудьте на минутку всё, что вы прочитали в Интернете и обратитесь к личному велосипедному опыту и здравому смыслу. Если вы совершите ногами сто вращательных движений с умеренной нагрузкой или 8000 почти без нагрузки, то что будет вреднее для коленей? Какого должно быть людям бегающим по пересечённой местности с подъёмами и спусками, которые вообще не могут выставлять оптимальный каденс? Я говорю об обычных людях, которые поддерживают физическую форму, солдатах- срочниках и т.д. У всех должны быть больные коленки? В городе на светофорах всё равно нельзя резко стартовать — тебя должны увидеть все участники движения. Опять же таки напомню мы говорим о велосипедистах не профессиональных, которые в среднем покрывают 20 — 40 км.
Насчёт безопасности. Если мы не говорим про сумасшедшие трассы, то главная угроза для велосипедиста, это автомобили и от них я советую держаться подальше. Более чем уверен, что те, кто меня критикует за не обязательность ношения шлема, постоянно рассекает по перегруженным автомобильным дорогам. Если «камаз» проедет по туловищу, то шлем не спасёт. В первую очередь в велосипедных авариях страдают руки и ноги, в таком случае сначала их и надо защитить.
Хотел бы добавить про вело воров. Они всё-таки сволочи, сколько бы людей ездило бы на работу и просто по своим личным делам, если не боялось, что у них уведут велосипед. Причём воруют и дешёвые, порою просто из хулиганских побуждений. Трос с замком не всегда может спасти ещё и потому, что частенько на спортивных велосипедах колёса, седло и прочее фиксируется зажимами. Велосипед могут просто разобрать на запчасти.
Мне очень стыдно за орфографические и пунктуационные ошибки. Вначале сосредоточился на содержимом, потом взгляд «замылился». Прошу меня «понять и простить».
По части езды «вокруг клумбы», катаюсь на велосипеде с детства. В последние годы езжу перед или после работы по 20 — 40 км чуть ли не каждый день. Хотя сейчас с этим будет сложнее. В выходные порой выбираюсь на более дальние велопробежки, например, до ближайшего города. Туда и обратно около 100 км. Кому-то эти цифры покажутся маленькими, но хотел бы заметить, что именно столько обычно и проезжают непрофессионалы, на которых и была рассчитана статья. На «диване» ничего не натирается. Справедливости ради надо сказать, что без подготовки попа будет болеть на любом сидении.
Забыл упомянуть про жителей сёл и деревень. Там очень много велосипедов. За исключением детворы, как правило, все катаются именно на классических дорожных. Там не самые лучшие дороги, но люди ездят.
Конечно, мои мысли большинству покажутся еретическими, но другого я не ожидал.
Не стал бы так рисковать и дело даже не в RDP. Сама Windows не являевляется безопастной системой. Лучше её «скрывать» за хорошими аппаратными или программными сетевыми экранами, которые будут защищать весь офис. Можно скачать готовую бесплатную сборку на основе Linux'a. Если нет отдельного компьютера, можно создать виртуальную машину и пропускать весь интернет трафик через неё. Вариантов много и всегда можно «выкрутится» даже если нет денег.
А без удалённого доступа сейчас тяжело — ни начальство с Кипра не может посмотреть, как идут дела, ни программиста 1С-ка не подлючишь, да и с VPN'ом можно все филиалы подключить к одной базе.
Доступ к 1С из дома очень нужная вещь, но нельзя «голую» винду выставлять на всеобщее обозрение. Доступ должен быть органзован через защищенные VPN IP-sec соединения. Контору, в которой я ранее работал и где был упрощён доступ, не давно так же взломали. Кончилось благополучно, но в следующий раз может уже и не повезти.
Какой-то странный выбор у автора статьи. Он перечислил весьма посредственные игры, но не упомянул о действительно хороших, например fallout 3/4, FarCray, Crysis и тд. Хотя конечно: «На вкус и цвет — одни враги». Minecraft — кубики для больших мальчиков.
Очень часто так и бывает: школьнику покупают компьютер, он научится переустанавливать «винду». Начинает чувствовать в себе большой потенциал, плюс закружится голова от больших доходах программистов и идёт учиться на соответсвующий факультет, но учиться программированию это тяжкий труд и особое мышление. Наш школьник быстро сдаётся и просто «плывёт по течению» и кое-как получает диплом. И всей группы только несколько человек, что-то реально знают и умеют с остальными не о чем разговаривать. Они не могут иногда даже «Винду» переустановить.
Если говорить про Laravel, то в нём есть определённые недоработки. В построителе запроса нельзя указать псевдоним таблицы, можно использовать метод from, но это не совсем то, что нужно. Очень неудобно использовать join, в статье это хорошо показано. Для формирования join'ов, where exists я использую свой трейт, который значительно облегчает написания кода. Кому интересно могу скинуть пример.
А вообще считаю ORM благом. Часто бывают ситуации, когда выборка может быть так или сяк, формировать эту строку запроса самому бывает проблематично. Очень длинную придётся написать "простыню" и наверняка в ней будет полно ошибок и много потенциальных "дырок".
Часто вижу, что разработчики сознательно идут на написания не оптимального кода, просто просто потому, что им лень писать лишние строчки, а вот ORM часто имеют инструменты, чтобы можно было писать краткий код, но при этом запросы к БД были оптимальными.
Говорят, что на ORM очень много уходит ресурсов серверов, но на самом деле основная трата ресурсов идёт за счёт неразумных запросов к БД. Когда за один запрос можно получить, то что делают ста запросами или неграмотными условиями выборки.
Многие программисты пишут обращения к атрибутам и функциям не отдавая себе отчёт, какие при этом происходят обращения к БД, но это проблема не ORM, а "кривых" рук.
Хочу сравнить Yii и Laravel. В Yii функционал разработан так, что думаешь попадание не в бровь, а в глаз. С одной стороны просто, а с другой стороны максимально удобно для разработки. Не хочу сказать, что Laravel плох, но как-то есть в нём недоработки. FormRequest - вообще неудобный, я полностью от него отказался в пользу своих классов. В миграциях не те настройки по умолчанию, которых хотелось бы иметь. Раньше нельзя было создать несколько миграций с одними теми же параметрами, например так: php artisan make:migration update_users_table . Как-то всё очень сложно. Много избыточных классов приходиться создавать. В Yii очень многое сделано для разработки MVC приложений. Очень удобно делать веб формы, табличные данные - в Laravel это делать нужно "ручками" или с помощью сторонних расширений. Когда пишу на Laravel , гораздо чаще думаю: вот бы сейчас функционал из Yii, а вот обратная ситуация бывает, но значительно реже. В Yii например не удобно проверять сложно структурированные данные. Есть внешний пакет, но он не совсем удобен.
Bitrix - это тихий ужас. Вместо MVC или web-api и использует метод "плюх". Вместо pdo myqsli, что небезопасно. Код жуткий, который с 90х, наверное ни разу не переписывался. И вообще такое ощущение, что Bitrix писали робинзоны, которые жили на не обитаемом острове в изоляции от другого мира.
WordPress, Drupal - ерунда, не годиться для разработки нормальных сайтов.
Мы использовали Ratchet , но веб сервер периодически "ложился". Потом мы вместо чистого nginx поставили openresty, в нем есть websocket'ы на базе языка Lua и теперь у нас счастье. Все работает намного быстрее стабильнее.
В Laravel, Yii для этого есть "жадная загрузка". Можно жадно загрузить не только профили пользователей, но и те данные, которые связаны с профилем. Есть возможность добавлять ограничение выборки и тд. Не понимаю зачем тут "изобретать велосипед".
Laravel - https://laravel.com/docs/10.x/eloquent-relationships#eager-loading
Yii2 - https://www.yiiframework.com/doc/guide/2.0/ru/db-active-record#lazy-eager-loading
Не понимаю зачем при таких зарплатах it специалисту уезжать в Польшу. Можно хоть в родном селе жить удалённо работать скажем на Москву и будешь больше зарабатывать. И не надо учить чужой язык, отрываться от родных и друзей, а так же не придётся на себе ловить "косые" взгляды, как на человеке второго сорта.
Очень часто без сложных запросов с подзапросами просто не обойтись и тут ORM не спасёт.
2. Не правда, даже с включенным кэшем сайты на Битриксе работают очень медленно.
3. Не уверен что это правда, но даже если и так, то сколько пришлось ждать это «счастья», во-вторых почему нельзя отобрать записи по другому полю? В БД данных такая возможность есть, в других CMS'ках где пошли чуть дальше одних только прямых SQL запросов то же есть.
5. Другие визуальные редакторы имеют свои нюансы, но во общем и целом работать в них комфортно и добавив к ним своих плагинов можно было бы реализовать свою архитектуру — песочницу, но почему-то в Битриксе так не сделали.
Битрикс это единственная CMS, где используется кодировка CP-1251 и в некоторых местах ты должен писать только на ней, но никак ни на UTF-8.
1. В Битриксе нет MVC, вместо него используется архиктектура «песочница». Я её называю метод плюх. Создаём пустой index.php и кидаем туда чего не попадя — контент, вызов компонентов, запросы к БД и тд. Так создаются страницы в Битриксе! Одного этого достаточно, чтобы забраковать эту систему. Неразделённая логика порождает кучу проблем: сложно и неудобно менять внешний вид сайта, неэффективные ajax запросы, много лишних файлов и тд.
2. Битрикс очень медленная и ресурсоёмкая CMS. На всех конференциях по Битриксу докладчики говорят, что скорость сайта очень важна и намекают на то, что Битрикс работает быстро. Сколько не встречал сайты на этой CMS все работали очень медленно.
3. В документации к Битриксу написана большая статья, что всю работу с БД лучше вести исключительно через ORM, а не прямыми SQL запросами. Здравая мысль, только ещё бы эта ORM была бы нормальной. Чтобы удалить или изменить несколько строк в БД надо запустить PHP цикл, который построчно выполнит нужную операцию, хотя все БД позволяют это сделать за одним запросом! Причём указать строку можно только через id, а если его нет, то надо сначала его получить.
4. Очень сложно и неудобно вести разработку на Битриксе. Частично это следствие выше названных проблем, но так же из-того что разработчики подходят весьма не гибко. Как-то раз мне нужно было чуть-чуть изменить корзину товара, но посмотрев сколько мне придётся сделать сопутствующих правок, пришлось от этой мысли отказаться. По этой причине не рекомендую веб студиям надеяться, что если они продадут сам Битрикс, плюс шаблон к нему они получат лёгкие деньги, даже если заказчику не нужны будут «перламутровые пуговицы». Кстати автор статьи не прав, программисты на Битриксе получают весьма неплохо, наверное это компенсация за все те мучения, которые они испытывают.
5. Очень плохо приходится и человеку, который добавляет информацию на сайт. Визуальный редактор там свой и его поменять никак нельзя. Работает он крайне плохо. HTML код получается сумбурным и «замусоренным».
6. Если что-то в Битрикс попадает оно там остаётся навсегда, старые методы не удаляются. Даже более того, если открыть свежий дистрибутив Битрикса, то можно встретить такие конструкции, которые рекомендовались ещё в PHP4. Например объявление атрибута класса через var.
Я преклоняюсь перед маркетологами Битрикса, что столь плохой продукт они ухитряются успешно продавать, а он стоит весьма недешево, при этом столько существуют полностью бесплатных решений. Да и вообще очень многие около компьютерные люди в России скажут, что Битрикс самая лучшая система для создания сайта.
Насчёт безопасности. Если мы не говорим про сумасшедшие трассы, то главная угроза для велосипедиста, это автомобили и от них я советую держаться подальше. Более чем уверен, что те, кто меня критикует за не обязательность ношения шлема, постоянно рассекает по перегруженным автомобильным дорогам. Если «камаз» проедет по туловищу, то шлем не спасёт. В первую очередь в велосипедных авариях страдают руки и ноги, в таком случае сначала их и надо защитить.
Хотел бы добавить про вело воров. Они всё-таки сволочи, сколько бы людей ездило бы на работу и просто по своим личным делам, если не боялось, что у них уведут велосипед. Причём воруют и дешёвые, порою просто из хулиганских побуждений. Трос с замком не всегда может спасти ещё и потому, что частенько на спортивных велосипедах колёса, седло и прочее фиксируется зажимами. Велосипед могут просто разобрать на запчасти.
По части езды «вокруг клумбы», катаюсь на велосипеде с детства. В последние годы езжу перед или после работы по 20 — 40 км чуть ли не каждый день. Хотя сейчас с этим будет сложнее. В выходные порой выбираюсь на более дальние велопробежки, например, до ближайшего города. Туда и обратно около 100 км. Кому-то эти цифры покажутся маленькими, но хотел бы заметить, что именно столько обычно и проезжают непрофессионалы, на которых и была рассчитана статья. На «диване» ничего не натирается. Справедливости ради надо сказать, что без подготовки попа будет болеть на любом сидении.
Забыл упомянуть про жителей сёл и деревень. Там очень много велосипедов. За исключением детворы, как правило, все катаются именно на классических дорожных. Там не самые лучшие дороги, но люди ездят.
Конечно, мои мысли большинству покажутся еретическими, но другого я не ожидал.
А без удалённого доступа сейчас тяжело — ни начальство с Кипра не может посмотреть, как идут дела, ни программиста 1С-ка не подлючишь, да и с VPN'ом можно все филиалы подключить к одной базе.