20 марта в 10:15

Рабочий дневник программиста

boat_journal
wikipedia.org


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


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


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

В общем, стараюсь сохранять всё более-менее полезное.


Выглядит это обычно как-то так:


example


Как именно это помогает


Разгружаем голову! Чем больше мыслей нужно держать в памяти одновременно, тем меньше ресурсов остаётся на сами размышления. Записывать все планы и задачи — базовый принцип техники GTD. Для разработчиков это особенно актуально: обычно нам приходится иметь дело с очень сложными задачами, которые сложно загрузить в голову целиком. Скидывая мысли и идеи в дневник, мы освобождаем голову для размышлений.


Проще вспомнить подробности решения задачи. Для многих программистов (и для knowlege workers в целом) самым продуктивным режимом работы является "поток" — полное погружение в одну задачу. Длительная концентрация внимания на одной цели без переключений на другие. Тем не менее, рано или поздно приходится делать перерыв и заниматься чем-то другим (хоть даже домашними делами), а к текущей задаче возвращаться спустя некоторое время. С помощью дневника можно быстрее вспомнить, на чём мы остановились в прошлый раз, и куда надо двигаться дальше. Экономится время и силы на возврат в поток.


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


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


Формализуем непонятную проблему — так её легче решать. Многие знают так называемый "метод утёнка", который помогает решать непонятные вопросы. Подробно рассказываешь свою проблему слушателю (в роли которого может выступать даже простая игрушка), и нередко получается так, что пока формулируешь проблему, мозг находит её решение.


Такой подход замечательно работает и без слушателя! Достаточно лишь взять и подробно расписать свою проблему в дневнике, чем подробнее, тем лучше. И это классно, особенно для интраверта: тихо что-то сам себе печатаешь и сам находишь решение. Ни с кем разговаривать не нужно — красота!


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

Недостатки дневника (или нет?)


Несложно увидеть и слабые стороны этого подхода. Впрочем, не такие уж они и страшные!


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


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


В такие моменты бывает лучше притормозить, немного подумать, чётко осознать причины проблемы — и сделать всё правильно. Не так уж редко оказывается, что первое пришедшее в голову решение правильным вовсе не является. Думаю, вы уже поняли, к чему я веду: замедляться при решении задач бывает не только не-вредно, но и полезно. И дневник в этом только поможет!


К слову, ничто не мешает описать сделанную работу в дневнике сразу после аврального фикса.

prof


Alice Sleeping
Дублирование работы. Уверен, у многих читателей к этому времени уже созрел такой вопрос: "У нас ведь уже есть командный таск-трекер, разве его недостаточно для журналирования?"


Однозначного ответа на этот вопрос у меня нет. Обстоятельства у всех разные, и было бы неправильно подходить ко всем с одной меркой. Могу сказать лишь за себя самого. В дневник я позволяю себе записывать абсолютно что угодно. Самые мелкие напоминалки для себя, вопросы "эту штуку сделал, что делаем дальше?", ключевую фразу "я туплю" и так далее. Порой это десятки записей в день! Если всё это писать в таск-трекер, коллеги взвоют из-за объёмов спама и навечно забанят меня.


Поэтому в трекер уходят только отфильтрованные записи. Copy & paste, copy & paste… Дублирование усилий получается, но не настолько уж большое. Суммарные преимущества дневника всё равно перевешивают.


Лень вести дневник. Пожалуй, самый весомый и самый серьёзный недостаток. Безусловно, на работу с дневником приходится тратить заметное количество сил и внимания. Мозг сопротивляется этому как может. Уж что-что, а экономить энергию он любит, хотя и не всегда делает это в правильных местах.


Бывали и у меня периоды, когда я сдавался и временно отступал от ведения дневника. Но всё же неизменно раз за разом возвращался к этой практике, слишком уж велики её преимущества!


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


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


Полезные приёмы


Упомяну также несколько дополнительных хитростей, которые помогают в работе над дневником.


Выбираем формат дневника. Простого plain text не всегда бывает достаточно, когда мы работаем с кодом. Сам я использую markdown и вполне им доволен: синтаксис поддерживается всеми популярными редакторами, удобно визуально выделять заголовки, код, цитаты и т.п. Но остерегусь навязывать Markdown читателю. У этого формата есть альтернативу, например: Restructured Text, Wiki, Orgmode. Главное, что требуется от формата — не вызывать раздражения при чтении и записи — ведь иначе дневник долго не проживёт!


