Комментарии 90
Спасибо за ссылку, обязательно изучу.
В своё время пробовал какие-то варианты с вики, но оказалось, что мне всё же удобнее вести документацию в том же редакторе, где я правлю код (обычно это gvim). Просто меньше действий надо делать, чтобы переключаться туда-сюда. Удобство ведения дневника часто оказывается решающим фактором для выбора инструмента. Поэтому текстовые файлы победили.
Простой как нотепад, но обладает мегаважными фичами:
+ древовидность => инфа структурирована
+ онлайн => всегда синхронизирован с мобилой и несколькими компами (если нет инета, сохраняет в кеше и потом синхронизирует)
+ возможность расшарить кусок дерева и редактировать совместно
По поводу комментарии написали же чуть выше… Комментарии так и так пишется… Но поднимать весь проект и тд и та… Я по началу использовал обычную тетрадку, а когда понял о необходимости сразу же разработал себе небольшое приложения которая лежит на хостинге… все просто, удобно, всегда есть доступ. Там создаешь проект а внутри записи разного статуса (идея, что надо делать, что сделано, ошибки и из решения и тд) время добавления записи автоматически добавляется… фильтр и поиск работает. С одним словом все работает именно так как тебе хочется… ооооочень удобно))
Плюсы: древовидность, легковесность, бесплатность, портативность.
Киллер-фича: мгновенное сворачивание/разворачивание по глобальному хоткею.
Минусы: plain text only.
1 день без интернета ставит разраба в ступор
А еще абсолютно безглючная ОС и средства разработки.
Следует учиться работать с локальной справкой + опыт, полученный горькими слезами и днями/неделями в поисках решения, запоминается гораздо сильнее и заставляет порой сильно осмыслить всю внутреннюю структуру используемой технологии. А ответ полученный за 15 сек в гугле или на стэке ещё через 15 секунд будет забыт к ендрене-матери.
«Дневник» (если я правильно понял мысль автора) в данном случае всё же следует использовать не как замену google, а как дополнительный swap раздел, помогающий освободить место в оперативке нашего мозга для поиска решения задачи.
Мы видимо в каких-то очень разных реалиях живем, если у вас есть на дни и недели(!) возможность. У вас есть вакансии?)
Фронтендом не занимаетесь видимо? Локальная справка, хах))
Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.
Полезнее записывать в дневник собственные идеи, планы, шаги. Это принципиально не гуглится и устаревает медленнее, чем внешняя информация
За год скопилась пятисантиметровая стопка черновиков. Но поскольку на каждой странице что-то нарисовано, не представляю, как это перевести в электронный вид.
А ещё ко всем этим записям обращался ровно один раз. Комментарии в коде рулят.
Баг трекеры и таск менеджеры могут поменяться и старые данные не будут перетащены в новое место, а текстовый файл всегда с тобой :)
За несколько лет получился очень даже приличный FAQ для себя.
Например, всякие особенности разных языков пр-ия.
Все это хозяйство просто отсортировал по по темам.
Оказалось, что это очень удобно, если вдруг в либе на си или си++, перле что-то придумано удобнее, чем в <вписать нужный язык>.
Код писать проще чем его читать!
Так что я обычно делаю так:
- Все пришедшие в голову случаи оформляем сразу в тесты
- Все принятые технические решения оформляем в виде комментариев, желательно и все отброшенные варианты(можно ссылкой на вики)
- Записываем для себя что-то во время написания кода для облегчения его написания или для поиска красивой архитектуры
А почему текстовый файл? Почему не хардварное решение? Иногда отвлечься от клавиатуры и монитора не менее полезно. Еще хорошо помогает набор цветных ручек/маркеров/карандашей по вкусу.
Бумагу использую, но в меньшей степени. В большом блокноте очень удобно заниматься дизайном систем (стрелочки-квадратики рисовать), но писать там код или стектрейс — увольте!
:)
К сожалению с бумажным вариантом комбинации Ctrl+F и Ctrl+C / Ctrl+V не работают :)
Ctrl+X / Ctrl+V работает, кстати :-)
Ctrl+F
Отметил для себя, что в этом случае развивается зрительная память. Где-то в голове у меня построены индексы, и я вспоминаю, что необходимая запись была сделана в нижней половине листа, а в верхней части была нарисована какая-то схемка + примерно ориентируюсь по времени, это помогает понять, в какой части блокнота находится запись. Тогда по небольшому range-scan быстро удается найти нужную заметку. Не так быстро, конечно, как в случае электронного варианта, но там тоже нужно помнить ключевые слова для поиска (например, номер тикета или места, где тупил особенно сильно, о чем сделал соответствующую пометку).
1) не у всех красивый почерк, знаю людей, которые свои собственные записи прочитать не могут через неделю
2) не всем нравится записывать ручкой в блокнот, клавиатура и быстрее, и правки вносить куда проще
3) занимает место, есть люди, которые кроме портмоне, телефона и ключей с собой ничего не носят
4) при утере\краже восстановить невозможно
5) записывать код в блокнот довольно бессмысленно
На доске легко можно поправить схему, текст — на бумаге с этим сложнее.
Пробовались всякие Dairy One (приложение под OS X) или просто текстовые файлы в конце дня отправляемые себе же на почту.
Был период когда использовался инстанс Atlassian Confluence но там главная проблема — с мобильного железа очень не удобно.
Записываю, но не как глобальную базу, а конкретно заметки по проекту, иногда по отдельной задаче, если она большая. Надо сделать это, это и то, тут переделать, там отрефакторить, про это уточнить, что сделано ставлю плюс, что решено не делать минус, ссылки на документацию и примеры, этот компонент настраивается так, этот кусок кода оказался не нужен, но возможно потом пригодится...
Во-во-во, у меня очень схожий паттерн использования. Неоднократно замечал: стоит только поддаться лени и перестать вести журнал, как начинаешь моментально путаться во всех этих микротасках. Дело порой доходит вплоть до почти полной невозможности продвигаться вперёд. Но стоит открыть редактор и записать туда все вопросы по задаче, как сразу появляется понимание, за что взяться первым делом, что отложить на потом — и работа сдвигается с мёртвой точки!
У нас для похожих целей официально используются "Technical Design Notes" (aka Design Specification), в которой есть главы (помимо прочих) "Design Rationale", "Design Methodology", "Proof of concepts", "Risks and Volatile Areas". При этом некоторые (существенные) части (например, "Component Contract") используются для формализации и "распределения" процесса разработки.
"Живые" многопользовательские документы создаются в Polarion, с диаграммами, линками и проч. (хотя можно и другие инструменты использовать). Это позволяет создавать иерархически структурированные "дневники" (design notes) для сложных продуктов.
Жаль, что плагины отличаются разной работоспособностью на разных платформах. Я используют на двух машинах: Linux — дома и Windows — работа, синхронизация через Yandex Disk (тут конкуррентность не проблема — я могу в один момент времени работать только в одной копии Zim, но если у кого есть другие предложения по поводу синхронизации, то я с радостью выслушаю).
Что удобно — это добавлять вложения. Особенно полезно, когда разбираешься с чем-то, где есть куча даташитов или прочей документации в PDF.
Ну и очень бы хотелось в Zim иметь какой-нить вариант GitHub Flavored Markdown
Одно время вел заметки в Org'е, синхронизируя их через git-репозиторий.
Все уперлось в то, что идеи иногда приходят в голову в удалении от ПК, а подходящего карманного устройства для заметок, длинной больше одного твита, просто не существует.
В итоге сейчас пользуюсь бумажными записями, в которых по большей части фиксирую условия и результаты экспериментов, чтобы по прошествии времени можно было их воспроизвести.
з.ы. очень не хватает электронной записной книжки 2.0, с удобной клавиатурой для ввода текста на ходу...
Если концептуально нравится Zim, можно еще присмотреться к CherryTree. Он немного побогаче функционалом (например, имеет подсвеку синтаксиса, умеет рисовать таблицы), но базу хранит в xml/SQLite. Есть импорт из Zim. Но не умеет, к примеры, поддерживать список TODO.
В общем — дело вкуса, но хорошо, что есть выбор.
Хотел бы поделиться своим опытом.
Много лет использовал для ведения записей простыми текстовыми редакторами: «Блокнот» в OS Microsoft Windows или vi — в UNIX. Честно скажу, что всегда не хватало системы контроля версий (хотя бы в самом простом виде) и возможностей синхронизировать между ПК. Разумеется, Evernote и подобные решения существуют не один год, да и сложно адаптироваться к новым интерфейсам в повседневной жизни. В конце концов, нашел для себя следующий выход: VPS с OS Linux с установленным ownCloud (для синхронизации), традиционный «Блокнот» или viM, а также скрипт в несколько строк кода — для бэкапа в публичное облако. В последнем случае, разумеется, проводится обработка файла с помощью GnuPG. С версиями решил все просто — добавил в viM хоткей для создания файла с другим именем.
Даже не буду спорить, что все мной изложенной — очевидно и примитивно :) (А также имеет недостатки), но лично мне — это кажется удобным и по этой причине решил поделиться решением.
Есть возможность работать с картой или обыкновенным списком.
Можно вставить любой файл или диаграмму
+ есть мобильная версия.
Непонятно, почему не писать это комментариями в тикеты в вашей любимой Jira/Redmine/что-там-у-вас. Так не только вам, но и всей команде будет видно, что сделано по задаче, и какие есть догадки. Да и менеджерам будет видно, что работа ведётся.
А то воспроизводишь багу, находишь соответствующий закрытый тикет в трекере, а там один комментарий от разработчика год назад — "Fixed".
Это организационный просчёт. Нужно вводить обязательное поле Analysis Information, в котором, хотя бы, указывать ссылку на комментарий, в котором этот анализ написан или на вложение, если это вложение — переписка из почты. Ну и соответственно карать за его пустоту.
обязательное поле
Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.
Я просто не вижу смысла вести какой-то дневник с описаниями того, что и как нужно сделать в рамках конкретной задачи, когда для этого существует баг-трекер. Тикеты в баг-трекере — это и есть персональный дневник каждой баги, только доступный всем членам команды. Туда лучше писать вообще все действия, выполненные в рамках задачи, важные команды, которые выполнял в терминале, вывод этих команд, результаты коммуникации и решения, ссылки на код-ревью и коммиты, etc.
Если утром не помнишь, что нужно делать — открываешь баг-трекер, тыкаешь в самую приоритетную задачу и читаешь последние записи.
Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.
Все эти "обязательные поля" не работают, всегда можно придумать способ обойти это.
Вот в чём дело: если всё оставить на самотёк, то от системы тикетов останется одно название: вроде и есть, а толку чуть (ну по крайней мере видно: кто и когда завёл, кто и когда решил). Собственно, если за такое не журят, значит никто трекер не мониторит, значит информация оттуда никому не особо нужна.
Идею делать личные заметки полностью поддерживают, сам часто так делаю (org-mode + babel рулят). Мне не нравится идея использовать личный дневник для того, что должно быть в баг-трекере.
Да я собственно с этим и не спорил, каюсь, нужно было процитировать то, на что отвечаю. Сам я заметки делаю ручкой в блокноте: быстрее и на родном языке, можно писать в любом направлении и оперативно делать простые схемы/графики. Да плюс можно просто писать поток сознания, которому не место на всеобщем обозрении :) Хотя такой формат часто систематизирует знания и факты и позволяет найти решение. В любом случае — потом результат анализа нужно оформить в тикете. Так что здесь у нас расхождений нет.
$ 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.
Использую GitBook Editor для записи большой общей документацией которая может пригодится в любом проекте/задачи. Для заметок по конкретному проекту, делаю отдельную папку doc, в отдельном файле заметки/мысли в других уже более конкретная документация которую переношу из файла с заметками, в основном для редактированию использую встроенный markdown редактор phpstorm или Mweb.
Можете его расширить, при случае?
Раньше вел дневник на guthub issue, но перестал когда переехал в офис, спасибо что напомнили.
Сомневаюсь, что у меня, в моей работе дневник окупит себя. У меня достаточно хорошая память, вроде её хватает.
Я лично на бумагу зарисовываю только структуры данных и наброски кода. Последние ещё делать относительно несложно, а вот первые весьма геморно. Но надо делать. Потому, что 20 летний программистский опыт показал, что надо делать сначала карандашом на бумаге, а потом садиться за компьютер. Так эффективнее всего выходит. Можно это делать и в голове, но делать надо обязательно перед)
Рабочий дневник программиста