蒙古タンメン中本 Advent Calendar 2015 13日目のエントリです。わたくし、高橋まいはが担当します。よろしくお願いします。
写真がきたねーですが過去の記念写真なのでお許し下さい。

中本にめちゃハマっていた頃の話を書きます。と思っていたのですが、半年以上前の記憶がほとんどないため、中本にハマっていた頃のこともよく覚えていません。自作するまでの流れを箇条書きで失礼します。

• 10代後半のほとんどを上野・御徒町エリアで過ごしていたので蒙古タンメン中本（御徒町店）との出会いは必然であった。けど初来店は19歳のとき
• はじめて食べたのは味噌卵麺だった気がする
• 「蒙古タンメン」は、わたくしが猫舌であるために食べられなかった…（麻婆が冷めなくてつらい）
• 2回目の来店以降、北極と味噌卵麺を交互に注文（このとき2週間に1度のペース）
• 1人で通うようになる(このときから週2・3のペース)
• 北極を3倍にしてハマる
• 1ヶ月後くらいに冷やし味噌を食べてハマる
• 冷やし味噌3倍にハマる
• でも北極のほうがスープがうまい気がするので冷やし味噌3倍と北極3倍を交互に食べる
• 当時超安月給、中本のせいで食費がキツくなる（そして太る）
• 自作する

こんな感じです。
中本のせいで貧乏になり、中本に行く日以外はなんにも食べないで過ごしたりしました。（ダイエットも兼ねて）貧乏人でも北極が食べたい！と思い、ぐぐり、こちら（http://tmrng.exblog.jp/4310950/）を参考に自作しました。

そのときの写真がこちらです。

期待を遥かに上回る旨さだったのをなんとなく覚えています。このスープを適当にアレンジして冷やし味噌っぽいのもつくったような気がする。

うまかったなあ。写真は美味しそうに見えないけど。

自作北極スープの味が安定してきてからは、そのスープで「北極鍋」をつくりました。具材はもやしと豚肉とキャベツのみ。キャベツの甘味がスープに染み出すのが若干アレですが、その鍋のシメに食べるラーメンもまた旨い。麺を投入する際に唐辛子を追加するとグッドです。写真はありません。

節約のためにつくりはじめましたが、自分好みに辛さを調節できるのと原材料費が安いこともあり、自作北極で満足しはじめました。そんで中本へ通うペースが2週に1度くらいにオチました。（そして、その他激辛メニューの自作にハマり、中本通いは終了した。）

何が書きたかったかわかんなくなっちゃった上に、当時のことをよく覚えていないのでアレですが、私が参考にしたレシピはかなり再現度高いと当時感じたのは確かなので、北極好きの方は是非つくってみてください。

材料として、
ラードはAmazonでチューブタイプのものを適当に買いました。
麺は、いろいろ試した結果「山岸一雄」監修　つけ麺専用中華麺　4玉入が最高でした。どこにでもある商品ではありませんし、つけ麺用の麺ですがとってもおいしいです。（北極を再現する以外にも、自宅でスープを仕込みラーメンをつくるときは絶対この麺を調達しています。）
唐辛子は、粗挽き（http://kaldi-online.com/item/4512170780331.html）と細挽き（http://kaldi-online.com/item/4512170780324.html）をブレンドしたもの。（常備している）
味噌は母が仕込んだものを実家からもらいました。その他調味料はてきとーです。うまいぞ〜〜！

今住んでいるマンションから歩いて10分ほどの距離に中本があるのですが、またハマってしまう（＝太る）のが怖いので行かないようにしています。
激ヤセしたあかつきには、また通いたい。

おわり〜

TKG Advent Calendar 2015 6日目のエントリです。わたくし、高橋まいはが担当します。よろしくお願いします。

先月半ばに転居＆転職＆もろもろのビッグライフイベントが重なり自炊していなかったこと、激太りしたボディを元に戻すダイエットを始めたことにより、数ヶ月TKGを食しておりませんでした。この度、本アドベントカレンダーへ参加するにあたり、数ヶ月ぶりの炊飯を行いTKGを口にしました。（人とご飯食べた時に、TKGヒトクチチョーダイしたことはあったけどちゃんと食べるのは久々）

