My understanding for IoC(Inversion of Control)

20230322 free chat sharing notes

Framework vs Library

  • our code calls library code
  • our code called by framework code

My understanding for IoC

IoC is we as programmers write codes that are called by Frameworks

  • control structures: Sequence, Selection & Iteration
  • normally we write business logic as step1, step2, step3… using above control structures
  • but we will notice bolier templates as we getting more and more familar with them, for examples:
    • we always need to close an open file
    • we always need to declare an empty array if we’re only interested in part of the elements in a list
    • some code only differs in the middle part

Examples

  • map/filter/reduce(pipelined list handling)
    • list.filter {}.map {}
    • list.filter {}.map {}.reduce {}
  • ruby: partition/all?/any?/none?
    • (1..6).partition { |v| v.even? } #=> [[2, 4, 6], [1, 3, 5]]
  • dsl(describe what to do, not how to do it)
  • framework
    • rails
    • event_sourcing
  • lambda(ruby block / First-class Function)

Take aways

  • find & use good abstraction(e.g.: use map/filter/reduce more)
  • learn more about the framework we’re using

References

Some common sense

最近这些简单的感悟和常识经常在脑袋里窜, 记下来供以后review

  1. 没有人阻止我去重看那些以前看不懂的东西(文章/书/电影/知识点…), 多看几次, 随着知识增长, 大概率会慢慢看懂并且学会的
  2. 没有人阻止我去练习那些不容易掌握的能力和技巧, 难是正常的, 刚开始不会也是正常的, 硕哥以前教过我: “我不会是因为我欠练”, 多多练习, 一定能提升熟练度, 慢慢掌握的
  3. 没有人阻止我做很多我认为正确的/有价值的事, 唯一的阻碍就是自己想偷懒, 问题在自己
  4. 守好自己的钱包, 在接受别人分享的”赚钱机会”时, 想想你是不是他爹? 凭什么他不自己闷声发财
  5. 重要的信息一定要确认来源, 多方验证, 要重视”验证码”的重要性
  6. 要多积累常识, 多思考”老生常谈”的含义, 做决定时多调用常识, 多多沟通
  7. 人给自己找理由实在太容易了, 不要怕麻烦, 如果自己思考不清楚, 应该向更厉害的人求助; 行动起来就会遇到问题, 遇到问题就解决问题, 坐在那里给自己找理由实在太容易了(还没做到…)
  8. 多想想怎么能把自己在做的事的价值描述清楚, 如果想不清楚, 说不清楚, 是不是说明在做的事没价值? 如果不是, 为什么说不清楚? 有什么是自己不敢面对的么?

review and remove unused gems

review and remove unused gems

1
2
3
4
5
6
7
bundle list --without-group dev development staging test
bundle list --only-group default production

tldr du
tldr sort

for dir in $(bundle list --only-group default production --paths); do du -shk $dir ; done | sort -nr

Abstract Data Type Collection

“和任何编程概念一样，理解抽象数据类型的威力和用法的最好办法是仔细研究更多的例子和实现” — algs4 ch1.2

  • Counter
  • Interval1D
  • Interval2D
  • Date
  • Transaction
    • from_user
    • to_user
    • created_at
    • amount
    • currency
    • souce_id
    • source_type
  • List
  • Stack
  • Queue
  • Bag
  • Tree

ref: Reading 10: Abstract Data Types

昨天复习优先队列的时候，才真正注意到 ADT 和 data structure 是两个不同的概念

比如优先队列(priority queue)是一种ADT, 所以他的实现可以有多种, 基于数组实现的而叉堆只是实现它的一种数据结构

比如栈(stack)是一种ADT, 基于数组实现的栈是一种数据结构, 基于链表实现的栈也是一种数据结构

(还是不够清晰，甚至感觉有错误…)

Find unused local variables in ruby project

Inspired by SublimeLinter plugin for ruby, using ruby -wc

1
parallel "ruby -wc {}" ::: $(find . -name \*.rb) 1> /dev/null

Known issue

it only detects local variables for “warning: assigned but unused variable - xxx”

not working for instance variables

probably work with unused-code/unused to detect other unused tokens

unused

1
2
3
4
5
6
7
8
# https://github.com/universal-ctags/homebrew-universal-ctags
brew install --HEAD universal-ctags/universal-ctags/universal-ctags
brew install unused --with-mimalloc

alias ctags='/usr/local/bin/ctags'

# go to project working dir
ctags --recurse . && ls -lh tags && unused

