ProgrammingBookmarks - Tech

   * UnixProgrammingBookmarks
   * WebProgrammingBookmarks
   * JavaProgrammingBookmarks
   * DatabaseProgrammingBookmarks
   * XmlProgrammingBookmarks

---+ Source Code Control

*git* is a _distributed_ revision control system.  http://git.or.cz/

GitNotes

*CVS* is the Concurrent Versions System, a tool for source code revision control.  The CVS home page is at http://www.cvshome.org/ and the User's Guide (also called the "Cederqvist Manual" because it was written by a guy named Per Cederqvist) is at http://www.loria.fr/~molli/cvs/doc/cvs_toc.html.  A book called "Open Source Development With CVS" is partially online.  The parts that are online seem to overlap substantially with the Cederqvist book but might be useful: http://cvsbook.red-bean.com/cvsbook.htm

CVS is fundamentally a UNIX program, but there are several different clients available.  <nop>WinCVS is the most commonly used, but it's not very easy for non-technical people to use.  At a couple of shops I've worked at we used CVS for code and Microsoft's VSS for documents.  This is a bad idea for a lot of reasons, not least of which is that it requires you to use Windows to access version control.  That's why I'm really excited about <nop>TortoiseCVS http://www.tortoisecvs.org/ which is a very well-designed Windows interface for CVS.  It plugs into the Windows File Explorer so there's no new UI to learn; you perform version control operations from within a tool that everybody already knows how to use.  Cool!  (You can make <nop>TortoiseCVS play nicely with Cygwin if you tell <nop>TortoiseCVS to use your Cygwin home directory as its home.  That way you can check out a directory tree using <nop>TortoiseCVS and then do cvs operations in Cygwin without having to login again.  _right click->CVS->Preferences... then click on the "Quirky" tab_)

*arch* is another version control system that attempts to fix the problems in CVS while adding new features.  It's had an _interesting_ life so far; the primary developer went bust while writing it and it's since been picked up by other folks and has become a GNU project.  http://www.gnu.org/software/gnu-arch/

*darcs* is a patch-oriented version control system.  It's interesting in that it doesn't look at code in terms of a tree that evolves over time, but in terms of a set of patches that product a desired result.  http://darcs.net/

*mercurial* is changeset-oriented system.  It's supposedly the leading candidate to become the next-gen Linux SCM if Linus decides to switch away from git.  http://www.selenic.com/mercurial/

*Writing good commit messages* - http://news.ycombinator.com/item?id=4270890

---+ Misc

*Producing Open Source Software* - http://producingoss.com/ "is a book about the human side of open source development. It describes how successful projects operate, the expectations of users and developers, and the culture of free software."  From a quick skim of the table of contents (the whole book is online) it looks to be very complete.

*Project Life Cycle* - is a collection of very useful info regarding the various phases a software project goes through over its life cycle.  It also includes some template documents which are useful for interaction between the client and consultant.  http://www.cratchit.org/dleigh/plc/plc-index.htm

*Software Architecture* - is an _extremely_ nebulous term in the context of software.  Everyone agrees that it's important, but nobody really agrees on what it is.  This site is a useful resource, though.  http://www.bredemeyer.com/

The Architecture of Open Source Applications - http://www.aosabook.org/en/index.html

*Extreme Programming* - is a recent fad methodology, and I've pretty much hated the various programming fads that preceded it (TQM, ISO9000, CMM, etc).  XP has some very good features, though, some of which I've incorporated into my day-to-day work.  One is a strong belief in unit testing, which has definitely paid off for me.  Another is working closely with the customer and setting very small, visible goals that you can easily track.  Worth an hour or two at their web site:  http://www.extremeprogramming.org/

*How To Ask Questions The Smart Way* - Eric Raymond has written many interesting papers about programming in general, and especially Open Source.  This one is great - it explains how someone can ask questions of programmers in a way that's most likely to generate a successful response.  If you're a user then you should read it; if you're a programmer then you'll probably find it handy to point people to: http://www.tuxedo.org/~esr/faqs/smart-questions.html

*How to Report Bugs Effectively* - http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

