Table of Contents:
Last active
August 29, 2015 13:57
-
-
Save davidcelis/9395704 to your computer and use it in GitHub Desktop.
Conference notes for Ruby on Ales 4
We think Object Oriented Programming is hard because of the code we end up writing. We create chaos; big classes, methods, applications... Want better apps?
Make smaller things.
Squint test:
- Squint your eyes, lean back, and look at the code.
- Look for changes in shape and changes in color.
- Changes in shape mean nested conditionals.
- Changes in color mean your code doesn't have the same leve of abstraction
Enter the Gilded Rose Kata and Sandi's tests
Create new empty methods based on what you think is going on, and call them instead of entering the big conditionals. See your tests not fail. Move code out of the huge conditional blocks into methods until your tests pass. Now refactor the nested conditionals to be sane and readable.
If you end up with methods that represent very similar algorithms, you might be tempted to remove the duplication, but wait until you've finished your refactoring. The code ended up having huge nested conditionals because people were looking for an asbtraction and found the wrong one. However, duplication is far cheaper than the wrong abstraction! You are allowed to wait for more information.
We teach people DRY as one of the first code principles, but only because it's one of the first things we can understand. So it's better to first abstract out your methods before looking for duplication to fix.
So why do we end up writing code this way?
- We feel that we need to write code similar to the existing code in the codebase.
- It's scary to do if you don't have good tests.
- If you can't see far enough ahead to see that you will end up with better code, you give up. You need to have faith that the intermediate complexity added during refactoring will go away.
If you have a class that only delegates methods to associated objects, you have a code smell called the "middleman class".
Inheritance is not evil when your hierarchy is shallow and narrow, when the subclasses use all of the superclass, and when the hierarchy is a leaf node in your application's object graph.
Better Living through ADHD (Ben Bleything)
Hey he has a terrible memory like me! What was I writing about again?
ADHD: Attention-Deficit/Hyperactivity Disorder
- Predominantly inattentive presentation
- Predominantly hyperactive/impulsive presentation
- Combined presentation
Inattention symptoms:
[ ] Often fails to give close attention to details or makes careless mistakes [x] Often has difficulty sustaining attention in tasks or play [x] Often does not seem to listen when spoken directly to [ ] Often does not follow through on instructions and fails to finish work [x] Often has difficult organizing tasks and activities [ ] Often avoids, dislikes, or is reluctant to engage in tasks that require sustained mental energy [ ] Often loses things necessary for tasks or activities [ ] Is often easily distracted by external stimuli [x] Is often forgetful in daily activities
Hyperactivity symptoms:
[x] Often fidgets with or taps hands or feet or squirms in seat [ ] Often leaves seat in situations when remaining seated is expected [ ] Often runs about or climbs in situations where it is inappropriate [ ] Often unable to play or engage in leisure activities quietly [ ] Is often "on the go", acting as if "driven by a motor" [ ] Often talks excessively [ ] Often blurts out an answer before a question has been completed [ ] Often has difficulty waiting his or her turn [ ] Often interrupts or intrudes upon others.
Morning exercise can really help manage focus. I should seriously bike to work all the time and see if it helps improve my own focus and memory.
Distributed systems are where you have a system that can't fit on a single computer. A property of distributed systems is that they are always broken.
- Consistency
- Availability
- Partition Tolerance
You can only have two, but if it's distributed, you have to pick partition tolerance. Lose consistency or availability during partitioning.
Unavailability: Twitter would rather you be unable to sign up than to steal someone's username.
Inconsistency: YouTube would rather correctly record likes/dislikes, and display inconsistent view counts that eventually become correct
You're already distributed: Web <==> Rails <==> Database
Easy thing to do here: put as much business logic into your database as possible.
Take a User class for example. It provides a lot of services: uploading profile images, sending welcome emails and other notifications, validating username uniqueness, etc. You could keep growing that model, or keep breaking up that model, but you want to extract parts of the model into services with their own databases.
The most logical path to follow is to extract storage of different things into different services. e.g. separate your tweet storage from your user profile storage.
Services will need to communicate with each other, so you must document your protocols.
- Smaller, incremental deployments
- Service tests
- Keep writing Unit tests
- Write service tests to make sure the entire service runs as expected
- Acceptance tests (instrument parts, and deploy to a part of your userbase)
- Deploy the new version of a method/service along with the old version
- Have requests run the logic for both, but only return the old version
- Record whether or not the new version returned something different
Make smarter clients, which many of us are already doing. Turbolinks is built into Rails, we have Ember, Backbone, etc.
Offline strategies:
- Operational transform: allow clients to get real-time updates based on what their doing but also what everybody else is doing.
- Git
- Vesper: make sure the offline client (iOS app) can make changes independently, merge stuff into the server if it makes sense, and try not to lose data. Users would rather have duplicated data than no data at all.
Decade of Regression (Randall Thomas)
The line is the Universal Statistical Hammer (USH). You are always dealing with lines.
- What happened? (descriptive statistics)
- What could happen? (predictive statistics)
Third (really hard) question: What is happening? (descriptive-predictive statistics)
One big happy family of techniques for describing a lot of other techniques in a statistician's toolbox that tell us roughly how all of the data points relate
- Computer friendly
- Simple to draw pictures
- Perfect place to start
- We know we have some data, how does it relate?
- Look at the data and connect the dots; extrapolate
- Try to draw a line that hits as many of the points as possible
But very few things in real life end up running in a straight line
Data sets can always be incomplete, so all we can do is try to draw the best line given the data we actually have.
Create a learned model from a true model:
- Draw a line
- Spatter points around it randomly
- Generate a new line using those points and the distance model
Except we actually start at point 3, because we never really know the true model.
Homebrewing: Simple as Ruby (jasonrclark)
Why brew beer when there are professionals brewing beer for us? Likewise, why write new operating systems? Why write new programming languages? Why write new web servers? Someone else has already done these things. However, there is a lot to be gained from doing something yourself: experience, and the joy of your own output.
- Water
- Malt (the main flavor of your beer, comparable to Ruby engine)
- Grains, usually roasted or toasted (flavor additives, comparable to Ruby gems)
- Hops
- Yeast
- Sanitation (or the yeast will die and mess up the flavor of the beer)
- Put grains into a grain bag and boil into water up to around 180°F. Then, pour in the malt while stirring.
- Add hops and continue boiling
- After boiling for a while, cool the wort down to 80° so you can add the yeast
- Put into primary fermentation and let the yeast work. It will bubble as fast as once every 1-5 seconds.
- Put into secondary fermentation after a while, typically when bubbling only once every minute or so
- Bottling time:
- Sanitize your bottles using heat
- Prime the wort with a bit more sugar
- Move the beer into a bottling bucket and draw into bottles. Cap, and wait a couple weeks.
More Code, Fewer Pixels (Cameron Daigle)
User-centered Design:
- Analysis
- IA, UI, UX
- Design
- Implement
- Deploy
Revised UCD: Deploy throughout the entire process. You can learn from users immediately and throughout your entire design process. This process is essentially rapid prototyping.
Clients have clients too, and clients don't necessarily understand partial design.
Consider the hammer:
- Show a drawing of the hammer on a piece of paper?
- Make a paper cutout and have the customer hold it?
- Make a styrofoam model and try to use it?
- Produce an actual hammer and try to use it?
You obviously want to do number 4, but if you get it wrong, you've spent more time and money than you need in order to produce a "prototype".
At Hashrocket, the design process is:
- Wireframe & Storycard
- Look & Feel
- Implement & Deploy
- React to feedback and go as far back in the process as needed
The design process involves a lot of handoffs. Hashrocket, today, has a team that wireframes along with a designer towards the end of the wireframing process, the designer creates PSDs and helps work on the HTML/CSS with developers, and the developers implement Ruby and/or Javascript along with the HTML/CSS towards the end of THAT process. These handoffs should involve overlaps of expertise.
As you move from idea, to pixel, to code: know your expertise and facilitate your handoffs. Deliver to communicate.
Choose the tool that allows you to follow the process you want. Don't let the tool dicatate how you work.
Ruby as Science, Art, & Craft (Davy Stevenson)
Computer Science teaches the science of computing without necessarily teaching to code. e.g. Algorithmic analysis divorces the implementation details from a problem to be solved.
As scientists, we should always be looking to expand our collective knowledge. We should be looking for the best results and bringing them forward.
If Ruby is our medium, our syntactic and semantic choices are our artistic styles. Diversity of coding styles is like a diversity of artistic styles.
Neuroscientists are discovering that the same pathways that light up when people view beautiful art or listen to beautiful music light up when a mathematician views an equation that they think is particularly beautiful. Art is about simplicity, code is about simplicity.
As artists, we should admit that there are many right answers, and that artists all have particular styles. We should welcome differences of styles.
Craftspeople often have journeyman, artisan, master designations. Crafts are viewed as skills that anybody are capable of picking up, but that take years to master. If code is a craft, we should not view it as a skill that people must have innate abilities to do. We should view it as a skill that anybody can delve into. Getting paid to do our work is a nice benefit, but at the end of the day, we write code to benefit other people.
We should know that the particular tools we choose to solve our problems will derive our final result, but are not necessarily indicative of our lives as craftspeople.
Writing Games With Ruby (Mike Moore)
Writing games is fun, and Ruby is a fun language. So why not write games in Ruby?
Gosu: a minimalistic game library. For Ruby, gem install gosu. Written via mostly C++ native extensions, but with usage from Ruby in mind.
The classic game loop:
- Button Down
- Button Up
- Update
- Draw
Gosu entities:
- Window: contains the game state
- Images: load one from the filesystem or create a new one via combining other images
- Sound: play samples, a one-off sound, or songs, intended to be looping in the background
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment