На написание данной статьи меня вдохновила статья об анализе Сишного printf. Однако, там был пропущен момент о том, какой путь проходят данные после того, как они попадают в терминальное устройство. В данной статье я хочу исправить этот недочет и проанализировать путь данных в терминале. Также мы разберемся, чем отличается Terminal от Shell, что такое Pseudoterminal, как работают эмуляторы терминалов и многое другое.

Методик повышения личной эффективности хоть пруд пруди. Как по мне, основная проблема с ними в том, что нужно работать самому. Совершенно нормальное стремление — избежать приложения усилий. Пускай хорошая методика и есть тот рычаг, коим обещают сдвинуть Землю, но физика знает, что всю-всю работу делать всё равно нам самим. Основной вопрос, терзавший меня в вопросе выбора персонального информационного менеджера заключался в том, что он будет делать вместо меня. Задача была не самая лёгкая. За короткий срок разобраться в новой области — организовать конспекты, классифицировать справочники и литературу по теме. Море открытых вкладок браузера (всё очень нужное, оно не должно скрыться из глаз), pdf-файлы, заботливо присланные новыми коллегами… С этим всем в голове я познакомился с программой Obsidian, которая пообещала стать A second brain, for you, forever.

Доброго времени суток, друзья!

Предлагаю вашему вниманию небольшую шпаргалку по основным командам bash, git, npm, yarn, package.json и semver.

Условные обозначения: [dir-name] — означает название директории, | — означает «или».

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

Приношу извинения за возможные ошибки и опечатки. Буду рад любым замечаниям и предложениям.

Без дальнейших предисловий.

Оглавление:

• bash
• git
• npm
• yarn
• package.json
• semver

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Приветствую молодую часть Хабрахабра.

Как вы можете догадаться из названия топика, речь пойдёт об абитуриентах, кто в эти выходные делает выбор — МГУ или ВШЭ, а может между чем-то ещё.

Я успешно отучился 2 (UPD: 4) курса на факультете программной инженерии ВШЭ, давно хотел написать небольшой рекламный пост.
Рекламщик из меня плохой, да и вопросов для обзора придумать самостоятельно не смог.

Зато в эти дни меня часто стали спрашивать примерно так

Привет! Ты с ПИ ВШЭ? Если да, то можешь ответить на несколько вопросов по поводу ПИ (я абитуриент, надо определиться окончательно в ближайшие дни).

И я подумал, почему бы не ответить подробно и не выложить на хабр. Вопросы довольно специфичные и относятся к первым двум курсам.
Предполагается, что вы уже знакомы с НИУ-ВШЭ и, в частности, с факультетом ПИ.
Данная статья была актуальна пару лет назад, сейчас многое изменилось в лучшую сторону, а ещё Яндекс и Высшая школа экономики открывают факультет Computer Science.

Представим, что в компании есть отлаженный процесс регулярного поступления заказов (звонков, заявок). И есть несколько возможных исполнителей, которые могут выполнить эту работу.
Задача усложняется, если исполнитель выполняет работу на территории заказчика. А услуга, которую он оказывает — вполне может быть выполнена без поддержки компании работодателя. Скажем, договорившись за полцены от официальной цены. Знакомо? Сантехники, репетиторы или даже девушки по вызову – все эти бизнесы остаются халтурами низкого уровня, во многом из-за сложности контроля со стороны работодателя. А диспетчеру, выполняющему эту работу, придется стать ангелом, чтобы распределить все заказы и никого не обидеть.

Наша задача — выбрать оптимального исполнителя, среди нескольких возможных.

Я рад приветствовать вас, дорогие читатели.

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

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

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

1. Я прав, а ты нет

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

Безусловно, это мое мнение, основанное на моем опыте, и оно — не догма, но пока он (опыт) меня не подводил.

Этот пост адресован прежде всего «HR-щикам», но и всем остальным, думаю, тоже будет интересен.

Главный постулат:

HR-менеджер не должен собеседовать инженера. Он даже не должен к нему приближаться. Вообще.

Под катом я объясню почему.