DarSheCodes

The great quest into unknown code. Follow me as I dive deep into Ruby development at Dev Bootcamp and attempt to make sense of it by sharing my understanding.

[darshecodes]

Apps I've Contributed to

Here are the two apps I've pushed to Heroku. I am not taking credit for the whole enchilada but I contributed my equal part on both teams. checkem out 

Flashcards

Craig's List Jr. 

[darshecodes]

CSS

so yesterday at dev bootcamp was CSS day for my cohort and I killed it. I had forced into CSS with my last job where they basically gave me a screenshot of the way they wanted a webpage to look, and I had to implement it whilst stumbling around wordpress and bootstrap3. Needless to say, I got pretty good at it and yesterday was the first day at bootcamp that I found was easy for me. I will hold on to that beautiful feeling because I know it will not last. Here is an example of one of our exercises:

We needed to make the pagination at the bottom look like this:

It originally looked like this:

Here is the HTML and CSS:

[darshecodes]

Gemfiles

This post is to remind me of it more than anything. Gemfiles hold your access to gems. 

Edit your gemfile

NEVER edit your gemfile.lock. 

To change the gemfile.lock, edit your gemfile and run bundle

ya heard?

[darshecodes]

Regex

Regular expressions are at first a difficult concept to grasp, but once conquered can make searching, scanning, and replacing strings extremely simple. Rubular is a great tool to learn and check your regex. All Regex must be escaped by '/ /'

Here are some examples of Regex used to find social security numbers:

The methods I did not write like scan and match can be found in the String class

Here is the regex quick reference found in Rubular

[darshecodes]

MVC methods to programming

MVC = Model View Controller

This is a way of organizing code to make it easier to write, function and read. The controller relays information from the model to the view and vice versa. The examples I give are from  a program I wrote for a Dev Bootcamp challenge that is essentially a game of virtual flashcards.

The Model

The model's function is to carry the functions that make your code run. This is the part of your code that is the actual functioning part of the program. You could have the user input be your parameters for these functions.  

The View

The view is what is seen by the user. This could be what prints to the console, or even the HTML and CSS of your program. Whatever it may be, the view is how the user interacts with your program. So far many of the views I have created have contained many "puts" statements.

The controller

The controller calls upon the methods of the model and view in the specified order that you desire. It is the class or section of code that interacts with the others, so that communication does not need to be happening between all three sections all the time. This organizes the functions of your code to avoid confusion and ultimately a crash. 

[darshecodes]

WET and DRY code

the first thing I learned from Dev Bootcamp was to always try your best to implement DRY code...

Don't Repeat Yourself

as opposed to WET code...

We Enjoy Typing

The reason that repeating yourself in code is dangerous, is that it is much easier to make an error if you keep repeating yourself. It is also harder for others to read when they come into the code. The best way in my experience to solve this problem is to define the repeated code into a method, and call that method when necessary.

[darshecodes]

Class vs Instance Variables

ONCE AND FOR ALL LETS DEFINE THIS

class variable

When you set a class variable, you set it for the superclass and all of the subclasses.

class RoadSigns

@@sign = 'stop'

end

puts RoadSigns.sign #=> 'stop'

~~~~~~~~~~~~~~~~~~~

class TheseSigns < RoadSigns

@@sign = 'yield'

end

puts RoadSigns.sign #=> 'yield'

~~~~~~~~~~~~~~~~~~~~~

instance variables

an instance variable doesn't change the super classes or subclasses, it just changes the instance of the class

class RoadSigns

class << self; attr_accessor :sign end

@sign = 'stop'

end

puts Roadsigns.sign #=> 'stop'

---------------------------------------

class TheseSigns < RoadSigns

@sign = 'yield'

end

puts RoadSigns.sign #=> 'stop'

puts TheseSigns.sign #=> 'yield'

----------------------------------------

[darshecodes]

Naming Conventions

snake_case VS CamelCase

generally:

method_name

variable_name

ClassName

ModuleName

CONSTANT

[darshecodes]

Iterating through Basic Data Structures

The MOST basic are arrays, hashes and strings. Here is a lil cheat sheet!

(ordered list, accessible by index)

----------------------------------------------------------------

Hashes(unordered list, accessible by its Key or Value pair)

------------------------------------------------------------------

Strings(surrounded by quotes)

---------------------------------------------------------------------

AND REMEMBER!!

counting in ruby for indexes starts at 0, not 1. 

so if I have an array of 

this_array = ["cash", "rules", "everything", "around", "me"]

to access "cash", the index is 0

to access "everything" the index is 2

[darshecodes]

SQL queries

SQL is a relatively simple language(esp compared to ruby!) since it has just a page of set methods. This language has been around since the early 70s and is used to iterate through database tables, often that need to be JOINED via their attributes in order to find specific information. Here is an example to show syntax:

List all artist names alongside the titles of their albums, in alphabetical order by artist name:

SELECT artists.name, albums.title FROM artists

JOIN albums ON albums.artist_id = artists.id

ORDER BY artists.name

SQL interactive tutorial

[darshecodes]

SQL Schema Design

There is one thing I can say about SQL...it's tough.

The purpose of SQL is to provide a way to iterate through raw data tables and connected lists of data.

Being a visual person, my favorite part of SQL is creating the visual on a schema designer  because it lays out a way for me to understand how the specific attributes of the data are connecting. I will use an example that was a challenge at Dev Bootcamp today to illustrate how different data tables relate to each other. In this example, I am mapping out the data for students at a university who go to a section of their class. There were specific rules to abide by:

Classes have many sections

Sections have a start time and an end time

Sections can either be Monday/Wednesday/Friday or Tuesday/Thursday

Students can attend many classes and must be assigned to a specific section, but they can only attend one section per class

Students are given a grade per section

Teachers can teach multiple sections, but a section is taught by only one teacher

Classes belong to a single department, but a department has multiple classes

There are different types of relationships in schema design:

one to one

one to many

many to many

Can you see which relationships are which?

one grade per student for one  section

each class can only have one teacher, but a teacher can teach many classes

many students can take many classes

[darshecodes]

Recursion

 I made this image with the recursive drawing tool  to help me better understand the principles of recursion. A recursive method works by breaking itself up into subproblems, and those subproblems into even smaller problems, etc. Just like the circles and tiny squares call upon themselves in an endless loop in this image, so recursion does the same in code.

When you look at your own reflection in a mirror and there is another mirror behind you, what happens? You see yourself an infinite amount of times. That is real life recursion.  This could go on forever, which is why in order for recursion to help us solve problems in development we need to implement a base case.

A base case is the line of code that STOPS the recursion by directing your code out of that infinite loop. The recursion stops because it can no longer break itself into more subproblems, it has reached its most simple subproblem. When the base case is reached, the next part of the code is called and the answer is returned. Here, the base case is Line 2.

STEPS TO RECURSION

Simplifying method into sub problems until base case is reached,

then piecing together the sub-solutions until the initial solution is solved.

 RULES

1. A recursive algorithm must have a base case.

2. A recursive algorithm must change its state and move toward the base case.

3. A recursive algorithm must call itself, recursively.

source for code and diagrams

[harveyjames-deactivated20190122]

[darshecodes]

all hail the gembot and his tunes