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

Во-первых, под впечатлением от книги Непрерывное развертывание ПО я взялся за автоматизацию процесса выкладывания новых версий и за большой рефакторинг системы сборки. Если раньше все сценарии сборки были собраны в одном большом fabfile.py в корне исходников, то теперь из него был выделен пакет buildtools, где по разным модулям разнесены сборки для разных операционных систем и другие вспомогательные скрипты. В группе во Вконтакте меня спрашивали по поводу того, как организована сборка, но тогда она еще находилась в скомканном состоянии, а сейчас ее не стыдно описать в документации, хотя процесс автоматизации выкладывания сборок еще не завершен.

Читать далее…

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

TOP500, вышедший в июне 2016 году интересен сразу несколькими моментами. Новый рейтинг знаменателен тем, что с первого места был свергнут китайский суперкомпьютер Tianhe-2, который держался на вершине рейтинга с весны 2013 года. Теперь лидер TOP500 — китайский же суперкомпьютер Sunway TaihuLight, который обгоняет Tianhe-2 по производительности почти в 3 раза — 93014.6 TFlop/s против 33862.7 TFlop/s у Tianhe-2. Напомню, что Flop/s — это количество операций с плавающей точкой, которое производит компьютер за секунду. На следующей картинке показана фотография нового лидера (почти все картинки в этом посте взяты с сайта top500.org и отчета про суперкомпьютер Sunway TaihuLight.

Читать далее…

Некоторое время назад попались мне две книжки про организацию работы программистов — «Как пасти котов» Дж. Ханка Рейнвотера и «Путь камикадзе» Эдварда Йордона. Эти книги написаны в первую очередь для менеджеров (в хорошем смысле этого слова) или тех, кто руководит группой разработчиков, и хотя мне это пока не особо актуально, я считаю, что такие книги полезно читать, чтобы задуматься об организации личного процесса разработки.

Начнем с книги Дж. Ханка Рейнвотера «Как пасти котов», которая написана в первую очередь для бывших программистов, которых внезапно назначили руководить другими программистами. Название этой книги родилось из сравнения программеров, которые часто являются интровертами-индивидуалистами, с котами, которые гуляют сами по себе, однако руководителю нужно организовать работу этих индивидуумов таким образом, чтобы они сообща все вместе двигались к определенной цели — созданию качественного программного обеспечения.

Автор этой книги рассматривает работу новоиспеченного начальника (или, если угодно, менеджера) с разных сторон, начиная с вопроса «как с этим жить», как привыкнуть к роли лидера и руководить теми людьми, с которыми вы еще вчера за кружкой пива обсуждали код и вели холивары, и заканчивая тем, как научиться понимать вышестоящее руководство.

Читать далее…

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

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

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

Читать далее…

Сейчас начинается сессия — самое время, чтобы поговорить о студентах. В этом посте я буду много ворчать на большую их часть.

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

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

Читать далее…

Сегодня выложил новую нестабильную версию OutWiker и обновления нескольких плагинов. В основном все исправления носят корректирующий характер, а в плагине WebPage (плагин для скачивания страниц из интернета) была добавлена новая возможность для импорта локальных страниц. А теперь обо всем по порядку и с подробностями.

Что касается самого OutWiker, то последние две недели занимался тем, что вылавливал и исправлял глюки, появившиеся после перехода на wxPython 3.0. Большая часть проблем касалась версии под Linux, хотя были и кроссплатформенные проблемы, и проблемы, проявлявшиеся только под Windows. Спасибо тем, кто присылал информацию о замеченных глюках, все эти проблемы я, вроде бы, поборол.

Читать далее…

Написал статью про особенности и трудности скачивания web-страниц с той целью, чтобы ее затем открывать в оффлайне. Идея для этой статьи родилась во время создания плагина WebPage для OutWiker.

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

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

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

Этот пост открывает новую главу развития OutWiker. Сразу после релиза я собирался сосредоточиться на создании новых плагинов, но пришлось срочно корректировать свои планы из-за выхода Ubuntu 16.04 LTS, в котором не оказалось библиотеки wxPython 2.8, которая использовалась в программе, а с wxPython 3.0 OutWiker 1.9 не работает. Обо всех сложностях с библиотеками я писал в прошлом посте OutWiker, Ubuntu и wxPython. Зоопарк версий.

Читать далее…

С этими версиями библиотек под Linux у меня уже идет голова кругом. Похоже, придется отказаться (по крайней мере на некоторое время от PPA на launchpad.net) и компилировать все сборки самому, выкладывая просто deb-пакет. И вот почему.

Изначально OutWiker писался под wxPython 2.8, который был в репозиториях Ubuntu (и не только). Версия 2.8 — уже достаточно старенькая, последняя версия ветки 2.8 вышла аж в 2011 году, и с тех пор на протяжении нескольких лет разработчики этой библиотеки работали над wxPython 3.0, которая вышла в конце 2013 года, но перейти на ее я не мог, поскольку в репозиториях Ubuntu ее долгое время не было. И до сих пор ее нет под Ubuntu 14.04, который является LTS (на момент написания этих строк последней версией LTS), поэтому отказываться от поддержки этой версии я не мог. wxPython 3.0 появился только в Ubuntu 15.04.

Читать далее…