Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

Если вы когда-либо делали хелп или мануал для своего приложения, наверняка вы отметили, как неожиданно много времени и сил занимает создание скриншотов.

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

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

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

• Как поставить человека на место: 10 реальных вопросов про давление в переговорах
• Управленческие инструменты: 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?»
• Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?
• [кейс] Как вернуть долг от бывших работодателей или про хитрые переговорные стратегии

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

Сегодня мы решили продолжить эту тему и опубликовать главу из новой книги Дмитрия Коткина «Переговорная книга быстрых рецептов».

Как распознавать манипуляции и быстро обезвреживать их

Продолжаем изучать планирование маленьких потоков. Я уже рассказала про два средства в ядре Linux, которые часто используются для отложенной обработки прерываний. Сегодня речь пойдет о совсем другой сущности — protothread Adam Dunkels, которые хоть и выбиваются из ряда, но в контексте рассматриваемой темы совсем не лишние.

А также:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

Продолжаем тему многопоточности в ядре Linux. В прошлый раз я рассказывала про прерывания, их обработку и tasklet’ы, и так как изначально предполагалось, что это будет одна статья, в своем рассказе о workqueue я буду ссылаться на tasklet’ы, считая, что читатель уже с ними знаком.
Как и в прошлый раз, я постараюсь сделать мой рассказ максимально подробным и детальным.

Статьи цикла:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

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

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

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

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