Baby steps to migratory bird

元半導体系エンジニア、今Webエンジニアの雑記

【参加してきた】次世代Webカンファレンス

先週開催された次世代Webカンファレンスに参加してきました。

nextwebconf.connpass.com

各セッション資料は用意されておらず、各分野の有識者によるディスカッション形式で話が進みました。

セッションの構成は下記になります。

  • アクセシビリティ
  • パフォーマンス
  • 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プロキシ

  • 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との付き合い方

  • テレビはしばらくなくならなさそう

    • WebとつながることによりXRへつながっていく。
  • 今時はリンクをシェアしない。画面をキャプチャしてシェアする。

    • URLをわからず使っている。
    • ARと知らずにARを使う世の中になるのでは。
  • play canvas

  • ARはWebがいいと思うが、VRはWebでなくてもいいのでは

  • いつ来るのか?

    • 今は仕様策定の最中
    • WebVRはすでにChrome LTSに載っている。ARはまだ載っていない。
    • ポジトラ:ポジショントラッキング
    • KhronosはOpenXRをやろうとしている。
    • 2020年に5Gが来るので、その頃には来るのでは?
    • モバイルよりはSSRしたものを送ってしまった方がいい説
    • 3Dに触れておくとか、3Dに数学が必要なんだな、ということを今のうちに知っておくのが良さそう。
  • CSSシェーダーなくなってしまったのが残念。。

  • WebGL村はCG国とWeb国の派閥の間にいる
  • WebGLは色々自分でやらないといけない。結構難しいのは知って置いた方が良い。
    • だが、手軽な方向に行って欲しい。
  • シェーダー
  • ジオメトリ
  • google poly
  • 今のうちに低レイヤーの仕様をきちんと策定しておきたい。

  • WebXRは機械学習と相性が良さそう

HTTPS

(自分がよくわかっていないところ、大体古川さんの要約ツイートがされてて助かりました)

  • EVも信頼を失いつつある今、CAは何を売るのか?

  • HTTPSだけで安全を保証できないなら、「安全に安全を保証するにはどうすれば良いか?」

  • TLS1.3

  • MLS: Message Layer Security
  • SSL pulse

  • TLS1.0と1.1を消すのはどのくらい大変なのか?

  • TLS1.3以降で必要になって来るものは?

    • TLSの量子コンピュータへの対応も必ず必要になって来る
      • 量子コンピュータがデプロイされる前に準備されておかなければならない。
    • 量子コンピュータは周期性があるものに対する計算が強い

      • 鍵交換では素数を使っているのでなんとかしないといけない(素数には周期性がある)
      • ハッシュ値を使っているものは、桁数を上げれば対応できるはず。
    • LTSという土管を通る前後の安全性をどう扱うか?

      • LTSの上位レイヤーの話
    • SXG

    • コンテンツに対して証明できるようにしたい。

    • AMP: Accelarated Mobile Pages

    • URLで識別するには、もう限界がきている。

HTTP3

まとめ

話題も多岐にわたりいろいろと消化しきれていないのですが、各分野で前線を貼っている人たちが何を気にして戦っているのかを知れたのは良かったかなと思います。

あと「そもそも普段自分が触っている技術の最前線を抑えられているか?」と自分に問い直してみると、 「ニュースとして流し見はしているが理解度は高くない」ということが多いのでまずはそこから対応した方が良いよね、というお気持ちです。

【参加してきた】よちがや.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さんが以前読書会をして、良い本だったとのこと。

www.crummy.com

  • 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を最初から読んでみました。

tech.misoca.jp

最近esaの記事移行を試したり、API書いたりしていて、そのあたりの所作を学びたいというのがモチベーションです。

メモ

メモはコミット順に沿っています。

gemspecの記述

gemで使いたいgemの情報はGemfileでなく.gemspecに書く。

add_dependency "hoge", "0.0.1"

https://github.com/misoca/wataridori/commit/41cf71715e77acf3223cf4e0a9771c5440898150#diff-c69a792d7d3d4f44144816b77a532882

