Technical books and notes: Difference between revisions
Jump to navigation
Jump to search
imported>Johayek |
imported>Johayek |
||
| Line 5: | Line 5: | ||
== 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 === | ||
==== The Unix Tools Are Your Friends ==== | ==== #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 | * mentions BusyBox and Cygwin | ||
=== Data Science at the Command Line === | === Data Science at the Command Line === | ||
==== running the Vagrant VM not just locally on some physical machine but … ==== | ==== running the Vagrant VM not just locally on some physical machine but … ==== | ||
Revision as of 15:12, 24 August 2015
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
#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.