「スタディサプリ TOEIC対策講座」が98日続いたので書く

前回を書いてから、スタディサプリのTOEIC対策講座が98日続いたので近況報告として書く。
なぜ98日時点での報告かと言うと、うっかり一日忘れて連続記録が途切れたからである。悲しい。

f:id:Peranikov:20180814220215p:plain

eigosapuri.jp

スタディサプリでの学習内容

TOEICの出題形式と同じPart1 ~ 7について対策があり、おおよそ以下の構成となっている。

  • 例題
  • 例題の動画解説
  • 例題に出てきた単語テスト
  • ディクテーション
  • シャドーイング

例題は実際のテストを模しており、時間制限が設けられている。このアプリはTOEIC対策に向けられているので、解説動画も英語の文法だけでなく試験のテクニック(問題の先読み、消去法での解き方、出題傾向など)についても解説されている。

いつやっているか

出勤前に自宅でやるようになった。1演習やると20分程なのでそこまで苦にはならない。以前は通勤時間を利用し電車内で行っていたが、周りの騒音によりリスニングが聞こえない、切りの悪いところで目的地に着いてしまう、妻と共有しているSIMの通信量が増えてクレームが来たなどの理由により外での使用は控えた。代わりに電車内では読書に勤しんでいる。

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)

続けてみて

3ヶ月経ったが、まだまだすんなり聴き取れているとは程遠い。リスニングでは聞き慣れない単語が続くとパニックになりその後の英文が頭に入ってこなくなるため、聞き慣れたパターンを増やし、知らない単語の意味は推測できることが重要だそう。

1日にどんどん問題を消化したい気持ちはあるが、1つの問題を身につくまで繰り返し解くほうが力になるそうで、納得のいくまでディクテーションとシャドーイングを繰り返すようにしている。

さいごに

98日を超えるという目標ができたのでまた頑張ります。

「英語学習五人組」を90日間完走した感想

今年の1月から、90日間にかけて互いに監視しながら毎日英語を学習するという活動を行っており、先日無事完走を果たすことができたので、その感想を残しておきます。

実際の活動内容については @kon_yu さんのブログを参照ください。 konyu.hatenablog.com

前提

自分は英語力はほとんどなく、幾度か身につけようと学習を試みたものの、一向に向上しない感覚から挫折を繰り返していました。今回Facebookの投稿で募集を見つけ、これで続かなければもう身につけられることはないだろうという思いで参加を表明しました。

なお自分が振り分けられたみんチャレのグループは

Maker Faire Tokyoと MashUp Award

それぞれお互いを2人ずつぐらい知っているグループ

Web系ソフトウェアエンジニア1

Web系ソフトウェアエンジニア2(下ネタが好きそうな人)

中国・深セン

の内のWeb系ソフトウェアエンジニア1 (下ネタが好きそうでない人)になりました。

習慣づけるために

性格上とても飽きっぽいため、地道に毎日帰宅後にやるなどと言っていては続かないことが目に見えていたため、以下の工夫をすることにしました。

  • 電車内の出勤時間で学習する(およそ20 ~ 30分)
  • いつでも始められるようアプリを活用する

これらのメリットとしては、

  • ほぼ毎日安定して作業時間が確保できる
  • 集中して時間としてちょうどいい

