This is a great list. As someone who has spoken at hundreds of conferences, there's one piece of advise I give younger speakers, particularly those nervous about how the audience will receive them. Dylan alludes to this in a different context
> Finally: respect your audience. Whether you’re talking to five people at a meetup, fifty at a community event, or five thousand at a huge international conference: those people are the reason you get to do this. They have given up their time - and often a substantial amount of money - to hear what you have to say. They deserve your best shot, every time
This is the same thing I say except, them _choosing_ to attend your talk, and opting in to giving you their time and attention is a signal that they _want_ you to succeed. They are HOPING you deliver your message, and that your demos all work, and that you conclude well. If kept in mind, I believe this can help alleviate some of the anxiety.
Sidebar: I've done this for a very long time and I still get nervous at the beginning of every talk. And I will be the first to admit—you WILL run into the occasional show off in the audience who is intent on demonstrating to you (and to the rest of room) how much smarter or more experienced they are than the speaker. That will happen—but it's an aberration.
I am very excited to try Draw Over It—thank you for sharing. I speak at several conferences a year, and also do online workshops and training, and Presentify has been a godsend.
However, the one limitation is if you toggle it, you lose your annotations. And you can't do anything with the underlying app—can't scroll or click buttons. Looking forward to trying this out.
Let me start by saying this is wonderful work. Thank you for creating such a comprehensive resource. I haven't read through it all, but one thing did catch my eye.
> The default branch used to be called master, and still is called that in some older repos.
This is not true. Git still defaults to `master`, but allows you to change the default (for future `git init` invocations via `git config --global init.defaultBranch <name>`)
Again, thank you. If I find anything else, I will be sure to post here.
*Update*: I also feel that referring to "older repos" sends the wrong message. *GitHub* decided to make this change, causing others to follow, and finally Git itself allows for the aforementioned configuration, but it has little to do with _newer_ or _older_, but rather preference.
Not the OP, but I've been teaching along similar lines. I've done it a couple of times at conferences—here's one of the versions: https://www.youtube.com/watch?v=8Q-frNO-yps
Let me start by saying (as someone who has written a few technical books of his own)—Congratulations!
I am sure you (assuming this is your first book) are learning that this is a labor of love, and I wish you the very best in this endeavor. You should be proud!
I was exposed to "data oriented programming" thanks to Clojure—wherein maps/sets are the constructs used to pass data (as plain data) around, with simple functions that work with the data, as opposed to the traditional OO (hello ORM) that mangles data to fit some weird hierarchy.
Java's recent innovations certainly make this a lot easier, and I am glad someone is looking at propagating a much needed message.
I will take a look at the book, but I wish you the very best.
While I'd like to think that this is _somewhat_ useful, I am a little hesitant. The issue I see with these bite-sized recipes is that there is no context, no place for nuance, and no hint that the behavior you see might be different for a variety of reasons.
Take the following for example:
> Oh shit, I need to change the message on my last commit!
> git commit --amend
It's important to realize here that if you are simply trying to edit the last commit message, you *should not* have anything in your index (that is, staged). Otherwise those changes will be recorded in the amended commit! What Git does is essentially move all the changes recorded in the commit you are amending _into_ the index, and then run `git commit -m <amended-message>` ... so if you have files in there, those will get mixed up with the ones in the commit.
Here's another one:
> Oh shit, I accidentally committed to the wrong branch!
> A lot of people have suggested using `cherry-pick` for this situation too, so take your pick on whatever one makes the most sense to you!
Umm ... No! The solution proposed (with `git reset --soft`) and a cherry-pick are NOT the same! Not even close! You will produce two completely different histories.
This final one, given when this page was written, _may be_ understandably incorrect
My book, Head First Git, was published by O'Reilly this January. I posted a submission here on HN about it https://news.ycombinator.com/item?id=30072348 so if you want any details feel free to peruse that.
This reminds me a brilliant article [1] by Barbara Oakley, who has a _superb_ course on Coursera on "Learning How to Learn" [2].
In this article, Barbara talks about how memorization helped her with Mathematics, a subject that she had previously struggled with. In particular, this line stands out to me
> Continually focusing on understanding itself actually gets in the way.
@luxpir mentioned Obsidian in another comment [1] and it might be what you are looking for, in particular with a community plugin called Obsidian Dataview [2]. Dataview uses JavaScript as a query language and can query the Obsidian "vault" and create different views.
Another tool to look at is Logseq [3], which is essentially an outliner (supports both MarkDown and Org syntax), but supports a rather simplistic TODO management system. The benefit here is exactly what you describe—as you work in Logseq, you can create Todos, thereby connecting the task to the related source and any context that surrounds the todo. Furthermore, Logseq also allows for queries [4], allowing you to query your "knowledge graph", which you can embed in other pages.
Both Obsidian and Logseq store your files locally, so they can be easily version-controlled (In fact, Logseq routines commits your files for you).
> Finally: respect your audience. Whether you’re talking to five people at a meetup, fifty at a community event, or five thousand at a huge international conference: those people are the reason you get to do this. They have given up their time - and often a substantial amount of money - to hear what you have to say. They deserve your best shot, every time
This is the same thing I say except, them _choosing_ to attend your talk, and opting in to giving you their time and attention is a signal that they _want_ you to succeed. They are HOPING you deliver your message, and that your demos all work, and that you conclude well. If kept in mind, I believe this can help alleviate some of the anxiety.
Sidebar: I've done this for a very long time and I still get nervous at the beginning of every talk. And I will be the first to admit—you WILL run into the occasional show off in the audience who is intent on demonstrating to you (and to the rest of room) how much smarter or more experienced they are than the speaker. That will happen—but it's an aberration.