SHIOPON LABO

知見や備忘録、レビューなど。しおぽん(shiopon01)のブログ

MacBook Pro (2018) 15インチをついに買った!開封式とMacBook Air 13インチと大きさの比較

社会人になったら買おう買おうと思っていたMacBook Proの15インチを、ついに買った。インテルの第8世代積んだやつがつい最近出たので、次は第9世代が出回るまで新しいMacBook Proは出ない読みの購入である。

買ったのは15インチでSSD512GBのモデルのデフォルト。i9とか32GBとかはちょっと考えたけど、仕事で映像編集バリバリやるわけでもなければイラストを書くわけでもないし、そのへん考えると + ¥ 770,00 (税別) は流石に払えなかった…。

購入したMacBook Proの性能はこちら。

  • 第8世代の2.6GHz 6コアIntel Core i7プ‍ロ‍セッサ(Turbo Boost使用時最大4.3GHz)
  • Radeon Pro 560X(4GB GDDR5メ‍モ‍リ搭載)
  • 16GB 2,400MHz DDR4メモリ
  • 512GB SSDストレージ
  • バックライトキーボード - 英語(米国)

www.apple.com

開封

ダンボールを開けた時。

f:id:shiopon01:20180911001658j:plain

いつもの真っ白なAppleの箱に入ったMacBook Pro。この箱を開ける時だけ、オレは少年の心を取り戻す。

f:id:shiopon01:20180911001715j:plain

本体の下には付属アクセサリーのコンセントに挿す電源と、充電用?のUSB Type-Cケーブル。薄い入れ物には説明書とAppleのりんごマークのシールが入っていた。

f:id:shiopon01:20180911001728j:plain

この付属アクセサリーを見ると、電源ポートが USB Type-C になったことを実感させられる。話では聞いていたし店頭でも見たことあるけど、MagSafeの時代はもう終わってしまったのかと…。(実際に使ってみると、左右どちらでも充電できるし意外と便利だった。でもやっぱり、磁石のカチッっていう感覚と、ケーブル足に引っ掛けた時の電源ポートへの負担を考えると、MagSafeが名残惜しい。)

試しに、手持ちのMacBook Air (2011〜2014モデルのどれか) 13インチを箱に入れてみた。これくらいのサイズ差があるらしい。やっぱり15インチは大きいが、ディスプレイの大きさこそ正義なのだ。

f:id:shiopon01:20180911001840j:plain

実際に開いてみると、トラックパッドのデカさが個人的には衝撃だった。(英字キーボードだから?)

f:id:shiopon01:20180911001908j:plain

静音化されたという改良バタフライキーボードは改良前をちゃんと使ったことがないため比較はできないが、気になるほどうるさくはない。音の質は違うが、タイピングの音量はMacBook Airのキーボードと同じくらいな気もする。最初はちょっと気持ち悪いバタフライキーボードも使っていけばすぐ慣れそうなかんじ。

MacBook Proから投稿!)

P.S.

本当は9/6に届く予定だったけどちょうど台風21号の影響が大きい頃で、関税手続きの遅れとか諸々あって3日遅れて届いた。(9/9到着)

f:id:shiopon01:20180910102038p:plain

React/Reduxのスターターキットを公開している(2018/8/8更新)

React/Reduxビギナーのための、React/Reduxスターターキットを公開しているという記事。当初は最小限の機能で1ページのReduxアプリを作成するためのスターターキットを目指していたのだが、現在のSPA需用もありルーティングなどを追加した。

github.com

中身としては単純に、 react-create-app コマンドで作成したReactアプリにReduxを組み込んだ形。 package.json を見ると、追加したパッケージは基本的なReact/Redux関連のパッケージとコード整形系。webpackなど多くの部分は react-scripts に依存している。

  • react: "^16.4.2"
  • react-dom: "^16.4.2"
  • react-redux: "^5.0.7"
  • react-router-dom: "^4.3.1"
  • react-scripts: "1.1.4"
  • redux: "^4.0.0"
  • redux-logger: "^3.0.6"
  • redux-thunk: "^2.3.0"
  • eslint: "^5.2.0"
  • eslint-config-prettier: "^2.9.0"
  • eslint-plugin-import: "^2.13.0"
  • eslint-plugin-prettier: "^2.6.2"
  • eslint-plugin-react: "^7.10.0"
  • eslint-plugin-react-redux: "^2.3.0"
  • prettier: "^1.14.0"

Example: Todo List - Redux

ディレクトリ構造

ActionやReducerは専用のディレクトリやファイルに分けるのではなく、依存し合うそれぞれを1つのモジュール単位として、1つのファイルで管理する手法を採用している (Ducks proposalと呼ばれてる?) 。これを採用するため、ducks-modular-reduxを参考にした。

github.com

.
├── public                             # 静的ファイル
├── src                                # アプリのソースコード
│   ├── index.js                       # main render
│   ├── reducers.js                    # combine Reducers
│   ├── registerServiceWorker.js       # Offline cache https://goo.gl/KwvDNy
│   ├── shareComponents                # share Components
│   │   └── Header.js                  # page header
│   ├── utils                          # convenient things
│   │   ├── logo.svg                   # React icon
│   │   ├── consts.js                  # your ENV
│   │   └── injectStyle.js             # you can use `@keyframes`
│   └── app                            # application main sources
│        ├── App.js                    # application routing
│        ├── home                      # [home] `localhost:3000/`
│        │   ├── index.js              # [home] main Container
│        │   └── Home.js               # [home] main Component
│        └── todo                      # [todo] `localhost:3000/todo`
│             ├── index.js             # [todo] main Container
│             ├── Home.js              # [todo] main Component
│             ├── components           # [todo] Components
│             ├── containers           # [todo] Container Components
│             └── modules              # [todo] main action logic files (include in `Action`, `Reducer`, `Action Creator`)
│                  ├── reducers.js     # [todo] combine Reducers
│                  ├── todos.js        # [todo] todo module
│                  └── todos.spec.js   # [todo] todo module unit test
└── LICENSE                            # License is MIT

ducks-modular-reduxでは、依存するそれぞれのAction, Reducer, Action Creatorを1つのモジュールとして1つのファイルにまとめる手法を提案している。
よくある、ActionやReducerをそれぞれ専用のディレクトリやファイルとして/reducer/index.js/action.jsで管理されるパターンは、機能 (Action, Reducer) の追加が非常に煩わしい。たしかにうまく管理はできるのだが、実際にプログラミングしてアプリを作る場合、この面倒くささは未経験の想像する面倒くささを凌駕する。

このプロジェクトで採用しているプロジェクト構造は、全ての機能はモジュール単位で分けているため幾分マシだ。機能を追加したい場合、必要な分モジュールを追加するだけで良い。機能が大きくなると1ファイルが大きくなってしまうデメリットはあるが、可読性が失われることはほとんどないし、ファイル移動が必要ないというメリットがある。

// Actions
const LOAD   = 'my-app/widgets/LOAD';

// Reducer
export default function reducer(state = {}, action = {}) {
  switch (action.type) {
    default: return state;
  }
}

// Action Creators
export function loadWidgets() {
  return { type: LOAD };
}

組織が裁量労働制を導入するためには何をしなければならないか

3行でまとめると

裁量労働制の導入には時間がかかるというポエム

TL;DR

9時18時のフルタイムが働き方が定着した組織で本気で裁量労働制を導入したいならば、段階的に導入する他無い。
今までフルタイムだった組織が突然裁量労働制を採用したところで、必要な文化が培われておらず容量のつかめていない雇用者や労働者は困惑し、結局いつも通りの働き方をし続けることは間違い無しだ。
これはウォーターフォールに慣れたチームが上司の命令でアジャイルを導入しても、結局ウォーターフォールで開発してしまうことと同じだ。さらにこの、誰も裁量労働できていないが形式的には裁量労働制の環境が続くと、雇用者も味をしめて定額働かせ放題の環境を作り上げる。これは上司が「アジャイルだから納期短く出来るよね」と言ってくるのと同じだ。

多くの組織にとって自由な働き方を可能としない原因として、リモートで働く環境が整っていない点が挙げられる。これは例えば、書類での承認手続き、face to faceしか認めない文化、VPNでアクセスできない社内サーバーなど。裁量労働制を導入するためには、まずはこの障壁となる文化を破壊していかなければならない。

もし組織が裁量労働制を導入したいと考えているなら、まずは先にコアタイム付きのフレックスタイム制を導入するべきだ。これは裁量労働制より自由ではないが、労働者にはある程度の自由と裁量が与えられる。なにより、きちんと残業代が支払われるのもフレックスタイム制の良いところだ。この制度で働きながら、前述した、障壁となる文化を破壊していく。

ある程度フレックスタイム制が定着し、雇用者が労働者の裁量を認められるようになり、いくつかの文化を破壊できたならば、次はフレックスタイム制のまま、新たな環境を整えるフェーズに入る。それにはまず、リモートワークを導入できる環境を目指すことが良い。リモートワークを可能にするには、遠隔でも情報共有できるツールの導入、遠隔でもコミュニケーションを取るためのツールの導入が必要不可欠になる。

この段階で終了しても良いが、最終的に裁量労働制を考えているのなら、このままフレックスタイム制の中でリモートワークを導入するべきだ。この時点でもほとんど裁量労働ではあるが、前述したように、残業代はきちんと支払われる。そして、同じ時間に働くという一体感はまだ多少残っている。
この段階では、ツールの導入やコミュニケーションの練習と共に、お互いの休憩と成果を認める文化を培っていきたい。給与は時間ではなく、成果に支払われるべきだ。ここで言う成果とは、コードの行数ではなく、利益貢献度である。

そして、全ての業務がリモートワークで可能になり、雇用者だけでなく労働者同士でお互いの裁量を認め合える文化を培った上で、初めて裁量労働制を取り入れることができる。9時18時のフルタイムで働かせている組織でこの工程を踏まずに裁量労働制へ切り替えると、間違いなく失敗する。裁量労働制とは、気軽に導入できる制度ではないのだ。

終わりに

裁量労働制を導入するために、前提としてリモートワークで働ける環境が存在しなければならない。その環境を整えるために、まずはフレックスタイム制で出社しつつリモートワークで利用できるツールや制度を決めたり、作るべきだ。これには多大な時間を要するだろうが、いきなり裁量労働制を採用するのは絶対にやめよう。

結局結局、はてなブログに帰ってきた。

ブログを作っては爆破、作っては爆破してきましたが、もう2度とブログを爆破せず、今後はこのはてなブログを利用し続けることを誓います。