やる気を出すためにやるべきこと /「エンジニアの知的生産術」を読んだ(2)
前回の続き
今日は第2章の 「やる気をだすには」についてまとめていく
第2章 やる気を出すには
やる気を出すし、タスクを継続的に片付けるためにはいくつか方法がある
やるべきタスクを1つに絞る
タスクを切り替える意思決定をバカにしてはならず、やると決めたら1つのことに集中して取り組む必要がある。
GTDの活用に関しても触れている
- まずはやりたいことを全て書き出し、インボックスに入れる
- 次に取るべき行動ベースにタスクを分類する
- 複数ならプロジェクトを作る
- 2分以内でできることなら今やる
- 特定の日時にやるべきことなら、カレンダーに入れる
- 上記以外がタスクとなる
- 今日やるべきことだけに集中する
タスクの粒度を小さくする
1つのタスクが4時間以上かかる場合、それは粒度としては大きすぎる
自分の場合、プライベートの勉強時間は1日2h を目安に考えているため、2hを上回るようであれば分割する必要があるし、見積もりが明確でない
- 「本を執筆する」-> 2h で終わらない
- 「本の第一章のたたき台を作る」「たたき台の精査と誤字チェック」-> 2hで終わるかも。
時間を区切ってタスクを管理する
- 人間の集中力は2時間が限度。
- ゴールが遠いと、休憩しがち。
- 時間を決めてタスクを分割することでルールを明確にする
具体的な方法としてポモドーロ テクニックについても紹介されている
ゴールが遠いとタスクの途中で、メールチェックしちゃったり、他のことに気が散るようになる。 これは本当に仕事でもあるある。25分間やると決めたことをやり、休憩をちゃんと取り入れることで集中する時間を作る。
上記の内容を受けて自分の中で決めたタスク管理ルール
自分もこれを模倣して todoistとtogglを使って現在タスクを整理し始めた。
こんな感じ
todoistのマイルール
- 気になったらInbox
- プロジェクトの作成
- タスクは25分単位で1つ
- 25分で終わらないならコピーして分割
- 1日のタスクは4つまでとする
- 今日と明日やるものは期限を入れる
toggl のマイルール
- todoist のプロジェクト単位でタスクを作る
まとめ
- やるべきタスクを1つに絞ることで、集中力を上げる
- タスクの粒度を小さくし、達成感を感じることで継続しやすくすることができる
効率的に新しい技術を学ぶ方法の探究 /「エンジニアの知的生産術」を読んだ
結構前に購入していたけど積ん読になっていた「エンジニアの知的生産術――効率的に学び,整理し,アウトプットする」を読んだ。4月末に転職も決まり新しい環境で早く結果を出せるように、入社前に勉強したいと思い、まずは勉強の仕方を学ぶことにした。
ブログを久々に書いているのも、この本でアプトプットすることの重要性が説かれていたからだ。
目次
(目次)
- 第1章 新しいことを学ぶには
- 第2章 やる気を出すには
- 第3章 記憶を鍛えるには
- 第4章 効率的に読むには
- 第5章 考えをまとめるには
- 第6章 アイデアを思い付くには
- 第7章 何を学ぶかを決めるには
ブログとしては自分の中で重要だと感じた、1章〜3章までについてまとめることで、この本で学んだことをしっかり身につけて学習に活かせるようにしたい。
今日のブログでは1章についてまとめる
第1章 新しいことを学ぶには
この本では学びのサイクルとして以下の3つが重要であり、このサイクルを回すことで効率的な学びができるという解説があった。
https://gihyo.jp/magazine/wdpress/plus/978-4-7741-9876-7/0001
1 情報収集、体験
例えば 「Python の リストとタプルの違いについて知りたい」というのを例に取ったとき、ネットの記事や本を読んで調べるという行為が該当する
最初からから順番に読むことよりも、知りたいところから調べることで、やる気を持続しやすくすることを説いている。
知りたいところから学ぶためには、「目標が明確化されている」 「目標が達成可能である」 「大まかに全体像を把握している」 という前提条件ある
この条件に合致しない場合、初めは「大雑把に読む」「全体を理解する」ことを重要視している
例えば、Springフレームワークについて知りたいと思った場合、
「Springフレームワークを学ぶ」という目標は曖昧だし、達成可能かどうかの判断が難しい。 それなら目標は、「SpringフレームワークのうちDIについて理解し、DIの効果を誰かに説明できる」「DIを使った実装を行うことができるようになる」といったものが適切だと思う。
写経という方法についても言及されている
写経は補助輪
写経は非常に時間がかかる勉強法だが、確実な成果が出せるという点において有益 ただし、非効率的な学習方法であるということは念頭に置く必要がある
前に TypeScript で Redux を扱うときの型定義の仕方について学びたいと思ったときは、以下の本を必死に写経して動かし、自分のアプリに落とし込んで自分のものにした。時間はかかったが、成果が明らかなのと、コードを動かして学ぶサイクルを回すことでちゃんと理解が進むことがわかった。
2 抽象
抽象ということばは、「注目すべき重要な部分だけを抜き出す」 ということを意味している。 実際にこのブログを書く課程で、本の中から自分の中で「重要な部分」を抜き出している。 ブログを書くことで抽象化作業をしていると言えるのではないだろうか。
また抽象化された重要な部分だけを抜き出されたものを 「モデル」 と表現している。
具体的な事例から共通点や繰り返しを見つけた場合それをパターンと表現している。
学ぶ対象からモデルやパターンを見つけ、自分のものにすることで理解が深まる。
具体的に抽象化していくには、「比較して学ぶ」という方法がある。
具体的な事例の、同じ部分、違う部分に注目することで元々違いがわからずもやっとしていたものが、はっきりわかるようになる。
例えば、Java、C#、TypeScript、Ruby、Go の同じところと違うところ。
プログラミング言語という点においては同じだが、Rubyは動的型付けであり、それ以外は静的型付け言語という違いがある。
この本の中では、情報収集を、「箱を地面に並べる」という表現をしており、抽象化のことを「箱を積み上げる」という表現をしている
抽象化できているかどうかは
- 自分の言葉で説明できる
- 自分の経験に基づいた例を挙げることができる
- 自分の目標を達成するために利用することができる
という条件を達成できた場合に抽象化ができたと言える。
このことは、何かをちゃんと理解したか?ということをジャッジするときには有効に思える。
3 検証
わかったような気持ちになったとしても、本当にわかったのかを確認する必要がある。 プログラミングの場合、作るって動かすことで検証が可能となる。
タプルとリストの違いを知りたい場合、タプルとリストに重複する値を入れて、標準出力してみてその結果を観察し、ちゃんと理解できていれば期待通りの結果となる。
プログラミング以外の場合、解説記事を書くことで検証となる。
今回のブログはまさに解説を書くこと検証している。
1日前の自分に説明できるか?ということを考えながら解説記事を書くことで検証となる。
あとは試験で検証する。情報処理試験など、テストがある場合はテストで確認可能である。
1章まとめ
- 学びには、「情報収集、体験」「抽象」「検証」が必要でる
- 情報収集には、目標を適切に設定し、目標が達成可能であることが重要
- 抽象とは、大事なところを抜き出し、モデル、パターンを見つけること。自分の言葉で例えを交えて説明できることが重要
- 検証は自分が本当に理解できているか確認すること。
交通費精算自動化をサポートするSPAのWebサービスをReact/Typescript + ServerSide Kotlinで作ってリリースしました🎉
URL
フロントエンドのレポジトリ
React + TypeScript に bulma というCSS フレームワークを利用して SPA を作成しました。 コンテンツのホスティングは Firebase を選択しています。
詳細はフロントエンド編で紹介しようと思います。
バックエンドのレポジトリ(レポジトリ自体はbitbucket で 非公開)
フロントエンドから叩かれるAPIサーバーは Springboot を Kotlinで書いており Heroku にデプロイしています。 また非同期でリクエストを裁く必要がある部分は AWS Lambda で Python で書いています。
これも詳細はバックエンド編で紹介しようと思います。
https://bitbucket.org/nokogiring/expenses-automation-api/src/master/
どんなサービスか?🏝
領収書が不要な近接旅費の精算をサポートするサービス
趣味で作ったサービスなのでお金はかかりません。
既に自社内でサービスの運用は開始しており、バグとかは随時もらって修正しています。
どんな人が使うことを想定しているか?😺
- 主に営業の人。領収書が不要な近接旅費の精算が月末にたまる人。
使い方
- Google Calenar に"【駅名】訪問先"のフォーマットで予定を登録します。
- 出力されたCSV ファイルは上記のようなイメージです。
詳細な使い方は以下のチュートリアルのURL参照してください。
https://expenses-automation-app.firebaseapp.com/tutorial
作った動機 🤔
社内の営業の人が月末の夜遅くまで残って交通費精算をしていました。 何にそんなに時間がかかっているのかを伺ったところ、Google Calendar に登録した訪問先情報を元に Yahoo路線図で検索して Excel に金額を入力するという毎月末にやっているそうです。 せっかく Google Calendar に登録するという運用をしているのであれば、APIもありますし自動化できると思いサービスを作成してみました。
リアクション👍👎
ポジティブなリアクション
すぐに使ってもらえたのが嬉しくて、バグ報告をしてくれる人がいただけでも嬉しかったです。
本来の目的である単純作業が減り楽になったと言ってくれた人がいたのも作った甲斐がありました。
ネガティブなリアクション
- ネガティブなリアクションというか、そもそも使ってないし見てもいないという感じの人がいて結構ショックでした。 作業が今までのやり方から変わるので嫌だということや、結局趣味で作ったものなので、強制はできないから仕方ないかなと思います。
サービスを公開する目的
サービスに対するフィードバックが欲しい
元々社内向けツールなので、Google Calenar への登録内容や CSVのフォーマットは完全に社内の運用に最適化されています。 しかし、実際世の中の営業の人は近接旅費の精算に時間がかかっていそうなら運用を変更することで、自動化できるのではないかと思います。 運用的にハマるなら是非使ってみて欲しいです🙇🏻♂️
技術的なフィードバックが欲しい
今業務では React も Typescript も使っておらず、かつ独学なのでもっとフロントエンド力を高めるためにフィードバックが欲しいなあと思ってます。 Github のレポジトリを公開していますので、フィードバックいただきたいです。バグ報告でも!
次回予告
次回以降のこのサービスの技術的な側面からブログで紹介していきたいと思います。
【備忘録】Mac で Spotlight や Alfredを起動した後、英数で入力を開始するようにする
TL;DL 🗒
- Karabiner-Elements の Complex Modifications を利用して Alfred の起動時に "英数" キーが入力されるようにする
動機 🤔
- 普段アプリケーションランチャーとしてAlfred を利用しているが、日本語で検索することがないにも関わらず、日本語入力モードから Alfred を起動してしまい一度英数に変換するという手間を何回も経験している
- vim も escキーを押下したタイミングで 英数に切り替えるようにしているので Alfred でも同じことをしたい
前提📜
- Alfred の起動は デフォルトだと Spotlight に割り当てられている control + spacebar にしている
- Mac のキーボードカスタマイズアプリ Karabiner-Elements を利用する
Karabiner - Software for macOS
- macOS v10.13.6
以下のディレクトリにKarabiner-Elements の設定ファイルがある
vim .config/karabiner/assets/complex_modifications/xxxx.json
設定方法📜
*まずは以下の内容を 上記の設定ファイルに追加する
{ "description": "CTRL + SPACE => CTRL + SPACE, 英数キー", "manipulators": [ { [f:id:nkgr:20180826200932p:plain] "type": "basic", "from": { "key_code": "spacebar", "modifiers": { "mandatory": [ "control" ] } }, "to": [ { "key_code": "spacebar", "modifiers": [ "control" ] }, { "key_code": "japanese_eisuu" } ] } ] },
- ルールの追加
- Add Rules をクリック
先ほど追加した「CTRL + SPACE => CTRL + SPACE, 英数キー」を選択してクリック
【勉強会まとめ】クラスメソッドのモバイル開発を知る!全5回〜第4回 Webフロント開発編〜 に参加してきたのでまとめる
概要
クラスメソッド社のモバイル開発の中の Webフロントエンド開発に関する発表
セッションは以下の3つ
- Atomic Design with React
- React のレガシープロジェクトと戦って得た戦果
- クラスメソッドで働き始めたサーバサイドエンジニアの8ヶ月間
- 終了後に懇親会
Atomic Design with React
登壇者:清田 隆志 さん
- Director / UI Designer / 半熟 Web Frontend Engineer
- 元々 Director と Designer 出身で今はフロントエンドをやっている
- 開発は東京
開発しているサービスについて
スマホアプリ開発のカスタマーストーリーモバイル|クラスメソッドのサービス
- 現在は SaaS プラットフォームの開発で、CMS の管理画面を担当している
- SPAでクライアントサイドは React を利用している
- バックエンド は AWS AppSync という GraphQL サービスを利用している
- AWS のマネージドサービスの開発
Atomic Design をつかったコンポーネント管理について
- Atomic Design → UIコンポーネントを atom(原子) , molecules(分子), organisms(生体), templates(テンプレート), pages(ページ) に分割し整理・管理する手法
- 管理画面のUIを顧客が自分で細かくカスタマイズできる仕様のためコンポーネントを細分化して利用する必要があった
- デザインツールとして invision を利用している
- 具体的な Atom の分割単位は HTML のタグレベル
- 実際の開発では以下のレベルでコンポーネントを管理している
- atom → ラベル、テキスト、入力欄、ボタンなど
- molecules → 検索フォーム
- organisms → ヘッダー、フッター、モーダル、テーブル、フォームなど
- コンポーネント管理単位のはチーム内で話し合って決める
Atomic Design with React
- 基本的にAtomic Design の流儀に乗るのが良い
- 最初からAtom 層を作るのは難しい → ログインフォームとかある程度の塊から作り、そこから Atom を抽出していく
- React のコンポーネントを atom の単位で作成
- ReactコンポーネントをStoryBook を使ってコードからスタイルガイドを作成することで効率良くかつ保守しやすい開発をしていく
- スタイルガイドドキュメントを地力で作るのはつらい
- AbemaTV の開発で使われている
- 実際にどのように使うかはStorybookのサンプルと Atomic React というオープンソースがあるのでそこで確認できる
所感🤔
- Atomic Design を実際に運用している例を聞くことはあまりなかったので、大変貴重な機会だった
- Atomic Design が React にマッチしてるのがよくわかった🧠
- なんとなく受託開発で納期優先ならStoryBook を使ってコンポーネント管理していくとこまで時間かけれなさそうだけど、納品したあとも保守する前提なのかな?🤔
- コンポーネントの定義をどのように分類するかはチームでよく話し合わないとあとでめちゃくちゃになりそう😇
- エンジニアしかいない(デザイナーがいない)チームだとCSS周りとかつらそうだと思った。
- 懇親会でお伺いしたが登壇者の方が元々デザイナー出身のフロントエンド開発者なので CSS まわりも問題ないそうで。うらやましい。
- 全体的にスライドがキレイだった
- 大阪のおすすめスポットについて質問されていたが、自分的には観光なら京都に行かれては?と思った🚆
React のレガシープロジェクトと戦ってきた戦果
登壇者:伊勢洋平 さん
- フロントエンド開発
- 主にRuby on Rails の開発をやっていた
- React 歴は浅め
開発しているサービスについて
- モバイルアプリサービス
- React + Rails
- Redux
- AWSAppSync(GraphQL)
React の 開発環境
- SPA で React と Rails は別で管理している。 Git リポジトリも別
- SPA なので ルーティングはクライアント側で行っている
- 認証機能を自前で実装せず、Amazon Cognito を利用している
- React で GraphQL のエンドポイントを叩くのに react-apollo を利用している
- より安全な開発のために React コンポーネントは Class を使わずに 純粋関数で記述しStateless Functional Component を実現している
- Stateless Functional Component で開発するために recompose を利用している
- フロントエンドは 開発環境設定に凝ると時間を使いすぎてしまう → 環境構築は react-create-app
- プロジェクトがレガシー化するのがはやい → つらい
- チーム開発でコードレビューでの無駄なやりとりをなくすために eslint + prettier を利用している
- コンポーネントの引数に props を渡すときは展開式 を使うと props に何が入るかわかってよい
const button = props => {...} // NG パターン const button = ({ height, width }) => {} // OK パターン
- Flow を使って型定義を行い、実行時エラーの前にビルド時点でエラーを検知できるようにする。
- JS に型定義を持ち込むには Flow と TypeScript があるが、Flow は TypeScript よりも既存プロジェクトへの追加が容易。
- ただしTypeScriptにくらべ型情報が少ない。開発初期から使うなら TypeScript がよい
所感🤔
- JSに足りない安全安心な開発を React で行うための施策がたくさん盛り込まれていた。素晴らしい。
- recompose はつかったことないので使って見たい
- Vim@terminalでReact 書いていらっしゃったようだが、元々 Rails 出身ならなんとなく納得。Vim の入力補完で React とか対応しているんだろうか?
- GraphQL はサーバーサイドの実装がつらそうなイメージだったが、AWS AppSync はデータ設定を正しく行うだけで クライアントからGraphQL APIが利用できるようになるらしい
- 改めてReact は開発を始めるまでに準備しないといけないことが多すぎる
- 懇親会の時にデファクトスタンダードな設定がないことがつらいとみんな行っていた。
クラスメソッドで働き始めたサーバサイドエンジニアの8ヶ月間
登壇者:木田 亮介 さん
クラスメソッド社のアプリ開発について
- モバイルアプリサービス部の話
- 受託のアプリ開発がメイン
- 特に小売業向けのモバイルアプリ開発(カスタマーに近い立場のアプリが多い)
- サーバーサイドの利用する言語フレームワークはプロジェクトの特性やチームメンバーのスキルによる
- CMSなどわりと軽めのサービスの場合 → Ruby On Rails
- 高負荷なアプリケーションの場合 → Java Scala, Go
- フロントエンドは React Angularが使われる
クラスメソッドに転職する前と後の話
技術スタック
- 転職前 → php, Laravel , angular2, typescript
- 転職後 → SpringBoot(Java) , PlayFrameWork(Scala), Rails , AWS
転職前に経験のない分野だったが、先輩が優しく教えてくれる
時間かかってもいいと言ってもらえたのが心強かったそう。
怒られない、キレられない🤣 というパワーワード
- 年収が上がった(割と具体的にわかるレベルの話をしてくれた😅)
- 前の職場では技術的な話ができる人がいなかったが、クラスメソッドは優秀なエンジニアが多い
- クラスメソッド社の中でもブログを書くエンジニアは強いエンジニアらしい👨🏻💻
- AWS に詳しくないと働けないわけではない
- プロジェクト管理はカンバン
- Github issue と Backlog で管理している
- 札幌と大阪で遠隔で開発しているがコミュニケーションは密に取っている
- Slackに乃木坂の動画が上がる!!!!(素晴らしい🎉👏👏👏)
- Slack の退勤報告の時間は 19:15くらいだった
- エンジニア募集中
所感🤔
- エンジニアとして楽しく開発ができているそうで、素晴らしい🎉
- 乃木坂好きのエンジニアがいるというだけで、うらやましい👏
- クラスメソッド社に転職する前の会社の年収にはちょっと引いた😅本当に年収アップしてよかったと思う。
- 優秀なエンジニアが多い環境で働けるのはいいのと、技術好きな人が多いというはエンジニアとしては働きやそう
ターミナルの操作を記録してgif ファイルを作成する terminalizer を試してみた
Github Trends で人気だったので試してみた
概要
terminal のコマンドを記録して実行結果を記録して gif をつくれる こんな感じの gif ファイルができる
面白いのは単純に実行環境の録画ではなく、再現するterminal環境のShellを選べたり、terminalのレイアウトを選べて、後でカスタマイズできるということ
動機 🤔
- ターミナルコマンドの実行中と実行した結果をブログにはるため
環境 💻
使い方
インストール
管理は npm
利用には node.js が必須
npm install -g terminalizer
実行と録画
以下のコマンドで録画を開始して録画を開始して CTRL+D で終了する
terminalizer record demo
実行ディレクトリに以下のファイルができている
実行するシェルやterminal の背景とかフォントなど色々指定できる 単純にローカルの実行環境の実行結果の gif を作る訳ではなく色々カスタマイズできるみたい
demo.yml
# The configurations that used for the recording, feel free to edit them config: # Specify a command to be executed # like `/bin/bash -l`, `ls`, or any other commands # the default is bash for Linux # or powershell.exe for Windows command: bash -l ....(中略) # Font family # You can use any font that is installed on your machine # in CSS-like syntax fontFamily: "Monaco, Lucida Console, Ubuntu Mono, Monospace" # The size of the font fontSize: 12 # The height of lines lineHeight: 1 # The spacing between letters letterSpacing: 0 # Theme theme: background: "transparent" foreground: "#afafaf" cursor: "#c7c7c7" black: "#232628" red: "#fc4384" green: "#b3e33b" yellow: "#ffa727" blue: "#75dff2" magenta: "#ae89fe" cyan: "#708387" white: "#d5d5d0" brightBlack: "#626566" brightRed: "#ff7fac" brightGreen: "#c8ed71" brightYellow: "#ebdf86" brightBlue: "#75dff2" brightMagenta: "#ae89fe" brightCyan: "#b1c6ca" brightWhite: "#f9f9f4" ....(中略) # Records, feel free to edit them records: - delay: 208 content: 'mbp:~ user$ ' - delay: 904
記録した内容を terminal 上で再現する
terminalizer play demo
gifファイルの生成
長いコマンドだと出力に結構時間かかる
gifファイルが生成されている
render1533389856283.gif
terminalizer render demo Rendering frame 123/123 100% [==============================] 0.0s Merging frame 123/123 100% [==============================] 0.0s Successfully Rendered The animated GIF image is saved into the file: /Users/user/render1533389856283.gif
以上。終了
関西Node学園 3時限目 で「AWS Serverless Express 入門」というLTの登壇をしてきました
開始30分後からの参加だったので最初のお二人の登壇が聞けなかったのが残念だった。 京都なら避けられないだろうなー。
概要 📄
- 関西Node学園 主催のNode.js に関する勉強会 3回目
- 参加者は24人 登壇者は4人
- 日時:2018/08/03 19:00
- 場所: LINE KYOTOオフィス 京都府京都市下京区四条通麸屋町西入る立売東町28番地 SAKIZO PLAZA B1F
- 隠れ家的イベントスペースだった
成果物 🎉
スライド: AWS Serverless Express 入門
他の登壇者の方のスライドなど 🎉
www.slideshare.net
感想 🗒
自分のLTに関して
- 参加者の方から「よい刺激を受けた」と言ってもらえたのは本当に嬉しかった
- 登壇しているときに参加者の方が真剣に聞いてくれいる感じがしてありがたかった。割とすぐに使えて実用性のあるライブラリだったからかな。
- 勉強会は登壇したほうが得るものが大きい。
- Twitterの フォロアーが増えた🤣
- 懇親会の時にスライドがおしゃれと言ってもらえたのが嬉しかった(こなみかん)
スライドについてはフリーでダウンロードできる keynote のテンプレートを利用した
時間の関係上唯一聞けた「LINEで馬券を購入する」 のLTについて
- 次の自分のLTの準備してたらか話半分しか聞けなかった...
- 雑に説明すると Line の Bot に馬券情報を送り、馬券を購入するというもの
- 実際の作りはLine Messaging API を利用して AWS Lambda 上のHeadless Chrome を動かして JRA の Webサイトに情報を入力しながら馬券購入を行うというもの
- 実際に作るときのハマりポイントも紹介
- タイトルがキャッチー。結構笑いの多いLTになってたのが印象だった
- 登壇者の方と話をしたが、画像の権利関係には気をつけていたのでいらすとやを使ったそう。いらすとや最強。
昔ファミコン + 電話線で馬券を購入できた
最終的に実現したいサービス作りのために、実現すべき技術的な課題を解決していく課程が明確
- 馬券購入アプリを作りたいがJRAにはAPIがない → なければ作る
- HeadlessChromeのブラウザ自動実行でAPI化して購入する → Macではなくサーバーで動かしたい
- Lambda で実現する → Lambda のコンソールで動かすのではなく外部API化したい
- API GateWay → LineでAPIを叩く
自分のやってることをちゃんと人に説明できる人のスライドって感じ。
「どんなWebサービスでもAPI化できる」というパワーワード
確かにHeadless Chromeを使うとChromeでアクセスできるWebの操作はほぼ可能になる。 ただし、スクレイピングと同じ問題でWebサイトの変更の 事前検知 が難しい。
変更検知はdomのElementを探してなかったらエラーにするとかで実現できるだろうけど、それはアプリケーションがエラーを吐いて初めて開発者が気づく。 サービスの性質によるけど、お金取って顧客提供するようなサービスではさすがに使えないよなーと思う。
Selenium vs puppeteer
参加者質問で Selenium とどう違うか?みたいな質問が出ていた。
ブラウザの自動実行をサポート実現するという点では同じ。 どちらも windows / mac / linux で使える
- Java / Python / Ruby / Node.js など言語から利用できる各種ライブラリが出ている
- Selenium にブラウザは含まれないのでブラウザ毎のドライバーのダウンロードとPATHが通った場所への配置が必要
- ブラウザのユーザー操作を記録して再実行 / プログラムからの利用ができる Selenium IDEというブラウザ拡張機能がある
puppeteer
- 基本 Node.js がメイン
- npm install するとすぐ使える(node_modulesにlocal_chromium が入ってる)
- local_chromium のダウンロードはスキップしてpuppeteer.executablePath() で特定のパスを指定してChromeを実行できるのでApplication フォルダの Chromeも選べる
その他参加者の方や運営の方と話したこと
- 普段何の開発しているか?(Frontend ? Backend ? インフラ?) → 全部やってるという人がいてフルスタックかよ、すげーってなった。
- 業種は自社サービス?受託? → 両方いらっしゃってそれぞれ、辛みとか楽しさを語ってもらえてよかった。
- 他にどんな技術スタックに興味があるか? → Vue.js やってるって方がいて、VueはやっぱHotだなと。
- Node学園は Nodeがメインだけど、そろそろ フロントエンドの話があってもいいのでは?と思った。Node.js をバックエンドでガチで使って運用している企業は比較的に少ない印象。Node.js の利用用途はフロントエンドの開発環境構築の方が使う人多いと思うので、フロントエンドのLTとかあると参加者の間口が広がりそう。
- さくらインターネットはコンソール画面のリニューアルでフロントエンド募集しているらしい。
運営の方がめっちゃ低姿勢だし、色々サポートしてもらったので登壇者として本当にやりやすかった。いつかこういう勉強会の運営にも携わりたい。
Lineのエンジニアミートアップがある。さっき見たらもう埋まってたけど、抽選みたい。ちょうど出産予定日前後だから無理だなー。行きたいけど。