nayucolony

勉強したこととか

builderscon tokyo 2017にスタッフとして参加しました

昔の人は言いました。 鉄は熱いうちに打て。ブログはエモいうちにしたためよ。 ブログを書くまでがカンファレンス。

buildersconを知ったきっかけ

興味を持ったきっかけは、@GeckoTangさんや@Takazudoさんのような、CSSに明るいエンジニアがCfPを出していることでした。Twitterで見かけてbuildersconを意識しはじめました。

ちなみに、2016年にも@kubosho_さんのCSSを破綻させないというCSSのセッションがあり、それは動画で見ました。

当時「テックカンファレンス」に抱いていた先入観

日本のテックカンファレンスは、サーバーサイドやアプリエンジニアが盛んにやっているイメージを持っていました。フロントエンド系のカンファレンスももちろん盛り上がっていますが、AngularやVueなどプロジェクトベースの開催が多いように思います。

ちなみに、私が普段描いているHTMLやCSSのような、プログラミング言語ではない言語をとりあげると、業務ベースで「設計」「効率化」という話が多いというのが現状かなと感じています。そのため、カンファレンスというよりは、セミナーという形が多いですね。

Rubykaigi, PHPカンファレンス, YAPC, iOSDCなどでTLが盛り上がっていると、楽しそうだなーとよく思います。

buildersconへの参加

最初は「CfP出そうかな」「せめてLTくらいなら」と思っていました。しかし、日程確保ができなかったというのと「そもそも、空気感がわからない」というのもあり、その足は踏み出せませんでした。

ですが、あの場に立てることが名誉なことくらいはわかっていました。なので、「参加のきっかけが欲しい」などと思っていたところ、「ボランティアスタッフを募集している」というツイートが目にとまりました。

意識していたから目についたのか、たまたまなのかはわかりませんが、我ながら「〜〜したいな」と思ったらチャンスがくるラッキーさには定評があるなと感じます。

当日

3daysの開催でしたが、仕事(副業のほう)の都合で日程が確保できず、最終日のみの参加でした。「あーいきたかったな」と思ってしまうので、ハッシュタグ見るのがつらかったです。

当日は、メイントラックのスタッフとして常駐していたため

のセッションを聞くことができました。

また、一部トラックを移動して

を聴きに行きました。

今日から使えるCSS Grid

Gridが使えることは、先日の一斉実装の件もあり知っていました。 ですが、やはりその方面に明るい方から聞くのは得るものが多いだろうというのと、「buildersconでCSSの話ってどんな感じなんだろう?」というのが気になって参加しました。

Twitterやトラックの様子を見ていると、専業のフロントエンド(マークアップ)エンジニアはそんなにいないという印象でした。別畑からキャッチアップしにきているのかな?という感じもありました。

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りですというキャッチコピーの通りだと思いました。

専門外の分野の話を聞いて見るのは面白い

ここまで出来るmrubyThe Evolution of PHP at Slack HQは、PHPRubyも書かない私が聞いても発見がありました(追いつけない部分もありましたが)

一番の発見は「〜って、〜なんですよ」という発言に、わたしは「へぇ〜」と思うのに対し、おそらく普段からPHPRubyを描いてる人は「wwwww」のような「あるあるw」的な反応をしていたことでした。

専門でやってる人から見たら当たり前な話でも、専門外の人にとっては「知らなかった」「今学んだ」なんだなぁと思いました。 もっというならば、僕がここでUIデザインの話をしたとして、もしかしたら誰かの新たな発見に繋がるかもしれないということです。別分野の人に向けてトークすることを「アウェイ」ではないと思い始めました。

クロージングトークのエモ

refs. Closing

後からスライドや動画は公開されると思うので完結に。 (自分の解釈が多分に含まれます)

  • エンジニア35歳定年説みたいな話は、誰かが勝手に決めた限界値
  • でも、時間が有限であるというのは事実
  • じゃあ、今すぐアクションしたほうがいい
  • 今この話を聞いてる人が、今この瞬間にアクションにうつせることは「スピーカーと話す」「参加者と繋がる」
  • この先アクションできることは「登壇する側になる」「カンファレンスを作る側になる」
  • 技術者はスキルだけあればいいってもんじゃない
  • 自分の分野の外側と繋がるともっといいもの作れる
  • buildersconはそういうカンファレンスだ

