Это что, какой-то эзотерический язык, чтобы усложнить разработку в команде?..
Напомнило какую-то ужасную смесь непонятности Ассемблера и кириллицу 1С.
Задача кода быть понятным, а тут какая-то непонятная экономия, чтобы меньше печатать ключевые слова и увеличивать количество опечаток.
Ну обычно подобные статьи действительно страдают тем, что трудно найти необходимую аудиторию — кому-то большинство пунктов известно, кому-то нет…
Хотя однозначно польза в подобных статьях есть — например, я не знал раньше о «lobotomized owl selector» (точнее, не задумывался, что так удобнее) — а ведь действительно, на одну директиву меньше. Думаю, другие разработчики тоже найдут один-два пункты, о которых не знали — уже польза!
Для меня, кстати, довольно неочевидным было то, что для inline-block указывать вертикальное позиционирование нужно для собственно тех элементов, которые их используют, хотя по логике казалось, что это нужно делать для родительского контейнера.
Неужели в перспективе скорость, удобство, цена и окупаемость может превысить авиаперевозки?
Понимаю, звучит глупо с разряда «разве может медленная машина, которой нужен бензин превысить удобство лошади», но мне кажется, что обслуживание тысяч километров труб будет намного дороже, чем аэропорты.
От себя бы добавил:
Отсутствие интересных задач. Иногда везет, и ты разрабатываешь какой-то хитрый плагин или модуль, или оптимизируешь какое-то место в системе, что приводит к ускорению алгоритма в несколько раз.
Но когда доходит до: «сдвинь кнопочку на три пикселя вправо, добавьте то, добавьте это» — когда требуются чисто технические навыки без фактического размышления и оригинальности — подобные задачи просто выматывают за несколько часов.
Все зависит от самих запросов. Да, один запрос будет немного быстрее. Но у меня бывали случаи, когда большая выборка длилась до 10-15 секунд, и тогда выполнить один запрос или несколько мелких — уже не имеет значения.
По своему опыту, если нужно получить таблицу менеджеров и продуктов — получил бы менеджеров отдельно, а продукты отдельно (учитывая, что там еще обычно нужно JOIN'ить с других таблиц дополнительные данные). Потеря от лишнего запроса компенсируется сопровождаемостью и очевидностью кода, а не использованием магических библиотек, которые обычно будут накладывать свой синтаксис или ограничения.
Несомненно плохо делать сотни или даже тысячи мелких запросов в цикле.
Пример с юнионом я вижу в виде следующей библиотеки (набросал первое, что пришло в голову):
$get_complex_query = new ComplexQuery(
new Query(['id', 'name', 'other_info'], $manager_table_name),
new Query(['id', 'name', 'price', 'color', 'many_other_product_data'], $product_table_name)
);
Результатом будет либо еще объект со своими свойствами, либо массив типа array => [manager=>[...], product=>[...]]
В таком виде оно имеет право на существование, но когда нужно будет джойнить, добавлять WHERE, ORDER условия (в менеджеров — свои, в продуктах — свои и при этом динамически) — библиотека будет расти и усложняться, и в какой-то момент понимаешь, что проще было не создавать этот костыль. Когда придет новый человек в команду — ему придется еще тратить время на изучение этого велосипеда.
В итоге может оказаться, что все эти запросы очень ограниченные, а там, где они подходят — выигрыш слишком мелкий, чтобы жертвовать удобством разработки.
Плюс потеря будет еще в необходимости лишнего прохода циклом по всем данным. Данные, полученные с DB, нужно будет разнести по разным массивам и вернуть сразу весь результат. То есть, сделать динамический fetch мне не представляется возможным.
Ну либо будет возвращен fetch, и тогда все тяготы по различению, с какой таблицы эти данные — ложатся на плечи разработчика, либо передавать какие-то анонимные функции, что 100% будет влиять на смешивание модели и представления.
В этот момент пора задать вопрос: не лучше ли JOIN или два отдельных запроса?..
Ну или магия хранимых процедур, а это вообще отдельная тема для разговора.
Предлагаю обсудить этот метод. Он мне показался сильным анти-паттерном и примером того, как делать не нужно.
Во-первых, нужна дополнительная колонка, которая объяснит, какую таблицу вы получили. То есть,
select 'product', product_id, product_title from product
UNION
select 'manager', name, '' from manager
Во-вторых, в этом методе придется писать какие-то обертки и делать слишком много неочевидной магии (за которую, собственно, так и ненавидят PHP).
В третьих, вам всегда придется указывать конкретное количество полей и помнить, в каком порядке они находятся. Если же вам придется добавить поле хотя бы в одну колонку — переписывать придется все запросы, которые находятся в UNION.
Мне кажется, в подобном случае сделать два отдельных запроса будет более очевидно и тестируемо, а еще лучше — использовать JOIN либо кэширование manager в оперативной памяти (я уверен, что этих менеджеров даже в самой большой фирме не больше двух-трех сотен, а на деле меньше 20, поэтому нужно просто сделать один раз запрос на менеджера и закэшировать это в Redis на несколько часов).
Не знаю, чтобы решить — мне достаточно посмотреть по экрану. Купил на свою голову как подарок PocketBook — по качеству экрана все равно хуже, чем Kindle. Правда, уже год прошел, нужно опять сравнивать.
Они сейчас даже блокируют сайты в связи с похожестью названия доменов.
То есть, у вас домен good-mouse, где у вас продаются компьютерные мышки.
Регистрируете немного похожий домен mouse-good, на котором размещаете незаконные материалы (несколько ссылок на торренты, музыки, пару фильмов).
Второй домен блокируют, а за некоторое время из-за «схожести названия и содержимого» заблокируют без суда и следствия первый домен.
«Deprecation of fallback to root scope» — зачем полностью ломать обратную совместимость скриптов? Это что, больше безопасности добавит? Придется ведь переписывать код всех существующих библиотек и скриптов!
Редчайшая глупость, надеюсь, этот RFC не примут.
Думаю, его далекие потомки просто не разрешат это сделать и обратятся в полицию по факту кражи. Несмотря на то, что машина в космосе — не думаю, что Илон решил ее сделать достоянием человечества, а не личным имуществом.
Вычитку делайте в другой день, чем написание статьи, если возможно.
Если нет — сбрасывайте кому-то на перепроверку. Иногда даже обычный друг без специального образования может заметить подобные мелочи, которые находятся прямо перед глазами.
Вообще все тростевые инструменты очень в этом смысле привередливые.
Записывали на студии гобоиста — он всегда носит несколько тростей, на репетициях-оркестрах — то же самое. Кларнетисты вообще обычно носят два инструмента (ля и си-бемольный), а они еще и по-разному звучат. Два инструмента, правда, связано с удобством исполнения (аппликатурой, т.е., какими пальцами что нажимать) — ля-кларнетом удобнее исполнять тональности, где больше диезов, си-бемоль-кларнет — удобнее бемольные тональности. Мне слухового опыта не хватит, но духовики запросто различат.
Влияет качество трости, температура воздуха, влажность, настроение самого музыканта и, не исключаю, космические лучи и взмах крыла бабочки в мезозое.
С фаготами, кларнетами, саксофонами — та же история. Там где есть нелинейность в виде натуральных компонентов (древесины) — всегда будут отличия в звучании.
Привет от музыковеда! Вижу, в последнее время здесь много музыки, самому, что ли, написать?
Рассказ интересный, со многими трубачами был знаком, но впервые слышал о пластиковом мундштуке. Сначала хотел попросить вас записать разницу между ними, но минута гугления, и результат нашел: https://www.youtube.com/watch?v=IDCY8D357uI
С пластиковым мне звук на примере даже немного больше понравился — в нем меньше металла, но это дело вкуса.
P.S. Кстати, забыли о сурдине — она умеет давать интересный эффект и активно используется джазовиками, да и не только.
Это связано больше с возрастными особенностями восприятия времени.
Уже не найду видео, но суть в том, что когда вам было 1 год, еще один год — это половина вашей существующей жизни. Когда вам 5 лет, еще пять лет — это тоже еще половина жизни.
Но когда вам уже 30 — тогда 5 лет это только малая часть той жизни, которую вы прожили.
Это одно из объяснений, почему людям кажется, что раньше все происходило как-то медленнее, а само время было более насыщенным и медленным.
Напомнило какую-то ужасную смесь непонятности Ассемблера и кириллицу 1С.
Задача кода быть понятным, а тут какая-то непонятная экономия, чтобы меньше печатать ключевые слова и увеличивать количество опечаток.
Хотя однозначно польза в подобных статьях есть — например, я не знал раньше о «lobotomized owl selector» (точнее, не задумывался, что так удобнее) — а ведь действительно, на одну директиву меньше. Думаю, другие разработчики тоже найдут один-два пункты, о которых не знали — уже польза!
Для меня, кстати, довольно неочевидным было то, что для inline-block указывать вертикальное позиционирование нужно для собственно тех элементов, которые их используют, хотя по логике казалось, что это нужно делать для родительского контейнера.
Понимаю, звучит глупо с разряда «разве может медленная машина, которой нужен бензин превысить удобство лошади», но мне кажется, что обслуживание тысяч километров труб будет намного дороже, чем аэропорты.
Отсутствие интересных задач. Иногда везет, и ты разрабатываешь какой-то хитрый плагин или модуль, или оптимизируешь какое-то место в системе, что приводит к ускорению алгоритма в несколько раз.
Но когда доходит до: «сдвинь кнопочку на три пикселя вправо, добавьте то, добавьте это» — когда требуются чисто технические навыки без фактического размышления и оригинальности — подобные задачи просто выматывают за несколько часов.
По своему опыту, если нужно получить таблицу менеджеров и продуктов — получил бы менеджеров отдельно, а продукты отдельно (учитывая, что там еще обычно нужно JOIN'ить с других таблиц дополнительные данные). Потеря от лишнего запроса компенсируется сопровождаемостью и очевидностью кода, а не использованием магических библиотек, которые обычно будут накладывать свой синтаксис или ограничения.
Несомненно плохо делать сотни или даже тысячи мелких запросов в цикле.
Пример с юнионом я вижу в виде следующей библиотеки (набросал первое, что пришло в голову):
Результатом будет либо еще объект со своими свойствами, либо массив типа array => [manager=>[...], product=>[...]]
В таком виде оно имеет право на существование, но когда нужно будет джойнить, добавлять WHERE, ORDER условия (в менеджеров — свои, в продуктах — свои и при этом динамически) — библиотека будет расти и усложняться, и в какой-то момент понимаешь, что проще было не создавать этот костыль. Когда придет новый человек в команду — ему придется еще тратить время на изучение этого велосипеда.
В итоге может оказаться, что все эти запросы очень ограниченные, а там, где они подходят — выигрыш слишком мелкий, чтобы жертвовать удобством разработки.
Плюс потеря будет еще в необходимости лишнего прохода циклом по всем данным. Данные, полученные с DB, нужно будет разнести по разным массивам и вернуть сразу весь результат. То есть, сделать динамический fetch мне не представляется возможным.
Ну либо будет возвращен fetch, и тогда все тяготы по различению, с какой таблицы эти данные — ложатся на плечи разработчика, либо передавать какие-то анонимные функции, что 100% будет влиять на смешивание модели и представления.
В этот момент пора задать вопрос: не лучше ли JOIN или два отдельных запроса?..
Ну или магия хранимых процедур, а это вообще отдельная тема для разговора.
Во-первых, нужна дополнительная колонка, которая объяснит, какую таблицу вы получили. То есть,
Во-вторых, в этом методе придется писать какие-то обертки и делать слишком много неочевидной магии (за которую, собственно, так и ненавидят PHP).
В третьих, вам всегда придется указывать конкретное количество полей и помнить, в каком порядке они находятся. Если же вам придется добавить поле хотя бы в одну колонку — переписывать придется все запросы, которые находятся в UNION.
Мне кажется, в подобном случае сделать два отдельных запроса будет более очевидно и тестируемо, а еще лучше — использовать JOIN либо кэширование manager в оперативной памяти (я уверен, что этих менеджеров даже в самой большой фирме не больше двух-трех сотен, а на деле меньше 20, поэтому нужно просто сделать один раз запрос на менеджера и закэшировать это в Redis на несколько часов).
То есть, у вас домен good-mouse, где у вас продаются компьютерные мышки.
Регистрируете немного похожий домен mouse-good, на котором размещаете незаконные материалы (несколько ссылок на торренты, музыки, пару фильмов).
Второй домен блокируют, а за некоторое время из-за «схожести названия и содержимого» заблокируют без суда и следствия первый домен.
Редчайшая глупость, надеюсь, этот RFC не примут.
Достань меня, если сможешь!
Илон в своем стиле.
Если нет — сбрасывайте кому-то на перепроверку. Иногда даже обычный друг без специального образования может заметить подобные мелочи, которые находятся прямо перед глазами.
Записывали на студии гобоиста — он всегда носит несколько тростей, на репетициях-оркестрах — то же самое. Кларнетисты вообще обычно носят два инструмента (ля и си-бемольный), а они еще и по-разному звучат. Два инструмента, правда, связано с удобством исполнения (аппликатурой, т.е., какими пальцами что нажимать) — ля-кларнетом удобнее исполнять тональности, где больше диезов, си-бемоль-кларнет — удобнее бемольные тональности. Мне слухового опыта не хватит, но духовики запросто различат.
Влияет качество трости, температура воздуха, влажность, настроение самого музыканта и, не исключаю, космические лучи и взмах крыла бабочки в мезозое.
С фаготами, кларнетами, саксофонами — та же история. Там где есть нелинейность в виде натуральных компонентов (древесины) — всегда будут отличия в звучании.
Рассказ интересный, со многими трубачами был знаком, но впервые слышал о пластиковом мундштуке. Сначала хотел попросить вас записать разницу между ними, но минута гугления, и результат нашел:
https://www.youtube.com/watch?v=IDCY8D357uI
С пластиковым мне звук на примере даже немного больше понравился — в нем меньше металла, но это дело вкуса.
P.S. Кстати, забыли о сурдине — она умеет давать интересный эффект и активно используется джазовиками, да и не только.
Уже не найду видео, но суть в том, что когда вам было 1 год, еще один год — это половина вашей существующей жизни. Когда вам 5 лет, еще пять лет — это тоже еще половина жизни.
Но когда вам уже 30 — тогда 5 лет это только малая часть той жизни, которую вы прожили.
Это одно из объяснений, почему людям кажется, что раньше все происходило как-то медленнее, а само время было более насыщенным и медленным.