ダイエット中なのでUTKGを食べます。SEIYU（最近行けるようになった！）でうずらを買いました。ちっさい。

インターネットで検索したところ、うずらの卵でつくるTKGは濃厚で美味しいとのことでした。

自宅のテーブルがガラス天板なことを後悔しました。照明と脚がどうやっても写り込んでしまう。なんとか写らないように工夫して撮影しているうちにご飯が冷めました。写真トルの下手クソ〜。
ちなみにこのお茶碗に見えるUTKGの食器はチーズフォンデュのチーズを温める器です。小さい。

うずらの卵は鶏卵に比べて、黄身に対する白身の量が少ないように感じます。白身をドュルルルっとすすりたい私としては物足りなさしか感じません。
もう2度とUTKGを食べることはないでしょう。鶏卵が最高。残りのうずらはおでんにします。

小学生の頃、いわゆる鍵っ子だった私は、誰もいない家に帰り空腹を満たすためにTKGを三杯ほど食べるのが日課でした。一杯目はそのまま、二杯目はシャケフレークを入れて、三杯目はごはんですよ！を入れて。TKGのおかげで、こんなにも大きく育ちました。TKGは私にとって母のような存在です。いつもありがとう。

このブログの最初の記事で、CSS仕様書もくもく会やりたい〜などど宣った結果、@kubosho_さんのおかげで、W3C CSS Module 仕様書もくもく会をやっています。（明日第二回目、開催します！）
言い出しっぺが私なので形式上主催者となっていますが、言い出した時点では仕様書のことなんて１個もわかりませんでした。

それから今日まで約１ヶ月半、少なくとも一瞬は每日仕様書（の日本語訳）を見るようにしてきました。それについてメモしておきます。
仕様書に興味あるけど、コレ読むの辛ぃ…と思ってる人がいたら参考になるかもしれません。

やってきたこと

慣れるために

• 第一回CSS仕様書もくもく会のテーマだったセレクタ Level 3を流し見する（每日）
• 仕事中、CSSについて調べることがあったときは、仕様書を読む必要がなくても仕様書のその項目に目を通す
• @momdo_さんのCSS関連ツイートを見かけたら、仕様書を読む

流し見

仕様書と呼ばれるもの全般について思うことですが、日本語が難しいのでしっかり読もうとすると挫けます。（何度か挫けました）
しかし、そこで挫けていては何も始まりませんので、ペロペローっとなんとなく、読んでる風に眺めることを続けました。今でも、しっかり通読することはできていませんが、以前に比べると読むことに抵抗がなくなってきていると感じます。
ちなみに、第二回もくもく会のテーマがColor Moduleに決まってからは、そっちも読んでます。

調べるついでに仕様書

業務でのコーディング中などに、CSSについて調べるときは、ついでに必ず仕様書を読む！ようにしたのもよかったと思います。
これも、流し見と同様、おカタイ文で書かれた仕様書に慣れることの役に立ちましたし、なかなか読む機会がないであろう仕様にも目を通すことができました。

@momdo_さん

もんどさんは、グッドなペースでCSSについて呟いてくださるので、もんどさんのツイート見たら仕様書読む！みたいな、トリガーにさせていただいてます。（もんどさん、ありがとうございます。）

ちゃんと読むために

• 基本の前の基礎知識 - Back to Basics CSS - http://unformedbuilding.com/slide/back-to-basics-2015-08-30/
• W3Cスタイルシート仕様の歩き方みたいなもの（メモ） - http://momdo.hatenablog.jp/entry/20150911/1441977908
• W3C勧告プロセスの概要 - http://www.kanzaki.com/w3c/process.html

