みかん箱

考えておきます。

age++

仕事では相変わらずFlashで書かれたアプリケーションをWebSockethlsへリプレースしたり、今年に入って人が増えたのでレガシーな開発環境を開発しやすい環境(モダンな環境)へ整備したりしている。

組織に属して開発をやる以上、チームとして(今の|将来の)仲間が不幸になる事態はなるべく避けたいので、「プロダクトに必要なものを必要なぶんだけ。もし不十分になったときは、その環境を捨てやすいようなアーキテクト」を心がけた。

エンジニアとして「新しい技術を試したい」「置いてけぼりにされたくない」という気持ちは理解できるが、周りの人が幸せだと思っていない環境で、自分自身も幸せになれるとは思わないので、チーム開発におけるオーバーエンジニアリングはあまり好きじゃない。

 

26歳、この先のライフプランや働き方について考える機会が圧倒的に増えた。

これまで恵まれているとはいい難い人生だったが、上京してからは人や機会に恵まれた。

人と関わる恐怖心を和らげてくれた配偶者、友人。プログラマーの道へ導いてくれた人々、未経験の自分を温かく迎え入れてくれた1社目の会社。悪い縁もあれば良い縁もあるもので、恩返ししていきたい。

 

自分は中高不登校で学位どころかまともに教育を受けたことがない。ただ学ぶことそのものは大好きだったので、プログラミングや英語をはじめ基本的に独学で学んできた。今も何とかそれで生きている。

一方で問題にぶち当たり解決しようとうんうん唸ってる間に、10代の間たっぷり学んだ彼らがその問題をいとも簡単に解決するので、やるせない気持ちになる事は多い。さらに年々最新の技術を学ぶことに時間を費やしてきた若者たちが入ってくる。

最近は学び続けながらも、基本的に「経験」を以て立ち回らなければならない気がしている。

 

個人プロダクトをガンガンやっていきたい。好きなことでないとなかなか熱量を維持することが難しいので、旅のしおりアプリや麻雀スコア記録アプリとか趣味に関連するものを考えている。

 

幸福には相対的なものと絶対的なものが存在すると思っている。

相対的な幸福はお金や地位など「他人と比較して自分はどうなのか?」が気になってしまう。一時的に満足したとしても、不安や不満がなくなることはないし外的要因も大きい。

絶対的な幸福は趣味や大切な人たちと過ごしているときなど他人と比較する必要がない。前者もある程度は大事だが、永続性のある絶対的な幸せを大事に生きていたい。

そのために今どうするべきか考えている。

 

 

2017年の振り返りと2018年にやること

あけましておめでとうございます。 ざっくり去年の振り返りと今年の目標です。

どんな2017年だったか

転職しました。

サーバーサイドエンジニアとして働いていた受託開発会社を辞め、4月から動画ストリーミングサービスの会社にフロントエンドエンジニアとしてジョインしました。

そして、そのどったんばったんで、仕事以外全く身動きの取れない一年でした… 何故そのような事になったのか、今一度自戒の念を込めて振り返りたいと思います。

仕事で何をしていたのか

主にJavaScriptでガリガリWebアプリ実装してました。

具体的には、Flashで提供されている機能をHTML5に書き換えたり、UI/UXデザイン込みで新機能実装やったり、パフォーマンスチューニングや使用パッケージの整理、ビルド時間短縮など地ならし的なこともやりました。

そもそも自分が入社する前の半年間はフロントエンドエンジニアが不在だったりと、お世辞にも開発的に良い環境とはいえない状態でした…が、1年かけて多少は改善されたと思います。というかそうであってくれ!!!!

ちなみに一番堪えたのは、既に辞めた方の出した、半年〜1年放置されたPRをリファクタリングしてQA対応、リリースまで漕ぎ着けるという作業 × 2セット フロントエンドエンジニアが自分一人しかいないため、常にQA対応しならがら他の機能開発を繰り返していました…

