- Development Process
- Technical Topics
- Coding chunks and Collaboration Mechanics
- Recruiting, Interviewing
At first the tickets were just a way for me to track my own work, but we're getting pretty good at using trac for an approximation of the XP planning game: Russ plays business customer and I represent development. Sometimes sketching milestones and breaking them down into tickets is straightforward enough, but sometimes I don't understand what he's asking for, so I ask him to tell me stories about how it works, and we capture those in the wiki.
- UsingVersionControl, especially setting up TortoiseHG on Windows
- HeronProjectTimeline (whose name is a bit ironic, since the trac uses "timeline" to look back; for looking forward, it uses "roadmap")
- UnderTheHood - details about this project management and issue tracking system
Testing, documentation, and quality software development
Databases, Data Warehousing, and Information Security
- SQL - central to just about everything we do: HeronLoad, REDCap, CRIS?, etc. Russ has some books
- Data Warehousing (including ETL)
Web Design, Security
- Web Design for Developers - Dan got it based on a nod from Tim Bray. I haven't read it yet, though
- Tangled Web book on web security
- AuthorityInjection -- patterns of secure composition
- We've had good experience with the python pyramid web framework; see [9e4f4c169c5e/reqroute] to get started. It's known for a "pay only for what you use" style, and it works reasonably well with AuthorityInjection, since it doesn't rely on globals.
Opening New Browser Windows
Opening New Browser Windows is one of the top 10 mistakes in web design, according to Jacob Nielsen. It seems to be a KUMC norm, meanwhile. todo (Dan): find KUMC web styleguide and see if this is a conscious decision, and what it would take to get it changed.
- python - we use it in our HeronLoad ETL process, HeronAdminDev, web integration, etc.
- python cheat sheet
- PEP: 8 Style Guide for Python Code
- python tutorial
- Python is a language you can get into on one battery'' -- Tim Berners-Lee, Oct 2010
- official python docs are a great reference. (multiple formats are available, including typeset versions for printing.)
- Russ has some books
- deployment: PythonOnWindows?, PythonVirtualEnvironment
Stack Overflow is a great community resource for all of the above (and much of the below...).
Software Carpentry is a good source for somebody who's new to programming.
System administration, web server administration
- InformationResources? - our partners in monitoring, administration of HERON, REDCap, CRIS?, etc.
- ops keyword tickets
Statistics and Data Analysis with R
The informatics division is part of the biostatistics department, our work hasn't involved much stats yet, with the exception of HeronStatsPlugins.
- R: R project
- Introductory Statistics with R by Peter Dalgaard (Russ's)
- Google's R Style Guide
- Introduction to data analysis Hadley Wickham Fall 2012. Rice University
- Dan's bookmarks tagged statistics and programming
- Dan got The Art of R Programming. on the basis of recommendations such as Nov 2011 on Stack Overflow
- It has, for example, nothing on automated testing; so I'm not sure I'd recommend it.
- Advanced R programming by Hadley Wickham
WritingQualityCode#r-pkg is starting to take shape.
Coding chunks and Collaboration Mechanics
I maintain that programming cannot be done in less than three-hour windows. It takes three hours to spin up to speed, gather your concentration, shift into "right brain mode", and really focus on a problem. Effective programmers organize their day to have at least one three-hour window, and hopefully two or three. -- The Tyranny of Email, Ole Eichhorn, March 2003
I disagree with Eichhorn about shared text chat. More on that below. -- Dan
Meetings are valuable, but costly too. So let's be judicious about doing them, and do them right. (Avoid the The Seven Sins of Deadly Meetings)
One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more. -- Maker's Schedule, Manager's Schedule, Paul Graham, July 2009
- CodeRevewNotes (ugh... misspelled... need trac wiki rename tool)
Improving efficiency with text chat
We (Biomedical Informatics) are physically co-located, so it's less critical than when collaborating remotely, but it's still useful:
- technical details are often easier to communicate in text than by voice (e.g. error messages, URLs, commands to type)
- text chat is near-real-time; you can think out loud and somebody might respond right away or quite a while later or not at all.
The random rewards of gambling are much more seductive than a more predictable reward cycle. -- Your brain on gambling
- People shouldn't be expected to respond to email instantly. Allowing email to interrupt work is terribly counter-productive; it's best to leave it be until a natural stopping point.
- Ringing somebody's phone is sure to break their concentration.
The interruption costs more than just the minute or two to deal with the incoming call or message:
It typically takes about 15 minutes of uninterrupted study to get into a state of "flow", and the constant interruptions and distractions of a typical office environment will force you out of "flow" and make productivity impossible to achieve.
In your development process, identify the activities that disrupt flow, and modify them until they don't. ... For example, consider getting rid of the telephone.
With shared text chat, people can choose how much attention to give it any time, to participate or not, respond quickly or slowly, etc. This leads to some suggestions:
- Rather than asking "may I interrupt you?" face to face or by phone, consider text chat first. There's no way to say "no" in the other two media.
- If it's important but not urgent, use email.
- Feel free to turn off or tune out text chat; if it's critical, people can escalate to other means.
For real-time collaboration with (and support from) the wider open source community, see FreeNode.
See also Social standards and coding fugues, Dan C., Feb 2007
- Cracking the Coding Interview: 150 Programming Questions and Solutions by Gayle Laakmann