What I Did

1. Attended six distinct meetings (each about an hour long)
   • Intern Project Meeting: Design Exploration
   • Intern Project Meeting: Key Site Components
   • Intern Project Meeting: Colonel Kurtz Integration
   • Client App Monthly Meeting: Real time live preview updates using iframes.
   • Orientation Meeting: Business Development
   • Scram Challenge Meeting: Remote 1:1 Informal Conversation with Saad.
2. I spent the little development time I had today to refactoring my models and controllers, which both actually have much more additional work to do.
3. I attended a very awesome Coding Night organized by the Boulder Ruby Meetup Group and hosted by the folks at MojoTech. The meeting provided a Vegan pizza option, which made me very happy along with an informal and dynamic meeting space that encouraged collaboration and assistance with whatever work one has at hand.

What I Learned

Note: The things that I learn in a given day are due to Viget developers, the Internet, people with Startup Colorado, people at external events like tonight’s Ruby coding night today.

1. One should be wary not to congest models with bloat. That is, models should contain mostly just business logic. It is helpful to counteract bloat with helpers or external classes (PORO’s) to separate out code better, effectively allowing for code to be better tested as well.
2. REST is an architectural style and approach to communications that is preferred for the development of web services. Here are some of REST’s advantages
   • easy to leverage by most tools
   • easy to scale
   • mild learning curve
   • smaller message format than SOAP
   • designed for the Web
3. Ruby was initially intended to by its developer(s) to be a fun language to develop in rather than necessarily the most efficient one.
4. Apparently, there is a ruby gem that allows for programming in emojis. Also, emojis are apparently a serious subject for some companies in which they have rather standardized and meaningful implications.
5. One should certainly strive for modular code, but one should not write methods that essentially contain one-liners that will never be duplicated anywhere…which was what I was doing at many points.
6. Implicit return values in Ruby methods have to be carefully dealt with sometimes in the contexts in which they are returned to.
7. There are so many ways to accomplish the same micro tasks in a Rails app (and all apps in general). I’ve only recently begun to appreciate the art that lies behind development that the untrained mind simply glosses over. That is, the ratio of art to science in development is closer to 1:1 than one initially guess at.
8. Code should be as self-documenting as possible. Method names, parameter names, method calls, etc. should be very clear at all times, so that necessity of documentation and commenting is diminished.
9. If a given block within a controller action is incomplete, Rails will attempt to render a view that would theoretically be associated with said controller action, raising an exception if that view simply does not exist.
10. Update_attributes is preferable to simple assignment and update_attribute because it automatically saves to the database and runs model validations.
11. The params hash is generated from the URL of a browser request.
12. Certain helper classes should be name spaced to reference the class that its functionality seeks to enhance.

What I Still Don’t Understand

1. Exactly what the structure of database files are like and how a database management system like PostgreSQL interacts with said database using SQL.

What I’m Interested in Learning

1. When, where, and how most effectively to use pry in order to debug code.