Showing posts with label coding. Show all posts
Showing posts with label coding. Show all posts

Thursday, September 19, 2013

Coding 101: What Languages to Learn

Let's keep going.  At this point I've talked a lot about different programming languages.  But, the more important question that needs to be answered is, what programming languages should you learn?  More than that which programming languages are easiest to learn?

My answer to those questions is...that depends.  Yea, I know that's a cop out but it really does.  The context in which you want to program is really important and I'll cover some of the biggest contexts and what languages would be most helpful for each one in this post.

Tuesday, September 17, 2013

Coding 101: Object Oriented Programming

Next topic, let's talk about 'Object Oriented Programming', often abbreviated OOP.  OOP is a topic that often comes up when talking about programming languages.  So what is it exactly?

OOP is the concept of treating the world as a collection of objects.  If you want an apple in your program, create an apple object, if you want a dog in your program, create a dog program.  Internally, these objects have properties which describe them, for apples you might have a property for color and another for shelf life.  For a dog, you might have properties like breed or age.

So far so simple right?  Every 'thing' that you want to exist in your program should be defined as some kind of object, easy.  Generally, when talking about OOP, these objects are represented as classes.

So, what does OOP accomplish for programmers?  OOP often times is described as allowing for a particular set of things.  Depending on who you talk to, you get different answers, as I was taught OOP allows for 3 things, encapsulation, inheritance, and polymorphism each of which I will talk in detail if you wish to continue.

Friday, September 13, 2013

Coding 101: Typing

Next lecture in my Coding 101 series.  Looks like September is another one of those coding based months.  Anyways, this post is about typing.

What do I mean by typing?  Surely I don't mean the act of typing on a keyboard.  While an interesting topic, see Dvorak, this post is not about that.  This post is however about programming languages, more precisely the type safety of a language.

In particular this post is about the difference and examples of statically typed and dynamically typed languages.

Saturday, September 7, 2013

Coding 101: Types of Languages (Imperative and Declarative)

Let's push forward with Coding 101.  The topic for this segment is the different types of programming languages.  I mean for this to be a high level post and maybe in the future I'll go into more depth about them.  Anyways, let's get started.

First off are the languages that most people first get introduced to in computer science courses.  These languages are the 'imperative languages'.  Examples of this kind of language are languages like C, Java, Python, or Ruby.  The reason why these are called imperative languages are because each line of code you write is an instruction.  It's a command.  You can think of languages like these as recipes.  You tell the computer a set of instructions that have to be done in a specific order.  Logically, these kinds of languages are relatively simple to grasp once you understand the syntax that goes with the language, much like learning French or Mandarin.  Since things (almost always) happen exactly in the order that you write them, it's usually pretty simple to figure out when something goes wrong because there is an order that things happen in.  There are some wonky edge cases but as a whole this is true.

On the other side of the language fence are declarative programming languages.  Examples of this kind of language are Lisp, Haskell, Scheme, or parts of SQL (select queries in specific).  These languages differ in that the idea behind them is to declare what to do with your data.  For example, imagine you have a bushel of apples, some of them are red and the others are green.  Now, imagine you want to know how many red apples there are.  In an imperative language, you would have to take each apple out, examine if it's red or green and take a count.  In a functional programming language you would apply a function of whether something is red or green to the bushel and get the subset of red apples from which you can take the count.  Or you might just ask to get all the red apples from the bushel.  Internally, it's quite possible that the two approaches look the exact same, but from our perspective as coders they look quite different.

Thursday, September 5, 2013

Coding 101: What's the big deal?

New segment on an old topic.  Let's get down to it.  Recently (not so recently), I've come to realize that coding is quite intimidating.  There are tons of resources out there and a bunch of them honestly suck.  Even the good ones don't do a great job at explaining just how diverse and multi-dimensional the world of coding is.

