Карьера в IT-индустрии
Управление персоналом
Комментарии 724
+1
Это не правда. Во-1, Nodejs не всея руси, отнюдь не везде эта технология считается приемлемой. Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.
+3
  1. Сложно найти технологию, которая везде считается приемлемой.
  2. Я писал про фуллстек, а вы мне про сеньор бекенд. Ок.
+1
1. Python, Go, раньше java была.

2. В статье же об этом речь. И, пожалуй, требование знать sql ко всем бэкендщикам относится.
+2
  1. Python, Go, Java отличные технологии, но тоже не всея руси.
  2. Я не спорю, что чем больше технологий знаешь, тем лучше. Но использование SQL тоже не обязательно. Есть ORM, есть NoSQL базы данных.

Мой первый комментарий не ставит под вопрос другие технологии, но NodeJS + TypeScript (JavaScript) впервые дали возможность быть FullStack и писать только на одном ЯП. Тем самым упрощая процесс профессионального роста.

0

Поправьте меня если я неправ, но Razor — это по сути шаблонизатор. На нем клиентскую логику вы не напишете.

0

Чего только в наше время не выдумают: Blazor — Full-stack web development with C# and WebAssembly

0
Blazor — это конечно клево, но я бы лучше сразу писал на фронтовом языке вместо того чтобы постоянно огребать) Ну и blazor опять никак не решит проблему того, что сеньором во фронте не станешь, тонкости C# окажутся совсем не применимыми к фронту.
0
сеньором во фронте не станешь

А каким критериям должен удовлетворять уровень человека что бы можно было именовать его сеньором?
0
Про это пишет автор статьи и я с ним в какой-то степени согласен.
+2
Сеньор — это человек самостоятельно решающий проблемы и не создающий в этом процессе проблем коллегам, в том числе будущие проблемы.

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

Мидл же может наворотить пачку костылей. Просто потому, что хуже знает систему и предметку, плюс часто хочет показать что «я вот так умею».

Ну и сеньор менее заметен в офисе, но более заметен в баг-трекере)
+1
Наверное наоборот:
«Ну и сеньор более заметен в офисе, но менее в баг-трекере»
0

Сеньоры разные бывают. Одни тащат задачи, другие любят потрындеть и покрасоваться. Я наверно 50 на 50. Хотя почти искренне верю, что первый тип)

-1
Если вся клиентская часть — это набор формочек, то помогут библиотеки jquery-ajax-unobtrusive и jquery-validation-unobtrusive, они настраиваются исключительно атрибутами.

Хотя фулстеком того кто пользуется только ими назвать сложно.
0
Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.

Зачем сеньору-то знать другую технологию? Он же не джун.

+1
Очень интересное утверждение. А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?
+2

Не все приложения требуют использования триггеров. Я и не писал, что typescript на все случаи жизни.

+2
В таком случае нужно понимать что такое FullStack разработчик. В моем понимании это разработчик, который способен написать приложение от и до без посторонней помощи. А не так, что если нужны триггеры, то я уже не FullStack разработчик.
+12

Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.


Так можно до бесконечности продолжать. Например у вас в проекте должен быть ИИ, а нейросеть вы строить не умеете. Вы уже не fullstack.

+3
>> Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
+3
Грамотней означает, что для каждой задачи нужно применять тот инструмент, который для нее наиболее подходит, а не пытаться писать свой велосипед для любой задачи.
+1
Любите вы поспорить. :)
При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
+4

Люблю, да. Особенно вижу категоричные суждения или оперирование общими оценочными категориями типа "грамотней" без указания критериев :)

+5
Скорее всего, самостоятельная реализация триггеров будет тормозить. Скорее всего, эти тормоза будут настолько не важными для проекта, особенно на ранней стадии, что ради них искать узкоспециализированного разработчика бд — пустая трата времени и денег.
Когда бизнес молодой и развивается, ему важно как можно быстрее и проще провалидировать жизнеспособность своей модели. В этих условиях, человек-оркестр, способный в одиночку запилить и бэк, и фронт, намного выгоднее двух крутых специализированных бэк/фронт разработчиков.
Другое дело — когда бизнес уже захватил основную часть аудитории, и начинается борьба за оптимизацию и увеличение конверсии. Тут нужен тюнинг перформанса и все остальное в таком духе, и нужны узкие спецы.
Проблема узких спецов на старте — часто они сходу начинают оптимизировать под будущий «хайлоад», когда вообще не факт что бизнес вообще взлетит.
+1
Скорее не так. Использование триггеров, обеспечивает нам некоторую консистентность данных средствами DB (некоторую, потому что в триггере можно много чего сломать). И это круто — встроенное, надежное и известное решение.

Но всё решают зависимости. В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.

Но если, при изменении записи, нам надо взять данные не из DB, и как-то их по хитрому обработать… Тут возможно имеет смысл спроектировать слой над базой данных, а консистентность сохранить за счёт транзакционности и прямых рук. Это может оказаться, быстрее, надёжнее и даже проще реализовать.

Но, кмк, нам намекают, что то, что можно сделать в триггере, лучше сделать в триггере. Например записать лог изменения записи, или поддержать волшебным образом денормализацию «на лету». И плодить хитрое решение на технологии, которую лучше знаешь, а не на той, на которой от тебя ждут решение… По моему это подготовка будещего мазохизма, притом не своего, а того, кто будет поддерживать твою систему «если что».
+1

Если от тебя ждут решения на конкретной технологии, то надо его как-то делать или сообщать, что не можешь. Но часто такие нюансы как реализация логирования остаются в лучшем случае на усмотрение команды, а и одного разработчика.

+2
В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.

Проблема же в цене поддержки. Если бизнес-логика размазана по триггерам и хранимкам дб — это очень печально. Просто sql очень плохой язык с точки зрения промышленного программирования, вот и все.

0

Ну тут есть вариант: бизнес логика собрана в триггерах и хранимках. И на это может быть много причин. До сих пор.


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


И опять же начало спора было о том, что для разных случаев разные инструменты. И знание вариантов инструментов нелишне.

0
Но это не значит, что от триггеров надо отказываться принципиально.

Об этом вроде никто и не говорил.

0

PS. Sql в богатых расширениях(транзакт sql, pl/sql) это отличный язык для промышленного программирования. Просто нужно понимать какие, задачи решать на нём. Вы же не будете для построения статистики тащить 50 таблиц по миллиону записей на клиент) И пре и, пост обработку данных для некоторых операций проще делать хранимкой

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

FullStack хорош для запуска первой версии продукта или для небольших фирм. Когда требуется не "грамотная реализация", а реализация в принципе. По мере роста проекта уже требуются более узкие специалисты.


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

0
>> Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А.
Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
+1
FullStack хорош не только для запуска, но и последующего контроля. Эволюция FullStack — это архитектор проекта.
0
На самом деле в большинстве случаев когда ищут FullStack'a — на самом деле предполагается что 95% времени он будет работать в одном стаке и изредка надо будет что-то поправлять в другом.
0
Ну не знаю, как так предполагается, то обычно пишется что-то вроде: PHP, знание JS будет плюсом. А если ищут именно фуллстэка, то предполагается что основные задачи будут на весь стэк.
+1
По-моему, если база не какая-то специфичная, то лучше всю логику делать в коде, а не «часть в коде, часть в базе»
Код проще тестировать и поддерживать. Да и случаи замены базы, хоть и довольно редки, но все-равно случаются.
+1
Что значит «нужны»? Вот в бизнес-задаче декларируется «нужны триггеры»?
+8
А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?

Есть же достаточно распространенное мнение, что использование триггеров (и вообще дергание скл руками) — code smell. В такой парадигме неумение использовать тригеры — конкурентное преимущество.

+1
Триггеры в данной ситуации лишь пример, а не предложение повсеместно их использовать т.е. вместо них можно придумать любой другой подходящий.
+1
Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?
+2
Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?

Зависит от ситуации.
SQL, конечно, хорош в плане перформанса, но:


  1. не всегда в принципе скорость запросов — бутылочное горлышко.
  2. код на SQL, мягко говоря, не слишком удобен в плане поддержки.

В общем, как и всегда — есть разные задачи, есть разные инструменты, а серебряной пули нет.

-3
код на SQL, мягко говоря, не слишком удобен в плане поддержки.
просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.
не всегда в принципе скорость запросов — бутылочное горлышко.
трудно не согласиться, но если есть возможность — надо ей пользоваться — к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.
+2
Если использовать хранимки...

Если она будет ровно одна, то, возможно, не стоит.

к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.

… однако, если у вас уже есть подсистема, которая форматирует данные, в том числе полученные не из БД, то этого делать не нужно. Особенно если там все по-взрослому, с подтягиванием настроек пользователя, определением региона, учетом смещений часовых поясов и всего такого.

ИМХО, спор про то, на чем правильно делать то или это в абстрактном проекте — беспредметный.
+2
Трудно, но можно. В postgresql, mysql и оракле такая возможность есть. Суть такова:
  • Как язык SQL плох, но без него никак. Он динамический, имеет громоздкий синтаксис и на 90% состоит из весьма нудного бойлерплейта. Читать — легче. Понимать — ещё легче.
  • Переписывать всю БЛ на хранимки, как предлагают некоторые горячие головы, равносильно отстреливанию себе в упор всех конечностей.
  • Хорошие ОРМ значительно удешевляют разработку. Но чтобы уметь ими пользоваться, нужно по мимо ОРМ знать SQL.
  • Даже с самой хорошей ОРМ писать SQL всё равно придётся.
  • Использовать nosql только потому, что лень учить SQL или разбираться с ОРМ — такая же дичь, как и писать всё на хранимках, чтобы не учить условную java. Нужно учить CAP теорему и разбираться, когда использовать nosql 1) допустимо 2) приемемо 3) оправдано. Вопросы не тривиальные практически всегда.
+1
А есть ли возможность гонять эти тесты без непосредственно базы данных? Потому что для бэкенда как бы это практически всегда запросто. Более того, в моем родном дотнете скоро обещают возможность запуска owin-based-приложух прямо в памяти. Типа можно писать интеграционные тесты на ваш API вообще не запуская сервер.

Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
+2
просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.

Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.

В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
+1
Угу. Все запросы — в хранимках на сервере, а история и blame — в гите. Вот и выросла цена сопровождения кода на пустом месте.
0
а чем хранимка отличается от скрипта? Элементарно выгружается в текстовый файл — чистый скрипт. и элементарно версионируется.
-1
Администраторы субд делают это с закрытыми глазами, для них это основная работа — а по простому — просто запустить батник, который сделает дамп, и отправит на гит. так же можно и восстановить. Я в очередной раз прорекламирую инструмент для работы с субд — dbForge — позволяет просто делать резервную копию базы, как с данными, так и просто структуру с триггерами, вью, функциями, хранимками. можно для каждого разработчика иметь свой экземпляр и очень просто сливать в одну и её уже переносить в базу продакшена.
0
Каждому разработчику могут понадобиться их с десяток за день, а слияний за день может быть сотни. Сколько будет делаться дамп и восстановление с него на более-менее серьёзной базе?
+1
считай: перейти в ide — выбрать нужный файл -подтвердить действие — дождаться завершения, итого секунд 15.
и дамп и восстановление.
слияние — в ide -выбор в меню, выбор базы источника, выбор базы приёмника — сравнение — галочками отметить что слить — enter, итого секунд 30.
из практики — ни о каких сотнях в день речь не идёт…
дамп делается не всей базы а только выбранного -структуры, данных или отдельных выбранных элементов.
каждому разработчику лучше иметь свой экземпляр базы, (лучше на своей машине) со своим набором даннх(они могут быть элементарно перенесены как с базы продакшена, так и с любой базы разработчиков)
при слиянии отображается разница между базами-по каждому элементу как структуры так и данных.
отладка также происходит в ide, хранимки можно отлаживать по шагам (запрос в хранимке -это один шаг).
написали хранимку сохранили — выполнили — увидели результат. можно отдельно отлаживать запрос тогда и сохранять не надо просто написать — запустить — увидеть результат. и уже потом вставить в хранимку.
0
То есть только ручные слияния, ручные переключения, ничего подобного git checkout feature-name или git merge feature-name. Эта система не предполагает хранения истории версий, не обладает информацией о том, что версия 7 основана на версии 3, а версия 4 на версии 2 и при объединении версий 7 и 4 за основу нужно брать версию 2, а не 3 или 1?

А сотня изменений в команде из десяти разработчиков за день создаётся легко.
-1
Всё дело в том, есть ли у вас желание получить в итоге качественную, быструю систему, а не просто срубить бабла, а там будь что будет. Вы можете меня убеждать сколько угодно, но пока вы сами не захотите работать (лили хотя бы поработать), и организовать всё версионность работы под себя — это будет разговор ни о чём. желающий ищет возможности, не желающий — отговорки.
0
У меня есть желание, обычно, сделать заказчика системы довольным. Я использовал много разных подходов к версионированию баз данных (не только таблиц, но и хранимок, триггеров и т. п.), но только с декларативным описанием таблиц в текстовых файлах (в SQL императивные команды на создание таблиц, впрочем как и все остальные — уж не знаю почему его считают декларативным языком ) получалось что-то сочетающее:
— скорость разработки
— возможность параллельной (или псевдопараллельной) работы над десятками фич или над несколькими фичами, затрагивающими много одних и тех же таблиц
— автоматическое разворачивание и обновление локально и на удалённых серверах

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

Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.
0
Причём даже с только с таблицами возникают ситуации, когда приходится предупреждать всех разработчиков, что собираешься, например, переименовать поле.
это будет в любом случае, если есть необходимость изменить структуру базы. Но используя IDE субд это делается просто — везде где надо поле переименовывается а в зависимых запросах можно добавить as «старое_имя» и в коде никаких изменений вносить не надо…
в этих ide и прочий рефакторинг делается просто.
Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.
Из практики — возможности хранимок увеличивают возможности, к примеру хранимки могут возвращать несколько результсетов, при добавлении записи в одну из связанных таблиц сразу добавляется и в другую… что сокращает обращений к базе. ну и, не маловажный фактор, защита данных, и полная защита от инъекций. Если не использовать специализированные ide для работы с базами — то это трудно и накладно, но ведь и никто не пишет проекты в блокноте…
я принял как стандарт — даже простейшие запросы оборачивать в хранимки — самое огромное преимущество — огромная быстрота быстрота их написания любой сложности и огромная быстрота отладки. написал — запустил — увидел результат. ни компиляции кода, ничего. даже в том же хибере, даже если ide помогает написанием запроса — то увидеть результат — надо сделать кучу действий. как минимум запустить какой-нибудь тест. В ide субд — только запустить на выполнение…
0
То есть в двух IDE постоянно работать и синхронизировать их код вручную?

А вы правите код непосредственно хранимки или какого-то скрипта CREATE OR REPLACE…?
0
Работа в двух ide — это не проблема. Синхронизировать их коды вообще не нужно, вот пример кода на java
try (Connection con = dataSource.getConnection(); CallableStatement proc = con.prepareCall("{call хранимка1(" + param + ")}");) {
            rs = proc.executeQuery();
            rs.next();
            userSession.getBasicRemote().sendText(rs.getString("av"));
        } catch (SQLException | IOException ex) {
            ex.printStackTrace();
        }
это конечно, примитивное использование, но показывает как это делается,
я написал вызов и обработку, в param набор передаваемых данных(вариантов прередыи несколько — выбор — повкусу и месту), на этом работ с java закончена.Открываю ide dbFogge и работаю с нужной хранимкой.
Я работаю непосредственно с хранимкой, всю остальную работу за меня делает ide. при запуске она спрашивает о сохранении хранимки и формочкадля ввода параметров(достаточно ввести один раз, в дальнейшем просто подвердить), иногда мне это надоедает я открываю запрос из храники (в том случае если хранимка состоит из одного запроса) в новой вкладке и просто запускаю его (предварительно организовав входные параметры(если они нужны :) )
добившись правильной и быстрой работы хранимки — сохраняю её. Всё. Никакой синхронизации.
если кто-то изменил что-то в базе, в огромном большинстве случаев в коде ничего менять не надо. Достаточно открыть хранимку она закричит о несоответствии чего-либо, просто её поправить, главное чтоб она возвращала «правильные» названия полей и их количество. Ну а — правильность данных в этом случае — это уже по месту. Чисто теоритически хранимка может представлять (на какомто этапе разработки) из себя заглушку, которая просто делает такое
select 0 as поле1 1, 'xxxx' as поле2 from table
union
select 3 as поле1 1, 'rrr' as поле2 from table;

этого достаточно чтоб отладит код. а специалист по субд может отладить хранимку(добавив к имени префикс)
0
Как минимум нужно синхронизировать параметры и результат. Переименовали столбец (или что там) av в хранимке, нужно переименовать его и в Java коде.

И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал? Или переименование таблицы реплицируется на все базы всех разработчиков и не только таблицы, но и её использование в хранимках? IDE для той же Java начнёт ругаться об ошибках с тем что-то не так вызывается, как только получит код, а не дожидаясь его закрытия или, тем более, запуска.
0
Как минимум нужно синхронизировать параметры и результат. Переименовали столбец (или что там) av в хранимке, нужно переименовать его и в Java коде.
ничего подобного делать не надо, достаточно использование алиас (as ) и всё. у вас в коде будет постоянное имя поля.
И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал?
я говорю о ide dbFogre (Devart, у этой фирмы есть ide для популярных субд) при переименовывании возникает вопрос о применении рефакторига — и изменения вносятся во все места где встречается место для смены имени таблицы, хранимки, вью, функции, использование as избавит от смены имен полей в коде.
можно использовать каждому свой экземпляр базы, и по завершению работы над куском задачи сливать в «общую».
этот процесс наглядный, простой, удобный…
при сливании показываются все отличия, так что сделать ошибку трудно.
хранимки поддерживают комметарии в коде.
0
Так эта IDE работает с базой непосредственно или с исходными кодами в текстовых файлах, а может синхронизирует их? Пока то, что вы описываете, больше напоминает какую-то крутую админку к базе, типа как плагин работы с СУБД в IDE от JetBrains, а не инструмент разработки приложений. Слияние баз, о котором вы говорите — это генерация нового дампа, в котором можно посмотреть отличия с предыдущим, генерация скрипта миграции или реальное слияние, типа подключились с дев-машины к проду и запустили синхронизацию локальной базы с продуктовой?
0
Работает непосредственно с базой, может иметь коннекты к нескольким базам, поддерживает подключение к удалённым базам по ssh.(я так обновляю у клиентов)
больше напоминает какую-то крутую админку к базе,
не просто крутую, а ОЧЕНЬ КРУТУЮ да, это не инструмент разработки приложений, а инструмент разработки запросов, функций, вьюшек, хранимок. Инструмент полноценной работы с базой
Слияние баз, о котором вы говорите — это генерация нового дампа, в котором можно посмотреть отличия с предыдущим, генерация скрипта миграции или реальное слияние, типа подключились с дев-машины к проду и запустили синхронизацию локальной базы с продуктовой?
это всё в одном. Есть два пункта «слияния» -для структуры и для данных. как результат — генерируется скрип, который можно посмотреть, а можно и запустить.
подключаете ide к проду и к свой базе, сливаете необходимые данные и тестируете у себя на реальных данных.
можно делать «резервную копию» — я так резервировал базу с клиента — 14гиг в зипе.
все запросы можно строить в гуи,
не идеальный, но отличный редактор для написания, с подстановкой, подсветкой кода, есть форматирование кода.
есть «проводник» в котором перечислены все элементы, можете выбрать таблицу и увидите что от неё зависит, выбираете хранимку и видите от чего она зависит.
наверно единственно чего не хватает — это работы с гит, но у них есть глосовалка и этот пункт набирает голоса.
Ребята активно развивают продукт, активно откликаются на замеченные баги.
0
Я работаю с тремя IDE: PhpStorm, IDEA, DataGrid
Так вот, BigDflz прав (а вы все же зря спорите) в той части, что он про tool for database — это вполне можно назвать «IDE для базы данных» либо «сильно крутая админка».
Да, весь функционал по работе с БД присутствует.
www.jetbrains.com/datagrip/features
Вид

P.S. Конечно, BigDflz вел речь о «другом» продукте, но они из одной ниши.
P.P.S. Про саму концепцию «как писать» — я вмешиваться не хочу… у меня лично позиция, как и у вас, но BigDlfz я так же понимаю.
Всему свое место )))
+1
А не прав он в том, что ручные операции в IDE называет «автоматизацией»…
0
Скорее с мощными IDE это частично автоматизированные операции.
0
Вроде же все три имеют один модуль работы с СУБД (последняя ничего кроме него и не имеет по сути). Я его знаю и активно использую (PhpStorm обычно), в том числе и для хранимок. Но проблемы работы с логикой в СУБД как с обычным кодом он не решает, впрочем и со схемами/начальными данными тоже. По сути, когда вынужден что-то менять прямо в базе, чувствую себя как будто на 20 лет назад вернулся. Всё это версионирование через имена файлов/сущностей, бэкапы, слияние «глазами» и т. п.
0
Эм, пардоньте, но я даже линк с фитчами кидал от JetBrains… там и VCS (Git) есть, и «изменения в БД» (вкладка).
Можно ведь делать в пару кликов выгрузку того же ddl и «в базу» лить скрипт. По крайней мере JetBrains гордится своим продуктом (на пустом месте?).
0
Может как-то не так его использую, но разве есть там маппинг файлов с кодом на схему? Типа файлик изменил или ветку переключил и изменения автоматом в базу попали, как попадают, например, исходные коды на удалённый сервер?
0
странно, но таких проблем не испытываю. может потому что работу над проектом начинаю с проработки базы.
дак вопрос в чём?
в преимуществах работы с хранимками или то что работа с базой «плохо версионированна»?
если у вас текст запроса в коде, то при изменении имени поля в базе, разве не надо искать все вхождения этого поля по всем файлам проекта? Тогда как инструмент рефакторинга в IDE это сделает во всех хранимках, а чтоб не копаться в коде достаточно использовать алиасы в коде хранимке.
0
У работы с хранимками, вьюхами и прочим кодом, хранящимся на стороне СУБД, вернее в СУБД, есть и плюсы, и минусы. Один из минусов — отсутствие версионирования, отсутствие возможности (может в этой dbForge есть) работать с этим кодом через текстовые файлы с кодом этих хранимок и т. д. Для схемы таблиц эти вопросы худо-бедно решены через декларативные описания и генерацию миграций через диффы схем. Для исполняемого кода я чего-то удобного не видал. Удобного как для разработки, так и для автоматического раскатывания по серверам с каких-то CD серверов
0
работа с хранимкой — это работа в текстовом редакторе IDE, как с обычным текстом. с цветовым выделением, форматированием, подстановкой. Отсутствие версионирования не такая уж и проблема(хотя иметь возможность отката вещь приятная, тут не поспоришь) я тут уже описал свою технологию работы с хранимками.
Повторюсь несколько. Я использую все обращения к базе через хранимки, в запросах(которые в хранимках, я использую алиасы, это позволяет избежать зависимости от названия полей, таблиц в коде основного софта. если кто-то внешний изменит имя поля, в IDE есть рефакторинг, который найдёт все использованные имена и предоставит возможность их переименовать и сделает это автоматом в всей базе. в коде все останется по прежнему. Это как бы «подобие json» для обмена данными между базой и кодом. Чего нет при использовании запросов написанных в коде софта. когда я занимаюсь отладкой хранимки (в большинстве случаев — это простой селект) я правлю только текст хранимки и проверяю его работу, какие данные он выводит, как работает, смотрю план запроса. Это происходит быстро. Код софта при этом не трогается. Я могу проверить как работает код сделав хранимку-заглушку. Отладив хранимку(запрос в ней) проверяю как работает всё вместе и код и выборка данных. Ни каких 100+ вариантов хранимки мне не нужно. в хранимке можно комментировать любой фрагмент, в любом месте.
если надо хранить варианты, для этого есть команда продублировать. и в базе будет сделана копия элемента(хранимки, вью...)
для нормальной разработки лучше иметь у каждого свой экземпляр. базы.
Обычно использование хранимок воспринимают как перенос бизнес-логики в базу, но это не всегда так, хранимки — это разделение работы.
Вы написали вызов хранимки, перечень параметров, список возвращаемых полей, и этого достаточно что специально обученный DBA сделал оптимальный вариант обработки данных. Чего нельзя сделать при написании кода запроса в основном коде. DBA делает своё дело — вы своё. Это как разделение фронт-енд — бэк-енд, только добавляется бэйз-енд.
0
Дело не в возможности отката, дело в возможности разрабатывать параллельно фичи, затрагивающие одни сущности базы и удобно (в большинстве случаев автоматом) сливать их, а также просмотреть историю изменений удобно, как в виде различий, так и в виде «снэпшота». Все системы, претендующие на просмотр изменений, которые я пробовал, не могли предоставить её удобно. Даже просто таблицы взять: список команд CREATE TABLE ..., ALTER TABLE ..., ALTER TABLE ..., DROP TABLE ..., CREATE TABLE ..., ALTER TABLE ..., ALTER TABLE… — это не история изменений, это история команд на изменение.
-1
Тут проблема в том, вы вторгаетесь в область DBA со своим мерками, несмотря на то, что строго разграничиваете фронт и бэк. Область баз это такое же звено как бэк и фронт. Те проблемы что вы перечисляете по работе с базами — у DBA нет. Посетите www.sql.ru/forum/microsoft-sql-server. И что и как там решается. Либо научитесь работать с базами, либо наймите DBA. Это не в обиду, не в оскорбление, это просто многолетнее наблюдение, когда пишущие на C, java, php и пр. начинают заниматься базами… Почему из фронта не лезут в бэк и наоборот(если не фулстеки :) ), но почему все считают себя знатоками баз?