リファレンス https://guides.rubygems.org/specification-reference/

参考記事 gemライブラリの依存はGemfileではなくgemspecに記述する理由

テストしやすい書き方をする

以下ではtoken, from, toを渡す先をnewからfrom_teamnameに切り出すことで、 クライアントの差し替えを行い易くしている。

https://github.com/misoca/wataridori/commit/82faabb727bcd94e76542d898f6071cd4acdc83a

CI

ツールが小さいうちに導入するの良さそう

ラッパークラスの導入

ラップしておくと今後の実装で便利らしい →レート制御、リトライ制御 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

nokogiri gem

こんちゃんさんが言ってたprivate accessorや↓

https://github.com/misoca/wataridori/commit/80a2c018dabb4ca1a2b217e2d8ae7dfc4bf5ba76#diff-04c30e2e12fac45633edb2fc268a2d1cR37

複数コマンド対応の書き方

https://github.com/misoca/wataridori/commit/448973083708bc87b44cd9ea20483bbaf4548db6

retry処理の導入

retrieble gem

https://github.com/misoca/wataridori/commit/dea92a14e7b44ceec415bb764555a893bd305027

まとめ

普段はある程度形ができたリポジトリのコードを読むことが多いのですが、公開されるまでの流れを把握できる規模のコードを読むのはひよっこエンジニア的にかなり勉強になりました。

たまたま「名前に親近感を持った」という興味で読み始めたのですが、こういうOSS貢献しているMisocaさん素敵だなぁと思いました。

他業界から転職してきたWebエンジニアの1年後はまだまだ「楽しくてしかたがない」のか?

はじめに

これは#しがないラジオ Advent Calender 2018の17日目の記事です。

昨日16日目はVTRyoさんの記事でした。

blog.vtryo.me

「楽しく生きて何が悪い。楽しく働いて何が悪い」

力強く書き綴られた言葉が心に響く凄い記事でしたね。


本日のお品書きです

自己紹介

渡り鳥といいます。

今は某企業にてRailsエンジニアをやっています。 去年他業界から移ってきて、Webエンジニアになってだいたい1年ほどです。

元々PHPを書いていたのですが、諸事情により転職して今はRubyをメインに触っています。

最初の転職の経緯はこちらの記事に書いているので、もし興味ありましたら覗いて頂けると嬉しいですm(. .)m

ちなみにこの記事は、去年のしがないラジオアドベントカレンダーの番外編を勝手に書いたものです 笑

しがないラジオと出会って1年

僕がしがないラジオのことを知ったのは去年の秋頃だったのですが、他業界からWeb業界に移ってきた身として毎回楽しみに聴いています。

ゲストが続々

どんどんゲストが豪華になってきてますね〜

普段自分が触れない技術やマネジメントの話など、パーソナリティのお二人がわかりやすくゲストのお話を掘り下げてくれるのでありがたいです。また毎回ゲストの生い立ちから話が進むので、親近感を持ちながら聴けるところがすごく好きです^^

Meetup

今年は2回ありましたね。 先日の2回目には参加できなかったのですが、5月に行われた1回目に参加して受付や動画撮影などしてました。

参加してみて、しがないラジオがとても愛されていて、色んな人に影響を与え、背中を後押ししてくれる良いコミュニティを作り出しているのだなぁとすごく温かい気持ちになりました。僕も今年しがないラジオに背中を押される出来事があり、すごく感謝してます。ありがとうございます!

Meetupに参加したことのない方には、とても臨場感のあるVTRyoさんのブログがオススメです。

しがなく動き続けた1年

この1年、自分なりに色々動いてみたので、よかったこと/残念だったことなどつらつら書いていこうと思います。

1. 勉強会

今年の前半はジャンル問わず顔を出していました。言語的にはPHP/JS/Go/Ruby、また機械学習やデザインなども色々です。

