Showing posts with label Learning. Show all posts
Showing posts with label Learning. Show all posts

Sunday, March 13, 2016

Feynman Method of Learning

I just read about the Feynman method for learning. The article describes it well, so you can read about it here. But in the spirit of the method, I'll try to describe it from memory now.

Start by writing the concept you want to learn at the top of the page.

Example: "How to learn with the Feynman method"
Why: I think this is important for getting you to focus on one concept instead of letting yourself get off tangent.

Describe the concept as if you are teaching it to a beginner.

This means describing the concept without using any subject specific jargon or relying on any other assumptions.

Why: This will expose holes in your understanding.

Go back to the source material.

After you discover holes in your understanding, go back to the source materials (books, lectures, mentors) and re-learn what you are unsure of.

Simplify

Describe the concept again using simpler words and analogies.

Why: This will ensure you have a deep understanding and you aren't accidentally, incorrectly assuming anything.

My takeaway

The methodology sounds good. I think the most important thing is being an active learner, instead of just being a passive observer.

Saturday, March 5, 2016

How to Master Skills

Recently, I watched a youtube video from Tim Ferris on how to master any skill.

He describes his process via an acronym called DiSSS:

  • Deconstruct (break the problem down)
  • Select (think 80/20)
  • Sequence (deviating from traditional order might be faster)
  • Stakes (create incentives for success or failure)
  • Simplify (less is more)

I had trouble remembering this acronym because there are too many 'S's. I thought of a better acronym that's easier for me to remember, which is DEQUE.

  • Deconstruct. Same as before.
  • Eighty/twenty. Replacing 'Select' with 'Eighty' gives me a nice vowel for my acronym.
  • Queer. I could be wrong, but when Tim suggests learning things out of sequence, I think he's actually suggesting to us to not be afraid of learning things in a seemingly odd or 'queer' way.
  • Uh-oh. Instead of 'Stakes', I think 'Uh-oh' captures the sentiment of "I need to learn this skill or else I'm screwed."
  • Enough. I think 'Simplify' is fine, but using 'Enough' makes my acronym flow a little better (in my opinion).

Unfortunately, another acronym already exists for deque (double-ended queue), but I still find it easier to remember than DiSSS.

Whichever acronym you go with, the more important part is applying it to the skill you want to learn, and it hopefully helping you master it. That is still to be determined for me.

Tuesday, July 22, 2014

Understanding the Mean JS Stack

I began working with the MEAN.io javascript framework, but due to my ignorance on many fronts, I couldn't quite see how it all worked.

I was trying to figure out how it worked by reading the generated code; experimenting with small code changes to see the effects; and reading documentation from MEAN.io and questions from stack overflow. This didn't get me very far. I was either too deep in the code or too far above in the high level overviews.

The best learning tool for me was this youtube tutorial by Michael Moser. He went through each of the components of a MEAN stack application.

I'm finally starting to get it, I think. Here are two things that I'm starting to see.

Communication between the client and the server is done via http verbs. In your client side angular controller, you can do a few operations with your model like $get, $save, $remove and $update. These correspond to http verbs like get, put, delete, update and so on. It seems so simple now. My misconception was that I could define functions with my own keywords and I'd have to keep this in sync between the client and server.

The node package manager is only used on the server. This means, "npm install whatever" allows you to write
    var whatever = require('whatever');
in server side code. It doesn't work on the client (I think). This again makes sense now that I realized it. Node is your server, so you wouldn't install server side modules onto a client.

Working with new technologies is painful. But things are easier with youtube, tutorials, Q&A sites. After you become an experiment in something it is hard to remember how you felt when you were a newbie and what you didn't quite grok before.

This blog entry is just a reminder to my future self of how little I once understand.

Friday, June 20, 2014

Early reflections on MEAN framework

A few days ago, I initialized my first MEAN.io app.

It's fair to say that I'm a complete new comer to this style of programming. As a newcomer, I'd like to document what I think MEAN is, how it works and my overall impression on it. I'm sure there will be many misconceptions and inaccuracies. Over time, it will be funny to reflect on how lost I once was.

So MEAN is built on top of NodeJS. NodeJS is a server where you can write Javascript code. Why does it matter that you can write Javascript on the server side? The key point is that you program things such that everything is event-driven and everything has a call back.

For a developer like me, this makes the code look a bit gnarly. Instead of executing code in a linear path that matches the code in your text file, different functions are fired off as needed when things are ready.

Of course, the benefit of having event-driven code with callbacks is that the server keeps the UI thread free and clear as much as possible. This makes the application super-responsive. So, making things a bit harder for the developer, but nicer for the user is a good tradeoff.

Now on top of this event-driven server (NodeJS) MEAN uses ExpressJS. I have read that this is a web-framework. Since I'm not a web programmer, this is the component in MEAN that I am most unsure about. For now, I think of it as the plumbing or middle man that helps send messages between the UI screens and the backend server and databases. Is that a correct notion? I'm not sure. Like I said, this feels a little abstract to me.

So, I'll move on to the component I understand the best. MongoDB is a NoSQL database. You insert data and retrieve data as json objects, while they are stored in some binary format. Why is it json? I'm not sure, but it certainly fits into the idea of having this framework be javascript from top to bottom.

One of the nice things about NoSQL databases like Mongo is that you can easily add data to collections without a lot of painful schema designing. Any old json object is ok. The downside is that you can throw anything in, and that leaves model validation up to you.

