Читая обычный сайт с телефона или планшетного компьютера с touch-интерфейсом я постоянно промахиваюсь мимо нужных ссылок и мелких контролов.

Touch несовершенен, а подушечка пальца имеет площадь. Что происходит под ней не видно. Результат действия непредсказуем до его завершения. Постоянно уменьшать или увеличивать страницу неудобно, а стилусы — это то, от чего мы ушли 5 лет назад.

На месте разработчиков мобильных интерфейсов я бы сделал следующим образом.



В основе решения лежат некоторые реализации экранных клавиатур и quad-menu, которые присутствуют во многих редакторах трехмерной графики.

Всех с наступающим!

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



Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

(в качестве иллюстрации лицо типичной универсальной методики авторства RuxxSilver, которое на первый взгляд выглядит весьма привлекательно и правдоподобно)

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



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

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

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)

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



Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.

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

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

(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)

1. Индустрия на стероидах

 

Основные изменения:

• Автоматически добавляются escape-символы при выводе в шаблоны
• Стандартная реализация AsyncHTTPClient теперь simple_httpclient.
• Поддержка Python 3.2.

Минорные изменения:

• Новые теги шаблонизатора:
  — {% autoescape ...%} управление добавлением escape — символов
  — {% raw… %} убрать escape-символы
  — {% module… %} для вызова UIModules
• {% module Template(path, **kwargs) %} теперь может быть использовано для вызова другого шаблона с независимым пространством имен
• Все вызовы IOStream callbacks теперь осуществляются напрямую в IOLoop через add_callback.
• HTTPServer теперь поддерживает IPv6. Для отключения нужно передать параметр family=socket.AF_INET в HTTPServer.bind().
• HTTPClient теперь поддерживает IPv6, если у запроса установлен параметр allow_ipv6=True
• RequestHandlers теперь может использовать кодировки, отличные от utf-8 для параметра запроса путем переопределения decode_argument()
• Улучшена производительность, особенно для приложений, использующих много IOLoop timeouts
• HTTP OPTIONS метод теперь не требует XSRF token.
• Вывод в JSON (RequestHandler.write(dict)) теперь устанавливает Content-Type application/json
• вычисление Etag теперь может быть настроено или отключено путем переопределения RequestHandler.compute_etag
• USE_SIMPLE_HTTPCLIENT больше не поддерживается, вместо него используйте AsyncHTTPClient.configure.

Берем на GitHub

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



Можно скачать pdf и можно заказать

Есть куча методик улучшения свой производительности и тайм менеджмента, самомотивации, вроде GTD, таймдайвинга и т.д.

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

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

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

 

Хотим представить вашему вниманию русскоязычную версию руководства tornado server 0.2

Сегодня мне попался пост о засилии презентаций в американской армии. Я работаю в администрации лицея и могу сказать, что в образовании ситуация приблизительно такая же. К каждому чиху, публично сказанному слову и микродостижению нужна презентация. И в учреждении где учится 300 детишек создается порядка 600-700 презентаций в год, около 200 из них создаются педагогами, остальное — детишками. Даже если учреждение захочет остановить этот поток — оно не сможет, для любого внешнего выступления презентации — обязательное требование, они включены во все программы по информатике и т.д.
О качестве их исполнения, полагаю, рассказывать не стоит. И учителей и учащихся десятки часов учат делать презентации, но от этого не очень много толка.
Есть поговорка, что если бардак нельзя прекратить, то его надо возглавить. Тем более беда с визуальной подачей информации также повсеместна среди клерков, в науке, и где только нет.

Итак, сейчас я обкатываю часовой интенсив по юзабилити компьютерных презентаций, представленный в лекционной форме и сопровождающийся, как ни странно, презентацией. Основная цель: человек тратит час и избавляется хотя бы от «детских ошибок».



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

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

В голову пришли следующие варианты:

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

1 поле: email
Пользователь оставляет email, id создается автоматически, на email он получает пароль, авторизация либо по ID либо по email, username задается пользователем уже в профиле

+ Черт, это все таки одно поле! По умолчанию может быть сгенерен устойчивый к перебору пароль.
± username свободно меняются, и могут оставаться пустыми. Учитывать пользователей по айдишникам мне не хочется
— ЧПУ приобретают вид ufosite.nl/users/18567, скорее всего пользователь захочет сменить свой пароль. При ЧПУ вида ufosite.nl/users/customusername наступает ад для поисковиков. Строить ЧПУ на основе email, который, к тому же, далеко не все захотят публиковать — это подарок спамерам и ЧПУ становятся не совсем ЧПУ.

 

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

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

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

Источник информации — разговор со службой поддержки программы «Первая помощь».
Попробую получить дополнительную информацию от Департамента и ИАЦ.

Хотелось бы добавить от себя, что необходимые для подобного перехода кадры школам взять неоткуда, ставок для того чтобы организовать внутренние службы поддержки (а они будут очень нужны) тоже никто не даст. Программы по информатике будут серьезно перекроены. Коллеги, то есть диркетора, ИТ-замы и преподаватели информатики, воспринимают ситуацию как катастрофическую.

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



Только в образовании все происходит тихо и спокойно.

Утро понедельника.
Я прибегаю на работу, у меня есть три минуты, чтобы залезть в почту, вытащить с gmail документ, распечатать, кинуть коллеге сообщение, чтобы он спускался вниз, и отправиться на планерку.
Но не тут-то было.

Я давно не занимался сайтостроительством, но недавно пришлось.
Само-собой, половину времени, ушедшего на верстку, я убил на совместимость с IE6 и IE7.
Добавил к этому времени две минуты и дописал крохотный скриптик в конце шаблона, вежливо предлагающий сменить браузер на альтернативный, со ссылками на них.
Буду рад, если вы поддержите подобную инициативу.

(Логотипы пришлось брать с rambler.ru, так как на сайтах производителей браузеров они уже давно размещены в формате PNG, который так себе дружит с IE)

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



Я думаю многие, кто хоть краем глаза почитывает новости в области IT помнят историю со школьным порталом. Для тех, кто не помнит, вот wiki про то, как удачно распилили 13 950 000 рублей и все это всплыло на поверхность благодаря блогам.
Но все течет, все меняется и вот уже два года здравствует порождение очередного распила, о котором пока в рунете ни слова. Проживает оно по изящному адресу schoolinfo.educom.ru:8080 и называется «Электронный журнал» или более официально «Школьная информационная система». Ранее оно называлось «Городская Школьная Информационная Система 1.0» и жило здесь. Для понимания серьезности проблемы счет школ, использующих этот сервис идет на сотни, если уже не на тысячи, разработчик системы некая контора под названием «Электронная школа» www.e-school.ru, сайт которой блещут красивыми словами об эффктивности, долгосрочном партнерстве и многочисленных ГОСТ-ах.

Расскажу о своем бывшем питомце.
В 99-м году попала в руки и осела такая железяка: