Showing posts with label learning. Show all posts
Showing posts with label learning. Show all posts

Friday, January 17, 2014

Taking A Different Approach To JavaScript

I enjoyed my Codecademy experience in learning JavaScript, but especially toward the end, I felt like I was having to look up things constantly. I posted a query on their forums and got a very nice response back from one of the mods explaining that this was perfectly normal. He suggested retaking the course to help cement the new concepts and haunting the Q & A forums for more info. In the meantime, I found something else.

Interestingly enough, I found out in one of the Codecademy Q & A's about a site called JavaScript.is (Sexy). It sounds like a silly name, but I think it's actually going to be the solution to my situation. They have an eight week tutorial that I just began titled How to Learn JavaScript Properly.

There's a textbook involved, and they recommend a related reddit study group, signing up for Stack Overflow and, interestingly enough, using Codecademy for practice.

You can click the link I provided to see all of the requirements for the class, but I like the organization and structure involved. It also provides me with the format for repeating the Codecademy JavaScript course as well as adding more content via the other class elements.

Since this is a work requirement, I need to stick with it and I guess that's the secret, especially for people like me who aren't "natural" programmers. I write in English everyday for a variety of purposes, professional, semi-professional, and personal, so I have plenty of practice in that arena. If I did the same with JavaScript, even though I find it less intuitive than my native written and spoken language, I can only imagine that coding in JavaScript will get a little bit easier.

I haven't forgotten HTML5 and CSS3, but I'm not sure combining that with JavaScript in the same learning effort is going to be effective. I may need a different plan for that learning path. Right now, in addition to my professional and personal life, I'm focusing on this plan.

Wish me luck.

I'll be back at some point to let you know how things are panning out.

Sunday, December 15, 2013

Ten Days Down the Road

This always happens when I start studying. I get sidetracked. My actual work started to heat up, preventing me from proceeding with the CSS book. I did receive Training Guide: Programming in HTML5 with JavaScript and CSS nearly a week ago and started noodling around in that, but didn't get too far.

