Аристотель придумал, что в риторике есть четыре главных способа убеждения. Пафос — через эмоции и повествование. Логос — через факты и логику. Этос — через авторитет того, что убеждает. Есть еще кайрос, фактор контекста: того, когда вас пытаются убедить и при каких условиях.

Познакомился я с ними, когда работал академконсультантом в США: помогал получать высшее образование так, чтобы иметь хорошие оценки и не тратить слишком много денег. В колледжах США риторику изучают все гуманитарии на первом курсе, иногда даже технари. И так как всю риторику сводили именно к способам убеждения, мои клиенты из Ближнего Востока и Китая часто этим возмущались. И спрашивали меня, какой скрытый смысл в том, чтобы изучать такие очевидные вещи.

Что же, ответ у меня есть. Я считаю, что этос — это бич мыслящего человека. Кайрос — кандалы, который выковал информационный век. А понимание того, как работает риторика — базовый инструмент критического мышления. Особенно для IT-специалиста.

Я так много рассказывал об этом на кухнях и в чатах, что решил написать статью. А получился лонгрид с научными исследованиями, разбором влияния алгоритмических новостных лент, и безумным комиксом из мемов, который я делал 4 часа в Фигме. Поехали!

UPD Большое спасибо всем тем людям, что помогли мне исправить ошибки и очепятки! Только на Хабре так стремятся помочь, и это неоценимо.

Disclaimer: Статья Мартина Фаулера была опубликована в 2003 году

в журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).

Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.

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

Кто самый легкий?
(иллюстрация из журнала «Веселые картинки», 1983, №4)

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

Применение погремушек и сосок оказалось делом более-менее простым, но вот с «развивающими играми» все показалось намного интереснее. Можно ли на самом деле усиливать развитие мыслительных способностей у ребенка, и как это делать?

Чтобы ответить на этот вопрос, я оставила карьеру ученого и пошла работать педагогом дополнительного образования. То, что вы прочитаете дальше – результат, пардон, опытов над детьми (не волнуйтесь, ни один подопытный ребенок не пострадал).

Когда printf — мало, а ncurses — много


Когда данных становится слишком много, бывает не хватает стандартного вывода printf в консольной программе. Особенно если различных событий много и различные данные превращаются в безумный листинг. Эти данные могут поступать от контроллера через UART, и тут нечего и думать о какой-то gui-программе. Может так же быть и обычный bash-скрипт, к которому хочется прикрутить какой-никакой псевдографический интерфейс.

Про предмет статьи ходит много домыслов — от «русский Барроуз» до «не имеющий аналогов». Вызвано это в немалой степени отсутствием (доступной) полноценной документации, немногочисленным кругом лиц, имевших с ними дело да и немалым временем, прошедшим с тех пор. «Эльбрус» превратился в один из мифов ушедшей эпохи.

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

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

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Это заметка о любви. О любви статического анализатора кода PVS-Studio к замечательной открытой операционной системе Linux. Эта любовь молода, трогательная и ранима. Этой любви нужно помочь укрепиться. Вы поможете, если заранее запишитесь в добровольцы для тестирования beta-версии PVS-Studio for Linux.

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

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

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

Я написал свои первые несколько строчек кода почти 32 года назад, когда мне было 6. Я развил очень сильные инстинкты программирования и мог смотреть на любую проблему, сразу зная, как ее решить — просто интуитивно.

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

Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться. Далее Bill Sourour поделится с нами информацией о том, как не останавливаться на достигнутом. Кому-то эти рассуждения, безусловно, покажутся очевидными. Ну, а кому-то — пригодятся.

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

Спустя несколько десятилетий «воплей», Национальная метеорологическая служба США недавно сообщила о том, что больше не будет публиковать свои прогнозы и метеопредупреждения только прописными буквами. С 11 мая все ее сообщения публикуются смешанным регистром.

Сейчас Пол Грэм учит правительства и университеты как создавать стартап-хабы, а а вот раньше… он провел замечательную аналогию между высококлассными программистами и художниками.

За 13 лет глава, одноименная с названием книги, затерялась в сети. Для удобства, хочу опубликовать ее, собранную по кусочкам из различных архивов.

Перевод Анастасии Грызуновой, Яны Щекотовой. Приведение текста в порядок — CaptainCrocus.

