(Photo Credit: “Person Standing on Train Rail” by <a href="https://unsplash.com/@clayton_cardinalli" rel="nofollow noopener noreferrer" target="_blank">Clayton Cardinalli</a> on <a href="https://unsplash.com/photos/ik1xoxbLDgM" rel="nofollow noopener noreferrer" target="_blank">Unsplash</a>)

## 目錄
- 前言
- 使用 `reload!` 來重新讀取更改過後的 Code
- 呼叫 Helper Methods 與發送 HTTP Request
 - 呼叫 URL Helper Method
 - 呼叫 View Helper Method
- 用 YAML Module 將資料漂亮地印出
- Rails Console Sandbox Mode
- 其它小技巧
 - 使用 `~/.irbrc` 載入常用的東西
 - IRB 裡的 `_`
- 補充： `$ rails routes` 加 flag （ Rails 5 以上）

## 前言
程式語言 Perl 的作者 <a href="https://en.wikipedia.org/wiki/Larry_Wall" rel="nofollow noopener noreferrer" target="_blank">Larry Wall</a> 在他的書 <a href="https://en.wikipedia.org/wiki/Programming_Perl" rel="nofollow noopener noreferrer" target="_blank">Programming Perl</a> 曾經提到過的<a href="http://threevirtues.com/" rel="nofollow noopener noreferrer" target="_blank"> Programmer 三大美德 （ Three Virtues of a Programmer ）</a>之中，第一點即為「懶惰 （ Laziness ）」。在 Rails 工程師天天中都會使用到的 Rails console ，其實有些更<del>偷懶</del>聰明的使用方式。筆者在這邊整理了一些小撇步，要來帶著大家一起更有效率地使用 Rails console ！

## 使用 `reload!` 來讀取更改過後的 Code
若是在 Rails console 已經開啟的狀態下更動了 code ，只要執行 `reload!` ， Rails 就會讀取更改過後的 code ！

```ruby
# call a model's scope
>> SomeModel.some_scope

# modify the code and use `reload!`
>> reload!
>> SomeModel.some_scope
```

## 呼叫 Helper Methods 與發送 HTTP Request
說到測試 helper ，一般比較直覺的做法會是在 ERB template 或 helper method 的 method body 中插入斷點（如 `byebug` 或 `binding.pry` ）後試圖讓 code 跑到斷點以進行測試。但其實在 Rails console 中是可以呼叫這些 methods 的。

### 呼叫 URL Helper Method
想要在 console 裡呼叫 URL method 的話，只要將 method send 給 `helper` 就可以了。若想要更進一步、直接在 console 內發送 request ，只要將 HTTP Verb send 給 `app` 即可：

```ruby
# example from https://guides.rubyonrails.org/command_line.html#rails-console
>> app.root_path
 => "/"

>> app.get _
Started GET "/" for 127.0.0.1 at 2014-06-19 10:41:57 -0300
...
```

### 呼叫 View Helper Method
想要在 console 裡呼叫 helper method 的話，可以將 method send 給 `helper` 來使用。筆者自己常用的情境有以下：

- 測試 Rails 的 helper method
- Debug 自己寫的 helper method

```ruby
>> helper.number_to_currency 1234.567, unit: '円', precision: 1, format: '約 %n %u'
 => "約 1,234.6 円"
>> helper.some_helper_method
```

## 用 YAML Module 將資料漂亮地印出
若是平常的工作情境上會常常需要呈現資料給夥伴的話，將資料以好閱讀的方式印出，可以<del>有效降低夥伴眼睛脫窗的機率</del>讓夥伴更快速地掌握資料的樣貌。要在 Rails console 中將資料漂亮地印出，除了使用一般常見的 gem <a href="https://github.com/cldwalker/hirb" rel="nofollow noopener noreferrer" target="_blank">Hirb</a> 或 <a href="https://github.com/awesome-print/awesome_print" rel="nofollow noopener noreferrer" target="_blank">Awesome Print</a> 外，還可以使用已經在 Rails 裡面就引入的 `YAML` module 來達到類似的效果。若想要在一般的 IRB 內使用的話，只要先執行 `require 'yaml'` 就可以了。

```ruby
>> y User.first.attributes
---
id: 1
email: email@email.biz
encrypted_password: "somelonglonglonghashedpw"
 => nil
```

```ruby
2.6.0 :005 > y %w[foo bar baz]
---
- foo
- bar
- baz
 => nil
```

```ruby
>> y({ a: 1, b: 2, c: 3 })
---
:a: 1
:b: 2
:c: 3
 => nil
```

若看不慣 YAML 的資料格式，可以用 `PP` module （ Pretty-Printer ），在保留資料原來的樣態下印出 hash 或 array ：

