Web Development Flashcards
Download two and a half years of practical experience
- What is this?
- What Technologies Are Included?
- Who Created These?
- How Do I Use This Deck?
- What Resources Were Used?
- Advice About Making Your Own Decks
What is this?
I created about 5500 questions and answers on a spectrum of topics important in building and maintaining web applications using the popular Rails stack. These cards preserve my day to day learning experiences and I believe that new web developers can shorten their learning curves using these. Included are simple descriptions of language features, explanations of key programming concepts, examples of idiomatic code usage and solutions to commonly occurring problems. Seeing as they are free to download I encourage you to give this technique a try since you could be pleasantly surprised.
What technologies are covered by these flashcards?
- Ruby (1.9)
- Ruby on Rails (3.2)
- Unix - command line API and OS fundamentals
- HTTP protocol
- Design patterns, refactoring, code smells, functional programming, object-orientated-programming, best practices
- Git version control
- HTML5, including the canvas, geolocation and web workers
- Regular expressions
- TDD theory
- Web development issues (deployment, caching, etc.)
Who are you?
Jack Kinsella (@jackkinsella), a Berlin based Oxford law graduate turned programmer. I make my living buying and selling notes that help students pass exams, with a focus on LPC Notes, GDL Notes and BPTC Notes. If you've got notes to sell, high school, college or professional level, we publish notes here. I also co-founded Bolivian Express, Bolivia's major English language publication - if you fancy coming out to Bolivia to write, explore and learn some Spanish we have a journalism internship program.
Why did you start making these cards?
When I was younger I had trouble learning Spanish; in particular I kept forgetting vocabulary - that was until I put new words onto small flashcards I kept in my back-pocket and reviewed these cards whenever I was sitting around waiting. The Spanish words drilled in this way stayed with me to this day.
I faced a similar problem with forgetting when I was learning to program. Recalling my positive experiences using flashcards with Spanish and seeing the parallels between learning natural languages and learning programming languages, I thought I'd apply the same technique to learning Ruby. On Google I found a deck of 400 or so Ruby cards (I believe this deck is no longer available), and spent a few evenings going through these cards. I found, to my surprise, that I could immediately apply some of this knowledge in my programs and after a few weeks I felt more confident with the contours of the Ruby programming language. Realizing the value of using flashcards as an educational tool but not finding any adequate resources, I prepared my own decks.
How should I use this deck?
To begin you'll need to download Anki, a free open source flashcard viewer, to enable you to open the files below.
Next pick a topic you'd like to learn, for example Git, and read over all the cards tagged as such using Anki's cram mode. At the end of this session you'll have a good overview of how Git works and what it can do. Next start a toy project using Git and leverage Anki's search feature to reference the specifics you need to complete this project.
For those of you looking to internalize the knowledge and cement it in long term memory, you can place the cards on a spaced repetition schedule using the Supermemo algorithm, a feature built into Anki. I wrote extensively about my experiences using SRS to learn programming on my personal website.
Must Read Update on How I Use Flashcards
I refined my Janki methodology and wrote about 13 advanced rules that make learning even easier. Open this up in a new tab now and read.
What resources were used in creating these flashcards?
- Ruby API
- Rails API
- The Well Grounded Rubyist
- The Unix Programming Environment
- The Rails Way
- The RSpec Book
- Metaprogramming Ruby
- Exceptional Ruby
- Working with Unix Process
- HTML5: The Missing Manual
- Code Complete
- jQuery in Action
- A variety of Peepcode materials
- Every piece of code I've ever laid eyes on cc/the Gods at Github
As mentioned elsewhere, these decks are somewhat rough and there are a few issues you need to be aware of:
- I went through the cards and checked for technical accuracy, but seeing as I only have a few years of experience programming, there are bound to be some mistakes I did not perceive. If you spot any of these please create a patch with your changes.
- I did not resolve the knowledge dependency graph and so the cards are not ordered. If you'd like to order the cards to make for a more pleasant learning experience, then you'd be my hero.
- There are a few typos, missing words and grammatical mistakes since I didn't have the time to proof read for this in detail. With so much material (I estimate 300-450 pages of text) and no budget for a professional editor, such a proof run was sadly outside my time budget. Particularly embarrassing was my failure to bother with the distinction between it's vs its...
- In some cases I used the word linux interchangeably with unix, OSX or the linux command line, despite this not being technically true.
Originally I intended for this to be a $30-$50 product, but due to other priorities I didn't have the time to polish these to that high a level (see the issues above). Instead, I'm releasing these cards into the wild for free as I'd like to encourage others to share their decks in a similar way, and to share their experiences using learning strategies to shorten that curve.
I would appreciate a donation from anyone who downloads and uses these decks. Why? After preparing these cards for my personal use, I spent about 150 hours in the summer of 2012 editing these cards for public release, foregoing an estimated $10,000 of paid work. I trimmed the deck by removing thousands of redundant cards, I corrected technical errors, I expanded idiosyncratic personal abbreviations and I turned unclear sentence fragments into full(er) sentences.
I suggest a donation of $9, but if you believe in what I'm doing and can afford to pay more then I'll gladly accept. Donations will encourage further work by me in this area.
Download and License Information
Shared under the MIT License
I created a separate version of the decks using Git as source control. You can download the bundle file here and send me patches.
I want to make my own decks. Do you have any guidelines based on your experiences?
- Give specific examples of code to be executed and return values. I found cards with this information particularly practical.
- Question: 'What does String#capitalize do?'
- OK answer: 'It capitalizes the first character of a string'
- Great answer: 'It capitalizes the first character of a string: "dogs are good".capitalize => "Dogs are good". '
- Proof read new cards for technical accuracy and correct natural language usage as soon as you add them to your decks. Trust me, it's easier to do this up-front on a card by card basis than years later, as I did. Besides putting your cards into a permanent release ready state, double checking for accuracy promotes the habit of trying out new concepts for yourself, improving your own understanding.
- Decide on your own formatting guidelines up-front and stick to them. Formatting guidelines enhance a reader's ability to scan the cards and consistent formatting make programmatic interaction with your decks increasingly viable. By way of example I'll suggest a few conventions I (sometimes) used to good effect.
- One statement per line
- Precede lines with return values from the programming environment with => output looks like this
- Precede comment lines with a hash. # this is a comment
- Bold the key part of a code example to draw the user's attention to it.
- Add multiple narrow tags to each card. I tagged all my cards in Ruby only with the tag Ruby. Instead I should have been more specific and tagged, for example, a card about Ruby's Array#push method, with the tags: Ruby, Array, Ruby-Basics and son on. As my decks grew the few tags I had were excellent for filtering and organising information, although I lament not having more of these.
- Add references to books, blog posts and project names when relevant.
- Add cards for the common jargon in use in the community of your target technology. Knowing the key vocabulary improves your ability to search for extra information on Google or phrase a question on Stack Overflow. Furthermore, knowledge of jargon can increase your perception, as you'll recognize these concepts in code you read or later write.
- Use syntax highlighting on code. I haven't looked into how this works but apparently Tiago Barroso created a syntax highlighting plugin for Anki 2.0.
- Don't put anything in your deck that you haven't tried out yourself first. Otherwise you create cards that are more likely to be inaccurate. Furthermore, if you cannot think of a way to apply something then there's a chance it's just useless trivia, and so would be a waste to enter.
- If you feel you might have already made a similar card, use Anki's search to read through your old entries and catch any possibly redundant cards. Even if you find no redundant cards, you might use the search to improve an old card with new information or connect your new piece of knowledge with an old one and so get a technological narrative going.
- Ask a single question and give a single answer in each card. If a question has multiple answers then split it into multiple more specific questions. For example instead of saying "what the advantages of X?", say "what is the performance advantage of X?' and add a second question "what is the abstraction advantage of X?".
- Seek to capture the fundamentals of your target technology. This leads to fewer but more abstract cards. For example it's better to have a couple of cards explaining how branches, tags, commits and SHAs relate in Git and then one card on how each Git command interacts with these SHA objects, compared to having many cards for each Git command explaining, redundantly, how to deal with branches, tags, commits and so on, such cards written without any underlying understanding of the relationships between SHA objects. It may not be possible for you to start with fundamentals, so if you find yourself in such a position make a point to update and delete old cards as your understanding deepens.
- Be aware of knowledge dependencies, that is, the order in which concepts should be learned, and think about ways to use Anki's features like tagging to help organise your knowledge in a more linear fashion. A crude half-solution is to tag your cards with 'basics', 'intermediate' and 'advanced', and also tag with alternative taxonomies like 'core-command,' 'command-options,' 'ClassName' and so on to facilitate later sectioning and organisation.
- Use mnemonics techniques. I didn't do this, but having recently read Moonwalking with Einstein and then moved on to using the excellent memory product, Memrise (if you care remotely about learning I encourage you to sign up now), I am convinced of the advantages of mnemonic technique and I can already see a world of application in easing the teaching of programming.
Please comment on Hacker News; having had bad experiences moderating hateful comments on a previous website I now prefer to outsource moderation to HN, seeing as it self-moderates quite nicely. If you want to reach me privately I'm at the usual firstname.lastname@example.org (Jack Kinsella).