普段は基本流し見しかしませんが、時間をつくってちゃんと読んだりもします。
まとりさんのスライドには、先日のBack to Basics CSS当日も、その後も本当に助けられています。
そして、もんどさんの記事。もんどさんが書かれているとおり、仕様書に対する熱が下がってきたと言いますか、心が折れかけていた頃に投下してくださいましたので、今でもモチベーションが下がってきた時は、この記事を読みなおして奮起してます。

あと！W3C勧告プロセス！恥ずかしいことに、これをよくわかっていませんでした。CSSの日本語訳集の表のRECとかEDとか見ても、なんだそれ状態でした。
これは知っておかなきゃいけなかったと思います。（仕様書読み始めた頃は、あまり意識してなかったのです）

やってみて今思うこと

なぜ今まで仕様書に出会わなかったのか

私はもっともっとも〜〜〜〜っと早くに、仕様書をちゃんと読んでいたら今より素敵な人生を送れていたかもしれない。あのときハマったアレは、仕様書を読んでいれば、なんてことない当たり前の結果だったのかもしれない…。

思い起こせばCSSを書き始めた十数年前から、CSSについてずっと調べてきたはずなのに、一度も仕様書に出会うことはありませんでした。（私が仕様書を軽視していて、目に触れることがあっても、気に留めていなかっただけかもしれないが）読まなくても生きていけるし、コーディングのお仕事できるけど、仕様書読めばもうちょっと幸せになれるのでは、と少し思います。

私は幸せになりたいので、これからも積極的にいろんな仕様書を読んでいこうと思っております。

覚えることたくさんだ〜！おわり！

先日、働いている会社で一部サービスを利用している◯P◯さんのセミナー？に行ってきました。
参加者が少なかったせいで軽食とは言えない量の食事がでてきたので夕飯食べられてよかったです。

日にちが経ってしまっていて記憶がアレなのですが、参加記念としてゆる〜くメモしておきます。

最低限やっておくべきセキュリティ対策

今回のテーマは、Web制作者だったら知っていて当たり前・できていなかったら恥ずかしい最低限のセキュリティ対策　ということでした。

WWWに公開することの危険性を知る

WWWに公開した直後の訪問ユーザを見たところ（登壇者の方のブログをサンプルとして）（たしか公開翌日のデータ）
訪問者の割合が、人：18%　bot：82%
だったそうです。もちろんbotにもいろいろありますが、なかでも中国のbotとロシアのbotが異常に多かったとかそんな話でした。

セキュリティ対策が不十分で損害賠償請求された例

多分これ の話をされてました。
で、こんときの裁判で「最低限のセキュリティ対策」の基準？になったのが「安全なウェブサイトのつくりかた（IPA）」だとかそんなお話でした。

私たちが最低限できること

個人情報やカード情報などをできるだけ保持しないこと

セキュリティリスク軽減のために

• ID/PWはバレやすいのではだめ
• CMSやPHPなどのアップデートはマメに実施しましょう
• XSSクロスサイトスクリプティング
• SQLインジェクション

不正アクセス事件？の約半分が内部関係者の犯行だとおっしゃっていました。こわいですね。

そんな感じでした。
スライド1枚ごとに対する説明はよくわかったのですが、全体を通して何を伝えたかったのか私の頭では理解できませんでした。
（スライドのはじめのほうに目次的なものがあったので、その流れで話が進むのかと思って聞いていたら、目次通りには話が進まなかったため、だいぶ混乱しました）

ただ、ウェブディレクター向けのセミナーで、広く・浅くセキュリティについて知るって感じの会だったので、そういうものなのかもしれません。理屈知りたいマンとしては不完全燃焼です。

今回は自身の興味ではなく、会社で◯P◯を利用しているので何かタメになればと思っての参加でしたが、会社に持ち帰って役立てることはなかったかもしれません。
ちょっと残念でしたが、そういうときもある。

おわり〜

誰にも言わずにひっそり、こういう記事を先月書きました。
http://mtdew2.com/2015/09/15/why-to-compress-javascript/

