2019-11-03

FRONTEND CONFERENCE 2019行ってきたので雑な感想

日記

最近の案件でVueでSPAに入門して、設計どうしたらいいかさっぱりで困ったので、ヒントでもないかなーと行ってみた。

あと関西でやってくれるカンファレンスとても助かるのでできるだけ行きたいよね。

もっとデザイン寄りかなーと思ってたけど、思ってたよりプログラマ寄りというか、そんな感じだった。まあそもそも俺が選んだセッションがプログラマ寄りだったのもある。

セッション・LTの感想
運営の混乱
個人的な反省
総括

セッション・LTの感想

各セッションのスライドは以下にいい感じでまとめられていた。

https://qiita.com/chieeeeno/items/33969dca006681e9be68

LTのスライドに関しては上記ページになかったので、ここからリンクしてある。またセッションのスライドのうちA-5についても上記ページにないためリンクした。

A-1 モダンJavaScript再入門

タイトル通りの話。VueでSPAやったときは一応ES2015で書いたけど、十分理解できているかというとそうでもなかったので。

Computed properties, 分割代入、別名つけての分割代入あたりは知らなかった。

個人的にいちばん気になったのは、紹介されているシンタックスがIE以外のブラウザではすでに一通り動作するというあたり。そういえばちょっとした動作確認するときに雑にconstとかアロー演算子使ってたけど、Firefoxでは動いてたな。

A-2 ディレクトリ構成ベストプラクティス〜 Angularアプリを作り続けてわかったこと

Angularの人によるプロジェクトのディレクトリ構成の話。とはいえAngularに限った話ではなく。さらに言うならおそらくフロントエンドに限らずサーバサイドでも普通に通用する話だったかと。

ドメインごとにディレクトリ作るか、レイヤー(セッションではタイプと呼ばれていたけど)ごとに作るか。どっちもつらみがあり、特に大規模になるとつらいとのこと。

登壇者が辿り着いたベストプラクティスは割とシンプルに、あまり細かすぎない程度にレイヤーで分ける感じ。サーバサイドのフレームワークでよくあるのに近いかな、って感じで個人的には納得。

このセッションは話もとてもうまかった。が、内容しっかりしてる割にスピードあったのでついていくのが大変だった。

C-3 レガシーなフロントエンドをリプレイスする

A-2もそうだけど、このセッションもなにが問題なのかを説明するのがすごくうまかった。

Angular 1とVueが混在するとか、とにかく作ったかのようなレガシーっぷりがウケた。そんなレガシーを作り出してしまう環境から、どうやってしっかりリプレースする流れに持って行ったのかが気になるところ。

A-4 2019年のUIパフォーマンス

フロントエンドの表示のパフォーマンス周りの、多分基本的な話。なぜ多分かというとこの辺さっぱりなので基本的な話なのかの判断もつかないから。

小手先の話ではなく、そもそもライブラリは常に改善されているから最新版を使おうとか、ロードされるコードのサイズ自体を減らしていこうとか、本質的なところでどうこうしようという話だった。

コードの遅延ロード周りとかもいろいろあるっぽくて、ハイドレーションという初めて聞く手法もあるようで、この辺も相当奥が深そう。

なお登壇者によるハイドレーションのサンプルがここに。

https://github.com/jlkiri/partial-hydration-example

A-5 AWSを活用したフロントエンド開発

すぐ満席になっていたということもあり、早めの開始。それにしても終わるのが早くてちょっとびっくりだった。

スライド公開されてないのかな？　サーバサイドはAWSの各種サービスで置き換えられるから、フロントエンドだけでけっこうなところまで開発できちゃうよ、的な、サーバサイドの人間としては危機感感じるような話だった。

とはいえサーバサイドを自前で実装・運用しないで作るっての正直面白すぎるんで一回試してみたい。紹介されていたサービス周り確認したいのでスライド公開希望……。

2019-11-05 15時追記

スライド発見したのでリンクしておく。

https://speakerdeck.com/maeda/awswoyong-itahurontoendokai-fa

A-6 私たちはなぜ SPA で開発するのか

