Продолжаем разбираться в устройстве и работе современных механических клавиатур. В первой части мы поговорили про терминологию, размеры и типы переключателей. А сегодня разберемся в кейкапах (клавишах) и программировании, полюбуемся на артизаны и другие виды кастомизации, а также посмотрим где все это продается и какому алгоритму можно следовать при покупке.

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все знают про язык программирования C, поменьше — про язык программирования F, кое‑кто про B, предшественник C, а вот знаете ли вы про язык «e»? Их кстати два — один с большой буквы «E», а другой с маленькой «e».

Вы наверное подумали, что это еще один безызвестный язык от какого‑нибудь аспиранта провинциального европейского университета. Однако интерпретатор маленького «e» под названием Specman продали в 2005 году большой компании Cadence Design Systems за $315 милионов долларов. Причем президента продающей компании Verisity звали Гаврилов. Также можно нагуглить, что этот язык использовали внутри компании Intel. Что же в нем такого, что вызвало интерес у толстых богатых корпораций?

Заблуждение 1. Любые символы, кроме управляющих, имеют предсказуемую ширину

Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

Я работаю проектировщиком аппаратного блока графического процессора в телефонах Samsung, в рамках совместного проекта с AMD. Сейчас наш менеджмент расширяет команду и поощряет инженеров распостранять информацию о новых позициях среди своих знакомых. Я решил написать это пост для более широкой аудитории, так как множество людей, способных пройти интервью на RTL или DV позицию - больше, чем множество моих знакомых. Если вы сможете прислать мне ответ на задачку в моем посте вместе с вашим резюме, я перешлю его нанимающему менеджеру и рекрутеру нашей группы (в комментах прошу ответ не писать). Если резюме им понравится, вам нужно будет пройти стандартное собеседование на несколько часов, с несколькими инженерами, у каждого из которых свой набор задачек.

Также я покажу материалы, по которым можно готовиться к собеседованию, особенно если вы студент или у вас ограниченный опыт в микроэлектронной промышлености.

У меня был в свое время практикант из Стенфорда, от которого я получил инсайдерскую информацию, чему их там учат. Потом я интервьировал много студентов, и понял, что если человек не делает самостоятельных проектов в вузе, а просто плывет по течению программы как медуза, то будучи выброшенным на берег индустрии, он становится совершенно беспомощным.

Когда я вижу у недавнего выпускника в резюме какой-то из протоколов в котором используется valid/ready, например AXI или AHB, я прошу его спроектировать блок, у которого на входе два числа A и B, а на выходе их сумма. Разумеется не просто написать SUM=A+B, а еще и поставить valid/ready сигналы на каждый из A, B, SUM, чтобы A и B могли приходить в разное время, а также чтобы блок ждал, если SUM не может быть передана другому блоку сразу.

Некоторые не справляются. Грустно смотреть на человека, который потратил 6 лет своей жизни (4 года в бакалавриате и 2 года в магистратуре) и океан денег на образование - и не может сложить два числа и бьется как угорь на сковородке. То блок не работает когда числа приходят в разное время, то создатель забывает снять valid, и блок на 2+2 выдает не 4, а 4-4-4-4-4-4-4... То числа складываются не попарно, а просто записываются в регистры и на выход идет их текущая сумма, хотя количество аргументов A и B не совпадает. То не отрабатывается backpressure и результаты теряются, то (после того как кандидат написал страницу кода на верилоге) блок работает на половинной производительности, то есть не может принимать поток чисел подряд, а ожидает между ними пропуски (gaps). Короче ведет себя как ChatGPT.

Машина

Новый результат показывает, что квантовая информация теоретически может быть защищена от ошибок точно так же, как и классическая информация.

Нижеприведенный список является моей небольшой коллекцией примеров кода на языке С, которые не являются корректными с точки зрения языка С++ или имеют какое-то специфичное именно для языка С поведение. (Именно в эту сторону: С код, являющийся некорректным с точки зрения С++.)

Этот материал я уже публиковал на другом ресурсе в менее причесанном виде, Я бы, наверное, поддался прокрастинации и никогда не собрался опубликовать эту коллекцию здесь, но из-за горизонта уже доносится стук копыт неумолимо приближающегося С23, который безжалостно принесет некоторые жемчужины моей коллекции в жертву богам С-С++ совместимости. Поэтому мне и пришлось встать с печи, пока они еще актуальны...

Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.

Мне всегда нравилось копаться в истории IT и находить какие-то штуки из прошлого, которые находятся здесь и сейчас рядом с нами. Что-то такое, что было разработано десятки лет назад, но продолжает жить и развиваться и, порой, занимает заметное место в нашей жизни даже если мы об этом не знаем.

В публикации - три короткие "живые" истории. Первая про старое железо и 6-битные байты. Вторая про старый софт и Министерство Обороны. И третья про старые баги и новые айФоны.

Наверное, мне не дано понять всю красоту и мощь диаграмм Ганта. Зато попытки разобраться в них подарили открытие — деятельность Кароля Адамецкого, человека, который не просто опередил и Ганта, и своё время, но придумал менеджмент, каким мы его знаем, когда абстрактное управление проектами идёт параллельно с работой с людьми.

К сожалению, все его разработки конца 19 — начала 20 века были известны в пределах Российской империи, и тогда по большому счёту не до менеджмента было. Поэтому первенство в открытии проектных диаграмм осталось за Гантом, а первые попытки описать менеджмент как современную дисциплину стали достижением Тэйлора. А Адамецкий вошёл в историю почти никому не известным гением. Дальше — просто его история, интересные находки и озарения.

Введение

По мере изменения климата волны жары становятся все более интенсивными: они длятся дольше, идут чаще, а температуры всё выше. Сейчас одна такая волна проносится через Европу: в Испании и Португалии только за прошедшую неделю умерли 1100 человек. Люди просто оказались не готовы к температурам выше 35 ºС: у них в домах не было кондиционеров, а многие днем выходили и пытались работать как обычно. И получили огромные проблемы со здоровьем.

В целом по Европе за одно это лето счет идет уже на десятки тысяч. Этот год, по всей видимости, станет даже более смертоносным, чем печально известный 2003-й, когда в Европе от жары погибло 30 000 людей. Но тогда температура доходила до 37 ºС, сейчас — под тем же Парижем фиксируют уже до +42 ºС.

Видимо, люди просто не понимают, в какую погоду можно находиться на улице, как им вести себя дома, и насколько вообще всё серьезно.

Попытаемся ответить.

Конкурентность сложно как следует наладить, как минимум, тем из нас, кому не повезло писать на языках, непосредственно открывающих нутро конкурентного аппаратного обеспечения: речь о потоках и разделяемой памяти. Не менее сложно организовать конкурентность так, чтобы она работала и правильно, и быстро. Все, что вы знаете об оптимизации однопоточного кода, зачастую вам не поможет. На микроуровне (отдельные инструкции) просто невозможно применить обычные правила, актуальные для μ-операций, цепочек зависимостей, пределов пропускной способности и т.д. При конкурентности правила другие.

Если этот первый абзац вселил в вас надежду, то второй ее обломает: в этой статье я не собираюсь углубленно анализировать самые низкоуровневые аспекты конкурентной производительности. Мы попросту очень многого не знаем о том, как выполняются атомарные инструкции и барьеры памяти, и эту тему мы пока отложим.

Вместо этого я собираюсь дать сравнительно высокоуровневую классификацию, которой пользуюсь для рассуждений о производительности конкурентных операций. Мы сгруппируем вопросы производительности конкурентных операций, выделив шесть обширных уровней, от быстрого к медленному, причем, каждый уровень примерно на порядок отличается по производительности от соседствующих с ним.

Часто ловлю себя на мысли, что рассуждаю именно в таких категориях, когда мне нужна высокопроизводительная конкурентность: каков наилучший уровень, который я реально могу достичь при решении конкретной задачи? Держать в уме эти уровни полезно и на этапе первичного проектирования (иногда небольшое изменение требований или высокоуровневого дизайна позволяют вам выйти на более выгодный уровень), а также при оценке уже существующих систем (для еще более точного понимания имеющейся производительности и выстраивания пути наименьшего сопротивления, ведущего к улучшениям).

23 июля 2021 года на «Хабре» прошло как-то спокойно, никто даже и не вспомнил, что в этот день во всем мире отмечали шестидесятилетие пишущей машинки «IBM Selectric І». Вдумчивый читатель спросит: а что, теперь надо отмечать юбилей каждой модели пишущей машинки, которая была выпущена за всю историю человечества? Сразу же отвечу: нет, всех не надо. А вот особо выдающихся — надо. Тем более, что «IBM Selectric І» — это не просто очередная пишущая машинка, а целый компьютер, который смогли создать и запустить в массовое производство в конце 1950-ых годов.