Заканчивается наша двухдневная поездка в Дубну и Кимры. Больше всего поездка запомнилась погодой. Если вчера полдня было сухо, а полдня шел дождь средней интенсивности, то сегодня погоду колбасит. Проливной дождь периодически сменяется ярким солнцем. Был даже момент, когда шёл град при ярком солнце.

Сейчас едем в электричке, в окне слева - синее небо с облаками, а справа - тяжёлая темная туча. За такой погодой, конечно, лучше следить из сухого укромного места, вагон электрички подойдёт :)

https://jenyay.livejournal.com/285458.html

Оригинал записи.



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

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

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




Когда программист отправляет код в репозиторий, сервер CI сначала компилирует программу, и дальнейшие тесты выполняются уже на этой скомпилированной версии (важно, чтобы тестировались именно те бинарные сборки, которые потом попасть на продакшн или пользователям). Первыми запускаются модульные тесты (unit tests), которые должны выполняться быстро, не дольше 5-10 минут, окончания которых должен дождаться программист, отправивший изменения на сервер. Если тесты провалились, то вся команда должна остановить работу или, по крайней мере, не отправлять новые изменения на сервер, пока прохождение модульных тестов не будет исправлено. Если программист, сломавший тесты, за короткий промежуток времени не исправит ошибку, приводящую к провалу теста, то администратор сборки должен иметь право отменить исправление, внесенное этим программистом.

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

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

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

Если программа успешно проходит приемочные тесты и тесты производительности, наступает очередь пользовательских приемочных тестов. Это этап ручной проверки тестировщиками. После прохождения всех тестов, приложение развертывается на тестовом сервере и/или готовится стать релизом для пользователей.

Если строго придерживаться принципов непрерывной интеграции, приложение всегда должно находиться в работоспособном состоянии.

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

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

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

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

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

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

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

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

Автоматизированное развертывание следует использовать всегда; оно должно быть единственной технологией выпуска ПО.

Авторы всячески поддерживают использование виртуализации, чтобы уменьшить различие между тестовыми и рабочими серверами. Поскольку книга была написана в далеком 2011 году, когда еще не было Docker (его первая версия вышла в 2013 году), то понятно, что он не упоминается, а так, мне кажется, что авторы о нем непременно написали что-нибудь хорошее, поскольку он позволяет малой кровью свести к минимуму различия сред выполнения на тестовых серверах и в продакшне.

Любопытно, что отдельные идеи, описанные в этой книге, уже повсеместно применяются (идеи во многом пересекаются с гибкими методологиями разработки), но в "Непрерывном развертывании ПО" авторы их органично объединили в общую идеологию.

Как я уже сказал в начале, на меня эта книга произвела сильное впечатление. Когда я ее читал, постоянно прикидывал, как можно применить описанные в ней идеи к своим проектам и, в частности, к OutWiker, выкладывание новой версии которого сейчас занимает более двух часов, включая тестирование под Windows и Ubuntu, создание сборок и выкладывание их на сайт. У меня есть чек-лист, который описывает список действий, которые нужно выполнить при выкладывании очередной версии, я его для себя нарисовал в виде алгоритма и увидел, что многие его части можно автоматизировать. И некоторые запланированные пункты уже выполнил. Да и вообще эта книга заставляет задуматься о том, как правильно организовать тестирование и развертывание приложений.

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

https://jenyay.livejournal.com/285226.html

Оригинал записи.



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

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

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




Когда программист отправляет код в репозиторий, сервер CI сначала компилирует программу, и дальнейшие тесты выполняются уже на этой скомпилированной версии (важно, чтобы тестировались именно те бинарные сборки, которые потом попасть на продакшн или пользователям). Первыми запускаются модульные тесты (unit tests), которые должны выполняться быстро, не дольше 5-10 минут, окончания которых должен дождаться программист, отправивший изменения на сервер. Если тесты провалились, то вся команда должна остановить работу или, по крайней мере, не отправлять новые изменения на сервер, пока прохождение модульных тестов не будет исправлено. Если программист, сломавший тесты, за короткий промежуток времени не исправит ошибку, приводящую к провалу теста, то администратор сборки должен иметь право отменить исправление, внесенное этим программистом.

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

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

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

Если программа успешно проходит приемочные тесты и тесты производительности, наступает очередь пользовательских приемочных тестов. Это этап ручной проверки тестировщиками. После прохождения всех тестов, приложение развертывается на тестовом сервере и/или готовится стать релизом для пользователей.

Если строго придерживаться принципов непрерывной интеграции, приложение всегда должно находиться в работоспособном состоянии.

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

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

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

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

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

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

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

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

Автоматизированное развертывание следует использовать всегда; оно должно быть единственной технологией выпуска ПО.