```ruby
>> pp User.first.attributes
---
{"id"=>1,
 "email"=>"email@email.biz",
 "encrypted_password"=>
 "somelonglonglonghashedpw"}
 => # omitted
```

## Rails Console Sandbox Mode
要在不更動到 DB 裡的資料的前提下在 Rails console 裡面進行操作，可以在呼叫 Rails console 時在後方加上 flag `--sandbox` 。沙盒模式運用了 DB 的 savepoint ，在離開 Rails console 後即 rollback 。

**另外需要注意的一點是請不要在 Production 使用，因為沙盒模式會讓被更新的資料列被鎖住，造成其它需要跟該資料列互動的工作被卡住。**

```sh
# short form
# $ rails c -s
$ rails console --sandbox
```

```ruby
Loading development environment in sandbox (Rails 5.2.4.2)
Any modifications you make will be rolled back on exit
>> User.delete_all
 User Destroy (18.5ms) DELETE FROM "users"
 => 11
>> exit
 (0.3ms) ROLLBACK
```

平常在新增 migrate 檔時，若擔心在執行 `rails db:migrate` 的過程當中、會因為 migrate 檔內有一部分 code 沒寫好而造成執行失敗，陷入了「 migrate 檔僅跑完部分、但檔案被 Rails 標註為已執行、 DB 資料還壞掉」的這種不上不下的窘境，也可以運用 Rails console 的沙盒模式來放心地進行測試！

```ruby
# credit goes to https://shime.sh/til/testing-migrations-from-sandboxed-rails-console
>> require './db/migrate/20200516140557_create_identities.rb'
 => true

# use #change/#up to invoke the migration
>> CreateIdentities.new.change
-- create_table(:identities)
 (11.1ms) CREATE TABLE "identities" ( # omitted
```

## 使用 `~/.irbrc` 載入常用的東西
透過在家目錄下定義的 `.irbrc` ，我們可以在每次 IRB 或 Rails Console 被開啟時，將我們所需要的函式庫及設定一次讀取進來：

- 引入需要平常會用到的 modules ，如前面提到的 `YAML` ，或者是 `BigDecimal`
- 設定在 console 內、給特定專案用的 aliases 及 helper methods

```ruby
# ~/.irbrc
LIBS = %w[yaml bigdecimal hirb].freeze
LIBS.each do |lib|
 next if respond_to? lib

 require lib
 puts "Lib is loaded: #{lib}"
rescue LoadError
 puts "\e[31mLoading lib failed: #{lib}\e[0m"
end

if defined? Rails
 app_name = Rails.application.class.parent.to_s

 # tries to match module name string defined in config/application.rb
 if app_name == 'FooBarBaz'
 def me
 @me ||= User.find_by(first_name: 'danny', last_name: 'boi')
 end
 end

 if app_name == 'BazBarFoo'
 # that long query you find yourself typing every day
 def foo
 Foo.where(some_column: 'some_long_value',
 another_column: 'some_long_long_long_value')
 end
 end
end
```

## 其它小技巧
### IRB 裡的 `_`
若是想要使用上一次 IRB eval 的結果來做些什麼的話，可以使用 `_` ：

```ruby
>> Time.now
 => 2020-05-16 10:43:02 +0800
>> now = _
 => 2020-05-16 10:43:02 +0800
>> now
 => 2020-05-16 10:43:02 +0800
```

### 使用 `CTRL` 加 `r` 搜尋歷史 Input
要搜尋之前打過的東西，除了用上下鍵慢慢找以外，其實還有更快的方式。按下 `CTRL` 加 `r` 後就可以輸入關鍵字、往回搜尋曾經輸入過的 code 。

若要離開 `reverse-i-search` 模式，按下 `ESC` 或 `CTRL` 加 `[` 即可跳出。

## 補充： `$ rails routes` 加 flag （ Rails 5 以上）
若要以 `rails routes` 來尋找特定的路徑，最直覺的方式應該是 pipe 給 grep 來過濾出自己想要的路徑：

```sh
$ rails routes | grep users
```

在 Rails 5 以後，可以靠 flag `-c` 或 `-g` 達到類似的效果：
- Controller specific search

```sh
$ rails -c users
$ rails -c admin/users
```

- Pattern specific search

```sh
$ rails routes -g product
```

若專案使用的是 Rails 6 ，還可以使用 flag `-x` 、漂亮地印出路徑：

```sh
# example from https://guides.rubyonrails.org/routing.html#listing-existing-routes
# short form
# $ rails routes -x
$ rails routes --expanded
```

```
--[ Route 1 ]----------------------------------------------------
Prefix | users
Verb | GET
URI | /users(.:format)
Controller#Action | users#index
--[ Route 2 ]----------------------------------------------------
Prefix |
Verb | POST
URI | /users(.:format)
Controller#Action | users#create
# omitted
```

