ブラウザとモジュールとバージョン管理

ブラウザはモジュールを持つか

ブラウザとモジュール

モジュール化は綺麗で管理しやすく安全なコードを生む。
モジュールは最高だ。
そして今や、ブラウザ(フロントエンド)でもモジュールは使える

モジュールは単体で動くのが主たる仕事ではない。
他のモジュールと共同して動くのだ。
そのためには、モジュールの読み込みが必要だ。

ブラウザの長きにわたる問題点は、モジュール読み込みの不在だった。
Scriptタグの連打とグローバル空間の汚染は最悪で、jsファイル内からは読み込みすら不可能だった。
しかしそれは過去のもの、全てはimportが解決した。

import

import ~~~ from “module_name”;

主要ブラウザは全て、import文に対応している.
Can I use... Support tables for HTML5, CSS3, etc

Node.jsではフラグ立てれば使える.
モジュールチーム
GitHub - nodejs/modules: Node.js Foundation Modules Team

モジュール解決

次の段階は、import対象だ。
つまり、import ~~~ from “module_name”; のmodule_nameだ。
対象のディレクトリをハードコードしたくない
つまり、module specifierの管理であり、module resolutionとそのalgorithmだ。

GitHub - domenic/package-name-maps: How to solve the web's "bare import specifier" problem

ESモジュール特有のつらみ、そこから生まれる問題と解決策

ESモジュールはブラウザで使われる。
そしてブラウザはモジュールをインターネット越しにダウンロードする。
ゆえにモジュール読み込みはとても時間がかかる。
モジュールを読み込むたびに実行していると、日が暮れてしまう。
だからESモジュールでは(commonJSとは異なり) モジュール解決とモジュール実行を非同期にしている。
そのつらみの結果、モジュール名に変数を入れられない問題が発生する。
なぜなら変数は、コードを実行しないと生まれないからだ。
変数はロードするモジュールの分岐等に有用なため、つらい。

そこで出てくるのがDynamic import、つまり実行後のモジュールimportだ。

モジュール解決の現状

webpack

resolve.alias to your webpack.config.js
How to avoid relative path hell in JavaScript / TypeScript projects – @goenning

I think babel has something like this using ‘@/thing/…’, but I don’t use babel.

It’s called modules resolving and webpack can do it too: https://webpack.js.org/configuration/resolve/. Take a look :)

参考文献

スーパークール必読参考文献

hacks.mozilla.org

Shadow DOMとcomposition

Web Componentsの一要素であるShadow DOM.
Shadow DOMを有効に利用するためには、compositionの概念がとても重要。
このcompositionについて解説してみた。

Shadow DOMとは

web標準に颯爽と現れた期待の新人 (新人ではない)
切り離されたDOM、のようなもの.
切り離されているので、CSSの影響を受けないし、アクセスもできない.
切り離されているので、独自のCSSをもつしそれは外部へ出ていかない.

compositionとは

組み立て、構成、合成のような意味の英語.
複数の個別要素をがっちゃんこして新しい機能get!なノリ

DOMにおけるcomposition

HTML/DOMでは、我々は日常的に、無意識のうちにcomposition, 組み立てをしている。
別々の機能を持つ要素を組み立ててパワーアップする、次が好例
\<ul> +　\<li> -> 番号無しリスト
\<ol> + \<li> -> 番号付きリスト
組み立ての表記法は単純で、親子関係.
HTMLはcompositionをしまくることで個別機能をサービスに組み立てている(composition)とみることができる.

Shadow DOMにおけるcomposition

切り離されたDOMは、名前空間の問題などを解決してくれる。
しかし、完全に切り離されていると不便極まりない。
そこで出てくるのがcomposition, 組み立て.
compositionの概念により、別々のDOMを組み立ててより優れた機能を得るのだ！

Shadow DOMをもつ要素を\<original-card>とする。\<original-card>はカード型の見た目を提供してくれるとする.
\<original-card>のなかにボタンを付ける、つまり\<original-card>\<button>をcompositionすれば、さらによい働きをしてくれるはず！
しかし、ShadowDOMは本体のDOM (LightDOM) と隔離されているので、単純に次のように書いてもcompositionできない…

<original-card>
  <button>push!</button>
<original-card>