Авторы всячески поддерживают использование виртуализации, чтобы уменьшить различие между тестовыми и рабочими серверами. Поскольку книга была написана в далеком 2011 году, когда еще не было Docker (его первая версия вышла в 2013 году), то понятно, что он не упоминается, а так, мне кажется, что авторы о нем непременно написали что-нибудь хорошее, поскольку он позволяет малой кровью свести к минимуму различия сред выполнения на тестовых серверах и в продакшне.

Любопытно, что отдельные идеи, описанные в этой книге, уже повсеместно применяются (идеи во многом пересекаются с гибкими методологиями разработки), но в "Непрерывном развертывании ПО" авторы их органично объединили в общую идеологию.

Как я уже сказал в начале, на меня эта книга произвела сильное впечатление. Когда я ее читал, постоянно прикидывал, как можно применить описанные в ней идеи к своим проектам и, в частности, к OutWiker, выкладывание новой версии которого сейчас занимает более двух часов, включая тестирование под Windows и Ubuntu, создание сборок и выкладывание их на сайт. У меня есть чек-лист, который описывает список действий, которые нужно выполнить при выкладывании очередной версии, я его для себя нарисовал в виде алгоритма и увидел, что многие его части можно автоматизировать. И некоторые запланированные пункты уже выполнил. Да и вообще эта книга заставляет задуматься о том, как правильно организовать тестирование и развертывание приложений.

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

https://jenyay.livejournal.com/285226.html

Оригинал записи.

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

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

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



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

Например, в этом семестре я читал пятикурсникам лекции про алгоритмы моделирования, которые применяется для решения задач электродинамики. Естественно, он основан на электродинамике, которая у них была на 2-3 курсах. Оказалось, что они не отвечают на вопросы, не зная которых они не могли не только получить зачет по электродинамике на 2 курсе, но и защитить лабы на том же курсе. Понятно, что знания, которыми не пользуешься, выветриваются. Это естественно. Но основные крупные моменты без подробностей должны же сохраняться в памяти.

Самое обидное, что они не пытаются разобраться в предмете, а пытаются запомнить ответы, которые он них ждет препод. Они уже так и спрашивают, когда им ставишь "неуд": "А что я должен был ответить?" Кратко рассказываешь, приходят через несколько дней пересдавать, фрагментарно рассказывают то, что им еще раз объяснял на зачете, но примерно в 70% случаев этот ответ уже не подходит, потому что вопрос им теперь достался другой. Снова спрашивают, как надо было отвечать. Через несколько неудачных попыток сдать они начинают перебирать набранные таким образом варианты ответов. Кто-то угадывает. Получается, что больше всего знаний они получают на зачете и экзамене. Многие преподаватели этим пользуются и прежде, чем поставить "неуд" или даже тройку, устраивают индивидуальную минилекцию для каждого студента, еще раз повторяя то, что было в течение семестра. Насколько такой подход действует - вопрос интересный.

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

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

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

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

Я работаю с 1, 2, 3 и 5 курсами и заметил интересную закономерность. С первым курсом работать приятнее всего - они больше всех знают. Если первокурсники, например, легко отличают период колебания от длины волны, то на втором-третьем курсах - это уже вопрос на засыпку. Но при этом, как ни странно, наибольший отсев студентов происходит именно на первых курсах. Объяснить этот феномен я не в состоянии.

Отдельно хочется поговорить про отношение к литературе. Для студента книга, не выложенная в интернет не считается написанной. На первом-втором курсе я веду предмет, который раньше назывался введением в специальность. Цель этого предмета - заинтересовать студентов в их будущей профессии, поэтому на лекциях я поверхностно рассказываю про области, с которыми им может быть придется столкнуться, если они пойдут работать по специальности: моделирование антенн, радиолокация и технология Stealth, подповерхностная радиолокация, антенные решетки, спутниковые системы навигации и еще некоторые темы. Устраивать серьезный опрос по этому предмету - не гуманно, не получится заинтересованности, а оценку за семестр поставить надо. Поэтому в качестве решения было решено давать им написать реферат на одну из тем, связанную или близкую с тем, что я им рассказываю. Но за последние годы я понял, что это бесполезное занятие - они приносят копипасту из первых статей, попавшихся в поисковой выдаче при запросе у гугла темы реферата. Каждый год приносят одни и те же тексты. Причем я специально проверяю, это не скачанные готовые рефераты - это именно компиляция с одних и тех же сайтов. Некоторые из этих статей - серьезные научные работы, но студент, принесший ее не может ничего объяснить из того, что там написано. Понимание статей такого уровня на первом курсе от них и не требуется, я им специально говорю, чтобы они не включали в реферат то, что они не смогут объяснить - бесполезно. Ну попалось это в первых выдачах поисковика.

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

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

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

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

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

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

Вотъ. Накипело.

https://jenyay.livejournal.com/284959.html

Оригинал записи.

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

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

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



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

Например, в этом семестре я читал пятикурсникам лекции про алгоритмы моделирования, которые применяется для решения задач электродинамики. Естественно, он основан на электродинамике, которая у них была на 2-3 курсах. Оказалось, что они не отвечают на вопросы, не зная которых они не могли не только получить зачет по электродинамике на 2 курсе, но и защитить лабы на том же курсе. Понятно, что знания, которыми не пользуешься, выветриваются. Это естественно. Но основные крупные моменты без подробностей должны же сохраняться в памяти.

Самое обидное, что они не пытаются разобраться в предмете, а пытаются запомнить ответы, которые он них ждет препод. Они уже так и спрашивают, когда им ставишь "неуд": "А что я должен был ответить?" Кратко рассказываешь, приходят через несколько дней пересдавать, фрагментарно рассказывают то, что им еще раз объяснял на зачете, но примерно в 70% случаев этот ответ уже не подходит, потому что вопрос им теперь достался другой. Снова спрашивают, как надо было отвечать. Через несколько неудачных попыток сдать они начинают перебирать набранные таким образом варианты ответов. Кто-то угадывает. Получается, что больше всего знаний они получают на зачете и экзамене. Многие преподаватели этим пользуются и прежде, чем поставить "неуд" или даже тройку, устраивают индивидуальную минилекцию для каждого студента, еще раз повторяя то, что было в течение семестра. Насколько такой подход действует - вопрос интересный.

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

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

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

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

Я работаю с 1, 2, 3 и 5 курсами и заметил интересную закономерность. С первым курсом работать приятнее всего - они больше всех знают. Если первокурсники, например, легко отличают период колебания от длины волны, то на втором-третьем курсах - это уже вопрос на засыпку. Но при этом, как ни странно, наибольший отсев студентов происходит именно на первых курсах. Объяснить этот феномен я не в состоянии.

Отдельно хочется поговорить про отношение к литературе. Для студента книга, не выложенная в интернет не считается написанной. На первом-втором курсе я веду предмет, который раньше назывался введением в специальность. Цель этого предмета - заинтересовать студентов в их будущей профессии, поэтому на лекциях я поверхностно рассказываю про области, с которыми им может быть придется столкнуться, если они пойдут работать по специальности: моделирование антенн, радиолокация и технология Stealth, подповерхностная радиолокация, антенные решетки, спутниковые системы навигации и еще некоторые темы. Устраивать серьезный опрос по этому предмету - не гуманно, не получится заинтересованности, а оценку за семестр поставить надо. Поэтому в качестве решения было решено давать им написать реферат на одну из тем, связанную или близкую с тем, что я им рассказываю. Но за последние годы я понял, что это бесполезное занятие - они приносят копипасту из первых статей, попавшихся в поисковой выдаче при запросе у гугла темы реферата. Каждый год приносят одни и те же тексты. Причем я специально проверяю, это не скачанные готовые рефераты - это именно компиляция с одних и тех же сайтов. Некоторые из этих статей - серьезные научные работы, но студент, принесший ее не может ничего объяснить из того, что там написано. Понимание статей такого уровня на первом курсе от них и не требуется, я им специально говорю, чтобы они не включали в реферат то, что они не смогут объяснить - бесполезно. Ну попалось это в первых выдачах поисковика.

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

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

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

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

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

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

Вотъ. Накипело.

https://jenyay.livejournal.com/284959.html

Оригинал записи.

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

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

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



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

Например, в этом семестре я читал пятикурсникам лекции про алгоритмы моделирования, которые применяется для решения задач электродинамики. Естественно, он основан на электродинамике, которая у них была на 2-3 курсах. Оказалось, что они не отвечают на вопросы, не зная которых они не могли не только получить зачет по электродинамике на 2 курсе, но и защитить лабы на том же курсе. Понятно, что знания, которыми не пользуешься, выветриваются. Это естественно. Но основные крупные моменты без подробностей должны же сохраняться в памяти.

Самое обидное, что они не пытаются разобраться в предмете, а пытаются запомнить ответы, которые он них ждет препод. Они уже так и спрашивают, когда им ставишь "неуд": "А что я должен был ответить?" Кратко рассказываешь, приходят через несколько дней пересдавать, фрагментарно рассказывают то, что им еще раз объяснял на зачете, но примерно в 70% случаев этот ответ уже не подходит, потому что вопрос им теперь достался другой. Снова спрашивают, как надо было отвечать. Через несколько неудачных попыток сдать они начинают перебирать набранные таким образом варианты ответов. Кто-то угадывает. Получается, что больше всего знаний они получают на зачете и экзамене. Многие преподаватели этим пользуются и прежде, чем поставить "неуд" или даже тройку, устраивают индивидуальную минилекцию для каждого студента, еще раз повторяя то, что было в течение семестра. Насколько такой подход действует - вопрос интересный.

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

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

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

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

