#技術書典 3にサークル参加しました！
技術書典3にサークル参加しました
TL;DR
- 完売御礼ありがとう
- 商業化します頑張ります
- 大量の戦利品
トピックいくつか
決済システム
技術書典決済システムを導入しました。バーコードを読み取ってもらって、完了したらwebの管理画面に状態が出るというやつ。 これが、まあひくほどよくできてて、驚きました。
初回のやりとり：
来「決済完了でーす」
私「はーい、確認しm、、、えっもう反映されてる！？はやくね？あれ？エビ？エビ？？あっOKです！ありがとうございます！」
ざっくり15%程度はこちらの決済で、いずれも利用者のトートバッグはパンパンでした。 個人的には、毎回かわるシェアコード（決済固有のワンタイムシリアルっぽいものが発行される）が絵文字だったのがいい感じで、ゴリラとかペンギンとか、かわいい〜とかいってたんですが、エビとか、カタツムリとか、こう、毎回「次はなんだろう？？」と楽しむ感じの謎UXを発揮していました。
ステッカー
めちゃくちゃ在庫あるので常時持っておきます。 やたら質のいいシールなのでどこかに貼ってください。
部数
完売です #技術書典
— ナユ【11/4,CSSnite登壇】 (@nayucolony) 2017年10月22日
前回、終了間際で100部なくなったという感じだったので、今回も同程度持ち込んでいたのですが、半分の時間で完売してしまいました。前回はそもそも話題がニッチだったこと、それに比べると今回は割と対象読者の間口が広かったり、技術書典というイベント自体のオペレーションが爆速でスケールしていたりという理由もあったかと思います。正確な需要把握というものは難しいなと感じているところです。
完売しちゃうと、正確な需要の把握ができないんですよね。200部だったのかもしれないし、500部だったのかもしれない、みたいな感じになると、次回に活かせません。この辺は、プレス代なんかのことも考慮してちゃんとやっていかないといけないなと思いました。どかどか利益が出なくてもいいとは思っているものの（同人イベントだし）、サークルとして継続的活動ができて、他サークルの頒布物をお金のことを気にせずに買い漁れるくらいには考えておく方が、イベントのためにもいいよなあと思っているところです。次回に活かす！
制作サイドの話
このへんはデザイナーのshizooo氏が書くって言ってた。
商業化
（近くで「商業化」の話が聞こえまする。。。）
— ナユ【11/4,CSSnite登壇】 (@nayucolony) 2017年10月22日
こちら、実は他人事ではなく、弊サークルも商業化のお話をいただいています。
告知する割にはお知らせできる情報が少ないのですが、3月にC&R研究所様より発刊予定です。 同社は、公式広報が、なんと犬。アカウントはこちら。
C&R研究所の会社犬ラッキー(@lucky_CandR)さん | Twitter
「わかばちゃんと学ぶ」シリーズの湊川あい氏や、「インフラエンジニアの教科書」シリーズの佐野 裕氏と同じ出版社様です。
わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉 | 湊川 あい, DQNEO |本 | 通販 | Amazon
インフラエンジニアの教科書 | 佐野 裕 |本 | 通販 | Amazon
僕自身がデザイナーとエンジニアの橋渡し的なポジションで仕事をしているということもあり、今回取り上げたgulpに限らず、ウェブデザイナーがエンジニア方面にゆるふわで歩み寄れて、もっと楽しく仕事ができるような本にしたいなと思っています。 ですので「絶対感想くれるマン」ほか、手に取っていただいた方のフィードバックを切にお待ちしています。なにとぞよろしくお願いします。
次書きたいなーと思ってるもの
もちろん、まずは商業出版に向けてフルコミットしていく予定ではあるのですが、その後の技術書典のことなんかも色々膨らみますよね。
結構色々あるのですが、やっぱり僕が一回つまづいたものをチョイスしたいなという感じです。今のとこ、JavaScript方面でなかなかつまづいてきたので何かゆるふわにチュートリアルとか書きたいなーと思ってます。
あとは毎回言ってるんですが単著じゃなくて共著でも書きたい。ウェブメディアも、会社のも書かなきゃだし、あー、することいっぱいでうれしい（白目）
買ったもの
- 技術季報 vol.2 / 技術書典
- やっていく合同誌 / pentapod
- CSSではじめる同人誌制作 / pentapod
- 技術と法律 / Smipsのエンタメと知財分科会と法律実務分科会
- 小さな会社でwebプログラマはじめました / かまずにまるのみ
- プログラミング勉強中の人にオブジェクト指向とは何なのかなんとなく伝えたい本 / かまずにまるのみ
- KotlinでAndroidアプリをつくってみるハンズオン / しゃのラボ
- 逆引きwebpack / chibi-developer
- RxJS入門 / chibi-developer
- にきてきな / ひかる黄金わかめ帝国
- Vue.jsでポートフォリオサイト制作記 / べころもち工房
- イヌでもわかるWeb Comopnents / 犬テトラ+
- 簡単JavaScript AST入門 / 東京ラビットハウス
- エンジニア・デザイナーのためのCSS z-indexを倒す / 吉川雅彦
- たのしいGitオブジェクトの歩き方 / ukyoweb
- 解説CoreUtils / 第7開発セクション
- インフラエンジニアの教科書 / C&R研究所
- まこちゃんとラッキー / C&R研究所
- 魔王教授と学ぶGitコマンド入門 / マンガでわかるWebデザイン＋Git
- 図解でわかるGoogle Analytics / マンガでわかるWebデザイン＋Git
いくら使ったのかとか知らないよ。
当たり前ですが、本を買ったお金が著者に入りますが、そのお金でまた新しい本を刷ることになります。 いいかいクリエイターにものを作らせたければ札束でなぐるんだ。
次のイベント
CSS Nite LP54「Coder's High 2017」（2017年11月4日開催）
こちらに登壇します。テンプレートエンジンPugのお話をさせていただきます。
#技術書典 3で「ゼロからはじめるgulp入門書」を頒布します！
技術書典さんは２回目の参加です。前回すっごく楽しかったので今回もすっごく楽しみです。
お品書き
今回は物理本があります！薄い本作成の実績解除！
- 新刊「ゼロからわかるgulp入門書」500円
- ちびガルプステッカー 200円
（技術書典2で頒布した「Bulma Code Reading」のダウンロードカード頒布はありません。）
決済方法
- 現金
- 技術書典決済システム
- pixiv PAY（事前にアプリの導入をお願いいたします）
pixiv PAYは2017年12月までは手数料がかからないそうなので今回試験的に導入させていただきます！ありがとうございます！！
ちなみに、技術書典専用決済システムは使用できませんのでご了承ください。。。（Android端末をもってないので、、、）
10/21追記:対応します！Androidユーザーの方限定になりますが、以下からアプリをダウンロードし事前設定をお願いします！ 技術書典 - Google Play の Android アプリ
新刊「ゼロからわかるgulp入門書」
概要
gulpとは？という部分からスタートし、環境構築、タスクを書いてみるという入門本です。 業務でJavaScript書く機会ないけど練習したいというウェブ制作者さんにはgulpでNode.jsを書いてみるのがオススメ。 ブラウザ対応などを考えなくていいので新し目の仕様も取り入れられたりして楽しいですよ！
こんなひとにおすすめ
- これからgulpを始めたいウェブ制作者
- 社内・取引先などにgulpを使わせたいウェブ制作者
これからな人はもちろん、もう使ってるけど他の人にgulp教えたいという場合に便利です。 物理本購入者特典としてepub/pdfのダウンロードが可能になっておりますので合わせてご活用ください！
ちびガルプステッカー
表紙イラストを飾る女の子のステッカー。イラストは ろく氏。 表面がいい感じに加工されたステッカーです。丸なので割とどこにでも貼りやすい！
ブース
執筆とイラスト以外のデザインとあらゆるマネジメントは shizooo姉様がしてくれました。間違いなく弊サークルの黒幕です。
通販について
前回のペースでいくと当日完売になる可能性があります。大変恐縮ですが「絶対に感想くれるマン」の方へ在庫のお取り置きを実施しようとおもいます。もちろん完売しなければ通常通りの通販になります。
もしも興味のある方がいらっしゃいましたら @nayucolonyまでご連絡ください。
最後に
技術書典公式サイトでの情報はこちらです！
それでは、当日会場でお会いしましょう！何卒よろしくお願いいたします！
配列の要素を関数に渡して、それらの結果から新たに配列を作るためにはmap()メソッドを使う
やりたかったこと
gulpで、配列に定義したディレクトリをつくるタスクを定義しようとしました。 別のタスクで書き出し先を決めてしまっているため、そのまえにディレクトリが存在していてほしいという感じです。
そこで、Node.jsのchild_process.execを使おうとしました。これはNode.jsにビルトインされている、シェルコマンドを実行するためのメソッドです。これにmkdirコマンドと配列の要素をわたしてつくればいいんじゃね？という考えにいたりました。
しかし、このchild_process.execコマンドは非同期処理のコマンドです。child_process.execSyncを使うという手もあったものの、せっかくなのでしっかりPromiseを使えるようになろうという気持ちで挑戦してみました。
TL;DR
結論からいうとできたやつはこれです。
const gulp = require('gulp') const exec = require('child_process').exec const directories = [ './hoge/fuga', './hoge/piyo', './piyo' ] function execMkdir(name) { return new Promise((resolve, reject) => { exec(`mkdir -p ${name}`, (error, stdout, stderr) => { if (error) return reject(error) if (stderr) return reject(stderr) return resolve(true) }) }) } gulp.task('generate-directory', () => Promise.all(directories.map(app => execMkdir(app))) )
解説
配列を定義
作りたいディレクトリが3つあって、配列に定義しています。
const directories = [ './hoge/fuga', './hoge/piyo', './piyo' ]
これらのディレクトリを生成したいという状態です。
child_process.execメソッド
Node.jsでシェルコマンドを実行するにはchild_processのexecメソッドを使います。
Child Process | Node.js v8.7.0 Documentation
execメソッドは非同期処理なので、ターミナルに「はいこれよろしくー」と命令を出した後にさっさか次に進んでしまいます。これでは、処理が完了しているわけでもないのに次の処理が始まってしまう可能性があります。これだと意味がなくて、全てしっかり終了したことを確認してから次の処理を行う必要があります。
ちなみにchild_processにはexecSyncというメソッドもあります。execメソッドを同期処理にするやつです。
Child Process | Node.js v8.7.0 Documentation
これを使えばいちいち処理が完了をまつので、順番に行われはします。しかし、非同期処理のgulp上で同期処理のメソッドをいれるのもなーとか、あとは同期・非同期をしっかり理解して扱えるようになりたいなーというのもあり、ここは苦手なPromiseに挑戦してみることにしました。
Promiseを返す関数を定義
流れ的には次の通りです。
Promiseオブジェクトをつくる- 関数を実行する
- 実行した関数のコールバックで
rejectかresolveを返す
実際の関数は次のとおりです。
function execMkdir(name) { return new Promise((resolve, reject) => { exec(`mkdir -p ${name}`, (error, stdout, stderr) => { if (error) return reject(error) if (stderr) return reject(stderr) return resolve(true) }) }) }
この関数が呼び出されると、処理が完了するたびにPromiseオブジェクトが返されます。
Promise.allメソッドでPromiseをキャッチ
あとは、タスク側で先述の関数をループさせ、ループするたびに返されるPromiseオブジェクトを全部キャッチできた時点で「全部終わった」という判断がなされます。それらの処理をキャッチするのがPromise.all()メソッドです。
Promise.all(iterable);
Promise.all() - JavaScript | MDN
iterableとはES2015から追加された概念で、反復処理プロトコルのことです。iterableの意味は「反復可能」。JavaScriptにビルトインされているものでいうとString、Array、TypedArray、Map、Setの5つの型がiterableだそうです。
そのほかにもジェネレーター関数を用いることでユーザー定義できるようですがここでは取り扱いません。
要は、3つの処理を全て配列(Array）に叩き込んでPromise.all()メソッドに渡せば処理完了という感じです。その後、メソッドチェーンされたthen()メソッドに処理が移ります。例としては次のような形です。
var p1 = Promise.resolve(3); var p2 = 1337; var p3 = new Promise(function(resolve, reject) { setTimeout(resolve, 100, "foo"); }); Promise.all([p1, p2, p3]).then(function(values) { console.log(values); // [3, 1337, "foo"] });
mapメソッドで、配列を関数に渡してあらたな関数をつくる
先述のように一つ一つのPromiseオブジェクトや数値が名前を持っていれば、それぞれ配列の要素として代入するだけでいいのですが、今回は一つの関数を配列の要素のぶんだけループさせる処理をしたい、いったいどうすれば？と言うときに教えてもらったのがmap()メソッドです。
Array.prototype.map() - JavaScript | MDN
map()メソッドは、与えられた関数を配列のすべての要素に対して呼び出し、その結果からなる新しい配列を生成します。
これで、配列の全ての要素に対する処理からあらたな配列を生成することができます。
ということで、処理はこんな感じに。
const gulp = require('gulp') const exec = require('child_process').exec const directories = [ './hoge/fuga', './hoge/piyo', './piyo' ] // function execMkdir(name) { return new Promise((resolve, reject) => { exec(`mkdir -p ${name}`, (error, stdout, stderr) => { if (error) return reject(error) if (stderr) return reject(stderr) return resolve(true) }) }) } gulp.task('generate-directory', () => Promise.all(directories.map(app => execMkdir(app))) )
これで、いちいち処理するたびにPromiseを返し、全てPromiseを受け取った時点で次の処理にすすむという処理がかけました。
WordCamp Tokyo 2017にスピーカーとして参加しました。 #wctokyo
にスピーカーとして参加しました。
※セッション内で口約した「あとでフォロー記事書く」といったやつとは別の、参加報告エントリです。技術的な面は、改めて書きます。
一つ書きました 【CLI・atom対応】textlintで文章をチェックしよう！ - to-R Media
登壇スライド
詳しい技術的内容は追って説明記事を書きます。
ひとまずは、参加しましたブログをかかないことには終われませんので、そういうブログを書かせてください。
今回この話をしようとしたきっかけは、「目の前のことに手をつけたら広がりに広がって一連の開発プロセスを経験できたので、せっかくだから外部化したい！」という思いと、ちょうどWordCampTokyo2017のCfP募集の時期が被っていたことでした。
会社のブログを更新する気がなかなか起きないという現状があります。
その原因を辿ると
「ネタはある、書きたいこともあるが、WordPressのエディタだとやる気がでない。しかし、手元で好きなエディタでマークダウンで書くと、それをWordPressで見れるようにする作業が発生する。レビューしてもらうのもめんどくさい。みんな忙しいしもういいや」
こんな感じでした。
実際、下書きのまま公開してない（あと一歩で公開できる）レベルのデータは存在します。ただ、メインの制作や個人活動に時間をさくと完全に「いつかやろう」状態。
これを打開するためのプロセス構築が、今回の事の発端でした。
そして、構築するにあたり、どうせ作るならいいものをと思って実際の紙のメディアのフローも参考にしました。執筆と出版（デプロイ）の間にあるものを、コンピューターで処理できればいいのではないかと。そのあたりで「校閲」というワードがピンときたのでした。
こういう「当たり前だけど、当たり前にすることがおろそかにされがちな行為」を原点にちゃんとしようとする性格があり（マークアップなんかもそう）ここをかなり勉強しました。
そして、「なぜちゃんとしないといけないのか？」という部分にもどって考えるということもしました。どちらかというと、僕はちゃんとしたいから、ちゃんとしないといけないんだという主張を通すための、理屈がとおるような理由を探しました。
とりあえずこれらの本は読みました。
エディターズ・ハンドブック 編集者・ライターのための必修基礎知識 (Editor’s Handbook) | 編集の学校/文章の学校 |本 | 通販 | Amazon
Amazon.co.jp： セルフパブリッシングのための校正術 (群雛文庫) eBook: 大西寿男, 伊富魚, 0.9Gravitation, 鷹野凌: Kindleストア
- Amazon.co.jp： ナタリーってこうなってたのか YOUR BOOKS eBook: 大山卓也: Kindleストア
もっとあるけどこの辺で。
そして、大した理由は書いてませんでした（笑）。もう、当たり前のようにその行為のことについて書いていたので、「あぁ、そもそも間違ったもの、世に出せないよな」というなんとなくな部分に着地しました。スライドでは「あやまった情報を出すことで信用を失う。真摯に向き合ってないことがバレる。読み手がこちらの情報に真摯であるほど失う信用はでかいし甘く見てはいけない。信用で色々なことが生み出せる今の時代でそれは大きなロス」みたいな話をしました。僕が自分を納得させられる最大の理由がこれでした。
スライドづくりが難しい
難しい。
ツールの選定からはじめました。最初、原稿をmarkdownで書いていたのでそのままreveal.jsに流しこもうとしました。たしかに作成ツールとしては非常に便利ですが、やはりプレゼンツールとしての機能に富んでいるのはkeynoteだなと思い途中で変更。
また、昔、著作権のことを考えずに拾って来たアニメの画像をばんばんつかって登壇していたのですが「そういうのちょっと考えたほうがいいと思うよ」と言っていただいたことがあり、photoACとAdobeStockからCC0の素材のみをピックアップするみたいなことも気をつけました。あれがなかったら今だにあの調子だったんだとおもうとぞっとしますね。恥ずかしい。
また、30分セッションは「短い！」という人もいますが僕からすれば聞き手側の30分は長いです。人間の集中力が持つのは何分とかいいますが、話がおもしろくなければ5分のLTでも早く終われやと思ってしまいます。なので「最後まで聞いてもらえる」を目指しました。がんばったつもりですが、こちらの世界に引きずりこむようなトークを盛り込みすぎた結果あまりテクニカルな部分にコミットできてないというのが現実。。。これはあとでブログを出すという事をその場で言いましたし、なんなら最初に謝りました。。。
あとは縦長の会場でどうスライドをつくるか？色は？文字は読めないだろうから画像を出すか？みたいなことも試行錯誤しました。でも会場のセッティングがちゃんと設計されてたので若干杞憂だったかな。
次回に向けてのメモ
まわせPDCA。
接続確認はちゃんとする
デモができなかったんですよ。動かなかったわけじゃありません。ミラーリングの仕方がわかりませんでした。お見苦しいところをお見せしたくなかったので即中止しました。だって手元で動かしても、聴衆の目線の先には 山。
普段、もちろんディスプレイに投影して練習はしていたのですが、ディスプレイが見える位置にあったので、練習ではデュアルディスプレイでもデモができていたんですよ。それが、背後にスクリーン、明るさも部屋とは違う、カーソルが見えない、などなど完全に本番を想定できていませんでした。いやまじで痛い思いして学んだ。
あと、iPhoneから画像を転送しようとしたらめちゃくちゃAirdropできる端末でてきて自分のが検出されないとか笑
姿勢
友人が写真を撮ってくれていたので写真を見ると、まーえらそうというか、緊張感がないというか。普段一人練習だとちゃんと直立で手も目の前で軽く組むみたいなことができてたんですが、完全にテンションがあがって舞い上がってるんですよね。緊張感がない。場なれのしてなさですね、、、次回までに改善します。
発言
生意気な若者みたいで嫌だなと思いました。笑
すごく嬉しかった事
ここからいい話だから読んで。
スライドの中でも言ったのですが、僕がウェブ業界に入るきっかけになったブログがいくつかあって、その著者のデザイナーさんにたくさん会えた事です。
これね。
フリーランス Advent Calendar 2014 - Adventar
主催はspicagraph氏なんだけれど、会場では旦那さんにご挨拶しました。笑
たぶんこの人たちは、普通に企画だからブログを書いただけなんだけど、それを見て誰かが何かを思うわけで、誰かの人生変える可能性だってあるわけですよ。
だから、「私なんて何者でもないし」と何かを言おうとした口を閉じるのじゃなくて、「今こうです、こういう状況だから、これをしていて、こうなりました」をただ言っていただくことが今のあなたが出せる価値なんですよというメッセージを最後に投げたという感じでした。
22の時に最初に入社した会社の上司とうまくいかずに、売り言葉に買いことばで辞めるといってからこの先どうしよ〜と思っていた矢先にこれを見て、こういう生き方がいい！と思って業界を志したのでした。勉強好きだし性に合ってるという気持ちでいま二年なんとか生きてこれたよー、、
で、「ぜひ関西遊びにおいでよ！」といろんな人に声かけてもらえたので、なんかのイベントの際に遠征しよーと思ってるところです。でも、直近めぼしいイベントが特に何もない（笑）年内は忙しいので、来年が楽しみです。せっかく行くんだから、LTくらいはしたいしね。
イベントの感想
はじめての1000人規模のカンファレンスだったのですが、特にセッション班のスタッフチームの方には本当にお世話になりました。ハングアウトでリハーサルや当日の流れの相談までしていただけて本当にありがたかったです。
しかも、運良く聞きたいセッションはほとんど周れて（どうしても自分の裏のトラック聞けないのまじで残念でならないんですけど）会いたい人にもたくさん会えて満足です。懇親会も楽しかった。たくさん声かけてもらえたし、たくさん声かけた。アフターで参加者のひとたちと飲んで話して楽しかった。コントリビューターデイも行きたかった（泣）
次のイベント
次は技術書典3に向けて準備をすすめています。また、11月にはCSSNiteに登壇します。トラックあたりの規模は同じくらいですが、やはりOSSカンファレンスとは少し違った雰囲気もあり、より一層気を引き締めていかないとなという気持ちです。
トークで登壇の１回目のチャレンジの場を与えてくださったという意味でもWordCampには感謝しています。来年もスピーカーなりLTなりスタッフなり、何かしらの形で貢献できたらなと思っています。
参加者の皆さん本当にお疲れ様でした。ありがとうございました。
reveal.jsでスライドを作るときに更新するたびに最初のスライドに戻されない方法
はじめてのカンファレンス、トーク採択で30分セッションをさせてもらうことになり、スライドを作っています。 30分スライドとしたら1枚30秒くらい喋るとしても60枚はスライドを作ることになり、デザインが大変。
ということで、普段はkeynoteを使っていたのですが、reveal.jsに乗り換えました。 hakimel/reveal.js: The HTML Presentation Framework
普段使い慣れてるCSSでインブラウザデザインができるので、WEBデザイナーであればkeynote使うよりも楽かもしれません。 CSS側をフレームワーク化すれば、レイアウトも画一化できるし。
cloneしてyarnして必要なものを揃えたら、yarn run startしてライブリローディングしながら編集作業を行うのですが、いちいちリロードのたびに最初のスライドに戻される。世の中の人は毎回こんなことしてんのか？嘘だろ？と思い、reveal.jsを使った形跡のあるリポジトリを見ていると、僕のファイルとの違いを発見。
Reveal.initialize({
history: true,
dependencies: [{
src: 'plugin/markdown/marked.js'
},
{
src: 'plugin/markdown/markdown.js'
},
{
src: 'plugin/notes/notes.js',
async: true
},
{
src: 'plugin/highlight/highlight.js',
async: true,
callback: function() {
hljs.initHighlightingOnLoad();
}
}
]
});
このhistory: true,を記述するのがキモでした。
reveal.jsは、1つのHTMLファイルに全スライドをDOM要素として生成したあとにJavaScriptで出し入れしてスライドっぽく見せています。 なので、リロードがかかると初期状態に戻る＝最初のスライドに戻されるというわけです。
しかし、上記の記述をすることで、スライドごとに固有のURLが発行されます。 なので、リロードしてもそのスライドのURLが更新されるので、最初のページに戻されません。
SPAでも、実際はJSがレンダリングしてるだけだけれど、それぞれの状態にURLを発行している、みたいなことをしているので、同じ原理ですね。
もちろんドキュメントには
// Push each slide change to the browser history
と書いているのですが、個別URLの発行というワードに結び付けられていなかった自分がいたりして、勉強不足でした。 スライド作りも佳境に迫ったところでこれに気づいてしまったのでもっと早く知りたかった感はありますが、ブラッシュアップに役立てたいと思います。
あと、Configurationはちゃんと読みましょう。ぐぐって情報があつまらない理由のほとんどは「そこに書いてあるから」だったりします。
誰かの役にたてば幸いです。
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の開催でしたが、仕事（副業のほう）の都合で日程が確保できず、最終日のみの参加でした。「あーいきたかったな」と思ってしまうので、ハッシュタグ見るのがつらかったです。
当日は、メイントラックのスタッフとして常駐していたため
- ここまで出来るmruby
- Make you a React: How to build your own JavaScript framework.
- Factory Class
- The Evolution of PHP at Slack HQ
のセッションを聞くことができました。
また、一部トラックを移動して
を聴きに行きました。
今日から使えるCSS Grid
Gridが使えることは、先日の一斉実装の件もあり知っていました。 ですが、やはりその方面に明るい方から聞くのは得るものが多いだろうというのと、「buildersconでCSSの話ってどんな感じなんだろう？」というのが気になって参加しました。
Twitterやトラックの様子を見ていると、専業のフロントエンド（マークアップ）エンジニアはそんなにいないという印象でした。別畑からキャッチアップしにきているのかな？という感じもありました。
buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りですというキャッチコピーの通りだと思いました。
専門外の分野の話を聞いて見るのは面白い
ここまで出来るmrubyや The Evolution of PHP at Slack HQは、PHPもRubyも書かない私が聞いても発見がありました（追いつけない部分もありましたが）
一番の発見は「〜って、〜なんですよ」という発言に、わたしは「へぇ〜」と思うのに対し、おそらく普段からPHPやRubyを描いてる人は「wwwww」のような「あるあるw」的な反応をしていたことでした。
専門でやってる人から見たら当たり前な話でも、専門外の人にとっては「知らなかった」「今学んだ」なんだなぁと思いました。 もっというならば、僕がここでUIデザインの話をしたとして、もしかしたら誰かの新たな発見に繋がるかもしれないということです。別分野の人に向けてトークすることを「アウェイ」ではないと思い始めました。
クロージングトークのエモ
refs. Closing
後からスライドや動画は公開されると思うので完結に。 （自分の解釈が多分に含まれます）
- エンジニア35歳定年説みたいな話は、誰かが勝手に決めた限界値
- でも、時間が有限であるというのは事実
- じゃあ、今すぐアクションしたほうがいい
- 今この話を聞いてる人が、今この瞬間にアクションにうつせることは「スピーカーと話す」「参加者と繋がる」
- この先アクションできることは「登壇する側になる」「カンファレンスを作る側になる」
- 技術者はスキルだけあればいいってもんじゃない
- 自分の分野の外側と繋がるともっといいもの作れる
- buildersconはそういうカンファレンスだ
ぶっちゃけ感動しました。エモです。
当初は、よくわからないからちょっと覗いてみようと思っていたレベルだったのが、積極的に技術トークをしていきたいという気持ちになっていました。
最後に
とにかく、刺激になるカンファレンスでした。深夜のエモがとまりません。
もっとやばいのは、今回は最終日にスタッフ参加だけという、ほんのひとつまみしか参加できていないというのに最高みを感じているところです。
次回は全日程参加する、CfPだす、もっといろんな人と喋る、自分の専門外のトークも耳を傾ける、スタッフとしてももっといいものを作る・・・いろんな思いがあります。もっと楽しめそうです。
このエントリは、buildersconを終えた夜に「エモ」駆動でbuildされたものです。 これが、今私にできるアクションでした。
皆さん、次回は一緒にbuilderscon行きましょう！
WP REST APIで投稿データから著者名をひっぱってくる
普通にやっても取ってこれるオブジェクトのなかにはいってない。雑にメモ。
やりかた
wp-json/wp/v2/posts
ではなく、次のURLにGETをなげる
wp-json/wp/v2/posts?_embed
すると、帰って来るオブジェクトに_embeddedプロパティが追加される。
_embedded.author[0].nameに、著者名が格納されている。
これがないと、author idからエンドポイントを生成して叩いてオブジェクト取得して、、、ってしないといけない（？）ので見つけられてよかった。