0
DBA есть отдельные, но это именно администраторы, а не разработчики. Схема базы — не область их ответственности, максимум могут порекомендовать переписать запрос, добавить индекс или изменить структуру. Ну и «наймите DBA» совет совсем не по адресу, когда говорим о разработке, а не о управлении разработкой.

P.S. я как раз фронт и бэк не разграничиваю строго, даже если они в разных репах лежат.
0
Тогда нужен специалист по работе с базами. Я вообще не разграничиваю — ни фронт, ни бэк, ни бэйз. И для меня не знакомы ваши проблемы с базами. Для меня просто странно выглядят эти разбросанные грабли по которым бродят, и жалуются на всякую ерунду. Сначала создадут запрос в коде, потом изменяют поле, и требуется изменить во всём коде… Ну нет этой проблемы, пользуетесь IDE для написания кода — так и для работы с базами есть инструменты. Я знаю контору в которой в одном проекте 900+ хранимок mssql, и все работает, развивается.
0
Я знаю контору в которой в одном проекте 900+ хранимок mssql, и все работает, развивается.

900+ хранимок — это проект уровня гостевой книги по размерам, такой можно разрабатывать как угодно и на чем угодно, проблем не возникнет.
Что если хранимок будет 900+ сотен?

0
могу сказать, что это проект уровня транспорта России.
Что если хранимок будет 900+ сотен?
тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.
0
тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.

То есть проект не поддерживается? Написали и выкинули?

0
проекту уже более 10 лет. живёт и развивается. просто у людей нет страха перед использованием хранимок и их количеством.
0
проекту уже более 10 лет.

900 хранимок за 10 лет? То есть, по сути хранимки в проекте практически не используются?

0
То есть, по сути хранимки в проекте практически не используются?
Придирки не приветствуются! Если вы думаете, что за 10 лет только добавляются — значит вы не поддерживали проект длительное время, как правило большая часть подвержена изменениям, причём очень частым — требования и законы меняются постояноо. и добавление не столь сложная задача как изменение существующего.
0
Да не в полях проблема, а в том что нет удобного инструмента синхронизации исходного кода в текстовых файлов с базой. Чтобы был у меня в гите файлик /sql/procedures/simpleproc.sql типа
```sql
PROCEDURE simpleproc (OUT param1 INT) BEGIN
SELECT COUNT(*) INTO param1 FROM t;
END
```
и какой-то вотчер, который любые изменения в этом файле «маппил» бы на базу, сам анализируя, какую команд(ы) конкретно запускать, например DROP при удалении файла и CREATE при создании. Ну и все прелести современной разработки типа навигации по именам, автозаполнения, обнаружения ошибок без обращения к базе и т. п. Чтобы поднимать базу мне приходилось только для тестов (так же в файлах лежащих) и отладки, а код мог спокойно писать без базы.
0
если для вас это проблема, и вы ставите крест на использование процедур, тогда запретите вообще процедуры во всех субд, обвините разработчиков субд в помехах программированию и будет вам счастье. Если для вас это проблема — может вы просто не научились их готовить?
У меня нет ваших проблем, ваших страхов, я использую хранимые процедуры по-полной и наслаждаюсь их возможностями.
Не нравится — не ешь, но зачем кричать, что это не вкусно?
0
Я не ставлю крест на их использовании из-за страхов. Я ставлю крест на их использовании по умолчанию из-за неудобства (читай — дороговизны) поддержки, отношу их использование по умолчанию к преждевременной оптимизации.
-1
это твоё право, твоё мнение — но не надо настаивать, как на истине первой инстанции
+3

В целом зависит от задачи. И ОРМ придумали как раз для упрощения и увеличения продуктивности.

+1
А можете привести пример триггера в какой-нибудь СУБД
Да мы уже поняли что вы обожаете триггеры в бд и везде их пытаетесь сувать, не думаю что это характеризует вас как «Senior developer»
+10
Имхо хорошая концепция быть крутым в одном и примерно понимать и немного практиковать окружение.
+2
Я думаю, что своё «вширь vs вглубь» можно варьировать, т.е. необязательно либо вширь, либо вглубь. Я бы сказал, что обе крайности опасны. Вширь — описал автор. Вглубь — другая проблема: сегодня ты сеньор технологии N, а завтра она выкинута на помойку (как не редко бывает в IT).
+3
У музыкантов на эту тему есть поговорка «сегодня ты играешь фьюжен а завтра никому не нужен».
+43
могу попробовать уйти в управление

Вы знаете, то о чем Вы написали и есть путь в управление.ИТ Архитектор это и есть профессиональный дилетант.Знающий много технологий и "прокладывающий путь" проекту.
Конечно, если архитектор делает фичи сам а не делегирует их более узкоспециализированным разработчикам,- может получится лажа.Архитектор строительный я думаю тоже может заштукатурить стену… но профессиональный штукатур сделает это лучше. Но штукатур не сможет быть архитектором.

+10
Только управление — это прораб/PM, а не архитектор. Совсем разные компетенции.
0

Только в крупных проектах есть и прораб и архитектор, в небольших все таки стараются совмещать (оттуда ноги и растут). И это не только в IT

+3
То есть мидл фулстек дев станет ещё и мидл архитектором и мидл PM?

Если честно, плохо себе представляю, что на небольшом проекте техстек будет выбирать человек, не пишущий код. Ну то есть как «не представляю» — видел, но больше не хочу.

И ведь его даже на смех то поднять нельзя.
НЛО прилетело, и опубликовало эту надпись здесь
+29
А надо было учиться программировать.


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

Вот что вы за занудством занимаетесь? Это как на галерные лычки наяривать: «я не программист, я сениор эксперт мастер рокстар девелопер».
+19
Понавыдумывали понятий — разработчик, девелопер, программист, кодер, инженер… и никто разницу понять не может
+20
Мало того — они еще и внутри этих классов норовят поделить на сеньоров-миддлов-джуниоров. Никак людям не живется без цветовой дифференциации штанов
+4
Там есть ещё экземпляры, со своими «гуру», «джедаями» и прочими «рокстарами» от которых хочется блевать
+9
Понравилось, вчера кто то из хабарожителей написал комент:
Мне нравится разделение по уровню ответственности:

Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
+1
Беда в том, что есть очень много людей в ИТ сфере, которые даже не поняли вашу игру слов.
+2
Ханин мягко улыбнулся. — Творцы нам тут на ххх не нужны, — сказал он. — Криэйтором, Вава, криэйтором.
+9
Навешивание ярлыков и ваше деление людей на «кодеров» и «программистов» устарело уже лет на 20. Не смешно уже.
+9
Да да, в какой-то момент каждый задумывается об этом.

Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.

Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.
+7
У Райкина была хорошая юмореска про узких специалистов: У нас узкая специализация. Один пришивает карман, один - проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть? И они — не портные, они — подмастерья.

Узкие специалисты нужны редко и ненадолго. Если нужен человек по конкретному интерфейсу SoС — его можно позвать на конкретную задачу. А нужны именно full-stack — спроектировать схему, развести её, спаять, отладить электрически, запустить SoC, потом RTOS, потом приложение.

Это должна быть очень крупная фирма, чтобы позволить себе держать специалиста по RS-485 или RS-232. И очень много разных платформ, чтобы у него был фронт работы.

Ну и потом, узкий специалист не может нормально отлаживаться. Ио работу кода мы отлаживаем осциллографом, а проблемы в железе ищем кодом.

Так что сеньор — это full stack, а «мастера по пришивке пуговиц» — джуны. Для того и было придумано разделение труда и узкая специализация — чтобы заменить десяток сеньоров сотней джунов.
+5
По мне вы описали слегка расширенного, но довольно специализированного разработчика встроенных систем. Когда для созданной железяки понадобится мобильное приложение или сервер сбора данных — это окажется за пределами компетенций описанного специалиста.
А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МК
+3
Угу, любой нормальный embedчик — это fullstack. А для редких задач мы привлекаем узких специалистов. Например, привлекали спецов по CAN и по MIL-STD-1553B. Мобильное приложение, сайтик, сервер — это все из другого мира. Того, где linux — достоинство, а не недостаток.

Хуже — это по каким параметрам? По количеству ошибок, по читаемости, по стабильности кода за 10 лет? Когда у вас для отладки только светодиод и осциллограф — есть смысл писать надежно и просто. То есть весьма-весьма дубово. Но это достоинство, а не недостаток.
+4
Кажется вы меня не до конца поняли. Описанный вами embedчик-fullstack — для меня выглядит, как узкий специалист. Хотя, возможно я лукавлю и задним умом считаю логичным разделять разработку железа и его программирование примерно также, как front-end и back-end.

Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.
0
Узкие специалисты это: «элементщик» (тот, кто компоненты выбирает), закупщик, проектировщик схем, разводчик, оформитель схемы по ГОСТ (приглашали разок), технолог производства печатных плат (консультировались), монтажник, технолог пайки… Это только по стороне железа.

А на стороне софта… у RS-485 есть терминаторные резисторы. Ну как настраивает резисторы обычный программист? Посмотрел осциллографом, поставил — и тест на сутки. Если больше одного сбойного байта за сутки — менять номинал. А узкий специалист сразу ставит нужный резистор.

SOLID — это все-таки С++. Простой и читаемый код — это обычный Си, близкий к ассемблеру. См. драйвера linux — они довольно хорошо написаны.

P.S. У нас в конторе есть всего один узкий специалист — это технический писатель по ГОСТ.
+1

Зачем вы в каждое обсуждение пихаете свою предметную область с отсылкой к "а у нас вот так, и поэтому весь мир должен думать так же"?


BTW, SOLID — это не про С++ и принципы можно и нужно использовать и в не ОО-языках тоже.

-1
Это просто реакция на тех, кто считает, что весь мир делает web-приложения. Поэтому и рассказываю о том, что бывает за пределами узкого мирка web-архитектуры.

А про SOLID в не ОО-языках — расскажите или ссылку дайте.
+1

Все принципы, кроме подстановки Лисков можно применять к процедурным и функциональным языкам, просто надо думать в чуть более широком смысле. Например, SRP — функция должна иметь конкретную зону ответственности. Interface segregation — подразумеваем интерфейс в широком смысле, не ключевое слово, а API. И так далее.

-1
Ну как раз что-то вроде принципа подстановки Лисков мы применяем в Cи-коде. Делается указатель на процедуру — и вперед. Примерно как onexit в Си.

Просто нафига очевидные вещи называть громкими словами?
0

Принцип подставки Лисков говорит об отношениях между типами и подтипами, как это вы его используете в Си?
onexit — это обычные коллбеки.
Очевидные вещи:
1) очевидны не всем;
2) очевидны по-разному;
Что и демонстрирует ваше непонимание очевидных другим вещей.

0
Читаем определение:

Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

Вот на callback и на weak-функциях оно и делается. Базовый тип — вывести информацию Специализации — вывести на RS32, на RS32 через ПЛИС, на CAN, на MIL-STD-1443b…

onexit — как раз нормальный пример. Базовый тип — выполнить финализацию. А специфические подтипы делают конкретные вещи.

В принципе группа weak-функций или callback дает вполне функциональную замену ООП. Даже с наследованием (можно выставить свою функцию на callback и в ней вызвать то, что было на callback раньше.
+2

Короче вы спорите со мной непонятно о чём. Если вы сделали в Си псевдо-наследование — честь вам и хвала. И это даже больше подтверждает моё утверждение. Если вам просто хочется поговорить, так и скажите, а не прыгайте с темы на тему.
JFYI, постоянные упоминания деталей ваших реализаций не делает вас круче, равно как и не даёт дополнительной информации собеседнику.

0
Мое видение таково

Инженер: Если работает так как надо, то дальнейшие улучшения не требуются.
Программист: Если результат не оптимален, то не будет работать как надо.

У первого цель — рабочая программа.
Цель второго — не ломающаяся программа.
+3
Как embedчик не соглашусь с вами. Железо и софт очень сильно отличается, и я еще ни разу за свою карьеру не видел человека, который был очень хорош и там, и там. Как правило, у каждого очень сильный перекос в какую-то из этих областей. Поэтому очень важна специализация каждого, чтобы выпустить качественный продукт. Конечно, если в компании два человека, делающие мелкосерийный продукт для конкретного заказчика со сроками «надо было сделать вчера», то понятно, что каждый должен уметь что-то в каждой области.

Другое дело когда проект большой, сложный и массовый. Вот у меня сейчас проект — это кодовая база на несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом. Поэтому тут и SOLID, и юнит тесты, и blackbox тесты, Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.

Все-таки разделение труда — это главное достижение человечества.
-4
Миллион строк? Гм, простите, какой объем ПЗУ это занимает? И почему бы при таком объеме кода не использовать linux? А linux — это по моим понятиям уже не совсем embed. Ну или совсем не embed.

Разделение труда (в пределе — конвейер) придумано, чтобы привлечь к работе низкоквалифицированный персонал. Брукс хорошо доказал, что увеличение численности не ускоряет разработку (если 9 беременных женщин собрать вместе, ребенок через месяц не родится), наоборот, в его конкретном случае, увеличение численности в 10 раз разработку замедлило.

Поэтому вопрос в экономике. Нужна эффективность производства — делаете конвейер с сотней программистов. Нужно качество — обходитесь всего несколькими сеньорами.

несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом.
Поржал. Зачем это отлаживать на МК? Разработка и отладка 99.9% идет на windows. Да, приходится делать имитаторы и писать переносимый код. Но на windows отлаживается все, кроме очень специфичного для МК кода. Потом перенос на linux, потом — на МК.

У меня был проект с доступным временем на отладку на реальном стане — 2 часа в месяц (130 тысяч строк кода). Ничего, справился без отладки.

Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.
Ну и я таких терминов как SIL и HIL не знал. Но мы их применяли почти 20 лет назад. Как-то не сложно было независимо их изобрести.
+4
Был у нас на прошлой работе яжпрограммист, начальник отдела программных средств АСУ, а я, соответственно, был сеньором ведущим инженегром в отделе технических средств АСУ. Граница раздела компетенций отделов проходила по клеммникам подключения проводов к контроллерам. Ну вот исторически так сложилось и усиленно поддерживалось руководством. Техник — не лезь в дела программеров, без тебя разберутся, а твоя задача ТЗ написать, железо подобрать, чертежи начертить, процесс сборки проконтроллировать, протестировать, смонтировать, пусконаладить и сдать. А программистам — программистово, код напишут, зальют, посидят за ноутом на пусконаладке, а ты бегай, выполняй их указания, какой датчик попинать, чтобы заработало.
Так вот этот товарищ усиленно не хотел разбираться в том, чем будет управлять програмирумый им ПЛК и как этот ПЛК, собственно, функционирует. Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать, либо алгоритмы вытрясайте у технологов.
И вот настал тот последний проект, который мне в той фирме посчасливилось доводить до конца, от конструкторской документации и почти до пусконаладки. Система ответственная, для нефтехимпрома, контроллеры отказоустойчивые, вероятность отказа 0.(0)1%. Нарисовал схемы, собрали шкафы на сборочном участке, собрали стендики-эмуляторы сигналов, закупили калибратор за бешенные бабки для настройки аналоговых каналов. Начался этап тестирования софта, я подаю сигнал 4...20 мА, имитируя работу датчика, программист смотрит, что пришло, подгоняет единицы измерения — ток в паскали, мм, кубометры и прочее. Подаю я, значится, сигнал, яжпрограммист ждет, что там будет уровень в емкости 1 метр, а уровень то скачет немного, шумит младшими битами 12-битный АЦП в ПЛК. И тут возникает «шум АЦП» со стороны яжпрограммиста: ты что это, подлец и диверсант, делаешь, я ж прошу выставить уровень в емкости 1 м, а ты какого рожна выставляешь то 0.99, то 1.01 м, ты мне вынь да положь 1.000м, как я с буду программу отстраивать на работу с такими данными? Чуть я заикнуля про необходимость фильтрации, аппартаной или программной, как «шум АЦП» начал усиливаться, что это я лезу не в свое дело, мое дело должно быть маленькое, обеспечить нормальное функционирование техники, а не учить программистов работать, что это за препирания с начальством, да и вообще таким специалистам тут не место.
+2
Мне кажется что человеку который не знает что АЦП шумит не место в области.
0
Это аппаратная проблема, программисты этим не занимаются (с) анекдот.
+2
Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать

Чуть я заикнуля про необходимость фильтрации, аппартаной или программной

Тут всплывает весьма важный вопрос: а почему в предоставленном разработчику ТЗ и описании алгоритмов ни слова не было сказано про фильтрацию или сглаживание входных сигналов?
На тему «это же очевидно» и «это же надо знать» — увы, нет, как минимум потому, что нередко можно встретить модули AIn с включенным по-умолчанию фильтром, и, следовательно, если его нет по ТТХ изделия, стоит явно сформулировать требование о наличии фильтрации, а не махать руками во время пусконаладочных работ, мол, «ты должен был знать».
Так что, как говорится, «без подробного ТЗ результат ХЗ».
+2
Согласен, но как обычно есть несколько тонкостей.
1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.
2. ТЗ пишется исполнителем (да, те самые отделы технических и программных средств), поэтому относятся к нему, как к формальности — отдельному пункту бюджета поекта. Таким образом, утвержденное заказчиком ТЗ является, прежде всего, документом, который в дальнейшем отсеивает необоснованные притязания заказчика к исполнителю по функциям и задачам системы. И уж во вторую очереди исполнитель обращается к собственноручно составленному ТЗ, чтобы посмортеть, а как же на самом деле надо реализовать ту или иную вещь. Возможно, в других отраслях заказчик приходит к исполнителю с готовым ТЗ, но у нас все наоборот.
3. Фильтрация сигналов таки была прописана, это стандартный шаблонный пункт (да, мы используем предыдущие наработки в дальнеших проектах, не пишем «код» каждый раз с нуля).
4. В модулях AI фильтр встроенный есть, на этапе работы с железом (в момент испытаний же!) стало ясно, что его возможности не удоволетворяют требованиям точности. Если железячники о причинах проблемы догадались сразу и тут же предложили метод решения, то яжпрограммист пошел по пути наименьшего сопротивления. Зачем создавать себе работу, если можно свалить проблемы на соседний отдел?
Да черт с ним, с АЦП, это одна из историй, создавшая проблемы ровно на 2 рабочих дня, с учетом совещания у начальства (любую незначительную проблему выноси на повестку дня на планерке — n-ое правило ватокатства).
Еще одна история из этого же проекта. Алгоритмы, по которым должна функционировать система, разрабатывались в одном ЭнскГИПроКакойтотампромышленности, разрабатывались в виде, так сказать функциональных диаграмм (дикая смесь FBD и LAD), но в отрыве от соответствующих стандартов. Возможно, авторы листали лет 30 назад справочную литературу по Ремиконтам. Ну не суть, в принципах работы создаваемой системы разобраться можно — что контролировать, что, когда и с какими задержками и блокировками включать. На изучение этой документации техотдел потратил 2 месяца, и потом все на пальцах объяснил программистам, описав алгоритмы в текстовом виде, заодно нашел множество нестыковок, косяков и прочего. Но, в ходе общения с Заказчиком, представителями ЭнскГИПроКакойтотампромышленности пришли к заключению, что «проект уже давно утвержден (лет 6 назад как), переделывать его никто не будет, это деньги и время, делайте как есть, на месте разберемся». ОК, раз есть такой приказ, яжпрограммист использует алгоритмы как руководство к действию, пишет программу.
Тут поджидает засада. Проектировщики алгоритма знать не знали о стандартах IEC, о том, какие контроллеры будут использваться, какие там есть билиотечные функции. Напоминаю, что в IEC имеются таймеры, типа TON, TOF, TP. Проектировщики алгоритма предполагали одно поведение таймера, стандарт предполагает другое поведение. Яжпрограммист реализует структуру программы в точном соответствии с алгоритмом (проект же утвержден, что я буду отходить от него?), в итоге программа не работает. ОК, копья ломаются, АЦП шумит, проблема решается не без крови (потребовалось добавить к таймеру дополнительно RS-триггер, но в алгоритмах, хоть и предполагается такое поведение, явно это не указано!).
Поехали дальше, следующая засада. Используются ПЛК двух типов, стандартные, для неответственной системы РСУ, и Safety для системы ПАЗ. Если стандартные контроллеры имеют широкую библиотеку функций, то Safety не дадут вам выстрелить в ногу, даже если очень нужно, поэтому библиотека функций урезана по самое небалуй. Проектировщики алгоритма этих тонкостей учесть не могли, т.к. им все равно, на каком железе это все будет работать. Программист об этом знает, но алгоритмы же утверждены! Итог? Опять неработающая программа.
И все это в условиях вяло текущего дедлайна, со спецификой особо опасного производства, где любое нарушение технологии — катастрофа.
+2
> 1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.

Вообще-то у же на этапе реализации проекта может выпускаться т.н. «Исполнительная документация», которая отражает согласованные с заказчиком изменения проекта, которые были внесены на стадии его реализации. Ну то есть в проекте: «Язык программирования: BASIC, Система хранения: перфокарты», в исполнительной документации: «Язык программирования: Ocaml, Система хранения: Amazon S3» :)
+6
У вас какое-то слишком узкое понятие узости специалиста.
Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.

А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?
0
Угу, у нас именно так. Подобного рода специалисты нам нужны лишь на время стыковки нашей части с тем, что пишут другие организации. Нанимали ненадолго специалиста по SCADA, чуть не наняли доктора наук по PID-регулированию, но справились сами. Насчет найма ненадолго специалиста по машинному обучению — уж думали, может быть и наймем.
+6
Сейчас поискал гуглом определение — вот вылезло:
«A Full-Stack Web Developer is someone who is able to work on both the front-end and back-end portions of an application»

Фулстэк — это тот, кто может работать как над бэкэндом так и над фронтэндом. Просто сейчас масса разработчиков, которые могут только angular, или только мобильные формы лепить, или только сервисы пишут последние 20 лет. Проблема с такими разработчиками, что комманду из таких невозможно нормально нагрузить работой. Всегда кто-то простаивает.
0
Вообще статья несколько шире, она не только о вебе судя по всему.
+5
отладить электрически, запустить SoC, потом RTOS, потом приложение.

Вполне допускаю, что у вас не так, но из моего личного опыта разработчики такого широкого спектра «и железо и программы и жнец и на дуде игрец» пишут такой отвратительный код, что жалко глаза. Наблюдается какой-то поразительный шовинизм вида «мы тут Железку создали, что там какой-то код», из чего следует некоторая узость взглядов в сфере разработки ПО и отвратительный нечитаемый и неподдерживаемый код.
-2
я бы сказал отвратительный безошибочный читабельный и не меняемый годами код. Но общего тут только «отвратительный». :-) Правда коллега — программист, делать железо — это такое хобби-переросток.
+2
Вот в точку. Самый адовый, запутанный и кривой говнокод почему-то встречается именно у микроконтроллерщиков и ПЛКшников, причем часто в проектах для очень серьезных применений. И отговорки везде одинаковые: «тут своя специфика», «работает — не трогай», «доделывали на пусконаладке и нет времени переписать нормально» и подобное.
0
Я полагаю, схемы, сделанные программистами, тоже не без недостатков :) А насчет специфики — даже между специалистами по разным ЯП случается недопонимание. Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
0
Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)
Безусловно. Поэтому я и топлю за четкое разделение обязанностей. Каждый должен заниматься своим делом. Анализом предметной области, технологии процессов, формулированием ТЗ — технолог/аналитик, проектированием схем, разводкой плат, подбором компонентов — инженер-электроник, разработкой архитектуры ПО, написанием кода и тестов — программист. И налаженное взаимодействие между ними. Это, кстати, к вопросу про «фулл-стеков», да :)
Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
Тоже верно. Поэтому я обо всем и рассуждаю немного свысока, как человек, учившийся на специальности «промышленная электроника», большую часть своей карьеры копавшийся с микроконтроллерами, ПЛК и системами автоматики, а потом увлекшийся веб-разработкой и высоконагруженными сервисами :)
0
Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)

Разумеется. Так о том и речь, что универсальная вещь делает всё, но делает всё хуже, чем специализированные по отдельности. Так и со специалистами — к вопросу о fullstack.
Конкретно с «железячниками» не раз сталкивался с отношением к вопросу — см. выше — «мы сделали железку, это 99% успеха, осталось только программку накидать, это фигня, за вечер управимся». Получается так себе. Лучше, конечно, чем если наоборот — написать программу, а потом «за вечер» накидать плату, но тем не менее. Т.е. здесь раз за разом встречаю отношение к программированию, как к игровой области, где нет никаких профессиональных стандартов, неважен опыт и навык, нет технологий разработки и этим может заниматься каждый с улицы. Да, порог вхождения, пожалуй, ниже, чем в «железо», но проблема остается.
+1
Не только бизнес накладывает ограничения, но и рынок труда. Я бы и рад нанять сеньор реакт дева, и одобрение сверху есть, но в моём городе (850к жителей) спецов в поиске просто нету. А переучивать джейэсников из веб-студий времени нет, быстрее самому написать.
+1
Если есть не только одобрение, но еще и деньги, то можно с москвы релокейтнуть
0
Можно попробовать компромисс. Смотрим «в ширину», что есть на рынке. Находим «вкусное», интересное, перспективное и изучаем именно это вглубь. После нескольких лет повторяем. Правда, простым это кажется только на словах.
+2
А в 40+ проводить итерацию «Находим «вкусное», интересное, перспективное и изучаем именно это вглубь» становится уже ни разу не интересно. Молодёжь всё равно сделает это лучше.
+3
Да вот не всегда, тк покопавшись в очередной «новейшей, перспективнейшей bleeding-edge technology» часто обнаруживаешь там решения, про которые тебе рассказывали седые профессора в универе лет 20 назад, а в литературе так вообще лет 50 описано.

Например, тут вон недавно механический map-reduce на перфокартах пролетал…
+3
Что наводит на мысли нафига тратить на это время. Вот у меня например вызывает умиление как сейчас JSники открывают для себя прописные истины, которые для нас дедов сто лет в обед пройдены. Но вот начинаю сам писать JS по современным понятиям и ощущаю себя джуном, так как требуются некоторые другие навыки, что бы связать всю эту JS лапшу вместе и это вызывает не интерес, а отвращение, так как начинаешь думать нафига терять время на ковыряние с инструментарием, который ещё переживает детский возраст. А молодёжь открывает для себя чудеса типа строгой типизации и подсказок в IDE и писает кипятком. Что нам дедам там делать, мы всё это уже видели.
0
Android-разработчики недавно открыли для себя MVVM, хотя в WPF было это еще очень давно. Технологии развиваются и проходят один и тот же цикл…
+2
не согласен) Судя по конфам седые дяденьки уделывают школьников которые только за бесплатными обедами туда и ходят на раз-два тольно на одном практическом опыте).
А уж багаж знаний творит и вовсе чудеса).
Программиста может погубить только возрастная болезнь мозга, все остальное трудно но преодолимо (даже отстуствие зрения к примеру =) )
+2
да, но будучи фуллстеком вы сможете в каску поднять проект, не программный продукт конечно, но все же…
+4
вместо того что бы рассуждать фулстак или сеньёр, лучше бы накодили, что-то толковое.
+3
Вместо того чтобы рассуждать о том, что автор сделал или не сделал, лучше бы комментарий толковый написали.
+4
Вместо того чтобы комментарии толковые писать про комментарии бестолковые, лучше бы пирожок скушали. С малиной.
+1
МОлодо и зелено, сам был таким, но потом понял, что это всё ерунда… титулы, должности, самобичевание, понты, плюнуть и растереть :) Это пройдёт, наверное.
+16
Правильно — сразу мерить все деньгами и зовите хоть подмастерьем!
+1
Хочу стать долларовым миллионером… чтобы говорить, что не в деньгах счастье…
0
Стою ровно на такой же развилке. Fullstack это самообман, которые не так очевиден пока работаешь в одиночку или в непрофессиональной команде. Но роста тут никакого. Так что путь в что-нибудь вроде Technical Project Manager.
+3
Все верно. Это как RPG, если ты качаешь перса во все одинаково, то ты к концу игры будешь плох во всем. Я года 3 назад тоже схватился за голову, присел и сам себе сказал: «вот чего ты достиг, что ты умеешь?». И пошли ответы. Оказывается достаточно много, ведь 8 лет просто так без опыта не могут быть. А рас получил ответы, то задался вопросом: «что можно изменить или дополнить, что бы больше зарабатывать?». С тех пор по утрам я учусь. Всему. Старые знания я несколько раз переповторял, заново открывал книги, и уже в них находил ошибки. Я сейчас взял курс на руководителя. Это значит я должен знать все, что мне приносит прибыль, на 30% минимум. Что-то больше, что-то меньше. Но управление и маркетинг обязан знать минимум на 4-ку, т.к. там нельзя брать в процентном соотношении. И сейчас целенаправленно иду к этому.
+1

Все хорошо, только учить разные технологии — это не «как в РПГ». Если, конечно, не ставить целью овладение технологией ради технологии (а не ради решения бизнес-задачи).

+20
Быть «сорокалетним синьором одной технологии» — это тоже опасно, тк со временем начинает теряться кругозор (а так же отрастать борода и свитер). Опять же диверсификация важна как в финансах, так и в карьере. К тому же технологии имеют тенденцию наскучивать (мне по крайней мере) и редко кто, как мне кажется, хочет копаться 20 лет в одном и том же. Ну да, за 20 лет можно стать мегаджедаем Джавы или Оракла и затыкать всех за пояс на собесах, но в этом ли цель?
+11
Я fullstack, я могу построить систему от 0 до акта. Когда я вижу системы написанные «частичниками» — у меня волосы дыбом встают, сколько глупого кода, лишнего… То что можно сделать в субд, делается в коде языка софта бэка. Насколько это затратно и по коду и по времени выполнения… что можно эффективно сделать на языке софта бэка — перекладывается на язык клиента… Как минимум в команде должен быть руководитель fullstack, а лучшие — вся команда из fullstack. В такой команде всегда найдутся те, кому нравится больше фронт, кому бэк, кому субд. Но такая команда сможет грамотно организовать распределение задачи на нужную область выполнения.
+26
У вас тут подмена понятий происходит.

Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.

Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.
-2
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Ключевое слово — Нормальный. Но таких ужасающе мало, и к сожалению, я таких не встречал. Хотя в своей «частной» области сеньёры…
+12
Откуда вы такие беретесь? Умные, красивые, дартаньяны, все прям могут и при этом «нормальных» бэкендеров не встречали? Я конечно могу жестко заблуждаться, но что-то мне подсказывает, что если вы не работали с крутыми, умными коллегами и в том числе специалистами в узких областях — то вы врядли настолько офигенные, как вы о себе думаете.
-4
К сожалению — не встречал. Наверное такие есть, не отрицаю, но практика вещь серьёзная… На моей практике людей разбирающихся в субд — мало, зато остальные считают себя спецами и городят функции субд на языке софта системы… — да, в своей области они спецы, но они не понимают, что их труд по реализации функций субд полная фигня… Ладно бы они это признавали и просили о содействии, а то ведь считают себя в этом вопросе истиной в первой инстанции. Придумывают тысячу отговорок, чтоб не использовать возможности субд.
Да и в своей области не всегда красиво выглядят. Есть примеры когда ругают код, а предлагают такое, что добавляет и кучу кода и время выполнения. Как яркий пример использование шаблонизации — да, чисто внешне вроде красиво, как копнёшь… нужно сделать то, сё, пятое, десятое… а в итоге за всем этим скрыто простое построение строки, которое можно сделать просто и наглядно в в несколько строк кода, а не в нескольких файлах. и будет работать а разы быстрее.
0
Можно уточнить, что подразумевается под «простым построением строки», конкатенация?
-2
по большому счёту — конкатенация, только в java это, если в лоб, очень затратная операция, поэтому используется StringBuilder. В любом случае, и серверный рендеринг, и json, и шаблонизация — это построение строки.
+3
Отлично, сегодня вы сделали конкатенацию строки в процедуре а завтра туда мигрирует вся логика. После этого саппорт подобного «солюшена» превращается в муки ада. Я не спорю что иногда лучше посчитать там где данные обитают чем гонять их по сети, но конкатенировать несколько строк возможностями бд это уже выше моего понимания.
0
Вот по каким критериям полная фигня? Эти критерии важны для кого? У этих кого нет более важных критериев?

Если код работает, отвечает функциональным требованиям к системе — он уже не фигня объективно.
0
код может работать 1 мс, а может 1минуту — оба варианта отвечают требованиям.
как правило один код может отличаться от другого на не большое время работы — но таких кусков кода может быть много — в итоге система может либо тормозить, либо быстро работать — выбор за тобой
+2
Выбор не за мной, а за людьми, создающими требования. Если в требованиях «время ответа 100 мс в такой-то конфигурации железа и софта», я выберу технологии, позволяющие написать поддерживаемый код как можно быстрее и надежней без превышения этого предела. И я не буду затягивать время разработки в разы, а стоимость поддержки на порядки ради того, чтобы код работал не 70 мс, а 7.
0
Еще, возможно, что там дело было в плохой организации совместной разработки. Фронтэндеру нужна фича вот прям щас (он фрилансер, про проект целиком даже не в курсе, но пока не доделает свою часть функционала, денег не получит), а бакендер занят своей задачей. Ну, ни вапрос — сам запилю…
0
по этому поводу есть старый вопрос: "… К пуговицам претензии есть?..."
+2
А кто нормального бэкэндера и фронтэндера заинтегрирует? Нормальный интегрендер? А если нормальных бэкэндеров отдел из 20 человек и столько же фронтэндеров (реальный пример из жизни — 2 отдела, один UI другой бэкэнд), то как выкатывать функциональность? Кто для кого является зависимостью? Кто определяет структуры данных? Кто определяет типы сообщений и шаблоны коммуникации? А если бизнес выдал новых требований и все, что написали в требованиях — это куча новых формочек, то что делать с бэкэндерами — увольнять? А если на следующий раз выдали кучу отчетности или биллинг переделывать — увольнять фротэндеров?
+10
> То что можно сделать в субд, делается в коде языка софта бэка.
Порой вполне оправданно. То что в бд делается через 9 джойнов на коде бэка можно сделать простым кодом — намного дешевле и по времени выполнения и по оперативке, даже на не самом быстром яп бэка.
Другой пример — когда для улучшения скорости бэк хранит часть данных базы в своих структурах данных чтобы не бегать в нее за каждым чихом. Очень важно если нам нужно отвечать на запросы не медленнее икс миллисекунд. В этом случае кстати бэк плюсовым.
+12

Есть еще нюанс. Да, на стороне sql многое делается сильно проще и эффективнее (даже, когда надо 9 джойнов, то почему бы не задействовать кеши СУБД с отполированным годами кодом, написанным суровыми системными программистами вместо своих велосипедов, к тому же, можно materialized view или триггеры и поддержание +1 таблицы устроить).
Проблема как правило лежит в другой плоскости. Код бека легко покрыть тестами, он будет в рамках паттернов и ооп, он версионируется без костылей, он не требует миграционных скриптов, его проще переиспользовать. Кроме того, вариант "одна субд с мин нагрузкой + куча стейтлес воркеров" идеально масштабируется. Версии воркеров тоже можно обновлять нода за нодой. Также, если речь идет о лицензионном mssql/oracle, которые лицензиуются за ядра cpu, то может быть дешевле нагрузить 3 ядра на сервис хосте, чем одно на машине с субд;)

-1
Конечно, когда идет разговор о стоимости субд, надо выбирать стоимость/всё прочее. Но это уже административный вопрос, который накладывает ограничения на программиста.
С другой стороны если грамотно построить структуру субд, грамотно написать запросы/хранимки — может и не потребоваться масштабируемость.
+2
Речь о том, что руками написанные запросы и, тем более, хранимки очень сложны в поддержке. И дороги для бизнеса.
0
стоимость запроса/хранимки зависит от умения владеть инструментом, для меня это не имеет значения. для меня важно суммарное быстродействие системы. система работает быстро — заказчик доволен.
+3

Заказчик доволен, когда скорость и приемлемая, и стоимость приемлемая. Суммарная быстродействие системы для него важно, но не критично, пока оно приемлемо.

0
Плюс миграция с условного оракла на условный постгрес в первом случае будет значительно больнее
-3
Глубокое заблуждение, те же 9 джойнов выполнятся намного быстрее, чем код. Есть очень хороший пример в области jsva — Hibernate. Его любители не понимающие в субд. Это такой тормоз, такое количество лишнего кода, огромное потребление памяти. и эта прокладка использует только поверхностные возможности субд. Такие спецы, не зная субд, ытаются реализовать функции субд в своём коде, хотя всё уже реализовано в субд. А их реализация выглядит жалким подобием субд, с добавлением тормозов и ошибок. Такая реализация плохо читаема, плохо сопровождаема…
+2
Про 9 джройнов пример из жизни. Один и тот же набор данных, в двух вариантах — в одном случае 9 джойнов, в другом последовательные вызовы ко всем необходимым таблицам и последующая обработка-склейка данных в коде ( на перле ). Результат с обработкой кодом — улучшение по скорости примерно в 20 раз.
+1
Честно говоря, звучит как рассказ про встречу с единорогами.

Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным. Именно поэтому в т.н. BigData описание вычисления присылают в хранилище данных, а не данные из хранилища присылают исполнителю вычисления.

Разве что в описанном случае запрос вышел очень неоптимальный, но при этом с крайне низкой кардинальностью по данным в итоге. Тогда да, обработка в лоб действительно может быть быстрее. С другой стороны, уверен, что перестроенный и оптимизированный запрос всё равно выиграет.
0
Хм, запрос время от времени писал в лог, что ему не хватило оперативки на выполнение и фэйлился. План не изучал.
+2
Так может традиционная ситуация что индексы забыли и бд поехала вычитывать все таблицы полностью?
0
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным.

Это больше на демагогический постулат походит. Ну или на "кодерско-оптимизаторский" (хотя не факт, что на практике будет быстрее, если СУБД у нас толком не масштабируется, а апп-серверы сотнями можно поднимать). Инженерный подход подразумевает не только техническое, но и экономическое обоснование.

+1
Никакая не демагогия, вот отсюда беру, обратите внимание на пункт “Moving Computation is Cheaper than Moving Data”:
hadoop.apache.org/docs/r1.2.1/hdfs_design.html

Уж поверьте, как кодер я был бы только рад унести логику обработки данных из «холодной, безразличной» и требующей многословных запросов базы данных (где, например, попытки переиспользовать код обычно натыкаются на ощутимые тормоза ввиду переключения контекстов между SQL и PL) в уютный для меня любимый язык программирования. Но сетевой доступ к хранилищу не может происходить по путям бесконечной ёмкости, а значит, чем больше работы я сделал вдали от данных, тем больше данных было передано по сети. А это вещь ненадёжная и медленная.

Я не исключаю что в каких-то системах такой подход может не работать и сервер базы загружен на 98%, но с другой стороны, если мы можем поднять сотню аппсерверов (для чего, кстати? вручную делать join'ы и закат солнца до кучи?), то почему мы не можем поднять «клон» для чтения, к примеру? Или поделить данные между несколькими базами, для начала, а склеивать уже результат от полученный от одинакового запроса к разным базам?
+1
Никакая не демагогия, вот отсюда беру, обратите внимание на пункт “Moving Computation is Cheaper than Moving Data”:

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


Пример: рендер изображения в сетевой игре происходит на клиенте, а не на сервере

0
> Пример: рендер изображения в сетевой игре происходит на клиенте, а не на сервере

Плохой пример: если изображение это данные, то их совершенно правильно не передают с сервера, вместо этого клиенту передаётся описание вычислений, необходимых для получения правильных данных (поток событий в матче).
С другой стороны, в ММО, опять, же не передают все данные из базы на клиента, дабы клиент сам определился, какие из них ему действительно нужны и сделал необходимые вычисления. Переводя на язык СУБД, в таком случае вся фильтрация и join'ы произведены на сервере (в базе данных), клиенту приходит только проекция. Когда такая схема нарушается по любой причине, появляется возможность сжульничать — например, убрать «туман войны» в стратегии (применимо только для стратегий с сервером-арбитром правда, обойтись без дупликатов данных в P2P играх, насколько я знаю, пока не получалось ни у кого).
0
Что интересно, хотя в заглавии пункта «Cheaper», в самом пункте «much more efficient… when the size of the data set is huge». Может поэтому в кавычках? О технической оптимизации, о скорости, я уже говорил, но бизнесу нужны экономические обоснования. А ваше «был бы только рад» намекает на то, что отсутствие радости на работе нужно чем-то компенсировать, обычно деньгами :)
0

Так мы вроде и обсуждаем здесь случай, когда данных много? Иначе зачем для их хранения нужна база данных? Малые объёмы можно держать и в оперативной памяти где-нибудь.


А ваше «был бы только рад» намекает на то

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

0
Huge — это обычно не про много, а про «немеренно». И часто ресурсы приложению выделяется столько, чтобы вся база в оперативке помещалась, если их немного, или много, но не сильно — гигабайты. Просто с экономической точки зрения обычно в сторонней СУБД хранить выгодней. Не эффективней по вычресурсам, а выгодней весь цикл жизни приложения.
0
Этот постулат верен только когда идет работа с большими или «средними» данными. Для мелких данных (порядка сотни записей) могут проявляться обратные эффекты.

0
Согласен. С другой стороны, мелкие данные можно выгрузить в память один-единственный раз (если они иногда меняются, то писать обратно после изменения чем-нибудь неблокирующим) и потом работать с ними без запросов вообще. Это налагает свои ограничения, разумеется (например, все операции придётся писать императивно, если нет желания ставить SQL-совместимую in-memory-DB), но подход проверенный и работающий.
В исходной формулировке с уточнениями, правда, выходит, что запрос «хавал» очень много ресурсов сервера БД, а малое количество данных так не делает.
0
Это типичная ситуация когда в тяжелом запросе есть джойны с кучкой мелких справочников. В таком случае отдельная загрузка этих самых справочников способна в некоторых ситуациях запрос ускорить. Но еще большее ускорение, конечно же, достигается кешированием — тут я согласен (сам три недели назад такой кеш делал).

Кстати, в C# запросы к данным в памяти и к данным в БД могут строиться одинаково и декларативно (см. linq).
0
Мелкие справочники можно грузить только если они не часть предиката. Если они появляются в предикате — никакой особой разницы не будет, их всё равно придётся подключать. Опять же, всегда был под впечатлением, что для join с малой кардинальностью сама база вполне в состоянии сложить у себя в памяти hashTable из значений, и прирост тогда будет только для нескольких конкурирующих запросов с одного и того же сервера, а иначе расходом памяти и процессора на такой join с таблицей можно пренебречь на фоне основного запроса.

Кстати, в порядке просвещения меня: может ли LINQ сделать такую отдельную загрузку для малых таблиц и потом использовать эти таблицы в проекциях без настоящего join'a на стороне БД? Хотя бы в теории?
0

Даже если они часть предиката, все равно варианты "подключить, проверить и забыть" и "подключить, проверить и запомнить" дают разные требования к памяти. Пренебречь им нельзя, потому что это целый дополнительный столбец в результатах запроса.


Кстати, в порядке просвещения меня: может ли LINQ сделать такую отдельную загрузку для малых таблиц и потом использовать эти таблицы в проекциях без настоящего join'a на стороне БД? Хотя бы в теории?

LINQ такого не может, ибо это всего лишь язык запросов. А вот Entity Framework нечто подобное умеет, если пару хелперов написать. Вот изменения трехнедельной давности (полсекунды выиграл, однако):


Картинка

public static void AttachFromCache<T>(
        this DbContext ctx,
        IEntityCacheService cache
    ) where T : class
{
    var set = ctx.Set<T>();
    foreach (var item in cache.GetAllItems<T>())
    {
        set.Attach(item);
    }
}
0
Пренебречь им нельзя

Ну почему так категорично. Предикация и проекция — две операции, которые не так чтобы близко были связаны между собой. Для малых кардинальностей, логически, есть возможность оптимизировать запрос так, чтобы этот столбец был "Ленивым" и вычислялся вообще прямо перед "Show" каждой строки (в последний момент), что будет ценно как раз при ограничении по памяти, т.к. позволяет при вообще не хранить в столбце значения — только "рецепт" и кеш-таблицу. Оптимизация менее применима при наличии сортировки по такому столбцу, но не снимается полностью даже в этом случае.


Про LINQ: Там в картинке явно указывается в тексте запроса, что, что некие сущности следует брать из кеша.
Не то чтоб это было плохо само по себе, но требует телодвижений в каждом use-site. Впрочем, принципиальную возможность это уже доказывает, следовательно, где-то должен быть способ то же самое делать более централизованно. Благодарю за просвещение.

0
Это типичная ситуация когда в тяжелом запросе есть джойны с кучкой мелких справочников.
такие справочники кэшируются в субд и подключаются результирующему select в самом конце. и нет никакой необходимости их загружать в код. Правильное написание селекта только и всего.
0
Во-первых, кеш на стороне кода не хуже вашего решения, к тому же экономит еще и пропускную способность сети. Во-вторых, иногда проще написать этот самый кеш чем правильно переписывать select.
0
правильно составленный запрос возвращает только нужные данные. Этим самым и происходит экономия пропускной способности сети.
Вот и есть ответ на все претензии к работе с базой — прогер не может правильно записать/переписать select. Происходит попытка заменить возможности субд своим кодом, который явно не может быть лучше чем код обрабатывающий запрос в субд.
0
То, что запрос возвращает только нужные данные, еще не означает что они не дублируются.

Что займет меньше места: 100 записей вида «число+строка» и 10000 чисел — или 10000 записей вида «число+строка»?
-1
То, что запрос возвращает только нужные данные, еще не означает что они не дублируются.
Странное утверждение — если требуется — будут и дубли, не требуется — дубли убираются — в селекте за это отвечает 1 слово.
А меньше займу место правильно выбранные данные. Зачем отправлять 10000 чисел? когда можно сформировать запрос, чтоб он вернул 100…
0
Затем, что запрос должен возвращать и возвращает 10000 строк. Два столбца при этом дублируются, потому что взяты из справочника на 100 строк. «Одно слово» тут никак не поможет, потому что остальные столбцы — не дублируются! Что еще тут не понятно?
-2
Вот тут и скрыто ваше не понимание работы субд — то, что вы называете дублированием — на самом деле не является дублированием, если вы из справочника подставляете текстовое значение, это не означает дублирование записи, это только то, что некоторые поля имеют одинаковое значение, да, вы можете не возвращать это текстовое значение, но вы должны вернуть id этого значения, чтоб потом вывести юзеру не id а само наименование, а эти id также будут «дублироваться», если следовать вашему утверждению.
У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти? чтоб вывести накладную из 20 позиций…
Да вы можете сэкономить(только что сэкономить?) и держать в памяти этот справочник, и при формировании чего-либо для отправки клиенту подставить из мапы/листа/хэша, но это ни есть экономия ни памяти, ни времени работы. При подстановке нужны множественные обращения к этому хранилищу справочника, это код, это время…
и Ещё вопрос Запрос возвращающий 10 000 записей — это не правильно поставленная задача, соответственно и решение не верное. Если вы хотите отправить все 10 000 клиенту и чтоб он их сортировал, фильтровал — если вы так делаете…
+1
это не означает дублирование записи, это только то, что некоторые поля имеют одинаковое значение

