я не про авральный режим.
я про то, что переписывать большую систему, даже в планомерном режиме — на плохо-совместимую новую версию языка — дело очень дорогое.
и отсутствие эксцессов вида «денежные затраты, только потому что создатель языка решил впилить пару новых фишек» — это первейшее требование бизнеса к промышленному языку.
если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
и платить за это никто не готов.
и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.
____________________________________________________
ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.
но что же с питоном 3?
какие у него есть гарантии или стратегии, которые помогут ему претендовать на роль «промышленного языка для больших систем»? как создатели собираются предотвращать проблемы обратной совместимости и затрат на перевод на новые версии, проблем изменения поведения при смене версий?
когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»
20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?
offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?
о необходимости обратной совместимости для языков, о которых заявляют как
" промышленные" уже упоминали? проблема вечная, а питон подзабил на это в свое время.
и пока разработчики языка питон ( читай еще и котлин, руби, и тд.) не озаботятся серьезно поддержкой этой самой обратной совместимости — статьи наподобии этой будут периодически появляться и говорить об одном и том же: а именно — бизнес не хочет и не будет вкладывать денег в перевод системы на новую версию языка, какой бы она (новая версия языка) не была «вкусной» от синтаксического сахара, красивой от функционального стиля программирования, лаконичной от лямбда выражений и прочего…
и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.
рубисты вон, помнится, как то раз просто плюнули на всех кто не смог перехать на новую версии — причем почти сразу, на горизонте трех или около того лет.
а питонисты — молодцы. но увы. неумение в свое время обеспечить обратную совместимость наконец ударило по тем, кто много лет назад поверил молодым питон-программистам с горящими глазами и принял решение разработки больших систем питоне.
я к чему? хорошая статья, хорошее напоминание, о необходимости быть осмотрительным, не вестись на «модное в этом сезоне» при выборе средств реализации систем, у которых срок жизни чуть больше пары лет.
важно помнить о том, что совсем не лябды, не синтаксический сахар, и не модные фичи и тренды этого сезона делают язык хорошим в промышленной разработке. и даже не LTS.
что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?
пока котлин не обеспечит гарантий 100% обратной совместимости и полное покрытие спеками языка (и/или компилятора) — никакой конкуренции java он не составит. в лучшем случае будет болтаться в проруби платформенного языка так же как swift или шарпы, меняя спецификации от версии к версии.
но даже, гугл, мне кажется, не потянет обязательства по совместимости версий и покрытию спеками языка от версии к версии.
Какая-нибудь Стрида, думаю, вполне себе близка по проходимости к крупным самокатам. При этом на ней вполне ездят 30+ по дороге.
давайте не будем брать крайние случаи и распространять их на всё множество?
Это лукавство.
во вторых, если и ездят по дороге — то, вероятно нарушают ПДД. движение велосипедов по проезжей части — только по обочине или по правому краю проезжей части в один ряд.
Моноколёса так и вовсе довольно крупного диаметра и ввиду своего «моно» даже устойчивее при проезде мелких неровностей
Ну что вы такое говорите? «устойчивость» моноколеса?! ))
Я конечно могу ошибаться, но размышления говорят о том, что «устойчивость пилота» на средстве передвижения определяется не только диаметром колеса, но и «колесной базой» — основанием на которое пилот может опереться что бы не упасть.
Что имеем? По самокату или скейту — вон даже попереступать можно…
А у моноколеса «колесная база» — нулевая.
Итог? кратковременная задержка в движении — рывок назад из-за кочки — который для самоката может быть даже не всегда смертелен (человек упрется на переднюю ногу и может даже устоит, протолкнув таким образом самокат под собой вперед), для моноколеса будет фатален — опереться то не на что, и колесо уходит из под точки опоры назад — а пилот моноколеса летит на зубодробительную встречу с асфальтом.
масса моноколеса конечно моет помочь сохранить скорость и положение в области опоры пилота, но суть, мне кажется понятна. Моноколеса, одноколесные велосипеды — им, имхо, лучше оставаться в пределах цирковой арены и гладких, офисных территорий и парков, где «все ровно».
В ямы, конечно, заезжать не надо, но в полосе почему самокат ехать не может? По тротуару же ездят.
Потому, что запрещено действующими ПДД. Пешеходы не должны передвигаться по проезжей части ))) (*если конечно у нас не пешеходная зона типа дворов или пешеход не идет/едет по пешеходному переходу на зеленый)
Ну раз так, то идите, пожалуйста, и попробуйте получить на ваш «50-и кубовый мотоцикл» номер. Мотоциклам же, как и автомобилям — запрещено ездить без номеров — это то вы тоже должны знать? ))
И попрообуйте объяснить инспектору, что вы лучше него знаете, что у вас «50-и кубовый мотоцикл», а не «мопед» — именно как раз по ПДД.
Главное запишите на видео — что бы мы тоже могли поугорать.
Самокаты до 250 ватт полностью соответствуют определению велосипедов из ПДД, а больше 250 ватт — мопедам. Не нужно ничего изобретать.
вы лукавите.
во первых, вы совершенно игнорируете конструктив самоката.
диаметр колес, например: пока он не будет схож с велосипедными или скутерными — игнориррвать это нельзя.
там где велосипед проедет на 40 км/ч, а пилот только синяк на заднице получит — самокат резко застрянет с 40 км/ч до нуля — со всеми последствиями для «ездока».
далее, если следовать вашему определению, то и инвалидные коляски, имеющие в современном исполнении мотор, тоже — являются «механическими транспортными средствами». и в следствии чего, им, (внимание!), нельзя ездить по тротуарам и в пешеходных зонах… да ?)
но ведь этого не происходит. все как раз наоборот:
вне зависимости от наличия мотора у инвалидной коляски, она не перестает быть инвалидной коляской, и продолжает приравниваться к пешеходам.
почему? потому что она прописана в определении пешехода без уточнения — есть на ней мотор или нет.
аналогично и самокаты — сейчас это пешеходы, вне зависимости от того, есть или нет там морчик, и какая его мощность.
и мы же не проект ПДД, обсуждаем, а действующие ПДД?..
По такой логике и на велосипеде по ПЧ нельзя ездить, вдруг ямка, щель и т.п. И на скутере поскользнуться можно.
вы вот это серьезно? понимаю, ерничаете или сарказмируете, наверное.
вы же тоже должны понимаеть, что велосипед устойчивее и стабильнее самоката на неровной дороге? и я говорю именно про это.
у велосипеда вы не встретите колес диаметра самоката: диаметр колеса велосипеда гораздо больше, и сопоставим с автомобильным или мотоциклетным, и мелкие щели на дороге, стыки плит, крышки люков (утопленный на 3 см под покрытие) — проезжаются велосипедами вполне незаметно. в отличии от самоката, который, проезжая крышку люка, рискует на этой же крышке люка и остаться.
это не говоря об устойчивости (благодаря тому же диаметру колеса), которой не могут похвастаться самокаты.
Быстроедущий самокат мотоциклом или велосипедом не становится.
Пешеход перемещающийся 30+ км/час на прыгучих ходулях не перестает быть пешеходом.
Не согласны? Вот пример из жизни: скутер «50кубиков», даже при конструктивной его возможности «гнать» 75 км/час — не перемещается из категории «мопед» в категорию «мотоцикл». И будет рассматриваться ГИБДД именно как «мопед».
Точно так же «быстроедущий самокат», с точки зрения ПДД не перестает быть приравненным к «очень быстро бегущему пешеходу».
При разборе ДТП судить будут по букве закона, а «буква», именно «буква ПДД» явно говорит про самокаты вне зависимости от их максимальной скорости.
«Пешеход» — лицо, находящееся вне транспортного средства на дороге либо на пешеходной или велопешеходной дорожке и не производящее на них работу. К пешеходам приравниваются лица, передвигающиеся в инвалидных колясках, ведущие велосипед, мопед, мотоцикл, везущие санки, тележку, детскую или инвалидную коляску, а также использующие для передвижения роликовые коньки, самокаты и иные аналогичные средства.
т.е именно пешеходы, со всеми вытекающими.
Когда вас случайно собьют или задавят — просто потому что маленькое колесо самоката застряло в дорожной щели, вы распластались на асфальте, а водитель позади вас едущего автомобиля не успел среагировать — виноваты будете именно Вы.
Вы, как пешеход, нагло и беспардонно нарушающий ПДД.
И когда вы «бежите» на самокате или моноколесе во втором ряду, даже на скорости 45 км/ч — водители не просто имеют право бибикать (для предотвращения дтп), но и наверное, им следует вызвать наряд гибдд, что бы вас оштрафовать зарвавшегося пешехода.
Настоятельно, очень сильно, сердечно от лица мото- и авто- водителей, прошу: не надо ездить на самокате по дорогам общего пользования! Помрете «низачто».
Ни на самокате, ни на моноколесе, ни на роликах, ни на самоходном скейтборде.
Пожалуйста, не надо создавать проблем себе, водителям, страховым компаниям, гиббд и вашим родственникам.
Не надо вписывать своей кровью новый пункт в ПДД, явно запрещающий самокатам кататься по дорогам общего пользования.
Ну что значит просто…
… где дзен SMD и паяльной пасты под 60W паяльником ?! ))
Я к чему:
1) тема SMD не раскрыта.
А это бывает срочно надо. Причем именно тогда, когда нет ни паяльной станции, ни фена, а только старый добрый «паяльник с жалом».
2) паять с пастой, имхо, куда приятнее чем с припоем и флюсом.
но вообще тема рабоче-технических комиксов — штука правильная. продолжайте)
ну как же… тесла рано или поздно перейдет на активное сканирование местности (если уже не перешли?), или как минимум на восстановление 3D-ространства вокруг по стереопаре камер или даже (что имхо, разумнее) по трем камерам.
скорее тут мысль про то, что такой «защитный макиях», сам по себе «слишком выделяющийся в толпе». черно белые резкие грани на лице человека — мгновенно привлекают к себе внимание человека-охранника. Другое дело — что когда/если таких персонажей в метро будет больше чем единичные случаи — то толпа лиц превратится в чернобелую мешанину.
имхо, если хочешь скрыться от распознавалки — лучше/разумнее сделать деформирующий грим, который будет выглядеть как новое лицо — не известное ни для камеры ни для человеков. и не привлекающее внимание человеков ))
кодогенерация — это изменение процесса сборки, или доп. ручной труд по поддержке скриптов пересборки объектов при расширении структур данных и их запуску. это не всегда приемлемо.
также это потребует пересборки всех компонент проекта при любом изменении структур данных.
хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.
но лично я предпочитаю рантайм решения для генерации интерфейса.
ну и это расширяет области применения такихьмеханизмов. это позволит например создать конфигуриемый на лету механизм пользовательских карточек, что иногда нужно в Ынтерпраз.
так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.
все же помнят что он НЕ бесплатный?)))
а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.
с объектно ориентирвоанными БД тоже много засад. правильная объектная БД должна уметь валидировать объекты которые ей подсовывают.
т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.
Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.
и хорошо если вы их решаете, и при переходе с версии на версию успешно решаете проблемы конвертации старых обхектов в новые форматы и структуры или поддерживаете все механизмы отображения данных в вашей обхектной бд начиная с начала времен.
но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.
т.е. объекты у вас будут, но понять что они означают вы не сможете. потому что давно потеряли информацию о том что записано и как трактовать эти json-структуры.
Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.
— ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
Только играют они иную роль и по другому выглядят, по другому называются.
XSD, Json-schema и тп — становятся неотъемлемой частью системы метаданных если вы используете объектныю бд на больших долгоживущих проектах.
мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?
т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
У вас будет AutoGeneratedForm. один на всех.
AutoGeneratedForm — универсальный механизм. угловатый но предоставляющий приемлемый минимальный уровень работы со всеми сущностями.
механизм который умеет динамически себя перестраивать под тот объект который ей передали.
Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.
Т.е. идея такая: вы один раз написали такую универсальную форму, и после этого практически забыли о типовых CRUD-механизмах работы с сущностями в GUI (просмотр списка, просмjтр карточки, сортировка, выборка, редактирование).
Теперь к вам вопрос: каким образом реализовать такую систему?
т.е. я с вами согласен что непосредственно связывать их — это глупая идея.
и правильный, имхо, ответ на поставленную задачу такой:
И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.
детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.
вы говорите что «на js можно поместить в объект информацию о том как его отображать» — я же правил но вас понимаю?
тут 2 момента.
1) вы по сути подтверждаете мой тезис о том, что сам по себе ооп-язык не предоставляет механизмов и правил описания как отображать данные.
2) вы говорите про детали реализации, которые распределяют задачи функциональных подсистем на программные классы систем.
действительнь — почему бы не разместить в объекте его собственный кусочек метаданных, и отнаследовать откуда то кусочек для орм, который дает объекту самому сохраняться в хранилище — почему нет? это не более чем детали реализации тех же сущностей о которых я говорю: объект и метаданные.
только система метаданных у вас организована так, что каждый объект «знает о себе всё».
и я так делал. так был построен мой орм для qt.
но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.
и я не говорил что классический фронт должен что то знать о том как классический бек хранит информацию или наоборот. они по прежнему могут делать это без оглядки друг на друга, но что бы синхронизировать и сработаться — им нужна третья сторона. в обычном программировании роль синхронизатора выступает архитектор/разработчик с его «высшим пониманием», в системах с метаданными — записи метаданных (а архитектор/разработчик в идеале изменяет уже только метаданные)
сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.
но откуда им обоим, если не из метаданных, взять информацию об объекте, что бы
1) фронт мог иметь систему генерации форм, способную автомтически сгенерировать форму для отображения любого ифн.объекта в системе?
2) а бек мог корректно это отработать?
я не говорил что фронт должен знать о том, как бек хранит информацию, или бек о том как фронт отображает объект. ответственность не размывается.
я говорю про то что универсальные механизмы и бека и фронта должны уметь обработать объект о котором они буквально секунду назад ничего не знали, и каждый берет необходимую информацию из третьей стороны — метаданные. да, она будет формально на сервере, но она не будет ни мешать работать классическому беку работать с объектом, ни отбирать у него ответственность. она скорее выставляет им обоим — беку и фронту некий реестр требований, по которым они оба должны синхронно жить.
и орм тоже должен участвовать в этом безобразии, ибо если вы делаете только генерацию форм по метаданным, но не делаете орм в беке, который по метаданным умеет сохранить объект в бд — то какой смысл делать метаданные ?- вы замучаетесь руками подтягивать одно к другому при изменении того же атрибутного состава.
ps: отмечу, что, идея о том, что объект должен сам уметь себя хранить в бд — она валидна только для отдельных архитектур (простите не помню названия этого подхода).
например — скажите — откуда объект должен знать как ему собирать или размещать себя в хранилище типа datavault? это ответственность хранилища, точнее орм, который знает правила «трансляции» записей метаданных на «физику» хранилища.
pps: и да, я не говорю что ваш подход и ваши идеи плохи. я говорю о том, что есть спектр ситуаций, в которых ваши подходы будут работать не так хорошо и давать совокупный результат хуже, чем системы, которые не соответствуют вашим идеям об архитектуре.
и, естественно, наоборот: системы с метаданными и автогенерацией нет смысла применять на вебсайтах. но мы же сейчас обсуждаем автогенерацию форм.
я про то, что переписывать большую систему, даже в планомерном режиме — на плохо-совместимую новую версию языка — дело очень дорогое.
и отсутствие эксцессов вида «денежные затраты, только потому что создатель языка решил впилить пару новых фишек» — это первейшее требование бизнеса к промышленному языку.
если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
и платить за это никто не готов.
и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.
____________________________________________________
ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.
но что же с питоном 3?
какие у него есть гарантии или стратегии, которые помогут ему претендовать на роль «промышленного языка для больших систем»? как создатели собираются предотвращать проблемы обратной совместимости и затрат на перевод на новые версии, проблем изменения поведения при смене версий?
когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»
20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?
offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?
" промышленные" уже упоминали? проблема вечная, а питон подзабил на это в свое время.
и пока разработчики языка питон ( читай еще и котлин, руби, и тд.) не озаботятся серьезно поддержкой этой самой обратной совместимости — статьи наподобии этой будут периодически появляться и говорить об одном и том же: а именно — бизнес не хочет и не будет вкладывать денег в перевод системы на новую версию языка, какой бы она (новая версия языка) не была «вкусной» от синтаксического сахара, красивой от функционального стиля программирования, лаконичной от лямбда выражений и прочего…
и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.
рубисты вон, помнится, как то раз просто плюнули на всех кто не смог перехать на новую версии — причем почти сразу, на горизонте трех или около того лет.
а питонисты — молодцы. но увы. неумение в свое время обеспечить обратную совместимость наконец ударило по тем, кто много лет назад поверил молодым питон-программистам с горящими глазами и принял решение разработки больших систем питоне.
я к чему? хорошая статья, хорошее напоминание, о необходимости быть осмотрительным, не вестись на «модное в этом сезоне» при выборе средств реализации систем, у которых срок жизни чуть больше пары лет.
важно помнить о том, что совсем не лябды, не синтаксический сахар, и не модные фичи и тренды этого сезона делают язык хорошим в промышленной разработке. и даже не LTS.
что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?
пока котлин не обеспечит гарантий 100% обратной совместимости и полное покрытие спеками языка (и/или компилятора) — никакой конкуренции java он не составит. в лучшем случае будет болтаться в проруби платформенного языка так же как swift или шарпы, меняя спецификации от версии к версии.
но даже, гугл, мне кажется, не потянет обязательства по совместимости версий и покрытию спеками языка от версии к версии.
а в 19м веке, говорят, диаметр переднего колеса у велосипедов был метра 2 ))давайте не будем брать крайние случаи и распространять их на всё множество?
Это лукавство.
во вторых, если и ездят по дороге — то, вероятно нарушают ПДД. движение велосипедов по проезжей части — только по обочине или по правому краю проезжей части в один ряд.
Ну что вы такое говорите? «устойчивость» моноколеса?! ))
Я конечно могу ошибаться, но размышления говорят о том, что «устойчивость пилота» на средстве передвижения определяется не только диаметром колеса, но и «колесной базой» — основанием на которое пилот может опереться что бы не упасть.
Что имеем? По самокату или скейту — вон даже попереступать можно…
А у моноколеса «колесная база» — нулевая.
Итог? кратковременная задержка в движении — рывок назад из-за кочки — который для самоката может быть даже не всегда смертелен (человек упрется на переднюю ногу и может даже устоит, протолкнув таким образом самокат под собой вперед), для моноколеса будет фатален — опереться то не на что, и колесо уходит из под точки опоры назад — а пилот моноколеса летит на зубодробительную встречу с асфальтом.
масса моноколеса конечно моет помочь сохранить скорость и положение в области опоры пилота, но суть, мне кажется понятна. Моноколеса, одноколесные велосипеды — им, имхо, лучше оставаться в пределах цирковой арены и гладких, офисных территорий и парков, где «все ровно».
Потому, что запрещено действующими ПДД. Пешеходы не должны передвигаться по проезжей части ))) (*если конечно у нас не пешеходная зона типа дворов или пешеход не идет/едет по пешеходному переходу на зеленый)
Кстати, велосипеду по ПДД — тоже запрещено «ехать в полосе» (ПДД, пункт 24.2: www.drom.ru/pdd/pdd/punkt_24_2 )
ну и повторюсь: самокат слишком не устойчив, слишком требователен к качеству покрытия, что часто не выполняется на наших дорогах.
И попрообуйте объяснить инспектору, что вы лучше него знаете, что у вас «50-и кубовый мотоцикл», а не «мопед» — именно как раз по ПДД.
Главное запишите на видео — что бы мы тоже могли поугорать.
во первых, вы совершенно игнорируете конструктив самоката.
диаметр колес, например: пока он не будет схож с велосипедными или скутерными — игнориррвать это нельзя.
там где велосипед проедет на 40 км/ч, а пилот только синяк на заднице получит — самокат резко застрянет с 40 км/ч до нуля — со всеми последствиями для «ездока».
далее, если следовать вашему определению, то и инвалидные коляски, имеющие в современном исполнении мотор, тоже — являются «механическими транспортными средствами». и в следствии чего, им, (внимание!), нельзя ездить по тротуарам и в пешеходных зонах… да ?)
но ведь этого не происходит. все как раз наоборот:
вне зависимости от наличия мотора у инвалидной коляски, она не перестает быть инвалидной коляской, и продолжает приравниваться к пешеходам.
почему? потому что она прописана в определении пешехода без уточнения — есть на ней мотор или нет.
аналогично и самокаты — сейчас это пешеходы, вне зависимости от того, есть или нет там морчик, и какая его мощность.
и мы же не проект ПДД, обсуждаем, а действующие ПДД?..
вы же тоже должны понимаеть, что велосипед устойчивее и стабильнее самоката на неровной дороге? и я говорю именно про это.
у велосипеда вы не встретите колес диаметра самоката: диаметр колеса велосипеда гораздо больше, и сопоставим с автомобильным или мотоциклетным, и мелкие щели на дороге, стыки плит, крышки люков (утопленный на 3 см под покрытие) — проезжаются велосипедами вполне незаметно. в отличии от самоката, который, проезжая крышку люка, рискует на этой же крышке люка и остаться.
это не говоря об устойчивости (благодаря тому же диаметру колеса), которой не могут похвастаться самокаты.
Быстроедущий самокат мотоциклом или велосипедом не становится.
Пешеход перемещающийся 30+ км/час на прыгучих ходулях не перестает быть пешеходом.
Не согласны? Вот пример из жизни: скутер «50кубиков», даже при конструктивной его возможности «гнать» 75 км/час — не перемещается из категории «мопед» в категорию «мотоцикл». И будет рассматриваться ГИБДД именно как «мопед».
Точно так же «быстроедущий самокат», с точки зрения ПДД не перестает быть приравненным к «очень быстро бегущему пешеходу».
При разборе ДТП судить будут по букве закона, а «буква», именно «буква ПДД» явно говорит про самокаты вне зависимости от их максимальной скорости.
ээээ… что?!
Простите пожалуйста, но не надо вводить людей в заблуждение,
По ПДД, «самокатчики» — это именно пешеходы.
www.pdd24.com:
т.е именно пешеходы, со всеми вытекающими.
Когда вас случайно собьют или задавят — просто потому что маленькое колесо самоката застряло в дорожной щели, вы распластались на асфальте, а водитель позади вас едущего автомобиля не успел среагировать — виноваты будете именно Вы.
Вы, как пешеход, нагло и беспардонно нарушающий ПДД.
И когда вы «бежите» на самокате или моноколесе во втором ряду, даже на скорости 45 км/ч — водители не просто имеют право бибикать (для предотвращения дтп), но и наверное, им следует вызвать наряд гибдд, что бы вас оштрафовать зарвавшегося пешехода.
Настоятельно, очень сильно, сердечно от лица мото- и авто- водителей, прошу: не надо ездить на самокате по дорогам общего пользования! Помрете «низачто».
Ни на самокате, ни на моноколесе, ни на роликах, ни на самоходном скейтборде.
Пожалуйста, не надо создавать проблем себе, водителям, страховым компаниям, гиббд и вашим родственникам.
Не надо вписывать своей кровью новый пункт в ПДД, явно запрещающий самокатам кататься по дорогам общего пользования.
… где дзен SMD и паяльной пасты под 60W паяльником ?! ))
Я к чему:
1) тема SMD не раскрыта.
А это бывает срочно надо. Причем именно тогда, когда нет ни паяльной станции, ни фена, а только старый добрый «паяльник с жалом».
2) паять с пастой, имхо, куда приятнее чем с припоем и флюсом.
но вообще тема рабоче-технических комиксов — штука правильная. продолжайте)
имхо, если хочешь скрыться от распознавалки — лучше/разумнее сделать деформирующий грим, который будет выглядеть как новое лицо — не известное ни для камеры ни для человеков. и не привлекающее внимание человеков ))
также это потребует пересборки всех компонент проекта при любом изменении структур данных.
хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.
но лично я предпочитаю рантайм решения для генерации интерфейса.
ну и это расширяет области применения такихьмеханизмов. это позволит например создать конфигуриемый на лету механизм пользовательских карточек, что иногда нужно в Ынтерпраз.
так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.
а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.
хотя да, выглядит он не плохо.
т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.
Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.
и хорошо если вы их решаете, и при переходе с версии на версию успешно решаете проблемы конвертации старых обхектов в новые форматы и структуры или поддерживаете все механизмы отображения данных в вашей обхектной бд начиная с начала времен.
но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.
т.е. объекты у вас будут, но понять что они означают вы не сможете. потому что давно потеряли информацию о том что записано и как трактовать эти json-структуры.
Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.
— ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
Только играют они иную роль и по другому выглядят, по другому называются.
XSD, Json-schema и тп — становятся неотъемлемой частью системы метаданных если вы используете объектныю бд на больших долгоживущих проектах.
мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?
т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
У вас будет AutoGeneratedForm. один на всех.
AutoGeneratedForm — универсальный механизм. угловатый но предоставляющий приемлемый минимальный уровень работы со всеми сущностями.
механизм который умеет динамически себя перестраивать под тот объект который ей передали.
Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.
Т.е. идея такая: вы один раз написали такую универсальную форму, и после этого практически забыли о типовых CRUD-механизмах работы с сущностями в GUI (просмотр списка, просмjтр карточки, сортировка, выборка, редактирование).
Теперь к вам вопрос: каким образом реализовать такую систему?
т.е. я с вами согласен что непосредственно связывать их — это глупая идея.
и правильный, имхо, ответ на поставленную задачу такой:
И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.
детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.
тут 2 момента.
1) вы по сути подтверждаете мой тезис о том, что сам по себе ооп-язык не предоставляет механизмов и правил описания как отображать данные.
2) вы говорите про детали реализации, которые распределяют задачи функциональных подсистем на программные классы систем.
действительнь — почему бы не разместить в объекте его собственный кусочек метаданных, и отнаследовать откуда то кусочек для орм, который дает объекту самому сохраняться в хранилище — почему нет? это не более чем детали реализации тех же сущностей о которых я говорю: объект и метаданные.
только система метаданных у вас организована так, что каждый объект «знает о себе всё».
и я так делал. так был построен мой орм для qt.
но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.
и я не говорил что классический фронт должен что то знать о том как классический бек хранит информацию или наоборот. они по прежнему могут делать это без оглядки друг на друга, но что бы синхронизировать и сработаться — им нужна третья сторона. в обычном программировании роль синхронизатора выступает архитектор/разработчик с его «высшим пониманием», в системах с метаданными — записи метаданных (а архитектор/разработчик в идеале изменяет уже только метаданные)
сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.
но откуда им обоим, если не из метаданных, взять информацию об объекте, что бы
1) фронт мог иметь систему генерации форм, способную автомтически сгенерировать форму для отображения любого ифн.объекта в системе?
2) а бек мог корректно это отработать?
я не говорил что фронт должен знать о том, как бек хранит информацию, или бек о том как фронт отображает объект. ответственность не размывается.
я говорю про то что универсальные механизмы и бека и фронта должны уметь обработать объект о котором они буквально секунду назад ничего не знали, и каждый берет необходимую информацию из третьей стороны — метаданные. да, она будет формально на сервере, но она не будет ни мешать работать классическому беку работать с объектом, ни отбирать у него ответственность. она скорее выставляет им обоим — беку и фронту некий реестр требований, по которым они оба должны синхронно жить.
и орм тоже должен участвовать в этом безобразии, ибо если вы делаете только генерацию форм по метаданным, но не делаете орм в беке, который по метаданным умеет сохранить объект в бд — то какой смысл делать метаданные ?- вы замучаетесь руками подтягивать одно к другому при изменении того же атрибутного состава.
ps: отмечу, что, идея о том, что объект должен сам уметь себя хранить в бд — она валидна только для отдельных архитектур (простите не помню названия этого подхода).
например — скажите — откуда объект должен знать как ему собирать или размещать себя в хранилище типа datavault? это ответственность хранилища, точнее орм, который знает правила «трансляции» записей метаданных на «физику» хранилища.
pps: и да, я не говорю что ваш подход и ваши идеи плохи. я говорю о том, что есть спектр ситуаций, в которых ваши подходы будут работать не так хорошо и давать совокупный результат хуже, чем системы, которые не соответствуют вашим идеям об архитектуре.
и, естественно, наоборот: системы с метаданными и автогенерацией нет смысла применять на вебсайтах. но мы же сейчас обсуждаем автогенерацию форм.