Некоторое время назад на Хабре вышла статья замечательной девушки fur_habr о проблемах безопасности, приватности и конфиденциальности мобильных коммуникаций и о путях решения этих проблем на платформе Android.

В момент выхода этой статьи я как-то не обратил на неё внимания — тема смартфонов и Андроида мне вообще не очень интересна. Потом, уже через несколько месяцев, я вновь случайно наткнулся на эту статью, вчитался, и проникся идеями, содержащимися в ней. Действительно, почему бы не стать хозяином своему собственному смартфону?

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

По сообщениям в комментариях к статье про блокнот, во всех версиях Microsoft Excel, начиная по крайней мере с '97 и до самых новых, в имени листа не всегда можно ввести большую букву Ж. Данная проблема обсуждается в сети уже давно, например на этом форуме забавно наблюдать, как некоторые утверждают, что у них проблемы нет, а у других есть, но не всегда, и никто не понимает, почему так. На первый взгляд можно подумать, что это просто недоработка программистов: они хотели не дать пользователю ввести символ ':', и просто не подумали о том, что Ж находится на той же кнопке.

На деле оказалось всё гораздо хуже. Описать нормальными словами то, что происходит в excel, когда вы просто нажимаете кнопку 'Ж', практически невозможно. Поэтому я попытаюсь обрисовать в целом процесс исследования, сократив его где возможно, и не слишком перегружая статью ассемблерным кодом. В итоге мы узнаем, почему получается так, что не любые символы можно ввести, и как это можно исправить.

Меня зовут Андрей Артемьев, я работаю в Microsoft над ядром ОС Windows 10, ранее я работал над Windows 10x (WCOS), XBox, Windows Phone и Microsoft Edge. Я хочу популярно в образовательных целях рассказать о том как работает компьютер на примере клавиатурного ввода и Windows 10. Данный цикл статей рассчитан в первую очередь на студентов технических специальностей. Мы рассмотрим какой путь проходит информация о нажатой клавише от клавиатуры до отображения в Notepad.exe. В виду обширности и междисциплинарности темы в статьях могут быть неточности, о которых сообщайте в комментариях. Какая-то информация может быть устаревшей в виду скорости с которой развивается Windows.

В далеком 2009-м на Хабре уже возникал холиварный шуточный пост с вопросом "Умирает ли Delphi?", а неким энтузиастом (Jamie Ingilby) в поддержку были созданы 2 сайта, которые утвердительно отвечали «Нет, язык Delphi жив».

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

_{Команда Хабра почти в полном составе}

Мы можем только догадываться, как всё выглядело снаружи, но изнутри Хабра 2019-й показался чертовски насыщенным. Мы по чуть-чуть меняли подход то тут, то там, и все вместе эти мелочи сделали проект более открытым и дружелюбным. Мы «раскрутили гайки» — теперь на Хабр можно репостить из личных блогов, а за посты голосовать дольше; новых авторов встречает специальная страница, заряженная на успех; мы постоянно улучшаем мобильную версию и потихоньку готовимся к релизу PWA. В начале года мы запустили англоязычную версию, и 12 месяцев спустя на нее заходят уже 400 тысяч человек ежемесячно. А в конце года мы сделали ребрендинг и теперь наши проекты-сателлиты по-настоящему стали частью Хабра и доступны по говорящим адресам career.habr.com, freelance.habr.com и qna.habr.com. Заодно в декабре немного видоизменили и навигацию, подчеркнув, что тут есть не только потоки о разработке и администрировании, но и сравнимый по масштабу раздел с научно-популярными статьями, а еще потоки о дизайне, менеджменте и маркетинге. Но что бы мы там ни меняли, главное осталось на месте — во главе угла стоит контент, которые создают участники сообщества. Об этом сейчас расскажем подробнее.

Я всегда думал, что я – тупой. Точнее, что я — тугодум.