Один фиг если не пересылать по сети одинаковые значения — будет сэкономлена пропускная способность. Или вы и в это не верите?


но вы должны вернуть id этого значения, чтоб потом вывести юзеру не id а само наименование, а эти id также будут «дублироваться», если следовать вашему утверждению

id занимает намного меньше байт


У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти?

Я выше уже писал, что для разных объемов данных оптимальные решения — различные. У нас тот справочник о котором идет речь содержит меньше сотни записей и никогда не будет сильно расти.


Да вы можете сэкономить(только что сэкономить?) и держать в памяти этот справочник, и при формировании чего-либо для отправки клиенту подставить из мапы/листа/хэша, но это ни есть экономия ни памяти, ни времени работы. При подстановке нужны множественные обращения к этому хранилищу справочника, это код, это время…

Ну, вообще-то, у меня почему-то экономится и память, и время работы. Возможно, вы просто не умеете писать код.


и Ещё вопрос Запрос возвращающий 10 000 записей — это не правильно поставленная задача, соответственно и решение не верное. Если вы хотите отправить все 10 000 клиенту и чтоб он их сортировал, фильтровал — если вы так делаете…

Если дофига задач где требуются большие выборки. Как пример — экспорт данных или ETL. Если вы не только ни разу с ними не сталкивались, но и представить себе их не можете — вы не такой опытный админ СУБД как пытаетесь показаться.

-1
Один фиг если не пересылать по сети одинаковые значения — будет сэкономлена пропускная способность. Или вы и в это не верите?
пропускная способность гигабитной локальной сети?
Ну, вообще-то, у меня почему-то экономится и память, и время работы. Возможно, вы просто не умеете писать код.
а у меня просто нет необходимости экономить — просто не требуется память.
Если дофига задач где требуются большие выборки. Как пример — экспорт данных или ETL. Если вы не только ни разу с ними не сталкивались, но и представить себе их не можете — вы не такой опытный админ СУБД как пытаетесь показаться.
Согласен, но ваши же слова Я выше уже писал, что для разных объемов данных оптимальные решения — различные.
У нас тот справочник о котором идет речь содержит меньше сотни записей и никогда не будет сильно расти.
но подставляя эти значения в коде — вы увеличиваете код. Мелочь, но я просто использую поле, которое мне вернула база — И нету даже этой мелочи, что вас.
та же субд может сделать ETL в нужном формате прямо в файл(при необходимости) или из результсета сразу выгружать по месту и для этого в 99% случаев нет необходимости доп обработки данных. Mssql может даже транспонировать данные… Даже если данных будет 1 000 000 нет необходимости выгружать их в память — субд организует правильную отправку результатов в код.
+1
У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти?

Хранить 100 000 наименований (или даже 1000 000 наименований) в памяти намного эффективнее, чем каждый раз СУБД дергать.

-3
Вот это большая ошибка, разработчиков с малым опытом работы с базой. При правильной настройке субд все нужное кэширует, но для поиска и выборк работает намного эффективнее, чем код прогера использующего результаты вынутые из базы. Хранение с памяти софта — это попытка продублировать работу базы, но база заточена намного больше под обработку данных, чем код прогера. стоимость дерганья намного меньше чем стоимость хранения в коде. база для этого и предназначена, чтоб её дергали.
+2
Вот это большая ошибка админов СУБД с малым опытом разработки. Сетевое взаимодействие с базой никогда не будет быстрее прямого обращения к оперативной памяти.
0
При правильной настройке субд все нужное кэширует

Если субд что-то закешировало, то вам все равно придется делать запрос, а это обычно использование сети, а использование сети — очень затратная операция. Если ваши данные просто лежат в памяти, то к базе вообще не надо обращаться.


Кроме того, универсальный кеш субд заведомо менее эффективен чем конкретный кеш на клиенте.

-1
Druu, mayorovp

Сетевое взаимодействие с базой никогда не будет быстрее прямого обращения к оперативной памяти.
с одной стороны да, но с другой субд специально заточена на обработку данных, с использованием кэша, индексов и прочего. и ваша попытка эмулировать работу базы очень проигрывает.
база ищет по индексам — для этого у неё есть специальные таблицы, специальные механизмы, алгоритмы. в вашем же распоряжении мапы/хеши, они явно уступают методам баз.
использование сети — очень затратная операция.
это было актуально в начале 90-х когда сеть была на BNCконнекторах, сейчас уже оптикой никого не удивишь даже в квартиру. у нас предлагают 500мбит во внешний инет, а уж в нормальных конторах локальный трафик есть 10Гбит.
Была статья про .stackoverflow.com как у них всё устроено — куча серверов, и ни одного упоминания про сетевые затраты.
и ещё есть много систем с хорошей памятью и достаточным количеством ядер — и все в одном места и приложение и субд — так вот там нет никаких затрат на сеть все через память.
Если ваши данные просто лежат в памяти, то к базе вообще не надо обращаться.
смотря для каких целей. таблицы могут быть по 10+ гиг и вы всё это будете держать в памяти? Ещё раз — даже если у вас нет ограничения на память, то вы все равно не сможете конкурировать с по работе с данными ни с какой субд.
у любого приложения есть драйвер, который поддерживает пул соединений с базой, и любое обращение к базе стоит очень дешево.
Кроме того, универсальный кеш субд заведомо менее эффективен чем конкретный кеш на клиенте.
кэш в базе не просто таблица, а также индексы, и поиск данных идет с помощью индексов(при правильной организации данных, их индексирования, правильного составления запроса)
если следовать вашим рекомендациям — для ускорения надо однажды из файла прочитать в память и работать с памятью, и никаких таблиц не надо, и всех разработчиков баз разогнать.
0
ashumkin
я читал про систему, что для выключения которой требовалось 8 часов — всё шло на сохранения на диски…
mayorovp
Вынужден вас расстроить, но все эти «специальные механизмы» БД проигрывают обычной хеш-таблице в памяти.
так тогда давайте исключим все субд как тормоз и всё будет летать. и само понятие субд запретим…
+1
так тогда давайте исключим все субд как тормоз и всё будет летать. и само понятие субд запретим…

… и это будет даже правильным решением! При условии что данные неизменяемые и помещаются в оперативную память.

-1
если вы замените все таблицы на хэши в памяти — думаете что у вас получится сделать нужный выбор быстрее чем селект в субд? Вы в этом уверены? Вопрос: почему тогда разработчики субд не используют такое? Они глупее вас? Даже для сохранения в памяти они использую таблицы, полностью расположенные в памяти, именно таблицы, а не ваши хэши/мапы
+2
Да, уверен. Разработчики СУБД не используют такой способ по трем причинам:

1. СУБД — универсальное решение, применяемое для данных, которые, в общем случае, в оперативную память не влезают;

2. СУБД рассчитаны на длительное и надежное хранение данных, да еще и ACID вынь да полож;

3. разработчики СУБД предполагают, что их решением будут пользоваться тогда, когда простые способы уже не помогают.
0
Вопрос: почему тогда разработчики субд не используют такое?

индексы как-бы примерно таким образом и работают.


Даже для сохранения в памяти они использую таблицы

Что удивительного в том что реляционная база использует реляции а не что-то другое? В целом нет никакой проблемы хранить данные в jsonb с ключем, будет та же хэшмэпа. Но только если вам прям в памяти нужно дешевле будет redis использовать. Он опять же может только ключи в памяти хранить, если вдруг у вас все в память не помещается.

0
Разработчики СУБД (точнее SQL РСУБД) скорее всего не считают, что операции выборки полной записи из одной таблицы по ключу или выборки всех записей должны быть оптимизированы в ущерб всему остальному.

А ещё разработчики SQL РСУБД активно используют хэш-индексы, которые при полной загрузки в память и индекса и таблицы, как думаете чем являются?
+3

Вынужден вас расстроить, но все эти "специальные механизмы" БД проигрывают обычной хеш-таблице в памяти.


а уж в нормальных конторах локальный трафик есть 10Гбит

Сетевые задержки измеряются в милисекундах, а не в гигабитах


и ещё есть много систем с хорошей памятью и достаточным количеством ядер — и все в одном места и приложение и субд

Прощай, масштабируемость!

+1
> в вашем же распоряжении мапы/хеши, они явно уступают методам баз.

Что за механизмы в базе, что уступают получению указателя из хеш-таблицы в памяти процесса?
-3
Судя по вопросу вам плохо преподавали работу субд…
как минимум наличие всевозможных индексов
+2
Судя по вопросу вам плохо преподавали работу субд, иначе бы вы знали, что хеш-таблица — быстрейший из возможных индексов (но сильно ограниченный в применимости).
+1
это было актуально в начале 90-х когда сеть была на BNCконнекторах, сейчас уже оптикой никого не удивишь даже в квартиру

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


смотря для каких целей. таблицы могут быть по 10+ гиг и вы всё это будете держать в памяти?

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


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

Именно по-этому кеш бд и является настолько неэффективным.

-1
Именно по-этому кеш бд и является настолько неэффективным.
ты об это разрабам mssql, mysql, oracle скажи, научи уму-разуму, а то пишут всякую фигню, обманывают народ…
А ты хоть знаешь для чего индексы нужны?
Какая разница оптика или не оптика? Сама отправка запроса по сети уже работает дольше, чем запрос к кешу в памяти
Сама жизнь яяляется признаком смерти…
Естественно, речь идет о случаях, когда вы можете себе позволить держать все в памяти.
гы-гы-гы
когда твоя «база» — один хэш и все — это твоя область деятельности?
0
ты об это разрабам mssql, mysql, oracle скажи, научи уму-разуму, а то пишут всякую фигню, обманывают народ…

Они-то в курсе обо всем, им ничего говорить не требуется.

0
Простите, но вы боретесь с ветряной мельницей и отвечаете невпопад. При чем тут индексы БД, если речь идет о том, что выборка из ОЗУ быстрее, чем передача данных по сети ПЛЮС выборка из кеша-ОЗУ сервера БД?
гы-гы-гы
когда твоя «база» — один хэш и все — это твоя область деятельности?

Ну, какбэ выше и обсуждалось, что в таких случаях, когда (… оговорки… и можно делать выборку из памяти) то быстрее не общаться с сервером БД. Вы влетели со своими «разоблачениями» без учета оговорок.
0
у вас в локальной памяти вся база? даже если вы скопируете себе в память все таблицы — со своей выборкой вы не опередите работу базы со всеми сопутствующими ей затратами. и приплетать свои оговорки — это просто не профессионально.
Выборка из памяти — это не работа сданными.
если вы посмотрите планы выполнения запроса — то увидите, на что влияют индексы и во сколько раз они сокращают выборку данных.
+2
и приплетать свои оговорки — это просто не профессионально.

Непрофессионально — не исходить из заданных критериев, чем вы и занялись.
если вы посмотрите планы выполнения запроса — то увидите, на что влияют индексы и во сколько раз они сокращают выборку данных.

Вы опять не учитываете указанные оговорки и спорите сам с собой о чем-то своем. Удачи.
+3
со своей выборкой вы не опередите работу базы со всеми сопутствующими ей затратами.

Конечно же, опередит. Он получит результат еще до того, как ваш запрос до базы дойдет.

-2

А чего этот план изучать?


Нет, серьёзно. У меня есть опыт, когда очевидно эквивалентные запросы (таблица с полями uid и object_id, дан :object_id, нужно найти первый uid по убыванию, для которого нет записи (uid, :object_id)) с практически синтаксическим изменением вложенного подзапроса выполнялись 4 секунд и одну миллисекунду соответственно. Один план делал фуллскан, другой прибегал к индексам. Я не DBA и едва сам этот запрос написал, но вот то, что я не могу рассчитывать, что после обновления БД или какого-нибудь ANALYZE что-нибудь не отвалится и не начнёт снова делать фуллсканы, меня очень печалит, и делать все нужные джойны в коде выглядит надёжнее.

0

План запроса еще и от статистики в бд поменяться может, так что там вообще все недетерменировано, в новолуние — так, при убывающей луне — эдак :)

+1
Тем интереснее, как апологеты обработки данных на стороне БД предлагают с этим всем счастьем бороться.

Это, наверное, один из немногих случаев, когда меня печалит проявление несогласия, ибо оно не сопровождается конструктивной дискуссией :(
+7
Hibernate и прочие ORM сделаны как раз чтобы улучшить читаемость и сопровождаемость кода, обычного ООП-кода. И использование ORM вовсе не значит «неумение в субд», может быть просто принято решение не использовать всю мощь конкретной СУБД, ради увеличения скорости разработки, улучшения читаемости и сопровождаемости. А если где-то вылезет нарушение нефункциональных требований по производительности, то отпрофилируют и перепишут точечно на SQL и ко критически важные части.
-2
конечно, против административного решения не попрёшь, но цена такого решения — очень огромна. О читаемости и сопровождаемости хибера — вопрос спорный, потому как для него надо много классов/файлов для простого изменения. И опять таки для меня нет проблемы прочитать и понять запрос/хранимку. За неиспользованием все мощи субд придется заплатить масштабированием, приобретением нового, дорогого железа. Конечно это всё можно обосновать красивыми словами, но с точки зрения кода это глупо.
0

Я не об административном, когда решил заказчик или начальник. Собрались разработчики и решили, что c ОРМ проект быстрее запустится и проще его будет поддерживать и развивать. Ну или единственный разработчик, который хоть знает об альтернативах так решил :) А за использование всей мощи СУБД придётся заплатить усложнением поддержки, замедлением (ну или удорожанием) разработки, усложнением развёртывания. Конечно это всё можно обосновать красивыми словами, но с точки зрения кода (а не его эффективности) это глупо :)

+2
За неиспользованием все мощи субд придется заплатить масштабированием

Можети привести пример как вы платите масштабированием за хабирнейт? Хабернейт это всего лишь дополнительная нашлепка, которая помогает замапить данные в объекты. Т.е. если у вас бэкэнд на жаве, с большой вероятностью вам и так придется это делать, а с хабернейтом код просто будет чище.
потому как для него надо много классов/файлов для простого изменения

Ну как бы нет, если у вас много кассов/файлов в изменении, то значит это уже не простое изменение. Т.е. опять если вы мапите результат квери в жава объекты без хабернейта, то изменения в базе спровоцируют изменения в коде, причем изменения как в коде мапинга так и в объектах, а с использованием хабернейта только в объектах.
P.S.
Понятное дело, что за использование универсальной библиотеки вы всегда немного платите производительностью, но если на этом зацикливаться так можно и на с++ все писать. Когда я только начинал с хабернейтом, я тоже от него плевался по началу. Но после того как я в нем разобрался он оказался не так уж и плох.
0
ORM сияет обычно при записи, потому что не нужно думать, какие сущности сохранять первыми, какие вторыми и так далее. Очень сильно помогает если в схеме присутствуют циклические связи.

Для запросов и их результатов ORM подходит куда меньше, хотя бы потому, что не позволит просто так пойти и высчитать среднее, бегущую сумму или какой-нибудь изврат с оконными функциями — а это обычно самые интересные данные с точки зрения заказчика.
+1
Хм… Кто вам запрещает строить запросы используя поддерживаемые ORM аггрегатные функции?
И с чтением/записью как раз все наоборот. ORM здорово тормозит на операциях bulk import, и редко умеет делать partial write объектов. Еще проблема в том, что persistent manager перед тем как сформировать update-запрос должен понят, какие именно объекты изменились, а это при большом их количестве занимает много времени даже в RAM.
А вот как раз с чтением данных проблем как раз никаких. Потому, что запросы на чтение вы формируете сами и такие, какие считаете нужными. На этом этапе фактически работает только DBAL. А уж субстантизация полученных результатов запроса тоже зависит только от того, что вы понаписали в конструкторы и какие навешали на ваши объектв ORM-хуки. Собственно забота ORM — это сделать new, да заполнить свойства объекта.

Что же до курсоров и бегущих сумм, то это уже вообще говоря за рамками реляционной модели. Стоит ли такие вещи класть в СУБД? Не знаю… Может оказаться, что вам нужна сумма по страницам, а размер страницы зависит вообще говоря от устройства вывода.
Если у вас на все ВЦ одно АЦПУ, тогда почему бы и нет. А если у вас размер страницы зависит от размера окна браузера пользователя, то наверно это будет несколько затруднительно.
Вообще гуру учат отделять представление от модели, но может быть вы не верите во все это новомодные (для 1970-х годов) штучки…
0
> ORM здорово тормозит на операциях bulk import

bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.

В целом ORM нужны там где у вас OLTP (OnLine Transaction Processing). То есть берем чуть-чуть данных (агрегат, границы бизнес транзакции, DDD), делаем с ними что-то и записываем.

Чтение и т.д. — для этого проще делать отдельно выборки через SQL. Тут не только с точки зрения производительности сколько с той точки зрения, что модели данных для чтения и записи нужны обычно разные.

Собственно вы сами в конце про разделение представлений говорите.
0
bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.

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


Неконсистентность помянута потому, что в случае неконсистентных данных приходится применять всякие нечеткие критерии поиска, которые часто базируются на заведомо консистентных данных уже находящихся в БД. И это одно из самых нелюбимых мной мест в коде. Пререписывать все это на SQL… Боже упаси!

0
> У меня информация от контрагентов…

Сейчас бы по одному кейсу статистику по индустрии проэцировать. Импорт данных может быть, но чаще всего это импорт части данных а не всех. Да, есть исключения, как и проекты где вообще нет bulk import.
0
ORM скорее сделаны для того чтобы объектную модель натянуть на реляционную, при некотором сходстве двух моделей они всё же разные, так получилось, что реляционные БД намного более популярны чем объектные, а в языках программирования у нас объектная модель.
0
База данных не всегда одна на приложение, может быть микс из sql и какой-то монги для метрик.
+2
Использование ORM — это прежде всего избегание vendor lock. От СУБД в этом случае требуется только стандартный SQL, без всяких «фирменных» дополнений. И менять их (СУБД) можно практически на ходу.
Плюс хранимые процедуры и особенно триггеры усложняют такие вещи, как версионирование и развертывание. Плюс требуют от разработчика дополнительных компетенций, что автоматически сужает количество кандидатов и увеличивает их зарплату.
Я думаю, что с точки зрения бизнеса такое оправдано только как последнее средство в каких-то весьма высоконагруженных приложениях.
+3
прежде всего избегание vendor lock

то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).


Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры. При этом у вас может быть тотальная завязка на нюансы конкретной СУБД. Дальше все больше про разделение ответственности (изменения персистенса не должны влиять на бизнес логику, но думать что при смене СУБД вам код не придется писать — глупо).


как версионирование и развертывание.

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


Плюс требуют от разработчика дополнительных компетенций

Если подумать то объем знаний необходимых для работы с каким-нибудь nhibernate сопоставим с объемом знаний для работы с процедурами. Да, это сильно разный опыт, и стоит ориентироваться на рынок труда (а он такой что я ни тот ни другой вариант бы не доверил большинству)


в каких-то весьма высоконагруженных приложениях.

Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д. Производительность — сомнительный довод. Да и процедуры будут ограничивать вас по горизонтали (хотя кто его знает).


p.s. Если что — принципиально не использую процедуры/тригеры для бизнес логики и пока не встречался с юзкейсами где это все дает очевидные преимущества. Но полагаю такие кейсы есть. Не подумайте что я там фанат таких вещей.

+1
> то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).

ORM — это все же библиотека. Она — часть разрабатываемого вами продукта. Вряд ли заказчик будет самомстоятельно пересобирать ваш продукт. СУБД — это тоже часть проекта, но это внешний компонент, и нет причин, кроме тех, что я упоминал к нему привязываться. Vendor Lock — не абсолютное зло, но все же зло. И причины, которые его оправдывают должны быть достаточно серьезными.

> Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры.

Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.

> потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода

Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API. Я не слишком глубоко знаю SQL, но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.

> Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д.

А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.

> Но полагаю такие кейсы есть.

Да есть конечно. Тысячи их. Тот же Highload, когда приходится вылизывать планы исполнения запросов и играться с тонкими настройками СУБД. Или когда это голый CRUD.

Вообще, для меня использование хранимых процедур для бизнес-логики это примерно как ассемблерные вставки в высокоуровневом языке. Можно, но если других способов нет.
0
но это внешний компонент

Почему? Можно ли воспринимать скажем версию JVM как "внешний компонент"?


У меня вещи типа база данных это внутренний компонент. Я поставляю код как готовую инфраструктуру (предположим через докер). И я регламентирую что нужно для того что бы код работал.


У меня был один кейс когда мне была выгодна смена субд прозрачная — у заказчика был тот самый вендор лок на оракл, и ничего другого они юзать не могли. И выяснилось это через 3 недели посте старта проекта. Но там и проект примитивный.


Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.


Вы же не переживаете что выбрав определенный язык программирования вы как бы тоже создали себе вендор лок?


Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.

Тогда было бы не O/RM (Object-relational mapping) а Object-Relation Abstraction какой. Задача ORM — исключительно мэппинг одного в другое. И при том что две эти модели данных (основанная на реляциях и ваши in memory структуры) сильно различаются, то и мэппинг мы можем сделать в ограниченном наборе сценариев (всему виной такая вещи как референсы, которые выражены сильно по разному)


Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API

это как UI, попробуйте такое с бизнес логикой провернуть. И не важно будет в тригерах она или в коде. Ну либо ваши две версии воркеров должны реализовывать совместимость на уровне бизнес процессов. Что как бы… можно провернуть и с тригерами.


но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.

Я не вижу необходимости в этом. Но вообще зависит от вашей СУБД. В PostgreSQL подобное можно хитро замутить со схемами.


А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.

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


Такое можно и с кодом провернуть (здрасте микросервисы).


Тот же Highload

Я уже упоминал тут что в хайлоад врядли тригеры и процедуры хорошо ложатся ибо вы ограничиваете себя скейлингом по вертикали. Горизонтальный уже сложнее.

0
Можно ли воспринимать скажем версию JVM как "внешний компонент"?

Почему нет? Можно и ОС, и веб-сервер рассматирвать как внешний компонет, и все остальное. Чем меньше зафиксированных зависимостей пришлось затащить в проект — тем лучше.


Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.

Не увидел серьезных обоснований. Вы просто на писали как вы привыкли делаеть это. Попробуте делать по-другому. Я уверен, у вас все получится.


всему виной такая вещи как референсы, которые выражены сильно по разному

Выражены по разному, но смысл у них одинаковый — сама природа реляционных отношений.


это как UI, попробуйте такое с бизнес логикой провернуть.

Воркеры это про UI? С чего бы вдруг? Хотя что считать UI? Если у меня воркеры e-mail формируют, и я шаблон поменял. И для нового шаблона требуются данные, которые не нужны были для старого. Что мешает работать и тем и другим параллельно? Или e-mail — это тоже UI?
Или если у меня с определенного месяца алгоритм расчета комиссий поменялся. Что мне мешает запустить комплект новых воркеров, которые будут это делать для нового месяца и параллелльно использовать старые, для предыдущих месяцев?


можно хитро замутить со схемами.

Можно. Но зачем? Ради суперзадачи "использовать триггеры во что бы то ни стало?"


Это больше про загоны с отслеживанием изменений.

Вот как раз тут через ORM все чудесно решается. Через Entity lifecycle events. Или вы полагаете, что "триггеры" бывают только в СУБД? Кстати, довольно "дешево" реализуется, т.к. отслеживание изменений в ORM обычно из коробки. и сторонние сервисы подцепляются легко. Я в последнем проекте просто кидал сообщение в менеджер очередей: "Пользователь IvanovAA поменял зарплату сотруднику Иванов А.А.". А там его уже логировали, кому следует на проверку отправляли и "завертелась карусель". Кстати, вопрос… в PostgreSQL в триггкре доступна информация о пользователе, выполнившем транзакцию, и можно ли к каким-то внешним службам обратиться, типа RabbitMQ или Redis? И желательно асинхронно, дабы не тормозить процесс.


Я уже упоминал тут что в хайлоад врядли тригеры и процедуры хорошо ложатся ибо вы ограничиваете себя скейлингом по вертикали. Горизонтальный уже сложнее.

Тут не стану с вами спорить, ибо не специалист по триггерам и процедурам. Но они что, правда не работают в кластерах и при шардинге?

0

На всякий случай повторю, а то может быть вы не заметили — я НЕ использую тригеры и процедуры для бизнес логики и категорически против этого на своих проектах. Опять же я категорически против так же называть ORM "решением всех проблем", есть и другие способы дела делать.


Чем меньше зафиксированных зависимостей пришлось затащить в проект — тем лучше.

Меня не покидает ощущение что мы говорим о разных вещах. Что бы небыло недопонимания, давайте так.


Вы согласны что зависимость все равно есть? А это значит что мы не можем просто поставить "другую субд" и все будет гарантировано работать, то есть может потребоваться дополнительная работа.


Ну или расскажите про свои проекты. Ибо я не могу вспомнить ни одного проекта где мы гарантировали бы стабильность работы софта при смене скажем postgres на mysql.


У вас вообще нет контроля за окружением? Коробочные решения? Десктоп? Просто это довольно важно понимать, ибо задачи могут быть чуть другие.


Я просто не очень верю в волшебное "зависимости есть но я могу махнуть палочкой и вжух уже имплементация другая". То есть да, изолировать зависимость — понимаю и согласен. Но ORM — это не про "устранение зависимости от конкретной базы", это не ее первоочередная задача. Абстракцию вы уже сами делаете (шаблон Repository например).


Что мешает работать и тем и другим параллельно?

ничего, просто два процесса. И да — формирование email-а это представление. Независимый процесс. Запускайте сколько хотите. А вот если ваш "коркер" бизнес процессы будет разруливать, то вам уже важно что бы бизнес процессы реализованные в версии 1 и версии 2 были совместимы.


Что мне мешает запустить комплект новых воркеров

А что мешает добавить код в имеющийся воркер что бы тот сам стал считать в нужный момент по другому? У вас же по любому будет какой-то код который будет принимать решение какому из воркеров трудиться когда. Или вы руками планируете переключать?


Ради суперзадачи "использовать триггеры во что бы то ни стало?"

Нет, просто я не очень понимаю зачем может понадобиться две версии одного тригера одновременно выкатывать. Два тригера. Или две процедуры. Если очень хочется.


Пример со схемами — просто говорю что есть механизмы. Если говорить не про тригеры и процедуры, а просто про схему базы, то оно вам и с ORM поможет (удобно при zero downtime. Как пример можете глянуть как вот тут делают).


Вот как раз тут через ORM все чудесно решается.

речь идет не о тех изменениях. Это про изменения логики/кода.


Через Entity lifecycle events.

если вы вешаете на них бизнес логику — сочувствую тем кто будет поддерживать ваш код в будущем. Эти вещи предназначаются для персистенс логики всякой веселой.


т.к. отслеживание изменений в ORM обычно из коробки

Только если ваша ORM имеет внутри unit of work. Это маленький процент ORM и в целом они обычно очень сложные. Не ну как, если понимать что магии там нету и разбираться как оно работает)


Я в последнем проекте просто кидал сообщение в менеджер очередей

А у меня вообще event sourcing


в PostgreSQL в триггкре доступна информация о пользователе, выполнившем транзакцию

Тригер будет запущен из под того же пользователя, из под которого идет подключение. Ну то есть соответственно помимо тригера вам надо будет еще аутентификацию на пользователей СУБД перевести. А вот это уже оч херово скейлится.


Скажем у меня на проекте HIPAA и мне нужно не только трекать кто чего подправил, но и кто чего посмотрел. Настолько что мол мне надо трекать кто в какое время в результате поиска каких пользователей увидел.


Подобное я ни в коем случае не буду делать ни на тригерах ни на ORM. У меня сверху подсистема которая коллектит ивентики эти и потом балк инсертом записывает.


и можно ли к каким-то внешним службам обратиться, типа RabbitMQ или Redis?

Там есть notify через который можно замутить pub/sub. Например — штуки типа postgraphile используют для того что бы апдейты на клиент в сокеты пихать.


Но они что, правда не работают в кластерах и при шардинге?

Тут больше вопрос в бизнес логики и можно ли эту логику на шарды разбить.


Опять же, у меня опыта такого тоже нет, просто из всех проектов которые приходилось видеть основной юзкейс был именно в том что бы жестко ограничивать доступ к данным (когда самое критически важное лежит процедурами, все данные жестко разбиты какими-нибудь row based security и т.д.). Ну и те же микросервисы, где можно ввести те же ограничения, уже могут выйти дороже. Но опять же всякое бывает. Иногда критически важную подсистему можно выделить отдельно и будет как бы монолит + внешняя система которая не меняется без согласования с контролирующими органами (какие-нибудь PCI DSS)

+1

Наши с вами комментарии становятся все длинее и длиннее. Это верный знак, что мы движемся куда-то не туда. Я решил посмотреть куда именно, и, как мне кажется, понял проблему.


  1. Наши подходы в принципе совпадают.


    • Я не отрицаю, что иногда триггеры и хранимые процедуры могут быть полезны. Вы привели много примеров этого.
    • Вы утверждаете, что ORM не панацея и не серебряная пуля. Я согласен с вами на 100%. Я вообще думаю, что "серебряных пуль не бывает".
    • Мы расходимся в оценках того, какие именно особенности ORM являются их сильными и слабыми сторонами, но это во-первых все же вторично, а во-вторых сильно зависит от конкретной задачи. Можно рассмотреть 100 сферических ТЗ в вакууме, но это явно выходит за рамки дискуссии в комментариях.

  2. Очевидно разное понимание роли ORM в проекте, сложилось скорее всего по моей вине. Мой опыт как раз ограничен "очень сложными" ORM с DBAL, UoW, Lifeсycle Events, Query Builder, Repository Pattern, Entity Collections, Criteria, блэкджеком и всем остальным. В результате у меня в коде проекта не бывает не то что хранимых процедур, а SQL вообще. Или lazy loading, или Query Builder, или Criteria.
    Глупо с моей стороны было упускать из виду существование ORM as is, без всего этого "богатства". Прошу простить мне мою профессиональную деформацию.


  3. Насчет зависимости от СУБД. На ранних стадиях предпоследнего проекта (около 15% кодовой базы) я пробовал интереса ради запуститься с PostrgeSQL вместо MariaDB. После некоторой пляски с настройками ORM все получилось. Код менять не пришлось.


0
> Глупо с моей стороны было упускать из виду существование ORM as is

Подозреваю что вы пользуетесь либо Доктриной либо Чем-то вроде гибернейта, ну тогда в целом мы используем одни и те же инструменты.

разница лишь в том что вот все эти «богатства» это про persistence а не про бизнес логику. И да, я помню как я сам завязывал на всякие вычисления чейнджсетов бизнес логику — это прямая дорога в ад на любом маломальски сложном проекте.

Ну и еще раз — вы сами предлагали посмотреть на вещи «по другому». Например — event sourcing вполне себе компромисный вараинт, который позволяет вам крутить вертеть вашей моделью данных как угодно.
+1

ORM и DBAL не синонимы и не вложенные множества. Отсутствие vendor lock в случае универсальной ORM лишь бесплатній бонус, если вам нужен маппинг, и огромній оверхид если нужна абстракция от диалекта SQL.

+3
Проблема с хибернейтом не в хибернейте, а в том, что его применять необходимо правильно, что требует опыта и сениорского уровня. Чаще же к любому ORM относятся как к упрощающей прослойке с которой любой джуниор может работать, в результате и получается то, что получается.
0
Ну и выстрелить себе в ногу там пара путяков — одно неловкое движение и он загружает в память тьму данных (по крайней мере лет 10 назад так было)
+1

Что опять же подразумевает сеньорские знания в случаях отличных от самых тривиальных :)

0
Хм. Вы думаете на SQL невозможно написать что-то подобное? Ошибка в условии в UPDATE… JOIN может давать очень интересные эффекты. Но гораздо более частая проблема неправильного использования ORM — это N+1 запрос.

ORM — она (он?) такая же реляционная как СУБД под ней. Поэтому использование ORM не отменяет необходимости понимания того, как работает реляционная модель данных. Должен ли это понимать джун? Я думаю да.
0
ORM — она (он?) такая же реляционная как СУБД под ней.

реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты) или в каком смысле вы употребляете это слово?


Должен ли это понимать джун? Я думаю да.

Понимают ли? думаю нет. Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. Вот выше тоже вещают про то что ORM это абстракция от базы. А если оно абстракция — значит про базу знать не обязательно.

0
реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты)

В том смысле, что она орудует сущностями связанными отношениями. Если пожелаете, то можно и с предикатами. Есть например забавные штуки, которые позволяют строить запросы, которые отрабатываются по уже загруженным данным, вообще не обращаясь с СУБД, если все что нужно уже имееется. а если нет, то будет запрошено. Есть разумеется, некоторые ограничения, но иногда очень полезно.


Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает.

Для подавляющего большинства джунов RDBMS — это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. "Оптимизация индексов? План исполнения? Нет, не слышали! Там есть какой-то оптимизатор внутре, вот он пусть и оптимизирует. А мы умеем в SELECT и UPDATE".

0
которые отрабатываются по уже загруженным данным

и джойны там есть? Или чисто проверка условий? Ну мол реляционная алгебра это все ж чуть интереснее чем фильтрация коллекции.


Опять же — главное пожалуй отличие — отсутствие ссылок и возможности однонаправленные one-to-many связи делать (у вас на стороне many fk что делает его зависимым от one)


Ну и за счет всех этих нюансов и появляются кучи плюшек по оптимизации. А так можно просто key-value хранилище сделать и индексы строить, никто не мешает. Объектно-ориентированные базы были, сейчас вот есть документно ориентированные (или мой любимый объектно/реляционный постгресс)

0
и джойны там есть? Или чисто проверка условий? Ну мол реляционная алгебра это все ж чуть интереснее чем фильтрация коллекции.

Тут начинаются тонкости реализации.
Джойны есть в том смысле, что вы можете фильтровать по свойствам вложенных объектов. Ну и естественно получив объект(ы) вы получите доступ ко всему "дереву зависимостей". Но в общем да, это все же просто фильтрация. И если есть lazy loading, вы рискуете получить x*N+1, если cвязанные сущности не подгружены. Тут уж вам решать надо оно вам или нет. Ну и иногда (при больших объемах данных) быстрее будет выполнить запрос к СУБД, чем копаться в памяти.


у вас на стороне many fk что делает его зависимым от one

Нет, ну ORM — это все же не RDBMS, но связи между объектами и некоторые реляционно-ориентированные операции поддерживаются могут поддерживаться.

+1
> по свойствам вложенных объектов.

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

> ну ORM — это все же не RDBMS

прикол то в том что если у вас есть RDBMS то ограничения этой модели будут просачиваться сквозь вашу ORM (если она общего назначения, типа гибернейта). Те же one-to-many там кастылем разруливаются, что бы эмулировать однонаправленность связи.
0
забавные штуки, которые позволяют строить запросы, которые отрабатываются по уже загруженным данным

Расскажите подробнее, пожалуйста. Какие группы запросов поддерживаются — произвольные, или только фильтрация по PrimaryKey? Если произвольные запросы, то чем обеспечивается доказательство, что из базы уже всё прочитано в память, и в базу лезть не требуется?


Просто если здесь только фильтрация по PrimaryKey, то такие штуки по факту являются банальным кэшем, и ввиду этого абсолютно не забавны. А вот если там поддержка произвольных запросов (и не просто кэширование результатов) — то это да, интересно неимоверно.

0
Если произвольные запросы, то чем обеспечивается доказательство, что из базы уже всё прочитано в память, и в базу лезть не требуется?

Со стороны ORM ничем и никак. Любая коллекция итерируется так, как она есть. Рассматривайте это просто как кэш с некоторыми дополнительными фишками. Волшебного решения инвалидации кэша из коробки нет. Можно просто выкинуть все или часть загруженных сущностей. Тогда при следующем обращении они будут вытянуты. Плюс — lazy loading, который иногда удобен, но при неправильном использовании даст вам N+1.
Фильтрация в принципе произвольная, но с учетом оговорок выше.

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

Да, это может работать если клиенту возможно скармливать данные по кускам, как, например, Flux<T> в реакторе. Тогда при запросе можно быстро выдавать из кэша что есть, и если этого не хватило — выдать уже из базы данных. Так можно сильно уменьшить время первоначального отклика на запрос, если отклик на запросы клиентов часто содержит повторяющиеся данные.
К сожалению, плохо будет работать сортировка — в общем случае, в любой момент остаётся шанс, что в базе находится некий элемент, который по данному критерию ниже, чем начало кешированной страницы.

+15

Промышленная разработка софта отличается от идеальной разработки софта. Решения принимаются в различных условиях и всегда с неполными данными. Грамотная архитектура недостижима, когда приходишь в проект в любом случае видишь говно.


Пример с БД и бэком может быть обусловлен тысячей причин, начиная с "спроектировали БД, потом появились новые требования" заканчивая "для возможности будущей миграции с SQL на NoSQL (или наоборот) принято решение вынести логику на уровень Бэка".


То же самое с фронтом: ВК например отправляет через AJAX на фронт сразу куски готового HTML, в то время как стандарт — это JSON. Даже если условия изменились, и сейчас какое-то решение выглядит глупым, вполне возможно что оно принято в других условиях и сейчас это тупо ДОРОГО переделывать.


Глупость кода, таким образом, в 95% случаев не глупость, а стечение обстоятельств, недостаток рефакторинга и ошибки в архитектурных решениях, принятых в условиях дефицита информации, которых было невозможно избежать. А в оставшихся 5% случаев допускаются как "фулстеками" так и "частичниками".


И кстати, опять же с точки зрения архитектуры, "частичникам" гораздо проще сохранить консистентность слоев. Если ты знаешь свои границы — через них так просто не перейдешь.
А вот если ты пишешь сверху донизу, то вот тут как раз очень просто поместить логику "не туда", куда ты поместил аналогичную логику в прошлый раз. Да, может быть это дает какой-то эффект, но убивает архитектуру кода и ее консистентность.

-5
Я не говорю о проблемах возникших при сопровождении, я говорю о стадии разработки — это видно, когда возникла эта глупость…
Когда знаешь свои границы…, но чаще бывает важнее знать что и где выгоднее выполнить. Это важно ещё на стадии разработки.
Вот упоминание json… все считают стандарт… но это лишняя, как минимум двойная работа. Ajax — даже на новые разработки его втыкают, когда уже есть websocket.
Дорого переделывать — а кто оценивает? фуллстек? или «узкий специалист»?
+11

Судя по вашему комментарию вы очень далеки от процессов разработки софта, я уж не знаю как:


  1. В любом Agile окружение "разработка" и "поддержка" трудно отличимы после первого же цикла, а после MVP это вообще уже одно и то же.


  2. Никогда не "выгоднее" выполнить что-то не там где надо, потому что с кодом работают люди, и им надо писать его так, чтобы можно было его поддерживать. Иначе бы все в мире писали на ассемблере, потому что это "очень выгодно".


  3. json — лишняя, двойная работа? Вы о чем вообще??? Ajax заменяется веб-сокетом? Серьезно?? Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket? Я уже молчу о том, что по вебсокету обычно все передают json...


  4. Дорого переделывать — обычно оценивает бизнес. Потому что он платит деньги. И это важно понимать любому разработчику… Если говорить про конкретных людей — CTO, Архитектор, ТехЛид, ТимЛид. Люди с кругозором на весь используемый стек.


-5
Достаточно 3 пункта, чтоб понять, что дальнейший спор бесполезен.
json — лишняя, двойная работа

1 Преобразование данный в json
2 Пребразование json в html (рассматриваем веб проекты)
все это можно заменить на сервере простым «серверным рендерингом» преобразованием данных а hyml. на клиенте html строка вставляется в дом 1 строкой кода.
Ajax заменяется веб-сокетом? Серьезно??
элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.
Я уже молчу о том, что по вебсокету обычно все передают json...
Очень важное слово «обычно»,(раньше обычно ездили на телегах...) можно просто передать html, будет просто и наглядно и быстро. Я видел как запаковывают html в json вместе с другими с другими данными, но это отрыжка из прошлого, когда использование ajax требовало режима запрос-ответ, т.е. на один запрос только один ответ. Технология websocket позволяет отойти от этого. Чем я и пользуюсь.
Мало того, websocket позволяет снизить нагрузку на сервер. позволяет отображать данные в реальном масштабе времени. Есть проекты где по ws предаются данные с arduino, пишутся в базу и отображаются в виде бегущего графика у клиента, и все это в реальном времени с минимальной нагрузкой на сервер…
+3
2 Пребразование json в html (рассматриваем веб проекты)

В большинстве новых проектах на "хайповых" технологиях преобразования в html нет, преобразование идёт в DOM

0
есть, конечно варианты, но все равно это строка не json, в той или иной форме это строка из элементов html. Если мне надо вставить в див таблицу, я сформирую на сервере html строку таблицы. отправлю её клиенту и вставлю в дом простой командой .innerHTML='html_строка_таблицы'. есть вариации типа DocumentFragment., но это сути не меняет.
В большинстве новых проектах на «хайповых» технологиях преобразования в html нет, преобразование идёт в DOM
не будь голословным приведи варианты этих хайповых технологий
+2
не будь голословным приведи варианты этих хайповых технологий

React, Angular, Vue, KnockoutJS, Svelte, Ember… Честно говоря практически всё, что вы только сможете найти в области SPA. При этом oldschool подход формирования кусочков HTML на стороне backend продолжает использоваться в более простых задачах. Чем проще продукт, тем меньше ему нужно заморочек с frontend. Большая часть вебсайтов в сети будут себя прекрасно чувствовать вовсе без JS, используя только HTTP + HTML + CSS + JS.


.innerHTML='html_строка_таблицы'

Очень странно, что вы умудряетесь совмещать в своих проектах такие вещи как WebSocket (штука крутая, но нужна оооочень ограниченному числу проектов) и .innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.

-3
React, Angular, Vue, KnockoutJS, Svelte, Ember
это всё фантики, я же просил код, пример.
штука крутая, но нужна оооочень ограниченному числу проектов
это просто потому что многие не умеют её готовить. проще по-старинке ajax…
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.
а что тут такого? на сервере готовлю html строку и на клиенте вставляю, просто, быстро, наглядно. Есть что-то более проще — воспользуюсь.
+3
это всё фантики, я же просил код, пример.

Что именно вас интересует? Внутри этих библиотек используется DOMAPI (appendChild, createElement, setAttribute & etc...). Вам ссылку на MDN? Или ссылку на те места где эти методы используются в недрах этих библиотек? Или ссылку на те места где вы их руками в своём коде пишете? Если последнее, то в том то и суть, что руками вы это пишете только совсем уж в исключительных случаях. Библиотека\фреймворк делает это за вас в оставшихся 99%. Вы работаете над данными и взаимодействиями между ними.


это просто потому что многие не умеют её готовить. проще по-старинке ajax…

Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю.


а что тут такого?

Ничего плохого в использовании каменного зубила нет. Просто непродуктивно это для больших и сложных frontend-проектов. Поэтому уже больше 5-и лет для сложных задач используют различные реактивные вещи. Правда более простыми я бы их не назвал, погружаться в эти технологии придётся долго и трудно. Это существенный пласт знаний, без которых сегодняшняя разработка серьёзных фронтенд приложений просто немыслима (ооочень дорого).


По сути это всё настолько объёмный пласт знаний, что по первой это может вызвать кровоизлияние в мозг. Шучу. Все эти webpack-и, babel-и, JSX-ы, React-ы, PostCSS-ы и тысячи других баззвордов — это реалия современного фронтенд рынка.

-2
(appendChild, createElement, setAttribute & etc...)
это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.
Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю
.это хорошая новость., что есть люди, умеющие их готовить, но для меня это не серебрянная пуля, просто это универсальная технология позволяющая полностью заменить ajax, и отказаться от множества поддерживаемых технологий.
Для меня это элементарный механизм, как и хранимки, поэтому я считаю это одним из простейший кирпичиков для построения систем.
+7
это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.

Вы их используете. А мы нет. В этом суть. Мы не орудуем каменным зубилом. Им орудуют используемые нами инструменты. Это сложно объяснить в двух словах.


P.S. Ну и есть огромная разница между innerHTML= и производительной работой с DOM.

0
Ну и есть огромная разница между innerHTML= и производительной работой с DOM.

Не флейма ради, а объективности для: разница есть, в разы. В IE (включая 11) и Edge* innerHTML = ... гораздо быстрее appendChild. В WebKit с точностью до наоборот.


Всплакнём, господа гусары...


* По данным на год или около того назад, с тех пор не проверял.

0

nohuhu речь идёт о другом. О том, что innerHTML заменяет весь DOM-блок целиком. А современная тенденция заключается в переиспользовании существующего DOM-а. Т.е. с одной стороны весов у нас полное удаление и пересоздание всего звена, а с другой — добавить новое, поправить существующее, убрать лишнее. Я об этом.

0
А современная тенденция заключается в переиспользовании существующего DOM-а.

Да я в курсе, просто позанудствовал. :)

0
Плохой пример. Там разница — 2 миллисекунды. А для web-интерфейса 2 миллисекунды — это примерно в 100 раз быстрее, чем «мгновенно».
-1
мозилла
GEThttps://jonhappy.github.io/inner/
[HTTP/2.0 304 Not Modified 56ms]
t1: 3мс inner:46:13
t3: 4мс inner:51:13
t2: 11мс inner:81:13
хром
t1: 3.31298828125ms
t3: 13.749267578125ms
t2: 65.237060546875ms

для сервера формировать html и json — затраты одинаковые
для клиента — есть разница и по времени и по количеству кода.
0
Это самый простейший вариант, если чуть усложнить — добавить условий — то разница будет больше. И если это запускать в млзилле — то на быстрой машине разницу увидеть трудно из-за того что точность времени мс, в хроме точность отображения намного больше — и разница заметна.
+1
Я, в общем, в курсе, что разница есть. Но я считаю, что ускорять приложение там, где пользователь не увидит разницы — нерентабельно. Из двух приемлемых по производительности способов нужно выбирать тот, который делает разработку проще (а значит, быстрее и дешевле).
И есть еще одна ерунда: код выполняется в среде, которую вы не контролируете. Так что даже преимущество по скорости конкретной низкоуровневой реализации не гарантируется. Скажем, выкатил Google крупное обновление для Chrome — и ой. С них станется, я помню, они как-то раз системные select'ы сломали (все жутко тупило и жрало ресурсы без всякого JS). А фреймворки как раз нужны еще и для того, чтобы не думать о всевозможных подводных камнях и особенностях конкретных версий конкретных браузеров на конкретных системах. И не заниматься занудной работой по воспроизводству экзотических багов. Да, в абсолютных цифрах это решение, возможно, не будет «быстрым, насколько только возможно». Но оно будет оптимальным по стоимости, поддерживаемости и, в том числе, быстродействию. А на низкий уровень надо лезть, только если на быстродействии поставлен отдельный акцент и когда проблемы с ним действительно заметны.
+1
во сколько раз отличается мой innerHTML= и ваша «производительная работа с DOM. „

Так вы ж неправильно "производительную работу с ДОМ" делаете. Надо менять существующие ноды, а не создавать новые.

0