A-5がかなり早く終わったこともあり待ち時間が長く、登壇者の方がその間にOSS活動されてたのがとても印象的だった。

単純にSPAで開発する理由あまりわかってないので聞いてみたが、かなりしっかりした内容の話だった。あとこの方もまた話がうまかった。

A-7 フロントエンドエンジニアのためのセキュリティ対策

セキュリティ好きなので。最初は基本的な話になるのかな、と思いきや、最終的にはCSPの新しめの機能でDOM Based XSSがかなりのところまで回避できるようになるぞ、という、知らなかったエキサイティングな話になった。

CSPのTrusted Types, Perlでもtaintモードとかあったねー、みたいな感じのあれだと思うけど、これブラウザ側でサポートされれば、DOM Based XSSの回避もサーバサイドでのXSSの回避と同じくらい簡単になりそう。すごい。

つーかすでにPolyfillで動くという話なので、試さなくては。

LT-1 脊髄反射でプロダクト作ることの学びとススメ

https://www.notion.so/2019-7cbaa8438e6746029172267e50f9c5fa

小さなプロダクトをいろいろ作ってる方の話。小さなプロダクト、工数少ない割に学べること多いよー、みたいなこと言ってたのがとても興味深かった。

LT-2 Angularはいいぞ！フレームワークにAngularを採用した理由

https://slides.com/yayoimatsuoka/frontend-kansai-2019

Angularは作法が多いけど、そこがいいんだよー、という話。Vueは仕事で使って、ReactはチュートリアルくらいやったけどAngularはさっぱりなんで、ちょっと試したい。

A-2でもAngularのチュートリアル、内容がガチでいいよって話聞いたし。

LT-3 TypeScriptでHTTPリクエストを型安全にする方法

https://docs.google.com/presentation/d/1OoceK0kGSQ9N0l6q-d1UK3zo2gmImwDNKgSfBp8bkOg/edit#slide=id.g6f5b5c2297_0_147

このLTがまたすごかった。話がうまくて、内容もすごい。

せっかくTypeScript使っていても、axiosでHTTPリクエストすると戻ってくるデータが型なくてつらいので、型を簡単につけられるラッパ作りました、って話なんだけど、VS Codeでの補完のデモがほんといい感じで……。

そのライブラリは以下。TypeScript入門したら、試してみよう。

https://github.com/aspidajs/aspida

LT-4 コンポーネント管理の失敗と今後のやっていき

https://speakerdeck.com/yahooshiken/konponentoguan-li-falseshi-bai-tokorekarafalseyatuteiki

内容的にはちょうどC-3と同じ系統。ただしデザイン寄り、という感じ。

ボタンのデザインがぜんぜん共通化されていないという状況を、スクリーンショット撮ってまとめて問題意識を共有していく、というのはほんと理想的なやり方っぽい。見える化大事だよね……。

登壇者の方には懇親会でもためになる話を聞かせてもらいました。

LT-5 Automatic Test for Frontend Side

SeleniumやAppiumでのUIの自動テストの話。AIによる要素セレクタがあるっぽい？　スライドが軽くアニメーションしてかっこよかったのとそれくらいしか覚えてない……。

運営の混乱

セッション自体の進行には俺の見た限り問題なかったものの、細かいところでいろいろ気になった。

部屋番号がわかりづらかった。B05とB06をつなげてB5(ここで0落とすのも)として使っていたようだが、これがわかるまでちょっと困った。
セッションのABCDと部屋番号の対応もわかりづらかった。パンフレットは色でだけ対応が載っている。上の問題とあいまってか、Twitterでハッシュタグを間違えていた人もいた。
プレミアムチケットでの優先席の指定が、事前の連絡ではGoogleフォームでの登録となっていたがそちらがスタッフから確認できるようになっておらず、会場で再度選択しなければならなかった。ま
その他優先席周りは混乱が多かった。特に立ち見が出る中、優先席に空きがあるのはなんとも言えない気分。
FRONTEND CONFERENCEに限らず割とどこでもそうだけど、休憩が席確保のためにじっさいには取れない状態なのはなんとかして欲しい。この手のカンファレンスは、全席指定にした方がいいんじゃないかと思う。

