【参加してきた】JAWS DAYS 2019
昨日JAWS DAYS 2019に参加してきました。初参加です!
今年のテーマは『満漢全席』というだけあり、A~Kまでの計11トラック、約100セッションのてんこ盛りなイベントでした。
公式サイト
参加目的
参加時点での自分のステータスはこんな感じ
- 普段の業務でAWSはちょくちょく触るが、がっつりは学習できていない。
- Dockerなどのコンテナ技術を含めたDevOpsに興味を持っている。
AWS周りの技術は何となく身近だけど真面目に勉強したことがないという状態だったため、どんな進め方で身につけるかのヒントを得ようと主に初心者向けのセッションをピックアップして参加しました。
新卒1年目のSREがコンテナをデプロイできるようになるまでの道のり
10:10~ Fトラック
eureka/ex-eurekaのコンビが初めてDockerを触るところからKubernetesの導入、AWSへの展開、今後の展望など約300ページにも及ぶてんこ盛りな内容でした。
初心者からみて疑問を覚えるワードに逐一簡単な解説が挿入され、駆け足にもかかわらず置いていかれずに聴くことができました。 OJTでのやりとりベースで話が進んだところも、聴いている側が入り込みやすくてよかったです。
同日湊川あいさんのマンガでわかるDocker AWS編も販売されていたのですが、合わせて読むと完璧なのでは\(^o^)/ (今日からBoothでも購入できます!)
EC2 T2インスタンスでつまづきやすいCPUクレジット〜EC2でチャットボット作って運用でハマって学んだ話〜
11:10~ Dトラック
www.slideshare.net
EC2のCPUクレジット切れ、自分も経験して焦ったことあるのでわかりみが深い〜と思いつつ聞きました。実はCPUクレジットの計算方法がよくわかっていなく、かなりわかりやすい説明でありがたかったです。
次の話でもあったのですが、最小構成でいいのでまずは始めて知見を貯めていくと良いよというお話がありました。
モバイルアプリのバックエンドをEC2で運用している話
(資料まだなし?)
コスト以外に技術検証にかけられる時間も、利用するサービスを制限する要素になる話があり、自分の中その手法が確立できているのが大切なのだなぁと思いました。
ランチ
弁当戦争に負けた我々をやさしく待ち受けていた豚丼
GitHub Actionsを使って、ワークフローもプルリクベースで開発しよう!
昨年10月に発表されたGitHub Actions(現状ベータ版)を利用して、EKSにデプロイするまでのデモがありました。
Actionsは基本Dockerfileに書いていくとのこと。そうすることで運用をモジュール化したり、OSS化したりと、皆で良い方向に進みましょうというコンセプトらしいです。
あまり資料が上がる雰囲気がなさそうなので(笑)、
ここらへんを追うといいかと思います。 (あとでまとめるかも)
- #jd2019_h
- @ikeike443
- GitHub Actions · GitHub
- Marketplace · Tools to improve your workflow · GitHub
- GitHub - sdras/awesome-actions: A curated list of awesome actions to use on GitHub
- Home - GitHub Community Forum
昼寝
(お腹いっぱいだったので帰ってちょっと昼寝^^;)
AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩
(資料まだアップされてないはず)
普段GUIでしか操作しない人向けに、CLIをちゃんと活用できることが運用自動化への最初の一歩だよ、というお話でした。 色々なtipsがてんこ盛りで、資料公開されたら一人ワークショップしたいところ。
アイコンにパンチが効いてます笑
資料
早速Qiitaにまとめてくださった方がいました。感謝!!
まとめ
自分はAWS初心者目線で参加したため、インフラのトレンドな話は聞かなかったのですが、自分のレベルに合わせて上記リンクを逐一見直して行こうと思います。 まずはDockerと最小構成でのAWSデプロイかな
【参加してきた】銀座Rails#6
銀座Railsについて
『テストコード未経験者が RailsでそれなりにRSpecがかけるようになるまでの話』 by @shinkuFencerさん
資料
ご本人の登壇記事
メモ
自分もRSpec書き始めてから日が浅いので、めちゃ響く発表でした。新規開発でゼロからRSpecを導入するよ、という人に一番良さそうな内容(目の前の広大なRSpecの海に立ち向かうバージョンもどこかにないでしょうか 笑)
紹介されてたふつうのRailsアプリケーション開発、開発における「ふつう」の指針が整理されてて何度も読みたい神資料でした。
『Rails6からRailsをわかってく』 by cawaさん
資料
メモ
Rails6の解説というよりは、「自分も詳しくないけどだいたいここらへん見とけば良い感じでキャッチアップできそう」というまとめでした。
またRails6.0にはRuby2.5以降が必要ということで、そちらのRubyとRailsの両方のキャッチアップ情報が含まれていました。
- 基本的にはリリースノートで注目すべき差分を押さえる。
- リリースノートから関連するPRへリンクが貼られているので詳しくはそこへ
- Railsのclosed PRを読んでみるとなるようになるブログのrails commit log流し読みの理解度up
- 新機能のソースコードを読んで見る(発表で言ってたactionmailboxの各メールツール向け実装はここらへん)
とここまではリリース済み(もしくは決まっている)内容のキャッチアップなのですが、 この先どうなるのかなーと気になったらこのあたり見ると良さそうです。
- Ruby trunk / ロードマップ
- Rails 6.0.0 / マイルストーン (GitHub Milestones最近おぼえた)
今まで何となく見たことあるかも、という情報群でしたが、もうちょっと真面目にウォッチしようと思ういいきっかけになりました。そのモチベを保つには普段触れるRubyやRailsのバージョンが最新に近いかどうかが効いてくるので、何とかしないと。
1からの再出発 by onkさん
資料(ブログ)は公開されていません。togetterだとこのあたり
メモ
- 自分の中でこうあるべきという指針を持つ。その指針は世界のどこへ行っても通用する王道をベースとして実践する(っょぃ)
- 転職などで新しい環境へ移動した時、前後のギャップを感じられるのははじめの数ヶ月(その期間を大切にしよう)
- レガシーなアプリをメンテし続けると世間から置いていかれる感が積み上がり退職に繋がる
- ADKARモデル
総括
開始1時間前に申し込むというドタ参もいいとこな感じでしたが、参加してよかった〜
世の中には自分が気づいてない公開された知見が、まだまだたくさんあるなぁと再認識しました。
【参加してきた】次世代Webカンファレンス
先週開催された次世代Webカンファレンスに参加してきました。
各セッション資料は用意されておらず、各分野の有識者によるディスカッション形式で話が進みました。
セッションの構成は下記になります。
- アクセシビリティ
- パフォーマンス
- WebXR(*)
- セキュリティ(*)
- 広告
- 認証
- マイクロサービス
- SRE
- HTTP3(*)
- フロントエンド
- HTTPS(*)
- CSS
- Webミュージック
- デザイン
*付のセッションに参加
このところはRubyによるオブジェクト指向/デザインパターン、JavaScript、Gitの基礎的なところを勉強しているので、今回は視野を広げるべく普段あまりインプットしないジャンルのセッションに参加しました。 (動画が公開されているため、全て観られるのですが)
基本的にはなるほど知らなかった、というトピックが多く検索しつつ箇条書きしたメモになります。
メモ
セキュリティ
今度から徳丸本の輪読会を始めるし、生徳丸先生もいらっしゃるのでちょっとしたミーハー感もありつつ選びました笑
Webアプリの開発者はセキュリティについてどの程度気にするべきか?
- あまり気にしなくていいのでは?(気にしたいけど)
- ブラウザ側の問題なのにアプリ側で対応する、というのはいけてない。
- Flashだとクロスドメインなのにjsonが送れる問題(徳丸本に書いてあるとのこと)
- 正しく理解せずに「いいから黙ってつけとけ」に従っていると、機能が動かない時などよくわからず外してしまったりするので危険
クッキーの上書きに対して
- __hostのクッキーで対応できる。
- githubのクッキーでも採用されている。
- これをman in the middleで設定していないと、httpsに対応していても、クッキー上書きにより他人がログインできてしまう。
- プリロードでの対応策もある?
ダブルサブミットクッキーはダメ?
- fuelPHPやDjangoでデフォルトで入っていたらしい。
- OWASP
クッキーの使用では;のみ区切り文字だが、
- パーサーにより:も対応しており、
- それによるニッチなバグがあったりする。
CSPについて
GDPRの影響
- クッキーをセットするのに同意を求めるやつ
- 今形骸化してしまっているのですごく良くない。
- 昔話) IEのP3Pポリシー
個人情報の収集について
- google検索でリファラーが送られていたり(今はやめたらしい)、マーケティング目的でユーザーの動作を収集していたりするが、これは業界的にはなし崩し的に常識となっているが、知識のない一般ユーザーはそういうことを認識していなかったりする。
- そのうち「このサイトではJavaScriptが使われています」と出さないといけなくなるのでは? →ディストピア感。。
ハードウェアだとPL法によりセキュリティバグを公表しなければならないが、ソフトウェアはそうでなく公表されないケースが多い。
man in the middleプロキシ
- 中間者攻撃 - Wikipedia
- 作って学ぶ 「Https Man in The Middle Proxy」 in Go - ( ꒪⌓꒪) ゆるよろ日記
- バーク(綴りわからん)
- http2、grcpに対応してない
Webアプリケーションエンジニアに対するお気持ち表明
- 徳丸さん「何でもかんでもコピペするのは危ない」
- 検索して一発目に出てくるコードがイケてないことが良くある。
- bulkneetsさん「開発者みんながセキュリティに対する当事者意識を持ってほしい」
- 全ては分かってなくても良いが、取っ掛かりでそこに気づいてほしい。気づいてくれれば、あとは相談してもらえれば良い。
- k2wankoさん「開発者のみなさんにもセキュリティについてもっと興味を持ってもらえると嬉しい」
- リクルートだと開発者とセキュリティのジョブローテがあるらしい。
- 徳丸さん「何でもかんでもコピペするのは危ない」
WebXR
XR: AR/VR/MRを合体させたもの
WebXRは来ると思うか?
- モバイルデバイスから来ると思っている。ARが来る。
- その中でWebで有用性があると思うのは、ショッピングサイトの商品を自分の部屋に置いてみる体験をしてもらう。
- 例えば教育。博物館などにあるようなものを実際に部屋に置いてみる。
- また地図。自分が行きたい方向へ矢印を表示する
Webの良さはインストールがいらないところ
ARクラウドという情報インフラが出て来るのでは?と各社興味を持っている。
WebGLは来る?
- ハイエンドのゲームから、一般ユーザー向けの簡単な動きを作るところまで。
- ブラウザからGPUの力を使うためにWebGLを使う。
- CG界隈は堅苦しい?WebGL界隈にはその雰囲気は持ち込みたくないと思っているが、、
- WebGL:ゲームのようなハイエンドから、サイト上での簡単な動気をつける、GPUを使うためなど、色々な使い方がある
- 3Dは必要になるし、学んで置いた方が良いのでは?
- 今の時点では3Dの表現をできるのはWebGL一択
- WebGPU、Web用のシェーダー言語、などWebGLに変わる新しい仕様が出るかもしれないが、今のところはWebGL一強
Web開発者目線でのARとの付き合い方
- Khronosという団体がWebGLをサポートしている。
テレビはしばらくなくならなさそう
- WebとつながることによりXRへつながっていく。
今時はリンクをシェアしない。画面をキャプチャしてシェアする。
- URLをわからず使っている。
- ARと知らずにARを使う世の中になるのでは。
play canvas
- 導入 | Learn PlayCanvas
- インストールしなくて使える、はかなり使いやすい体験
ARはWebがいいと思うが、VRはWebでなくてもいいのでは
- VRとARの違いはCGの濃度の違い
- 現時点のARとVRは融合する手前の状態
- nreal light
いつ来るのか?
- 今は仕様策定の最中
- WebVRはすでにChrome LTSに載っている。ARはまだ載っていない。
- ポジトラ:ポジショントラッキング
- KhronosはOpenXRをやろうとしている。
- 今乱立されているのを、標準化したいお気持ち。
- OpenXR Overview - The Khronos Group Inc
- 2020年に5Gが来るので、その頃には来るのでは?
- モバイルよりはSSRしたものを送ってしまった方がいい説
- 3Dに触れておくとか、3Dに数学が必要なんだな、ということを今のうちに知っておくのが良さそう。
CSSシェーダーなくなってしまったのが残念。。
- WebGL村はCG国とWeb国の派閥の間にいる
- WebGLは色々自分でやらないといけない。結構難しいのは知って置いた方が良い。
- だが、手軽な方向に行って欲しい。
- シェーダー
- ジオメトリ
- google poly
今のうちに低レイヤーの仕様をきちんと策定しておきたい。
WebXRは機械学習と相性が良さそう
HTTPS
2018振り返り
- Symantecの事件
- PKIベンダー苦難の年
- ワールドワイドでシェア3割だったのに、一瞬でディストラストされてしまった。
- Symantecはブラウザの信用を外されてしまった。
- Chromeで信頼されなくなるSymantec発行のSSL証明書かどうか判定・確認する方法:Tech TIPS - @IT
- Symantecの事件
- 今理解しておくべきトラスト〜Web PKIのサーバ証明書事情〜
- CT (Certificate Transparency) 証明書の発行ログを見られるようにすることで、みんなで変な証明書が発行されていないかを監視したいというモチベでやっている。
CAの重要性が上がっているが、使えるルート認証局が減少する問題
- 大手 (Symantec) でも信用できないとなると、結局どこを選べば良いのか?
- ルート認証局の数自体は減っておらずむしろ増えている。ルート自体は増えている
- lets encryptのようなDV証明書が主流になっている。EV証明書は無くなる方向
- Let’s EncryptがVerisignと棲み分けできる理由: SSL証明書の「DV、OV、EV」とは何か
- 今さら聞けないSSL証明書とは、DV、OV、EVとは、常時SSLについて | レンタルサーバーのCPIスタッフブログ
TLSは認証はしているが、信頼はしていない
- DV証明書は認証はするが、信頼はしていない
- EV証明書は、信頼をちょっと上乗せしている
- EV証明書は去年インシデントがあった。
- イギリス:identity verified
- アメリカ:stripe
- 違う州で違う会社が同じ名前で証明書をとったケース
- EV証明書を使用して既知の企業になりすませる可能性が指摘される | スラド セキュリティ
- EV証明書は去年インシデントがあった。
EV証明書は信頼されなくなったこれには2つの理由がある。
— Yosuke FURUKAWA (@yosuke_furukawa) January 13, 2019
- Identity Verified という証明書が出た、これを悪用するケースがiOSであった。
- 別の組織の人がお金さえ払えばEV証明書を作れてしまう事例があり、これによりお金さえ払えばフィッシングサイト作れるという事例ができてしまった#nwc_https
(自分がよくわかっていないところ、大体古川さんの要約ツイートがされてて助かりました)
EVも信頼を失いつつある今、CAは何を売るのか?
HTTPSだけで安全を保証できないなら、「安全に安全を保証するにはどうすれば良いか?」
TLS1.3
- RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
- TLS1.2との後方互換性を大切にしているため、それほど変わっていない?なぜか?
TLS1.3印象:
— Yosuke FURUKAWA (@yosuke_furukawa) January 13, 2019
- 今までボロボロの長屋をダンボールで補強してたのをプロトコルごと変えたのは良い
- ただし、あんまりドラスティックに変わってない
- ドラスティックに変わってない理由の反面教師はIPv6
- 後方互換性をなくすと絶対変更について来れない#nwc_https
- MLS: Message Layer Security
SSL pulse
TLS1.0と1.1を消すのはどのくらい大変なのか?
TLS1.3以降で必要になって来るものは?
- TLSの量子コンピュータへの対応も必ず必要になって来る
- 量子コンピュータがデプロイされる前に準備されておかなければならない。
量子コンピュータは周期性があるものに対する計算が強い
- 鍵交換では素数を使っているのでなんとかしないといけない(素数には周期性がある)
- ハッシュ値を使っているものは、桁数を上げれば対応できるはず。
LTSという土管を通る前後の安全性をどう扱うか?
- LTSの上位レイヤーの話
SXG
コンテンツに対して証明できるようにしたい。
AMP: Accelarated Mobile Pages
URLで識別するには、もう限界がきている。
- TLSの量子コンピュータへの対応も必ず必要になって来る
HTTP3
- HTTPなのにTCPじゃないの?
- なぜHTTP3と名乗っているの?
- 低レイヤー側は変えているが、インターフェイス的にはセマンティクスは変わっていないからいいんじゃない?的に思っている。
- 詳解 HTTP/3
- 元々の課題感
- Googleが作るQUICとIETFが作るQUICが混乱を招きそう
- ブラウザがログを吐くときにバージョニングする方が便利
- QUICは意外と広まっている (5-10%)
- キャリアグレードNAT
- Firewallが想定している挙動とQUICやTLS1.3の挙動が一致していないため通らない問題
- バージョンごとに通ったり通らなかったりする問題。。
QUICとロードバランサーの両立はどうすれば良いか?
- 対応策
- connection idはipが変わったら変更する。
- connection idを外側からは暗号化する
- 対応策
ロードバランサーがQUICに対応しないといけない?
0RTT
LRU
BBR 輻輳制御アルゴリズム
Wifiと公衆回線の切り替え時に、通信が途切れる問題が解決されるのでHTTP3 (QUIC) 使って欲しいとのこと。
new reno cubic
WebRTC over QUIC
Webのこれから
まとめ
話題も多岐にわたりいろいろと消化しきれていないのですが、各分野で前線を貼っている人たちが何を気にして戦っているのかを知れたのは良かったかなと思います。
あと「そもそも普段自分が触っている技術の最前線を抑えられているか?」と自分に問い直してみると、 「ニュースとして流し見はしているが理解度は高くない」ということが多いのでまずはそこから対応した方が良いよね、というお気持ちです。
【参加してきた】よちがや.rb REST会
よちがや.rb REST会について
普段開催日が被っているよちよち.rbとSendagaya.rbの合同開催で、tkawaさんがRESTについてRailsチュートリアルを進めている/終えたレベルの人に向けて、tkawaさんがRESTを解説する会でした。
RESTといえば、去年自分達でやっていたWebを支える技術のテーマもRESTでした。輪読会向けの資料を作る際、毎度tkawaさんの過去記事が参考になりいつかお礼を言いたいなぁと思っていたので、個人的に今回は願ったり叶ったりな会なのでした。
資料
RailsスタイルからRESTを学ぼう よちがや.rb
www.slideshare.net
内容メモ
- RESTful Web APIs
翻訳されていないらしいですが、tkawaさんが以前読書会をして、良い本だったとのこと。
- RESTとは制約である
- 9個の要素で出来た枠に沿って当てはめていく
RESTという制約の元でうまく調和を保ちつアプリを作るには、その要素であるURL/HTTP/HTMLのことをよく知り、正しく使いましょう(この3つはWebを支える技術でも再三重要であると挙げられていました)
- リソースの名前(URI)と4種類の操作(リクエストメソッド)で機能を実現する
- Railsが広まることで、RESTも広まった。
- Railsのアクションとリソース/メソッドの対応
- リクエストメソッドが当てはまらないときは、隠れたリソースがある。
Railsはver2以降、そのリソース設計のパターンをRESTに沿うように方向転換した。それとRailsの普及が相まり、REST視点で違和感のある設計が減少したとのこと。
この点について、規約の強いフレームワークには技術の差分を埋める役割があると以前聞いたことがあったのですが、Railsはある意味正しいフォームの要請ギプスになっているのかなと感じました(逆に隠蔽されることで、意図しないとその差が埋まりづらいとも言えるかも)。
またRailsがデフォルトで作成するControllerのアクションとリソース/メソッドの対応表のがわかりやすかったです。
そして「リクエストメソッドが当てはまらないときは、隠れたリソースがある」という話は、とても学びがあるなぁと頷きながら話を聞いていました。制約に従うことにより、考え方の指標ができるのですね。
- PUTとPATCHについての質問
ここまでRailsでデフォルトで利用するリクエストメソッドはGET/POST/PUT/DELETEの4つという話だが、Railsではver4からPUTの代わりにPATCHが採用されていますよね?という感じの質問が出ました。tkawaさんが想定Qです!と元気よく返答してたのが印象的でした笑
ちなみにPUTとPATCHは両方ともリソースの更新を行うリクエストメソッドで、 PUTでは変更対象のリソースのデータを丸ごと更新するが、PATCHでは変更対象のリソースのうち変更するデータのみ部分的に更新するという違いがあります。これにより更新操作においてPUTが持っていたべき等性が、PATCHに変更することでべき等でなくなり、色々議論があったそうです。
【参考記事】次期RailsがPATCHメソッドを採用 - ぶろぐ。@はてな
- 現実的にはRESTから外れる部分もある(なのでRESTful)
とはいえ現実的にはRESTから外れることもあるよね、ということでいくつか質問も挙がっていました。
おまけ
- Rails周りのHTTP1.1とHTTP2.0の話
RailsではHTTP1.1で通信しているが、その先のCDN以降はHTTP2に変換されてたりする。その距離をできるだけ短くすることで通信の高速化を実現している。元々RailsでHTTP2を採用する構想もあったが、結局そうなってないらしい。
まとめ
今までRailsとRESTは密接に関係があるよという話は聞いていたのですが、tkawaさんの解説によりWebを支える技術で学んだことや普段触るRailsアプリの構造が自分の中でより整理できたように思います。参加して良かった〜
軽めのgemをコードリーディングしてみた w/ wataridori
はじめに
この記事で紹介されているgemにとてもても親近感を覚えたので、コードリーディングの練習としてcommit logを最初から読んでみました。
最近esaの記事移行を試したり、API書いたりしていて、そのあたりの所作を学びたいというのがモチベーションです。
メモ
メモはコミット順に沿っています。
gemspecの記述
gemで使いたいgemの情報はGemfileでなく.gemspecに書く。
add_dependency "hoge", "0.0.1"
リファレンス https://guides.rubygems.org/specification-reference/
参考記事 gemライブラリの依存はGemfileではなくgemspecに記述する理由
テストしやすい書き方をする
以下ではtoken, from, toを渡す先をnewからfrom_teamnameに切り出すことで、 クライアントの差し替えを行い易くしている。
https://github.com/misoca/wataridori/commit/82faabb727bcd94e76542d898f6071cd4acdc83a
CI
ツールが小さいうちに導入するの良さそう
Circle CIの導入 https://github.com/misoca/wataridori/commit/97db850fd19447299248659fcb608d33ac641e52
RuboCopの導入 https://github.com/misoca/wataridori/commit/dc248d23bb71e07054c50ff411465d8dd5a8e946
ラッパークラスの導入
ラップしておくと今後の実装で便利らしい →レート制御、リトライ制御 https://github.com/misoca/wataridori/commit/c3dbba1caa916ae9a82cc1e37fdce05b94aaeef7
method_missingもここで用意している(メタプロ感)
ガード節という書き方(リファクタ)
普段使ってるけど名前があったのか。 処理の冒頭に条件判断とreturnを入れて例外処理を完結させる。 ネストが深くなるのを防止できる。
https://github.com/misoca/wataridori/commit/d55361632ea3f3e5ca320409ef7a2e5bb451e20d
参考記事 初心者向け。覚えておきたい 「ガード節」という書き方。
インスタンス変数へのアクセサをきちんと書く
今回はattr_readerだがこんな感じのセット
- attr_reader: 読み込み
- attr_writer: 書き込み
- attr_accessor: 読み込み&書き込み
https://github.com/misoca/wataridori/commit/2a229be5ad7185669c77334f9494679b28ef5fa2
リファレンス https://ref.xaio.jp/ruby/classes/module/attr_accessor
APIのRate Limit (利用制限)
結構最初の方に仕込んでるのでAPI利用時に注意することとしては高めぽい。
esa APIのRatelimitを表すクラスを追加 https://github.com/misoca/wataridori/commit/81ad20c8188891146de51f2683207497f0069f0a
Wataridori::Esa::ClientでRatelimitを考慮するよう機能追加 https://github.com/misoca/wataridori/commit/d22862b254798fbc7a2a7439c2a1af7d06faf141
例) GitHub https://developer.github.com/v3/rate_limit/
参考記事 APIとは?API Rate Limitってなに? WebAPIを設計するうえでの利用制限(Rate Limit)について調べた
テストの可読性を上げる
https://github.com/misoca/wataridori/commit/2cc1ba07a1e80a285f17182e59a477d56a8d61d9
ページネーションへの対応
https://github.com/misoca/wataridori/commit/8ebf6a70f3ddf76ea8a03b04eb1514d35b879314
なるほどこういう書き方をするのね 仕様としてnext_pageがないとnullが返ってくるのでそこでloopが終わる(loop処理はあとでリファクタされてました)。
def list_posts(category, per_page) posts = [] page = 1 loop do res = from_client.posts(posts_params(category, page, per_page)) posts += res.body['posts'] page = res.body['next_page'] break unless page end posts end
Hashie gemの導入
ハッシュをより便利に。 https://github.com/intridea/hashie
参考記事 ぼくのおすすめGem その2
ロガーでスクリプト実行内容を標準出力
何をやっているかをわかるようにする。 https://github.com/misoca/wataridori/commit/68f8f8d0158647e15a1e5fd44b6f159bd07ead47
コマンド追加とREAD ME追記
処理の改善
- コピー処理をページごとに実施することでメモリ効率を改善
- yieldの使い方要復習
https://github.com/misoca/wataridori/commit/23d7a0a93b38687d4ba9a7332d8a0768834a367f
データのまとまりは構造体にする
ここでもhashieが活躍 https://github.com/misoca/wataridori/commit/637553181956be2b678fcbfca9945cc5781961ad
参考記事 構造体を使ったプログラム
共用体というのもあるらしい。
リンクの書き換え用にnokogiriを導入
https://github.com/misoca/wataridori/commit/b255e92817c55fe085b95ba900ba8777bc5804af
https://github.com/misoca/wataridori/commit/80a2c018dabb4ca1a2b217e2d8ae7dfc4bf5ba76
こんちゃんさんが言ってたprivate accessorや↓
複数コマンド対応の書き方
https://github.com/misoca/wataridori/commit/448973083708bc87b44cd9ea20483bbaf4548db6
retry処理の導入
https://github.com/misoca/wataridori/commit/dea92a14e7b44ceec415bb764555a893bd305027
まとめ
普段はある程度形ができたリポジトリのコードを読むことが多いのですが、公開されるまでの流れを把握できる規模のコードを読むのはひよっこエンジニア的にかなり勉強になりました。
たまたま「名前に親近感を持った」という興味で読み始めたのですが、こういうOSS貢献しているMisocaさん素敵だなぁと思いました。
他業界から転職してきたWebエンジニアの1年後はまだまだ「楽しくてしかたがない」のか?
はじめに
これは#しがないラジオ Advent Calender 2018の17日目の記事です。
昨日16日目はVTRyoさんの記事でした。
「楽しく生きて何が悪い。楽しく働いて何が悪い」
力強く書き綴られた言葉が心に響く凄い記事でしたね。
本日のお品書きです
自己紹介
渡り鳥といいます。
今は某企業にてRailsエンジニアをやっています。 去年他業界から移ってきて、Webエンジニアになってだいたい1年ほどです。
元々PHPを書いていたのですが、諸事情により転職して今はRubyをメインに触っています。
最初の転職の経緯はこちらの記事に書いているので、もし興味ありましたら覗いて頂けると嬉しいですm(. .)m
ちなみにこの記事は、去年のしがないラジオアドベントカレンダーの番外編を勝手に書いたものです 笑
しがないラジオと出会って1年
僕がしがないラジオのことを知ったのは去年の秋頃だったのですが、他業界からWeb業界に移ってきた身として毎回楽しみに聴いています。
ゲストが続々
どんどんゲストが豪華になってきてますね〜
普段自分が触れない技術やマネジメントの話など、パーソナリティのお二人がわかりやすくゲストのお話を掘り下げてくれるのでありがたいです。また毎回ゲストの生い立ちから話が進むので、親近感を持ちながら聴けるところがすごく好きです^^
Meetup
今年は2回ありましたね。 先日の2回目には参加できなかったのですが、5月に行われた1回目に参加して受付や動画撮影などしてました。
参加してみて、しがないラジオがとても愛されていて、色んな人に影響を与え、背中を後押ししてくれる良いコミュニティを作り出しているのだなぁとすごく温かい気持ちになりました。僕も今年しがないラジオに背中を押される出来事があり、すごく感謝してます。ありがとうございます!
Meetupに参加したことのない方には、とても臨場感のあるVTRyoさんのブログがオススメです。
しがなく動き続けた1年
この1年、自分なりに色々動いてみたので、よかったこと/残念だったことなどつらつら書いていこうと思います。
1. 勉強会
今年の前半はジャンル問わず顔を出していました。言語的にはPHP/JS/Go/Ruby、また機械学習やデザインなども色々です。
[よかったこと] 色々見てみることで、自分が直に触っていないが盛り上がっているネタについて 知ることができた。 [残念だったこと] 浅く広く参加しすぎてそれぞれの技術を深堀りできなかった。
こんな反省を活かして、後半は勉強会のジャンルをRubyに絞る&参加数も抑えるよう意識しました。あとワークショップ形式やディスカッション形式など、今の自分に効果的だなと思うものに参加するようにしました。
試しに集計して見たのがこちら↓
※主催は後述の輪読会のこと
数は全然減ってませんでいた 笑
ジャンルについて見てみると、、
※こちらは輪読会は含めず
前半はだいぶカラフルですが、後半はRuby/Railsが圧倒的に増えてます。方向性はブレていない。よし!
[よかったこと] 手をつけるジャンルを絞ることで、技術的に少しずつ深堀りできるようになってきた。 継続して同じ勉強会に参加していると、徐々にコミュニティの一員になれてる感覚があり楽しい。 [残念だったこと] 特になし
2. 登壇
そんなこんなで勉強会に色々参加してみたのですが、だんだん話を聞くだけでは物足りなくなってきました。 発表してみるとすごく勉強になるよーと登壇者の方もよく言っているし、自分も何か発表したい。でも発表できるようなネタがない。。 と悶々として日々を過ごしていました。
そんな時omoiyari.fmの#22 「Trello があるので眠れない」を聴き、「とりあえずLT枠で申し込んでみて、内容は後から考える。きっと何か思いつく」というハック?を知り、5月に初めてWEBエンジニア勉強会の登壇枠で申し込んでみました。こちらはしがないラジオのsp6a/sp6bでゲスト出演されたOSCAさんが開催されている勉強会です。毎回話題が幅広く勉強になる上、発表初心者にも優しい会なので「今まで発表したことないけどどこか良い勉強会ないかな〜」という方はぜひ!
[よかったこと] 発表のプレッシャーがあるとインプットの質も上がる アウトプットの工夫をするのは楽しい 登壇するのは楽しい [残念だったこと] 特になし
(LT申込駆動は主催者のOSCAさんに少し心配されていたようなので、ご利用はほどほどに!笑)
今年はSQLから輪読会の発表まで色々発表してみたのですが、 来年はより技術を深堀りした話ができたらな〜と思ってます。日々精進です。
手前味噌ですが登壇した時の記事はこちら↓
【ブログ記事】【LTしてきた】WEBエンジニア勉強会 #07
【ブログ記事】【LTしてきた】WEBエンジニア勉強会 #08
3. 転職
最初の方にも書いたのですが、今年の6月頃に2回目の転職をしました。
何があったのか?
最初に転職してから5ヶ月ほどしたある日、 「諸事情により所属する開発部がなくなる」という話が浮上。。 当時の上司「ワイ、これから会社作るけど付いてくる?」 私「お世話になりました!(やべー!)」
30代でWebエンジニアになり半年、というなんとも微妙な経験値で転職することになり、
「周りと自分の実力差が見えてきた分、未経験の時より不安がでかいぞ」と若干焦りつつ転職活動を進めました。
ともあれ1ヶ月弱のナイス無職転職活動期間を経て内定を頂き、晴れてRailsエンジニアに。社内に強いエンジニアの先輩がいたり、自社でRubyの勉強会が開催されたりとすごく恵まれた環境にいます。
実はRubyに興味を持ったきっかけがsp.13b【ゲスト: pupupopo88】楽しいよちよちRubyistがコミュニティに貢献する理由で紹介されていたよちよち.rbに行き始めたことだったので、しがないラジオがきっかけで今楽しくRubyを触れているのは間違いないです!
よちよち.rbも良いコミュニティなので、ぜひ参加してみてください!
普段はRailsチュートリアルの輪読会ですが、最近は特別企画も開催されていて、経験問わず幅広く楽しめる会だと思います。
[よかったこと] 思いがけず転職することになったが、実は良い環境に移動するチャンスだった。 [残念だったこと] 特になし
4. 運営
色々な勉強会に参加する中で、技術力が突出してる訳でもない自分でも何かコミュニティの役に立てないかなぁと考え、 少しずつ運営側にも携わるようになっていきました。
WEBエンジニア勉強会の当日手伝い
実はWEBエンジニア勉強会で初めて登壇するとき、初めての当日スタッフもやってみました。
この時の会場はYahoo! LODGEさんで、OSCAさんのブログにも運営裏話が書かれているのですが、 大きな会場を借りる大変さやそれをやりきるということに微力ながら関わることができて、「次はどこかのカンファレンスに関わりたい」と思うようになりました。
カンファレンスの当日スタッフ
ということで勢いで申し込んだのがiOSDCでした。
普段iOSアプリ開発に全く携わっていないのですが、後述するバスケイベントに参加するうちに「iOS界隈楽しそう」と思うようになり、 その主催者のあかつきさんのブログで「とりあえずやってみればいいじゃん」という気になり(単純ですね 笑)、気がついたら申し込んでいました。
スタッフ当選のメールが届いた時には「マジか 笑」とビビりましたが、参加してみて最高に楽しかったです!
【ブログ記事】iOS開発未経験だけどiOSDC当日スタッフしてきたよ!
輪読会
こちらは先日のWEBエンジニア勉強会で紹介したのですが、今年の8-11月に「Webを支える技術」という本の輪読会を主催しました。
よちよち.rb後の飲み会でまたもやぷぽさんに背中を押され動いてみたのですが、 賛同してくれたメンバーに恵まれて最後まで走りきることができました。
煽られたとしても、それを実際に実行したのはカッコいいです。それだけでも尊敬にあたいします!
— みずりゅ (@MzRyuKa) 2018年11月9日
#WEBエンジニア勉強会10 pic.twitter.com/qhCcy64dcq
恐縮です。。
【発表スライド】みんなで読めばつらくない!Web技術の輪読会の話
最近はこの輪読会メンバーでRuby gemを作ってみたり、アドベントカレンダー書く会(まさにこの記事を書いてます)
来年からは徳丸本で有名な体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践の輪読会をやる予定です。もし興味ある方がいればTwitterなどでお声がけくださいm(. .)m
[よかったこと] 小さなところからでもコミュニティに役立てることは嬉しいし楽しい。 煽りに乗ると思ったより良いことがある。 [残念だったこと] 特になし
5. 運動
僕は元々運動好きなのですが、ある日connpassを眺めていた時にこんな怪しげなグループを見つけてしまいました。
実はiOSDCのところでも出てきたあかつきさんが主催するバスケイベントだったのです。
知っている人が全然いない中、恐る恐る参加してみたのですが、楽しすぎて気づいたら毎度参加する常連になっていました。
もくもく会→運動→飲み会、のゴールデンルートは最高なので気になった方はぜひ参加してみてください〜
[よかったこと] よく知らない場所にもえいやで飛び込んでみると良いことある。 [残念だったこと] 特になし
まとめ
今年は気づいたらしがないラジオの影響で色々前進していた1年でした。
僕はエンジニアとしてまだまだ未熟で毎日学ぶことだらけですが、引き続き楽しんでやっていきたいです。
ということで、他業界から転職してきたWebエンジニアの1年後も、、
楽しくてしかたがない!
明日、18日目は@kdnaktさんです。 内容は「しがないラジオの感想の予定」とのこと。お楽しみに!
【参加メモ】第1回 Nuxt.jsハンズオン 初心者編
最近Vueのチュートリアル触ったし、Nuxtも触ってみたいなと考えてたところでライブ配信ありの情報を見つけたのでリモート参加してみた。
ハンズオンの資料はリンク貼っていいかわからないので貼らないけれど、 イベントページからslack参加すると当日のハンズオンチャンネルがあるのでそこで見られる (エラーの対応ログも残ってるので良きです)。
配信動画は今は見られないみたい。
参加のモチベーション
Nuxtなんぞ?を触りながら感じたい
Nuxtの特徴
- 環境構築が楽
- ディレクトリ構成が決まっている
- Vue.jsはインターフェースが整っているので、誰でも同じ様に書ける。
- Sassが使える
- HTMLそのまま使える(JSX書かなくて良い)
- 動きをつけやすい
- モジュールが便利
- 静的サイトジェネレータ
途中で
Nuxtは学習コストが低いわけではなく、 インターフェースが整っているだけ
というコメントがあったのはなるほどなぁという感じだった。
ハンズオンの流れ
最初にサーバー起動して以降は ほぼVueのハンズオン的な感じで進み、 こちらも流行りのNetlifyを利用して静的サイトをデプロイして終了。
といった感じだった。
Nuxtを使いこなす、というところまではいかないけれども、 最後にデプロイできる体験はハンズオンとして良いなぁと思う。
まとめ
- まだVueをまともに触ったことない人はまずはVueからちゃんとやった方がいい感じ。
- Nuxtを触りたいモチベーションって普段フロントでVue触ってて、サーバーサイドのハードル下げつつアプリを作りたいところにあるのでは。
逆に普段Railsなどサーバーサイド触ってる立場からすると、そこにVueを組み込むのが早いと思う。
→なのでちゃんとやるなら、自分もまずはVueかなと。