ぶっちゃけ感動しました。エモです。

当初は、よくわからないからちょっと覗いてみようと思っていたレベルだったのが、積極的に技術トークをしていきたいという気持ちになっていました。

最後に

とにかく、刺激になるカンファレンスでした。深夜のエモがとまりません。

もっとやばいのは、今回は最終日にスタッフ参加だけという、ほんのひとつまみしか参加できていないというのに最高みを感じているところです。

次回は全日程参加する、CfPだす、もっといろんな人と喋る、自分の専門外のトークも耳を傾ける、スタッフとしてももっといいものを作る・・・いろんな思いがあります。もっと楽しめそうです。

このエントリは、buildersconを終えた夜に「エモ」駆動でbuildされたものです。 これが、今私にできるアクションでした。

皆さん、次回は一緒にbuilderscon行きましょう!

f:id:nayucolony:20170806045251j:plain

WP REST APIで投稿データから著者名をひっぱってくる

普通にやっても取ってこれるオブジェクトのなかにはいってない。雑にメモ。

やりかた

wp-json/wp/v2/posts

ではなく、次のURLにGETをなげる

wp-json/wp/v2/posts?_embed

すると、帰って来るオブジェクトに_embeddedプロパティが追加される。 _embedded.author[0].nameに、著者名が格納されている。

これがないと、author idからエンドポイントを生成して叩いてオブジェクト取得して、、、ってしないといけない(?)ので見つけられてよかった。

【process.env】node.jsでプロジェクトごとに環境変数を設定する

circleCIに環境変数を仕込んだものの、ローカルで動かせないじゃんってなった。 どうにかしてプロジェクトごとに環境変数を追加できないかなと思って調べているとdotenvというnodeモジュールに出会ったのでメモ

どうするの

プロジェクトルートに.envファイルをつくる

USER = nauycolony
PASSWORD = password

node.jsで使えるようにする

dotenvというnode_moduleをつかうのでインストールする。 yarnでも、npmでも、使ってる方でどうぞ。

yarn add dotenv
npm i dotenv

動かすスクリプトファイルで次のように記述。

require('dotend').config();

こうすることで、process.envというオブジェクトに.envの内容をぶちこんでくれる プロジェクト固有の変数を作れる。

使ってみる

普通にオブジェクトとして使えるので、ブラケット記法なりなんなりで参照する。

console.log(process.env.USER) // nayucolony
console.log(process.env.PASSWORD) // password

あとは、.envファイルをgitに含めずにアップすれば、認証につかうユーザー名とかパスワードなんかをリポジトリにあげずに認証を通したりできるということだ。 絶対に.envファイルをリポジトリにあげないように。

process.envってなに

環境変数をまとめて管理するオブジェクト。

中身を見たければ次のようにする。

console.log(process.env)

一例としては以下のようなオブジェクトがでてくる。

{
  SHELL: 'usr/local/bin/zdh',
  VISUAL: 'vim'
  .
  .
  .
}

通したPATHとか、色々とここに全部集約されている。 通常、マシン全体で使うものだが、dotenvをつかうとプロジェクト固有の数値も持たせることができる。

Parallelsで立ち上げたIEからrailsにアクセスする

こうするだけ

たちあげるときに次のようにする。

rails s -b 0.0.0.0

what

通常、Macでnode.jsなんかをつかってローカルサーバーを立ち上げてそこにアクセスする場合、http://localhost:8000のようにURLをうつ。

しかし、同じマシン内でParallelsを起動し、その中でIEを起動して動作チェックをする場合などは http://192.168.11.2:8000のように、ローカルIPアドレスを指定する必要がある。

この192.168.11.2の部分は各自ネットワーク環境によってことなる。 ifconfigで確認できる人はそうすればいいし、わかんなければシステム環境設定>ネットワークを確認すれば Wi-FiはXXXXXXXに接続していて、IPアドレス 192.168.11.2が設定されています。みたいにかいているはず。