誰かの役に立つとも、おもしろいとも思わなかったので、そっとしておいたのですが
某氏の記事からリンクしていただき、思ってたより多くの方の目に触れることになったようで非常に恥ずかしいです。
まとまっておらず申し訳ありません。
ひっそり書いた記事の終盤で、HTMLはなぜ圧縮しないのか（する必要がないのか）というようなことを書き、それについて@webcre8さんに相談にのってもらっていたので、そこを改めて書こうと思います。

HTML ファイルは圧縮しないの…？

私が普段、他所様のソースコードを拝見する限りではHTMLファイルのソースコードを圧縮しているものもありますし、していないものもありますが、圧縮していないことが圧倒的に多いような気がしていました。（CSS/JSは圧縮しているのに！）

で、その疑問を深夜の@webcre8さんに投げかけたところ、氏の書いた過去記事の「要素間ホワイトスペース」にあるようなお話をしてくださいました。

HTMLには要素間ホワイトスペースが存在する

上記記事には、

スペースは通常半角を使うと思いますが、ここで代わりに全角スペースを使うと、それは要素間ホワイトスペースとはみなされません。それを利用して自由に間隔をとる人もいたりするのですが、半角スペースは改行やインデントの様に記号として存在するものであり、全角スペースは日本語にしか存在しないれっきとした文字です。見えないひらがなを置いているのと同じで、タグとタグの間にあるべきものではありません。

と書いてあります。
さらに、

要素と要素の間にある連続したスペース、タブ、改行タグは全て一つの要素間ホワイトスペースと見なされているからです。

とのことです。

この説明を踏まえて、「HTMLを圧縮してスペースや改行を取り除いたHTMLのソースコードは、圧縮の前後で全く同じHTMLのソースコードは言えない。」という内容の話をしました。@webcre8さんの記事をじっくり読むといいかもしれません。

この記事ではこのあと、display: inline;やdisplay: inline-block;を使ったリストの横並び表示をした際に、横並びのリスト間に隙間ができることについて説明されています。

前述の説明で、なぜ横並びのリストの間に隙間が出来るかがわかったと思います。これはli要素をインライン扱いにしたことによってli要素間に要素間ホワイトスペースができている、というわけです。

1
2
3
4
5

<ul>
  <li>リスト１</li>
  <li>リスト２</li>
  <li>リスト３</li>
</ul>

この<li>に、display: inline;やdisplay: inline-block;を指定して横並びのリストをつくろうとします。
で、表示するとリスト間に小さな隙間ができます。
これを

1

<ul><li>リスト１</li><li>リスト２</li><li>リスト３</li></ul>

こんな感じに改行とスペースを削除して、display: inline;やdisplay: inline-block;を指定して表示させると、リスト間の隙間がなくなるのですねー。

これが、「圧縮（改行やスペースを削除）前後のソースコードは同じものと言えない」ってことなのかと思います。

preの話

あとは<pre>の話です。
<pre>内は改行もスペースもソースコード通りに表示されますね。
試しにぐぐって出てきたHTMLソースコードの圧縮ツールのうちいくつかで、圧縮を試してみたのですが、今回試したものに関しては全て<pre>内の改行も削除されてしまいました。
そのHTMLファイルをブラウザで表示すると、元々含まれていた改行やスペースが削除された<pre>〜</pre>が表示されるわけです。
たまたまそのとき見ていたCodeGridさんの^1ソースコードを見ると、<pre>内の改行やスペースのみ保持され、それ以外の改行やスペースは削除されている感じでした。（違うかも。）
このCodeGridさんのような圧縮であれば、<pre>内は正しく表示され、圧縮による表示への影響は大きくないのではないかと思います。

preのスペース・改行を保持したとしても

話を少し戻して、@webcre8さんの記事にあった「要素間ホワイトスペース」の存在を考えると、<pre>内の改行が保持されていようと、圧縮前後のソースコードが同じものとは言えないですよねーというお話になりました。

圧縮したらファイルサイズが小さくなるわけですね。で、そのとき圧縮前後のソースコードが必ずしも「同じもの」でなければならないとは私は思いません。（HTML詳しくないので、なんとなくそう思うだけです。）
ただ、HTMLのソースコードを見る・読むのが個人的に好きなので、圧縮されてないほうが読みやすくていいなあと思います。