結果かなり疲弊してしまい、仕事以外の時間は家族と過ごしたり音楽を聴いたり、メンタルリセットに費やすことになりました…

良かった点

  • 技術駆動ではなくプロダクト駆動での転職だったため、自分がやりたいこととプロダクトのビジョンがマッチしていた
  • 「もっとサービスを育てたい!」「より良くしたい!」「たくさんの人に使ってもらいたい!」と心の底から思いながら開発できた
  • 支えてくれる家族や気の置けない友人の有り難さを身にしみて感じた

悪かった点

  • そんなこんなで仕事はとても楽しかったが、夢中になりすぎた…
  • その結果、勉強やアウトプットが疎かになった
  • 麻雀打てなかった

2018年やること

  • サービスや音楽・アートなど、ジャンル問わず個人プロダクトやる(できれば音楽に関するサービスつくりたい)
  • 登壇や執筆など積極的にアウトプットやる
  • 麻雀打つ

昨年は、あくまで自分にとってプログラミングはプロダクトに必要な機能を実装するための手段だなぁと改めて実感した年でした。 とはいえ、WebRTCやWebAssemblyなど、Webは自分にとって常にワクワクの対象であり、2018年はそんな「ワクワク」をもっともっと追い求める年にしたいと思います。

Inside Frontend # 1 に参加してきました。

先日行われたInside Frontend #1にブログ絶対書く人枠として参加してまいりました。 (年度末的なごにょごにょで遅くなってしまったことを心よりお詫び申し上げます…🙇)

このブログではいくつかのセッションについての内容や、個人的な感想について述べていきたいと思います。

会場の雰囲気等 、他のブログ書くマンさんの記事もとても参考になるので是非そちらの方も御覧ください…!

資料 & Blog等

また、セミナーA、Bのセッションに関しては下記にて視聴できる模様です。

Inside Frontend #1 Seminar A

Inside Frontend #1 Seminar B

多様化する利用環境とどう向き合うか

福本 翔さんによる利用環境の多様化についてのおはなし。

利用環境とは

利用者、利用機器、コンテキストの組み合わせ。それぞれ、障害者やお年寄り、デバイスやブラウザ、運転中や音の出せない状況などを指す。

マルチデバイス対応について

利用環境に応じて「使いやすい」プロダクトの状態は変わってくる。しかし多様な環境全てに対応するのは難しいので、全体最適化の後個別最適化を図る。

アクセシビリティオブジェクト

取得されたコンテンツはアクセシビリティオブジェクトへ変換され、アクセシビリティAPIを通じて支援技術(読み上げ機能等)に渡される。どのような情報を渡すのかというと、

  • DOMツリーとレンダーツリーの組み合わせ
  • 名前や役割や状態など(HTMLやWAI-ARIA)
  • 位置や大きさなど見た目の情報

因みにWAI-ARIAとは、role属性による役割付与や、aria-*による状態特性付与など、HTMLで不足している情報を補うことができる属性のこと。このような情報をもとにアクセシビリティオブジェクトは作られる。

まとめ

まずは全体最適化を優先し、後に個別に環境対応を行う。APIが適切な処理を行えるようにマシンリーダビリティを向上させよう。

所感

以前から気になっていたWebフロントにおけるアクセシビリティについて。

フロントエンドはユーザーと直接触れ合うインターフェイス部分であり、突然のデバイス普及による利用者・利用環境の多様化など、制御することのできないパラダイムシフトと常に向き合っていかなければならないと分野であると考えています。

そのなかで、実際にどのようにアクセシビリティオブジェクトがつくられ、支援技術に渡されているのか。その仕組について理解することにより、今後構造や属性の意味合いをより意識しながら開発したいきたいです。

直後に行われたAMAの内容も非常に興味深かったので、ぜひこちらの方も御覧ください。 AMA:C1 アクセシビリティ

Web フロントエンドにおけるコンポーネント化のアプローチ

@1000chさんによるWebフロントエンドにおけるコンポーネントのおはなし