Linus torvalds talking about good taste

“The mind behind Linux | Linus Torvalds”

Sometimes you can see a problem in a different way and rewrite it so that a special case goes away and becomes the normal case. And that’s good code.

To me , the sign of good people I really want to work with is that they have good taste.

This is a small example , Good Taste is much bigger than this.

Good taste is about really seeing the big patterns, and kind of instinctively and knowing what’s the right way to do things.

install ruby-3.2.0 on macos

Background

Steps

1
2
3
4
5
6
7
rvm reinstall "ruby-3.2.0" --with-openssl-dir=`brew --prefix openssl@3` # not ok, [ruby don't support openssl 3 yet.](https://github.com/ruby/openssl/issues/369)

brew uninstall openssl@3
brew reinstall openssl@1.1

# new shell
rvm reinstall "ruby-3.2.0" --with-openssl-dir=`brew --prefix openssl@1.1` --disable-binary # ok

Other ref

Reading List of 2022

  • review: unix-processes 15 * 15 min = 225 min(done 20220517)

  • read: 元编程 240 页 / (10页/15 min) = 360 min(done 20220521)

  • listen/review: 史蒂夫乔布斯传 (76 - 18 + 1) * 20 min = 1180 min(done 20220524)

  • read: 暗时间 244 页 / (10页/15 min) = 366 min(done 20220623)

  • read: CSAPP 730 页 / (10页/20 min) = 1460 min(ff)(done 20220512 -> 20220925)

  • review: 现实一种(余华) (done 20220925 -> 20221001)

  • read: unix编程艺术 (done 20200704 -> 20220924)

  • read: refactoring (done 20220929 -> 20221012)

  • read: DDD (done 20221107 -> 20221213)

Testing and Refactoring sharing

  • Bi-weekly Tech Sharing

Agenda

  • Experience
  • Testing
  • Refactoring
  • References

Experience

  • best thing learned this year

  • I’m proud that we have testing culture and code review

  • how I test my code before?

    • coding -> run program -> postman / repl -> verify by eye -> QA

  • how I test my code now?

    • coding -> add tests -> green -> refactoring -> coding -> repeat -> code review

  • hopefully I’ll benefit from TDD style sooner

Testing

  • raise a question: we’re relying on tests to guarantee code work as expected, who guarantees our tests are correct then?

    • short answer: we can only rely on simple tests
    • too simple to be wrong(ideal world)

  • testing proportion

  • testing helped on

    • building confidence
    • building solid(bug free) code as possible
    • gives me a button to click
      • “if you ever get that button, you’ll never want to lose it or work other way round so you wouldn’t have it.”

  • testing drives me to write simple code

    • I want class to be small
    • I want responsiblilty to be single/simple/clear
    • I want method to be short
    • I want interface to be well defined
    • I love good names

  • example of using let(private git repo pull request)

    • demo for independant tests
    • avoid mutable variable
    • discipline posed upon assignment/mutability

  • key points:

    • write simple code & test when possible
    • more unit tests
    • “write enough tests to be confident”

Refactoring

  • let’s put performance aside while coding & refactoring

  • let’s focus on clarity/simplicity/readability/maintainability, not performance

    • make it simple
    • make it easier to read/review
    • make it easier to change/maintain

  • How I do code refactoring?

    • clean up feature flags
    • check code coverage and make it up to 100%
    • remove code smell
    • simplify code
    • enjoy the tiny changes/improvements
    • enjoy the green dots
    • enjoy the red dots(it shows I didn’t fully understand my code)
    • remove unused/dead code(unused)
    • check with flog(rely on metric tools, not “feeling”)
    • choose a better name for variables/methods/class/file/moudles
    • simplify tests
    • I got better understanding of the code, and I can repeat the above process…

  • example of simplifying code(private git repo pull request)

  • The point is: “business complixity is the lower limit of system complixity”

    • so I want my code to be as simple/readable as possible
    • try functional thinking: e.g. use filter/map/reduce
    • ruby: Enumerable module is amazing

  • key points:

    • lean on tests, no tests, no refactoring
    • do your refactoring with small steps(highlighted in both “refactoring” and “99 bottles of OOP”)
    • refactoring is just pattern matching(focus on code smell) and follow the solution

References

At last

these are just my limited experience on testing & refactoring; I’m pretty sure I have a lot more to learn

I really want to learn from everyone about these two topics

pls correct me if I’m wrong. pls discuss with me if you’re interested~ Orz