はじめ@webcre8さんにこれについて聞いた時に「HTMLは文書だし、スペースも行間も意味あるんだからむやみに消さんほうがいいでしょ」的なことをおっしゃっていたのですが、
私の頭が追いつけず、@webcre8さんにはだいぶ長い時間お付き合い頂きました。ありがとうございます。
正直しっくりこない部分もあるのですが、以上のような理由で圧縮ツールにかけないほうがよさそうだね〜（<pre>内のスペースや改行が削除されてしまうツールも多いので）って話で一旦終わりになりました。

もし違う意見がある方がいらっしゃいましたら、お聞かせいただけますと大変嬉しいです。

おわり！

追記

• 2015-10-06 @debiruさんが記事書いてくださいました。
  http://debiru.hatenablog.com/entry/20151006/no-more-compress
  ありがとうございます。
  記事の内容と関係ありませんが、no-more-compressっていうのがかっこいいと思います。（NO MORE LIESっぽいです。COMPLEXの）

@debiruさんのツイートにハッとした。（@debiruさんのツイートにはハッとさせられることが多い）
http://twitter.com/debiru/status/642357943560638465

上記ツイートの後

闇雲に「JSは圧縮するもの」という認識で圧縮している人が多いように感じています。

（https://twitter.com/debiru/status/642362384670068736

と、おっしゃっていた。まさに、私がそれ（闇雲に圧縮している人）です…。ごめんなさい。
そこで、JavaScriptの内容をなぜ圧縮するのか考えてみました。誰かの役に立つことはないと思いますが、備忘録的にまとめます。

私の考える圧縮の理由

• ファイルサイズを小さくする
• ↑ によって読み込み速度をあげる

これしか思いつきません。無知だ。
JavaScriptやCSSファイルを圧縮するウェブサービスやツールが話題になった頃に、「あ〜とりあえず圧縮したほうがいいらしいよ〜？」くらいの気持ちで、なんでもかんでも圧縮しはじめた私は、なぜ圧縮するのかなんて考えたことがありません。
しかし、私が制作に携わるサイトは小規模〜中規模でアクセス数も多いとはいえない。圧縮したからといって、読み込み速度の違いを実感することはない。圧縮の前後で明らかに違うのは、JavaScriptファイルのソースコードの可読性のみ…？

聞いてみた

最近とってもお世話になっている@umekichinanoさんにJavaScriptファイルの内容の圧縮について、見解を伺いました。
以下、インタビュー形式の箇条書きでまとめます。

JavaScriptファイルのコードを圧縮する理由は何だと思いますか

• 元々の目的は、サイズダウンすることによってページのレスポンスを早くすることだったかと
• 個人プログラマーはコードを読まれたくなくて圧縮していることも
• 会社等のルールに準じていることも
• アクセス数が少ないと圧縮しても変わらないが、数百億のアクセス数があるレベルになると、多少のサイズダウンでも転送量に差が出る

可読性以外に圧縮しないメリットはあるのでしょうか

• 特にないかもしれない
• 圧縮（によるサイズダウン）はどんなときに必要といえるでしょう
• 重量課金制のサーバ（AWS等）を使う等、転送量を気にする必要があるとき
• JavaScriptやCSSのファイルサイズがとても大きいサイトで、スマートフォンからのアクセス等を考慮したとき

「圧縮することにこの程度のメリットがある、とは言えないが、アクセス数・転送量を考慮するときや、明らかにサイズが大きいファイルをサイズダウンさせるという意味では、十分にメリットがある」という認識で大丈夫でしょうか…

• 今の世の中ではそれで十分かと
• 今後、5G回線が普及して10Gbpsのデータが行き交う世の中になったときは、ほぼ意味のない労力になっているかも

@umekichinanoさん、本当にありがとうございます。理解には程遠いですが、だいぶ雰囲気をつかめました。
ウェブサイトのパフォーマンスやチューニングについて知識がないままでは、この件を理解することはできなさそうなので、今後の課題にします。

