Pull to refresh
6
Karma
0
Rating

Почему в 21 веке геофизики верят в теорию плоской Земли?

И всё же. Почему геофизики верят в плоскую землю? И верят ли?

PHP Xdebug proxy: когда стандартных возможностей Xdebug не хватает

О! Рад что проект не заброшен. А вообще удивительно что при такой популярности php реализаций прокси так мало.
Хорошее дело, надо развивать.

Как я написал и защитил диплом по DEVOPS и инженерным практикам в 1С с нуля

Очень похожая история. Я учился по направлению «Системы корпоративного управления», параллельно работал в вузе в отделе поддержки и разработки внутренних информационных систем. Работали с 1С…
шучу, не с ним, а с 1С Битрикс.
Т.к. в штате были одни студенты пришлось добавлять в процесс разработки процедуры контроля качества кода, начиная от банального написания подробной инструкции как у нас принято писать код и заканчивая развёртыванием собственного CI сервера. не долго думая я взял все свои наработки и оформил в качестве диплома.

Необразованная молодежь: да, еще один пост с точки зрения школьника

Ещё несколько лет назад я тоже думал — как это так, как может не быть времени чтобы изучать новые технологии? Но теперь я взрослый и живу отдельно от родителей. И вот я хожу на работу, готовлю еду, убираюсь, делаю ещё какие-то дела… И времени действительно нет.
Очень просто говорить — "как это нет времени?", когда ты школьник/студент и единственное что ты обязан делать это учиться.

Четырехмерное пространство

Ну так получите для начала эти самые фундаментальные знания. Пока что ваши измышления одинаково успешно можно понять и как эфир и как искривление пространства. У вас не зря просят определение поля, ведь всё что вы измышляете можно описать одним абзацем, будь это формальное определение.

Четырехмерное пространство

Т.е. вы решили поделиться с аудиторией тем, что прокручиваете у себя в голове?

Четырехмерное пространство

Тогда вы неправильно назвали/начали пост. Если бы написали что-то вроде «предлагаю способ как интуитивно понимать поля, в частности гравитационное», тогда придраться можно было бы только к тому зачем вы вообще описываете своё представление. Но вы вполне чётко написали «построим свою теорию единого поля».
Предлагаете теорию — будьте добры приложить кило формул

Четырехмерное пространство

Можно придумать десяток аналогий, которые как-то более интутитивно-понятно будут объяснять различные физические явления (ту же гравитацию), однако чтобы иметь хоть какой-то шанс на существование, такая аналогия должна в нормальных условиях сводиться к ньютоновской механике. Не умозрительно, а по формулам. Следующий шаг — объяснение релятивистских эффектов, таких как прецессия орбиты меркурия. Если и эта вершина покорена, но то грех не попытаться объяснить ускоренное вращение галактик и расширение вселенной.
Вообще, сейчас есть бесчисленное множество явлений, который уже объяснены существующей теорией. Предлагать какое-то иное видение мира, не показав что, путь не все, но основные явления вписываются в это видение, просто смешно.

Рядом с центром Млечного Пути нашли сверхмассивную чёрную дыру

Млечный путь весит сотни миллиардов масс солнца. Скорее ЧД упадёт в центр, чем всё остальное начнёт вращаться вокруг неё.

MVC на чистом JavaScript

Он пришёл в веб-программирование из настольных приложений и доказал свою эффективность в новой сфере применения.

В этом предложении есть неоднозначность, т.к. веб-программирование — очень широкое понятие. Веб-программированием можно назвать как создание backend, так и создание frontend. При этом MVC для backend действительно проявил себя в новой сфере, если конечно то что используется на стороне сервера можно назвать MVC. Программирование же пользовательского интерфейса на стороне клиента не стало новой сферой применения для архитектурного подхода с названием MVC, т.к. SPA по сути являются теми же desktop приложениями, просто запускаются в runtime в виде браузера.

Модель в этом шаблоне проектирования занята исключительно работой с JSON или объектами, которые поступают с сервера.

А вот это уже антипаттерн. Модель это больше чем просто объектная обёртка к данным. Это ещё и управление состоянием приложения, а оно, отнюдь, не сосредоточено на данных. Например, отображаемая в данный момент вкладка (tab), а точнее информация о том какая вкладка должна быть показана — тоже часть состояния приложения. А концентрация на работе с данными ведёт к тому, что работа с состоянием размазывается по контроллеру.

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

О деталях реализации вообще никто заботиться не должен. Но в контексте разделения ответственности между Моделью, Представлением и Контроллером ваше заявление в корне неверно и противоречит вашему же примеру. Как раз наоборот — именно контроллер «знает» за какие ниточки дёргать модель, а за какие представление.

SQL vs ORM

Согласен. Но тогда получается, что люди выбирают не столько ORM, сколько хорошо притёртый набор библиотек в составе ORM. Что же тогда отличает ORM от набора библиотек?

