DEV Community: Mengjia L

Python Interview Questions (WIP)

Mengjia L — Fri, 13 Sep 2024 16:16:35 +0000

Q: What is the difference between a function and a method in Python?
A: A function is a standalone block of code that performs a specific task, while a method is a function that is associated with an object and can access and modify its data.

Q: What is the difference between the “is” operator and the “==” operator in Python?
A: The “is” operator checks if two objects are the same object, while the “==” operator checks if two objects have the same value.

References
https://coderpad.io/interview-questions/python-interview-questions/

Ruby Design Patterns (WIP)

Mengjia L — Fri, 09 Aug 2024 21:58:44 +0000

Model

The Model represents the business layer of the application, responsible for handling business logic, validations, data persistence, and interactions with the database. (source)

Presenters (View)

There should be no ActiveRecord queries in views (source).
It should be separate from the business logic (here's a great explanation in case you are wondering what business logic means)

Controller

A controller can be thought of as a middleman between models and views. It makes the model data available to the view, so it can display that data to the user, and it saves or updates user data to the model (source).

The Pragmatic Programmer Summary (WIP)

Mengjia L — Sat, 06 Jul 2024 17:10:52 +0000

I've been reading the book The Pragmatic Programmer for a while and here's a summary of what I learned from this book.

Care about your craft
- There is no point in developing software unless you care about doing it well.
Never run on auto-pilot
- Constantly be thinking, critiquing your work in real time
You have agency
- Make time to study new stuff that look interesting.
Instead of excuses, provide options
Don't live with broken windows
- Neglect accelerates the rot faster than any other factor.
Keep an eye on the big picture
- Constantly review what's happening around you, not just what you personally are doing.
Great software today is often preferable to perfect software tomorrow
Invest regularly in your knowledge portfolio
- Learn a new language
Critically analyze what you read and hear
It's both what you say and the way you say it
- The more effective you communicate, the more influential you become.
Build good documentation in
- It's easy to produce good-looking documentation from the comments in source code, and we recommend adding comments to modules and exported functions to give other developers a leg up when they come to use it.
Good design is easier to change than bad design
- Decoupling is good because by isolating concerns we make each easier to change.
- Single responsibility principle is useful because a change in requirements is mirrored by a change in just one module.
- Naming is important because good names make code easier to read, and hence make code easier to change.
DRY -- Don't Repeat Yourself
- save you from having to rewrite logic
- prevent you from having to rewrite code when you have to make changes
- avoid human error as you will only be modifying one piece
- make code easier to read
Make a point of reading other people's source code and documentation, either informally or during code reviews. What you're trying to do is foster an environment where it's easier to find and reuse existing stuff than to write it yourself.

Ruby dry-monads

Mengjia L — Wed, 27 Mar 2024 23:24:56 +0000

🤔 What is the use case for dry-monads?
😀 return either Success or Failure from some operation

From the dry-monads doc:

Monads provide an elegant way of handling errors, exceptions and chaining functions so that the code is much more understandable and has all the error handling without all the ifs and elses

user = User.find_by(id: params[:id])

if user
  address = user.address
end

if address
  city = address.city
end

if city
  state = city.state
end

if state
  state_name = state.name
end

user_state = state_name || "No state"

After using dry-monads ✨

def find_user(user_id)
  user = User.find_by(id: user_id)

  if user
    Success(user)
  else
    Failure(:user_not_found)
  end
end

def find_address(address_id)
  address = Address.find_by(id: address_id)

  if address
    Success(address)
  else
    Failure(:address_not_found)
  end
end

This style of programming is called 🚃 Oriented Programming ( Railway Oriented Programming) - More info here!

Code Reviews

Mengjia L — Fri, 22 Mar 2024 00:42:05 +0000

Looking back on my two-year journey as a software engineer, one of the areas where I experienced most growth is code review 🔍. I knew next to nothing about code reviews when I started my current job in 2022. Thanks to my supportive team members and online resources, I’ve adopted a personal mantra on code review: I Choose the Intent to Learn 🌻

One of the biggest challenges I faced during my early days is my own insecurity. When I was assigned as a reviewer, I would think to myself I don’t really think I have anything useful to add because I am still new to everything! I’d have the urge to automatically approve when the pull request creator is a senior engineer, since I believed that I had nothing to comment on a PR of a senior developer.

During a one-on-one meeting with my manager, I shared my feelings about code reviews and he kindly pointed out that I don’t need to provide constructive feedback for every pull request, and it is absolutely okay for me to ask clarifying questions if I don’t understand a particular line of the code 💛

It was then that I realized that my intention was a bit off when code reviewing. I had the intention of trying my best to spot any potential flaw and therefore providing a useful review. However, code reviewing is not limited to a one-directional activity where one side purely gives and the other side purely receives. It can be a two-directional activity if you set the intention to learn while you review others’ code.

This mindset shift drastically reduced my anxiety around code reviews and also taught me the power of our mindset and intention ✨. When I choose the intent to learn, I also find it easier to give constructive feedback since my mind is open and calm.

What is the code doing?

do you have the right background info?
do you fully understand why this code is needed?
do you understand how this code fits into the project?

Frame your mind

how experienced are you with the codebase/language?
are you going to be using this code in the future?
have you written code similar to this?
what is the experience level of the author?
what is your relationship with the author?

Test the code

does the code generate warnings/errors?
does the code take longer than normal to build/run?
do the changes require any additional setup steps?

Inspect the code

are correct naming conventions followed?
does the code follow DRY principles?
are new files/folders named appropriately?
does the code have error handling?
is the code written in a similar style to other code in the project?

Compile your review

beware of bikeshedding
be respectful
be specific and descriptive
be open to follow-ups

I’ll keep updating this post as I move along in my career 😊

Resources for Code Reviews: