Hacker News Reader

The more I read about different applications, the more I think you can't understand them unless you look at the underlying data format.

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

— Fred Brooks, The Mythical Man-Month

That quote deserves to be in stone.

If we use 50 sculptors we can get it done in less than 20 minutes!

Oh man, that was a good one! Do kids these days even know about that book?

Probably not. Hell I've never even read the book. Instead I learned through experience and observation then later learning about the book and a summation of it :)

I do! (I'm 23, 18 months into my first professional engineering gig)

It should be required reading and I have it prominently displayed on my desk at work.

Small flaw though. It only runs on OS-X.

I might give it a shot if they decide to support linux.

Note: I was being sarcastic when I said small.

That honestly isn't a small flaw if you are building a note/documentation application of any kind. The ability to share it is too valuable to use anything that can't be used on all platforms.

Indeed. Why not make it web-based in the first place?

(Also, why is this specific to programmers?)

Here's a weekend project idea: Shiver, a web-based Quiver port which reads/writes in the same data format :)

Weekend? I suspect quite a few of them to produce a relatively polished app.

If it were web-based in the first place, I'd be complaining about that instead!

They make their data format public, so a Linux app could be built.

It's a small flaw... compared to not being on Windows.

I like the concept, but it's a non-starter while it's not available on... I don't know... the largest platform.

<i>I like the concept, but it's a non-starter while it's not available on... I don't know... the largest platform</i>

It is slightly unfair to complain about what platforms a developer chooses to publish his/her work on. Perhaps they have been a long term Apple user? Perhaps they don't know anything about Windows development.

Windows may be the largest, but there are so many good apps and developers making a living off the smaller platforms. This doesn't make using their apps a "non-starter".

> This doesn't make using their apps a "non-starter".

I don't think the parent meant a "non-starter" in general. This app seems really awesome, but I primarily develop on Windows, so it's a non-starter for me, which is really too bad. I was really excited looking through the page until I noticed it was only on OS X.

That and I'd prefer my electronic notebook to be available on my phone as well, so that's another reason I wouldn't use it. But if this ever comes out for Windows/Android, I'd definitely be excited to try it out.

I understand what you are saying. I re-read the parent post and it sure does seem that is exactly what the post says.

There are so many platforms available. I don't think apps would ever get released (or companies started) if for people to adopt them they had to be out for every desktop and mobile platform. That is unreasonable. Get something out there and iterate on it.

I prefer not to use my phone and tablet for stuff like this. It forces me to pay attention to it more than I wold like because I am carrying the device. I force myself to take breaks from work by not having work stuff on my phone. If one of my co-workers really wants me, they have my phone number.

No, they said "non-starter". Not non-starter for them, just non-starter.

http://stackoverflow.com/research/developer-survey-2015#tech...

According to the StackOverflow survey Windows has been losing developers for the past three years (though that's obviously not a new trend). So much that those stats say that there are about 2/3rds as many developers on OSX as were on Windows 7 (I don't know when 10 came out, but it's not represented).

IME if you're on a Mac at your day-job you on-average have a lot more freedom in which tools you're using, and you're a lot more likely to spend your own money on them.

All that just to say: I'd be very surprised if releasing for OSX first wasn't the best financial move for them.

I'm sold on it, but with it being OS X I cannot use it for a good while, until they port it. Hoping they do.

Based on the fact that they are using ACE to edit code cells and MathJax to render Latex, I'm going to go out on a limb and guess that a large chunk of the app is written using web technologies, and porting to Windows/Linux should be relatively straight-forward.

It also might mean that the entire thing is relatively heavyweight.

Yes, I have a few gigs of RAM on my laptop — but this RAM is needed for other apps, too.

It likely does use webviews, but it seems way lighter than an Electron app. It certainly isn't packaging Chromium given the size.

It starts up under 50MB with the built in notebook. Scrolling around between notes (with images) and starting a new notebook, I managed to get it up to 150MB (and then back down, so no strong evidence of memory leaks).

Not a huge deal to me for an app of this functionality at this point in time. (I do remember being able to run X11 + Netscape in 16MB, though.)

I use Zim on Linux. When I saw the Quiver screenshots I thought "hey, this is very similar to Zim!"

Can you compare this to org-mode? Any advantages / disadvantages?

I don't know if you can compare ANYTHING to org-mode :P

But it is a small program, gtk gui (I think), it is WYSIWYG, has lots of plugins (calendar, todo, tex equations) and it is a Wiki. Even the calendar plugin is mostly a helper to create note-pages with the date as their title.

This seems remarkably similar to the Jupyter (IPython) notebook format [0]. The only big difference I can see is the separate metadata file, which I'm not so sure is a plus (since it adds the complexity of needing each notebook to be a folder).

[0] https://ipython.org/ipython-doc/3/notebook/nbformat.html

It's a tricky situation. I'm not sure which is best. The advantage of using a directory for your format is that it's easy to use preexisting tools on the contents of a note.

Say your note looks like the Quiver example:

  B59AC519-2A2C-4EC8-B701-E69F54F40A85.qvnote/
  ├── content.json
  ├── meta.json
  └── resources
      └── BCA3F8A8-C8CC-4FE5-AABB-C4262134B9E7.tiff

You can examine and modify the .tiff file using normal command line tools. This is nice!

Whether this adds to the complication of the project depends on your perspective. From the user's perspective this is simpler, they can now use normal tools to work on resources without having to manually extract and then reinsert the resource.

But from an overall perspective (which is probably more important), I think you're right that this is more complicated. Directories are higher level than JSON files -- we don't always have tools that can work with them. A JSON file has a both a single Unicode and byte representation, not so for directories. Losing this to make things easier on the user is no small deal.

Perhaps the right answer _is_ to put the whole note in a single JSON file. From there it can be transformed into directory with FUSE for modification by standard tools (or for export purposes if the user wants to move away from our note type). I'm still not sure about this though.

Right, but Jupyter lets you evaluate the code, which is much cooler than just editing it. On the other hand, Quive may have better search functionality.

> Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has undo somehow I'd like to hear how they do it).

The GUI does have an Undo, and it works exactly as you expect: it reverts changes made in the GUI app. If you have a note open and you make an external change, the app will at some point notice the change and ask you if you want to reload; if you say yes, it reloads from disk and throws away the undo history. I was able to get it to reload content without realizing it changed (by editing the note, then closing it in Quiver before it detected the change and reopening) and this didn't throw away the undo history, which seems like just a fairly simple bug.

Or to put it more generally, Undo works in Quiver pretty much the same way you'd expect it to work in any editor that can reload files that change on disk; the undo history simply doesn't concern itself with undoing changes made outside of the app, and in most cases reloading the file from disk throws away undo history.

Oh, that makes sense! So it's exactly like Vim (with noswapfile turned on) or any other program that tracks history at the application-level, but doesn't write it to the directory you're working in.

Sublime seems to work very well in the case you describe: The changes coming in from a reload are simply put into the undo history just like any other change. No need to throw anything away.

Smallest Federated Wiki's format is very similar:

https://github.com/WardCunningham/Smallest-Federated-Wiki/bl...

Whoa, how have I not seen this before? Thanks for the link.

This weekend I kept thinking about wanting to make a trello like board for personal knowledge or idea tracking but keep it git version controlled, your comment reminds me that maybe others are in the same track.

I think https://gingkoapp.com might fit in that niche.