Проявлялось это просто: на совещаниях и обсуждениях я не мог быстро придумывать решение задачи. Все чего-то говорят, иногда умное, а я – сижу и молчу. Даже как-то неудобно было.

Все остальные тоже думали, что я тупой. Поэтому меня перестали звать на совещания. Звали тех, кто что-то говорит без промедления.

А я, выйдя с совещания, продолжал думать над задачей. И, как говорит устойчивое идиоматическое выражение, хорошая мысля приходит опосля. Находил нормальное, иногда интересное, а бывало – что и офигенное решение. Но оно уже никому не было нужно. Типа после драки кулаками не машут.

Просто культура в тех компаниях, где я начинал работать, была модерновая. Ну, как там это бывает – «совещание должно закончиться принятием решения». Вот чего придумали на совещании, то и принимается. Даже если решение — полная фигня.

Приветствую всех Хаброжителей!

Это мой первый пост, так что, возможно он будет несколько сумбурным – прошу не очень строго судить, но конструктивным замечаниям буду рад. Картинок не будет.

Если мой пост что называется «зайдёт», я планирую осветить ещё некоторые интересные, на мой взгляд, темы, связанные с медициной, фармацией и здоровьем.

Пишу простым языком, с минимумом медицинской и фармацевтической терминологии.

Предисловие

Всем привет! Меня зовут Саша, и я больше шести лет занимаюсь тестированием бэкенда (сервисы Linux и API). Мысль о статье у меня появилась после очередной просьбы знакомого тестировщика подсказать ему, что можно почитать по командам Linux перед собеседованием. Обычно от кандидата на позицию QA инженера требуют знание основных команд (если, конечно, подразумевается работа с Linux), но как понять, про какие команды стоит почитать во время подготовки к собеседованию, если опыта работы с Linux мало или вовсе нет?

Поэтому, хоть про это уже и много раз написано, я всё же решился написать ещё одну статью «Linux для новичков» и перечислить здесь базовые команды, которые нужно знать перед любым собеседованием в отдел (или компанию), где используют Linux. Я подумал, какие команды и утилиты и с какими параметрами я использую чаще всего, собрал фидбек от коллег, и скомпоновал это всё в одну статью. Статья условно делится на 3 части: сначала краткая информация об основах ввода-вывода в терминале Linux, затем обзор самых базовых команд, а в третьей части описывается решение типовых задач в Linux.

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

Хочется проснуться в понедельник без будильника и отправиться на прогулку в красивые калифорнийские горы. Посидеть на пляже, глядя на людей и вдыхая солёный воздух.

Шесть лет назад в один такой воскресный вечер я понял, что сил больше не осталось. Работа довела до полного изнеможения. По какой-то причине я был совершенно измотан. Хотя не напрягался физически, но зубы отчего-то сжимались до боли.

Я включил компьютер и сделал что-то невероятное для себя. Попросил помощи. Зашёл на HN и запустил новый тред. Я не знал, что и как сказать, но пальцы сами стучали, пока проблема не вылилась на страницу. Вот что я тогда написал: «Нас могут уволить, и я не знаю, что делать» (тред в разделе 'Ask HN', 114 комментариев).

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

Значения null, при бездумном их использовании, могут сделать вашу жизнь невыносимой и вы, возможно, даже не понимаете, что именно в них причиняет такую боль. Позвольте мне объяснить.

Автор: Антон Реймер
В первой части статьи, основанной моем вебинаре, мы рассмотрели общие принципы работы браузера. Во второй — я сконцентрировал внимание на важных событиях: repaints и reflows — и на принципах работы event loop.

Repaints and reflows

При загрузке страницы, если она не пустая, всегда выполняется, как минимум, по одному reflow и repaint. Далее эти события возникают в следующих случаях:

1. Часть дерева отображения нуждается в перерасчете, т. е. у какого-то узла изменились ширина, высота или координаты. Вызывается событие reflow.