Оригинал — Hackers and Painters (May 2003)


Закончив аспирантуру по computer science, я пошел на художественный факультет изучать живопись. Многие удивились, что компьютерщик вдруг заинтересовался живописью. Эти люди, видимо, считали, что хакерство и художество — очень разные занятия: хакерство — холодное, точное и методичное, а художество — яростное выражение некого первобытного порыва.

Оба представления неверны. У хакерства и художества масса общего. Из множества различных типов людей хакеры и художники — едва ли не самые похожие.

«Чтение и личный опыт формируют мировоззрение. И даже если вы не помните самый момент получения опыта или содержания книги, то их влияние на ваше представление о мире непременно остается в Вас. Ваш разум похож на скомпилированную программу без исходного кода — он работает, но не ясно как.»
— Пол Грэм, основатель Y Combinator, программист, инвестор, эссеист


«Взятие Константинополя крестоносцами» (Эжен Делакруа, 1840)

Оригинал — How You Know
December 2014

За перевод спасибо lxsmkv, за ценные уточнения — knagaev.

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

Парой месяцев ранее я читал замечательную биографию Гильберта, написанную Констанцией Рид, и нашел в ней, если и не ответ на свой вопрос, то как минимум что-то, что сгладило бы это неприятное ощущение. В своей книге она пишет:

Гильберт не терпел лекций по математике, на которых студентов пичкали фактами, вместо того чтобы учить их формулировать и решать задачи. Он часто повторял им: “Хорошая постановка задачи уже половина ее решения.”

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

Однако, как я пришел к этому убеждению? Оно родилось из моего личного опыта и прочитанных книг. Ни одной из которых я не запомнил. И, возможно, мне бы даже не вспомнились слова Гильберта. Но найденные в книгах мысли подкрепили мои мысли и убеждения, несмотря на то, что я не помню их содержания.

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

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

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

Я видел много технических стартапов, которые теряли из виду, что, как и зачем они делают, и скатывались к 100-процентному фокусированию на добыче денег, необходимых исключительно на поддержание текущего состояния дел. Такое встречается очень часто. Подумайте о всех этих благотворительных фондах, которые начинали с чёткой цели (условно говоря, "спасти кота"), но спустя несколько лет вперёд оказывается, что большинство их усилий — если не все — направлены лишь на то, чтобы найти денег на то, чтобы выплатить всем зарплату и продолжать "благотворительность".

КДПВ

От переводчика:
Большинство моих знакомых для измерения времени в разного вида бенчмарках в С++ используют chrono или, в особо запущенных случаях, ctime. Но для бенчмаркинга гораздо полезнее замерять процессорное время. Недавно я наткнулся на статью о кроссплатформенном замере процессорного времени и решил поделиться ею тут, возможно несколько увеличив качество местных бенчмарков.

P.S. Когда в статье написано "сегодня" или "сейчас", имеется ввиду "на момент выхода статьи", то есть, если я не ошибаюсь, март 2012. Ни я, ни автор не гарантируем, что это до сих пор так.
P.P.S. На момент публикации оригинал недоступен, но хранится в кэше Яндекса

Функции API, позволяющие получить процессорное время, использованное процессом, отличаются в разных операционных системах: Windows, Linux, OSX, BSD, Solaris, а также прочих UNIX-подобных ОС. Эта статья предоставляет кросс-платформенную функцию, получающую процессорное время процесса и объясняет, какие функции поддерживает каждая ОС.

Последние несколько лет отмечены ростом популярности «контейнерных» решений для ОС Linux. О том, как и для каких целей можно использовать контейнеры, сегодня много говорят и пишут. А вот механизмам, лежащим в основе контейнеризации, уделяется гораздо меньше внимания.

Все инструменты контейнеризации — будь то Docker, LXC или systemd-nspawn,— основываются на двух подсистемах ядра Linux: namespaces и cgroups. Механизм namespaces (пространств имён) мы хотели бы подробно рассмотреть в этой статье.

Начнём несколько издалека. Идеи, лежащие в основе механизма пространств имён, не новы. Ещё в 1979 году в UNIX был добавлен системный вызов chroot() — как раз с целью обеспечить изоляцию и предоставить разработчикам отдельную от основной системы площадку для тестирования. Нелишним будет вспомнить, как он работает. Затем мы рассмотрим особенности функционирования механизма пространств имён в современных Linux-системах.

