Re:Beej's Guide to Network Concepts
by wcarss on Thursday November 09, 2023 @12:44AM
(#38201605)
It's really cool to see something like this in the dedication, as one of a few "hardest things about writing these guides":
> - Putting myself out there as a so-called authority, when really I’m just a regular human trying to make sense of it all, just like everyone else
I read Beej's guide to networking like a bible when I was in a networking class around 15 years ago, and it pretty much solely got me through that class -- so I certainly _do_ think of him as an authority. Seeing him refer to his own very recent work and identity this way is a comforting testament and reminder that that feeling is normal, and that even people who do things which seem _amazing_ are just people too. Thanks Beej!
Re:Beej's Guide to Network Concepts
by hliyan on Thursday November 09, 2023 @12:49AM
(#38201628)
This is great. His original socket programming guide was one of my first exposures to network programming (even though I didn't understand it at the time). However, for network concepts, I prefer the historical context of "Connected: An Internet Encyclopedia" https://www.freesoft.org/CIE/Topics/index.htm
Re:Beej's Guide to Network Concepts
by beej71 on Thursday November 09, 2023 @01:03AM
(#38201705)
Hey everyone! This newer guide is basically what I wrote for teaching an Intro to Networking class last year. And I decided instead of keeping it locked away in the LMS I'd put it online for everyone.
Where the other, more popular guide is basically an intro to the C sockets API, this is more about networks in general.
There are certainly a large number of errors to still be found, and I'd love to hear about them if^H^Hwhen you find them.
The goal, as always, is ad-free and correct-as-possible. :)
Re:Beej's Guide to Network Concepts
by beej71 on Thursday November 09, 2023 @10:53AM
(#38206561)
I'm sure everyone has their own approaches for this kind of thing, but mine is basically this:
Try to remember what was difficult about this material.
Use that to guide yourself down to the core pieces. What is the kernel at the center of this mass of knowledge? "This would have been easy to learn if only... [what?]"
Often if you view the particular ecosystem as a dependency graph, the places to start are the root dependencies. If you go back far enough, there tends to be a single root.
Make sure that core foundation is well-covered and answers all those questions that made the material difficult when you learned it.
Then add some more use cases on top of it just to give the reader ideas of what they could go on to build. This won't be comprehensive, but should be tempting.
The very act of _learning to program_ should be exciting and fun. I recall when I was 12--every page of a programming book was unlocking something else in the world. "Wait--it can do _that_?" I try model this more as a path to follow at first and less of an open field going off in all directions. And I try to _hint_ that it _is_ actually an open field going off in all directions, but the reader can explore that later.
Don't worry about being wrong. Make an effort to be right (pride in quality) of course; just remember that everyone who produces a laundry list of reasons why your guide is crap and you shouldn't be allowed near a keyboard has just given you some free editing. :) If the points aren't valid, you can ignore them. If they are valid, you learn something (win), the guide gets better (win), everyone who reads it after the fixes gets better-quality info (win), and the complainer can no longer complain about those things (win). And ask Brian Kernighan or Rob Pike if they've ever published something wrong, and I guarantee they'll laugh knowingly. :)
My tone--I imagine I'm being a goofball discussing this with one of my best friends. I like that tone, I have an easy time writing in that tone, and it seems to be pretty popular. But I've also definitely had people complain about it being too casual. I don't know what to say, other than...
We're knights of the round table
We dance whene'er we're able
We do routines and chorus scenes
With footwork impeccable
We dine well here in Camelot
We eat ham and jam and spam a lot
Dah dah dah da da dah dah... [dude clapping in the dungeon]
Also, don't forget to reread and rewrite everything. There's always room for improvement.
> - Putting myself out there as a so-called authority, when really I’m just a regular human trying to make sense of it all, just like everyone else
I read Beej's guide to networking like a bible when I was in a networking class around 15 years ago, and it pretty much solely got me through that class -- so I certainly _do_ think of him as an authority. Seeing him refer to his own very recent work and identity this way is a comforting testament and reminder that that feeling is normal, and that even people who do things which seem _amazing_ are just people too. Thanks Beej!
Where the other, more popular guide is basically an intro to the C sockets API, this is more about networks in general.
There are certainly a large number of errors to still be found, and I'd love to hear about them if^H^Hwhen you find them.
The goal, as always, is ad-free and correct-as-possible. :)
Try to remember what was difficult about this material.
Use that to guide yourself down to the core pieces. What is the kernel at the center of this mass of knowledge? "This would have been easy to learn if only... [what?]"
Often if you view the particular ecosystem as a dependency graph, the places to start are the root dependencies. If you go back far enough, there tends to be a single root.
Make sure that core foundation is well-covered and answers all those questions that made the material difficult when you learned it.
Then add some more use cases on top of it just to give the reader ideas of what they could go on to build. This won't be comprehensive, but should be tempting.
The very act of _learning to program_ should be exciting and fun. I recall when I was 12--every page of a programming book was unlocking something else in the world. "Wait--it can do _that_?" I try model this more as a path to follow at first and less of an open field going off in all directions. And I try to _hint_ that it _is_ actually an open field going off in all directions, but the reader can explore that later.
Don't worry about being wrong. Make an effort to be right (pride in quality) of course; just remember that everyone who produces a laundry list of reasons why your guide is crap and you shouldn't be allowed near a keyboard has just given you some free editing. :) If the points aren't valid, you can ignore them. If they are valid, you learn something (win), the guide gets better (win), everyone who reads it after the fixes gets better-quality info (win), and the complainer can no longer complain about those things (win). And ask Brian Kernighan or Rob Pike if they've ever published something wrong, and I guarantee they'll laugh knowingly. :)
My tone--I imagine I'm being a goofball discussing this with one of my best friends. I like that tone, I have an easy time writing in that tone, and it seems to be pretty popular. But I've also definitely had people complain about it being too casual. I don't know what to say, other than...
We're knights of the round table
We dance whene'er we're able
We do routines and chorus scenes
With footwork impeccable
We dine well here in Camelot
We eat ham and jam and spam a lot
Dah dah dah da da dah dah... [dude clapping in the dungeon]
Also, don't forget to reread and rewrite everything. There's always room for improvement.