[よかったこと]
 色々見てみることで、自分が直に触っていないが盛り上がっているネタについて
 知ることができた。
[残念だったこと]
 浅く広く参加しすぎてそれぞれの技術を深堀りできなかった。

こんな反省を活かして、後半は勉強会のジャンルをRubyに絞る&参加数も抑えるよう意識しました。あとワークショップ形式やディスカッション形式など、今の自分に効果的だなと思うものに参加するようにしました。

試しに集計して見たのがこちら↓

月ごとの勉強会参加回数
月ごとの勉強会参加回数

※主催は後述の輪読会のこと

数は全然減ってませんでいた 笑

ジャンルについて見てみると、、

f:id:roo_oregon:20181216112318p:plain
参加した勉強会のジャンル比率

※こちらは輪読会は含めず

前半はだいぶカラフルですが、後半は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後の飲み会でまたもやぷぽさんに背中を押され動いてみたのですが、 賛同してくれたメンバーに恵まれて最後まで走りきることができました。

恐縮です。。

【発表スライド】みんなで読めばつらくない!Web技術の輪読会の話

最近はこの輪読会メンバーでRuby gemを作ってみたり、アドベントカレンダー書く会(まさにこの記事を書いてます)

来年からは徳丸本で有名な体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践の輪読会をやる予定です。もし興味ある方がいればTwitterなどでお声がけくださいm(. .)m

[よかったこと]
 小さなところからでもコミュニティに役立てることは嬉しいし楽しい。
 煽りに乗ると思ったより良いことがある。
[残念だったこと]
 特になし

5. 運動

僕は元々運動好きなのですが、ある日connpassを眺めていた時にこんな怪しげなグループを見つけてしまいました。

sport-creator.connpass.com

実はiOSDCのところでも出てきたあかつきさんが主催するバスケイベントだったのです。

知っている人が全然いない中、恐る恐る参加してみたのですが、楽しすぎて気づいたら毎度参加する常連になっていました。

もくもく会→運動→飲み会、のゴールデンルートは最高なので気になった方はぜひ参加してみてください〜

[よかったこと]
 よく知らない場所にもえいやで飛び込んでみると良いことある。
[残念だったこと]
 特になし

まとめ

今年は気づいたらしがないラジオの影響で色々前進していた1年でした。

僕はエンジニアとしてまだまだ未熟で毎日学ぶことだらけですが、引き続き楽しんでやっていきたいです。


ということで、他業界から転職してきたWebエンジニアの1年後も、、

楽しくてしかたがない!


明日、18日目は@kdnaktさんです。 内容は「しがないラジオの感想の予定」とのこと。お楽しみに!

【参加メモ】第1回 Nuxt.jsハンズオン 初心者編

最近Vueのチュートリアル触ったし、Nuxtも触ってみたいなと考えてたところでライブ配信ありの情報を見つけたのでリモート参加してみた。

frontend-temple.connpass.com

ハンズオンの資料はリンク貼っていいかわからないので貼らないけれど、 イベントページからslack参加すると当日のハンズオンチャンネルがあるのでそこで見られる (エラーの対応ログも残ってるので良きです)。

配信動画は今は見られないみたい。

参加のモチベーション

Nuxtなんぞ?を触りながら感じたい

Nuxtの特徴

  • 環境構築が楽
  • ディレクトリ構成が決まっている
  • Vue.jsはインターフェースが整っているので、誰でも同じ様に書ける。
  • Sassが使える
  • HTMLそのまま使える(JSX書かなくて良い)
  • 動きをつけやすい
  • モジュールが便利
  • 静的サイトジェネレータ

途中で

Nuxtは学習コストが低いわけではなく、
インターフェースが整っているだけ

というコメントがあったのはなるほどなぁという感じだった。

ハンズオンの流れ

最初にサーバー起動して以降は ほぼVueのハンズオン的な感じで進み、 こちらも流行りのNetlifyを利用して静的サイトをデプロイして終了。

といった感じだった。

