vit_r: default (Default)
vit_r ([personal profile] vit_r) wrote2012-12-07 10:34 am

NullPlus

Этот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.



Решил сделать движущиеся картинки. Поискал, можно ли собрать gif из командной строки. Нашёл у себя инсталляцию ImageMagick (как потом оказалось, обрезанную и кривую). Решил попробовать. Короче, в тот день я ничего не сделал. Точнее, ничего полезного.

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

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

Методами интенсификации умственной деятельности я начал интересоваться ещё в школе. Правильные методики разработки софта ищу с тех пор, как начал программированием зарабатывать деньги. То есть, где-то с третьего-четвёртого курса. За это время перечитал массу бреда, включая свежие статьи в профильных журналах и спецификации стандартов. Плюс кучу книжек по организации деятельности от американских бестселлеров до советских учебников по психологии. Ну и, конечно, genchi genbutsu, то есть сам приложил руки к реальным делам во многих проектах.

Видел много чудесного и прекрасного. Но всё не решало, а чаще всего ухудшало основной принцип неопределённости умственной деятельности: «Или у нас хорошая отчётность, или у нас хороший результат»

Плюс все методики не стабильны.

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

Мы можем три года аккуратно вести проект по gnatt, точно вписываясь в дидлайны и победно отчитываясь по каждому этапу. Но за три месяца до сдачи вылезают незамеченные мелочи, и вся красота идёт в мусорное ведро, а реальность улетает куда-то в туман.

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

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

Короче, все известные методики и подходы не выдерживают требования предсказуемости, правдивости и стрессоустойчивости. Что-то полезное нашёл только у Барбары Шер и у Тойоты. (У последней, естественно, не в конвейерных сказках про lean и kanban, которые они продают миру, а во внутренних методиках, которые они тщательно прячут и упоминают лишь изредка и очень туманно.)

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

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

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

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

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

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

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

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

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

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

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

Это ещё не решение. И даже не направление движения. Просто проблеск идеи. Но мне понравилось. И теперь понятно, куда идти дальше.

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





Если картинка не движется секунд 10, её надо перегрузить. FFox у меня показывает анимацию через раз.

Post a comment in response:

(will be screened)
(will be screened if not validated)
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org