五倍直播間

Blogs - Sidebar


## 「在飯店上班時，看到外籍的工程師坐在吧台寫程式、遠端工作，當時就在想，我是否有一天也可以做得到？」

我是一個後端工程師，在成為後端工程師之前，我做的是 bartender， 在服務業待了接近六年的時間。

有些人會說：「你應該大學就是資訊相關科系吧～」其實，我大學原本唸的是德文，甚至因為家庭因素，大一唸完就休學去工作；後來下定決心轉職後，從初次接觸程式，到找到工作，前後大約是一年的時間。

轉職之前，我在飯店業工作了滿長一段時間，

那時候看主管們的生活就大概可以想像未來的發展，如果一直留在飯店做服務業，薪水很容易遇到天花板限制，即使做到主管階級，也是長時間被綁在飯店，甚至得住在飯店。

就覺得這不是我想要的，我理想的工作是能夠有自己時間能夠陪陪家人，做想做的事。

曾經跟家人、朋友討論過類似的想法，回饋大概是都是：

「你現在的工作不錯呀，五星級飯店欸，多少人想進去呀」

「那個 xxx 的女兒以前也是跟你一樣，熬過來以後薪水也是...」

「轉職成功的都是特例，你不能把特例作為自己的人生規劃...」

## 開始起步學寫程式時的想法很簡單：

我覺得「所有公司都需要網站」，所以就先從網站開發開始學起。

當時新創創業的風潮很盛行，技術的部分蠻多是採用可以快速開發的 Rails。

加上自己很嚮往在新創上班，又聽說會 Rails 的人很少，就選擇 Rails 做主力學習的目標。

最初在 Udemy 上面找了很多免費課程，但學起來散散的，很沒有系統。

例如：

叫你「把程式碼複製貼上」，貼一次、貼兩次，第三次自己手寫看看。原本跟著教材跑覺得很有趣，這樣拼拼湊湊竟然真的就做出了一個煞有其事的網站。但學到後面，發現自己只會套課程的模板、框架，對程式語言的特性和邏輯完全搞不清楚，沒有能力自己開發出想要的功能。當時真的超崩潰，心裡一直想「我的網頁會動，但我不知道為什麼！」甚至開始覺得自己可能真的不適合走程式這行吧 ⋯⋯

在網路上找技術文章的時候，有找到五倍紅寶石的高見龍（龍哥）在 iT 邦幫忙寫的 Rails 系列文。覺得寫得很清楚，蠻多疑惑有被解開，看他的文章才知道有五倍這個教育機構。後來發現他有開實體的基礎課程，抱著有點去見偶像的心情參加。我印象很深的是那次參加的課程，龍哥講到一句話突破了我的學習盲點：

「要知道程式如何思考，怎麼用程式思考的方式去寫程式、看程式。」

那天還重新聽了一次基本的 function、變數等等的概念。把許多之前上過課不懂的地方都連結起來，整個豁然開朗，後來也報名了他們的完整課程。

總之，他們的課對有程式底子的人來說怎麼樣我不知道，但我自己覺得對曾經自學卻卡住遇到瓶頸的人來說，非常有幫助！

## 轉職規劃

參加完課程後，我原先打算給自己一年的時間，花半年累積一些作品集，半年找工作。當時去上實體課程是 2017 年 10 月的事，因為自己是一邊學習、一邊還有工作，所以有想把戰線拉長一點。

可能是我當初問問題問得特別勤吧，老師們對我都蠻有印象的。課程結業沒多久，在 2017 年 12 月的時候，就受老師們的引薦，獲得了人生中第一個工程師職缺的面試機會，很幸運的，也在 2018 年 2 月的時候確定拿到 offer、3 月到新公司上班！

「當初預計會花一年的時間，最後從開始上課到拿到工作，只花了半年，順利從 bartender 轉職軟體工程師！（笑）」

而這一切會過的這麼順暢，主要原因有以下幾點：

### 1. 實務專案

許多跟我一樣半路出家的朋友，在轉職的路上走得不夠順的原因，就是他們沒有經歷過「真正的專案開發」。這就好像一個廚師他研究過很多食譜、知道每個規則，但從來沒有自己煮過菜一樣，這樣的工程師是很難找到工作的。仿間很多程式教育機構，雖然有協助工程師做專案，但是沒有業界的工程師協助「review」，對於品質與工作流程上，水準與業界的工程師還是有落差。

### 2. 作品集
強烈建議要花時間好好整理自己的「作品集」與個人頁面！

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/d0CD1loFd0kXyp88UKrLO/aa574c20d431b3908600307336350d0c/portfolio-1.png)

> 這是我當時求職的作品集，包含過去的作品、專案、和工作經驗（跟程式設計不相關，所以著墨的很少，基本上只寫單位、職位、期間）

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/4neySDt5BeQkqWPaCgQ9rT/8fec8b95aa4da41f8293dbd5df2bf89e/portfolio-2.png)

> 專案的部分，我把我負責的部分、有什麼功能，用 HR 也看得懂的方式表達

