Позволю себе добавить также упоминание каналов DotNetRu и DotNext , там много полезного по .NET/Azure/Microsoft технологиям для русскоязычной аудитории.
Хорошая программа, особенно спасибо за «Building Cloud Native applications with .NET 5 and AKS»,
Я вообще считаю, нужно больше докладов для только вкатывающихся в платформу, чтобы было понятно — как просто (или легко?) начать систему на .NET, не загружаясь сразу в дебри DDD и луковых архитектур.
сожалел о том, что каждый его пост в блоке «привлекает сотни комментариев» и «теперь надо аккуратнее высказывать свое мнение», потому что сообщество часто понимало его слова слишком буквально.
Пожалуй да, а то получается неловкая ситуация судя по материалам статьи (глубже не копал).
Сначала несколько лет громко популяризировать свою собственную платформу, убеждая людей что её можно и нужно использовать, люди поверили ему.
Потом взять и фактически изящно кинуть всех, бросить своё детище и уйти на Go.
Потом также бодро соскочить на Rust.
Тем временем, те кто поверил ему и выбрал Node.js как свою основную платформу (энтерпрайз даже) вынуждены были выстроить своё сообщество, сами развивать систему и бороться с врождёнными болячками, который лучше всего как раз мог бы исправлять прародитель платформы.
Интересно, есть ли теперь новые желающие последовать за ним в новое потрясающее приключение с Deno?
Спасибо за детальный перечень с указанием Зачем и Почему, больше лучших и инженерных практик в мире — лучше в мире. :)
Напомнило: https://habr.com/ru/company/jugru/blog/159689/.
Правда я присутствовал только на одном семинаре и только в качестве ментора. Мы на последнем занятии собрали анонимные отзывы на наш курс. За всё время обучения в ЛЭТИ у меня такого не было ни разу.
Технически, никто не запрещает проявить такую инициативу, если договориться с людьми и наладить контакт.
Например, я в последние года в конце каждого семестра стал давать студентам анонимную гугл доку с опросом — Что было хорошо в курсе, в лекциях, а что можно улучшить, где были просадки по темам. Т.к. опрос анонимный и семестр уже закончился, то за проблемы на зачете и последующие преследования студенты почти не переживали. :)
Я лишь хочу сказать, что на местном уровне — всё в наших руках.
Как это обычно бывает в нашей стране — строгость формальных процедур компенсируется отсутствием возможности у проверяющих постоянно за ними следить.
Если у вас есть желание, вы можете взять на себя инициативу по улучшению, экспериментальным методам обучения, сделать всё здорово.
Если на выходе результат соответствует требования, предмет изучен и студенты успешно сдают проверочные работы, то вроде как всех всё устраивает.
Другой вопрос, что поддержку и заинтересованность в этом сложно найти зачастую, чтобы потом продолжили, см. пункт про ригидность и KPI. :(
Не было ощущения, что вы в аспирантуре как почти бесплатная рабочая сила?
Именно у меня ощущения такого не было, я хотел сам преподавать,
Получается параллельно с аспирантурой я работал как преподаватель на кафедре на 0.25 ставки, что жёстко ограничивало нагрузку максимум 6 парами в 2 недели, а обычно их было 4.
Также 1 обязательный курсовик (переходящий в дипломника) из каждого нового набора, и иногда приходилось брать еще 1 дополнительно, т.к. человек очень хотел заниматься особым проектом, а нужные технологические знания имелись только у меня, просто хотелось помочь умным студентам.
По времени я всегда выбирал самые ранние занятия либо самые поздние, т.к. жил рядом с университетом, и конкуренции обычно не возникало, как и желания у кого то встроиться в окошко. :)
Подозреваю, мой пример не самый показательный. Встречались аспиранты кто вообще покрывал лишь минимальную нагрузку в 10-20 часов на год (что-то вроде того). Я слышал единичные случаи и про 0.5 ставки у аспирантов, что давало в 2-2.5 раза больше нагрузки, это действительно жестковато совмещать с работой. Вероятно, зависело от условий и результатов переговоров с кафедрой.
Могу сказать взгляд изнутри, т.к. тесно общался с преподавателями и посещал заседания кафедры. Основные преподавателя кафедры действительно всегда рады «поделиться» учебной нагрузкой, т.к. на одного человека приходится очень много часов из за всяких оптимизаций штата, заочников и вечерников. Поэтому, старались аспирантам отдать дневную нагрузку, где хотя бы самые адекватные вменяемые студенты, к которым обычно не требуется применения воспитательных мер.
сейчас многие вузы стараются ввести проектную деятельность и компетентностно-ориентированный подход. Иногда доходит до странного, когда студентов первокурсников меда и IT совмещают в группы, чтобы они выдали совместный проект (НовГУ).
Мы немного практиковали как раз такое кросс-кафедральное взаимодействие, я вообще очень радовался когда подобное удавалось, ведь IT само по себе сферично в вакууме, ему нужна предметная область. Однако, это было очень индивидуально и сильно зависело от общительности самих студентов и готовности научрука с Не-IT кафедры. Массового внедрения не случилось, к сожалению.
Не знаю, как с этим обстоят дела в обучении, но в аспирантуре мне сказали, что можешь приглашать любых деятелей и ученых из твоей области — проезд мы оплатим. Связи же налаживать нужно.
Единственное, что я знаю, так это то, что математику тоже часто дают в отрыве от реальности.
Вопрос скорее о проценте полноценных преподавателей кафедры, которые не ведут научной деятельности т.к. успешными предсдавителями производства. Он был у нас достаточно низок, чисто чтобы закрыть минимальное требование от министерства.
Попробую высказать своё мнение, как человека с кандидатской степенью и по касательной прошедшего рядом с наукой,
слабая связность системы высшего образования при низком уровне гибкости
Да, отчасти. Например, в нашем в ВУЗе:
Плюс — старались с 1го курса определить путь развития студента до диплома (и даже магистерской), чтобы он постоянно продвигал исследование в нужную сторону, и показать существование конференций, крупных журналов и вообще научного мира (хотя сильно зависит от кафедры);
Плюс — с некоторых пор у нас ввели Компетентностно-ориентированный подход к образованию, который позволяет ведущему преподавателю включить в учебную программу любые темы лекций и любые материалы, главное чтобы они развивали необходимые компетенции, даже сами предметы можно знатно перетасовать (хотя опять же, сильно зависит от кафедры и деканата);
Плюс/Минус — общеобразовательные предметы вроде той же философии, КСЕ или разных видов математики я считаю полезными, они дают разминку уму, НО и отлично понимаю, что тут бы делом начать наконец то заниматься, а не ум разминать, кому понадобится — нагонят в будущем;
Минус (жирный) — военная кафедра отжирает у парней студентов невероятные силы, просто огромные старания уходят на ублажение запросов военных преподавателей по их крайне сомнительным предметам и уж тем более сомнительным методам преподавания;
Вообще обязательная воинская повинность имеет явное влияние на наше образование и науку, как мне думается.
С одной стороны, благодаря страху ухода в армию — многие парни стараются таки отучиться в ВУЗе, получить какой-никакой уровень знаний.
С другой, некоторые из них ведь занимают чьи то бюджетные места понапрасну, создают лишнюю работу ВУЗам (хоть и приносят деньги), вынуждая просеивать сотни студентов в поисках единиц толковых.
отсутствие науки как таковой в провинциальных ВУЗах
Зависит,
Чисто на уровне догадки разве что я верю, немало будущих интересных идей было заложено в ходе университеских исследований, хотя именно доделаны вряд ли в стенах университета.
избыток “научных сотрудников”, ригидность мышления профессоров и низкое качество публикаций
Поделитесь, пожалуйста, а как обстоят дела в вузах США и Европы насчет — Доли ненаучных сотрудников кафедр и преподавателей?
Т.е. представителей компаний/предприятий/бизнеса, которые могли бы делиться реальными знаниями и показывать связь изучаемого с практикой, а заодно и приносить новые идеи по внедрению науки в производство.
В нашем вузах были строгие требования на научную работу кафедр, практически весь состав кафедры должен писать статьи и участвовать в грантах. Более того, за подобную работу преподаватели получают баллы, а вуз каждый год якобы решает на основе этих баллов — продлить контракт или нет. Лишь небольшая доля представителей производства освобождалась от этого.
От того и имели что имели:
Огромное количество публикаций, по 8 авторов вписанных в статью, чисто ради галочки, хотя эти люди могли бы просто хорошо делать своё дело — преподавать свои предметы, глядишь и время нашлось на обновление материала в ногу со временем.
Постоянный уровень стресса в погоне за баллами, новые метрики, хотя по факту альтернатив этим людям нет на рынке.
Думаю, отчасти ригидность мышления вызвана такими навязанными KPI на которые тратится много ментальных усилий, а потом еще надо где то взять силы на преподавание, на обдумывание вместе со студентом его курсовой/дипломной (по, вероятно, совершенно новой для тебя теме).
Причем преподаватели любящие своё дело находят силы и еще как, за что низкий поклон. Видел как вытягивают даже самых сомнительных персонажей, ставят им речь и вправляют извилины.
слабая культурная поддержка отечественной науки и неспособность сложившейся системы образования создавать качественные проекты.
Отмечу, кстати, за участие в конференциях разного уровня и статьях в крупных журналах — вполне удавалось получить и правительственные стипендии, и президентские, которые прилично добавляли в личный бюджет.
Хотя согласен — это крайне не надежный способ выживания, если бы я жил только на университетские деньги.
Благодарность за выпуск, хоть и многое общими словами, но много отссылок на подробные материалы,
Хочу еще поделиться подборкой ссылок что мне когда то посоветовали — Self learning DDD: https://emacsway.github.io/ru/self-learning-for-software-engineer/#ddd, список выглядит достаточно внушительно.
А я всё же поддержу автора и его размышления о слове «микро», и это ни разу не словоблудие.
Мы, люди, общаемся при помощи слов. Более того, бОльшую часть времени мы мыслим при помощи слов. Слова важны.
Каждое слово может иметь несколько значений, которые зависят от различных контекстов (опа, и тут контексты?). Нюанс в том, что если один контекст более распространён, то он может перекрыть прочие и люди даже не задумаются о прочих значениях.
Не берусь утверждать наверняка, но слово «микро» всё же обычно воспринимается в контексте размера, а не рассуждений о предметной области.
Многие разработчики изначально ограничились осознанием слова «микро» как указанием размера, оттого мы и имеем что имеем. Потребовалось много лет прежде чем до широких масс дошла идея про разбиение сервисов по фрагментам предметной области.
Поэтому, я категорически согласен, термин изначально был выбран не идеально. Но его ведь надо было как то продавать, чтобы затмить предыдущие идеи, вот и раскрутили звучное название.
Вам когда-нибудь приходилось анализировать 7 уровней try/catch методов с возможным отловом и обёртыванием/заменой типа исключения на каждом из уровней?
Стараюсь держать исключения только для самых неимоверно жутких ситуаций, а в идеале вообще обходиться без них, потому что из за них код неимоверно: 1) разбухает, 2) тормозит, 3) теряет линейность и предсказуемость. Пожалуй, потеря линейности это самая главная моя претензия к пользовательским исключениям.
Более того,
Как показывает опыт, рано или поздно, Бизнес захочет видеть максимум подробностей для любой возникающей ошибки, процесса обработки вообще, накопленных итогов валидации и т.п.
Тогда то исключения и плавно уходят в сторону ближайшей рощи, а у вас появляется класс вида подобного логам:
public class Message
{
public LevelEnum Level { get; set; }
public string Text { get; set; }
// Если смогли отловить исключение, то оно пригодится.
public Exception Error { get; set; }
}
Процессоры же отвечающие за обработку бизнес-логики начинают накапливать итоги ошибок:
public TResponse ProcessSomething(...)
{
// Ответ имеет коллекцию List<Message> и метод Add добавляющий в неё.
var response = new FooResponse();
Message msg;
var step1 = DoStepOne(out msg);
if (!response.Add(msg).IsSuccess)
return response;
// Или с приходом ValueTuple и моды на Go:
var (step2, msg2) = DoStepTwo(...);
if (!response.Add(msg2).IsSuccess)
return response;
// Или с приходом моды на Монады:
var step3WithMessageMaybe = DoStepThree(...);
if (!step3WithMessageMaybe.TryGetRight(out var step3))
return response.Add(step3Maybe.Left);
// А иногда нужен более подробный объектный трейс:
var step4WithTraceMaybe = DoStepFour(...);
if (!step4WithTraceMaybe.TryGetRight(out var step4))
return response.AddFooTrace(step4WithTraceMaybe.Left);
...
}
Лично для меня, все 3 варианта выглядят плюс-минус одинаково и все они имеют риск опечатки, когда случайно используется ответ/результат из предыдущего шага. Railway Oriented Programming (или ссылка #2) подход отчасти может уменьшить риск опечатки, но с накоплением сложного трейса в нём туже.
Ведь создание сущности — это команда, а получение Id — запрос.
По моему личному опыту, строго разделение на «команды» и «запросы» — довольно иллюзорно. Для команд рано или поздно (скорее рано) появится необходимость возвращать больше информации в ответе. Для запросов выяснится, что надо попутно записать информацию в аудит или счетчики, т.е. это уже будет не совсем чистый запрос.
_tecture.Save()
Выглядит как потенциально протекающая абстракция, ибо для других каналов может отсутствовать функция накопления операций (данных?) в памяти. Вот для работы в транзакции, например, это будет обоснованно, но всё равно хочется как то иначе это организовать (пока не знаю как).
Будем подождать 3ю часть этого сериала, пока интригующе, спасибо! :)
Отдельное спасибо за перечисление откуда берётся бардак, открыто подсвечивать проблемы это важно.
— Это IoC!
О-о-о эти длинные конфигурации DI-контейнеров, они изящно прячут от нас сотни или даже тысячи микро-зависимостей. Однако же, в случае их поломки или несовместимости — это невозможно починить на глазок, надо закапываться в исходники и раскручивать всю цепочку. Если же у вас есть сторонние крупные модули которые несут свои собственные конфигурации, то можно смело возводить веселье в квадрат.
Конечно, без DI-контейнеров жилось бы хуже (наверняка). Где грань между рациональным использованием автоматической инъекции зависимостей и неуправляемым мессивом из интерфейсов — мне неизвестно, пока что.
Будем ждать ссылку на репозиторий с версией готовой к открытому релизу. :)
Сам не пишу на TypeScript, потому при прочтении не слишком осознал проблему, вроде же на каждом углу трубят что TS = строго типизированный JS.
Но недавно вышла статья: Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты.
Вернулся сюда, перечитал, теперь понял. Будем знать, спасибо!
Вдруг кому тоже пригодится.
Спасибо большое за доклад! Хочу дополнить вопросом и рассказом,
Вопрос: Если мы имеем и используем сильную декларативную выразительность ограничений типов, это еще лишь точная Анемичная модель, или уже недоделанная Богатая?
Рассказ: Когда речь заходит про выразительность модели предметной области, то мне сразу вспоминается Онтологическое проектирование вместе с инструментами RDFS и OWL, при знакомстве с которыми я был удивлен насколько иначе можно представить предметную область, нежели в известных мне C#/Java/RDBS.
Как пример, Наследование Классов:
В Онтологиях наследование «subClassOf» означает сужение, уточнение подмножеств классов и экземпляров, что соответствует действительности, ведь Студентов вообще меньше чем Человеков.
В Классических ООП языках наследованием же обычно называется расширение базового класса. Наблюдательный программист увидит в этом конкретизацию типа (ведь Student унаследованный от Person можно привести к Person, но не наоборот), особо заметно это на примитивах.
Однако, в обсуждениях зачастую я слышу именно термин «расширение».
Другой пример, Наследование Свойств:
Если свойство «Length» имеет наследников «OfficialLength» и «EstimatedLength», то они унаследуют ограничения базового свойства, а также, наличие любого из свойств наследников будет означать наличие базового.
Заголовок спойлера
В классическом ООП и реляционных БД обычно такое реализуются через связующую сущность (таблицу) с необходимыми свойствами, и хранением типа этой сущности, справедливости ради это позволяет сохранить даже больше информации о связи.
Однако, создаются такие промежуточные сущности тоже нечасто (для этого требуются манипуляции в хранилище) и зачастую «протекают» (если их вовремя не превращают в самостоятельную сущность). 99% свойств это всё таки именно свойства.
Разумеется, у этих инструментов есть и недостатки, придумывались они прежде всего под научные цели, немного оторванные от реальной жизни. Хотя концепции там имеются любопытные и мне видится они уже проникают понемногу в привычную разработку ПО благодаря приходу графовых БД (крупные игроки стали вписываться в эту область), правда простое использование графов как способа хранения даст лишь самую малую толику от возможной выразительности предметной области, на мой взгляд.
К сожалению не подскажу за другие языки программирования, знаю лишь поверхностно, интересно было бы узнать как там с подобными понятиями.
Подозреваю опечатку в своём тексте, думаю правильнее говорить о «сложении» вероятностей.
Вполне могу признать, что мои познания в теории вероятностей далеко не идеальны, но вот сам подсчет мне видится приблизительно верным, ведь подсчитывается вероятность появления хотя бы 1 ошибки, эти события вполне себе совместные, а значит формула:
P(A+B)=P(A)+P(B)−P(A⋅B).
Вероятность наличия ошибки в одной строке кода: 0.01%.
Вероятность наличия ошибки во всех строках кода: 0.01%^10000 = очень мало.
Вероятность наличия хотя бы одной ошибки в любой строке кода: 0.01%*10000 — 0.01%^10000 ~= 100%.
Категорически извиняюсь, честно говоря, у меня имеется ощущение, что вы отчасти лукавите. :)
То ли специально чрезмерно иронизируете, то ли преувеличиваете своё ощущение усталости от похожих задач, то ли еще как назвать. Например:
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы».
Противоречит упомянутому ниже вашему хорошему качеству:
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
В любом случае, хочу отметить пару опасных допущений данной фразы:
мне не быть хорошим программистом несмотря на 15 лет опыта… А потому, у меня много опыта и я не был и не буду хорошим программистом.
1) «Хороший» программист (инженер) — не звание на всю жизнь, нельзя лишь почевать на лаврах прошлых заслуг, человек на определенном этапе развития может быть таковым, а потом может выгореть или решить немного отдохнуть и перейти в режим просто «Норм» — в среднем нормально решает знакомые задачи знакомыми методами без лишнего погружения и разбора деталей.
2) Цифра стажа — не определяет автоматически попадение в категорию «Хорошего», лишь повышая вероятность накопления определенного опыта, т.к. см. 1 первый — важно и как человек провел эти года, и каков он сейчас.
Уточню (обращу внимание) пункт «Бонус» — автор подразумевает именно тех, кто в первую очередь ориентирован на создании бизнеса — очень быстро такому человеку надоест копаться в техническом утройстве инструмента. Здесь соглашусь.
Однако, как и говорится в 3м пункте: «Суть программирования есть решение проблем». Опять же соглашусь, на мой взгляд, программист-практик обязан держать в голове решаемую проблему бизнеса из реального мира, а не фокусироваться на абстрактном творческом процессе.
Отчасти рассматривается: habr.com/ru/post/480204,
Правда, на мой взгляд, здесь есть грань — если переводить ситуацию в разряд «явной агрессией на явную агрессию», то IT сообщество в какой то мере себя и дискредитирует, по сути став на 1 шаг ближе к тем силам/процессам/глупостям которым противопоставляется. Ну на мой взгляд, но еще не обдумывал очень сильно.
Вот абсолютно согласен.
Претензия не к самой статье, а в целом было огромным удивлением узнать:
Заканчивается 2018 год, а фанаты "прогрессивных" языков до сих пор учатся генерировать WSDL/OpenAPI/ из метаданных сборки/кода.
Спасибо за подборку!
Позволю себе добавить также упоминание каналов DotNetRu и DotNext , там много полезного по .NET/Azure/Microsoft технологиям для русскоязычной аудитории.
Я вообще считаю, нужно больше докладов для только вкатывающихся в платформу, чтобы было понятно — как просто (или легко?) начать систему на .NET, не загружаясь сразу в дебри DDD и луковых архитектур.
Пожалуй да, а то получается неловкая ситуация судя по материалам статьи (глубже не копал).
Сначала несколько лет громко популяризировать свою собственную платформу, убеждая людей что её можно и нужно использовать, люди поверили ему.
Потом взять и фактически изящно кинуть всех, бросить своё детище и уйти на Go.
Потом также бодро соскочить на Rust.
Тем временем, те кто поверил ему и выбрал Node.js как свою основную платформу (энтерпрайз даже) вынуждены были выстроить своё сообщество, сами развивать систему и бороться с врождёнными болячками, который лучше всего как раз мог бы исправлять прародитель платформы.
Интересно, есть ли теперь новые желающие последовать за ним в новое потрясающее приключение с Deno?
Напомнило: https://habr.com/ru/company/jugru/blog/159689/.
Технически, никто не запрещает проявить такую инициативу, если договориться с людьми и наладить контакт.
Например, я в последние года в конце каждого семестра стал давать студентам анонимную гугл доку с опросом — Что было хорошо в курсе, в лекциях, а что можно улучшить, где были просадки по темам. Т.к. опрос анонимный и семестр уже закончился, то за проблемы на зачете и последующие преследования студенты почти не переживали. :)
Я лишь хочу сказать, что на местном уровне — всё в наших руках.
Как это обычно бывает в нашей стране — строгость формальных процедур компенсируется отсутствием возможности у проверяющих постоянно за ними следить.
Если у вас есть желание, вы можете взять на себя инициативу по улучшению, экспериментальным методам обучения, сделать всё здорово.
Если на выходе результат соответствует требования, предмет изучен и студенты успешно сдают проверочные работы, то вроде как всех всё устраивает.
Другой вопрос, что поддержку и заинтересованность в этом сложно найти зачастую, чтобы потом продолжили, см. пункт про ригидность и KPI. :(
Именно у меня ощущения такого не было, я хотел сам преподавать,
Получается параллельно с аспирантурой я работал как преподаватель на кафедре на 0.25 ставки, что жёстко ограничивало нагрузку максимум 6 парами в 2 недели, а обычно их было 4.
Также 1 обязательный курсовик (переходящий в дипломника) из каждого нового набора, и иногда приходилось брать еще 1 дополнительно, т.к. человек очень хотел заниматься особым проектом, а нужные технологические знания имелись только у меня, просто хотелось помочь умным студентам.
По времени я всегда выбирал самые ранние занятия либо самые поздние, т.к. жил рядом с университетом, и конкуренции обычно не возникало, как и желания у кого то встроиться в окошко. :)
Подозреваю, мой пример не самый показательный. Встречались аспиранты кто вообще покрывал лишь минимальную нагрузку в 10-20 часов на год (что-то вроде того). Я слышал единичные случаи и про 0.5 ставки у аспирантов, что давало в 2-2.5 раза больше нагрузки, это действительно жестковато совмещать с работой. Вероятно, зависело от условий и результатов переговоров с кафедрой.
Могу сказать взгляд изнутри, т.к. тесно общался с преподавателями и посещал заседания кафедры. Основные преподавателя кафедры действительно всегда рады «поделиться» учебной нагрузкой, т.к. на одного человека приходится очень много часов из за всяких оптимизаций штата, заочников и вечерников. Поэтому, старались аспирантам отдать дневную нагрузку, где хотя бы самые адекватные вменяемые студенты, к которым обычно не требуется применения воспитательных мер.
Мы немного практиковали как раз такое кросс-кафедральное взаимодействие, я вообще очень радовался когда подобное удавалось, ведь IT само по себе сферично в вакууме, ему нужна предметная область. Однако, это было очень индивидуально и сильно зависело от общительности самих студентов и готовности научрука с Не-IT кафедры. Массового внедрения не случилось, к сожалению.
Вопрос скорее о проценте полноценных преподавателей кафедры, которые не ведут научной деятельности т.к. успешными предсдавителями производства. Он был у нас достаточно низок, чисто чтобы закрыть минимальное требование от министерства.
Да, отчасти. Например, в нашем в ВУЗе:
Вообще обязательная воинская повинность имеет явное влияние на наше образование и науку, как мне думается.
С одной стороны, благодаря страху ухода в армию — многие парни стараются таки отучиться в ВУЗе, получить какой-никакой уровень знаний.
С другой, некоторые из них ведь занимают чьи то бюджетные места понапрасну, создают лишнюю работу ВУЗам (хоть и приносят деньги), вынуждая просеивать сотни студентов в поисках единиц толковых.
Зависит,
Чисто на уровне догадки разве что я верю, немало будущих интересных идей было заложено в ходе университеских исследований, хотя именно доделаны вряд ли в стенах университета.
Поделитесь, пожалуйста, а как обстоят дела в вузах США и Европы насчет — Доли ненаучных сотрудников кафедр и преподавателей?
Т.е. представителей компаний/предприятий/бизнеса, которые могли бы делиться реальными знаниями и показывать связь изучаемого с практикой, а заодно и приносить новые идеи по внедрению науки в производство.
В нашем вузах были строгие требования на научную работу кафедр, практически весь состав кафедры должен писать статьи и участвовать в грантах. Более того, за подобную работу преподаватели получают баллы, а вуз каждый год якобы решает на основе этих баллов — продлить контракт или нет. Лишь небольшая доля представителей производства освобождалась от этого.
От того и имели что имели:
Огромное количество публикаций, по 8 авторов вписанных в статью, чисто ради галочки, хотя эти люди могли бы просто хорошо делать своё дело — преподавать свои предметы, глядишь и время нашлось на обновление материала в ногу со временем.
Постоянный уровень стресса в погоне за баллами, новые метрики, хотя по факту альтернатив этим людям нет на рынке.
Думаю, отчасти ригидность мышления вызвана такими навязанными KPI на которые тратится много ментальных усилий, а потом еще надо где то взять силы на преподавание, на обдумывание вместе со студентом его курсовой/дипломной (по, вероятно, совершенно новой для тебя теме).
Причем преподаватели любящие своё дело находят силы и еще как, за что низкий поклон. Видел как вытягивают даже самых сомнительных персонажей, ставят им речь и вправляют извилины.
Отмечу, кстати, за участие в конференциях разного уровня и статьях в крупных журналах — вполне удавалось получить и правительственные стипендии, и президентские, которые прилично добавляли в личный бюджет.
Хотя согласен — это крайне не надежный способ выживания, если бы я жил только на университетские деньги.
Хочу еще поделиться подборкой ссылок что мне когда то посоветовали — Self learning DDD: https://emacsway.github.io/ru/self-learning-for-software-engineer/#ddd, список выглядит достаточно внушительно.
Мы, люди, общаемся при помощи слов. Более того, бОльшую часть времени мы мыслим при помощи слов. Слова важны.
Каждое слово может иметь несколько значений, которые зависят от различных контекстов (опа, и тут контексты?). Нюанс в том, что если один контекст более распространён, то он может перекрыть прочие и люди даже не задумаются о прочих значениях.
Не берусь утверждать наверняка, но слово «микро» всё же обычно воспринимается в контексте размера, а не рассуждений о предметной области.
Многие разработчики изначально ограничились осознанием слова «микро» как указанием размера, оттого мы и имеем что имеем. Потребовалось много лет прежде чем до широких масс дошла идея про разбиение сервисов по фрагментам предметной области.
Поэтому, я категорически согласен, термин изначально был выбран не идеально. Но его ведь надо было как то продавать, чтобы затмить предыдущие идеи, вот и раскрутили звучное название.
Стараюсь держать исключения только для самых неимоверно жутких ситуаций, а в идеале вообще обходиться без них, потому что из за них код неимоверно: 1) разбухает, 2) тормозит, 3) теряет линейность и предсказуемость. Пожалуй, потеря линейности это самая главная моя претензия к пользовательским исключениям.
Более того,
Как показывает опыт, рано или поздно, Бизнес захочет видеть максимум подробностей для любой возникающей ошибки, процесса обработки вообще, накопленных итогов валидации и т.п.
Тогда то исключения и плавно уходят в сторону ближайшей рощи, а у вас появляется класс вида подобного логам:
Процессоры же отвечающие за обработку бизнес-логики начинают накапливать итоги ошибок:
Лично для меня, все 3 варианта выглядят плюс-минус одинаково и все они имеют риск опечатки, когда случайно используется ответ/результат из предыдущего шага.
Railway Oriented Programming (или ссылка #2) подход отчасти может уменьшить риск опечатки, но с накоплением сложного трейса в нём туже.
По моему личному опыту, строго разделение на «команды» и «запросы» — довольно иллюзорно. Для команд рано или поздно (скорее рано) появится необходимость возвращать больше информации в ответе. Для запросов выяснится, что надо попутно записать информацию в аудит или счетчики, т.е. это уже будет не совсем чистый запрос.
Выглядит как потенциально протекающая абстракция, ибо для других каналов может отсутствовать функция накопления операций (данных?) в памяти. Вот для работы в транзакции, например, это будет обоснованно, но всё равно хочется как то иначе это организовать (пока не знаю как).
Будем подождать 3ю часть этого сериала, пока интригующе, спасибо! :)
О-о-о эти длинные конфигурации DI-контейнеров, они изящно прячут от нас сотни или даже тысячи микро-зависимостей. Однако же, в случае их поломки или несовместимости — это невозможно починить на глазок, надо закапываться в исходники и раскручивать всю цепочку. Если же у вас есть сторонние крупные модули которые несут свои собственные конфигурации, то можно смело возводить веселье в квадрат.
Конечно, без DI-контейнеров жилось бы хуже (наверняка). Где грань между рациональным использованием автоматической инъекции зависимостей и неуправляемым мессивом из интерфейсов — мне неизвестно, пока что.
Будем ждать ссылку на репозиторий с версией готовой к открытому релизу. :)
Но недавно вышла статья: Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты.
Вернулся сюда, перечитал, теперь понял. Будем знать, спасибо!
Вдруг кому тоже пригодится.
Вопрос: Если мы имеем и используем сильную декларативную выразительность ограничений типов, это еще лишь точная Анемичная модель, или уже недоделанная Богатая?
Рассказ: Когда речь заходит про выразительность модели предметной области, то мне сразу вспоминается Онтологическое проектирование вместе с инструментами RDFS и OWL, при знакомстве с которыми я был удивлен насколько иначе можно представить предметную область, нежели в известных мне C#/Java/RDBS.
Как пример, Наследование Классов:
В Онтологиях наследование «subClassOf» означает сужение, уточнение подмножеств классов и экземпляров, что соответствует действительности, ведь Студентов вообще меньше чем Человеков.
В Классических ООП языках наследованием же обычно называется расширение базового класса. Наблюдательный программист увидит в этом конкретизацию типа (ведь Student унаследованный от Person можно привести к Person, но не наоборот), особо заметно это на примитивах.
Однако, в обсуждениях зачастую я слышу именно термин «расширение».
Другой пример, Наследование Свойств:
Если свойство «Length» имеет наследников «OfficialLength» и «EstimatedLength», то они унаследуют ограничения базового свойства, а также, наличие любого из свойств наследников будет означать наличие базового.
В классическом ООП и реляционных БД обычно такое реализуются через связующую сущность (таблицу) с необходимыми свойствами, и хранением типа этой сущности, справедливости ради это позволяет сохранить даже больше информации о связи.
Однако, создаются такие промежуточные сущности тоже нечасто (для этого требуются манипуляции в хранилище) и зачастую «протекают» (если их вовремя не превращают в самостоятельную сущность). 99% свойств это всё таки именно свойства.
Разумеется, у этих инструментов есть и недостатки, придумывались они прежде всего под научные цели, немного оторванные от реальной жизни. Хотя концепции там имеются любопытные и мне видится они уже проникают понемногу в привычную разработку ПО благодаря приходу графовых БД (крупные игроки стали вписываться в эту область), правда простое использование графов как способа хранения даст лишь самую малую толику от возможной выразительности предметной области, на мой взгляд.
К сожалению не подскажу за другие языки программирования, знаю лишь поверхностно, интересно было бы узнать как там с подобными понятиями.
Подозреваю опечатку в своём тексте, думаю правильнее говорить о «сложении» вероятностей.
Вполне могу признать, что мои познания в теории вероятностей далеко не идеальны, но вот сам подсчет мне видится приблизительно верным, ведь подсчитывается вероятность появления хотя бы 1 ошибки, эти события вполне себе совместные, а значит формула:
P(A+B)=P(A)+P(B)−P(A⋅B).
Вероятность наличия ошибки в одной строке кода: 0.01%.
Вероятность наличия ошибки во всех строках кода: 0.01%^10000 = очень мало.
Вероятность наличия хотя бы одной ошибки в любой строке кода: 0.01%*10000 — 0.01%^10000 ~= 100%.
То ли специально чрезмерно иронизируете, то ли преувеличиваете своё ощущение усталости от похожих задач, то ли еще как назвать. Например:
Противоречит упомянутому ниже вашему хорошему качеству:
В любом случае, хочу отметить пару опасных допущений данной фразы:
1) «Хороший» программист (инженер) — не звание на всю жизнь, нельзя лишь почевать на лаврах прошлых заслуг, человек на определенном этапе развития может быть таковым, а потом может выгореть или решить немного отдохнуть и перейти в режим просто «Норм» — в среднем нормально решает знакомые задачи знакомыми методами без лишнего погружения и разбора деталей.
2) Цифра стажа — не определяет автоматически попадение в категорию «Хорошего», лишь повышая вероятность накопления определенного опыта, т.к. см. 1 первый — важно и как человек провел эти года, и каков он сейчас.
Однако, как и говорится в 3м пункте: «Суть программирования есть решение проблем». Опять же соглашусь, на мой взгляд, программист-практик обязан держать в голове решаемую проблему бизнеса из реального мира, а не фокусироваться на абстрактном творческом процессе.
Правда, на мой взгляд, здесь есть грань — если переводить ситуацию в разряд «явной агрессией на явную агрессию», то IT сообщество в какой то мере себя и дискредитирует, по сути став на 1 шаг ближе к тем силам/процессам/глупостям которым противопоставляется. Ну на мой взгляд, но еще не обдумывал очень сильно.
Вот абсолютно согласен.
Претензия не к самой статье, а в целом было огромным удивлением узнать:
Заканчивается 2018 год, а фанаты "прогрессивных" языков до сих пор учатся генерировать WSDL/OpenAPI/ из метаданных сборки/кода.