那以上跟直接呼叫 `rails routes` 後再使用 `grep` 有什麼差異嗎？其實沒有<del>，但是可以拿出來炫一下</del>。

## 參考資料
- <a href="https://guides.rubyonrails.org/command_line.html#rails-console" rel="nofollow noopener noreferrer" target="_blank">The Rails Command Line - 1.4 rails console</a>
- <a href="https://shime.sh/til/testing-migrations-from-sandboxed-rails-console" rel="nofollow noopener noreferrer" target="_blank">Testing migrations from sandboxed Rails console</a> by <a href="https://shime.sh/" rel="nofollow noopener noreferrer" target="_blank">Hrvoje Šimić</a>
- <a href="https://guides.rubyonrails.org/routing.html#listing-existing-routes" rel="nofollow noopener noreferrer" target="_blank">Rails Routing from the Outside In - 5.1 Listing Existing Routes</a>

---

> 👩‍🏫 __課務小幫手：__
> 
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

post-原來 Rails Console 可以這樣用/cover

原來 Rails Console 可以這樣用

有聽說過「編輯體例」嗎？拿起你手邊任何一本有經過出版社印製的書來看看，你應該可以發現：同一本書裡，不論是在排版格式上或是翻譯用語和專有名詞上，是有很高的一致性的。舉個簡單的例子，如果書中主角是「彼得」和「瑪莉」，即便編輯自身比較偏愛「彼德」和「瑪麗」的用法，也必須按照出版社要求的編輯體例，將用語統一為「彼得」和「瑪莉」。因為有共同的標準，同一間出版社下，就算是不同的編輯經手的不同作品，在排版和用語上也會有很高的一致性，例如凡是日期都會統一使用「六月四日」這樣的格式，不會印成「6 月 4 日」。

程式的世界裡也有類似的概念，我們稱之為 coding style。諸如怎麼縮排、括號怎麼斷行（或不斷行）、變數如何命名、判斷式的寫法、是否有行數限制等，每個人都有各自的偏好。這裡面有些是業界公認的 best practice，也有些是見仁見智的宗教戰爭，但無論如何，在團隊協作的情境下，有一個「大家可以接受並願意遵循的 coding style」作為開發的基礎，是相當重要的事情。

Ruby 圈有幾個比較有名的 style guide（字母序）供大家參考：

- [社群版](https://rubystyle.guide/)
- [Airbnb 版](https://airbnb.io/projects/ruby/)
- [Cookpad 版](https://github.com/cookpad/styleguide/blob/master/ruby.en.md)
- [GitHub 版](https://github.com/github/rubocop-github/blob/master/STYLEGUIDE.md)
- [Shopify 版](https://shopify.github.io/ruby-style-guide/)

對於工程師來說，「程式碼的風格統一」這種事情，當然就應該交給工具來處理囉。而在 Ruby 圈裡，最被廣泛使用的檢查工具就是本文要介紹的 [RuboCop](https://github.com/rubocop-hq/rubocop)。RuboCop 大約在 2012 年前後問世，也算是歷史悠久的開源專案了，但時至今日依然還沒有推出 1.0 的版本，官方文件也很大方地承認常會有向後相容的問題，要大家自己注意使用的版號 XD 

那就開始吧。因為沒有現成的例子，就順便工商服務一下，用敝公司的開源工具 [bankai] (https://github.com/5xRuby/bankai) 產生一個新的 Rails 專案：

```
$ gem install bankai
$ bankai demo
```

馬上來執行看看：

```
$ cd demo
$ rubocop
Inspecting 40 files
........................................

40 files inspected, no offenses detected
```

RuboCop 檢查了 40 個檔案，沒有發現問題 ，打完收工 🎉 呃不是啦 XD 再仔細看一下，會發現專案下有這兩個設定檔：

```
$ ls .rubocop*
.rubocop.yml .rubocop_todo.yml
```

`.rubocop.yml` 一看就是善良市民可以先放一邊， 倒是 `.rubocop_todo.yml` 看起來就很可疑，馬上打開來看看：

```ruby
# This configuration was generated by
# `rubocop --auto-gen-config`
# on 2020-05-13 11:13:56 +0800 using RuboCop version 0.81.0.
# The point is for the user to remove these configuration records
# one by one as the offenses are removed from the code base.
# Note that changes in the inspected code, or installation of new
# versions of RuboCop, may require this file to be generated again.
```
RuboCop 既然是用來檢查 coding style 的工具，自然也是依據某個 style guide 作為標準，而 RuboCop 參照的則是前文提到的社群版本。由於 Rails 和 RuboCop 是由不同團隊開發的，雙方的「出廠預設值」會有衝突也是在情理之中，所以並不是「RuboCop 沒有意見」，而是 bankai 預先把這些「已知不合」的狀況先隔離在 todo 裡，再讓團隊自行判斷後續該如何處理。

> 這裡必須再強調一次：我們在專案中導入 RuboCop 或其他 linter，並不是為了要追求「考試一百分」這樣的價值，而是要讓團隊成員在協作時能有共同遵循的標準。也就是說，在團隊成員有共識的前提之下，RuboCop 的結果只是參考，不需要盲從，預設值可以調整，必要時甚至也可以忽略。

那我們就順手改一下 todo 裡的東西吧！

```ruby
# Offense count: 1
# Configuration parameters: EnforcedStyle.
# SupportedStyles: slashes, arguments
Rails/FilePath:
 Exclude:
 - 'config/environments/development.rb'
```

 把這一條規則（我們稱之為 cop）註解起來後再執行一次，就會乖乖噴錯了：

```
$ rubocop
Inspecting 40 files
.................C......................

Offenses:

config/environments/development.rb:19:6: C: Rails/FilePath: Please use Rails.root.join('path/to') instead.
 if Rails.root.join('tmp', 'caching-dev.txt').exist?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

40 files inspected, 1 offense detected
```

翻成白話文就是，RuboCop 幫我們偵測到了「未遵循 [Rails/FilePath](https://docs.rubocop.org/projects/rails/en/latest/cops_rails/#railsfilepath) 規則」的原始碼，還很親切地告訴我們是在哪個檔案的哪一行，以及修改的建議。我們通常有以下選項：

- <del>就讓它噴錯，什麼都不做</del>
- 照著 RuboCop 的建議修改程式碼
- 調整規則，不改原始碼
- 保留規則，但將這段程式碼排除在外

> 一般來說，我們會把 .rubocop_todo.yml 中的 cop 逐一註解掉，處理過後使之不再報錯，直到整個 todo 可以被安全移除為止。

#### 照建議修改

在這個例子裡，程式碼的修改很單純，照著建議去改就可以了：

```ruby
 if Rails.root.join('tmp/caching-dev.txt').exist?
```

改過後再執行一次，確認沒有問題：

```ruby
$ rubocop
Inspecting 40 files
........................................

40 files inspected, no offenses detected
```

不過實務上，尤其是在比較有歷史的 code base 裡，是很有機會遇到「只是換個寫法，測試就掛了」「要改就只能整段重寫」等狀況的。因為這真的很重要所以要說第三次：RuboCop 這一類的工具只是幫助我們找出潛在的風險，它給的建議也不是「標準答案」（寫程式本身就沒有標準答案這回事），「怎麼做才是最好的？」最終還是要用自己的專業做判斷。

#### 調整規則

反過來說，如果大家覺得 RuboCop 抱怨的程式碼沒有問題，那就來<del>解決提出問題的人</del>調整 RuboCop 的設定檔就好。一種作法是直接放大絕，把整個規則 disable 掉：

```ruby
# .rubocop.yml

Rails/FilePath:
 Enabled: false
```

逃避雖然可恥但是有用？這雖然也是一種解法，但比較好的作法是去修改規則的內容，而不是把規則整個拿掉。參照官方文件可以得知 Rails/FilePath 預設的樣式是 `path/to/file`，如果希望統一成 `('path', 'to', 'file')` 的格式的話，就要另外指定為：

```ruby
# .rubocop.yml

Rails/FilePath:
 EnforcedStyle: arguments
```

修改後再執行一次看看有沒有問題：

```
$ rubocop
Inspecting 40 files
...................................C....

Offenses:

spec/rails_helper.rb:15:5: C: Rails/FilePath: Please use Rails.root.join('path', 'to') instead.
Dir[Rails.root.join('spec/support/**/*.rb')].sort.each { |f| require f }
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

40 files inspected, 1 offense detected
```

因為規則改了，所以原本沒有問題的地方變成有問題了。照理說，因為規則改了，我們應該要去改 rails_helper.rb 的程式碼才對，但因為正好可以拿來展示語法，我們就順勢來用排除法吧。

#### 排除特定程式碼

當我們希望「這個 cop 有其必要」，但「在這個特例下可以排除」的時候，可以用 inline 的方式對程式段落做 disable：

```ruby
# rubocop:disable Rails/FilePath
Dir[Rails.root.join('spec/support/**/*.rb')].sort.each { |f| require f }
# rubocop:enable Rails/FilePath
```

如果是「這個 cop 有其必要」，但「這些目錄下的檔案可以不用遵守」的話，也可以直接在設定檔裡做排除。例如在 `.rubocop.yml` 中，我們已經預設讓 db migration 和 rake task 之類的程式碼，可以不受 metrics 條件的限制：

```ruby
# .rubocop.yml

Metrics:
 Exclude:
 - db/migrate/*
 - Rakefile
 - Gemfile
 - config/**/*
 - spec/**/*
 - lib/tasks/**/*
```

#### 自動修改

RuboCop 也支援自動修改。要注意的是，並不是每一個 cop 都有支援（請自己看文件確認），就算支援，一般也不建議用在單純語法或排版統一以外的地方。Rails 開發者最常用到的可能是這個 XD

```
$ rubocop --auto-correct --only Style/FrozenStringLiteralComment
```

執行下去後，RuboCop 就會幫我們補好煩人的這一句：

```
# frozen_string_literal: true
```

#### 結語

善用工具，可以讓團隊協作的品質更整齊，但要小心不要陷入追求標準答案和滿分的陷阱，不然很容易本末倒置。Ruby 圈類似的檢測工具還有：

- [reek](https://github.com/troessner/reek): 偵測可能的 code smell
- [rails\_best\_practices](https://github.com/flyerhzm/rails_best_practices): 這個在做什麼應該很明顯
- [flay](https://ruby.sadi.st/Flay.html): 偵測可能的重覆程式碼
- [SandiMeter](https://github.com/makaroni4/sandi_meter): 檢查程式碼是否符合 Sandi Metz 提倡的四大原則

有機會的話都可以拿來玩看看 :)

#### 參考資料

各個 cop 的詳細設定方式和範例都可以在官方文件裡查到：

- [rubocop 官方文件](https://docs.rubocop.org/en/stable/)
- [rubocop-rails 官方文件](https://docs.rubocop.org/projects/rails/en/latest/)

(Photo Credit: "RoboCop" by [Andrew Milligan sumo](https://www.flickr.com/photos/24470821@N04) is licensed under CC BY 2.0)

---

> 👩‍🏫 __課務小幫手：__
> 
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

post-機器戰警 RuboCop/cover

機器戰警 RuboCop 

post-還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！/cover

還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！


「工程師」是近年來最受人矚目的職業之一。在每天生活不可少的各種便利服務裡，都有工程師付出的影子。
也因為這樣，近年來「轉職當工程師」，變得非常熱門。國內外許多名人也不約而宣導「學習寫程式」的好處，這股學習熱潮甚至讓一些父母從小學就開始讓孩童接受程式教育。寫程式不僅幫助訓練邏輯思考，其延伸的相關 Know-how 對高科技年代追求高薪也非常有用。

更由於工程師屬於「年資加值度高」的工作（亦即越資深薪酬越高），轉職最好趁早，使不少人趨之若鶩踏上轉職當工程師之路。

但說到「轉職工程師」，不少非本科的人會有這種疑惑：
「我不是理組出身的耶，我可以嗎？」
「數學要很好吧？」
「不是輕易就能學會吧，要學個好幾年吧？」
「寫程式這麼難適合我嗎？」

這些都是考慮轉職成為工程師時常見的煩惱。今天我們想藉由這篇文章告訴大家，學寫程式不但不難，轉職當工程師更可以短短幾個月就成功。

五倍紅寶石創建的轉職服務：全端工程師實戰訓練營「ASTRO Camp」，主打從素人轉職全端工程師，如今正在報名下一期，現在的課程也如火如荼進行中。輔導近上百位素人成功轉職工程師的五倍紅寶石程式教育機構，可以很肯定地告訴你：

相關科系重要嗎？數理很好重要嗎？

這些都不是轉職當工程師的關鍵因素。

數理能力固然有助強化邏輯力，但不是左右程式語言能力最大的因素。
簡單來說，轉職工程師只有一件事最重要：「找到你的熱情，並積極，積極，積極！」

## 熱情

找到熱情：在轉職初期，如何維持動力會是最重要的事。
學習一樣新技能時，必定會有碰撞期。所以能明確化動機，具現化想達成的目標，會是非常重要的事。

五倍紅寶石在全端工程師實戰訓練營裡，就精選了網站工程師最熱門的實作主題，以培訓出能建構能實作市場主流服務的能力為目標，從0開始教大家寫程式。
即便是新手，也能預期自己上完課後培養到的技能，目標具體，就不會輕易慌張或打退堂鼓。

## 積極
積極會是幫助你學習時克服困難不斷成長的主因。當然，轉職時也一樣。

課堂上遇到聽不懂的，是否有積極詢問老師、助教？
練習作業時是否有確實完成？
回家後有沒有複習？
教室裡上有沒有積極和同學切磋？
畢業後是否積極求職？

這些課前、課中、課後的功課，如果有按部就班做到。我們有足夠的案例大聲說，雖然是「完全素人」，但能在課程結束甚至課程進行中就找到工作的同學，真的很多、很多、很多。

## 持續進修

畢業後拿到轉職的門票，但是如何讓你從「成為工程師」到「成為高薪的工程師」，關鍵還是在「不斷花時間維繫熱情」。我們鼓勵所有學員每週回到教室跟學長姐同學們切磋、舉辦讀書會拓展知識，甚至如果開始新工作後發現自己想進修特定方面的技能，也可以參與五倍紅寶石的短期假日課程來持續進修。再沒時間，也可以隨時透過 LINE 群組跟同學們持續切磋，讓助教繼續解惑。

從「做得到」到「做得很好」，差異在於，如何持續投入熱情，追求突破。

看到這裡你有沒有發現：轉職工程師的眉角，從來不在是否相關科系、數理底子好不好。
而是唯一一件也最重要的：學習態度。

只要學習態度正確，你也一定能成功搭上轉職科技業就業的浪潮，成為全端工程師，並且成為高薪全端工程師！

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [面試攻略(二) 藏在自薦信 ( Cover letter) 裡的魔鬼](/posts/3skills-of-interview-2)
- [職涯原力：善用企劃力，為自己的生命校正](/posts/career-power-planning)
- [職涯原力：解開千千結的邏輯力](/posts/career-power-logic)

post-想當工程師？學寫程式，只有這件事最重要！/ cover

想當工程師？學寫程式，只有這件事最重要！

post-Vue.js 新手如何製作口罩地圖？一起來貢獻小小力量吧！/ cover

Vue.js 新手如何製作口罩地圖？一起來貢獻小小力量吧！

「工作上出錯了，不知道問題在哪」
「老闆需要我建議最佳方案，不知道從何建議起」

這些狀況對你來說熟悉嗎？

要鍛鍊這種解決問題、評估風險的能力，你就不能略過「邏輯力」。
特別是職場上的困難往往變因極多，如何梳理原委，排序優先順序，解決牽一髮而動全身的問題，正是需要發揮邏輯力的地方。

## 分辨變因屬性

把可能的變因列出來，可以幫助你整理思緒，客觀看待事情全貌。
建議把變因進一步分成「可掌握」（只與自己有關或有權解決）或「不可掌握」（與他人有關，又無法影響他人行為）。

## 排序優先度
依序檢討哪個變因對解決當前情況最有力，列為優先。但如果優先變因的「影響因子」全為不可控，那選擇優先解決它可能吃力不討好。

## 判斷影響力

找出「變因屬性」和「變因優先度」的交集。自己可掌握又排序優先的，影響力最大，應該先解決；然後是自己掌握幅度有限，但排序次優先的項目。雖然無法直接掌握，但可透過其他人事物施力，就能成為次優先的項目。無法施力又優先度低的影響力最小，可選擇最後處理。

這個步驟重要的是採取行動。

以上三個心法如果落實到實際範例上，可為：

假設 Joe 在公司內擔任專案經理，但是無法準時交付開發進度，因此被客戶客訴，老闆十分生氣。

結果來看是無法準時交付成品，但可能的變因有： 
1). 沒有即時分辨風險：客戶提出的時程與規格本來就無法合理完成，是風險很高的承諾。 
2). 沒有提前預警：工程師遇到障礙沒有或無法反應，導致無法提前告知客戶。

無論是 (1) 或是 (2)，其關鍵因素都在於有沒有辦法迅速判斷需求是否合理：不論是時程或規格的合理性，結果才導致被客訴。所以 Joe 需要即時判斷需求＆規格，團隊是否能準時交付。

要達成這一項目標，又有兩種方式： 
A). 掌握「增加判斷能力」必備知識 
B). 一律由主管審核確認 
C). 請具有該專業能力的要好同事協助判斷 

但是選擇 (B)可能會增加主管的工作負擔，並消減自己在職場上的價值。
短期要解決可以選擇 (C), 但是長期要完全治療這個狀況，則是要選擇 (A).

用這種方式來列出所有事物的關聯性與重要度，就變得很好判斷每個解決方案是否該執行。

看起來很複雜嗎？其實你只是需要多加一些判斷指標，就可以很快完成這些思考。
那麼，有沒有訓練邏輯力最有效的方式呢？

很有力的管道就是學寫程式！ 
程式語言的架構讓你可以預期要達成這些 output 需要多少 input，循線判斷影響因素，並進行除錯。不過，「寫程式」聽起來有點難，是嗎？

其實只要掌握一個要訣，學習寫程式可以是一眨眼的事情。
下一篇，我們就來告訴你那個要訣是什麼。

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [面試攻略(二) 藏在自薦信 ( Cover letter) 裡的魔鬼](/posts/3skills-of-interview-2)
- [職涯原力：善用企劃力，為自己的生命校正](/posts/career-power-planning)
- [想當工程師？學寫程式，只有這件事最重要！](/posts/to-be-an-engineer)

post-職涯原力：解開千千結的邏輯力 / cover

職涯原力：解開千千結的邏輯力

Photo by Alvaro Reyes on Unsplash

不管你是何種職位，身處哪個業界，你都應該善用企劃力為自己的人生企劃。

所謂的企劃力，是展現解決問題、創造價值的能力。
在企劃的過程中，我們不止能釐清思緒，梳理邏輯，更能好好省視一路以來的職涯規劃是否符合你想要的。而不至於在某天晚上突然驚覺「我這幾年都在做什麼呢？我當初想做的明明是....現在卻....」

那麼，如何在人生規劃中應用企劃力呢？
以下列出三個重要的企劃力，可以為你的人生校正：

## 目標設定

長程目標舉例來說，你現在如果是25歲，可以拉到30歲，這種需花費數年才能達成的目標，可歸類為長程目標。

短程目標是為長程目標服務。
舉例：假設你希望30歲能夠在外商公司擔任數位產品的產品經理，那麼將這個目標再切細一些，便是你的短程目標。可能是： 
1.增加外文聽說讀寫的技能 
2.增加產品管理的技能，包含： 

> 1.分析需求的技能 
> 2.PDCA（ Plan, Do, Check, Act）的技能 
> 3.資訊架構的基本概念 
> 4.前端技術基礎觀念與基本技術力 
> 5.後端技術基礎觀念與基本技術力 
> 6.時程管理的概念與實戰技能 
> 7.跨文化國際團隊溝通的技能 
> 8.跨部門團隊溝通的技能 
> 9.其他：如策略規劃能力、邏輯思考能力等。 

當目標切細之後，你就知道每年應該完成怎樣的目標。現在如果 TOEIC 是660分，那麼明年希望可以提升到800分，後年可以是900分....。

短程目標是一小步一小步的前進，就像在爬山，起點在山腳下，但每一小步都縮短了你與山頂的距離。
 

## 執行方案
可能是上課或自學，又或者是直接選擇相關領域的工作來培育專業能力。依據個人需求和現階段能力進行規劃。

 

## 風險評估
指的是執行方案的風險評估。例如上述「直接選擇相關領域的工作來培育專業能力」這個選項，很有可能因為專業不足，無法得到期望薪資。在本身也有經濟壓力的狀態下，選擇在職進修反而是虧損較少的選項。

風險評估的時候，需把目前所能覓得的資源一起加入評估，才能客觀選擇適合自己的方案。
 

## 路線調整

實際進入執行方案後，有可能會因為實際執行的成果，影響到目標。譬如你原本想要今年先提升英文程度到 TOEIC 800分，但是因為工作需求，必須先進修資訊技術的基本知識，那麼計畫就必須要根據實際的狀況調整。也或者是你在進修一項技能時狀況很好，感到游刃有餘，因此決定提前進多項技能。

無論如何，計畫建議可以三個月一次回頭調整，確保自己有最多的彈性。

在忙碌的每一天，我們常常為了解決眼前事，忘記也要隨時看看長遠目標。不妨花點心思，偶爾為自己確保一個下午來好好思考人生目標，才能確定自己永遠是朝著最渴望的方向走。

人生只有一回，好好規劃，好好實踐吧！

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [面試攻略(二) 藏在自薦信 ( Cover letter) 裡的魔鬼](/posts/3skills-of-interview-2)
- [職涯原力：解開千千結的邏輯力](/posts/career-power-logic)
- [想當工程師？學寫程式，只有這件事最重要！](/posts/to-be-an-engineer)

post-職涯原力：善用企劃力，為自己的生命校正 / cover

職涯原力：善用企劃力，為自己的生命校正

Cover Letter ，又稱自薦信，是左右投履歷時面試官第一個接觸你印象的重要工具。
教求職者寫履歷的文章很多，教寫自薦信的相對卻少了不少。其實自薦信對於是否能獲得面試邀約至關重要，五倍紅寶石今天就來幫你揭秘，為什麼自薦信如此重要。

自薦信正如同你在認識新朋友時，給對方的第一印象。他是履歷的精華版，必須要一眼就讓要約面試的人資對你產生好奇。

常見的自薦信錯誤如下：
## 1.太過求職者角度出發

![post-面試攻略(二) 藏在自薦信 (Cover letter) 裡的魔鬼 / sample-2](//images.ctfassets.net/8er52l3j5u76/3KjkNCrMpJMPk3mJIYXjkn/58259de28ea3cf67cfcded987da4afc3/sample.png)

撰文時只著重於自己的感覺：「有興趣」「很好玩」，會給人資一種「訊息與本職缺無關」的感覺。要表達對本職缺熱情的時候，不要忘記加上「對這個職務的不可或缺性」，才能抓住人資的眼球，願意點開你的履歷，用更多時間來認識你，甚至發出面試邀請。
 

## 太短或太長

對人資來說，一天會收到的履歷從幾十封到上百封都有可能。太短的自薦信無法讓人印象深刻，而太長的自薦信則是為人資增加閱讀的困難。若再合併下一點的問題，就很容易讓人資直接跳過。記住，自薦信最長也請落在300字，如果沒有辦法在30秒內朗讀完，那就是太長的自薦信。
 

## 自薦內容與職缺需求沒有直接相關

這裡我們用幾個合格範例和危險範例來說明：
 
 
《範例一》
> 目前任職OOOO，累積 2 年 B2C 、 B2B 電商行銷經驗。負責經營的渠道平均成長率最低可達 OO% 以上（詳情請見中文履歷或作品集）。除此之外我對 OOO（求職公司的領域）也有著極大的興趣。除了額外進修了本領域的知識外，也希望能有機會瞭解 OOO（求職公司的產品）。甚至期許自己能發揮所長，將這個產品（求職公司的領域及產品）推廣給跟我一樣有這種需求的初學者。
> 由於有平台端的行銷經驗，對產品安排宣傳、規劃廣告預算，甚至是使用 HTML 編輯 EDM 等，我相信我皆能在短時間內掌握這些工作內容。也希望有機會面試貴公司的「 OOOO 」一職，與貴公司一同打造最棒的服務，成為本產業的領航者。

以上這個範例，非常具體寫出他的專長以及與本職缺相關的興趣。且文章不會過長，很好閱讀。
 
 
《範例二》
> 主管您好，我叫 OOO，過去有超過三年的時間都在教授語言。大學的寒暑假期間做過許多行銷業務的工作，如：販售商品、展擔任銷售人員、資訊公司業務。對於科技新知一直都非常有興趣，貴公司是一個非常棒的環境能夠讓我學習。我願意發揮所長在貴公司擔任 OOO 一職，謝謝

人資心裡話：謝謝你願意發揮所長，可是我還沒有看到你的所長...
 
 
如果沒有相關經歷，切勿在自薦信裡曝露弱點，而是應該在自薦信裡提出為什麼你（雖然經歷不足），卻是最有潛力成為本職缺的適任者。可以主打你的人格特質，畢竟認真又積極的工作態度，再加上勤奮，沒有公司會不喜歡。
 
 
《範例三》
![post-面試攻略(二) 藏在自薦信 (Cover letter) 裡的魔鬼 / sample-2](//images.ctfassets.net/8er52l3j5u76/47RpiMcQHodNRs4L3CfTee/09dfd332de7fca59a45657ef6ca37a0e/sample2.png)
這種訊息雖然看似罐頭，卻用普世認可的成功價值當釣鉤引起人資好奇：「該求職者如何讓公司的收穫大於在他身上的投資？」因而點開了履歷。
 
 
《範例四》
有些人試圖加入一些創意，反其道而行：
> 關於OOO職位，我認為應有以下能力： 
> 一、文書作業能力 
> （下略300字，說明自己擁有的證照與文書作業能力） 
> 二、溝通協調能力 
> （下略二百字，說明如何溝通協調） 
> 三、積極求知、學習能力 
> （下略一百五十字，說明他的學習能力） 
> 四、團隊合作能力 
> （下略一百字，說明團隊合作學習能力） 
> 五、加分的英文能力 
> （下略五十字）
> 六、保持冷靜的能力
> （下略五十字）

這樣雖然也能吸引人資「喔？我來看看你的想法吧！」但因為落落長，簡直把自傳帶到自薦信裡來，也是需要盡量避免的。且如果人資不同意你提出的見解，也很容易造成「應該不適合」的先入為主觀念。

總而言之，自薦信磨的是「化繁為簡」、「抓重點」的功力，有些面試官也會從自薦信來判斷求職者的人格特質如何。不妨為每個機會各寫幾個版本，一方面磨練功力，一方面測試看看成效吧！

系列文章：

- [面試攻略(一) 初心者的三大面試攻略心法](/posts/3skills-of-interview)
- [職涯原力：善用企劃力，為自己的生命校正](/posts/career-power-planning)
- [職涯原力：解開千千結的邏輯力](/posts/career-power-logic)
- [想當工程師？學寫程式，只有這件事最重要！](/posts/to-be-an-engineer)

五倍紅寶石・專業程式教育機構

ASTRO Camp

線上課程

短期課程

技術文章

五倍消息

技術文章

原來 Rails Console 可以這樣用

機器戰警 RuboCop

還在跟複雜的 CSS 的設定奮鬥嗎？用 Tailwind 來幫你實現真正的高效整潔！

想當工程師？學寫程式，只有這件事最重要！

Vue.js 新手如何製作口罩地圖？一起來貢獻小小力量吧！

職涯原力：解開千千結的邏輯力

職涯原力：善用企劃力，為自己的生命校正

面試攻略(二) 藏在自薦信 (Cover letter) 裡的魔鬼

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

地址 | 10046 台北市中正區衡陽路 7 號 5 樓

專業課程

ASTRO Camp

線上課程

短期課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款