Хочу немного рассказать про полезную рабочую практику, которая уже не первый год здорово помогает мне. Как ни странно, далеко не все разработчики этим пользуются. Наверно, большинству просто не приходило в голову. Заполним пробел, проведём сеанс ликбеза.
Сама идея рабочего дневника очень простая. Начиная работу над очередной задачей, я завожу в специальной папке новый текстовый файл. В него пишу все мысли, которые приходят в голову во время работы над этой задачей:
- Какую проблему я решаю
- Какие действия планирую совершить и в каком порядке
- Какие действия уже совершил, и к чему они привели
- Какие у меня есть предположения о характере проблемы
- Какие сложности и непонятки возникают
- С кем из коллег и по какому вопросу надо поговорить
- Что мне мешает сделать следующий шаг
- И прочее в том же духе
В общем, стараюсь сохранять всё более-менее полезное.
Выглядит это обычно как-то так:
Как именно это помогает
Разгружаем голову! Чем больше мыслей нужно держать в памяти одновременно, тем меньше ресурсов остаётся на сами размышления. Записывать все планы и задачи — базовый принцип техники GTD. Для разработчиков это особенно актуально: обычно нам приходится иметь дело с очень сложными задачами, которые сложно загрузить в голову целиком. Скидывая мысли и идеи в дневник, мы освобождаем голову для размышлений.
Проще вспомнить подробности решения задачи. Для многих программистов (и для knowlege workers в целом) самым продуктивным режимом работы является "поток" — полное погружение в одну задачу. Длительная концентрация внимания на одной цели без переключений на другие. Тем не менее, рано или поздно приходится делать перерыв и заниматься чем-то другим (хоть даже домашними делами), а к текущей задаче возвращаться спустя некоторое время. С помощью дневника можно быстрее вспомнить, на чём мы остановились в прошлый раз, и куда надо двигаться дальше. Экономится время и силы на возврат в поток.
Также порой приходится обращаться к старым задачам спустя месяцы и годы, чтобы повторить их или хотя бы выяснить подробности сделанного. Голова уже не сможет удержать всех нюансов задачи спустя такой промежуток времени. А с записями ничего не случится.
Сохраняем маленькие полезняшки. Например, найденные в процессе работы ссылки. Или полезные сниппеты кода. Когда в следующий раз потребуется подобный кусок кода, не придётся восстанавливать его по памяти. Можно будет просто найти в дневнике через поиск.
Формализуем непонятную проблему — так её легче решать. Многие знают так называемый "метод утёнка", который помогает решать непонятные вопросы. Подробно рассказываешь свою проблему слушателю (в роли которого может выступать даже простая игрушка), и нередко получается так, что пока формулируешь проблему, мозг находит её решение.
Такой подход замечательно работает и без слушателя! Достаточно лишь взять и подробно расписать свою проблему в дневнике, чем подробнее, тем лучше. И это классно, особенно для интраверта: тихо что-то сам себе печатаешь и сам находишь решение. Ни с кем разговаривать не нужно — красота!
Решение сложной технической задачи нередко напоминает блуждание по лабиринту. Двинулись в одну сторону — наткнулись на стену, пошли в другом направлении — встретили пропасть. По ходу дела обнаружили сокровища в боковом туннеле, но сразу взять не получилось. Рабочий дневник — это карта лабиринта, со всеми его поворотами, западнями и ништяками.
Недостатки дневника (или нет?)
Несложно увидеть и слабые стороны этого подхода. Впрочем, не такие уж они и страшные!
Дополнительная трата времени. Да, ведение дневника отнимает достаточно много времени. Не во всех случаях можно позволить себе такую роскошь. Позволительно ли записывать свои планы в дневничок, когда нужно срочно накатывать фикс на упавший прод?
С другой стороны, авральное состояние — вещь достаточно противоестественная для интеллектуального работника. В таком режиме сложно делать вещи качественно, очень возрастает риск где-нибудь ошибиться. Ошибки приводят к новым авралам, а там недалеко и до сваливания в смертельный штопор!
В такие моменты бывает лучше притормозить, немного подумать, чётко осознать причины проблемы — и сделать всё правильно. Не так уж редко оказывается, что первое пришедшее в голову решение правильным вовсе не является. Думаю, вы уже поняли, к чему я веду: замедляться при решении задач бывает не только не-вредно, но и полезно. И дневник в этом только поможет!
К слову, ничто не мешает описать сделанную работу в дневнике сразу после аврального фикса.
Alice Sleeping
Дублирование работы. Уверен, у многих читателей к этому времени уже созрел такой вопрос: "У нас ведь уже есть командный таск-трекер, разве его недостаточно для журналирования?"
Однозначного ответа на этот вопрос у меня нет. Обстоятельства у всех разные, и было бы неправильно подходить ко всем с одной меркой. Могу сказать лишь за себя самого. В дневник я позволяю себе записывать абсолютно что угодно. Самые мелкие напоминалки для себя, вопросы "эту штуку сделал, что делаем дальше?", ключевую фразу "я туплю" и так далее. Порой это десятки записей в день! Если всё это писать в таск-трекер, коллеги взвоют из-за объёмов спама и навечно забанят меня.
Поэтому в трекер уходят только отфильтрованные записи. Copy & paste, copy & paste… Дублирование усилий получается, но не настолько уж большое. Суммарные преимущества дневника всё равно перевешивают.
Лень вести дневник. Пожалуй, самый весомый и самый серьёзный недостаток. Безусловно, на работу с дневником приходится тратить заметное количество сил и внимания. Мозг сопротивляется этому как может. Уж что-что, а экономить энергию он любит, хотя и не всегда делает это в правильных местах.
Бывали и у меня периоды, когда я сдавался и временно отступал от ведения дневника. Но всё же неизменно раз за разом возвращался к этой практике, слишком уж велики её преимущества!
Как же сделать так, чтобы лень не вставала на пути? Пара советов у меня найдётся. Самое главное — стараться сделать ведение дневника максимально удобным и приятным занятием. Использовать любимый текстовый редактор, сократить объём вспомогательных ручных действий, минимизировать неудобства и сфокусироваться на главном — фиксации важных моментов.
Ещё неплохо помогает формальный подход. Максимальное сопротивление мозг оказывает тогда, когда записей по задаче ещё нет, но в голове уже куча идей, и хочется поскорее все их проверить в деле. Важно в этот момент — в самом начале работы над задачей — применить волевое усилие и напомнить самому себе: "у меня есть правило, что я веду дневник". Создать файл и записать в него все свои идеи. Остальные записи уже пойдут гораздо легче.
Полезные приёмы
Упомяну также несколько дополнительных хитростей, которые помогают в работе над дневником.
Выбираем формат дневника. Простого plain text не всегда бывает достаточно, когда мы работаем с кодом. Сам я использую markdown и вполне им доволен: синтаксис поддерживается всеми популярными редакторами, удобно визуально выделять заголовки, код, цитаты и т.п. Но остерегусь навязывать Markdown читателю. У этого формата есть альтернативу, например: Restructured Text, Wiki, Orgmode. Главное, что требуется от формата — не вызывать раздражения при чтении и записи — ведь иначе дневник долго не проживёт!
Используем сниппеты. Некоторые операции приходится чаще других при работе с дневником. Например, я привык начинать очередную запись с отметки времени, чтобы потом проще было ориентироваться. Довольно очевидно, что вводить дату каждый раз руками слишком утомительно (порой десятки раз в день!). Здесь стоит обратиться к возможностям текстового редактора, чтобы облегчить себе труд. Я привык работать в Vim, а для него есть отличный плагин Snipmate. Теперь мне достаточно написать слово time, нажать Tab — и отметка времени генерируется автоматически! Аналогичные примочки есть, пожалуй, у каждого продвинутого тестового редактора.
Храним бэкапы. Чем дольше вы ведёте дневник, тем большую ценность начинает представлять сохранённая в нём информация. Не лишним будет позаботиться о её сохранности! Я настроил автокоммит в git и бэкап в bare-репозиторий внутри Dropbox по cron-у. Теперь можно спать спокойно и не бояться, что дневник пропадёт вместе со сдохшим диском.
Расписываем контекст со всеми подробностями. Не очевидный, но очень существенный момент! Во время работы над задачей много вещей кажутся очевидными, поэтому они могут не попадать в дневник. Но вот проходит какое-то время, и весь контекст вытесняется из памяти. Открываем дневник заново, видим какие-то обрывочные записи и ничего не можем вспомнить. Восстановить удастся только то, что было записано.
Представим, что мы работаем над веб-приложением, и натыкаемся в нём на ошибку. Много ли будет пользы от дневника, который ведётся так?
Я что-то нажал, и всё сломалось :(((((
Куда полезнее будет, если в запись попадёт и конкретная страница приложения, и проблемная кнопка на ней, и текст ошибки.
В заключение
Я не претендую на лавры первооткрывателя этого метода. Прошаренные товарищи с успехом используют его уже не одну сотню лет.
Неожиданной может показаться разве что мысль, что рабочий дневник окажется полезен не только маститому изобретателю, но и скромному трудяге-программисту. Но это так. Дневник — один из инструментов, облегчающих путь к вершинам профессионального мастерства. Каждый сам волен решать, применять ли его в своей работе. И я буду рад, если моя статья хотя бы ненамного увеличит число тех, кто готов попытаться!
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (87)
intsurfer
20.03.2017 10:57+1в свое время пытался вести похожий дневник с находками, полезными ссылками и т.п. причем не только в области программирования, но и по своим хобби. Заглохло по простой причине — вся информация устаревала очень быстро. И стало намного проще при необходимости погуглить и найти более свежую информацию.
erwin_shrodinger
20.03.2017 11:43+1вот это и называется «начало конца»
1 день без интернета ставит разраба в ступорintsurfer
20.03.2017 12:12+2а что, много разрабов помнят ВСЕ функции, классы, их детальное описание и т.д.? С чем работаю постоянно, то не гуглю. Наверное я не один такой.
j_wayne
20.03.2017 12:17+4Я думаю, без интернета программировать возможно, если вы скажем программируете под голый attiny13 и заучили все наизусть. Ну или у вас абсолютно core java, скаченный javadoc и сферические задачи в вакууме. И никакой интеграции с внешними системами.
А еще абсолютно безглючная ОС и средства разработки.erwin_shrodinger
20.03.2017 13:54-1Сарказм излишен.
Следует учиться работать с локальной справкой + опыт, полученный горькими слезами и днями/неделями в поисках решения, запоминается гораздо сильнее и заставляет порой сильно осмыслить всю внутреннюю структуру используемой технологии. А ответ полученный за 15 сек в гугле или на стэке ещё через 15 секунд будет забыт к ендрене-матери.
«Дневник» (если я правильно понял мысль автора) в данном случае всё же следует использовать не как замену google, а как дополнительный swap раздел, помогающий освободить место в оперативке нашего мозга для поиска решения задачи.j_wayne
20.03.2017 14:01>> опыт, полученный горькими слезами и днями/неделями в поисках решения
Мы видимо в каких-то очень разных реалиях живем, если у вас есть на дни и недели(!) возможность. У вас есть вакансии?)
Фронтендом не занимаетесь видимо? Локальная справка, хах))
Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.erwin_shrodinger
20.03.2017 14:30Пообщайтесь с другими системными программистами, познаете «нашу реаль»)
j_wayne
20.03.2017 14:37+2Ах, вот оно что. Теперь понятно. К сожалению, в современном вебе это [тру локальная работа] практически нереально.
3aicheg
21.03.2017 07:15Следует учиться гуглить за 15 сек в гугле даже то, что сам давно и чётко знаешь, как делать. Зачастую узнаёшь много нового. В худшем случае (или в лучшем, как посмотреть) зря теряешь 15 сек.
zloddey
20.03.2017 11:46+10Полезнее записывать в дневник собственные идеи, планы, шаги. Это принципиально не гуглится и устаревает медленнее, чем внешняя информация
m1n7
20.03.2017 11:22+1За год скопилась пятисантиметровая стопка черновиков. Но поскольку на каждой странице что-то нарисовано, не представляю, как это перевести в электронный вид.
А ещё ко всем этим записям обращался ровно один раз. Комментарии в коде рулят.BlackMustang
20.03.2017 18:28-1А я свой блокнот просто отфотографировал, и картинку каждой страницы по темам отсортировал. Т.е. когда надо по теме быстро найду нужную картинку.
muxa_ru
20.03.2017 11:27+3Ещё один плюс записывания мыслей в текстовик — он [текстовик] не зависит от прогресса.
Баг трекеры и таск менеджеры могут поменяться и старые данные не будут перетащены в новое место, а текстовый файл всегда с тобой :)
BelerafonL
20.03.2017 11:43+1А мы на фирме ведем похожие «групповые» дневники в эверноуте по проекту. И туда всей командой пишем кто что делал, что надо делать. И картинки можно вставлять, и документы — удобнее, чем текстовый файл. Если хочется писать очень много «спама», можно сделать личный дневник, куда писать будет только один человек, но читать при желании смогут и вникать в курс дела все в команде.
devrow
20.03.2017 11:44+1Делаю тоже самое, только некоторые пункты отсутствуют.
За несколько лет получился очень даже приличный FAQ для себя.
Например, всякие особенности разных языков пр-ия.
Все это хозяйство просто отсортировал по по темам.
Оказалось, что это очень удобно, если вдруг в либе на си или си++, перле что-то придумано удобнее, чем в <вписать нужный язык>.
sbnur
20.03.2017 11:48+1Видится, что вы духовный наследник профессора Любищева — рекомендую ознакомится с его наследием по организации рачего времени — очень познавательно
overmes
20.03.2017 12:01+1А если вы уйдете из этого проекта, кто-то будет читать ваш дневник?
Код писать проще чем его читать!
Так что я обычно делаю так:
- Все пришедшие в голову случаи оформляем сразу в тесты
- Все принятые технические решения оформляем в виде комментариев, желательно и все отброшенные варианты(можно ссылкой на вики)
- Записываем для себя что-то во время написания кода для облегчения его написания или для поиска красивой архитектуры
farcaller
20.03.2017 12:01+6А почему текстовый файл? Почему не хардварное решение? Иногда отвлечься от клавиатуры и монитора не менее полезно. Еще хорошо помогает набор цветных ручек/маркеров/карандашей по вкусу.
zloddey
20.03.2017 12:18Бумагу использую, но в меньшей степени. В большом блокноте очень удобно заниматься дизайном систем (стрелочки-квадратики рисовать), но писать там код или стектрейс — увольте!
copist
20.03.2017 12:23+3Помню одного своего коллегу. Он когда говорил, обязательно при этом рисовал абстракции без подписей. Квадратики, кружочки, треугольники, стрелки. Ни одной надписи. По окончании разговора он вырывал лист из блокнота и отдавал. Но если я сам к этим абстракциям не приписывал надписи, на следующий это был просто листок с квадратиками и стрелками. Один из многих в моём столе. Один от другого не отличишь.
:)
jacob1237
20.03.2017 12:39+1К сожалению с бумажным вариантом комбинации Ctrl+F и Ctrl+C / Ctrl+V не работают :)
NikitaYakuntsev
20.03.2017 18:28Ctrl+F
Отметил для себя, что в этом случае развивается зрительная память. Где-то в голове у меня построены индексы, и я вспоминаю, что необходимая запись была сделана в нижней половине листа, а в верхней части была нарисована какая-то схемка + примерно ориентируюсь по времени, это помогает понять, в какой части блокнота находится запись. Тогда по небольшому range-scan быстро удается найти нужную заметку. Не так быстро, конечно, как в случае электронного варианта, но там тоже нужно помнить ключевые слова для поиска (например, номер тикета или места, где тупил особенно сильно, о чем сделал соответствующую пометку).
Draconian
20.03.2017 18:28Как минимум:
1) не у всех красивый почерк, знаю людей, которые свои собственные записи прочитать не могут через неделю
2) не всем нравится записывать ручкой в блокнот, клавиатура и быстрее, и правки вносить куда проще
3) занимает место, есть люди, которые кроме портмоне, телефона и ключей с собой ничего не носят
4) при утере\краже восстановить невозможно
5) записывать код в блокнот довольно бессмысленноzloddey
20.03.2017 19:256) Бумажные блокноты быстро заканчиваются, если использовать их более-менее регулярно. А поиск по старым блокнотам — удовольствие сомнительное
worldxaker
21.03.2017 16:487)отстаивает версионирование, да и вообще с редактированием много промблем
Vasily_T
21.03.2017 08:29Вот, это мой вариант, правда попроще — тетрадка в 48 листочков на проект (может быть несколько),
для себя нашел даже объяснение — мне так запоминать лучше и ориентироваться в них быстрее.
К сожалению, электронные ср-ва (файлы и т.п.) по удобству еще долго не дорастут до нужного уровня «комфорта взаимодействия»…
copist
20.03.2017 12:20+1Записывай всё — у меня куча способов вести записи. Вот собрать всё в один ресурс не получается. Медиа-записи мне нравятся больше. Видео-файлы, фотографии. Поэтому Evernote и GoogleDocs.
adrianov
20.03.2017 12:48+2Давно веду такой дневник. Сейчас пользуюсь Evernote. Когда-то пользовался просто Word, OpenOffice. В принципе, тут любой редактор подойдёт.
.jpg){kind=link}
sadsaviour
20.03.2017 12:50+1Веду подобные записи в Notion. В нем есть все прелести воркфлоу — шаринг, влажность и проч. При этом типов контента намного больше. В том числе блоки с кодом можно вставлять и маркдауном пользоваться.
Houston
20.03.2017 23:59+2Спасибо за совет, классный редактор, сервис и приложение. Но смущает ценовая политика – $8/month за онлайн-документы это немного жирно.
sadsaviour
21.03.2017 12:49Бесплатной версии достаточно для работы. Плюшки платного аккаута вроде слак нотификаций особо не нужны ведения дневника. А лимиты на создание блоков можно поднять за счет инвайтов друзьям.
akardapolov
20.03.2017 13:08Была бы возможность — носил бы с собой маркерную доску. Схемы на доску, потом в смартфон.
На доске легко можно поправить схему, текст — на бумаге с этим сложнее.
dmitry_hidden
20.03.2017 13:13советую посмотреть на Diigo как альтернатива evernotes
dimm_ddr
21.03.2017 12:12+1При беглом осмотре так и не понял возможно ли там вообще создавать заметки а не только вырезки из пдф и веб страниц. Несколько иной класс задач все же.
vikarti
20.03.2017 14:25+1Я Evernote использую. Очень удобно.
Пробовались всякие Dairy One (приложение под OS X) или просто текстовые файлы в конце дня отправляемые себе же на почту.
Был период когда использовался инстанс Atlassian Confluence но там главная проблема — с мобильного железа очень не удобно.
michael_vostrikov
20.03.2017 15:01+2Записываю, но не как глобальную базу, а конкретно заметки по проекту, иногда по отдельной задаче, если она большая. Надо сделать это, это и то, тут переделать, там отрефакторить, про это уточнить, что сделано ставлю плюс, что решено не делать минус, ссылки на документацию и примеры, этот компонент настраивается так, этот кусок кода оказался не нужен, но возможно потом пригодится...
ForeverYoung
20.03.2017 16:00Аналогично, записываю заметки типа какие тикеты в Code Review, чего сделать перед деплоем и т.д., в Scratch-файл в PyCharm/IDEA/..., главное — быстро открывается.
zloddey
20.03.2017 19:32Во-во-во, у меня очень схожий паттерн использования. Неоднократно замечал: стоит только поддаться лени и перестать вести журнал, как начинаешь моментально путаться во всех этих микротасках. Дело порой доходит вплоть до почти полной невозможности продвигаться вперёд. Но стоит открыть редактор и записать туда все вопросы по задаче, как сразу появляется понимание, за что взяться первым делом, что отложить на потом — и работа сдвигается с мёртвой точки!
lpre
20.03.2017 16:03+1У нас для похожих целей официально используются "Technical Design Notes" (aka Design Specification), в которой есть главы (помимо прочих) "Design Rationale", "Design Methodology", "Proof of concepts", "Risks and Volatile Areas". При этом некоторые (существенные) части (например, "Component Contract") используются для формализации и "распределения" процесса разработки.
"Живые" многопользовательские документы создаются в Polarion, с диаграммами, линками и проч. (хотя можно и другие инструменты использовать). Это позволяет создавать иерархически структурированные "дневники" (design notes) для сложных продуктов.
marenkov
20.03.2017 16:35+2Работаю под linux, использую zim. Все хранит в обычных текстовых файлах в дереве директорий и отображает в виде древовидной навигационной структуры. Использует wiki-форматирование, можно создавать списки задач и отмечать что сделано и что отклонено. Есть поддержка тегов для быстрого поиска. Версии хранит в git-e.
monah_tuk
22.03.2017 08:36+1Жаль, что плагины отличаются разной работоспособностью на разных платформах. Я используют на двух машинах: Linux — дома и Windows — работа, синхронизация через Yandex Disk (тут конкуррентность не проблема — я могу в один момент времени работать только в одной копии Zim, но если у кого есть другие предложения по поводу синхронизации, то я с радостью выслушаю).
Что удобно — это добавлять вложения. Особенно полезно, когда разбираешься с чем-то, где есть куча даташитов или прочей документации в PDF.
Ну и очень бы хотелось в Zim иметь какой-нить вариант GitHub Flavored Markdown
BelBES
20.03.2017 16:41+1Одно время вел заметки в Org'е, синхронизируя их через git-репозиторий.
Все уперлось в то, что идеи иногда приходят в голову в удалении от ПК, а подходящего карманного устройства для заметок, длинной больше одного твита, просто не существует.
В итоге сейчас пользуюсь бумажными записями, в которых по большей части фиксирую условия и результаты экспериментов, чтобы по прошествии времени можно было их воспроизвести.
з.ы. очень не хватает электронной записной книжки 2.0, с удобной клавиатурой для ввода текста на ходу...
KhaosKat
20.03.2017 18:29+1Для похожих целей использую Zim desktop wiki — локальная «вики» система, с поддержкой тегов, ссылок между записями, иерархической структурой записей, простым текстовым форматом хранимых файлов (та же иерархическая структура из папок и txt файлов), кроссплатформенная (+опенсорс)
Steed
21.03.2017 13:23Если концептуально нравится Zim, можно еще присмотреться к CherryTree. Он немного побогаче функционалом (например, имеет подсвеку синтаксиса, умеет рисовать таблицы), но базу хранит в xml/SQLite. Есть импорт из Zim. Но не умеет, к примеры, поддерживать список TODO.
В общем — дело вкуса, но хорошо, что есть выбор.
whitedruid
20.03.2017 21:10+1Спасибо за статью!
Хотел бы поделиться своим опытом.
Много лет использовал для ведения записей простыми текстовыми редакторами: «Блокнот» в OS Microsoft Windows или vi — в UNIX. Честно скажу, что всегда не хватало системы контроля версий (хотя бы в самом простом виде) и возможностей синхронизировать между ПК. Разумеется, Evernote и подобные решения существуют не один год, да и сложно адаптироваться к новым интерфейсам в повседневной жизни. В конце концов, нашел для себя следующий выход: VPS с OS Linux с установленным ownCloud (для синхронизации), традиционный «Блокнот» или viM, а также скрипт в несколько строк кода — для бэкапа в публичное облако. В последнем случае, разумеется, проводится обработка файла с помощью GnuPG. С версиями решил все просто — добавил в viM хоткей для создания файла с другим именем.
Даже не буду спорить, что все мной изложенной — очевидно и примитивно :) (А также имеет недостатки), но лично мне — это кажется удобным и по этой причине решил поделиться решением.dimm_ddr
21.03.2017 12:16А почему не гит? Можно даже свой сервер не поднимать, а взять тот же bitbucket. Если сервис вдруг ляжет — ну так локально проект же есть, его всегда можно будет загрузить на новый. Я не пытаюсь доказать что это удобнее, просто интересны причины именно такого решения.
AWSVladimir
20.03.2017 21:38MindJet — карты памяти.
Есть возможность работать с картой или обыкновенным списком.
Можно вставить любой файл или диаграмму
+ есть мобильная версия.
roman_kashitsyn
21.03.2017 01:37Непонятно, почему не писать это комментариями в тикеты в вашей любимой Jira/Redmine/что-там-у-вас. Так не только вам, но и всей команде будет видно, что сделано по задаче, и какие есть догадки. Да и менеджерам будет видно, что работа ведётся.
А то воспроизводишь багу, находишь соответствующий закрытый тикет в трекере, а там один комментарий от разработчика год назад — "Fixed".
monah_tuk
22.03.2017 08:50Это организационный просчёт. Нужно вводить обязательное поле Analysis Information, в котором, хотя бы, указывать ссылку на комментарий, в котором этот анализ написан или на вложение, если это вложение — переписка из почты. Ну и соответственно карать за его пустоту.
roman_kashitsyn
22.03.2017 12:36обязательное поле
Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.
Я просто не вижу смысла вести какой-то дневник с описаниями того, что и как нужно сделать в рамках конкретной задачи, когда для этого существует баг-трекер. Тикеты в баг-трекере — это и есть персональный дневник каждой баги, только доступный всем членам команды. Туда лучше писать вообще все действия, выполненные в рамках задачи, важные команды, которые выполнял в терминале, вывод этих команд, результаты коммуникации и решения, ссылки на код-ревью и коммиты, etc.
Если утром не помнишь, что нужно делать — открываешь баг-трекер, тыкаешь в самую приоритетную задачу и читаешь последние записи.
Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.
monah_tuk
22.03.2017 15:05+1Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.
Вот в чём дело: если всё оставить на самотёк, то от системы тикетов останется одно название: вроде и есть, а толку чуть (ну по крайней мере видно: кто и когда завёл, кто и когда решил). Собственно, если за такое не журят, значит никто трекер не мониторит, значит информация оттуда никому не особо нужна.
Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.
Да я собственно с этим и не спорил, каюсь, нужно было процитировать то, на что отвечаю. Сам я заметки делаю ручкой в блокноте: быстрее и на родном языке, можно писать в любом направлении и оперативно делать простые схемы/графики. Да плюс можно просто писать поток сознания, которому не место на всеобщем обозрении :) Хотя такой формат часто систематизирует знания и факты и позволяет найти решение. В любом случае — потом результат анализа нужно оформить в тикете. Так что здесь у нас расхождений нет.
SoloMidPlzD
21.03.2017 08:29а я просто пишу в блоггер новий пост.
monah_tuk
22.03.2017 08:50+1Одно другому не мешает :) Я в Zim иногда накидываю просто заметки, ссылки, а потом формулирую из этого мысль в виде блого-поста.
niya3
21.03.2017 08:29Обычно c++filt после perf report не нужен.
$ man perf-report
--demangle
Demangle symbol names to human readable form. It’s enabled by default, disable with --no-demangle.
Здесь предлагают пересобрать perf.zloddey
21.03.2017 08:53Обычно не нужен, да. Но в RHEL и его производных (где приходится работать) в репозиториях часто находятся достаточно старые версии пакетов. В частности, старый
perf, у которого опция--demangleработает как-то не так. Конечно, я попробовал её в первую очередь, а кc++filtобратился только уже после, когда выяснил, что самperfне может нормально транслировать символы C++.
Смысла в пересборке в данном случае не вижу, если честно.
c++filtстоит в системе по-умолчанию, пайп написать тоже несложно. Со сборкой будет куда больше возни.
Но за комментарий всё равно спасибо!
lanseg
21.03.2017 11:11+1Сам пришёл к такой идее в своё время. Вначале вёл полноценный дневник, но он отнимал слишком много времени и я ограничился записыванием выполненных задач с какими-то своими пометками — для отчетов удобно, достаточно скопипастить текст.
От бумажного блокнота отказался, потому что в нём нет навигации, поиска и редактирования. Об эвернотах и разных облачных решениях даже не думал, потому что данные из них неудобно парсить, да и информация бывает только для внутреннего корпоративного пользования.
В итоге, поднял локально dokuwiki.
SantyagoNN
21.03.2017 11:51Если на поиск решения задачи в интернете уходит мене 2-3 минут, я ее не сохраняю. Если более, то записываю, а также записываю те задачи, которые имеют несколько шагов решения. Под линуксом пользуюсь CherryTree.
Apokalepsis
21.03.2017 15:56+1Тоже стал это использовать. Стал как вести дневник, так и дополнительную документацию ввести. Максимально подробно. В итоге кажется, да, вроде тратится много времени. Но когда тебе нужно решать похожие задачи, твой дневник и документация так сокращает время, что ой ой.
Использую GitBook Editor для записи большой общей документацией которая может пригодится в любом проекте/задачи. Для заметок по конкретному проекту, делаю отдельную папку doc, в отдельном файле заметки/мысли в других уже более конкретная документация которую переношу из файла с заметками, в основном для редактированию использую встроенный markdown редактор phpstorm или Mweb.
the_vi
23.03.2017 14:16Мне очень нравится список вопросов который вы задаёте (для создание самой записи в дневнике).
Можете его расширить, при случае?
maxru
Портабельная wiki в одном HTML файле вам в помощь :)
http://tiddlywiki.com/
zloddey
Спасибо за ссылку, обязательно изучу.
В своё время пробовал какие-то варианты с вики, но оказалось, что мне всё же удобнее вести документацию в том же редакторе, где я правлю код (обычно это gvim). Просто меньше действий надо делать, чтобы переключаться туда-сюда. Удобство ведения дневника часто оказывается решающим фактором для выбора инструмента. Поэтому текстовые файлы победили.
Rastishka
Мне нравится workflowy.com
Простой как нотепад, но обладает мегаважными фичами:
+ древовидность => инфа структурирована
+ онлайн => всегда синхронизирован с мобилой и несколькими компами (если нет инета, сохраняет в кеше и потом синхронизирует)
+ возможность расшарить кусок дерева и редактировать совместно
zloddey
Хм, тоже весьма интересно! Некоторых фишек вроде зумминга очень не хватает в других менеджерах
Di9
очень интересный сервис :)
А есть такой-же, но оффлайновый? а то в наши дни стартапы имеют привычку закрываться как только ты начинаешь ими активно пользоваться…
Rastishka
Сервис существует довольно давно (7 лет я им пользуюсь), достаточно популярен, даже на хабре его часто упоминают.
На платном тарифе есть синхронизация в дропбокс JSON файлом и отправка на почту списком.
Так что вы зря волнуетесь.
gks
Почему бы не писать дневник в самом коде? В качестве комментариев в начале. Тогда есть привязка к задаче и не только Вы видите, с чем столкнулись и работали. Просто по датам, не совсем удобно, нужно еще вспомнить когда решал ту или иную задачу. И по названием, тоже не очень. Так как тоже нужно вспомнить как назвал. А так при работе с кодом можно найти, когда нужно. В коде нет того официоза, все для своих. Можно особо не фильтровать.
shakhnur
По поводу комментарии написали же чуть выше… Комментарии так и так пишется… Но поднимать весь проект и тд и та… Я по началу использовал обычную тетрадку, а когда понял о необходимости сразу же разработал себе небольшое приложения которая лежит на хостинге… все просто, удобно, всегда есть доступ. Там создаешь проект а внутри записи разного статуса (идея, что надо делать, что сделано, ошибки и из решения и тд) время добавления записи автоматически добавляется… фильтр и поиск работает. С одним словом все работает именно так как тебе хочется… ооооочень удобно))
dezconnect
vi хватит, вики не нужна.
playermet
Могу посоветовать Flashnote.
Плюсы: древовидность, легковесность, бесплатность, портативность.
Киллер-фича: мгновенное сворачивание/разворачивание по глобальному хоткею.
Минусы: plain text only.