BigDflz, по ссылке я вижу бенчмарк, который сравнивает поэлементное создание цельного куска DOM двумя способами. При этом innerHTML= в 3-4 раза быстрее. Как это согласуется с тем, что я писал выше? Нормально согласуется, так и должно быть. А что должно быть в вашем бенчмарке, если предположить, что вы в коем веке начали прислушиваться к тому, что вам пишут? Должно быть сравнение, скажем единичного setAttribute(td, value) и цельного innerHTML = tableHTML. Т.е. сравнение одной крошечной операции и одной крайне тяжеловесной. Бенчмарк при этом не нужен, т.к. очевидно, что 1 точечная операция будет легче на несколько порядков. Именно это и есть производительная работа с DOM. Не формировать цельные куски DOM-а "руками", чтобы "наверняка" покрыть все изменения разом, а обновлять точно и по месту, ровно то, что нужно обновить. Причём не "руками", а автоматикой.


И что характерно, я ведь об этом писал вам в личку, писал сюда, даже ссылки приводил, что почитать. Но вы упорно гнёте свою линию, считая, что мы не понимаем вас, и не слушаете, что пишем мы. Какое-то одностороннее общение.

0

BigDflz не надо писать мне в личку. Я уже просил вас перестать это делать.


Вы серьёзно считаете, что я настолько глуп, что для того чтоб сменить атрибут буду использовать innerHTML? У меня в голове не укладывается, как можно спутать области применения innerHTML и setAttribute(td, value)…

Я заметил, что в вашей голове очень многое не укладывается. Не только это :)


P.S. я понимаю, что с каждым вашим комментарием у всё меньше и меньше прав на хабрахабре, и есть ограничения на комментарии. Но я тот тут причём?

+1

И снова мне в личку пишет наш неутомимый товарищ:


из-за того что на хабре нельзя высказывать и защищать своё мнение, из-за минусующих…
не хотите чтоб в личку — не минусуйте, дайте высказываться открыто.

Ух. Какой-то хабра-терроризм :) Призываю Boomburum

0
Всем привет в этом чате :) Вряд ли пользователь BigDflz чем-то угрожал или хотел навредить — просто у него отрицательная карма и она накладывает ограничение на частоту написания комментариев (1 комментарий в час), а в личных сообщениях такого нет. Поэтому ему проблематично поддерживать тут дискуссию и он пишет в ЛС (либо просит не минусовать его тут, чтобы он мог высказаться)). В любом случае давайте жить дружно, как говорится.

To BigDflz — карму всегда можно обнулить (вкладка reset в настройках профиля, правда, воспользоваться можно лишь однажды).
+2
это всё теже перепевы innerHTML,

Это не перепевы, это прямой способ формировать DOM. А innerHTML — это способ запустить парсер, который распарсит строку и сделает из неё DOM. Концептуально ничем не отличается от json, разве что парсер куда-то проще.

+2
innerHTML это прямой путь чтобы получить XSS, не думаю что кто либо в библиотеках это использует
+3
> innerHTML это прямой путь чтобы получить XSS

Особенно учитывая то, что шаблонизаторы BigDflz тоже не использует и рендерит html конкатенацией :) Ну тут сильно запущенный случай, я не думаю что есть смысл что-то объяснять.
-3
не думаю что кто либо в библиотеках это использует
если не думаешь, не стоит об эом писать. innerHTML такой же метод как и appendChild, createElement, setAttribute & etc..., только он меняет полностью содержимое родителя, а не часть его. то что я делаю из кода — можно элементарно сделать и из консоли браузера. Если посмотришь внимательно что делают известные fw — то увидишь, что они так же используют «серверный рендеринг», только из-за свойст ajax посылать один ответ на запрос пакуют в json сформированную (отрендеренную) на сервере html строку и дополнительный (при необходимости ) набор данных.
что шаблонизаторы BigDflz тоже не использует и рендерит html конкатенацией :)
да будет известно, что под фантиком шаблонизации скрывается та же самая конкатенация. А так называемый рендеринг html (серверный рендеринг) ни что иное, как формирование html строки путем конкатенация строк, содержащих тэги html и пользовательских данных.
Для ознакомления что может javasript делать прошу ознакомиться learn.javascript.ru/search/?query=%D0%B2%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0&type=article
Если послать клиенту json с данными, то необходимо преобразовать сначала в в какой-либо массив/объект, а потом из него в цикле произвести вставку поэлементно в dom, либо сформировать туже строку html и её вставить через innerHTML.
Ваши ангуляры и прочие фантики ничего другого не делают.
По быстродействию — для сервера равносильно что формировать json или html — и то и другое работа со строками, их конкатенацией, скрытой под фантиком шаблонизации или простым сложением строк.
На клиенте же есть разница — простая вставка inerHTML(или ей подобные) или преобразование из json в объект, а потом уже из объекта в inerHTML(или ей подобные)
+3
Ваши ангуляры и прочие фантики ничего другого не делают.

Вы несёте полнейшую чепуху, и похоже не имеете ни малейшего представления о том, как работают все эти "фантики". Ей богу, ну прекратите. Это ж даже не смешно. На дворе 2018г.

-1
перечисли что может ангуляр, и не может js?

Я с вами на "ты"? С каких пор?


Вопрос в высшей степени нелепый. Angular это JS фреймворк. Он на нём написан. Вопрос просто не имеет смысла.


Комментарий выше был про то, что все эти фантики работают на стороне клиента и никаких строчек в HTML не склеивают. На стороне JS нет необходимости формировать HTML из строк. Работа происходит на уровне объектов.


Серверный же рендеринг этих фантиков — явление достаточно редкое. Там тоже работа внутри "фантиков" происходит с объектами, а не строками. Строка собирается уже из объектов на самой самой финальной стадии. И это всё скрыто от разработчика в недрах библиотек.

+3
А так называемый рендеринг html (серверный рендеринг) ни что иное, как формирование html строки путем конкатенация строк, содержащих тэги html и пользовательских данных.

В конечном счёте, если речь идёт именно о серверном рендеринге (который зачастую отсутствует как класс), то да, сборка итогового HTML это сборка строки, которая отправляется клиенту назад по HTTP.


Однако, имеет существенное значение, как эта строка была сформирована. Если вы эти, пардон, руками формируете, склеивая строки в вашем коде явным образом… пример:


<div class="<?= htmlspecialchars($type.$some) ?>"><?= $title ?></div>

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


Шаблонизаторы внутри себя эти самые строчки и склеивают, да.


Правда я ещё раз сделаю акцент на том, что раз уж мы говорим про AJAX, WS и прочее, то у нас, как правило, почти всегда, нет никакого серверного рендеринга. Совсем. Вот прямо ни строки. Сервер передаёт нам только данные. А с HTMLDOM работает уже клиент (JS). И клиент никаких строчек не склеивает, т.к. незачем. У нас ведь есть DOM и полноценное API к нему. И даже этими методами мы не пользуемся почти, т.к. это делает дополнительная прослойка — фреймворк.

0

Более того, может отсутствовать классический шаблонизатор типа PHP :), а на стороне сервера собираться поэлементно полноценный DOM (или virtual DOM), который рендерится в "outer/innerHtml"

+2

Оказалось, что наш друг вовсе не PHP-ер, он JAVA-ер, и конкатенирует HTML "руками", за счёт огромной портянки цепочек .append(anything). Код вида:


StringBuilder s = new StringBuilder();
s.append("<div ").append(" id='").append(id).append("'><span>").append(/* и так далее */);

Собирает такие кусочки HTML на сервере по любому поводу (по сути любое изменение DOM) и отправляет на клиент через webSocket-ы (прямо как есть, строкой), а на той стороне jQuery-like портянка с innerHTML. Мотивация: все эти фреймворки очень медленные, а у меня вот как всё быстро и удобно. о_О. И это на задачах в стиле "вывести редактируемую табличку на корпоротивном сайте" (не какой-нибудь hyper-high-load).

0
BigDflz очень интересный уникум, он и в моей статье пытался доказать, что вся отрасль front-end глупцы, используют лишнюю абстракцию json и что нужно гонять html через ws
-1
Да, получается что я уникум, да, я гоняю всё через ws. Это всё намного проще и производительнее, чем гонять через ajax. в начале появления ws, я наслышался такого про эту технологию… а теперь оказывается что все wf её используют. А насчет гоняния html через ws, могу сказать, что вы просто имеете поверхностные знания о работе ваши wf, которые по тихому вставляют собранную на сервере html строку в поле того же json. И называют это красиво — серверный рендеринг
habr.com/company/ruvds/blog/339148
medium.com/devschacht/peter-chang-break-down-isomorphic-and-universal-boilerplate-react-redux-server-rendering-8fd0ec4a8512
ru.stackoverflow.com/questions/528390/%D0%97%D0%B0%D1%87%D0%B5%D0%BC-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BD%D1%8B%D0%B9-%D1%80%D0%B5%D0%BD%D0%B4%D0%B5%D1%80%D0%B8%D0%BD%D0%B3-react-js-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BE%D0%B2
+1
Это у вас поверхностные знания. Во-первых, серверный рендеринг применяется только при загрузке страницы. Во-вторых, это необязательная часть wf.
0
первоначальная страница всегда строится на сервере, строилась с самого начала появления веб. но даже тогда это не называлось серверным рендерингом. Да это не обязательная часть fw. Да, для построения элемента в dom можно передать json с необходимыми параметрами и потом построить элемент, примерно так
 var span = document.createElement('span');
            span.className = 'dataspan';
            span.id = v.id;
            span.style.display = 'table';

            var input = document.createElement('input');
            input.className = 'chbx';
            input.type = 'checkbox';
            input.id = 'stateCheck' + v.id;
            input.name = 'status';
            input.checked = v.completed;

предварительно распарсив json и сделав вставку в цикле(если это, к примеру, таблица).
а можно просто вставить готовую строку html таблицы
у сервера затраты на формирования json и html строки одинаковы. а на клиенте — намного разные.
+1
Да, правильно, на клиенте — намного разные: dom формируется быстрее.
-1
Dom формируется всегда на клиенте. и только на клиенте. Но он может быть сформирован по разному с помощью вставки через innerHTML и с помощь. createElement. но во втором случае по мимо самого построения dom используется ещё и циклы самого js. и построение происходит поэлементно, и по заданию каждого атрибута элемента отдельно. а это достаточно больше времени чем innerHTML.
куча вариантов вставки / построения элементов dom сделано для удобства его построения
+2

При первоначальном рендере вставить кусок html по месту быстрее, чем делать это итеративно. Это правда. Это кстати одна из причин серверного рендера — пока на клиенте всё заведётся, можно ему уже готовый кусок кода подсунуть.


Вся соль в том, что эти "fw" нужны в динамических приложениях. Там где этот DOM постоянно меняется. Довольно сложным образом. И вот тут эти самые "поэлементные js циклы", будучи правильно организованными, уделывают innerHTML, кладут на лопатки. Потому, что переиспользуются уже существующие DOMElement-ы. Теперь их не нужно уничтожать и создавать заного на любое обновление. Система сама определяет что изменилось (js-циклами со сравнениями, да) и обновляет точечно. А так как практически любая возня с DOM просто адово тяжелее этих самых вами ненавистных js-циклов, получается, что обновить точечно только то, что изменилось на пару порядков быстрее.


Причина простая — DOM сам по себе ну очень тяжёлая абстракция. И почти всемогущий CSS ещё в большей степени его замедляет. Рендер этого DOM-а очень тяжёлая операция. Так называемый reflow это то, чего стараются избегать без особой на то причины. И т.д.


Вот выделите любой dom-element в древе и пропишите в консоли console.dir($0). Поковыряйте этот объект. Там просто бездна всего. Это очень тяжёлая штука.

0
  1. Сейчас всё чаще и чаще "первоначальная страница" лежит на сервере как статический файл index.html. И какой-нибудь nginx отдаёт его как есть. Т.е. на сервере нет рендера от слова "совсем".
  2. Сервера, за пределами этого nginx и пачки статических файлов может не быть вовсе. Ряду приложений он вообще не нужен.
  3. Если же сервер используется, то обычно для двух вещей: клиент запрашивает какие-либо данные, клиент просит сервер выполнить какое-нибудь действие.
  4. Ответ сервера не сводится к тому, чтобы обновить DOM. Серверу вообще не интересно как устроен DOM, где там что лежит и как устроено. Это отдано на откуп frontend приложению. А ему, приложению, нужны от сервера только данные.
  5. Frontend приложение не сводится к одному только обновлению DOM-древа. Это, зачастую, большие сложные штуки с грудой хитрой логики. Представьте себе любое сложное desktop-приложение. Вот это оно самое, только в web-е. Внутри frontend-приложения балом правят данные и взаимодействия основанные на этих данных. И только в самую последнюю очередь там заходит речь про обновление DOM-древа.
  6. На фоне всех этих задач — такие тонкости как JSON.parse и обработка DOM посредством DOM-API — это одна из самых несущественных задач.
  7. Эта несущественная задача виртуозно выполняется теми самыми фреймворками, которые вы так люто ненавидите. Они умеют обновлять только то, что нужно, а не целиком менять большие DOM-блоки. Это гораздо быстрее.
  8. В итоге задача программиста сводится не к тому, чтобы заморачиваться на DOM, а к тому чтобы грамотно организовать все эти потоки данных. Всю логику по их взаимодействую между собой. Часть результатов этих вычислений выливается в DOM. Часть в логику обработки eventHandler-ов. Ну и т.д… Задач в web-е нынче несчесть.
  9. Т.е., надеюсь, теперь вы понимаете, что эта ваша попытка сэкономить 3 байта и 3 наносекунды за счёт избегания JSON.parse и "циклов" — это полная нелепица. Большие сложные приложения имеют бутылочные горлышки совсем в других местах. И вообще frontend-мир устроен в 100 раз сложнее, чем привычная вам схема "гонять html строки с сервера на клиент".
  10. Вы можете подумать, что все эти уровни абстракций и сложности нафиг не нужны, и что "я уже многие годы делаю всё в 100 раз проще и всё хорошо работает". Но будете в корне не правы, т.к. вы просто не сталкивались с действительно сложными задачами, с конкретными ограничениями по времени, когда при вашем подходе вы за равное время дай бог 1/20 успеете сделать от требуемой задачи. Да и код ваш write-only. Его архитектура не выдерживает никакой критики в долгоиграющие динамично развивающихся проектах. Сразу в утиль.

Сейчас вы наверное начнёте всё подряд цитировать, писать про медленные gmail-ы, про протекающие абстракции, про то, что "из-за вас всё и тормозит" и прочее даратьянство. Но я прошу вас этого не делать. Постарайтесь хотя бы раз прочитать, что вам пишут "дутые пузыри".

0
1) страницы бывают разные поэтому не надо так однозначно утверждать. И я первоначально, в некоторых случаях, отдаю статическую страницу. Но после определённых действий юзера необходимо обновить страницу — это можно сделать 2 способами — перезагрузкоя всей страницы, но тогда сервер уже не отдаёт «статическую » страницу, а встраивает в неё необходимые элементы. либо обновит на странице только необходимую часть (к примеру вставить таблицу) и сервер должен для этого что-то сформировать — только 2 варианта json и html. Для сервера затраты равносильные.
для клиента разные.
2 не надо так критично заявлять иногда надо только данные. а иногда лучше для клиента получить готовое. Если я говорю о варианте вставки в dom- то это только один из множества вариантом.
моя попытка сэкономит миллисекунды выливается в сэкономленные минуты. Мне надоело сидеть перед оператором и ждать когда у него на экране появится нужная информация. а это встречается в 99. 9 случаях.
а по использованию fw — инет переполнен вопросами, как и что сделать на том или ином fw и скорость написания на них ни чуть не быстрее, зато время выполнения намного медленнее
+2
  1. Да, страницы бывают разные. Я выше уже упоминал, что для большей части WEB-а JS вообще не нужен. Читайте не по диагонали, плз.
  2. Причина по которой вы ждёте перед оператором минуты никак не связана с fw, и никак не связана с сэкономленными миллисекундами. Вы, как программист, ну просто обязаны это понимать. Если нет — срочно за книжки.
  3. Кстати да, скорость написания на "fw", в вашем случае, будет намного медленнее. Всё так. Проблема тут именно в вас. Когда ничего не знаешь, ничего не умеешь, и не хочешь учиться ― это пряма беда-беда. Вангую, что когда вам всё таки придётся освоить тот же webpack + babel, вы будете волосы на голове рвать, громко материться на полквартала и кричать про то, какие все вокруг тупые и всё переусложняют. И, что характерно, отчасти будете правы.
-1
а на той стороне jQuery-like портянка с innerHTML.
вот когда не знаешь и не понимаешь — не надо писать, выставлять своё не знание предмета. Для того чтоб вставить html не надо jquery. нудно просто 1 (ОДНУ) строку чистого javascript.
Ваши wf делают тоже самое, только все заворачивают в кучу кода, прогуглите «серверный рендеринг» ,«server side rendering», SSR.
за счёт огромной портянки цепочек .append(anything). Код вида:
если ты хоть что-то знаешь в java, это хоть и не очень «красивый» вариант работы со строками — но самый быстрый. И любой шаблонизатор это использует, только скрывает это за кучей лишнего кода.
+1

BigDflz, приглядитесь внимательнее, я ведь написал jQuery-like, а не jQuery. Это потому, что никакой принципиальной разницы между domNode.appendChild и $(selector).append я в этом вопросе не вижу. Ручная работа с DOM.


Да и про StringBuilder и принципы его работы я в курсе. Я много про что в курсе, вы за меня не переживайте.


А упёртости у вас хоть отбавляй ;)

0
faiwer, приглядитесь и вы внимательно — я отвергаю слово портянка
Я много про что в курсе, вы за меня не переживайте.
я рад за Вас, о том, что Вы в курсе, вот только по высказываниям так не скажешь.
А упёртости у вас хоть отбавляй ;)
«Упертость» — это так теперь называется защита своего мнения?
Создаётся впечатление, что многие причисляющие себя к синьёрам, просто мыльные пузыри. Которые используют fw, а что там у них внутри и понятия не имеют. Говорят о невозможности сохранять версий хранимок в гит, когда всё это давно реализуют админы этих субд, (бэкапирокание субд проработано досканально). Говорят о недостатках языка, тормознутости на примере своего написания и использования кучи лишнего…
говорят о портянке цепочек append, а сами, не понимая того, используют их в более ужасном виде в шаблонизаторах. Если б шаблонизаторы были написаны на ассемблере, я б ещё мог согласиться…
Ручная работа с DOM.
Зато как это круто использовать fw, который в итоге сделает тоже самое, только за более большее время. времени на написание параметров для того чтоб fw сделал нужное будет больше чем просто написать работающую строку на чистом js.

mayorovp
И главное — придется забыть про хранимки в СУБД, ибо они не умеют в нормальные двунаправленные потоки данных :-)
Вот когда в субд имеешь поверхностное знание — не надо делать такие заявления. Есть такое разделение для запросов — редактируемые и не редактируемые. Так вот большинство серьёзных запросов — не редактируемые. Используя хранимки — об не редактируемости можно забыть. Я могу изменить данные в любом наборе, и для этого не надо «двунаправленных потоков»
0
вот только по высказываниям так не скажешь.

Если читать по диагонали, то это всегда так ;)


«Упертость» — это так теперь называется защита своего мнения?

Скорее, в вашем случае, это попытка навязать своё мнение\оправдаться, будучи с закрытыми глазами. Как в том анекдоте — чукча не читатель, чукча писатель.


Которые используют fw, а что там у них внутри и понятия не имеют.

А также это богатое воображение. Ну вот я знаю как устроены, используемые мною фреймворки по капотом. Я стараюсь не использовать вещи, которые не понимаю.


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

Вот яркий пример чукчи-писателя. Вы же просто не желаете понимать, что вам пишут. Зачем пытаться понять смысл тех вещей, которые вам пытаются объяснить? Главное ведь всем доказать, что вы д'Артьяньян, а мы мыльные пузыри?


Я знаю что внутри шаблонизаторов используется конкатенация итоговой HTML строки. Я знаю как устроен StringBuilder (знаю эту структуру данных и её асимптотику). Претензий ни к append методу, ни к самому StringBuilder я не имею. А вот к вашему коду, с его использованием имею. Вот только кажется, вам ну совсем не очевидно, что с ним не так и почему его не должно существовать в принципе.


<irony>Это, конечно же, потому, что вы не "мыльный пузырь". Вы не переусложняете простые вещи. И используете самые производительные подходы. Вы не ведётесь на хайповые "fw", как это делаем мы, дутые пузыри. Мы ведь не знаем, что внутри наших fw. Нам вообще бы дворы подменять, да вот не задалось. И gmail тормозит из-за нас.</irony>

0
Скорее, в вашем случае, это попытка навязать своё мнение\оправдаться, будучи с закрытыми глазами.
Я не навязываю своё мнение — я его высказываю, и если кого-то пугает чужое мнение — не надо трындеть, что оно не правильное.
Ну вот я знаю как устроены, используемые мною фреймворки по капотом. Я стараюсь не использовать вещи, которые не понимаю
Это хорошая новость. Я надеюсь, что и многие здесь такие, Но почему поднялся хай, по поводу серверного рендеринга? Можно сделать вывод, что только потому что многие не понимают что там под капотом у fw.
А вот к вашему коду, с его использованием имею. Вот только кажется, вам ну совсем не очевидно, что с ним не так и почему его не должно существовать в принципе.
Если можете предложить что-то более конкретное — готов выслушать, но думаете, что к такому виду пришёл просто так, написал с перепоя? и что я не знаю String.format?
+1
Не путайте бэкапы с версионированием. Да, некоторые используют гит для инкреметных бэкапов, а некоторые пытаются на бэкапах реализовать версионировании. Но вот как с SQL быстро и удобно переключаться между разными версиями одной хранимки несколько раз в час?
-1
Если очень нужно туда-сюда по версиям ездить — можно организовать прокси-хранимку с выбором версии.
+1
А разницу между двумя версиями посмотреть? Кто какую строку менял и когда?
+2

Чем для вас отличается конкатенация строк, их сложение и шаблонизация? простой сишный printf("Hello %s", name); для вас что?

+1
но думаете, что к такому виду пришёл просто так, написал с перепоя

Боюсь, что нет. Просто самоуверенность и невежество в вас превалирует над всеми остальными качествами.


Если можете предложить что-то более конкретное — готов выслушать

Увы, не готовы. По сути: требования к кодовой базе и требования к производительности программы это не одно и тоже. Кодовая база оценивается по целому ряду параметров. И в условиях асимптотически равного кода приоритет, почти всегда, сдвигается к вещам, завязанным на читаемость, расширяемость, безбажность, очевидность, тестируемость, безопасноть и пр. вещам. Вы, судя по всему, считаете что "быстрое решение" всегда лучше "медленного".


Это частая проблема многих новичков в программировании, которые ухватились за мантру "производительность", и старающихся применить её где надо и где не надо. По сути вопрос в правильных приоритетах.

-1
а многие уцепились за мантру «быстро написать, а там хоть трава не расти»
Увы, не готовы.
А готовность отрицать почему-то всегда на готовности номер Один.
0
а многие уцепились за мантру «быстро написать, а там хоть трава не расти»

Всё так, есть две крайности. Вы в одной, а те кедры, что пишут асимптотически катастрофический код, в другой. Кстати не стоит думать, что вы лучше их ;) Вы просто "другой".


Кстати вам знакомо понятие асимптотика? Вы можете рассказать, как построить хеш-таблицу? Можете написать про её производительность на чтение, запись, удаление. Про амортизацию? Про то как устроено простейшее бинарное древо поиска? Про sqrt-декомпозицию? Знаете алгоритмы на графах? Если нет, то вы зря кичитесь тем, что экономите миллисекунды, в мире, где всё тормозит. Вполне вероятно, что сэкономив 2 наносекунды в одном месте, вы потеряли 40'000 в другом. А ведь там ещё всякие кеш-промахи, всякие мудрые asm-вставки, и чего только нет.


Грубо говоря вопрос производительности штука весьма не тривиальная. Требует хороших познаний в computer science. И разработчик всегда исходит из каких-то компромиссов.