しかし、Railsでサーバを立ち上げる場合、ローカルIPアドレスを指定してもアクセスできない。 Railslocalhostでしかアクセスできないのだが、ParallelsからはlocalhostMacにアクセスできない(windows自身を参照してしまう) (そもそもlocalhostの正体は127.0.0.1という「ループバックアドレス」であり、自分のマシン自身だ。自分のPCをサーバーとして動かしているところに、自分のPCからアクセスするという自作自演をしている。)

よって、localhostではない、別のIPアドレスでアクセスできるようにしてやる必要がある。 そこで-bオプションを使う。 bindすなわち束縛の意味で、引数として渡したIPアドレスに結びつけてアクセスできるようにできる。

そこで、0.0.0.0というアドレスを使う。 0.0.0.0localhostのように自分自身を表すが、ループバックではなく、外部からもアクセスできる自分自身である。

mac0.0.0.0Railsアプリを公開している状態になるので、そのネットワークに繋いでいる人は0.0.0.0でアクセスできる。 これは、Parallelsも例外ではない。

よって、

rails s -b 0.0.0.0

としてサーバを起動し

http://0.0.0.0:8000/

のように任意のポート番号を指定することで、アクセスが可能になる。

レスポンシブのサイト制作で、必要なカンプは?

結論はないですが最後にいちコーダーとしての個人的なわがままがあります。

事の発端

この発言。TLで「モバイルファーストでCSS書く」みたいな話を見かけて、そういえばないなあっていう思いから漏れ出たツイーツでした。

注意事項

まず、ツイッターで意見を募る系の世論調査、業界全体でみると「意識高い人(NOTただ意識高い系の人)」が意見をくださる場合が多いです。 なので、わりと「アンテナはってる」層の意見が多いパターンが多く、一般世論とは乖離している可能性が高いことをご留意ください。

また、「モバイル/SP」のような表現をしますが「小さい画面」という意味で言っており、特定のデバイスをさしているわけではないのでご了承ください。

あと、私は元デザイナーでありコーダーですが、互いの職域に対する文句やdisではありません。 いただいた意見を元にした現状の解釈と、個人的な意見です。

ツイートに対する反応

この辺は、僕のツイートが「つらみのぼやき」に見えてしまったのか、デザイナーの「そんなことないよ」という反応とコーダーの「だよなー」という反応が多くを占めました。

デザイナーの反応

  • まじで?そんなパターンあるの?
  • PCとSPを想定してつくる
  • 大中小の画面パターン用意する
  • 実装者が社内のウェブデザイナーとかならコミュニケーションで回す

etc.

コーダーの反応

  • あるある
  • やっぱどこもそんな感じなんだな
  • 「よしなに」の指示が来ることが多い。工数増えるっていう話をすると辞退される
  • 完全なカンプは予算によっては存在するが、ディレクターが手書きワイヤーフレームで指示くれてコーダーが実装する
  • 元デザイナーなのである程度汲み取る
  • SPはトップだけくる

etc.

デザインカンプの持つ側面

たくさんの意見をいただいて、次のような側面が存在することに気づきました。

  • デザインカンプは、次工程への指示書である
  • デザインカンプは、前工程への報告書である

前者はコーダーに渡すカンプとして、後者はクライアントに見せるカンプとしてという意味合いです。

コーダーは「別バージョンのカンプ」が欲しいのか

そもそも、欲しいのか、欲しくないのか、ということから考えました。 結論からいうと、場合によるよね、とはなるのですが(笑)

前職では、クライアントの性質上「PCからの流入が圧倒的」であり、「小さい画面」については存在さえしていればいい、本当によしなにやってくれればいい、という感じでした。 しかし、「じゃあ適当にやっときますわ」というわけにもいかないのが現実でした。

なぜなら、「PC向けのデザインが本当にPCの画面いっぱいを使って表現するようなデザイン」であり、段組を変えてレイアウトを変更すればいいという話ではすまなかったからでした。

webコミックの話

具体的なサイト名を出せないので、下手くそなたとえ話をします。

例えば、スマートフォンでマンガを読む場合は、見開きではなく1ぺージずつスワイプを行なって読むことが多いですよね。もしくは、縦スクロール。 その際「見開きをぶち抜いて表現しているページ」が本来作者の意図した見せ方ができなくなりますよね。