コンポーネント化とは?

ソフトウェア的な再利用性・汎用性を持たせつつ、UIにおいても見た目や挙動等レイアウトに統一性を持たせること

例えばボタンで例えると、 文言の差し替えが容易に出来るようになっていたり(ソフトウェア的な再利用性・汎用性) hoverした時のインタラクションを統一する(UIの統一性) といった感じでしょうか。

コンポーネントの管理にいて

デザイナーとエンジニアどちらが管理するのか?という問題。どちらか一方が管理することが多い。しかしそれだと上手くまわらない。どちらも責任を持つ必要がある。

HTML + CSSによるコンポーネント

Cascading Style Sheetという名の通り全てがグローバル定義でありスコープの無いCSS。設計手法としては主に命名規則でなんとかするしかない。 しかし、そもそもCSS設計を工夫してもデザイン次第で破綻するので、エンジニアはデザインを、デザイナーは実装を理解する。

CSS ModulesとCSS in JS

とはいえやはりスコープは欲しい。JavaScriptのオブジェクトリテラル形式でCSSを記述したファイル(CSS in JS)をスタイルを適用したいコンポーネントにimportすることにより、コンポーネント毎に一意なハッシュが自動生成されクラス名に付与されるので、結果ローカルスコープを手に入れることができる。(CSS Modules)

まとめ

デザイナーとエンジニアどちらがやるのか?ではなく、職能同士が歩み寄ることが重要。説得する際は自分の都合だけでなくきちんと相手におけるメリットを提示すること。デザインシステム(Atomic Design等)の導入。

所感

昨今のWebフロントエンド開発において役割分担の曖昧さは悩みどころだったので、非常に勉強になりました。

また個人的には、スタイルはコンポーネントごとに閉じ込め、状態管理をFluxライブラリで奪い取る。そのようなキレイな世界で生きていきたいでスッ・・・😇

Refactoring CSS: 管理されたカオスへの道のり

@cssradarさんと@hilokiさんによるCSSリファクタリングのおはなし。

CSSにおけるリファクタリングとは

リファクタリングとは、ソフトウェアの外部的振る舞いを変えることなく、より保守性・拡張性の高いコードへ書き換える作業のこと。しかし、CSSだとなかなか実施しづらい。それには以下の問題があげられる

  • UIの変遷が速い
  • 影響範囲が広い
  • テストを書くことが難しい

リファクタリング手法

プログラミングにおけるリファクタリングと、表現言語であるCSSでは異なる部分もでてくる。が、基本的に手法は同じ。

タイミングとしては機能実装前・バグ修正時等。もしくは常にやるくらいの気持ち。 CSSにおける、マジックナンバー(謎の27pxとか)や!importantなどはやはり良くない。 命名規則の導入は新しくデザインが刷新されるタイミングで。スタイルガイドはあくまで見た目の振る舞いを確認するもので、コードについては触れられていない。そこについてはドキュメントを残そう。

また、元のコードは消さず、セレクタに対してRF_*でリファクタリングは残しておく。具体的には

リファクタリングをしている時は消さない、リファクタリングが終わったら消す。rf_ のネーミングごと消す。

2つの帽子をかぶり分ける、開発とリファクタのモードを変えていかないといけない。機能追加とリファクタを同時にすると事故る。

リファクタリングで「コードを消さない」と負債にならないか? / CSS Evolution #56より

まとめ

表現言語であるCSSにおけるリファクタリングは可能だがなかなか大変。 リファクタリングのしやすい環境・習慣をつくろう。

所感

リファクタリングを試みるも、あまりの影響範囲の予測しづらさに悪戦苦闘することが多いCSS…今回のセッションを拝聴して、是非取り入れてみようと思いました!また、AMAの以下の質問について、

CSS Modulesについてどう思ってますか? / CSS Evolution #56

SPAプロダクトではにおいては是非使いたい…スコープ欲しい…と思ったりもするのですが、そもそもきちんと設計できていれば必要のないモノというのは、確かにそうだよなぁ…と思います。