*RFC's* - are the documents that describe internet protocols.  There are many ways to get them; among them are [[http://www.ietf.org/rfc.html][raw]] and [[http://zvon.org/tmRFC/RFC_share/Output/index.html][cooked]].

*Binary Arithmetic Considered Harmful* - It's not commonly understood that binary numbers are imprecise to the right of the decimal point.  http://www-106.ibm.com/developerworks/java/library/j-jtp0114/ is a good intro to floating point and its problems.  Although Java-centric, it has a good introduction to the topic and good references.<br/>
Also: http://blog.reverberate.org/2014/09/what-every-computer-programmer-should.html<br/>
Also: http://0.30000000000000004.com/

*Financial Calculations* - http://quantlib.org/ is an open-source C++ library for sophisticated financial calculations.

*Linux in the Workplace* - http://linuxpip.org/ is a book that talks about how to use Linux in a business environment.

*Communicating Sequential Processes* - http://www.usingcsp.com/ a theoretically sound approach to concurrent programming.


*Agile Manifesto* - http://agilemanifesto.org/


*Gardening With Tracer Bullets* - http://today.java.net/pub/a/today/2004/02/23/davenandy2.html I agree with most of what these guys are talking about.  The more you try to "anticipate" what you're going to need in the distant future the more that you're guessing.  Start small and build on that.  I love the "programming is gardening" metaphor.

*Notes on Distributed Computing* - http://research.sun.com/techrep/1994/abstract-29.html Sun labs researchers point out the ways in which writing distributed computer programs is different than writing local ones.

*How to denote numeric ranges* - http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html In summary, use =lower &#8804; i < upper=.  Another way to describe these is "half-open ranges": http://www.siliconbrain.com/ranges.htm

*Markup Languages* - XML, despite what Java folks will tell you, isn't the be-all and end-all of markup languages.  The interesting discussion at http://www.reddit.com/r/programming/comments/7muux/ogdl_an_incredibly_lightweight_markup_language/ discusses OGDL, YAML, and XML and how they compare to one another.

*Unicode* - the best quick intro I've seen: http://wiki.secondlife.com/wiki/Unicode_In_5_Minutes , and another that goes deeper: http://dmiessler.com/study/encoding/<br/>
A fun rant about how "unicode" is not the same thing as "utf-8": http://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-is-not-utf/

*Maker's Schedule* - a very interesting article about how "makers" and managers view time differently: http://paulgraham.com/makersschedule.html<br/>
This is related to Demarco and Lister's discussion of "flow" in _Peopleware_.  Here's Joel Spolsky's review of _Peopleware_: http://www.amazon.com/review/RYVTUPDAUANZW <br/>
Somewhat related is the question of what really motivates creative people.  Turns out it's not money: http://www.youtube.com/watch?v=rrkrvAUbU9Y<br/>
Well-researched presentation about software management (team size, hours, etc): http://www.lostgarden.com/2008/09/rules-of-productivity-presentation.html<br/>
Even very short interruptions have a surprisingly large impact on error rates: http://www.futurity.org/top-stories/3-second-distraction-doubles-work-errors/<br/>
http://www.newyorker.com/online/blogs/currency/2014/01/the-open-office-trap.html - open plan offices are less productive than offices with doors

*Developer Support Handbook* - http://www.developer-support-handbook.org/intro.html <blockquote>In this handbook, I mostly cover the first aspect of providing an API: support. It is probably the least glamorous aspect, but on the other hand, it is vital. You can have the best API in the world, but if people post in your forums and the response is just crickets chirping, then the developers will not stick around for very long. On the other hand, if you treat your developers well, then they will (for free) provide you with valuable insights about ways to improve your API, and they will evangelize your API for you.</blockquote>

*How to Design a Good API and Why it Matters* - Uses Java examples but it's generally good advice for any language: http://lcsd05.cs.tamu.edu/slides/keynote.pdf

*Hashing* - http://programmers.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

*Design Principles* - from the UK Government design group: https://www.gov.uk/designprinciples <br/>
from Dieter Rams, a famous industrial designer: http://www.vitsoe.com/en/gb/about/dieterrams/gooddesign/

*Guess Gender by First Name* - code (and database) to guess a person's gender from their first name: http://www.autohotkey.com/community/viewtopic.php?t=22000