読者です 読者をやめる 読者になる 読者になる

natsumican's blog

Tech & Music

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ブースが設けられました。 ここから質問&回答が見れます。鮮度の高い情報を得られるのはとても有難かったです🙏

参加してみて

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

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

2016年を振り返る。

日常

エンジニアリング

昨年から引続きサーバーサイドをメインにやりつつ、後半はゴリゴリフロントエンドに挑戦しました。

好奇心旺盛で何でも興味が湧いてしまう性格なので、浅く広くなりがちな所がコンプレックスだったけれど、執筆した記事がブクマ数700users近くいったので、「それはそれでいいのかも?」と少しだけ自分のスタンスに自信が持てたりもしました。

2017年は基本的にフロントエンドを深く掘っていく予定ですが、ネットワーク周り等、引続きエンジニアとしての基礎固めもしっかりやっていきたいです。

個人的なこと

デザイン

旦那のサイトつくったり、趣味で開催したギャラリーのフライヤーつくったり、お絵描きしたり。

見た目やインタラクションをつくることはやっぱり楽しいです😊

音楽

ボカロ動画公開したり、友人とCDつくってM3初出店したりしました。

↑作詞作曲&歌&絵全部ひとりでやったりしました。 とはいっても昔の曲を引っ張りだしてきただけで新しい曲は3年位かいてないので、来年こそは…!><

麻雀

夏頃に始めて、狂ったようにハマる。コード書く以外で費やした時間は間違いなくNo1…

ハイライトはプロに誘われた事と、先週の麻雀納めでスッタンツモった事です…

時間というお金よりも貴重なリソースについて考えさせられつつ、もっと強くなりたい…!

勉学

ノリで某通信制KO大学に入学しました。

一応入学選考があるので、初めて論文の書き方を本を読んで勉強しました。 お陰で文章を書く能力がグンと上がった気がするし、文章への抵抗も減りました。

英語もちゃんと勉強する事は初めてでしたが、時間はかかるものの、ドキュメント読めるくらいには成長しました。

切っ掛けがないと勉強しないので、すごく為になったと思っています。一通り楽しんだのでたぶん辞める。

結婚

6月3日、24歳の誕生日に2年間のお付き合いを経て、20歳上の夫と入籍しました。

正直ノリで籍を入れてしまった感は否めないけれど、飲み会での鉄板ネタができたのでまぁいいや。

何だかんだコミュ強旦那にはいろいろ助けられています。今年もお世話になりました🙏

おわりに

安心できる環境で、好きなことを好きなだけ勉強出来て、いつも暖かく見守ってくれる人達がいる。

そんな日常がどれほど貴重で幸運なことか…皆様にはただただ感謝しかありません。

家庭の事情によりまぁ闇深い人生を送ってきたのですが、それももう、随分遠くまで来たような気がします。

「今年が人生で一番楽しかった」と思えることが何よりも幸せです。

2016年、大変お世話になりました! こんな私ですが、来年もどうぞ宜しくお願い致します🙏

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がその役割を担っていたように。

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

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

おしまい

フロントエンド初心者が各種ツールについて調べてみた。

プログラミング フロントエンド JavaScript

先日社内勉強会でこんなLTをしました。

 

実は、わたしがはじめてプログラミングに触れたのは小学生の頃。

HTML/CSSと、ちょっとしたJavaScript(こんにちは◯◯さん!をアラートで出力するだけ)を書いて遊んでいました。

当時あまりに熱中しすぎて親にPCの電源ケーブル隠されたことも今ではいい思い出です…( ˘ω˘ ) 

 

2年前にサーバーサイドエンジニアになってからは、ときどきjsやjQueryでDOM操作する程度でフロントは全くノータッチだったので、正直ES6で書かれたコードを読んで「お前…本当にJavaScriptなのか…?」と戸惑いを禁じ得ませんでした。

というか、

 ES + Babel + React.js + Redux.js +Webpack

と、最早知らない子と化していました。

てかいつのまにjQueryしんじゃったの…

 

↑についてキャッチアップしたときの方法についてはそのうち書こうと思います。

 

そんなわけで原点回帰とまでは行かないけれど、やっぱり画面構築するのは楽しいなー!とおもった1年でした。٩(๑❛ᴗ❛๑)۶