![post-轉職只是選擇，我從 Bartender 轉軟體工程師](//images.ctfassets.net/8er52l3j5u76/nxi7PA2iW2rAtxPVNqLgM/e248b74a58572542d44b36b659e0a2af/portfolio-3.png)

> 面試的時候，因為自己不是本科系而且跳很大，很多面試官都會問「動機」，因此我也獨立整理出來

根據以上這兩個點，五倍紅寶石近期有專門為了這兩個點，設計了全新的線下課程，可以參考。

最後想跟大家講分享一些我自己經歷學習到轉職這段時間後的體悟：

很幸運的，我在開始求職後的三個月找到工作，但同時，這樣的幸運來自於我全心投入轉職的準備與程式學習。

老實說，我覺得其實要轉職成功是真的很辛苦的，從準備成為工程師，到成為工程師，是充滿荊棘的一條路。

網路上許多轉職文章寫的感覺很輕鬆，但只是沒有把累的那一面寫出來。

可能蠻多人的想法是：現在工作薪水太低，想轉工程師得到好起薪，但「工程師」這條職涯選項，是必須一直不停學習的，否則技術推陳出新，真的會跟不上。

如果妳還卡在猶豫要不要轉職的階段，建議妳可以先從免費的課程開始，不論什麼語言，或是前後端。先跟著課程實作點東西出來，才知道自己是否可以接受寫程式。

也可以參加一些社群聚會，例如 [默默會](https://www.facebook.com/rubymokumokukai/) ，來這邊跟五倍的同仁詢問。

寫程式這件事，挫折感和成就感幾乎是一樣大的，想不出來時的挫折很大，但做出來的時候成就感也一樣大。

對真的想要轉職的人來說，重要的是要能禁得起挫折失敗。這段路上，一定是經過無數次的失敗，才終於把版排好、把功能寫出來。

就拿 Rails 當例子，有稍微接觸過 Rails 的朋友應該都一樣，最一開始讓人感到挫折的，就是陰魂不散的紅畫面！像我就不是很有耐心的人，每次看到都覺得很心煩 XD

但是該說幸好這個語言夠體貼嗎？反正 Rails 出錯的原因都會寫在畫面上，靜下心慢慢看，就能找出錯在哪裡。

真正的難關是「如何實作一個想要的功能出來」，這就攸關到你對語言原理的認識，以及如何操作、思考的流程。

以上都是比較辛苦面的說法啦，當然學程式寫程式，一定也是有快樂的地方。對我來說最快樂的時候，就是我順利解決一個又一個的 bug 的時候。還有看到網站上線的成就感，真的會覺得「啊～苦盡甘來！」

最後，總結以上：

1. 轉職是辛苦的，但結果是甜美的（以我自身的例子）
2. 專案一定要給業界工程師「review」過，才能從中獲得扎實的成長，縮短所學與業界的落差
3. 來 [默默會](https://www.facebook.com/rubymokumokukai/) 找已經在業界工作的人聊聊、與五倍紅寶石的課程團隊聊聊，或許會有不同的想法
4. 最近看到他們有在辦說明會，有興趣不如直接去現場看看吧：[ASTRO X 五倍紅寶石 全端工程師實戰訓練營](https://astro.5xruby.tw/)

post-轉職只是選擇，我從 Bartender 轉軟體工程師

轉職只是選擇，我從 Bartender 轉軟體工程師


這篇文章要討論的是 XML 格式的 sitemap，而不是有時在一些網站上會看到的『網站地圖』頁面內容（HTML sitemap），而 XML sitemap 內的 URL 資訊以及附帶的 metadata 主要功能在於幫助搜尋引擎暸解一個網站內的連結以及所對應的頁面的一些額外資訊（如：最後修改時間、修改頻率...等）。

最基本的內容大概會像下方範例。當中可以發現 `<url>` tag 裡除了 `<loc>` 為必要的資訊外其他都可以選擇性填入。而目前支援 [standard sitemap protocol](https://www.sitemaps.org/index.html) 的搜尋引擎包含了 Google、Yahoo!、Microsoft。

```xml
<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

   <url> # 第一組 URL

      <loc>http://www.example.com/</loc> # 必填

      <lastmod>2005-01-01</lastmod> # 選填

      <changefreq>monthly</changefreq> # 選填

      <priority>0.8</priority> # 選填

   </url>

   <url> # 第二組 URL

      <loc>http://www.example.com/blog</loc>

   </url>

</urlset>
```

## Sitemap 與 SEO

Sitemap 與 Search Engine Optimization (SEO) 之間的關聯，常見的迷思大概有：

* 做了 sitemap 網頁就能在搜尋結果頁中出現
* 做了 sitemap 能提升網頁在搜尋結果頁(SERP)中的排名
* 不做 sitemap 網頁還是會出現在 google

前面兩點，大概可以用『買了兩塊肋眼牛肉回家就會自動變成情人節晚餐』比擬，而 [sitemap.org](https://www.sitemaps.org/index.html) 的說明是：

> Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling ... (略) ... so that search engines can more intelligently crawl the site.

當中說明了 sitemap 的作用在於讓搜尋引擎知道網站的存在以及當搜尋引擎在爬網站時能夠更有效率。這裡有兩個重點：

* **available** for crawling 意思是告訴搜尋引擎網站的 sitemap 已經準備好了，但不保證搜尋引擎的 crawler 什麼時候會爬
* **crawl** 不等同 **index** 。意即，搜尋引擎爬了也不保證會收錄，即使收錄也與 SERP 排名沒有直接關係

關於迷思的最後一項，確實，即使不做 sitemap ，網頁也是有機會被爬並出現在SERP。

#### 那...為什麼還要做？

搜尋引擎爬網站的速度與頻率，如同很多其他 SEO 因素，沒有標準答案。然而國外有些實驗比較網站沒有 sitemap 與有 sitemap 時搜尋引擎爬的速度差異，當中有一個[實驗](https://neilpatel.com/blog/google-index/#step_7)測出結果是，有 sitemap 時，搜尋引擎平均爬的時間是14分鐘，而沒有 sitemap 時是1,375分鐘。

相較於其他 SEO 因素，Sitemap 在提升排名方面或許沒有太大的幫助，但可以確定的是可以加快網頁被爬的速度。畢竟，在進一步優化 organic traffic 前先確保網頁出現在 SERP 會比較好。

## 在 Rails Web App 上實作 sitemap

以下是這次簡易實作範例的範圍，sitemap 部分使用 [sitemap_generator](https://github.com/kjvarga/sitemap_generator) gem。

1. 建立新專案、新增 articles CRUD
2. 產生部落格首頁與文章頁的 standard sitemap
3. 新文章產生後動態更新 sitemap
4. 提交 sitemap

### 建立新部落格專案、新增 blog CRUD

建立專案

``` shell
$ rails new index_me_google
$ cd index_me_google
$ rails db:create
```

因為是為了練習 sitemap，快速 scaffold 出 `Article` ，欄位部分就只給了一個 `title`。

``` shell
$ rails g scaffold Article title
$ rails db:migrate
```

另外設定一下首頁路徑

``` ruby
# routes.rb
root 'articles#index'
resources :articles
```

在 console 裡建立一些 articles

``` ruby
(1..5).each{ |num| Article.create(title: "article-#{num}")}
```

### 產生部落格首頁與文章頁的 standard sitemap
`sitemap_generator` 功能相當完整，從壓縮、ping 搜尋引擎這類貼心功能到支援 sitemap extensions（news, video ... 等），如果不是太奇特的需求，基本上這個 gem 都能幫忙做到。

安裝

``` ruby
# Gemfile
...
gem 'sitemap_generator'
...
```

產生設定檔

``` shell
$ rails sitemap:install
```

完成後會發現 `config` 資料夾下多了一個 `sitemap.rb` 檔案。初始檔案裡面只有幫我們預設一個 `default_host` 選項還有一個空的 create block。

``` ruby
# config/sitemap.rb
SitemapGenerator::Sitemap.default_host = "http://www.example.com"

SitemapGenerator::Sitemap.create do

end
```

`sitemap_generator` 產出的 sitemap 預設為壓縮檔，為了方便檢查之後產出的 xml 檔案內容，在開發階段通常我會將 `compress` 選項改為 `false`，另外記得將 `default_host` 改成自己的 domain。

``` ruby
# config/sitemap.rb
SitemapGenerator::Sitemap.default_host = "http://www.index.me"
SitemapGenerator::Sitemap.compress = false
...略...
```

接下來，在 create block 內加入我們想要放入 sitemap 內的 URL。

``` ruby
# config/sitemap.rb
...略...
SitemapGenerator::Sitemap.create do
  Article.find_each do |article|
    add article_path(article), lastmod: article.updated_at
  end
end
```

在操作上相當簡易， `add` 方法接收的第一個參數是路徑，第二個是 hash 選項，預設的選項為：

``` ruby
{ priority: 0.5, changefreq: 'weekly', lastmod: Time.now, host: default_host }
```

可以留意的是， crawlers 不一定會因為我們把 `priority` 設為 `1` 或 `changefreq` 設為 `always` 就增加重爬的頻率，把這些數值想成是給 crawlers 做決定的線索就好。另外，雖然有預設值，前三個選項不一定都需要（如：google 目前不採用 priority），可以視情況調整使用。

執行 `$ rails sitemap:create` 後產生一個 `sitemap.xml` 檔案，預設位置在 `public` 資料夾下。直接開瀏覽器檢查一下（localhost:3000/sitemap.xml）。設定正確的話會發現除了所有 article 的 URL 被寫入外，額外附贈 root `http://www.index.me`，如果不想要的話需要將設定選項 `include_root` 改為 `false`。

```xml
<urlset>
  <url>
    <loc>http://www.index.me</loc>
    <lastmod>2019-02-13T16:45:39+08:00</lastmod>
    <changefreq>always</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>http://www.index.me/articles/1</loc>
    <lastmod>2019-02-13T05:14:31+00:00</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.5</priority>
  </url>
  <url>
    <loc>http://www.index.me/articles/2</loc>
    <lastmod>2019-02-13T05:14:31+00:00</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.5</priority>
  </url>

  ...略...

</urlset>
```

### 新文章產生後動態更新 sitemap
到目前為止，我們成功為『現有』的 articles 建立 sitemaps，但像是部落格文章或者是新聞之類不定期會新增或的動態頁面也需要 sitemap。比較常見的做法有使用 cron jobs 定時更新 sitemap，或者在頁面新增後立刻更新。

如果使用 cron jobs，可以參考搭配 [whenever gem](https://github.com/kjvarga/sitemap_generator#crontab) 使用；如果是後者， `sitemap_generator` 提供了對應的方法：

```ruby
class ArticlesController < ApplicationController

  ...略...

  def create
    @article = Article.new(article_params)

    respond_to do |format|
      if @article.save
        # 建立 sitemap
        SitemapGenerator::Interpreter.run(config_file: Rails.root.join('config', 'sitemap.rb'))
        # ping 搜尋引擎
        SitemapGenerator::Sitemap.ping_search_engines

        ...略...

      end
    end
  end

  ...略...

end
```
這樣基本上就能達到新增頁面後立即更新 sitemap 的效果，但建議可以把相關的行為用一個 job 處理。

### 提交 sitemap
在提交 sitemap 到搜尋引擎之前，還要準備一個置放在 server 頂層資料夾的 `robots.txt` 檔，作用在於指示 crawlers 該如何爬網站，當中也包含了提供 sitemap 位置的資訊（暸解更多關於 [robots.txt](https://moz.com/learn/seo/robotstxt) 使用方式）。 這裡只簡單做出允許所有搜尋引擎爬站並提供 sitemap 位置。

```txt
User-agent: *

Sitemap: http://www.index.me/sitemap.xml
```

以下使用 [Google Search Console](https://search.google.com/search-console) 為例提交 sitemap。

如果是第一次使用，必須先新增網站並驗證所有權。另外，新版的 google search console 沒有提供提交前測試的功能，如果有需求可以切到舊版使用。

填寫 `robots.txt` 網址測試

![post-使用 Sitemap 打好網站 SEO 基石](//images.ctfassets.net/8er52l3j5u76/1Vvoe59UySp5V1Dww858Xv/25e7494a5878583be13a64610d798a5b/hFfVjh5.png)

填寫 `sitemap.xml` 網址測試，如果測試結果正常，就可以正式提交了！過一段時間再回來 search console 就可以看到網頁被收錄的狀態。

![post-使用 Sitemap 打好網站 SEO 基石](//images.ctfassets.net/8er52l3j5u76/7o8mDeaug56JdJkJWP4GAr/2f48cc7ac65ea0ecbf1bd4ba6e183b20/pbMRbzJ.png)

## 結語
Rails 搭配 sitemap_generator 實作 sitemap 並不困難，所需時間成本也不高。雖然對於網站 SEO 沒有什麼直接加分的效果，個人會比較用『有好無壞』以及『SEO第一步』的角度看待。另外，如果有多餘心力，建議可以研究 [sitemap extensions](https://support.google.com/webmasters/answer/183668#extensions)，增加網頁在搜尋引擎的足跡。

---

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


post-使用 Sitemap 打好網站 SEO 基石

使用 Sitemap 打好網站 SEO 基石


專案中很常出現按鈕點下跳出 "確認視窗" 的行為，有時候是刪除的警告確認、有時候是資料送出的確認。這些有共同操作行為的 Component 都應該做成共用的元件以方便在各種情況下重複使用， 才不會某 A 做一個版本，某 B 做另一個版本，大家都自己寫自己的造成維護上的困難。

此文章不會詳細列出各項程式碼，如果有興趣可以 clone [source code](https://github.com/treekey999/react-promise-modal-example) 下來研究研究。

封面圖來源：[https://mrdoob.com/lab/javascript/effects/ie6/](https://mrdoob.com/lab/javascript/effects/ie6/)

---

期望可以用以下程式碼達到我要的目的：

```jsx
import React from 'react'

import { confirmBox } from './promiseModal'

class App extends React.Component {
  render() {
    <button
      onClick={() => {
        confirmBox({
          title: 'Logout',
          description: 'Are you sure to logout?',
        }).then(() => {
          console.log('Confirm, Do some logout action...')
        }).catch(() => {
          console.log('Cancel, Nothing happened...')  
        })
      }}
    >
      Logout
    </button>
  }
}

```

`confirmbox` 執行並帶入客製化 params，期望最後會回傳 `promise` 物件，並由 `.then()` 或是 `.catch()` 來知道使用者點下 `Confirm` 還是 `Cancel` 再做後續的動作。

---

### 實作步驟分析

* 準備一個基本的 popup modal component（確認視窗）。

* 因為 modal 是一個蓋版視窗，使用者必須要按下 `Confirm` 或 `Cancel` 按鈕才能繼續操作，所以選擇使用 `Promise` 物件來等待使用者按下按鈕。

* 執行 `confirmBox` 的時候，預期會 create 一個 `promise` 物件，並在裡面將 React Component 掛載到某個 div 上面(`ReactDOM.render`)，並將 `resolve`、`reject` function 當作 props 一併傳到 modal 中使用。

* 因為 modal 擁有了 `resolve`、`reject` 這兩個可以繼續 `promise` 的 function，所以可以在按下 `Confirm` 按鈕的時候呼叫 `resolve`，按下 `Cancel` 按鈕的時候呼叫 `reject` 來達成 `Promise Chain` 的目的。

* 無論按下哪一個按鈕後都應該要清除、卸載，動態掛上去的 React Component。

* 以下解說都會省略 css code, 有興趣可以看 [source code](https://github.com/treekey999/react-promise-modal-example/commits/master)

---

### Step 0. 準備範例按鈕

```jsx
class App extends Component {
  render() {
    return (
      <div className="App">
        <button
          type='button'
          className='btn-example logout'
        >
          Logout
        </button>

        <button
          type='button'
          className='btn-example submit'
        >
          Submit
        </button>

        <button
          type='button'
          className='btn-example delete'
        >
          Destroy
        </button>
      </div>
    );
  }
}
```

![post-React Promise Modal](//images.ctfassets.net/8er52l3j5u76/7ELSNkT1Mp68uD5EOFVEW0/5db4be62d877273c8c463acc58ad802c/hChnSKR.png)

---

### Step 1. 準備基本 popup modal

使用 [react-modal](https://github.com/reactjs/react-modal) 來快速建造一個確認視窗的 modal。

```jsx
import React, { useState } from 'react'
import PropTypes from 'prop-types'
import Modal from 'react-modal'

const ConfirmBox = (props) => {
  const {
    color, // 客製化顏色
    title, // 客製化文字
    description, // 客製化文字
    onConfirm, // 預期收到 resolve function
    onCancel, // 預期收到 reject function
    confirmText, // 客製化文字
    cancelText, // 客製化文字
  } = props

  // `useState` 是 react 16.8 新功能 hooks, 等同於 state/setState 效果
  // 初始值為 true
  const [isOpen, setIsOpen] = useState(true) 

  const onClickConfirm = () => {
    // 按下 Confirm 將 modal 關閉, 並執行 onConfirm (resolve function)
    setIsOpen(false)
    onConfirm()
  }

  const onClickCancel = () => {
    // 按下 Confirm 將 modal 關閉, 並執行 onCancel (reject function)
    setIsOpen(false)
    onCancel()
  }

  return (
    <Modal
      overlayClassName='promise-modal-overlay'
      className='confirm-box'
      isOpen={isOpen}
      onRequestClose={onClickCancel} // 點下 modal 之外的區域時觸發 (modal overlay)
      shouldReturnFocusAfterClose={false}
    >
     <div className={`modal-container color-${color}`}>

      <div className='modal-header'>
        <h3>{ title }</h3>
        <button
          type='button'
          className='close-btn'
          onClick={onClickCancel}
        >
          X
        </button>
      </div>

      <div className='modal-content'>
        <p>{ description }</p>
        <div className='button-list'>
          <button
            type='button'
            className='cancel'
            onClick={onClickCancel}
          >
            { cancelText }
          </button>
          <button
            type='button'
            className='confirm'
            onClick={() => onClickConfirm()}
          >
            { confirmText }
          </button>
        </div>
      </div>
     </div> 
    </Modal>
  )
}

```

測試一下剛剛做的 Component Render 有沒有正確，丟到測試頁面看看 js/css 有沒有正確。

![](https://i.imgur.com/v5jsT8W.png)

---

### Step 2. 製作 Promise function

流程可以拆分為以下：

  * 動態產生不重複的 div element，為了讓 `ReactDom.render` 掛載上去。
  * new 一個 `Promise` 物件，並在第一個 promise 裡面將 `Modal Component` 掛載上去。
  * 成功 render React Modal 之後就會在介面上看到蓋版 Modal，並等待使用者按下按鈕之後接續呼叫 `resolve`、`reject` function。
  * 卸載、移除先前動態產生的 Component、Element。

```jsx
import React from 'react'
import ReactDOM from 'react-dom'
import Modal from 'react-modal'

// 卸載、移除先前動態產生的 Component、Element
const unsetPromiseModal = (wrapper) => {
  setTimeout(() => {
    ReactDOM.unmountComponentAtNode(wrapper)
    wrapper.remove()
  }, 300)
}

// 動態產生不重複的 div element
const findOrCreateWrapper = (identifyID) => {
  let wrapper = document.getElementById(identifyID)
  if (wrapper === null) {
    wrapper = document.body.appendChild(document.createElement('div'))
    wrapper.id = identifyID
  }
  return wrapper
}

// params 預期接收要被掛載的 Component, 跟客製化 options
const promisableModal = (Component, options = {}) => {

  // 動態產生不重複的 div element
  const wrapper = findOrCreateWrapper(`promise-modal-wrapper-${Date.now()}`)

  // 無障礙網頁辨識用, 參考：http://reactcommunity.org/react-modal/accessibility/#
  Modal.setAppElement(wrapper)

  const promise = new Promise((resolve, reject) => {
    ReactDOM.render( // 掛載 React Component
      <Component
        {...options} // 帶入客製化參數(props)
        onConfirm={resolve} // resolve 傳給 onConfirm
        onCancel={reject} // reject 傳給 onCancel
      />,
      wrapper,
    )
  })

  return promise.then(() => {
    // 使用者按下 Confirm 之後執行此段
    unsetPromiseModal(wrapper)
    return true
  }, () => {
    // 使用者按下 Cancel 之後執行此段
    unsetPromiseModal(wrapper)
    return Promise.reject(false)
  })
}

export default promisableModal

```

由於最後回傳的是一個 `promise` 物件，如果接續著呼叫 `.then()` 會在使用者按下 `Confirm` 後接續執行；如果接續著呼叫 `.catch()` 會在使用者按下 `Cancel` 後接續執行。

---

### Step 3. 組合

```jsx
import './style.scss' // base modal overlay csss

import promisableModal from './promisableModal'
import ConfirmBox from './components/ConfirmBox'

// 將 ConfirmBox 和 promisableModal 做組合
const confirmBox = props => promisableModal(ConfirmBox, props)

export {
  promisableModal,
  confirmBox,
}
```

因為已經寫好了可以 `promisable` 的 function，所以未來如果想要擴充其他種類型的 modal，都可以透過 `promisable` 輸出，例如未來我如果想做一個編輯蓋版視窗：

```jsx=

... 省略

import EditBox from './components/EditBox'

const editBox = props => promisableModal(EditBox, props)

export {
  promisableModal,
  confirmBox,
  editBox, // 新的擴充
}

```

---

### Step 4. 使用

三種不同情境的確認視窗，都只要呼叫同一個 promise function 來達成目的，達到 reuse 的目的。

```jsx
import React, { Component } from 'react'
import './App.scss'

import { confirmBox } from './promiseModal'

class App extends Component {
  render() {
    return (
      <div className="App">
        <button
          type='button'
          className='btn-example logout'
          onClick={() => {
            confirmBox({
              color: 'primary',
              title: 'Logout',
              description: 'Are you sure to logout?',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to logout ...', 'color: blue')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: blue')
            }) 
          }}
        >
          Logout
        </button>

        <button
          type='button'
          className='btn-example submit'
          onClick={() => {
            confirmBox({
              color: 'info',
              title: 'Submit Form',
              description: 'Are you sure to submit form?',
              confirmText: 'Submit',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to fetch data to backend api ...', 'color: green')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: green')
            }) 
          }}
        >
          Submit
        </button>

        <button
          type='button'
          className='btn-example delete'
          onClick={() => {
            confirmBox({
              color: 'danger',
              title: 'Delete Product',
              description: 'Are you sure to delete this product?',
              confirmText: 'Delete',
            }).then(() => {
              console.log('%c Click Confirm!, prepare to fetch data to delete product ...', 'color: red')
            }).catch(() => {
              console.log('%c Click Cancel!, nothing happened ...', 'color: red')
            }) 
          }}
        >
          Destroy
        </button>
      </div>
    );
  }
}
```

![](https://i.imgur.com/acalG7Y.gif)

---

Don't Repeat Yourself，這個範例的元件在我先前的幾份專案中都有用到，而且都只是複製最初的那一份出來調整 css 而已。

寫 React 的時候不妨思考一下專案中哪些是常常共用的元件，試著練習抽離出來做成 shared component，會省下未來不少時間。

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 React 觀念和原理嗎？
>
> 我們有開設 💠 [React 全攻略入門班](https://5xruby.tw/courses/react) 課程唷 ❤️️
>


post-React Promise Modal

React Promise Modal


[calc()][0] 是一個 CSS function 作用於屬性設定是數值的時候可以進行加減乘除的運算，例如： `<length> 長度`、`<frequency> 頻率`、`<angle> 角度`、`<time> 時間`、`<number> 數字`或者是 `<integer> 整數`這幾個屬性值都可以使用 `calc()`。

```css
/* property: calc(expression) */
/* 屬性: calc(運算式) */
width: calc(100% - 50px);
```

## calc() 語法

calc() 這個 function 需要傳入 1 個加減乘除的運算式，在設定 `width`、`height` 這種 \<length\> 相關的屬性時， 在不同單位間也可以進行運算，如剛剛上面的範例：`width: calc(100% - 50px);`。calc() 的運算式一樣是按照先乘除後加減進行計算，如果需要進行複雜的運算，在 calc() 裡面也可以再加入括號 `()`，就可以設為括號先決裡面的先算。

- `+`：加
- `-`：減
- `*`：乘。其中一個運算參數必須是數字 (number)
- `/`：除。除數必須是數字，除數不可為零，會造成 HTML 解析錯誤。

必須注意在使用 + 和 - 的時候，在前後一定要加上空白，不然會被誤為是給了個負值。* 和 / 可以不用加，但為了格式統一方便和閱讀建議還是加一下。

```css
width: calc(50% + 8px)
/* 意思是 50% 的寬度 + 上 8px */
width: calc(50% + -8px)
/* 意思是 50% 的寬度 + 上 -8px，也等於 '50% - 8px' */
```

## Example 應用範例

### 定位

calc() 可以用來定位，如下面所設定的 CSS，就能作出一個滿版的藍色 banner 區塊有固定 40px 的邊距，也是一種將區塊置中的寫法。

```css
.banner {
  position: absolute;
  left: calc(40px);
  width: calc(100% - 80px);
  background-color: #6C92AF;
  padding: 6px 0;
  text-align: center;
  color: #FFF;
}
```

```html
<div class="banner">Hello banner/div>
```

<p data-height="265" data-theme-id="light" data-slug-hash="PEgoZq" data-default-tab="css,result" data-user="fokayx" data-embed-version="2" data-pen-title="CSS_calc" class="codepen">See the Pen <a href="https://codepen.io/fokayx/pen/PEgoZq/">CSS_calc</a> by fokayx (<a href="https://codepen.io/fokayx">@fokayx</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://production-assets.codepen.io/assets/embed/ei.js"></script>

### 根據父層容器尺寸自動調整尺寸

設定 width 或 height 屬性使用 calc() 計算的數字是 100% 的時候，會自動去抓父層容器的尺寸。例如：做 autocomplete 的時候，希望在輸入框下，出現和輸入框等寬的列表：

```css
.container1 {
  width: 30%;
}

input {
  width: 100%;
  padding-left: 1rem;
  padding-right: 1rem;
  padding-top: 1rem;
  padding-bottom: 1rem;
  margin: 0;
  border-left: 2px solid #6c92af;
  border-right: 2px solid #6c92af;
  border-top: 2px solid #6c92af;
  border-bottom: 2px solid #6c92af;
}

ul {
  background-color: #6c92af;
  margin: 0;
  padding: 0;
  width: calc(100% + 1rem + 1rem + 2px + 2px);
  color: #FFF;
  list-style: none;
}
```

```html
<div class="container1">
  <input placeholder='container1'/>
  <ul>
    <li>show item 1</li>
    <li>show item 2</li>
    <li>show item 3</li>
  </ul>
</div>
```

由於 CSS 在加上 border、padding 的時候都是從原本設定得尺寸再往外加，所以長出來的東西看起來的尺寸會比原本設定的 width 還要大，因此要做到 ul 和 input 等寬的結果，在 input 加上的 padding 和 border 在算 ul 的 width 的時候也要幫他算進去，所以 `ul { width: calc(100% + 1rem + 1rem + 2px + 2px); }` 指的是：符合父容器的 100% 寬度，加上 input 的 `padding-left: 1rem` 和 `padding-right: 1rem`，再加上 `border-left: 2px` 和 `border-right: 2px`。用 calc() 計算尺寸非常方便，即使不同單位也沒有問題。如：codepen 第一個區塊。

如果在 ul 有設定 border、padding，ul 自己也會長大，在 calc() 計算的時候就必須扣掉這部份，例如：codepen 第二個區塊。

```css
.container2 {
  width: 30%;
}

.container2 input {
  width: 100%;
  padding-left: 1rem;
  padding-right: 1rem;
  padding-top: 1rem;
  padding-bottom: 1rem;
  margin: 0;
  border-left: 2px solid #6c92af;
  border-right: 2px solid #6c92af;
  border-top: 2px solid #6c92af;
  border-bottom: 2px solid #6c92af;
}

.container2 ul {
  background-color: #6c92af;
  margin: 0;
  padding: 0;
  border: 1px solid #212c35;
  width: calc(100% + 1px + 1px);
  color: #FFF;
  list-style: none;
}
```

```html
<div class="container2">
  <input placeholder='container2'/>
  <ul>
    <li>show item 1</li>
    <li>show item 2</li>
    <li>show item 3</li>
  </ul>
</div>
```

<p data-height="265" data-theme-id="light" data-slug-hash="JMqyyP" data-default-tab="css,result" data-user="fokayx" data-embed-version="2" data-pen-title="css_calc_ex2" class="codepen">See the Pen <a href="https://codepen.io/fokayx/pen/JMqyyP/">css_calc_ex2</a> by fokayx (<a href="https://codepen.io/fokayx">@fokayx</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://production-assets.codepen.io/assets/embed/ei.js"></script>

### 將 calc() 巢狀包入 CSS 變數中

只要用括號 () 包好包滿，就可以無限次使用 calc() 方法，會一層一層從括號裡面計算出來。

```css
.foo {
  --widthA: 100px;
  --widthB: calc(var(--widthA) / 2);
  --widthC: calc(var(--widthB) / 2);
  width: var(--widthC);
}
```

在上面這段程式碼裡面展開所有變數之後 widthC 就等於：

`--widthC: calc( calc( 100px / 2) / 2)`

所以 .foo 的 width 最後算出來的值就是 25px。

[0]: https://developer.mozilla.org/zh-TW/docs/Web/CSS/calc 'calc at mdn'

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 HTML / CSS 觀念和原理嗎？
>
> 我們有開設 🪁 [HTML 網頁設計新手村](https://5xruby.tw/courses/html) 課程唷 ❤️️
>


post-CSS： calc() 數值運算 / css calc xuemei

CSS： calc() 數值運算

最近因為參加聚會聽到了在不同領域擔任專案管理的分享，談到專案管理過程中幾個共通的問題，剛好趁這個機會，想回顧一下，這兩年內學會了什麼，心態上又改變了什麼？於是整理出五件我覺得改變我工作方式的重要小事

1. 事情分輕重緩急，追蹤問題
2. 學習談判，細心與耐心
3. 專案的建議，但把選擇權交回客戶
4. 建立團隊從小原則開始
5. 抓好時間管理，讓客戶感受到被重視

### 1. 事情分輕重緩急，追蹤問題

> 剛開始做 PM 工作的第一個月，每一封信每一個對話我都回的戰戰兢兢，深怕遺漏掉任何事情，只要客戶一問「這東西進度怎麼樣啦？」我就會緊張的跑到工程師旁邊問他所以進度怎麼樣，弄的大家都很緊張...

雖然說工作上是以客為尊，快速的回應會讓顧客有好印象，但若只為了這樣而中斷自己甚至工程師的工作時，就可以停下來想一下客戶提出來的問題是不是真的這麼的迫切？

適時的讓客戶知道，我們已經收到你提出來的疑問了，並且會盡快為他處理這些問題
也因此 PM 身上也會一串長長的追蹤事項，每天固定找一個時間，重新檢視一次今天需要追蹤的問題，把處理掉的問題劃掉，

### 2. 學習談判，細心與耐心

PM 其中一個重要的工作在於如何溝通協調，對外我們要判斷需求，並適時的給予客戶專業建議、對內需要學著跟工程師協調任務的先後順序，這也是為什麼大家常說 PM 學著說不同的話，在面對不同領域的人有著不一樣的腦袋，如何聽懂對方的話、使彼此交流順常，找出最適的解決方案，溝通是專案管理最重要的軟實力。

關於協調與談判，我自己的心得是可以從耐心的傾聽以及換位思考開始練習，在 <卡內基溝通與人際關係：如何贏取友誼與影響他人> 書中，戴爾‧卡內基（Dale Carnegie）曾提到，假如你在職場上只學會一樣東西，就是能從自己與別人的角度思考、去看事情，那很有可能是你人生、事業成功的踏腳石。

### 3. 專案的建議，但把選擇權交回客戶

>「這樣不行，那樣不好，不然你告訴我你覺得怎麼樣才行？」

從第二點延伸，許多時候客戶會提出不太明確的需求或是天馬行空的想法，在我們傾聽完客戶的需求後，對於一些複雜的需求我們可能將需求帶回去在和工程師討論可行的方案，而最後我們可以怎麼呈現給客戶？

在想解決方案的過程中透過換位思考的方式，重新站在客戶考量他的需求，這裡的需求有時不單只是產品需求，還有成本、時間的考量也要加在這當中，透過提案的方式，列出可行的解決方案的優缺點後、需要開發的時間、成本後，將最後的選擇權交回給客戶。

透過良好的表達方式呈現我們解決問題的專業，同時也尊重客戶的選擇，除了能把問題解決之外最重要的是贏得客戶的信任。做 PM 給我一個很大的訓練是，我們得先聽懂並且了解對方的需求，在以專業的建議表達自己的需求，從中找尋交集的解決方式，就可以創造雙贏。

### 4.  建立團隊從小原則開始

理想上我們都希望能待在一個好的團隊，團隊裡的成員會自發性的去學習、並且積極地完成工作。但有時就算很幸運的遇上一群擁有很高熱忱的成員，若能有一些小的原則在這團隊當中發酵，更能將大家的力量凝結起來，發揮團隊最大的作用。

我覺得可以從每日的站立會議開始

站立會議其實是 Scrum（敏捷軟體開發過程）中的一部份，但我自己的心得是不一定只能用在 Scrum 的專案中 (畢竟不是每個專案都適合 scrum) ，每日的站立會議，能夠讓團隊成員有更多時間專注在工作上，同時也讓 PM 更輕鬆、即時地掌握實際情報

有效的站立會議我覺得有幾個要點：

  *  每天固定的時間
  *  會議時間不超過 15 分鐘
  *  一次只有一個人發言，並只針對三個重點說明，包括「昨天完成了哪些任務」、「今天的預計要執行的任務」、「碰到的問題」
  *  遠端的工程師可使用一些視訊軟體輔助，一樣可以參加站立會議

PM 在這當中有點像是引導者，透過發問的方式，讓團隊成員們慢慢的熟悉站立會議的模式，同時也讓自己更能掌握實際的狀況。

### 5. 要讓客戶感受到被重視

由於 PM 身上可能會不只處理一個專案，如何在不同專案之間做好顧客關係管理，我想很大一部分跟時間管理有關係。

在第一點時我提到了事情要分輕重緩急，分完後依序地處理每件事情之外，另外也可以透過一些工作摘要整理成進度跟客戶做回報，表現出主動追蹤處理問題的態度，重點式的回報進度給客戶，客戶在知道專案狀況後通常會比較放心。

許多時候 PM 除了專注於管理專案的進度之外，也需要服務客戶的心理狀態，讓客戶放心也感受到備受重視

### 最後，我對 PM 工作的想法

專案管理有趣卻也困難的是在於許多事情沒有完美或唯一正確的解答，只有能被大家接受的解決方法，當 PM 需要學會在這灰色地帶中透過有效的溝通作出決定，並學習接受現實世界中不可能滿足所有人的狀況下，如何使專案能夠向前推進。


preview stefan-stefancik-257625

專案管理起步走：五件重要的小事


之前曾經寫過一篇我們公司專案使用敏捷開發的案例，當時我們在預期的時間讓 MVP 的產品能夠上線，讓敏捷開發的價值得底被證明。不過這一次我想從另一個同樣是跑敏捷開發卻跑的不盡理想的專案中，重新探究敏捷開發的價值。

專案的背景是與國外企業的 RD 部門將部分的產品委外給我們開發，產品的規劃、設計由他們主導，我們只要負責好開發的部分，聽起來是非常單純的委外開發。但短短的半年期間，雙方經歷過多次的調整，才終於催生出產品進到使用者測試的階段。

### 溝通的高牆

敏捷開發宣言裡提到：個人與互動重於流程與工具

在最剛開始接下這專案時，負責管理我們的是客戶公司（以下簡稱Ａ社）的 Tech Lead 以及負責這個產品的 Product Manager、Product Owner，我們與其他 RD 的溝通幾乎是零。

我們走我們的 Scrum，他們走他們的 Scrum，只有 Tech Lead 和 PM 知道雙方在做什麼。
這樣延伸出來的主要問題是功能開發的速度會變的緩慢。

在一個有打算做跨部門的組織裡，要讓這件事情得以實現，我想還是需要讓對於同一功能再進行開發的相關人員有能夠溝通的管道，不然的話兩個團隊各做各的狀況其實還是一種 waterfall 的流程，只是裝上了敏捷開發流程的殼。

當時為了解決這個問題，Ａ社的新 CTO 在剛上任時找了我們幾位同事到他們公司一起共事幾天，和他們一起每日站立會議，確實與他們的工程師面對面的溝通時，許多之前需要等待很長時間回應的狀況就馬上等到解決，但由於我們終究不是駐點的團隊，這一次的面對面溝通只是暫時化解當時正在開發功能上的一些問題，並沒有真正解決之前溝通的高牆。

### 小小的調整，讓問題提早被發現

舉例來說我們當時遇到的狀況是開發功能的流程是固定的，功能設計與圖完稿後才會進到功能開發，我們沒有機會可以對設計圖上問題提出改善建議，必須要照圖開發，直到一個不正確的功能被開發完成後再重新由 Product Manager 開新需求進行調整，理想上這雖然是一個完整程序，但開發者及設計師就會面臨一種時常在打掉重練的挫敗感，對產品而言則是不停地在累積技術債。

![post-從失敗案例重新思考敏捷開發價值](//images.ctfassets.net/8er52l3j5u76/YZvwV2YPJmVMCYRNUDTjy/8d065402c363e2c7ede151388dcf0271/WSH7bjP.png)

後來，針對上面提到的情境我們做了一點溝通上的調整，使得一些邏輯面上的問題在交付給客戶之前就能得到解決，雖然說交付給客戶之後，有一定的機率客戶會要求修改或調整功能，但至少工程師們在開發過程中就發現的邏輯問題能夠在交付給客戶前就得到討論，減少一些未來開發上所累積的技術債。

![post-從失敗案例重新思考敏捷開發價值](//images.ctfassets.net/8er52l3j5u76/TNL6tqgGxTEmwTxMyxbkS/706a5061943dc3457d92b492cd8b6cef/nkTtpPC.png)

### 不再只有單一對話窗口，多團隊看板開發

除了剛才提到一點流程上的改變，在我們回國後，CTO 下了一個決策，我們從一開始的 Scrum 換成了 Kanban 的管理方式。
過去不同團隊做的事情如果會相互影響到，很難在各自的站立會議中發現，因此非常倚賴 Tech Lead 來同步溝通個團隊的狀況，導致開發速度一直都很緩慢，大家都互相的等來等去，而且還不知道到底等的是誰。

改成看板開發後，以這家公司規模（工程師在20位以內）還可以在同一時間一起開會，主要由 CTO 擔任會議主持人瀏覽看板，因為不同部門的正在負責的票都在同一個看板上，Ａ團隊的票被 B 團隊影響著的狀態就能夠在看板上一目瞭然。

解決了之前不同團隊對於進度瞭解上的高牆。

### 持續堅持站立會議

站立會議是大家耳熟能詳在 Scrum（敏捷軟體開發過程）中的一部份。

在專案的這段時間內，不論有沒有和客戶那邊一起站立會議，我們自己這邊則是一直都有進行著，我想除了同步彼此的進度狀況，發現專案的問題、進度的問題、技術的問題之外，我另外有個心得是覺得站立會議同時還是一個建立團隊默契及感情滿重要的會議。

這個專案中有過幾次工程師上的人力調整，除了全職的工程師外也有一些 Remote 工程師在我們的團隊當中，透過每日的站立會議，讓新進的工程師或是無法常常面對面對話的  Remote 工程師們都有一段時間和其他團隊成員對話、溝通，能夠幫助他們更快地融入團隊中，這點是我覺得站立會議在敏捷開發中的另一個價值。

在這專案中，客戶有客戶團隊自己的開發腳步，站在外包團隊的角度正好可以觀察到這些事情，更加讓我體會到敏捷開發絕對不是單單只有那些原則、圖表和方法，還會牽扯到組織的文化及管理。我想要做到資深的管理者（或說 Scrum Master）需要有效且精準地找出組織問題的癥結點並加以改善，才能夠讓敏捷開發一直保有他敏捷的優勢，而不是只是流於形式。

post-從失敗案例重新思考敏捷開發價值/cover

從失敗案例重新思考敏捷開發價值

我大學是讀電子係偏光電類的，雖然都是理工科，但和程式是完全無關的，所以我根本也不會寫程式。

一直從電子系讀到電子所碩士畢業，但我根本就不喜歡當工程師，所以碩士畢業後，就跑到一家銀行當人力派遣領個 22k 的工作 (當時晚上在補英文) 待了 2 年有。後來又去到一家社團法人協會當秘書，是屬於兩岸交流相關的協會，因為有這個機緣，就會時常到大陸出差及開會，也透過這個機會，了解到兩岸對於資訊人才的需求是很大的。

為了公司勞心勞力的工作及加班，但在我的心中很明白，行政這類型的工作，對男生而言，很難當個專業技能更不可能靠這個吃一輩子及養家活口。在前年 7 月的時候，更被老闆一句話，就調離現職的工作崗位，更讓我決定了，一定要轉換跑道，脫離目前的環境。

## 想學程式的原因：想證明自己的極限在哪

我覺得我已經 34 歲了，一直對於未來都是很茫然的，同期的同學工作穩定，也都結婚有了小孩，真心覺得我怎麼會這樣 ? 因此同學會或聚餐之類的也都不參加，我覺得這是一件很丟臉的事，我心想難道真的就這樣了嗎?

那時正好看在網路上，看到一個全端網路開發的線上學習課程，一套課程就可以學到前後端網路開發技能，心想這根本是為我打造，因此就算是高達好幾萬塊，但我是抱著也許這就是我人生最後的機會了，因此就報名了。

從一開始每天利用下班後，獨自一人留在辦公室花 4 小時練習，週末至少花 10 小時寫程式，我很了解距離轉職工程師還是有一大段路要走，然而過程如何辛苦，我給自己的目標，要在一年左右的時間，一定順利正式轉職工程師。

## 這不是盡頭，而是另一個起頭
但是花了許多時間自學這個線上學習課程，由於並沒有沒有得到適當的回應，所以導致學習效果不好 (而且還不是只有我一個人這樣認為)，整個學習狀況遇到了瓶頸及失去動力，在加上 Demo Day 選拔的落選，讓我失落了一段時間。

很感謝同時期學習的同學，告訴我五倍紅寶石這家公司，要幫助我們重新建立對 Ruby on Rails 的信心，我便又開始長達 3 月個的實體課程學習，在這期間中我也把工作辭掉，把全部心力放在寫程式這檔事。心想，這次這次我真的拚了，除了到五倍上課外，其它日子就是一睜開眼睛就寫程式寫到睡覺，不出去玩、完全也不參加任何聚餐及各種活動，過年也不回外婆家，完全閉關苦練。

最後很順利的在去年 10 月，透過五倍的媒合機制，我終於順利正式轉職工程師，現職為前端工程師，但是現在的我，不管是下班還是假日，依然的不斷進修磨練我手上所會的技能，早日成為獨角獸 (一個精通 UI / UX 設計，還能同時進行前端和後端開發的厲害角色)。

在此感謝五倍的眾大神們，龍哥、蒼時、澤清、悉剛、Alan、KT、Sandy、典禎、Tea、Amos 及 Kuro 兩位老師還有同期的同學們及常被我打擾的助教們。

## 鼓勵想轉職的人 別再說：「我辦不到」
想要轉職是一件需要勇氣的事情，而實際去執行才是真正拿出勇氣的人，所以如果你跟我一樣也對轉職網頁工程師有興趣，記得隨時都可以開始，像我在 34 歲的年紀都可以了，我相信您也一定可以的 !過程中會遇到很多需要挑戰的地方，千萬不要忘記當初下這個決定的時候，那一個充滿勇氣與熱忱的自己，莫忘初衷 !

## 讓生命繼續發光發熱
在 2019 年的 1 月 15 日很順利的通過試用期考核，算是真正的踏入這個行業。接下來，我要以 senior 全端工程師為目標，在公司持續學習且能夠有更好的表現。

以下幾點和各位分享，希望會有幫助。

規劃達成目標的每一步：俗話說的好，不怕慢，就怕站。利用每天、每週、每月完成小目標的規劃，達到自我的成長。
在社群培養軟實力：積極參與社群活動，建立自己的網絡人脈。就好比在臉書上可以找到各式各樣的程式社群來加入，獲取新知。
撰寫部落格：平時多經營個人的 GitHub 和部落格，適時的輸出一些自己學程式的過程和心得。很多新創公司的老闆或是工程師們都在看 GitHub，他們透過這個平台，會了解您是否活躍地持續創造、進步、對社群貢獻。
善用網路資源：網路上學習資源很多，各式各樣的學習平台都有，最建議的是直接學習閱讀英文網站，來獲取最新知識。
五倍默默會：每週二的晚上，五倍都會有一個實體聚會，有關程式的任何問題及對於程式這條路的想法，都可以透過這裡獲得良好的解答。這聚會可能跟你想像的有一點不一樣，來就找個位置坐下來做自己的事，也歡迎上台分享自由與會眾交流，同時也希望大家可以「默默待在這邊就會了」。(截自默默會官網介紹)
就這樣分享給大家，也鼓勵自己繼續人生的另一段旅程。

原文出處為：[vita shela](https://medium.com/%E5%89%8D%E5%BE%80%E7%8D%A8%E8%A7%92%E7%8D%B8%E4%B9%8B%E8%B7%AF/34%E6%AD%B2%E6%89%8D%E9%96%8B%E5%A7%8B%E8%87%AA%E5%AD%B8%E5%AF%AB%E7%A8%8B%E5%BC%8F%E6%9C%83%E4%B8%8D%E6%9C%83%E5%A4%AA%E6%99%9A-%E7%9C%9F%E7%9A%84%E6%9C%89%E5%BF%83-%E6%B0%B8%E9%81%A0%E9%83%BD%E4%B8%8D%E5%AB%8C%E6%99%9A-91b46bcad9bb)

post-34 歲才開始自學寫程式會不會太晚？真的有心，永遠都不嫌晚。

34 歲才開始自學寫程式會不會太晚？真的有心，永遠都不嫌晚。


相信大家小時候都學過四則運算。以 Ruby 進行四則運算時，**整數**的加法、減法、乘法相當單純：

```
> 1 + 2
=> 3

> 9 - 2
=> 7

> 3 * 2
=> 6
```

為什麼要強調整數呢…因為換成**浮點數**的話就會混進奇怪的東西 XD

```
> 0.1 + 0.2
=> 0.30000000000000004

> 0.3 - 0.1
=> 0.19999999999999998

> 0.1 * 0.2
=> 0.020000000000000004
```

簡單來說，由於電腦記憶體有限，**浮點數的 0.1** 和一般人腦認知的**小數點 0.1**有著極微妙的誤差。這是有名的「浮點數不精確問題」，不論任何程式語言都會遇到。不過今天的主題是除法，這部分就跳過吧。

## 那除法呢？
和加減乘法比起來，除法的花樣就多了。首先，從數學上來說，除法運算必然會產生**商數**和**餘數**：

```
被除數 = 商數 * 除數 + 餘數
# 14 = 4 * 3 + 2
```

因此，對人腦來說是簡單的 `x ÷ y`，對電腦來說就是黑人問號了：「所以你現在是想知道除數還是餘數還是什麼？」

### 我兩個都想知道，不行嗎？
可以喔！使用 `x.divmod(y)` 方法，可以同時取得商數和餘數：

```
> 14.divmod(3)
=> [4, 2]
```

### 我想知道商數

#### 總之先幫我隨便算一下吧
好喔，那就是最經典的 `x / y` 方法：

```
# 整數相除，得到整數的商數
> 14 / 3
=> 4

# 非整數相除，得到非整數的商數
> 14 / 3.0
=> 4.666666666666667
```

#### 就是要整數

使用 `x.div(y)` 方法，結果會轉為整數：

```
> 14.div(3)
=> 4

> 14.div(3.0)
=> 4
```

#### 浮點數錯了嗎？

使用 `x.fdiv(y)` 方法，結果會轉為浮點數：

```
> 14.fdiv(3)
=> 4.666666666666667

> 14.fdiv(3.0)
=> 4.666666666666667
```

#### 整數什麼的最討厭了

使用 `x.quo(y)` 方法，會得到更精確的商數：

```
# 整數相除，得到分數物件（Rational）
> 14.quo(3)
=> (14/3)

# 非整數相除，得到浮點數物件（Float）
> 14.quo(3.0)
=> 4.666666666666667
```

### 我想知道餘數

我們先從最單純的情況開始。

#### x, y 的正負值相同時

`x.modulo(y)` 和 `x.remainder(y)` 可以取得餘數：

```
> 14.modulo(3)
=> 2
> 14.remainder(3)
=> 2
```

兩邊同樣都是負數時也是一樣：

```
> -14.modulo(-3)
=> -2
> -14.remainder(-3)
=> -2
```

其中 `x.modulo(y)` 也可以寫成（比較常見的？） `x % y`，兩者意義是一樣的。

#### x, y 的正負值不同時

好，問題來了。當 `x` 和 `y` 的正負值不同時，也就是像是 `14 ÷ -3` 或 `-14 ÷ 3` 這樣的計算時，會發生什麼事情呢？

```
> 14.divmod(-3)
=> [-5, -1]
> 14.modulo(-3)
=> -1
> 14.remainder(-3)
=> 2
```

咦？為何同樣是取得餘數的 `x.modulo(y)` 和 `x.remainder(y)`，得到的結果卻是不一樣的呢？還記得剛才的除法復習嗎：

```
被除數 = 商數 * 除數 + 餘數
```

當被除數和除數的正負值不同時，例如 `14 ÷ -3`，按照數學上對餘數的定義（詳細請參考[維基百科](https://zh.wikipedia.org/wiki/%E4%BD%99%E6%95%B0)），以下兩個解法都是成立的！

```
14 = (-5) * (-3) + (-1)
14 = (-4) * (-3) + 2
```

這也就是說，在數學上，`14 ÷ -3` 的餘數同時有可能是 `-1` 和 `2`。因此，Ruby 同時提供了 `x.modulo(y)` 和 `x.remainder(y)` 兩種方法，以分別取得兩個不同解法所得到的餘數。

簡單地說，能使 `x = a * y + b` 成立的**最小商數解**`a`，與其搭配的餘數 `b` 就是 `x.modulo(y)` 會取得的值：

```
# 14 = (-5) * (-3) + (-1)
> 14.modulo(-3)
=> -1
```

而另一個解法所得到的餘數，就是 `x.remainder(y)` 的結果。它和被除數的正負值會是一致的：

```
＃ 14 = (-4) * (-3) + 2
> 14.remainder(-3)
=> 2
```

前述 `x.divmod(y)` 所取得的餘數，則是以 `x.modulo(y)` 的值為準。

### 特殊狀況

再補充一些和零有關的特殊狀況：

```
＃ 除數是零的話會噴錯
> 1 / 0
=> ZeroDivisionError

＃ 但可以是 0.0 XD
> 1 / 0.0
=> Infinity

# 被除數是零的話，怎麼除都會是零
> 0 / 3
=> 0

# 除非用 0.0 去除 XD
> 0 / 0.0
=> NaN
```

## 結語

以上是關於 Ruby 除法的介紹，雖然實用性應該很低（笑）想更深入理解 Ruby 的數學運算的話，可以參考官方文件的 [Numeric API](https://ruby-doc.org/core-2.4.0/Numeric.html)，還有很多不常用的冷門方法等大家去認識喔～

---

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

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

ASTRO Camp

線上課程

實體課程

技術文章

五倍消息

技術文章

轉職只是選擇，我從 Bartender 轉軟體工程師

使用 Sitemap 打好網站 SEO 基石

React Promise Modal

CSS： calc() 數值運算

專案管理起步走：五件重要的小事

從失敗案例重新思考敏捷開發價值

34 歲才開始自學寫程式會不會太晚？真的有心，永遠都不嫌晚。

Ruby 冷知識：除法篇

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

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

專業課程

ASTRO Camp

線上課程

實體課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款