«Она истинный морпех, но если копнуть глубже, мы найдем пирата.»



Грейс Хоппер (Grace Hopper) — американская учёная и контр-адмирал флота США. Программист гарвардского компьютера Марк I.

• В детстве разобрала 7 будильников, чтобы понять, как все устроено.
• Боролась за идею машинонезависимого языка программирования.
• Разработала первый компилятор.
• Приложила руку к распространению мема «дебаггинг» (выловив настоящего жука из Mark 2).
• Могла объяснить сообразительным военным, что такое «наносекунда» и «пикосекунда». На пальцах.
• В её честь назвали эсминец USS Hopper (DDG-70).
• И суперкомпьютер Cray XE6 «Hopper».
• И в ее честь именная премия Ассоциации вычислительной техники (ACM) — присуждается молодому (до 35 лет) специалисту, сделавшему значительный вклад в области вычислительной техники.

Построив успешную карьеру математика в Йеле (защитив докторскую и став профессором), Грэйс Хоппер в 1943 (37 лет) пошла добровольцем во Флот.
Но у нее был недобор по весу 6 кг, поэтому пришлось сесть «за клавиатуру» Гарвардского Mark 1.

Представляю вашему вниманию перевод статьи Джеффа Атвуда о тестировании новых компьютеров. Я не видел ни одной статьи подобного качества на эту тему; в статье приведена вся необходимая информация и ничего лишнего, а так же хорошо структурирован материал. Надеюсь, и вам она придётся по нраву.

Джефф — основатель StackOverflow. Ныне он работает над проектом Discourse.

Оригинальная статья: Is Your Computer Stable?

Дисклеймер: Хоть статья и называется "Надёжен ли твой компьютер?", речь идет не о надёжности как термине(англ. reliability), а, скорее, о стабильности (англ. stability). Статья о том, как автор тестирует новые компьютеры на стабильность и прочность.


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

Например, вот что может понадобится для сборки Scooter Computer:

1. Нанести немного термопасты на верхнюю часть корпуса.
2. Поместить в корпус материнскую плату.
3. Прикрутить материнскую плату к корпусу.
4. Вставить плату SSD.
5. Вставить плату RAM.
6. Подключить внешнее питание.
7. Загрузиться.

Вот и все.



Это до смешного просто. Мы с моим шестилетним сыном собирали конструкторы Лего, которые были намного сложнее. Сборка традиционных ПК отличается всего парой дополнительных шагов: вставить процессор, радиатор, подключить кабели. И, наконец, сборка сервера добавляет еще пару незначительных действий, возможно, с ограничениями на размер сборки. Мини-компьютер, обычный ПК или сервер — если вы смогли собрать один из них — считайте вы собрали их все.

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

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



Осторожно: много букв и картинок!

Как бы не было много сторонников старых версий ОС, все же пришла пора переходить на Windows 10. В связи с этим предлагаю разобраться с предустановлеными Metro-приложениями. Согласитесь, мало кто будет использовать абсолютно все приложения, которые навязывает нам корпорация. Ведь большинство из них просто занимают место, а кого-то вообще раздражают. В этой статье я поделюсь с вами способом, которым можно «почистить» систему от именно таких — ненужных — приложений на Windows 10.

Все знают историю Эдварда Сноудена и секретного проекта PRISM по массовой слежке со стороны АНБ, о котором Сноуден рассказал миру. Если верить математику из Оксфордского университета, то это была не случайность, а закономерность. Согласно теории вероятности, чем больше людей вовлечено в заговор, тем быстрее кто-нибудь проболтается. Д-р Дэвид Роберт Граймс (David Robert Grimes) рассчитал в точности, сколько времени в среднем продержится заговор в секрете, в зависимости от количество вовлечённых людей.

Расчёты д-ра Граймса опубликованы 26 января в журнале PLOS ONE.

Ключевой параметр в формуле — вероятность того, что конкретный участник заговора станет причиной утечки информации. Для вычисления этого параметра учёный использовал известные параметры трёх уже раскрытых заговоров: упомянутого проекта PRISM (30 000 участников заговора, срок раскрытия 6 лет), исследовании сифилиса в Таскиги (6700 человек, 25 лет), а также некорректных научных методов, применявшихся в ФБР (500 человек, 6 лет).