Nuxtを使いこなす、というところまではいかないけれども、 最後にデプロイできる体験はハンズオンとして良いなぁと思う。

まとめ

  • まだVueをまともに触ったことない人はまずはVueからちゃんとやった方がいい感じ。
  • Nuxtを触りたいモチベーションって普段フロントでVue触ってて、サーバーサイドのハードル下げつつアプリを作りたいところにあるのでは。
  • 逆に普段Railsなどサーバーサイド触ってる立場からすると、そこにVueを組み込むのが早いと思う。

    →なのでちゃんとやるなら、自分もまずはVueかなと。

【参加メモ】第一回 エリック・エヴァンスのドメイン駆動設計 読書会

最近DDDの勉強会をよく見るなぁ、と機運が高まっていたので参加

evans-ddd-book-read.connpass.com

今回は初回ということで全体構成の紹介とまえがき・第1章の解説でした。

主催者の@moaieeeさんが時折笑いを交えながら、全体的に緩やかな雰囲気で進められました。

詳細な説明よりは、イメージを掴んでもらうようなゆるいスタイルの解説的な感じで進みそう(な予感)です。

全体構成

1,2部の話は正直つまらないかも、とのこと

自分の理解度に応じて参加回を決めてOK

  • 1部 用語の定義と動きの紹介
  • 2部 モデル駆動開発の基本構成の紹介
  • 3部 実用的なモデルの設計と実装の話
  • 4部 より大規模な設計の話

まえがき

  • モデルとは何か?

    あるものを抽象化したもの

image.png (109.8 kB)

  • モデルを蒸留する

    モデルまでだけでなく、実装までやってくぞ、という話

第1章

構成

  • やり方

    モデルを取り出す5つのポイント

  • モデル化

    モデルを取り出す流れ

      PCB回路の例
    
  • 実装化

    モデルを適用したコード

      貨物の運搬の例
    
  • モデルを取り出す

    〜知識を噛み砕く〜

PCB回路の例

  • ヒアリングから徐々にモデルを作り出していく

  • 人により言葉の定義が違う

  • ヒアリングを進めるうちに目的が曖昧になりがち。。

    →実は、回路の遅延回数を知りたい。それを表すモデルが欲しいことがわかる。

  • ここでは何が言いたかった(と思われる)こと

    設計者へのヒアリングを繰り返すことで、知識を噛み砕き、 モデルを洗練させていきましたよ、という例。

  • 最初から完璧なモデルはできないので、継続的な学習により深いモデルが出来上がっていく。

【参考】

船に載せる貨物の例

最初の簡単な例を作る
(航海に貨物を載せる)
↓
制限の追加
(最大予約数を実装に反映)
↓
新たな制限の追加
(さらに実装に反映)
↓
(洗練を繰り返す)

【参考】

早くも2回目が公開されてる

evans-ddd-book-read.connpass.com

こちらも気になる ddd-community-jp.connpass.com

【Ruby】putsの返り値はnilらしいと聞いて色々みてみた。

きっかけ

Railsチュートリアルを眺めててたら

4.2.4 メソッドの定義の演習3で

palindrome_tester("racecar")に対してnil?メソッドを呼び出し、
戻り値がnilであるかどうかを確認してみてください 
(つまりnil?を呼び出した結果がtrueであることを確認してください)。
(以下略)
def palindrome_tester(s)
  if (条件。問題なので省略)
    puts "It's a palindrome!"
  else
    puts "It's not a palindrome."
  end
end

と書いてあり、なんでだろ?と思ったので調べてみた。

また、 注記13にもこんなことが書いてある。

実際には些細な違いがあり、pメソッドは画面出力だけでなく戻り値も
オブジェクトになります。
しかし、putsメソッドの場合は引数によらず必ずnilが戻り値になります。
(以下略)

リファレンスを見てみる

module function Kernel.#putsより

puts(*arg) -> nil

引数と改行を順番に 標準出力 $stdout に出力します。 引数がなければ改行のみを出力します。