あとがきと課題

今私が仕事で携わっている案件の規模では、圧縮することに大きなメリットはなさそうだということがわかりました。
それでも、圧縮しない理由がないなら、ファイルサイズは小さいほうがいいだろうと思うので、今後も業務で制作するサイトのJavaScriptのファイルは圧縮すると思います。

HTMLファイルは圧縮しないの…？

これすごい気になってるんですが、CSSとJSのファイルを圧縮していても、HTMLはしていないサイトって結構見かけるような気がします。（わ、私がそうです。）
個人的に、自分のも他所様のもHTMLのソースコードは見ることが多いので、圧縮されていないほうが助かるのですが、CSSとJavaScriptは圧縮するのにHTMLだけしないのもなぁ。と疑問に思っています。
読みやすさのためだけに圧縮していないのか、他に理由があるのか、圧縮する必要がないのか、勉強したらわかるようになるのかしら。

2015/9/16 20:30 追記
@webcre8さんに説明していただき、↓読んだらだいたい解決しました。HTMLファイルは圧縮しないほうがよさそう。
http://webcre8.jp/investigate/html-implied-specifications.html

参考と課題の記事

• Webフロントエンドパフォーマンスチューニング // Speaker Deck : https://speakerdeck.com/h13i32maru/webhurontoendopahuomansutiyuningu
• ユーザーの体感速度を高めるためのJavaScriptチューニング（前編） | HTML5Experts.jp : https://html5experts.jp/yoshikawa_t/877/
• ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks : http://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/
• Webサイトのパフォーマンスをチューニングする | PowerCMS ブログ | PowerCMS - カスタマイズする CMS。 : http://www.powercms.jp/blog/2013/02/website_fast.html

CSSイベント「Back to Basics」 | Peatix : http://peatix.com/event/105960

Togetterまとめ : http://togetter.com/li/867476

2015年8月30日(日)に恵比寿ガーデンプレイスタワーで開催された、Back to Basicsに参加しました。13:00〜19:00（懇親会含）と長時間のイベントでしたが、どのセッションも興味深いものばかりで、あっというまの６時間でした。

全セッション・LTについて書いていますのでとっても長くなりましたが、復習できてよかったです。

イケないことや変なこと書いてたら即座に修正しますのでお知らせくださいませ。（@mt_dew2）

1. 基本の前の基礎知識（@ub_pnr さん）

https://twitter.com/ub_pnr/status/637866768476667904

• 宣言（property:value ）から宣言ブロック、スタイルルール、@ルール、コメントのお話
• プロパティ仕様の読み方
• 値の構文
• プロパティに指定できる型と単位

※↑はオリジナルの目次と異なる自分用のまとめです。（以下同様）

一番目にこのセッションがあってよかった！仕様書を読み慣れてない人（私とか）なら、コレを見るだけで仕様書がどんなもんかわかったような気になれると思います。とってもわかりやすいスライドで、仕様書って楽しそう！と思わせてもらいました。

2. UAスタイルシートとリセットCSS（@kojika17 さん）

https://twitter.com/kojika17/status/637857572452564993

• UAスタイルシートのお話
• ↑を踏まえて、Reset.css(Normalize.css)のお話

（@kojika17 さんは過去にもブログでデフォルトスタイルシートについて書いてくださっています。とても好きな記事です。）
デフォルトスタイルシートから考える、リセットCSSの留意点｜Web Design KOJIKA17

http://kojika17.com/2012/09/reset-css-from-default-style-sheet.html

3.ご存じですか？colorプロパティ（@GeckoTang さん）

https://twitter.com/GeckoTang/status/637866434740137984

• colorプロパティは文字の色を決めるプロパティではない
• colorプロパティが影響するその他プロパティ
• currentColorと使い方の例
• tomatoについて（番外編・スライドにはありません）

currentColor、使い方によっては超ベンリだということがわかりましたので使える機会をうかがっていきたいです。

