Привет, человек, %хабраюзер%, %юзернейм%, программист.

Этот пост является оплотом ненависти. Так уж вышло. Но тебе, как программисту пора перестать оправдываться.

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

Но. Я рассматривала только эти варианты: мне присылают тестовое, и я решу его выполнить - или решу не выполнить.

Заблуждение 1. Форма Земли — это просто

Есть вещи, которые не нравятся, есть вещи, которые бесят, есть вызывающие жгучий гнев, и есть ситуация с NULL в SQL.

Давайте немножко похоливарим по этому поводу.

Введение

Многие, если не все, кому приходится подключаться по ssh к серверам начинают использовать ssh aliases(конфиг файлы), когда этих серверов становится больше одного. А если их больше двух наступает время автоматизации. Так появился sshto.

Приглашаю вас в небольшое приключение выходного дня, в котором никто никому ничего не будет доказывать. Мы просто будем реализовывать один и тот же несложный алгоритм, разыскивающий простые числа в некотором диапазоне, на нескольких языках программирования: C, C++, Scheme и Python - и смотреть, что этим кодом могут сделать современные оптимизирующие компиляторы. В процессе приключения мы увидим, что «динамический» не означает «совсем уж медленный», и посмотрим на приёмы программирования на Scheme, что, как мне кажется, можно сравнить с путешествием на экзотический остров.

Нет, это не ругательное слово (для тех, кто не в курсе). Транскрибация это перевод голоса в текст.

На протяжении нескольких лет я подрабатывал этим делом. Титры для видео (использовал subtitle editor), интервью, доклады, проповеди и т. п. По заказам речь переводил в текст.

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

Тем не менее существенно облегчить труд может творческое отношение к процессу.

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

При записи текста обычно требуется указывать этот самый тайминг.

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

Это существенно помогает ориентироваться в тексте и в аудио записи.

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

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

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

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

...или о fork() в двух словах.

Как люди решают задачи

Обычно у каждой задачи есть одно простое решение, которое воспринимается всеми как правильное. Люди воспринимают такое решение правильным либо исходя из личного опыта¹; исходя из опыта других людей² или просто не задумываясь о правильности³. И самое удивительное, что мир не взорвался, никто (массово) от этого не умер, код работает и приносит деньги.

¹ "всегда так пишу код, никто не умер"
² "копирую код из stack overflow который набрал больше всех плюсов"
³ "копирую первый попавшийся код из stack overflow"

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

Однако мы отвлеклись. Поставим перед собой задачу:

Нам необходимо наиболее правильным способом запустить из своего кода другую программу.

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

Содержание статьи

* Как кушать пингвина вилкой?
Общие знания о запуске процессов под LINUX-системами
* Как кушать корову если есть вилка?
Copy-on-write, что это и зачем? vfork и почему он не лучше
* Как кушать икру?
posix_spawn и почему он не замещает fork()
* Как кушают клоны?
clone() под капотом у fork()
* Почему когда ешь суп вилкой он утекает?
Утечка дескрипторов после fork() и как этого избежать
* Почему у вилки три зуба?
Важность обработки всех вариантов возврата fork()
* Как кушать демонов вилкой?
Запуск демонизирующихся процессов при помощи fork()
* Как наложить вилкой в другую тарелку?
Переназначение дескрипторов вывода для нового процесса
* Как сигналить вилке?
Взаимоотношения обработки сигналов и fork()
* Как пользоваться вилкой когда сломалась ручка?
Самоликвидация дочернего процесса после завершения материнского
* Как подготовиться к использованию вилки?
Сценарии использования pthread_atfork()
* Как поцарапать окно вилкой?
Запуск дочернего процесса под Windows-системой
* Как систематически пользоваться вилкой?
Почему вам не стоит пользоваться system()
* Заключение
Благодарности и выводы

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

Потом что-то пошло не так, начали появляться какие-то полутехнические статьи, и (далее моя интерпретация событий) чтобы сохранить Хабр, всех нетехнических писателей заманили в один корабль и отправили куда подальше на гиктаймс - подобно тому, как врач ампутирует руку пациенту, чтобы спасти жизнь. В данном случае, правда, врач подержал эту руку, посмотрел на неё, а потом пришил обратно. Что из этого вышло?

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

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

Пирамида аргументации Грэма, описанная им в эссе «Искусство возражать» — хороший инструмент, помогающий вырваться из этого порочного круга. Она четко структурирует возможные варианты критических комментариев – и связывает их с истинными намерениями оппонента. Теперь вы всегда можете идентифицировать "ступень" и понять: стоит ли критика вашего внимания — или это грязь под ногами, которую просто надо перешагнуть.

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

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

Всем фанатам светодиодов дальше лучше не читать.