個人的には、スコープある方がより直観的に書けて良い気がしなくもないのですが、しかしそれはもう本質的にCSSのような何かであってCSSではないと思うので、このあたりでstyle sheet言語として乖離が始まる気もします…CSSの今後が気になるところです。

AMAブースについて

今回のイベントでは、セッションの合間に登壇者の方が事前にGithubue上で募集した質問や、その場で出た質問に答えていくAMAブースが設けられました。 ここから質問&回答が見れます。鮮度の高い情報を得られるのはとても有難かったです🙏

参加してみて

あまりの楽しさに適宜休憩をアナウンスされているにも関わらず、どのセッションも聞き漏らすまいと必死になった結果、無事死亡しました…次回は頑張って任意休憩します…😇

運営スタッフ様、登壇者様、お疲れ様でした…! 次回も楽しみにしております!

React Advent Calendar 2016に投稿したら予想以上に伸びたので、理由を考察してみる。

昨日、React Advent Calendar 2016に参加するべく、社内ブログにて記事を投稿したところ、人生初ホットエントリー入り致しました♪٩(๑❛ᴗ❛๑)۶

www.s-arcana.co.jp

まさかの650userオーバー…だと…

正直嬉しい気持ち半分「何故伸びたのか…?」という疑問がひたすら湧いたので、考察してみようと思います。

専門的ではない、体系的な話だったから

敷居が低く、多数にリーチしやすい内容となっていたのはもちろんのこと、最新のフロントエンド事情に関して体系的に述べている記事は意外と少なかった。 (自分がそうであったように)「何から学べば良いのかわからない」という人は多いのかもしれないと思いました。

また、フロントエンド周りの技術を学ぶにあたり、「それぞれのツールの役割」を知ることは特に重要だと感じています。

一通りのツールの役割を知ることにより、たとえ目新しく見えるツールが現れても「これは◯◯の代替品」(しかも大抵は便利になっている)という判別ができるようになるので、毎回そんなに大きなパラダイムシフトが置きているわけではないのだということが解ってきます。

個人的には、外側から眺めているときの印象よりも、だいぶ緩やかなイメージになりました。

学習順序に関しては、「わからん!」→「やっぱりこっちから学ぼう!」と自分で何度もツールを行き来して導き出した結果なので、それなりに合理的である…と思いたい…

フロントに興味のあるサーバーサイドエンジニアが増えてきたから

先日お邪魔したPHPカンファレンス2016では、満員で入場できない程フロントエンド系のセッションが盛り上がっていました。

とくにPHPは比較的Viewが身近な存在だと思うので、もしかしたら興味のある方も多いのかもしれません

また、これまでの「ちょっとしたDOM操作やってよ~~」的なノリでフロントを強いられているサーバーサイドエンジニアの方がいたりもするのかな…と思いました。

React/Redux流行ってるから

そのまま

そうは言っても、どうせ頑張って学んだところで枯れるんでしょ?という声について

フロントエンドはその名の通り、ユーザーが直接操作し、触れ合う箇所です。即ち、ユーザーの求める「体験」と密接に関係します。

時代によってユーザーの求める「体験」は変わっていきます。

映画も音楽もアニメもドラマも、そしてインターネットも。

時代の変遷、あるいはスマートフォン等のデバイスの台頭等、様々な要因によりユーザーの求める「体験」は少しずつ変化していきます。

それらと共に、フロントエンドの技術も変遷していくのではないかと考えます。

所感

今回React/Reduxについての記事を書かせて頂きましたが、これらは、あくまでUI/UXを向上させるためのツールに過ぎないと私は考えています。 かつてjQueryFlashがその役割を担っていたように。

そのプロダクトのためには何が必要なのか?

フロントエンドにせよサーバーサイドにせよ、手段と目的を履き違えず、たのしくモノづくりしたいな!とおもいます♪٩(๑❛ᴗ❛๑)۶

おしまい