0
[sarcasm]
Боже, какой занимательный срач, аж зачитался!
А разбор кода будет?
[/sarcasm]
0
Эх, жаль :( Полная «картина мира» была бы понятней, а так слишком много абстракции для стороннего читателя.

Но вы продолжайте, очень занимательно, чесслово.

0
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.

посмотрите трафик VK и внимательно разглядите что там отвечает сервер как он работает зубилом
0
посмотрите трафик VK и внимательно разглядите что там отвечает сервер

Посмотрел, с аякс-запросов json он возвращает.

0
а что он может возвратить кроме json? было слабо заглянуть в содержимое json, проскролив несколько экранов?
0

VK, Github, Redmine и многие другие проекты, из тех, что на слуху. В основном очень старые. Счёту им нет. У меня у самого полно проектов, где задействуется это зубило (тоже все старые). Сути это не меняет. Зубило неэффективно. Но порой его достаточно. Я выше писал, что 99% сайтов в сети вообще JS не нужен. Скажем тот же github пытается быть таким условным no-JS сайтом, когда JS используется для разного рода мелочей, но любая серьёзная операция сопровождается перегрузкой. Правда не вкладки, а содержимого страницы. В желании гонять по ws\ajax туда-сюда куски HTML и выставлять их через innerHTML вы не одиноки.

-1
Новшества серверного рендеринга в React 16
SSR. Отрисовка на стороне сервера
Server-side rendering your React app in three simple steps
Angular 4 with server side rendering (aka Angular Universal)

можно ещё перечислять…
а любой «серверный рендеринг» — это вставка через .innerHTML
похоже весь мир шагает не в ногу, один вы в ногу…
можете продолжать настаивать и хаять всех, кто с вами не согласен.
Я вижу что вставка через innerHTML работает быстрее, занимает мало кода на клиенте, очень наглядна.
и если старые проекты задействуют вставку через innerHTML, значит уже давно этот вариант имеет преимущества.

+1
Серверным рендерингом в контексте реакта и ангуляра обычно называют рендеринг страницы на сервере, всей страницы, которая отдаётся при вводе адресной строки в браузере или запрашивается поисковыми роботами.

А старые проекты могут быть настолько старые, что во времена их молодости других вариантов особо не было, а теперь переписывать всё дорого и это единственное что удерживает.
0
страница которая отдаётся при вводе адреса — она может быть как чисто html, так и построенная на сервере, как пример — jsp. и роботу без разницы как она сделана. Если ты посмотришь что возвращает сервер VK при скролинге страницы, то увидишь — json, а в этом json будет поле из чистой html строки. Вот это и вставляется в дом с помощью innerHTML. это и называется серверным рендерингом. Я показал, что вставка с использованием большого куска в dom с использованием innerHtml быстрее чем поэлементная, поатрибутная. Серверу всё рамно что строить собирать json строку или html. Когда сервер созданную html строку вставляет в json, это для того чтоб облегчит жизнь клиенту. Если сервер передавал просто набор json — то он бы должен был содержать и сами тэги и данные для них, потому как вставляемый кусок известен только серверу. если json будет содержать и тэги и данные — то какой смысл стоить все на клиенте? когда можно это сразу сформировать на сервере? а на клиенте просто вставить? Ещё раз, посмотрите на json VK — там строка html — всегда разная и по данным и по тэгам.
0
Я показал, что вставка с использованием большого куска в dom с использованием innerHtml быстрее чем поэлементная, поатрибутная.

Вам уже нцать раз сказали, никто поэлементно дом не строит, обновляются только те ноды, что изменились. И обновить несколько нод — значительно быстрее, чем вставить через innerHTML сотню.


Если сервер передавал просто набор json — то он бы должен был содержать и сами тэги и данные для них, потому как вставляемый кусок известен только серверу.

Теги известны клиенту и без сервера.

0
если изменилось содержимое div, в котором была куча разных элементов, на новую кучу уже других элементов- вы тоже будите обновлять поэлементно?
И обновить несколько нод — значительно быстрее, чем вставить через innerHTML сотню.
я показал пример как изменяется таблица через innerHTML и поэлементно.
Теги известны клиенту и без сервера.
только не известно что и где будет расположено
0
если изменилось содержимое div, в котором была куча разных элементов, на новую кучу уже других элементов- вы тоже будите обновлять поэлементно?

Конечно, ведь это намного быстрее.


я показал пример как изменяется таблица через innerHTML и поэлементно.

Вы показали сравнение ручного создания нод и innerHTML. Сравните теперь как обновляется одна нода и как вставляется сотню нод через innerHTML — это и будет валидное сравнение.


Еще раз — никто не спорит, что через innerHTML ноды создаются быстрее, чем "руками". Смысл просто в том, что там где с innerHTML вы создаете много нод можно поменять всего одну вместо этих многих. За счет этого и происходит выигрыш.


только не известно что и где будет расположено

Как это неизвестно? Известно, конечно же.

0
Конечно, ведь это намного быстрее.
поэлементно быстрее?
Еще раз — никто не спорит, что через innerHTML ноды создаются быстрее, чем «руками». Смысл просто в том, что там где с innerHTML вы создаете много нод можно поменять всего одну вместо этих многих. За счет этого и происходит выигрыш.
вы хоть читаете о том что пишу? я разве хоть однажды сказал, что ради одной ноды я буду менять всё? если в диве меняется таблица — это что?
Как это неизвестно? Известно, конечно же.
когда тот же VK вставляет инфу клиент не знает что там будет.
Ели вы динамически меняете содержимое дива — там может быть или картинка или таблица или ещё что…
0
В таблице из десятка столбцов и сотен строк меняется одна ячейка — что за html у вас придёт на сервер?
0
поэлементно быстрее?

Поэлементно изменить один элемент — быстрее, чем построить сотню через innerHTML.


вы хоть читаете о том что пишу? я разве хоть однажды сказал, что ради одной ноды я буду менять всё?

В случае с innerHTML у вас нет выбора. Вам с сервера пришел какой-нибудь виджет целиком, вы его целиком вставляете, несмотря на то, что изменилась в нем одна нода. Естественно, вы можете с сервера прислать данные в json (или каком-то другом формате) для одной этой ноды и ее обновить. И тогда получится ровно то, как работают современные SPA-фреймворки.

-1
Поэлементно изменить один элемент — быстрее, чем построить сотню через innerHTML.
ну не держите оппонента за дурака. Где я такое утверждал?
В случае с innerHTML у вас нет выбора. Вам с сервера пришел какой-нибудь виджет целиком, вы его целиком вставляете, несмотря на то, что изменилась в нем одна нода.
Это напоминает анек: Мужик пошел утром умываться-бриться, пока вода/бритва шумели, жена что-то спросила, что-то подумала, что-то ответила… В итоге из ванной он вышел уже разведённым…
Я показал пример, что и на что как меняется. Я просил посмотреть что передаётся в json в VK… кто-нибудь посмотрел?
Я знаю все команды, что и как вставить и заменить. И уж поверьте, если я фулстек — то смогу правильно перераспределить что и где проще/быстрее формировать.
Если у меня есть таблица со сложной структурой, то мне намного проще сформировать её один раз на сервере, чем сначала json из данных, а потом из json на клиенте сформировать эту сложную таблицу на клиенте, что я вижу во многих реализациях… Если проще заменить всю строку — я заменю всю строку.
0
Если проще заменить всю строку — я заменю всю строку.

А если потом окажется, что строку надо по-другому форматировать, например, выделить жирным шрифтом один из столбцов — пойдете исправлять отдачу бекенда? Норм, чо. Надежно.

-1
А если потом окажется, что строку надо по-другому форматировать, например, выделить жирным шрифтом один из столбцов — пойдете исправлять отдачу бекенда? Норм, чо. Надежно.
Вот сразу видно «опытного» прогера — в одну кучу смешивает и мух и котлеты. Таблица формируется в одном месте. И отображается в одном месте и если нужно исправить — правится в одном месте. Если у вас одна таблица отображается в нескольких местах — и вы для каждого места пишете код для её формирования — меняйте во всех местах.
только не надо путать понятие «изменить» — изменить код, и изменить значение/отображение в рантайме.

Табличка хтмл с сервера клиенту

Семейство методов для вставки HTML/элемента/текста в произвольное место документа:
elem.insertAdjacentHTML(where, html)
elem.insertAdjacentElement(where, element)
elem.insertAdjacentText(where, text)

изучайте что можно вставить/изменить
В таблице из десятка столбцов и сотен строк меняется одна ячейка — что за html у вас придёт на сервер?

по месту — я могу изменить весь элемент
 <td>...</td>

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

Ну то есть пойдете отдачу бекенда править?


по месту — я могу изменить весь элемент

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

0
Ну то есть пойдете отдачу бекенда править?
Для вас это проблема? Для меня — нет.
Вас не спрашивали, что вы будете менять, вас спросили, что с сервера придет. Так что?
с севера может придти как строка html содержащая
 <td>...</td>
так и строка содержащая
<tr><td>...</td><td>...</td>..... </tr>
а также «координаты» места вставки/замены как это всё будет упаковано а ответе сервера — вариантом море, в том числе и json.
А также и просто данные для замены чего-либо конкретного в этой ячейке. надо смотреть по конкретному случаю.
0
Для вас это проблема? Для меня — нет.

Конечно это проблема, ведь фронтенд-программист при вашем подходе не сможет жирным шрифтом текст выделить.


с севера может придти как строка html содержащая

Я верно понимаю, что если в вашей таблице 100 строк то вы делаете 100 запросов, каждый из которых возвращает одну строку таблицы, каждую из которых вы создаете отдельной нодой и добавляете? Или вы склеиваете эти строки и создаете потом таблицу цельной нодой? Или вы получаете с сервера всю таблицу одним запросом, а когда надо что-то поменять — парсите ответ сервера, смотрите что изменилось и точечно изменяете нужную строку? Какой из вариантов?

-1
Конечно это проблема, ведь фронтенд-программист при вашем подходе не сможет жирным шрифтом текст выделить.
а причём здесь фронтенд-программист? Я фулстек-программист. Я сам решаю, что и где проще сделать.
Ни один из перечисленных.
Как один из примеров: есть таблица при клике по строкам её — обновляется див, который содержит ещё одну таблицу. При клике на сервер отправляется некий id, по этому id хранимка выбирает данные (~35полей, N строк) по этим данным серверное приложение строит html строку всей таблицы и передает клиенту, клиент вставляет её через innerHTML. 30 полей этой таблицы редактируемые.
Есть группа полей. При изменении поля в ней, не сервер передаётся соответствующий код, позволяющий серверу однозначно идентифицировать место записи в базу. от сервера идет ответ, который содержит среднее значение по этой группе в строке и среднее по всем строкам этого набора строк этих групп. Сервер отправляет это 2 ответами. Данные вставляются в таблицу. Для этого мне не надо парсить ни ответ ни таблицу — в сообщении от сервера есть идентификаторы куда вставить. Есть поля которые заполняются из файла .doc — в соответствующей ячейке кликается значок, загружается на сервер файл, парсится — в результате в базу записывается 7 полей и эти данные возвращаются клиенту — и просто вставляются как текст в нужные ячейки нужной строки.
Есть вариант когда при клике на кнопку с сервера приходит готовая строка таблицы, с уже заполненными data- атрибутами для идентификации изменений, вносимых в поля.
Если в моей таблице 100 строк — я из субд получаю результсет, содержащий все 100 строк и в цикле обрабатывая эти строки результсета строю html строку, которую и отправляю клиенту. мне не надо 100 запросов.
Когда я меняю значение в одной ячейке — я отправляю на сервер некий id, который однозначно идентифицирует место изменённых данных, и, в простейшем случае, после вставки в базу, сервер ничего не отвечает. Если есть необходимость — от сервера приходит ответ парсится — извлекаются «координаты» изменённой ячейки и текстом вставляются данные — Это можно трактовать как ваше: " смотрите что изменилось и точечно изменяете нужную строку"но это только один из возможных вариантов.
Это получается элементарная CRUD система.
0
а причём здесь фронтенд-программист? Я фулстек-программист. Я сам решаю, что и где проще сделать.

То есть работать с вашим проектом сможет только фуллстек. Это явно не плюс.


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


До кучи добавим мобильное приложение, которое выводит строки таблицы в виде списка элементов с определенной версткой, естественно в этом случае в качестве данных используются только некоторые предопределенные столбцы.


Как у вас чего и сколько в этом случае сервер возвращает?


К слову при классическом SPA-варианте сервер по сравнению с предыдущим случаем (просто обычная табличка) даже трогать не придется, будет вполне достаточно одного запроса, который там и был реализован.


Если есть необходимость — от сервера приходит ответ парсится — извлекаются «координаты» изменённой ячейки и текстом вставляются данные

То есть вы вручную делаете то, с чем фреймворки прекрасно справляются автоматически.

-1
То есть работать с вашим проектом сможет только фуллстек. Это явно не плюс.
не надо делать резких выводов. всё можно разбить на части. как вдоль так и поперёк.
Давайте немного усложним пример — допустим, нам надо выводить таблицу в двух форматах. Первый — полный, со всеми полями, ширина по контенту, в таблице присутствует внутренний горизонтальный скролл (т.к. в экран она не влазит). Второй — краткий, отображаются только избранные столбцы, скролла нет, ширина столбцов — проценты от области. Режим переключается чекером, там же мультиселект со столбцами, позволяющий выбрать отображаемые в кратком виде столбцы.
вариантов несколько — как формировать две различные таблицы(или N таблиц) или по условию в формировании htm строки таблицы выводить только нужные столбцы. надо смотреть по месту и выбрать оптимальный. Проблем не вижу.
До кучи добавим мобильное приложение, которое выводит строки таблицы в виде списка элементов с определенной версткой, естественно в этом случае в качестве данных используются только некоторые предопределенные столбцы.
можно фантазировать сколько угодно, реальные условия/данные ограничат варианты. Будет конкретная задача — будет решение. Делать что-то универсальное — палки самому себе в колёса.
То есть вы вручную делаете то, с чем фреймворки прекрасно справляются автоматически.
есть два пути либо решение задачи подстраивается под fw, либо пишется код под оптимальное решение задачи. Я выбираю второй путь — мне это не сложно. Как строятся велосипеды чтоб заставить fw сделать нужное для конкретной задачи — примеров куча.
SPA или не SPA — по большому счёту не отличается.
можно просто тем же html через inner HTML обновлять полностью body. которые брать из html файлов. а можно и как ещё.
Как аналогию могу привести 1c — нормально развивающаяся контора имеет вторую внутреннюю систему учета заточенную под свои производственные процессы(ту же 1с перепиливают под это), либо подстраивает свою работу под одну из конфигураций 1с.
первый вариант — обеспечивает развитие, второй — мучение…
Затраты на изучение чистого js html css3 равносильны по изучению fw, но с мощью wf — строятся панельные дома, а с помощью js html css3 — дворцы. Выбор за вами. Я выбрал дворцы. Мне не сложно сделать это. От проектирования проекта, до запуска продакшена. я спокойно могу разделить проект на части и отдать часть фулстек прогеру/ам.
0
не надо делать резких выводов. всё можно разбить на части. как вдоль так и поперёк.

Ну вот мы конкретный пример рассмотрели, и чтобы жирным шрифтом кусок текста выделить надо фуллстек-программиста звать.


надо смотреть по месту и выбрать оптимальный.
Будет конкретная задача — будет решение. Делать что-то универсальное — палки самому себе в колёса.

Ну вот видите, вам надо что-=то смотреть, какие-то проблемы решать. А в случае со SPA-подходом у вас есть один запрос к серверу, который отдает конкретно данные — и на этом все, ничего выдумывать не надо. Как эти данные отображать — ответственность клиента, сервер не трогаем. Вы не видите тут очевидного преимущества?

0
Есть проект, где в при изменении/добавлении любого поля (происходит в отдельном модальном окне) оказалось выгоднее просто перегрузить всю таблицу
-1
по всем. Вставка/изменение в базе, запрос и получение всего набора данных — отработано, если редактировать поэлементно — на клиенте — добавляется столько кода…
и на серверной стороне тоже до фига. Этот код надо написать и отладить… Ежели просто повторить вставку всей таблицы — ничего нового не требуется… А время на запрос и формирование — минимально, на код и время на клиенте — и того меньше..
вот такая
image
0
Вы непоследовательны. Сначала вы утверждаете, что нужно любой ценой выносить формирование html на сервер, наплевав на усложнение кода и увеличение стоимости поддержки — а теперь вдруг приводите аргумент «если редактировать поэлементно — на клиенте — добавляется столько кода».

Лучше просто признайте, что вам серверный рендер нравится больше клиентского — и прекращайте спор, потому что о вкусах спорить не следует.
0
не надо передёргивать — даже если я пришлю с сервера новую сформированную html строку, я не смогу её просто так вставить, мне придётся проанализировать соседние строки и внести в них правки. а это код на клиенте.
Собственно я не спорю. Это вы спорите с fw, VK, которые используют серверный рендеринг где это выгодно и не парятся. если в вашем понимание серверный рендеринг это только первая выдача страницы, то такого понятия нет как минимум в построении страниц jsp, хотя все страницы строятся в java коде.
И да, мне это нравится, потому что возможности огромны и всё просто.
0

Ну и какой из вас фулстек, если вы боитесь кода на клиенте?


Это вы спорите с fw, VK, которые используют серверный рендеринг где это выгодно и не парятся.

Нет, мы спорим с тем что это априори самый лучший вариант, а все кто используют клиентские фреймворки — делают все неправильно.

0
не надо передёргивать. Я не боюсь кода на клиенте. Я ненавижу лишний код . Если я могу сделать это проще на сервере — будет сделано на сервере.
Нет, мы спорим с тем что это априори самый лучший вариант,
на клиенте это самый простой, наглядный, быстрый вариант.
все кто используют клиентские фреймворки — делают все неправильно.
этого я не говорил, и все fw используют серверный рендеринг, там где это выгодно.
Мне просто не нравятся fw, своими ограничениями, выгоднее потратить время на изучения js, html, css. возможностей будет больше.
0
А я ненавижу, когда программа тормозит. Что дальше?
Я добиваюсь, чтоб не тормозила — фронтенд+бэкенд+бэйзенд --> минимум(именно сумма)
0
Это противоречит вашему решению каждый раз перезагружать таблицу.
0
… позволяет снизить нагрузку на сервер ...


Как раз генерация HTML на клиенте очень-очень здорово позволяет ее снизить. Генерация HTML вообще может быть самой дорогой операцией в приложении. А если притянуть сюда, скажем, генерацию изображений, то еще и основным потребителем сети. Ну например, масштабирование/обрезка изображения перед загрузкой на сервер. Или построения графика по табличке с данными. Arduino застрелится такое сделать. И «нормальный» сервер застрелится при определенном (не очень большом) числе пользователей.

И вы почему-то смешали отчуждение уровня отрисовки (что делается, в том числе, c помощью AJAX/json) и решение проблемы большого числа запросов к серверу (websockets).
+3
Ajax заменяется веб-сокетом? Серьезно??

элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.


Похоже на одурманенность хайпом, уж не знаю каким. Вебсокет или шмебсмокет, json или неджсон — какая половая разница, если это всего лишь транспортный протокол и текстовый формат? Когда инструмент становится фетишем — смешно же. в идеале ни фронт- ни бэк- программист вообще не должен думать о транспорте и сериализации, а должен думать о задачах бизнеса. Из ваши комментариев видно, что вы понятия не имеете об rpc фреймворках Thrift и grpc — а зря. В серьёзных проектах либо они, либо им подобные решения, которые выбирает тех.лид, затем вся команда использует явочным порядком. А вы тут втираете сказки про websocket vs ajax, тот ещё bubble effect.

Вебсокет между прочим в большинстве задач гораздо хуже ajax хотя бы уже тем, что он сложнее. А где именно и что рендерить — html на сервере или dom в браузере — это совсем уже зависит от задачи, и тут ещё более смешно кому то навязывать что-то в качестве универсального решения.
-5
Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket?
Просто для любителей старины и для совместимости со старыми наработками.
+3

У вас очень специфическое представление как о частностях (Ajax, WebSocket, data-flow), так и в целом об front- & backend разработке.

-1
может просто это Ваше мнение? У меня большой опыт (с начала появления ) websocket, я наслышался о не нужности и пагубности ws, но время показывает, что все переходят на них. И нет ни одного аргумента, чтоб перейти на ajax и его производные велосипеды. Одно то, что это фулдуплекс, говорит о многом. Я могу из любого места серверного кода отправить данные нужному клиенту. это просто. Приведи пример что может ajax и неможет ws, обратного же куча.
И да использование ws меняет подход к веб проектам, тем кто привык к ajax это кажется не привычным, не правильным. Но это раскрывает огромные перспективы если понять и научиться работать с ws. У меня есть свои наработки, свои решения, которые позволяют использовать ws широко, просто, удобно.
0

Кажется у вас просто большой опыт с websocket, но очень специфический опыт с web в целом. Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьям. Воробья подстрелить можно, но зачем? Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly. И не забыть сделать offlne-версию всех своих продуктов.


У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.

-1
Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьям
это заблуждение, на самом деле это намного проще чем ajax.
Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly.
я к этому стремлюсь. Если есть опыт — прошу поделиться.
У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.
могу согласиться, но у меня корпоративные порталы, где persistance connection как основа. С другой стороны если есть проверенные наработки с ws, почему не заменить ими ajax? и клиентская сторона и серверная получаются простыми, ни чуть не сложнее чем с ajax.
+5

Я не буду вас переубеждать. Скажу проще вы очень сильно заблудились в своём познании web-а. Вероятно вы на 99%+ самоучка. Вам стоило бы рассмотреть возможность очной работы в крупной продуктовой компании, в команде более опытных коллег.

+3
Скажу проще вы очень сильно заблудились в своём познании web-а. Вероятно вы на 99%+ самоучка.
Такое же впечатление, да. «Синдром самозванца» наоборот :)
+4

Хм, а вебсокеты умеют в request-response flow? Понятно, что эмулировать можно, но по дефолту?


А перестраивать всю архитектуру под двунаправленные серверные потоки данных — это намного сложнее, чем AJAX.

0

И главное — придется забыть про хранимки в СУБД, ибо они не умеют в нормальные двунаправленные потоки данных :-)

+25
А мне нравится фуллстек. Да, я точно так же осознаю, что нельзя «объять необъятное», но меня это никак не смущает. Ровно как и «не помню про IDisposable без гугла» (кстати, не помню, ага). Я вообще много времени провожу в гугле при разработке чего-либо. Мне нравится учиться. Нравится смотреть, как программируют другие, нравится думать и сравнивать, почему вот этот подход лучше вот этого.
Никогда не считал зазорным спросить совета у более опытного разработчика в текущей технологии, не испытываю по этому поводу никаких комплексов.

Я тащусь от того, что в общем-то не ограничен языком или платформой. Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.
И так далее и тому подобное.

Да, я совершенно точно уступаю синьору в любой из этих платформ, в некоторых областях даже с натяжкой могу назвать себя «миддл» (а скорее «продвинутый джун»), но черт возьми… Это настолько удобно и комфортно, что даже не знаю с чем сравнить!

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

0
могу только отказаться от второго абзаца, просто не было необходимости, а остальное как с меня писано :)
+2
Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.

Что у вас за место работы, если приходится вот так вот скакать по технологиям? Или вы фрилансер?

+13
Не совсем фрилансер. Просто за 20+ лет кодинга за деньги я наработал весьма солидную базу клиентов и (самое главное) — некий авторитет («широко известен в узких кругах»), благодаря которому не мне нужно искать клиентов на свои поделки, а наоборот, всегда стоит очередь на мои услуги. Уже закрытые и сданные как правило ничего не требуют, но есть десятка полтора, которые время от времени обновляются («на обслуживании»). За деньги конечно.

Кому-то нужен крайне специфический внутренний продукт (например, ПО для расчетов ТТХ изготавливаемой арматуры в мобильничек или «микро-CAD» для расчетов прочностных характеристик всяких специфичных железяк (на этом проекте я не осилил матан, поэтому понадобилась помощь зала, хех)). Здесь обычно рулит дотнет.

Кому-то нужен специфичный сайтик (не визитка, не интернет-магазин, и не шаблон WP/Drupal/итп, такое я не беру, неинтересно). Здесь как правило PHP/JS/CSS/HTML. Если нужен специфичный дизайн, то я привлекаю стороннего покемона (с художественным развитием у меня не очень).

Иногда приходится делать продукт для интранета (с подъемом серверов, блэкджеком и прочим).

