- Learn the tools required to actually build websites
- Become comfortable with SQL and databases
- Get better at CSS and HTML
- Start hardware posse
- Write some blog posts
- A: End-of-Module Assessment: X
- B: Individual Work & Projects: X
- C: Group Work & Projects: X
- D: Professional Skills: X
- E: Feedback & Community Participation: X
- Conceptual Understanding
- 4: Developer is able to describe concepts with a high degree of specificity and accuracy without assistance
- Analytic/Algorithmic Thinking
- 4: Developer independently breaks complex processes into logical sequences of small steps and validates progress along the way
- Feature Completeness
- 4: Developer is able to finish all prescribed functionality, refactor and have all passing tests
- ActiveRecord Syntax and Style
- 4: Developer is able to establish and utilize ActiveRecord methods independently and can articulately discuss the difference between relationships at the model and database level
- Rails Style
- 3: Developer generally writes clean Rails features that make smart use of Ruby, with some struggles in pushing logic down the stack
- Testing
- 4: Developer understands errors produced by tests, and uses them to drive development independently
- Collaboration
- 4: Developer actively seeks collaboration both before implementing, while in motion, and when stuck
Job tracker is a personal job organizational app. I build it to specifications and then had fun clicking through and changing things around to make it more user friendly. I learned a lot about following convention.
- Database, Relationships, and Migrations
- 4: The database has appropriate tables and appropriate columns to create relationships between tables. Foreign keys are indexed to increase database performance. Tables and columns are appropriately named.
- Routes
- 3: The developer has routes for all functionality that they provide, but may include routes that are not used in the application.
- Controllers
- 3: Some logic may leak into the controllers that would more appropriately exist in a model/PORO. The developer may pass more instance variables than necessary to the view.
- ActiveRecord
- 4: ActiveRecord methods are used in models to supply all appropriate functionality. Methods exist on the appropriate model, and developers are not referencing other classes or self in models unnecessarily. Ruby enumerables are not used where ActiveRecord methods could provide the necessary functionality. The developer can explain the ActiveRecord methods they used and the relationships between ActiveRecord models.
- Views
- 3: Limited logic that could be moved elsewhere remains in the views and/or controllers and developers are able to identify potentially opportunities to refactor.
- User Experience
- 4: The application has been styled and the user can easily navigate between different portions of the application without manually entering the URL into the nav-bar or using the back button on their browser.
- Testing
- 3: Project has a running test suite that tests and multiple levels but fails to cover some features
Mix Master is a tutorial that re-enforced RESTful conventions in rails. I greatly improved my test writing / factory girls skills in this project.
I got a little carried away with this project and tried to make a game for our cohort to play. It was actually pretty fun for a day. No one won the burrito grand prize. I learned about cookies and user authentication / authorization on this project.
Rush hour was a project built with Sinatra and Active Record to record web traffic. The simplicity of Sinatra allowed us to gain a solid understanding of MVC before moving into rails.
- Functional Expectations
- 3: Application fulfills base expectations
- Test-Driven Development
- 3: Application is well tested but does not balance isolation and integration/feature tests
- Encapsulation / Breaking Logic into Components
- 3: Application effectively breaks logical components apart but breaks the principle of SRP
- Fundamental Ruby & Style
- 3: Application shows strong effort towards organization, content, and refactoring
- Sinatra / Web and Business Logic
- 3: Application makes good use of Sinatra but has some mixing of the web and business logic.
- View Layer
- 4: Application expertly breaks components out to view partials and makes use of both built-in and custom-written view helpers.
Working with Joey was great. His calm, collected way of approaching problems meant that we were able to move through Rush Hour at a consistent pace, and I never felt rushed or as though we were running out of time. He is a skilled programmer and his use of .reduce deserves a particular shout out - saving us both time and lines of code. My only critical feedback would be to suggest that he not allow this skill to get in the way: sometimes the solution to a problem is the simplest possible thing, and looking for a complex solution only leads to going in circles. That being said his understated, relaxed approach to even the most ridiculous problems is a definite asset to a team, and I look forward to working with him again in the future.
RushHour was an ambitious project and I consider myself fortunate to have been on Joey’s team. Not only did he live up to his reputation as the “.reduce ninja” with his impressive enumeration skills, but he was also amazingly able to quickly find solutions in the code when we were stuck on a particularly nasty error or failure. Even when he was a few steps ahead in his thinking, Joey was always willing to take the time to patiently explain his solution until everyone understood and was on the same page. Both in terms of his coding skills and his interpersonal skills, Joey will be an extremely valuable team member wherever he ends up in his professional career. I expect he’ll do big things.
Little shop is a full on e-commerce app. My favorite part was learning the git workflow in a big team scenario. Our "pick a card and solve it" approach made me excited to be a developer.
The most valuable part of this Gear Up was the Citizens Bill of Responsibilities. I do believe that with rights, come responsibilities, but I also feel that no one has the right to tell you what these responsibilities are. You need to determine that for yourself.
I fall right in the middle of introverted and extroverted. I've come out of my shell this module and have generally been outgoing, but when the weekend comes, my battery is drained and I haven't been hanging out with friends as much as before Turing. This gear up made introverts out to be the victims in many social situations. I hadn't thought about it that way before. It's certainly important to be conscience of other peoples social batteries.
Resilience is an interesting thing. We talked about it as refusing to make yourself the victim. It's really hard to influence someone else to be resilient without sounding unempathetic. The best way to spread resilience is to lead by example.
- ChatLingual
- Lucas Dikey https://www.linkedin.com/in/lucasdickey
- Weave
- Christian Nitu @ChristianNitu
- Distillery Solutions
- Jason Lippa https://www.linkedin.com/in/jason-lippa-044aa13a
- RedJade
- Joey Crone @joeycrone
- Baker Technologies
- Roger Obando https://www.linkedin.com/in/rogerobando
Hey Jason,
I'm a software developer in Devner and I'm interested in the work you're doing at Distillery Solutions. As a former distiller, I have firm understanding of the need for software to make daily distillery operations run smoothly. I'd love to learn more about how your team is meeting this challenge.
Are you available for coffee at this place and time?
Cheers, Joey
I learned a lot about git workflow in a team setting this module. On both Rush Hour and Little Shop, we used waffle to layout issues that needed addressed. This was especially useful in Little Shop and we were able to break up the work very effectively. Next time I'm working in a group setting, I'd like to have some sort of code style guide. When a lot of people are contributing to a project, the codebase can quickly become messy. I think we can prevent this by laying out some sort of guide in the beginning.
My biggest weakness in group scenarios is my tendency to become fixated on an issue and chase it down a rabbit hole. This wasn't an issue in Little Shop, but it's important for me to be aware of this in the future. It could be a problem if the rest of my team felt like they were carrying to much weight in terms of base requirements. So far that hasn't happened.
David, we described you as our project anchor. We could always count on you to be on track when Noah and I were starting to lose attention. I often found myself going "uhhhhhhhh..." and you would break me out of that by telling me what to type. This contributed greatly to the overall smoothness of our project. Attention is a major area of weakness for me, so it's great to have someone on the team who can fill that gap. My only criticism for you is that I think you should try to do more driving. I'd suggest dedicating some time to mastering keyboard shortcuts.
Noah, I was really impressed with your ability on this project and learned a lot from you in serveral different areas. Your workflow is top notch and your willingness to throw yourself at new (js, frontend) problems is inspiring. As far as criticism, you may want to try to stay focused on spec related problems before you dive into things that you're just personally interested in. It wasn't a problem on this project (actually i think it made it more fun) but keep that in mind as projects get more challenging.
Joey was an awesome addition to our littleshop team. I don't think we would have been able to pull off any of the cool search bar and password functionality if it wasn't for you willing to dive into some JavaScript. Pairing with you was great as I learned a lot and I can clearly see why your code and understanding is so strong. My only suggestion would be when pairing with someone (since you have the answer first 99% of the time) to check in with the other person to make sure they understand the code just as clearly. Other then that working with you was a pleasure and would love to paired up again! - Anthony
Joey is an amazing partner to work with. His ability to quickly, and efficiently complete any task that is handed to him is amazing. Every day he would come in with some new functionality that was well thought out and executed beautifully. He did a fantastic job of integrating JavaScript into the project to get added functionality. This addition made our Little Shop so much more professional and something that I am excited to show people. I would be thrilled to have Joey as a partner again either in Turing or in the work force. - Ben
I appreciated working with you on Little Shop. I am often in awe of your ability to research and devise solutions to problems on your own. You set the bar for quickly consuming new languages and tools. I agree with your assessment that we share a penchant to get fixated on issues. My one piece critical feedback is to be cognizant of that trait in yourself (you already are) and know how long you can burn on an individual issue. And I think while that trait can be spun as a negative, it is also one of your greatest strengths. Again, it was a pleasure working on the same group in this project. I learned a lot from you throughout and would be thrilled with any chance to work together in the future. - Ryan
I've participated in Miyamoto including leading a Friday Spike session on building a retropie. Next Module, Jeff Duke and I are co-leading a hardware posse.
The posse experiece has been a way to meet people and have fun and can also be a support system. I tend to ask senior posse members technical questions before anyone else. The best part of posses is that it gives you a chance to meet students in frontend and other mods.
( Leave blanks for reviewers )
( Leave blanks for reviewers )