A Month of Learning


My month(ish) of learning

So one of my goals has to been to dive deeper into Ruby and Rails, but as well as to try to learn a new thing, maybe technical, maybe not, every work day. And then to write that thing down. This was to help with accountability, you know actually doing it, as well as to help remember and learn it better. It also allows me to have proof that I know more now then I did a day, a week, or even a month ago.

Sometimes it feels like you are making progress in your career. Maybe becoming a better programmer, better at understanding patterns, helping out on more code reviews, but how can you tell when you know more?

How can you tell if you have leveled up?

Level Up with Star moving gif

This was one way for me to attempt to quantify it. Below is my list of learning items for around one month, I kept these in a note and tried to make sure to update every day. Some days I might have made note of more than one item, especially if I was trying to get it fixed in my brain. I used Notes for this, but is this the best app to keep these in? Probably not, but it was the most convenient (at least on my Mac), but it sucks for formatting little code segments.

11/21 – git log –oneline = display git log history with only the first line of the commit message, easy for scanning and to get commit hash. For git commit –fixup 1e30877 . I can then specify the hash of the commit I want to fixup to, not just the last one as how amend works. This then can be used with an auto squash workflow git rebase -i –autosquash HEAD~3, and –autosquash is just an option added onto the typical interactive rebase that automatically marks the fixup items with f in there.

YML can do comments # this == is a comment.

Cron is hard, use CronTab Guru

11/22 – API rate limits suck, and changing them up for different endpoints in the same API seem arbitrary, and unnecessary and if you have a default but it only applies to your first get on an API is it really a default??
Resque::TermException == see this error when the dynos are restarted (referring to Heroku Dynos)

11/25 – Mutex pattern = Mutual Exclusion Object only one process at a time can access the given resource. Allows multiple threads to use a same resource but one at a time, not simultaneously. (Java implementation example)

11/26 – .() is an alias for .call (We are working on a lot of Railway oriented programming, Ruby dry-transaction, and do-notation right now, so really understanding these patterns are critical)

crontab syntax- if you have five **(asterisks), it’s every minute. If you have six **(asterisks), it’s extended crontab syntax which is every second.

11/27 – PostGres to_tsvector(text) reads the string and does some normalization (taking language settings into account) on the string.

12/2 – Don’t schedule appointments on the Monday after a holiday, probably not on a Monday ever. For an Rspec ‘expect’, it should probably be called before actually testing the part of code you are working on.

12/3 – Testing command objects can be tricky, make sure your expectations are correct

&block is an explicit block with the name “block”

12/4 – With the do notation (dry-monds) when you are doing a block on the ResultMatcher (on.success/on.failure) You have to take both paths into account, otherwise you get a Dry::Matcher::NonExhaustiveMatchError: cases +failure+ not handled.

Use ~~ on GitHub for markdown to add strikethrough text.

A lambda is a way to define a block & its parameters with some special syntax. { puts “This is a lambda” }. But the lambda won’t just run, like when you define a method, it won’t run until it is called.

my_lambda.call, .() (that call alias peeks its head up again, other call aliases are [], .===.). Lambda’s can take arguments too

times_two = ->(x) { x * 2 } times_two.call(10)

12/5 – Naming stuff is hard, when in doubt reexamine the docs for each individual part, ask people, get descriptive

12/6 – You can stash untracked files, git stash –include-untracked, git stash –all, TIL DON’T USE –all!! That is a memory hog!! Use –include-untracked. Maybe just git alias this.

12/9 – When reporting to Honeybadger.notify, there is a ton of options :context hash context to associate with exception. :tags string, comma-separated list.

12/10 – text selection in VIM V – select entire lines, (out of insert mode)

12/11 – describe and it are the same method in rspec just use whichever one describes the situation that is being tested best.

12/12 – You can do sum on array but also pass it a block, (1..10).sum {|v| v * 2 } (v == value)

12/13 – Ruby Enumerable map, this method on a enumerable object returns a new array with the results of running block once for every element in the enum.

PostgreSQL COALESCE. Function accepts an unlimited number of arguments, return the first argument that is not null. If all arguments are null then will return null.

