1. Заходим на вкладку лист; 2. Нажимаем комбинацию кнопок Cntrl+P либо кнопку печать в главном меню; 3. В меню печати нужно выбрать PublishToWeb JPG 4. После выделяем рамкой нужный нам чертеж 5. Выбираем формат листа; 6...
Метод прогрессивного джипега в разработке В начале десятых, в самом начале своей карьеры я прочитал про метод прогрессивного джипега у дизайнера Лебедева в Ководстве. Идея такая: вместо того, чтобы делать работу сразу в финальном качестве по чуть-чуть, мы делаем сначала все «крупными мазками», а потом уточняем детали и полируем. Таким образом, в любой момент у нас готова какая-то версия, пусть и не до конца проработанная. Тогда я не до конца понял суть этой идеи. Думал, что это, в первую очередь, про макеты дизайна. И только с опытом я стал понимать, что такой подход работает и в разработке. Например, мы пишем сервис, который сжимает картинки, кладет их в s3 и присылает нам ссылку. В первый же момент мы можем его замокать — прямо на уровне документации к API, в swagger, например. Во-первых, фронтэнд может уже завязываться на ручки. Во-вторых, нам сразу видно что на входе и что на выходе у нашего сервиса. Следующей итерацией мы можем написать болванку, которая будет подключаться к готовому бакету и класть картинку без изменений. Потом докручиваем создание бакетов, сжатие джипегов. Только когда это заработает, разбираемся со счетчиками, форматами изображений, проверками безопасности. Ну и так далее. Такой подход помогает не тормозить коллег, которые будут завязываться на нашу работу. Полезная скорость работы возрастает многократно — для всех вокруг у нас все готово уже вот прямо сейчас и не важно, что мы докручиваем детали. Сравните это с ситуацией, когда до первого релиза мы бы стали доводить до блеска работу с тысячей форматов. А главное, сразу увидеть проблемы, которые можно не заметить, если сразу закопаться в детали. А недавно, мой коллега показал мне еще одну грань этого метода. В первый же день он выкатил эхо-сервис, который ничего не делал полезного, но у него уже были ручки в проде, графики в графане. Еще через пару дней сервис стал «прозрачным» и прогонял через себя запросы без изменений, зато уже считал их количество и видно было с какой нагрузкой он потенциально справится. Ну и потом уже появились все нужные протоколы взаимодействия, метрики, оптимизации. А параллельно с этим, другой коллега пошел обратным путем — сначала пытался изучить все корнер-кейсы и подготовится к ним. И когда дело дошло до первого релиза, оказалось, что не так-то просто зарелизить всю подготовленную «громадину». Да и необходимость уже во много отпала. Итог: первый сервис активно внедряется, а второй так и не родился. Удивительно, но в управленческих кейсах это тоже работает. Лучше не идеальный процесс, чем не внедренный. Лучше сначала построить схему целиком, а потом уточнять детали, чем закопаться в первый же блок. Наверное, есть области, где это не так. Наверняка, ракету построить таким способом очень сложно. Но в большинстве применений, который встречаются мне, этот метод показывает себя с лучшей стороны. Буду рад, если поделитесь кейсами, которые это подтверждают или опровергают. Это экспериментальный пост для этого канала. Поставьте, пожалуйста, реакцию стоит ли такое писать или оставить канал больше для анонсов подкаста?