w5d5 - var Wars: A New Scope

    Week 5 done! javaScript is getting a little easier to understand, this is becoming clearer everyday, and the scope of our understanding continues to get deeper, forming a closure on all the knowledge we've gained prior to this point, binding this to that. We ended this week by revisiting a couple of old favorites, Tic Tac Toe, and (for the 3rd time) Tower of Annoi (I mean Hanoi). This time, we built javaScript versions. Neither project took us too long to implement, as all of the logic was still the same, but it was interesting to see how differently Ruby and javaScript handled the user input. With Ruby, everything was a bit more straightforward, since the entire program pauses and waits for user input. With javaScript, you have to utilize callback functions to handle the user input, because the function that asks for input is asynchronous, and does not actually wait for the answer, it just continues on with the next set of instructions. This is where callbacks come in. You carefully set them up to be called back only when you need them, which in this case was after the user provides their input. Callbacks make it possible to do multiple things at once, which is extremely important when dealing with web applications.

    We also got our first real taste of debugging a web app, using the developer tools available in Chrome. It looks like it'll be a very powerful tool that can make debugging and finding issues a lot less painful. The console that comes with it gives you full access to any functions and variables that are in your running app, and you can even set up break points in your code to inspect your code at specific points. You can even directly edit and save your files, and see how those changes affect the live version of you application, so I'm sure we will be getting a ton of use out of that.

    Lastly, we got an official introduction to CSS at the end of class. I have a tiny bit of experience with HTML and CSS, from just playing around with them a few years ago. I have to admit that I was not a big fan of CSS back then, but since we've starting building actual apps in class, I've been looking forward to getting into the CSS portion of the curriculum. We will finally be able to add a little bit of color and style to the applications that we've been building, which is very exciting! Week 6, here we come!

w5d4 - Ruby, my one true love

    Oh Ruby, how I miss thee! Your simple methods... your casual nature... your descriptive variables and liberal underscores... the way you verbosely yell at me when I do something wrong... I took you for granted, and now you're gone! The only left to fill the void is javaScript...

    Sigh... The official first day of javaScript was a little rough. I thought I was ready after all of the CodeAcademy prep, but I'm still trying to get used to this fickle mistress of a computer language. It's jarringly littered with braces and semicolons, and I think the thing that bugs me the most, is how permissive it is. Unless you do something blatantly wrong, javaScript just sort of lets things happen and you're left to figure out where you went wrong. My favorite example is that javaScript has a value called NaN, which stands for "Not a Number". When it comes across some weird calculation, like 7/"chair", it doesn't throw any kind of error, it just assigns it the value NaN and continues on it's merry way. This might sound great, except for the fact that this will screw up any other calculations that may have depended on that value, turning EVERYTHING into NaN. Since there was no actual error, it can be difficult to backtrack through your code to see where things went awry. In the coming days, we'll be exposed to better debugging tools, which should prove to be immensely useful for seeing what is going on at any point of your JS program.

    Of course, it makes sense that JS is so lenient. The internet is basically built on JavaScript and it HAS to be very flexible to work so widely, so we will just have to deal with the quirks of JS as we go along, and hopefully get used to them. It does have some cool things that Ruby didn't (I hope Ruby isn't listening right now...), such as callbacks and asynchronous functions. Callbacks are basically functions that you can set up, specifically to be called later. It seems that these are typically used alongside Closures, which are functions defined within other functions, and they handle the local variables of the original function... or something like that, I'm still trying to nail down the concept. Asynchronous functions are pretty cool, and I'm looking forward to dealing with those more in depth. Things that are asynchronous don't hold up the rest of your program while they run. You can trigger one and continue running the rest of the program while the async function does it's own thing. The tricky thing is grabbing any useful information back, and I think that's where callbacks come in handy, but I'm not entirely sure. It will take some practice before I get used to these new concepts.

    Despite the rocky start, I'm still excited to go deeper into javaScript. The things that I mentioned above are of particular interest to me, and I see how they might be powerful tools in the arsenal of any developer.

w5d3 - Going off the Rails

    Rails, done! At least for now... I have a sneaking suspicion it will be back. I spent the first part of the day finishing up the Rails Lite project that we started yesterday. I was done pretty early, but I spent some time going back over older sections and trying to understand them a little better. I feel more comfortable now with all of the hocus pocus that Rails does for you, and I think once we get into more complex application development, it will be a huge help to have spent the last 2 days dissecting Rails the way we did. But, that's behind us for now, it time to move on the some JavaScript!

    It feels weird to just completely shift gears and deRail the Ruby train, but it makes sense. It's time to add on to that knowledge base with some good old fashioned, tried and true JavaScript. The first part of our prep was to do a tutorial from , CodeAcademy. I've used the site in the past, and in fact I used it to help me learn Ruby prior to starting App Academy, and I'm a big fan, but going through the beginner JavaScript material was pretty dull, almost torturous. I think that's partly a testament to how well I already know Ruby. There are a lot of shared concepts between the languages, and I'm sure I picked up on things a lot faster, solely because they were already very familiar concepts. Still, I know it won't be easy to just start writing JavaScript. There are certainly enough nuances to keep me on my toes. I even got stuck a few times doing the tutorials today because I kept trying to do "joe = Person.new(...)" (a la Ruby) instead of "joe = new Person(...)". It's the small things that are probably going to be the hardest to adjust to, but even so, I'm excited to see what new functionality JavaScript brings us.

w5d2 - All of the Lites

    Today we started tying up the Rails section of the curriculum with an assessment, aimed at testing our knowledge of putting together a basic web app. It mostly revolved around user authentication, and using sessions to handle logged in users. By now, I feel pretty comfortable with all of that, and the assessment went down without a fight. Once we were all done, we moved on to the last piece of the curriculum.

    The Rails curriculum started last week with learning SQL and then constructing a lite version of ActiveRecord, which gave us a glimpse at how Rails handles Models behind the scenes. It's only fitting that we end with trying to put together the rest of Rails, with Rails Lite. This entails trying to reconstruct the way that Views and Controllers function. Everything seems to be driven by the server, which sends down an HTTP Request and expects an HTTP Response. Rails takes that response, parses it in a way that make it useful to developers (we've mostly used the "params" method, which returns a hash of specific parameters that were included in the request), decides what process to hand it off to, and then sends back the final response. To me, this is probably the most magical part of Rails, and that makes it a bit harder to understand. There is a LOT going on under the hood, and it can get confusing pretty quickly, but I think by the end of the day tomorrow, I should have a pretty good handle on some of the black magic that Rails likes to practice.

w5d1 - The Chupacabra

Week 5 has begun and interestingly it seems to have started off a bit slow. We spent the day in pairs writing another web app. This time it was a goal tracking app. The purpose of it was for users to be able to sign up and enter goals for themselves. These goals could be public or private, and other users on the site could go to another users page and see a list of their public goals. Obviously, private goals were only visible to the owner. In addition, users could comment on other user’s goals, or on the actual user’s page. This gave us a chance to use polymorphic associations in conjunction with “concerns” to keep our code DRY.

This was all pretty straightforward after everything we worked on last week, but the twist was that we had to do it by implementing TDD: Test Driven Development. This means that instead of jumping right into coding the app, we had to write tests that described how our application should behave. The idea is that you write a test (or small series of tests, depending on how strictly you are adhering to TDD), then run the tests (which should all fail, typically shown in Red). Once the tests fail, you write the code to make your tests pass (typically shown in Green). Once you have passing tests, you can go back and optimize your code, running the tests as you go to make sure everything still works properly. This cycle is known as “Red, Green, Refactor.”

This was only the second time we’ve had to write our own tests, and this time we had to do it for a much more complex application. However, I found that it was a lot easier this time around, as the testing felt a lot more natural. Maybe it’s because we are that much better than we were when we first saw it. Maybe it’s because the suite we used, Capybara (or as I like to call it: Chupacabra), made Rspec easier to understand. Maybe it’s because we were doing integration testing rather than unit testing (testing functionality of the app rather than testing the implementation of specific pieces). It’s probably a combination of all of those, but it certainly wasn’t as bad as I thought it was going to be.

In some ways it made the development process easier, since our decisions about what to build next were always driven by the tests we wrote, which were themselves driven by the process of someone just using the app. What would they do? Where would they click? What should they be allowed to see and do? What shouldn’t they be allowed to see and do? When approached from this way, it forces you to break the process down into small pieces, which makes the whole thing easier to manage. Also, the fact that you have reliable tests for your app’s functionality gives you more confidence to make changes without fear of breaking something you hadn’t thought of. Of course, all of this means that the development process tends to be slower, and that can be frustrating when you feel like you already know what needs to be done. Also, you have to make sure you’re testing the right things and that your tests are written correctly, otherwise you may end up falsely relying on tests that don’t tell you what you might be missing.

Whether you love it or hate it, it seems like TDD is here to stay. You can’t escape the Chupacabra!

w4d5 - Reddit? I barely even know it!

    Week 4 done! We've officially been coding at App Academy for a month, and it's amazing to see how much we've learned since then. Today's project was to build a version of Reddit from the group up, and though it was surely a challenge, it's something that we were able to manage, which we could not have done even a few days earlier in the week. The rate at which we are learning somehow seems to be speeding up. I would not have believed you if you'd told me that at the end of Week 1. But here we are, 1/3 of the way into the program and running at full speed. We are at a point where we're starting to see how everything in Rails fits together nicely under the "MVC" architecture, and the past week was pretty much dedicated to getting familiar with the different pieces, as well as seeing how they all interact.

    The models represent the "M" in the holy trinity of the "MVC" application architecture, and they are probably the most straightforward of the three. They enable you to interact with the database on the backend of your application via an Object Oriented means. This abstracts much of the SQL querying that goes on beneath the surface. Working on the ActiveRecord Lite project last week gave us exposure to the way that this is actually done, and gave me a huge appreciation for the existence of ActiveRecord! It's easy to see how complex things could get if you had to interact with the database directly every time you needed access to the information.

    The other pieces of "MVC" are the Views and Controllers, which each come with their fair share of complexity. The Views are basically the web pages that your application uses, and from the client side are made up of HTML. In reality, producing these views requires some finesse, using Embedded Ruby (ERb), to dynamically generate the HTML before it gets sent to the server (and the client's browser). This has probably been my least favorite part of dealing with Rails so far. HTML just seems so clunky and we are tasked with shoehorning Ruby into it, in order to get results. I'm left wondering if things are going to get any cleaner when we start to incorporate Javascript, but I doubt it!

    Controllers, on the other hand have been fun to work with. They are one of the most "magical" parts of Rails, and they do a LOT behind the scenes with very minimal setup. But once you start understanding them, you start to realize just how powerful they can be. Controllers sit in the middle of every request to your application, and their job is to control things (big surprise). They give the Views information about the Model that helps generate the HTML. The take information passed from the View and give it to the Model to make changes in the database. They also control the level of access that clients have to any part of your application. In a nutshell, they receive a request from a clients browser (via the router built specifically for handing things off to the Controller), they decide how to handle the request, and when they're done, they tell the client's browser what to do next.

    Having knowledge of all of these pieces was a huge help for constructing a stripped down version of Reddit, which was our task on Friday (especially since neither myself nor my partner were Reddit pros). Once again, we had to build a user authentication system first, which wasn't too bad. We implemented the User model with the necessary fields for authentication, and it took us way less time than it did for either of the previous 2 projects. During User authentication, we also started tying together the Users Controller and the Views for the User pages. We worked in this sort of circular pattern for most of the day, creating a model, building it's associations to other models, building it's controller with the necessary actions, and then fleshing out the views which allowed us to see our hard work come to fruition. Doing things in this way, just seemed like a natural way to flow through the application, and it seemed like doing one thing just sort of led to the next, always giving us something to work towards. By the end of class, we had a working application that included Users, Subs (subreddits), Posts, and Comments. Later on, I went back and did some refactoring to optimize the rendering of nested comments, and also introduced a basic voting system where users could upvote or downvote individual posts or comments. To do this, I had to implement a Votes resource, using polymorphic associations so that both posts and comments were "votable".

    As we move into Week 5, I feel like we're capable of putting together pretty complete web apps, at least basic ones. Of course, we have not delved into CSS yet, which will enable us to add some style, and Javascript which will allow us to script some advanced functionality... but the basic knowledge is coming together, and the first half of this week will focus on solidifying that knowledge as we finish up Rails and move into the part of the curriculum focused on Javascript.

w4d4 - Band Aid

♫ Help! I need sombody!
♫ Help! Not just anybody!
♫ Help! I need some help with Raiilllllsssss

    Actually, today was pretty fun! We had a solo day, and we were tasked with building an app that would serve as a sort of music catalog. We started with dealing with user sign up and authentication. After our work yesterday, this wasn't too bad. It will definitely take some practice before it becomes second nature, but I felt like I knew what I was doing the whole time, and I generally had a good idea of what steps I needed to take in order to get the results I wanted.

    Once authentication was out of the way, it was time to add the meat of the app, which revolved around having resources for Bands, Albums and Tracks. Obviously they all needed to be associated properly, or the whole concept sort of falls apart. For the most part, I didn't have much trouble setting things up, but with Rails, there are so many little areas where you can get tripped up, that things are always tricky. I plugged away slowly and steadily, trying to avoid making any major mistakes, and it worked well for the most part. I was able to get that part done by the end of class.

    It was great seeing how everything fit together nicely, and the flow of the application was pretty slick, even though it looked like crap! The main page displayed a list of all bands in the database, with links to each bands detail page. I even added a text field next to the band link with a count of how many Albums they had. From the index, you could add new bands to the database by following the 'new_bands_url' link. On the band detail page, you could see all of the Albums for that Band, and any Tracks for those Albums nested underneath. All of these were also links that took you to their detail pages. You could also click a link to submit a new Album. On that screen, you had the ability to select any Band to add the album to, but the default value was the Band whose page you were just on. The Album detail page was similar, it had links to all of it's Tracks, and a link to add a new Track. Again, the new Track page defaulted to the Album you clicked from. Finally, there was the Track Detail page, which showed the name of the Band, the name of the Album, and listed out lyrics to the song (entered by users). There was a link to edit the track, where you could actually enter the lyrics.

    After class, most people stayed longer and tried to finish up. In this time, I was able to complete the next phase of the project, which was giving users the ability to add Notes to Track pages. Even better, they had the ability to delete notes, but only ones that they posted. Any actions they didn't have access to were not visible, and in case they tried anything sneaky, they were also prevented by the Controller itself, which automatically redirected any users without access to make the change.

    The last piece, I actually added from home, which was adding in the formatting of "ugly lyrics", as per our instructions. It wasn't too bad, but it was good practice for figuring out which pieces of code you need to escape (to avoid code injection attacks), and which pieces you need to make "html_safe", so that your page actually understands that it should be using it as valid html. To do this, I created a helper method that took the lyrics and split them into an array based on line breaks. For each line, I added a little note (♫) to the front and escaped out the actual text, pushing this into a new array. At the end, I just joined the new array together with new lines ("\n"), surrounded it in <pre> tags to preserves the formatting, and made the whole thing an html_safe string to generate my so called "ugly lyrics". I think they look pretty awesome! But maybe that's because it's the ONLY graphical element of the app (if you could even call it that!). I'm definitely looking forward to the point where we can add a little bit of style, but that is still probably a few days away... 

w4d3 - Everybody gets a cat!

    Today we finished creating our 99 Cats application that we started yesterday. Although it was completely silly, I'm very pleased with the results. You might look at it and think that we called it 99 Cats because it looks like it's from 1999, but all the function is there! Users can now sign up and log in, like a typical website! We utilized a session helper method in Rails to read, set and destroy cookies. And we used a session_token column in our users table to check whether or not a user was logged in. This also enabled us to check the current user pretty easily by comparing the session toke stored in the database to the token store in the users' cookies.

    Throughout the project, we were able to put together everything we've learned so far, creating new routes (generating only the ones we needed to use), linking those routes to controllers, setting up the actions in the controllers to render or redirect to the desired page, and we also got a lot of practice creating forms and buttons (which apparently have to be wrapped in forms to work correctly). We were even able to get buttons to appear and disappear based on user permissions. For example, only the cats' owner was allowed to Approve or Deny rental requests. Other users couldn't even see the buttons. In addition to that, we made sure to add checks into the controllers themselves to prevent a user with insufficient rights from making any changes they weren't authorized to make. Rails really makes things like that fairly easy to do once you know your way around a bit.

    There was a bunch of refactoring that we could have done to make the HTML cleaner. In particular, we could have used a couple more partials to DRY up the code in our views, but overall I was excited to see the application working as we wanted/expected it to. Tomorrow is actually a solo day where we get to build another app from the ground up, using everything that we've done in the past 2 days and hopefully creating something even better than the 99 (though that will be difficult!).

w4d2 - I got 99 problems but a Cat ain't one

    If you having Rails problems I feel bad for you son...

    We started building our first fully functional Rails app today. Pretty exciting! We're starting simple by building an application called "99 Cats", which is based on the site '99dresses'. I'll forgive you if you haven't heard of it, but it's basically a site where users could post their used dresses for sale for some sort of virtual currency, and then turn around and use that currency to purchase dresses from other users. Apparently it was pretty successful... but it's no longer around. Naturally, this idea also works great for Cats. The premise is slightly modified to the idea that users can post cats on the site, which are for rent, and then other users can logon and request to rent them for a period of time. Not absurd at all!

    We started by putting together the basic migrations to create tables to store our Cat data. Once we had our Cat table and some database level validations, we added some additional validations to the Cat model class to prevent the ability to save any cat with incomplete information. We then worked on the individual controller actions needed to handle the different requests: viewing all cats (index), viewing individual cats (show), creating new cats (new -> create), or editing existing cats (edit -> update). We slapped together some VERY basic html pages so that we could actually see our work, which allowed us to implement some HTML staples such as tables and forms.

    Once this was done we added a model for Cat Rentals, which is where we stored rental requests, along with a status of approved, denied or pending (the default). We added the required associations to the models and updated our routes for the new resource. One interesting thing that we had to figure out was that we needed to add routes for the controller to handle our "approve" and "deny" requests, which are buttons on an individual cats page (next to each potential rental request). These routes were mapped to controller actions, but the controller actions mapped back to existing pages. This was the first time that we had seen a route for a resource that didn't have a page associated to it. I'm starting to understand now how genius Rails' set up is, and I can see how you would easily be able to handle less concrete resources, e.g. "Likes", in a similar manner to any of your more standard resources like pictures and comments.

    Tomorrow will be Day 2 of 99 Cats, where we actually add in the user functionality, complete with sign in and authorizations. By the end of the day, we should have an application that will be pretty functional! With a little CSS styling and some investors, I think we might have a winner... We could corner the cat rental market!

w4d1 - Oh CRUD!

    Today we officially began our quest to master Rails. It seems like a daunting task, but every journey starts with just one step. We spent the latter part of last week preparing for the journey, and it seems to have paid off thus far.

    I thought today went pretty well and I’m beginning to understand Rails more and more each time I look at it. Today was all about setting up Routes and configuring controllers to handle those route requests. To do this we spent the day setting up a simple Contact Sharing API that was able to store a users contacts and then allowed the user to share those contacts with any other users. This project also introduced us to the concept of an API, which, from what I gather, is a very broadly used term. In this context, we were providing raw data (rendered as JSON objects) via specific routes that could be hooked into from a separate program. We learned that this is actually similar to the way that popular applications like Twitter and Tumblr handle API requests, which is what allows independent developers to build applications or web parts surrounding those elements.

    We also learned about the importance of designing with CRUD in mind. Create, Read, Update, Destroy. If you can design your sites resources using just these actions, then you should be able to produce a RESTful, (REpresentational State Transfer) application, which is all the rage these days. That basically means that the application should work in such a way that doesn’t expose the inner workings of itself to the client. A person interacts with their browser, the browser interacts with a web server, and the server takes care of everything and lets the browser know how to proceed. This isn’t the olden days anymore (like pre 2000!)

w3d5

  Week 3 done! And it did NOT go down without a fight. It was a sort of roller coaster of a week. It started with the universally despised SQLZoo, climbed to a high point on Wednesday and Thursday where we got to start experimenting with Rails and ActiveRecord and then plummetted back down to Earth as we ended the week trying to reconstruct ActiveRecord, at least partially. Even so, Active Record Lite was not so lite. It was definitely a difficult task, one that most of us did not complete by the end of the day… oh and did I mention that it was a SOLO day for everyone? That always ramps up the difficulty a few notches. I would have to say that this was the hardest day yet… BUT after all of this, I can now appreciate the beauty and elegance of Rails and ActiveRecord, and I feel like I have a deeper understanding of what might be going on under the hood, and THAT will inevitably make things easier to understand down the road hopefully…

  We were also introduced to the concept of metaprogramming, using the ability to Ruby to inspect itself to sort of redefine the things it can do dynamically. I’m sure that was a pretty fuzzy explanation, but hey, it;s a pretty fuzzy subject! Basically it allows your code to write it’s own code, which is a little mind blowing, right? I’m pretty sure it eventually leads to Skynet, but it’s fun to play around with for now, and seems like it’d be a pretty powerful tool to master. I think part of what made Active Record Lite so difficult was the fact that we had to utilize metaprogramming to get the results that we wanted, which isn’t easy when I only just learned about it the previous night. I’m sure it will all make more sense after using it some more, and maybe watching the Terminator movies a few more times.

  Today was also the last day for the students in the previous cohort. It was awesome seeing how far these guys (and gal!) got in 12 weeks, and I was able to see the kinds of things that I’ll be able to build pretty soon. At the same time, it feels like a long way off considering that we haven’t exactly tackled any major projects yet. I’m not saying that what we’ve done up to this point hasn’t been pretty cool, I mean we started 3 weeks ago with very little knowledge and are are a few short weeks away from being able to build functional web applications. I can feel us turning the corner as we dive head first into the Rails curriculum for the next 2 weeks.

  Towards the end of the day, App Academy held a “hiring day” where people from potential employers came and the graduating students could show off their Final projects. It also gave me a chance to talk to some of the grads, which is something we never really get an opportunity to do, considering we all spend most of our days buried in code. It was nice to get some perspective from students who were just where we were 9 weeks ago. It was also a good opportunity for our class to get to know each other better outside of normal class conditions. We even joked about what it would be like if WE also had to show our projects to the employers…

"Uh ok, first go the terminal and clone my repository from Github. Now type ‘g = Game.new… OK now type g.run… Oops, I guess it’s g.play. Oh there it goes! Oh wait, I forgot that you have to install a few gems first… Ok, now we’re ready, just type g.play! …no, sorry, there’s no cursor, just type in the commands… No, don’t type that, it’ll error out! …it’s pretty good right?!"

w3d4

class TumblrPost < ActiveRecord::Base
  validates presence: true

  belongs_to(
    :author,
    class_name: “User”,
    foreign_key: :author_id
    primary_key: :id
   )
end

class User < ActiveRecord::Base
  validates presence: true, uniqueness: true

  has_many(
    :posts,
    class_name: “TumblrPost”,
    foreign_key: :author_id,
    primary_key: :id
  )
end

  Today was all about associations. We also did some associations, and to end the day we finished up with a little bit of association creating. All in all, I’d say we’re getting pretty good at associations!

  Rails continues to be magic, but we are slowly learning how the Wizard works. Sometimes however, there are things that just make you scratch your head. Today we spent about 20 minutes trying to do something the “long way” by making associations, when we could have just chained a few methods together. We figured it would be good practice to do so. We ended up creating a ‘has_many :through’ association that went through another ‘has_many :through’ association. Well apparently, that’s when Rails stops doing things magically because we were unable to get the method to work properly. After calling the TA over, we found out that for some reason, when you chain two ‘has_many :through’ associations together, the association won’t work properly unless the record you are using is already saved in the database. So, even though we had methods that worked perfectly fine when used separately, they broke when we tried chaining them together. I’m sure those are the kind of things you learn over time, and might be able to make sense of at some point, but for now it just seems a little odd.

  It’s a good thing that we spent the last couple of days getting well acquainted with ActiveRecord, because tomorrow’s task is to build our own version of it, solo!

w3d3

Rails today! It was crazy seeing all the things that we manually constructed this week being automagically handled by Rails. It was pretty amazing. Today was mainly focused on getting used to how to do database migrations, and creating associations between models. This is going to be a crucial concept to master and today was a good start at getting our feet wet in the world of Rails and ActiveRecord

w3d2

SQL part II today… the sequel. It actually wasn’t that bad! Of course we all realize now that the awful SQL setup they had us working through the day before was partially to give us an appreciation for well written, properly set up databases and how much easier it is to query.

We worked on integrating SQL into Ruby today to build a database driven application and after the previous day, it was much easier to write and understand the SQL needed to do so. Looks like we’ll be moving right into Rails tomorrow and utilizing ActiveRecord to do most of our database querying. I’m definitely interested to find out how much more it will all make sense after having looked at a ton of SQL these past couple of days

w3d1

Week 3 begins with SQL… Not the most glamorous of languages, but functional nonetheless. I can’t say that I enjoyed diving into it and trying to do multiple joins and subqueries to return data that would have been pretty easy to get otherwise, but I’m looking forward to seeing how we are going to implement it into our programs.

w2d5

Week 2 done! This week was all about getting comfortable using classes to build our projects, and after building checkers, chess and poker, I can say that I have a much better understanding today than I did when the week started.

We also dedicated today to writing our own testing specs using rspec, which I did not find fun at all. However, I do see the utility of using them and I know that it will be important to get very familiar with them, which I plan on doing

w2d4

Tackled Checkers today as a solo project. Taking a cue from our work on the Chess project, I decided to get a basic gui implemented first. Again, I think it helped a lot to introduce that part first and then revisit it later once the game mechanics have been fleshed out. I was very pleased with the way my game turned out, it included all the basic rules of checkers, and I implemented a lot of error raising/rescuing which helped speed up the development process.

w2d3

We finished up our chess project today, compete with super fancy graphics, using a little assistance from a gem called colorize. Catching all of the possible errors took longer than expected, but by the end of the day we had a pretty decent looking chess game with all the right logic.

After looking at the solution, I see a lot of areas that our code could have been improved. For one, we ended up putting everything in one file, which definitely made finding things a pain. Lesson learned!

w2d2

We built a (mostly) working chess prototype today, laying the groundwork to finish it tomorrow. We actually built it “backwards”, designing our rendering system to output the game closer to the beginning. Doing it that way made it feel more concrete and actually made our testing easier, since we were able to visually check if something worked rather than having to rely solely on error messages and finding functionality quirks (which we still saw plenty of!). We also spent some time refactoring some of the messier parts of our code, abstracting a lot of pieces into their own methods and trying to keep the program flow clean and DRY. tomorrow we will work on finishing up the game mechanics and polishing the user interface.

w2d1

Today’s challenge was to recreate a command line version of minesweeper. After everything we did last week, it didn’t feel too tough and we ended up finishing the core functionality with time to spare. there was definitely room to refactor and make improvements on our code, but we didn’t have quite enough time to get to that. We were also able to implement YAML, which let us save an instance of the board that could be reloaded later, which was pretty cool.