Используем сниппеты. Некоторые операции приходится чаще других при работе с дневником. Например, я привык начинать очередную запись с отметки времени, чтобы потом проще было ориентироваться. Довольно очевидно, что вводить дату каждый раз руками слишком утомительно (порой десятки раз в день!). Здесь стоит обратиться к возможностям текстового редактора, чтобы облегчить себе труд. Я привык работать в Vim, а для него есть отличный плагин Snipmate. Теперь мне достаточно написать слово time, нажать Tab — и отметка времени генерируется автоматически! Аналогичные примочки есть, пожалуй, у каждого продвинутого тестового редактора.


Храним бэкапы. Чем дольше вы ведёте дневник, тем большую ценность начинает представлять сохранённая в нём информация. Не лишним будет позаботиться о её сохранности! Я настроил автокоммит в git и бэкап в bare-репозиторий внутри Dropbox по cron-у. Теперь можно спать спокойно и не бояться, что дневник пропадёт вместе со сдохшим диском.


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


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


Я что-то нажал, и всё сломалось :(((((

Куда полезнее будет, если в запись попадёт и конкретная страница приложения, и проблемная кнопка на ней, и текст ошибки.


В заключение


crossbow


wikipedia.org


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


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

Пробовали ли вы вести рабочие записи раньше?

Проголосовало 652 человека. Воздержался 141 человек.

А будете ли пробовать после этой статьи?

Проголосовало 537 человек. Воздержалось 172 человека.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Андрей Хитрин @zloddey
карма
111,0
рейтинг 25,1
Человек-оркестр
Самое читаемое Разработка

Комментарии (87)

  • +5

    Портабельная wiki в одном HTML файле вам в помощь :)


    http://tiddlywiki.com/

    • +1

      Спасибо за ссылку, обязательно изучу.


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

      • +4
        Мне нравится workflowy.com

        Простой как нотепад, но обладает мегаважными фичами:
        + древовидность => инфа структурирована
        + онлайн => всегда синхронизирован с мобилой и несколькими компами (если нет инета, сохраняет в кеше и потом синхронизирует)
        + возможность расшарить кусок дерева и редактировать совместно
        • 0

          Хм, тоже весьма интересно! Некоторых фишек вроде зумминга очень не хватает в других менеджерах

        • 0
          очень интересный сервис :)
          А есть такой-же, но оффлайновый? а то в наши дни стартапы имеют привычку закрываться как только ты начинаешь ими активно пользоваться…
          • 0
            Сервис существует довольно давно (7 лет я им пользуюсь), достаточно популярен, даже на хабре его часто упоминают.

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

            Так что вы зря волнуетесь.
      • +1
        Почему бы не писать дневник в самом коде? В качестве комментариев в начале. Тогда есть привязка к задаче и не только Вы видите, с чем столкнулись и работали. Просто по датам, не совсем удобно, нужно еще вспомнить когда решал ту или иную задачу. И по названием, тоже не очень. Так как тоже нужно вспомнить как назвал. А так при работе с кодом можно найти, когда нужно. В коде нет того официоза, все для своих. Можно особо не фильтровать.
        • 0

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

    • +1
      vi хватит, вики не нужна.
    • 0
      Могу посоветовать Flashnote.
      Плюсы: древовидность, легковесность, бесплатность, портативность.
      Киллер-фича: мгновенное сворачивание/разворачивание по глобальному хоткею.
      Минусы: plain text only.
  • +1
    в свое время пытался вести похожий дневник с находками, полезными ссылками и т.п. причем не только в области программирования, но и по своим хобби. Заглохло по простой причине — вся информация устаревала очень быстро. И стало намного проще при необходимости погуглить и найти более свежую информацию.
    • +1
      вот это и называется «начало конца»
      1 день без интернета ставит разраба в ступор
      • +2
        а что, много разрабов помнят ВСЕ функции, классы, их детальное описание и т.д.? С чем работаю постоянно, то не гуглю. Наверное я не один такой.
      • +4
        Я думаю, без интернета программировать возможно, если вы скажем программируете под голый attiny13 и заучили все наизусть. Ну или у вас абсолютно core java, скаченный javadoc и сферические задачи в вакууме. И никакой интеграции с внешними системами.
        А еще абсолютно безглючная ОС и средства разработки.
        • –1
          Сарказм излишен.
          Следует учиться работать с локальной справкой + опыт, полученный горькими слезами и днями/неделями в поисках решения, запоминается гораздо сильнее и заставляет порой сильно осмыслить всю внутреннюю структуру используемой технологии. А ответ полученный за 15 сек в гугле или на стэке ещё через 15 секунд будет забыт к ендрене-матери.
          «Дневник» (если я правильно понял мысль автора) в данном случае всё же следует использовать не как замену google, а как дополнительный swap раздел, помогающий освободить место в оперативке нашего мозга для поиска решения задачи.
          • 0
            >> опыт, полученный горькими слезами и днями/неделями в поисках решения
            Мы видимо в каких-то очень разных реалиях живем, если у вас есть на дни и недели(!) возможность. У вас есть вакансии?)

            Фронтендом не занимаетесь видимо? Локальная справка, хах))
            Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.
            • 0
              Пообщайтесь с другими системными программистами, познаете «нашу реаль»)
              • +2
                Ах, вот оно что. Теперь понятно. К сожалению, в современном вебе это [тру локальная работа] практически нереально.
          • 0
            Следует учиться гуглить за 15 сек в гугле даже то, что сам давно и чётко знаешь, как делать. Зачастую узнаёшь много нового. В худшем случае (или в лучшем, как посмотреть) зря теряешь 15 сек.
        • 0
          послушай лекцию Бобука про программирование без интернета
    • +10

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

  • +1

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

    • +2
      Сам процесс записывания включает механическую память.
      Свои записи приятно полистать.
      • +1
        Свои записи приятно полистать.

        Для этого у меня есть двухтомник записей с лекций по теории кодирования и каналам передачи данных :)

    • –1
      А я свой блокнот просто отфотографировал, и картинку каждой страницы по темам отсортировал. Т.е. когда надо по теме быстро найду нужную картинку.
  • +3
    Ещё один плюс записывания мыслей в текстовик — он [текстовик] не зависит от прогресса.

    Баг трекеры и таск менеджеры могут поменяться и старые данные не будут перетащены в новое место, а текстовый файл всегда с тобой :)
  • +1
    А мы на фирме ведем похожие «групповые» дневники в эверноуте по проекту. И туда всей командой пишем кто что делал, что надо делать. И картинки можно вставлять, и документы — удобнее, чем текстовый файл. Если хочется писать очень много «спама», можно сделать личный дневник, куда писать будет только один человек, но читать при желании смогут и вникать в курс дела все в команде.
  • +1
    Делаю тоже самое, только некоторые пункты отсутствуют.
    За несколько лет получился очень даже приличный FAQ для себя.
    Например, всякие особенности разных языков пр-ия.
    Все это хозяйство просто отсортировал по по темам.
    Оказалось, что это очень удобно, если вдруг в либе на си или си++, перле что-то придумано удобнее, чем в <вписать нужный язык>.
  • +1
    Видится, что вы духовный наследник профессора Любищева — рекомендую ознакомится с его наследием по организации рачего времени — очень познавательно
  • +1
    А если вы уйдете из этого проекта, кто-то будет читать ваш дневник?
    Код писать проще чем его читать!
    Так что я обычно делаю так:
    1. Все пришедшие в голову случаи оформляем сразу в тесты
    2. Все принятые технические решения оформляем в виде комментариев, желательно и все отброшенные варианты(можно ссылкой на вики)
    3. Записываем для себя что-то во время написания кода для облегчения его написания или для поиска красивой архитектуры
  • +6

    А почему текстовый файл? Почему не хардварное решение? Иногда отвлечься от клавиатуры и монитора не менее полезно. Еще хорошо помогает набор цветных ручек/маркеров/карандашей по вкусу.


    image

    • 0

      Бумагу использую, но в меньшей степени. В большом блокноте очень удобно заниматься дизайном систем (стрелочки-квадратики рисовать), но писать там код или стектрейс — увольте!

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

        :)
    • +1

      К сожалению с бумажным вариантом комбинации Ctrl+F и Ctrl+C / Ctrl+V не работают :)

      • +5

        Ctrl+X / Ctrl+V работает, кстати :-)

        • 0

          Согласен =D

          • 0
            Поэтому они и называются «Cut» и «Paste».
      • 0
        Ctrl+F

        Отметил для себя, что в этом случае развивается зрительная память. Где-то в голове у меня построены индексы, и я вспоминаю, что необходимая запись была сделана в нижней половине листа, а в верхней части была нарисована какая-то схемка + примерно ориентируюсь по времени, это помогает понять, в какой части блокнота находится запись. Тогда по небольшому range-scan быстро удается найти нужную заметку. Не так быстро, конечно, как в случае электронного варианта, но там тоже нужно помнить ключевые слова для поиска (например, номер тикета или места, где тупил особенно сильно, о чем сделал соответствующую пометку).
    • 0
      эта картинка мне аж браузер подвешивает
      • 0

        Неудивительно — при размере в 4032x3024 пикселя...

    • 0
      Как минимум:
      1) не у всех красивый почерк, знаю людей, которые свои собственные записи прочитать не могут через неделю
      2) не всем нравится записывать ручкой в блокнот, клавиатура и быстрее, и правки вносить куда проще
      3) занимает место, есть люди, которые кроме портмоне, телефона и ключей с собой ничего не носят
      4) при утере\краже восстановить невозможно
      5) записывать код в блокнот довольно бессмысленно
      • 0

        6) Бумажные блокноты быстро заканчиваются, если использовать их более-менее регулярно. А поиск по старым блокнотам — удовольствие сомнительное

        • 0
          7)отстаивает версионирование, да и вообще с редактированием много промблем
    • 0
      Оно ж даже если бекапится — фиг восстановишь в изначальном виде!
    • 0
      Вот, это мой вариант, правда попроще — тетрадка в 48 листочков на проект (может быть несколько),
      для себя нашел даже объяснение — мне так запоминать лучше и ориентироваться в них быстрее.
      К сожалению, электронные ср-ва (файлы и т.п.) по удобству еще долго не дорастут до нужного уровня «комфорта взаимодействия»…
  • +1
    Записывай всё — у меня куча способов вести записи. Вот собрать всё в один ресурс не получается. Медиа-записи мне нравятся больше. Видео-файлы, фотографии. Поэтому Evernote и GoogleDocs.
    • 0

      Крутая статья!

      • 0
        Спасибо
  • +2
    Давно веду такой дневник. Сейчас пользуюсь Evernote. Когда-то пользовался просто Word, OpenOffice. В принципе, тут любой редактор подойдёт.
    • 0

      Да, главное — найти формат, удобный лично для себя

    • 0
      +,
      Тоже пользуюсь evernote, а раньше — notepad.
  • +1
    Веду подобные записи в Notion. В нем есть все прелести воркфлоу — шаринг, влажность и проч. При этом типов контента намного больше. В том числе блоки с кодом можно вставлять и маркдауном пользоваться.
    • +1

      Выглядит интересно, но Mac есть не у каждого

    • +2

      Спасибо за совет, классный редактор, сервис и приложение. Но смущает ценовая политика – $8/month за онлайн-документы это немного жирно.

      • 0
        Бесплатной версии достаточно для работы. Плюшки платного аккаута вроде слак нотификаций особо не нужны ведения дневника. А лимиты на создание блоков можно поднять за счет инвайтов друзьям.
  • 0
    Была бы возможность — носил бы с собой маркерную доску. Схемы на доску, потом в смартфон.
    На доске легко можно поправить схему, текст — на бумаге с этим сложнее.
  • 0
    советую посмотреть на Diigo как альтернатива evernotes
    • 0
      Чем лучше?
    • +1
      При беглом осмотре так и не понял возможно ли там вообще создавать заметки а не только вырезки из пдф и веб страниц. Несколько иной класс задач все же.
  • +1
    Я Evernote использую. Очень удобно.
    Пробовались всякие Dairy One (приложение под OS X) или просто текстовые файлы в конце дня отправляемые себе же на почту.
    Был период когда использовался инстанс Atlassian Confluence но там главная проблема — с мобильного железа очень не удобно.
  • +2

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

    • 0
      Аналогично, записываю заметки типа какие тикеты в Code Review, чего сделать перед деплоем и т.д., в Scratch-файл в PyCharm/IDEA/..., главное — быстро открывается.
    • 0

      Во-во-во, у меня очень схожий паттерн использования. Неоднократно замечал: стоит только поддаться лени и перестать вести журнал, как начинаешь моментально путаться во всех этих микротасках. Дело порой доходит вплоть до почти полной невозможности продвигаться вперёд. Но стоит открыть редактор и записать туда все вопросы по задаче, как сразу появляется понимание, за что взяться первым делом, что отложить на потом — и работа сдвигается с мёртвой точки!

  • +1

    У нас для похожих целей официально используются "Technical Design Notes" (aka Design Specification), в которой есть главы (помимо прочих) "Design Rationale", "Design Methodology", "Proof of concepts", "Risks and Volatile Areas". При этом некоторые (существенные) части (например, "Component Contract") используются для формализации и "распределения" процесса разработки.


    "Живые" многопользовательские документы создаются в Polarion, с диаграммами, линками и проч. (хотя можно и другие инструменты использовать). Это позволяет создавать иерархически структурированные "дневники" (design notes) для сложных продуктов.

  • +2
    Работаю под linux, использую zim. Все хранит в обычных текстовых файлах в дереве директорий и отображает в виде древовидной навигационной структуры. Использует wiki-форматирование, можно создавать списки задач и отмечать что сделано и что отклонено. Есть поддержка тегов для быстрого поиска. Версии хранит в git-e.
    • +1

      Жаль, что плагины отличаются разной работоспособностью на разных платформах. Я используют на двух машинах: Linux — дома и Windows — работа, синхронизация через Yandex Disk (тут конкуррентность не проблема — я могу в один момент времени работать только в одной копии Zim, но если у кого есть другие предложения по поводу синхронизации, то я с радостью выслушаю).


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


      Ну и очень бы хотелось в Zim иметь какой-нить вариант GitHub Flavored Markdown

  • +1

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


    з.ы. очень не хватает электронной записной книжки 2.0, с удобной клавиатурой для ввода текста на ходу...

  • +1
    Для похожих целей использую Zim desktop wiki — локальная «вики» система, с поддержкой тегов, ссылок между записями, иерархической структурой записей, простым текстовым форматом хранимых файлов (та же иерархическая структура из папок и txt файлов), кроссплатформенная (+опенсорс)
    • 0

      Если концептуально нравится Zim, можно еще присмотреться к CherryTree. Он немного побогаче функционалом (например, имеет подсвеку синтаксиса, умеет рисовать таблицы), но базу хранит в xml/SQLite. Есть импорт из Zim. Но не умеет, к примеры, поддерживать список TODO.
      В общем — дело вкуса, но хорошо, что есть выбор.

      • 0

        Zim плагинами подсветку (код) и таблицы тоже умеет.

  • +1
    Спасибо за статью!
    Хотел бы поделиться своим опытом.
    Много лет использовал для ведения записей простыми текстовыми редакторами: «Блокнот» в OS Microsoft Windows или vi — в UNIX. Честно скажу, что всегда не хватало системы контроля версий (хотя бы в самом простом виде) и возможностей синхронизировать между ПК. Разумеется, Evernote и подобные решения существуют не один год, да и сложно адаптироваться к новым интерфейсам в повседневной жизни. В конце концов, нашел для себя следующий выход: VPS с OS Linux с установленным ownCloud (для синхронизации), традиционный «Блокнот» или viM, а также скрипт в несколько строк кода — для бэкапа в публичное облако. В последнем случае, разумеется, проводится обработка файла с помощью GnuPG. С версиями решил все просто — добавил в viM хоткей для создания файла с другим именем.
    Даже не буду спорить, что все мной изложенной — очевидно и примитивно :) (А также имеет недостатки), но лично мне — это кажется удобным и по этой причине решил поделиться решением.
    • 0
      А почему не гит? Можно даже свой сервер не поднимать, а взять тот же bitbucket. Если сервис вдруг ляжет — ну так локально проект же есть, его всегда можно будет загрузить на новый. Я не пытаюсь доказать что это удобнее, просто интересны причины именно такого решения.
  • 0
    MindJet — карты памяти.
    Есть возможность работать с картой или обыкновенным списком.
    Можно вставить любой файл или диаграмму
    + есть мобильная версия.
  • 0

    Непонятно, почему не писать это комментариями в тикеты в вашей любимой Jira/Redmine/что-там-у-вас. Так не только вам, но и всей команде будет видно, что сделано по задаче, и какие есть догадки. Да и менеджерам будет видно, что работа ведётся.


    А то воспроизводишь багу, находишь соответствующий закрытый тикет в трекере, а там один комментарий от разработчика год назад — "Fixed".

    • 0

      Это организационный просчёт. Нужно вводить обязательное поле Analysis Information, в котором, хотя бы, указывать ссылку на комментарий, в котором этот анализ написан или на вложение, если это вложение — переписка из почты. Ну и соответственно карать за его пустоту.

      • 0
        обязательное поле

        Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.


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


        Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.

        • +1
          Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.

          Вот в чём дело: если всё оставить на самотёк, то от системы тикетов останется одно название: вроде и есть, а толку чуть (ну по крайней мере видно: кто и когда завёл, кто и когда решил). Собственно, если за такое не журят, значит никто трекер не мониторит, значит информация оттуда никому не особо нужна.


          Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.

          Да я собственно с этим и не спорил, каюсь, нужно было процитировать то, на что отвечаю. Сам я заметки делаю ручкой в блокноте: быстрее и на родном языке, можно писать в любом направлении и оперативно делать простые схемы/графики. Да плюс можно просто писать поток сознания, которому не место на всеобщем обозрении :) Хотя такой формат часто систематизирует знания и факты и позволяет найти решение. В любом случае — потом результат анализа нужно оформить в тикете. Так что здесь у нас расхождений нет.

  • 0
    а я просто пишу в блоггер новий пост.
    • +1

      Одно другому не мешает :) Я в Zim иногда накидываю просто заметки, ссылки, а потом формулирую из этого мысль в виде блого-поста.

  • 0
    Обычно 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.
    • 0

      Обычно не нужен, да. Но в RHEL и его производных (где приходится работать) в репозиториях часто находятся достаточно старые версии пакетов. В частности, старый perf, у которого опция --demangle работает как-то не так. Конечно, я попробовал её в первую очередь, а к c++filt обратился только уже после, когда выяснил, что сам perf не может нормально транслировать символы C++.


      Смысла в пересборке в данном случае не вижу, если честно. c++filt стоит в системе по-умолчанию, пайп написать тоже несложно. Со сборкой будет куда больше возни.


      Но за комментарий всё равно спасибо!

  • +1

    Сам пришёл к такой идее в своё время. Вначале вёл полноценный дневник, но он отнимал слишком много времени и я ограничился записыванием выполненных задач с какими-то своими пометками — для отчетов удобно, достаточно скопипастить текст.
    От бумажного блокнота отказался, потому что в нём нет навигации, поиска и редактирования. Об эвернотах и разных облачных решениях даже не думал, потому что данные из них неудобно парсить, да и информация бывает только для внутреннего корпоративного пользования.
    В итоге, поднял локально dokuwiki.

  • 0
    Если на поиск решения задачи в интернете уходит мене 2-3 минут, я ее не сохраняю. Если более, то записываю, а также записываю те задачи, которые имеют несколько шагов решения. Под линуксом пользуюсь CherryTree.
  • +1
    Тоже стал это использовать. Стал как вести дневник, так и дополнительную документацию ввести. Максимально подробно. В итоге кажется, да, вроде тратится много времени. Но когда тебе нужно решать похожие задачи, твой дневник и документация так сокращает время, что ой ой.

    Использую GitBook Editor для записи большой общей документацией которая может пригодится в любом проекте/задачи. Для заметок по конкретному проекту, делаю отдельную папку doc, в отдельном файле заметки/мысли в других уже более конкретная документация которую переношу из файла с заметками, в основном для редактированию использую встроенный markdown редактор phpstorm или Mweb.
  • 0
    Мне очень нравится список вопросов который вы задаёте (для создание самой записи в дневнике).
    Можете его расширить, при случае?
  • 0
    а что за шрифт на скришноте?
    • 0

      Ubuntu Mono

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.