個人的な反省

懇親会で仕事くれくれしてしまったのは最悪だった。次からはしません……。

総括

なんか段々テンション下がっていく感想になってしまったけど、基本的にはとても楽しめた。わからないことが多い分学べたことも多かったし。

次も関西でやってくれるならぜひ行きたい。

2019-10-28

［募集終了しました］2019年11月以降のフルリモートのPHPのお仕事を募集しています

仕事数ヶ月分埋まったので、募集終了です。ありがとうございました。

とりあえず自己紹介

私は神戸在住の個人事業主でやっているプログラマです。よろしくお願いします。
ここ5年ほどは仕事ではPHPを書いています。最近はLaravelをかなりやっていて、1人月未満～6人月程度の小さなものですが、5件ほどやりました。
Webアプリケーション開発のお仕事を請負でいただくことが多いです。基本的に一人ですべて、要件定義、設計、実装、テスト、サーバへの設置までやっています。ただしデザイン、HTML・CSSコーディングはやっていません。
一人で一通りやっていることもあり、JavaScriptやSQLも最低限できます。
特別すごいプログラマというわけではありませんが、普通のことを普通よりちょっとくらいはいい感じにできる自信があります。

どういう仕事を募集しているか

フルリモートのPHPのお仕事を募集しています。神戸近辺であれば面談、打ち合わせ行けます。
単価は50万/月程度いただきたいですが、その他の条件次第で応相談です。もちろん50万以上いただけるのなら大変嬉しいです。
PHPでLaravelのお仕事や、VueでSPAなお仕事が嬉しいですが、基本的になんでもやります。使う技術に強いこだわりはなく、やっていれば割となんでも楽しめる方です。
速度最優先ではなく自動テストを書く程度の余裕があるお仕事だと嬉しいです。テスト駆動で開発したいので。
GitHubでissue管理して、Pull Requestでマージしていくようなモダンなフローでの開発ができれば嬉しいですが、今後その辺を進めていきたい、あるいは導入していって欲しい、みたいな感じでも問題ありません。

ご興味のある方は、以下のメールアドレス、Twitterアカウントからご連絡ください

xxmagai@gmail.com

https://twitter.com/xxmagai

2019-10-20

SynologyのNASのファームウェアのマイナーバージョンの更新を手動でする場合の注意

その他

メジャーバージョンなら、あるいは多分自動更新とかでも問題ないと思うのだが、マイナーバージョンアップをインターネットにつないでいない場合に自分でダウンロードしてきて更新する場合にちょっと引っかかったのでメモ。

メジャーバージョンの.patファイルは、 https://www.synology.com/ja-jp/support/download から普通に探してダウンロードできるのだが、マイナーバージョンの場合は、「すべてのダウンロード」から criticalupdate/ に移動して、そこから探さないといけないようだ。

まあ、それだけの話なのだが。

ちなみに6.2.2-24922のようなバージョンがメジャーで、後ろにもう一つついている6.2.2-24922-3のようなバージョンがマイナー。

2019-10-15

Anker SoundCore Ace A1買ったので感想

買い物

前から寝室で使う用の小さくてバッテリー駆動のBluetoothスピーカー欲しかったのだが、安くてよさそうなのがセールやってて2000円切ってたので買った。

決め手の一つが防水ついてないこと。防水つけるとどう考えても音質・入出力・操作性に影響するので、防水いらないならない方が多分いいし。

具体的な用途としては、

寝室で枕元に置いて、
週3～4日、1日あたり1～2時間、
スマホからBluetoothで音楽をかける。

という感じで、感想としては、

音質なかなかいい。低音もサイズの割に出てる。
モノラルなのはいいが、ステレオ左右に振りまくる曲で聞こえ方が不自然なのは残念。仕方ない気もするが。
再生中にホワイトノイズあり。
Bluetooth接続が切れてからしばらく(10分くらい？)すると電源が自動で切れる。
起動・終了音大きめ。不快な音ではないが。まあ終了は、自動オフの場合は鳴らないのでまだマシ。
ボタンちょっと押しにくい。その上起動が電源ボタン長押しなのでちょっと面倒臭い。終了はやはり自動オフでいいので気にならないが。

