Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Конечно накопятся разные проблемы, но тех, которые заложены в сами основы языков и культуры С/С++ точно не появятся.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
Это увеличит время вывода продуктов на рынок, но уже готовятся законодательные нормы, которые заставят поставщиков ПО серьёзнее относиться к безопасности.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
<input> заточен именно под это, особенно при правильной настройке.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
Из rich-вещей я написал на HTML аналог
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Но вопрос-то остается открытым — вы бы взяли себе такого кандидата?
Вопрос взять или нет кандидата определяет собеседование а не строчки в резюме/сопроводительном письме и если бы он (кандидат) его прошел и показал требуемый набор знаний то я бы его взял. Выше Вы пишете "Но самое интересное в конце в блоке «О себе» — готов бить лица за критику. Мы правильно поняли?" а если Вы все же неправильно поняли?
По крайней мере профессионализм по одной строчке в статье мы точно не определяем.
Простите но из Вашей статьи непонятно этот кандидат был отсеян на этапе чтения сопроводительного письма или уже после/перед прохождения собеседования? Дальше идет скриншот примера где сложно сказать в чем проблема и кто кому пишет? И самое главное непонятно в чем суть - начальник написал двум исполнителям которые что-то одно делают(или разное?) о проблеме и каждый из них написал что это не его ответственность? Это может быть как проблемой начальника и организации в целом так и проблемой исполнителей. Начальник вместо того чтобы разбираться просто матом послал первого из них разбираться, это может говорить и о том что исполнитель плохой и футболит и о том что начальник вместо того чтобы разобраться "кто виноват и что делать" просто ставит ультиматумы первому попавшемуся исполнителю. Я к тому что пример не коррелирует или слабо коррелирует с указание строчки в сопроводительном письме и определении кого то как нестабильного, нестабильность <> неисполнительность. Более того определить будет ли человек футболить или нет на работе невозможно просто читая резюме, да даже на собеседовании это вряд ли получиться определить, только когда он начнет работать это выясниться и то это может проявиться через время когда он успокоиться что не потеряет место или например если выгорит.
Я говорил о Вашем утверждении из статьи где Вы говорите что не будете менять стек. Не очень понятно причем здесь мое желание? Моя мысль в комментарии выше как бы намекает что если завтра измениться востребованность Вашего стека на рынке то с наибольшей вероятность Вам также придется переобуться на актуальную технологию просто чтобы быть востребованным на рынке.
Я уже не поменяю стек, ибо понимаю, что частые переключения стека могут привести к деградации опыта и обесценению навыков. В результате я могу оказаться менее востребованным на рынке труда, и потребуются годы, чтобы достичь того уровня, который у был до изменений.
Просиживание штанов в одном стеке наоборот приводит к "деградации" опыта и в один прекрасный момент этот самый стек может стать не актуальным что уже ударит по востребованности на рынке труда поэтому не все так однозначно.
Ну допустим мы используем голый SQL. Завтра меняется структура и что требуется сделать? Найти по поиску все места где использовались измененные таблицы и поменять заменой или руками и так каждый раз, так удобней работать?
Хорошо исключим из CRUD операцию R, выборка действительно может быть сложной. CUD у Вас как-то по особенному работает? Вы не через INSERT, UPDATE, DELETE его выполняете?
При использовании ORM мы обычно прописываем в коде сущности и их взаимосвязи, и по сути это — проектирование БД ещё раз (дублирование логики!) прямо в коде.
Очень странная логика. Вот Вы например когда хотите передать сложный JSON объект наверно создаете набор классов/структур которые его описывают, создаете его экземпляр, заполняете поля значениями а потом скармливаете сериализатору который из Вашего сложного объекта превратит в строку. Бесспорно Вы можете сформировать JSON в виде строки без использования всего этого но согласитесь что поддерживать первый вариант будет намного проще как Вам так и людям после Вас. Тоже самое и с ORM, по факту он обычный (де)сериализатор неких объектов в запрос и обратно. Вы можете использовать например odbc или драйвер базы напрямую но удобно ли это поддерживать? ORM это больше про удобство поддержки кода чем про удобство работы с базой. А если Вам не хочется ручками в базе что-то делать то как вариант можно использовать тулинг миграций например такой https://github.com/davedevelopment/phpmig
Борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Ты просто не можешь не знать, что у тебя под капотом происходит. Какие там делаются джойны и группировки.
Странно но это относиться к абсолютно любой вещи в разработке, просто замените заголовок на любой другой. Обычно ORM позволяет использовать сырые запросы на манер odbc, да даже просто никто не мешает использовать odbc в местах где требуется работать с сырыми запросами. Т.е. вполне можно комбинировать для простых CRUD-ов использовать ORM для всего остального сырые запросы. Если сырые запросы сложные то да библиотеки для генерации sql помогают.
Есть ещё такое мнение, что ORM — это слой, абстрагирующий от способа хранения. Мол, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь — и тебе пофиг, код остаётся тем же. Чистая архитектура.
Это слой абстрагирующий от использования драйвера базы данных или odbc напрямую. И да он полностью решает эту задачу. Способность перехода с базы на базу зависит не от ORM а от Вашего проекта и его потребностей, например использовали Вы gis модуль в бд а потом попытались перейти на другую бд в которой этого модуля нет или он работает как-то не так.
А почему он ищет записи там, если изначально знает что репорт может быть в разных таймзонах? ну то есть камон время на экране != время на сервере/в базе/логах/журналах.
Тут разница не в том где он ищет а в том что время которое он видит у себя на экране (в своей таймзоне) не равно времени которое на самом деле записано в базе (в UTC). И когда он хочет поискать по времени, например колонка с датой < конкретная дате и время, ему надо из времени которое он видит у себя на экране в уме перевести в UTC либо явно указать перевод в UTC используя сессию или прописать в запросе иначе он либо не найдет того что ищет либо найдет что-то другое.
Интересное исследование и интересные выводы но спешу Вас отговорить от поспешных переделок всех полей c timestamp на timestampz. Тип timestampz предназначен для случаев когда Вам надо видеть (именно видеть!) дату+время в какой-то часовой зоне (обычно своей но это не важно). И это как раз узкий кейс в то время как тип timestamp предназначен для всех остальных случаев когда нам нужна просто гипотетическая дата+время. Если Вам требуется точная система которая обеспечивает гарантии на что бы то ни было связанное с временными зонами то ни timestamp ни timestampz Вам это не обеспечат. По Вашей логике клиент не несет ответственности за ту таймзону которую он настроил в сессии, но это не корректное утверждение. Каждый клиент ответственен за то какую таймзону он настроил. Условный дядя не устанавливает же время на Ваших часах, да Вы можете подключить службу по синхронизации времени но опять же это будет Ваше осознанное решение. К тому же замена типов порождает уже другую проблему, как я и сказал выше тип timestampz предназначен чтобы видеть дату+время в каком-то конкретном часовом поясе. Дак вот предположим ситуацию: есть 5 сотрудников работающих с базой каждый работает в своей часовой зоне (или как мы выяснили из статьи даже просто в разных клиентах). Один из них тестер который нашел багу в двух полях с датами в мобильном приложении и снял скриншот в зоне -5 с ошибкой и зарепортил баг. Разработчик в зоне +5 получив баг решил воспроизвести проблему у себя и попытался найти записи с датами как на скриншоте но он их не нашел а чтобы найти их ему надо было бы выполнить пересчет дат из -5 в utc и написать field = utc_date но результат запроса он увидит в +5. Т.е. все операции такие как больше, меньше равно и т.п выполняются не по той дате которую ты видишь а по utc что требует от пользователя выполнения операций в уме. Я уж не говорю сколько будет матов сложены администратором который в зоне -10 когда ему потребуется выбрать всех пользователей которые что-то когда то сделали и выгрузить в отчет. Другая проблема приведение к какому-то часовому поясу может давать другую дату что может еще больше повысить когнитивный диссонанс. Что подводит нас к одной простой мысли, установка таймзоны это обязанность клиента а если это так то Ваш главный аргумент в пользу незамедлительного уничтожения полей с типом timestamp уже не выглядит таким уж весомым.
"Нет. GeForce now — скорее да, и то с некоторой натяжкой. MMORPG всё-таки позволяют кнопки в меню нажимать локальным кодом, а не вызовом сервера. "
Т.е. Backend-Driven UI это когда клиент просто "удаленный рабочий столприложение" который картинку приезжающую с сервера показывает? С клиента только точки где мышка проезжает отсылаются и какие кнопки на ней (мышке) нажимаются? Я все верно понял?
Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
"упрощая игру в игры" :) Игра в игру, новое измерение.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Вопрос взять или нет кандидата определяет собеседование а не строчки в резюме/сопроводительном письме и если бы он (кандидат) его прошел и показал требуемый набор знаний то я бы его взял. Выше Вы пишете "Но самое интересное в конце в блоке «О себе» — готов бить лица за критику. Мы правильно поняли?" а если Вы все же неправильно поняли?
Простите но из Вашей статьи непонятно этот кандидат был отсеян на этапе чтения сопроводительного письма или уже после/перед прохождения собеседования? Дальше идет скриншот примера где сложно сказать в чем проблема и кто кому пишет? И самое главное непонятно в чем суть - начальник написал двум исполнителям которые что-то одно делают(или разное?) о проблеме и каждый из них написал что это не его ответственность? Это может быть как проблемой начальника и организации в целом так и проблемой исполнителей. Начальник вместо того чтобы разбираться просто матом послал первого из них разбираться, это может говорить и о том что исполнитель плохой и футболит и о том что начальник вместо того чтобы разобраться "кто виноват и что делать" просто ставит ультиматумы первому попавшемуся исполнителю. Я к тому что пример не коррелирует или слабо коррелирует с указание строчки в сопроводительном письме и определении кого то как нестабильного, нестабильность <> неисполнительность. Более того определить будет ли человек футболить или нет на работе невозможно просто читая резюме, да даже на собеседовании это вряд ли получиться определить, только когда он начнет работать это выясниться и то это может проявиться через время когда он успокоиться что не потеряет место или например если выгорит.
Определение что человек нестабильный по одной строчке в резюме это признак профессионализма. Какие еще заболевания можно определить таким образом?
Я говорил о Вашем утверждении из статьи где Вы говорите что не будете менять стек. Не очень понятно причем здесь мое желание? Моя мысль в комментарии выше как бы намекает что если завтра измениться востребованность Вашего стека на рынке то с наибольшей вероятность Вам также придется переобуться на актуальную технологию просто чтобы быть востребованным на рынке.
Просиживание штанов в одном стеке наоборот приводит к "деградации" опыта и в один прекрасный момент этот самый стек может стать не актуальным что уже ударит по востребованности на рынке труда поэтому не все так однозначно.
Ну допустим мы используем голый SQL. Завтра меняется структура и что требуется сделать? Найти по поиску все места где использовались измененные таблицы и поменять заменой или руками и так каждый раз, так удобней работать?
Хорошо исключим из CRUD операцию R, выборка действительно может быть сложной. CUD у Вас как-то по особенному работает? Вы не через INSERT, UPDATE, DELETE его выполняете?
Просветите нас какой же способ не "панихида продуктивности"?
Очень странная логика. Вот Вы например когда хотите передать сложный JSON объект наверно создаете набор классов/структур которые его описывают, создаете его экземпляр, заполняете поля значениями а потом скармливаете сериализатору который из Вашего сложного объекта превратит в строку. Бесспорно Вы можете сформировать JSON в виде строки без использования всего этого но согласитесь что поддерживать первый вариант будет намного проще как Вам так и людям после Вас. Тоже самое и с ORM, по факту он обычный (де)сериализатор неких объектов в запрос и обратно. Вы можете использовать например odbc или драйвер базы напрямую но удобно ли это поддерживать? ORM это больше про удобство поддержки кода чем про удобство работы с базой. А если Вам не хочется ручками в базе что-то делать то как вариант можно использовать тулинг миграций например такой https://github.com/davedevelopment/phpmig
Странно но это относиться к абсолютно любой вещи в разработке, просто замените заголовок на любой другой. Обычно ORM позволяет использовать сырые запросы на манер odbc, да даже просто никто не мешает использовать odbc в местах где требуется работать с сырыми запросами. Т.е. вполне можно комбинировать для простых CRUD-ов использовать ORM для всего остального сырые запросы. Если сырые запросы сложные то да библиотеки для генерации sql помогают.
Это слой абстрагирующий от использования драйвера базы данных или odbc напрямую. И да он полностью решает эту задачу. Способность перехода с базы на базу зависит не от ORM а от Вашего проекта и его потребностей, например использовали Вы gis модуль в бд а потом попытались перейти на другую бд в которой этого модуля нет или он работает как-то не так.
Тут разница не в том где он ищет а в том что время которое он видит у себя на экране (в своей таймзоне) не равно времени которое на самом деле записано в базе (в UTC). И когда он хочет поискать по времени, например колонка с датой < конкретная дате и время, ему надо из времени которое он видит у себя на экране в уме перевести в UTC либо явно указать перевод в UTC используя сессию или прописать в запросе иначе он либо не найдет того что ищет либо найдет что-то другое.
Интересное исследование и интересные выводы но спешу Вас отговорить от поспешных переделок всех полей c timestamp на timestampz.
Тип timestampz предназначен для случаев когда Вам надо видеть (именно видеть!) дату+время в какой-то часовой зоне (обычно своей но это не важно).
И это как раз узкий кейс в то время как тип timestamp предназначен для всех остальных случаев когда нам нужна просто гипотетическая дата+время. Если Вам требуется точная система которая обеспечивает гарантии на что бы то ни было связанное с временными зонами то ни timestamp ни timestampz Вам это не обеспечат. По Вашей логике клиент не несет ответственности за ту таймзону которую он настроил в сессии, но это не корректное утверждение. Каждый клиент ответственен за то какую таймзону он настроил. Условный дядя не устанавливает же время на Ваших часах, да Вы можете подключить службу по синхронизации времени но опять же это будет Ваше осознанное решение. К тому же замена типов порождает уже другую проблему, как я и сказал выше тип timestampz предназначен чтобы видеть дату+время в каком-то конкретном часовом поясе. Дак вот предположим ситуацию: есть 5 сотрудников работающих с базой каждый работает в своей часовой зоне (или как мы выяснили из статьи даже просто в разных клиентах). Один из них тестер который нашел багу в двух полях с датами в мобильном приложении и снял скриншот в зоне -5 с ошибкой и зарепортил баг. Разработчик в зоне +5 получив баг решил воспроизвести проблему у себя и попытался найти записи с датами как на скриншоте но он их не нашел а чтобы найти их ему надо было бы выполнить пересчет дат из -5 в utc и написать field = utc_date но результат запроса он увидит в +5. Т.е. все операции такие как больше, меньше равно и т.п выполняются не по той дате которую ты видишь а по utc что требует от пользователя выполнения операций в уме. Я уж не говорю сколько будет матов сложены администратором который в зоне -10 когда ему потребуется выбрать всех пользователей которые что-то когда то сделали и выгрузить в отчет. Другая проблема приведение к какому-то часовому поясу может давать другую дату что может еще больше повысить когнитивный диссонанс. Что подводит нас к одной простой мысли, установка таймзоны это обязанность клиента а если это так то Ваш главный аргумент в пользу незамедлительного уничтожения полей с типом timestamp уже не выглядит таким уж весомым.
Спасибо за разъяснение. Я думаю за пределами Web такое проворачивать без изобретения своего HTML аналога крайне затруднительно.
Объясните пожалуйста отличие "представления для рендеринга" от "семантических данных" пожалуйста.
"Нет. GeForce now — скорее да, и то с некоторой натяжкой. MMORPG всё-таки позволяют кнопки в меню нажимать локальным кодом, а не вызовом сервера. "
Т.е. Backend-Driven UI это когда клиент просто "удаленный рабочий
столприложение" который картинку приезжающую с сервера показывает? С клиента только точки где мышка проезжает отсылаются и какие кнопки на ней (мышке) нажимаются? Я все верно понял?