Я работаю с 1, 2, 3 и 5 курсами и заметил интересную закономерность. С первым курсом работать приятнее всего - они больше всех знают. Если первокурсники, например, легко отличают период колебания от длины волны, то на втором-третьем курсах - это уже вопрос на засыпку. Но при этом, как ни странно, наибольший отсев студентов происходит именно на первых курсах. Объяснить этот феномен я не в состоянии.

Отдельно хочется поговорить про отношение к литературе. Для студента книга, не выложенная в интернет не считается написанной. На первом-втором курсе я веду предмет, который раньше назывался введением в специальность. Цель этого предмета - заинтересовать студентов в их будущей профессии, поэтому на лекциях я поверхностно рассказываю про области, с которыми им может быть придется столкнуться, если они пойдут работать по специальности: моделирование антенн, радиолокация и технология Stealth, подповерхностная радиолокация, антенные решетки, спутниковые системы навигации и еще некоторые темы. Устраивать серьезный опрос по этому предмету - не гуманно, не получится заинтересованности, а оценку за семестр поставить надо. Поэтому в качестве решения было решено давать им написать реферат на одну из тем, связанную или близкую с тем, что я им рассказываю. Но за последние годы я понял, что это бесполезное занятие - они приносят копипасту из первых статей, попавшихся в поисковой выдаче при запросе у гугла темы реферата. Каждый год приносят одни и те же тексты. Причем я специально проверяю, это не скачанные готовые рефераты - это именно компиляция с одних и тех же сайтов. Некоторые из этих статей - серьезные научные работы, но студент, принесший ее не может ничего объяснить из того, что там написано. Понимание статей такого уровня на первом курсе от них и не требуется, я им специально говорю, чтобы они не включали в реферат то, что они не смогут объяснить - бесполезно. Ну попалось это в первых выдачах поисковика.

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

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

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

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

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

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

Вотъ. Накипело.

https://jenyay.livejournal.com/284959.html

Оригинал записи.

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

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



Больше всего пришлось возиться с тем, что после перехода в полноэкранный режим переставали работать горячие клавиши для некоторых пунктов меню. У меня сложилось впечатление, что это глюк wxPython, я подготовил минимальный пример, где он проявляется, и отправил его на форум wxPython. Посмотрим, что там скажут. Пока в версии под Linux я отключил переход в полноэкранный режим, при выборе этого пункта меню теперь только скрываются лишние панели. Кроме этого была исправлена ошибка с показом контекстного меню для слов с ошибками орфографии.

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

Во-вторых, В плагине Source был исправлен глюк, который проявлял себя таким образом, что диалог для вставки команды (:source:) от раза к разу становился все больше и больше по высоте. Не буду вас мучить подробностями этой странности, но есть у меня подозрение, что тут тоже не все гладко с wxPython. Причем под Windows все работает как надо, проблема проявлялась только под Linux. Эту проблему, к счастью, удалось обойти довольно легко. Такая же бяка была и с диалогом создания страниц в самом OutWiker. В общем, если вы увидите, что какой-то диалог каждый раз становится все больше и больше, пишите мне - поправлю.

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

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

PS. А в качестве анонса приведу скриншот папки plugins исходников программы.

https://jenyay.livejournal.com/284803.html

Оригинал записи.

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

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



Больше всего пришлось возиться с тем, что после перехода в полноэкранный режим переставали работать горячие клавиши для некоторых пунктов меню. У меня сложилось впечатление, что это глюк wxPython, я подготовил минимальный пример, где он проявляется, и отправил его на форум wxPython. Посмотрим, что там скажут. Пока в версии под Linux я отключил переход в полноэкранный режим, при выборе этого пункта меню теперь только скрываются лишние панели. Кроме этого была исправлена ошибка с показом контекстного меню для слов с ошибками орфографии.

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

Во-вторых, В плагине Source был исправлен глюк, который проявлял себя таким образом, что диалог для вставки команды (:source:) от раза к разу становился все больше и больше по высоте. Не буду вас мучить подробностями этой странности, но есть у меня подозрение, что тут тоже не все гладко с wxPython. Причем под Windows все работает как надо, проблема проявлялась только под Linux. Эту проблему, к счастью, удалось обойти довольно легко. Такая же бяка была и с диалогом создания страниц в самом OutWiker. В общем, если вы увидите, что какой-то диалог каждый раз становится все больше и больше, пишите мне - поправлю.

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

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

