Проводится сеанс разоблачения магии (CISC, RISC, OoO, VLIW, EPIC, ...).
Без традиционной рубрики “а что, если” тоже не обошлось.
Добро пожаловать под кат, правда, лёгкого чтения ожидать не стоит.
Пользователь
[Пятничное] Теория Жоп
Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...
Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.
Как заменить лампочку на рабочем месте так, чтобы тебя не уволили?
Уже три года я живу и работаю в Германии. В декабре прошлого года в нашем кабинете перегорела одна из ламп дневного света. Но не просто перестала светить, а как это часто бывает у люминесцентных ламп со стартером, стала постоянно гаснуть и включаться снова с характерным щелчком. Мои коллеги сразу же позвонили секретарю, та вызвала электрика. Через три дня секретарь сказала, что лампу поменяют нескоро, так как их нет на складе и нужно заказывать. Меня эта ситуация категорически не устраивала. Это моргание раздражало очень сильно.
У нас на этаже есть кладовая, где стоят точно такие же лампы. Только в эту кладовку люди ходят раз в неделю. Самое простое решение – заменить лампу в кабинете на лампу из кладовки. А когда придут новые, сделать нормально.
Вообще эту лампу поменять очень легко. У меня были такие лампы и дома, и на работе. Я, будучи админом, проворачивал этот фокус с подменой ламп много раз.
Я взял барный стул и попросил коллегу-немца подвинуться – лампа висела прямо над его рабочим местом. Нильс спросил, что я задумал, и я поделился с ним своей идеей. Он радостно воскликнул: «Классно, мы будем тебе очень благодарны, а то она уже всем надоела!», а потом шепотом добавил: «… но я бы не советовал тебе этого делать!»
Ультра быстрый Cron с шагом в миллисекунду, или когда тестовые задания такими прикидываются
Давным-давно наш коллега @novar разместил на Хабре статью с описанием вот такого незатейливого ТЗ, полученного им от потенциального работодателя:
Реализовать класс для задания и расчета времени по расписанию. Расписание задано в стиле crontab (точный формат см. во вложении), требуется находить ближайшие в будущем или прошлом моменты, попадающие в это расписание. Обращаю Ваше внимание, что класс должен быть эффективным и не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений. Например очень много значений с шагом в одну миллисекунду.
Хочу предложить алгоритм, приближающийся к O(1) во всех возможных ситуациях, вместо оригинального O(n). Интересующихся прошу под кат.
Ах да. Если вы тот самый работодатель, вот готовый код под ваше ТЗ. Правда на Java, а не на C#. Но вы же не думали, что всё будет так просто?
Как я «напрограммировал» себе скилл рисования диаграмм в скетч-стиле
По работе мне часто приходится рисовать разные схемы, диаграммы процессов и графики, в том числе и те, которые потом используются в качестве иллюстраций для сайта, статей и презентаций. Всё бы ничего, но есть у диаграмм и графиков, сделанных в популярных онлайн-сервисах наподобие draw.io или lucidcharts одна беда — они выглядят как-то слишком уныло и «олдскульно», в духе «90-х». Всю эту инфографику хотелось бы сделать более заметной, привлекательной и душевной (и, желательно, без привлечения дизайнера).
Так у меня возникла идея создания инструмента для отрисовки диаграмм и графиков в стиле «нарисовано от руки». Об истории создания сервиса и «подводных камнях» я расскажу в этой заметке.
Григорий Остер — Вредные советы для писателей мануалов
— Ну, там можно научиться огромному количеству новых и неизвестных вещей.
— А… Правда? Ок, удиви меня.
— Вот! – наивный юнец с радостью ткнул на указатель на приборной панели своей «Хонды».
— И что же в этом такого прикольного?
— Видишь стрелку? Она показывает с какой стороны у тебя крышка бензобака, чтобы ты помнил, где останавливаться у бензоколонки.
Я тяжело вздохнул, открыл бардачок, и, к ужасу парнишки, извлёк из него потрёпанный мануал 2004 года выпуска. После 20 секунд листания оного мануала, я ткнул пальцем в ту самую иконку, которая показывает, с какой стороны у тебя бензобак.
— Ну вот, пожалуйста. Это было известно ещё до «Тик-тока», и даже до «Фэйсбука». Эх! Это было известно ещё до интернета и, возможно, до появления автоматической коробки передач. Это было известно до того, как твои родители появились на свет. Ты мануал-то читал?
— Нет.
— Оно и видно.
Признайтесь, люди не читают мануалов. Давайте посмотрим, что Вам можно посоветовать, чтобы люди от них вообще избавились.
Взламываем ТВ-приставку, чтобы получить плацдарм для хакерских атак
Под катом вас ждет профессиональный экскурс в безопасность низкоуровневого ПО от одного из наших сотрудников. Вы узнаете, как получить доступ к Nand-памяти без программатора, обмануть загрузчик нулевого уровня и превратить Android-приставку в зомби за десять секунд.
Закон дырявых абстракций
Текст, который установил «закон дырявых абстракций», был написан в 2002 году. Почему я перевожу его спустя почти 20 лет? Он до сих пор не потерял своей актуальности и достоин прочтения. Протокол TCP не получил лучшую альтернативу, а закон дырявых абстракций лишь укрепился в жизни разработчиков и рискует стать аксиомой. Добавлю, что я не пересчитывал все указанные в тексте временные рамки, так что учитывайте некоторый «сдвиг во времени».
Безумие и успех кода Oracle Database
Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.
За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.
Разработка ПО: факты против мифов
Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.
То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования. Программной инженерии чуть больше полувека. Если сравнивать с материальным производством, то необходимо констатировать, что разработка ПО пребывает еще в первобытном состоянии.
За короткую историю в отрасли сложилось большое количество мифов, суеверий и религиозных заблуждения. Эти мифы, суеверия и заблуждения, порой очень похожи на правду. Они получили широкое распространение и пагубно влияют на руководителей, которые никогда сами профессионально не разрабатывали ПО. Следствием этого является применение неадекватных методов и подходов в управлении программистами, что гарантированно приводит проект к провалу.
Вот наиболее распространенные мифы и факты, которые их опровергают.
Полностью электрический ускоритель космических кораблей
Дамы и Господа, в этой статье я представлю вашему вниманию революционный безтопливный ускоритель, не имеющий аналогов в мире, который ничего не выбрасывает (требуется только электричество). Мой ускоритель в тысячи раз эффективней обычных ракетных двигателей, он просто перевернёт всю мировую космонавтику и позволит колонизировать всю Солнечную систему за 50-100 Лет. 3 недели до Марса, 7 месяцев до Юпитера и 11 месяцев до Сатурна — такого даже в научной фантастике нет — но сегодня это станет реальностью.
Как и все безтопливные ускорители — мой ускоритель может работать только в вакууме, но главное преимущество моего ускорителя перед другими безтопливными двигателями заключается в том — что другие ускорители не работают, а мой работает!!! — мой ускоритель никаким законам физики не противоречит. Мой ускоритель противоречит лишь животным инстинктам — человек так устроен, что в процессе жизнедеятельности, человеку постоянно необходимо гадить — и поэтому Людям кажется, что если не нагадить в космосе — то ракета не полетит — но это в корне не верно! Хватит обезьяних технологий!!! Реактивный … струя, импульс, формула Циолковского — сегодня вы забудете про эту гадость как про плохой сон.
Для начала давайте отправимся на Луну со второй космической скоростью.
Итак, чтобы отправиться с орбиты Земли на Луну, нам понадобится:
Откровения трезвого инженера
Ответ на: Откровения пьяного старшего инженера
… Я выскажу свое мнение и значительно короче, наверное.
- Работа в нашей отрасли полностью построена на порочных стимулах.
- Лучший способ продвинуться по карьерной лестнице — это смена компании. Компании, в которых вы работаете, будут вознаграждать хорошую работу большей работой и ответственностью, а не большим количеством времени и/или денег. Компании, в которые вы переходите, вознаградят вашу предыдущую хорошую работу в других компаниях большими деньгами. На самом деле это не имеет смысла… См. Пункт №1.
- Каждый раз, когда я меняю работу, я сокращаю свои обязанности на 50% и увеличиваю зарплату на 50%. На моей первой работе я был очень раздражен, когда новые сотрудники, которые были на моем уровне квалификации, зарабатывали больше, чем я. Теперь другие старожилы в моей компании с таким же уровнем квалификации раздражаются, когда я зарабатываю намного больше, чем они (обратите внимание, что количество смен работы >= 3). На самом деле это не имеет смысла… См. Пункт №1.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность