![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Этот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.
Решил сделать движущиеся картинки. Поискал, можно ли собрать gif из командной строки. Нашёл у себя инсталляцию ImageMagick (как потом оказалось, обрезанную и кривую). Решил попробовать. Короче, в тот день я ничего не сделал. Точнее, ничего полезного.
R, кстати, оказался достаточно простым и понятным. Правда, документации нормальной тоже нет, и приходится работать по методу: попробуй, найди ошибку в гугле, пойми, исправь и попробуй следующий шаг. Благо, народу, с гонором объясняющего базовые принципы, по форумам полно, и ответы есть на все вопросы.
Надо было, конечно, выпендриться и написать ниже следующее на английском. Но пофиг. Чужие здесь не хотят, а если кто лишний вдруг случайно набредёт, пусть довольствуется гуглопереводчиком.
Методами интенсификации умственной деятельности я начал интересоваться ещё в школе. Правильные методики разработки софта ищу с тех пор, как начал программированием зарабатывать деньги. То есть, где-то с третьего-четвёртого курса. За это время перечитал массу бреда, включая свежие статьи в профильных журналах и спецификации стандартов. Плюс кучу книжек по организации деятельности от американских бестселлеров до советских учебников по психологии. Ну и, конечно, genchi genbutsu, то есть сам приложил руки к реальным делам во многих проектах.
Видел много чудесного и прекрасного. Но всё не решало, а чаще всего ухудшало основной принцип неопределённости умственной деятельности: «Или у нас хорошая отчётность, или у нас хороший результат»
Плюс все методики не стабильны.
Мы можем выделить группу из трёх предсказателей, которая на больших проектах в стабильных условиях на заданной группе выдаст прекрасную точность. Но всё летит к чертям, когда вдруг в техзадание влезают не учтённые, но совершенно критические требования, или бюджет внезапно схлопывается в два раза.
Мы можем три года аккуратно вести проект по gnatt, точно вписываясь в дидлайны и победно отчитываясь по каждому этапу. Но за три месяца до сдачи вылезают незамеченные мелочи, и вся красота идёт в мусорное ведро, а реальность улетает куда-то в туман.
И да, agile. Люди работают, клиент доволен. Что получается, не понятно, зато постоянно у клиента есть игрушка. Пока внезапно он не понимает, что это игрушка которая игрушкой и останется. Потому что где-то в глобальных принципах какие-то траблы, архитектура ни к чёрту, кодировщики уже на сто процентов заняты только тем, что загоняют в код ошибки, а потом мужественно их исправляют, при этом куча важных, само собой разумеющихся (для специалиста) требований в продукт просто не вошла. И никогда не влезет, потому как фундаментальные решения были не те, что нужно.
Единственное, если маленькой сплочённой группе дать чёткое задание, желательно в области создания чего-то для программистов, и оставить их на долгое время в покое, они выдадут что-то интересное. Но ни предсказать, что это будет, ни с уверенностью сказать, когда это случится и случится ли вообще, мы не можем.
Короче, все известные методики и подходы не выдерживают требования предсказуемости, правдивости и стрессоустойчивости. Что-то полезное нашёл только у Барбары Шер и у Тойоты. (У последней, естественно, не в конвейерных сказках про lean и kanban, которые они продают миру, а во внутренних методиках, которые они тщательно прячут и упоминают лишь изредка и очень туманно.)
Короче, методика, которая мне нужна, применяется на любой деятельности, говорит правду, не создаёт панику, точно описывает настоящее, точно предсказывает и помогает контролировать будущее. При этом она должна быть стабильна и масштабируема до одного человека. Последнее требование, вынесенный в заголовок NullPlus, просто даёт гарантию, что всё будет работать даже в ситуации, когда ни времени, ни бюджета, ни ресурсов нет. То есть, методика будет экономить время и силы даже в ситуации нуля, желательно помогая выгребать из минуса.
Из работающих и давно применяемых компонентов могу упомянуть лог проекта. После игры с разными тулами, форматами и способами всё стабилизировалось на банальном текстовом файле с отметками дат и простым нумерованным списком произошедших за день событий. (В принципе, у меня сейчас лог - это только конец файла, растущий вниз, есть и другие разделы для агрегации и контроля, но это уже совсем другая тема.)
Выяснилось, что это наиболее надёжный и удобный способ. Можно писать толстые документы, использовать архивы мейлов, извращаться с баг треккингом, шарепойнтом, вики, ньюсами, но, если решения, задумки и достижения не ложатся в несколько строк текстового файла, контроль за происходящим потерян.
Естественно, вся красота и мощь автоматизации живёт параллельно и несколько сбоку. Иногда со ссылками из текстового лога, иногда с упоминаниями, иногда просто как свалка для отчётности. Если что-то нужно быстро понять, вспомнить или повторить, всё ищется в банальном простом текстовом файле, содержащем всё важное, и только это.
Базовая теория для удовлетворяющей меня методики предсказания и планирования начала вырисовываться в девяносто седьмом году прошлого века. С тех пор ищу, как это реализовать на практике.
То, что мир избавлен от пары-тройки хитроумных тулов, это только благодаря тому, что я, в отличии от большинства представителей кнопкодавов, сначала пытаюсь обкатать теорию на практике в ручном режиме или на прототипах. Несколько образцов хорошо вписались во все требования, включая неожиданные заскоки техзадания и точность предсказания. Они прошли практически все испытания. Кроме испытания ленью.
По характеру работы мне любой контроль абсолютно пофиг. Точнее, я знаю, что надо, и сделаю к сроку. Или скажу, что сделать невозможно. И это без всяких тулов, ничего не записывая.
По этой причине, когда проект становился совсем грустным, и скачки переходили в механизированную эмуляцию передвижения загнанных лошадей, все прототипы медленно застывали. В основном потому, что они показывали реальное положение вещей, которое было абсолютно не мотивирующим.
Короче, лень и пофигизм - это реальный параметр, который в полевых условиях будет гробить любое развитие тестируемого образца. И пока что все прототипы на этом ломались.
Но в этом году наконец-то найден способ, побеждающий лень и сохраняющий фактор кайфа при любом развитии событий. (А с загнанными лошадьми и на этот раз всё было стандартно.)
Конечно, в полной реализации для нормальных людей это всё будет выглядеть совсем по-другому. И что-то годное для рынка можно сделать, только вложив разработку, судя по аналогам, порядка трёхсот тысяч.
Это ещё не решение. И даже не направление движения. Просто проблеск идеи. Но мне понравилось. И теперь понятно, куда идти дальше.
Под катом семь месяцев за полторы минуты в 9 мегабайтах.

Если картинка не движется секунд 10, её надо перегрузить. FFox у меня показывает анимацию через раз.
Решил сделать движущиеся картинки. Поискал, можно ли собрать gif из командной строки. Нашёл у себя инсталляцию ImageMagick (как потом оказалось, обрезанную и кривую). Решил попробовать. Короче, в тот день я ничего не сделал. Точнее, ничего полезного.
R, кстати, оказался достаточно простым и понятным. Правда, документации нормальной тоже нет, и приходится работать по методу: попробуй, найди ошибку в гугле, пойми, исправь и попробуй следующий шаг. Благо, народу, с гонором объясняющего базовые принципы, по форумам полно, и ответы есть на все вопросы.

Методами интенсификации умственной деятельности я начал интересоваться ещё в школе. Правильные методики разработки софта ищу с тех пор, как начал программированием зарабатывать деньги. То есть, где-то с третьего-четвёртого курса. За это время перечитал массу бреда, включая свежие статьи в профильных журналах и спецификации стандартов. Плюс кучу книжек по организации деятельности от американских бестселлеров до советских учебников по психологии. Ну и, конечно, genchi genbutsu, то есть сам приложил руки к реальным делам во многих проектах.
Видел много чудесного и прекрасного. Но всё не решало, а чаще всего ухудшало основной принцип неопределённости умственной деятельности: «Или у нас хорошая отчётность, или у нас хороший результат»
Плюс все методики не стабильны.
Мы можем выделить группу из трёх предсказателей, которая на больших проектах в стабильных условиях на заданной группе выдаст прекрасную точность. Но всё летит к чертям, когда вдруг в техзадание влезают не учтённые, но совершенно критические требования, или бюджет внезапно схлопывается в два раза.
Мы можем три года аккуратно вести проект по gnatt, точно вписываясь в дидлайны и победно отчитываясь по каждому этапу. Но за три месяца до сдачи вылезают незамеченные мелочи, и вся красота идёт в мусорное ведро, а реальность улетает куда-то в туман.
И да, agile. Люди работают, клиент доволен. Что получается, не понятно, зато постоянно у клиента есть игрушка. Пока внезапно он не понимает, что это игрушка которая игрушкой и останется. Потому что где-то в глобальных принципах какие-то траблы, архитектура ни к чёрту, кодировщики уже на сто процентов заняты только тем, что загоняют в код ошибки, а потом мужественно их исправляют, при этом куча важных, само собой разумеющихся (для специалиста) требований в продукт просто не вошла. И никогда не влезет, потому как фундаментальные решения были не те, что нужно.
Единственное, если маленькой сплочённой группе дать чёткое задание, желательно в области создания чего-то для программистов, и оставить их на долгое время в покое, они выдадут что-то интересное. Но ни предсказать, что это будет, ни с уверенностью сказать, когда это случится и случится ли вообще, мы не можем.
Короче, все известные методики и подходы не выдерживают требования предсказуемости, правдивости и стрессоустойчивости. Что-то полезное нашёл только у Барбары Шер и у Тойоты. (У последней, естественно, не в конвейерных сказках про lean и kanban, которые они продают миру, а во внутренних методиках, которые они тщательно прячут и упоминают лишь изредка и очень туманно.)
Короче, методика, которая мне нужна, применяется на любой деятельности, говорит правду, не создаёт панику, точно описывает настоящее, точно предсказывает и помогает контролировать будущее. При этом она должна быть стабильна и масштабируема до одного человека. Последнее требование, вынесенный в заголовок NullPlus, просто даёт гарантию, что всё будет работать даже в ситуации, когда ни времени, ни бюджета, ни ресурсов нет. То есть, методика будет экономить время и силы даже в ситуации нуля, желательно помогая выгребать из минуса.
Из работающих и давно применяемых компонентов могу упомянуть лог проекта. После игры с разными тулами, форматами и способами всё стабилизировалось на банальном текстовом файле с отметками дат и простым нумерованным списком произошедших за день событий. (В принципе, у меня сейчас лог - это только конец файла, растущий вниз, есть и другие разделы для агрегации и контроля, но это уже совсем другая тема.)
Выяснилось, что это наиболее надёжный и удобный способ. Можно писать толстые документы, использовать архивы мейлов, извращаться с баг треккингом, шарепойнтом, вики, ньюсами, но, если решения, задумки и достижения не ложатся в несколько строк текстового файла, контроль за происходящим потерян.
Естественно, вся красота и мощь автоматизации живёт параллельно и несколько сбоку. Иногда со ссылками из текстового лога, иногда с упоминаниями, иногда просто как свалка для отчётности. Если что-то нужно быстро понять, вспомнить или повторить, всё ищется в банальном простом текстовом файле, содержащем всё важное, и только это.
Базовая теория для удовлетворяющей меня методики предсказания и планирования начала вырисовываться в девяносто седьмом году прошлого века. С тех пор ищу, как это реализовать на практике.
То, что мир избавлен от пары-тройки хитроумных тулов, это только благодаря тому, что я, в отличии от большинства представителей кнопкодавов, сначала пытаюсь обкатать теорию на практике в ручном режиме или на прототипах. Несколько образцов хорошо вписались во все требования, включая неожиданные заскоки техзадания и точность предсказания. Они прошли практически все испытания. Кроме испытания ленью.
По характеру работы мне любой контроль абсолютно пофиг. Точнее, я знаю, что надо, и сделаю к сроку. Или скажу, что сделать невозможно. И это без всяких тулов, ничего не записывая.
По этой причине, когда проект становился совсем грустным, и скачки переходили в механизированную эмуляцию передвижения загнанных лошадей, все прототипы медленно застывали. В основном потому, что они показывали реальное положение вещей, которое было абсолютно не мотивирующим.
Короче, лень и пофигизм - это реальный параметр, который в полевых условиях будет гробить любое развитие тестируемого образца. И пока что все прототипы на этом ломались.
Но в этом году наконец-то найден способ, побеждающий лень и сохраняющий фактор кайфа при любом развитии событий. (А с загнанными лошадьми и на этот раз всё было стандартно.)
Конечно, в полной реализации для нормальных людей это всё будет выглядеть совсем по-другому. И что-то годное для рынка можно сделать, только вложив разработку, судя по аналогам, порядка трёхсот тысяч.
Это ещё не решение. И даже не направление движения. Просто проблеск идеи. Но мне понравилось. И теперь понятно, куда идти дальше.
Под катом семь месяцев за полторы минуты в 9 мегабайтах.

Если картинка не движется секунд 10, её надо перегрузить. FFox у меня показывает анимацию через раз.
(frozen) Важные цитыты из комментариев
Date: 2018-12-29 08:47 pm (UTC)Делать программную связку можно элементарно даже на этом этапе (потому как оно парсится по отметкам и ключевым словам), но она нафиг не нужна. Это разные области, у которых разные задачи и в большом проекте таким занимаются разные, не пересекающиеся друг с другом люди.
Практически на картинке стоит что и в каком порядке надо делать и когда это сделано или изменено, а в логе подробности того, как именно и что именно делается, включая тупиковые ходы, команды вызова тестовых скриптов и отметки о презентациях и переговорах.
...
Ну и какая радость будет от подобной информации. Оно же строится под потребности каждого проекта по-новой.
Впрочем, принципы я где-то тут уже описывал. Особенно, по поводу организации мейлов.
Ну вот с предыдущего проекта. Почти всё, кроме конкретики
...
Проблема в том, что нельзя сделать из кучи дерьма конфетку. Думать надо было с самого начала. (И не отдавать куски кода в Бангалор)
Потому гораздо больше нравится делать что-то новое с нуля, чем присобачивать заплатки на старую систему.
На самом деле часто приходится делать или перемычки (интерфейсы между ужасом в библиотеках или форматом данных) для новых систем. Или вообще заниматься археологией, добывая смысл из старого плохо документированного кода. В последнем случае делается просто нормальное техзадание и вменяемый дизайн, после чего весь ужас переписывается снова по-человечески. (Желательно вменяемыми людьми.)
И то, и то, сложная ручная интеллектуальная работа, автоматизируемая лишь частично. Потому как надо не только понять, что в коде, но и, "что думал этот идиот, пытаясь решить задачу этим способом?"
Формальные языки спецификаций есть, но они только изредка применяются в университетах и на реальных проектах и на реальных программистах не работают.
...
Количество факторов, о которых надо думать, конечно. И достаточно невелико. То, что оно превосходит возможности "среднего программиста", говорит только о качестве этих средних.
Ну плюс стоит это немного дороже сначала, когда в софт вкладывают смысл, а не собирают кучу "как получится"
...
Увы и ах, но если камень берега для создания моста не подходит, мост переносят, делают другую конструкцию (за другую цену) или вообще не строят.
...
Во многих случаях умные люди просто отказываются делать проект, если не видят возможности его завершения. (Инженерный подход) Но ещё более умные берутся делать, в надежде вытянуть у клиента денег на "доделки". (Менеджерский подход) Потому в индустрии стандартом является пролёт мимо сроков и качество ниже плинтуса.