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

Code Documentation – before, after, and during coding

Sometimes you just need to started on some design for work on a larger ticket or new feature, you want to get your thoughts down and maybe start plotting out a code flow or some potential classes but what app do you reach for?

So much of the time I reach for Google Docs, for my personal or professional work. It’s easy, automatically backs up your work, and makes it very simple to share the document or convert it to another format. Opening a Google Doc, and starting to type out some pseudo code can be frustrating with the automatic capitalization or the code just not displaying as you would like.  I have found the Code Blocks extension extremely awesome with that.  Putting in code next to text is a breeze with it.

Helpful tip – If you are using Google Docs you can change up your preference to not annoyingly capitalize the first letter in a sentence (which is rather annoying for your Ruby classes which like to start with a non-capitalized letter).

Sometimes you just want to work on a spike story or share research that you had to done on a particularly hard debugging process or obscure part of your application. For this type of information, I like the use Confluence, a GitHub readme, or even the GitHub pull request itself. Just depending on if it is something I am currently fixing (it will go in the GitHub PR, preferably with screenshots if it a UI type fix), research for tickets or design coming up (Confluence, so easy to share and searchable for other developers) or if it is something that is needed for the code itself, like metadata or installation information, a readme works well. As a developer, I am trying to improve my git commits and PR for future development and maintenance. I highly ecourage anyone working in Git to check out Tekin Süleyman’s awesome “A Branch in Time” talk. Also his blog post on creating useful git history has some great Git tips and tricks, and really makes you think about how your git comments today, and effect someones code tomorrow.

For UML and flow diagrams, LucidChart, is my current app of choice. It is an online diagramming tool that has a lot of flexibility on what you want to show. Coming up with your flow diagram isn’t too hard, just make use of the typical shapes and lines. For me drawing the lines for the code that is calling a self.method was the hardest, but LucidChart has some pretty good tutorials that can walk you through the process, and help you with all the keyboard shortcuts that make you work life happier.

For the documentation of the code itself, I love writing code that is self documenting. For years with writing Java, if your code needed to have comments above it so other developers could understand what it was doing, it was probably too complicated. Writing comments were not encouraged, and refactoring out methods, and patterns to be better descriptors were the norm. Now with Ruby and the software I develop on, there are more comments in the code base. There doesn’t seem to be any stigma with code comments. Sharing information on how to use a command object, or the usage of an API or providing context on a classes public contract all seem to be valid use cases for inline code comments. I am getting used to using comments effectively in Ruby, and the not bring over any Java stigmas that I might have carried over about comments.  I still do lean towards refactoring out code into smaller chunks with self descriptive method names, but do understand when code comments are helpful. All my method names tend to be more verbose, and I am still working on remembering to snake case everything.

There are so many different things that we have to document as developers that it is so important to figure out the best tools and applications that work for you. So, you as a developer, can document code effectively, efficiently and hopefully in a way that other people can find it and use it. Because the only thing worse than not documenting code is code documentation that isn’t used.