ORM сияет обычно при записи, потому что не нужно думать, какие сущности сохранять первыми, какие вторыми и так далее. Очень сильно помогает если в схеме присутствуют циклические связи.
Для запросов и их результатов ORM подходит куда меньше, хотя бы потому, что не позволит просто так пойти и высчитать среднее, бегущую сумму или какой-нибудь изврат с оконными функциями — а это обычно самые интересные данные с точки зрения заказчика.
Уж поверьте, как кодер я был бы только рад унести логику обработки данных из «холодной, безразличной» и требующей многословных запросов базы данных (где, например, попытки переиспользовать код обычно натыкаются на ощутимые тормоза ввиду переключения контекстов между SQL и PL) в уютный для меня любимый язык программирования. Но сетевой доступ к хранилищу не может происходить по путям бесконечной ёмкости, а значит, чем больше работы я сделал вдали от данных, тем больше данных было передано по сети. А это вещь ненадёжная и медленная.
Я не исключаю что в каких-то системах такой подход может не работать и сервер базы загружен на 98%, но с другой стороны, если мы можем поднять сотню аппсерверов (для чего, кстати? вручную делать join'ы и закат солнца до кучи?), то почему мы не можем поднять «клон» для чтения, к примеру? Или поделить данные между несколькими базами, для начала, а склеивать уже результат от полученный от одинакового запроса к разным базам?
Честно говоря, звучит как рассказ про встречу с единорогами.
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным. Именно поэтому в т.н. BigData описание вычисления присылают в хранилище данных, а не данные из хранилища присылают исполнителю вычисления.
Разве что в описанном случае запрос вышел очень неоптимальный, но при этом с крайне низкой кардинальностью по данным в итоге. Тогда да, обработка в лоб действительно может быть быстрее. С другой стороны, уверен, что перестроенный и оптимизированный запрос всё равно выиграет.
«Трюк» с padding-top звучит как использование Undefined Behavior, особенно учитывая что в спецификации ничего про это нет (согласно данной статье). Я бы, в таком случае, воздержался от использования этого в проде, иначе есть риск нарваться на «багфикс», который добавит разъяснение в спецификации, и сделает
padding-top: x%
зависимым от высоты, а не ширины, во имя снижения количества неожиданностей в обработке.
Дело просто в том, что кроме них никто инициативу не подхватил, и они были в этом начинании единственными. Если бы их подход не был уникальным — неизвестно как ещё сложилось бы.
Проблема действительно имеет планетарный масштаб, но это совсем не значит, что с ней не нужно бороться здесь и сейчас. Так банально проще, разделять проблему на части и решать её тоже по частям.
Решение этой проблемы в России, в частности, даст больше рычагов для решения её в остальном мире, включая и такие важные вещи как «прецедент» и «стратегия решения».
1. Сеньор (слово заимствованно в обоих языках, и в современном русском выглядит именно так, хоть смысл у него другой)
2. Старший разработчик/дизайнер/etc.
Я говорил про другое, и не особо намерен выяснять продвинутость и каноничность Hyper как, собственно, терминала. Исходный комментарий постулировал, что Electron нужен, когда UI не текстовый, на что я дал пример программы с текстовым UI, которая сделана через Electron, несмотря ни на что. И да, жрёт память. Как и всё на электроне. Зато можно темки писать на CSS. Прогресс, что.
Голографический экран — это когда проекция на воздух? Такие экраны — это, фактически, приглашение любому желающему посмотреть, что ты там такое делаешь. Не уверен, что подобное действительно когда-либо взлетит для мобильных устройств. Для дома, для офисных презентаций — может, и взлетит.
Нет, не согласен, что это воздействия одного поля. Если некто пишет требования выслать миллион (просто так, или с угрозами) — то это вымогательство, шантаж, и что там ещё. Можно смело освещать такое публично, и в целом общественное мнение будет на Вашей стороне.
Зато если некто пишет будто вы каждый день приходите домой, и у Вас там к батарее в тёмном подвале привязаны рабы всевозможных расцветок, то градус поддержки уже будет значительно меньше. И тем меньше, чем правдоподобнее это выглядит. Мол как это так, компания не хочет брать на работу транссексуалов? Если правильно выбрать слова, то виноватой будет выглядеть компания, а не, скажем, низкий уровень профессиональных навыков или навыков работы в команде конкретных кандидатов, о сексуальных предпочтениях которых никто и не спрашивал даже. Кроме того, там ещё всегда остаётся аргумент «А почему вы не ищете транссексуалов с достаточным уровнем навыка и не берёте их на работу? Уж не думаете ли вы, будто у транссексуалов не бывает хороших навыков?!». Иными словами, тактика допроса в духе «как давно вы перестали избивать Вашу жену?» до сих пор исправно работает.
Алекса Джонсона недавно Google и Facebook забанил, при этом аналогичных левых радикалов никто не трогает. Twitter при этом показал себя более свободолюбивым.
Показал, но ненадолго. В итоге всё равно забанили и его, и InfoWars, только чуть-чуть попозже. И следом ещё пару человек из "правой" тусовки. К их чести могу заметить, что досталось и паре "левых" тоже — из числа особо агрессивных.
На тему статьи по ссылке:
Похоже, так нынче «развлекается» несколько групп учёных/журналистов.
Несколько раз замечал публикации, похожие на описанные там, и всякий раз задавался вопросом, действительно ли есть люди с такими абсурдными точками зрения, или все только прикидываются.
На проекты всё-таки стоит смотреть до собеседования, а не после. Тогда получится сэкономить немало времени от предложений, которые в любом случае были бы неинтересны.
Для запросов и их результатов ORM подходит куда меньше, хотя бы потому, что не позволит просто так пойти и высчитать среднее, бегущую сумму или какой-нибудь изврат с оконными функциями — а это обычно самые интересные данные с точки зрения заказчика.
hadoop.apache.org/docs/r1.2.1/hdfs_design.html
Уж поверьте, как кодер я был бы только рад унести логику обработки данных из «холодной, безразличной» и требующей многословных запросов базы данных (где, например, попытки переиспользовать код обычно натыкаются на ощутимые тормоза ввиду переключения контекстов между SQL и PL) в уютный для меня любимый язык программирования. Но сетевой доступ к хранилищу не может происходить по путям бесконечной ёмкости, а значит, чем больше работы я сделал вдали от данных, тем больше данных было передано по сети. А это вещь ненадёжная и медленная.
Я не исключаю что в каких-то системах такой подход может не работать и сервер базы загружен на 98%, но с другой стороны, если мы можем поднять сотню аппсерверов (для чего, кстати? вручную делать join'ы и закат солнца до кучи?), то почему мы не можем поднять «клон» для чтения, к примеру? Или поделить данные между несколькими базами, для начала, а склеивать уже результат от полученный от одинакового запроса к разным базам?
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным. Именно поэтому в т.н. BigData описание вычисления присылают в хранилище данных, а не данные из хранилища присылают исполнителю вычисления.
Разве что в описанном случае запрос вышел очень неоптимальный, но при этом с крайне низкой кардинальностью по данным в итоге. Тогда да, обработка в лоб действительно может быть быстрее. С другой стороны, уверен, что перестроенный и оптимизированный запрос всё равно выиграет.
Решение этой проблемы в России, в частности, даст больше рычагов для решения её в остальном мире, включая и такие важные вещи как «прецедент» и «стратегия решения».
2. Старший разработчик/дизайнер/etc.
Absolutely horrifying.
Зато если некто пишет будто вы каждый день приходите домой, и у Вас там к батарее в тёмном подвале привязаны рабы всевозможных расцветок, то градус поддержки уже будет значительно меньше. И тем меньше, чем правдоподобнее это выглядит. Мол как это так, компания не хочет брать на работу транссексуалов? Если правильно выбрать слова, то виноватой будет выглядеть компания, а не, скажем, низкий уровень профессиональных навыков или навыков работы в команде конкретных кандидатов, о сексуальных предпочтениях которых никто и не спрашивал даже. Кроме того, там ещё всегда остаётся аргумент «А почему вы не ищете транссексуалов с достаточным уровнем навыка и не берёте их на работу? Уж не думаете ли вы, будто у транссексуалов не бывает хороших навыков?!». Иными словами, тактика допроса в духе «как давно вы перестали избивать Вашу жену?» до сих пор исправно работает.
Smart-контракты?
Показал, но ненадолго. В итоге всё равно забанили и его, и InfoWars, только чуть-чуть попозже. И следом ещё пару человек из "правой" тусовки. К их чести могу заметить, что досталось и паре "левых" тоже — из числа особо агрессивных.
Похоже, так нынче «развлекается» несколько групп учёных/журналистов.
Несколько раз замечал публикации, похожие на описанные там, и всякий раз задавался вопросом, действительно ли есть люди с такими абсурдными точками зрения, или все только прикидываются.
www.javarticles.com/2016/09/java-garbage-collector-reachable-and-unreachable-objects.html