GitHubリポジトリのTopicsが少しずつアップデートされてた
GitHubリポジトリのTopicsが少しずつアップデートされてた話。
Topicsは出た当初から使っていたが、登録する時、初めは半角スペースで区切られた単語がただトピックとして登録されるだけだった。
それが知らぬ間に、予測変換的な機能が追加されていて
さっきトピックを付けようと思ったら、なんとサジェストの機能まで実装されていた。たぶんそのリポジトリによく出てくる単語とかがサジェストされる。
リポジトリのProjectsも初期の頃に比べたら知らない間にちょっとずつ良くなっていってたし、GitHubのいつものサイレント改善を今日もまた見ることが出来た。（もしかしたらどっかで告知されてるのかもしれない。）
LINE BOOT AWARDSの最終選考に残ったやつ
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ストレージ
- バックライトキーボード - 英語（米国）
開封
ダンボールを開けた時。
いつもの真っ白なAppleの箱に入ったMacBook Pro。この箱を開ける時だけ、オレは少年の心を取り戻す。
本体の下には付属アクセサリーのコンセントに挿す電源と、充電用？のUSB Type-Cケーブル。薄い入れ物には説明書とAppleのりんごマークのシールが入っていた。
この付属アクセサリーを見ると、電源ポートが USB Type-C になったことを実感させられる。話では聞いていたし店頭でも見たことあるけど、MagSafeの時代はもう終わってしまったのかと…。（実際に使ってみると、左右どちらでも充電できるし意外と便利だった。でもやっぱり、磁石のカチッっていう感覚と、ケーブル足に引っ掛けた時の電源ポートへの負担を考えると、MagSafeが名残惜しい。）
試しに、手持ちのMacBook Air (2011〜2014モデルのどれか) 13インチを箱に入れてみた。これくらいのサイズ差があるらしい。やっぱり15インチは大きいが、ディスプレイの大きさこそ正義なのだ。
実際に開いてみると、トラックパッドのデカさが個人的には衝撃だった。（英字キーボードだから？）
静音化されたという改良バタフライキーボードは改良前をちゃんと使ったことがないため比較はできないが、気になるほどうるさくはない。音の質は違うが、タイピングの音量はMacBook Airのキーボードと同じくらいな気もする。最初はちょっと気持ち悪いバタフライキーボードも使っていけばすぐ慣れそうなかんじ。
（MacBook Proから投稿！）
P.S.
本当は9/6に届く予定だったけどちょうど台風21号の影響が大きい頃で、関税手続きの遅れとか諸々あって3日遅れて届いた。（9/9到着）
React/Reduxのスターターキットを公開している
React/Reduxビギナーのための、React/Reduxスターターキットを公開しているという記事。当初は最小限の機能で1ページのReduxアプリを作成するためのスターターキットを目指していたのだが、現在のSPA需用もありルーティングなどを追加した。
中身としては単純に、 react-create-app コマンドで作成したReactアプリにReduxを組み込んだ形。 package.json を見ると、追加したパッケージは基本的なReact/Redux関連のパッケージとコード整形系。webpackなど多くの部分は react-scripts に依存している。
- react
- react-dom
- react-redux
- react-router-dom
- react-scripts
- redux
- redux-logger
- redux-thunk
- eslint
- eslint-config-prettier
- eslint-plugin-import
- eslint-plugin-prettier
- eslint-plugin-react
- eslint-plugin-react-redux
- prettier
ディレクトリ構造
ActionやReducerは専用のディレクトリやファイルに分けるのではなく、依存し合うそれぞれを1つのモジュール単位として、1つのファイルで管理する手法を採用している (Ducks proposalと呼ばれてる?) 。これを採用するため、ducks-modular-reduxを参考にした。
. ├── 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 };
}
組織が1から裁量労働制を導入するためにしなければならないこと
裁量労働制の導入にはそれなりの時間を要するというポエム。
TL;DR
9時18時フルタイムの働き方が定着した組織で、本気で裁量労働制を導入しようと考えるなら段階的に導入していく他無い。
今までフルタイムだった組織が突然裁量労働制を採用したところで、必要な文化が培われておらず容量のつかめていない雇用者や労働者は困惑し、結局いつも通りの働き方をし続けることは間違い無しだ。
これはウォーターフォールに慣れたチームが上司の命令でアジャイルを導入しても、結局ウォーターフォールで開発してしまうことと同じだ。さらにこの、誰も裁量労働できていないが形式的には裁量労働制の環境が続くと、雇用者も味をしめて定額働かせ放題の環境を作り上げる。これは上司が「アジャイルだから納期短く出来るよね」と言ってくるのと同じだ。
多くの組織にとって自由な働き方を可能としない原因として、リモートで働く環境が整っていない点が挙げられる。これは例えば、書類での承認手続き、face to faceしか認めない文化、VPNでアクセスできない社内サーバーなど。裁量労働制を導入するためには、まずはこの障壁となる文化を破壊していかなければならない。
もし組織が裁量労働制を導入したいと考えているなら、まずは先にコアタイム付きのフレックスタイム制を導入するべきだ。これは裁量労働制より自由ではないが、労働者にはある程度の自由と裁量が与えられる。なにより、きちんと残業代が支払われるのもフレックスタイム制の良いところだ。この制度で働きながら、前述した、障壁となる文化を破壊していく。
ある程度フレックスタイム制が定着し、雇用者が労働者の裁量を認められるようになり、いくつかの文化を破壊できたならば、次はフレックスタイム制のまま、新たな環境を整えるフェーズに入る。それにはまず、リモートワークを導入できる環境を目指すことが良い。リモートワークを可能にするには、遠隔でも情報共有できるツールの導入、遠隔でもコミュニケーションを取るためのツールの導入が必要不可欠になる。
この段階で終了しても良いが、最終的に裁量労働制を考えているのなら、このままフレックスタイム制の中でリモートワークを導入するべきだ。この時点でもほとんど裁量労働ではあるが、前述したように、残業代はきちんと支払われる。そして、同じ時間に働くという一体感はまだ多少残っている。
この段階では、ツールの導入やコミュニケーションの練習と共に、お互いの休憩と成果を認める文化を培っていきたい。給与は時間ではなく、成果に支払われるべきだ。ここで言う成果とは、コードの行数ではなく、利益貢献度である。
そして、全ての業務がリモートワークで可能になり、雇用者だけでなく労働者同士でお互いの裁量を認め合える文化を培った上で、初めて裁量労働制を取り入れることができる。9時18時のフルタイムで働かせている組織でこの工程を踏まずに裁量労働制へ切り替えると、間違いなく失敗する。裁量労働制とは、気軽に導入できる制度ではないのだ。
終わりに
裁量労働制を導入するために、前提としてリモートワークで働ける環境が存在しなければならない。その環境を整えるために、まずはフレックスタイム制で出社しつつリモートワークで利用できるツールや制度を決めたり、作るべきだ。これには多大な時間を要するだろうが、いきなり裁量労働制を採用するのは絶対にやめよう。