Now I'm sure I've noted that computer programming or coding is important and that you should get started.  But really, it is quite intimidating.  For one, there are a ton of programming languages, from C to Python to Perl to PHP to Haskell.  While they all kind of look the same they all have their own nuances and their own strengths and weaknesses.  As a beginning coder, it's hard to wrap your head around what a pointer is or why dynamically typed languages are 'slow' or what 'slow' even means.

The point of this segment, Coding 101, is to go over things at a high level.  Things like, why program or what are the different kinds of programming languages.  Why pick one programming language over another, what tools are available for you as a coder to use.  I'll try to keep things simple, but as with any technical subject there is a lot of jargon to absorb.

Hopefully someone will find this useful and I hope to cement what I've learned and observed for myself.  So let's begin with why program?

Tuesday, September 3, 2013

Big Data

Big data is a topic that many people spout off and one that is quite interesting to talk about.  If you're unaware, the idea behind big data is that every website you hit, every search you put into Google, every Facebook post you like is stored somewhere and in turn those companies use that data to better predict what users like you want to search for or buy or might want to look at and like later.  So why is this 'big' data?  Well for one, there are billions of people on the internet every second of every day.  For each person, there is some amount of data being created and stored somewhere on some server belonging to some company.  How much data does this equate to?  Well here are some ideas.  Easily put, it's way more than you can sit and look at even if you had multiple lifetimes to look.

