This tutorial will help guide you through the process of setting up a new Ruby on Rails project with robust testing capabilities. This tutorial makes a couple of assumptions:
| We just completed a two week sprint where we focused on additional feature build out of www.thumbtack.com, refining the user experience, and creation of various API endpoints that contained sales/marketing data. One particular element that I tasked myself with was the creation of previously mentioned API data as well as the locking down of access to our various APIs. Yak shaving was ever present in this endeavour. | |
| After a few flase starts I came upon the Blazer gem that I was very quickly able to get up and running. Three to four lines of code in three different files, a migration and -*viola*- a browser-GUI SQL sandbox to play around in. Tinkering around with this I was able to slowly build out my queries by continually appending more filtration. At first it was plug and play guessing but by the third data set things were moving much faster. Will be using blazer again in the future. As a side note, there is a terminal command for accessing a postgresql console, much like the rails console, attempts t |
| Module 4 Goals | |
| List your longterm goal(s) of what you want to accomplish by the end of module 4 | |
| be armed with a capstone project and confidence that will allow me to feel strong about my job selection process | |
| Strategy To Achieve Goals: | |
| Not daley on tangential work but focus only on that knowledge which is needed to build out the app sufficiently | |
| Start liining up emails for coffee meet ups with trello board peeps. Start to do casual feelers about what's out there and who i might want to work for. Boss shopping, and i like high quality. |
| # This is a skeleton for testing models including examples of validations, callbacks, | |
| # scopes, instance & class methods, associations, and more. | |
| # Pick and choose what you want, as all models don't NEED to be tested at this depth. | |
| # | |
| # I'm always eager to hear new tips & suggestions as I'm still new to testing, | |
| # so if you have any, please share! | |
| # | |
| # @kyletcarlson | |
| # | |
| # This skeleton also assumes you're using the following gems: |
| Let's say tech executives (consciously or subconsciously) seek teams in which at least 1/3 of team members are like them (gender, age, race). How will this impact the types of jobs available? | |
| **Whitey mc whitey ville ** | |
| Diversity "quotas" are sometimes dismissed as counter-productive or missing the point of actually valuing diversity. PotP does demonstrate how they may add some value. What are your attitudes toward diversity quotas; does this game change your assumptions? | |
| **recent effort made by (blanking on local tech company) to strive for parity has raised their dev team numbers to 34% women, simply because it was a stated goal | |
| having been to tech meetups where EVERYONE is a white dude, that creeps me out. diversity please | |
| especially after my turing experience or my squads when coaching or the camps i've run. These were always 1/4 to 1/3 women, so why not in the tech world? And why not more? ** |
Guiding Questions to Define The Relationship:
Time/schedule: Craig - stay till 7 in the evening at school on weekdays 1 life day on the weekend
Seth - Saturday extended commiment away from keyboard
Nick - apartment hunting as it comes up
#Guiding Questions to Define The Relationship: What are your learning goals for this project? Brandon: single responsibility controllers (test for it) Use ActiveRecord for biz intelligence (utilizing methods and SQL queries Mark: not die blend familiarity of ORM and tables and their intertwining relationships
What is your collaboration style? How do you feel about pair programming vs. divide-and-conquer approaches? Brandon: screenhero Mark: gone WED 4p to due time (not available)
Blog of 13+ years is all racing/coaching focused... i've yet to start one up that's more code/professional-interest focused... till that time i'll have this live here.
Progressing from Sinatra to Rails was a bit tricky for me. There was an ordered simplicity to both the build out process and functionality Sinatra provides you that when stepping up to Rails my head started to spin a bit. With Sinatra and the CRUD process everything is quite literal and straight forward. You are in control of assigning processes (routes/actions/controllers/etc) and tend to remain fairly aware of what you've built because you've basically been doing it by hand from scratch. Furthermore, database integration (as far as we have used it in this framework) is light and fluffy. Not a whole lot of intertwining of tables. While you get a little bit of an intro to ActiveRecord you do have the ability (oops) of completely bypassing it (NOT recommended) and querying the database with ruby methods (super slow, BAD idea). Moving
Mastery: student is able to explain and implement the concept independently or with light reference
Functional: student recognizes when to use the concept and can implement it with the support of documentation and/or a collaborator
Familiarity: student can recognize and describe the concept when needed/appropriate, but is not able to implement the technology/technique
Project Management & Professional Skills
Fam - familiarity