もう、web連載なんかでは縦スクロールを前提としたコマ割りを行われているケースが多いですが、もし紙の本にむけて書いたものをその形式で出してしまうとほんとうに悲惨なことになります。 (その場合、そのコマにさしかかたときだけ横にスクロールするマンガもありますが)

・・・とまあ、話がそれましたが、その辺に近いものがありました。

そのため、「まあよしなにやってくれや」というオーダーがきた場合、かなり無理があるので、狭い画面向けのデザインの再構築をお願いしたいという気持ちがあるというのが当時の状況でした。

デザイナーは「別バージョンのカンプ」を作りたいのか

まず、多かった意見が「クライアントのビジュアルチェックがあるので絶対に必要になる」というパターンでした。これは私もやっていました。

特にコンペとかだと、おそらく100%のデザインを出すんでしょうし、それがそのままコーダーに渡って来る可能性が高いです。 レギュレーションとかもありますし、前職ではプレスチェックのために完璧なデザインを提出していました。

そのフェーズで「クライアントのビジュアル的要求」と「文書構造の一貫性」を両立することが困難になるケースも多くて、カンプのデザイン以外は「誰も知らない中間の姿」となってしまうこともありました。 当時はとにかくデザインのOKをもらうことを優先していたため、いつも、そこの調整を闇雲に行っては消耗していました。

その辺を確実に実装させるための戦略として、別バージョンのカンプを用意すると言う意見もありました。 それだけの予算をとる説得ができるかどうかは、もう一つ上の工程に掛かっているのかとはおもいますが、納期と予算の都合で難しいケースもあるとのことです。

コーポレートデザイン的な部分も含めてサイトを作ることのウェイトが高い場合は、そういう予算も惜しまずだしてもらえるのでしょうか。

ワイヤーフレームをしっかり決めることが大切

たじまさん(@DesignHumore) という、ブランディング戦略から現場のデザイナーまでを担当されている方がいて、その方の意見がすごく参考になりました。

複数ツイートに渡っての会話だったので、要約すると以下のような形になります。

  • ワイヤーの時点で仕様を徹底的に詰める。必要な要素に抜け漏れがないかの確認が目的。
  • デザイン(ビジュアル的な話)はイメージボードを使って方向性を決める
  • 「とはいえ実物見ないとわからない」場合も当然あるが、その場合は30%くらいの力でデザインしてイメージを見せる。
    • コーダーへの指示書ではなく、お客さんへのイメージ共有なので、最適レベルで見せるという意味だと思う。
  • デザイナーとしては、装飾の変更は言うほどつらくない。情報構造の変化は、大変。

デザイナーはデザインツール上で完結することはテクニックで完了させられますが、インフォメーションアーキテクト的な話は、そこだけでは完結させられないのでクライアントを巻き込んだ手戻りが発生しがちです。

実装でもそうで、CSSの書き換えはSassなんかを駆使すればけっこう簡単に終わらせられます。 しかし、情報構造が変わると、HTMLも含め考慮することが増えがちです。サーバサイドと連携している場合はなおのことです。

たじまさんは「その手戻り・修正にかかる費用と時間はお客さんのものだから勝手に資源にしてはならない」とも仰っていました。

作業の大変さとかしか考えてなかったので感心しました。

文書構造の変更は大変だが、あしらいの調整はそうでもない

たじまさんの話をうけて、下手くそなたとえ話をします。

家を建てる過程で、もう色々な作業が動いているときに「すみません!忘れてたんですけど、2Fにもトイレが必要なんでした!このスペースに置いてくれればいいんで!」みたいな話をされた時の話です(なんだそれ)。

  • 「いやいや、スペースはあるけど、このスペースは居住者の使いやすさをいろんな面から考慮してデザインしてまして・・・」
  • 「水道管の整備、電源の確保、換気ダクトの設置、収納、あらゆる要素を改めて考慮するので、一旦全作業をストップしてもらって、もう一度打ち合わせが必要です」
  • 「モノがありません、完了予定日は決まっています、無理です」

みたいな問題が生まれると思うのですが、コーディングもなんか、似たようなことが起こります。 なるべく文書構造のぶっこわしは発生してほしくないと思っています。

