Last Seen Blogs
supermaaad
moood & dsgn
buggyspot
b u g g y s p o t
lockon5
portrait
caldernews
News&Edits
survivorsolomonislands
Tumblr Survivor: Solomon Islands
Text
w5d1
Today was the first day I really felt comfortable with rolling our own authentication. I'm really starting to understand the MVC model.
The input fields in our views templates are responsible for giving us all the information we need about a user. This is passed to the controller which uses our model to create a user object. The model is then saved to the database (each of its attributes being columns).
We'be been told that we would never implement our own authentication checks (because there are plenty of open source security suites that offer far better protection) but it has great utility as a learning tool.
1 note
·
View note
Text
w4d3
Today we home rolled our own authentication pattern. This is something that we would never ever attempt to do in the real world, but it was a great learning experience. I'm not sure I understand it all yet, but I'm pretty sure we're implementing it two more times this week.
0 notes
Text
w4d2
Today we built a cat rental website a la 99dresses. A couple things we got hung up on: -Spent way to much time trying to get our forms to re-render with the info users had already entered. This was harder to do with select boxes and radio buttons. -We had a really hard time dealing with the logic that didn't allow for overlapping cat rentals.
Overall, I feel like I am gaining a much better understanding of rails. The MVC(Models, Views, Controllers) scheme is starting to make much more sense.
The models are responsible for creating the framework for a user or a cat_rental. The controller is responsible for client/server interaction. It delegates to the views template to render what the client will see.
0 notes
Text
w4d1
Getting a rails site up and running is getting easier and easier. I guess I should qualify that a little bit. We haven't really made a full blown website yet, but the parts are all starting to coalesce.
0 notes
Text
w3d5
Today we built our own version of active record. It was a solo project. I definitely struggled a bit, but I feel like have a much better understanding of what's going on under the hood in rails now.
0 notes
Text
w3d4
Today we created a polling app that would take answers from users to various questions. The trickiest part was getting it to validate for uniqueness (making sure that no user answered more than once for each question). This was done by checking all of the answers given so far and making sure that the user who gave each of those answers is not the current user. It doesn't sound too difficult, but it was in practice.
0 notes
Text
w3d3
We started Rails today. I found it fairly confusing. It extracts away a lot of things from SQL. The way we join table is done more implicitly by a many to one relationship that we specify in the classes. If a post belongs_to a User, we join the table where the foreign key from posts matches with the user id. This is similar to SQL, but rather than calling is explicity with post.user_id = user.id, we just specify that each User has_many posts and each post belongs_to a User.
0 notes
Text
w3d2
Today we created our own implementation of an ORM (Object Relational Mapping). Basically, the idea is to get the best from both Ruby and SQL. We get the power of SQL databases with the ease of use of Ruby code.
0 notes
Text
w3d1
Today was a tough day. I failed my first assessment. We were supposed to build a shell version of free cell. I made a few stupid mistakes and couldn't get it working in the hour allotted.
We are starting off the databases section this week. Here's to a fresh start!
0 notes
Text
w2d5
Today we continued our work on optimization. At the center of any optimization problem is a concept called big O. The idea is to break different algorithms down into separate families of functions where the input size is the independent variable and the time it takes the program to execute is the dependent variable. Big O is a measure of this ratio.
The holy grail is for an algorithm to run in what is called 'constant time'. This means that regardless of input size the algorithm runs in a fixed length of time. This seemed like an impossible task to me when I first heard of it, but we set out today building something that does just that.
This thing is an LRU cache. LRU = Least Recently Used. A cache's purpose is to store values of calculations that have already been run so that they need not be run again. It would be wonderful if we could store all the calculations we have already run, but limited memory doesn't allow for this possibility, so we need to have a way of deciding which results are least likely to be needed again.
An LRU cache operates on the premise that the things that have been used most recently are more likely to be used again. It was explained to me like this: Imagine you are playing Super Mario Bros. The original one that came with duck hunt. Mario runs along and clouds pass over his head and he jumps over pipes and slams his head into those floating brick boxes that for some inexplicable reason produce coins. We want all of these things to persist if Mario decides to run backwards on the screen so that we don't have to rerender everything (itself a process that slows things down). The player is more likely to run backwards just a few frames, so the old school Nintendo stores the objects in the frames immediately proceeding the player.
0 notes
Text
w2d4
Today's work was all about optimization. Different data structures and different algorithms can vastly improve how efficiently our programs run.
0 notes
Text
w2d3
Today's focus was on RSpec. There is a movement within the software development community to create an entire suite of tests before writing a single line of code. I have been sceptical of this idea since I first read about it a few months ago. To me, one of the most appealing aspects of this whole process is the creativity one gets to employ when solving complicated problems. Why would you want to limit yourself by writing tests? Why don't we just allow the muses to take over?
It turns out the answer is that we humans are stupid, stupid creatures. Getting just a few classes to interact when we create a game as simple as chess is a confusing process. I cannot yet imagine what must go in to some of the things that are being created today. Writing a suite of tests before hands assures that the logic of our programs lives in the right place. This reduces codependency in our code and makes it more receptive to change and less susceptible to errors.
0 notes
Text
w2d2
We finished our Chess game with everything but the pawns in working order. With the unicode chess pieces, it looks pretty good, although the red and blue board is horrendous.
0 notes
Text
w2d1
After today's assessment we set out to build a working chess program. Hurdles included: Getting the board to re-render only when the cursor had been moved, nailing down the move logic for all the different pieces, and creating an "empty piece" class that would allow us to render the board with all of its squares but not get in the way of the movement of the other pieces.
Of these, the movement of the pieces was the trickiest. We ended the day with our pieces unable to move. The first hurdle was limiting the direction that the sliding pieces are able to move (diagonally for bishops, horizontal and vertical for rooks, and both for the queen). Once this was done, it seemed like we need only check to make sure the square we wished to land in was empty. Unfortunately, we also have to check for any pieces impeding this path.
On to day 2!
0 notes
Text
w1d5
Today the name of the game was Abstract Data Types. We used trees to build a tic-tac-toe AI that can't be beaten.
The weirdest thing about these trees is that they don't really exist as a structure in themselves. Each tree consists of 'nodes' that keep track of their parent and their own children.
Unlike a physical tree, which exists as a united whole, these data trees exist only in the memories of their nodes. It's like a family tree. We only know our lineage as far back as people have kept it documented. If we don't give these nodes methods through which they can access their parents, it is impossible to find the root of the tree.
0 notes
Text
w1d4
Today was the most successful day so far. Asher gave a great lecture about finding bugs efficiently. The average programmer wastes about six weeks a year debugging less efficiently than they should (assuming three minutes per bug). I'm sure if I continue on at the I have been debugging it will be more like six months!
We were given a zip file with an intentionally bug ridden sudoku game and tasked with getting it two work again. There were twelve levels two it, beginning with fairly minor bugs and progressing to bugs that were spread across several classes.
Our next project was creating a command line version of minesweeper. The most interesting part of this was getting the map to open up when you click on a a square that is surrounded by many empty squares. We had do use recursion to get all of the surrounding squares to act like they had also been clicked if they were also surrounded by zero bombs.
0 notes