という感じで、値段考えるとかなり満足。

なおだいぶ前に買ったこちらからの乗り換え。こっちも今は3000円くらいになってるけど、購入時は2000円くらいだったはず。

https://www.amazon.co.jp/gp/product/B005T1445M/

これにいくつか不満点があり、Ace A1では一通り解消された。

Bluetoothなくて有線でつなぐしかなかった。
横長が枕元のスペース的に邪魔だった。
充電が(多分)mini USB...

音質はどちらも違いはあれど大差なしな感じ。

2019-09-28

デブサミ2019関西に行ってきたのでだいぶ雑な感想を

その他日記

雑な上個人的な話ばかりでレポート的な感じではないので、そういうのを求めてる人には以下などのほかの人のレポートがおすすめ。

以下、見たセッションと雑な感想。

【B-1】心理的安全性の構造

かなり期待していたセッションだがちょっと雑な感じだった。期待しすぎていたかもしれない。スライド見る感じ、あきらかに「時間が余ったらする話」以下が本題なので、前半飛ばしてそっちやってくれていたら。

【B-2】新規事業を支える文化と加速させる技術～DevOps/GCP/DDD～

新規事業を文化と技術でうまくやっていくみたいな話だったかな。ちょっと焦点がぼやけてはいた。B-1やこれ見てると、チーム開発もしてみたくなった。

【C-3】生産性を上げる新しい役割「業務ハック」とは？

なんで選んだのか覚えてない程度の期待だったが、かなりよかった。業務ハックってコンピュータ使わない(とは限らないが使うことが必須ではない)プログラミングだと思う。

【C-4】非テック企業でも出来る！テクノロジーでHRを牽引する組織作りと案件事例～機械学習・ブロックチェーンetc～

昼食ちょい後のタイミングのせいかちょっと眠かった。すまん……。採用周りの話は非常に興味深かった。採用する側ではなく採用的なことをされる側として。

【C-5】エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ

とにかくスピーカーの話のうまさが際立っていた。エンジニア採用の難しさ的な話は興味深い。C-4同様この辺はされる側視点だけど。

【C-6】CI/CDを使い倒して数段上のソフトウェア開発をしよう！

CircleCIの人による話だけどCircleCIの話はほぼなかった。一般的なCI/CDの話だけど、詳しくない俺にはかなりまとまっていてよかった。

セッション選んだ時点ではCI未経験だったけど、選んでからデブサミまでの間にCircleCI既存のCIをちょっとどうこうしたのと、GitHub Actionsをちょっと試していた。で、GitHub Actionsいいじゃんとなってたけど、このセッションでちょっとCircleCIもちゃんと比較しなきゃなあとなった。

なおもらった資料にCircleCIとJenkinsの比較してるところがあって、これもけっこうわかりやすいのでよかった。今後GitHub Actionsとの比較も出してくれないかなあ。

【C-7】ぶっちゃけ儲かるの？アウトプットするエンジニア大集合LT！

これがほんと楽しかった。技術同人誌的なの書きたいなあという思いはあって、じっさいちょっと手を出してたりするのもあって銭けっとの人の話が特に気になってたけど、そういう期待とは別次元の話でこの人の話力と存在感がやばかった。

最初にこの人出して大丈夫かと思ったけど大丈夫だったので後続の方たちもすごかった。

やっぱアウトプット大事だよねー、と思いつつ、基本ブログで断片的な技術情報書くだけで、そこから仕事につながったことなんてないし、ただ出すだけでは駄目だよねとも。

今の案件かなり忙しくてなかなか時間取れない(割にあちこちでかけてはいるんだが)ので、終わってからになりそうだけど、またちょっとちゃんとしたもの書いていきたい。ブログはどうしても雑に断片だけ書いて、それで理解できる人だけ理解してくれとなるんだよね。

総括

心残りとして、Lifematicsの人が募集してたモブプログラミングの勉強会への参加を迷ってたらセッションぜんぶ終わってブースも閉じてて、というのがあって。ほかのブースも見れなくて、途中トイレも行けなくてだるかったので、次行くときは1セッション犠牲にしてブースやら見ようかなと。

