Вы уходите от сути, начинаете рассуждать о нужности или не нужности метода. А я не метод обсуждаю, я пишу что лишь 1 из 10 джунов ЗНАЕТ О НЕМ, что он в принципе существует. Я это привел как пример простейшей сознательной денормализации БД, о котором почему-то редко в каком ВУЗе рассказывают на курсе СУБД.
Например мы все (я надеюсь, а то уже страшновато) знаем сортировку пузырьком. В продакшене никто из нас ее не применяет, потому что есть более оптимальные сортировки. Но мы все начинаем с нее, потому что если на человека сразу вывалить Smoothsort у него порвет шаблон.
Но в то же время — чем больше разных способов сортировки человек знает, тем более оптимальный код он пишет — потому что выбирает инструмент под задачу, а не переизобретает велосипеды в мучениях. С нормальными формами то же самое.
MPTT (Modified Preorder Tree Traversal) позволяет ЗНАЧИТЕЛЬНО ускорить чтение иерархических данных из базы, путем небольшой сознательной денормализации. Оставлю пару ссылок, там все подробно расписано.
Если кратко, без MPTT быстрая вставка но медленное чтение. С MPTT медленная вставка (поскольку приходится пересчитывать атрибуты MPTT) но быстрое чтение. Идеальный вариант для больших и редко меняющихся справочников, вроде общероссийских классификаторов или деревьев гео-данных.
И я нигде не писал что прохождение моего теста сводится к знанию MPTT. Я писал что лишь 1 из 10 джунов знает о нем, остальные решают либо через JOIN-ы, либо через рекурсию.
И я никого не заставляю делать это на собеседовании, обычно даю им такой тест на дом, дня на 2-3, чтобы они могли решить задачу в комфортной для себя обстановке и с интернетом (да хоть под пиво, музыку и с девочками).
Потому что как по мне, способность быстро найти, усвоить и использовать инфу — не менее важный навык для IT-шника, чем базовые знания. Т.е. если джун знал о базах только CRUD, но за пару вечеров разобрался в MPTT и сделал с ним тестовый пример — он мне подходит)
У меня одно из тестовых заданий для джунов — сделать простой иерархический каталог, чтобы он отображался в дерево на странице — а перейдя на один из его элементов, вывести хлебные крошки к корню. Там кода на полтора экрана, но только 1 из 10 кандидатов знает про MPTT (это к слову о денормализации) и даже этому кандидату (если я его беру) приходится объяснять что он и вывод, и операции благодаря этому может осуществлять над линейным списком за 1 проход, а не рекурсивно.
Меня это удивляло ровно до того момента, пока я не узнал что преподаватели в самых разных ВУЗах тоже про MPTT ничего не знают… все это очень печально(((
Смотря что за должность. Как я уже писал выше — для фронтенда или девопса это не критично. Но если это бэкенд, то незнание СУБД нужно оправдывать чем-то очень весомым в плане специализации — например «Я сетевой программист и сделаю вам такие сокеты, что синхронизация распределенных по разным ЦОД реалтайм-сервисам будет летать за наносекунды».
Но при этом если вашим конкурентом на должность будет равный вам специалист, который четко ответит что 1НФ это «Атомарность», и означает что каждый кортеж отношения содержит только одно значение для каждого из атрибутов, и нарисует табличку-пример — будьте уверены, возьмут его. Потому что он может оптимизировать сетевое взаимодействие зная как определить, что в лаге виноват косяк в базе сервиса, а не сокет.
Тем не менее, изучить все времени не хватает ни у кого)) Поэтому я рекомендую вам пораньше начинать вливаться в ту сферу и должность, на которой вы хотите работать. Искать инфу, ходить по мероприятиям, докапываться до всех с вопросами.
Вам нужно определить круг критичных для этой работы навыков, без которых у вас просто нет шансов. И круг вторичных навыков — которые повышают вашу конкурентоспособность. Расставить приоритеты и учиться, а если сможете — пробовать делать то, чем собираетесь заниматься.
Идете в бэкенд — пишите сервисы для себя. Идете в РП — пишите бизнес-планы для себя. Идете в SEO — пишите планы продвижения для себя. Идете в маркетинг — пишите рыночные исследования для себя.
Если вы не сможете делать это для себя, не сможете и для кого-то. И в этом нет ничего плохого, просто значит вам это не очень интересно. И это лучше узнать на берегу, чтобы потом не пополнить ряды тех кто ноет что им не нравится их работа.
А если сможете — шикарно, поскольку у вас начнет формирования понимание разницы между учебой и реальностью. Плюс, вы сможете прямо на первое же собеседование принести тучу своих тренировочных примеров. Профит +)))
Я к тому что даже если ORM позволяет сначала написать классы-модели, а потом накатить миграцию чтобы сгенерить для них БД — все-равно нужно сначала спроектировать БД, в том числе выполнив нормализацию. Т.к. именно по проекту базы будет понятно — какие модели и с какими полями создавать, как декомпозировать, какие отношения определять и т.д. CodeFirst не заменяет собой сам процесс проектирования базы, лишь позволяет после проектирования пойти писать код для ORM, а не create-ы и alter-ы в базу, которые как раз ORM и выполнит.
Возможно разница в восприятии, я когда слышу «ORM управляет схемой», для меня это значит что в приложении есть функционал, который в штатной работе системы на лету модифицирует ее структуру. А не то, что ORM в принципе умеет это делать.
А что с ними такого страшного происходит, если про Eager Loading не забывать?
Это в фреймворке можно так сделать, когда пишешь ручками)) Например в Django это prefetch_related — а вот в коробках типа Drupal где изменение схемы данных автоматизировано и делается мышкой из админки, все работает через mainhook — и количество запросов к базе со временем становится просто убийственным))
А знать их должен тот кто схему БД проектирует или изменяет — а это не обязательно DBA.
Вообще не обязательно. Любой backend-middle уже должен твердо знать такие вещи. Потому что когда у меня в компании over9000 проектов, я как архитектор проектирую только основную концепцию базы. И если я отдаю ее мидлу, я должен быть уверен что он не проморгает в ней какие-то детали и нюансы связанные с реализацией. И что он не впихнет туда не нормализованную таблицу, которая потом превратит в хаос работу с любыми связанными данными. Особенно, если такая таблица успеет накопить миллиарды записей.
А если это распределенная система, работающая в реальном времени, с репликациями, синхронизацией и тяжелыми данными, цена ошибки на этапе проектирования БД будет фатальной.
На начальных стадиях проектов схемой БД частенько управляет ORM — и тут без знания нормальных форм можно наворотить такого что потом никакой DBA такую базу не согласится поддерживать.
ORM управляет схемой? Что вы там курите?)))
ORM в 99% случаев лишь отражает схему в DAL. Но независимо от того мигрирует ли ваша ORM таблицы в классы кода, или же классы в таблицы и отношения СУБД — все-равно сначала нужно спроектировать саму базу и уже только потом реализовывать интерфейсы для нее в ORM.
Проект в котором приложение имеет доступ к миграциям БД для динамической модификации схемы данных — огромная редкость) И я не беру в расчет сейчас банальные вещи вроде Drupal который просто создает таблицы под ваш CCK, потому что думаю мы все знаем что потом происходит с количеством запросов к базе. ИМХО, нужно быть конченым психопатом, чтобы строить большую сложную систему по такому принципу.
Нормальная история для фронтенда или девопса, но бэкенда, заявившего такое, я бы не подпустил к коду и на пушечный выстрел.
А сфера деятельности у вас, простите, какая?
Проектирование и разработка информационных систем — от сайтов общего назначения (новостные порталы, интернет магазины и т. д.) до специальных систем обработки данных, автоматизации процессов и др.
Инженерный навык это хорошо, когда он нужен. Абстракцию инженерного мышления я могу потренировать и на других областях.
Знание баз данных и мышление в их категориях, это один из критичных навыков для бэкенд-разработчика.
Его отсутствие порождает персонажей, которые берут SQL запрос работающий 5мс и переводят в ORM так, что он работает 5 минут — просто потому, что они не понимают как работают индексы по составным ключам, например. Или страдают с запросом N дней просто потому, что не понимают как сделать каскадный JOIN на M-N-K отношение и дербанят его по частям, чтобы потом собирать обратно уже в коде. Примеров много.
Все это произрастает как раз из отсутствия понимания таких базовых вещей как нормальные формы.
Druu там выше написал, что:
Если же бд приходится постоянно дорабатывать — сохранение нормальности сильно усложняет процесс, т.к. часто требует достаточно глубоко изменять структуру базы, в то время как при отказе от нормальности достаточно добавить одно поле в таблицу.
Так вот понимание НФ как-раз и позволяет еще на этапе проектирования базы определить такую структуру, чтобы не приходилось ради добавления пары полей нырять с головой в ад миграций или забивать пол-базы нулями.
При этом страдает расширяемость бд и производительность.
Страдает она именно у тех кто при проектировании положил болт на вещи вроде НФ а-ля «все-равно база будет меняться». Если системный архитектор нормально выполнил свою работу, модификация структуры базы — штатная рутина.
Рекомендую вам остановиться и прочитать классическое "Введение в базы данных" Криса Дейта.
Я каждого своего джуна заставляю учить нормальные формы до НФБК, и регулярно, например в курилке или на обеде, терроризирую их спонтанными вопросами-примерами вроде "у тебя есть такая задача, расскажи как ты будешь делать базу..."
Потому что помимо прикладного навыка, это ещё и абстракция инженерного мышления.
Джуны не будут расти, если их не грузить такими вещами. Ну за редким исключением, но такие исключения недолго сидят в джунах))
В плане готовки ИИ еще долго не превзойдет человека, потому что он не чувствует «вкуса данных», которыми оперирует. Даже если разработать какие-то вкусовые метрики, вкусы людей очень сильно отличаются. К тому же люди очень по-разному улавливают вкусовые интонации и детали. Так что у ИИ просто не хватит воображения придумать что-то интригующее, все это в рамках случайных попаданий в процессе комбинаторики, всеравно оцениваемых потом людьми. Плюс, он врядле учитывает декомпозированную сложность приготовления, вот например…
Ставим кастрюлю с водой (2 литра) кипятиться. Пока она греется, в миску пару желтков яиц (отделить желтки от белков, если попадет немного белка нестрашно). Потом выжать в яица половину небольшого лимона, следя чтобы не попали семечки, и хорошенько все это взбить. Когда вода закипит — вылить смесь желтка и лимона в нее. Лимон не даст яйцу свернуться и получится наваристый бульон. Потом долить в бульон немного сливок, и дать покипеть минут 5, после чего закинуть туда макароны на свой вкус — рачки, ломаные спагеттины, вермишель, флотские или другие. Когда макарохи почти сварились, добавить сверху водоросли НОРИ, которые для роллов, поломав их на кусочки нужного размера, и дать еще постоять. Специи по вкусу.
Делается минут за 10-15, главное найти баланс лимона, потому что чуть меньше — яица свернутся в кипятке… но чуть больше и получится невыносимая кислятина.
Это все прекрасно, но снова про английский язык. Даже на конференциях вроде ДИАЛОГ-а подавляющее большинство прикладных разработок — про английский язык. Где же такие статьи и системы для русского языка?
Когда 6 падежей, а не 2 как в английском. Когда язык поддерживает все 6 базовых порядка слов, а не 2 как в английском. Когда время равномерно размазано по всему языку, и присутствуют маркеры которые контекстно могут относиться к любому времени, а не организованы в аккуратные 12 времен. Когда омонимия — это половина языка, а сам язык при этом настолько инкапсулирует контекст, что в нем что угодно можно выразить смешивая императив и декларатив, и положить болт на их противоречия. В противовес английскому, который исторически формировался как инструкция (благодаря чему и стал техническим языком).
И потом, от статей с таким названием лично я вот уже много лет ожидаю, что в них расскажут о том как красиво кто-то автоматизировал хотя бы процессы синтеза правил. А в итоге в каждой статье одно и тоже — снова и снова переизобретается интерфейс для колоссального ручного труда.
Даже под капотом IBM WATSON постоянный ручной труд, разница лишь в том что когда IBM нужно сделать Ватсону поддержку японского языка, они просто покупают японскую компанию которая присоединяется к ручному наполнению Ватсона.
И даже в отношении английского языка… ну вот есть ChatScript. И что же в нем прям радикально отличает его от хотя бы OWL/RDF? Да даже от реляционно связанных предикатов, использующихся как основа для регулярок — такое можно написать просто на Python, PHP, JS, хоть на бейсике.
Где и в чем он упрощает разработку при создании чат-ботов? А сопровождение эксплуатируемой системы? Почему система использующая ChatScript не потонет в хаосе и безумии мониторинга, оценки, ранжирования, модификации и контроля правил, когда их количество перевалит хотя-бы за 10000? А 100000? А миллион?
ChatScript только для маленьких систем? Эффективен только в системах с количеством правил в районе 100? Если у меня весь проект на Python, зачем мне тащить в маленький проект целый +1 язык ради 100 правил?
Это все прекрасно пока у вас 1 страница админки соответствует 1 объекту данных. А можете ли вы в рамках такой системы разруливать ситуации, когда у вас N объектов данных на странице, и доступ назначается не столько к данным, сколько к сценариям того, что можно выполнить с этими данными?
Например если на странице несколько объектов связанных в БД отношением класса M-N-K, и действия одного пользователя должны влиять на них всех, а другой пользователь части из них даже не видит, но может работать с видимой ему частью.
Насколько я знаю, для такого пока никто не придумал удобных решений. Это делают либо цепляя доступ к вьюхам, а не к моделям. Либо вообще выносят проверку доступа вместе с бизнес-логикой в интеграционную шину, а приложения и базы априори считают, что если им какая-то команда пришла от шины, значит шина 100% все проверила и разрешила.
Но управлять таким доступом все-равно ад в обоих этих решениях, для любой более-менее крупной и сложной системы.
А если туда ещё подвозят мандатные метки уровня ОС...
Лол, письменность? Вы чё шумеры штоле? На дворе 2017!!! Поди прогуливали телепатию в школе?)))
Я ни разу не в защиту оберона или модулы, но я например вообще не знаю JAVA. При этом у меня есть знакомый, который вообще не знает Python… И это никогда не мешало нам обсуждать алгоритмы и архитектуры.
Ну восхваляет кто-то фортран в 2017-м, зачем на него агриться если только цель не в умышленном троллинге?))
Когда я поступал, на кафедре куда я хотел было 10 бюджетных мест, 10 целевых и 40 платных. И вот 10 бюджетных мест заняли медалисты, 10 — целевики за которых платят предприятия, а они потом должны 3 года отработать за это на местах. А что делать остальным? Искать другую кафедру или другой ВУЗ? Так в них та же самая картина)
Почти в 5 раз разница. А теперь вспоминаем, что средняя зарплата айтишника в провинции 30к плюс-минус… все-еще настаиваете, что отправить в топовый ВУЗ ничего в плане денег не стоит?
Я имею ввиду не политиков, а бизнес-элиту. Тех кто выше среднего класса. Когда человек не может позволить себе отправить детей в MIT, но может в ИТМО, он не будет отправлять их в университет Мухосранска. И университеты знают это, возможно отчасти поэтому в провинциях они и не парятся.
На более старших курсах пример курсовой — написать планировщик задач для ОС с определенными зарактеристиками, выполнить исследования по «пропускной способности» в зависимости от настроек и т.д.
Написать АИС для институтской библиотеки с полным циклом — учет книг, читателей, все операции с ними, репликация между филиалами в разных зданиях библиотеки, каталог, поиск, стыковка для веб-интерфейса (без реализации оного), создание «кубов» для анализа, вывод аналитических справок
Мы же говорили о курсовой, т.е. о достаточно большом проекте.
Даже интересно стало, как выглядели курсовые у вас — в нормальном ВУЗе?)) Наши «курсовые» выглядели так, преподаватель дает тебе задачу из какого-неть учебника, на какой-то мат-метод… чаще всего это было либо что-то из Кнута, либо какой-нибудь метод оптимизации. И тебе нужно написать прогу для его реализации, и предоставить пояснительную записку листов на 10 — что там такое и как оно работает. «Большими проектами» там и не пахло)))
Есть ТЗ, неотъемлемой частью которого...
Нет, не было никаких ТЗ +)) Была постановка задачи — «Написать программу для демонстрации сортировки пузырьком». Все +))
И да, предлагаю оставить этот спор, т.к. я все-равно останусь при своем мнении, что a = a + 1 или if x < y: можно понять для любого ЯП, и преподаватель который устраивает из-за этого истерику… ладно, мы же люди культурные… некомпетентен.
Скорее просто студенты, которые поступили в ВУЗ после 10 лет в школе, не имеют достаточного жизненного опыта. Я школу закончил в 18 и имел опыт написания бумаг, жалоб, представлял, как работает бюрократическая машина, и куда давить.
Все в ВУЗ поступали в 17-18, после 10 лет в школе. Не осознал в чем ваша уникальность окончания школы в 18 лет?
А что касается бумаг, жалоб и бюрократической машины… вы видимо еще не сталкивались с ситуацией, когда бюрократическая машина перемалывает вас своими жерновами, ломая все кости) Потому что ей нужно не обучать студентов, ей нужно платить зарплаты преподавателям, от которых ВУЗам не так-то просто избавиться… да и кем их заменить?)
Например мы все (я надеюсь, а то уже страшновато) знаем сортировку пузырьком. В продакшене никто из нас ее не применяет, потому что есть более оптимальные сортировки. Но мы все начинаем с нее, потому что если на человека сразу вывалить Smoothsort у него порвет шаблон.
Но в то же время — чем больше разных способов сортировки человек знает, тем более оптимальный код он пишет — потому что выбирает инструмент под задачу, а не переизобретает велосипеды в мучениях. С нормальными формами то же самое.
www.sitepoint.com/hierarchical-data-database-2
www.caktusgroup.com/blog/2016/01/04/modified-preorder-tree-traversal-django
Если кратко, без MPTT быстрая вставка но медленное чтение. С MPTT медленная вставка (поскольку приходится пересчитывать атрибуты MPTT) но быстрое чтение. Идеальный вариант для больших и редко меняющихся справочников, вроде общероссийских классификаторов или деревьев гео-данных.
И я нигде не писал что прохождение моего теста сводится к знанию MPTT. Я писал что лишь 1 из 10 джунов знает о нем, остальные решают либо через JOIN-ы, либо через рекурсию.
И я никого не заставляю делать это на собеседовании, обычно даю им такой тест на дом, дня на 2-3, чтобы они могли решить задачу в комфортной для себя обстановке и с интернетом (да хоть под пиво, музыку и с девочками).
Потому что как по мне, способность быстро найти, усвоить и использовать инфу — не менее важный навык для IT-шника, чем базовые знания. Т.е. если джун знал о базах только CRUD, но за пару вечеров разобрался в MPTT и сделал с ним тестовый пример — он мне подходит)
Меня это удивляло ровно до того момента, пока я не узнал что преподаватели в самых разных ВУЗах тоже про MPTT ничего не знают… все это очень печально(((
Но при этом если вашим конкурентом на должность будет равный вам специалист, который четко ответит что 1НФ это «Атомарность», и означает что каждый кортеж отношения содержит только одно значение для каждого из атрибутов, и нарисует табличку-пример — будьте уверены, возьмут его. Потому что он может оптимизировать сетевое взаимодействие зная как определить, что в лаге виноват косяк в базе сервиса, а не сокет.
Тем не менее, изучить все времени не хватает ни у кого)) Поэтому я рекомендую вам пораньше начинать вливаться в ту сферу и должность, на которой вы хотите работать. Искать инфу, ходить по мероприятиям, докапываться до всех с вопросами.
Вам нужно определить круг критичных для этой работы навыков, без которых у вас просто нет шансов. И круг вторичных навыков — которые повышают вашу конкурентоспособность. Расставить приоритеты и учиться, а если сможете — пробовать делать то, чем собираетесь заниматься.
Идете в бэкенд — пишите сервисы для себя. Идете в РП — пишите бизнес-планы для себя. Идете в SEO — пишите планы продвижения для себя. Идете в маркетинг — пишите рыночные исследования для себя.
Если вы не сможете делать это для себя, не сможете и для кого-то. И в этом нет ничего плохого, просто значит вам это не очень интересно. И это лучше узнать на берегу, чтобы потом не пополнить ряды тех кто ноет что им не нравится их работа.
А если сможете — шикарно, поскольку у вас начнет формирования понимание разницы между учебой и реальностью. Плюс, вы сможете прямо на первое же собеседование принести тучу своих тренировочных примеров. Профит +)))
Да, говорим об одном и том же) Спасибо за уточнение)
Возможно разница в восприятии, я когда слышу «ORM управляет схемой», для меня это значит что в приложении есть функционал, который в штатной работе системы на лету модифицирует ее структуру. А не то, что ORM в принципе умеет это делать.
Это в фреймворке можно так сделать, когда пишешь ручками)) Например в Django это prefetch_related — а вот в коробках типа Drupal где изменение схемы данных автоматизировано и делается мышкой из админки, все работает через mainhook — и количество запросов к базе со временем становится просто убийственным))
А если это распределенная система, работающая в реальном времени, с репликациями, синхронизацией и тяжелыми данными, цена ошибки на этапе проектирования БД будет фатальной.
ORM управляет схемой? Что вы там курите?)))
ORM в 99% случаев лишь отражает схему в DAL. Но независимо от того мигрирует ли ваша ORM таблицы в классы кода, или же классы в таблицы и отношения СУБД — все-равно сначала нужно спроектировать саму базу и уже только потом реализовывать интерфейсы для нее в ORM.
Проект в котором приложение имеет доступ к миграциям БД для динамической модификации схемы данных — огромная редкость) И я не беру в расчет сейчас банальные вещи вроде Drupal который просто создает таблицы под ваш CCK, потому что думаю мы все знаем что потом происходит с количеством запросов к базе. ИМХО, нужно быть конченым психопатом, чтобы строить большую сложную систему по такому принципу.
Проектирование и разработка информационных систем — от сайтов общего назначения (новостные порталы, интернет магазины и т. д.) до специальных систем обработки данных, автоматизации процессов и др.
Знание баз данных и мышление в их категориях, это один из критичных навыков для бэкенд-разработчика.
Его отсутствие порождает персонажей, которые берут SQL запрос работающий 5мс и переводят в ORM так, что он работает 5 минут — просто потому, что они не понимают как работают индексы по составным ключам, например. Или страдают с запросом N дней просто потому, что не понимают как сделать каскадный JOIN на M-N-K отношение и дербанят его по частям, чтобы потом собирать обратно уже в коде. Примеров много.
Все это произрастает как раз из отсутствия понимания таких базовых вещей как нормальные формы.
Druu там выше написал, что:Так вот понимание НФ как-раз и позволяет еще на этапе проектирования базы определить такую структуру, чтобы не приходилось ради добавления пары полей нырять с головой в ад миграций или забивать пол-базы нулями.
Страдает она именно у тех кто при проектировании положил болт на вещи вроде НФ а-ля «все-равно база будет меняться». Если системный архитектор нормально выполнил свою работу, модификация структуры базы — штатная рутина.
Рекомендую вам остановиться и прочитать классическое "Введение в базы данных" Криса Дейта.
Я каждого своего джуна заставляю учить нормальные формы до НФБК, и регулярно, например в курилке или на обеде, терроризирую их спонтанными вопросами-примерами вроде "у тебя есть такая задача, расскажи как ты будешь делать базу..."
Потому что помимо прикладного навыка, это ещё и абстракция инженерного мышления.
Джуны не будут расти, если их не грузить такими вещами. Ну за редким исключением, но такие исключения недолго сидят в джунах))
Лол, продолжай)) Я заинтригован)))
Ставим кастрюлю с водой (2 литра) кипятиться. Пока она греется, в миску пару желтков яиц (отделить желтки от белков, если попадет немного белка нестрашно). Потом выжать в яица половину небольшого лимона, следя чтобы не попали семечки, и хорошенько все это взбить. Когда вода закипит — вылить смесь желтка и лимона в нее. Лимон не даст яйцу свернуться и получится наваристый бульон. Потом долить в бульон немного сливок, и дать покипеть минут 5, после чего закинуть туда макароны на свой вкус — рачки, ломаные спагеттины, вермишель, флотские или другие. Когда макарохи почти сварились, добавить сверху водоросли НОРИ, которые для роллов, поломав их на кусочки нужного размера, и дать еще постоять. Специи по вкусу.
Делается минут за 10-15, главное найти баланс лимона, потому что чуть меньше — яица свернутся в кипятке… но чуть больше и получится невыносимая кислятина.
Когда 6 падежей, а не 2 как в английском. Когда язык поддерживает все 6 базовых порядка слов, а не 2 как в английском. Когда время равномерно размазано по всему языку, и присутствуют маркеры которые контекстно могут относиться к любому времени, а не организованы в аккуратные 12 времен. Когда омонимия — это половина языка, а сам язык при этом настолько инкапсулирует контекст, что в нем что угодно можно выразить смешивая императив и декларатив, и положить болт на их противоречия. В противовес английскому, который исторически формировался как инструкция (благодаря чему и стал техническим языком).
И потом, от статей с таким названием лично я вот уже много лет ожидаю, что в них расскажут о том как красиво кто-то автоматизировал хотя бы процессы синтеза правил. А в итоге в каждой статье одно и тоже — снова и снова переизобретается интерфейс для колоссального ручного труда.
Даже под капотом IBM WATSON постоянный ручной труд, разница лишь в том что когда IBM нужно сделать Ватсону поддержку японского языка, они просто покупают японскую компанию которая присоединяется к ручному наполнению Ватсона.
И даже в отношении английского языка… ну вот есть ChatScript. И что же в нем прям радикально отличает его от хотя бы OWL/RDF? Да даже от реляционно связанных предикатов, использующихся как основа для регулярок — такое можно написать просто на Python, PHP, JS, хоть на бейсике.
Где и в чем он упрощает разработку при создании чат-ботов? А сопровождение эксплуатируемой системы? Почему система использующая ChatScript не потонет в хаосе и безумии мониторинга, оценки, ранжирования, модификации и контроля правил, когда их количество перевалит хотя-бы за 10000? А 100000? А миллион?
ChatScript только для маленьких систем? Эффективен только в системах с количеством правил в районе 100? Если у меня весь проект на Python, зачем мне тащить в маленький проект целый +1 язык ради 100 правил?
Это все прекрасно пока у вас 1 страница админки соответствует 1 объекту данных. А можете ли вы в рамках такой системы разруливать ситуации, когда у вас N объектов данных на странице, и доступ назначается не столько к данным, сколько к сценариям того, что можно выполнить с этими данными?
Например если на странице несколько объектов связанных в БД отношением класса M-N-K, и действия одного пользователя должны влиять на них всех, а другой пользователь части из них даже не видит, но может работать с видимой ему частью.
Насколько я знаю, для такого пока никто не придумал удобных решений. Это делают либо цепляя доступ к вьюхам, а не к моделям. Либо вообще выносят проверку доступа вместе с бизнес-логикой в интеграционную шину, а приложения и базы априори считают, что если им какая-то команда пришла от шины, значит шина 100% все проверила и разрешила.
Но управлять таким доступом все-равно ад в обоих этих решениях, для любой более-менее крупной и сложной системы.
А если туда ещё подвозят мандатные метки уровня ОС...
Лол, письменность? Вы чё шумеры штоле? На дворе 2017!!! Поди прогуливали телепатию в школе?)))
Я ни разу не в защиту оберона или модулы, но я например вообще не знаю JAVA. При этом у меня есть знакомый, который вообще не знает Python… И это никогда не мешало нам обсуждать алгоритмы и архитектуры.
Ну восхваляет кто-то фортран в 2017-м, зачем на него агриться если только цель не в умышленном троллинге?))
1. Бауманка, isot.bmstu.ru/edu/price/price-17181718.html — от 257к в год
2. Тюменский индустриальный, www.tyuiu.ru/stoimost-obucheniya — от 56к в год
Почти в 5 раз разница. А теперь вспоминаем, что средняя зарплата айтишника в провинции 30к плюс-минус… все-еще настаиваете, что отправить в топовый ВУЗ ничего в плане денег не стоит?
Я имею ввиду не политиков, а бизнес-элиту. Тех кто выше среднего класса. Когда человек не может позволить себе отправить детей в MIT, но может в ИТМО, он не будет отправлять их в университет Мухосранска. И университеты знают это, возможно отчасти поэтому в провинциях они и не парятся.
Нет, не было никаких ТЗ +)) Была постановка задачи — «Написать программу для демонстрации сортировки пузырьком». Все +))
И да, предлагаю оставить этот спор, т.к. я все-равно останусь при своем мнении, что a = a + 1 или if x < y: можно понять для любого ЯП, и преподаватель который устраивает из-за этого истерику… ладно, мы же люди культурные… некомпетентен.
Все в ВУЗ поступали в 17-18, после 10 лет в школе. Не осознал в чем ваша уникальность окончания школы в 18 лет?
А что касается бумаг, жалоб и бюрократической машины… вы видимо еще не сталкивались с ситуацией, когда бюрократическая машина перемалывает вас своими жерновами, ломая все кости) Потому что ей нужно не обучать студентов, ей нужно платить зарплаты преподавателям, от которых ВУЗам не так-то просто избавиться… да и кем их заменить?)