Во первых нужно определиться с типами данных языка и операциями над ними, в самом простом случае мы можем свести что у нас будут только биты или на крайний случай числа в языке, но и вот что будет в графическом языке.? Допустим тоже... Ок
Потом нужно определиться с операциями над ними, с битами там понятно and, or,... с числами тоже
Потом работу с памятью придумать надо (read /write variables)
А далее порядок исполнения (if, while, call)
Если мы вводим вызов функции (call) то нужно определить синтаксис для определения функции, рекурсию и стек вызова
С типами данных, если их больше одного, то сразу тяжелее... Проверка на совместимость, ковариантности и прочего...
И вот.. Тут начинается зоопарк, надо написать парсер, который умеет из плоских данных (исходного текста, а данном случае из картинок/диаграмм) создать абстрактное синтаксическое дерево
А это парсер написать уже не тривиальным программа по размеру, даже если очень пытаться
Есть два варианта уменьшать грамматику языка, чтобы уменьшить объем парсера
За счёт упрощения языка
За счёт усложнения статического анализа и сложной модели типизации
В любом случае необходимо в языке (на котором ведётся разработка) иметь возможность выражать средствами самого языка графовые, неоднородные структуры
А многие графические языки, включая hiasm этого не умеют (могу заблуждаться) hiasm может использовать другие языки, но сам он не умеет в сложные типы данных
Под сложными типами я понимаю наличие параметриеских типов данных, типизированных кортежей + pattern matching, лямбд/замыканий
По мне, многие графические языки останавливаются на уровне простого процедурного программирования
https://habr.com/ru/post/599329/#comment_23904673 - Начали за здравие, закончили за упокой. Программированию то удалось обучить? Потому что пока выглядит как реклама визуальных сред. ), и какую именно роль сыграло в этом визуальное прграммирование, очень большой вопрос
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
И опять видать фраза про выразительные языки как-то мимо вас прошла
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
блин... кто ж спорит, а можно и по другому начать программирование и тем же гумманитарием
Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши"
я говорю о графическом вводе, когда рисуется диаграмма вы графически вводите объекты, перетаскиваете мышью на холст
потом дополняете объекты текстом - клавиатурой
когда обычное программирование это в первую очередь работа с текстом большого объема
но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
ну вот именно, только с оговоркой, разработчик вообще к графическим интерфейсам из за отсуствия дизайнеров занимается этой штукой
ну а мушью я пользуюсь, в основном чтоб скорилить текст, да и то..., а большую часть действий я совершаю клавиаутрой
А что вы думаете про графическое программирование и технологию RPA в частности?
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач?
Ну потому что это показывает предел графического программирования, дело не в сложности, а в возможностях языка
Перечисленные выше вопросы - это все о примитивах языка
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM - это вопрос к тому что любой язык программирования может быть сведен к более простому языку (по Тюрингу)
Но мы как-то не используем простые языки (ASM, C), а используем именно выразительные языки (Scala/C#/Haskel/TypeScript/...)
По мне из известных графических языков, многие из них страдают одними и теме же проблемами:
Не выразительны в сложных абстракциях - это не доработка дизайнера языка
Все ориентированы на кликанье мыши - а это заведомый тупик и проигрышь по сравнению с клавиатурой, стилус почему то не используют
Большинство работают как с листом бумаги и схемами на ней, а должно быть более сложное пространство, например бесконечное увеличение частей схемы
У большинства нет возможности создавать свои графические обозначения, свой графический язык - а это нарушает сами принципы языков
Собственно и изучаю, что может ваша платформа, чем она может быть полезна (и в ваших же интересах расказать о ней)
Например меня интересует на сколько силен ваш статический анализатор по сравнению с Rust
Переименование это только первая очивидная проблема
Я могу предположить, что у вас на платформе генерируется код, тот же C# и потом делается попытка его скомпилировать
Если так, тогда как пользователь платформы узнает о
опечатках в коде
не правильном использовании типов данных, например: "Иванов" + 5 сентября
Из менее очивидных проблем графического программирования:
как быть если хотим ООП (свои структуры данных + методы структур данных) - тут я ожидаю, что визуального языка нет, все придется описывать руками и текстом
как быть с много поточкой и блокировками
как быть с иммутабельностью
как быть с транзакциями, вложенными транзакциями
Как быть с унаследованным кодом, можно ли трансформировать исходный код на C# в диаграммы ?
Возможно и устарели представления, но в целом я ожидал этот ответ, что рекурсивной стрелки/дуги нет.
Хотя если бы язык был развитый, тогда из синего прямоугольника (invoke) могла быть дуга к пункту старт - это было бы значительно наглядней.
Из примеров я могу судить что у вас xaml файл = функция - так ?
А из-за того что у вас используются названия файлов при вызове - возникнет (я так предполагаю) очивидные мелкие проблемы - переименование файла может к чертям сломать функцию, которая вызывает код. Была бы рекурсивная стрелка - ничего бы не сломалось.
Как вы боритесь с согласованностью визуального кода и вызывемых функций ? т.е. что будет если файлы переименовать, когда узнаем о проблеме - в compile time или run time ?
Я понимаю что вы на Net все написали, это конечно хорошо, еще бы Java/Rust/etc..., но дело же не в этом
Вы пишете:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Мне интересно как именно графически будет выглядеть кусок кода ниже:
Вот смотрите, есть допустим у меня такой кусок кода:
Number fact( Number x ) {
if( x>1 )return x*fact(x-1);
return x;
}
Данная функция вызвает сама себя, а как в вашем случае в графической нотации вызывает функция сама себя ?
Как вы определяете графически функцию ? есть ли у вас для аргментов функции какие-то графические блоки, для каждого аргумента функции как определить тип данных ?
Простые конструкции языка графически представить не сложно
цикл - две дуги, одна дуга ведущая к началу итерации, другая к выходу из цикла
ветвление (if) - пара дуг, одна в случае истенности условния, другая в случае ложности
При большом желании можно определить графически функцию исключительно, но вот куда засунуть рекурсивный вызов функции графически, так чтоб стрелочкой... вот это уже интереснее, а текстом я и сам знаю
Что тут думать... А то, что среды графической разработки (графические языки программирования) пользуются своей нишевостью и от туда не вылезают уже очень давно
По мне, это только первый этап в обучении программированию, не стоит делать большую ставку (но у вас там целый отдел), как самостоятельная практика написания возможна, но она упрется в фундаметальные ограничения
В первую очередь графический язык - некоторые штуки в нем тяжело выразить, например понятия:
рекурсия
лямбда / функтор (функциональный объект)
рефлексия и метапрограммирование
.... много оных
Вторая очередь: инструменты, есть ли в инструментах например intellisense, git, ...
А мне вот вообще кажется идея узнать за 60 минут порочна.
За это время в лучшем случае я за это время составить свое/субъективное мнение и не факт что оно будет верным, другой человек спросить кандидата другие вопросы и его мнение будет отличаться от моего... Кто тогда прав будет?
Т.е. первый вопрос, а как вы проверяете что ваши методики проверки знаний работают корректно?
Второй вопрос - стек: а что, вы действительно считаете что есть только Spring boot? И знание его ньюансов так важно? Ну вот в качестве примеров транзакции например почему не спросить, чем именно отличается уровень транзакции serializable от repeatable read, и как это реализовано в бд?
Так же про более базовые вещи, я например не вижу смысла спрашивать за rest api endpoint , если человек не знает разницу между UDP/TCP/HTTP
Т.е. у меня есть такое и убеждение (которое может быть не верно) что базовые знания важны, а фреймворки могут меняться со временем, базовые же реже меняются
Хотелось бы услышать по подробнее по саму задачу. Возможно это можно решить все проще, например так:
Ставь oracle клиент вообще не обязательно, можно просто скачать oracle instant client - он занимает около 30 мб и не требует и установки, в комплекте и oci, и sqlplus.exe. а при желание наверно можно уменьшить и до 10 мб.
С другой стороны имея sqlplus.exe, то C++ особо не нужен, достаточно будет написать скрипт на pl/sql который будет исполняться на клиенте (посредством sqlplus) и работать с oracle db.
Если нужны специфичные от ос функции, у вас всегда есть под рукой powershell, либо wsh+wmi
Если подумать то все это должно быть не больше 20..30 мб и все это замечательно можно упаковать zip/rar/7z sfx
(С) "Кто тут в цари последний? никого, тогда я первый буду!"
Ваша работа - не задавать вопросы, обсуждать или вводить новшества. Ваша работа - писать код в соответствии с требованиями. Эта функция была выбрана кем-то, кого вы даже не знаете.
Вскоре поймете, что сама причина, по которой вы увлеклись программированием, ушла. Вы просто здесь, чтобы воплотить чьи-то идеи в код. Редко к вам относятся как к человеку со своими собственными мнениями и идеями.
Вот что тут сказать, если вы не задаете вопросов или ваши вопросы не корректны, то наверно вы сами тому виной, элементарно в ТЗ будет написано такое как "написать вирус шифровальщик" - то, уж как не крутите, вы будете со автором, это элементарно перекладывание ответственности.
Поскольку программисты никогда не были важны для бизнеса с самого начала, их назвали центрами затрат.
Microsoft / Apple / IBM / ... - это уже не бизнес ?
По общему признанию, этот аргумент неприменим к крупным технологическим компаниям, где программисты более чем необходимы. Но рабочие места в сфере высоких технологий очень редки и сосредоточены всего в нескольких местах в мире.
А по мне это логично, ведь в не в каждой деревне есть своя Красная площадь или Мавзолей и свой царь, ведь это не повод говорить, что теперь нам царь/мавзолей/... не нужен
И даже если есть такие инженеры-новаторы, они должны быть довольно редкими, поскольку я их не видел.
Когда-то говорили что черных лебедей не бывает
С толпами молодых, невежественных и все более конкурентоспособных программистов, жаждущих проявить себя, компании могут легко заменить большинство старых программистов новыми.
Вот тут ошибка невежественных и конкурентоспособных - это как ? o_O
На мой взгляд прав, и на мой субъективный взгляд - проблема в тех же приславутых Soft Skill
По мне Soft Skill - это шапочный термин и очень не точный, из которого растут больше кол-во проблем, ведь в той же школе/институте нет таких обязательных дисциплин как: Логика, Теория аргументации, Ораторское искусства и соответственно на собесах спрашивают, то что знают - а это Hard (алгоритмы, сети, etc...)
Конечно это не отменяет того факта, что кандидаты действительно могут и не уметь в hard и как-то надо отсеивать, да и само собеседование не дешевое удовольствие по времени и силам
Как вы видите развитие эмоционального интеллекта ? у меня например есть предубеждение - что читать курсы по эмоциям и мышлению - это как "об стенку горохом" / "танцевать об архитектуре"
По мне большая часть эмоционального интеллекта не сводиться к психологии, а скорее на оборот - например музыке, литературе, философии и ораторскому искусству
Цели института частично совпадают с потребностями бизнеса, но так же другая может быть цель - наука и тут точно дипломные работы не обязаны совпадать с бизнесом.
Наука и исследования - тут могут и должны привлекаться специалисты из профессиональной области - рабочие программисты.
Это я к тому что у вас не только одна группа лиц - студенты - потенциальные ваши работники.
Вторая группа - это преподаватели/учёные из ваших работников т.е. в которых заинтересован сам институт.
Вот когда совпадут ваши интересны : работодателя и института - тогда может что то получится, иначе игра в одни ворота.
Это я к тому что институт или вуз - задачи науки (или освоение бюджета) могут быть более приоритетные чем обучение студентов, а тоже обучение это лишь побочный продукт этой системы.
Второй аспект этой "игры" между бизнесом и институтом - это разные "весовые" категории игроков, уж что, но бизнес слабее - т.к. за институтом - гос финансирование, и гос заказ. Бизнесу надо объединятся для подготовки будущих кадров - т.е. чтоб набрать "вес".
Просто для тех же студентов есть риск - что их знания не будут нужны, а когда этими знаниями занимается один бизнес, то риски только увеличиваются - например обучить только хайповым технологиям.
Согласен, в целом эта же проблема с паролями и ключами/сертификатами
Достаточно сложно доказать, что ты - это ты когда тебе не верят, один из вариантов, .... это привязать например ключ и физической составляющей (днк,отпечаток,...) и ментальной (пароль, контрольная фраза, сгенерированный уникальный ключ, то что не имеет физического аналога) - та чем обладает человек как знаниями, такая своеобразная двух факторная авторизация.
Тут еще можно пофантазировать например иметь два ключа физический + ментальный1 - для утвердительного голосования физический + ментальный2 - на случай если тебя пытают, ... говоришь пароль и тогда в той-же системе фиксируется факт пытки...,
Это как в одном сериале - что бы открыть сейф герой называет пароль взломщику, и после ввода пароля - все содержимое сейфа уничтожается
Если глубоко уходить в размышления - то когда имеет автоматическую систему - которая проверят только сертификат/пароль/... появляется ряд вещей которая она не в состоянии проверить - например, человек не адекватен, пьян, или его запугивают - тогда все его действия нельзя считать юридически верными, т.к. он за себя не отвечает, в таких случаях обычно нужно третье лицо, и обычно это нотариус.
Ну глупо было бы говорить, что это не возможно.
О понятиях, не уже ли вы хотите сказать что в графических языках отсуствуют понятия как цикл, переменная, ветвление ?
Я например не считаю что это понятия относятся текстовым языкам или графическим языкам, они вне этих языков...
Такая же история и со сложными структурами данных
А текстовый или графическияй язык программирования - это лишь способ представить программу
А вот на сколько это удобный способ удобен и выразителен, это отдельный разговор
Это возможно, но сложно... объяснение почему https://habr.com/ru/post/599329/comments/#comment_23910815
Если кратко... То это сложно
Во первых нужно определиться с типами данных языка и операциями над ними, в самом простом случае мы можем свести что у нас будут только биты или на крайний случай числа в языке, но и вот что будет в графическом языке.? Допустим тоже... Ок
Потом нужно определиться с операциями над ними, с битами там понятно and, or,... с числами тоже
Потом работу с памятью придумать надо (read /write variables)
А далее порядок исполнения (if, while, call)
Если мы вводим вызов функции (call) то нужно определить синтаксис для определения функции, рекурсию и стек вызова
С типами данных, если их больше одного, то сразу тяжелее... Проверка на совместимость, ковариантности и прочего...
И вот.. Тут начинается зоопарк, надо написать парсер, который умеет из плоских данных (исходного текста, а данном случае из картинок/диаграмм) создать абстрактное синтаксическое дерево
А это парсер написать уже не тривиальным программа по размеру, даже если очень пытаться
Есть два варианта уменьшать грамматику языка, чтобы уменьшить объем парсера
За счёт упрощения языка
За счёт усложнения статического анализа и сложной модели типизации
В любом случае необходимо в языке (на котором ведётся разработка) иметь возможность выражать средствами самого языка графовые, неоднородные структуры
А многие графические языки, включая hiasm этого не умеют (могу заблуждаться) hiasm может использовать другие языки, но сам он не умеет в сложные типы данных
Под сложными типами я понимаю наличие параметриеских типов данных, типизированных кортежей + pattern matching, лямбд/замыканий
По мне, многие графические языки останавливаются на уровне простого процедурного программирования
В целом по поводу графических языков программирования - есть простой критерий их (не)состоятельности:
Вот когда на графическом языке программирования можно будет создать еще один графический язык программирования - тогда будет о чем по говорить
По вашей статье очень мало что можно вынести
"Как я учил гуманитариев программировать и что из этого вышло"
Что вышло - вопрос открытый (https://habr.com/ru/post/599329/#comment_23903797 - Удалось объяснить гуманитарию зачем нужны переменные и что такое функция? Или "это другое"? (c)
https://habr.com/ru/post/599329/#comment_23904673 - Начали за здравие, закончили за упокой. Программированию то удалось обучить? Потому что пока выглядит как реклама визуальных сред.
), и какую именно роль сыграло в этом визуальное прграммирование, очень большой вопрос
И опять видать фраза про выразительные языки как-то мимо вас прошла
блин... кто ж спорит, а можно и по другому начать программирование и тем же гумманитарием
я говорю о графическом вводе, когда рисуется диаграмма вы графически вводите объекты, перетаскиваете мышью на холст
потом дополняете объекты текстом - клавиатурой
когда обычное программирование это в первую очередь работа с текстом большого объема
ну вот именно, только с оговоркой, разработчик вообще к графическим интерфейсам из за отсуствия дизайнеров занимается этой штукой
ну а мушью я пользуюсь, в основном чтоб скорилить текст, да и то..., а большую часть действий я совершаю клавиаутрой
Кто вас за язык тянул ?
Ну потому что это показывает предел графического программирования, дело не в сложности, а в возможностях языка
Перечисленные выше вопросы - это все о примитивах языка
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM - это вопрос к тому что любой язык программирования может быть сведен к более простому языку (по Тюрингу)
Но мы как-то не используем простые языки (ASM, C), а используем именно выразительные языки (Scala/C#/Haskel/TypeScript/...)
По мне из известных графических языков, многие из них страдают одними и теме же проблемами:
Не выразительны в сложных абстракциях - это не доработка дизайнера языка
Все ориентированы на кликанье мыши - а это заведомый тупик и проигрышь по сравнению с клавиатурой, стилус почему то не используют
Большинство работают как с листом бумаги и схемами на ней, а должно быть более сложное пространство, например бесконечное увеличение частей схемы
У большинства нет возможности создавать свои графические обозначения, свой графический язык - а это нарушает сами принципы языков
Собственно и изучаю, что может ваша платформа, чем она может быть полезна (и в ваших же интересах расказать о ней)
Например меня интересует на сколько силен ваш статический анализатор по сравнению с Rust
Переименование это только первая очивидная проблема
Я могу предположить, что у вас на платформе генерируется код, тот же C# и потом делается попытка его скомпилировать
Если так, тогда как пользователь платформы узнает о
опечатках в коде
не правильном использовании типов данных, например: "Иванов" + 5 сентября
Из менее очивидных проблем графического программирования:
как быть если хотим ООП (свои структуры данных + методы структур данных) - тут я ожидаю, что визуального языка нет, все придется описывать руками и текстом
как быть с много поточкой и блокировками
как быть с иммутабельностью
как быть с транзакциями, вложенными транзакциями
Как быть с унаследованным кодом, можно ли трансформировать исходный код на C# в диаграммы ?
Возможно и устарели представления, но в целом я ожидал этот ответ, что рекурсивной стрелки/дуги нет.
Хотя если бы язык был развитый, тогда из синего прямоугольника (invoke) могла быть дуга к пункту старт - это было бы значительно наглядней.
Из примеров я могу судить что у вас xaml файл = функция - так ?
А из-за того что у вас используются названия файлов при вызове - возникнет (я так предполагаю) очивидные мелкие проблемы - переименование файла может к чертям сломать функцию, которая вызывает код. Была бы рекурсивная стрелка - ничего бы не сломалось.
Как вы боритесь с согласованностью визуального кода и вызывемых функций ? т.е. что будет если файлы переименовать, когда узнаем о проблеме - в compile time или run time ?
Я понимаю что вы на Net все написали, это конечно хорошо, еще бы Java/Rust/etc..., но дело же не в этом
Вы пишете:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Мне интересно как именно графически будет выглядеть кусок кода ниже:
Вот смотрите, есть допустим у меня такой кусок кода:
Данная функция вызвает сама себя, а как в вашем случае в графической нотации вызывает функция сама себя ?
Как вы определяете графически функцию ? есть ли у вас для аргментов функции какие-то графические блоки, для каждого аргумента функции как определить тип данных ?
Простые конструкции языка графически представить не сложно
цикл - две дуги, одна дуга ведущая к началу итерации, другая к выходу из цикла
ветвление (if) - пара дуг, одна в случае истенности условния, другая в случае ложности
При большом желании можно определить графически функцию исключительно, но вот куда засунуть рекурсивный вызов функции графически, так чтоб стрелочкой... вот это уже интереснее, а текстом я и сам знаю
Что тут думать... А то, что среды графической разработки (графические языки программирования) пользуются своей нишевостью и от туда не вылезают уже очень давно
Вот статья на хабр https://habr.com/ru/company/edison/blog/432334/ (Визуальное программирование — почему это плохая идея)
По мне, это только первый этап в обучении программированию, не стоит делать большую ставку (но у вас там целый отдел), как самостоятельная практика написания возможна, но она упрется в фундаметальные ограничения
В первую очередь графический язык - некоторые штуки в нем тяжело выразить, например понятия:
рекурсия
лямбда / функтор (функциональный объект)
рефлексия и метапрограммирование
.... много оных
Вторая очередь: инструменты, есть ли в инструментах например intellisense, git, ...
Можете прояснить, как производительность связана с hotreload, о какой производительности идёт речь?
А мне вот вообще кажется идея узнать за 60 минут порочна.
За это время в лучшем случае я за это время составить свое/субъективное мнение и не факт что оно будет верным, другой человек спросить кандидата другие вопросы и его мнение будет отличаться от моего... Кто тогда прав будет?
Т.е. первый вопрос, а как вы проверяете что ваши методики проверки знаний работают корректно?
Второй вопрос - стек: а что, вы действительно считаете что есть только Spring boot? И знание его ньюансов так важно? Ну вот в качестве примеров транзакции например почему не спросить, чем именно отличается уровень транзакции serializable от repeatable read, и как это реализовано в бд?
Так же про более базовые вещи, я например не вижу смысла спрашивать за rest api endpoint , если человек не знает разницу между UDP/TCP/HTTP
Т.е. у меня есть такое и убеждение (которое может быть не верно) что базовые знания важны, а фреймворки могут меняться со временем, базовые же реже меняются
Спасибо за статью, будет полезна.
Хотелось бы услышать по подробнее по саму задачу. Возможно это можно решить все проще, например так:
Ставь oracle клиент вообще не обязательно, можно просто скачать oracle instant client - он занимает около 30 мб и не требует и установки, в комплекте и oci, и sqlplus.exe. а при желание наверно можно уменьшить и до 10 мб.
С другой стороны имея sqlplus.exe, то C++ особо не нужен, достаточно будет написать скрипт на pl/sql который будет исполняться на клиенте (посредством sqlplus) и работать с oracle db.
Если нужны специфичные от ос функции, у вас всегда есть под рукой powershell, либо wsh+wmi
Если подумать то все это должно быть не больше 20..30 мб и все это замечательно можно упаковать zip/rar/7z sfx
(С) "Кто тут в цари последний? никого, тогда я первый буду!"
Вот что тут сказать, если вы не задаете вопросов или ваши вопросы не корректны, то наверно вы сами тому виной, элементарно в ТЗ будет написано такое как "написать вирус шифровальщик" - то, уж как не крутите, вы будете со автором, это элементарно перекладывание ответственности.
Microsoft / Apple / IBM / ... - это уже не бизнес ?
А по мне это логично, ведь в не в каждой деревне есть своя Красная площадь или Мавзолей и свой царь, ведь это не повод говорить, что теперь нам царь/мавзолей/... не нужен
Когда-то говорили что черных лебедей не бывает
Вот тут ошибка невежественных и конкурентоспособных - это как ? o_O
На мой взгляд прав, и на мой субъективный взгляд - проблема в тех же приславутых Soft Skill
По мне Soft Skill - это шапочный термин и очень не точный, из которого растут больше кол-во проблем, ведь в той же школе/институте нет таких обязательных дисциплин как: Логика, Теория аргументации, Ораторское искусства и соответственно на собесах спрашивают, то что знают - а это Hard (алгоритмы, сети, etc...)
Конечно это не отменяет того факта, что кандидаты действительно могут и не уметь в hard и как-то надо отсеивать, да и само собеседование не дешевое удовольствие по времени и силам
Как вы видите развитие эмоционального интеллекта ? у меня например есть предубеждение - что читать курсы по эмоциям и мышлению - это как "об стенку горохом" / "танцевать об архитектуре"
По мне большая часть эмоционального интеллекта не сводиться к психологии, а скорее на оборот - например музыке, литературе, философии и ораторскому искусству
Ну что бы было противодействие - нужно что-то в духе Профсоюза, что бы не (бывший) студент читал не понятные - а проф юристы
Еще желательно это иметь эту привычку с момента учебы - например какие ни будь студенческие союзы
В целом мне нравится порядок мыслей
Несколько соображения, о учебе и бизнесе
Цели института частично совпадают с потребностями бизнеса, но так же другая может быть цель - наука и тут точно дипломные работы не обязаны совпадать с бизнесом.
Наука и исследования - тут могут и должны привлекаться специалисты из профессиональной области - рабочие программисты.
Это я к тому что у вас не только одна группа лиц - студенты - потенциальные ваши работники.
Вторая группа - это преподаватели/учёные из ваших работников т.е. в которых заинтересован сам институт.
Вот когда совпадут ваши интересны : работодателя и института - тогда может что то получится, иначе игра в одни ворота.
Это я к тому что институт или вуз - задачи науки (или освоение бюджета) могут быть более приоритетные чем обучение студентов, а тоже обучение это лишь побочный продукт этой системы.
Второй аспект этой "игры" между бизнесом и институтом - это разные "весовые" категории игроков, уж что, но бизнес слабее - т.к. за институтом - гос финансирование, и гос заказ. Бизнесу надо объединятся для подготовки будущих кадров - т.е. чтоб набрать "вес".
Просто для тех же студентов есть риск - что их знания не будут нужны, а когда этими знаниями занимается один бизнес, то риски только увеличиваются - например обучить только хайповым технологиям.
:))) ладно если key, а то ведь отпечаток зубов попросят :)) даже страшно подумать как его им (не)передать в таком случае
Согласен, в целом эта же проблема с паролями и ключами/сертификатами
Достаточно сложно доказать, что ты - это ты когда тебе не верят, один из вариантов, .... это привязать например ключ и физической составляющей (днк,отпечаток,...) и ментальной (пароль, контрольная фраза, сгенерированный уникальный ключ, то что не имеет физического аналога) - та чем обладает человек как знаниями, такая своеобразная двух факторная авторизация.
Тут еще можно пофантазировать например иметь два ключа
физический + ментальный1 - для утвердительного голосования
физический + ментальный2 - на случай если тебя пытают, ... говоришь пароль и тогда в той-же системе фиксируется факт пытки...,
Это как в одном сериале - что бы открыть сейф герой называет пароль взломщику, и после ввода пароля - все содержимое сейфа уничтожается
Если глубоко уходить в размышления - то
когда имеет автоматическую систему - которая проверят только сертификат/пароль/... появляется ряд вещей которая она не в состоянии проверить - например, человек не адекватен, пьян, или его запугивают - тогда все его действия нельзя считать юридически верными, т.к. он за себя не отвечает, в таких случаях обычно нужно третье лицо, и обычно это нотариус.