そこで登場するのがslot要素。slot要素はShadow DOM内で利用する要素.
Shadow DOMを作る際に

<power-card>
  <p>私に力を分けてくれ！</p>
  <slot></slot>
</power-card>

のようにしておくと、LightDOMとcomposition可能になるのだ！
つまり、

// LightDOM
<power-card>
  <button>OK!</button>
</power-card>

と書くと、Shadow DOMとcompositionされて

<power-card>
  <p>私に力を分けてくれ！</p>
  <button>OK！</button>
<power-card>

のように働いてくれるのである！
これ便利か？と一瞬思うが、実はとても便利。
ShadowDOMはLightDOMと切り離されているので、CSSが奇麗。
そしてpower-cardは単体で機能するので簡単にライブラリ化できる。
この要素に好きな要素を一瞬でcompositionできるんですよ、これはすごい.
もし先の元気ボタンにNOをさらにつけたかったら、

// LightDOM
<power-card>
  <button>OK!</button>
  <button>NO</button>
</power-card>

と書くだけで、compositionされた後には

<power-card>
  <p>私に力を分けてくれ！</p>
  <button>OK!</button>
  <button>NO</button>
<power-card>

のようになっている。

Web Componentsの実践

依存ファイルはwcの中に。重複してもパフォーマンスに影響ないよ

Don't worry if that means including redundant ; as long as you set appropriate cache headers, these will only be fetched and loaded once
webcomponents.org - Discuss & share web components

設定の注入には属性を使う

Attributes for data in. Use attributes to pass configuration in

built-in要素と同様に動くのが大原則.
だから属性値による設定が大切.

Custom elements, like their built-in counterparts, should be configurable.
Custom Element Best Practices  |  Web Fundamentals  |  Google Developers

attribute, propertyの変更が要素の変更へ即座に反映されるよう

Aim to keep primitive data attributes and properties in sync, reflecting from property to attribute, and vice versa.
Custom Element Best Practices  |  Web Fundamentals  |  Google Developers

1つのコンポーネントに詰め込むのか
あるいはコンポーネントの連鎖で作るのか

styling

Componentsにどうやってスタイルをつけるか

link要素が相性よくない。CSSをlink要素で読み込むのがあまり望ましくない.
Style要素が基本.

外部CSSの場合、

@import url("url")

をStyle要素内で使えば良い。

Plus Ultra

効率の良いDOM更新がほかの大きなテーマ.
VDOMやlit-html系やら

template literals + innerHTML でWeb Componentsを作ってみると性能普通な今どきな書き方 (not 命令型 but 宣言型) ができる.

HTML/DOM/CSS

• コンポーネント
  • WebComponents
• DOM更新
  • VDOM (React etc)
  • lit-html系 (template element based?)
• data binding

• 記法 (命令型・宣言型)

  • 宣言型
    • lit-html
    • JSX

• Systematic Styling

  • Design system
    • Material Design

GitHubのEvent

GitHub REST API v3 の EVENT API

全部で40Events (多い…)

commit
merge
issue
pull request
とりあえずこのあたりがメインかな

4: CreateEvent
17: IssueEvent
30: PullRequestEvent
34: ReleaseEvent
35: RepositoryEvent

そうか、GitHub的にはcommitはなくて、commitがpushされてくるのか.

Twitterで最新投稿を取得する

正確には、最新投稿を埋め込む

原理を気にせず使うには、ここの指示通りで1分で終わる
Twitter Publish

仕組みとしてはEmbedded Timeline機能
タグの属性でいくつか表示設定ができる
Embedded Timelines — Twitter Developers

マイク(音声入力)でブログを書いてみた

iPhoneの音声入力でブログの記事を書いてみた

今は2時10分
これからブログを書き始める
実際に音声入力をしてみた事は以前に会って音声入力の精度が高い事はよく知っている
ただ考えながらしゃべる書きながら考えると言うのとは違う感じで喋りながら書くとどうなのか試したことがなかった
実際普段しゃべる時と同じように考えながらしゃべってるだけでまぁ何とかなってそうな気もするんだけどまぁとりあえず書いてみている
これを書き始めたきっかけはネットに同じような記事が堕ちてたから
どうもブラウザ経由で音声入力をできるものはあったみたいなんだけどもiPhoneのSafariのブラウザでは動かなかったのでこちらの?ブログにiPhoneのしりの音声入力を使って入力をしている
ここまでで2時11分

書いていて思うのは箇条書きとかをしながら書いてるからまとまったのがいきなりかけるわけで喋りながら書いてると何を次喋ろうかっていうのはあんまりピンとこない
多分もともと思ってることを頭の外に出すと言う形で音声入力使うにはさそうだけどいろいろ考えたり調べながら私りしながら使うにはちょっと厳しそう
後窯内で入力するのが意外と難しそうな感じがするね
改行できないってのもちょっと辛い
まぁ後々に整形しなきゃいけないっての考えるとそうでもないのかな
何よりもブラインドタッチはできるけどスピードが普通犬と比べるとしゃべる方がやっぱり早いね

マハ新書について マハ新書の良いところはやっぱり発信したいと思った時に発信できることだと思う
頃増(※Goroman氏) が指摘した通りある意味で同時に指摘である強い雨釣りみたいなもんで売れてるところも強いんだろうけれども
止まらずにその情熱でものを書くためにはどうしても時間をかけないと言う工夫が必要
そこで音声入力です
Twitterでも見たんだけども音声入力で書くとアウトプットの時間は明らかに短くなる
実際このブログを書いてる時もものすごい短い
後はこれをどこまで圧縮するか、お金をつけて人に売ると言う意味でどこまでクオリティーを求めるか
まぁ自分を切り売りしてるようなものだから中途半端な中途半端ではいいのか人をがっかりさせるねん
違うか自分が許せるLINEを決めてそこまでどれくらい編集をするかって言う程度問題だと思う
私としてはブログに書き散らかしているものに評価をもらってワンボックスか何かで100円位もらえると嬉しいと言う感じではあるかな

........
以上は、改行 (と一箇所だけ注釈)を除いて無修正
所要時間は約3分、テクノロジーの進歩は凄いなぁ。

私を支援してくれ！！！！

てワンボックスか何かで100円位もらえると嬉しいと言う感じではあるかな

ワンボックスちゃう、FANBOXだ！ 頑張れSiri！
というわけで、「お、良い記事だな。応援したろ」という方、Pixiv FANBOXでのご支援お待ちしてます！
もっといい記事、もっとたくさん書くよ！
www.pixiv.net

オススメの記事

ここにたどり着きそうな人が興味ありげな記事

Oculus Go開発

tarepan.hatenablog.com

脳科学とVR、私は博士の卵なので

tarepan.hatenablog.com

コトバの語源

tarepan.hatenablog.com

GmailからGoogle Calendarに予定を登録

Gmailへ決められた形式で予定のメールを送ると、Google Calendarにその予定が自動登録される.
その方法を調べてみた.

概要

仕組み

schema.orgが定める形式に則って予定をメールする。
メールはhtmlメール。JSON-LD等が形式として定められている。
Gmailサーバー側がschema.org対応しており、必要な情報を利用してGoogle Calendarを更新する。

Gmailが対応する Event Type

• Event Reservation
• Flight Reservation
• Hotel Reservation
• Restaurant Reservation

Google Calendar  |  Email Markup  |  Google Developers

Gmailから試してみたい！

ウェブのgmailから送っても駄目だよ (試したけどNG)
どうもhtmlタグを認識してくれないらしい.
Google Apps Script サーバーが簡単なのでそこでテスト用に送りましょう。

実装

まずはこれに従うことをお勧めする。
自力でやるとどはまる.
Apps Script Quickstart  |  Email Markup  |  Google Developers

google apps scriptについてよい記事
qiita.com

しかしapps scriptはES6未対応。なんてこった.

markup checker by Google
メール マークアップ テスター

注意事項

• 本人からメールしないと最初はだめだよ. どはまったよ
• LD-JSONでmarkupするところ、不要なコンマはだめだよ。はまったよ
• endDateの更新には微妙なタイムラグがあるよ。ちょっと待ってね. はまった

私を支援してくれ！！！！

「お、良い記事だな。応援したろ」という方、Pixiv FANBOXでのご支援お待ちしてます！
もっといい記事、もっとたくさん書くよ！
www.pixiv.net