I was advised this would be a good book to learn from even without working in Windows 8 and with Visual Studio (I'm not interested in the certification, just learning the information), but that means I get to skip a few chapters. The book is organized in "waves," so to speak, so you first get introduced to HTML, then JavaScript, then CSS. Later, you get more advanced information on HTML, then JavaScript, then CSS again, and so on. I'm only on page 32, so you can imagine things are still pretty elementary.

On the other hand, I did start the Codecademy JavaScript tutorial, but as usual, I got bogged down toward the end of "Introduction to Functions in JS." I've appealed for help to the forums so I guess I'll see what the error of my ways is by the by. 

I thought I was doing reasonably well there for awhile, but then the problems seemed to assume more knowledge than I had. I thought I had missed some key portion of a previous lesson and went back, working my way forward again, but it didn't help. One exercise gives me both an error and also passes me on to the next exercise, so that's confusing. On top of that, I thought my code was written exactly to specs.

The other exercise is beyond me. I don't find enough information in the instructions or the previous exercises to allow me to write code that doesn't complain at me. I know for actual programmers, these lessons would be painfully elementary, but to me, they're locked black boxes with no way in.

My real problem is that I don't naturally think like a programmer. I've read arguments back and forth on the web about whether anyone can learn to code. Sort of like the message in the Pixar film Ratatouille (2007), "Anyone can cook." 

I believe anyone can cook but not that anyone can cook well. The question remains, can anyone learn to code, even at an elementary level, or is programming a skill set for a specific population that no one outside that group can acquire? I feel like Codecademy's "teaching style" is good in that they don't just lead you around by the nose, giving you all the code upfront and then simply having you copy and paste, and then run short, small programs. On the other hand, when you get stuck, you're stuck. The hints on the last two exercises weren't helpful in the slightest.

Forums can be incredibly slow to respond, depending on how attentive the mods are, so I don't know how long I'll need to wait for a clue let alone an answer. A large part of programming is debugging, but that requires a sufficient understanding of how the code works to find the problem. I'm not there yet. The point of setting these work goals is to see if I can ever get there. Now that my job performance is riding on it, I'll have to figure out a way or be prepared (at least) to eat large helpings of humble pie.

That's my report, such as it is.

Addendum: Not that much time passed and I got two helpful responses on the forum. Turns out I made some minor, newbie errors. Oh duh. Now, back on track.

Tuesday, December 3, 2013

Oh man! I've really ignored this place!

I can't believe it's been over a year since I've written on this blog. Well, yes I can. My priorities have shifted quite a bit, certainly away from learning Python. I think my brain just gets stuck at a certain stage of the learning process and I can't break beyond the barrier. So I give up and pursue an avenue that's a little easier to navigate (or one that I feel more passionate about).

But that's changing.

I've made a number of abortive attempts at learning in other venues including Codecademy. I felt like I wasn't learning how to program there either, but a number of months ago (I don't remember how many), I "started with the basics," as Edna might say, and revisited Codecademy's vanilla-level HTML tutorials. I know. That's shamefully elementary, but I wanted to get back into an area where I felt comfortable and at home, and then start ramping up again...slowly.

But I got distracted again and let it slide.

However, performance evaluations have a habit of shaking one out of complacency and overcoming inertia. I perform some routine maintenance tasks on two websites for the folks I work for. No real heavy lifting, just add a blog post, insert a news item, post a job listing, that sort of thing. We hired a company to do all the design and development which I would be helpless to accomplish.

Now, one of my goals for the coming year, my official work goals, is to learn more about web design and maybe even some development work so I can take greater responsibility for our sites. My boss will pay for any training that I want (within reason). The problem is, where to look for the resources I need to accomplish my goals (and they're not tightly defined)?

I decided to revisit some old friends of mine, namely the Certforums IT certification boards. I received some suggestions besides the CIW Web Design Certification I was initially considering. You can click the link for Certforums to get the details.

While asking more questions online and pondering my options, I logged into the Codecademy site and discovered that I had stopped my last tutorial right on the edge of "Introduction to CSS".

Cascading Style Sheets (CSS) has been a sort of nemesis of mine, although I don't know why. It shouldn't be any more complicated than HTML but some sort of phobia kicked in and I dropped that one like a hot rock, too.

Today though, with new motivation in hand and no other viable option immediately available, I decided to give Codecademy another whirl and I was hooked. Everything seemed so easy (not that I've done that much yet) and I felt like an old dog might still have a few tricks left in him. Mind you, this is light years easier than programming, but I've got to start somewhere.

I've been missing this blog. It was my first blog and I have a nostalgic attachment to it. I see that fifty people are subscribed so when I post a new article after over a year, I can only imagine fifty people are going to fall over in shock...or wonder, who the heck is that, having forgotten all about me and an old blog called "A Million Chimpanzees."

If you've taken the time to read my entire request posted at Certforums and you'd like to respond with something helpful and polite on this blog, I'd be appreciative. If not, then at least I've gotten the ball rolling on this neglected corner of the blogosphere.

As I discovered when writing on another of my blogs (where I spend most of my time these days), blogging is a great way for me to process information. I think that's what I was trying to do here too, but the information wasn't sticking so my determination flagged. Since I've made learning basic web design skills a work goal along with a number of other priorities, I can't just drop it again. What I can do though, is blog about what I'm learning, what I'm not learning, where I'm stuck, and where I'm going.

I don't expect a lot of people to care (barring spammers, of course), but like I said above, any reasonable suggestions and responses are welcome.

As I make my way through the next series of Codecademy tutorials, I'll post my progress. If something else comes up, I'll mention that, too. If you've got other suggestions (books, online resources, and so on), let me know.

Friday, August 24, 2012

Book Review: Think Like a Programmer

Author: V Anton Spraul
Format: Paperback, 256 pages
Publisher: No Starch Press (August 8, 2012)
ISBN-10: 1593274246
ISBN-13: 978-1593274245

I'll give No Starch and Amazon the benefit of the doubt and say that any understanding about the intent, purpose, and function of the book are mine. Spraul's Think Like a Programmer really wasn't quite what I thought it would be.

Let me explain.

One of the issues with learning how to program, as the author rightly states, "isn't learning a language's syntax—it's learning to creatively solve problems so you can build something great." More to the point for me, it's learning the thought process that's used by the programmer. What makes it easy for one person to pick up a book on a language such as JavaScript or, for the sake of this book, C++ and start useful programming in a relatively short period of time, while another person who seems equally intelligent always gets stuck at a particular point in the learning process?

Besides the willingness to practice and sometimes be virtually obsessed with programming, it's the ability to conceptualize the idea of programming, and probably the world in general, in a very specific way. I think this is what makes some people great artists while others can barely doodle. Your brain is just "wired" to program (or draw or doodle). However, that doesn't mean people who don't consider the process of programming (as opposed to the process of learning and using a specific language) intuitive can't learn to program, at least to a degree. It just means that the non-intuitive "programmer" needs to learn to think in a particular way by training and practice rather than just "getting it" naturally.

I mentioned before that some people are just intuitively artistic, but I also learned many years ago from Dan O'Neill and The Big Yellow Drawing Book, that anyone can be taught to draw. It doesn't mean anyone can be turned into a Picasso, but they can learn to be reasonably competent, as long as they follow a certain order of steps and practice regularly. That's how I imagined Spraul's book would present learning to think like a programmer.

O'Neill's book doesn't assume anything except that the person using it can see six inches in front of them and hold a pencil. Alas, Spraul's book is based on the assumption that the reader has some programming experience and specifically with C++. Since Spraul is advertised as having "taught introductory programming and computer science for more than 15 years," it seemed reasonable to assume that the book was a very beginning programming book or better yet, a "pre-programming" book where the reader is taught to think like a programmer and to learn introductory programming simultaneously.

That's my fault, I suppose. In order to even use the book to its fullest extent, you have to have some basic knowledge in compiled programming languages in general and C++ in specific (I know just enough JavaScript and Python to get my face slapped, as the saying goes..I don't know from C++ from jack). Before that, you have to know set up a compiler so you can even run your code (assuming you know how to code anything in C++). So if (like me) you thought Spraul's book would be a beginner's book on coding and thinking like a coder...oops.

Now for the good news. The book will probably hone your programming problem solving skills or even help you hone your puzzle solving skills...but again, if you are a C++ newbie, you will probably be out of luck. OK, I know that writing a book that is language agnostic or without referencing a programming language at all is probably impossible. You can't teach the thought process behind programming in isolation from doing actual programming. But (and I'm sure Spraul would disagree with me on this, but I'm the newbie here) there were two errors (in my humble opinion as the reviewer) made before the writing of this book ever started. The first was the choice of programming language and the second was requiring that the reader have prior knowledge of that language. Something like JavaScript or Python would have been a better choice (for all I know, Spraul is more comfortable teaching C++ but who knows?). They require virtually no set up on a computer and are considered more "beginning" programming languages. Also (again, in my opinion), it wouldn't be quite so challenging for a total newbie who also isn't an "intuitive programmer" to pick up either language for the sake of learning problem solving.

Beyond that, teaching problem solving isn't exactly the same as teaching a thought process. How do programmers think differently than non-programmers? Can the difference be taught to non-programmers who want to learn to program (if not for money, then for fun)? With all due respect to Spraul, who I'm sure is a cracker jack teacher, programmer, and a wonderful human being, I don't think this book teaches that to the non-programmer audience. The "disconnect" may be between the process of teaching programming in the classroom, where the student has plenty of support, including any introductory technical set up required for the language being used, and picking up a book and teaching yourself not only programming, but "how to think like a programmer."

The "dream book" for non-programmer newbies to learn to successfully program has yet to be written.

Monday, February 16, 2009

Spelling, Algebra, and When to Turn Off the Computer

Update 2009/02/18: Tim O'Reilly commented on this blog entry, and it looks like I didn't read his original comments well enough. I appreciate him stopping by my humble abode and feel it necessary to include his comments here.
"I think you missed the point of my "change happens" blog post, if you thought my reply was "just get used to it." In fact, I was writing about resilience in the face of change. And what you're talking about - stepping away from the computer when needed - is one way to become more resilient in the face of change. We should always be wary of becoming too dependent on our tools. FWIW, I also published the book you recommend at the end, Steve Talbott's Devices of the Soul, as well as his much earlier The Future Does Not Compute. So I really don't know why you thought that my "change happens" piece was contrary to your thinking".
Mea culpa. Update 2009/02/17: I saw this Calvin and Hobbes cartoon this morning and thought it the perfect "counterpoint" to my article. I just proves that doing it "the old fashioned way" has pitfalls, at least when your tutor is a tiger. LOL Original Article: Tracey Pilone's recent blog at O'Reilly.com, The Intersection of Algebra and Technology got me thinking about one of my "soapbox" issues; the use of computing in education. One of the biggest proponents of computers in schools is the Bill and Melinda Gates Foundation which has provided millions of dollars in technology to education, from Elementary schools to Universities over the years. But is this all a good idea? As Pilone, co-author of Head First Algebra (O'Reilly, December 2008) points out in her blog, there was a great deal of discussion between the authors (her and her spouse) and the publishers as to how much technology should be injected into the book. In other words, should graphing calculators be required or at least "allowed" in working through the book's problems? The ultimate answer was "no", which was a relief to me (I don't what to have to go out and buy one again). The Pilones had grown up and learned Algebra in a world without graphing calculators, and certainly generations of mathematicians worked through Algebra without such aids. Learning to do it yourself has advantages (and yes, calculators are "allowed" to perform simple math calculations). Pilone also mentioned a Duke University study, Scaling the Digital Divide which "surprisingly" concluded (not a surprise to me) that ...the impact of home computer use is, if anything, negative on school achievement. That means that there may be benefits to learning language and mathematics before introducing technology into the mix". I have an experience that illustrates this in a very simple way. I'm known as the dictionary of my family. Whenever anyone wants to know how to spell a word or the definition of a word, they ask me. Why? Because 9 times out of 10, I probably know the answer. I grew up in a world without the Internet, online dictionaries, and spell checkers. I still have hard copies of a Dictionary and a Thesaurus that I consult when I want to learn something about words (and since I'm a writer, I refer to them often). Since I grew up with this practice, without realizing it, I had memorized a large number of word spellings and definitions, so I've become something of an asset to my kids and my spouse (and to myself). There are words that always "defeat" me, such as "Caribbean" and "Mediterranean", but for the most part, I'm pretty good at not having to use "high tech" to figure out how to spell (I suppose a hard copy dictionary could be considered "low tech"). The idea of putting computers in schools is simple and understandable. Computers are *the* tool of the 21st century for accessing information in the "Information Age". I say "computers" using the widest possible definition, including hand held devices and any hardware or software utility used to store, collect, organize, and transmit data. I'm not saying to pull all the PCs out of the classroom and to burn down all of the computer labs at your local university. I am saying though, that we sadly teach our children to use a calculator to do simple addition, subtraction, multiplication, and division to the point that they can't even make change at a grocery store and they always assume the cash register (or whatever it's called these days) is right (even though it's not). This practice is not doing our children and future generations any favors. Tim O'Reilly wrote an article for his blog yesterday called Change Happens and communicates the idea that, since change is inevitable, we shouldn't resist it. I replied to his tweet on twitter that I didn't think all change was good and got back the standard "party line" that it's inevitable, more or less saying "why fight it"? This makes me wonder if O'Reilly bothered to read Pilone's blog (which after all, is published on OReilly.com), since it doesn't seem to line up with his perspectives. Yes, change is inevitable and some change is beneficial, but not all change should be embraced. No, the future won't be like we imagine and the future won't always be good, but that doesn't mean we're helpless in the face of change. Change is caused for the most part, by the intervention of people in the world. It's not an elemental force we are helpless to affect, such as a hurricane. We can steer the course of change. All we have to do is care enough to make the effort. If we want to take control of our education, our understanding of the world around us, and the direction of our lives, we can do small, simple things to make a difference. It can come down to something as straightforward as learning and memorizing the spelling and definitions of words, and working out algebra problems using a pencil and paper. Tools are instruments to be used by people; we are not to be used by them, nor should our lives be dictated by them, simply because they were invented and simply because they exist. Again, I'm not talking about "killing" the PC or Mac. After all, I make my living documenting technology in a number of different ways, including being a technical writer for a software firm, writing books and book reviews about technology, and a column for Linux Pro Magazine. I'm not talking about biting the hand that feeds me. I am talking about making conscious and calculated decisions on when to use technology and when to use less complicated (and less convenient) tools. Your brain is still the best "technology" that you'll ever have for solving problems and making decisions. Try putting away the cell phone and Kindle and picking up a book once in awhile. You'll be surprised at how much you learn. By the way, Harlan Ellison spoke somewhat to this point in his short story Jeffty is Five, which I read many years ago and which remains one of my favorite Ellison works. An excellent book on precisely this topic is Steve Talbott's Devices of the Soul: Battling for Our Selves in an Age of Machines. Reading these works is worth definitely worth your time.