PS. А в качестве анонса приведу скриншот папки plugins исходников программы.

https://jenyay.livejournal.com/284803.html

Оригинал записи.

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

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



Больше всего пришлось возиться с тем, что после перехода в полноэкранный режим переставали работать горячие клавиши для некоторых пунктов меню. У меня сложилось впечатление, что это глюк wxPython, я подготовил минимальный пример, где он проявляется, и отправил его на форум wxPython. Посмотрим, что там скажут. Пока в версии под Linux я отключил переход в полноэкранный режим, при выборе этого пункта меню теперь только скрываются лишние панели. Кроме этого была исправлена ошибка с показом контекстного меню для слов с ошибками орфографии.

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

Во-вторых, В плагине Source был исправлен глюк, который проявлял себя таким образом, что диалог для вставки команды (:source:) от раза к разу становился все больше и больше по высоте. Не буду вас мучить подробностями этой странности, но есть у меня подозрение, что тут тоже не все гладко с wxPython. Причем под Windows все работает как надо, проблема проявлялась только под Linux. Эту проблему, к счастью, удалось обойти довольно легко. Такая же бяка была и с диалогом создания страниц в самом OutWiker. В общем, если вы увидите, что какой-то диалог каждый раз становится все больше и больше, пишите мне - поправлю.

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

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

PS. А в качестве анонса приведу скриншот папки plugins исходников программы.

https://jenyay.livejournal.com/284803.html

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



За последний месяц работа над OutWiker-ом шла по двум направлениям. Первое - это сделать сборку под Linux, которая бы тащила за собой все скомпилированные объектные файлы из wxPython 2.8, чтобы не зависеть от наличия этой библиотеки в стандартных репозиториях Ubuntu. Второй путь - это миграция на wxPython 3.0. Хотя бинарную сборку и даже deb-пакет со скомпилированной библиотекой wxPython 2.8 сделать удалось, но все-таки этот путь мне показался тупиковым из-за того, что такая сборка тянет за собой явно лишние файлы, от которых сходу избавиться не удалось, а размер такой сборки оказался слишком уж большим (около 200 МБ, интересно snap-пакет, когда дойдут руки его сделать, будет такого же размера?).

Переход на wxPython 3.0 - дело кропотливое, но в итоге оказалось вполне посильное. Больше всего проблем было с использованием WebKit. Спасибо Юрию, который в предыдущем посте подсказал идею с использованием переменной окружения LP_PRELOAD, эта идея резко облегчила жизнь и помогла обойти ошибку в библиотеке wxPython 3.0 из стандартного репозитория.

При переходе на wxPython 3.0 были еще некоторые проблемы, не все из них еще решены, но в целом программа уже вполне работоспособна. Единственное, что под Linux сейчас отключено сворачивание программы в системный трей. Но, и до этого в Unity это не работало, а в KDE - глючило. Эту часть я буду переписывать полностью (под Windows все работает).

Еще могут быть какие-то моменты, которые я не заметил, поэтому буду благодарен за сообщения о глюках.

Итак, первая нестабильная версия OutWiker версии 2.0 с использованием wxPython 3.0 готова для скачивания и испытания.

Скачать ее как всегда можно по ссылке - http://jenyay.net/Outwiker/Unstable

https://jenyay.livejournal.com/284518.html

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



За последний месяц работа над OutWiker-ом шла по двум направлениям. Первое - это сделать сборку под Linux, которая бы тащила за собой все скомпилированные объектные файлы из wxPython 2.8, чтобы не зависеть от наличия этой библиотеки в стандартных репозиториях Ubuntu. Второй путь - это миграция на wxPython 3.0. Хотя бинарную сборку и даже deb-пакет со скомпилированной библиотекой wxPython 2.8 сделать удалось, но все-таки этот путь мне показался тупиковым из-за того, что такая сборка тянет за собой явно лишние файлы, от которых сходу избавиться не удалось, а размер такой сборки оказался слишком уж большим (около 200 МБ, интересно snap-пакет, когда дойдут руки его сделать, будет такого же размера?).

Переход на wxPython 3.0 - дело кропотливое, но в итоге оказалось вполне посильное. Больше всего проблем было с использованием WebKit. Спасибо Юрию, который в предыдущем посте подсказал идею с использованием переменной окружения LP_PRELOAD, эта идея резко облегчила жизнь и помогла обойти ошибку в библиотеке wxPython 3.0 из стандартного репозитория.

При переходе на wxPython 3.0 были еще некоторые проблемы, не все из них еще решены, но в целом программа уже вполне работоспособна. Единственное, что под Linux сейчас отключено сворачивание программы в системный трей. Но, и до этого в Unity это не работало, а в KDE - глючило. Эту часть я буду переписывать полностью (под Windows все работает).

Еще могут быть какие-то моменты, которые я не заметил, поэтому буду благодарен за сообщения о глюках.

Итак, первая нестабильная версия OutWiker версии 2.0 с использованием wxPython 3.0 готова для скачивания и испытания.

Скачать ее как всегда можно по ссылке - http://jenyay.net/Outwiker/Unstable

https://jenyay.livejournal.com/284518.html

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



За последний месяц работа над OutWiker-ом шла по двум направлениям. Первое - это сделать сборку под Linux, которая бы тащила за собой все скомпилированные объектные файлы из wxPython 2.8, чтобы не зависеть от наличия этой библиотеки в стандартных репозиториях Ubuntu. Второй путь - это миграция на wxPython 3.0. Хотя бинарную сборку и даже deb-пакет со скомпилированной библиотекой wxPython 2.8 сделать удалось, но все-таки этот путь мне показался тупиковым из-за того, что такая сборка тянет за собой явно лишние файлы, от которых сходу избавиться не удалось, а размер такой сборки оказался слишком уж большим (около 200 МБ, интересно snap-пакет, когда дойдут руки его сделать, будет такого же размера?).

Переход на wxPython 3.0 - дело кропотливое, но в итоге оказалось вполне посильное. Больше всего проблем было с использованием WebKit. Спасибо Юрию, который в предыдущем посте подсказал идею с использованием переменной окружения LP_PRELOAD, эта идея резко облегчила жизнь и помогла обойти ошибку в библиотеке wxPython 3.0 из стандартного репозитория.

При переходе на wxPython 3.0 были еще некоторые проблемы, не все из них еще решены, но в целом программа уже вполне работоспособна. Единственное, что под Linux сейчас отключено сворачивание программы в системный трей. Но, и до этого в Unity это не работало, а в KDE - глючило. Эту часть я буду переписывать полностью (под Windows все работает).

Еще могут быть какие-то моменты, которые я не заметил, поэтому буду благодарен за сообщения о глюках.

Итак, первая нестабильная версия OutWiker версии 2.0 с использованием wxPython 3.0 готова для скачивания и испытания.

Скачать ее как всегда можно по ссылке - http://jenyay.net/Outwiker/Unstable

https://jenyay.livejournal.com/284518.html

Наконец-то OutWiker версии 1.9 можно назвать стабильной версией и выпустить очередной крупный релиз. По планам я собирался выпустить релиз несколько раньше, но из-за загруженностью работой количество свободного времени резко уменьшилось - в институте, где я работаю, в этом семестре я читаю новый курс, который надо готовить, и большая часть свободного времени уходит на подготовку (если кому интересно, курс называется "Моделирование антенн и устройств СВЧ").

Далее в этом посте я перечислю основные изменения, которые произошли в OutWiker 1.9 по сравнению с предыдущей версией 1.8.1.




Самое крупное нововведение - это добавление проверки орфографии.

В отличие от многих других программ, OutWiker позволяет одновременно использовать словари для нескольких языков. Это удобно, если у вас заметки содержат текст, например, и на русском, и на английском языках. Выбрать используемые словари можно в диалоге настроек в разделе "Редактор - Проверка орфографии".

По умолчанию доступны словари для русского, украинского и английского языков, но вы можете добавить словарь для другого языка (OutWiker использует словари в формате dic и aff), скопировав их в папку "spell" внутри папки настроек.

Напомню, что папка настроек под Windows 7 и выше находится по адресу "C:\Users\USERNAME\AppData\Roaming\outwiker", где USERNAME - это имя вашего пользователя на компьютере. Под Linux путь до папки настроек выглядит так: "~/.config/outwiker".

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

Для HTML-страниц проверка орфографии учитывает известные ей HTML-теги. Кстати, в OutWiker 1.9 подсветка кода HTML теперь понимает большее количество тегов - были добавлены новые теги из HTML5.

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

Теперь пользователи теперь могут добавлять собственные значки (в принципе, это можно было делать и раньше, но теперь для добавления значков был сделан удобный интерфейс). Пользовательские значки хранятся в папке "icons" в папке настроек, но об этом можно не задумываться, потому что для добавления и удаления значков был сделан интерфейс в диалоге настроек. Находится он в разделе "Значки пользователя".

В OutWiker 1.9 был расширен синтаксис викинотации. Например, были добавлены новые команды для создания таблиц. Старый синтаксис, использующий вертикальные линии ||...||...|| остался, но его удобнее использовать для небольших таблиц, а для более объемных таблиц удобнее использовать команды (:table:), (:row:), (:cell:) и (:hcell:). Здесь я их описывать не буду, просто дам ссылку на блогозапись, где они подробно описаны.

