Technical books and notes: Difference between revisions
Jump to navigation
Jump to search
imported>Johayek mNo edit summary |
imported>Johayek mNo edit summary |
||
Line 11: | Line 11: | ||
== Business/Publishing_and_Printing/Publishing/Books/Business/O'Reilly_and_Associates == | == Business/Publishing_and_Printing/Publishing/Books/Business/O'Reilly_and_Associates == | ||
=== 97 Things Every Programmer Should Know === | === 97 Things Every Programmer Should Know === | ||
This is also a book on [[Clean Code]]. | |||
==== #06: Before You Refactor ==== | ==== #06: Before You Refactor ==== | ||
* The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. | * The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. |
Revision as of 15:22, 24 August 2015
Business/Publishing_and_Printing/Publishing/Books/Business/Addison_Wesley
The Pragmatic Programmer
This is also a book on Clean Code.
- …
Business/Publishing_and_Printing/Publishing/Books/Business/Manning
Minimal Perl
Business/Publishing_and_Printing/Publishing/Books/Business/O'Reilly_and_Associates
97 Things Every Programmer Should Know
This is also a book on Clean Code.
#06: Before You Refactor
- The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code.
- Avoid the temptation to rewrite everything.
- Many incremental changes are better than one massive change.
- After each development iteration, it is important to ensure that the existing tests pass.
- Personal preferences and ego shouldn't get in the way.
- New technology is an insufficient reason to refactor.
- Remember that humans make mistakes.
#08: The Boy Scout Rule – by Robert C. Martin (Uncle Bob)
criticism: doesn't that violate "never change a running software"?!!
#88: The Unix Tools Are Your Friends
- mentions BusyBox and Cygwin
Data Science at the Command Line
running the Vagrant VM not just locally on some physical machine but …
- I want to run the Vagrant VM on a strong physical machine attached to my LAN,
- I want the VM to have an interface (VirtualBox: Bridged Adapter) and its own IP address on the LAN;
- the VM's OS is ubuntu;
- its hostname is data-science-toolbox;
- I want to access the OS from another machine on my LAN, not just from the machine, that hosts the VM:
$ ssh vagrant@data-science-toolbox
If I start the Vagrant VM through its ordinary interface, Vagrant complains about a NAT rule of this names already existing.
But I am starting the VM from the Oracle VM VirtualBox Manager – that way it works without complaint.
With a entry in $HOME/.ssh/config :
# from $HOME/.ssh/config : Host data-science-toolbox User vagrant
… the ssh command line is even shorter:
$ ssh data-science-toolbox
installing the tools elsewhere
Appendix A lists the command-line tools together with their home pages.