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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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