あとは参加証印刷いるとか、筆記用具いるとか、資料入るサイズのバッグいるとか、その辺を次行くときは忘れないようにしたい。

そういえば前回も一応感想ブログ書いてた。具体例が欲しいって前回から言ってたのか。自分がなにか人に話すようなことがあれば、その辺しっかりやるようにしよう……。

デブサミ2018関西行ってきたのでセッションの感想など - 遠い叫び

2019-09-20

CentOS 7でCircleCI CLIでDockerがエラーを出す場合

こんなエラー。

% sudo circleci local execute --job build
Docker image digest: sha256:359227b82618c1ce0514da6b1ee0c05f60863601b8078b1907fe6917f3e5593a
====>> Spin up Environment
Build-agent version 1.0.15410-75b89bda (2019-09-13T15:43:07+0000)
Docker Engine Version: 1.13.1
Kernel Version: Linux 38934e5cbd31 3.10.0-957.27.2.el7.x86_64 #1 SMP Mon Jul 29 17:46:05 UTC 2019 x86_64 Linux
Error:
Unexpected environment preparation error: error connecting build-agent to ephemeral network: error connecting build-agent container to ephemeral network: Error response from daemon: No such container: docker-38934e5cbd3129668b05d985f6a45a08bb878e283a0acc11b5d125fdde800b43.scope

Step failed
Task failed
Error: Unhandled prepare executor error: error connecting build-agent to ephemeral network: error connecting build-agent container to ephemeral network: Error response from daemon: No such container: docker-38934e5cbd3129668b05d985f6a45a08bb878e283a0acc11b5d125fdde800b43.scope

Dockerのバージョンが古いだけかも。CentOS 7のBaseリポジトリに入ってるのは使ってはいけない。Docker公式にあるドキュメント見て入れよう。

Get Docker Engine - Community for CentOS | Docker Documentation

2019-08-14

Goでis-a関係を作る

Goには継承はなく、実装の再利用は構造体の埋め込みで行う。じっさいは委譲だが、見た目はオブジェクト指向言語で継承した場合のように使える。

package main

type Super struct {}
func (super Super) SuperMethod() {}

type Sub struct {Super}

func main() {
    sub := Sub{Super{}}
    sub.SuperMethod() // Subから直接Superのメソッドを実行できる
}

ただしこれだと当然is-a関係にはならないため、以下のようにSuperを要求する関数でSubは使えない。

package main

func RequiresSuper(super Super) Super {
    return super
}

type Super struct {}
func (super Super) SuperMethod() {}

type Sub struct {Super}

func main() {
    sub := Sub{Super{}}
    sub.SuperMethod()

    super := RequiresSuper(sub) // コンパイルエラーになる
    super.SuperMethod()
}

sub.Superを渡すことで済む場合もあろうが、当然それはSuper型の変数となってしまうので、今度はSubのメソッドを実行できない。

package main

func RequiresSuper(super Super) Super {
    return super
}

type Super struct {}
func (super Super) SuperMethod() {}

type Sub struct {Super}

func main() {
    sub := Sub{Super{}}
    sub.SuperMethod()

    super := RequiresSuper(sub.Super) // ここを変更
    super.SuperMethod()
    super.SubMethod() // コンパイルエラー
}

どうするか。インターフェイスを使う。SuperがSuperInterfaceを満たすようにし、Superを直接でなく、SuperInterfaceを要求するようにする。

package main

func RequiresSuper(super SuperInterface) SuperInterface {
    return super
}

type SuperInterface interface { SuperMethod() }

type Super struct {}
func (super Super) SuperMethod() {}

type Sub struct {Super}
func (sub Sub) SubMethod() {}

func main() {
    sub := Sub{Super{}}
    sub.SuperMethod()
    sub.SubMethod()

    super := RequiresSuper(sub)
    super.SuperMethod()
    super.(Sub).SubMethod() // とはいえ、SuperInterfaceはSubMethod()を当然持っていないので、ここではどうしても型表明が必要になる
}

ここまで辿り着くのにかなりかかった。