Now that we've established just how big the internet is and how much data there is, how do we deal with that?  These numbers are so large that they are beyond what we normally think of outside physics, in particular physics of an astronomical scale.  Let's put these numbers in perspective.  There are roughly 3 million emails sent per second every day.  Now 3 million is a large number I think we can agree on that.  But that also means that there are roughly 90 trillion (107 trillion if you're looking at the infographic in the second link) emails sent per year.  Sure, a great deal of those are spam, but even the 10% that isn't amounts to over 10 trillion actual emails.  If we assume, that each email is just one line long and that there are 50 single spaced lines per page, 100 as we'll even let them be double sided.  Let's be so bold as to say that a novel is generally 500 pages, to make the math easier.  10 trillion emails would then be 100 billion pages long or 200 million novels worth, and that's only what we're generating per year!

Personally, I find big data intriguing.  There's this idea that this is a internet related problem and so people might call this problem an 'internet scale problem' but honestly, 'Big Data' just sounds better.  It's simpler and doesn't really require you to know why these things are necessarily problems.  Be assured though, big data is a problem that many people are trying to figure out.  As the years go by, more and more ways of handling it emerge from transitioning to NoSQL, to using MapReduce, among other things.  If you didn't care for the post, I hope you at least enjoyed the infographics.  Until next time.

--CsMiREK

Friday, May 17, 2013

Step Four: JavaScript/jQuery

After learning HTML and CSS comes JavaScript.  So what exactly is JavaScript?  JavaScript is a programming language, much more similar to Java or C++ or Python than HTML or CSS.  What this means is that you can do much more computationally interesting things with JavaScript.  While HTML and CSS are focused mainly on rendering webpages from text, JavaScript is more about how to add interactivity to a site.  This is not fully true as CSS3 introduces a bunch of cool features that allow some interactivity that used to belong fully in the realm of JavaScript

More specifically though, why learn JavaScript?  In my opinion, JavaScript is more necessary than either HTML or CSS when it comes to programming for the web.  It allows for so much of the web, from pages that have auto-refreshing or auto-loading content a la Facebook walls (AJAX) to adding very complex actions on click or hover events.  However, JavaScript is also much more complex than HTML or CSS and takes a lot of work to really understand.

I have also put a point here to talk about jQuery.  jQuery is a JavaScript library designed almost solely for common web related JavaScript tasks.  What this means is that it is an independently created set of functions using JavaScript meant to make web based JavaScript easier.  It is useful, for instance, in when you want to add click events programmatically to objects.  Or perhaps you want to add new elements to a page when a button is clicked, jQuery provides easier and well tested ways of doing such things.  However, it should be noted that anything you do with jQuery can be done with JavaScript too.  In my opinion, you should learn JavaScript before jQuery so you know what kinds of benefits you are getting and so you know exactly what things are possible in regular JavaScript that are not expressible with jQuery functions.

That's all I've got on JavaScript and jQuery.  If you intend to do anything web related I view JavaScript as extremely necessary unless you want to make really static pages.  Anyways I hope you enjoyed that and hopefully I can back fill some of these old posts more quickly than I have.

--CsMiREK

Saturday, May 11, 2013

Step Three: CSS

Ok, if you've gotten this far, you know the basics of HTML.  But now you're probably wondering how websites manage to ever look nice with the clunkiness of raw HTML.  Blah blah you can use style tags and whatnot to position.  But let's be honest, that sucks.

And that's where CSS comes in.  CSS stands for Cascading Style Sheets, which is a pretty strange name.  However, it's what makes web coding interesting.  By doing relatively simple things and organizing different fields: id, class, etc. you can make really organized and pretty good looking websites.  Don't worry about interactivity yet, that's coming up.  (Note that if you're into the hip, new CSS3 stuff, a lot of interactivity can be done with CSS.) If all you need is a really good looking site that won't flip a shit when you change one line in your HTML, after this section you'll be pretty much set.  (Interactivity is what makes the internet fun though so I hope you stick around.)

--CsMiREK

Friday, May 10, 2013

HTML Resource Four: Treehouse

Time for the fourth in this series on HTML resources, Treehouse.  From a first look standpoint, I find that the site is mainly based off of videos.  Now, while I personally don't want to sit through videos, I think that many people do like videos and so I will continue to review it based on content.  While the site is a paid site, there are a lot of introductory materials for free that you can try out.

Personally, I'm actually not going to sit through this site but the projects do seem quite good and the videos seem like really good resources.  However, I will say that it appears that the site does end up going quite in depth if you're willing to pay and they have stuff all the way from web development to iOS and Android development.  So if you're looking to dip your toes into programming and are willing to spend that bit of money for pretty much lectures with instructional aid, this site looks like a really fine website to help you in your pursuit.  Going forward, I'm going to cover the basics of what CSS is and what its functions are.  After that I'll go over codeavengers and Codecademy for those.  Then we'll dip into Javascript/JQuery and again I'll cover some resources to tell you what I think.  Until next time I hope you enjoyed the posts.

--CsMiREK

Thursday, May 9, 2013

HTML Resource Three: Codecademy

The next resource I'm covering is Codecademy.  Codecademy is a pretty well known site as of now for being really intuitive and covering things in a pretty good and methodical manner.  Personally I find it to be a good, if a bit fast pace, more than CodeAvengers.  They also cover things for full stack development like Ruby, Python, and PHP if you think you might have a knack for the back end server kind of stuff.

When you get to the website, if you want to learn HTML, head up to the 'Learn' tab up top and go to 'Web Fundamentals'.  From there sections 1 through 3 are all HTML.  I didn't go quite as in depth on this one and didn't quite finish doing the tutorials, but from what I did, I really enjoyed it.  The pacing is pretty good and the examples are quite nice.  They don't have review sections quite like CodeAvengers does.  However, they do have full project type reviews after the main lessons which is just as, if not more, important to learning how to program.

Overall, I think that the breakdown and ordering of topics that Codecademy uses is better than CodeAvengers.  However, don't let that be a view that you pick up just because I said so.  Feel free to try everything and see what works.  Often times, I find myself picking things up long after I first learn them.  Just make sure you put in the effort and time and I think you can learn anything you put your mind to.  Until next time.

--CsMiREK

Tuesday, May 7, 2013

HTML Resource Two: CodeAvengers

Here we are at a tutorial based resource, CodeAvengers.  For this section I'll only cover the HTML portion of the tutorials (Up through lesson 10 of level 1) they have.  For reference, the entire section took me about an hour and a half to finish, although I was trying to rush most of it down, so expect maybe double to triple the amount of time if you're just starting out.  Anything else besides HTML covered, I'll cover in a different post. So let's get started.

To start with, I think that this particular tutorial series is kind of dumbed down.  It seems quite slow in its pacing, but for a beginner that might be exactly what you need.  However, I also find that their chosen interface is kind of clumsy.  The phone on the side is interesting, but the button placements and ordering to remember just seems extraneous.

I think the first lesson is kind of a throw away as you're mainly just typing text and it seems kind of pointless.  I also wish that they could just show both the example and your page at the same time.  Switching back and forth not only wastes time, it detracts from the learning experience and is kind of frustrating, especially when they have hints that sometimes outright give away the answers.  I also find that the ordering of topics is somewhat odd as the <p> or paragraph tag is not introduced until the 8th lesson.  They also make an example where they have <p> tags without the closing </p> tag, which while unnecessary, is cleaner and more straightforward in my opinion, <br> tags are the only exception really as <br></br> isn't correct syntax. They make their reasoning for this, but I just simply don't agree.  Regardless of these differences in opinion, I find the review lessons really useful as they make you find common mistakes which are sometimes quite frustrating for new coders. 

Overall, I think that the site is pretty good.  While slow paced for me, I already have some knowledge in the subject and for beginners I feel that it is probably moving at the right tempo.  Definitely check it out if you think you'd enjoy it.  Unfortunately it seems like you can't skip forward, so if you have some experience you'll have to go through the motions again.  However, the strictness of the system is pretty on point as well so I think it's definitely worth looking at if you're new to this subject and are looking for a fresh start.

--CsMiREK

Monday, May 6, 2013

HTML Resource One: w3schools

First up on the resource list is w3schools.  w3schools is a pretty simple website.  I actually started learning from w3schools just as a beginning.  It isn't the most fun nor the most interactive, however it does go through things very thoroughly.  If you really want to know why things are the way they are, w3schools helps out a bunch with that, or better yet look at Mozilla's mdn stuff as that's what a lot of professionals like to look at.

This review's pretty straightforward as the site is pretty straightforward.  The content is really quite good, but it goes more like a textbook than an interactive guide.  If you like that, then this is probably the site for you.  It also includes a lot of knowledge on things like CSS and JavaScript and covers those in very much a similar way.  As such I'll step back from reviewing w3schools again on those topics as it'll be pretty much the same thing.  If however, you find w3schools silly and suck, you're not alone.  In the end however, whatever helps you learn best is the best for you and I hope you don't take my words super seriously because as they say, "different strokes for different folks."

--CsMiREK

Sunday, May 5, 2013

Step Two: HTML

In learning how to program for the web, the first essential element is HTML.  So the question to ask is, what exactly is HTML and why should I care?  HTML stands for Hyper-Text Markup Language and without going into too much detail, it's the reason why websites even exist.  Your internet browser (Firefox, Chrome, Internet Explorer, Opera, etc.) reads HTML and turns it into a readable format along with CSS.

As an analogy, we can say that HTML is the outline for your site.  It includes things like title, body, and headers along with paragraphs that are used to help describe and organize websites.  And just like an outline, a poorly written HTML file can lead to some pretty terrible looking things.  I won't go into details on how to build lists or tables in HTML, that's for the resources I'll cover.  However, I would like to say that HTML by itself is quite powerful, even without CSS or JavaScript.  But, I will also say that simply knowing HTML isn't enough to make really nice looking and robust websites.  Also, while you can do fine tuning of positioning and visual manipulation in HTML, that type of stuff is better suited for CSS, which I'll go over later.

Look forward to the next few updates which will cover some resources to get you started on HTML.

--CsMiREK

Friday, May 3, 2013

Step One: Resources

Step one in learning anything new is getting resources.  While some people like their books and swear by what books can teach them, I find that learning by book is really poor.  Don't get me wrong, books have their strengths, namely in organizing and structuring facts and knowledge.  However, they do a poor job of interacting and providing impetus to continue learning.  As such, I feel that any resource that does not give a strong level of interaction and satisfaction probably won't be good.

As for coding resources, I'm sure all of you can Google for 'coding tutorials' or 'html tutorials' or whatever the else you feel like typing.  But, I'll save you some trouble and give my own ideas about what these things do well and what they don't.  You'll notice that this month will have a lot of updates and that not all of them will be coding related.  I'll try to cover as much as possible and review as much as possible, but I'll put in some other stuff to break it up I promise.

If you want to get a heads up on what some other people think about the resources available and what it takes to be a coder, check out these links.  Ok, so the last one kinda sucks as it seems totally corporate, but I hope this month will be informative for you and I know I'll learn a lot.  I just hope you come along for the ride.  Also, fun fact, this is post number 42, woo!

--CsMiREK

Thursday, May 2, 2013

Disclaimer

Unlike previous posts, this month's posts are gonna be a bit more technical.  As such, I want to make some things clear.  First, learning to program is not easy.  Like anything worth doing, it takes time and it takes work.  However, like most things, it can be readily learned.  And like many things on the internet, it has many resources available to you to help you.  These posts will be focusing on those resources and what I think of each one.  I am not an expert in HTML/CSS/JS coding so this will be an informative experience for me as well.  If you have any interest in the subject my recommendation is to learn a bit from tutorials.  But mainly I think the best way to learn is to jump into things, even if you fail, you're bound to learn from your failure.  When you can understand and appreciate this and my words, then I think you'll have gotten over some of the biggest hurdles facing you.  Without further ado, let's begin and I hope you come along for the ride.

--CsMiREK

Wednesday, May 1, 2013

Into the Void

Well, I hope you enjoyed poetry month.  I missed a couple of updates but they're all up now.  Other than that, I think I'll spend this month going over some HTML/CSS/JS resources.  Partially because I want to do it to help myself and partially because I think it'll be fun for you guys as well.  So without further ado, let's begin our journey into the void of the internet.

--CsMiREK

Saturday, March 23, 2013

Musicians and Programmers Pt. 3

Here we stand, at part 3 in this series about musicians and programmers.  You must have questions.  Is this the last part?  Am I seriously reading this?  Why the hell are these posts being posted at 2AM central time?  Well...I imagine you have such questions.  Much more likely I'm deluding myself into thinking what I'm writing is read much at all.  Whatever, don't care too much.

Let's get back to the topic.  In this post I'm going to recall most of my college career and the kinds of thoughts I gathered about both topics.  Let's begin with programming since it's what I spent most of my college career actively trying to learn.  As I said earlier, I think that anyone can code, oh and you should too.  My reasoning for that is that I honestly believe that coding is a way of viewing the world.  It requires one to break things down to small discrete steps, but let's be honest, we all do that everyday.  A computer program in that sense is no different from a personal schedule.  Each event on your planner or calendar or what have you, is a function that you do because, through your experience, you have learned what to do on those occasions.  So, why am I talking about this?  Well, I think what I just said is actually wrong.  It's a perception of coding that makes people think that it's about a micro-scale.  However, it's more similar to language, where after you learn the vocabulary and syntax, it's about the composing of said vocabulary and syntax into comprehensible and meaningful stuff.  Yea, I used the word 'stuff' in an otherwise didactic post, get over it.  Anyways, barring the aside, my point is that coding is both about the micro scale which is often the bane of new programmers and the macro scale which is the need to see the big picture in regards to the programs we write.

Sunday, March 3, 2013

Rant Corner - Time to Start Coding

I'm not sure whether this is particularly unique to me or whether it's a common occurrence with everyone, but I'm a huge fan of starting projects.  Now this doesn't mean that I get a lot done.  On the contrary, most of the people you talk to about me would say that I am quite lazy.  However, I enjoy starting things without any regard as to necessarily finishing them.

To that end I am starting up yet another feature called "Rant Corner".  This one's mainly just for me to voice my various opinions on any number of things.  So, the intro isn't completely useless.  I'm not so scatterbrained to begin writing and suddenly change my thoughts...  Anyways, this episode of "Rant Corner" is about coding, a topic close to my heart.

It is my opinion that computer programming, coding, hacking, or whatever you want to call it is not that hard.  People make coding out to be difficult and cumbersome.  However, I think that that's a misconception.  While it isn't necessarily easy, coding, like anything worth doing, is about the work you put into it.  Of course there are people better than you, but that goes for everything else as well.  My thought is that through whatever experience, people get this notion that coding is hard and that there's no way that they can get better or understand it.  This obviously doesn't apply solely to coding, but it is definitely a factor in how people react to coding.  Of course I'm biased but I really do think that anyone can learn how to code and others do too.

Sunday, February 10, 2013

Musicians and Programmers Pt. 2

So it's been over a month since the last post in this series on musicians and programmers.  I suppose that means that it's about time to continue.  At the end of my previous post, I left you with a couple of questions.  At this point I would like to answer some of those.

First, what makes a "good" program?  This is arguably a difficult question as different people regard different things as good.  We can't simply base it off of popularity as there are plenty of terrible programs that are wildly successful (anyone remember Farmville?)  On the other hand, we would be remiss to say that programs that are popular and successful are not good programs.  Perhaps an apt way of gauging the "goodness" of a program is its ability to affect a large group of people.  Again it ends up being quite arguable as to what constitutes a "good" program.  Another example is Google.  Quite likely one of the most well known websites in the world, it connects humanity to reservoirs of information the likes of which never existed previously.  Surely it must be a "good" program.  It affects millions of people daily, serving billions of searches per day to people in over 100 countries, with trillions of searches per year (see this).  And yet, an article like this was published in 2008.  If you think about it, it is actually true to an extent.  The way we receive, parse, and then analyze data has drastically changed since the advent of Google and the accessible web.  That's not to say that we are or aren't any smarter due to Google but it's an interesting thought exercise to carry out.  In more recent history we have Facebook.  A site with billions of users and yet, a single bug can wipe out large regions of the internet.  What I'm trying to say is that even the most influential websites and programs have their dark sides and that makes it increasingly difficult to understand what a "good" program really is.

Tuesday, January 1, 2013

Musicians and Programmers Pt. 1

So here we are, a real post. But what should I talk about?  Well, how about I talk about myself a bit.  The purpose of this site is to show the world my views and opinions.  To do so, you should probably know some stuff about me.

Given that the title of this post is musicians and programmers I guess that must mean I am both a musician and a programmer.  Well, if you came to that conclusion, I would surmise that you are at least as smart as a 5th grader.  More specifically, I am a cellist and am about to graduate from college with a bachelors in computer science.

What I have realized in my few years in programming is that a LOT of programmers are musicians. This seems strange as in programming, you try to create programs with the "correct" behavior.  In this way, programming seems incredibly objective, there is a right answer, get to it.  On the other hand, music is highly subjective.  It is hard to gauge what "good" music is and there generally isn't an answer at all.   To that, I say that you're not asking the right questions about music nor are you asking the right questions about the minds behind the music.

I won't go into why I think so many programmers are musicians in this post, I'll leave that for later.  (If you're curious what others think about the subject, see this).  However, I want to impart onto you the correct questions to ask yourself for my next post on this topic.  First, what makes a "good" program?  At the same token, what makes a "good" piece of music?  Next, what do programmers aim for to make "good" programs and what do composers aim for to make "good" pieces of music?   Lastly, does everyone have a consensus on what constitutes a "good" program?

--CsMiREK