First off, I try and rank the pieces of the project by complexity.. there's almost always a simple CRUD interface that it needs somewhere that I can start with.
I always start out getting a book, which I then don't read the majority of (although that is a luxury of moving from web language to web language instead of something more drastically different). I'll read how to get the project setup, and skim basic framework object structure (this is where having a book you can easily skim back-and-forth in is handy). Then I'll just start. Most simple stuff (syntax to traverse a collection), I'll just Google quickly. Inevitably I hit a framework aspect that's unique or in-depth enough to merit study, and then I'll read that section of the book completely.
If you're using a third-party library with source, stepping through some of the logic is generally something you end up doing anyway, but it's pretty useful to do right away to get an idea of some of the optimal structural tricks the more familiar devs use. Maybe follow a couple of API calls for a step or two to see how they arrange things.
Once you've done enough to feel comfortable (maybe the first couple chunks of complete functionality in the bag), it's good to Google around for things like "Common Mistakes/Pitfalls in X". You'll probably have run afoul of a couple of those, and will now be familiar enough to understand and remember them. You can go back and clean up the little bit of code you did then.
I always start out getting a book, which I then don't read the majority of (although that is a luxury of moving from web language to web language instead of something more drastically different). I'll read how to get the project setup, and skim basic framework object structure (this is where having a book you can easily skim back-and-forth in is handy). Then I'll just start. Most simple stuff (syntax to traverse a collection), I'll just Google quickly. Inevitably I hit a framework aspect that's unique or in-depth enough to merit study, and then I'll read that section of the book completely.
If you're using a third-party library with source, stepping through some of the logic is generally something you end up doing anyway, but it's pretty useful to do right away to get an idea of some of the optimal structural tricks the more familiar devs use. Maybe follow a couple of API calls for a step or two to see how they arrange things.
Once you've done enough to feel comfortable (maybe the first couple chunks of complete functionality in the bag), it's good to Google around for things like "Common Mistakes/Pitfalls in X". You'll probably have run afoul of a couple of those, and will now be familiar enough to understand and remember them. You can go back and clean up the little bit of code you did then.