2. В результате изменений часть отображаемого контента должна обновиться. Речь идет, в первую очередь, о свойствах стилей: цвет фона, радиус и т. д. Вызывается событие repaint.

Если вызывается reflow, после него обязательно вызовется и repaint. Но обратное неверно: repaint может вызываться независимо от reflow.

Какие действия вызывают reflow и/или repaint

Менее чем за неделю один твит Дэвида Синклера собрал 1 500 ретвитов, 5 200 лайков, что для его твиттера довольно много. Кто такой Дэвид Синклер? Это сейчас самый хайповый чувак в продлении жизни, профессор Гарварда, автор более 50 публикаций, опубликованных в рецензируемых журналах, в том числе в Nature, Cell и Science, организатор Национальной Академии Здоровья и Продолжительности Жизни, учредитель множество компаний, участник подкастов у Рогана и других шоу. Привлек уже как минимум 50 миллионов долларов. Дэвид недавно написал книгу “Продолжительность жизни”.


А еще он сооснователь Life Bioscience. Это такая семья компаний, нацеленных на продление жизни. Те, кто анализирует биотех компании, сразу обратят внимание на то, что на сайте этой компании нет раздела Pipeline — раздела, посвященному клиническим исследованиям. И нет раздела Science — где были б статьи. Не то, чтобы это прям совсем плохо, но просто отмечаем такую деталь. Правда, есть на этом сайте и хорошее: в фокусе компании обозначены несколько важных направлений — митохондрии, эпигенетика, воспаление и прочее. И дизайн симпатичный.


Дэвид Синклер.

А в твите он дал совет, как всем жить:

Я расскажу о том, как изучать иностранный язык и буду это делать на примере личного опыта изучения английского языка. Английский я начал учить в 36 лет, а уже сейчас у меня свободный английский язык (как письменный, так и устный), подтверждённый официальными сертификатами. Чтобы не быть голословным: у меня есть сертификат IELTS 7.5 баллов (это С1 level) и сертификат переводчика NAATI. Короче, я знаю о чем говорю.

Оглавление:

1. Отступление про умных людей и прочих полиглотов
2. Первый шаг
3. Какой преподаватель нужен (уровень преподавателя)
4. Где искать преподавателя
5. Развитие навыков: слушание
6. Развитие навыков: чтение
7. Развитие навыков: письмо
8. Развитие навыков: разговор: произношение
9. Развитие навыков: разговор: языковой барьер
10. Словарный запас
11. Самое главное

Итак, вопрос: “Как выучить английский язык?”.

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

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

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

Что такое технический долг? Можно ли понимать его, как плохое исполнение разработчиками своих обязанностей? Возможно ли избежать появления технического долга, и следует ли его избегать? Как связан технический долг с архитектурой приложения и с доверием между заказчиком и исполнителем? Какие стратегии применяются для контроля технического долга?

Предлагаю вашему вниманию перевод интервью, вышедшего в подкасте «Software Enginering Radio» в апреле 2015 года. Свен Йохан и Эберхард Вольф обсуждают внутреннее и внешнее качество ПО, вспоминают общепринятые модели качества и стратегии, направленные на поддержание внутреннего качества ПО. Технический долг, в основном, рассматривается в контексте управления программными проектами.

Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.

Сравниваем особенности микросервисной и монолитной архитектуры, их преимущества и недостатки. Статья подготовлена для Хабра по материалам нашего митапа Hot Backend, который прошел в Самаре 9 февраля 2019 года. Мы рассматриваем факторы выбора архитектуры в зависимости от конкретной задачи.

Программные системы склонны к накоплению мусора — внутренних недоработок, которые затрудняют дальнейшее изменение и расширение системы по сравнению с идеальным кодом. Технический долг — это метафора, придуманная Уордом Каннингемом. Она объясняет, как воспринимать этот мусор, по аналогии с финансовым кредитом. Дополнительные усилия, необходимые для добавления новых функций, — это проценты по кредиту.