По мне так - с какого расстояния смотреть - и по факту качество лишь одно - "скорость". Связи, поиска, генерации мусора, решения типовых задач... т.е. сокращение трудозатрат на рутину - при неизменной скорости жизнедеятельности человека и природных процессов. Т.е. алгоритмически - экстенсивно, хотя да, это качество есть. Вопрос философский...
Только новоязом. А так - ничто не ново под луной, выше написал :) всё экстенсивный рост, качественные скачки за счет абстракции/сборки из готовых модулей/примитивов да ускорение вычислений. Инженерный аппарат со времен Ляпунова, Вирта и прочих Кнутов/Аммералов/Таненбаумов тоже всё тот же
(не осуждаю, мне нравится (кроме питона с его отступами) - просто констатирую)
1987, кластер, MicroVAX II (KA 630, 32 бита 33 МГц RISC), 9 МБ памяти на узел, полная виртуализация, несколько ТК на полдюймовке, терминальный мультиплексор на 50 пользователей, геораспределенка, по 2 HDD по 27 блинов на 850 МБ с аргоновой продувкой.
Да, на терминалах VT340 было разрешение 800*500, 4096 цветов и оконный интерфейс DECWindow, если надо (не надо).
Годами непрерывная работа; раз в год плановая остановка и автоочистка/калибровка HDD.
шкаф документации (читаешь - и понимаешь, что ничего нового в Windows/*nix за 40 лет не изобретено (разве что ИИ, да и то - нет, был же Lucas), и это всё - просто потомки (от ядра NT до PowerShell, удивительно напоминающего DCL по идеологии (DEC Command Language). Даже файловая система-БД NT Longhorn, которая в серию не пошла - с ушами RMS (VAX/VMS Record Management System).
Я бы не недооценивал сорокалетних :))) это не только брак СМ
ЗЫ. а еще на экран VT340 можно было налепить (сама прилипала) дискету 5.25, что заглючила, и его включить - петля размагничивания сама чинила дискеты :) )
Кстати, хотя версия ошибки перевода распространена (как я писал ниже), оказывается, есть и вторая версия: что не ошибка, а именно Grobe (грубый как большой), а не Große (большой) - в англоязычных источниках встречается со ссылкой на немецкую традицию, например, список Kleine Kanon / Kanon / Grobe Kanon.
Глубокая тема... на практике делали разные системы, экспериментировали:
Кто-то "по образцу" - "так набрали Цицерона, давайте так же"
Кто-то "по автору" рисунка шрифта или хозяину типографии/заказчику
Кто-то по золотому сечению или Фибоначчи, от эстетики
Кто-то - "пол-цицеро, полтора цицеро"
Кто-то - "заголовок, тело, сноска"
Китайцы - вообще по номерам (самый крупный - "первый", наборный - ЕМНИП 5-й).
Во времена французской революции - попытались перевести в метрическую систему (потом это же пытались немцы и американцы). Неудобно, зрение человека не так устроено, не прижилось.
... А потом во времена растра и ЭЛТ - сначала продолжили (поэтому, например, логическое разрешение экранов было 72 ppi, и сохранялось при повышении физического разрешения (но 96 было неудобно, лучше 100 - примерно х1,4; потом - 120, примерно х1,7). Причем у Windows и Mac - с разной оптической поправкой через угловые градусы на другое расстояние просмотра. Отсюда даже сейчас масштаб "1,25х, 1,5х...", с разной хинтовкой и растаскиванием...
и только когда экраны стали совсем разными, а разрешение - высоким, система поменялась (но пересчет через угловые градусы на расстояние до экрана везде, если копнуть глубже, остался).
В итоге сейчас история повторяется, и система снова становится похожей на изначальную: либо "доли от базового наборного шрифта", либо названия "по назначению" (заголовок, текст), либо собственные имена.
Так не было еще размеров ) Примерно так (без исторической точности) "сначала набрали Цицерона", потом другие книги, потом - придумали делить "от Цицерона" на 12 и умножать на 4 и на 6 - так появились пункты, пики и квадраты... да еще и разные в разных странах.
Литеры не масштабировались, гравировали и отливали кассу конкретного размера отдельно, сразу с оптическими поправками. "На глазок". Ручная мастерская работа, и мастера давали названия. )
Гробе - не ошибка (точнее - устоявшаяся ошибка русских наборщиков позапрошлых веков, которые так прочитали гроссе), как и, например, "петит" - вместо "пти".
...А еще кегль и другие метрики (очка, засечек, шпаций...) в русской системе отличались от зарубежных.
Это было не случайно. В России, потом в СССР - оптически подправляли под кириллицу.
Поэтому в современном наборе на ПК как для печати, так и для экрана все русские шрифты неправильного (эргономически контр-интуитивного) размера, подогнаны под латиницу (хотя можно поправить на коэффициенты, но это только для художественных изданий старые мастера делают), а стандартные шрифты еще и искорежены (начиная от тихого ужаса Arial по-русски). "Звучание" уже не то. "Штош..." )
Способ реализации оставляется кандидату. Принцип - "решить или показать ход решения задачи за ограниченное время любым способом лично" (без гугления / ide / ...)
Ниже https://habr.com/ru/companies/ruvds/articles/861018/comments/#comment_27596024 есть про экзамен "пригласить полетать на тренажере" - это примерно то же самое. С учетом того, что в ИТ разнообразие тренажеров (средств разработки), и нужно время на привыкание - лучший по моему опыту - мозг / карандаш / бумага (иногда - пальцы рук и две коленки, т.е. просто рассказать/показать устно).
Ну или "принести с собой свой ноут" - но это тоже усложняет.
Когда я собеседовал разработчиков / аналитиков / QA - в итоге пришел в части проверки навыков к очень простому тесту: произвольная (из нужной части) задача из древней книги The IBM Programmer's Challenge: 50 Challenging Problems to Test Your Programming Skills With Solutions in Basic, Pascal and C (см. например на Amazon или https://books.google.com/books/about/The_IBM_Programmer_s_Challenge.html?id=Ic1CAAAACAAJ).
Языки, конечно, менялись. Страницу книги мог рандомно выбрать кандидат.
Подбиралась так, чтобы уложиться в полчаса, максимум час. Без компьютера, карандашом на бумаге. При выходе за лимит времени оценивалось то, что есть.
Для аналитика - производная задача как сформулировать требования, для QA - как проверить результат.
Так сразу проверялось и понимание задачи, и готовые навыки структурировать решение, и "на память" ЯП, и английский, и подход, и умение работать в непривычных условиях.
... 100% работоспособность или полнота кода не имела значения.
Вторым подходом - тут же действующий разраб смотрел логику и задавал 2-3 вопроса, а если видел ошибки - задавал вопросы по ним.
Если было очень нужно - это было второй частью; первая - показать и объяснить свой код/требования/..., третья - задать вопросы (не прокомментировать) по коду/докам действующего сотрудника.
Т.е. всё на "ход мыслей", умение собраться, взаимодействовать и рассуждать, и только (остальное всегда требует врабатываемости и "права на ошибку"). На всё про всё хватало часа-полутора в один подход.
Заодно ограждало от "нашего стека", узких задач, почерка или предпочтений тимлида - автор книги лучший составитель задач, чем программист-практик.
Так и делали! Учась на работах тех же Ляпуновых. Ну и европейской школы, начиная от дедушки Вирта.
Вспоминаю "300 томов" документации например к MicroVAX II и VAX/VMS - если их знать - понимаешь, что и в новом железе и в, например, Windows 11 нет вообщеничего принципиально нового за 35 лет (даже включая видеопроцессоры, нейропроцессоры и т.п.) - всё было в том же STARAN и LUCAS...
Только авторов "ядра" (будь то железо, или BIOS, или микроядра) - всегда были в мире единицы...
Помню, как Windows 286 (помните такую? то ли 2.03, то ли 2.11 по-моему - порт на защищенный режим с совместимостью с реальным) реально писал один человек две недели и 4 ящика пива.
Просто нужны инженеры программного обеспечения а не "блочные сборщики" - мало кто помнит имхо, что такая профессия еще есть... (хотя конечно меня закидают тапками сейчас :) )
Соглашусь. Хотя я сам давно ушел в другую немного сферу - опыт из 80-х - 90-х (от машинных и ассемблера z80/x86/KA630 (кто помнит такой? классный! 32 бит 33 МГц в кластерах :) до логики стеков BIOS / BDOS / CPM / VMS, OS/2, Windows 1.03 и далее - с резидентами, VT, драйверами плат и локалкой от DEQNA - и всяких BLISS, Паскалей/Mодул/Фортранов и прочих там C/C++ до сих пор на кончиках пальцев )
Тогда было в кайф, "мышководителей" не было, руководства были толковыми, при знании алгоритмов "базы" освоить новый язык - было делом 2-4 недель, а собрать и запустить локалку - за неделю можно было на лапше и вертолетных разъемах...
До сих пор уверен, что "старички" с правильной логикой, не забывшие stepwise refinement и подобные приемы - вполне могут обучить молодую смену.
Только вот вопрос: зачем это юным? Где потом применять кроме одного-двух проектов???
Точно! RSX уже подзабыл, а в VMS 5.3 точно был, как раз probe/challenge. Но привычнее был ручной конфиг.
адреса или жесткие или перемычками/переключателями, поэтому искать что попало где ни попадя не нужно было.
А как приятны были команды типа stop dub0:ivanov :)
а еще в тему статьи можно было писать сразу на Fortran / Pascal / C и с добавлением BLISS и DCL - и всё работало из коробки.
пожалуй, тут вы правы ) хотя probe/challenge/handshake протоколы были, но тут - да.
Дык! Тёмного!
По мне так - с какого расстояния смотреть - и по факту качество лишь одно - "скорость". Связи, поиска, генерации мусора, решения типовых задач... т.е. сокращение трудозатрат на рутину - при неизменной скорости жизнедеятельности человека и природных процессов. Т.е. алгоритмически - экстенсивно, хотя да, это качество есть. Вопрос философский...
А для вас - какое именно качество?
Только новоязом. А так - ничто не ново под луной, выше написал :) всё экстенсивный рост, качественные скачки за счет абстракции/сборки из готовых модулей/примитивов да ускорение вычислений. Инженерный аппарат со времен Ляпунова, Вирта и прочих Кнутов/Аммералов/Таненбаумов тоже всё тот же
(не осуждаю, мне нравится (кроме питона с его отступами) - просто констатирую)
Ага, а еще отладка и аварийный останов (АВОСТ / ABORT / ABEND) и пакетные задания )
И посмертный дамп.
1987, кластер, MicroVAX II (KA 630, 32 бита 33 МГц RISC), 9 МБ памяти на узел, полная виртуализация, несколько ТК на полдюймовке, терминальный мультиплексор на 50 пользователей, геораспределенка, по 2 HDD по 27 блинов на 850 МБ с аргоновой продувкой.
Да, на терминалах VT340 было разрешение 800*500, 4096 цветов и оконный интерфейс DECWindow, если надо (не надо).
Годами непрерывная работа; раз в год плановая остановка и автоочистка/калибровка HDD.
шкаф документации (читаешь - и понимаешь, что ничего нового в Windows/*nix за 40 лет не изобретено (разве что ИИ, да и то - нет, был же Lucas), и это всё - просто потомки (от ядра NT до PowerShell, удивительно напоминающего DCL по идеологии (DEC Command Language). Даже файловая система-БД NT Longhorn, которая в серию не пошла - с ушами RMS (VAX/VMS Record Management System).
Я бы не недооценивал сорокалетних :))) это не только брак СМ
ЗЫ. а еще на экран VT340 можно было налепить (сама прилипала) дискету 5.25, что заглючила, и его включить - петля размагничивания сама чинила дискеты :) )
ЗЗЫ. а еще в 2010+ продолжало работать.
Кстати, хотя версия ошибки перевода распространена (как я писал ниже), оказывается, есть и вторая версия: что не ошибка, а именно Grobe (грубый как большой), а не Große (большой) - в англоязычных источниках встречается со ссылкой на немецкую традицию, например, список Kleine Kanon / Kanon / Grobe Kanon.
Или он же на https://polygraphy_de_ru.academic.ru/6767/der_grobe_Kanon___die_groben_Kanons
не удивлюсь, если верны обе (например, англичане и французы также могли читать ß как b, а немцы - большой называть грубым для "смачности").
Благодарю за ссылку, уже лет 25 эта книга не попадалась на глаза - на бумаге читал, а потом забыл :)
Глубокая тема... на практике делали разные системы, экспериментировали:
Кто-то "по образцу" - "так набрали Цицерона, давайте так же"
Кто-то "по автору" рисунка шрифта или хозяину типографии/заказчику
Кто-то по золотому сечению или Фибоначчи, от эстетики
Кто-то - "пол-цицеро, полтора цицеро"
Кто-то - "заголовок, тело, сноска"
Китайцы - вообще по номерам (самый крупный - "первый", наборный - ЕМНИП 5-й).
Во времена французской революции - попытались перевести в метрическую систему (потом это же пытались немцы и американцы). Неудобно, зрение человека не так устроено, не прижилось.
... А потом во времена растра и ЭЛТ - сначала продолжили (поэтому, например, логическое разрешение экранов было 72 ppi, и сохранялось при повышении физического разрешения (но 96 было неудобно, лучше 100 - примерно х1,4; потом - 120, примерно х1,7). Причем у Windows и Mac - с разной оптической поправкой через угловые градусы на другое расстояние просмотра. Отсюда даже сейчас масштаб "1,25х, 1,5х...", с разной хинтовкой и растаскиванием...
и только когда экраны стали совсем разными, а разрешение - высоким, система поменялась (но пересчет через угловые градусы на расстояние до экрана везде, если копнуть глубже, остался).
В итоге сейчас история повторяется, и система снова становится похожей на изначальную: либо "доли от базового наборного шрифта", либо названия "по назначению" (заголовок, текст), либо собственные имена.
Так не было еще размеров ) Примерно так (без исторической точности) "сначала набрали Цицерона", потом другие книги, потом - придумали делить "от Цицерона" на 12 и умножать на 4 и на 6 - так появились пункты, пики и квадраты... да еще и разные в разных странах.
Литеры не масштабировались, гравировали и отливали кассу конкретного размера отдельно, сразу с оптическими поправками. "На глазок". Ручная мастерская работа, и мастера давали названия. )
Гробе - не ошибка (точнее - устоявшаяся ошибка русских наборщиков позапрошлых веков, которые так прочитали гроссе), как и, например, "петит" - вместо "пти".
Что ж, так принято.
Любопытно посмотреть, например, здесь. https://lubivaet.narod.ru/pdf/Cicero.pdf
...А еще кегль и другие метрики (очка, засечек, шпаций...) в русской системе отличались от зарубежных.
Это было не случайно. В России, потом в СССР - оптически подправляли под кириллицу.
Поэтому в современном наборе на ПК как для печати, так и для экрана все русские шрифты неправильного (эргономически контр-интуитивного) размера, подогнаны под латиницу (хотя можно поправить на коэффициенты, но это только для художественных изданий старые мастера делают), а стандартные шрифты еще и искорежены (начиная от тихого ужаса Arial по-русски). "Звучание" уже не то. "Штош..." )
Способ реализации оставляется кандидату. Принцип - "решить или показать ход решения задачи за ограниченное время любым способом лично" (без гугления / ide / ...)
Ниже https://habr.com/ru/companies/ruvds/articles/861018/comments/#comment_27596024 есть про экзамен "пригласить полетать на тренажере" - это примерно то же самое. С учетом того, что в ИТ разнообразие тренажеров (средств разработки), и нужно время на привыкание - лучший по моему опыту - мозг / карандаш / бумага (иногда - пальцы рук и две коленки, т.е. просто рассказать/показать устно).
Ну или "принести с собой свой ноут" - но это тоже усложняет.
Когда я собеседовал разработчиков / аналитиков / QA - в итоге пришел в части проверки навыков к очень простому тесту: произвольная (из нужной части) задача из древней книги The IBM Programmer's Challenge: 50 Challenging Problems to Test Your Programming Skills With Solutions in Basic, Pascal and C (см. например на Amazon или https://books.google.com/books/about/The_IBM_Programmer_s_Challenge.html?id=Ic1CAAAACAAJ).
Языки, конечно, менялись. Страницу книги мог рандомно выбрать кандидат.
Подбиралась так, чтобы уложиться в полчаса, максимум час. Без компьютера, карандашом на бумаге. При выходе за лимит времени оценивалось то, что есть.
Для аналитика - производная задача как сформулировать требования, для QA - как проверить результат.
Так сразу проверялось и понимание задачи, и готовые навыки структурировать решение, и "на память" ЯП, и английский, и подход, и умение работать в непривычных условиях.
... 100% работоспособность или полнота кода не имела значения.
Вторым подходом - тут же действующий разраб смотрел логику и задавал 2-3 вопроса, а если видел ошибки - задавал вопросы по ним.
Если было очень нужно - это было второй частью; первая - показать и объяснить свой код/требования/..., третья - задать вопросы (не прокомментировать) по коду/докам действующего сотрудника.
Т.е. всё на "ход мыслей", умение собраться, взаимодействовать и рассуждать, и только (остальное всегда требует врабатываемости и "права на ошибку"). На всё про всё хватало часа-полутора в один подход.
Заодно ограждало от "нашего стека", узких задач, почерка или предпочтений тимлида - автор книги лучший составитель задач, чем программист-практик.
А вам как вам такой подход? И как вы собеседуете?
"Миндалины я удалил..."
там имхо печаль, да.
Android - AquaMail? Nine? (конечно кроме OSS)
Не понимаю, почему Вас минусуют...
Так и делали! Учась на работах тех же Ляпуновых. Ну и европейской школы, начиная от дедушки Вирта.
Вспоминаю "300 томов" документации например к MicroVAX II и VAX/VMS - если их знать - понимаешь, что и в новом железе и в, например, Windows 11 нет вообще ничего принципиально нового за 35 лет (даже включая видеопроцессоры, нейропроцессоры и т.п.) - всё было в том же STARAN и LUCAS...
Только авторов "ядра" (будь то железо, или BIOS, или микроядра) - всегда были в мире единицы...
Помню, как Windows 286 (помните такую? то ли 2.03, то ли 2.11 по-моему - порт на защищенный режим с совместимостью с реальным) реально писал один человек две недели и 4 ящика пива.
Просто нужны инженеры программного обеспечения а не "блочные сборщики" - мало кто помнит имхо, что такая профессия еще есть... (хотя конечно меня закидают тапками сейчас :) )
Соглашусь. Хотя я сам давно ушел в другую немного сферу - опыт из 80-х - 90-х (от машинных и ассемблера z80/x86/KA630 (кто помнит такой? классный! 32 бит 33 МГц в кластерах :) до логики стеков BIOS / BDOS / CPM / VMS, OS/2, Windows 1.03 и далее - с резидентами, VT, драйверами плат и локалкой от DEQNA - и всяких BLISS, Паскалей/Mодул/Фортранов и прочих там C/C++ до сих пор на кончиках пальцев )
Тогда было в кайф, "мышководителей" не было, руководства были толковыми, при знании алгоритмов "базы" освоить новый язык - было делом 2-4 недель, а собрать и запустить локалку - за неделю можно было на лапше и вертолетных разъемах...
До сих пор уверен, что "старички" с правильной логикой, не забывшие stepwise refinement и подобные приемы - вполне могут обучить молодую смену.
Только вот вопрос: зачем это юным? Где потом применять кроме одного-двух проектов???
:) морских
(как в нефтянке - onshore / offshore = бурение на суше / в море)