And the final part of the MEAN.io web framework is AngularJS. AngularJS is a "new" way to do HTML and UI. So far, I've come across at least two new things that AngularJs adds to an HTML web page. Data binding allows you to use a variable directly in HTML code. (I think). Dependency Injection allows you to swap in different dependencies (pieces of code as needed). Did I define those correctly? What are the benefits to these things? I don't know.

I have a feeling that I not only said some dumb things, but that I will inevitably program some dumb things in the near future. Hopefully, I learn and can appreciate all of the magic that occurs within the MEAN framework.

If you are new to MEAN or to programming in general, take heart that your feeling of being lost is shared by me.

Wednesday, March 5, 2014

Learning on the internet

In the few years that I have been programming, I have learned a mountain of stuff; yet there is an ever expanding galaxies of things that I don't know.

I'm always trying to bridge this gap by learning. Lately, I've tried out two platforms, Codecademy and Coursera. These are both excellent and free resources. The material on both sites is amazing. Neither are magic. You still have to work to learn the material, but the fact that this sort of material is out there is amazing. Stop surfing the web and try it yourself.

Coursera
Coursera has a number of courses given by college professors. The courses have video lectures, homeworks and exams. There are also online discussion forums where students are asking/answering questions moderated by administrators of the course.

I've worked through a few courses (Computer networks, Algorithms, and Databases). I cannot say I completed the courses, because I didn't do all the lectures and exams, but I think I still learned a lot, which is the purpose of it all.

Coolest things about Coursera - the video lectures are insanely good. You get lectures from professors from the best schools in the world for free. If I were a paying student, I'd feel a little bit cheated!

Worst thing about Coursera - I'm not sure why, but some of the courses start and end on a fixed schedule. Once the video lectures and other material is created, I'd like for the material to just stay online so that I can go at my own pace. I found that some weeks would go too slow, and I'd be waiting on material and some weeks would go too fast. But this is a minor gripe, as many of the courses repeat.

Codecademy
Codecademy has a much narrower focus, to teach people how to code. Instead of video lectures, homework and tests, they have a very nice text editor that you can use to interactively code and learn.

I took the web course which focuses on HTML and CSS. Relative to my experience it was a little bit too basic, so I wanted to skip ahead a bit. In any case, due to the fact that it was gamified (I got points and badges along the way), things felt fun and I continued until the end.

Coolest thing about Codecademy - as mentioned before, the editor is great. It allows you to immediately try out the code you are learning without setting up a test development environment.

Worst thing about Codecademy - I haven't encountered anything bad yet. I wonder how things will go as I advance. I will take the JQuery course and see what that's like.

Conclusion
I plan on continuing to use both Coursera and Codecademy. I can't believe such great resources are free.

I imagine that this will be the future of learning. It is much more efficient, convenient and scalable. I am not sure if it is as effective as the traditional mode of learning, but it's working for me. Give it a try!

Wednesday, December 11, 2013

Hardware is hard

The wife and I started working on a robot.  We are trying to follow the tutorial at Let's make Robots.  I have found that working with hardware is hard.

As with many things, the hardest part is that I don't have the basic skills or knowledge.  For example, soldering looks like the basic building block of putting electronic components together.  For a regular software developer, it is akin to editing text.  If you can't solder, then you can't build any electronics, and I didn't know how to solder.  When you don't know what to do, how to do it, or why it should be done, making progress is hard.

In the hardware world, everything costs something.  In the software world, once you have a computer and an internet connection, there are tons of free languages and tools to build real world applications.  If you have been building robots for a while, you may have a collection of unused supplies.  But for me, a beginner, I had to buy a lot of stuff, from wires to soldering tips and of course batteries.

It is not easy to undo a change.  If you break something, you might need to buy a new one.  This makes tinkering a little bit scary.  For now, I don't have a good means of debugging a problem or testing a change.  It will take a combination of increased knowledge and maybe some new tools (like a volt or current meter) to really be able to debug problems.

This experience reminds me of being a physics student.  In class, we solved problems and the math worked out perfectly.  Then, we tried to measure things in lab, and all the answers were just a bit off.  The hardware world is much less forgiving, but I hope that going through the trouble of working with hardware will have some benefits.  I hope to have a greater appreciation for all hardware, and I hope it helps me be a better software developer.

Tuesday, September 3, 2013

First time using coursera

A few days ago, I registered for my first class using coursera.  Coursera provides free online courses from top-notch educators.  The first class I am taking is https://class.coursera.org/db/class, by Jennifer Widom from Stanford University.

I use databases pretty often, so I expect to be familiar with a lot of the material.  Nevertheless, I hope the course will help me fill in gaps of knowledge that I might have missed and organize my understanding of databases in general.

So far, I have only watched the first lecture, which was just introductory material on databases.  Here are my some things that I liked.
  • The quality of the video and audio is good.  It is clear and clean.
  • The video has subtitles, which I turn on even when I have audio on.  
  • The video also lets you change the playback speed. I set it to 1.25x speed.  When I come to a lecture where the material is more unfamiliar or a bit difficult to understand, I can reduce it back to normal speed. 
  • Each lecture is relatively short. The longest one goes for 30 minutes, but many are around 15 minutes.
  • The ability to pause and rewind is great and much better than live lectures.  If I missed something I can rewind and try again.  Or, I can go on the internet and search for a different explanation.  I can then move on with the lecture when I feel ready. 
Overall, I think coursera is a pretty great service, and I hope that I persevere long enough to benefit from it.