Here is the first tutorial in this section. It shows two techniques for computing a fibonacci sequence given two starting numbers and how long you want the sequence to be.
So this begs the question, how to get started? Well, as mentioned there are several books published about the subject, and I will be reviewing some of those in the future. But I think a great first step is to really understand some of the methods of the Array object. These methods were designed around functional programming concepts. For example, map, forEach, every and reduce are a few that are valuable to understand. And it just so happens we have a tutorial on some of those methods.
I just completed two tutorials on exception handling. The first shows how to use try catch statements in your code. The second talks about when you should and should not use try catch.
Take a look at both videos and if you have any additional rules to add for using try catch statements post them here.
I love the word obfuscation. It seems to reflect its own definition. To obfuscate something is to make it difficult to understand.
Now I find that a lot of my debugging is done with the console. At times I will open up the debugger, but for most things, I can figure it out pretty quickly using the console.
Over the years I have learned a few console commands that are very helpful. I know I would have loved to have these commands when I started out, so I put together a tutorial on some of the lesser known console commands. I think these can help you find a resolution faster.
Many years ago when I started my university studies (more than I would like to think), I elected as my major computer science. I stuck with that major for about 2 semesters and then switched to English. Many people thought it was a drastic switch; from one side of the spectrum to the other. Two majors that are not even closely related.
However, I considered both majors similar. I discovered that the reason I enjoyed English during my undergraduate studies is because I enjoy expressing myself with language. (Now, I may not be that great at it, but I still enjoy it.) I also enjoy seeing (reading) how others express themselves with language.
Well, in that sense I see many similarities between programming and writing. In programming you need to use the syntax and semantics of the language to express what you are trying to accomplish. You not only have to communicate to the computer, but you also need to communicate to other programmers that will need to read and understand your code.
The tutorials are currently organized into 5 categories. As we see the need, we will break them out into more categories. Take a look at the list and find those you would really like to view.
Browsers have a DOMParser object that will allow you to make that conversion. Once you have the XML data as an XML DOM, you can then use the same commands you use to manipulate an HTML DOM to work with the XML data.
When you first start learning to program, your initial focus is on the language. You learn the syntax and the structure. Once you become comfortable and able to put statements together to solve programming problems, you are then free to think more about programming.
As experienced programmers have thought about the best ways to approach the building of an application or the best way to solve a particular problem, they have developed paradigms and design patterns. The smart developers draw on this expertise to improve their own programming skills by adopting paradigms and design patterns.
A paradigm is simply a style or an approach to programming. For example, Object Oriented programming is a paradigm. If you follow this paradigm you use objects to approach the overall program. The objects contain data and behaviors and you connect them in logical ways to successfully solve the task at hand.
Now a design pattern is a tried and tested solution to a common programming pattern. It could be considered a best practice. If you approach a program using an Object Oriented paradigm, there are a number of design patterns you can then draw on to solve specific problems.
I really like this quote by Angus Croll: