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

В этом посте я опишу простой способ, который:

• не требует программирования — только unix-way сборка системы из маленьких кирпичиков
• не отжирает много ресурсов (не нужно зря поллить файл, а сама программа весит значительно меньше шелла)
• срабатывает моментально

Добрый вечер, хабровчане!

Начну с того, что работаю я в непростой школе простым лаборантом. На мне висит много всяких обязанностей, одной из которых является пополнение школьного сайта и ресурса oshkole.ru контентом.
Часто приходится выкладывать на этот ресурс фотографии. Но так как написан он о-очень криво (к слову, ведение там странички школы обязательно и контролируется прокуратурой), фотографии конечному пользователю подгружаются в полном размере. Вот и приходится ресайзить по ~30 штук в неделю.

Так как я любительница unix-way, быстро пришла идея написать bash скрипт.

Была поставлена цель: легко и непринужденно изменять размер всех изображений в директории. Задача достаточно тривиальная, скриптик был набросан за 5 минут, и… Тут меня осенило: я ведь так давно хотела написать статью на хабр, только было неочем. И вот я здесь =)

Всем, кому еще не стало скучно, добро пожаловать под кат.

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

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

Есть ряд книг, которые, на мой взгляд, являются своеобразными «библиями» для тех, кто решил связать свое будущее с разработкой ПО. С одной из них я хотел бы начать цикл статей. Это книга Эрика Рейнмонда, «Искусство программирования под Unix». Я бы рекомендовал эту книгу не только тем, кто выбрал для себя открытые операционные системы. В основе лежит довольно универсальная философия, пригодная абсолютно всем, связавшим свою профессию с программированием.

Эрик Реймонд выделяет 17 правил этой «философии». Я буду посвящать по одной заметке на каждое правило. Я постараюсь изложить эти концепции в максимально понятной, упрощенной и популярной форме, насколько это будет возможно.

Начнем с самого первого правила — Правила модульности. Оно звучит так: «Простые блоки связывайте друг с другом ясными и понятными интерфейсами» (Rule of Modularity: Write simple parts connected by clean interfaces).

Как при подготовке документов избежать медлительных офисных пакетов, пользоваться любимым текстовым редактором, отделить содержание от представления, обеспечить высокую читаемость и прозрачность документов для VCS, легко сравнивать версии текстов?

Постить скриншоты довольно заморочно если всё делать руками. Но возможен и более лёгкий сценарий:
1) жму Alt+Ctrl+S
2) появляется редактор с готовым скриншотом
3) обрезаю картинку, закрываю редактор
4) картинка сама загружается; ссылка на картинку оказывается в буфере обмена

Как это сделать — для тех кто знает что такое bat-файлы и сумеет установить пару Python-модулей.

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

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

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

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

Ну начнем с того, что довольно часто приходится сталкиваться с тем, что необходимо реализовывать какую-либо серверную часть для обработки каких-то данных и т.д. Естественно, что сервеную часть удобней всего было бы реализовать в виде демона. В свое время я наткнулся на подобный класс реализации демонов написанного на Python. И вот на прошлой неделе решил написать такое же творение на PHP, вроде получилось не плохо, оценивать Вам.

Мне, как и многим из вас, работать с bash и стандартными утилитами Linux гораздо удобнее и приятнее, чем с cmd.exe. Однако, к сожалению, порой обстоятельства складываются так, что операционную систему выбирать не приходится. Например, в моём случае корпоративным стандартом является Windows 7. К счастью есть способ сделать жизнь линуксоида в командной строке Windows комфортнее, о нём и пойдет речь ниже.

«Качество появляется только тогда, когда кто-нибудь несёт ответственность лично».
— Фредерик Ф. Брукс



Привет, хабр!

Предлагаю вашему вниманию вольный перевод эссе "A Generation Lost in the Bazaar" Пола-Хеннинга Кампа, повествующего нам о печальной судьбе поколения IT-профессионалов, выросших в период бума доткомов, а также о фундаментальных проблемах в UNIX, напрямую влияющих на качество и портабельность ПО. Обо всём по порядку.

Давным-давно, когда разрабатывалась файловая система Unix, в ней появились «псевдо-файлы» . и .., чтобы упростить перемещение между каталогами. Кажется, .. был добавлен в Версии 2, когда файловая система стала иерархической (в первой версии она была устроена совсем по-другому). Но эти «псевдо-файлы» засоряли вывод ls, и то ли Кен, то ли Деннис добавил в код ls простую проверку:

if (name[0] == '.') continue;

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

if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;

— но какая разница, главное что всё работало.

У этого было два далеко идущих последствия.

Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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

Привет! 28 декабря 2015 года при довольно странных обстоятельствах ушел из жизни Ян Мердок (Ian Murdock) — основатель проекта Debian. Как-то блуждая по Сети и выясняя причины этой весьма загадочной смерти, я наткнулся на блог Яна и пост в нем под названием «How I came to find Linux». Этот текст мне показался очень трогательным и интересным. Так как я не программист и не художник, я решил внести свой небольшой вклад в сообщество, сделав перевод его текста на русский язык. Я постарался, чтобы мой перевод был одновременно и максимально близким к тексту, и, все-таки, литературным, читаемым. Получилось или нет —судить не мне. Сам текст, как мне кажется, несмотря на его небольшой размер и простоту, очень важен. Важен для понимания того времени, той розовой эпохи, плодами которой мы пользуемся до сих пор, будь то iPhone, Android или сайт VK.com (powered by Debian, насколько мне известно). В завершении предисловия я хотел бы дать и практический смысл моему посту. Дело в том, что я так и не смог найти сервис для совместного перевода, который бы отличался простотой и ясностью в главном: в размещении английского оригинала и удобной совместной работы над переводом в идеале с учетом разных вариантов. Вот посмотрел с пяток и нужного не нашел. Так и переводил в google docs с разбивкой на строки-абзацы и две колонки: оригинал/перевод. Если знаете такой: отпишите в комментариях и, да, не судите строго. Приятного чтения!

Как я очутился в Linux

Cвою первую рабочую станцию компании Sun я увидел зимой 1992 года, будучи молодым студентом Университета Пурду. В то время, когда я еще был студентом Краннерсткой школы менеджмента и моя детская любовь к компьютерам была заново пробуждена обязательным курсом программирования, который я изучал во время осеннего семестра (нам дали на выбор языки COBOL и FORTRAN, оба даже в 1992 кажется уже сильно устарели — я выбрал COBOL, поскольку он казался более “рабочим” из этих двух языков).