MedleyText
medleytext.net
medleytext.net
A tip if you're designing something like this. Be fast, responsible and keyboard first. The time to take a note (flush your brain) shouldn't interrupt your current task and should be as mechanical as possible.
I've been using the same note take system for the last two years. It just works as expected. It's as fast as my terminal can be and I can use org or MD if needed.
postit@workstation:~# cat bin/logbook
#!/bin/sh
TS=$(date +'%H:%M:%S')
DS=$(date +'%Y-%m-%d')
cd ~/txt/logbook/
joe $DS.md && git add . && git commit -am "Updating $DS entry on $TS" && git push
exit
ps: I decided to use joe in the script because it's the fastest text editor by far to start on my system, you can stick to your own solution.
First one was to get rid of always thinking about a commit message.
Second, I can use git blame and understand the order of things I've inserted w/o headaches. Past information gets agglutinated and I needed granularity specially during long work hours
Which time stamp is better in your opinion?
Also with an eye scan I can see how much I've updated on a single note
* 4a23de5 - Updating 2017-12-05 entry on 23:30:02 (postit, 3 weeks ago)
* ed9e37b - Updating 2017-12-05 entry on 23:26:21 (postit, 3 weeks ago)
* 7692b94 - Updating 2017-12-05 entry on 23:24:57 (postit, 3 weeks ago)
* 816adce - Updating 2017-12-05 entry on 23:24:21 (postit, 3 weeks ago)
* fd29ca3 - Updating 2017-12-05 entry on 23:22:08 (postit, 3 weeks ago)
* b914010 - Updating 2017-12-05 entry on 21:30:44 (postit, 3 weeks ago)
* 63e7aec - Updating 2017-12-05 entry on 20:54:06 (postit, 3 weeks ago)
* 2fabda1 - Updating 2017-12-05 entry on 16:38:32 (postit, 3 weeks ago)McDonalds didn't put Peter Luger out of business.
Is the hostility towards electron mostly from native app developers who are feeling their value diminished, and/or their careers threatened by the advent of electron?
Is this love for 'develop separately for 3 different platforms' backed by some practical/rational thinking?
Edit: Also I feel your analogy is a false equivalence. Perhaps a better analogy would be between a wood fire over, and an electric one.
I'm a web developer (though backend these days) myself.
My hostility towards Electron is purely as an end-user.
>Is this love for 'develop separately for 3 different platforms' backed by some practical/rational thinking?
Performance, memory, speed, following the platforms conventions and taking full advantage of its APIs, looking and behaving best for each platform.
So, anything else except "put something out there fast / attract JS programmers" (which are valid concerns too, but not user-first ones).
It has very little to do with lazy developers. It just takes more resources to release native applications for all three major desktop platforms.
Not if it serves as a "good enough" stop gap that prevents the better made application from being ported.
There is no reason for it to be this way other than vendor desire for lock in. In the end what the vendors will get is the web eating the desktop. Serves them right.
- Discord
- VS Code
I just spent more than three hours with a friend on Discord playing The Division and it was smooth as it can be.
It's kind of become the norm to hate on Electron apps, but to be fair, I don't see the point.
I'm working on a python project right now and enjoying PyCharm quite a bit, but in a window right next to me is VS Code with my running log. I'm using it at home with a plug-in to write code in CUDA and C++, I use it at work for TypeScript and dotnet core C#, editing configuration files. Heck, on one of my Windows boxes, I have a PowerShell command "Edit-File" that opens up the target in VS Code, is set to the default commit comment editor for Git and aliases "nvim" because I can't get NeoVim to work on that box to save my life.
Sure, it doesn't launch anywhere near as quickly as vi/vim/nvim, but since I live out of the thing, it's always already pulled up and the time it takes to open a file when the editor is already up is plenty fast.
As far as being resource heavy -- I like to work on the couch at work and it's nowhere near a plug. I started doing light editing of C# and .NET apps in VS Code to avoid having Visual Studio halve my battery life. I get a solid 4 hours of editing/testing which isn't all that much less than I get just leaving Windows running with nothing open. It wasn't always like that, sure -- I recall either Atom or VS Code having a bug where the cursor blinking caused the CPU to stay steady at 15% (though, ConEmu -- a must-have console app for Windows[0] hangs at around 5-10% CPU with nothing executing, too), but I haven't had any battery/memory/CPU issues running Code for the last year or so.
[0] If you use cmder, that's Conemu
Props to VS Code - that, along with the excellent Markdown Enhanced Preview and (less excellent, but usable) VSVim extension is my note-taking app ... on my HP Omen laptop loaded with openSUSE Tumbleweed. Of the 7 or so people that I work directly with at the company that employs me, all of them run Linux (with most using Manjaro) and VS Code is pulled up on one of the monitors on every one of them.
Who'd have thunk that a bunch of developers running Linux would be writing the vast majority of their code using a Microsoft product built natively for Linux named after another development tool who's name is usually proceeded by a profanity when spoken by a typical *nix geek.
Specifically, it allows lazy dev teams to deploy lazy "apps."
Before Electron, the quality of the average cross-platform app was generally atrocious. e.g. lack of support for retina displays, menu bars attached to the window, system fonts totally missing, non-system file pickers, ugly homegrown font rendering...
Electron is amazing and as much as people like to shit on it, it has raised the quality bar considerably.
The problem you have with "Inkscape on a Mac" is all over the place. I cringe when I go to install an app and find out it's used some C++ GUI kit that was designed for X/linix. They all "sort of" work on Windows -- the file dialogs will be all wrong, they'll have forward instead of back-slashes sometimes, none of my pinned folders will be there, etc. The windows in the app will sort-of feel like native Windows apps but will function just screwy enough that you long to be running KDE or Gnome[0]. Even if they look good in all of those OSes, they rarely provide the same experience. Then there's the handful of Electron apps I use. Keybase looks and behaves exactly the same way in KDE and Windows, as does Visual Studio Code and draw.io (though I almost always just use this right from the site, itself). And I'm very happy with the UI of those apps. Then I decide I want to tweak the way a ligature looks in a font I rely on and make the mistake of launching FontForge on my Windows box and remember why cross-platform generally means "take the worst of every platform and use only those features". Non-electron cross-platform apps all-too-often look like Java-based GUI apps from the early 00's -- write once, suffer everywhere.
[0] I've had apps that launch in a single pane within KDE/Gnome, but in Windows launch as several separate windows and apps that launch as normal looking windows in KDE/Gnome but in Windows look like a "Window within a Window" with all of the native Windows chrome outlining the application's window chrome, akin to placing a camera in front of a television and watching that camera's feed to watch a show/movie.
You need to try different things and see what works for you and what doesn't. Your personal preference could be even customized to the situation, so you might want to use GTD for work and some other system for your personal life.
So how I did it is tried one option (blogging about everything), then tweaked it (blogging about something), then tweaked it again (leaning towards messy notes, away from blog drafts), then tweaked it again (Markdown brain dumb of all the things that I think I might need in a day/week/month/year), and again (some of the notes about a random topic get detailed enough to write a blog post about it).
And the reason I've mentioned blogging so much is that, when trying to tell a story about the topic, I often find some previously unnoticed gaps in my knowledge. So that's kind of "reading notes, re-writing notes in such a way that I'm telling a story" style that currently works for me the best. YMMV
While learning a new subject (almost always from a big, fat, e-book), I take notes as I skim/scan the material. I'll go from cover to cover about 4-5 times, enhancing my notes each time. I re-read my notes in-between reading the book to see what I don't understand from my notes. These notes, later, become a reference material for me.
When I come across something new idea/technique (new to me, not necessarily "revolutionary", in general), I find the relevant document in my note library and add to it.
About once a year or so, I go through most of my notes and re-organize things. Since I've been doing this for 15-odd years, re-organization is usually moving a small percentage of text around to another file -- my notes repository is very well organized and often I remember exactly where something is that I'm looking for without resorting to searching.
All of my notes are written in Markdown -- something I started doing about 2 years ago. I converted all of the existing notes that I felt were important into this format because it gave me the best of all worlds -- I get solid, pleasant (and configurable) formatting, code highlighting which can be viewed in a styled format in-browser or printed[0] and yet still end up with a plain-text document that plays nicely with git. All of my notes are stored in five different git repositories which are now all stored on Keybase's Encrypted Git. I keep separate repositories to separate out work and personal, but I have a programming-notes repository that's dedicated to generic notes I've taken on the programming languages I write in (each has its own folder with several documents, but minimally a "cheat-sheet" and "snippets" document which should be self-explanatory).
The Markdown bit is key -- I am not always in a GUI, sometimes I'm having to refer to things from the terminal and everywhere I go, I have a copy of that keybase repo. Everywhere I go I also have grep and when I can't remember something specific, but I know I took notes on it, grep finds my answer faster than evernote/onenote's search function ever could and I can read what I need right in the output of that command with an "-A/-B" of sufficient size, or just open the file in VS Code if I want to see it with formatting.
I get where you're at, though. You don't get value from taking notes until you've taken a lot of notes and it takes forming the habit of taking notes to get that value -- not being certain that you'll get any value from your notes because of the tool you chose or the format it's stored in can be a barrier to forming that habit. I started keeping programming notes outside of those I took while learning a language when I realized I was constantly googling the same thing about languages that I didn't use frequently enough to commit those things to memory. That's fine and all until you can't remember the specific incantation of search string that you used, or Google changed the ranking of things for the search term, or the site that had that great nugget of information was reformatted or changed URLs so you can't find it and your bookmarks are no good any longer ... I believe I started taking daily note-taking seriously after spending a day between Google and writing code only to throw most of it away when I finally found that library I had been looking for the next day after remembering the author's name and searching directly for him/her rather than what I thought was the name of the library[1].
[0] I use Markdown Enhanced Preview with Visual Studio Code and have written customer proposals and full-on "report-style" documents. When I had to do the first one of these at the job I took in March, I was given a Word template to work from and after swearing at Word's awful WYSIWYG interface, I went into the CSS editor for Markdown, added some rules and managed to get it to interpret my Markdown in a manner that looked identical to the Word template, complete with a full-page "Title Page", headers, footers, and a formatted Table of Contents that it generated automatically from headers (a feature of the add-on for VS Code). I've sent that CSS file over to at least 20 different coworkers via Slack.
[10] The thing is, I remember neither now, but it was a C++ library that had to do with string edit distance algorithms and I could probably find it given a few minutes with grep targeted at my C++ folder.
> I get where you're at, though. You don't get value from taking notes until you've taken a lot of notes and it takes forming the habit of taking notes to get that value
Exactly, I think.. I struggle with the details of the notes I take. Maybe it is just practice. Do I take a one-liner, a paragraph? Pictures? In between?
My current way of working is to have a Todoist [0] filled with tasks, properly tagged and assigned to projects. Emails that need action go into Todoist, tasks from meetings go into Todoist, any tasks I come up with, Todoist. Next to this I have a Pocket [1] filled with articles, both to read later but I also use it as reference material and future use. Also properly tagged (most of times).
Now that leaves only notes that are not actions. Either from content that is too large to have in my pocket (say longer than a blog post) or not from any content I can send to Pocket at all. Probably the freeflow nature of these comments is what makes it hard for me to write them down. Granularity, quality, and governance are hard here. On my previous tries I either ended up with a huge pile of messy notes I never used or with too few notes that didn't accurately cover my thoughts at the time, i.e. needed to redo the process the note originated from.
I'll try again. Maybe this time things go right. If it is practice there is no shortcut to become a successful note-taker it seems.
WYSIWYGIWYRW?
- Less cluttered UI
- Allows both a file tree, or a more TOC-style tree, in the left pane
- A lot faster startup
etc.
Great with more options for pure-markdown wysiwyg editing/note-taking though.
* Stackedit: Not developed anymore, I've encountered many bugs.
* Typora: It's very good, as a couple of bugs but it's probably the best to me at the moment.
* Ghostwriter: What I'm trying out these days.
Honestly, my problem with Typora (and also with this MedleyText) is that they aren't opensource.
I've settled on having a permanently open vim buffer in a hidden window. When I press a hotkey it's pulled ontop of any windows I have. I type in a plain ascii pseudo-markdown-org-mode-ish style I've made up over the years but no one else needs to read. Then I hit the same hotkey to hide the window until I need it again.
The biggest thing for me is that it pops up, I brain barf all over the buffer, and then it's gone with no thought on how it's supposed to be formatted or anything. It should be more like playing an instrument than creating good documentation. It can be changed into something presentable later iff I need to. Options and features, while necessary to push your new app, are the antithesis of seamless note taking for me.
MedleyText+S Available in Nov. 2017
and button for download is inactive.
You decide the structure and the files, so you can throw it all in git to make it accessible anywhere.
I think I'll pass on downloading and executing a binary file.
Given the options available for installing an application, what would you have preferred? If it had been a GitHub repository with a releases item, it would have either been a tarball'd source I have to compile (I run Linux), an RPM file that might-or-might-not work (I run openSUSE and Fedora/Redhat RPMs are more common and hit/miss on openSUSE), instructions on how to apt-get or yum install it -- no openSUSE zypper commands (though, yum instructions often work depending with the same hit/miss ratio as RPM installs).
An improvement would have been if it was code-signed in some verifiable way (I'm not sure if it was or wasn't -- I wasn't paying a lot of attention when I launched it in this virtual, TBH), but the reality is that if you want to run code, it has to be in a binary format of some kind whether you compile it yourself or it's compiled for you, and even in the case of self-compiling ... it's not like you're going to do a line-by-line audit of the code looking to ensure they're not trying to win an underhanded C contest. At least an AppImage file can be run in a sandbox, and it is a very pleasant way to get a working binary on a Linux host. It didn't require root privileges to install or execute (that would have caused raised eyebrows, here).
So as to your app, the good points are: it's minimalist with a clean UI and native code highlighting. Those are pretty much the base requirements before I'll even consider looking into it, and I'm happy with the large array of supported languages. It looks quite nice and useful in that regard, so kudos! I love that it supports basically every OS -- I'm on Windows and Linux split about 50/50 and too often I'll run into apps that cover MacOS, Android, iOS and Windows. Since I run Linux at home, that's my preference and it a non-starter if it's not supported.
Unfortunately, for me, I can't handle another WYSIWYG editor. I'm done with them. It's not that I don't like formatting -- quite the contrary -- with the amount of note-taking I do day-to-day, I require good formatting. It's that I've never found a WYSIWYG editor that doesn't come with it's own set of F-bombs. I'm not taking my fingers off of the keyboard to hit a button with a mouse and while keyboard shortcuts are fine, I'll still end up highlighting a line, hitting that keyboard shortcut and having the WYSIWYG app decide to apply that formatting in some non-intuitive way (i.e. select a large line with mixed slant/non-slant and pick the slant button -- three choices: slant everything, slant nothing, or reverse slanting).
So I've settled on two technologies for my note-taking: Markdown and git. It just feels right -- it uses a dead simple dialect that allows me to directly indicate my formatting intent within the writing, it's lightweight enough that when viewing it in a terminal, the markup rarely decreases the readability (and sometimes increases it) and combined with a good rendering tool, can make a document format well for in-browser viewing and printing. I currently rely on a combination of Visual Studio Code (with Markdown Enhanced Preview for side-by-side previewing-as-you-type) and plain-old vim with markdown syntax highlighting for note-taking, combined with Keybase Encrypted Git for version management. I've yet to find something superior for me, though this would be pretty close if it simply gave me a Markdown editor with a preview on the side. And I'd really like a better UX than what's offered by grep for searching my notes. I'd love for an easy way to say "find all references to this function in this language" that would rip through my repo and pull out the relevant sections.
Perhaps I'm a bad example being so particular, but I've tried so many note taking apps -- online from Atlassian's Confluence (which I personally hate) to semi-online/offline markdown editors and things like one-note/evernote. For the most part, the major features of those applications are overshadowed by the poor experience of actually taking notes[1].
[0] I'm not a university student -- it's mostly for my job, which lately has consisted of being pulled into projects that have hit a wall to do code analysis and large-scale re-architecture. With that comes a lot of read-and-explain work both for myself and for my clients. Like most of you, I effortlessly type at about the speed people talk, so it keeping a running log comes easily. I also speed-read (not the gimmicky eyeball exercises but the old-school skimming and scanning) and practice a form of study that involves racing through material while typing notes, organizing said notes and re-reading 3-5 times to maximize extracting information, so on a good weekend, I'd type up several thousand lines of raw notes.
[1] And I'm not one to "web clip" -- if the blog post or article is important enough, I'll summarize it and re-type.