引数が配列の場合、その要素と改行を順に出力します。 
配列や文字列以外のオブジェクトが引数として与えられた場合には、 
当該オブジェクトを最初に to_ary により配列へ、 
次に to_s メソッドにより文字列へ変換を試みます。
 末尾が改行で終っている引数や配列の要素に対しては puts 自身 は改行を出力しません。

なるほど標準出力されるのか〜

元々標準出力に向けてアウトプットするためのメソッドであり、返り値を得るようにはできてないですよってことなのだろうか。

似ているメソッドとして、module function Kernel.#pも見てみる。

p(*arg) -> object | Array

引数を人間に読みやすい形に整形して改行と順番に標準出力 $stdout に出力します。
主にデバッグに使用します。

引数の inspect メソッドの返り値と改行を順番に出力します。つまり以下のコードと同じです。

print arg[0].inspect, "\n", arg[1].inspect, "\n", ...
整形に用いられるObject#inspectは普通に文字列に変換すると
区別がつかなくなるようなクラス間の差異も表現できるように工夫されています。

p に引数を与えずに呼び出した場合は特に何もしません。

こっちは出力した情報を色々抜き出したりできるよう、返り値がオブジェクトになっているっぽい。

試してみる

Rails上で比較してみた。

  • メソッドではメッセージ作成のみ。viewで<%= %>
# 例えばapplication_helper.rb
def thanks_message(user_name = "ユーザー")
  "#{user_name}さん、ありがとうございます"
end

# 例えばthanks.html.erb
<div class="thanks_message"
  <%= thanks_message(@user.name) %>
<div>

<結果> 当たり前だけど(ユーザー名)さん、ありがとうございますと表示される。

  • メソッド内でメッセージをputsして、それを<% %>viewに埋め込む
# 例えばapplication_helper.rb
def thanks_message(user_name = "ユーザー")
  puts "#{user_name}さん、ありがとうございます"
end

# 例えばthanks.html.erb
<div class="thanks_message"
  <% thanks_message(@user.name) %>
<div>

<結果> viewには何も表示されない! 一方、rails sしてるconsoleの方を見てみるとこっちに出力されてた。

色々試したが整理するとこんな感じ↓

メソッド内の出力メソッド↓/viewの表記→ <% %> <%= %>
なし 非表示 表示
puts 非表示 非表示
p 非表示 表示

(pでも表示できるけど無駄感ハンパない。。)

余談

そもそも<%= %>は何を出力してくれるのか

結果を出力

なるほどわからん。

  #   <%# WRONG %>
  #   Hi, Mr. <% puts "Frodo" %>

はい、ごめんなさい。。

ここらへんだろうか https://github.com/jeremyevans/erubi/blob/master/lib/erubi.rb#L129-L133

when '='
          rspace = nil if tailch && !tailch.empty?
          add_text(lspace) if lspace
          add_expression(indicator, code)
          add_text(rspace) if rspace
# Add the given ruby expression result to the template,
    # escaping it based on the indicator given and escape flag.
    def add_expression(indicator, code)
      if ((indicator == '=') ^ @escape)
        add_expression_result(code)
      else
        add_expression_result_escaped(code)
      end
    end

    # Add the result of Ruby expression to the template
    def add_expression_result(code)
      @src << " #{@bufvar} << (" << code << ').to_s;' // to_sで文字列に変換
    end

    # Add the escaped result of Ruby expression to the template
    def add_expression_result_escaped(code)
      @src << " #{@bufvar} << #{@escapefunc}((" << code << '));'
    end

結局の所to_sで文字列に変換してるということらしい。

to_sはObject classのメソッドなので、何でも文字列として返す(はず)。

例えば対象がarrayでも

[1, 2, 3].to_s
=>"[1, 2, 3]" # 返り値はこんな文字列になる

まとめ

  • putsの返り値はnil, pの返り値はarrayオブジェクト
  • viewに出力するときはオブジェクトを用意して素直に<%= %>で書こう