image_2025-01-23_11-51-24.png
156.3 KB
Принцип работы LLM тоже предвосхитили вездесущие Стругацкие. Но книга вышла с опечаткой: редактор исправил «нейронной» на «нейтронной». Штош, его можно понять.
(И далее по тексту снова исправил: во фразе "У мене внутре нейронка" заменил нейронку на неонку.)
(И далее по тексту снова исправил: во фразе "У мене внутре нейронка" заменил нейронку на неонку.)
три уровня требований.png
246.3 KB
Почему выделяют три уровня требований?
Почему же их на самом деле три? Я для себя нашел, что ответ дает теория систем.
Есть наша система или наш продукт, который мы куда-то хотим продать, внедрить, настроить и так далее. Он нужен не просто так, он нужен как часть какой-то надсистемы, и он там нужен для чего-то - для того, чтобы решать какие-то верхнеуровневые цели. И представление о том, зачем он нужен, то есть требования к его назначению, это и есть первый уровень, так называемые бизнес-требования.
Внутри системы по определению есть другие элементы, с которыми мы, опять же по определению системы, взаимодействуем. И способ взаимодействия с внешним миром внутри системы – это второй уровень требований. У Вигерса он называется «пользовательские требования», и туда же относятся требования к интеграции. Сейчас они все более актуальны, потому что системы все больше взаимодействуют не с людьми, а с другими системами. Это окружение нашего продукта или системы, где наша система как черный ящик взаимодействует с остальным.
И третий уровень требований. Наша система тоже является системой, и требования, относящиеся уже к ее внутреннему устройству, тому, что она должна собой представлять, составляют третий уровень.
У него есть разные названия. Вигерс это называет «функциональными требованиями». Мне кажется, это очень неудачный термин, потому что они не только функциональные. Кто-то называет эти требования «системными», кто-то называет «техническими», и это как раз то, чем занимаются системные аналитики.
Чуть подробнее в видео:
https://www.webursitet.ru/article/pochemu-urovnei-trebovanii-imenno-tri.html
Почему же их на самом деле три? Я для себя нашел, что ответ дает теория систем.
Есть наша система или наш продукт, который мы куда-то хотим продать, внедрить, настроить и так далее. Он нужен не просто так, он нужен как часть какой-то надсистемы, и он там нужен для чего-то - для того, чтобы решать какие-то верхнеуровневые цели. И представление о том, зачем он нужен, то есть требования к его назначению, это и есть первый уровень, так называемые бизнес-требования.
Внутри системы по определению есть другие элементы, с которыми мы, опять же по определению системы, взаимодействуем. И способ взаимодействия с внешним миром внутри системы – это второй уровень требований. У Вигерса он называется «пользовательские требования», и туда же относятся требования к интеграции. Сейчас они все более актуальны, потому что системы все больше взаимодействуют не с людьми, а с другими системами. Это окружение нашего продукта или системы, где наша система как черный ящик взаимодействует с остальным.
И третий уровень требований. Наша система тоже является системой, и требования, относящиеся уже к ее внутреннему устройству, тому, что она должна собой представлять, составляют третий уровень.
У него есть разные названия. Вигерс это называет «функциональными требованиями». Мне кажется, это очень неудачный термин, потому что они не только функциональные. Кто-то называет эти требования «системными», кто-то называет «техническими», и это как раз то, чем занимаются системные аналитики.
Чуть подробнее в видео:
https://www.webursitet.ru/article/pochemu-urovnei-trebovanii-imenno-tri.html
🔥2❤1👍1
Почему юзабилити нет места в ГОСТ 34
(Для зануд: речь идёт о ГОСТ ГОСТ 34.602-89, который про ТЗ.)
Итак, почему же в нём ничего не говорится об удобстве использования?
Простой, но неполный ответ: потому что ГОСТ устарел.
На этом удовлетворённые приверженцы Agile расходятся писать юзер стори. Помашем им ручкой.
А с теми, кто остался, попробуем разобраться.
О чём ГОСТ 34? Он об Автоматизированных Системах . Которые представляют собой что? А вот что:
Стало быть, вопрос можно перефразировать так: почему юзабилити нет места в АС?
В жестоком капиталистическом мире эксплуатации и чистогана под определение АС подходят в первую очередь корпоративные системы — всякие там АБС, CRM, ERP и прочие слова из трёх букв.
Их объединяет одно: все они обладают жутким с точки зрения обывателя UI.
На мой взгляд, на то есть три причины.
Во-первых, модель АС не покрывает коммерческие продукты для массового пользователя. У которых есть независимые пользователи, а не подневольный персонал. И конкурентные преимущества этих продуктов будут оценивать эти самые конечные пользователи, а не дяди в высоких кабинетах.
А юзабилити — это для независимого пользователя самое очевидное конкурентное преимущество. Если пользователь чувствует себя в твоей системе дураком, он обидится и уйдёт, и никакой функциональностью его уже не заманишь.
Во-вторых, требования к юзабилити, как и любые нефункциональные требования, должны закладываться при проектировании программной архитектуры.
Жестокая правда состоит в том, что в большинстве корпоративных систем архитектура сложилась годы назад, и ориентирована она в первую очередь на расширение функциональности.
В АС на первом месте стоят функции. Собственно, поэтому мы и делим требования на функциональные и нефункциональные. Само название «нефункциональные» подчёркивает их вторичность и неполноценность.
Функциональные требования к типичной банковской системе изменяются ежедневно. Только успевай к ним адаптироваться. Выживет тот, кто может непрерывно пилить новые фичи. И архитектура системы должна быть заточена на это.
Но почему нельзя совмещать функциональность с удобством?
А по третьей причине: это дорого (очень дорого), но при этом в АС удобство не является конкурентным преимуществом. Персонал АС будет плакать, колоться, но всё равно будет реализовывать свою деятельность по выполнению установленных функций, ему за это деньги платят. А если при добавлении каждой новой функции учитывать юзабилити, объём работ возрастает раза в два-три (это моя грубая оценка, специальных исследований я не проводил, и буду благодарен, если кто-то даст ссылку).
Так что же, нет шансов сделать корпоративные системы удобными для людей? Для тех самых волшебных гномиков, которых пренебрежительно называют персоналом?
Шансы есть, но произойдёт это эволюционно.
На наших глазах формируется культура, в которой разрабатывать системы без учёта юзабилити становится неприличным.
Архитектуры корпоративных систем тоже постепенно перестраиваются.
Во-первых, у некоторых из них появляются те самые внешние пользователи (например, в банковские системы пришлось запускать клиентов, которые не хотели больше ходить ногами в отделение за каждой бумажкой).
Во-вторых, им на пятки наступают хипстерские сервисы «для малого бизнеса», в которых удобство есть изначально. Они отъедают рынок у монстров, превращая юзабилити в конкурентное преимущество.
Но ГОСТу за ними не угнаться. Он по определению направлен в прошлое, когда трава была зеленой, а компьютеры были большими и назывались ЭВМ.
Все ушли удовлетворённые, но осталась ещё пара зануд, защищающих ГОСТ. А как же эргономика и техническая эстетика, спрашивают они. Ведь можно подогнать юзабилити под ГОСТ, там же есть такой раздел!
Нет ничего невозможного для людей с интеллектом. Можно и зайца научить курить. Но модель АС никуда не делась. Либо мы делаем АС с автоматизацией функций и волшебными гномиками, и тогда всё лишнее вянет, чахнет и отваливается.
(Для зануд: речь идёт о ГОСТ ГОСТ 34.602-89, который про ТЗ.)
Итак, почему же в нём ничего не говорится об удобстве использования?
Простой, но неполный ответ: потому что ГОСТ устарел.
На этом удовлетворённые приверженцы Agile расходятся писать юзер стори. Помашем им ручкой.
А с теми, кто остался, попробуем разобраться.
О чём ГОСТ 34? Он об Автоматизированных Системах . Которые представляют собой что? А вот что:
«Систему, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.»
Стало быть, вопрос можно перефразировать так: почему юзабилити нет места в АС?
В жестоком капиталистическом мире эксплуатации и чистогана под определение АС подходят в первую очередь корпоративные системы — всякие там АБС, CRM, ERP и прочие слова из трёх букв.
Их объединяет одно: все они обладают жутким с точки зрения обывателя UI.
На мой взгляд, на то есть три причины.
Во-первых, модель АС не покрывает коммерческие продукты для массового пользователя. У которых есть независимые пользователи, а не подневольный персонал. И конкурентные преимущества этих продуктов будут оценивать эти самые конечные пользователи, а не дяди в высоких кабинетах.
А юзабилити — это для независимого пользователя самое очевидное конкурентное преимущество. Если пользователь чувствует себя в твоей системе дураком, он обидится и уйдёт, и никакой функциональностью его уже не заманишь.
Во-вторых, требования к юзабилити, как и любые нефункциональные требования, должны закладываться при проектировании программной архитектуры.
Жестокая правда состоит в том, что в большинстве корпоративных систем архитектура сложилась годы назад, и ориентирована она в первую очередь на расширение функциональности.
В АС на первом месте стоят функции. Собственно, поэтому мы и делим требования на функциональные и нефункциональные. Само название «нефункциональные» подчёркивает их вторичность и неполноценность.
Функциональные требования к типичной банковской системе изменяются ежедневно. Только успевай к ним адаптироваться. Выживет тот, кто может непрерывно пилить новые фичи. И архитектура системы должна быть заточена на это.
Но почему нельзя совмещать функциональность с удобством?
А по третьей причине: это дорого (очень дорого), но при этом в АС удобство не является конкурентным преимуществом. Персонал АС будет плакать, колоться, но всё равно будет реализовывать свою деятельность по выполнению установленных функций, ему за это деньги платят. А если при добавлении каждой новой функции учитывать юзабилити, объём работ возрастает раза в два-три (это моя грубая оценка, специальных исследований я не проводил, и буду благодарен, если кто-то даст ссылку).
Так что же, нет шансов сделать корпоративные системы удобными для людей? Для тех самых волшебных гномиков, которых пренебрежительно называют персоналом?
Шансы есть, но произойдёт это эволюционно.
На наших глазах формируется культура, в которой разрабатывать системы без учёта юзабилити становится неприличным.
Архитектуры корпоративных систем тоже постепенно перестраиваются.
Во-первых, у некоторых из них появляются те самые внешние пользователи (например, в банковские системы пришлось запускать клиентов, которые не хотели больше ходить ногами в отделение за каждой бумажкой).
Во-вторых, им на пятки наступают хипстерские сервисы «для малого бизнеса», в которых удобство есть изначально. Они отъедают рынок у монстров, превращая юзабилити в конкурентное преимущество.
Но ГОСТу за ними не угнаться. Он по определению направлен в прошлое, когда трава была зеленой, а компьютеры были большими и назывались ЭВМ.
Все ушли удовлетворённые, но осталась ещё пара зануд, защищающих ГОСТ. А как же эргономика и техническая эстетика, спрашивают они. Ведь можно подогнать юзабилити под ГОСТ, там же есть такой раздел!
Нет ничего невозможного для людей с интеллектом. Можно и зайца научить курить. Но модель АС никуда не делась. Либо мы делаем АС с автоматизацией функций и волшебными гномиками, и тогда всё лишнее вянет, чахнет и отваливается.
❤1👍1
Либо юзабилити перестаёт быть лишним и врастает в нашу систему, но тогда она перестаёт быть тем, что называется АС.
Это Катя, она уже пятый год занимается организацией ЛАФ и WAW. До этого десять лет всё делалось руками участников Сообщества – сами искали площадки, занимались расселением, питанием, билетами, трансферами и всей этой вашей логистикой. А потом пришла Катя и всё исправила.
Сейчас мы с Катей на WAW.
Сейчас мы с Катей на WAW.
🔥4🙏2
photo_2025-02-24_20-25-50.jpg
119.9 KB
В ответ на требование Маска всем сотрудникам отчитаться о проделанной работе Секретная служба предложила золотой стандарт Performance Review.
👍2
установка whisperx.txt
2 KB
Поставил локально WhisperX (это whisper с диаризацией - распознаванием голосов) и не могу нарадоваться. Распознаёт лучше оригинальной модели от OpenAI, работает в разы быстрее.
Загнал в него целую папку с записями интервью (17 файлов, каждый длительностью не меньше часа) - всё прожевал за полчаса. Судя по монитору ресурсов, ему хватает 8GB памяти GPU. До чего техника дошла!
Но при установке пришлось немного попрыгать с бубном, конечно. Питон - это новый круг ада зависимостей.
Ещё у него не очень удобный формат выдачи расшифровки, но эта проблема решилась за пять минут написанием переформатирующего скрипта с помощью ChatGPT (в код даже не заглядывал, просто скопировал и запустил - так я уже ему доверяю).
Прилагаю краткую инструкцию по установке (мой путь по граблям) на память, вдруг кому-то ещё пригодится.
Загнал в него целую папку с записями интервью (17 файлов, каждый длительностью не меньше часа) - всё прожевал за полчаса. Судя по монитору ресурсов, ему хватает 8GB памяти GPU. До чего техника дошла!
Но при установке пришлось немного попрыгать с бубном, конечно. Питон - это новый круг ада зависимостей.
Ещё у него не очень удобный формат выдачи расшифровки, но эта проблема решилась за пять минут написанием переформатирующего скрипта с помощью ChatGPT (в код даже не заглядывал, просто скопировал и запустил - так я уже ему доверяю).
Прилагаю краткую инструкцию по установке (мой путь по граблям) на память, вдруг кому-то ещё пригодится.
❤3🔥2👍1
Смотрю на свои 100500 рабочих чятиков и думаю, что ШКЯ, конечно, пора записать римейк "каким файлообменником ты пользуешься", теперь про телеграм.
😁3
Расскажу, как я познакомился с жизненным циклом АСУ по ГОСТу.
В 1980 году Совет министров СССР принял решение о разработке одной автоматизированной системы управления для военно-воздушных сил. Это было ещё при товарище Брежневе.
Я об этом тогда не знал, да и не мог знать, потому что мне было всего 10 лет. Я был юным пионером, ходил в школу, собирал металлолом и макулатуру и играл в школьной самодеятельности.
Время шло, я подрастал. Учился в школе, играл на скрипке, паял в радиокружке, побеждал в олимпиадах по математике, оказывал помощь подшефному колхозу осенью (собирал помидоры) и летом (пропалывал помидорные грядки).
Страна тоже не стояла на месте. Товарища Брежнева сменил товарищ Черненко, которого сменил товарищ Андропов, которого сменил товарищ Горбачёв, который объявил перестройку, гласность, новое мышление и борьбу с алкоголизмом.
Пришёл 1987 год. Я окончил школу. И как раз в этом году несколько крупных НИИ авиационной промышленности совместно с ВВС наконец разработали и согласовали Техническое задание на ту самую автоматизированную систему, решение о разработке которой было принято Советом министров СССР в 1980 году. Но я по-прежнему об этом не знал, да и не мог знать, потому что только что поступил в военное авиационное инженерное училище, на специальность «математическое обеспечение автоматизированных систем управления».
Время шло дальше. Я успел изучить архитектуру и язык ассемблера «больших» ЕС ЭВМ (советских клонов IBM/360), на смену которым внезапно пришли IBM PC, архитектуру и ассемблер которых тоже пришлось изучить. Женился, родилась дочка, заработал первые деньги в «левом» коммерческом проекте.
В 1992 году я выпустился из военного училища и молодым лейтенантом прибыл служить в Научно-испытательный институт ВВС. И вот тогда, наконец, узнал о проекте той самой АСУ, решение о разработке которой было принято в 1980 году Советом министров несуществующего уже СССР. К этом моменту группа НИИ авиационной промышленности как раз закончила разработку эскизного проекта и приступила к разработке технического проекта — то есть, собственно, к созданию системы.
Если вы подумали, что система существовала только на бумаге, то вы ошибаетесь. НИИ, отвечающий за её разработку, даже начал писать код! В отделении из нескольких десятков человек была одна женщина-программист (тогда уже пенсионного возраста). Она как раз осваивала новомодный тогда язык C++ и решила (довольно справедливо), что это язык гораздо лучше подходит для разработки новой системы, чем указанный в ТЗ Фортран. А остальные сотрудники отделения занялись разработкой и согласованием этого изменения в ТЗ.
Кстати, именно тогда я проникся мудростью людей, причисливших первый советский клон IBM PC к семейству Единой серии ЭВМ, назначив ему индекс ЕС-1840. Персоналки к тому времени уже окончательно вытеснили «большие» ЕС ЭВМ, которые гнили нераспакованными по всем НИИ бывшего Советского Союза. Но ТЗ в этой части менять было не нужно! В нём было указано, что АСУ должна использовать ЭВМ Единой серии как основу технического обеспечения.
В 1998 году я поступил в адъюнктуру Военно-воздушной инженерной академии имени Жуковского и уехал в Москву. Адъюнктуру я через год бросил, уволившись из армии, и началась у меня совсем другая жизнь. Поэтому я так и не знаю, чем закончилась история с этой АСУ, решение о разработке которой было принято Советом министров СССР в 1980 году.
Но, возможно, и теперь, спустя 45 лет, она продолжает кормить целые институты авиационной промышленности.
В 1980 году Совет министров СССР принял решение о разработке одной автоматизированной системы управления для военно-воздушных сил. Это было ещё при товарище Брежневе.
Я об этом тогда не знал, да и не мог знать, потому что мне было всего 10 лет. Я был юным пионером, ходил в школу, собирал металлолом и макулатуру и играл в школьной самодеятельности.
Время шло, я подрастал. Учился в школе, играл на скрипке, паял в радиокружке, побеждал в олимпиадах по математике, оказывал помощь подшефному колхозу осенью (собирал помидоры) и летом (пропалывал помидорные грядки).
Страна тоже не стояла на месте. Товарища Брежнева сменил товарищ Черненко, которого сменил товарищ Андропов, которого сменил товарищ Горбачёв, который объявил перестройку, гласность, новое мышление и борьбу с алкоголизмом.
Пришёл 1987 год. Я окончил школу. И как раз в этом году несколько крупных НИИ авиационной промышленности совместно с ВВС наконец разработали и согласовали Техническое задание на ту самую автоматизированную систему, решение о разработке которой было принято Советом министров СССР в 1980 году. Но я по-прежнему об этом не знал, да и не мог знать, потому что только что поступил в военное авиационное инженерное училище, на специальность «математическое обеспечение автоматизированных систем управления».
Время шло дальше. Я успел изучить архитектуру и язык ассемблера «больших» ЕС ЭВМ (советских клонов IBM/360), на смену которым внезапно пришли IBM PC, архитектуру и ассемблер которых тоже пришлось изучить. Женился, родилась дочка, заработал первые деньги в «левом» коммерческом проекте.
В 1992 году я выпустился из военного училища и молодым лейтенантом прибыл служить в Научно-испытательный институт ВВС. И вот тогда, наконец, узнал о проекте той самой АСУ, решение о разработке которой было принято в 1980 году Советом министров несуществующего уже СССР. К этом моменту группа НИИ авиационной промышленности как раз закончила разработку эскизного проекта и приступила к разработке технического проекта — то есть, собственно, к созданию системы.
Если вы подумали, что система существовала только на бумаге, то вы ошибаетесь. НИИ, отвечающий за её разработку, даже начал писать код! В отделении из нескольких десятков человек была одна женщина-программист (тогда уже пенсионного возраста). Она как раз осваивала новомодный тогда язык C++ и решила (довольно справедливо), что это язык гораздо лучше подходит для разработки новой системы, чем указанный в ТЗ Фортран. А остальные сотрудники отделения занялись разработкой и согласованием этого изменения в ТЗ.
Кстати, именно тогда я проникся мудростью людей, причисливших первый советский клон IBM PC к семейству Единой серии ЭВМ, назначив ему индекс ЕС-1840. Персоналки к тому времени уже окончательно вытеснили «большие» ЕС ЭВМ, которые гнили нераспакованными по всем НИИ бывшего Советского Союза. Но ТЗ в этой части менять было не нужно! В нём было указано, что АСУ должна использовать ЭВМ Единой серии как основу технического обеспечения.
В 1998 году я поступил в адъюнктуру Военно-воздушной инженерной академии имени Жуковского и уехал в Москву. Адъюнктуру я через год бросил, уволившись из армии, и началась у меня совсем другая жизнь. Поэтому я так и не знаю, чем закончилась история с этой АСУ, решение о разработке которой было принято Советом министров СССР в 1980 году.
Но, возможно, и теперь, спустя 45 лет, она продолжает кормить целые институты авиационной промышленности.
🔥6
Не могу перестать восхищаться (и немного ужасаться) возможностями, которые предоставляет ИИ в разработке программ. Вчера я с помощью ChatGPT за полчаса реализовал импорт данных из xml файлов, которые до этого ни разу не видел. Из этого получаса десять минут у меня ушло на подготовку промпта и ещё пятнадцать минут на проверку работающего кода и исправление ошибок (моих ошибок, не его!)
Если бы я писал этот код руками, на это ушло бы не меньше недели. На подбор библиотек, чтение форумов, размышления, копипаст, отладку, тестирование и исправления, перерывы, перекуры и, конечно же, прокрастинацию. И ещё в коде затаилась бы пара-тройка багов.
А тут – за две минуты ChatGPT выдал мне готовый код, объяснение его работы и рекомендации по оптимальной встройке в проект.
Скопировал, вставил – всё работает, можно двигаться дальше!
Мне кажется (точнее, я это ясно вижу вокруг), что программисты ещё не осознали, какой медный таз над ними завис, закрывая небо. Слишком быстро всё происходит.
Для самых пытливых привожу промпт. Довольно простая и не самая грамотная постановка задачи, основное время у меня ушло на поиск идентификаторов в файле xml и их перебивку в текст.
Если бы я писал этот код руками, на это ушло бы не меньше недели. На подбор библиотек, чтение форумов, размышления, копипаст, отладку, тестирование и исправления, перерывы, перекуры и, конечно же, прокрастинацию. И ещё в коде затаилась бы пара-тройка багов.
А тут – за две минуты ChatGPT выдал мне готовый код, объяснение его работы и рекомендации по оптимальной встройке в проект.
Скопировал, вставил – всё работает, можно двигаться дальше!
Мне кажется (точнее, я это ясно вижу вокруг), что программисты ещё не осознали, какой медный таз над ними завис, закрывая небо. Слишком быстро всё происходит.
Для самых пытливых привожу промпт. Довольно простая и не самая грамотная постановка задачи, основное время у меня ушло на поиск идентификаторов в файле xml и их перебивку в текст.
Мне нужно добавить в приложение импорт учебных планов в формате xml.
Из каждого учебного плана мне нужно извлечь и сохранить в базу данных строки о каждой дисциплине.
Особенность этого импорта в том, что каждый учебный план лежит в отдельном файле, которые нужно импортировать в одну таблицу.
То есть каждый новый импорт не должен полностью удалять всю таблицу, а должен только предварительно удалять строки, относящиеся только к загружаемому учебном плану.
В базе данных для учебных планов должна быть одна ненормализованная таблица TeachingPlans, содержащая общие данные из секции tp и данные по каждой дисциплине из секций tp:discipline.
Вся информация, относящаяся к блокам учебного плана (в секциях block), не нужна в базе данных.
Дисциплины могут длиться несколько семестров.
В этом случае в таблице должна быть отдельная строка для каждой составной части (модуля) дисциплины на каждый семестр.
Каждая строка модуля дисциплины должна содержать следующие данные:
- id - идентификатор строки (auto increment)
- tp_Id - идентификатор учебного плана из поля teachingPlanId
- tp_start_Year - год начала обучения по учебному плану из поля startYear
- tp_program_code - код направления подготовки образовательной программы из поля tp:specialty code
- tp_program_name - наименование образовательной программы из поля tp:name
- tp_program_profile - наименование профиля из поля tp:profile
- tp_periods - количество семестров в программе из поля tp:curriculum termsCount
- disc_name - наименование всей дисциплины из поля tp:name блока discipline
- disc_weight - вес (количество зачётных единиц) всей дисциплины из поля tp:discipline weight
- disc_start_Period - начальный семестр всей дисциплины из поля tp:discipline startTermNumber
- disc_end_Period - конечный семестр всей дисциплины из поля tp:discipline endTermNumber
- module_name - module_period
- module_weigth - module_Lect_hours - количество лекционных часов: значение поля hours секции lesson, если значение поля type этой содержит подстроку "Лекц"
- module_Sem_hours - количество семинарских часов: значение поля hours секции lesson, если значение поля type этой секции содержит подстроку "Семинар"
- module_Lab_hours - количество семинарских часов: значение поля hours секции lesson, если значение поля type этой секции содержит подстроку "Лаборатор"
- module_Check_hours - количество часов на текущий контроль: значение поля hours секции lesson, если значение поля type этой секции содержит подстроку "Текущ"
- module_Cons_hours - количество часов на консультации: значение поля hours секции lesson, если значение поля type этой секции содержит подстроку "Консульт"
- module_Self_hours - количество часов на самостоятельную работу: значение поля hours секции lesson, если значение поля type этой секции содержит подстроку "Самостоят"
- module_Exam_type - тип аттестации для этого модуля дисциплины - значение поля type секции controlObject
- module_Exam_hours - количество часов на подготовку к аттестации - значение поля tp:controlObject hours
Ниже представлен пример файла xml.
Пожалуйста, сгенерируй код для импорта учебных планов.
Если у тебя возникнут вопросы в процессе анализа файла xml, задай их мне.
❤1
Действительно ли эффективна повсеместно используемая в компаниях практика Performance Review? Ответ на этот вопрос зависит от того, на каком языке вы его задаёте.
🔥2
Сижу в Домодедово. Все рейсы задержаны, народу в кафешке полно. Раздаётся какой-то свист, и железная женщина объявляет: «Внимание, чрезвычайная ситуация, всем немедленно покинуть здание через аварийные выходы». Половина народа куда-то подрывается (куда?), остальные сидят. Официанты разносят чай, как ни в чём не бывало. И всё это под весёлые рождественские песенки.
😁5
А вы что будете смотреть в новогоднюю ночь? Я, как и в прошлом году, «Мирные огоньки». https://ogonki.tv/
ogonki.tv
Мирные огоньки 2026 | Настоящий новогодний концерт
Смотрите Мирные огоньки 2026 — главный новогодний концерт с участием любимых артистов. Тепло, искренность и музыка для миллионов зрителей по всему миру.
🔥7
Варю суп из топора.
Валяются у меня без дела процессор Ryzen 2400G и видеокарта RTX 1060 6GB после недавнего апгрейда. Решил, что вполне можно ещё погонять на этом добре небольшие модельки, но только желательно без лишних затрат, тем более что стоит под столом пустой старый системник.
Купил по минимуму комплектующие: материнку, память и SSD. Когда выбирал материнку, соблазнился возможностью установки двух видеокарт PCIe-x16, чисто на будущее.
После покупки оказалось, что материнка не лезет в старый системный блок (давненько я не собирал компы, позабыл типовые форматы). Пришлось срочно докупать новый.
Собрал, выяснилось, что старый блок питания всё-таки не работает как надо.
Заказал новый БП, а заодно уж психанул и добавил в заказ процессор Ryzen 5700X, потому что 2400G всё-таки слабоват (не зря же я его заменил при апгрейде).
Теперь смотрю на эту конфигурацию и думаю, что нужно бы ещё и нормальную видеокарту докупить. Пока рубль не упал, ага.
Валяются у меня без дела процессор Ryzen 2400G и видеокарта RTX 1060 6GB после недавнего апгрейда. Решил, что вполне можно ещё погонять на этом добре небольшие модельки, но только желательно без лишних затрат, тем более что стоит под столом пустой старый системник.
Купил по минимуму комплектующие: материнку, память и SSD. Когда выбирал материнку, соблазнился возможностью установки двух видеокарт PCIe-x16, чисто на будущее.
После покупки оказалось, что материнка не лезет в старый системный блок (давненько я не собирал компы, позабыл типовые форматы). Пришлось срочно докупать новый.
Собрал, выяснилось, что старый блок питания всё-таки не работает как надо.
Заказал новый БП, а заодно уж психанул и добавил в заказ процессор Ryzen 5700X, потому что 2400G всё-таки слабоват (не зря же я его заменил при апгрейде).
Теперь смотрю на эту конфигурацию и думаю, что нужно бы ещё и нормальную видеокарту докупить. Пока рубль не упал, ага.
😁5🔥2👍1