И в чужих древних разработках (пресловутые Делфи/VB/CBuilder лохматых годов) приходится покопаться — ПО написано 20 лет назад, поддержки уже давно нет, а поменять что-то нужно (чаще прикрутить что-то к чужому коду быстрее и дешевле, чем переписать заново, проекты попадаются далеко не уровня «hello, world»).

Linux — это больше хобби, но случалось несколько раз писать за деньги и под него.

Почему я, а не «команда проф. разработчиков»? Потому что малый и средний бизнес как правило не понимает 90% того, что лидеры/«эффективные менеджеры» этих команд им говорят, и (главное) не тянут по финансам.

Скажем, переговоры по «микро-CADу» с разными командами заняли в итоге 4 месяца(!) и цены на готовый продукт начинались от 5 млн (в рублях разумеется), со временем разработки в 4-6 месяцев.

Я не особо напрягаясь сделал чуть больше, чем за квартал и за миллион. При этом вечерами ведя пару мелких проектов.
Не потому, что я круче упомянутых команд, а потому, что я мог по 2-3 дня подряд ничего не писать, а ходить хвостом за инженерами, для которых этот продукт делался.
Узнавать, что им нужно, помимо унылого ТЗ, как будет удобно, как вообще это работает с их точки зрения.
В результате, как минимум треть ТЗ ушла в помойку, а процесс разработки ускорился невероятно из-за того, что отпала необходимость реализовывать ненужные фичи, которые «вроде как нужны», но на самом деле никто их никогда бы и не использовал.

В общем, такой подход к разработке — это еще один очень важный скилл в жизни fullstack :)
+2
Ну я бы сказал, что это уже не фуллстек-девелопер, а скорее фуллстек-вообще. Здорово, когда человек никому ничего не доказывает, а просто делает работу и понимает, для кого он ее делает. Респект вам.
В среднем по больнице, к сожалению, как и любые титулы, этот скорее связан с фаллометрией и используется далеко не во благо.
0
Напишите публикацию, хочу поднять вам карму (а без публикаций +4 это максимум)
+1
Публикацию «Почему быть фуллстеком клево»? :)
Если народу будет интересно, почему бы и нет? :)
0
Да, это должно быть занятно. Заодно холивары переедут отсюда туда)
+1
Вот такой подход — идеальный для найма.

Во-первых если сотрудника есть представление о разных технологиях, то по крайней мере есть возможность выбрать ту, что подходит лучше, а не лепить в очередной раз на том что умеет, но оно точно не работает. Если бизнесу нужен совет о технологии — то разработчик может его дать.

Во-вторых если может в одиночку тянуть некрупный проект — то значит не надо тратиться на лишних менеджеров, а значит на целую кучу организационных активностей (собрания о собраниях и о том как их правильно проводить). Кроме того если проект ведется одним разработчиком (лучше все-таки двумя для High Availability), то не требуется даже формальный SDLC, разве что некоторое количество инструментов.

В целом не знаю как там насчет синьора, но эти навыки по крайней мере по моей субъективной шкале стоят выше чем доскональное знание всех стандартных хранимых процедур того же Sql Server. Приоритет — это сделать софтину, а не родить инженерный шедевр.
0
Согласен. Если ты занимаешься беком, то и в фронте должен хоть немного, но соображать и наоборот. Хороший инженер должен хоть немного но разбираться в смежных технологиях.
Я не встречал спецов которые знают только Java.Обычно спец идет под стек, кругозор и умение мыслить нужными категориями — определяют.
Страшно представить сферического Java кодера который 10 лет занимается только чистой Java и Spring_ом не зная ничего о фронте.
+2
Увы, такое не редкость. Доводилось работать с людьми 15 лет занимающимися postgresql и ничем больше (не потрудившимися даже выяснить, что существуют системы контроля версий), с теми кто 10 лет пишет одно приложение на ASP.NET и не замчает то, что мир несколько изменился за это время. Недавно с проекта у нас ушел человек, толковый но вбивший себе в голову, что хочет работать только с CRM Dynamics, не хотел смотреть ни в сторону SalesForce ни в сторону разработки ни devops.

+3
Приоритет — это сделать софтину, а не родить инженерный шедевр.

Именно так.

Кстати, когда я начинал свой путь (это когда за деньги), то разумеется смотрел, как это делают другие корифеи.
Поначалу меня всегда удивляло, что узкоспециализированное ПО (для одного человека или небольшой группы/команды) имеет «убогий дизайн».
Ну реально, вместо лаконичного и «уже вроде как привычного» от билгейца — какое-то малопонятное со стороны нагромождение UI-элементов, хоткеев и вообще, без бутылки не разберешься (под DOS вообще были шедевры почище vi).

Однако, после нескольких попыток нести в массы «правильный» интерфейс, начало приходить понимание, что это все явно неспроста, а заточено именно под упомянутого пользователя или группу.

Первым проектом после осознания факта, что узкоспециализированное ПО должно быть в первую очередь функциональным и удобным, а только потом «красивым», была система учета/управления библиотекой (заведение с бумажными книгами) под винду (год 98й однако был).
После изменения «красивенько» на «удобненько», приложение приобрело несколько страшноватый вид, но скорость работы трех девчонок повысилось где-то в 5 раз.
Т.е. UI было сделано так, как им было удобно. Хоткеи такие, какие им были удобны. Каждое движение, каждое нажатие было максимально функциональным — от автодобавления строк, до сортировок и сохранения.

Скажем, ну кто бы мог подумать, что девчонкам удобно нажать Ctrl+T n раз (режимы сортировок) и чтобы она (сортировка) не менялась в основном окне, а всплывало поверх формы, не загораживая основной список и висело там до тех пор, пока хоткей зажат?
Да в жизни бы до такого не догадался, а девкам, подсказавшим, как им было бы удобно ну очень нравилось — кинули взгляд, ага, здесь то, а здесь то; отпустили хоткей и дальше работать. На все про все уходило в пределах 1-2с, когда при «обычной» сортировке (когда все в одном списке) приходилось листать по 10 (а то и 30с), да еще запоминать большие объемы данных, т.к. перед глазами не было предыдущих данных.

И таких нюансов при плотном контакте с будущими пользователями — вагон и две тележки сверху.
ИМХО, только такой подход реализует тезис «вам шашечки или ехать» :)
0
До такого действительно невозможно додуматься самостоятельно. А как сами девочки к такому решению пришли? Из какого-то старого ПО приползло?
0
Нет, это сугубо их идея. Простая как три рубля, внезапная, как понос :)
Что-то вроде того:

— Слух, а можно сразу две сортировки делать?
— Это как и зачем?
— Ну я вот тут смотрю, а когда переключаю, нифига не понимаю, что и откуда. Как-нить можно сразу и такую и такую?
— [сразу начинаешь думать, как перекроить UI, чтобы еще что-то влезало, на 14" с 1024х768 особо не разбежишься, а один из трех мониторов вообще в 800х600 только умеет] Ээээ… Нууу… А куда ее вставить-то тут, без того экран занят?!
— Да не надо вставлять, пусть тут [тык в экран пальцем] квадрат вылазит с ней, пока держу клавиши и все.
— Бинго!


Ровно как и перенести режимы сортировок на одну клавишу (слепым методом печати они не владели, т.е. куча хоткеев для одного и того же было для них не очень удобным решением).
А в таком виде (Ctrl+T) — клац = одна сортировка, клац-клац = другая, клац-клац-клац = третья…

А уж сколько денег было поднято на простецкой проге для сдачи данных/отчетов в налоговую до прихода в массы «1С Налогоплательщик» (да и после тоже, т.к. скорость внесения данных в мою поделку была без преувеличения на пару порядков выше)…
И все это благодаря тому, что кривенький и косонький UI был на самом деле выверен до последнего тыка в клавиатуру, все заточено под максимальную скорость ввода.
Закончилась лафа с этим ПО только после внедрения на предприятия и частникам всевозможных «Бухгалтерий», «Кадров», где эти отчеты формировались на автомате.
+2

Все смешалось в доме Облонских: стеки, языки программирования, доменные области. Не понятно на счет чего именно из этого вы пишите.


Во взять, например, только языки.
Есть, условно говоря, три класса языков: нативные (c и c++) — очень близко к профессору, высокоуровневые ОО (java, c#, scala, kotlin), высокоуровневые функциональные (f#, haskel). Можно еще, скажем выделить высокоуровневые небезопасные (python, javascript).
Внутри класса языки очень легко менять. Основное время должно уходить не на чтение спеки, а на познавание тулов окружающих язык (они то точно сильно разные). Но это все при условии, что вы пробовали писать на этом языке уже когда-то. Переключение между языками из разных парадигм больно и дорого. Мозгу нужно выстроить синоптические дорожки...


Вообще работать одновременно на разных языках — это очень интересно. Это расширяет кругозор невероятно. Никогда не интересовались, как получилось, что Java стала таким говном? А мне это очевидно (как и то, что Java — говно, как язык) — программисты, создатели языка и пользователи, не смотрели по сторонам и не увидели что происходит в C#, когда они поняли что надо пилить фичи, то уже было слишком поздно — народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам.
И много такого. Обладая таким опытом можно предсказать куда идет развитие. Тот, что в Scala и C# появится enforced null safety, тем кто пробовал на F# было понятно очень давно. В C# уже объявили и в Scala тоже будет.

0
На сколько знаю он ОО, точно высокоуровневый — нет управления памятью. Как там с контролем типов во время компиляции? Раньше не было и это делало его небезопасным языком — без отрицательной коннотации, просто надо другие практики использовать — тотальное покрытие тестами… А как в современном PHP даже и не знаю.
0
Контроля типов практически не было кроме ручного, сейчас есть времени исполнения на уровне сигнатур функций/методов, обещают завезти на уровне свойств.
0
Ну как бы тогда небезопасный. Нужно тотальное модульное тестирование. Это не хорошо и не плохо, но требует от мозга изменения подхода скорее всего на test first, потому как иначе не выжить. Поэтому переключения скажем C# <-> PHP не будут гладкими. В C# мы доверяемся компилятору и забиваем тестировать автоматизированными модульными тестами очень часто, зато больше тратим времени на проектирование системы типов в явном или неявном виде.
0
Ну как бы тогда небезопасный. Нужно тотальное модульное тестирование. Это не хорошо и не плохо, но требует от мозга изменения подхода скорее всего на test first, потому как иначе не выжить.

Замена типизации тестами — самое глупое решение, которое вообще можно себе представить. Лучше на динамике вообще не писать в таких случаях.

-1

Это ваше личное мнение, или можете привести результаты исследований? :)

+1
Это ваше личное мнение, или можете привести результаты исследований? :)

Исследований чего? Просто сама идея о том, что типы заменяются тестами говорит, что человек не умеет в статику. А если человек не умеет в статику — то в динамику он не умеет и подавно, до динамики его вообще допускать нельзя.

0

Возможно вам будет интересно: Ideology — там как раз рассматриваются эти точки зрения (что статическая типизация и тесты могут заменять друг друга)

+3

Всё зависит от требований. Я предпочитаю тестировать логику, а не что будет, если в метод передадут целое вместо строки.

0

Да, в принципе, я тоже больше использую функциональные модульные тесты, чем просто формальные модульные.
Но тем не менее, без статической типизации надо покрывать тестами намного больше, чтобы код был поддерживаемым, иначе вносить изменения очень дорого.

+2
функциональные модульные тесты, чем просто формальные модульные.

ммм… не поделитесь определением? Что есть что?

+1

Формальные тесты проверяют корректность API: принимают ли методы/функции задекларированные типы аргументов, что возвращают, что получается если передать "неправильный" тип данных, и т.д.


Функциональные тесты проверяют что код делает. Нажали на кнопку, получили результат. Тот результат или не тот? И т.д.

0

Исходя из вашего определение мне кажется что под "формальными тестами" мы подразумеваем проверку сходятся ли типы. "формальные модульные" явно что-то другое.

0
Официальная наука говорит, что есть тесты: модульные и функциональные (еще есть интеграционные и приемочные). Модульные — слишком низкий уровень, зато исчерпывающий, функциональные — очень высокий уровень. Мне кажется, что наиболее полезный подход — что-то среднее между этими двумя.
Еще не на уровне UI, но выше уровнем чем тесты на отдельные методы/функции. Тесты на всю подсистему, на реализацию абстракции в системе. Модульные-модульные тесты в больших системах часто скатываются в какие-то проверки что конкретные методы были вызваны. Они не проверяют функциональность, они проверяют, что какие-то методы были вызваны с правильными параметрами — слишком много знаний о внутреннем устройстве кода утекает. Такие тесты дороги в обслуживании, замедляют рефакторинг…
Скажем, в микросервисах, я не пишу тесты на код внутри сервиса, а тестирую микросервис как black box — снаружи, через его API (HTTP) и использованием fake других сервисов и очередей, если надо.
0
Официальная наука говорит

когда говорите "наука говорит" приводите источники, иначе это вы говорите а не "наука".


модульные и функциональные

то есть модульные тесты не проверяют функциональность? Ну и интеграционные тесты не являются функциональными? Чем тогда приемочные от ваших функциональных отличаются? И можно ли делать приемочные тесты не со стороны UI?


Мне кажется, что наиболее полезный подход — что-то среднее между этими двумя.

Мне нравится что вы начали комментарий с фразы "наука говорит".


Они не проверяют функциональность, они проверяют, что какие-то методы были вызваны с правильными параметрами

если они проверяют какие методы были вызваны с какими параметрами и в какой последовательности — ваши тесты дублируют реализацию и их можно в целом удалить, они пользы не несут.


слишком много знаний о внутреннем устройстве кода утекает.

Это говорит о том что дизайн нашего кода такой, что провацирует подобное. Обычно — из-за большого количества зависимостей (попробуйте перегруппировать код таким образом, что бы уменьшить количество оных).


а тестирую микросервис как black box — снаружи

Немного накину: J B Rainsberger — Integrated Tests Are A Scam

0
Но тем не менее, без статической типизации надо покрывать тестами намного больше, чтобы код был поддерживаемым, иначе вносить изменения очень дорого.

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


Можете привести примеры, когда статическая типизация помогла вам провести логический рефакторинг когда без наличия существенного тестового покрытия? Честно не флейма ради, мне правда интересно.

0
Можете привести примеры, когда статическая типизация помогла вам провести логический рефакторинг когда без наличия существенного тестового покрытия?

Ну вот есть у меня сущность Х, в ней поле Y, я его переименовал на Z. В статике мне сразу все ошибки покажет (вообще говоря, в статике этот рефакторинг будет сделан автоматически даже), без каких-либо тестов.

0
Блин, ну вы банально пишите где-то: myobj.myMethod. В динамических языках этот код может упасть банально потому что нет такого метода. Поначалу, пока система маленькая — это не очевидно. Но как только надо переименовать что-то, что используется 500+ раз по всей кодовой базе, то начинается самая веселуха. Это мы просто про имя метода говорим, а есть еще типы параметров. Из-за изменения типа одного параметра может получить много ошибок в рантайме без предупреждений. Все покрывающие тесты спасают от подобных косяков.

В то же время строгая типизация ооочень сильно продвинулась за последние годы: generics — это вобщем-то тоже был шаг в сторону более полной строгой типизации, но с тех пор у нас добавилось (в зависимости от языка): enforced null-safety, pattern matching by type, conditional types, discriminated unions. При этом сами типы писать не надо (почти) — как в питоне…
0
Блин, ну вы банально пишите где-то: myobj.myMethod.

Спасибо за пример, но пока не убедительно. Я просил привести случаи, когда именно строгая типизация помогала при рефакторинге логики. Отсутствующие методы и прочие тривиальные случаи не являются адекватным примером, т.к. легко закрываются статическими анализаторами кода даже при слабой типизации, не говоря уже о тестах.


С тем, что хорошее покрытие тестами спасает от таких проблем, я спорить не собирался. Я вообще с вами не спорю, а пытаюсь (в очередной раз) узреть свет истины в строгой типизации. Пока не очень получается, т.к. все приводят банальные примеры в стиле: ну вот мне надо поле в объекте поменять, типизация меня спасёт. Чего-то более убедительного я пока не видел, а когда начинаешь копать, всё сводится к тёплому ламповому ощущению безопасности (Type safety? Отличный маркетинг).


В то же время строгая типизация ооочень сильно продвинулась за последние годы

Это всё хорошо и замечательно, но не показывает, зачем всё это нужно.

0
Спасибо за пример, но пока не убедительно. Я просил привести случаи, когда именно строгая типизация помогала при рефакторинге логики.

У вас был метод, который что-то вычисляет и возвращает значения типа X. Вам пришлось по тем или иным причинам поменять эту логику и при этом теперь метод может иногда бросаться наллами, типа, не получилось вычислить. Естественно, теперь везде на call site должна быть добавлена проверка на null'ы — вы меняете возвращаемый тип с X на X | null и теперь код не скомпилируется, если где-то есть непроверенные места.


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

Вы врете. Все существующие анализаторы справляются с задачей от "чуть лучше чем никак" до "ужасно" и как-либо полагаться на них нельзя в принципе.


С тем, что хорошее покрытие тестами спасает от таких проблем, я спорить не собирался.

А с типами никакого покрытия тестами не надо. Код с указанными проблемами просто не компилируется.


Это всё хорошо и замечательно, но не показывает, зачем всё это нужно.

Очевидно, за тем, чтобы не писать (и потом не выполнять регулярно) тысячи строк кода с:


Формальные тесты проверяют корректность API: принимают ли методы/функции задекларированные типы аргументов, что возвращают, что получается если передать "неправильный" тип данных, и т.д.
0
Естественно, теперь везде на call site должна быть добавлена проверка на null'ы — вы меняете возвращаемый тип с X на X | null и теперь код не скомпилируется, если где-то есть непроверенные места.

Спасибо, это убедительный пример. Зерно сомнений продолжает расти.


Вы врете.

Давайте на полтона ниже, хорошо? И можно не так авторитативно, меряться длиной бороды мне недосуг.


А с типами никакого покрытия тестами не надо.

Это очень распространённое мнение, но, на мой взгляд, весьма ошибочное. Смысл тестирования вовсе не в том, чтобы заменить строгую типизацию. Правильно написанные тесты выполняют как минимум три основные задачи:


а) Документирование ожиданий
б) Проверка правильности исполнения в нужном контексте (для front end, в конкретных браузерах)
в) Защиту от регрессий


Отлавливание мелких проблем с типизацией это дешёвый побочный эффект хорошо написанных функциональных и интеграционных тестов. Формальные тесты в таком случае тоже обычно излишни, т.е. писать их и так и этак не надо.


Очевидно, за тем, чтобы не писать

Это тоже очень распространённое мнение, и, на мой взгляд, настолько же ошибочное. Смотрите:


  • Рефакторинг становится не только возможным, но и вполне лёгким, когда вы можете менять любой код в системе, зная что тесты будут падать, если что-то не так. И даже в тех случаях, когда компилятор пропустит.
  • Наличие работающего набора тестов позволяет легко решить проблему с устранением дефектов: пишем тест, который падает без фикса, и проходит с фиксом. Со временем такие тесты становятся просто незаменимыми для учёта различных пограничных случаев при рефакторинге.
  • На базе набора тестов с достаточным покрытием можно внедрить разные продвинутые механизмы динамического QA, статическим анализаторам и компиляторам просто неподвластные.

Если вы доведёте вышеизложенные мысли до логического конца, то увидите: писать тесты надо нипочему. Вне зависимости от наличия или отсутствия строгой и/или статической типизации.


А вот когда правильный упор на тестирование делается изначально, то статическая типизация оказывается… Не жизненно необходимой. Ну вот просто, зачем? Это я и пытаюсь понять.


(и потом не выполнять регулярно)

А вот это уже мелочи, извините. Вам не всё равно, что именно выполнять, компиляцию или тесты?

0
Это очень распространённое мнение, но, на мой взгляд, весьма ошибочное.

Речь не об отсутствии покрытия тестами в принципе, а об отсутствии покрытия тестами вида "ф-я принимает строку и возвращает число". В случае статики у вас гарантированно эта ф-я принимает строку и возвращает число, т.к. это указано в типах, если бы это было не так — код бы не скомпилировался. С-но тесты именно этого конкретного класса вам не нужны. Тесты, проверяющие логику работы — нужны, конечно.


Давайте на полтона ниже, хорошо? И можно не так авторитативно, меряться длиной бороды мне недосуг.

Окей, смотрите. Проблема даже не в том, что анализаторы плохи, проблема в том, что типичный динамикокод написан так, что его просто невозможно полноценно проанализировать. В коде просто нету достаточной информации.
Например, тот е Хиндли-милнер, когда увидит что в коде недостаточно информации, выдаст вам ошибку вывода и вам придется либо переписать код, либо дообавить аннотации. Анализатор динамики же просто вам скажет: "ну нишмогла, звиняй". По-этому можно, конечно, использовать, но надеяться на то, что они отработают правильно — нельзя. И чем больше у вас проект — тем больше будет встречаться кейсов, где анализатор обломается.


А вот это уже мелочи, извините. Вам не всё равно, что именно выполнять, компиляцию или тесты?

Тесты обычно на порядок медленнее компиляции.

0
Речь не об отсутствии покрытия тестами в принципе, а об отсутствии покрытия тестами вида "ф-я принимает строку и возвращает число". В случае статики у вас гарантированно эта ф-я принимает строку и возвращает число

Вот тут вы как раз и задели большую и интересную тему. Если вкратце и упрощённо: а зачем это гарантировать? Нет, погодите возмущаться, подумайте. От кода нужно, чтобы он делал что-то полезное: проценты какие-нибудь считал, или DOM элемент создал, или ещё что-нибудь. В подавляющем большинстве случаев конечный результат работы это строка. Если смотреть с этой стороны, то типы данных это не более чем внутренняя абстракция программы, инструмент для достижения каких-то целей. Почему этому инструменту придаётся такое большое значение?


Тесты, проверяющие логику работы — нужны, конечно.

Именно, в логике работы мы все и зантересованы. А проверяя логику работы, вам всё равно придётся вызывать эти функции/методы, передавать им какие-то данные, проверять вывод. Если ваша функция принимает число/строку/массив чисел, то вам имеет смысл написать тесты, проверяющие обработку результата вызова этой функции во всех этих случаях. Проверка собственно обработки типов в этом случае является побочной.


Проблема даже не в том, что анализаторы плохи, проблема в том, что типичный динамикокод написан так, что его просто невозможно полноценно проанализировать.

Моя теоретическая база могла устареть, но я откуда-то помню, что динамический код невозможно полностью проанализировать в принципе. И дело тут не в том, как он написан.


По-этому можно, конечно, использовать, но надеяться на то, что они отработают правильно — нельзя.

Вот тут, мне кажется, вы переводите вопрос в эмоциональную плоскость. Если отойти от эмоций и уверенности/обеспокоенности, то можно заметить, что динамический анализатор это такой же инструмент, как и все остальные: статическая проверка типов, тесты, и т.д. Динамические анализаторы не могут решить 100% проблем, равно как и остальные инструменты. Мы используем эти инструменты для уменьшения количества дефектов в программах, но добиться полной победы невозможно, поэтому надеяться на это тоже бессмысленно.


А с другой стороны, как всегда, вопрос стоимости того или иного инструмента. Стоимость внедрения, стоимость поддержки, ограничения — вот это всё. Плюсы против минусов.


И чем больше у вас проект — тем больше будет встречаться кейсов, где анализатор обломается.

Я очень часто слышу эту мантру: вот встретишь, мол, по-настоящему большой проект, тогда поймёшь. Давайте определимся, о каком размере речь-то идёт? Я уже приводил пример проекта на 1.5 млн строк в JavaScript. Написанных очень, очень опытными и профессиональными людьми, и весьма плотно. Это web framework, на котором построены высоконагруженные проекты, соответственно и требования к качеству кода намного выше, чем у обычного LoB приложения.


Исходя из опыта поддержки и развития этого проекта на протяжении 8 лет, я делаю вывод: не так страшен чёрт динамической слабой типизации, как его малюют. Точнее, вообще не страшен. Иногда бывают проблемы, но так редко и такие мелкие, что отказываться ради их решения от динамическ