しかし、「すみません、外装なんですが、やっぱりクライアントのイメージと少し違っていて、もう少し濃い茶色のモノに変更してください!」という場合。

  • 「塗装業者をもう一回呼びましょう。最悪、材変えましょう。お金はかかりますが、いけますよ」
  • 「壁紙剥がして張り替えですかねー、内装業者のスケジュールにもよりますが、無理はないですよ、そのぶんお金はかかりますけど」
  • 「この色は、全体の調和を考えてデザインしていて、他の部分もトーンを変えないと変な感じになっちゃいそうですが、本当に必要ですか?」

みたいな、割とお金で解決できるフェーズじゃないかとおもいます。 この辺は、CSSを書くときにだいたい想定しているので、割と変更は楽です。

web制作の現場、家とかに例えると「なんだそれ」ってなりますが、結構頻繁にこういう事が起こっているのを考えるとおかしな部分がありますね。 リアルの物体じゃないという性質上、修正が簡単なのは、わからなくもないんですが。

私なりのわがまま

最後に、個人的な意見です。

大きな画面でないと表現できないようなデザインならば、画面が小さくなった時のデザインも欲しい

例えば、横長のヒーローイメージをドカンと置いているような場合、「よしなに」と指示をすると「画面幅に合わせて縦横比を合わせて縮小」されて、すごくダイナミックな表現だったはずのものがすごくみすぼらしくなったりします。 デザイナーとしては「私はこんなの認めないぞ!これはこれに向けたデザインをしなおす!」という気持ちになるのではないでしょうか? その辺りを放棄されると実装側は萎えるということもあり、お互いいい仕事をするためにも、ビジュアルの共有をしてほしいです。

レイアウトの変更だけでいけるようなサイトならば、ワイヤーレベルの指示書が欲しい

複数のカラムで構成されていて、1カラムに並べ替えるとか、1カラムを表示させないとか、そういう操作だけで行けるような場合はカンプはそこまで重要ではないかなとおもいます。 逆に、ケツの姿が決まってしまっていて、クライアントにも「これでいきます!」と固めてしまうと、中間の処理なども含めて無理が発生することが多いです。

・・・まあ、クライアントのチェックが入る以上、必要なものは必要なので、仕方ないのですが。

ただ、要素の増減が発生する場合、何を削ったらいいのかとかは実装者の独断では決められないので、指示書レベルで欲しいという気持ちがあります。 手書きワイヤーでもいいです。デザインも、デザインをかじったレベルでいいのならばまかせてくれという感じです。

結局、コミュニケーション

中間成果物がなくても、コミュニケーションで巻き取れる部分はかなりあると思っています。

  • 「ふってきたデザインがこれで」
  • 「ふってきたオーダーがこれで」

という風に何か超常現象のように捉えてしまいがちですが(いや、あいつぶっ殺すという人もいるとは思いますよ)、やはり決めてるのは人なのでコミュニケーションを大事にしたいですね。

そのコミュニケーションのためのベースとして、実装者はデザインに対する理解を深めておきたいし、デザイナーは実装に対する理解を深めていけるといいなと思っています。

最後に

元も子もないような感じではありますが・・・

「手戻りが発生することも含めて、お金で解決するのがプロフェッショナル」

ということもあるということを忘れてはならないと思います。

とはいえ、湯水のようにお金を使う事がプロフェッショナルかというと、そうではないということも合わせて肝に命じておきたいですね。

最後まで読んでいただきありがとうございました。

touchstartをイベントハンドラとした時のpageX,pageYプロパティへのアクセス方法

イベントハンドラmousedownのときとtouchstartの時で引数に渡されるオブジェクトが異なるというメモ。

mousedownのときに渡されるオブジェクト

MouseEventオブジェクトが渡される。

目的のpageXpageYプロパティは直下にあるので

e.pageX
e.pageY

でアクセスできる。

MouseEvent - Web API インターフェイス | MDN

touchstartのときに渡されるオブジェクト

TouchEventオブジェクトが渡される。

TouchEvent - Web API インターフェイス | MDN

場合によってはMouseEventも渡されるっぽいが、あらゆる場合で渡されるのかは未調査。

