Кстати, хотя версия ошибки перевода распространена (как я писал ниже), оказывается, есть и вторая версия: что не ошибка, а именно 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 и подобные приемы - вполне могут обучить молодую смену.
Только вот вопрос: зачем это юным? Где потом применять кроме одного-двух проектов???
по идее, лучше охлаждение (2 кулера), больше батарея, дольше держит. Хуже SSD, меньше портов USB (-1 type C), хуже камера (720 вместо 1080), хуже БП - провод не вынимается.
да, еще раскрывается новый на 180 градусов и звук получше.
torq-set (смещенный крест) делали специально для аэрокосмической - больший крутящий момент при меньшем весе крепежа, ниже риск сорвать, и обычным крестом не открутишь (защита от дурака). а потом еще развили - mortorq.
Не совсем... если "помотать нервы" - изменят трудовой договор в одностороннем порядке - с уведомлением за 2 месяца и 2 неделями выходного, с увольнением по п. 7 ст. 77 ТК РФ. В этом случае можно "коллективным спором" на это влиять, а также договариваться о возмещении расходов на переезд по 169 ТК РФ.
Самый для меня классный был BRIEF (B.R.I.E.F.) - конкурент ME, умел все интеграции, невероятно шустрый, и 'distraction-free'. https://en.wikipedia.org/wiki/Brief_(text_editor) потом его купил Борланд и встроил в свое IDE / заодно убил конкурента. По-моему, до сих пор режим совместимости с Brief есть )
"несколько тысяч подрядчиков"- скорее всего, contractors - имелось в виду "сотни штатных и несколько тысяч внештатных работников" (американская специфика FTE / contractor)
Кстати, к варианту ПИЕ leǵ (relegere) = "собирать" : в Бхагавад Гите (2:66) видим "Нет разума для несобранного и нет для несобранного творческой мысли; для не имеющего творческой мысли нет мира, а для не имеющего мира — откуда быть счастью?"
Кстати, хотя версия ошибки перевода распространена (как я писал ниже), оказывается, есть и вторая версия: что не ошибка, а именно 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 = бурение на суше / в море)
по идее, лучше охлаждение (2 кулера), больше батарея, дольше держит. Хуже SSD, меньше портов USB (-1 type C), хуже камера (720 вместо 1080), хуже БП - провод не вынимается.
да, еще раскрывается новый на 180 градусов и звук получше.
torq-set (смещенный крест) делали специально для аэрокосмической - больший крутящий момент при меньшем весе крепежа, ниже риск сорвать, и обычным крестом не открутишь (защита от дурака).
а потом еще развили - mortorq.
https://www.eurekamagazine.co.uk/content/technology/can-phillips-top-what-has-become-the-most-famous-screw-thread-in-the-world/
Не совсем... если "помотать нервы" - изменят трудовой договор в одностороннем порядке - с уведомлением за 2 месяца и 2 неделями выходного, с увольнением по п. 7 ст. 77 ТК РФ. В этом случае можно "коллективным спором" на это влиять, а также договариваться о возмещении расходов на переезд по 169 ТК РФ.
Самый для меня классный был BRIEF (B.R.I.E.F.) - конкурент ME, умел все интеграции, невероятно шустрый, и 'distraction-free'. https://en.wikipedia.org/wiki/Brief_(text_editor)
потом его купил Борланд и встроил в свое IDE / заодно убил конкурента. По-моему, до сих пор режим совместимости с Brief есть )
"несколько тысяч подрядчиков"- скорее всего, contractors - имелось в виду "сотни штатных и несколько тысяч внештатных работников" (американская специфика FTE / contractor)
Скорее you will not pass = ты не пройдешь / you shall not pass = тебе не пройти, "да не пройди!"
А вообще на этом построены, например, формально все стандарты ISO и англосаксонский юридический язык:
shall = обязательство/должествование (должен, обязан, следует / shall not = нельзя, должен не, не следует) - русское "обязанности сторон"
should = желательное поведение / рекомендация (часто "следует / не следует" - тут размыто с shall)
may = имеет право / may not = не имеет права
will и can = просто "добрая воля", формально не используется
(было выше) will = "собираюсь" - КМК не совсем так: для этого есть "going to"
как-то так из "формального мира".
...You shall not kill = длинное "тебе не следует убивать", краткая форма - "да не убий"; неточная, но устоявшаяся - просто "не убий"...
Как-то так AFAICR
Кстати, к варианту ПИЕ leǵ (relegere) = "собирать" : в Бхагавад Гите (2:66) видим "Нет разума для несобранного и нет для несобранного творческой мысли; для не имеющего творческой мысли нет мира, а для не имеющего мира — откуда быть счастью?"
Другие переводы - http://zhalevich.com/biblioteka/bhagavad-gita/1921-bhagavad-gita-266.html (если поискать, будет много об искажениях переводов, и всё же в целом это грани одного смысла...)
(Ср. тж. в семантических полях разных языков гнезда "цельность/integrity" / "справность", "верой-правдой/правоверие" - "вера - veritas - правда (истина)", счастье = "со-частие" (соединение с целым)
В итоге - "религия = собранность" - например, но не обязательно, как набор практик/путь к цельности/истине/богу?