MIT Hacker Tools: a lecture series on programmer tools
hacker-tools.github.io
hacker-tools.github.io
There’s just no class in the undergrad curriculum that teaches you how to become familiar with the system you’re working with! Students are expected to know about, or figure out, the shell, editors, remote access and file management, version control, debugging and profiling utilities, and all sorts of other useful tools on their own. Often times, they won’t even know that many of these tools exist, and instead do things in roundabout ways or simply be left frustrated about their development environment.
To help mitigate this, we decided to run this short lecture series at MIT during the January Independent Activities Period that we called “Hacker Tools” (in reference to “hacker culture”, not hacking computers). Our hope was that through this class, and the resulting lecture materials and videos, we might be able to bootstrap students’ knowledge about the tools that are available to them, which they can then put to use throughout their time at university, and beyond.
We’ve shared both the lecture notes and the recordings of the lectures in the hopes that people outside of MIT may also find these resources useful in making better use of their tools. If that turns out to be true, we’re also thinking of re-doing the videos in screen-cast style with live chat and a proper microphone when we get the time. If that sounds interesting to you, and if you have ideas about other things you’d like to see us cover, please leave a comment below; we’d love to hear from you!
We’re sure there are also plenty of cool tools that we didn’t get to cover in this series that you all know and love. Please share them below along with a short description so we can all learn something new!
Anish, Jose, and Jon
Now I'm out in the real world (MIT class of '86!) I think this is more of an MIT thing -- many graduates of other schools get explicit training in things that the MIT faculty, fairly or not, assumes students will simply pick up. And this is despite the heavy emphasis on actually doing stuff, especially in the school of engineering. Actually I've had hit or miss results hiring freshly-graduated MIT grads (maybe less so VI-A) for this reason, though once they are up to speed they've mostly been great.
Really good use of IAP by the way!
uh...I graduated from a low tier state school that was notable in our state for focusing on practical matters....and we didn't get 'explicitly trained' on this either. Most people do just pick it up.
As an MIT grad myself I should be biased to think otherwise, and I certainly hope the credential stands for something good. But I haven’t found much difference in programmers 5 years out of school — it’s been attitude that has mattered more.
While you definitely do pick stuff up over time, this is arranged in a way that I could see myself preferring to reference this rather than find that one stack overflow answer that clicked with me at the time. Now that I at least have a better understanding of these concepts 3.5 years into real-world web development, this seems like a good resource to cover my bases better now.
From my undergrad programming class, which was a while ago, I remember that the first class had a brief intro to vim. But something like vim is an acquired taste. I never used or appreciated vim until much later when I saw others at work use it. During school, I think I used geany since that's relatively easy to use and install on ubuntu. So maybe there is some merit to spending more time on tools. However, my experience is from before everything was so easily accessible on the internet (i.e., pre github, stackoverflow etc.). So maybe these days it's not such a big deal.
(BTW, among things I’m glad that MIT has done, open courseware is top of my list. Glad you used it!)
Early pilots of the course were put together with a set of Linux guides including bash scripts and Makefiles, source control with svn (hopefully hit by now), and moved quickly into practical stuff with bison / yacc to parse complex files and work with GCC output. I never got to see how well it was received by students but I was glad to see students go through the time-honored traditions of learning CLI tools.
Thanks a lot for this! It appears like the recording doesn't really capture the screen well for multiple videos. I wish it was more professionally done, it could've been useful for years to come.
Sadly, we're missing screen recordings for a couple videos (such as the shell video, where we had some issues with the screen recording software). We're thinking of re-doing some of those videos in a screen-cast style so that they'll be more useful for viewers.
For me the key point above is about a lack of tool knowledge causing "roundabout approaches" and frustration. Knowledge of these tools can do so much to demystify and make the seemingly arcane start to slot into place.
Anyway, my list of topics is as follows, maybe you want to consider adding a few of them to your list?
Password Managers • 2-factor authentication • Virtual machines • Package managers • Command line • Routers • QR codes • Port forwarding • Python • Pandas • Onion routing • Ad-blocking • PDF reordering • Flow charts • Regular Expressions • Time-lapses • Encryption • Column edit • Digital photo editing in RAW • Audio noise reduction • Vector graphics • Making websites • DJing • LaTeX publishing • Reference management • pandoc • git version control • Programming • Web apps • Self-hosting • Home automation • Monte Carlo • VPNs, • ImageMagick • Linear regression • ffmpeg • Sphinx • Robotics
That's the one?
EDIT: I guess it is, via https://digitalsuperpowers.com/. The list of topics is great, gonna check the book out!
I am happy you had compatibility in mind as I am not super fussed on which operating system I use.
I would suggest adding a virtual desktop section as that has been the biggest gamechanger for me ( I use windows 10s with virtual desktop enhancer) I dont know any linux or mac equilivants though.
Gary Bernhardt - The Unix Chainsaw
What a champ!
Vim -> Emacs is a better direction than Emacs -> Vim, because you’ll learn the more efficient editing style, then have access to the better environment, instead of getting used to the great Emacs environment minus the Vim keybindings, and feeling constrained by losing this when moving on to Vim.
Nobody wants to die on Emacs Keybindings Hill, even diehards like me and my pinky.
From my perspective, I tried to learn Emacs, and decided it's a great editor, once you spend weeks to months to get it actually "working good," and learn shitloads of commands (let alone keybindings). Given my initial goal was "keep hands on home row," it was far, far faster/better for me to spend 3 days learning/memorizing VIM commands, installing a vim plugin into VScode, and just doing that.
Would love to use Emacs, but it's a nightmare to set up. I still haven't managed to get it feature parity with vscode.
Maybe you would like spacemacs then? It is a Configuration Bundle for Emacs focusing on "Evil Mode" (aka the Vim emulator in Emacs). It is just a few minutes to install and if you already familiar with vim then there should not be much change what the normal editor usage is concerned. Of course the customization is Emacs lisp which has a bit of a learning curve, but just to get started with Emacs and evil you don't really need to customize anything.
Getting Emacs installed and running should hopefully be easy (e.g. via your OS package manager). After that I think it mostly comes down to coming up with workflows that you're comfortable with, building muscle memory and gradually introducing new things to see whether or not they stick.
No emphasis on git, but I used it anyway.
A decade later, and my Emacs easily surpasses most VS Code features.
A decade later. Heh. Co-workers use VS Code OOTB and I'm like, "Yeah, but can you tangle or play Tetris?!"
Truth is, whatever works for you and gets out of your way is the right tool. I'm invested and happy with Emacs, but also I get why it's not the first choice for a lot of devs.
Even though it should be. :)
BTW, Stanford did an online training course 5 years ago or something called CS 184 Startup Engineering. They had some excellent tutorials on the CLI and Emacs [1]. -I wish I could find the materials, if anyone else can find them.-
Actually, I found them online: [1] http://docshare.tips/cli-git-emacs-dotfiles_57592eb2b6d87f37...
[2] Link to their dotfiles for beginner config: https://github.com/startup-class
I looked at the Wikipedia article [1], but none of the alternatives seem to do that.
What can you recommend?
===
You could start with this guide, which solves a slightly different but related problem: https://virtualizationreview.com/articles/2017/02/08/graphic...
Sorry, but I don't think there is anything you can do about the GUI..
I like to use x2go on another machine or VM, it gives you access to individual windows/tiles for Linux programs, similar to Citrix published apps.
I have a branch on my todo list solely focused on my tools, because there are so many things to configure continuously. I schedule these tasks for the occassion I feel like I'll have a couple of minutes to improve and their priority are often labeled as "Compounding Rewards" as opposed to "Critical".
Literally none of these have anything to do with proper information security/hacking/penetration testing. Will you please consider to stop abusing the term "hacker"?
So in the context of some people from MIT putting out a list of resources, originally for others at MIT doing #1 above, "hacker" is the right word to use.
Not "hacker" in this sense: https://en.wikipedia.org/wiki/Security_hacker
I know this will piss off vim users but in my experience vim users are seriously out date when it comes to dev tools. It's like they never left the 70s. vim might be great, it might be available everywhere but when I see a vim user I then see them use something like gdb and have clearly never experienced a modern debugger because if they had they'd be infuriated at how their debugging tools haven't improved in 30 years.
I'm sure others could go into all the features a modern editor or IDE provide. The vim users will say they don't need that crap. They sound like some grandpa saying "back in my we had to walk to 5 miles to school, no one had invented bicycles or cars or buses. Don't need those new fangled things, now Get off my Lawn!"
If you want that shallow level of debugging you can do it from inside vim though: https://github.com/idanarye/vim-vebugger
sounds like you've never used one but then that's what I'd guess from watching most vim users. All of those have been standard features of visual IDE debuggers for over 30 years. Mean while instead of seeing every thing update live I watch the vim users type various gdb print and dump commands at the command line and then watch that data scroll off their terminal instead of being updated live as they progress like an IDE debugger.
You'd be mistaken, I've spent a huge chunk of my adult life inside Visual Studio. IME most devs don't even know you can add a condition to a breakpoint (hiding feature behind right clicks aren't obvious) and anything complicated turns into a very convoluted process very quickly. Even setting conditional breakpoints are basically an input into the command interface, essentially what the windows run menu is to the command line.
Take this short tutorial (https://amazingdim.wordpress.com/2014/02/01/gdb-script/) on gdb scripting and show me how to do similar through an IDE. With Visual Studio at least it is much more complicated, here are a few google results on that path:
1. https://docs.microsoft.com/en-us/visualstudio/debugger/using... 2. https://blogs.msdn.microsoft.com/debugger/2009/12/30/what-is... 3. https://stackoverflow.com/questions/47513337/howto-debug-a-n... 4. https://docs.microsoft.com/en-us/windows/desktop/wer/collect...
Can confirm: I sure didn't. ...honestly most of my debugging is with print statements.