MouseEventオブジェクトとは違い、pageXpageYプロパティは直下には存在しない。 ではどこにあるのかというと、TouchEventオブジェクトのchangedTouchesプロパティの中だ。

TouchEvent.changedTouches - Web API インターフェイス | MDN

ここにtouchListというオブジェクトが格納されている。

TouchList - Web API インターフェイス | MDN

touchListオブジェクトの中には0というプロパティ名でTouchオブジェクトが格納されている。 この中にpageXpageYが入っている。

Touch - Web API インターフェイス | MDN

そのため、アクセスするには以下のように記述すればOK。

e.changedTouches[0].pageX
e.changedTouches[0].pageY

オブジェクトのプロパティへアクセスする際の注意事項

JavaSctiptでは、ブラケット表記法でオブジェクトのプロパティにアクセスする際に数値をいれても文字列として扱われる。 ブラケット表記法には式の評価を行うプロセスがあり、その際にtoStringメソッドを経由するので、強制的に文字列型への変換がかかるためである。

メンバー演算子 - JavaScript | MDN

一方、ドット表記法はそのプロセスは存在しない。 したがってe.changedTouches.0のような表記は使えないので注意。

これらについては別記事でまとめてあるのできになる場合はそちらで確認してほしい。

変数をキーとしてオブジェクトのプロパティを参照する際はブラケット表記法を使う。 - nayucolony

関連

今回のエントリの内容は以下のサンプルコードに登場します。

弾力のあるヘッダ - Vue.js JSFiddle

SVGを触ってみる【path要素/d属性/直線/ベジェ曲線】

SVGのことを実は全く知らないので少し調べてみた。

とりあえず、簡単なパスを引いて図形をつくる。

まず、基本事項としてsvg要素が存在し、子要素としてpath要素を作る。 そしてpath要素にd属性を指定することでパスを引いていく。ddraw = 線を引くという意味。

パスの内側を塗りつぶす時はfill属性を使用する。

直線を引く場合

始点を決めたら、あとは座標をどかどかうっていくと直線をどんどん引いていける。

Mで始点の座標を決定し、L以降に指定した座標に直線を引いていく。LはLineto〜に直線を引く 以下の例では、0,0を支店に、順番に320,0=>320,160=>0,160と線を引いた場合。

0,160 => 0,0のように始点までの直線を指定しなくても、最後の座標から自動的に始点にまでのパスを引いてクローズドパスになる。

<svg width="1000" height="1000">
  <path d="M0,0 L320,0 320,160 0,160" fill="#3F51B5"></path>
</svg>

f:id:nayucolony:20170604040750p:plain

座標は書いた順番にパスが惹かれていくので、入れ替えると見た目は変わる。

<svg width="1000" height="1000">
  <path d="M0,0 L320,160 320,0 0,160" fill="#3F51B5"></path>
</svg>

f:id:nayucolony:20170604040636p:plain

曲線を引く場合

曲線を引く場合はQを使う。 曲線はベジ絵曲線で、クアドラティックベジエとキュービックベジエの二種類がある。Qだと「クアドラティックベジエ」が惹かれる。 名前が違えば当然処理も違うが、詳しいことはまだ調べきれていない。

以下は、一番最初の図形を少し変更したもので

320,160 => 160,320160,320 => 0,160が曲線になる。

<svg width="1000" height="1000">
  <path d="M0,0 L320,0 320,160 Q160,320 0,160" fill="#3F51B5"></path>
</svg>

f:id:nayucolony:20170604041952p:plain

注意

この図形描画は、svg要素がその直線を引くのに必要なだけの領域を確保できていることが前提となる。 上記までのサンプルは、しれっと1000px * 1000pxを確保していたが

たとえば2つ目のサンプルは、描画に320px * 160pxを必要とする。 ここで、svg要素の領域を160px * 80px にしてみる。

<svg width="160" height="80">
  <path d="M0,0 L320,160 320,0 0,160" fill="#3F51B5"></path>
</svg>

すると、こうなる。

f:id:nayucolony:20170604042736p:plain

path要素はちゃんと描画領域を確保しているものの、svgが領域を確保していないためにクロップされている、と表現するのが正しそう。

参考

d - SVG | MDN