マークアップエンジニアとしてウェブ制作会社に入社してから10年になりました。若いね~と言われなくなってからも随分たちました。いろんな意味でひとつの節目に来たのかなと感じます。そこで、わたしがごく個人的に大事にしている、仕事とエンジニアリングについての価値観をまとめました。
意味もなく、これからの若手エンジニアに語りかけるようなまとめ方をしています。
Webフロントエンドにまつわるいろいろな話
マークアップエンジニアとしてウェブ制作会社に入社してから10年になりました。若いね~と言われなくなってからも随分たちました。いろんな意味でひとつの節目に来たのかなと感じます。そこで、わたしがごく個人的に大事にしている、仕事とエンジニアリングについての価値観をまとめました。
意味もなく、これからの若手エンジニアに語りかけるようなまとめ方をしています。
※身内がつどうプライベートチャンネルで嶌田なりの意見を書いたところ、記事にしてくれという声がありました。論点が錯綜するこの手の議論をまとめるのは得意ではないので、通勤電車の中で書ける範囲で、わたしが感じていることを箇条書きでかきくだしました。
ネコメシでは週に1回、持ち回り制で勉強会を開催しています。各々が気になっているトピックについてスライドを作って、30分~1時間くらいの発表を行います。
先日の勉強会にて、コーディング作業高速化について発表したので、その内容を公開します。拙速が大事ということで、スライド貼っ付けただけで、説明もなにもなしですが…。
スライドに説明文を追記しました (2019-07-18 22:04)
https://speakerdeck.com/tsmd/devtools-plus-perfectpixeldebao-su-kodeingu
2019年5月16日に神戸で開催された「アクセシビリティの祭典 2019」というセミナーに参加しました。セミナー費用、交通費、懇親会費用、ホテル代はもちろん会社負担です。なんてすばらしい会社制度!
昨年は弊社CEOの森田が参加して、同様にレポート記事を投稿しています。併せてお読みください。
わたしは網羅的なレポートは得意ではありません。技術者目線で、うんうんと頷いたり、へーっと参考になった点を中心に書いていきます。
ネコメシでは週に1回、持ち回り制で勉強会を開催しています。各々が気になっているトピックについてスライドを作って、30分~1時間くらいの発表を行います。
先日の勉強会にて、JavaScriptフレームワークのStimulusについて発表したので、その内容を公開します。
Stimulusは控えめなフレームワークで、非SPAのウェブサイト制作(コーポレートサイト、キャンペーンサイト等)において非常に強力なツールだと思います。jQueryをメインに使っている制作者や、オブジェクト指向的にコードを書こうとしているけどいまいちコレといった腹落ちができていない人には、特におすすめできるものです。
先日、27日に納会と称した昼から飲む会をして、2018年を仕事納めしました。トゥーアールさんが会社の振り返り記事を掲載していたので、じゃあウチも…ということで。
年末ぎりぎり滑り込みって感じですが簡単にまとめてみました。なお本記事は「エンジニア編」の色が強いです。「サービス開発編」は、副社長の石村が別途まとめてくれるかもしれません。
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。
しかし実際は、悪い意味で期待を裏切られることになりました。
Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。
全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。
※この記事の内容は、まだブラウザに実装されていない内容を含みます。また、勧告前の仕様について言及しているため、最新の仕様では変更になっている場合があります。
overscroll-behavior
プロパティを使うと、スクロール境界(端っこ)におけるブラウザデフォルトの挙動を上書きすることができます。例えば、ブラウザが持っている「下方向に引っ張ってリロード」する機能や、スクロールが親要素に伝わる「スクロールチェーン」の挙動を無効化することができます。
主にタッチデバイスにおいて、無効化したいのにできない、スワイプ操作やスクロールにまつわる困った挙動が3種類ありました。
BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。
レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。
BEMを使いはじめてかれこれ3,4年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。
ただし、それはBEM的にはオッケーなのである。もともと「正しいBEMの書き方」というものはなく、みんなの中にそれぞれのBEMがある、という捉え方でオッケーなのだということだ(みたいなことが実は公式にも書いてある)。
少し長くなるけれど、私がいつも使っているプラクティスを紹介する。