Была добавлена викикоманда [!...!] для выделения текста. Эта команда преобразуется в HTML-теги ... и предназначена для выделения важного текста на странице.

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

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

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

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

Самый крупный такой плагин - это WebPage, который предназначен для скачивания страниц из интернета. Это была вторая крупная фича (первой была проверка орфографии), которую очень хотелось сделать до выхода релиза OutWiker 1.9. Подробнее об этом плагине вы можете прочитать здесь.

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

В OutWiker 1.9 возможность вставки формул была перенесена из базовой возможности в плагин TexEquation. На данный момент этот плагин по возможностям не отличается от вставки формул, которая была раньше, но зато теперь OutWiker не тянет с собой mimeTeX, который используется для рендеринга формул (для работы плагина mimeTeX по-прежнему нужен).

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

Недавно я узнал про интересную библиотеку KaTeX, которая рендерит формулы в формате TeX с помощью JavaScript, но при этом она не такая огромная, как аналогичная библиотека MathJax.

В экспериментальной ветке в исходниках я уже заменил mimeTeX на KaTeX и обрадовался, насколько с ней формулы стали выглядеть симпатичнее, в том числе и на темном фоне, но оказалось, что у KaTeX есть проблемы с русскими буквами - формулы, которые их содержат, не рендерятся. В багтрекере эта проблема описана (https://github.com/Khan/KaTeX/issues/380), но, похоже, автор не горит желанием ее исправлять, ссылаясь на технические трудности.

Очень жаль, но пока придется остаться на mimeTeX, но буду следить за развитием KaTeX, и как только проблема будет решена, перейду на эту библиотеку.

Для OutWiker 1.9 появился новый плагин под названием HtmlFormatter. После установки этого плагина в диалоге настроек в разделе "Просмотр" появляется переключатель, который позволяет выбрать, каким образом на создаваемой HTML-странице будут оформляться параграфы - с помощью тегов

...

или с помощью последовательности тегов
.

И еще один появившийся недавно плагин, который работает в OutWiker, начиная с версии 1.9, это PageTypeColor. Про этот плагин я подробно писал в блоге, когда его только сделал. Если коротко, то этот плагин подкрашивает разными цветами поле ввода заголовка страницы в зависимости от того, какой тип страницы в данный момент выбран в диалоге.

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

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

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

Во-вторых, многие просили сделать поддержку синтаксиса Markdown. В OutWiker 1.9 вроде бы все готово, чтобы эту возможность реализовать в виде плагина.

Кроме того, я хочу расширить возможности плагина ChangePageUid и добавить в него возможность менять не только идентификатор страниц, но и дату создания страницы (по поводу возможности изменения даты редактирования я еще думаю), поэтому плагин придется переименовать, пока у него рабочее название HackPage, и я не вижу причин от отказываться от такого названия.

Что касается следующей версии OutWiker, то в ней нужно будет как минимум перейти на wxPython 3.0 (не путайте с Python 3.x). К сожалению, там есть проблемы с обратной совместимостью, но надеюсь, что это все решается малой кровью. Хотя при этом придется отказаться от поддержки Ubuntu 14.04 (по крайней мере в виде PPA, бинарные сборки там работать должны).

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

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

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

Скачать OutWiker 1.9 можно на этой странице.

На этом пока все. Жду ваших отзывов и комментариев, а также присоединяйтесь к группе Вконтакте, Facebook, Google+ и ЖЖ. Также недавно был создан канал в Telegram.

https://jenyay.livejournal.com/284307.html

Наконец-то OutWiker версии 1.9 можно назвать стабильной версией и выпустить очередной крупный релиз. По планам я собирался выпустить релиз несколько раньше, но из-за загруженностью работой количество свободного времени резко уменьшилось - в институте, где я работаю, в этом семестре я читаю новый курс, который надо готовить, и большая часть свободного времени уходит на подготовку (если кому интересно, курс называется "Моделирование антенн и устройств СВЧ").

Далее в этом посте я перечислю основные изменения, которые произошли в OutWiker 1.9 по сравнению с предыдущей версией 1.8.1.




Самое крупное нововведение - это добавление проверки орфографии.

В отличие от многих других программ, OutWiker позволяет одновременно использовать словари для нескольких языков. Это удобно, если у вас заметки содержат текст, например, и на русском, и на английском языках. Выбрать используемые словари можно в диалоге настроек в разделе "Редактор - Проверка орфографии".

По умолчанию доступны словари для русского, украинского и английского языков, но вы можете добавить словарь для другого языка (OutWiker использует словари в формате dic и aff), скопировав их в папку "spell" внутри папки настроек.

Напомню, что папка настроек под Windows 7 и выше находится по адресу "C:\Users\USERNAME\AppData\Roaming\outwiker", где USERNAME - это имя вашего пользователя на компьютере. Под Linux путь до папки настроек выглядит так: "~/.config/outwiker".

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

Для HTML-страниц проверка орфографии учитывает известные ей HTML-теги. Кстати, в OutWiker 1.9 подсветка кода HTML теперь понимает большее количество тегов - были добавлены новые теги из HTML5.

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

Теперь пользователи теперь могут добавлять собственные значки (в принципе, это можно было делать и раньше, но теперь для добавления значков был сделан удобный интерфейс). Пользовательские значки хранятся в папке "icons" в папке настроек, но об этом можно не задумываться, потому что для добавления и удаления значков был сделан интерфейс в диалоге настроек. Находится он в разделе "Значки пользователя".

В OutWiker 1.9 был расширен синтаксис викинотации. Например, были добавлены новые команды для создания таблиц. Старый синтаксис, использующий вертикальные линии ||...||...|| остался, но его удобнее использовать для небольших таблиц, а для более объемных таблиц удобнее использовать команды (:table:), (:row:), (:cell:) и (:hcell:). Здесь я их описывать не буду, просто дам ссылку на блогозапись, где они подробно описаны.

Была добавлена викикоманда [!...!] для выделения текста. Эта команда преобразуется в HTML-теги ... и предназначена для выделения важного текста на странице.

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

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

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

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

Самый крупный такой плагин - это WebPage, который предназначен для скачивания страниц из интернета. Это была вторая крупная фича (первой была проверка орфографии), которую очень хотелось сделать до выхода релиза OutWiker 1.9. Подробнее об этом плагине вы можете прочитать здесь.

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

В OutWiker 1.9 возможность вставки формул была перенесена из базовой возможности в плагин TexEquation. На данный момент этот плагин по возможностям не отличается от вставки формул, которая была раньше, но зато теперь OutWiker не тянет с собой mimeTeX, который используется для рендеринга формул (для работы плагина mimeTeX по-прежнему нужен).

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

Недавно я узнал про интересную библиотеку KaTeX, которая рендерит формулы в формате TeX с помощью JavaScript, но при этом она не такая огромная, как аналогичная библиотека MathJax.

В экспериментальной ветке в исходниках я уже заменил mimeTeX на KaTeX и обрадовался, насколько с ней формулы стали выглядеть симпатичнее, в том числе и на темном фоне, но оказалось, что у KaTeX есть проблемы с русскими буквами - формулы, которые их содержат, не рендерятся. В багтрекере эта проблема описана (https://github.com/Khan/KaTeX/issues/380), но, похоже, автор не горит желанием ее исправлять, ссылаясь на технические трудности.

Очень жаль, но пока придется остаться на mimeTeX, но буду следить за развитием KaTeX, и как только проблема будет решена, перейду на эту библиотеку.

Для OutWiker 1.9 появился новый плагин под названием HtmlFormatter. После установки этого плагина в диалоге настроек в разделе "Просмотр" появляется переключатель, который позволяет выбрать, каким образом на создаваемой HTML-странице будут оформляться параграфы - с помощью тегов

...

или с помощью последовательности тегов
.

И еще один появившийся недавно плагин, который работает в OutWiker, начиная с версии 1.9, это PageTypeColor. Про этот плагин я подробно писал в блоге, когда его только сделал. Если коротко, то этот плагин подкрашивает разными цветами поле ввода заголовка страницы в зависимости от того, какой тип страницы в данный момент выбран в диалоге.

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

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

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

Во-вторых, многие просили сделать поддержку синтаксиса Markdown. В OutWiker 1.9 вроде бы все готово, чтобы эту возможность реализовать в виде плагина.

Кроме того, я хочу расширить возможности плагина ChangePageUid и добавить в него возможность менять не только идентификатор страниц, но и дату создания страницы (по поводу возможности изменения даты редактирования я еще думаю), поэтому плагин придется переименовать, пока у него рабочее название HackPage, и я не вижу причин от отказываться от такого названия.

Что касается следующей версии OutWiker, то в ней нужно будет как минимум перейти на wxPython 3.0 (не путайте с Python 3.x). К сожалению, там есть проблемы с обратной совместимостью, но надеюсь, что это все решается малой кровью. Хотя при этом придется отказаться от поддержки Ubuntu 14.04 (по крайней мере в виде PPA, бинарные сборки там работать должны).

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

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

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

Скачать OutWiker 1.9 можно на этой странице.

На этом пока все. Жду ваших отзывов и комментариев, а также присоединяйтесь к группе Вконтакте, Facebook, Google+ и ЖЖ. Также недавно был создан канал в Telegram.

https://jenyay.livejournal.com/284307.html