SQL vs ORM

Я не говорю что через ORM нельзя выполнять миграции. Кроме того я не говорю что надо писать механизм миграций с нуля. Но возможность выполнять миграции это не то что нам даёт ORM.
Это не тот плюс ORM ради которого стоит выбрать ORM вместо библиотеки, которая заточена только под миграции.

SQL vs ORM

ORM, а точнее популярные ORM-библиотеки всё же делают упор на работу с графами объектов данных и соответственно на генерацию DML запросов.
Генерация же DDL запросов, как и их применение к базе это задача механизма миграций.

SQL vs ORM

Это заслуга не столько ORM, сколько того, что вы заранее ввели абстракцию в виде интерфейса.
Того же эффекта можно было добиться и без ORM, главное тут — чтобы клиентский код обращался строго к интерфейсу и не знал подробности того как этот интерфейс работает внутри.

SQL vs ORM

SQL vs ORM

Вы путаете набор библиотек для работы с БД и коллекциями, и ORM, основной задачей которого является поддержание консистентного состояния объектов в памяти приложения в соответствии с данными в БД.
Этим я хочу сказать, что ни работа с коллекциями, ни удобное подключение к базе, ни сахар при работе с БД не являются киллер-фичами ORM. Да, они есть в ORM, но также их можно заполучить просто используя отдельные библиотеки.
Так что же полезного в самом ORM?

По поводу документации. Так или иначе, сущности и логику работы приложения как-то описать надо, не важно, используете ли вы ORM или пишете запросы руками. Слой абстракции не подразумевает создание собственного сложного фреймворка для доступа к данным, достаточно писать запросы не в самом объекте предметной области, а в отдельном классе, названия методов которого вполне самодокументируемы по названию. Что может быть непонятного в методе findNewsByTitle(title) внутри которого одной-двумя строчками делается запрос и отдаётся массив объектов? Для этого не требуется обширной документации.

Ну и напоследок про sql через ORM.
Всё-таки ORM сам по себе является слоем абстракции. Работа с базой должна быть скрыта в этом слое. А когда мы пишем sql через ORM — мы вытаскиваем работу с базой наружу.

SQL vs ORM

Когда вы используете ORM и пишете SQL код в сложных случаях, вы теряете независимость от конкретной СУБД, т.е. один из «плюсов» использования ORM.
В случаях, когда вам необходимо абстрагироваться от СУБД, вам придётся вводить слой абстркации. Да и без такой необходимости, выделение работы с базой делает код чище.
«Фишки ORM» совсем не фишкки ORM:
  • indexBy — работа с коллекциями
  • подключение к базе — фишка драйвера, такого как PDO, ну или библиотеки, облегчающей работу с базой
  • параметры запроса — аналогично

то есть нужно писать документацию

Да ладно? Вы считаете что это оверхед? А ничего что документация должна быть в любом случае?

SQL vs ORM

Вложенные циклы устраняются не использованием ORM, а использованием объектов для выстраивания структуры обрабатываемых данных.
Не думать как там называется таблица можно введя дополнительный слой абстракции над слоем, который выполняет запросы к базе. Более того, выделение слоя, который выполняет запросы к базе, позволяет таки… выполнять запросы к базе. Т.е. ты пишешь sql запрос, и тебя совесть не мучает за то что ты делаешь хак в обход ORM.
Мне кажется, лучше руками писать простые запросы и иметь возможность так же быстро написать сложный, чем экономить время на простых запросах и безбожно тратить его на сложных.

SQL vs ORM

Миграции к ORM отношения не имеют. Механизм миграций может быть реализован в рамках ORM, как и построитель запросов (для сахара, да и для защиты от дурака), но это не значит, что они не могут жить отдельно от него.

SQL vs ORM

ORM позволяет абстрагироваться от конкретной базы, но не от хранилища данных в целом. Вот только совместимые различия баз, вероятнее всего можно сгладить просто используя QueryBuilder, который будет переводить унифицированные запросы в специфичные.
По поводу маппинга на объекты, а точнее управления их состоянием, может быть, вот только польза от этого видна лишь в stateful приложениях. На PHP, где 90% эндпоинтов либо только читают из базы, либо только пишут в неё, держать пул объектов и следить за их идентичностью (IdentityMap) бесполезно.
Конечно, бывают случаи повторного чтения/записи, сам с таким сталкивался. Но бывает это редко, и наверное оно не стоит того чтобы постоянно иметь немалый оверхед от ORM.
Да, ORM предлагают красивое решение для простых случаев. Но как только начинается что-то посложнее, начинается борьба с ORM, когда ты понимаешь как можно написать запрос на sql, но ORM заставляет тебя совать друг в друга лямбды, которые строят куски запросов с помощью того-же QueryBuilder'a.

Information

Rating
5,991-st
Location
Зеленоград, Москва и Московская обл., Россия
Date of birth
Registered
Activity