といったあたりが感じられました。逆にデメリットとしては

  • 各停と快速で作業時間にムラができる
  • 作業が半端でも駅に着いてしまうと強制中断される
  • 声が出せないのでシャドーイングは口パクになり怪しい人に見える(あまり気にしていない
  • 電車に乗らない日の学習タイミングがわからない
    • これは暇をみつけてまずアプリを起動するよう心掛けた

などが挙げられます。

実施した内容

90日の間は以下の順で学習を行いました。それぞれ学習していった中で感じたメリデメを列挙していきます(個人の感想です)。

duolingo

Duolingo

Duolingo

  • Duolingo
  • 教育
  • 無料

duolingoは様々な言語を無料で学習することができるサービスです。 レベルとしては中学生で習うものが主のようで、学習を始める入り口としては良さそうな印象でした。

メリット

  • 単語、和訳/英訳、ヒアリング、スピーキングと英語の学習法を網羅している
  • かなり基本的なことから学習できる
  • 問題ごとに参加者によるQ&Aが確認でき、深く理解できる
  • 連続学習日数が見られるので、ログインボーナス感覚で続けられる
  • 無料
    • 課金もあるがする意味は感じられなかった

デメリット

  • 初期は簡単すぎて物足りない
    • ただし、いくつかの項をまとめてクリアしスキップすることは可能
  • 単語/英文の発音が怪しい
  • スピーキングは飾りのようなもの
    • 誤っていてもどこが悪いかまでは教えてくれない
  • Q&Aの質が安定しない
  • 日数が経過すると復習させるために進捗率が下がるのでモチベーションも下がる
    • 最近確認したところ、%でなくスキルレベルというものに置き換わっていた

瞬間英作文

duolingoが一通り完了したので別のアプリを試すことにしました。この時はkon_yuさんの以下の記事を参考にしました。

konyu.hatenablog.com

記事にも書いてありますが、これは筋トレのようにひたすら繰り返し、ただ脳に英文を馴染ませるもの、という感覚がありました。こちらもレベルは中学1 ~ 3になります。

メリット

  • 英文の発音がしっかりしている
  • 章が細かく分けられており、10問ずつあるのでボリュームはある
  • 買い切り1200円

デメリット

  • 解説が章ごとなので、問題ごとの細かい解説などは無く、どうしてこの解答になるの?という疑問は拭えない
    • 解説が無い章もある
    • 深く考えず丸暗記した方がいいのかも
  • ゲーム性は無くあまり楽しくはない

金のフレーズ2

金のフレーズ 2

金のフレーズ 2

  • 物書堂
  • 教育
  • ¥600

英文よりまず単語だろ、と思い立ちこのアプリも買ってみました。(英作文に飽きてきたというのもある こちらはTOEICで頻出の単語を集めており、TOEICスコア毎にグルーピングされて出題される形式でした。学習方法としては、

  1. フレーズとフレーズ訳を一通り眺めて覚える
  2. フレーズ訳からフレーズを記憶しているかチェックする
  3. 実際にタイピングして英単語を記憶しているかチェックする

という流れになっています。一つの設問に10単語が含まれており、全てクリアできるまで繰り返します。

メリット

  • タイピングで本当に記憶できているかチェックできるのは良い
  • 単語ごとの解説が丁寧
  • 買い切り600円

デメリット

  • あまり身に付いている感覚がない(これは個人差がありそう
    • まずは600レベルを反復して学習するという方がいいかも

スタディサプリ ENGLISH TOEIC対策

この時点で念願の90日を達成することができました。単語も720レベルまでを一通り終えたので、別のアプリを試してみることにしました。こちらはまだ初めて5日目なので、触ってみたレベルの印象になります。

メリット

  • 1つの問題に対してものすごく丁寧
  • 学習を続けさせる工夫が感じられる
    • 一週間の目標学習時間と今週の学習時間が見られる
    • 連続学習日数が見られる

デメリット

  • そこそこ高い(2,480円/月

得られた効果

たった90日間続けてみて英語力が見違えるように向上するというのは、そもそもあまり期待しているところではありませんでした。実際に得られたと思われる効果は「学習する習慣が得られた」ということに尽きるかと思います。

飽きっぽい自分がここまで続けられたのは以下の要因があったおかげでした。

  • 2日間で強制脱退されるという縛りが良いプレッシャーになった
  • 多少方法は違えど、やっていることは一緒なので自分は間違っていないという自信になった
  • 他の人の活動内容が見れるので、別の学習方法が発見でき、飽きたら試してみるという方法がとれた

自分は学習方法をコロコロ変えていたので効率はよくないかも知れませんが、まず習慣を得るという目標は達成することができました。

f:id:Peranikov:20180504145530p:plain

(たまに穴が空いているのは学習したけどみんチャレにアップロードし忘れました。信じてください。)

今後について

90日を過ぎてもまだみんチャレメンバーは継続しているので、このまま惰性で学習を続けて行こうと思います。今の自分の力量がわかっていた方がモチベーションに繋がるはずなので、まずはTOEICを受けてみようかと思います。

また、10月にアメリカに行く予定が出来たのでその準備と心構えを付けたいという目標もできました。

企画していただいた @kon_yuさんありがとうございました!

2017年を振り返る

2018年になって早くも三が日が終わりそうですがいまさら2017年を振り返ります。 なお去年の振り返りはこちらです。

norizabuton.hateblo.jp

Kawasaki.rbの公式ブログを書き続けて2年と9ヶ月

Kawasaki.rbの公式ブログを一昨年の4月から毎月休まず寄稿しつづけて2年と9ヶ月が経過しました。

medium.com

パーフェクトRuby読書会は相変わらず参加者達の楽しい脱線解説*1により遅々として進まず2017年5月にはとうとう第二版が出てしまいましたが、Rubyの話を中心にさまざまな技術が聞けるのがKawasaki.rbのとても素晴らしいところです。

参加者達もそのことは充分理解しており、読書会後のセッションでも「今日はGoの話をします」「Pythonで野球分析する話もってきました」「今日は珍しくRailsの話がありましたね」という言葉が飛び交っています。

社内の非エンジニアに向けて自社サービスにまつわる技術講習を行った

弊社の非エンジニアは、エンジニアではなくても仕事柄HTML/JS/CSSを触る機会も多く、提供しているサービスの機能によりCookieリファラなどのWeb上の技術を知っていなければならないという割と高度な仕事を要求されているため、お客様からの問い合わせや開発者チームとの会話がよりスムーズになれば良いと思い技術講習を行いました。

内容は全3回に分けて行い、

  • 自社サービスが動作している仕組み(GoogleDevToolを使ったHTTPリクエスト/レスポンスの眺め方)
  • 提供している機能にまつわるWeb技術の解説(Cookie,リファラ,DOM,URLの構造)
  • CSS演習(別のデザイナにお願いした)

という内容で実施しました。得られた効果としては、実施後のサーベイから「深い理解からお客様により詳しく機能を案内することができた」「GoogleDevToolを使い機能が動かない原因特定の助けになった」というものがありました。

サービスに関係ない知識を教えたり、座学だけでは実務に活かすことは難しいと思い、講習では「何を教え、何を教えないか」に充分注意しつつ、GoogleDevToolを通したハンズオンで実際に体験してもらうことに重きを置きました。

この話はきちんとまとめて、別途ちゃんと発表したいと思います。

さいごに

今年はいよいよ20代最後の年になってしまうので、良き30歳を迎えられるよう悔いの残らないように精進したいと思います。

*1:前回はWindowsファイルシステムについての話になった

react-reduxのconnectとは何なのか

だいぶ端折っているので本家を読んだほうがいいです。

何なのか

簡単に言えばReactComponentをReduxのStoreに繋ぐもの。ReactComponent自体には手を加えず、Reduxに接続された新しいComponentを返す。ReduxではContainerと呼ばれる。

できること

引数として以下を渡すことができる。

  • mapStateToProps
  • mapDispatchToProps
  • mergeProps
  • options

特に重要なのはmapStateToPropsとmapDispatchToPropsである。

mapStateToProps

Storeが更新される度に呼ばれる。つまり、アプリの状態が変化したときのコールバック。Reactを単体で使用した場合、イベントが発生したらルートのComponentから末端のComponentまでバケツリレーしながら状態を変化させなければならないが、それをしないですむようになる。 mapStateToPropsが返す値はプレーンなObjectでなければならない。Storeを監視したくなければnull/undefinedを返せば良い。

mapDispatchToProps

ReduxComponentのイベントとReduxのActionを結びつける。

mergeProps

mapStateToProps()、mapDispatchToProps()、親コンポーネントのpropsの結果が渡される。つまり決定したpropsをここで改変することができる。省略すると Object.assign({}、ownProps、stateProps、dispatchProps) が呼ばれる。

options

connectorの振る舞いを変えることができる。

  • pure(Boolean) … propsが変更されていない場合、再レンダリングを行わない。デフォルトは true
  • areStatesEqual(Function) … pureのstateが等しいか判定基準となる関数。デフォルトは ===
  • areStatePropsEqual(Function) … pureのpropsが等しいか判定基準となる関数。デフォルトは shallowEqual
  • areStatePropsEqual(Function) … pureのmapStateToPropsが等しいか判定基準となる関数。デフォルトは shallowEqual
  • areMergedPropsEqual(Function) … pureのmergedPropsが等しいか判定基準となる関数。デフォルトは shallowEqual

街コロの期待値を出す

街コロとは

これ

街コロ

街コロ

ルールなどはここ などを参照して欲しい。

モチベーション

どうやっても序盤は森林を買い、周りが駅を建てるに連れて鉱山/家具工場への流れが最強な気がしているんだが、ここまで売れているゲームなのだから他の戦略もあるのだろう、と思い各カードの期待値を出してみた。

コード

建物の数やプレイヤー数で収入が変動するものは除外
期待値はプレイヤー1週で得られる収入
サイコロの数は全員同じとする

街コロの期待値を出す · GitHub

結果

プレイヤー数(試行回数): 4

麦畑(blue) 目:[1] コスト:1 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:2
サイコロが2つ 期待値:0  元が取れるターン数:Infinity

牧場(blue) 目:[2] コスト:1 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:2
サイコロが2つ 期待値:1/9  元が取れるターン数:9

パン屋(green) 目:[2, 3] コスト:1 収入:1
サイコロが1つ 期待値:1/3 元が取れるターン数:3
サイコロが2つ 期待値:1/12  元が取れるターン数:12

コンビニ(green) 目:[4] コスト:2 収入:4
サイコロが1つ 期待値:2/3 元が取れるターン数:3
サイコロが2つ 期待値:1/3  元が取れるターン数:6

カフェ(red) 目:[3] コスト:2 収入:3
サイコロが1つ 期待値:3/2 元が取れるターン数:1
サイコロが2つ 期待値:1/2  元が取れるターン数:4

森林(blue) 目:[5] コスト:3 収入:1
サイコロが1つ 期待値:2/3 元が取れるターン数:5
サイコロが2つ 期待値:4/9  元が取れるターン数:7

鉱山(blue) 目:[9] コスト:6 収入:5
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:20/9  元が取れるターン数:3

ファミレス(red) 目:[9, 10] コスト:3 収入:2
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:7/6  元が取れるターン数:3

リンゴ園(blue) 目:[10] コスト:3 収入:2
サイコロが1つ 期待値:0 元が取れるターン数:Infinity
サイコロが2つ 期待値:2/3  元が取れるターン数:5

感想

鉱山の期待値が20/9というのはぶっ壊れ性能では…
序盤はカフェが強い。駅が揃い始めたら建てる必要はないだろう。
プレイヤー人数が増えるほど緑(自分のターンでのみ収入が得られる)カードの効果は薄まる。緑の収入全体的に増やした方が良かったのでは…?と思うくらい。

標準ルールでは全ての建物を自由に選択できるので戦略が固定化されがちだが、拡張ルールでは序盤に建てられる建造物が限定化されておりランダム性が増すので、こちらで遊んだ方が楽しそう。

ゼロからReduxを学びボドゲのシミュレーターを作った

モダンなJSの開発環境とReact/Reduxを習得したくて、課題としてちょうどハマってたボドゲのシミュレーターを作った。

デモ

Dungeon of Mandom Simulator

ソース

github.com

ReactとFluxは一時期趣味で触ったことがあるくらいで、記事を遡ったら既に2年前の話だった。

norizabuton.hateblo.jp

技術選定

ビルドツール

babel/Webpackを使用。小規模なJSにbabelを使いたいだけであればbabelifyを通すだけで良さそうだが、今回はきちんと学ぶという名目なのでWebpackをちゃんと整備することにした。後々css-loaderを使ってCSS Modulesを試すこともできたのでこの選択は良かった。

AltJS

型が欲しいと思いTypeScriptかFlowで迷った。TypeScriptは現在ReactやAngularでもサポートされており、息が長そうで学ぶ価値は高そうという印象だが、既にbabel/Webpackでビルド環境を構築しており、ここからts-loaderを導入してTS用の環境を作るのが面倒だった(この時点で既にビルド環境構築に1週間ほど費やしている)ので、今回はbabel/Webpackに比較的乗せやすいFlowを選択した。

テスティングフレームワーク

node.jsでサーバーを立てた時にmochaでテストしていた経験はあったが、今回はReduxも推しているJestにし、assertはpower-assertを使ってみた。Jestはmochaと比較しても記法は対して変わらないので学習コストとしては大したことはなかった。デフォルトでMockになるので単体テストが容易という特徴があるらしいが、依存しているモジュールが少ないせいか今回はあまり恩恵を受けられなかった。

デザイン

同僚からantが綺麗で良いというオススメをもらったがmaterial-uiが使いたかった。使ってから気づいたがmaterial-uiにはBootstrapのGrid Systemは標準では存在してなさそうで、導入したければ恐らくサードパーティのものを使う必要がありそうだった。

エディタ

最近AtomからVS Codeに乗り換えたのでこれで書いている。Flowを入れてから気づいたが、VS Codeで型を定義すると.tsでないと使えないぞと怒られる。*1

f:id:Peranikov:20170318103654p:plain

これを回避するにはVS Codeの設定で "javascript.validate.enable": false とすれば良いのだがあまりに場当たりっぽい。

下記設定を試したところjsのコードハイライトが消えてしまったのですぐ戻した。

"files.associations": {
      "*.js": "flow"
    }

github.com

Issueの方でも正式な解決策は無さそうで今のところは警告を無視するしかなさそうな気がしている。つらい。

デプロイ

静的サイトなのでgh-pagesを使いGithub pagesにデプロイした。1コマンドでデプロイできめっちゃ便利である。

Redux所感

このくらいの規模のアプリケーションであれば正直Vue.jsを使ったほうが速く書けるし設計もさして重要ではなさそうである。各レイヤーの役割を覚えるまではコードが分散するので追っていくのが大変だが、慣れてくればどこを修正すれば良いのかがすぐわかるので後のメンテナビリティは上がりそうな気はした。

Modelレイヤー

Reduxを書き始めてすぐに気になった所は、どうやらロジックがreducerに集中してどんどんFatになっていく気がした。なので、下記記事を参考にimmutable.jsとModelレイヤーを導入した。*2

post.simplie.jp

モデルにロジックが集約していくのでテスタビリティも向上し、ロジックの見通しも良くなったと思われる。

それとは別に、Containerなどでコレクションのフィルタリングをしているのだが、モデルの構造を意識してフィルタリングしたくなく、もっと抽象的に扱うためにファーストクラスコレクションを導入したくなった。が、immutable.jsのコレクションは直接拡張することはどうやら難しそうで、公式でないextendable-immutableを用いれば実現できそうな気がしたが、なんとなく依存を増やしたくなく、PureなJSで色々試していたがあまりうまくいかなかった。良い例があったら知りたい。

Constantsの意味

ReduxではActionとReducerはActionTypeという文字列のキーを使ってロジックを紐付けるのだが、わざわざ定数を介する意味が見えず最初は直接文字列で書いていた。途中で気になって調べたところ、下記記事からメリットが複数あることがわかった。

stackoverflow.com

要約すると、

  • ActionTypeの一覧性が1つのファイルに集約するので、既存のアクションが把握しやすく名前の一貫性を保ちやすくなる
  • IDEを使っていれば補完が効くのでタイプミスを誘発しにくくなる
  • 変数名を介してアクセスするので、minifyの効果が向上する

ということで、ActionTypeのファイルを設けることにした。

デバッグ

イベントが発生後にStoreがどのように変化したかデバッグするために方法を探ったところ、redux-devtoolを見つけた。redux-devtoolはとても高機能で、Storeの状態を確認する以外にもActionのUndoやResetが可能らしいのだが、専用のComponentを導入する必要があったり、コードを多く変更する必要がある印象を受け、敷居の高さを感じ今回は見送った。それとは別にredux-loggerというものを見つけた。こちらはイベントの度にStoreの変更前と変更後をロギングしてくれ、比較的導入も楽で必要十分と感じたのでこちらを使用した。

テスト

公式を参考にaction/component/reducerのテストを書いてみたが、ロジックが大したことないのもあって、あまり必要性を感じなかった。Actionは外部APIを叩いたり非同期な処理が増えてくると有用性も高まるかもしれない。Componentsのテストも試しに書いてみたが、デザイン性に大きく関わる部分なのでどういう観点でテストを書けば良いのかがまだあまり掴めていない。Componentsにロジックが寄るのは恐らく設計としてあまりよろしくなさそうだし、UIについてはE2Eテストを別途設けたほうがむしろ有用ではないかという疑念が残っている。

さいごに

ダンジョンオブマンダムは良ゲーだったので買って遊ぶと良い。

ダンジョンオブマンダム

ダンジョンオブマンダム

*1:いかにもMSが作ったエディタっぽい挙動

*2:どんどんFacebookに染まっていくぞ〜

2016年を振り返る

今年も今日を含めてあと2日で終了するので振り返っておく。

なお去年の振り返り。

norizabuton.hateblo.jp

川崎Ruby会議やった

norizabuton.hateblo.jp

スタッフとスピーカーという立場で参加した。自分の中では今年一番大きなイベントだったと思われる。気になるのは来年もやるのかというところだがまだ何も決まってはいない。Kawasaki.rbは土地柄かWeb屋が少なくRuby以外で仕事してる人のほうが割合として多い*1ので、今年の川崎Ruby会議もそのカラーを前面に出し、コンテンツも特にRubyにこだわらずに実施した。もし次回があるのであれば、このカラーは続けていって欲しいと思うし、そんな内容でも聞いてみたいと思う人は是非参加して欲しい。

なおkawasaki.rb公式ブログは今年からMediumに移行して絶賛継続中である。去年の4月から毎月休まず寄稿しているぞ。

データの民主化SQLハンズオン

今年はやたら「データの民主化」という言葉が耳に入った年だと思う。弊社でもRe:dashが整備され、非エンジニアがデータベースにSQLを投げられる環境は整われた。

ただ、環境は整備されても初めてSQLを投げるのはハードルが高く、当初はその人の席で直接SQLを教えながら手伝っていたのだが、手も回らないし全体的に基礎的な事を先に教えた方が良かろうと思いハンズオンという形式で実施した。

norizabuton.hateblo.jp

なおこの記事の2週間後に第2回を実施している。内容は1回目で苦戦したJOINとGROUP BYを図解込みで解説し、残りの時間で難題かと思われたサブクエリの演習をした。講習でなくハンズオンという形にしたことで、課題を解けたという達成感と実際のデータ取得に応用してみようというモチベーションに繋がったと思う。現に、弊社SlackのSQL質問チャンネルでは既にエンジニアを介さずに質問と解答が繰り広げられていた*2

技術スタック

川崎Ruby会議ではScalaについて話してみたものの、結局あまりScalaには触らず、仕事ではRubyを使うことのほうが断然多かった。今年はモニタリングとパフォーマンスチューニングをすることが多かったからか半インフラ業のような仕事が多く、DockerとGatringで負荷テスト、Passengerのチューニング、AWSのサービス(Lambda, CloudWatch, ElasticBeanstalk...)と仲良くなった。特にLambdaとSlackは監視に使うには本当に便利で、最近ServerlessFrameworkも覚えたしどんどん活用していきたい。

あとCUIツールとか今はRubyで書いちゃうんだけど、配布とか考えるとGo覚えてさくっと書けるようになりたい。

まとめ

気の利いたまとめを書こうと思ったが特に何も思い浮かばなかったのであえて書かない。

皆様良いお年を。

*1:Cで組み込みやってますみたいな人もいる

*2:仕事が減ったぞガハハ