Our two-day workshop at the University of Alberta wound up a couple of hours ago. We had quite a few no-shows this time (which was annoying, given how many people were waitlisted), but those who did come seemed to get a lot out of it:
| Good |
Bad |
- Room
- Mix of talking & doing
- Stickies
- Version control
- Hands on
- Link on online video
- Python
- Clear speaking
- Computer in lab (using linux)
- Automatic versioning
- Programming in windows in Cygwin
- Philosophy
- Discussion of productivity
- Good reading suggestions
- Functional programming
- Overall workflow
- I feel more competent (morale boost)
- Researched anectodes, backed with data
- Website
- TDD
- Instructor’s body language
- Helpers
|
- Coffee hard
- Need more projectors
- Having to keep stickies
- No testing
- Not enough depth
- Not convinced about version control
- Too fast on day 1, too slow on day 2
- Need levels
- Came late
- Not enough Python
- No lunch
- No time for notes
- More version control
- Too short break
- No shows
- Pace (a little fast)
- Supervisor wasn’t here (need to convince her)
- Where is the code (dropbox?)
- Bad chairs
- Windows alienation
- Mailing list
- Making DB (no info)
|
Many thanks to Rose, Neil, and Paul for making it possible.
We have just added another workshop to the summer’s list, this one at Saint Mary’s University in Halifax, Nova Scotia, on July 16-17. Please let friends and colleagues know—I look forward to meeting them.
We’re pleased to announce that we will be running a two-day boot camp at Johns Hopkins University in Baltimore on June 18-19, 2012. We only have space for 20 participants, so please register early.
Our workshop at Michigan State University this week was three days long instead of two, and included two topics (Git and the IPython notebook) that we haven’t tried before. Feedback was generally positive, but we’ve got lots to work on for next time as well.
| Good |
Bad |
- Using history
- Ending with general theory
- Pen and paper database design
- Version control was useful
- Good practice in software
- Concise and module programming in Python
- Console segment
- Smooth flow between Bash and Python
- Challenging and flowed nicely
- Futher reading material
- Desktop setup
- Instructor teaching style
- Permission to spend less time coding
- iPython notebook looks great
- Paired programming model
- Git script (tutorials used were available)
- Legal issues (opensource)
- Good for beginners
- Free course (and food!)
- Variety
- Practical (reality-based)
- Overview of DB options
- Testing
- Better ways to do things
- Somewhat static seating created helpful partners
|
- Typing speed is too fast
- Class time chunks too long
- Why iPython
- Need more ‘why’
- Curriculum
- Advanced Git bounced
- Too much switching screens
- Some things failed
- Beverages included only caffeine
- Need snacks at breaks
- Lacked connection between course material and applicability
- Tuesday way too long
- Wanted a cheat sheet
- Not enough exercises
- How to create DB
- Anti-Windows bigotry
- Next day install at end of day
- Some concepts skipped
- Don’t know where to start (registrationg etc.)
- Inappropriate room size
- Breadth
- PPT for CS
|
We are pleased to announce that we will be running a boot camp on July 9 and 10 in Boston—please see its page for details (some of which we’re still working out). We have room for 40 participants, so please register early. (And if you can, register with friends: we are finding that people get a lot more out of this training if they’re learning with their labmates and other collaborators.)
For the boot camp at UCL, we tried using Mercurial (with EasyMercurial) instead of Subversion in the version control segment.
You can see the plan for the segment on this EasyMercurial project page. Briefly, we opened with a few plain slides about the purpose of version control, followed by a hands-on example in three parts (working by yourself, working by yourself with an online remote repository, and working with others). We started at the beginning and got as far as “hg bisect”, but did not cover branching.
I was presenting the segment, so I’m not well placed to judge how effective it was as a learning experience. But I did make some notes.
Read more…
We’ve come to the end of a hot, slightly sweaty, two days of learning in UCL and have just done a straw poll of participants of the good and bad points of this bootcamp. Something that was trialled at UCL was asking participants to sign up in small (3-4 people) teams drawn from their local research group. In total, we had a little over 40 learners and 10 helpers. We also taught the version control portion using EasyMercurial (thanks to Chris Cannam from SoundSoftware).
Here’s what we learned…
Read more…
I’m sitting in a packed room helping out at the UCL bootcamp, the first of a series to be run in the United Kingdom (Newcastle is next, and there are plans to run additional workshops in Oxford, RAL, Glasgow, Edinburgh and Bristol). I’m thinking about two things: why would you design a 60 seater lecture theatre with only one window for ventilation and why is Software Carpentry so popular in the UK?
Read more…
Do you know someone who’d be helped by a Software Carpentry boot camp? Or can you introduce us to someone who’d help us organize one in a new venue? If so, please introduce us: we’d like to start planning for the fall, and we’re always keen to make new friends.
Our boot camp at Utah State University finished earlier today—many thanks once again to Ethan White and his friends for hosting us. Here’s what the students thought:
|
Good
|
Bad
|
- keeping history
- break work into pieces
- integrating different things
- good for different levels of knowledge
- liked the pace
- good tech support from helpers
- download data from the web
- liked the escalation
- using up-to-date languages
- emphasis on commonality of patterns
- liked flexibility
- talked about formatting/style
- everything consistent
- Greg’s stories
- hearing from multiple people
- organized around simple, general structural things
- liked structure around data processing
|
- machine/software setup
- hard to keep up with Greg’s typing
- wind tunnel
- no beer
- assumed knowledge we didn’t have
- less lecture, more time on examples/practicals
- rushed
- wide range of applicability
- wanted more complicated examples
- some things glossed over
- don’t understand strengths/weaknesses of languages
- would have liked time to make better examples
- some places were “show” not “do”
- didn’t cover testing
- Greg’s stories
- couldn’t tell if people were with us or not
- hard to keep track of what tool we were in
- coordination across people
|
Next stop: London!