ORM – object relational mapping

12/16 – You can add in untracked files in git if needed git add –force my/ignore/file.yml

12/17 – Don’t have an order on a scope, not a best practice.

Ruby gsub Returns a copy of a string, with all occurrence of pattern substituted for the second argument.

12/18 – Ruby ‘transform_values!’ takes a hash, returns a new one with the results of the running block once for every values. Doesn’t change the keys,

12/19ActiveSupport presence, returns self if present? == true, otherwise returns nil, so code could go from name = user.name.present? ? user.name : ‘N.A.’ to name = user.name.presence || ‘N.A.’

12/23 – curl the Honeybadger API for getting quick data back on a certain error, and your AUTH_TOKEN is under the profile.

12/30 – Cmd + P to search for file name in VSCode, works kind of similar to RubyMine’s shift-shift for searching for files.

12/31 – Rails ActiveRecord touch method easier way of updating an active record models updated_at timestamp and pass symbol argument of other timestamp to update too. Ex. product.touch(:started_at)

Well that’s all my notes.

They are a bit rambly, and I take notes in pseudo-code a lot. But to me, these are an accomplishment. I feel like I have leveled up with coding with dry-monads and do notation (functional programming implementations in Ruby). I not only can exit successfully in VIM, I can select lines and words every time. I have been diving in on ActiveRecord/ActiveSupport documentation a lot, and when I have a Ruby question, my new go to is to look at the source docs.

This was a huge change from being a Java programmer for me, I don’t think I looked at a lot of Java code implementation documentation. Sure there are Oracle API docs but do you ever look at Java source code? Can you look at Java source code? I can say it something that I now do regularly in Ruby.

How do you level up?

For me? I am going to stick with my notes, maybe find myself a better place to keep them (maybe with markdown, and makes my code a bit prettier). Any suggestions for a good notes app? Also, I am going to continue to writing down one thing I learn a day (or at least on work days)

Phew. I’m done with my learning till 2020 😉

Cat on treadmill that is so tired afterwards
Me attempting to get all my learning in for 2019

Engineering Bookclub – Pragmatic Programmer Chapter 8 Notes and Questions

So sorry this took a while to post, but let’s dive into the last chapter for The Pragmatic Programmer! As always, thank you to Ari Caplan of Dev Empathy Bookclub for letting me use questions from the book club. If you are looking for an awesome group of people to discuss books that can help you become a better person and better developer check them out! Right now they are taking on Say What You Mean: A Mindful Approach to Nonviolent Communication by Oren Jay Sofer.

Notes on Chapter 8, Pragmatic Projects

  • Quality of code is a team issue
  • Teams should not tolerate broken windows, team must have accountability 
  • Communication within a project team is important, as is the project team communicating with the rest of the company
  • Don’t duplicate work between members of a team
  • Divide teams up by function, into small groups that are self-organizing
  • Automate what you can, don’t rely on manual processes (ex. scheduling backups, compiling project, generating code, regression tests, making a build…)
  • “Finding bugs is somewhat like fishing with a net. We use fine, small nets (unit tests) to catch the minnows, and big, coarse nets (integration tests) to catch the killer sharks.”
  • Earlier a bug is found, the cheaper it is to fix it
  • Be aware of end-user use patterns and how they are different from test data/patterns
  • If a bug slips through the net of existing tests, you need to add a new test to trap it next time.
  • All documentation is a mirror of the code, if there is a discrepancy, the code is what matters
  • Code comments should discuss the why something is done, purpose and goal (the code is the how)
  • Documentation of any form is just a snapshot in time of the code
  • Communicate expectations, work with users so they understand what you will be delivering
  • Have pride in ownership of your finished code, don’t jealously defend it, bu show that it is is solid, well written, tested and documented code.
    • Before Git blame! So now your name is in their no matter what now 😛
    • Have strong opinions, but loosely held

Tips

  • Organize Around Functionality, Not Job Functions
  • Don’t Use Manual Procedures
  • Test Early. Test Often. Test Automatically.
  • Coding Ain’t Done ’Til All the Tests Run
  • Use Saboteurs to Test Your Testing
  • Test State Coverage, Not Code Coverage
  • Find Bugs Once
  • Treat English as Just Another Programming Language
  • Build Documentation In, Don’t Bolt It On
  • Gently Exceed Your Users’ Expectations
  • Sign Your Work

Questions on Chapter 8

  • Is a separate tool builder tool still necessary? Or does each programmer also have to build their own tools?
  • “Our goal is to maintain an automatic, unattended, content-driven workflow” is this something we have been able to achieve as developers now that we have 20 more years of tools and utilities?
  • What tests are you missing in your project/application? For ex. Think about how many unit/integration tests may exist but what about validation and verification

Testing? The book goes through several major types:

  • 1. Unit testing
  • Integration testing
  • Validation and verification
  • Resource exhaustion, errors, and recovery (Stress tests)
  • Performance testing
  • Usability testing
  • In Tip 60 in the book urges: Organize Around Functionality, Not Job Functions
    • Have you worked on a cross-functional team before? How did that experience compare with working on a function-based (backend-only, frontend-only, DB-only, etc.) team?
  • While advocating for usability testing (chapter 43, Ruthless Testing), the book claims: Failure to meet usability criteria is just as big a bug as dividing by zero. Has that been the attitude of teams where you’ve worked? Do you believe this is true?

Further reading

https://en.wikipedia.org/wiki/Chief_programmer_team

In an article in the April 1999 CACM, Robert Glass summarizes research that seems to indicate that, while code inspection is effective, conducting reviews in meetings is not [Gla99a].

And with that we are done!! Next up for my engineering book club we are looking at tackling How We Got to Now: Six Innovations That Made the Modern World, thought/feelings on this? What is up next on your reading list?

The Pragmatic Programmer – Chapter 7 Notes and Questions

Notes on Chapter 7, Before the Project

  • All about what to do before starting a project. Seems like it is pre-agile methodologies. Since the agile manifesto came out 2001 seems to fit that timeline.
  • Dig for requirements, don’t gather. They are on not the surface but deep under assumptions. A requirement is a statement of something that needs to be accomplished
  • Use cases help describe a particular use of the system, and should use cases be formal (use template) or informal.
  • Don’t over specify in a requirements document, good ones remain abstract, simplest statement that accurately reflects the business need is best.
  • Maintain a Glossary, one place that defines all the specific terms and vocabulary used in a project
  • Publish project documents to internal Web sites.
  • Some constraints are absolute; others are preconceived notions, honor absolute constraints.
  • Listen to the voice that says “wait.” If you sit down to start typing and there’s a doubt in, listen (Good Judgment or Procrastination?)
  • Tips:
    • Don’t Gather Requirements—Dig for Them
    • Work with a User to Think Like a User
    • Abstractions Live Longer than Details
    • Use a Project Glossary
    • Don’t Think Outside the Box—Find the Box
    • Listen to Nagging Doubts—Start When You’re Ready
    • Some Things Are Better Done than Described
    • Don’t Be a Slave to Formal Methods
    • Expensive Tools Do Not Produce Better Designs

Questions on Chapter 7

Helpfully provided by the Dev Empathy Book Club (check it out if you are looking for an online book club to expand your reading horizons and if you want to meet of group of awesome supportive people looking to help your develop your empathy skills)

  • In section 36 (“The Requirements Pit”), the authors advocate limiting requirements to be as minimal and abstract as possible. Is this always practical? Desirable?
  • Also in section 36, the authors encourage you to become a user of your own system – or, in modern terms, they advocate dogfooding. Have you tried using the tools you build extensively? If so, how has it helped you understand your users and better meet their needs?
  • In section 39 (“The Specification Trap”), the authors define program specification as: the process of taking a requirement and reducing it down to the point where a programmer’s skill can take over. This is cast as a mindset to avoid over-specifying a system and building in constraints that will hurt the product, and ultimately its users.
  • How does the specification process work in your organization? Do you think there’s too much, or too little?