Да я понимаю. Сам же ещё в 2008м году что-то подобное делал и упорно не хотел называть это ORM. Там сильно проще было, в угоду времени, но с кодогенерацией по структуре БД.
А так у вас уже есть маппер, можно прикрутить кодогенерацию по структуре (или модели) и немного расширить возможность составления запросов. Если linq прикрутить, так вообще будет весь EF...
Странно, конечно, что тут вообще DataTable делает. Можно же сразу из ридера грузить без посредников.
а для подвоза результата к сроку, на который босс забился с заказчиком
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
В какой-то момент стало понятно, что нам не хватает одного окна, в котором собраны все ключевые процессы
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Да я понимаю. Сам же ещё в 2008м году что-то подобное делал и упорно не хотел называть это ORM. Там сильно проще было, в угоду времени, но с кодогенерацией по структуре БД.
А так у вас уже есть маппер, можно прикрутить кодогенерацию по структуре (или модели) и немного расширить возможность составления запросов. Если linq прикрутить, так вообще будет весь EF...
Странно, конечно, что тут вообще DataTable делает. Можно же сразу из ридера грузить без посредников.
То есть между реляционными рядами RDBMS и объектами языка с ООП?
А Object-Relational Mapper назвать можно?
Так это же ORM. Да, не полный, да самописный, но это уже ORM.
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Я вертел на болту ОРП, вертел реакт, жаваскрипт и весь веб в целом. Десктопщик я. А для своего сайта сделал ssr и мне за глаза хватает.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Спасибо за статью! Это действительно хороший и интересный материал. Напомнило серию "техногенка, котаны?". А, ну да...
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Демократы хотят демократии, а не громить почему-то. Ну могут и погромить, если им обещали, но наврали, как в LA
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
А никто не пробовал твиты Трампа прогнать через него? Вдруг Дональд - программист?
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.