Легко почувствовать себя дальтоником с night light mode в Gnome, который роняет цветовую температуру с 6500 К до 4000 К. «А-а-а! Где цвееет????» :)
На самом деле фича удобная, но не с таким перепадом, мне 5700-5800 К комфортно.
Круто. Только один вопрос. Эта схема выдержит хотя бы два честных релиза в месяц? Честных — в смысле, что хотя бы в подготовке релиза только один релиз (потому что если 5 последующих в работе, то сбой в последнем аффектит ещё 4) и честный в том смысле, что со всеми перечисленными мероприятиями.
Если там всё задание пишется за 25 человекодней, то понятно, почему waterfall работает. На таких небольших объёмах будет работать всё при минимальном здравомыслии участников и каком-нибудь отлаженном процессе. WF обычно встаёт колом, если в согласовании задействовано 5+ подразделений (30-50+ более-менее активных участников) и объём самой постановки за сотню чд. Это субъективно нижняя планка, когда нельзя выехать на 1-2-3 суперэкспертах, которые могут охватить весь проект.
Ну и вообще, уже сто раз обсуждалось, что аналогия разработки ПО со строительством красивая, но не учитывает главного отличия. ПО по своей сути очень легко меняется. В разработке ПО "чертеж" — это по сути уже и есть продукт. Ну понятно, что в любой сложной системе есть некоторые нюансы, которые менять сложно/дорого/долго. Но на самом деле в ПО часто за несколько версий можно поменять самые глубокие архитектурные детали (и тут больше вопрос не к методологии управления проектом, а к культуре и профессионализму разработчиков).
Почему? L1 же примерно в 4 раза дальше Луны (L1 — 1,5E+9 м, до Луны 3,8E+8 м), а ГСО в 10 раз ближе Луны (3,5E+7 м). Можно, наверное, сэкономить в выводе на L1 гравитационным маневром у Луны, но всё равно разница большая.
У меня в комменте не было ни одной цифры, я не мог их передернуть. У меня было только вспомненное место из художественной книги :)
Да еще и наглядно иллюстрирующее подход.
Ну тогда слово SELECT становится мусорным и видим то что видим в этой статье или LINQ.
А вообще, черт его знает, что логичнее :). Весь SQL — сборище исторических нелогичных костылей за 50 лет. Точнее продукт эволюции computer science, костылей для обхода текущих возможностей железа, костылей для обхода текущих кривостей реализаии, перетягиваний одеяла между вендорами СУБД и необходимости как-то работать с данными. Дедушка Дейт, вон, тоже постоянно ворчит, что SQL кривым получился.
x2bool, этот комментарий будет достаточно резкий, но досмотрите его до конца, пожалуйста.
У вас и концепция, и статья, и код получились неудачными. Я отмечу только то, что в глаза бросилось, потому что иначе комментарий будет длиннее статьи.
В статье, например, синтаксические диаграммы некорректные и бессмысленные.
Код абсолютно небезопасный и не продуман с точки зрения надёжности: даже прямые включения строк в SQL (привет, injection).
DDL непонятно когда и непонятно как вызывается. В том смысле, что если есть таблица в БД, то что, её при следующем запуске снова создавать?
Запросы возможные только совсем-совсем примитивные. Не верите? Берите какой-нибудь http://sql-ex.ru/, нарешайте там штук 20-30 примеров (это несложно) и попробуйте воспроизвести.
Ваша модель диалектов не позволяет учесть даже базовых различий между СУБД.
Код на котлине написан "не по-котлински". Совсем не DRY, с кучей явных лишних обработок null. То есть вот просто каждый файл проекта надо брать и почти полностью переписывать.
Не учтена архитектура предшественников. Тот же linq для начала, ну и ORM типа Hibernate/NHibernate.
Конечная цель — проверка на этапе компиляции — не достигнута (даже автоинкремент в рантайме проверяется), а где достигнута, то это явным хардкодом типов полей.
На самом деле это всё косметика. Главная проблема — задача просто невообразимо сложнее, чем те приемы, которыми вы её пытаетесь решить. Там прямо в каждой маленькой детали нюансов больше, чем весь проект на текущий момент. С этим подходом не то что до промышленного, до учебного качества проект не довести.
НО.
Вы сделали прототип. Это важная стадия до которой не добирается и 10% идей, наверное. Этот прототип может быть на выброс, но он компилируется и показывает, куда вы хотите идти.
Вы правильно сделали, что вынесли прототип на обсуждение. Местами неприятный, но единственный способ получить обратную связь и посмотреть на решение "снаружи". Каждый час, потраченный на то, чтобы идти в неправильную сторону — это в итоге несколько часов потраченных зря.
Вы правильно заметили, что тулинг между kotlin и db далёк от совершенства. Эту тему есть куда развивать.
Насколько я понимаю, эта библиотека используется вами в другом проекте (или планировалась для этого). Сделайте паузу в развитии kuery, попробовав его использовать. Если не сможете — не используйте, но запишите, что помешало использовать. Не тратьте времени больше, чем на фикс критичных багов. За 1-2 месяца вы будете гораздо лучше знать, что именно нужно полностью переработать в kuery. Не бросайте, возможно у вас получится то, что задумано изначально, но получится другой полезный и удобный инструмент для разработки.
Спорно. Это вечная проблема, когда пишешь SELECT, а автокомплиту нечего тебе предложить, потому что он еще не знает ни таблиц, ни алиасов, ни полей. И когда запросы большие, видишьti.value, и, мотая вниз, думаешь "это, блин, вообще из какой таблицы???". Чаще всего сначала пишешь select * from или select 1 from, потом лепишь "tablesource" при помощи join/apply/where, а потом возвращаешься к списку полей.
В том же linq также пошли.
Моя задача заключается в правильном применении секретной формулы.
Чистая арифметика.
Классическая задачка из учебника.
Если новая машина, произведенная компанией, на которую я работаю, выехала из Чикаго со скоростью шестьдесят миль в час, и тут у нее заклинило дифференциал, и она улетела в кювет, разбилась, бензобак взорвался и все, кто были в салоне, сгорели заживо, должна ли компания отозвать все проданные автомобили этой модели на доработку?
Возьмите общее количество проданных на настоящий момент автомобилей (А), умножьте на среднее количество серьезных отказов (В), а затем умножьте произведение на среднюю стоимость урегулирования иска родственников пострадавших во внесудебном порядке (С).
А х В х С = X. Вот во сколько нам обойдется проблема, если мы не будем отзывать модель на доработку.
Если Х превышает стоимость доработки, томы производим доработку, и аварий больше не бывает.
Если Х меньше, чем стоимость доработки, то мы доработку не производим.
Судя по тестам, там задержка не сильно ниже, но она на очереди 1 близка к константе. Там нет хитроштопанной логики и кешей и нет жирных CoW, как на SSD. Обычные SSD «на коротких дистанциях» компенсируют это кэшем, и именно поэтому в обычных тестах оптаны показывают себя очень близко к обычным хорошим SSD. А выигрывают в проигрышных для SSD вариантах типа 100% random write 4kQ1.
Хотя я тоже пока подожду готовых решений. Может в жизни всё и не так радужно.
Нет никакой загадки. Простейший и типичный кейс. Есть уровень, который хранится на HDD 7200 (tier2), и есть его кеш примерно на 10% по объёму на SSD (tier1). Ночью запускается обслуживание БД: резервное копирование, перестроение индексов, пересчет статистик. В итоге утром в tier1 какая-то хрень, а не нужные данные. Просто потому что СХД не обладает достаточной информацией о значении данных.
Есть такая проблема, для каждого вида нагрузки нужны фактически свои политики гуляния по tier'ам. Но вендоры СХД обычно предоставляют рекомендации.
А моё личное мнение, что для СУБД все эти «интеллектуальные» кеши уровня СХД — больше геморроя, чем пользы.
Ну во-первых WAL это всё-таки не random, а seq. Во-вторых WAL может быть и не 4k за порцию, а меньше. Но я согласен, что SSD и тут может давать выбросы. И, кстати, на выделенных HDD многие СХД выжимают очень и очень хорошую производительность в этом режиме, так что упираются в каналы.
И, как заметил предыдущий комментатор, я расчитываю на прорыв Intel Optane. Посмотрите мой PS про SSD. Более того, если оптаны не обладают каким-то скрытым изъяном, то те скорости (задержки), которые они дают, делают спорным применение SAN/СХД на критичных к производительности приложениях. На VMax/VNC и подобных СХД пока еще никто не заморачивается на roundtrip до конечного приложения в десятки микросекунд.
На самом деле фича удобная, но не с таким перепадом, мне 5700-5800 К комфортно.
Круто. Только один вопрос. Эта схема выдержит хотя бы два честных релиза в месяц? Честных — в смысле, что хотя бы в подготовке релиза только один релиз (потому что если 5 последующих в работе, то сбой в последнем аффектит ещё 4) и честный в том смысле, что со всеми перечисленными мероприятиями.
Если там всё задание пишется за 25 человекодней, то понятно, почему waterfall работает. На таких небольших объёмах будет работать всё при минимальном здравомыслии участников и каком-нибудь отлаженном процессе. WF обычно встаёт колом, если в согласовании задействовано 5+ подразделений (30-50+ более-менее активных участников) и объём самой постановки за сотню чд. Это субъективно нижняя планка, когда нельзя выехать на 1-2-3 суперэкспертах, которые могут охватить весь проект.
Ну и вообще, уже сто раз обсуждалось, что аналогия разработки ПО со строительством красивая, но не учитывает главного отличия. ПО по своей сути очень легко меняется. В разработке ПО "чертеж" — это по сути уже и есть продукт. Ну понятно, что в любой сложной системе есть некоторые нюансы, которые менять сложно/дорого/долго. Но на самом деле в ПО часто за несколько версий можно поменять самые глубокие архитектурные детали (и тут больше вопрос не к методологии управления проектом, а к культуре и профессионализму разработчиков).
Да еще и наглядно иллюстрирующее подход.
Или я что-то не понял?
Ну тогда слово
SELECTстановится мусорным и видим то что видим в этой статье или LINQ.А вообще, черт его знает, что логичнее :). Весь SQL — сборище исторических нелогичных костылей за 50 лет. Точнее продукт эволюции computer science, костылей для обхода текущих возможностей железа, костылей для обхода текущих кривостей реализаии, перетягиваний одеяла между вендорами СУБД и необходимости как-то работать с данными. Дедушка Дейт, вон, тоже постоянно ворчит, что SQL кривым получился.
x2bool, этот комментарий будет достаточно резкий, но досмотрите его до конца, пожалуйста.
У вас и концепция, и статья, и код получились неудачными. Я отмечу только то, что в глаза бросилось, потому что иначе комментарий будет длиннее статьи.
На самом деле это всё косметика. Главная проблема — задача просто невообразимо сложнее, чем те приемы, которыми вы её пытаетесь решить. Там прямо в каждой маленькой детали нюансов больше, чем весь проект на текущий момент. С этим подходом не то что до промышленного, до учебного качества проект не довести.
НО.
Насколько я понимаю, эта библиотека используется вами в другом проекте (или планировалась для этого). Сделайте паузу в развитии
kuery, попробовав его использовать. Если не сможете — не используйте, но запишите, что помешало использовать. Не тратьте времени больше, чем на фикс критичных багов. За 1-2 месяца вы будете гораздо лучше знать, что именно нужно полностью переработать вkuery. Не бросайте, возможно у вас получится то, что задумано изначально, но получится другой полезный и удобный инструмент для разработки.Пусть он не моден, но… Linq?
Спорно. Это вечная проблема, когда пишешь
SELECT, а автокомплиту нечего тебе предложить, потому что он еще не знает ни таблиц, ни алиасов, ни полей. И когда запросы большие, видишьti.value, и, мотая вниз, думаешь "это, блин, вообще из какой таблицы???". Чаще всего сначала пишешьselect * fromилиselect 1 from, потом лепишь "tablesource" при помощи join/apply/where, а потом возвращаешься к списку полей.В том же linq также пошли.
О, да, точно. Но там своих приколов хватает.
Это ж классика
Чак Паланик, "Бойцовский клуб"
Мы об одном и том же :)
и
Хотя я тоже пока подожду готовых решений. Может в жизни всё и не так радужно.
Зато можно инфиксную
==в backticks определить. В JVM, но не js, правдаА моё личное мнение, что для СУБД все эти «интеллектуальные» кеши уровня СХД — больше геморроя, чем пользы.
Ну во-первых WAL это всё-таки не random, а seq. Во-вторых WAL может быть и не 4k за порцию, а меньше. Но я согласен, что SSD и тут может давать выбросы. И, кстати, на выделенных HDD многие СХД выжимают очень и очень хорошую производительность в этом режиме, так что упираются в каналы.
И, как заметил предыдущий комментатор, я расчитываю на прорыв Intel Optane. Посмотрите мой PS про SSD. Более того, если оптаны не обладают каким-то скрытым изъяном, то те скорости (задержки), которые они дают, делают спорным применение SAN/СХД на критичных к производительности приложениях. На VMax/VNC и подобных СХД пока еще никто не заморачивается на roundtrip до конечного приложения в десятки микросекунд.