Comments 89

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


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

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

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

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

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

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

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

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

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

Фронтендом не занимаетесь видимо? Локальная справка, хах))
Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.
Ах, вот оно что. Теперь понятно. К сожалению, в современном вебе это [тру локальная работа] практически нереально.
Следует учиться гуглить за 15 сек в гугле даже то, что сам давно и чётко знаешь, как делать. Зачастую узнаёшь много нового. В худшем случае (или в лучшем, как посмотреть) зря теряешь 15 сек.

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

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

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

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

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

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

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


image

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

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

:)

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

Ctrl+F

Отметил для себя, что в этом случае развивается зрительная память. Где-то в голове у меня построены индексы, и я вспоминаю, что необходимая запись была сделана в нижней половине листа, а в верхней части была нарисована какая-то схемка + примерно ориентируюсь по времени, это помогает понять, в какой части блокнота находится запись. Тогда по небольшому range-scan быстро удается найти нужную заметку. Не так быстро, конечно, как в случае электронного варианта, но там тоже нужно помнить ключевые слова для поиска (например, номер тикета или места, где тупил особенно сильно, о чем сделал соответствующую пометку).
Как минимум:
1) не у всех красивый почерк, знаю людей, которые свои собственные записи прочитать не могут через неделю
2) не всем нравится записывать ручкой в блокнот, клавиатура и быстрее, и правки вносить куда проще
3) занимает место, есть люди, которые кроме портмоне, телефона и ключей с собой ничего не носят
4) при утере\краже восстановить невозможно
5) записывать код в блокнот довольно бессмысленно

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

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

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

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

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

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

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

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


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

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

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


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


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

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


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

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

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

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

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


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

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

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

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


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


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

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

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


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

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

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

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

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


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


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

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

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

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

Раньше вел дневник на guthub issue, но перестал когда переехал в офис, спасибо что напомнили.

Only those users with full accounts are able to leave comments. Log in, please.