Noob Gains

4th GA Web Development Immersive, Sydney 2014

[sydneyapprentice]

"learning the programs/languages themselves will take several months, but the computer guys I know - coders, hackers, and just general backend programers - all understand how the machines work. It's a line of thought, and once you have that, which OP already does, retrofitting your mindset to a new language is pretty easy."

from reddit and wellitsbouttime

[sydneyapprentice]

MadFrand on working in web dev:

"You're in a time that's changing probably more rapidly than it ever has. There are times when you spend a week implementing something, just to realize that it's already considered cliche and bad practice at the end of that week. 

Web Dev is a very trendy end of the Software Industry, so don't spend too much time and get too specialized in anything that's not a standard. HTML5, CSS3, Javascript are all w3c standards.

jQuery is not a standard, but it's used pretty much everywhere. But since it's not a w3c standard, if something insanely better comes out tomorrow, then the world will start switching to that and away from jQuery. Same thing for any server-side language: Ruby, Scala, Java, etc. PHP is on pretty much every server and that's mostly why it's so popular. Most developers would rather not use PHP if they can help it. It gets very messy when you start getting into large projects. But if you want to build something that can be run by pretty much anyone anywhere, you build it in PHP. (like Wordpress or Drupal)

Don't take me the wrong way though, any of these languages are good to learn. Just keep your eye on other things and learn more than 1. Don't get to the point where you can only program in Ruby and nothing else or you can only program in PHP and can't comprehend how a pre-compiled server-side language like Java can possibly work. The point is, learn to program, don't just learn how to use a language."

From:

http://www.reddit.com/r/learnprogramming/comments/23d866/ive_been_a_professional_web_developer_for_3_years/

[sydneyapprentice]

Zen of Python

"Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!" Tim Peters, via Thinkful

[sydneyapprentice]

[sydneyapprentice]

"Programming is hard … even the pros feel uneasy at times. So try to enjoy the journey. This - the learning, the small victories, the struggle - is what it’s like to be a programmer. Breathe it in, and smell a few roses."

http://sarahunderstandsverylittle.tumblr.com/post/80748855508/hack-and-tell-plus-zed-shaw

[beingfather-blog-blog]

[gnrlassembly-deactivated2016120]

Never too early to start

[sydneyapprentice]

Code With Impunity

1. Create immunity necklace:

  git branch 'you_can_break_this'

2. Wear necklace:

  git checkout 'you_can_break_this'

3. Prove it is working:

  git branch

4. Keep the necklace:

  git checkout master   git merge 'you_can_break_this'

5. Destroy the necklace: 

git branch -d 'you_can_break_this'

[sydneyapprentice]

Rails after Sinatra

[sydneyapprentice]

From Clean Code

[sydneyapprentice]

[sydneyapprentice]

Trying to surrender happi_pets back into the shelter

[sydneyapprentice]

First steps in Git

One of the very first things you might do in Git is save files. 

First we add them to the staging area with "git add ."

Then we commit them to version control with "git commit -m "put your notes here" 

You can do it without the -m message, but you'll then need to add your notes in the git editor. 

You can also add specific folders by typing "git add directory/"

2. Differences

Type "git diff" to see any discrepancies in your current files. If you've already added them to the staging area, you can see the differences in staged files by typing "diff --staged". 

3. What if you want to get something off the stage? 

You type "git reset HEAD filename" and the stage will be rolled back.

If you make a mistake or forget something, you can pull your changes off version control and back onto the stage by typing "git reset --soft HEAD^"

4. What if you want to add or update individual files?

You type "git commit --amend -m "Your new updates" 

5. Sharing with others

To connect to a remote repo, you need to set a bookmark for it. 

So you type "git remote add origin url"

To add your local files to the remote repo, you type "git push -u origin master" 

Lastly, don't run the reset HEAD commands after you've pushed. It's like changing the past, and as we know from sci-fi, that can leads to problems. 

6. Cloning, branching, checking out, merging. 

To clone a repo, type "git clone url". 

To make changes to the repo, "git branch mychanges"

Then work on that repo by typing "git checkout mychanges"

If you want to add the changes to the master branch, go there with "git checkout master" then add them with "git merge mychanges"

[sydneyapprentice]

Lesson 17 of Ruby the Hard Way: Commands

Here's the list of commands to remember:

close -- Closes the file. Like File->Save.. in your editor.

read -- Reads the contents of the file, you can assign the result to a variable.

readline -- Reads just one line of a text file.

truncate -- Empties the file, watch out if you care about the file.

write(stuff) -- Writes stuff to the file.

[sydneyapprentice]

Learning Ruby the 'hard way'

Starting the 50 short exercises in this book: 

http://ruby.learncodethehardway.org/book/

So far it's a nice continuation from codeschool and codeacademy. Explains things in a different way but also a beginner level. 

Nice quote at the end of exercise 7: "Remember that everyone makes mistakes. Programmers are like magicians who like everyone to think they are perfect and never wrong, but it's all an act. They make mistakes all the time."

[sydneyapprentice]

OOP

Objects have methods, which you've seen before, and attributes, which are just data.

[sydneyapprentice]

Learning to yield

Why do some methods accept a block and others don't? It's because methods that accept blocks have a way of transferring control from the calling method to the block and back again. We can build this into the methods we define by using the yield keyword.

Code:

def block_test   puts "We're in the method!"   puts "Yielding to the block..."   yield   puts "We're back in the method!" end block_test { puts ">>> We're in the block!" }

Output:

We're in the method! Yielding to the block... >>> We're in the block! We're back in the method! nil

[sydneyapprentice]

Ruby Codecademy Update

We learned a bit about blocks in Loops & Iterators and Methods, Blocks, & Sorting. We said earlier that a block is like a nameless method, but that's not quite true. (We'll get to actual nameless methods, called lambdas, later in this lesson.) A Ruby block is just a bit of code that can be executed. Block syntax uses either do..end or curly braces ({}), like so: [1, 2, 3].each do |num| puts num end # ==> Prints 1, 2, 3 on separate lines [1, 2, 3].each { |num| puts num } # ==> Prints 1, 2, 3 on separate lines Blocks can be combined with methods like .each and .times to execute an instruction for each element in a collection (like a hash or array).