はい。Beer Advent Calendar 2017の8日目です。
30歳になってからというものの、1日に2缶空けて晩酌するのが当たり前になってしまった僕が8日目を担当します。
今日はたまたまコンビニで見かけた「キリン ブラウマイスター」というビールを飲みました。
どうやら、セブン＆アイグループで限定発売らしいですね。
普通の一番搾りと比べると少し苦め。味はサッポロ黒ラベルに近い印象で個人的には好きな味です。
程々の重厚さで飲み飽きないので、今週はこればかり飲んでる未来が見えます。
ないです。酔っ払いの駄文です。
jQueryに依存したライブラリを含めつつ、webpackでよしなにbundleする必要があったのでやってみた。
試した環境は以下の通り。
webpackは「npm install --save-dev」で、jQuery系は「npm install --save」でインストールしておく。
webpack.config.js
const webpack = require('webpack'); const config = { entry: './src/index.js', output: { path: `${__dirname}/`, filename: 'bundle.js' }, plugins: [ new webpack.ProvidePlugin({ $: 'jquery' }) ] }; module.exports = config;
pluginsの箇所にProvidePluginの記述を追加。$にjQueryを入れてもらうように設定する。 bundle.jsの吐き出し先は好きに変えちゃってください。
index.js
// ProvidePluginで$に入れているので // import $ from 'jquery'; の指定は不要 import 'jquery.cookie'; $(function(){ // $にjquery.cookie.jsの処理が入っているか試す $.cookie("name", "myname", { expires: 7 }); });
これをwebpackでビルドし、htmlを適当に作って、bundle.jsを読み込めばcookieが書き込まれているのを確認出来ると思います。
https://webpack.js.org/plugins/provide-plugin/
公式のドキュメント読むのが一番手っ取り早かったです。
相変わらずフロントエンドエンジニアをやっているわけですが、PHPとかRubyとかも触る機会が増えたり iTerm2を開いている時間が増えたりしていたので、普段使っている道具を見直す事にした。
前職でReact +Reduxをやっている時はWebStormで良かったわけですが、そうもいかなくなった。 そういうわけで、入社のタイミングで個人ライセンスを購入した。
※会社で買ってもらえなかったわけではなく、申請とかが色々面倒だったです。
Railsの勉強が落ち着いたら、これでKotlinの勉強も円滑に始められるのでサイコー！って感じです。
会社が変わったら、周りにbashを使っている人が全然いなかったので変えることにしました。
周りの人にはzshを勧められたのですが、「ここはあえてfish shelklかな・・」という反抗的な精神が働いたのでfish shellを入れました。 クラスメソッドさんの参考記事を見つつ、fishermanとzを入れて使ってみている感じです。
三連休でちょくちょく手を動かしている内に徐々に慣れてきたので、仕事で使うのが今から楽しみで仕方ないですね。
業務でコードを書く上でメモを残すことが欠かせなくなりつつあるのですが、しっくり来るメモアプリに出会えずにいました。
Macの標準メモアプリを使っても良いのですが、それだとコードを書くには微妙です。 ちょっとした事を書くために、社内のconfluenceを開くのもだるいです。
悩んだ結果、「やはりマークダウンだよね」ってことでInkDropを使うことにしました。
使い始めて2日しか経ってないですが、今のところ何の不満もなく快適に使えているので、トライアル期間の60日が過ぎたら普通に課金すると思います。
※自分でmarkdownエディタを作るモチベはない
不要なストレスが減り、快適に開発が出来ているなーという印象です。
今後も理想の開発環境を目指して、色々とチューン・アップしていこうと思っています。
↑のような背景があって、Project EulerをRubyの練習の場とすることにした。 どこにコードを載せていくかは決めていないが、qiitaかGitHub辺りにひっそりと載せていくつもり。
周りからRubyのアドバイスを貰いつつ、4問目を解き終わった辺り。とはいえ、ただ解いただけで処理速度とかは全然考慮できてない。
一応、ここに問題とコードを載せてみることにする。
左右どちらから読んでも同じ値になる数を回文数という. 2桁の数の積で表される回文数のうち, 最大のものは 9009 = 91 × 99 である. では, 3桁の数の積で表される回文数の最大値を求めよ.
def palindrome? (number) number.to_s == number.to_s.reverse end palindrome_array = [] (100..999).each do |i| (i..999).each do |j| result = i * j palindrome_array << result if palindrome?(result) end end puts palindrome_array.max
重複した計算を排除したり、eachの繰り返しを降順にするだけでも大分変わってくる気はするものの・・正直苦戦している。
20問目まで解くのを、とりあえずの目標にしておく。頑張っていくぞ。
ブログ枠で参加してきたので、ブログを書く。
面白い話は多かったけど、次回開催があってもたぶん行かない。理由は後述。
Keynote3本 + LT7本という構成で、合計で90分くらいでした。惹かれる内容もいくつかあったので、感想を述べます。
イタリアンレストラン、Webの受託会社で働いてきた人が30歳でDeNAに入り、普段どんな事を求められながら働いているのかという話を聞いた。「最初に求められたのがスタイルガイドの作成だった」という話を聞いて、実際にどういう運用をしているのかを深掘りして聞いてみたい気持ちになった。
上記のような感じだったので、内容が全然頭に入ってこなかった。
keynoteの中では一番惹かれるタイトルだっただけに残念。スライドが公開されるなら、見返したい(ヽ´ω`)。
名前は知っていたものの、MobXの話をちゃんと聞くのは初めてだった。
「stateという単語が出てきたので、Reactに似てるといえば似てるのか・・？」という印象を受けた。「observableが理解できれば、すんなり入っていける」的な話だったので、自分で手を動かしてみようと思っている。
まあ、autoprefixer使うくらいで十分だと思う。
個人的に、今はCSS4とかの先取りをするモチベーションが無いので、PostCSSのオレオレ構成を作る気も無い・・。
Chrome60で大幅に機能追加があった、DevToolsのAuditsパネルの話。
などが見られるようになる。Canaryの最新版が既に61とかなので、そっちで試せる筈。
「Webの品質」について考え直すきっかけになるとも思うので、気になる人は発表資料に目を通そう。
Webフロントエンドで大切なことは全てAuditsが教えてくれた
WebGLとかthree.jsとかそっちよりの話。
AndroidでJavaをやっていた時にOpenGLを勉強していた事もあって、個人的に凄く惹かれる内容。 しかし、5分で収めるにはディープだった感が否めなかった。別の機会があれば、もっと深い話も聞いてみたい。
↑この辺で遊んで見ると楽しそう。
Firebaseでチャットルームみたいのを作ってデモをやっていた。近くで内部の社員っぽい人達がワチャワチャ喋っていて、あまり発表者の声が聞けなかったのが残念。
FirebaseでSlackチックなものを雑に作るのは楽しいかもなーと思いながら、デモを眺めてました。
「フロントエンド開発、iPhone基準で考え過ぎ問題」がテーマのLT。
↑の辺を紹介しつつ、PWA化の実装を今から始めていこう的な話が聞けて面白かった。
ただ、日本ではiOSのシェアが大きい事もあり、普段からPWA化の時間をどれくらい確保できるかが悩みのタネな気がする。
↑みたいな導入から始まったLT。社内でも「jQueryやりたくないです（流行りな事をやりたいだけ）」みたいな声はちょくちょく聞くので、共感出来る所はある。
↑みたいな話にも触れていて、自分としても耳が痛い話があった。
これからは、チュートリアルを一通りやるだけで満足せずに何かしら形にしてアウトプットすることを心がけたいと思う。
Web業界に20年近くいるベテランの方から、↑みたいな話を聞けた。
「知識や技術のネットワークを広げると、どんどん面白さを感じられるようになっていく。」って辺りには凄く共感。触っていく内に徐々に慣れてきて、やれる事が広がると楽しくなるもんだと自分でも思っている。
KeynoteやLTは非常に楽しめたのだが、「LT + 懇親会」という構成は辛かったように思える。
「静かに発表者の話を聞きたい人」と「おしゃべりをして懇親したい人」が混在しつつ、「静かに発表者の話を聞きたい人」の方が割合多めだった気がするので、空気が少し重かった。
個人的に一番気になった（というか不快だった）のが、発表中に社員っぽい人達が雑談してる声が聞こえてきた事。発表を聞かないのは自由だと思うけど、それならそれで静かにしてて欲しいと思った。Keynoteの時間からそんな感じで、イベントに参加して嫌な気分になったのは久々だった。
「次回開催があってもたぶん行かない。」と思ったのはこの辺りが原因。お疲れ様でした。
↑のイベントに参加してきました。
（通常枠で申し込んだつもりでいたが、直前になって「ブログ執筆枠」で申し込んでいた事に気づくという阿呆ぶりを発揮。）
こんな人間から見た感想を書いていきます。
※発表者の方の資料は、展開され次第追記していきます。
チームスピリットさんが開発してるプロダクトがReactで開発されていて、それのパフォーマンス改善の話を聞いた。
結論はLTのタイトルにもある通りでそこまでパフォーマンスを改善する必要が無かった、とのこと。普段から設計やコードレビューに気をつけていた甲斐もあって、現状のパフォーマンスは悪くないし、改善を試しにやってみても0.01秒くらいしか変わらなかったらしい。
「Reactは最初から、ある程度のパフォーマンスを保てるようにできてる。」と言いつつも、何も考えずに開発を進めていると徐々にパフォーマンスが悪くなるので、以下のような事を開発の際に意識していたそう。
パフォーマンスが悪くなってマジで困ったら、Perfで何とかするそうです。
以前は自分も「スプレッドオペレータでpropsを全部渡す」をやってしまっていたので、同じ道を通った人がいて親近感を感じた。
やはり、必要なものだけを渡した方が無駄なprops比較も無くなるし、コードの見通しも良くなって良いですね。
自分が関わっているプロダクトではrecomposeのpure、shouldComponentUpdate、onlyUpdateForPropTypes辺りを使って、再レンダリングの負荷を出来るだけ軽減してたりします。
あと、スライドにちょいちょい挟まれる「いらすとや」の画像がジワジワ来て面白かった。
Goodpatchのよしこさんのお話。
Prottをリニューアルする動きがあるらしく、リニューアル時に使用する技術選定の話を聞いた。
この辺りの技術を使用する予定らしい。「Goodpatch = Angular」みたいなイメージを持っていたので、Reactに舵を切るのは正直意外だった。
といった感じの選定基準（+Angularを選定しなかった理由）らしい。
Reduxを入れた理由は「オレオレFWへの恐怖」だそう。Reduxのstate管理は良いと思いつつも、middlewareを使ったりせずに薄く使っていくつもりらしい。
middleware不要論についての参考リンク。
Flowを入れた理由は、やはり型が欲しいから。TypeScriptは候補に上がったものの、言語そのものをスイッチするよりもJSに型チェックを入れる方がライトに感じて、Flowに決めたそう。（ただし、Flowはハマりどころが多いそう）
とはいえ、まだ始めたばかり。Reduxを脱却するかもしれないし、TypeScriptに移行するかもしれないとのこと。
複雑な物を作ろうとすれば、何を使おうが大変になるだろうなーと思う。自分も1年間Reduxをやってきて、多くのメリットを感じつつもかなり苦労したので・・。
Flowは導入時に結構辛い思いをしたが、入れた方がコードの品質は高まっている感覚がある。
React沼CSSArchitect // Speaker Deck
試用期間中にReact、webpack、1つの巨大なSassファイルと戦った話を聞いた（個人的主観）。
「Reactでの画面のコンポーネント化は進んでいたが、CSSは1つのSassファイルに集約されていた。」 webpackによる長いコンパイル時間、CSSの見通しの悪さをどうにか解決したかったので、技術的にCSSを解決するアプローチを始めたらしい。
とはいえ、ツールは設計の解決までやってくれるわけではない。その辺りは別で考える必要があるので、BEMを使って設計アプローチを試みたそう。最終的には「単純で誰でも理解できる設計」に落ち着いたとのこと。
「コンポーネントの粒度は、JSとCSSで1:1」の原則で運用。CSSのimportルールとかも資料に詳しく書いてあるので、読むと良いかもしれない。
React-Storybookを使って、コンポーネント単位でのサンドボックス環境を作っているらしい。作った理由は、webpackのビルドが遅かったから。今後はstorybookを使って、styleguideにしていく計画もあるそう。
自分も昔はBEMでCSS設計をやっていたので、苦労は凄く理解できた。特に「クラス名考えるのが大変」って辺りの件は非常に共感。 （正直、もうBEMを使いたいとは思っていない）
今のプロジェクトではCSS in JSを使っているので、今後別の仕事をする際もそれで行きたいなーって気分でいる。
スタイルガイド作るのメンドイ。
LT後はビールを飲みつつ、スピーカーの方々のパネルディスカッションを聞いてました。
色々議題は合ったんですが、その中で印象に残ったものを少しだけ触れます。
会場で話を聞いた限り、コーディングまでやるデザイナーさんは稀らしい。
Goodpatchさんでも、フロントエンドとデザイナーの業務は明確に分かれていて、デザイナーさんがコーディングまでやることは基本的にないそう。
「コーディングまで綺麗にやってしまうデザイナーさんは、もはやデザイナーという枠を超えた存在なのでは・・」という気がしてる。
結論から言えば、共存は可能。とはいえ、「jQueryが必要になる場面は殆ど無いのでは？」という意見も出ていた。
自分もReactやり始めの頃は「jQueryの世界に帰りたいよぉ・・」とか言ってたので気持ちはすげー分かる。
今ではReactにすっかり慣れたので、「アニメーションさせるなら、jQueryの方が楽だな・・」というくらいの心境。
Airbnb凄い。
スタイルガイドを運用する上で起こりがちなのが、「実装とスタイルガイド間のズレ」。スタイルガイド側への反映が漏れていて、気づいたらスタイルガイドが役立たずになってるアレです。
これを技術で解決しましょう、ってことでreact-sketchappの出番が来ます。 要するに「作った画面をSketch上に描画する」という仕組み。こうすることで、実装とガイド間のズレを無くそうって話です。
今まで使ってなかったけど、ちょっと興味を惹かれたので試してみようと思っています。
翌日早起きしないといけなかったので、懇親会に出れなかったのが心残り。
スピーカーの人が作ったという、ローストビーフが食べたかった・・(ヽ´ω`)。
あと、話に上がっていたAtomicDesignの本が面白そう。
第二回があれば、是非参加したいなと思います！