余った時間でtomato（ ■ #ff6347）についてお話されていました。@GeckoTangさんがトマト好きなわけではないそうです。

LTのお時間

LT1. CSSで固定比率レイアウト（@yoshiko_pg さん）

https://twitter.com/yoshiko_pg/status/637865526438424576

• widthを基準にheightを％指定する方法
• スライドのおまけ（当日話してない内容）がイイ！

LT2. Evaluating your stylesheets（@t32k さん）

• StyleStats - An evaluating tool for writing better CSS. : (http://www.stylestats.org/)[http://www.stylestats.org/]
• 好きなウェブページをStyleStatsにつっこむ遊び楽しいです。

LT3. お前は table-cell に position: relativeできなかった人の数を覚えているのか（ @debiru さん）

https://twitter.com/debiru/status/637813897420890112

• Firefoxの伸び代について
• table-cell に position: relative できず苦しんだ人々がいたことを忘れません

LT4. PostCSS 5.0: for Custom CSS Preprocessing（@morishitter_ さん）

https://twitter.com/morishitter_/status/637874565792854016

• PostCSS 使ってみます。
• @morishitter_ さんは若くて勢いがすごい PostCSSエヴァンジェリスト。

LT5. みんなCodePenつかってる？（@hiloki さん）

https://twitter.com/hiloki/status/637884127006490624

• CodePenでスライドつくってらした！すてき。

LT6. @charset（@myakura さん）

https://twitter.com/myakura/status/638404006490968064

• @charset 書いて安心してはいけない。
• エンコーディングが決まるとき@charsetの優先順位は高くない…。←知りませんでした。

LT7. パフォーマンスを発揮するためのCSS（@448jpさん）

https://twitter.com/448jp/status/637879035125633024

• パフォーマンスの改善について。個人的には今一番興味のある話題でした。
• もっと詳しくお聞きしたい。

4.background-(image|size) の深みへようこそ（@kubosho_ さん）

https://twitter.com/kubosho_/status/637924205774802945

• background-size や background-image について
• 背景レイヤーの数は background-image で指定された値の数で決まる。
• 背景レイヤーの数と、background-* プロパティに指定できる値の数の関係
• 画像の内在サイズがない場合、background-size: auto は contain になる

@kubosho_さんが冒頭でおっしゃっていたように、謎の挙動をすることがあったbackground関連のプロパティ、このお話を聞いた今の私なら攻略できる気がします。

5.position:fixed;チョットデキル（@o_ti さん）

https://twitter.com/o_ti/status/637926154876268548

• 美味しそうなTKG
• positionのバグ（仕様上未解決）について
• position: fixed のない生活
• どうしても使わなければいけない場合の対処

私は MBA 11inch を愛用しておりますが、お話（スライド）にあったように大きなモーダルウィンドウが閉じられなかったり、ヘッダーから展開されたドロップダウンメニューのリンクが隠れてしまいクリックできないことが日常的にあります。fixedはあんまりしないでほしいです。

以上でございます。

このイベントに参加して本当によかったです。

便利ツール等々はどんどん新しいものが出てくるし、流行り廃りもあるし、それに振り回されて目の回る日々を送っていましたが、このイベントに参加したことで基礎の大切さを知り、自分の基礎知識のゆるさを痛感しました。問題にぶちあたるストレスを解消する一番の近道は仕様書にあるのかもしれません。基礎大事！

「基礎に立ち返る」テーマの中級者向けイベントってナカナカないので、貴重ですね。次回を楽しみにしています。

仕様書のもくもく会とかあれば行きたいし、誰かやりませんかー！オンラインでもいいです。お願いします。

おわり

2015/10/04 追記
今更追記するのも遅すぎるのですが、この記事を公開した直後に@kubosho_さんが仕様書もくもく会のコミュニティをつくってくださいまして、一応私も主催者になりました。（言い出しっぺとして）
9/28(月)に第一回目のもくもく会を開催しましたが、なかなか盛り上がったとおもいます。楽しかったです。
https://tokyo-css-module-specs.doorkeeper.jp/