This. Is. AWESOME. Let me tell you what this is useful for by telling you my story:
I'm a pretty fast typist (80-100WPM on TypeRacer, usually) and I really never put much thought into my typing, since it was good enough. But I recently started paying attention to the kinds of mistake I make on Typeracer, and realized that I have certain combinations of keys which I don't make using the "home row" of the keyboard, but rather, move my hands to make. Every time I hit one of these, I have a 50/50 chance of not getting back to the home row correctly, meaning I have a 50/50 chance of throwing off my typing.
And I am a heavy VIM user, by the way, which means I am very used to doing everything from the home row, including every navigation you can think of. I even have AutoHotKey scripts to give me vim-style navigation everywhere in windows, so I never have to move my hands.
Now with this program, I finished running an example and noticed 2 shocking things:
1. There are a lot of keys which I'm not used to typing from the homerow, which happen to show up a lot in regular Python code. For example, periods (.). And underscores. I was used to shifting my hand to type these characters. I don't notice this during every day work, since I'm actually programming, but I did notice this while playing a program specifically designed for typing.
2. At the end of the program, it gives you statistics, and I found out that I was only about 48% effective, meaning 52% of the keystrokes I made were accidents that had to be backspaced out. This is a lot. Part of it is "first time with this program" bias, but it still means I have a long way to go.
Anyway, I recommend running through this program, it will probably teach you a lot.
P.S. Just one bit of constructive criticism: the way the program presents mis-types is a little annoying, and hard to follow. I recommend doing the same as TypeRacer, that is, have the "mistaken" keystrokes be visible somewhere, so the typist is very clear on how many keys he needs to backspace out. This is much closer to how people type in the real world.
Thanks, I'm glad you found the stats useful. In my initial version, I wasn't requiring the user to correct errors. I was personally getting errors rates around 3~5% , which appear good but seemed too low for the amount of errors I feel I make. Adding the need to backspace and correct keys revealed the true cost of mistyping a key, namely the wasted keys typed before correcting and all the backspaces.
Thanks for pointing out typeracer. I will take a look at it and try to incorporate its error handling.
Just in case I wasn't clear, I absolutely agree that you should force users to correct errors. It's just that the interface right now makes it harder to see how to correct the error, since you don't get visual feedback on the "wrong" characters that you've typed.
Hey, I agree this is awesome. I have noticed as I've optimized my workflow that I actually make a huge number of typing errors when I'm programming. Other typing programs don't test the whole set of symbols we use, so they're not as useful (and I type English considerably faster than code.)
One thing I would say is that it would be nice if it showed stats while I was typing, instead of just at the end.
I was taught in typing class that its better to skip errors and then come back and correct them when you are done. Not that I follow that advice especially often, but I wonder if it would be more helpful to do that. I didn't like during the demo that I was forced to correct the problem before continuing.
Take it from someone who averages 140 WPM and peaks at 160-170 WPM. Don't skip errors and return to them later. Do delete whole words (alt-backspace) and re-type them from the beginning. When you get really fast, almost all typing errors are transposition errors. By the time they register you are already several characters, even words, ahead. Trying to correct them character by character will throw you off.
If you use emacs, what do you think about `flyspell-auto-correct-previous-word`? It's like autocorrect, but it only happens when you invoke it and it always happens on the last misspelled word rather than the word under point.
I agree. I believe the most typing classes are focused on the word processing end of things rather than programming. While waiting to correct errors afterwards can be faster for regular documents, I would absolutely never do that when programming.
Actually, I doubt it's even better for regular documents.
In the writing discipline, people will often tell you to write a first draft without correcting errors, then go back and error-correct on the second draft. But that's not about typing errors, but rather grammatic/narrative errors in your writing.
I had the same problem with not getting enough feedback on the errors I made. For example, I mistyped ")" a few times. But to correct it I need to know whether I hit the key to the left or to the right of ")" so I can move my finger accordingly. (I often type US-Dvorak on a spanish layout keyboard, so looking at the physical keys on the keyboard is pointless).
Supporting KILL and especially WERASE would be nice; I usually use one of those rather when I've made a string of errors, rather than watching and counting backspaces. And I agree with previous comments that it's hard to follow just how many backspaces are needed.
FYI I did the Symfony demo, then signed in with Google and got a 404 error. It did save my progress, but I had to re-authorize before I could get back to the list of languages.
Fantastic product, though. I see myself using this a lot. Any chance of a C# version coming along?
Exactly, and I'm a java programmer. For the record Sublime Text also inserts these for me. When I had to type '}' in the training program I actually had to look down at my keyboard!
They're completely valid brackets to use in writing. You don't tend to see them much but using different forms of brackets can add clarity to nested brackets (i.e. when you feel the urge to expand on your text in brackets [which I frequently do {and according to Wikipedia, others do too}])
Thanks so much for this bit of knowledge, I was not aware this was the grammatically accepted means of doing this. I always tried to reformulate sentences to avoid nested "expressions" due to the confusing nesting of parenthesis.
Yeah, that makes sense. I could foresee some cases where I was writing something documentation-y, such that it made sense to do in Word, but aimed at developers, such that I'd want to include code samples or the like.
This is really well done. Surprisingly well done. Way better done than average.
I'll tell you how I'd like to use it. This may seem odd, but I'd like to be able to upload code that I'm interested in learning, and then type over it just like in these lessons - but not to speed up my typing, but rather for learning.
Writing is a unique channel for learning new things. (Reading is too, of course, but everyone knows that.) Even if you're merely reproducing keystroke-for-keystroke what someone else wrote, following in someone's footsteps helps the brain absorb new patterns and is particularly good for something one's a beginner at. If what you're copying is the work of a master, then you're absorbing really good patterns. I would totally use a tool like this for that purpose. It's a way of learning with one's hands.
But pure typing efficiency? That's hardly a way to become a better programmer, only a more prolific one, and more code is not what we need in this business.
So basically I wish I could subvert the purpose of your tool and send it off in a new direction. :)
Thanks. I will give your idea some thought. A related offshoot I've considered is allowing companies to upload private code for employee onboarding. New programmers to the company can type through common code, get a feel for the libraries, coding standards, etc.
Man, that's a brilliant idea. I hope companies will use it!
Hey a few pieces of constructive criticism, I only did the Python lesson so I may have a skewed view though:
- your tool somehow collapses double newlines? in the example, after the import statements came a class definition, which are (as suggested in PEP8) separated by a blank line so I pressed Enter twice. But your program expected me to already type the 'c' of 'class' :(
- it skips comments. and not only comments, but also docstrings! docstrings are not just "comments that happen to be documentation" but actually proper python code and part of the program, they are not ignored like comments, but can be introspected. When I'm programming Python, I'm also typing docstrings.
- the example I got had me starting out by importing a whole load of modules that were particular to that project. for Python practice it would make more sense to practice typing imports of the standard library, or popular frameworks.
- You should try to figure out some way to incorporate the particular keyboard shortcuts, autocompletion and other typical code-editor features, because learning to use those properly gives enormous advances in efficiency. Does your program at least do auto-indenting? For other features it is more difficult since they are so different across editors.
Typing code is very bursty. It might not account for a large fraction of your programming time. But when you have to code up a function, waiting for hunt-and-peck to finish the job is infuriating for the same reason that waiting on your snail of a compiler is infuriating. No doubt there are zen masters who meditate mindfully on the meaning of each and every key stroke. I'm not that patient.
Things I particularly liked: not making me type the indentation (because any sane editor will do that for me), allowing backspace, providing examples in numerous languages.
Things that bugged me (and which only become an issue because the example otherwise proves sufficiently realistic that any remaining differences feel awkward, like an uncanny valley for typing code): showing faded-out code I'm not expected to type and skipping it, not allowing any navigation other than backspace (I frequently "correct" errors by ignoring them until I finish typing what I wanted to type and then going back and correcting them, which means the "collaterally typed before backspacing" characters are not wasted keystrokes), not allowing copy-paste (particularly important for lines like #include or import), not showing incorrect characters I've typed.
Things you probably can't do anything about: typing a file in a more natural order than top-to-bottom (the Haskell exercise starts with a giant export list, and the Python exercise starts with an import list). Normally, you'll extend those as you go, rather than typing them all at once.
Thanks for the feedback and criticism. I decided to keep error correct close to the error instead of allowing navigation to simplify navigation logic. Mimicking normal editing may have still felt stilted if I didn't support the mousing around or keyboard shortcuts programmers are used to with their editors.
I debated whether to require typing the import/include boilerplate at the start of code. As you noted, this usually done piecemeal and often inserted by an ide. I decided to include it as it's part of the code and looked for code samples that didn't go overboard. For the Java and Scala examples, I collapsed imports into wildcards imports.
I'm one of those folks who is on the top-end of crazy-stupid-fast typing, but hadn't ever seen a typing test that actually had typing code, so this is absolutely awesome for seeing the difference in speed between prose and code. However, the fading in and out cursor makes it extremely difficult to track where I am, particularly when going back to correct a mistake I made (I know I hit the wrong key, and depending on where in the typing I hit it, I'll need to see how far back to go). It's also exceedingly annoying when it blurs across multiple characters.
I personally would prefer a side-by-side text entry, rather than typing on top of existing code, so it's easy to see progress and mistakes (even if you don't highlight mistakes in the text).
EDIT: It looks like about 50 words per minute, maybe 55, is the max speed you can type and have the cursor actually be visible enough to be a guide of where you are in the text.
Only if I'm on my preferred keyboard, I top out at 120 to 130 on laptop/netbook keyboards.. For a stint in high school, I typed medical reports from dictation for a friend's mom, eventually having the cassette player on the fastest speed and keeping up without issue. I have no idea how people can be very productive as hunt and peck typists when writing code.
Would you also happen to be a fast reader? I can't seem to break the 120 barrier, and I'm wondering if the habit of mentally "saying" the words as I read them is a significant reason why I can't improve.
As dbarlett pointed out, the sub-vocalization is a big part of it, but once that's gone, there's still a long way to go to read quickly and effectively. I learned to read exceptionally fast, but had a very low retention rate of what I read (I use those techniques when typing), it's symbol recognition/word recognition, not real comprehension. I eventually slowed down my reading, but followging a rhythm (per-word rate) and process/think about/determine application for what I've read up to that point. In the end, reading quickly hadn't been as beneficial as being able to have a strong working knowledge of what I've read after only the first read through. However, I dislike reading fiction and don't prefer reading stories, an in depth whitepaper or textbook is my enjoyment reading, so learning as I read was more of a priority than just getting the high level view or enjoying the story construction.
I don't understand programmer's obsession with typing efficiency. We're not typists. Typing is a tiny fraction of the time I spend programming. Most of the time I'm thinking, or talking to another developer about a problem. I could have the fastest typing skills and most efficient editor and not even be marginally more productive.
Obsessing over typing efficiency doesn't make much sense, but being able to reasonably quickly with a high level of accuracy type makes a huge difference. By being able to touch-type at ~30 words a minute (making a rough guess here, I have no data to back up where the speed actually lies) means that you can quickly and easily get the bit of typing necessary over with and get back to thinking, planning and studying for the next bit of typing that's necessary. As an anecdote, I type extremely fast, but type for probably 45 minutes of the day in 30 second to 1 minute bursts every so often. In that burst, I likely create or edit a couple of functions and put in the calls to it. And then go to working on the next piece. There's rare times where it'll be a concentrated stream of typing, but that's following a large period of scrawling in a notebook.
I cannot fathom how people can find the time to actually approach any particular problem at a reasonable depth if it will take them more time to type out the solution than reading and understanding the existing code and determining how to solve the problem. Sure there's code where there's boilerplate, or add a line to a bunch of files, or tons of ways that raw typing speed doesn't play much of a benefit, but when it comes time to type, having to move your hands and look to find the { is akin to a carpenter having to read every label to find the bottle of glue.
re. your rough guess: 30 wpm is actually kind of slow, according to Wikipedia the "average computer user" types at 33 wpm. I'd expect someone who spends most of his time at the computer to do quite a bit better even if they never learned to touch-type. I thought I'd time myself copying the first two paragraphs of http://en.wikipedia.org/wiki/Words_per_minute#Alphanumeric_e... (1024 characters at the standard 5 per word = 204.8 words) and got 70 wpm! I'm a bit surprised by that myself, TBH, since I don't "properly" touch-type either--I'd probably get a significant drop if I had to type more than that though, but as you say programming goes in bursts so that's not much of an issue here.
As far as you wondering what use typing speed is to a programmer:
1) if you can type faster, it takes less effort to fix cosmetic mistakes and you do so more often. you must have noticed as well when looking over the shoulder of a slow typer they seem to make more errors? or maybe it just seems more tedious because you're waiting on it. you must have also seen that a really skilled typist can make an error and have it corrected before you hardly notice it (which is because they feel their fingers slipped).
2) in a similar sense, if you type faster, it takes less effort to quickly try something out. just type it out, maybe not even immediately test it, because as you see it on the screen you can more easily reason about it and make corrections before you do. if you type slower, you're more likely to get stuck halfway writing a block of code because you're thinking "wait this isn't right" and start doing proto premature optimization (well, that's my problem, I start thinking about what is the best/most concise/pythonic/readable way to write this code halfway, before I even got the rough structure down. I find it's almost always better to first write down something that works).
3) if you type faster you spend less time writing comments on HN and can get back to programming sooner.
People who say typing is not their bottleneck are saying they are not I/O bound but CPU bound. Makes me think what other things you need to improve before you notice your typing can't keep up? But that's kind of backwards. You will never know until you can type fast and freely, liberating your brain to actually think about the problem and code and not finding keys on the keyboard. Besides not everything you do is original and new or inventive. Sometimes you are just doing crap that you know how to do already, and typing or not using smart editor is the bottleneck. But people who can't type usually don't know this. What you don't know can't hurt you, or it can perhaps?
I thought this was a given? I am absolutely CPU bound and I don't know a single developer who isn't. Do any of you actually code (efficiently) at your maximum typing speed?
At the risk of painting with a wide brush, I am currently under the impression that any developer who sits down and cranks out code non-stop at their maximum typing rate is either :
a) cranking out a complete mess that will require extensive refactoring down the road
b) the protagonist of "Hackers" or "Swordfish"
For what it's worth, I am a reasonably fast typist (~115 wpm, qwerty) and can't even imagine myself ever coding as fast as I can type. I wouldn't mind for this to be the case, though :)
Well then. Time for me to get busy on one of those touch-type-training applications, that's nearly 2x what I just did.
Indeed at that speed you're sufficiently CPU bound to make that claim.
But can you crack a 2048 bit RSA code in your head within a minute while .. you know? Plus, in the later scene when he was doing the real job, he wasn't just typing at 115wpm, he was simultaneously dancing around at at least 145bpm. So there's always room for improvement.
Us 115wpm qwerty guys aren't "reasonably fast" - we're way up there - and to be sure, the only reason I have to improve my speed is because it's a sort of hobby.... it won't help me code better.
Being able to type with my left hand faster than my friends can type with both is always fun - as is constructing passwords and other shortcuts that can be done with a single hand in the blink of an eye... but that's all just fun and games.
You don't always bang out code at your max typing speed. But you do have bursts of fast code writing at times, which is extremely useful.
Also, I live in the shell and typing 200 char long one liners to do something useful and if you are a fast typist very quick too. It's great for generating on the fly reports, searches etc. This is the kind of thing that would take a slow typist a lot of time. Most of slow typists I know don't bother with these things because it takes too long. As a consequence they also get rusty with their shell foo, or never get good at it to begin with.
It may be true that we spend most of our time thinking or communicating, but doing anything creative is all about the flow. Slow typing interrupts thinking and it takes time for our brain to re-construct the "blueprint" after this interruption. For a programmer, typing is a more frequent activity than say, drinking coffee. I don't think anyone can work productively if we need to sip some coffee every 10 seconds.
I need to improve my typing speed and reduce the interruption as much as possible.
I used to think so too.But learning touch typing has made me to better document my code. I no longer fret about writing API documentation, I almost add API documentation most of the methods I write.
The blog post[1] Steve Yegge was the one that triggered me to consider touch typing seriously.
I completely agree. I have noticed, programmers who can't touch type write very few comments and very little documentation. Communicating with them via email sucks because they can never explain themselves properly. Just like typing is only a part of what you do when programming, programming is also only a part of what a good programmer does. Programming any sizable application is a very collaborative process, and that necessitates lots of documentation and communication, which are both very typing intensive. I hate working with developers that can't touch type, they just don't function well from a team perspective.
I'm pretty fast typist - about 50 WPM in those crazy JavaScript regexp exercises. I used to think my typing speed is just a perk, but everything changed, when I became proficient in TDD and refactoring.
Previously I've thought a lot about architecture, code, algorithms, etc. And then typed that in ~1 hour per day. However when I started doing real TDD with running tests every few dozen seconds, everything changed. Now I actualy code almost all the day - play with ideas, throw them away, implement in a multiple ways, refactor a lot. And that is a blessing when you may implement your ideas as fast as you may, so that instead of analyzing the solution, you verify it.
Other reason is I've changed my approach to application architecture. Previously I've used the standard PHP/Ruby/JS frameworks and fit my code into predefined places, generated scaffolds, etc. However then I started applying DDD, PoEAA and similar ideas. All the advanced design principles require a lot of boilerplate code - a lot of mappers, DTO transformers, domain classes, view models, etc. So I actually need to type ~3 times more code than before.
And then I've started using VIM. You better not make typos when using VIM - crazy staff happens and it breaks the flow.
You think typing skills are as essential to being a productive, and by productive I mean creating wealth and value, not lines of code, a productive developer as dribbling is to being a good basketball player?
A programmer, by practicing his trade diligently, will in high likelihood grow in his typing proficiency and become faster, especially if he is spending much of his time developing. Also, writing specs and comments take a lot of text as well.
It doesn't appear to respect my keyboard layout - I'm using colemak (which works fine) but with UK symbols instead of US (which works everywhere else, including the HN comment box, but not in Typing.io where it wants me to type US symblos: eg " and @ are swapped).
I can't type underscore on my "British" layout MBP keyboard.
I wrote a typing tutor a while ago and this is a somewhat common pitfall, to manually handle characters by pulling key codes. Instead you should let the O/S tell you which character was typed (and also check key codes, for things like backspace) which then handles different layouts / locales etc.
Edit: Ok, it works in Chrome - so it's not working for me in Firefox 14.0.1 on OS X Lion.
Now that I can use it, I love it, but I have one request - I'd like to be able to go back and see my stats, please!
yea, german keyboard here and it doesn't recognize my "=" ( so couldn't get past line one. Looks really cool though, I hope it gets I18lized sometime soon :)
Unfortunatelly suffering from the same problems, as soon as I type : or ( or = or anything other than normal characters, I get errors. :( Cool typing experience other than that!
Same problem with fr_FR on an azerty keyboard (Ubuntu or Windows 7). For example I can only type </> by typing <:> instead of the correct <shift> + <:>. For a <$> I would type <shift> + <'>.
This seems partially fixed. Though I cannot find a way to type <^>. On my azerty keyboard, I should type <^>+<^>, or on a querty one, simply <shift>+<6>, but neither works.
Same here. I'm using swedish layout, and it could not recognize semicolon
It wasn't even enough to press the corresponding button where semicolon is placed on English layout, I had to actually switch keyboard-layout and then press the correct button to get past it.
Can't type underscore at all, have to use the numpad to type dashes. If I have the layout set to US-International, I have to type alt-shift-doublequote to get "; it won't let me type shift-doublequote and then the next character (or space) like normal. CapsLock doesn't seem to work, so for some of the identifiers in the C++ example I need to hold down shift for a half-dozen letters in a row.
strange. i have no problems whatsoever regarding keyboard layout. and i am using an obscure one. is this os-dependent in a way? (i'm just curious and want to understand the problem)
Chrome on Windows 7 64bit does what I explained above. Chromium on Arch 64bit works fine.
In windows, I made my own keyboard layout in Microsoft Keyboard Layout Creator (so that I could switch the symbols to UK but also so I could add some dead keys to AltGr for various unicode symbols). I did "fix" the VK codes for the alphabethic characters, but I guess the symbols are still using whatever the key is assigned by default and I guess JS (at least in Chrome on Windows 7) checks the key code reported by the OS, rather than the value reported by the OS.
On Arch I use the GB colemak layout that came with the distro and I guess it sets all the key codes correctly to where all the symbols are...
Well done on the NoScript front. It's rare to see a site on HN that requires JS and falls back to a nice explanation of why it needs JS (Instead of just stating the fact, or worse, displaying a white page).
I didn't notice because I had scripting on at the time, but it deserves another compliment, seeing as so few websites seem to bother these days.
(even for those who think noscript browsing is not with the times any more, it's still good practice to give a decent error message / explanation instead of breaking or blanking)
Regarding indentation: I think you made a reasonable choice in excluding it across the board. Definitely better than requiring it to be typed everywhere. That said, ideally you would require the user to make the keystrokes to un-indent whenever an IDE wouldn't automatically.
Also: Something in Objective-C please. Those square brackets took me a lot of practice to get used to.
Thanks for the bug report. The next update will fix international keyboard layouts once I figure out the mess that is cross-browser, cross-language javascript key event handling:)
Thanks for the js library recommendations. I've taken a look at keymaster, and it's mostly focused around modifier keys used in shortcuts. I'm currently using google closure library, but I will need to add more key recognition and failsafes in case there is a unrecognized keyboard layout.
Wouldn't it be better to have an input field and simply read what has been typed in it? It's not as if you need to have something else focused while doing it. That would eliminate all international keyboard problems in one go, even without a dedicated library.
Not quite as important, but it seems that Caps Lock isn't being registered either (did the Rails demo and some of the constants would be rather tedious with only the shift key).
I'm using a standard Brazilian keyboard. The colon was mapped to the US layout location, but I could not type {, even though I knew the location on a US layout. Maybe because that key is a dead key here.
I would be very glad if there were an "ignore layout" option that dropped support for any layout difference, so I could type as in a US layout and at least finish the exercises.
We attempted to make something very similar at a hackathon. It's cool to see a more polished, complete version. Ours was more of an attempt to make a version of typeracer (http://play.typeracer.com/) using code samples from rosetta code. All we really got done though was handling typing the code (hilighting errors, letting you use tab for whitespace, etc), we didn't get around to recording stats.
This is all bringing back horrible memories of our disastrous demo actually, but very nice otherwise.
Great idea. But as a fast typist of both prose and code I found the interface nearly unusable. Please make it behave more like a normal edit box. I never had any idea of the location of my cursor. The lack of alt-backspace made it unbearably slow to correct errors. Auto-skipping whitespace makes it tougher to rely on my habits where the key strokes for indentation and line breaks are a natural part of the flow. And if you're not going to make me type the comments, just delete them from the text entirely so I can more easily scan ahead.
Here's a straight-up bug: I had to turn off a Chrome extension (Type Ahead Find) that I use for incremental search. It was intercepting key strokes that were supposed to go to typing.io. That hasn't happened with Ace and other canvas-based text editors. My friend also mentioned that it didn't work with his Danish keyboard.
Beyond these annoyances with the implementation, typing the C code from Redis reinforced how difficult (and frankly infuriating) it is to spontaneously conform to an unfamiliar coding convention. E.g. no spaces in "while(1)" throws me off completely because my brain is thinking "while 1" and my fingers translate that into my customary "while (1)". If you want this web app to be relevant to real-world programming, you need to let people upload their own code samples.
For even punctuation heavy, syntactically gnarly prose, I can average 140+ WPM without much effort. Typing.io put me at around 100 WPM for the first few sections of the C Redis lesson. I'd say I'm good for at least another 15-20 WPM if the environment wasn't so utterly alien.
The message google gives when trying to log in is really poor: "A third party service is requesting permission to access your Google Account.Please select an account that you would like to use."
What do you mean "access"? Do you mean "authenticate as"? Do you mean "go screw with my email"? I seem to remember that I sometimes see specific access requested, but this one is vague. Possibly this is the result of requesting sign in with no permissions at all.
This reminds me of Learn Code The Hard Way... The guy that runs it states the only way to learn is by typing the code in, bit by bit and not to go too long because you might burn yourself out...This is a nice free tool, Cheers moonboots!
Man I think I might be kind of a slow typer. I was only getting like 45 wpm in the javascript test. I think it's because of all the abnormal characters, although I do code in js daily. -_-
But keeping my fingers on the home keys to type has always felt really awkward to me. I tend to position my hands differently depending on the word I'm about to type - in a way that let's me "roll" my fingers along in just the right sequence so it tends to be a series of short bursts where it would seem as if I'm actually just smashing a bunch of keys at once over and over again.
Edit: I just tried type racer and was getting 80+ wpm. /me wonders how people get 140+. :O
Autocompletion is an important tool along side typing proficiency. Most of the autocomplete I've used only covers alphanumericVariableNames, so you still have to type the hard-to-reach symbol keys.
I made something similar except you can practice using any Gist you want. http://newtonapple.github.com/Gistype/#1 It still needs some work on the current cursor movement for longer Gists, but the basic functionality is there. No login required, just type. :) Note that if you have Vimium installed, you'll have to put the URL on your "excluded URLs" list.
I was considering doing something like this in the terminal, possibly using an adaptation of gtypist. However, I the more I thought about it, I realized that I would be better off writing a module for my everyday text editor, since I would have access to completion, copy/paste, indention, macros, etc.
I don't want to 'talk down' all the work you did with this. I'm really glad you made it and I am going to use it, for sure.
This is a very neat idea; but, I do have one issue with it. When I'm programming, I don't start with the import statements (except for maybe some common ones that I have to deal with). I usually start with the most important part of the API and then spiral outward. I noticed this issue in the Java sample I tried. It began with the drudgery of import blah.blah.SomethingSpecific 10 times. I wasn't able to get into the meat of the code, and by the time I did, I was bored to tears. Imports usually come organically, if I'm having to deal with them at all (IDE's usually take care of them).
I think a great place for this to go would be if the code bounced around a bit more. Perhaps, start with what seems like the most commonly used function and write that function header and whole function; then, start writing all of the different subordinate methods you called in this primary method, and so on until the whole class is created. The way it's written write now, in particular for Java, isn't a way that I code and I imagine it's not the way that many people code.
Just my two cents. Otherwise, it's an interesting system so far.
It would be an added bonus if there were an illustration of a hand highlighting which fingers should be used with which keys at the bottom. Similar to http://www.typingweb.com/. I get allot of practice typing my own source, but what I am currently working on is making sure I am using the right fingers for numbers, symbols, and punctuation.
Really fascinating to see my Javascript vs Python speed (the two I type the most in), JS around 45 and Python around 65. Super interested to see what the blog post shows!
And besides improving your code-typing speed, it's also a nice way to get a hang of all different languages you might want to delve into. Alternatively, you can also polish your muscle memory on all the thousands of function, classes and method names you can find in your typical language/framework of choice.
I couldn't type various characters, such as <>={ and probably others that I didn't get to try out. I have an Icelandic keyboard layout, if that matters. I should probably switch to the American layout anyway.
Ubuntu 12.04, Chrome version 21.0.1180.79.
This is still excellent. If these keys worked I would definitely use it.
Why can't I share my test results on social networks? This is like one of the only types of social activites / games I would want to share with my friends!
Other than that, this is freaking rad!
I found it funny that I'm normally a 120-150 WPM typist, but when typing special characters for regex, etc, I hit a patch of molasses.
With all of the emphasis on learning how to code I think this is really useful. The insight I really like is that simply learning to type in this weird way is a big part of being an efficient programmer.
Maybe when codeacademy students get frustrated they could spend a few minutes doing this.
I'll chime in as one of those, who made something similar. It's not very official, but should work in Firefox and Chrome for all keyboard layouts, though you have to bring your own text.
This serves as a great reminder that a good portion of your speed comes from accuracy. I find if I slow myself down ~10% of what feels "fast", I'm much more accurate and my WPM increase significantly over typing faster but backspacing more.
Kinda OT, but I noticed you're using Google Fonts, and they load instantaneously. When I use Google Fonts, they take a little bit, usually loading after the whole site is already displayed. Did you optimized anything regarding this?
Hmm, I'm not doing anything special. I just put the web font link at the top of head. I'm also only including the default font weight. How many assets does your page have? Typing.io is relatively slim, so the font download can occur relatively sooner. If I'm not mistaken, the initial css downloads blocks the page load, but the actual ttf/woff/etc download occurs async and may be delayed if there is other stuff.
I'm just in development right now, and the assets haven't been packed yet (but I'm loading the font right on top). Thanks for answering, and congrats on your very well designed website!
Really nice.
It felt like shadow-boxing the creation of a language. What I mean is that the ability to type what giants typed before me in such an easy and accessible way made it worthwhile. I'll do it again.
You would prefer Facebook or Twitter? Or that they implement yet another authentication scheme and store their own accounts and credential database?
There's no free lunch. The OAuth providers are, on balance, pretty good at what they do and a better choice for account management at small sites. This one happened to pick Google.
> Or that they implement yet another authentication scheme and store their own accounts and credential database?
Yes, either this or openid. I don't have an account at google. I don't want an account at google. While it's a lower barrier than a facebook login, it's still enough that I'll bounce off the site when I see it.
I think github is a nice choice for a site like this, you could even do a rudimentary look through their public repositories to see what languages they generally use and give targeted examples.
I don't know about you, but I have a windows desktop, a windows laptop, and a macbook pro that I regularly work from in different contexts. I much prefer cloud services that store my account information, and let me log in from whatever computer I want ... local storage would remove that benefit for users like me who don't really care that they're using my google login ;)
For the most part I like it, but there's a performance issue that actually affects usability. The first time you start a lesson, the editor is really snappy, but with each successive lesson, the scroll speed gets slightly slower, and a few lessons in, the entered text is just a blur, and you can't even see a cursor. This means that when you make a mistake, it's hard to tell how far you've backspaced, and I ended up bogged down in error correction loops.
I don't have anything more specific to add than that it seems to get worse over time.
Nice app, I would like to point out one thing, hope you find it useful enough to address.
I am pretty sure many people do this too: whenever I type braces/brackets/parentheses/[/%$..] I type both open and close, then continue filling in the statement inside the completed pair of open/close. It is a very useful practice especially for languages with a love of open/close symbol pairs. When you try this in your app, the close gets marked as an error, and I couldn't find an easy way out.
Things that bother me in the extreme: Not showing letters as they are typed in the advanced lessons. That immediate feedback is how I know that I'm typing a word correctly and how I know if I make an error that I have corrected it.
Penalization for adding additional whitespace between identifiers in some situations: "[one,two,three]", for example, I personally like adding a space after the comma and do it automatically.
Are the typing mechanics different in latter/advanced lessons? If so, it's something I need look into. Or is this a different problem?
I preserved the whitespace the project authors used. I'm a little picky too regarding these details, but I want users to see code in its original form.
One tiny piece of criticism though: when calculating the percentage of unproductive keystrokes, divide by the number of ALL keystrokes, not just the correct ones.
This is fantastically great! I'm a huge fan of typing games (typing of the dead, typeracer, etc.) and always lamented the fact that there were none that focused on programming syntax. Love it!
edit: the more I use this, the more I find myself really hoping that you're storing all of these stats somewhere. I think that some aggregate analytics of typing accuracy across programming languages would be fascinating.
It's collapsing newlines. In the Rails demo I hit enter twice to skip a line, but it only took one to get me down two lines, and the second was an 'error'.
Edit: It appears that this is part of the "auto-indent" mechanism (which is intuitive for indentation). How about accepting multiple newlines, or whitespace at the beginning of a line, but not requiring it?
Absolutely love the design and the idea! Just one small issue: I'm using a MBP but, for reasons that that I won't take the time to explain, I spend 90% of my time in bootcamp (windows 7). I can't seem to get past any single quote(') characters.
Maybe it's not a bug, but could you make the Details buttons collapse when you click away from them, or at the very least when you click on other details buttons? Detracts from checking out all your sourced projects :)
I don't understand why I need to sign in to try this out. Glad you're getting rave reviews in this thread but I'm passing on the basis that I believ this sign in is unnecessary and creates yet more data exhaust.
Anyway, the cursor occasionally obscures the character and slows you down. Might be worth testing out a fish-eye effect as the cursor scrolls so you clearly know what you need to type.
No, I meant the cursor that's highlighting the current character. This could be my own vision problems, but the size of the text + color of the cursor + motion makes it slightly difficult to tell what character I'm supposed to type on the fly. I found myself stopping and squinting just to be sure. That's mainly why I recommended a fisheye - enlarging the current character would solve the problem, but perhaps it's not worth it for most users.
Good question! I wanted to focus on helping users practice typing code with its often cumbersome symbols. The majority of comments are prose, comfortably near the home row, which I didn't feel deserved as much attention. Plus some comments (like the ones in the Guava projects) are longer than the code.
I'm glad to see someone else mention the Caps Lock issue, I was starting to fear that I was the only one who used it or that it was just an issue on my end. I would like to see the Caps Locks functionality added to the Rails practice set too if possible. Otherwise I think this is a fantastic resource you've created, moonboots!
i don't really care how fast i type as programmer as i found typing doesn't account much of time in total time of shipping a product. and second, why the hell we got code completion for!?
You even can't put more line breaks than it is - just type, character by character. If it checked the code in general (e.g. package names typed correctly - but not line breaks and stuff) - I'd totally use it. Not now, though.
I'm a pretty fast typist (80-100WPM on TypeRacer, usually) and I really never put much thought into my typing, since it was good enough. But I recently started paying attention to the kinds of mistake I make on Typeracer, and realized that I have certain combinations of keys which I don't make using the "home row" of the keyboard, but rather, move my hands to make. Every time I hit one of these, I have a 50/50 chance of not getting back to the home row correctly, meaning I have a 50/50 chance of throwing off my typing.
And I am a heavy VIM user, by the way, which means I am very used to doing everything from the home row, including every navigation you can think of. I even have AutoHotKey scripts to give me vim-style navigation everywhere in windows, so I never have to move my hands.
Now with this program, I finished running an example and noticed 2 shocking things:
1. There are a lot of keys which I'm not used to typing from the homerow, which happen to show up a lot in regular Python code. For example, periods (.). And underscores. I was used to shifting my hand to type these characters. I don't notice this during every day work, since I'm actually programming, but I did notice this while playing a program specifically designed for typing.
2. At the end of the program, it gives you statistics, and I found out that I was only about 48% effective, meaning 52% of the keystrokes I made were accidents that had to be backspaced out. This is a lot. Part of it is "first time with this program" bias, but it still means I have a long way to go.
Anyway, I recommend running through this program, it will probably teach you a lot.
P.S. Just one bit of constructive criticism: the way the program presents mis-types is a little annoying, and hard to follow. I recommend doing the same as TypeRacer, that is, have the "mistaken" keystrokes be visible somewhere, so the typist is very clear on how many keys he needs to backspace out. This is much closer to how people type in the real world.