https://1000ch.net/posts/Recent content in Posts on EagleLandHugoenMon, 26 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/reconnecting-expertise-and-decision-making/Mon, 26 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/reconnecting-expertise-and-decision-making/既得権益構造、ジョブ型雇用、評価経済の見直しは、しばしば別個の制度論として語られる。しかし本質的には、これらは同じ断絶を別の角度から言い換えているにすぎない。すなわち、組織において専門性と意思決定が切り離されてきたという事実である。 日本企業が長く前提としてきた「縦の関係」に基づく組織観を相対化し、マネジメントを昇進ではなく役割として捉え直すことで、専門性を横断的に統合し、目的達成へ向かう組織像を描き出す。これは警告であると同時に、現実に機能している実践を踏まえた設計論でもある。 縦の関係が専門性と意思決定を分断する 日本企業における既得権益構造は、個人の資質の問題ではない。それは、縦の関係を前提とした組織構造が長年にわたり再生産されてきた結果である。役割よりもポジション、価値創出よりも調整能力、意思決定よりも在籍年数が重視されるとき、組織は変化に耐えられなくなる。 この構造のもとでは、専門性は意思決定から切り離され、取引可能な資源として扱われる。日本に根強い個人商店的な職人像も、この前提を補強してきた。専門家は統合される存在ではなく、使われるか外注される存在として位置づけられ、組織の内部でさえ「使う側」と「使われる側」という非対称な関係が固定化する。 越境なき専門性は複雑な課題を解けない 現代の事業課題は複雑であり、単一の専門性では対処できない。にもかかわらず、専門家が自らの領域に閉じこもれば、組織は部分最適の集合体へと退行する。 必要なのは専門性の放棄ではない。近接領域へ踏み出し、他の専門性と接続する越境である。エンジニアがビジネスを理解し、デザイナーが技術的制約を把握し、コーポーレートがプロダクトの文脈を共有する。そのような行動を個人の資質に委ねるのではなく、組織構造として要請する必要がある。 意思決定を軸に再定義されるマネジメント トップダウンかボトムアップかという二項対立は、問題の本質を外している。組織の大きな方向性はトップが示すべきだが、細部の意思決定までを中央で握れば、組織は内部受託開発と化す。 重要なのは、誰が決めるかではなく、どの単位で決めるかである。品質、スピード、コストといった正当な専門的判断が衝突するとき、それらを調整するのではなく統合する役割が必要になる。その役割こそがマネジメントであり、昇進ではなく文脈依存で担われる役割である。組織は上下関係の集合ではなく、意思決定を中心とした役割のネットワークとして再定義される。 権限委譲が機能する組織の条件 権限を現場に移譲し、意思決定を積み上げる実践として、SpotifyやNetflixは示唆に富む。これらの企業に共通するのは、中央で最適解を設計することを諦め、現場で判断が行われることを前提に組織を設計している点である12。 Spotifyでは、自律的な小さなチームに明確なミッションが与えられ、達成手段は委ねられる。意思決定権と結果責任が同じ単位に置かれることで、学習と改善が高速化する3。Netflixでは、ルールを減らす代わりに高密度なコンテクストを共有し、高い期待値と責任を個々人に渡すことで、専門性を持つ人材の判断力と創造性を引き出している4。 日本企業が自律型組織でつまずく構造 これらのモデルは、日本企業でも頻繁に参照されるが、成果に結びつかない例が多い。その原因は、制度の表層だけを導入し、前提となる責任設計を変えていない点にある。 裁量は現場にあると言いながら、評価、人事、予算といった重要な権限は中央に残されたままである。加えて、日本的合意形成は意思決定の責任を拡散し、誰も決めない状態を生む。合意は理解共有の手段に過ぎず、役割に基づいて決め、その判断が検証される構造がなければ、自律は成立しない。 専門性を統合する強い要求と評価の再設計 専門性を持つ人に創造性を発揮させるには、尊重と同時に強い要求が必要である。イーロン・マスクの組織運営はその象徴的な例だ。彼は最終的な判断基準を常に物理法則や顧客価値といった一次原理に置き、専門家に対して全体理解を前提とした意思決定を求める56。 専門性は尊重されるが、閉じこもる自由は与えられない。このような統合は、評価の設計と不可分である。個人評価が専門最適化と結びついている限り、人は越境しない。成果の帰属ではなく、どのような問いを立て、どの判断を積み重ねたかという意思決定と学習に光を当てる評価へ転換して初めて、横断的な行動は合理的な選択となる。 横の関係を設計できるかが組織の分岐点となる 縦の関係を前提としたまま制度だけを導入しても、結果は変わらない。ジョブ型雇用も自律型チームも、横の関係が設計されなければ形骸化する。それらは専門性と意思決定の断絶を温存したまま、名称だけを更新する行為にすぎない。 再結合とは、単に権限を委譲することでも、専門家を集めることでもない。専門性を持つ者が、その専門性に基づいて意思決定責任を引き受ける構造を取り戻すことである。決める者が決め、その判断が検証され、学習として組織に還元される。その循環が成立して初めて、組織は目的に向かって駆動する。 横の関係とは仲良しクラブではない。共通の目的のもとで、専門性と意思決定を結び直すための緊張関係である。この再結合を設計できるかどうかが、日本企業が変わるか、同じ失敗を繰り返すかの分岐点となる。 Spotify Engineering Culture – Part 1–3, Spotify R&D Blog / YouTube ↩︎ Hastings, R. & Meyer, E., No Rules Rules: Netflix and the Culture of Reinvention, Penguin Press, 2020 ↩︎ Kniberg, H. & Ivarsson, A., Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Spotify Labs ↩︎ Netflix Culture Deck ↩︎https://1000ch.net/posts/2026/outsourcing-structure-in-software-industry/Sun, 25 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/outsourcing-structure-in-software-industry/日本のデジタル化の遅れについては、これまでも多くの論者が指摘してきた。経営層のIT理解不足、人材不足、レガシーシステム問題など、理由はいくつも挙げられている。しかし、それらは多くの場合、結果として現れている現象であって、原因そのものではない。 より本質的な問題は、日本において「ソフトウェア産業」がどのように形成されてきたのか、その歴史的・制度的経緯にある。日本では、ソフトウェアが「自らの競争力を生み出す中核産業」として育つことなく、「外部に委託して調達する業務」として定着してきた。その構造こそが、現在に至るまで日本のデジタル化を規定し続けている。 本稿では、国策としてのIT化の失敗を起点に、受託開発／SESを中心としたビジネス構造がどのように形成され、それがいかなる構造的負債を生み、最終的に既得権益として固定化されていったのかを整理する。その過程で、個人の努力や現場の善意では解消できない、制度としての問題を明らかにしたい。 国策としてのIT化と「外注モデル」の定着 日本におけるIT化は、1970年代以降、国家的課題として推進されてきた。行政、金融、製造業などを中心に、大規模な情報システムの導入が進められ、業務の効率化と標準化が目指された12。 しかし、その実装のあり方には決定的な特徴があった。多くの組織が、システム開発を自らの中核能力として育成するのではなく、外部ベンダーに委託する形を選択したのである。 背景には、終身雇用・年功序列を前提とした人事制度、技術職を長期的に育成する文化の弱さ、そしてITを経営戦略ではなく「業務インフラ」として捉える意識があった。結果として、事業会社や官公庁の内部には、システムを主体的に設計・進化させる組織能力が蓄積されなかった3。 こうして形成されたのが、「ITは外から買うもの」という前提である。この前提は、その後数十年にわたって日本の組織文化に深く埋め込まれていくことになる。 受託開発と多重構造の制度化 外注を前提としたIT化が常態化すると、次に進んだのが受託開発の分業化である。大規模案件を一社で完結させることは困難であり、元請を頂点とした多層的な下請構造が形成されていった。 この構造は、単なる業務分担ではない。リスクと責任を下流に押し出し、コストを段階的に圧縮する仕組みとして制度化されたものである。 元請は顧客との関係と契約を保持し、下請は与えられた仕様を実装する。さらにその下にはSESや派遣形態が重なり、現場は流動化していく。こうした分業は一見合理的に見えるが、全体としては「誰も全体責任を持たない構造」を生み出した。 システムの品質、拡張性、持続性よりも、契約範囲の明確化と責任回避が優先される環境では、長期的な技術的合理性は後景に退く。ここに、日本型IT産業の基礎構造が固まっていった4。 工数取引としての受託開発ビジネス この構造の中核に位置するのが、受託開発型ビジネスである。多くの場合、その収益モデルは「成果物の価値」ではなく、「投入された工数」に基づいて成立している。 単価と人月によって売上が決まるモデルでは、生産性の向上は必ずしも報われない。むしろ、効率化によって必要工数が減れば、売上も減少する。結果として、組織にとって合理的な行動は、技術力の最大化ではなく、コスト管理と工数維持に向かう。 この環境では、技術的挑戦や構造的改善は優先度が下がりやすい。安定的に案件を回し、トラブルを最小化し、予定通りに納品することが評価される。そこでは、「より良いソフトウェアを作る」よりも、「問題を起こさずに終える」ことが重視されるようになる5。 こうして、SIer組織の内部では、技術的成熟よりも、調整力や管理能力が相対的に重視される文化が形成されていった。 技術者の成長と構造的制約 このビジネス構造は、そこで働く技術者のキャリア形成にも大きな影響を与える。 多くの現場では、設計や意思決定は上流で固定され、実装は分業的に切り出される。個々の技術者がシステム全体を理解し、責任を持って改善していく余地は限られる。プロダクトの成否と自らの成果が直接結びつく機会も少ない。 こうした環境では、個人の努力によって一定のスキル向上は可能であっても、長期的に高度な設計力や事業理解を伴ったエンジニアへと成長することは難しい。問題は個人の資質ではなく、経験の蓄積経路そのものが制約されている点にある。 結果として、多くの技術者が「技術で勝負する場」ではなく、「配置と契約に依存する市場」に置かれることになる。 内製化途上の組織との本質的差異 近年、内製化を進める事業会社も増えている。そこでは、マネジメントの未熟さや制度設計の不備が表面化することも少なくない。プロダクトマネジメントの経験不足、人事評価の曖昧さ、組織運営の混乱など、課題は多い。 しかし、これらの問題は性質が異なる。それらは、組織が新たな能力を獲得する過程で生じる過渡的コストであり、学習と試行錯誤によって改善されうるものである。 一方、受託構造に組み込まれたSIer型モデルは、改善の余地が制度的に制限されている。目的設定、顧客理解、技術的意思決定が分断されている限り、根本的な進化は起こりにくい。 この差異は、日本のIT産業の将来可能性を考える上で極めて重要である。 既得権益として完成したシステム こうした構造が長年維持されてきた背景には、その「完成度の高さ」がある。 発注側は、責任を外部化できる。問題が起きても、契約関係の中で処理できる。経営層は、技術的詳細に深入りせずに済む。受注側は、安定的な需要を確保できる。大規模投資や高リスクな研究開発を行わなくても、継続的な収益が見込める。 行政や制度設計の側から見ても、このモデルは前例踏襲と親和性が高い。結果として、多くの関係者にとって「都合のよい均衡状態」が成立してきた6。 この均衡の中で不利益を被るのは、将来の競争力と人材の成長機会である。しかし、それらは短期的な指標には表れにくい。そのため、構造改革への動機は弱まり続けてきた。 構造的負債としての受託開発モデル 現在、日本が直面しているデジタル競争の課題は、こうした歴史的経緯の帰結である。AI、データ活用、プロダクト開発の高度化が求められる時代において重要なのは、技術と事業が統合された意思決定能力である。しかし、日本のIT構造は、長年にわたって分断と外注を前提として最適化されてきた。 その結果として蓄積されたのは、一時的な遅れではなく、構造的負債である7。この負債は、単なるシステム刷新や人材採用では解消できない。 求められているのは、調達モデル、組織設計、人材育成、評価制度を含めた全体的な再設計である。それは容易な改革ではない。しかし、この問題を直視しない限り、日本が「ITを使う国」から「ITで競争する国」へ転換することは難しいだろう。 構造を問い直すという出発点 SIerや受託開発そのものを否定することが本稿の目的ではない。それらは、特定の歴史的条件のもとで合理的に成立してきた産物である。問題は、その構造が時代環境の変化に適応できないまま固定化され、産業全体の進化を制約している点にある。 日本のデジタル化を本質的に前進させるためには、個別の成功事例や部分的な改善にとどまらず、この構造そのものを問い直す必要がある。その議論を避け続ける限り、「IT後進国」という評価は、今後も更新され続けることになる。 経済産業省「情報処理振興施策の歩み」 ↩︎ 総務省「電子政府・電子自治体の推進の経緯」 ↩︎ IPA（情報処理推進機構）「我が国IT産業の歴史と構造」 ↩︎ 野村総合研究所「日本型システム開発の形成過程」 ↩︎ 加藤俊彦ほか『日本のIT産業 なぜ世界から取り残されたのか』 ↩︎ OECD, Digital Economy Outlook (Japan) ↩︎ 日本銀行金融研究所「日本の決済・金融インフラの発展」 ↩︎https://1000ch.net/posts/2026/project-management-at-insourcing/Sat, 24 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/project-management-at-insourcing/近年、多くの企業において、競争環境の変化や人材不足、事業の高度化を背景として、デジタル化や内製化の重要性が語られている。その過程で、プロジェクトマネージャーやスクラムマスターといった役割の設置が進んできた。一方で、こうした役割が本来意図された機能を十分に果たしていないケースも少なくない。 組織には本質的に、現状を維持しようとする「慣性」が働く。なぜ多くの企業で内製化は「始まる」が「根付かない」のか。その背景には、制度や役割、評価の仕組みが一度定着すると容易には変わらないという構造的特性がある。この組織的慣性を前提としなければ、内製化や変革の議論は理想論に留まりやすい。 本来のプロジェクトマネジメントの役割 プロジェクトマネージャーやスクラムマスターの本来の役割は、進捗管理や調整業務そのものではない。情報の摩擦を減らし、意思決定の速度を高め、チームが最大限の成果を出せる環境を整えることに本質がある。 成熟した組織においては、事業目標と現場の判断が連動し、専門職が一定の裁量と責任を持って行動できる環境が整っている。そのため、これらの機能はエンジニアやデザイナー、プロダクトマネージャーの中に自然に内包されることも多い。その場合、専任の役割を設けなくとも、プロジェクトは円滑に進む。つまり、プロジェクトマネジメントとは「職種」ではなく「機能」であり、状況に応じて誰かが担うべきものである。 役割の形骸化と「仕事をしている感」の構造 一方で、多くの組織ではプロジェクトマネジメントの役割が形式化・固定化する。役割が本来の機能から切り離され、手続きや運用そのものが目的化することで、組織の柔軟性が失われる。その背景には、いくつかの構造的要因がある。 成果よりも「プロセス」や「調整」が評価される制度の存在は、その一例である。会議を運営し、資料を整え、関係者と合意を形成することは重要ではあるが、それ自体が目的化すると、価値創出との結びつきが弱くなる。 失敗リスクを回避する文化も、役割の形骸化を助長する。責任を分散し、意思決定を曖昧にすることで、個人がリスクを負わない構造が形成され、その結果として判断力や当事者意識が育たなくなる。 さらに、人材配置や予算配分といった短期的な最適化の積み重ねは、やがて「構造的負債」として組織に蓄積される。短期的には合理的に見える選択が、長期的には柔軟性や学習能力を奪う要因となる。 こうした構造の下では、「何かをしているように見えること」と「価値を生み出していること」が乖離する。評価制度や報告体制が活動量を可視化しやすい一方で、成果の質を測りにくい場合、人は無意識のうちに“見える努力”を優先してしまう。この乖離が常態化すると、組織全体が活動量を成果と錯覚し、改善や学習よりも現状維持を優先する。 経営のスタンスと人材育成への影響 内製化や組織変革の成否は、事業責任者層を含む経営層の姿勢と、人材育成のあり方に大きく左右される。 対立や摩擦を避け、短期的な安定を重視する経営スタンスの下では、抜本的な改革は進まない。既存の権力構造や慣行を維持する方が、短期的には安全であるためである。その結果、デジタル化や内製化は「取り組んでいる姿勢を示すための施策」になりやすく、実質的な変化にはつながらない。 こうした経営スタンスや意思決定構造の下では、人材育成のあり方にも影響が及ぶ。役割や責任が曖昧なまま業務が進むことで、個々人が自らの成長課題を認識しにくくなり、挑戦と改善のサイクルも十分に機能しにくくなる。結果として、個人の努力が組織能力の向上につながらず、中長期的な競争力の形成が難しくなる傾向がある。 建設的な方向性 まずは、役割ではなく成果を評価する制度の整備が求められる。短期的には制度変更に伴う混乱や反発も想定されるが、それを前提とした段階的な設計が不可欠である。肩書きや活動量ではなく、事業価値への貢献度を軸に評価することで、組織の関心を本質的な成果に向ける。 意思決定権限の明確化も欠かせない。責任と権限が分離している限り主体的なマネジメントは育ちにくく、判断は常に先送りされる。学習と失敗を許容する文化の構築も重要で、試行錯誤を通じて知見を蓄積し、組織全体で共有する仕組みがなければ、内製化は一過性の取り組みに終わることが多い。 また、経営と現場、事業と技術をつなぐ「翻訳レイヤー」の存在も重要である。戦略や方針を現場の行動に落とし込み、現場の知見を経営判断へと還元する循環がなければ、戦略と実装は恒常的に乖離し、分断は固定化される。 加えて、外部パートナーの活用と内製化を対立構造で捉えない視点も必要である。たとえば初期段階では外部の知見を積極的に活用し、徐々に中核部分を内製へ移行するなど、段階的な移行モデルが現実的である。外部との協働を通じて学習し、その成果を組織内部に蓄積していく姿勢が求められる。 持続的な変革に向けて プロジェクトマネジメントや内製化の問題は、個人の能力不足に還元できるものではない。だからこそ、表層的な対症療法ではなく、組織構造そのものに目を向ける必要がある。 多くの場合、評価制度、権限構造、経営姿勢といった設計上の選択が、長い時間をかけて組織の行動様式を規定する。これらを直視せずに役割や制度だけを導入しても、本質的な変化は生まれにくい。 組織として何を価値とし、誰にどのような責任と権限を与えるのかを問い直し続けることこそが、慣性や構造的負債を乗り越え、持続的な変革を実現するための出発点となる。https://1000ch.net/posts/2026/organizational-learning-at-insourcing/Fri, 23 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/organizational-learning-at-insourcing/内製化やプロダクト開発の現場では、技術や制度以上に、人と組織の在り方や意思決定構造が成果を左右する。これまで様々な組織に関わってきた経験をもとに、組織的慣性や構造的負債といった前提も踏まえながら、開発組織がどのように迷走し、学習し、成熟していくのかを一つの流れとして整理する。 目的の曖昧さが生む分断と摩擦 組織において最初に共有されるべきものは、「何のために取り組んでいるのか」という目的である。しかし多くの場合、この目的は十分に言語化されないままプロジェクトが始動する。 目的が曖昧なままでは、活動量や手続きが評価の中心となりやすく、やがて形式的な運用や「仕事をしている感」が組織に定着していく。その結果、人は自然と自らの専門領域や立場を拠り所に行動し、職種や役割が目的そのもののように扱われるようになる。 やがて、部分最適が全体最適に優先される構造が固定化される。この構造の中では、強い責任感や問題意識を持つ人ほど、厳しい指摘や主張を行うようになる。しかし、それらはしばしば感情を帯び、摩擦へと変質する。正しさと伝え方が切り離されないまま進むことで、議論は消耗戦となり、意思決定の速度は低下し、成果との接続も弱まっていく。 対話が失われていくプロセス 摩擦が常態化した環境では、人は次第に率直な発言を控えるようになる。直接対話よりも、沈黙や回避が合理的な選択となり、問題は表に出にくくなる。その結果、論点や懸念が共有されないまま意思決定が先送りされ、判断は曖昧な合意や前例踏襲に依存するようになる。 心理的安全性とは、制度や標語によって生まれるものではない。「意見を述べても排除されない」「違和感を示しても尊重される」といった経験の積み重ねによって形成されるものである。 この基盤が弱い組織では、意見の相違は建設的な議論に発展せず、自己防衛や責任分散へと回収されやすくなる。その結果、判断は個人から組織へと拡散され、誰も最終的な責任を負わない構造が形成される。やがて対話は機能不全に陥り、問題解決よりも責任回避が優先される状態が定着していく。 マネジメントと制度対応の限界 この段階で求められるのは、特定の役職や肩書きではなく、意思決定と課題解決の機能が組織内で適切に果たされているかという視点である。 対話が機能しなくなると、組織は形式や制度への依存を強める。記録や手続き、ルールが先行し、背景理解や本質的な対話が後回しにされる。 しかし、形式的対応は問題を「処理」することはできても、「解決」することはできない。当事者の意図や葛藤が置き去りにされた対応は、かえって不信感を増幅させる。また、専門性の高さがそのままマネジメント能力に転化されるわけではない。プロジェクトマネジメントとは職種ではなく機能であり、本来は組織の中で分散的に担われるべきものである。 マネジメントとは、人を管理することではなく、課題と目的を結びつける構造を設計する営みである。目的の翻訳、責任の明確化、対話の促進、学習の設計、すなわち経営と現場をつなぐ翻訳レイヤーの構築が中核となる。これらが欠けた状態で役職だけを与えても、組織は持続的に機能しない。 変化局面と組織学習の分岐点 組織には、方針転換や役割変更など、関係性が揺らぎやすい局面が必ず訪れる。その際の対応は、組織が成熟へ向かうか、停滞へ向かうかを分ける分岐点となる。こうした局面では、過去の意思決定や制度設計の積み重ねによって形成された慣性や構造的負債が、変化への抵抗として顕在化しやすい。 不安定な状況下で対話や配慮が不足すれば、当事者は疎外感を抱きやすくなる。短期的合理性を優先した対応は、これまでに蓄積された信頼や学習資産を損ない、構造的負債として組織に残り続ける。同時に、こうした局面は組織が学習する機会でもある。失敗や混乱を個人の問題に還元せず、構造として振り返り、次に活かす姿勢があれば、経験は資産へと転換される。 断罪ではなく分析を選び、責任追及ではなく進化を志向する組織だけが、慣性を乗り越え、持続的な変革と成長を実現できる。 成熟に向けた日常的実践 内製化や新規開発は、単なる技術導入ではない。それは、組織文化・対話様式・意思決定構造・制度設計を再構築する営みである。 目的を軸に据え、対話を維持し、制度や評価設計に潜む慣性や構造的負債と向き合いながら、失敗から学び続ける組織だけが、変化の中でも安定した成果を生み出す。 混乱や衝突は避けがたい副産物である。それらを排除するのではなく、分析と学習を通じて次の設計へと転換できるかどうかが、組織の成熟度を決定するのである。https://1000ch.net/posts/2026/japanese-organizational-model-transformation/Thu, 22 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/japanese-organizational-model-transformation/戦後日本は、高度経済成長とともに終身雇用を中核とする雇用モデルを築いてきた。企業は人材を長期的に抱え込み、時間をかけて育成し、個人は組織への忠誠と引き換えに安定を得る。この構造は、経済成長期においては極めて合理的であった。 このモデルの制度的基盤が、いわゆるメンバーシップ型雇用である。職務内容を厳密に定義せず、「会社の一員であること」自体を前提に採用・配置・評価を行う方式であり、新卒一括採用、定期異動、年功序列といった運用と結びついてきた。大企業に入社した総合職が数年ごとに部門をローテーションする構造は、その典型である1。 その結果、日本企業では「何ができるか」よりも「どこに属してきたか」「誰の下で働いてきたか」が評価軸として機能するようになった。上下関係と経歴に基づく統治モデルは、安定と引き換えに、専門性の形成と挑戦のインセンティブを弱めてきた。 メンバーシップ型とジョブ型の制度的断層 ソフトウェア、AI、クラウドを中心とする産業構造の変化は、日本型雇用モデルの限界を明確にした。現代の競争力は、設備投資よりも、エンジニアやデータ人材など高度専門職の生産性によって決まる。 同じ企業に在籍していても、設計や意思決定を担える人材と、定型業務にとどまる人材とでは、市場価値に大きな差が生まれる。しかしメンバーシップ型組織では、この差が制度的に可視化されにくい。その結果、高い能力を持つ人材ほど、組織内で十分に活用されない。実際、日本のIT企業では、高い技術力を持つ人材が外資系企業やスタートアップへ転出する傾向が強い23。これは個人の志向というより、能力を活かしきれない組織設計の帰結である。 これに対して、欧米企業を中心に発展してきたジョブ型雇用では、職務記述書によって責任範囲と成果基準が明確に定義される。評価は上司との関係ではなく、職務達成度を基準に行われる。GoogleやMetaでは、職種・レベルごとの評価基準が公開・共有されている45。個人は「誰に仕えるか」ではなく、「何を達成するか」によってキャリアを構築する。 国内においても、日立製作所や富士通などがジョブ型制度へ移行しつつある67。しかし多くの企業では、依然としてメンバーシップ型運用との併存が続き、制度と実態の乖離が生じている。 経歴依存型統治が生む属人化と学習不全 日本企業の人事判断は、今なお学歴、社歴、年次といった経歴情報に強く依存している。これは能力を測れないことによる消極策ではなく、組織摩擦を最小化するための統治戦略でもある。 大規模メーカーなどでは、昇進年次が暗黙に固定され、大きな逸脱は生じにくい。この仕組みは安定をもたらす一方で、成果よりも同調や関係維持を合理的行動にする8。評価設計がこの構造と結びつくことで、部下にとって最適な戦略は、成果創出よりも上司への適応となる。結果として、組織は意思決定の質よりも合意形成の容易さを優先する9。 さらに、能力や成果が体系的に可視化されない組織では、評価や配置は管理職の裁量に委ねられる。優秀な上司の下では成長できるが、そうでなければ停滞するという構造が生まれる。この仕組みでは、成功要因が組織に蓄積されない。ある部署の成果が、異動とともに失われる現象はその典型である10。組織全体としての学習速度は低下し、環境変化への対応力も弱まる。 労働市場制度と国際比較から見た転換点 欧米企業では、ジョブ型雇用を前提に、大規模な人員調整が行われる。2022年以降、GoogleやMeta、Amazonが実施したレイオフは象徴的である11。これらは、流動的な転職市場や再訓練制度と結びついている12。職務単位での再配置が可能であるからこそ、組織は環境変化に迅速に適応できる。 一方、日本では解雇規制が強く、人員調整は出向や早期退職に依存する13。この制度環境は安定をもたらすが、同時に組織変革の速度を抑制している。この違いは文化ではなく制度の差である。組織モデルは、労働市場制度と不可分なのである。 組織設計としての可視化と価値創出 能力、成果、意思決定プロセスを構造的に可視化できる組織は、人的資本を戦略資産として運用できる。プロジェクト貢献度や熟練度が体系化されていれば、配置や投資判断は高度化する1415。評価、配置、育成、報酬が連動する組織設計は、経営資源配分の精度を高め、企業価値の持続的向上に直結する16。これは単なる人事施策ではなく、経営基盤の再設計である。 評価制度、職務設計、権限配分、情報共有の仕組みは、すべて組織設計の一部である。それらは企業の将来収益構造を規定する長期投資である。経歴と従属に依存する組織は、過去を再生産する。能力と職務に基づく組織は、未来を創造する。 日本企業はいま、管理の延長線上にとどまるのか、価値創出型組織へ進化するのかという根源的選択を迫られている。 新卒一括採用に関する調査（経団連） ↩︎ LinkedIn Global Talent Trends 2022 ↩︎ IT人材白書（IPA） ↩︎ How We Hire at Google ↩︎ The Engineering Ladder at Meta ↩︎ 日立製作所 統合報告書 ↩︎ 富士通 人的資本レポート ↩︎ 持続的企業価値と人的資本（経済産業省） ↩︎ 企業統治に関する調査（内閣府） ↩︎ The Knowledge-Creating Company (HBR) ↩︎ Tech Layoffs in 2023 (Wall Street Journal) ↩︎ OECD Employment Outlook ↩︎ 労働経済白書（厚生労働省） ↩︎ ISO 30414 Human Capital Reporting ↩︎ 人的資本可視化指針（内閣官房） ↩︎ International Integrated Reporting Framework ↩︎https://1000ch.net/posts/2026/marathon-festival/Sat, 17 Jan 2026 00:00:00 +0000https://1000ch.net/posts/2026/marathon-festival/前回出場の多摩川ハーフマラソン 2025 から約9ヶ月ぶりに、マラソンフェスティバル in 昭和記念公園 2026 のハーフマラソンに会社の面々と出場し、完走した。 昭和記念公園は立川にある大きな公園で、立川駅からも歩けるが西立川駅が最寄りである。降り立ったことがなかったので立川駅から徒歩で向かったが、思った以上に距離があった。 結果は 1:58:56 で Personal Best には届かなかった。実は 10km までの調子は悪くなく、意図せず 10km の PB は出たが、12-13km あたりで脚に違和感を覚えて途中から失速した。なんとか完走したが、ラスト 5km はかなり辛かった。 人間なので時々で調子の善し悪しはあるが、繁閑はあれどランニング自体は継続していたので、今回の失速は何が決定的な要因か掴みきれていない。継続はしているが惰性的なトレーニングにはなっているので、もう少し VO2Max 向上のための工夫が必要そうである。https://1000ch.net/posts/2025/bought-in-2025/Tue, 30 Dec 2025 00:00:00 +0000https://1000ch.net/posts/2025/bought-in-2025/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの 2020年に買って良かったもの 2021年に買って良かったもの 2022年に買って良かったもの 2023年に買って良かったもの 2024年に買って良かったもの VOLTRX 電動プロテインシェーカーボトル 運動後にプロテインを飲むことが習慣になったが、牛乳とプロテインを混ぜる時に粉が溶け切らないペインがそれなりに大きかった。アナログシェーカーやグラスを使う場合は、マドラーが必要だったり丁寧に混ぜても溶け切らなかったり、これらを洗う手間も発生する。溶けやすい SAVAS ですらダマになってしまうことも多々ある。 瞬時にブレンド：強力な特許取得済みモーターと革新的なミキシングブレード設計により、わずか15秒でシルキーな滑らかなミックスが得られ、固まりやダマが残りません。ミキシングの未来を手に入れ、ダマと永遠にさよならを告げましょう！防漏れ＆簡単クリーニング：特許取得済みの防漏れ設計、取り外し可能な構造、およびBPAフリー素材により、クリーニングが簡単で最高品質と安全基準を確保。手軽にクリーンで健康的なミキシング体験を維持しましょう！少ない充電でより多くのミキシング：1回の充電で最大120回の使用が可能で、1日に2回のミキシングを1ヶ月間楽しめます！多機能なUSB-C充電ポートは、さまざまな充電デバイスと互換性があり、最終的な利便性が提供されます。ささやくような静音＆ぴったりフィット：私たちのミキサーは、従来のシェイカーボトルよりもかなり静かに設計されており、24オンスのサイズでほとんどのジムバッグにぴったりフィットし、さまざまなミキシングニーズ（最大3スクープのパウダーと450mlの液体）に対応します。フィットネスルーティンに利便性とスタイルをもたらしましょう！ そんな課題感をほぼ完璧に取り除いてくれたのがこの電動プロテインシェーカーで、材料を入れてスイッチを入れるだけでダマなく混ぜてくれる。キャップを外して直接飲むこともできるし、ミキサー部分以外は食洗機で洗えて手間もない。ミキサーは USB type-C で充電可能で、動作も静かで隙がない。この商品のおかげで、プロテインを飲む心理的な敷居がなくなった。 ちなみに最近飲んでいるプロテインは THE PROTEIN のヨーグルト味とココア味。以下の動画で、きんに君が「そもそもプロテインとは何なのか」を解説すると共に、自身が飲んでいるプロテインとして紹介している。 💪【40以上の多彩なフレーバー】あなたのお気に入りがきっと見つかる！「“選ぶ"が楽しくなる」豊富な40以上のフレーバーを展開！定番のココア・長年人気のレモンヨーグルト・マグケーキ専用のフレーバーまで！ 💪【ヨーグルト風味】ヨーグルトのまろやかさと爽やかな酸味で毎日飲みたい美味しさに！♪トレーニング前後はもちろんボディメイク中のおやつ代わりに。 💪【マルチビタミン】ビタミンC約50mgを１杯で！アスリートから日常のプロテイン摂取まで幅広くニーズに応えられる栄養設計にこだわりました 💪【おすすめの摂取タイミング】忙しい朝のごはん代わりに、栄養補給としてトレーニング後に、おやつ代わりに午後の空腹時に、睡眠前など様々なタイミングで摂取して頂けます！時短にピッタリ◎※製造ロットにより数値が前後する可能性がございます 💪【40以上の多彩なフレーバー】あなたのお気に入りがきっと見つかる！「“選ぶ"が楽しくなる」豊富な40以上のフレーバーを展開！定番のココア・長年人気のレモンヨーグルト・マグケーキ専用のフレーバーまで！ 💪【ココア風味】おやつ感覚で味わえる「まろやか」な口当たり♪トレーニング前後はもちろんボディメイク中のおやつ代わりに。 💪【マルチビタミン】ビタミンC約50mgを１杯で！アスリートから日常のプロテイン摂取まで幅広くニーズに応えられる栄養設計にこだわりました 💪【おすすめの摂取タイミング】忙しい朝のごはん代わりに、栄養補給としてトレーニング後に、おやつ代わりに午後の空腹時に、睡眠前など様々なタイミングで摂取して頂けます！時短にピッタリ◎※製造ロットにより数値が前後する可能性がございます CIO NovaWave SPOT PLUG +C 2023年に買って良かったものでも紹介している通り、Pixel 9 以前でも Peak Design の Everyday Case を使って MagSafe に対応させてきたが、遂に Pixel 10 で待望の Qi2 がサポートされた。スマートフォンだけでなく、Shokz OpenFit 2 や MacBook Pro といったデジタルデバイスを持ち運ぶことも多いので、充電器を常時携帯している。 最近は日本発の CIO を推していて、センスの良い商品が多い。そんな中、まさに欲しかったドンピシャの充電器を発売してくれた。CIO NovaWave SPOT PLUG +C は USB type-C のポートがあるのでケーブルを挿して給電できるだけでなく、Qi2 にも対応しているのでスマートフォンが MagSafe に対応していればマグネットで吸着させて充電できる。https://1000ch.net/posts/2025/western-philosophy/Mon, 29 Dec 2025 00:00:00 +0000https://1000ch.net/posts/2025/western-philosophy/哲学はソクラテスが説いた「無知の知」から始まり、中世のキリスト教神学、近代の理性の時代、そして現代の実存主義まで、主要な思想家の歩みを辿る。 単なる知識の蓄積ではなく、科学や政治が解決できない「答えのない問い」に立ち向かうための手段である。各時代の哲学者が当時の行き詰まった価値観をどう打破しようとしたのか。テクノロジーや資本主義が支配する現代社会においても、自分らしく生きるために哲学的な思考が必要である。 哲学とは 哲学の語源はギリシャ語で philein + sophia の「知を愛する」ことを意味する。それは、各時代における「当たり前の常識」を疑い、世界・社会・幸福・死といった「答えのない問い」に対して、その時代なりの最適解を導き出そうとする根源的な営みである。 1. 古代ギリシャ: 真理の追求 科学や政治の根源として哲学が誕生した。 ソクラテス (紀元前5世紀頃) 知恵者とされた人々との対話を通じて、自分が何も知らないことを自覚する 「無知の知」 を提唱した。相手の矛盾を突く問答法を用い、知識を詰め込むのではなく、自ら真理を発見させることを重視した。「単に生きるのではなく、善く生きる」意志を貫き、死刑宣告を受けても逃亡せず毒杯を仰いだ。 自己の所信を力強く表明する法廷のソクラテスを描いた『ソクラテスの弁明』．死刑の宣告を受けた後，国法を守って平静に死を迎えようとするソクラテスと，脱獄を勧める老友クリトンとの獄中の対話『クリトン』．ともにプラトン初期の作であるが，芸術的にも完璧に近い筆致をもって師ソクラテスの偉大な姿を我々に伝えている． プラトン (紀元前427-347年, ソクラテスの弟子) 世の中には様々な形や色のコップがあるが、私たちはそれらを見て共通して「これはコップだ」と判断できる。それは、私たちの頭の中に、個別のコップを超えた「コップらしきもの」という共通のイメージがあるからだ。この 個別の物事の背後にある抽象的な概念そのもの を、プラトンは「イデア」と呼んだ。 「善いこと」や「美しいこと」にも、人によって捉え方に違いがある。これらのイデアを追求することで、人間が共通して持つ真理に近づけると考えた。 ソクラテスは国家の名において処刑された．それを契機としてプラトンは，師が説きつづけた正義の徳の実現には人間の魂の在り方だけでなく，国家そのものを原理的に問わねばならぬと考えるに至る．この課題の追求の末に提示されるのが，本書の中心テーゼをなすあの哲人統治の思想に他ならなかった．プラトン対話篇中の最高峰． ソクラテスは国家の名において処刑された．それを契機としてプラトンは，師が説きつづけた正義の徳の実現には人間の魂の在り方だけでなく，国家そのものを原理的に問わねばならぬと考えるに至る．この課題の追求の末に提示されるのが，本書の中心テーゼをなすあの哲人統治の思想に他ならなかった．プラトン対話篇中の最高峰． アリストテレス (紀元前427-347年, プラトンの弟子) プラトンのアカデメイアで学び、科学・物理学・政治・自然・道徳など、極めて多岐にわたる分野を網羅的に研究したことで「万学の祖」と呼ばれ、イデアのような抽象概念よりも、現実の観察やバランス(中庸)を重視した。 彼の自然学や論理学は、中世に至るまで数千年にわたり絶対的な権威として君臨した。例えば物体の自由落下速度は、ガリレオ・ガリレイに否定されるまで信じられ続けた。 古代民主制国家の下で発展したギリシア弁論術の精華．著者は弁論術を，あらゆる場合にその問題に見合った説得手段を見つけ出す能力――と定義，師プラトンが経験による〈慣れ〉にすぎないとした従来の弁論術も，その成功の原因を観察し，方法化することによって〈技術〉として成立させ得ると主張する．明解で読みやすい新訳． 2. 中世: キリスト教の補完 キリスト教がヨーロッパを支配したこの時代、哲学は信仰を補完する役割を担った。 アウグスティヌス (354-430年) キリスト教の教理に新プラトン主義を統合した。全知全能の神がいるのになぜ悪が存在するのかという「悪の問題」に対し、神は人間に自由意志を与えたが、人間がその選択を誤ることで悪が生じると説明した。彼の思想は「神の国」と「地の国」を分ける歴史観を提示し、後世に多大な影響を与えた。 著者はキリスト教神学の集大成をなしとげた初期キリスト教会の教父。「神を賛美する」とも題されるこの書は、みずからがたどったキリスト教信仰への道のりを、隠すことなく率直に述べた稀有な自叙伝。幼年時代に学業をさぼったこと、青年期の女への執着と放縦な生活との葛藤、キケロの著作によって目をひらかれ、アンブロシウスの説教に心を動かされ、キリスト教に目覚めてマニ教から足を洗ったこと をつぶさに記し、最後には永遠の休息を神に希求して神への賛美を高らかにうたう。 著者はキリスト教神学の集大成をなしとげた初期キリスト教会の教父。「神を賛美する」とも題されるこの書は、みずからがたどったキリスト教信仰への道のりを、隠すことなく率直に述べた稀有な自叙伝。幼年時代に学業をさぼったこと、青年期の女への執着と放縦な生活との葛藤、キケロの著作によって目をひらかれ、アンブロシウスの説教に心を動かされ、キリスト教に目覚めてマニ教から足を洗ったこと をつぶさに記し、最後には永遠の休息を神に希求して神への賛美を高らかにうたう。 3. 近代: 神から「理性」へ 宗教の影響力が弱まり、科学の発達と共に、神ではなく人間の能力(理性)を信じる時代へ移行した。 ルネ・デカルト (1596-1650年) 数学者でもあったデカルトは、世の中の不確かなものをすべて排除しようと試み、「目に見えるものは幻覚かもしれない」「今生きているこの世界自体が夢かもしれない」と、疑える余地のあるものを一つずつ消去していった。すべてを疑った末に、疑っている自分自身の存在だけは確実であるという「我思う、ゆえに我あり」に到達した。数学的・分析的な手法を哲学に持ち込み、精神と身体を厳格に区別する二元論を唱えたことで、「近代哲学の父」と呼ばれる。 すべての人が真理を見いだすための方法を求めて，思索を重ねたデカルト（1596－1650）．「われ思う，ゆえにわれあり」は，その彼がいっさいの外的権威を否定して達した，思想の独立宣言である．本書で示される新しい哲学の根本原理と方法，自然の探求の展望などは，近代の礎を築くものとしてわたしたちの学問の基本的な枠組みをなしている．［新訳］ イマヌエル・カント (1724-1804年) 人間の認識能力の限界を確定しようと試みた。道徳においては、損得勘定ではなく自らの理性が命じる道徳法則に従うことこそが「自由」であると説いた。その際「汝の意志の格律が、常に普遍的な立法の原理として妥当するように行動せよ」という「定言命法」を掲げ、人間の尊厳を強調した。 世界の恒久的平和はいかにしてもたらされるべきか．カントは，常備軍の全廃・諸国家の民主化・国際連合の創設など具体的提起を行ない，さらに人類の最高善＝永遠平和の実現が決して空論にとどまらぬ根拠を明らかにして，人間ひとりひとりに平和への努力を厳粛に義務づける．あらためて熟読されるべき平和論の古典． ヘーゲル (1770-1831年) 物事は矛盾や対立(正・反)を抱えながら、それを乗り越えてより高い次元へと発展(合・止揚)するという「弁証法」を大成させた。歴史を、精神が自己実現を図りながら「自由」を拡大していくプロセスと捉え、個人を超えた社会や国家といった全体的な枠組みの中で真理を追求した。 感覚的経験という最も身近な段階から、数知れぬ弁証法的過程を経て、最高次の「絶対知」へと至るまで──。精神のこの遍歴を壮大なスケールで描き出し、哲学史上、この上なく難解かつ極めて重要な書物として、不動の地位を築いてきた『精神現象学』。我が国でも数多くの翻訳がなされてきたが、本書は、流麗ながら、かつてない平明な訳文により、ヘーゲルの晦渋な世界へと読者をやさしく誘う。同時に、主要な版すべてを照合しつつ訳出された本書は、それら四つの原典との頁対応も示し、原文を参照する一助となす。今後のヘーゲル読解に必携の画期的翻訳、文庫オリジナルでついに刊行。【※本電子書籍版には、紙書籍版本文の上欄、下欄に付した４つの原典（グロックナー版全集第二巻、ホフマイスター版、ズールカンプ版全集第三巻および大全集版〔アカデミー版〕）とのページ対応は含まれません。】 長大な遍歴のすえ、人間はいかにして「絶対知」へと到達するのか？　この書により、哲学史上、かつてない壮大な哲学体系をつくりあげたヘーゲルが、最後に出した答えとは──。平明な語り口でありながら、今後のヘーゲル研究に絶大な影響を与えるであろう緻密な新訳が、その核心を明らかにする。下巻の巻末には、『精神現象学』に数多くちりばめられた、広く知られる名言を拾いあげた「フレーズ索引」を収録。従来のはるか先へと読者の理解を導く。「精神が偉大なものとなるのは、より大きな対立からみずからへと立ちかえる場合である」。【※本電子書籍版には、紙書籍版本文の上欄、下欄に付した４つの原典（グロックナー版全集第二巻、ホフマイスター版、ズールカンプ版全集第三巻および大全集版〔アカデミー版〕）とのページ対応は含まれません。】 4. 近現代: 個人の幸福と社会 国家や宗教という大きな枠組みから、「自分にとっての幸せ」や「人間らしさ」が問われるようになった。 セーレン・キェルケゴール (1813-1855年) ヘーゲル的な抽象論に反対し、「私にとっての心理」を求める実存主義の先駆けとなった。自分を客観的に見失うことを「絶望」と呼び、これを「死に至る病」と定義した。絶望から救われるには、社会の常識ではなく、単独者として神(絶対者)に向き合うしかないと説いた。 「死に至る病とは絶望のことである」。──この鮮烈な主張を打ち出した本書は、キェルケゴールの後期著作活動の集大成として燦然と輝いている。本書は、気鋭の研究者が最新の校訂版全集に基づいてデンマーク語原典から訳出するとともに、簡にして要を得た訳注を加えた、新時代の決定版と呼ぶにふさわしい新訳である。「死に至る病」としての「絶望」が「罪」に変質するさまを見据え、その治癒を目的にして書かれた教えと救いの書。 フリードリヒ・ニーチェ (1844-1900年) 既存のキリスト教的道徳を「弱者の恨み(ルサンチマン)」として批判し、「神は死んだ」と宣言した。絶対的な価値観が崩壊したニヒリズムの時代において、運命を愛し、自ら新しい価値を創造し続ける「超人」として生きるべきだと主張した。https://1000ch.net/posts/2025/good-read/Sat, 27 Dec 2025 00:00:00 +0000https://1000ch.net/posts/2025/good-read/マネジメント［エッセンシャル版］ いわゆるプロジェクトやピープルマネジメントを想像しがちな人も多いが、そういった狭窄的な視野から抜けたそもそも論を問い直す良書。抽象度が高い故に語り口も固めだが、実例を交えながらも言及に無駄がなく、観点を持ち得る人には思考を体系化するヒントが多く詰まっている。マネジメント未経験の状態で読んだ時にどうなるかは不明だが、多層でのマネジメント経験を踏まえて読んだ時に、様々なアナロジーを感じながら同意できる内容だった。恐らく読む人のマネジメントに関する解像度次第で面白さが大きく変わる本。 変化のときこそ、基本を確認しなければならない。ドラッカー経営学の集大成を1冊に凝縮。自らの指針とすべき役割・責任・行動を示し、新しい目的意識と使命感を与える書。 ドラッカーの本は、はじめて読むドラッカーシリーズとしてイノベーターの条件・プロフェッショナルの条件・チェンジ・リーダーの条件・テクノロジストの条件があるが、マネジメント［エッセンシャル版］である程度網羅的に読める。 読書について 他二篇 (岩波文庫) 「読書そのものより、読んだ内容を自分の頭で“再構築”できるかが知の価値を決める」という点に尽きる。他人の思考を追体験するだけでは本質的な理解にはならず、異なる知識同士を結びつけ、自分の文脈で問い直して初めて“自分の知”になる。権威や引用に頼る姿勢は、理解力の放棄にすぎないという指摘も鋭く、普通の語で非凡なことを語るべきだという文体論も同じ文脈にある。読書とは本質的に「他人の頭で考える行為」であり、それを土台に自分の思考を持てるかどうかが、読書体験の真価である。 前記『付録と補遺』の中から『思索』『著作と文体』『読書について』の三篇を収録．「読者とは他人にものを考えてもらうことである．一日を多読に費す勤勉な人間は次第に自分でものを考える力を失ってゆく．」――鋭利な寸言，痛烈なアフォリズムの数々は，山なす出版物に取り囲まれた現代のわれわれにとって驚くほど新鮮である． 「読書は言ってみれば自分の頭ではなく、他人の頭で考えることである」は、読んで満足している人にとってはインパクトが大きい一文だろう。咀嚼し繋ぎ合わせて辿り着いた思考こそに価値があるという指摘は、知識から知恵への転換に他ならない。 THE COMING WAVE　AIを封じ込めよ DeepMind創業者の警告 AIと合成生物学という「汎用技術の新波」が、人類に前例のない繁栄と同じ規模のリスクを同時にもたらす。技術は拡散し安価になり、社会構造や権力バランスを一変させる。悲観を避けて楽観だけを見る「悲観論嫌悪」のほうが危険であり、アルゴリズムバイアスからバイオリスクまでをバラバラに議論している限り、波に飲まれるだけだという重い指摘。AIは人の知的単純労働だけでなく、善悪両方の力を増幅する。だからこそ、撤退ではなく「汎用革命に対する汎用コンセプト＝統合的なルールと覚悟」を持てるかどうかが、これから数十年の生存条件である。 AI、ロボット工学、合成生物学、核融合、量子コンピュータ、DNAプリンター、自律型致死兵器、人工ウイルス……。超進化する新世代テクノロジーが組み合わさることで、開発者すら想定していない未曾有の大混乱と大惨事がもたらされる。人類は分水嶺を越えようとしている。だがまだ何も準備ができていない。このまま強力なテクノロジーの「封じ込め」に失敗すれば、現在の国家は崩壊し、世界秩序は大混乱に陥る。私たちは一部の超巨大AI企業と金持ちに牛耳られた激しい格差社会で不安定な生活を強いられるのか。あるいは権威主義体制のディストピア的監視社会で暮らすのか。AlphaGoを開発したDeepMindの共同創業者で、Microsoft AIのCEOを務める著者が著した警告の書。 15 世紀半ばに発明された活版印刷、産業革命をもたらした代表的な技術革新として蒸気機関・電気・インターネットなどは、いずれも時間をかけて非可逆的に受容されてきた。AI は間違いなくその1つであり、その社会を変革するスピードは急速に速まっているだけでなく、一部の巨大 AI 企業が大多数の人間を使うといった社会構造をも変え得る力を持っている。 〔エッセンシャル版〕マイケル・ポーターの競争戦略 戦略とは「何をやらないか」を決めることであり、競争とは相手を叩き潰すことではなく、独自の価値を創り続けることである。多くの企業が陥るのは、成功事例をつまみ食いする二股で、短期的には安心感を与えるが、トレードオフを拒否する行為であり、結果として同質化と競争の収斂を招く。価値提案→バリューチェーン→トレードオフ→全体適合→継続性という連鎖で、戦略はスローガンではなく、活動全体に制約を課し、相互に噛み合わせる設計行為である。だからこそ戦略の主体は企業全体ではなく事業であり、競争優位は選択の一貫性から生まれる。 競争優位、バリューチェーン、五つの競争要因(ファイブフォース)、差別化、トレードオフ、適合性(フィット)――企業の持続的な成功に不可欠な競争戦略のアイデアを豊富な事例と最新の理論にもとづいて解説。巻末にはマイケル・ポーターとのQ&Aを収録。近年の講演で頻出する経営者からの質問に教授本人が答える。 いわゆる著名な戦略書として良い戦略、悪い戦略や戦略の要諦、少し趣向を変えれば孫子や老子などがあるが、ビジネスにおける事業戦略に絞って話せば、このマイケル・ポーターの競争戦略が最も実践的な戦略書かもしれない。https://1000ch.net/posts/2025/obsidian-sync-across-platforms/Sun, 11 May 2025 00:00:00 +0000https://1000ch.net/posts/2025/obsidian-sync-across-platforms/Obsidian のデータ同期をクロスプラットフォームで実現するには、幾つかのアプローチがある。大きく括ると、「公式で提供されている Obsidian Sync という有料の機能を使う」か、「任意の Vault を何らかの方法で端末越しに同期する」である。 自分は後者を幾つか試し、最初は Dropbox で Vault を同期していた。iOS や Android のモバイル端末ではファイルシステムの操作が制限されているが、Android であれば DropSync というアプリを使うことで、Android の任意のフォルダを Dropbox の同期対象として指定できる。これで、Android の Obsidian アプリで Vault を参照するときに任意のフォルダを作成・指定し、DropSync でそのフォルダを同期対象として指定する。あとは、PC の Obsidian でも Dropbox で同期されている Vault を参照すれば期待通りに動作する。 どのように同期されているかのイメージしやすいし、セットアップしてしまえば自動で運用されるが、Dropbox の無料プランで同期対象の端末数に制限があったり、クラウド同期系のアプリのインストール制限がある場合に問題が出てくる。 そこで、Obsidian のプラグインである obsidian-git を使った同期を紹介する。端末のファイルシステムを、Dropbox ではなく「リモートリポジトリを経由して git で同期する」というアプローチである。新たにセットアップする場合もそうでない場合も、Vault の取り扱いさえ注意すれば問題なく移行できる。移行する場合は Vault をバックアップしてから望むことをオススメする。 1. 同期する git リポジトリを作成する この git リポジトリを元に、各端末が git pull/push することで同期を実現できる。私は GitHub を日常的に使っているので GitHub でリポジトリを作成した。 ここでは https://github.com/yourname/obsidian とする。 2. 作成した git リポジトリをデスクトップ端末でクローンし、.gitignore を追加する PC の任意の場所に、作成した git リポジトリをクローンする。https://1000ch.net/posts/2025/40000min-on-dmm-eikaiwa/Sat, 03 May 2025 00:00:00 +0000https://1000ch.net/posts/2025/40000min-on-dmm-eikaiwa/オンライン英会話の学習時間が 30,000 分に到達してから丸 1 年少々が経過し、40,000 分に到達した。その間 437 日なので、400days x 25min で 10,000min になることを考えると、1ヶ月少々抜け落ちていることになる。体調不良等で数日受講できなかったことはあったが、正直1ヶ月も落とした記憶がないので、暇があったらログを辿ってみようと思う。 ここまで来ると、40,000 分という数字そのものに意味はなく、10,000 分単位でログに残してきたので今回も記録するくらいでしかない。肝心の英語力という意味でも、ある程度のレベルに達しているので、上達する感覚も薄い。しかし、きっと続けることには意義があるので今日も英会話を受ける。https://1000ch.net/posts/2025/tamagawa-half-marathon-spring/Sun, 20 Apr 2025 00:00:00 +0000https://1000ch.net/posts/2025/tamagawa-half-marathon-spring/本日開催された多摩川ハーフマラソンのハーフマラソン部門に参加し、完走した。2024 年末の頭に参加した多摩川ハーフマラソンに引き続き、ハーフマラソンレースへの出場は連続で多摩川沿いになった。 事前の天気予報では気温が 25 度前後で雨予測だったが、当日はそこまで暖かくならず、曇りで持ち堪えてくれた。唯一風が風速 5m で往復コースのうち往路が向かい風だったが、全体としては走りやすいコンディションだった。 前回のハーフマラソンは 1:54:17 で 5:25 /km のペースだったので、自身のレベルからするとこれ以上の記録は難しい予感がしていたが、今回は 1:51:44 でペースが 5:17 /km と予想外の記録更新となった。VO2max の値は前回のレース時点と変化しておらず、集中的なトレーニングを行っていたわけでもなかったが、継続が結実した形だろうか。 今回の多摩川ハーフマラソンは狙っていたレースというわけではなかったが、顧問先の仲間と偶々ランニングの話になり、その流れで出場することになった。1人はレースに初出場、もう1人も自己記録を更新ということで、何某かを持ち帰る良い機会になった。https://1000ch.net/posts/2025/key-points-of-web-dev/Sat, 05 Apr 2025 00:00:00 +0000https://1000ch.net/posts/2025/key-points-of-web-dev/ここで言う望ましさ 先進的で安定した技術を用い、実行環境を問わない動作 型安全かつ高速で、簡略化されたビルド 合理的に厳しく運用保守コストの少ない Lint と Format ESM による実装と実行環境による最適化 JavaScript の言語標準のモジュールシステムである ESM を前提とすることで、Node.js やブラウザといったランタイムレベルで将来的な最適化を期待できる。ESM かどうかを意識するのは、ビルドツールとしての Node.js だけでなく、実行環境としての Node.js やブラウザでもある。 Node.js であれば package.json の type プロパティに module を指定し、ブラウザであれば <script type=module> で指定することでモジュールシステムに ESM を用いることを宣言する。npm パッケージとして配布する場合は、main プロパティなどを考慮する必要があるが、詳しくはこちらの資料を参考にして欲しい。 あくまで要点は JavaScript ネイティブのモジュールシステムに倣うことであり、実装においては module.exports や require() といった旧来の CommonJS ではなく、import / export や import() を用いる ESM を使う。これをベースにしているバンドラーが、Vite に内包される Rolldown であり、遡れば Rollup だろう。 ここでの ESM は実装時点のコードベースを焦点としており、実行時を含まない。つまり、実行する JavaScript ファイルが依存関係に基づいて結合されているべきか等については論点に含まない。Web ページのパフォーマンスの重要要素にネットワーク処理があるが、HTTP/1.1 が主流だった頃はリクエスト数がボトルネックだったため JavaScript ファイルを結合するといったプラクティスがあった。しかし、HTTP/2 が普及し HTTP/3 も広がり、Web ページの性質も多様化する昨今でベストプラクティスも変化している。 最終的にはバンドルなどの中間処理を介さず、モジュール同士が ESM で連携する基本的な構造を前提とした仕様の議論が行われていることを踏まえ、状況に応じた技術や設計を選択していく。https://1000ch.net/posts/2025/customizable-select/Wed, 26 Mar 2025 00:00:00 +0000https://1000ch.net/posts/2025/customizable-select/昨今の Web で「複数の選択肢から1つを選ぶ」というインターフェースは多用されているが、Web の黎明期から存在する <select> 要素と <option> 要素に柔軟性がない故に、Web 開発者は自前の実装を要求され続けており、そのカスタマイズ性は長らく課題視されてきた。様々な「Web 黎明期に誕生したが今日の Web の要求に合致しない仕様」があったが、中でも <select> 要素と <option> 要素は代表格だろう。 Extensible Web の流れも受けて、開発者が再利用可能な Web の部品を作れるようにはじまった技術が Web Components であり、より現在の Web 需要に即した UI を検討するワーキンググループが W3C の Open UI である。これは TechFeed Experts Night#26 の 2023 年の Web 開発のベースライン でも触れている。 より柔軟な <select> 要素のアイデアは、ネイティブの <selectmenu> 要素にはじまり、<selectlist> 要素に名前が変更された後に Customizable Select Element に着地し、ついにその実装が Chrome では 135 から有効化されることになった。Chromium をベースにしているブラウザ郡は間もなくサポートされ、Mozilla と Apple も簡潔な仕様になったことで支持するようだ12。 最新の仕様は Updates to the customizable select API で詳しく解説されているが、自分用の覚書として以下に残す。 <select> 要素のカスタマイズ方法 ブラウザで UI として表示される <select> 要素および、クリック時に表示される ::picker(select) 擬似要素に、 appearance: base-select; を付与することで、ブラウザがカスタマイズする <select> 要素であることを認識する。https://1000ch.net/posts/2025/what-i-quit-to-enrich-my-life/Wed, 05 Mar 2025 00:00:00 +0000https://1000ch.net/posts/2025/what-i-quit-to-enrich-my-life/惰性的な飲酒 新型コロナウイルスの世界的な流行で、仮想的なコミュニケーションを余儀なくされた。その結果として飲み会が著しく減った。なんとなく晩酌して日々を過ごしていたが、これをきっかけに酒を飲む意味を思い直し、飲まないことを試してみたところ「飲まなくても問題ない」ことを悟り、以来ほとんど酒を飲まなくなった。 アルコールが肝臓に与える負荷が大きいのはもちろんのこと、アルコールの摂取量と肝臓の分解能力に応じて睡眠の質や次の日のパフォーマンスにも影響する。自ずと油分や塩分を摂る機会が少なくなるので体重が減り、一番の収穫として二日酔いに悩まされなくなった。 人間関係の惰性的な維持 知人に限らず親族を含めて、自分に悪影響を及ぼす人間関係を惰性で維持しない。人間関係は自分とその人の相互的な振る舞いで変化するので、その努力を全くしないことを直接意味するわけではない。しかし、人生という限られた時間の中でどこまで調整すべきかという ROI を踏まえた線引は存在する。 義務教育で学ぶことの1つに社会性がある。家族という輪だけに属していた生活とは打って変わって、学校という環境で大勢の他人と協生するのかを学ぶことになる。この「我慢できる範囲」は様々な経験を通じて培った価値観に依存するが、価値観が強固になるほど感じる摩擦は大きくなる。 経済活動の我慢 欲しいモノやコトを買うときの我慢が減った。もちろん必要性を吟味するし乱雑に使うという意味ではいが、迷ったときに「買う」に倒すことが多くなった。昔と比べて経済的な余裕があると同時に、人生の残り時間は減り続けている現実を受けた価値観の変化である。 誰かが「一度欲しいと思ったモノは、ずっと欲しい」という至言を残しているが、これは大半の場合に該当する実感がある。また「やらない後悔より、やった後悔」という言葉もあるように、経済活動による充足感は積極的に挑戦する。共有経済の現代では、後悔するリスクも小さくしやすい。 他者を価値基準にした行動 嫌われる勇気で繰り返し言及されている重要な点で、他者からの評価を軸に生きることは、他者との比較を生む。典型的な例が承認欲求で、SNS は承認欲求を増幅する装置であり、それをビジネスにしている会社の葛藤を描いているのが監視資本主義だ。https://1000ch.net/posts/2024/good-read/Mon, 23 Dec 2024 00:00:00 +0000https://1000ch.net/posts/2024/good-read/2024 年は 52 冊の本を読んだらしい。今年は TechTrain でインタビューをしていただく機会があり、そこでも偶々読んだ本の話をした。 🆕キャリアを考える時に読んで欲しい本 📚 前回、キャリアへの向き合い方を語ってくれた @1000ch さんが若手エンジニアにおすすめしたい書籍たち。 キャリアについて悩んでいるとき、"視野を広げたい"と思ったときに読んでほしい記事🧙‍♀️ ▼ 今すぐ読むhttps://t.co/yrC3xRNOBi — TechTrain 公式 (@TechBowl1) October 16, 2024 異なる様々な業態の会社での組織造りを含めたモノづくりへのコミットを通じて、自分なりの理想形を考えてきた。そしてそれは、いわゆる「開発組織マネジメントの本」に限らず、社会・人文といった広い分野の本を読む中でアナロジーを感じる場面も多い。 NETFLIX の最強人事戦略 性悪ではなく性善への徹底的なフォーカスで、従業員のモチベーションを最大限に引き出す。管理手法やインセンティブといった表層的な従属ではなく、ミッションを共有しタスクではなくイシューに向き合う優秀な人材を集めることに尽きる。 DVDの郵送レンタルから、映画のストリーミング配信、独自コンテンツ製作へと業態を進化させながら驚異的な成長を続けるNETFLIX。その成功の秘密は、型破りな人事制度に支えられたカルチャーにある。「業界最高水準の給料」「将来の業務にふさわしくない人は解雇」「有給休暇は廃止」等、同社の元最高人事責任者が刺激的な戦略の精髄を示す。「シリコンバレー史上、最も重要な文書」と呼ばれたNETFLIX CULTURE DECKを元に書籍化！ どんな文化でも抜本的に変えようとするときは、単に理念や業務方針を示すだけでは不十分であり。まず従業員に一貫してとってほしい行動をはっきりと打ち出し、続いてそれを実行するための規律を定着させる必要がある 優れたチームとは、これからどこに向かおうとしているかをメンバー全員が知っていて、どんなことをしてでもそこに到達しようとするチームのことだ。優れたチームをつくるのは、インセンティブや管理手法や従業員特典などではない。必要なのは、一人前の大人として挑戦に立ち向かうことを切望する有能な人材を採用し、その挑戦が何なのかを、彼らにはっきりと継続的に伝えること 「有機的に」とは、会社の目標や、時間と資源の配分方法、集中してとりくむ問題、それらを解決する手法を、事業や顧客の必要に合わせてたえず変化させているということ。そうした企業は成長し、変化し続ける有機体であって、あらかじめ決められた目標、人員、予算に縛られた、硬直的な組織ではない 会社は家族ではなくスポーツチームであり、キャリアマネジメントの責任はない。一番やってはいけない間違いのひとつは、重要ではない評価指標に固執すること、その好例が従業員定着率。人事の仕事は、従業員の満足度を図ることではなく、その実際は解雇することなのだ。採用チームも事業構築の重要な貢献者として「事業にとって何が重要か」を理解しなくてはならない 日本の難点 いつも通り宮台さんの書籍は読み解くことに苦労する。この書籍の初版が 2009 年ということ、そして 2024 年末においても社会構造の課題が変化していないことへの衝撃が大きい。 現代とは「社会の底が抜けた時代」である。相対主義の時代が終わり、すべての境界線があやふやで恣意的な時代となっている。そのデタラメさを自覚した上で、なぜ社会と現実へコミットメント(深い関わり)していかなければならないのか。本書は、最先端の人文知の成果を総動員して、生きていくのに必要な「評価の物差し」を指し示すべく、「現状→背景→処方箋」の3段ステップで完全解説した「宮台版・日本の論点」である。 尊厳と他者性が結びついているか。つまり、自分が自分であることを支えるために他者が関与しているか。旧来は、血縁関係や地元といった「近さ」という事実性が重要な意味を持っていたが、人口の増大と流動性の確保によってコミュニケーションが希薄化した。マスメディアの退潮も分化した趣味を共有できる空間がインターネットに無数に発達したため、共通の前提を与えられなくなった 社会学者のニクラス・ルーマンは「おかしなことは何も起こりません」という期待を「慣れ親しみ（安心）」と呼び、「いろいろあっても大丈夫です」という期待を「信頼」と呼んだ。「安心」は脆弱だが「信頼」は強靱であり、対面コミュニケーションを「信頼」ベースにするべき 戦後の高度経済成長期を支えた、終身雇用や年功序列という慣習は組織における既得権益を生み出し、現在における社会の望むべき変化の強い抑止力になっている。正規雇用の過度な保護は雇用の流動性を失わせ、労働者から挑戦し変化する意欲を奪い、産業構造の代替を促さない。非正規雇用と正規雇用の垣根を低くし、企業には解雇の事由を与え、働けなくなった事態には、社会保険を含むセーフティネットを用意する 社会契約論 当たり前に存在している社会や国家を、人類がどのように形成しているのか。国家・主権者・自由意志・一般意志といった非常に抽象度の高い言葉で、社会契約の本質的な条件を整理している。1762 年の発行であり、その抽象度故に難解だが、読んだ後には世の中が違って見えてくる。 本書は「Du Contrat Social ou Principes du droit politique」（ジャン・ジャック・ルソー著、一七六二年発行）の日本語訳である「民約論」（ジャン・ジャック・ルソー著、平林初之輔訳、岩波書店、一九五〇年九月三十日第十八刷）を底本として旧字体を新字体へ改める等の編集を独自に加えたものです。 子供と親の絆は、子供の生命を維持できるかどうかという問に尽き、自立可能になった瞬間から子供は親への服従義務はなくなり、親は子供の養育義務から解き放たれる。人は生まれながらに自由であり、子供を売り渡す権利を親は持たない。自由の放棄は人間としての権利や義務を放棄することだ 人類は自然のまま生きることが難しくなってきた故に、それを凌駕する力を得ようとした。しかし力を生み出せないため、力を合わせて統制しようとする。力を合わせるのだが、個々の自由は力は個々保存に使われる道具である以上、自己に対する注意を削ぐことなく他の用途に充てなくてはならない この社会契約で引き換えになるのは、自由意志やすべてのものに対する無制限の権利であり、獲得できるものは社会的自由と所有物に対する一切の権利である。さらに道徳的自由が付加されて、人間が社会的に人間たる。社会契約は、生まれながらに存在する肉体的不平等の代わりに、精神的平等と合法的平等を齎すhttps://1000ch.net/posts/2024/bought-in-2024/Thu, 12 Dec 2024 00:00:00 +0000https://1000ch.net/posts/2024/bought-in-2024/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの 2020年に買って良かったもの 2021年に買って良かったもの 2022年に買って良かったもの 2023年に買って良かったもの COROS PACE 3 と Shokz OpenFit Air 遂に COROS PACE 3 を買った。COROS PACE 2 の機能性に不満があったわけではないが、最新モデルを使っているという安心感は替え難い。ちなみに、更に新しい COROS PACE Pro というモデルも発売されている。 ランニングやトライアスロンなどスピードを求める方向け。一日中装着し続けてもストレスがない軽量性。充電の心配がないロングバッテリー。常時点灯の1.2インチ透過型タッチスクリーンディスプレイ。2周波GPS、次世代光学式心拍、高度計で正確なデータ提供。ルートナビゲーション、音楽機能を搭載。ウォッチバンドと充電ケーブルが付属 COROS PACE 3 はランニング時に活躍しているが、ランニングのお供としてオープンイヤー型のイヤホンは欠かせない。走っている間に読書するわけにもいかないので聴覚を活用したいわけだが、今までは2022年に購入した Aeropex を使っていた。今年は同じく Shokz の OpenFit Air を購入した。 耳の穴をふさがず、聞き疲れや蒸れを感じず、ソフトなシリコンで仕上げたイヤーフックが、イヤホンをぴったりと固定します。わずか8.7gの軽量デザインにより、長時間のリスニングでも圧迫感を最小限に抑え、メガネをかけたままでも、快適な装着感をお楽しみいただけます。 左右分離という点はさておき、ケースに収めれば非常にコンパクトでありケース自体を充電しておけるので、電源がなくとも充電できる。また、ケースの接続が USB-C であることは非常にありがたい。COROS 製品も見習って、USB-C 接続に揃えて欲しいと切に願う。 SHURE MV7+ と AudioTechnica のマイクアーム SHURE 製品の良さは知っていたが、よりポータブルに使えるダイナミックマイクで探していたところ、MV7 を見つける。しかし、接続が microUSB であったため長らく二の足を踏んでいた。そして、ついに後継として USB type-C バージョンとなる MV7+ が発売されたので、即座に購入した。 MV7+はカスタマイズ可能なLEDタッチパネル、強力なDSP機能、より上質な音声を備え生まれ変わった、音にこだわるストリーマー、ポッドキャスター、ミュージシャンのためのダイナミック型マイクロホンです。この新しいマイクロホンは、USB-CおよびXLR出力、強化されたオートレベルモード、デジタルポップフィルター、リアルタイム・デノイザーおよびリバーブ効果を備えています。タッチ式ミュートLEDパネルは多彩なカラーオプションが用意されていて、収音する音声と同様に独自性を持たせることができます。 Audio Technica のマイクアームも併せて購入し、音声周りの機材は充実してきた。もっと廉価なマイクアームも発売されているが、さすがは Audio Technica といったところで、高い機能性かつ安っぽさがない。 耐荷重 : 2kg / 可動距離 : 680mm / テーブルクランプ最大開口 : 50mm 取り付けねじ寸法 : 5/8インチねじ 回転角度 : アーム取付部：360°マイクロホン取付部：270° 上部アーム部：180°、下部アーム部：135° 外形寸法 : 430mm×398mm / 質量 : 本体：1030g、テーブルクランプ：172g Apple Studio Display 友人から譲り受けた LG UltraFine 5K Display 27インチ を満足して使っていたが、その友人とランチをしていた時に「後継機に Apple Studio Display を買った」と唆されて、購入することになった。https://1000ch.net/posts/2024/tamagawa-half-marathon/Sun, 01 Dec 2024 00:00:00 +0000https://1000ch.net/posts/2024/tamagawa-half-marathon/本日開催された多摩川ハーフマラソンのハーフマラソン部門に参加し、完走した。BOOST RUNNNING の主催するイベントに参加するのは、今年の頭に参加した荒川ハーフマラソン以来だ。 前回のハーフマラソンでは 17km 付近で膝を痛めて失速しタイムは 2:05:15 だった。今回はそういったアクシデントもなく気候も良好な中で気持ちよく走ることが出来て、前回を上回るタイムで完走できた。 明朗でテキパキとした進行、充分数の給水地点、ペーサーや医療班の皆さんのサポート、走行記録のデジタル配信など、前回に引き続き満足度は高い。しかし今回は唯一、多摩川沿いの諏訪いこいの広場に設営されていたトイレが維持管理されておらず辛いものがあった。行政側なのか大会側なのか不明だが、公衆のトイレを頼りにしないくらいの割り切りが必要かもしれない。https://1000ch.net/posts/2024/google-account-url/Wed, 23 Oct 2024 00:00:00 +0000https://1000ch.net/posts/2024/google-account-url/複数の Google アカウントでログインして各種サービスを利用していると、デフォルトアカウントは https://www.google.com/?authuser=0 となり、他の Google アカウントであれば https://www.google.com/?authuser=1 のように、ログインした順序に応じて採番される。 採番は Google グローバルつまりサービスをまたいで共通で、有効な URL も基本的に同じである。例えば Google に [account-name]@gmail.com でログインしている場合は、Gmail だと default: https://mail.google.com/mail/u/0/ https://mail.google.com/mail/u/[account-name]@gmail.com https://mail.google.com/mail/?authuser=0 https://mail.google.com/mail/?authuser=[account-name]@gmail.com であり、或いは Google Search だと default: https://www.google.com/?authuser=0 https://www.google.com/?authuser=[account-name]@gmail.com で、はたまた Google Drive だと default: https://drive.google.com/drive/u/0/home https://drive.google.com/drive/u/[account-name]@gmail.com https://drive.google.com/drive/?authuser=0 https://drive.google.com/drive/?authuser=[account-name]@gmail.com のようになっている。 デフォルトの URL は（恐らく短さを優先して）採番された番号ベースだが、その採番に紐づく Google アカウントが何かを覚えておくことは難しい。ログインし直しなどで採番が変わることも多々あり、ブックマークなどは機能しなくなる。そこで役立つのが ?authuser=[account-name]@gmail.com のようにクエリ文字列を利用するパターンである。 複数の Google アカウントの管理には、Shift という macOS アプリを使っているが、これでカバーできずに URL ブックマークを使う場合は ?authuser=[account-name]@gmail.com を使うと良いかもしれない。https://1000ch.net/posts/2024/how-to-improve-engineering-productivity/Sun, 20 Oct 2024 00:00:00 +0000https://1000ch.net/posts/2024/how-to-improve-engineering-productivity/来たる 2024 年 10 月 26 日に発売される「エンジニアチームの生産性の高め方」を恵贈いただいた。yoichiro さんが Bluesky で告知していたのを見かけた数日後に、kwakasa さんから「執筆に参加したので送ります」という旨の連絡をいただいた。 昨今の Web 業界で生産性は注目されているトピックである（ちなみに何故ここまで注目されているのか、前後の文脈はわかっていない）。図らずも去年、Findy の主催する開発生産性に関するカンファレンスに登壇し「一人ひとりが動機を持ってイシューに向き合うための、組織における相互期待値」といった旨を話した。 Google が Four Keys を示してから久しく、監修として関わった Web フロントエンド版 DX Criteria でも、生産性というキーワードは散りばめられている。あるいは Developer Productivity に関するポジションや組織も数多く見かける。ソフトウェアプロダクトを生業とする組織にとって、生産性への関心が高まっているのは間違いなさそうだ。 本書は、そんな「生産性」を開発プロセス（プロダクト要求・デザインドキュメント・ブランチとリリース・リアーキテクトにおけるテスト）と開発チーム（組織づくり・エンジニアリングイネーブルメント・開発基盤の改善）に分類し、体系的に解説している。 複数人でトピックごとに執筆している書籍ということで論旨の一貫性が気になっていたが、通して読んでもトピック同士が補完し合ってまとまっているのは、エンジニアリングに対する理想が著者間でズレていなかったこと、そして全体をまとめ上げた編集技術の賜物である。もちろん、章毎の独立性もあるため関心のあるトピックを読むだけでも理解を整理できる。認識している課題に近い章から、徐々に読み進めることも可能だろう1。 「エンジニアチームの生産性」という枕詞だが、全体として「課題解決と価値提供」を目的としたものであるという軸がブレておらず、そのためにプロダクトドメインの理解や目的を共にする仲間との協調が様々なところで言及されているのが印象的である。つまり How to ではなく Why を示し続けている。 印象的だった部分を幾つかピックアップすると、 Product Requirements Document, Marketing Requirements Document などを通じて、何を (What) なぜ (Why) 開発するのか、という原点に立ち返っている。これによって、エンジニアに限らずコミットする全ての人の認識を統一させる 普段は目の前の業務に気を取られるが、上記に加えて Design Doc やイネーブルメント・開発基盤の改善といった、ソフトウェアの実装開発そのものではない事項への投資が中長期的な能力や成果の向上に結びつくことを強調している ボトムアップな取り組みからトップダウンの意思決定に向けた意見の凝集、SPOF を作らないためのチーム構成、組織と枝分かれしたチームの目標を繋げるフレームワークとしての OKR、横軸の専門チームもプロダクトコードに触れるなど、他者と働く自覚や目標の構造と解像度の重要性が示唆されている 組織の誰か1人が本書を取って学び試行錯誤する以上に、この体系化された知識をエンジニアチームで学んで想いを共有することが、持続的に向き合う上で重要なのだろう。 ソフトウェア開発の世界では、生産性の向上は永遠のテーマです。ユーザーニーズの変遷や技術の進歩など、環境が変化し続ける中でいかにして効率的に開発を継続していくかは、多くのソフトウェア開発チームにとって切実な問題です。本書は、そのような問題に対する解決のヒントを提供することを目指しています。 しかし、本書が提供するのは汎用的な解決策や、普遍的な理論ではありません。各章に記されているのは、それぞれの著者が、自身の経験と専門性をもとに導き出した、生産性を向上させるための具体的かつ実践的な自説です。生産性を向上させるための網羅的な解説書というわけではなく、むしろ多角的な視点からの提案と捉えてください。 本書の読書ログは scrapbox にある ↩︎https://1000ch.net/posts/2024/hhkb-studio/Sat, 21 Sep 2024 00:00:00 +0000https://1000ch.net/posts/2024/hhkb-studio/購入してから半年ほどが経過し、使い心地も慣れてきた。 Mac mini を LG 4K モニターに接続してリビングで使用しており、以前までは Magic Keyboard と Magic Trackpad を使っていたが、テーブルの上に機器が 2 つあることの取り回しの悪さを感じていた。そんな中でキーボードとポインタが一体化した機器を探していると、タイミング良く HHKB Studio が発売されたので購入した。 初めての HHKB だったが、気になっていたタイピング感も次第に慣れて心地良くなってきた。ポインティングスティックは「とても良い」とまではなっていないものの「充分に使える」という感じで、それよりは キーボードとポインタが一体化しており Bluetooth による接続で気軽に持ち運んで使用できる 便益の方が大きい。 Bluetooth だけでなく USB-C による接続および給電にも対応しているが、知人から「HHKB は内蔵バッテリーを傷めないように、電池が使えるようになっている」というコンセプトを教えてもらったこともあり、乾電池で運用している。墨色で刻印された US 配列のキートップもオシャレで良い。 4つのジェスチャーパッド搭載。指先ひとつでボリューム操作などのアナログ量調整や、ウィンドウ切り替えができます。機能はカスタマイズ可能で、よく使うアプリのコマンドを割り当ててることもできます。 キーボード中央にポインティングスティック、スペースキーの下に3つのマウスボタンを配置。マウス機能が統合されているため、タッチパッドやマウスは不要です。どこでも没入して快適なタイピングが可能です。 キーおよびジェスチャーパッドのキーマップ設定はHHKB本体に保存されるので、接続デバイスを替えても、ご自分のキーマップをお使いいただけます。キーマップのプロファイルは4つまで作成可能。DIPスイッチでカスタムキーの動作や省電力設定を設定できます。 PCとのUSB(Type-C)接続のほか、PC、タブレット、スマートフォン(iPad、iPhone、Android)へのBluetooth接続をサポート。最大4つまでのマルチペアリングが可能なので、接続するデバイスをすばやく切り替えられます。 60キー(英語配列)のコンパクトな設計は、最小限の指の動きで最大限の効率を実現します。リニアタイプの静音メカニカルスイッチによってノイズが軽減され、深い集中を可能にします。キーボード本体はホットスワップ方式を採用。ユーザーご自身でお好みのキースイッチに変更いただけます。https://1000ch.net/posts/2024/99points-at-asset-management/Thu, 12 Sep 2024 00:00:00 +0000https://1000ch.net/posts/2024/99points-at-asset-management/「資産運用を始めたいが、何をすれば良いかわからない」 「iDeCo や NISA がどんな制度かわからない」 「どんな金融商品を買うべきか、買わないべきか」 戦時の国策の名残か、タンスや銀行預金を良しとされてきた日本では「投資」に関するリテラシーが高くない現状があり、このような疑問を持つ「普通の人」が大多数である。普通の人が資産運用で99点をとる方法とその考え方は、そうした人達にとって衝撃的だったこともあり、2020年「はてなブックマーク年間ランキング」トップになった。「これだけやっておけば、資産運用は OK」という類の記事や書籍は数多あるが、この記事ほど端的で論理的にまとまったものは見たことがない。 岸田政権でも NISA がアップグレードされて、投資に対する国民的感情が高まったことも受けてか、「普通の人が資産運用で99点をとる方法とその考え方」が書籍化されるというニュースが飛び込んできた。 投資初心者、運用成績が上がらないあなたへ･･･ 「やるべきこと」は1年に30分で完結、最高のリターンを得られる方法とは ・「99点をとる方法」は誰もが実践できる。年齢や資産額は一切問わない！ ・iDeCo、NISA、特定口座での投資、何がいちばんお得？ ・“勉強” すればするほど、投資の成績が落ちるのはなぜ？ 総論自体はオリジナルの記事で述べていることは変わらないものの、全面的に書き下ろされており、示されている方針の理論をしっかり理解するために必要な論拠が示されている。第1部「結論編」を信じて実践するだけでも 99 点は取れてしまうが、第2部「理論編」と第3部「Q&A編」を通じて金融リテラシーを高めておくことも同じかそれ以上に重要なのは言うまでもない。分量も 148 ページとコンパクトで読みやすく、¥1,760 で 99 点の資産運用の知見を享受できると考えれば、非常に得だろう。https://1000ch.net/posts/2024/individual-psychology/Sun, 18 Aug 2024 00:00:00 +0000https://1000ch.net/posts/2024/individual-psychology/アドラーの教えを示す 2 冊を読み、感銘を受けたのでそれをメモがてら示す。「嫌われる勇気」「幸せになる勇気」というキャッチーなタイトルは、「嫌われても大丈夫だから勇気を持とう」という勘違いをしてしまいそうだが、当然ながらそんなに短絡的な書籍ではなかった。 過去のトラウマや経験に囚われるのではなく、現在の目的に焦点を当てることで自己を変えることができる。過去の経験にどのような意味を付けるかが、自己を決定する要素 であり、トラウマというものは存在しない。人は現状に留まろうとするために、怒りや劣等感などの感情を、変わらないことを正当化するための手段として無意識に捏造する。人生は他者との競争ではなく、自分自身の理想に向かって進むべきものであり、劣等感は他者との比較からではなく、自分の理想との比較から生まれるべきだ。対人関係の悩みがすべての悩みの根源 であり、他者の課題に干渉せず、自分の課題にも他者を介入させない「課題の分離」が重要である。 世界的にはフロイト、ユングと並ぶ心理学界の三大巨匠とされながら、日本国内では無名に近い存在のアルフレッド・アドラー。「トラウマ」の存在を否定したうえで、「人間の悩みは、すべて対人関係の悩みである」と断言し、対人関係を改善していくための具体的な方策を提示していくアドラー心理学は、現代の日本にこそ必要な思想だと思われます。本書では平易かつドラマチックにアドラーの教えを伝えるため、哲学者と青年の対話篇形式によってその思想を解き明かしていきます。著者は日本におけるアドラー心理学の第一人者（日本アドラー心理学会顧問）で、アドラーの著作も多数翻訳している岸見一郎氏と、臨場感あふれるインタビュー原稿を得意とするライターの古賀史健氏。対人関係に悩み、人生に悩むすべての人に贈る、「まったくあたらしい古典」です。 人生を「どう生きるべきか」という問いに対して、宗教や哲学と同様に「共同体感覚」の概念が重要である。共同体感覚とは、他者の関心事に関心を寄せ、共感を通じて社会に貢献することで得られる ものである。教育において、褒めることや叱ることが他者との比較や競争を生み出し、承認欲求や依存心の要因となり、自立を妨げる。自立とは、自らの価値を他者ではなく自分で決定できるようになることであり、教育の目的は子供をそこに導くことにある。教育者は尊敬と共感を持って子供たちと接し、彼らの自立を支援することが求められる。 前作『嫌われる勇気』でアドラーの教えを知り、新たな生き方を決意した青年。その彼が3年ぶりに哲人のもとを訪れる。アドラーの教えを実践すべく図書館司書を辞めて教師となった彼が語る衝撃の告白。それは「アドラーを捨てるべきか否か」という苦悩だった。アドラー心理学など、教育現場でも現実社会でも通用しない机上の空論だとする彼に、「あなたはアドラーを誤解している」と哲人は語る。哲人と青年の対話は、教育論に始まり、仕事論、組織論、社会論、人生論へと及び、最後には「真の自立」と「愛」というテーマが浮かび上がる。そして、最後に哲人が説くのは、誰もが幸せに生きるために為すべき「人生最大の選択」についてだった。果たしてその選択とは？　あなたの人生を一変させる劇薬の哲学問答、再び！https://1000ch.net/posts/2024/dx-criteria-for-web-frontend/Wed, 24 Apr 2024 00:00:00 +0000https://1000ch.net/posts/2024/dx-criteria-for-web-frontend/日本 CTO 協会からのプレスリリースの通り、Web フロントエンド版 DX Criteria がリリースされました。公開に向けて、監修者として関わりました。 新DX Criteria 本日リリース Webフロントエンド版DX Criteria（プロダクトのユーザー体験と変化に適応するチームのためのガイドライン）https://t.co/LHA61cgajF この度 #日本CTO協会 からWebフロントエンドに関するDX Criteriaをリリースいたしました。… — 日本CTO協会公式アカウント (@ctoa_ja) April 24, 2024 Web フロントエンドは技術領域として進化の途上にあり変化に富んでいるだけでなく、ソフトウェアの開発工程におけるシステムとデザインの間にありながら、プロダクトデリバリーにおいてはユーザーに面する性質を持ち、高速な仮説検証とそれを実現するプロセスを求められます。Web フロントエンド版 DX Criteria はそれを目指す羅針盤として、Web 開発者を導いてくれるはずです。 DX Criteriaとは DX Criteria（DX基準）は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せて日本CTO協会のWG内で議論をおこないながら、適宜アップデートをしているものです。 https://dxcriteria.cto-a.org/https://1000ch.net/posts/2024/custom-pseudo-class-with-custom-state-set-api/Sun, 07 Apr 2024 00:00:00 +0000https://1000ch.net/posts/2024/custom-pseudo-class-with-custom-state-set-api/Safari 17.4 で CustomStateSet がサポートされた。CustomStateSet は Web Components のカスタム要素の状態を管理する API で、Element Internals の states プロパティに含まれる。Element Internals はカスタム要素の振る舞いを HTML のフォームと連動させるための仕様だ。 CustomStateSet は JavaScript のグローバルオブジェクトである Set と同様のインターフェースで、CustomStateSet に追加された文字列がカスタム要素の「状態」を定義する。 次のデモは HTML の minlength 属性を <input type="number"> で動的に設定し振る舞う Web Components である1。<input type="text"> や <input type="number"> の値を変更すると、validate() メソッドで入力値のバリデーションを行い、その結果を Element Internals オブジェクトの setValidity() メソッドで設定するとともに、states プロパティで状態を指定している。 See the Pen Custom pseudo-classes with CustomStateSet API of Element Internals by 1000ch (@1000ch) on CodePen. ここでは、入力値の長さが minlength の値より小さい場合にエラーを報告しつつ、error という値を保存している。これによって、この HTMLElement は Element Internals の states プロパティによって状態が宣言されることになる。:state() 擬似クラスは、CustomStateSet オブジェクトで定義される状態を参照し、任意の識別子として参照できる。ここでは error という状態を :state(error) のように参照し、スタイリングしている。https://1000ch.net/posts/2024/tokyo-sakura-marathon/Sun, 31 Mar 2024 00:00:00 +0000https://1000ch.net/posts/2024/tokyo-sakura-marathon/去年に引き続き、第5回 東京さくらマラソンに参加して 10km を完走した。2024 年は 3 月半ばを越えても寒く、今週に至っては雨続きでどうなることやらと思いきや、打って変わって当日は快晴どころか最高 26 度という夏日での開催になった。 2022 年が 54:22 で 2023 年が 55:48 という結果だったので、それは越えたいなと思い、今年はいくつか対策を凝らした。まず、レース前とレース中にちゃんとエネルギーを補給する。朝食を取っても良いが、よりエネルギーになりやすいゼリー飲料をレース前に取りつつ、荒川ハーフマラソンでも実践したように、レース中に MAURTEN のジェルを食べて、ZAMST の膝サポーターを着用して挑んだ。 それが功を奏してか、今年は 51:51 という自己ベストでゴールできた。 10km ではなく 10.2km を走っているのは御愛嬌だが、レースの途中からコース内の案内板と手元の時計の計測がズレていることには気付いており、恐らくコースの測量ミスなのではないかと予想している。 走行記録を遡ってみると、何を思い立ったのか 2017 年末に走り始めており、コンスタントに走り始めたのはここ数年のことである。加齢に抵抗しながらハーフマラソンまで走れるようになったことを思えば、一定の成長はあったと信じたい。https://1000ch.net/posts/2024/optin-auto-phrase/Thu, 28 Mar 2024 00:00:00 +0000https://1000ch.net/posts/2024/optin-auto-phrase/このブログでもダークモードを prefers-color-scheme を使って Dark Mode に対応 していたが、諸々の実装を見直すタイミングで削除してあった。今回は、デフォルトでシステムの設定を参照するようにし、ダークモードを優先したい場合はページ上部にあるチェックボックスを on にすると有効化される。 そのトグル UI の実装は、何の変哲もない <input type="checkbox> かと思いきや、実は <input type="checkbox" switch> という新しい仕様で実装している。 switch 属性は長らく GitHub での議論されているが、Safari Technology Preview 185 での実装を経て Safari 17.4 に ship された。 See the Pen <input type="checkbox" switch> by 1000ch (@1000ch) on CodePen. また CSS に 4 つの新しい国際化機能が導入された。このブログでも英数字と日本語の混在を意識して半角スペースを含めたテキストにしているが、 text-autospace プロパティと text-spacing-trim プロパティによってタイポグラフィは改善される。それぞれのプロパティのデフォルトの挙動が改善されるので、実装を待つのみだが、もう1つ注目しているのが word-break: auto-phrase; である。 日本語や中国語といった言語は単語をスペースで区切らず、 word-break プロパティや overflow-wrap プロパティの値に応じて単語そのものが改行され、読みづらさを招く場合がある。auto-phrase 値は、日本語においては文節で改行することで可読性を改善してくれる。 このブログでも全般的に適用したが、改行位置が各行の日本語文章に依存するため、ブロック要素の右端で改行されずレイアウト上の違和感が残る。これはパラグラフの改行位置でレイアウトのリズムを揃えるのではなく、そのブロック要素そのものの UI を改善するべきだとは思うが、ひとまずダークモードと同様にオプトインで設定できるようにした。https://1000ch.net/posts/2024/web-share-api/Fri, 22 Mar 2024 00:00:00 +0000https://1000ch.net/posts/2024/web-share-api/元々このブログでは記事ページに、各ソーシャルメディアのインテントへリンクするアイコンを設置していた。これを Web Share API を使ってより汎用的な実装に変更した。 ソーシャルメディアには GET でアクセスできるインテントが用意されていることが多い。これを用いた Web ページの共有機能は従来からある方法で、これ自体に大きな課題はないが、より利用者の OS コンテキストに適したシェア体験を実現する Web Share API が数年前に発表されている。 Web Share API はシェアする文言および URL をパラメータとして渡すことで、OS レイヤで実装される共有メニューを呼び出せる。モバイルではネイティブアプリの共有機能で呼び出されることも多いので、見慣れた UI だろう。このブログはしばしば技術的な実験場として使われ、試験的な API でもすぐに導入しがちだが、Web Share API はデスクトップ OS でのサポートが長らく進まず、倦ねていた。Web Share API を呼び出すモバイルと、ソーシャルメディアのインテントへリンクするデスクトップで、UI を変える必要があるからだ。「ページを共有する」という単一の UI アクションに揃えるために、Web Share API がサポートされていない環境では、シェアする文言をコピーするというフォールバックを提供することにした。 従来の Web ページにおけるコピー機能の実装はシンプルとは言い難い。コピーさせるテキストを <input type="text"> に埋め込み、そのテキストを選択状態にした上で document.execCommand('copy') を呼び出す、という手順が必要だったからだ。そういった実装の煩雑さに加えて同期処理という課題も相まって、Clipboard API が考案された。これは Web Share API より新しいが、OS のインターフェースに絡みづらい話であることもあり、サポートが進んでいる。 さらに最近では Popover API が話題である。Popover API は HTML ネイティブでトップレイヤーの HTML 表示・非表示を切り替える、Web 業界が待ち望んだ仕様だ。近しい HTML 技術としては <dialog> 要素があるが、細かな機能差があることに加えて「それがダイアログなのかどうか」といったメンタリティにも及ぶので、使い所は時と場合に依るだろう。https://1000ch.net/posts/2024/world-id-verification-at-mokuhari/Mon, 11 Mar 2024 00:00:00 +0000https://1000ch.net/posts/2024/world-id-verification-at-mokuhari/WorldCoin という OpenAI ファウンダーのサム・アルトマンが率いるデジタル通貨がある。そのコンセプトの詳細については WorldCoin のホワイトペーパーを読むことをおすすめするが、WorldCoin は World ID というデジタルアイデンティティと、WLD という通貨によって構成される。そのデジタルアイデンティティの核となるのは人間性の証明であり、人間ひとりひとりが持つ一意な虹彩によって World ID は認証される。発展的には、このデジタルアイデンティティ持つ人間性の証明が、今後 AI などのコンピュータと区別する重要な存在になっていく、という話だ。 World App をダウンロードし、アカウントを認証することで配布される $WLD トークンを受け取れるようになる。アカウントの認証には、Orb というデバイスで虹彩を認証する必要がある。 #OpenAI のサム・アルトマンが率いる $WLD (#WorldCoin) を、後楽園の工作室もくもくはりねずみ @mokuhari で🆔認証してきた 🔮 https://t.co/tQT3glSDCX pic.twitter.com/kXCxqNDeJM — Shogo SENSUI 🍵 (@1000ch) February 24, 2024 Orb はいくつかの国にあり、日本には 2024/3 時点で二十数か所に設置されている。東京都文京区にある工作室もくもくはりねずみはそのひとつだ。名前の通り DIY を楽しむワークスペースのような場所だが、日本でも数少ない Orb の設置場所ということで認証しにくる人も多いのだろう、快く受け入れてくれた。Orb の設置場所の中には混雑を避けるために、訪問前に予約が必要な場所もあるが、もくもくはりねずみは不要だった。…と思ったら、大混雑のために予約が必要になったようだ。 WLD というデジタル通貨の話もあるが、人間性の証明を掲げたプロジェクトは非常に野心的で、ゲームやソーシャルだけでなく様々な場面で活用できるとされている。理論上、虹彩認証を突破したアカウントの所持者は人間であるはずで、既に 400 万人以上がサインアップしている。人間性が保証されたデジタルアイデンティティの巨大なネットワークを構築するこのプロジェクトに興味がある人は、こちらからどうぞ。https://1000ch.net/posts/2024/30000min-on-dmm-eikaiwa/Wed, 21 Feb 2024 00:00:00 +0000https://1000ch.net/posts/2024/30000min-on-dmm-eikaiwa/オンライン英会話の学習時間が 20,000 分に到達してから丸 1 年少々が経過し、30,000 分に到達した。その間 418 日なので、400days x 25min で 10,000min になることを考えると、数日間は抜け落ちているものの、ほぼ毎日やっていることになる。 pic.twitter.com/ATPp5Tkc7k — Shogo SENSUI 🍵 (@1000ch) February 21, 2024 自分にとってモチベーションになっていたことはないが、ランクはマスターからレジェンドになり、これ以上は変化しないらしい。ここ 1 年間はプラスネイティブプランを契約して、ネイティブ英語に慣れながら、より細かい指摘を日本人にしてもらうことをしてきた。ただ、ネイティブに比べるとどうしても日本人の先生の英語レベルはまちまちなので、受講しながらレベル感を把握する必要がある。 どの程度実が伴っているか不明だが、10,000 分に達したのが 2021 年の 3 月で、3 年半くらいは継続できており、それは良かった。メルカリを辞めてからは、業務で英語を使う機会がなくなってしまったが、ライフワークの 1 つとしてこれからも続けていくつもりだ。https://1000ch.net/posts/2024/arakawa-half-marathon/Sat, 17 Feb 2024 00:00:00 +0000https://1000ch.net/posts/2024/arakawa-half-marathon/東京さくらマラソンには、人生初の大会となる 2022 年の第 3 回、続く 2023 年の第 4 回と参加してきており、そして第 5 回となる 2024 年も参加予定である。一方、他の大会の様子も気になっていた中で、偶然 Instagram の広告で流れてきたのがアミノバイタル presents 荒川ハーフマラソン 2024である。 開催の 2 週間前に迫っていたが、かなり直前まで申し込み可能という柔軟な運営になっており、参加者にとってはありがたい限りである。ようやく 10km に慣れてきたところでハーフマラソンは練習でも走ったことがなかったが、思いつきで申し込んだ。とはいえ、今まで走ってきた倍の距離ということで丸腰で挑むのも無謀だと認識しており、まずは練習としてハーフマラソンを走ってみることにした。 流石に苦しいが、走れなくはない。とはいえ、できる対策はしておこうということで、膝サポーターと走行中に補給するエネルギーを使ってみることにした。 【ランニング時のヒザ（お皿の下）にかかる負担を軽減】お皿の形に沿って設計されたバタフライパッドとストラップにより、ヒザ下にかかる負担を軽減します。 【快適な装着感を実現】ヒザ裏を含めた本体に薄く通気性の良い素材を採用。ランニング中もかさばらず、ムレにくく快適な装着感を実現します。 【ランニングの動きに合わせた立体裁断】ランニングの動きに合わせた独自の立体裁断を採用。高いフィット性を実現します。 【動きを妨げずにしっかり安定】ヒザの曲げ伸ばしをスムーズに行えるように設計された、独自のアクティブ樹脂ステーを採用。ヒザへの負担を軽減します。 皇居で練習していたところ、15km を超えたあたりから左膝・右膝と順に痛み始めて辛かったので、練習に付き合ってもらった知人に、膝サポーターを進めてもらった。これは、走り方のクセも影響していると思うが、いずれにしてもサポートがある方が安心だろう。 GEL 100は、高濃度の炭水化物を封入するMAURTENが開発した”ハイドロゲル技術”により、1時間あたり最大で100gの炭水化物をエネルギーに変換することを可能にした革命的スポーツエネルギードリンク・エナジージェルです。この量は、これまで人間が吸収できると考えられていた量の限界を超えています。 上記の練習中にウィダーインゼリーを補給しながら走ったら随分楽だったので、その話をしたところ、知人にこれを進めてもらった。高いが毎日飲むようなものではないし、値段相応の商品なんだろうということで挑戦してみることに。冷静に考えれば、21km という距離を走れば、それは相応に身体を消耗するよなというところである。 そして当日を迎えて、無事に完走できた。 ノベルティなどは最小限だが個人的にはむしろありがたい。司会進行やペーサー、そしてスタッフの対応も充実しており、大会の参加経験が少ない自分にとっては、中々勉強になる経験だった。ハーフマラソンに走り慣れるまでは時間がかかりそうだが、思い返せば 10km や、その前の 5km もそうだったので、続ければ人間なんとかなるものと信じて続けてみる。https://1000ch.net/posts/2024/software-engineering-at-google/Sun, 14 Jan 2024 00:00:00 +0000https://1000ch.net/posts/2024/software-engineering-at-google/kumagi さんの Mond での回答で言及があり、読みかけのまま本棚に入っていたことを思い出して読み直した。 Google という巨大企業がテクノロジーで世界を変えていることは周知の事実だが、ソフトウェアエンジニアリングに関わるいち技術者としては、どのようにしてそのテックドリブンな文化が支えられているのかに興味がある。エンジニアリングとして切り取られるプロセスそれぞれの重要性だけでなく、エンジニアリングそのものの解釈や組織的な位置づけなどが論じられている。要するに、エンジニアリングに対してソフトウェア開発の要求のみをしているうちは、テックカンパニーには程遠い。 Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。 Google の情報自体は書籍を含めて多くの情報がインターネットに落ちているが、ソフトウェアエンジニアリングに焦点が当たった体系的な資料が読めるのは貴重である。英語版の原著は Kindle でも販売されているが、日本語版だと単行本しか販売されていない。肝心の日本語訳も堅苦しさがあり、読みやすいとは言い難いものの、Google というテックカンパニーのエッセンスを吸収するには充分だろう。願わくば、日本語訳の改良と Kindle 版が販売されることを祈りたい。https://1000ch.net/posts/2023/look-back-over-2023/Sun, 31 Dec 2023 00:00:00 +0000https://1000ch.net/posts/2023/look-back-over-2023/2023 年は激動とは言わないまでも、様々な変化があった 1 年だった。雑でも書かないよりはマシだと信じて、2023 年の振り返りを書き残しておく。 2022 年の振り返り 2021 年の振り返り 2020 年の振り返り 2019 年の振り返り 転職と複業 2023 年 6 月に、5 年と 4 ヶ月勤めたメルカリを退職した。そして 2023 年 7 月に、技術顧問として関わっていたハウテレビジョンに転職した。転職後の話はハウテレビジョンのプロダクトの現在地や技術負債解消プロジェクト・ツールやリソースの全社的な統廃合・イシューに向き合う部門再編などの話に綴っている。その記事でも触れているように、キャリアを重ねる中で自分なりに向き合いたいテーマが出てきたことが、今回の転職のきっかけである。 様々な業務を様々なレイヤで関わる中で、日本社会のボトルネックは何なのかを自問する日々が続きました。当然、こうした壮大なテーマの答えが簡単に出る訳もありませんが、いくつか感じていた課題のひとつに「雇用」がありました。 ここ 30 年間、日本経済は停滞が続いていますが、その要因にあらゆる組織に存在する既得権益があり、必要な新陳代謝を妨げています。企業の営みにおいては、就職した会社に終身で勤め上げる慣習や正社員の雇用保護などがそれに当たるでしょう。戦後の教育制度もこれらの文化的背景に強く影響していますが、昨今では転職や副業が一般化してきたことで転換期を迎えています。 「ひとりひとりが働くテーマを持ち、適した環境で能力を発揮する。優秀な人材を抱えるために企業は新陳代謝を繰り返し、より優れた事業を社会に創出する。」こうした体質転換が、これからの日本社会に必要なことではないかと感じています。 2023 年 4 月にはデジタル庁に非常勤国家公務員として入庁し、国のデジタル化に関わってきた。この複業は上記の転職に加えて、そのテーマに向き合う追加オプションの 1 つだ。 この周辺の話は、知人との会話やカジュアル面談で言語化されつつあるので、何かのタイミングで何らかの形でまとめてみたい。 pic.twitter.com/vV2jSODp8I — Shogo SENSUI 🍵 (@1000ch) April 1, 2023 各種イベントへの出演 今年もいくつかのイベントで発表する機会をいただき、様々なテーマで話をしてきた。振り返ってみると、自分のキャリアについて話す機会が多かった。それなりに社会人歴も深くなってきたせいもありそうだが、自分自身もよくわかってないし懐疑的ですらあるので、「ひとつのケーススタディとして聞いてもらえれば」という気持ちで話した。 2023年のフロントエンド高速化手法〜Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線 2023年のフロントエンド高速化手法~Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線 2023年のフロントエンド高速化手法〜Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線に出演した 2023年のフロントエンド高速化手法~Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線@merpay_official 執行役員VP of Engineeringの泉水氏@1000ch とFastly 大室@katsuyukiomuro によるが登壇・パネルディスカッション！ 明日開催 今すぐ登録👇https://t.co/3pCekhBz1e #高速化_findy — Fastly Japan (@FastlyJapan) March 21, 2023 ソフトウェアエンジニアとしてのキャリアを歩むには - 外資就活Terminal 外資就活Terminal | 外資就活ドットコム ソフトウェアエンジニアとしてのキャリアを歩むには？働く場所、キャリアパス、専門性などメルカリの執行役員に聞いてみた ソフトウェアエンジニアとして活躍し続けるには？キャリアの軸はどう選ぶか？ 渡辺さきさん (@skwx) モデレーションのもと行われた外資就活 Terminal (@gaishishukatsu) の、 @ExaWizards 木村さんとのパネルディスカッションの書き起こしが公開されました / “ソフトウェアエンジニアとして活躍し続けるには？キャリアの軸はどう選ぶか？” https://t.https://1000ch.net/posts/2023/bought-in-2023/Wed, 06 Dec 2023 00:00:00 +0000https://1000ch.net/posts/2023/bought-in-2023/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの 2020年に買って良かったもの 2021年に買って良かったもの 2022年に買って良かったもの SwitchBot スマートロック 指紋認証パッド これは記事を書いた通り、改めて振り返っても良い買い物だった。他の人にもこの話をしたところ、2人ほど購入してくれて、感想を聞いてみたところ QoL がとても高まったとのこと。 THE NORTH FACE マウンテンライトジャケット 予期しない雨に対するソリューションは、長らく mont-bell のトラベルアンブレラ 50 を鞄に忍ばせていたが、傘を差したくない、もとい両手を開けたい私はこのジャケットに巡り合った。みんな大好き安心のノースフェイスで、素材も GORE-TEX なのでそれなりのお値段だが、それに見合う価値はある。素材の厚さも程々でゴワゴワしすぎないし、夏以外は活躍できるポテンシャルがある。 GORE-TEX PRODUCTSを採用した防水シェルジャケット。THE NORTH FACEの定番である肩部分の切り替えを取り入れたアイコニックなデザインです。耐久性の高い70デニールリサイクルナイロンを表生地に使用し、やや長めの着丈で保温性を確保。フロントはダブルフラップ仕様で防水性を高めています。内側の専用ファスナーでインナーを連結できるジップインジップシステム対応。トレッキングやキャンプのアウトドアのみならず、デイリーユースにも適した1着です。2022年秋冬シーズンよりサイズ感を見直し、身幅をハーフサイズ大きくし、よりバランスよいサイズ感にアップデートしました。 防水素材としては GORE-TEX だけでなく FUTURELIGHT™ という選択肢もある。それらの比較は、次のギズモード・ジャパンの動画がわかりやすい。 COROS PACE 2 もともと腕時計を付ける習慣がなかったが、ランニングをはじめたことがきっかけで Apple Watch にはじまり Fitbit Versa や Fitbit Sense を渡り歩いてきた。どれも電池が最大でも 3-4 程度しか持続せず高頻度で充電しなくてはならないのがボトルネックだった。そんな中、知人に紹介されたのが COROS PACE 2 である。 COROS PACE はフルマラソンの元世界記録保持者であるエリウド・キプチョゲが愛用しているスマートウォッチだ。一般的なスマートウォッチが備えている機能はもちろんのこと、特筆すべきは 29g という装着していることを感じさせない重さに加えて、20日間持続するバッテリーの持続性だろう。 ランニングやトライアスロンなどスピードを求める方向け 業界最軽量クラス、わずか29g（ナイロンバンド装着時） 通常使用なら最大20日間、GPSモードなら最大30時間連続稼働 4大衛星システムを採用し、広範囲かつ高精度の位置情報を提供 ウォッチバンドと充電ケーブルが付属 COROS PACE 2 を購入したのが 2023/6 だったが、その 3 ヶ月後に COROS PACE 3 が発表された。目立った機能差がなさそうなので買い替えていないが、いずれ買い換えよう。https://1000ch.net/posts/2023/techfeed-experts-night-26/Wed, 27 Sep 2023 00:00:00 +0000https://1000ch.net/posts/2023/techfeed-experts-night-26/掲題の通り、2023年9月27日に開催された TechFeed Experts Night#26 で 2023 年の Web 開発のベースラインについて発表しました。 TechFeed のイベントに出演したのは、昨年開催された TechFeed Conference 2022 ぶりで、ちょうど IE11 のサポート終了に関してアナウンスされた前後でした。それを踏まえて、これまで Web 開発がどういう変化を遂げてきたのかをおさらいしながら、これからの Web 開発のベースラインをどこに置くべきかという問について話しました。https://1000ch.net/posts/2023/obsidian/Tue, 26 Sep 2023 00:00:00 +0000https://1000ch.net/posts/2023/obsidian/仕事用なのかプライベート用なのか、はたまた両方なのか、端末を問わずに共有されるメモを望む人は多い。こうした目的に対しては Evernote や Day One、Inkdrop といったプロダクトがあるが、手に馴染みききらず public な scrapbox を使っている。 scrapbox 独自の記法はあるものの、メモがてら公開したいものを管理する目的に対して scrapbox はとても良い一方で、タッチデバイスで編集するには使い心地が難しい部分があったり、Markdown で書きたいニーズを満たせていなかった。 Markdown をサポートしているプロダクトは多数ある。Typora や Quiver、先の Day One/Inkdrop などもそうだが、Android に対応していなかったり、クラウド同期が各プロダクトに依存していたりする。特に後者は、蓄積したデータの可搬性を考えると慎重になっており、そのプロダクトが終了したときの import/export を考えると管理可能であって欲しい。 Obsidian が良く出来ている 自分のニーズを整理すると「プライベートに管理できて」「データ同期がクロスデバイスかつ持続可能で」「デバイスを問わずにアプリが優れている」だが、現時点で最も正解に近そうなのが Obsidian である。 Obsidian はマルチプラットフォームに対応しており、便利なコミュニティプラグインがあり、課金することでデータの同期やページの公開にも対応している。アプリ自体の出来が良く、データの同期を OS のファイルシステム上に Vault を作成する。その Vault を Dropbox で同期することで、Obsidian に依存せずクロスデバイスなデータ同期を実現できる。 Dropsync を使った Android でのデータ同期 Obsidian は Android アプリを提供しており、Dropbox の Android アプリも存在する。しかし、Dropbox がデータ同期に参照している Android のファイルシステムは隔離されているので、通常 Obsidian から参照できない。 そこで Dropsync: Autosync for Dropbox というアプリを使うことで Android 端末の任意のフォルダを Dropbox の同期対象とすることができる。同期の頻度や状況の設定なども豊富だし、苦労するポイントはない。あまりにピッタリのソリューションだったので、広告を非表示にする必要はなかったが、感謝の気持を込めて課金した。https://1000ch.net/posts/2023/frontend-productivity-online-conference/Thu, 21 Sep 2023 00:00:00 +0000https://1000ch.net/posts/2023/frontend-productivity-online-conference/Findy さんに声をかけていただき、2023 年 9 月 21 日に開催された、フロントエンドの開発生産性〜Online Conference〜というイベントに出演した。 半年前にも、同じく Findy さん主催の 2023年のフロントエンド高速化手法~Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線というイベントにも出演させていただいたが、今回は「開発生産性と組織」という難しいテーマで話すことになった。 イベントのセッションタイトルを並べてみたときに、皆さん認知負荷や変化の激しさ、技術選定とキャッチアップ、品質と生産性の両立、デザイン、テスト自動化など、同じ生産性を語る上でもいい感じにバラけていたので、このセッションも生産性に向き合う上で何らかのヒントになれば幸いです。https://1000ch.net/posts/2023/farewell-mercari/Fri, 30 Jun 2023 00:00:00 +0000https://1000ch.net/posts/2023/farewell-mercari/2018年3月にジョインして5年4ヶ月が経った。メルカリとの出会いを思い返すと、随分と前から長らく声を掛けていただき、タイミングの折り合いがつかなかったこともありったが、こうして自分のキャリアの中でメルカリを経験できたのは石黒さんのおかげに他ならない。 const diff = new Date('2023/6/30') - new Date('2018/3/1'); const days = diff / (1000 * 60 * 60 * 24); console.log(`${days} days`); // => 1947 days メルペイは2017年11月に会社化されて間もなく、入社時点では決済関連の機能もリリースされていなかった。しかし、既に C2C のマーケットプレイスとして成功していたメルカリが次は決済分野に乗り込むということで業界の注目を集めており、ひと月に何十人も入社するというある種の異常事態だった。 2018年7月からは、メルカリで先んじて導入されていた EM/PM/TL 体制がメルペイにも導入され組織として整備されていく中で、メルペイの Frontend チーム の立ち上げに、本格的に取り組んでいくことになる。兎にも角にも人が要るということで採用活動に奔走する中でメルペイの開発は進んでいき、2019年2月に最初のリリースに漕ぎ着けることができた。リリースに至るまでに語りきれない程多くのドラマがあったが、いちソフトウェアエンジニアとしてはメルペイのクーポン機能などの開発に関わっていた。良いチームでゼロイチの開発に取り組めたことはとても幸運で、リリース時にはメンバー皆でおにぎりが11円で購入できる様子を見守ったことを思い出す。 決済事業という点では、最初に iD による非接触決済がリリースされたことで iD が導入されている多くの店舗で利用できる状態からスタートした。通貨が通貨たるために価値として交換できることは非常に重要で、メルペイと提携している銀行やメルペイを利用できる加盟店の存在があってこそであり、それをリリース前から開拓し続けてきた Business Development チームや Sales チームの力は凄まじい。 2019年末に中国の武漢で発生した新型コロナウイルスは世界を震撼させた。日本でも感染が拡大するまでに時間はさしてかからず、人々の生活を強制的に変化させると共に、経済にも大きな打撃を与えた。多くの犠牲者を出した点に於いてこの事象を肯定する余地はないが、日本におけるデジタル化を大きく前進させたことも事実である。恐らく、新型コロナウイルスの存在がなければ日本のデジタル化はもう数年かかっていただろう。それはリモートワークの導入といったわかりやすい部分だけでなく、FAX によるやり取りや印鑑による承認フローといった、古くから続いてきた様々な非合理的なプロセスへ一石を投じた。ホワイトカラーの多くは出社せずとも仕事が成立することが証明され、企業も都心に限定せず労働力を確保する動きにシフトしている。限界集落や少子化といった問題へ働きかけてくれるかどうかはさておき、東京と地方との間で発生している経済格差を長い時間をかけて埋めてくれる可能性はある。そしてリモートワークが一般化した以上に、情報流通の改革をもたらしたインターネットが変革できていなかった部分に届きつつある感覚を覚える。 ほぼ同時期に立ち上がったのがメルカリ Web の刷新プロジェクトだった。もともと進んでいたリアーキテクチャプロジェクトをメルカリ経営として仕切り直し、そのリードを担当することになった。ここからメルカリの組織マネジメントも兼務することになり、結果的にはおよそ1年半でほぼすべてをリプレイスできた。 私が本格的に英語を勉強し始めたのが恐らくこのタイミングで、メルペイ Frontend として英語話者をメンバーとして受け入れることになったこと、メルカリ Frontend の英語話者のメンバーを担当することになったこと、この2つが大きな要因である。また、日本でも D&I への注目が高まっていく中でメルカリグループでも包括的な組織作りを掲げており、メルペイのエンジニアリング組織に対しても英語のインストールを徐々に推進してきた。「英語で対話できるようになること」と「包括的な組織」はイコールではないが、より多くの優秀な人材を採用したい中で日本市場だけでは既に人材が枯渇しつつあり1、また多様な人材を採用していける組織に向けて変化していくためにも自然とも言える。一方で、目下の業務に於いて、特に日本国内特有のドメインとも言える貸金や与信の領域は敢えて英語を使わなくても良いのも事実だ。グループ内において多言語をどのように捉えて組織に取り入れていく、これからも向き合うトピックの1つかもしれない。 メルカリ Web を刷新して後を託しつつ、メルペイでは iOS, Android, そして Web を含むクライアントサイドのエンジニアリングを担当することになってからは、Codecov への不正アクセスを起点としたセキュリティインシデントや、メルカリ Web の次はメルカリアプリのコードベース刷新といったタフなプロジェクトを経験してきた。これらのソフトウェア投資は、メルカリがこれからの数年を戦う上で重要な資産になると信じている。 2021年10月にはメルコインの発足と暗号資産事業に取り組むことが発表され、続く12月にはパ・リーグと提携した NFT 事業への参入も発表された。モノと通貨という価値交換に暗号通貨が加わることで経済上の摩擦が減ることは、将来的に日本以外のマーケットプレイスを取り込んでいくことにもつながっていくだろう。https://1000ch.net/posts/2023/open-sourced-qa-system/Mon, 24 Apr 2023 00:00:00 +0000https://1000ch.net/posts/2023/open-sourced-qa-system/社員が一堂に会する全体定例や各種イベントで、相互的な理解を促すためのコミュニケーションツールとして Q&A システムを用いている。元はと言えば、この目的に即した出来物のシステムを使っていたが、社内で求める用途に合わず @sinmetal さんがゼロから作ったことがきっかけで、途中からフロントエンド部分の改善を手伝っていた。 すると想定以上に様々な場面で利用されるようになり、ツールへの依存が高まる一方で、維持管理をボランティアベースでやっていたため、中長期的に維持が難しくなることが懸念された。実際、当時 Vue.js/Nuxt v2 で実装されていたが長い間そのまま改善されず、Vue.js/Nuxt v3 がリリースされた後もしばらく放置されていた。 そこで Vue.js/Nuxt を最新の v3 にアップグレードさせつつ、よりコミュニティベースでもコミットできるように OSS として公開した。それが gcpug/qa_board である。公開に際して、もともと社内向けにベタ書きしていたロジックなどの情報を削除する必要があり、コミットログは squash されていることをご容赦頂きたい。 システムとしてはデータベースに Firestore を利用している。そのため作成したプロジェクトの Firebase console から、Firebase SDK の初期化に必要な各種トークンを環境変数として渡す必要がある。ローカル環境であれば .env で（これは Nuxt v3 の機能である）、デプロイ時には CI の環境変数に設定しビルド時に参照できるようにする。 システムと言っても豊富な機能を備えているわけではなく、ある程度運用でカバーしている部分が大きい。機能を追加するほどソフトウェアが複雑になり最終的に持続が難しくなる側面は避けられないため、コミュニティベースになったとはいえ全ての機能リクエストを汲めるわけではなく、ある程度目を瞑ってメンテナンスしていく必要がある。この点を理解いただいた上で、こうした会社やコミュニティの Q&A システムの需要がある場合は是非お試しください。https://1000ch.net/posts/2023/tokyo-sakura-marathon/Sun, 09 Apr 2023 00:00:00 +0000https://1000ch.net/posts/2023/tokyo-sakura-marathon/去年に引き続き、第4回 東京さくらマラソンに参加して 10km を完走した。去年はとても暑くて途中でバテて 5km 時点でペースダウンした記憶があり、今年は少し抑えめのペースで走り切ることを目標にしたところ、10km を 55:48 という結果で、去年より 1:26 遅かった。 去年の出走から今回まで、レースへの参加を見据えて鍛え上げてきたというよりは、習慣づくりを目的に継続的に走ってきた。1年の間、一時的にスポーツジムを契約して筋力トレーニングをしていた時期もあったが、スポーツジムに通う時間と移動および金銭的なコスト、そして実際のトレーニング効率を含めて諸々顧みた時に、ランニングの方がパフォーマンスが良いと判断した。https://1000ch.net/posts/2023/frontend-performance-fastly-mercari/Wed, 22 Mar 2023 00:00:00 +0000https://1000ch.net/posts/2023/frontend-performance-fastly-mercari/Findy さんに声をかけていただき、2023 年 3 月 22 日に開催された、フロントエンドの開発生産性〜Online Conference〜というイベントに出演した。 メルカリ Web をゼロベースで書き直すという大きなプロジェクトの経緯は新しいメルカリ Web の話に詳細に書いたが、パフォーマンスそのものについて、もといアーキテクチャやそれを維持するための文化や仕組みといった込み入った話には及んでいなかったので、組織的な背景にも触れながら話す良い機会になった。https://1000ch.net/posts/2023/to-switchbot-lock-from-sesame4/Mon, 30 Jan 2023 00:00:00 +0000https://1000ch.net/posts/2023/to-switchbot-lock-from-sesame4/自宅のスマートロックを「SESAME 4 + WiFi Module 2 + NFC タグ」から「SwitchBot ロック + SwitchBot キーパッド」にしたら、施錠時と解錠時にスマートフォンを取り出す手間がなくなり、かなり快適になった。 【金属のカギを使わず、解錠も楽々に】スマートロックと指紋認証パッドを設置すれば、重たい金属のカギを使わず、ドアを解錠できます。スマホで解錠、パスワードで解錠、指紋認証で解錠、カードキーで解錠、室内で音声コントロールで解錠など、多数の方法でドアを簡単に解錠できます。今までのカギのわずらわしさから開放されて、ドアの解錠はもっと安全に、もっと便利になります。 SESAME 4 が悪い等の不満を言いたいわけではなく、スマートロックとして充分に機能していた。値段もお手頃だし、サポートも良好という話をよく見る。 SESAME 4 は玄関ドアの内側に取り付けて施錠と解錠を管理できるスマートロックだ。SESAME 4 の操作はアプリ経由で行い、Bluetooth で繋がるか別売の WiFi Module 2 で接続する。私は WiFi Module 2 を経由していた。 遠隔で施錠と解錠といった操作をできるのは良いものの、アプリを起動する手間が気になっていたため、NFC タグを玄関ドアに貼り付け、スマートフォンや Suica の FeLiCa を近づけると「SESAME 4 の施錠と解錠のトグル」アクションが実行されるようにしてあった。 【防水】：NTAG215 NFCカードは両面が空白で、耐久性のある防水ポリ塩化ビニル材質で作られています。カードが濡れても心配は要らないです。 【複数回データ編集】：カードの使用回数は一万回以上になっておりますため、長時間の複数使用は可能になっています。繰り返し消去、編集することや読み取り専用タグとして設定することもできます。＊注意：読み取り専用に設定されている場合、これ以上編集またはリセットすることはできません。 しかし、ここまでやっても「何かをポケットから取り出す手間」が残っていたので、やはり生体認証で操作したい。ということで、少しコストがかかるけど SwitchBot ロックと SwitchBot キーパッドの組み合わせに変更してみたら、桁違いの利便性を実感できている。ちなみにキーパッドはセキュリティ面の懸念から使用していない。 【ドアの解錠はタッチするだけ】本製品はSwitchBot スマートロックをもっと自由にしてくれる、専用の拡張デバイスです。指紋認証パッドは、スウェーデンのPRECISE BIOMETRICSより開発された指紋認識アルゴリズムと生体認証装置を備えており、汗かき·磨耗した指紋でもお子様の細い指でも素早く認識できます。指紋データはキーパッド本体ローカルログのみに保存、安全で信頼できます。 【パスワードで解錠】スマホをポケットから取り出さず、設定したパスワードで2秒以内解錠できます。一般パスワード以外、ワンタイムパスワードや指定時期のみ有効の期間限定パスワードや仮想パスワードなど特殊なパスワードをカスタマイズできます。付属のカードキーで解錠することにも可能です。 ちなみにマンションのエントランスの解錠をどうにかしたい問題は残っているが、こちらはマンションの組合で議論するハードルがある。理想的には生体認証による解錠を提案したいが、費用と工事規模が膨らみそうだ。せめてエントランスの工事だけで完結する要件を考えると、センサーによる非接触解錠あたりだろうか。自分の部屋番号を押されたときに、解錠ボタンが押されるような仕組みを作ることも不可能ではなさそうだが、逆に手間になってしまい解決にならなそうだ。https://1000ch.net/posts/2022/20000min-on-dmm-eikaiwa/Fri, 30 Dec 2022 00:00:00 +0000https://1000ch.net/posts/2022/20000min-on-dmm-eikaiwa/昨年オンライン英会話の学習時間が 10,000 分に到達したが、今年はそれが 20,000 分に到達した。1回25分のレッスンなので、1日1レッスンのプランだと 25min * 365days で 9125min/year が最大である。スランプに陥っていた時期などもあるので日数に換算すると足りていないが、DMM 英会話で勉強をはじめてから丸3年が経過したことになる。 pic.twitter.com/2Ig1q5tMR1 — Shogo 🍵 (@1000ch) December 30, 2022 この間、英検2級はパスしたが、英検準1級は3回落ちている。そのうち1回は通常の筆記と面接がある英検、後の2回は S-CBT という1日で4技能を測定するもので、いずれも Reading/Writing/Listening の合計がボーダーラインに到達しておらず、S-CBT の Speaking は2回ともボーダーラインを超えていた。修練している部分は結果に出ているし、そうでない部分は勉強が必要というごく自然な結果だろう。 休眠期間を除き基本的にはほぼ毎日レッスンを受けてきたが、以前と比べるとやはり上達を実感しづらくなっている。語学は費やした時間とその濃度だと思っているが、変数の1つとしてネイティブの英語にふれる機会を増やすべくスタンダードプランからネイティブプラスプランに変更した。もちろん、予習復習といった受講の仕方や YouTube チャネルなどを活用するなどのアプローチはある一方で、量という意味で1日1レッスンではなく、1日2レッスンにするなどをしていくことも必要かもしれない。https://1000ch.net/posts/2022/look-back-over-2022/Mon, 26 Dec 2022 00:00:00 +0000https://1000ch.net/posts/2022/look-back-over-2022/すっかり文字を書く時間を取れていない。仕事でドキュメントを読み書きする時間はたくさんあるのだが、ブログを書くことからはすっかり遠ざかってしまっている。そのためのインプットとなる学業や読書の時間は取れておらず、かといって業務上で学びが無いわけでは決してなく、むしろたくさんのことを学習している感覚はある。つまるところ業務外かつ娯楽的に学ぶ領域に時間を使えていないので、時間の配分は見直す必要がある。 2021 年の振り返り 2020 年の振り返り 2019 年の振り返り 本業でやっていたこと 引き続きマネジメント業務が中心にありつつ、経営へコミットしてきた1年だった。事業会社として達成したい価値提供、営利企業として達成しなくてはならない利益、開発組織として実現したいモノづくりの姿、様々な要素のバランスを探ってきた。人間がやることなので究極的には確固たる未来予測はできない中で、知識と経験から成される戦略精度は言うまでもなく重要でありつつ、それ以上に描く組織像に向かって統率する自信や覚悟の重要性、みたいなものをうっすら感じながら仕事に向き合った1年だった。 GroundUP App プロジェクトのリード 2022 年に担当したプロジェクトとして GroundUP App プロジェクトがある。これは昨年にリリースを達成した GroundUP Web の姉妹プロジェクトで、始まったのはほぼ同時期だったものの、規模や複雑性は事業的にもシステム的にも更に難易度が高かった。 ＼#MerpayAdventCalendar 13日目／ VPoE @1000ch による「メルカリアプリのコードベースを置き換える GroundUP App プロジェクトの話」です。https://t.co/ofkI4keN5x — Mercari_Dev (@mercaridevjp) December 13, 2022 Merpay Tech Fest 2022 のキーノートでの登壇 Merpay Tech Fest 2022 のキーノートは、3人の Engineering VP によるセッションで、CTO がメルペイエンジニアリングのこれまでを総ざらいしつつ今後の展望について話した後、パネルディスカッションが行われた。セッション内容はエンジニアリングブログに書き起こされているので、興味がある方はどうぞ。 【#MerpayTechFest 2022 書き起こし記事】 「メルペイエンジニアリングのこれまでとこれから」と題して、今後フォーカスしていきたいチャレンジ領域についてCTO, VPoEの３人（@nozaq @hidek @1000ch）がお話した内容です。 ▼詳細はこちら。動画もあわせてご覧ください。https://t.co/wcRsVzFkzk — Mercari_Dev (@mercaridevjp) October 19, 2022 LINE/メルペイ/一休 フロントエンドエンジニア採用説明会への出演 LINE、メルペイ、一休の三社合同でフロントエンドエンジニア向けの採用説明会に出演した。メルペイの事業の歩みと現状、そこへのフロントエンドの関わり方について網羅的かつコンパクトに話しつつ、その後のパネルディスカッションでは LINE 福島さんと一休 naoya さんとともにパネルディスカッションを行った。こちらもエンジニアリングブログとログミーそれぞれに書き起こし記事があるので、興味がある方はご覧いただければ。 2022/10/6 に行われた「LINE/メルペイ/一休 フロントエンドエンジニア採用説明会」のメルペイ・メルコイン部分を書き起こして頂きました。事業の概況・チームの状況などが、網羅的に書かれています！ / “【書き起こし】メルペイ・メルコインの紹介【フロントエンドエンジニ…” https://t.https://1000ch.net/posts/2022/bought-in-2022/Sat, 24 Dec 2022 00:00:00 +0000https://1000ch.net/posts/2022/bought-in-2022/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの 2020年に買って良かったもの 2021年に買って良かったもの Anker 737 Charger (GaNPrime 120W) 新製品が出る度にチェックしてしまう Anker の充電機器だが、Anker 737 Charger は単一ポートの最大出力が 100W という、これまでの製品では類を見ないレベルの高出力を誇る。実際にモバイルデバイスや MacBook Pro を充電してみても 速度を体感できるくらいの高速充電 で、家を出る 10 分前に充電するだけでもある程度補給できるし、折りたたみ可能なプラグで持ち運びにも便利なので携帯用途としても抜群に優秀である。 3台まとめて急速充電： 2つのUSB-Cポートと1つのUSB-Aポートを搭載し、これ1台で幅広い機器を3台同時に充電できます。 ※単ポートでの最大出力は100Wとなります。 “同時” 急速充電という、新常識。Anker GaNPrimeシリーズ：Anker独自技術「GaNPrime」を採用し、GaN搭載充電器が前シリーズから進化 超高出力 & 小型化に成功しながら複数ポートへの充電の最適配分と更なる安全性も実現しました。 PowerIQ 4.0搭載： Anker独自技術PowerIQが4.0へ進化。 更なる高出力への対応に加え、複数の機器への出力を最も効率の良い形に自動配分する機能を備えています。 コンパクト設計： 一般的な96W以上の充電器と比較して約40%小さなコンパクトサイズを実現。折りたたみ式プラグで持ち運びにも便利です。 最近東京駅に行った時に偶然 Anker の路面店を発見したので訪れたところ、こちらのポケモンコラボモデルを発見した。最も強力な 120W は進化形態であるライチュウで、真ん中の 65W はピカチュウ、最もコンパクトな 20W はピチューということで、理解できる製品ラインラップではありつつ、「120W 出力のピカチュウモデルが欲しい！」というニーズは一定あるだろうなと思った。 3台まとめて急速充電： 2つのUSB-Cポートと1つのUSB-Aポートを搭載し、これ1台で幅広い機器を3台同時に充電できます。 ※単ポートでの最大出力は100Wとなります。 “同時” 急速充電という、新常識。Anker GaNPrimeシリーズ：Anker独自技術「GaNPrime」を採用し、GaN搭載充電器が前シリーズから進化 超高出力 & 小型化に成功しながら複数ポートへの充電の最適配分と更なる安全性も実現しました。 PowerIQ 4.0搭載： Anker独自技術PowerIQが4.0へ進化。 更なる高出力への対応に加え、複数の機器への出力を最も効率の良い形に自動配分する機能を備えています。 コンパクト設計： 一般的な96W以上の充電器と比較して約40%小さなコンパクトサイズを実現。折りたたみ式プラグで持ち運びにも便利です。 Aer Fit Pack 3 Aer は去年スリングバッグを購入しているが、使い勝手が良かったので今度はバックパックを購入してみた。衣類なども収納できるフロント部分のポケットに加えて、MacBook Pro 13inch やその他の雑多なものを収納できるポケット、トップ部に小物を収納できるポケット、ボトム部にシューズを収納できるポケット、あとはペットボトルなどを収めるホルダーが左右についている。https://1000ch.net/posts/2022/my-engineering-career/Fri, 23 Dec 2022 00:00:00 +0000https://1000ch.net/posts/2022/my-engineering-career/技術顧問として関わっている企業にて「エンジニアのキャリア形成について LT して欲しい」というリクエストを頂き、自分のキャリアについて振り返る機会は今までなかったなと思いながら振り返った。 キャリア初期（SIer への新卒入社、事業会社へ転職、対外活動） 新卒で SIer にジョインしたところからエンジニアとしてのキャリアは始まった。もともと強い学習動機がなく入学した理学部だったため早々に研究の道に進まないことを決めたので、中学生の頃から触れていたインターネットを出発点に「手に職が付けれて、自分の想像力次第でプロダクトを生み出せる」という、まずまず単純な理由でエンジニアリングを志した。 受託開発が主な事業内容で、いわゆるデスマーチも味わった中で、より良いエンジニアリングを目指して事業会社への転職を決意する。当時、1年間で100個の Web サービスを立ち上げることを掲げて大量にエンジニアを採用していたサイバーエージェントに運良く拾って頂き、そこから Web 技術に没頭する日々を送ることになる。面接で出会った @cssradar 氏に師事しながら、Frontrend という Web Frontend 技術者向けのイベントに登壇することになり、そこからブログや書籍の執筆、イベントでの登壇といった対外活動に勤しむようになる。 キャリア中期（個人から組織への視野転換、労働に対する志向性） そうこうするうちに、メディア部門での事業開発からゲーム部門の横断組織への異動が決まり、いわゆる横軸活動に取り組むようになる。業務性質上、自分のアウトプットの量や質を高めるところから他者のそれにフォーカスすることになる。思い返せば、関心が個人から組織にシフトし始めたのはこのタイミングが原点だったように思う。 事業部の大再編などを経てアメブロの事業部に異動することになり、この辺りからエンジニアの評価業務などに関わり始めるようになる（当時はいわゆるマネージャという役割が存在せず、上位グレードのエンジニアが評価者になっていた）。当時強い関心を持って取り組んでいた Web パフォーマンスについて、半ば勝手にプロジェクト化してアメブロでも取り組んでいたら幸いにも評価され、事業部の最優秀エンジニア賞を受賞することもあった。 その後横断組織を立ち上げて、採用・評価・育成といったマネジメントに取り組むようになり、よりエンジニアリング組織という部分にフォーカスしていくことになる。 キャリア後期（チーム、部門、そして会社のマネジメント） メディアやゲームの事業開発、横断組織での横軸活動、Web エンジニアリングの強化を志した組織の立ち上げや人事業務などを含め様々なことをやってきた中で、より自分ごと化できる事業領域を志すようになる。世の中に対して自分なりに感じる社会課題の中に当時勃興し始めていたキャッシュレス領域があり、既に C2C マーケットプレイスとして成功を収めていたメルカリがそこに取り組んでいくという話を伺い、またとない機会だと考えて転職を決意する。 メルペイは会社が設立されて間もないタイミングでまだ組織らしい組織になっていない状態だったので、私への期待値もチームの組成だった。そこでメルペイの Frontend チームの立ち上げをしたり、ある程度落ち着いてくると Web 版メルカリの刷新プロジェクトやアプリ版メルカリの刷新プロジェクトなどを任されるなど、様々な大波を経験してきた。 キャリアの変革点はどこにあったか もちろんキャリアは人それぞれで一般化を試みるものではないが、自分のキャリアにおいて大きな転換点はいくつかあった。 SIer から事業会社への転職 → 自らが期待する技術者像への成長を支援してくれる環境に身を置くことの重要性 研鑽しあえる仲間や師事できるロールモデルの発見と対外活動 → 対内外へ認知されることの重要性、発展してより優れた技術や思想を啓蒙することの面白さ エンジニアから各層のマネジメントまで、様々な役割の経験 → エンジニアリングを軸にしながらも近接する役割を幅広く経験したことによる弾力性および希少性 これらは、私が最初のキャリアでエンジニアリングを志した時と同じように、中長期目線で計画できていたものではなく、その時々の想いを実現に向けて行動してきた結果である。 短い時間軸で高い地点を目指すのであれば相応の高さのハードルになるし、長い時間軸であれば同じ地点を目指すにも段階的に物事を進められるというのは想像に難くない。つまるところ、タイムスケールに差はあれど「現在地から目標地点までのギャップをどう埋めていくか」という話に帰結し、その時間軸が短ければ演繹的なキャリア形成に、長ければ帰納的なキャリア形成になるという話だと認識している。 たぶんこんな PDCA その現在地からゴール地点に到達するまでの道のりは、突き詰めるとこういう PDCA になるように思う。 1. 環境を選択する 環境を選ぶということは誰しもがやっている。それは就職や転職での会社選びや自らの専門性をどこに置くかといった大きな意思決定だけでなく、会社においてはどのプロジェクトに配属されるか（あるいは自ら手を挙げるか）、はたまた副業・コミュニティなどを通じて異なる環境で活動するなど、非常に様々なものが含まれる。 自分が選んだ環境に応じて「その環境における自分への期待値」が決まる。 2. 専門性を拡張する 選んだ「環境で求められる期待値」に対して何らかの能力を発揮することが求められる。エンジニアリングを例にすると、特定領域の技術力といった専門性を始めとして、各種マネジメントを含む様々なヒューマンスキルなど、総合的な業務遂行能力が問われているはずである。 その「環境からの期待」に応えられている事実が、その「環境における評価」に他ならない。できることが多い人はより多くの期待に応えられるので評価が高い。言わずもがな組織はそうした人材を求めるので、高い期待値を設定し、できることを伸ばす・増やすことをマネジメントを通じて求める。そして、その「期待値とのギャップを埋めることが成長」である。 3. 期待に応える 自分が培った能力を以て環境からの期待に応えていく、その「期待値を超えた上積み」が「その環境における評価の向上」であり、会社であれば対価として給与が上がったり、コミュニティにおいてはより多くの認知を得る、などに繋がっていく。 重要なのは、優秀で上長から信頼されている人が更に大きな仕事を任されるように、期待に応えることで「次に選択できる環境が増える」ということだ。そうすると、より大きな「その環境における自分への期待」に向き合う機会を得られる。そのため、自分に何が期待されているのかを正確に理解すること、つまり期待値の解像度が高ければ高いほど良いのは言うまでもない。 納得できる選択をし続けるために 私は幸運なことに、ソフトウェアエンジニアとしては事業開発から組織の立ち上げを含む横断的な活動、マネジメントでもチーム・部門・経営という様々なレイヤでコミットする機会があり、幅広い経験をしてきた。しかし、前述の通り、数ヶ年のキャリアを計画してギャップを埋める努力をしてきたというよりは、その時々で課せられた期待値を理解して応える努力を繰り返してきた、その結果として今があるという方が正しい。 You can’t connect the dots looking forward; you can only connect them looking backwards.https://1000ch.net/posts/2022/line-merpay-ikyu-hiring-event/Thu, 17 Nov 2022 00:00:00 +0000https://1000ch.net/posts/2022/line-merpay-ikyu-hiring-event/2022年10月6日に開催された LINE・メルペイ・一休の三社合同のフロントエンドエンジニア採用説明会に出演した。LINE は福島さん、メルペイは私、一休は naoya さんから、それぞれ会社の事業状況やそれらに対するフロントエンド領域の関わり・課題・魅力などについてセッションがあった。 メルペイのパートで私が話した内容はエンジニアリングブログに書き起こしていただいた。会社や事業の概況、ミッション、フロントエンドの開発体制や技術構成、課題や取り組みなど、2022年11月時点のスナップショットとしてまずまず網羅的にまとまっているので、興味のある方はご覧頂きたい。 また、3社のセッションの後はモデレータを交えて、パネルディスカッションが行われた。技術や組織の課題・求める人材像（マインド・スキル要件）・評価や育成などのマネジメントトピックについて肩肘張らずに議論し、特に組織運営について共感できる部分が多かったのと、フロントエンドエンジニアというキャリア選択についても需要が減ることは考えづらく、むしろ重要度は増していくだろうという話もあった。こちらのパネルディスカッションについてもログミーにて書き起こしていただいているので、是非ご覧ください。前編後編の2記事です。 先日 @linecorp_jp @merpayinc @ikyu_saiyo の合同で行われたフロントエンドエンジニア採用説明会のパネルディスカッションを @logmi_tech で書き起こして頂きました / “採用時に見ているのは技術と、経歴よりもコミュニケーション能力　LINE・メルペイ・一休の入社前後の…” https://t.co/UQrZK7picn — Shogo 🍵 (@1000ch) November 16, 2022https://1000ch.net/posts/2022/merpay-tech-fest-2022/Wed, 24 Aug 2022 00:00:00 +0000https://1000ch.net/posts/2022/merpay-tech-fest-2022/先日 Merpay Tech Fest 2022 が開催された。 Merpay Tech Fest はメルペイの事業を支える技術や組織といったエンジニアリングの取り組みを紹介するカンファレンスだ。2022年8月21日から3日間かけて開催され、エンジニアリング全体を総括するキーノートに始まり、プロダクト開発に関わるチームから様々な取り組みについて発表があった。また、今年はトークセッションだけでなく視聴者参加型のコンテンツとして、コードベースに仕込まれているバグを参加者が協力して直すといった、体験型ワークショップも開催された。 私は初日のキーノート「メルペイエンジニアリングのこれまでとこれから」というセッションの後半に出演したのと、最終日のクロージングトークを担当しました。クロージングトークでも話した通り、ここまでのメルペイの歩みを支えるエンジニアリングについて、視聴者の皆さんに知ってもらう機会になったこと、そして我々としてもそれを振り返りこれからに繋げる良いきっかけになった。セッションは書き起こし記事もありますので、宜しければご覧ください。https://1000ch.net/posts/2022/lg-ultrafine-display-27inch/Mon, 20 Jun 2022 00:00:00 +0000https://1000ch.net/posts/2022/lg-ultrafine-display-27inch/MacBook Pro (M1, 2020) 単品の運用で目立った不満があったわけではないが、USB type-C のポートが2つしかないので、基本的には給電しっぱなしであることを加味すると、残りのポートにマイクを繋げて終了という状況だった。あとは、大きい画面のほうが作業が捗るのはもちろんありつつ、ラップトップのディスプレイを見るとどうしても前かがみな姿勢になってしまうので、肩こりなどの原因になっている自覚が少なからずあった。 ということで、これらの問題を解消してくれるディスプレイとして、LG UltraFine 5K Display 27インチを購入した。もとい、友人がちょうど手放そうとしていたという偶然が重なり、譲り受けることができた。 4Kの約1.5倍となる5K（5120×2880）解像度の広大な表示領域、鮮やかで自然な色再現が特長とする、218PPIの高精細IPSパネルを搭載。DCI-P3 99%の広色域と500nitの高輝度にも対応。高精細で色彩豊かな表現で、実物そのままのリアルな写真や映像、くっきりしたシャープな文字の表示を可能に。USB3.0の8倍もの転送速度40Gbpsを実現するThunderbolt3を搭載。5Kの映像、音声、データの転送と同時に最大94Wまでの充電が可能。macOSに最適化されたディスプレイコントロールで、モニター側のボタンを使用することなく、macOSから輝度や音量、詳細なディスプレイ設定が可能。また、MacBookに接続すると、MacBookの周囲光センサーと連動してモニターの明るさも自動的に調整。迫力ある低音を実現するRich Bassを備えた5W+5Wのスピーカー、webカメラ、マイクを搭載。映像鑑賞だけでなくビデオチャットなどにも最適。 Apple お墨付きのセミオフィシャル的なディスプレイとしてストアでも販売されている。2018 年の発表当初は 4K モデルと 5K モデルが販売されていたが、今は 4K モデルのみをストアで取り扱っているようで、おそらく Apple Studio Display などのラインナップとも関係していると想像している。私が入手したのは 5K モデルだ。 Thunderbolt3 ポートと USB type-C ポートx3 がある MacBook Pro を Thunderbolt3 ポートに接続することで映像出力や給電をカバーできる USB type-C 接続の Anker の外付けマイク を接続できるため、MacBook Pro とマイクを都度付け外す必要がない 自分の場合は Bose のワイヤレスイヤホンを使っているが、有線のヘッドホンを使う場合もディスプレイと接続しておける 高性能な Web カメラが内蔵されている 会議等の用途に対して十分な性能であり、外付けカメラが必要ない 5K の解像度で、画面が美しい 自分にとっては 4K でも十分美しくどれだけ差があるのかという話はあるが、美しい 高音質で声をお届け：クリアな音を届けられる96kHz / 24bit対応の高音質のコンデンサーマイクです。大型コンデンサーマイク搭載：不要なノイズを防ぎながら一つの方向から集中的に集音することで声を逃さない単一指向性を持った、高感度の16mmの大型コンデンサーマイクを搭載。息遣いまでのクリアな音を伝達できるため、ゲーム実況やポッドキャストなどの音声配信に最適です。集音レベルを調整可能：ゲインコントロール機能により声の大きさや本体との距離に合わせて最適化することで、聞き手にストレスを感じさせない最適な音量調整が可能。また、縦方向に180度、横方向に360度の回転が可能な構造を採用し、集音しやすい向きに自在に変えることができます。直感的な操作：本製品に同梱されているUSB-A またはUSB-Cケーブルでお使いの機器に接続するだけで、複雑な初期設定なく簡単に使用を開始できます。また、ダイヤル式のボタンで集音するボリュームを調整可能な他、本体のボタンを押すだけで簡単にミュートのオン / オフを切り替えることができます。他にも、本製品とヘッドセットを直接接続することで、自分の声を遅延なくリアルタイムに聴くことができ、音声配信時にご自身の声を確認しながら配信できます。パッケージ内容：Anker PowerCast M300、スタンド、USB-C&USB-C ケーブル、USB-C&USB-A ケーブル、クイックスタートガイド、安全マニュアル、最大24ヶ月保証 (※正規販売店からの注文に限り18ヶ月保証の対象となり、条件付きで+6ヶ月の延長保証が付きます。詳細は「出品者のコメント」をご確認ください。注文番号が保証書の代わりとなります。) ノイズキャンセリングイヤホン - 世界でもっとも効果的なノイズキャンセリングテクノロジーと周囲の音を認識できるAwareモード搭載。ハイ・フィデリティオーディオ – 独自の音響構造により、音楽、ポッドキャスト、ビデオで臨場感あふれるサウンドを実現。音量に合わせて最適化されるアクティブEQにより、どんな音量でもバランスのとれたサウンドを実現。快適で安定した装着感のワイヤレスノイズキャンセリングイヤホン – 3サイズのStayHear Maxチップを付属。安定した装着感を実現します。柔らかなシリコン素材を採用、快適で安定した装着感とともにパッシブでもノイズをブロック。シンプルなタッチコントロール – タップ、タッチ、スワイプで操作も簡単。イヤホンをタッチするだけでノイズキャンセリング強度を選択、音楽の再生 / 一時停止、音量調節が可能です。イヤホンを長押しするだけで、Spotifyの前回聴いていたコンテンツにすばやくアクセス。ノイズリジェクティングマイク –超小型マイクが周囲のノイズをフィルタリング、あなたの声にフォーカスしてクリアな通話を実現します。ロングバッテリーライフ — 1回の充電で最大6時間の連続再生が可能。充電ケースを使用することで、さらに12時間の再生が可能に。ケースは付属のUSB-CケーブルやQi規格の充電マット（非同梱）で充電できます。防滴仕様 – 汗や突然の雨にも安心のIPX4防滴仕様。https://1000ch.net/posts/2022/techfeed-conference-2022/Fri, 03 Jun 2022 00:00:00 +0000https://1000ch.net/posts/2022/techfeed-conference-2022/掲題の通り、2022年5月14日に開催された TechFeed Conference 2022 で Web Standards Interop 2022 というタイトルで Web 標準技術の相互運用性について発表した。セッション資料とセッション動画があるのと、今回はありがたいことに記事として書き起こしていただいた。 事前練習のファーストテイクで 15min 程度かかったので、「これはまずい」ということで大幅に圧縮したバージョンがこちら。ぶっつけ本番で挑まなくて本当に良かった。 TechFeed はエンジニア向けの技術情報プラットフォームで、鮮度の品質の高い技術情報がキュレートされて配信されている。技術情報を集める手段は RSS を使ったり Twitter を眺めるなど色々あるが、各分野のエキスパートが関心を持っている情報や、より多くの人が注目している情報が優先されるようになっており、より低コストで高品質な技術情報を集めるためのプラットフォームと言える。「RSS を管理するのが面倒！」「Twitter では雑音が多い！」という方に良さそう。 TechFeed では2021年9月にもトライアル企画にお呼ばれしていて、Web 標準技術のエキスパートということでその時も最近の Web について話している。結果的に、今回のカンファレンスではその延長線にあたるセッションになった。https://1000ch.net/posts/2022/tokyo-sakura-marathon/Sun, 10 Apr 2022 00:00:00 +0000https://1000ch.net/posts/2022/tokyo-sakura-marathon/新型コロナウイルスのパンデミックになってからというものの、身体を動かす機会が劇的に減っていたので、危機感からランニングを再開した。走ってみた時期はあったものの断片的で、今回は習慣として定着した感覚がある。 折角コンスタントに走っているので、何かわかりやすい成果があると良いなと思っている最中 @stormcat24 氏にそそのかされ、第3回 東京さくらマラソンに参加することになった。 そもそも普段のランニングで 10km をぶっ続けで走ることがないので不安を覚えながらも、10km を 54:22 と思ったほど悪くないタイムで完走できた。今回の大会参加でまんまと味をしめたので、定期的に大会へ参加していきたい。日々のランニングも、走行距離を長くして運動負荷を徐々に高め、どこまでタイムを伸ばせるのか楽しみである。 昔、いわゆる学生時代に想いを馳せると、中学生の時に駅伝競走に参加していたことを思い出す。当時は 3km 弱を 10min 程で走っていた記憶（記録）があり、若かったとはいえ 3:40~3:50/km ぐらいのラップを刻んでいたのは恐ろしい。今では 5min/km で結構キツいので、このペースで走れる距離を伸ばしていくことを差し当たっての目標にしてみる。https://1000ch.net/posts/2021/look-back-over-2021/Fri, 31 Dec 2021 00:00:00 +0000https://1000ch.net/posts/2021/look-back-over-2021/ずっと忙しくて筆を執って書き留めるゆとりを持てなかったことは 2021 年最大の反省だが、今年が終わってしまいそうなので駆け込みで書いておく。 2020 年の振り返り 2019 年の振り返り 本業でやっていたこと 引き続きマネジメント業務の比率が高かった1年だった。自分が Web 畑でエンジニアリングが好きという根底はありつつ、最近の業務はマネジメント中心という話をすると意外に思う人もいるようだ。これは前職時代のアウトプットの傾向がエッジな技術に依っていたことが影響していると思うが、思い返してみれば前職からずっと組織づくりに関わってきた。 メルカリ Web のリード 2021 年もいくつかの社内プロジェクトをリードしてきた。2021 年より前に始まったプロジェクトだが、今年お披露目できたものとしては新しいメルカリ Web がある。様々な経緯やお気持ちも含めてブログに書いてあるので詳細はそちらに預けつつ、テクニカルな部分以上に組織的な段取りがポイントなプロジェクトだった。 本記事は新しいメルカリ Web についてまとめています。 この大きなプロジェクトのリリースは、多くの人の多大なる貢献によって成されたものです。そのプロジェクトの立ち上がりから今日まで、リードする役割でプロジェクトを見てきた一部始終を記録するべくまとめます。https://t.co/w4sKwxuIf5 — Mercari_Dev (@mercaridevjp) August 10, 2021 「数え切れないほどの試行錯誤と協力」を経て──新Web版メルカリのリリースを担当したメンバー21名の“今の気持ち” | mercan (メルカン) https://t.co/5DCFoQnydi — mercan（メルカン） (@mercari_team) September 1, 2021 メルペイのエンジニアリング組織のマネジメント メルカリ Web のリードの傍らメルペイではクライアントサイドのエンジニアリングを担当した。こちらも大きなプロジェクトが進行しているので、別の機会にアウトプットできるかもしれない。 メルペイのクライアントサイドでやっていることを書きました。図らずも #FELounge (https://t.co/HN22IePNkb) 向けの内容になりましたが、本番ではモチベーションの部分を話そうと思います。 / “メルペイのクライアントエンジニアリングの話” https://t.co/80FK600ebT — 1000ch (@1000ch) December 6, 2021 あとは、僭越ながら技育展 2021 の審査員を担当させていただいたり、メルペイやメルコインの会社説明会でメルカリグループ全体の事業や組織についてお話しさせていただいた。 副業でやっていたこと 2021 年も本業以外にいくつかのエンジニアリングチームとお仕事をすることができた。どちらも優秀なエンジニアを募集しているので、興味がある方はお気軽にご連絡ください。 ドクターズプライムでの広報活動の推進 その1つがドクターズプライムでの技術顧問である。ソフトウェアそのものの中長期方針についても議論しつつ、それを維持していくための体制作りという意味で、採用や広報戦略について考える時間も多かった。マーケティング業務の経験はないが、それでも認知されないことには始まらないので「（エンジニアリングに限らず）組織のことを知ってもらいましょう」という旗振りをしてきた。特に 12 月は @oinume さんの声がけでアドベントカレンダーも走破している。凄い。 「救急車のたらい回しが起きてしまう救命医療の構造上の問題を @drsprime がどのように解決しているか」は、とても面白い部分だと思います。Web フロントエンドの現状も含めて、興味がある方はお気軽にご応募ください！ https://t.https://1000ch.net/posts/2021/bought-in-2021/Thu, 30 Dec 2021 00:00:00 +0000https://1000ch.net/posts/2021/bought-in-2021/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの 2020年に買って良かったもの Kindle Paperwhite 第11世代 Black Friday でセールになっていたので買ってみた。買ってはスマートフォンの Kindle アプリに戻ってを繰り返していたので、Kindle Paperwhite を買うのは初めてではない。スマートフォンだと他のあらゆることを出来てしまうが故に気が散ることもあるが、Kindle 端末の良いところは読書しかできないので集中を強制してくれる。 新しくなったKindle Paperwhite。前モデルに比べ、20％早いページ送りで、大きくなった6.8インチのディスプレイ 読書のための専用端末。フラットで300ppiの高解像度ディスプレイで、小さな文字もくっきりキレイ。大きく、紙のような読み心地のディスプレイで、反射をおさえているから目に優しい USB-Cケーブルを使った一度のフル充電で、最大で10週間利用可能 新たに色調調節ライトを搭載。ホワイトからアンバーに色の暖かさを調節可能で、あなた好みの読み心地を 防水機能搭載でお風呂でもプールでも読書を 純正のカバーではないが、ある程度軽いマグネット付きのカバーでオートスリープ機能にも対応している。 2021 Kindle Paperwhite Newモデル第11世代6.8インチに適応します。他の機種の場合は、上記のモデルとサイズを比較してください。 このKindle Paperwhite2021カバーは高品質なPUレザーとマイクロファイバーを材料として、心地よいすり手触りを与えます。 Kindle Paperwhite2021ケースは多くの機能があります。マグネット機能付き、オートスリープ機能付き、またケースを入れたまま充電ができ、カバーから取り出さずにスマートに充電できます。 Aer Tech Sling 2 中田が最近「買ってよかったもの」BEST7 を見て Aer というブランドを知り、普段使い用にスリングバッグ買ってみた。動画で紹介しているバックパックも良さそうで、衝動的に買ってしまう可能性がある。 使い始めて間もないが、使い勝手が良く気に入っている。前述の Kindle Paperwhite はもちろん、MacBook Pro 13inch も入るサイズで、2つのメインポケットに加えて小物を収納する小さなポケットもある。購入直後は止水ジップがやや固く感じたが、徐々に柔らかくなってきた。 【生産国】中国 【素材】ナイロン 【仕様】耐摩耗性840Dナイロンカーボネートポリウレタンコ ーティング(表地)/1680Dコーデュラバリスティックナイロン(一部)/ファスナー開閉(日本製YKKジップ)/DURAFLEXプラスティックハードウエア/高級感のある柔らかな裏地/パッド付きノートPCポケット(13インチまで)/柔軟性裏地のバックポケット/アクセサリー用マルチインナーポケット/高汎用性スリングストラップ Anker PowerPort III 2-Port 65W 外出時にも持ち歩けるように Anker Nano II 65W を使っているが、ポートが1つなので家に常設しておくには少しだけ心許ない。が、そこを解決してくれたのが Anker PowerPort III 2-Port 65W だ。USB-C のポートが2つあり、プラグも折り畳めて、小さい。https://1000ch.net/posts/2021/wdpress-omnibus/Sun, 01 Aug 2021 00:00:00 +0000https://1000ch.net/posts/2021/wdpress-omnibus/WEB+DB PRESS総集編の書き下ろし特別企画「進化するプログラミング言語の魅力」で、JavaScript について寄稿しました。 書き下ろし特別企画「進化するプログラミング言語の魅力」で、JavaScript の歴史や進化の変遷について寄稿しました。WEB+DB PRESS の総集編ということで、Vol.1~120 という #wdpress の 20 年分が詰まった超お得な一冊です📚 https://t.co/sF98be039Q https://t.co/9LgKqP5vFf — Shogo (@1000ch) August 2, 2021 特別企画だけでなく、WEB+DB PRESS の 20 年間(!)が DVD として PDF で同梱されているようです。特別企画ではいくつかのプログラミング言語の歴史と進化について書かれていると思いますが、それに加えて 20 年間で盛衰を繰り返してきた様々な技術の変遷についてインプットできる一冊なので、とてもお買い得な一冊だと思います。是非皆さんお買い求めください。 泉水 翔吾 (著), 櫻庭 祐一 (著), 宇佐美 健太 (著), 笹田 耕一 (著), 牧 大輔 (著), 末田 卓巳 (著), 池田 翔 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2021/interview-on-codezine/Sat, 20 Mar 2021 00:00:00 +0000https://1000ch.net/posts/2021/interview-on-codezine/CodeZine で連載されている未来を創るエンジニアたちが見る世界の企画で、Yahoo! JAPAN のお二人と一緒にインタビューしてもらった。今回のお題は「サービスの価値を高めるフロントエンドとは」ということで、私のプロダクト開発に対するマインドセットやそれを踏まえてメルカリやメルペイでどのように活動しているかを話した。 Yahoo! JAPAN とメルカリ・メルペイにおけるエンジニアリング組織や、行っている取り組みなどについて話しました。改めて見ると所々で主語が大きめですが、それとなく雰囲気が伝わると嬉しいです / “エンジニアに求められるのは「品質に向き合う力」――ユーザー価値向上のた…” https://t.co/6fgV5p6fI6 — Shogo SENSUI (@1000ch) March 18, 2021 最近では Yahoo! JAPAN でもアクセシビリティに積極的に取り組んでいるようで、自然と品質に関する話題が中心になった。ライブラリやフレームワークのトレンドに依存しない「（自分が考える）優れたエンジニアリングとは何か？」を話す機会がたまにあるが、それを言語化してもらえた。 翔泳社の近藤さん、Yahoo! JAPAN の皆さん、貴重な機会を頂きましてありがとうございました。https://1000ch.net/posts/2021/input-suggestion-multiple-value/Sun, 14 Mar 2021 00:00:00 +0000https://1000ch.net/posts/2021/input-suggestion-multiple-value/<input type="text"> の入力補完は <datalist> 要素と組み合わせることで簡単に実現できる。ただし、これは単一の値に対する補完で、複数の値を入力しようとしたときに適用されない。というのも、ブラウザとしては <input> 要素の value プロパティをひとつの値として扱い、それを <datalist> 要素の入力候補と比較しているため、当たり前といえば当たり前である。つまり <input> 要素に複数の値を保持するという概念がそもそもない。 次のデモは <input type="text"> と <datalist> 要素を組み合わせた挙動である。 <input> 要素の list 属性に、<datalist> 要素の id 属性の値を指定している。 See the Pen <input type="text"> and <datalist> by 1000ch (@1000ch) on CodePen. 今回やりたいのは、ひとつの <input> 要素に対して、何らかの区切り文字を含めて複数の値を入力するようなユースケースである。これを実現しているのは jQuery UI の Autocomplete だが、ライブラリを用いず HTML だけで再現したい。 色々調べていると、 <input> 要素の中でも <input type="email"> は特殊なようで1、 multiple 属性と組み合わせることで、期待している挙動を実現できた。次のデモではカンマ (,) を区切り文字として、複数の値に対して <datalist> 要素による入力補完を受けられる。 See the Pen <input type="email" multiple> and <datalist> by 1000ch (@1000ch) on CodePen.https://1000ch.net/posts/2021/10000min-on-dmm-eikaiwa/Fri, 12 Mar 2021 00:00:00 +0000https://1000ch.net/posts/2021/10000min-on-dmm-eikaiwa/2019 年の8月頃から DMM 英会話を使って英語学習を続けており、つい先日レッスン時間が 10,000 分に到達した。1レッスン 25 分なので、10,000 分までに 400 レッスンを受けたことになる。毎日受講しても1年1ヶ月かかることになるが、自分の場合は、ほぼ毎日受講してきた中で約1ヶ月間のスランプに2回程陥っていたりして、結局1年半かかった。 constantly, consistently or continuously. pic.twitter.com/dpA0YsN27A — Shogo SENSUI (@1000ch) March 12, 2021 他にも週に n 時間のコミットが求められている会社の英語学習プログラムを受講していたり、通常業務においてもコミュニケーションが英語ベースのプロジェクトを担当しているので、英語に触れている時間でいえばもっと多かったのは間違いない。尚、英語学習プログラムは社内の Language Education Team、通称 LET という部署が提供しており受講できる人数に制限があり、自分の英語力がプログラムのゴールである CEFR における B2 というレベルに到達したため卒業した。https://1000ch.net/posts/2020/look-back-over-2020/Thu, 31 Dec 2020 00:00:00 +0000https://1000ch.net/posts/2020/look-back-over-2020/今年も振り返り記事を書いてみる。2020 年は誰も予想できなかったような事態になったこともあり、例年よりあっという間に過ぎてしまった感覚がある。 2019 年の振り返り 本業でやっていたこと Merpay Frontend のこれまでとこれからという記事でも触れたが、メルペイとメルカリの両組織にまたがって仕事をしている。役割としては引き続き Software Engineer と Engineering Manager を兼務していて、エンジニア成分がゼロにならないよう現場での開発にも関わるように意識している。 メルペイアドベントカレンダーの 22 日目を担当しました✅メルペイの Frontend チームについて書いてます📝 / “Merpay Frontend のこれまでとこれから | メルカリエンジニアリング” (1 user) https://t.co/myLHJG6Ww4 — Shogo SENSUI 🙂 (@1000ch) December 21, 2020 役割が複数あることに加えて関わっている組織やチームも多く、コンテキストスイッチのコストが高く難しい。当然ながら、それぞれに割く時間も分散されるので、これが効率が良い形なのかと自問自答すると、たぶん Yes ではない。それでも解くべき（解きたい）問題を解くためにはこのような関わり方がベストだと判断しているのでそうしている。 そういえば 2020 年始にはこんなインタビュー記事も公開されていた、懐かしい。 移ろいが激しいWeb周りの技術を、どうやってキャッチアップしてるの？ 今回のエンジニア立ち話には、メルペイエンジニア@1000chが登場。開発はもちろん、クオリティやパフォーマンス改善、アクセシビリティの啓蒙も行う理由をメルペイVP of Engineeringの@hidekが聞きます！https://t.co/bczE5yKkI2 — mercan（メルカン） (@mercari_team) January 20, 2020 メルペイの Frontend チームを育てるとともに、メルカリでもチームを持ちつつ、とある Web プロジェクトをリードしている。こちらで取り組んでいることも記事にする予定なので、興味がある方はもう少しお待ちください。 副業でやっていたこと 本業以外の部分では、副業もやっていた。Web アプリケーションの実装に関わることもチラホラあったが、技術顧問という立場でコミットすることが多かった。まとまった時間をコンスタントに割けるのであれば実装部分でも支援できるかもしれないが、稼働を安定させるのが難しい側面もあるのでアドバイザーという立場で関わるほうが双方にとって適切に思える。思い返せば「チーム・採用・開発体制・実装技術に関することを改善する」ことは、前職時代からやっていた。 チームの状態や抱えている課題も組織によって異なり、本業では向き合えない多種多様な問題に取り組めていることはとても貴重な経験である。ありがたいことに、2021 年も新しい組織に関われる予定なので、うまく時間配分しつつ貢献していきたい。露出を目的に技術顧問をするわけではないが、顧問先に還元することを目的に、組織でどういったことに取り組んでいるかをアウトプットする機会も作りたい。 #strobofm の運営 #strobofm は話したい人と話したいことを話すポッドキャストで、こちらも細々と継続している。あまり宣伝をしていないので知らない人も多そうだが、リスナーの数もじわじわと増えているので、暇つぶしには使ってもらえているのかもしれない。話題にこれと言って縛りはないが、時々の興味関心とそれに対する知識がスナップショットとして吐き出されていて、最近はコロナウイルス・英語・資産運用あたりのネタに寄っている。出演してくれるゲストの皆さん、いつもありがとうございます。 運営費用のカバーだけではなく、ゲストに何らかの形でお返しをするためにスポンサーを募っている。今のところ月払いのプランがあるが、割引ありの年払いができるような仕組みを Patreon が準備中のようで、これによって月 $1 で年 $12 のところを年払いだと $10 に割引されるといったオプションを用意できそう。https://1000ch.net/posts/2020/bought-in-2020/Fri, 25 Dec 2020 00:00:00 +0000https://1000ch.net/posts/2020/bought-in-2020/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの 2019年に買って良かったもの Google Pixel 5 いつでもベストな写真を撮影できるカメラ。昼でも夜でも、あらゆる瞬間を鮮やかな写真に。ハリウッド映画のような効果を演出したクリップも撮影できます。 ワイヤレス充電器にもなるスマートフォン。ワイヤレス充電対応で、長時間フル充電。スーパー バッテリー セーバーをオンにすると、電池が必要なときに最長 48 時間使用できるようになります。 セキュリティの脅威からも水滴からも保護します。防水仕様のメタルボディと超高機能セキュリティ チップでデータとデバイスを保護します。 Google アシスタントで外出先でも便利に。外出先でも頼れるアシスタント。Google アシスタントに何でも聞いてください。 Pixel 2 と Pixel 3 を 2018 年に、Pixel 4 を 2020 年に購入していたが、Pixel 5 も今年の 10 月に購入した。Pixel 3 は NFC に対応していたが FeLiCa に対応しておらず iPhone 7 に比べたときの劣化ポイントだった。また、Pixel 4 は FeLiCa に対応したものの指紋認証から顔認証に変更され、コロナ禍でマスクを着けているとかなり不便だった。 そして今年買った Pixel 5 は指紋認証の復活と電池容量の増加という、いわゆる順当な進化で特別何かが目立っていたわけではないが、堂々のベストバイだったと思っている。5G にも対応しているので、日本の通信キャリアが 5G の普及を進めてくれるのを待っている。その時は Pixel 6 が発売されているかもしれないが。 TP-Link Wi-Fi 無線LAN ルーター 11ac AC2600 [特徴] Archer A10にUSB3.0とセキュリティプログラム Homecareを搭載したアップグレードモデル。 [規格値] 5GHz: 1733 Mbps+ 2.https://1000ch.net/posts/2020/declarative-shadow-dom/Wed, 07 Oct 2020 00:00:00 +0000https://1000ch.net/posts/2020/declarative-shadow-dom/Shadow DOM は、代替要素を除いた任意の HTML 要素を DOM API で参照して attachShadow({ ... }) メソッドを呼び出すことで命令的に生成できる。これを新たに <template> 要素の shadowroot 属性によって、対象の HTML 要素の Shadow DOM を宣言的に生やせるようになる仕様が提案されている。既に Chrome 85 で試験的に実装されており、フラグ付きで利用できるようになっている。この記事は自分用にまとめたメモ。 Add declarative Shadow DOM features by mfreed7 · Pull Request #892 · whatwg/dom Add declarative Shadow DOM features by mfreed7 · Pull Request #5465 · whatwg/html declarative-shadow-dom/README.md at master · mfreed7/declarative-shadow-dom Chrome 85 以降のオムニボックスに chrome://flags/#enable-experimental-web-platform-features を入力し、 Experimental Web Platform Features flag を Enabled にして Chrome を再起動すると、有効化される。https://1000ch.net/posts/2020/yamaoku-neet/Tue, 22 Sep 2020 00:00:00 +0000https://1000ch.net/posts/2020/yamaoku-neet/きっかけはラジオとして流し聴きしている中田敦彦の YouTube 大学で、東京でニート生活をしている若者が和歌山の山奥に移住してニートをしているという実話を記録した書籍が解説されていた。 場所は和歌山の山奥にある限界集落で、もとより社会不適応に至っている人を集めて社会復帰を促進することを目的とした NPO 法人「共生舎」が設立した施設がある。廃校になった小学校が色々あってリフォームされ、そのニートの人達が住んでいる。もともとその集落にいた人達の仕事を手伝ったり、最寄りの駅周辺のビジネスのお手伝いをすることで収入を得ている。「週に何時間働く！」といった概念はなく、あくまで生活に必要な分だけ働いて、その他の時間はそれぞれが思い思いの時間を過ごしている。もっともこのご時世では、インターネットがあれば大抵のことは解決される。 ひきこもりとなって大学を中退し、ネットを通じて知り合ったニート仲間と2014年から和歌山の山奥に移住。以来、駅から車で2時間の限界集落に暮らしている。月の生活費は1万8000円。収入源は紀州梅の収穫や草刈りのお駄賃など。インターネットさえあれば、買い物も娯楽も問題なし。リモートの可能性をフル活用し、「なるべく働かず、面倒くさい人間関係から離れて生きていく」を実現したニートが綴る5年間の記録。 2014年に2人で始まった生活も、いまや15人~の生活共同体になり、この書籍や YouTube 大学による紹介によって、訪問者や入居希望者が耐えないそう。基本的には拒まないスタンスのようだけど、この「山奥ニート」での生活に合わない・沿わない人は出ていってもらう、あるいは自ら出ていくことも何度もあったようで、自浄作用が上手く働いているようである。 日本における東京の一極化はそれなりに問題で、こうした集いが限界集落を町村として蘇生させるような前例になればとても面白い。コロナウイルスは強制的にワークスタイルを変化させて地方回帰の兆しもほのかに見せている中で、政令指定都市だけでなくより過疎化が進んでいる地域の復興への後押しになって欲しい。 【山奥ニート①】なるべく働かずに楽して生きていく 【山奥ニート②】実は時代の最先端を走る生き方https://1000ch.net/posts/2020/yametemita/Sun, 20 Sep 2020 00:00:00 +0000https://1000ch.net/posts/2020/yametemita/最適化が好きな自分にとって、共感の多い一冊だった。炊飯器、テレビ、ゴミ箱、メイク（自分はやらないけど）、服、コンビニなど、何の気なしにやっている当たり前を見直す良いきっかけになる。 「なんとなく使ってきたけれど、本当に今の自分に必要なんだろうか」。そんな思いで炊飯器、ゴミ箱、そうじ機といった生活必需品から、つい謝ってしまう癖、もやもやする友達付き合いなどを「やめてみた」日々。その果てに訪れた変化とは？　少しずつ生きるのが楽になっていくさまを描いた実験的エッセイ漫画。 もちろん、この本の通りにこれらの習慣をやめることが全てではない。自分の人生を充実させているものであれば、やめる必要はない。が、惰性で「これは必要なことだ！」と思い込んでいる思考は自分を改善させる上でよろしくないと思うので、フラットな気持ちで読んで、習慣を改善することに「チャレンジしてみる」ことが最も重要に思える。 本当に必要なのか分からないものを捨て、ぐるぐるしがちな考えグセを手放したら生活に意外な変化が生まれました。「ボディーソープをやめたら石けん作りが趣味に」「深夜の居酒屋のかわりにお茶漬けにしたら健康になった」「無理に友達を作るのをやめたら、むしろ交友範囲が広がった」など、やめてみたら新しい自分に出会えた実体験エッセイ漫画。 やめてみることは、自分を肯定することでした。シリーズ累計30万部突破の最新作!サンダルやアイロン、化粧ポーチにクレジットカード。サークル活動を続けるかどうか、そして夫との共同貯金まで。「こうあるべき」をやめてみたら、自分を抑えず、本当にやりたいことが見えてきたーー大人気シリーズ、待望の完結編です。https://1000ch.net/posts/2020/webponize-on-appstore/Tue, 11 Aug 2020 00:00:00 +0000https://1000ch.net/posts/2020/webponize-on-appstore/最近メンテナンスが止まっていた WebPonize だが、Safari が WebP をサポートするとの発表がありメンテナンスを再開することにした。 Web Authentication (Face ID, Touch ID) や http/3 など、色々と実装されているけど WebP 対応が一番嬉しいかもしれない。うっかり OS 側も macOS 11 からサポートしたりするのかな / "Safari 14 Beta Release Notes | Apple Developer Documentation" https://t.co/JJNw4OIhhv — Shogo ( ˘ω˘) (@1000ch) June 22, 2020 App Store で公開するために developer certification & codesign 周りを整理した Sparkle による自動アップデート機能を削除した (webponize/webponize/dcc63f0) Homebrew Cask から削除した (https://github.com/Homebrew/homebrew-cask/pull/87302) Apple の Human Interface Guideline に則り、ユーザーが保存先を選択できるようにした (webponize/webponize/fffda24) ユーザー設定を sindresorhus/Defaults を使って管理するようにした (webponize/webponize/e7662f5) 設定画面を sindresorhus/Preferences を使って実装し直した (webponize/webponize/af5e2a7) webponize.https://1000ch.net/posts/2020/what-you-should-care-about-when-you-use-online-tool/Wed, 05 Aug 2020 00:00:00 +0000https://1000ch.net/posts/2020/what-you-should-care-about-when-you-use-online-tool/先日こちらのツイートに関して同僚と話して、思うところがあったので記事にしてみる。 簡単に実装出来そうな機能なら、野良ツールを探すよりは自分で作ったほうが安心して Web で使える（入力データがネットワークを介してどこに保存されるかわからないので）と思っているので、ササッと作ってソースコードと併せて公開するようにしている。 — Shogo ( ˘ω˘) (@1000ch) August 4, 2020 このツイートの通り、誰がどうやって管理しているかわからないオンラインツールは使わないようにしている。例に出しているのは YAML と JSON を相互に変換する yaml-json という簡単なツールで、たまたまそういうツールが欲しくなったので作った。もちろん、その手のツールは探せば野良に転がっていそうだが、プライバシーポリシーをすべてチェックするのは中々骨が折れるし、無いこともある。 「オンライン上でデータを入力して出力されたデータを使うな」と結論付けたいわけではないが、少なくとも闇雲にやるのは止めたほうが良い。業務上で翻訳が必要なときに翻訳サービスを使いたいときもあるし、画像を最適化したいときに圧縮サービスを使いたいときも多々あると思う。ただ、それらの変換や圧縮などの処理はブラックボックスなことが多いし、大半の場合は入力データはインターネット上のどこかのサーバーを経由しているだろう。その場合、どこの誰がどの情報を覗いているのかわからないし、どこかのサーバーに処理のログは残るだろう。 業務上に必要とはいえ、秘匿性が高いデータをカジュアルに入力（コピーアンドペースト、ドラッグアンドドロップ）していないだろうか？ ツールのプライバシーポリシーを確認する。コピーペーストする前に情報をマスクする。オープンソースで公開されているものであれば、入力データがどのように処理されているかを確認する。 オンライン上のツールを使わない。その代わりに、ローカルで完結することが保証されている macOS や Windows のアプリケーション・コマンドラインツールを使うようにする 「対策を徹底しましょう！」というより、まずは「入力データがインターネットのどこかのサーバーを経由しているかもしれない」こと（とそのリスク）を認識してもらえたら、この記事を書いた甲斐があります。https://1000ch.net/posts/2020/html-ready/Tue, 04 Aug 2020 00:00:00 +0000https://1000ch.net/posts/2020/html-ready/document の DOMContentLoaded イベント や window の load イベント は Web 開発者にとってお馴染みのブラウザライフサイクルである。 結論から言うと、これらを簡単にハンドリングするための html-ready という小さなライブラリを作ったという話。実装自体はとても簡単で、ここで改めて説明するほどのものではない。ただ、同じことを色んな場面で何度も何度も書いている実感があり、巷にも期待する機能を持ったライブラリがなかったので作った。 イベントのタイミングとハンドリング方法 簡単におさらいすると、それぞれ以下のような条件で発火する。 document の DOMContentLoaded イベント: HTML ドキュメントのロードが完了したタイミング window の load イベント: ページが参照する CSS や画像などのサブリソースのロードが完了したタイミング これらのタイミングを取得するためには、以下のように addEventListener を使ってコールバック内に任意の処理を記述すれば良い。 document.addEventListener('DOMContentLoaded', () => { console.log('DOMContentLoaded is fired'); }); window.addEventListener('load', () => { console.log('load is fired'); }); ただし、これらはイベントが発火されたあとに実行されるとコールバックが実行されないので、より丁寧にハンドリングしようとすると document.readyState を参照して HTML ドキュメントの読み込み状態をチェックしなくてはならない。 if (document.readyState === 'interactive' || document.readyState === 'complete') { console.log('DOMContentLoaded is already fired'); } else { document.https://1000ch.net/posts/2020/move-to-github-actions/Mon, 20 Jul 2020 00:00:00 +0000https://1000ch.net/posts/2020/move-to-github-actions/このブログを含めてホストしている Web ページを、GitHub Pages や Firebase Hosting、Netlify など様々な静的ホスティングサービスを使って運用している。これらのサービスへのデプロイは、リポジトリに更新があったときに自動的にデプロイするように設定してある。 Netlify であれば GitHub リポジトリを連携することで、master ブランチの変更を自動的に検知し、任意のデプロイ処理を実行できる。Firebase Hosting や GitHub Pages はこうした便利な連携がないので、CI を使って自動デプロイを設定するのが一般的だろう。 これまでは、CircleCI や Travis CI、Wercker といったような CI サービスを使って GitHub リポジトリを連携し、master ブランチの変更を検知して、配布されている各種スクリプトを使ってデプロイしてきた。これをすべて GitHub Actions で配布されているデプロイスクリプトに移行した。 Firebase Hostings へデプロイする package.json に記述されているビルドスクリプトでビルドする 成果物が出力されているフォルダを GitHub Actions for Firebase でデプロイする name: deploy on: push: branches: - master jobs: build: name: Build runs-on: ubuntu-latest steps: - name: Checkout Repo uses: actions/checkout@master - name: Install Dependencies run: npm install - name: Build run: npm run build - name: Archive Production Artifact uses: actions/upload-artifact@master with: name: public path: public deploy: name: Deploy needs: build runs-on: ubuntu-latest steps: - name: Checkout Repo uses: actions/checkout@master - name: Download Artifact uses: actions/download-artifact@master with: name: public path: public - name: Deploy to Firebase uses: w9jds/firebase-action@master with: args: deploy --only hosting --project project-name env: FIREBASE_TOKEN: ${{ secrets.https://1000ch.net/posts/2020/simplehttp2server-cli/Thu, 04 Jun 2020 00:00:00 +0000https://1000ch.net/posts/2020/simplehttp2server-cli/ディレクトリを簡易的にローカル環境でホストする Python 3 系の http.server という標準ライブラリがある。Python 2 系では SimpleHTTPServer として提供されており、ローカル環境で簡易的に Web ページをホストするのに重宝していた。 simplehttp2server これは http/1.1 でホストされるが、http/2 でホストしたい人のために GoogleChromeLabs/simplehttp2server というものがある。非常に便利なツールだが、Homebrew ないし go get でインストールする必要がある。これを Web Frontend のプロジェクトでも簡単に使えるようにするために、GoogleChromeLabs/simplehttp2server の Node.js ラッパーとして開発したのが 1000ch/simplehttp2server である。 と、言っても npm に simplehttp2server を公開したのは5年ほど前で、新しいものではない。最近変更を加えたのは、この Node.js ラッパーとコマンドライン用のパッケージを分割した部分にある。 simplehttp2server-cli そのため今は、バイナリをラップした 1000ch/simplehttp2server と 1000ch/simplehttp2server-cli がパッケージとして存在する。コマンドラインで simplehttp2server を実行するためには、後者をインストールする必要がある。 $ npm install simplehttp2server-cli $ simplehttp2server --help -config string Config file -cors string Set allowed origins (default "*") -listen string Port to listen on (default ":5000") これで simplehttp2server は動くようになり、ローカル環境のフォルダ等を http/2 で簡単にホストできる。この場合 http/2 なので https を伴うことになり、デフォルトポートを使う場合は https://localhost:5000 になることに注意して欲しい。そして Google Chrome ではデフォルトで https://localhost をセキュリティ上の問題で開けない。https://1000ch.net/posts/2020/web-standards-prospect/Mon, 06 Jan 2020 00:00:00 +0000https://1000ch.net/posts/2020/web-standards-prospect/今年も gihyo.jp の新春特別企画ということで 2020年のWeb標準 という記事を寄稿しました。 2020 年ということで、Web Packaging と Web Authentication について #gihyojp に寄稿しました📝🎍 Special thanks to @kinu and @agektmr ✨ / "新春特別企画：2020年のWeb標準" https://t.co/sVjHoi8zNC — Shogo ( ˘ω˘) (@1000ch) January 6, 2020 取り上げたトピックとしては Web Packaging と Web Authentication ということで、去年や一昨年に比べて少なく感じるかもしれません。が、Web Packaging には Signed HTTP Exchanges と Web Bundles を含んでいますし、Web Authentication もまずまずしっかり説明しており、それぞれの技術が一体どういうものかを掴むには程よい内容になったと思います。 執筆に際して、技術面を @kinu さんと @agektmr さんにレビューしていただきました。ありがとうございます🙌https://1000ch.net/posts/2020/fluid-iframe/Fri, 03 Jan 2020 00:00:00 +0000https://1000ch.net/posts/2020/fluid-iframe/縦横比を維持して親要素いっぱいに広がる <iframe> 要素の実現については、レスポンシブな iframe で解決している。このブログでも、YouTube などの動画を埋め込むことがあるので、この方法を使って対処してきたが、いくつか改善したいポイントがあった。 <iframe> の親に、特定のクラスを付与した要素を必要とする 縦横比に応じた padding-top を用意し、付け替えを必要とする これを Web Components で実装して解決した。 <fluid-iframe> 要素による単純化 <fluid-iframe> としてカスタム要素にして汎用化した。npm install fluid-iframe でもインストールできるが、直接 jsDeliver や unpkg などの CDN からモジュールスクリプトとしてインポートできる。あとは customElements.define() でカスタム要素として登録し、 <iframe> のように使うだけで良い。 <fluid-iframe src="https://www.youtube.com/embed/EqNHSrHzSOU" title="Santa Tracker: Out Like A Light" aspect="16/9"> </fluid-iframe> <script type="module"> import FluidIframe from 'https://unpkg.com/fluid-iframe'; customElements.define('fluid-iframe', FluidIframe); </script> <iframe is="fluid-iframe"> のように、<iframe> 要素の拡張として <iframe> 要素をフォールバックとして動作させたかったが、要素を親子関係にしないとレスポンシブを実現できないため、断念した。https://1000ch.net/posts/2019/english/Mon, 30 Dec 2019 00:00:00 +0000https://1000ch.net/posts/2019/english/2019年の8月頃から英語を本格的に勉強している。DMM 英会話と iKnow を、余程の事情がない限り毎日実施している。 DMM 英会話と iKnow! DMM 英会話はブラウザ上で講師と 1on1 の英語レッスンを受講できるサービスで、使い始めた頃は Skype が必要だったが今はブラウザのみでビデオチャットができる。日々のトピックは基本的に教材から選んでいて、デイリーニュースをやってきた他、最近では文法を繰り返し受講している。これは、会社で受けている英語のテストで、文法のクオリティをもっと高められるとの指摘があったためである。 iKnow! は DMM が 2015年に買収した英語学習サービスである。アプリケーションとしてもなかなか良くできている上に、DMM 英会話との連携も可能で、レッスン中にわからなかった単語等を保存しておき、あとから iKnow! で復習するといったことも可能になっている1。単に単語や熟語を出題して消化させるだけでなく、どの程度理解しているかを反応時間や間違えた回数などを元に算出しているようで、曖昧な理解でいるうちはとことん出題してくれて非常に良い。 iKnow! 単独でも契約して利用可能だが、DMM 英会話を契約すると iKnow! もついてくるので、どう考えても DMM 英会話を契約するのがお得である。DMM 英会話は無料会員登録でも2回までレッスンを受けれるので、まずは雰囲気を掴んでみるのが良いと思う。リファラルリンクから会員登録してもらうと、プラスレッスンチケットが3枚付与されるので、是非どうぞ。 ここまでの上達度合いと目標 英語に対する慣れは感じるものの、どの程度ボキャブラリーが増えたか・流暢になったか等を図ることは難しいので、わからない。とはいえ、この「慣れ」は重要だと思っていて、母国語ではない言語を話すことに対する抵抗は、多くの日本人にとって非常に大きい（主語大きめ）。言い換えれば「未熟な英語力で他人と話すのが恥ずかしい」のが大きな壁だと感じる。 肝心の定量的な英語力を計測できていないので、実技（口頭のコミュニケーション）もある英検を受けることにした。ちなみに会社でも CEFR に沿った試験を定期的に受けているが、折角なのでもう少しパブリックな試験を受けてみようという意図がある。英検は中学校3年生の時に3級に合格して以来ノータッチだったが、来年のうちに2級を、最終的には準1級に合格することを目標とすることにした。 英語学習サービスについての話は #strobofm ep.65 プライバシー保護 (@oinume) でも触れている ↩︎https://1000ch.net/posts/2019/look-back-over-2019/Tue, 17 Dec 2019 00:00:00 +0000https://1000ch.net/posts/2019/look-back-over-2019/自分用の2019年振り返り。こうして振り返ってみると色々やっているが、業務的なことを含めるともっと色々ある。何せ、弊ペイをリリースしたのがまだ今年の2月というのだから驚きである。正直今年頭のことは記憶が曖昧になってきているが、頑張って書き起こしてみる。 1.13 次世代 Web カンファレンス の #nwc_perf で登壇した #nwc_perf 枠で @sisidovski と @_likr の二人と、これからの Web パフォーマンスについて議論してきた。 公開されたスペースで60分間議論しっぱなしというのは初体験で新鮮そのものだった。登壇者で開催された懇親会のほうが議論が盛り上がったのはここだけの秘密である。 2.19 Chrome Tech Talk Night #12 で登壇した Google で Web パフォーマンスについて取り組んでいる @katiehempenius の来日に合わせて開催された Chrome Tech Talk Night #12 にて登壇し、Web パフォーマンスに関する Web 標準技術のアップデートについて話してきた。 3.2 ゲーム実機音源楽団 第一回コンサートに行った スギモトリガーに誘われて NES BAND のライブに行ってきた。NES BAND はファミコン実機を音源として1人1チャンネルずつ、4人で生演奏するバンドである。演奏者がキーボードを操作して入力し、接続されたファミコンやスーパーファミコンなどから出力するというもの。実機から音が出力されるのでゲーム音楽そのままだし、バンドメンバーの息もピッタリだし、スーパーファミコン世代に突き刺さる選曲で非常に良かった。 ライブの様子は YouTube にて公開されている。是非とも聴いて欲しい。 3.29 エンジニア Hub にてインタビューされた 自分の Web パフォーマンスに関する取り組みや OSS 活動へのモチベーションについてなど、普段はあまり話さないようなこともインタビューしてもらって、新鮮な体験だった。インタビューの内容は grdの作者が考える、いまフロントエンドエンジニアに求められる「速度という機能」 - エンジニアHub｜若手Webエンジニアのキャリアを考える！1にて公開されている。 4.27 JAGMO 4月公演『愛の交響詩 - for Symphonic Lovers -』 に参加した JAGMO の公演には事あるごとにスギモトリガーと参加している。例によってお目当ては MOTHER シリーズの音楽である（もちろん他の演目も素晴らしいけど）。オフィシャルで公開されている動画があったので貼っておく。https://1000ch.net/posts/2019/bought-in-2019/Sat, 14 Dec 2019 00:00:00 +0000https://1000ch.net/posts/2019/bought-in-2019/すっかりご無沙汰のブログですが、今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 2018年に買って良かったもの SONY α7ⅲ と単焦点レンズ ついにカメラ沼に足を踏み入れた。選択肢として SONY α6500 等もなくはなかったが、せっかくであれば良いものを購入しようということで、SONY α7ⅲ を買ってみた。カメラに関する知識は皆無レベルなので、まだまだ宝の持ち腐れ状態だが、旅行や食事など、各種イベントには持ち運んで使うようにしてまずまず楽しんでいる。 新開発有効約2420万画素35mmフルサイズ裏面照射型CMOSセンサー搭載。693点像面位相差AFセンサー/425点コントラストAFセンサー搭載で被写体を捉えて離さないAF性能。「リアルタイム瞳AF」動物対応。ペットや野生動物の瞳も高速・高精度に検出し、追随可能。AF/AE追随 最高約10コマ/秒連写を実現(連続撮影モード「Hi+」時)。最大710枚(LCDモニター使用時)撮影可能な高いスタミナとタッチによる自由度の高いフォーカス操作 購入後にカメラを持つ人々と話をしてみると、価格帯としてそこそこ高めな部類を買ってしまったことに気付かされるが、性能は良い（はずだ）し、いざとなれば売れば良いので然程気にしていない。折角一眼レフを買ったのであれば、単焦点レンズも買ってみようということで、同じく SONY の FE 50mm F1.8 を買った。 新規光学設計により高画質を実現した、小型・軽量な開放F値1.8の大口径標準単焦点レンズ。携帯性に優れた小型・軽量デザイン。非球面レンズを使用した新規光学設計により高画質を実現。開放F値1.8、単焦点レンズならではのぼけ味を生かした撮影が可能 あとはデータの保存先となる SD カードも購入した。今はだいぶ安くなってるのね…。自分の場合は Raw Data は使わず、JPEG のみを保存するようにしている。もちろん Raw Data も残しておきたい気持ちはあるけど、実運用を考えるとどうしても Google Photo 管理になるだろうし、キリが無くなりそうなので割り切っている。 カードタイプ : 3D TLC SDXC : CLASS10 UHS-I U3 V30。 転送速度 : 読出し最大95MB/s。 動作温度 : -25℃~85℃ : 耐温度、防水、耐磁、耐X線、静電耐性。 保証 : 5年保証 / 記録データの消失に関する保証はございませんので予めご了承ください。保証規定に関してはトランセンドホームページをご参照ください。 Anker PowerPort Atom PD 1(PD対応 30W USB-C急速充電器) 発売時点でかなり話題になっていた Anker の小型急速充電器だが、プラグを折り畳めないのが気になって買っていなかった。で、最近になってまた気になりはじめて結局買ってしまったわけだが、非常に便利に使っている。かばんに入れていても気にならない重さなので、携帯用として常に入れっぱなしにしてある。https://1000ch.net/posts/2019/dark-mode/Tue, 18 Jun 2019 00:00:00 +0000https://1000ch.net/posts/2019/dark-mode/prefers-color-scheme は Media Queries Level 5 で定義される、システムで明るいテーマ・暗いテーマどちらを要求しているかを参照するメディアクエリである。Safari では 12.1 からサポートされていたが、Chrome の次の安定版である 76 に ship されそうなので、このブログでも申し訳程度に対応した。 Firefox については現在の安定版である 67 に ship されているし、Mobile Safari についても 13 からサポートされそうなので、ブラウザのサポートは近いうちに広まりそうである。macOS は Mojave から Dark Mode を搭載しているので、試したい人はアップデートしてみて欲しい。 シンタックス prefers-color-scheme は値に light と dark、そして no-preference の3つを取る。no-preference はシステムに対して設定していない場合を指す。 @media (prefers-color-scheme: light) { body { background: #fff; color: #000; } } @media (prefers-color-scheme: dark) { body { background: #000; color: #fff; } } このブログではこれまでの明るい見た目を基本テーマとして、Dark Mode が検出された場合に暗いスタイルを適用するべく、@media (prefers-color-scheme: dark) を使って上書きしており、@media (prefers-color-scheme: light) を使って記述を分けてはいない。https://1000ch.net/posts/2019/interview-on-engineer-hub/Wed, 08 May 2019 00:00:00 +0000https://1000ch.net/posts/2019/interview-on-engineer-hub/エンジニア Hub キャリアの連載企画でインタビューして頂き、自分の Web パフォーマンスに関する取り組みや OSS 活動へのモチベーションについてなど、普段はあまり話さないようなことを話した。 インタビューされてました。No ろくろ / "grdの作者が考える、いまフロントエンドエンジニアに求められる「速度という機能」 - エンジニアHub｜若手Webエンジニアのキャリアを考える！" https://t.co/HcfX9k0bMQ — Shogo SENSUI (@1000ch) May 8, 2019 ちなみにインタビューの中で「速度という機能」という表現を使っているが、これは Performance is a Feature という記事から拝借して敢えて使っていて、非機能要件としてのパフォーマンスとは異なる文脈のコメントですので悪しからず。 株式会社はてなの初瀬川さん、スタッフの皆さん、貴重な機会を頂きましてありがとうございました。https://1000ch.net/posts/2019/setup-environment-for-designers/Thu, 31 Jan 2019 00:00:00 +0000https://1000ch.net/posts/2019/setup-environment-for-designers/社内のデザイナー向けに書いた資料があったが、読み返していたら社内専用という内容でもなかったので、社外向けに公開してみる。opinionated な部分があるのはご了承いただきたい。 1. macOS のアプリ 紹介するのは コマンドラインインターフェースとして iTerm と、テキストエディタとして Visual Studio Code である。より AI ファーストなエディタとして Cursor などもあるが、今回は割愛する。 1.1. iTerm2 標準のターミナルアプリも良いが、色々痒いところに手が届く機能が備わっているので、iTerm2 を推奨する。 1.1.1. フォントを変えたい ダサくてテンションが上がらない人は、まず iTerm のフォントを Profiles > Text > Change Font から、好みの等幅フォントに変更して欲しい。macOS にプリインストールされているものであれば、menlo あたりが良い。 1.1.2. カラースキーマを変えたい ダサくてテンションが上がらない人は、カラースキーマも変えると良い。iterm2 のカラースキーマは MartinSeeler/iterm2-material-design 等で配布されている。 1.1.3. もうちょっとオシャレにしたい ダサくてテンションが上がらない人は、テーマも変えてみると良い。 robbyrussell/oh-my-zsh sorin-ionescu/prezto sindresorhus/pure ここでは pure を Homebrew 経由でインストールする。 brew install pure zsh の人は ~/.zshrc に以下を追加する。 # .zshrc autoload -U promptinit; promptinit prompt pure 1.2. Visual Studio Code どんなエディタでも構わないが、「まだエディタをインストールしてない…」ということであれば、Visual Studio Code が良い。https://1000ch.net/posts/2019/web-standards-prospect/Tue, 08 Jan 2019 00:00:00 +0000https://1000ch.net/posts/2019/web-standards-prospect/あけましておめでとうございます。今年も宜しくお願い致します。 各ソーシャルでもシェアしましたが、去年に続いて新春特別企画ということで2019年のWeb標準という記事を gihyo.jp の方へ寄稿しました。ちなみに去年の記事は2018年のWeb標準です。 内容は2018年の W3CによるHTML5.2の勧告とWHATWGの標準化プロセスの整備 Web Components普及への期待 Service WorkerがもたらすWebの変化 クレジットカードのセキュリティとWeb Payments HTTPS化の更なる浸透 から、2019年の Microsoft EdgeへのChromiumプロジェクトの採用 Low Level APIとLayered APIs HTTP/2の普及とHTTP/3の標準化 Webパフォーマンスに関するAPIの拡充 と、被らないように気を付けつつ、私の趣味が色濃く影響しているラインナップになっています。細かいトピックを持ち出せばもっとありますが、大きめな話を拾って事実と私見を混ぜながら綴っています。ポッドキャストのこともあるので以前のような頻度で更新はできていないですが、こうして時々のスナップショットを取るのは趣深いので、ブログ記事は引き続き書いていこうと思います。https://1000ch.net/posts/2018/bought-in-2018/Mon, 24 Dec 2018 00:00:00 +0000https://1000ch.net/posts/2018/bought-in-2018/今年も書きます。 2015年に買って良かったもの 2016年に買って良かったもの 2017年に買って良かったもの 珪藻土マットを磨く紙ヤスリ 240番 珪藻土マットがあればバスマットが不要になる話は、過去にブログに書いた。どんなに速乾のタイプでも使用後のバスマットは濡れていて、ウッとなることも多かったが、珪藻土マットにしてからは、すぐ乾くし洗う手間もない。価格も安いので、バスマットを使っている人は騙されたと思って試して欲しい。 Tenswall 珪藻土速乾バスマットは太古の植物性プランクトン(珪藻)が原材料です。「驚異の吸水力」「脱臭湿度調整効果」「カビやダニの発生を抑制」「洗濯不要でいつでも快適」と多機能が特徴のバスマットです。寸法：横60cm縦39cm厚さ1cm 重さ：約2.70ｋｇ。シンプルな薄型設計で、室内利用に最適です。立てかけておけば場所も取りません。メーカー直営店、購入する時に販売元Tenswall JPをお確認してください。他のは偽物です。ご了承ください。 ただ、長らく使っていると吸水力が低下してきて、なかなか吸わなくなってきたなという瞬間が来る。これは商品の説明にもあるように、使う度に細かいゴミや皮脂などが珪藻土の孔に詰まっていくことで起きる現象である。これはヤスリで表面を磨くと再び吸水力を取り戻すとのことで、紙ヤスリを買って磨いてみたところ、見事に吸水力が復活した。 番手・枚数：#240(12枚)。サイズ：228mm × 93mm。その他：ハンドサンダー・電動サンダーにも取付け可能です。 ヤスリの目の細かさについては色んな説があるが、今回は240番で試した。要するに、表面を削れれば良い。足で踏んだ感触も、滑らかである。お手入れの頻度は、使用頻度に依るところが大きそうだが、半年〜1年に1度磨けば十分かなという印象。磨くのが面倒という説はあるが、定期的にバスマットを洗って乾かすよりは確実に手間が小さい。 Qi ワイヤレス急速充電器 Anker PowerWave 7.5 Stand 同僚が iPhone をワイヤレスで充電しており、試しに使わせてもらったら 「これは良い！」 となり、購入した。これを体感してしまうと「ケーブルを抜き差しすればいいじゃん」とはならない。思った以上に無線充電が良すぎて、気づいたらオフィス用と自宅用の 2 つ買っていた。 ワイヤレス充電はこれひとつで：最新のiPhone(最大7.5W)やSamsung製スマートフォン主要モデル(最大10W)を含む、ワイヤレス充電に対応するあらゆる機器と互換性があります(*急速充電に対応するには、別売りのQC3.0対応充電器を合わせてご利用ください)。 ケースはそのままで：PowerWaveは、ほとんどのスマホケースをつけたままでスマートフォンを充電することが可能です(※5mm以上の厚みがあるケースや金属製や磁気を帯びたケースおよびクレジットカードは、充電前に取り外してください)。 電子機器周り、特に給電系で安心感がある気がする Anker を選んだ。Mac やらヘッドホンやら、あらゆる電池機器が無線でできれば良いのに、と思う。 圧倒的な充電速度：Qualcomm Quick Charge 3.0対応ポートを搭載。また、Anker独自技術PowerIQとVoltageBoostを搭載し、あらゆるUSB機器にフルスピード充電が可能です。十分な4ポート：4ポートで合計43.5Wの出力が可能。家族全員分のスマホやタブレットを同時に急速充電可能です。また100-240Vの入力に対応しているので、世界中でご利用いただけます。海外旅行にも最適です。 Teslong のスコープ付き耳かき いつぞや Twitter のタイムラインに流れてきて、安かったので面白半分で買ってみた。簡単に言うと USB Type-C の耳掻き付きカメラで、耳の中をディスプレイやスマートフォンで見ながら耳掃除ができるというものである。自分の耳の中は見えないし、仮に他人の耳だとしても穴の中は見にくい。その耳の中をライト付きスコープで撮影しながら耳掻きできるのは、なんとも言い難い。ピンポイントで狙い撃ちできる。 主に耳道内と鼻内の検査です。パソコン、携帯などに接続して画像伝送ができる、画像はパソコンに保存する機能もあります。画像の取り込や回転、拡大などの編集も可能で、日常の診断のみでなく、患者さんヘの説明や診断の記録、医学教育にも役立ちます。インターフェースに適用のはwindows XP/7/8/10, mac OS X 10.6または最高バージョン、パソコンとMacに接続可能です。Android microインターフェースに適用のは携帯Androidシリーズおよび4.4以上バージョンのです。携帯はOTG とUVCに適用するかどうかを確認してください。ケーブルは1.5m 2.0USBを搭載 センサー解像度:640x480 Pixels イメージセンサー:0.3Megapixel 焦点距離:20mm-30mm 私は Mac に接続して使っている。USB 経由で給電されるので電池などは不要だし、接続すればあとは QuickTime を起動して New Movie Recording するだけで撮影を開始できる。https://1000ch.net/posts/2018/gae-project-firewall/Mon, 12 Nov 2018 00:00:00 +0000https://1000ch.net/posts/2018/gae-project-firewall/GAE のプロジェクトには Console から Firewall の設定ができる。 GAE を利用している GCP のプロジェクトを GCP Console から選択し、ハンバーガーメニューをクリックして表示されるドロワーメニューの、 App Engine → Firewall rules を選択する。 default のルールとして、全てのドメイン * に対して Allow が設定されているので、適用するルールを Create Rule から作成する。 例えば 111.111.111.111 からのアクセスのみに制限するには、以下の状態にする。 Priority: 1, Action: Allow, IP Range: 111.111.111.111 Priority: default, Action: Deny, IP Range: *https://1000ch.net/posts/2018/optimize-svg-in-gui/Sun, 11 Nov 2018 00:00:00 +0000https://1000ch.net/posts/2018/optimize-svg-in-gui/Sketch や各種ツールから出力する SVG には、表示には必要ないデータが含まれることがある。SVG を git などでバージョン管理することも多いと思うが、この時に不要なデータを含めたくない。 ツールとしては svgo という Node.js 製のツールがあり、これを使うことで不要なデータを取り除きつつ、整形や最小化処理を適用できる。 どのタイミングで最適化するのかという話があるが、それについてはワークフローにおける画像の最適化でも書いてある。今回は git のコミットフックではなく、GUI ツールで最適化することを考えてみる。 GUI ツールでやる必要性 は特にないが、とりあえず1ファイルだけ最適化したかったり、ターミナルではなくテキストエディタでやりたいなど、git のコミットフックを用意するまでもない場面の選択肢のひとつとして考えられる。 Sketch のプラグインをインストールしておけば、エクスポート時に最適化した状態で出力できるので、漏れがない。あとは SVG に限らないが、エクスポートする前に、アイコンであればアートボードのサイズを揃えたり、パスをアウトライン化しておいたり、アートボードの名前を意味のあるものにしておくと良い。これをやっておくと、ViewBox のサイズが統一され、不要な transform の情報がなくなり、 <title> 要素に意味のある名前が挿入される。 各種プラグイン Figma については With Figma’s new SVG Exports, less = more を見るに、ツールがない様子である。他のツールについては、Sketch にはオフィシャルで用意されていた。 BohemianCoding/svgo-compressor: Sketch のプラグインなので、手動でダウンロードする他、Sketchpacks などからインストールできる 1000ch/vscode-svgo: コマンドパレット (Cmd Shift P) で Install Extensions を実行し、svgo で検索する 1000ch/atom-svgo: apm install svgo または Install から svgo で検索する 1000ch/Sublime-svgo: コマンドパレット (Cmd Shift P) で Install Package を実行し、svgo で検索する VSCode と Atom は Node.https://1000ch.net/posts/2018/nd/Tue, 16 Oct 2018 00:00:00 +0000https://1000ch.net/posts/2018/nd/1000ch/nd という Node.js のバージョンマネージャを Go で書いた。車輪の再発明もいいところで、特に今使っているバージョンマネージャから切り替えるメリットは今の所ない。ただの作業ログです、悪しからず。 それっぽいモチベーション Go は Windows、macOS、Linux といった環境へのクロスコンパイルができることと、実行できるシングルバイナリを配布するだけでランタイムへ依存しなくて済む、この2点で選んだ。 作ったあとに @hokaccha とした答え合わせで、PATH の通し方については少々議論になった。今回作ったツールは Node.js のアーカイブファイルをダウンロードして展開し、あらかじめ通しておいたパスから node にシンボリックリンクを作るだけの単純な実装である。 代表的な既存ツールは以下のような実装になっている。 nodenv/nodenv: ~/.nodenv/shim/node を起点に実行する Node.js を探索する hokaccha/nodebrew: パスが通った場所から、対象の Node.js へシンボリックリンクを作成する creationix/nvm: PATH を変更して対象の Node.js へパスを通す nodenv は rbenv のフォークで、グローバルの node のパスを変更できるだけでなく、カレントディレクトリの .node-version を参照して実行する Node.js を切り替えできる。高機能で良いが、 .node-version でバージョンを固定して運用するには関わる人全てのバージョンマネージャを揃える必要があったりして、中々難しい部分もある。 nvm の PATH を変更する方式は、なかなか痒い部分があるのと、欲しい機能があるならフォークして使ってくれというスタンスなので、ツールとして微妙さを感じている。 思想や作りは nodebrew と最も似ていて、記述言語が違うくらい。 クロスコンパイルについて Go を選んだ割に、Windows や Linux でのテストをどうしようか考え中なので、まだクロスコンパイル環境は整えている最中である。経緯や概要は Go のクロスコンパイル環境構築で抑えたが、状況は改善されているようで、go のインストール時に --with-cc-all オプションが不要になっていたり、クロスコンパイルに追加で必要だったツールが不要になっている。 引き続きポイントになるのは GOOS と GOARCH という2つの環境変数で、 go build 時にこれらが参照されることで各種環境向けのバイナリが出力される。これを踏まえて、クロスコンパイルにはいくつか方法がある。https://1000ch.net/posts/2018/techbookfest-vol5/Mon, 08 Oct 2018 00:00:00 +0000https://1000ch.net/posts/2018/techbookfest-vol5/技術書典4に参加した時に触発されて、技術書典5は出店しようと決意していたが、宣言通り技術書典5にサークル参加してきた。サークル参加は共同参加と単独参加の2つで挑み、当日まで色々と苦労しながら、また当日も色々と大変だったが、無事に終えることができた。 馬クラッカー（う18） 馬クラッカーは共同参加のサークルで、開発に関するエモい話を集めた Fictions という本を仕上げた。主に @_kaelaela と @morishitter_ が本文を書いて、私は主に進行管理や校正などの編集を担当した。 こちらは開発に関する色んなポエムを集めた Fictions という本です。@_kaelaela と @morishitter_ と書きました（私は主に編集を担当）📖 https://t.co/ckCu9uXBEU — Shogo 🍵【技術書典5 け45・う18】 (@1000ch) 2018年9月29日 こちらは2人にプレッシャーをかけつつ、入稿作業まで速やかに進んだので、印刷費も通常の 20% オフで済んだ。当日は単独参加のサークルの切り盛りに追われていたので、こちらには物理的に顔を出せなかったが、頒布物を一部販売したりした。 物理版と併せて電子版（.epub）も準備してあるので、買い損ねた人や興味がある人は以下から購入してください。 Fictions - 1000ch - BOOTH（同人誌通販・ダウンロード） Gumroad - Fictions 伝説のコンポーネント（け45） 馬クラッカーの作業を進めているうちに、自分も何か一冊書いてみたくなり、衝動的にサークル参加を申し込んだ。 もう一つは、Web Components に関することを網羅的に書いた「よくわかる Web Components」です。 https://t.co/tIVz8XKQ80 — Shogo 🍵【技術書典5 け45・う18】 (@1000ch) 2018年9月29日 内容は色々と候補があったが、悩んだ挙げ句 Web Components に着地した（以下、まえがきから引用）。 Web Componentsという言葉を2013年末に初めて目にして以来、かれこれ5年が経ちます。Web ComponentsがWebのスコープ問題を根本的に解決しうる技術だと感じて以来、継続的に動向をキャッチアップしてはアウトプットを繰り返してきたように思います。 こうして蓄積してきた経験と知識を、いつか何らかの形でまとめたいなと、常々思ってきました。このような背景を踏まえて、今回は書籍という形でまとめ、出版させて頂くに至りました。 こちらは完売してしまっており再印刷は今の所予定していませんが、同じく電子版（.epub）の用意があります。 よくわかる Web Components - 1000ch - BOOTH（同人誌通販・ダウンロード） Gumroad - よくわかる Web Components 当日までの色々 執筆は Re:VIEW フォーマットで進めた。ビルド環境をスクラッチでセットアップは中々骨が折れるので、まずは TechBooster チームが公開している TechBooster/C89-FirstStepReVIEW-v2 をベースにすると良い。Re:VIEW の文法は公式の Re:VIEW フォーマットガイドや Re:VIEWチートシートあたりを参考にすれば直ぐに慣れる。が、出力結果を調整するためには LaTeX と向き合う必要があるので、最初は根気が必要である。https://1000ch.net/posts/2018/next-web-conf-2019/Mon, 01 Oct 2018 00:00:00 +0000https://1000ch.net/posts/2018/next-web-conf-2019/来たる 2019年1月13日(日) に開催される 次世代 Web カンファレンス に出演します。前回が2015年なので、4年に1度の開催ということで、オリンピックみたいですね（もちろん、そんな意図はないと思う）。 担当が Performance (#nwc_perf) のセッションオーナーということで一応まとめ役を兼ねていますが、いちスピーカーとして、これからの Web パフォーマンスについて色々と議論できればと思います。 #nwc_perf です、宜しくお願いします！ / "次世代 Web カンファレンス - connpass" https://t.co/91RqP6XORw #nwc_all — Shogo 🍵【技術書典5 け45・う18】 (@1000ch) 2018年10月1日 #超速本を世に送り出してから早一年が経とうとしており、Web パフォーマンスを取り巻く要素も増えつつあります。本番では議論がコンテンツなので頭出しはしませんが、触れたいトピックは色々とあるので、今から温めておこうと思います。https://1000ch.net/posts/2018/bonfire-frontend-vol2/Sat, 25 Aug 2018 00:00:00 +0000https://1000ch.net/posts/2018/bonfire-frontend-vol2/2018年8月23日に開催された Bonfire Frontend #2 に出演して、「PWA 対応戦略と現実解」というタイトルで PWA についてお話しました。 Progressive Web Apps はという言葉は 2015 年にスタートし、普及を続けてきました。PWA の構成要素や、それを達成するための HTTPS、Service Worker、Web App Manifest などの技術要素などについての理解も、ここ数年でかなり進んでいます。 今回の Bonfire Frontend は「実践的な Web アプリケーション」というテーマということで、 いざ PWA を実現していく時にどういったアプローチをすればいいか について戦略化してみました。https://1000ch.net/posts/2018/tryshift/Tue, 21 Aug 2018 00:00:00 +0000https://1000ch.net/posts/2018/tryshift/インターネット業界で働いている人であれば、個人・会社といったように、複数の Google アカウントを持っていることも珍しくないだろう。個人で複数の Google アカウントを持っている人もいるだろうし、副業先などで Google アカウントを発行している場合は、3つ以上持っている人もいるかと思う。 かくいう私も、個人の Google アカウントと会社の G Suite で発行される Google アカウントを所持している。個人の Gmail、会社の Gmail、個人の Google Calendar、会社の Google Calendar といったように、複数 Google アカウントの異なるアプリを開くことも多いので、管理方法に悩んでいた。 自作の URL opener を使った管理 昔作った Chrome の拡張機能に URL opener というものがある。これは予め URL を登録しておくと、アイコンをクリックするだけで一気にブラウザで開けて、更にピン止めしておくかどうかも指定できるというもの。 先に挙げた、複数 Google アカウントの異なるアプリはそれぞれユニークな URL があるので、この拡張機能にそれらを登録しておくことで、ワンクリックで表示できていた。概ね満足していたが、Chrome のタブで開くことになるので、⌘ + Tab でスイッチできなかったり、登録する URL に authuser= が含まれるので Google へのログイン順序が重要、などの課題はあった。 Shift で複数の Google/Outlook アカウント + α を管理 まずはこちらのトレーラーを見てもらうのが早い。 Web サイトには Shift - The Best Desktop Email Client for Gmail and Outlook.https://1000ch.net/posts/2018/lazyload-attributes/Sat, 18 Aug 2018 00:00:00 +0000https://1000ch.net/posts/2018/lazyload-attributes/<img> 要素と <iframe> 要素に lazyload 属性を定義する Pull Request が whatwg/html に出されている。 <img> 要素と <iframe> 要素の lazyload 属性 / "Lazyload images and iframes by bengreenstein · Pull Request #3752 · whatwg/html" https://t.co/3gJ9BVNRJc — Shogo 🍵 (@1000ch) 2018年8月18日 Web における画像の遅延ロード Web でロードするリソースは増える一方で、中でも画像が占める割合は大きい。ロードした HTML ドキュメントに <img> 要素があれば、ブラウザは即座に画像をダウンロードしようとする。これらの画像が大きければ大きいほど、初期ロードにおけるネットワークのコストと占めるメモリの割合が大きくなる。こうした問題を背景に、画像を遅延ロードする様々なアプローチが取られてきた。 aFarkas/lazysizes: is a fast (jank-free), SEO-friendly and self-initializing lazyloader for images (including responsive images picture/srcset), iframes, scripts/widgets and much more 1000ch/lazyload-image: HTMLImageElement extension for lazy loading. (プリロードスキャナのせいでうまく動かない) 今回追加されようとしている lazyload 属性はこうした処理をブラウザネイティブで出来るようにする提案である。この属性は <img> 要素だけでなく <iframe> 要素でも有効化され、Above The Fold にないこれらの要素が参照するリソースをむやみにロードせずに済む。https://1000ch.net/posts/2018/deprecate-webcomponents-v0/Mon, 30 Jul 2018 00:00:00 +0000https://1000ch.net/posts/2018/deprecate-webcomponents-v0/blink から Web Components v0 を deprecate and remove する intent が作成された。 Intent to Deprecate and Remove: Shadow DOM V0, Custom Elements V0, HTML Imports オチはないがツラツラと振り返ってみる。 Web Components v0 の変遷 Shadow DOM v0、Custom Elements v0、HTML Imports が初めて Chromium に実装されたのが 2014 年なので、そこから早 4 年が経つ（アイデアに至っては 2011 年まで遡り、Alex Russell 先生が Fronteers Conference 2011 で最初のコンセプトを発表している）。この v0 に分類される API は、<template> 要素 を除き、他のブラウザベンダーの合意を得られず、安定 API としてリリースされることなく終わった。 Shadow DOM と Custom Elements は API のデザイン変更のステップと捉えることもできるが、HTML Imports は Firefox が ES Modules の存在を理由に反対の姿勢を示していた。2014 年に実装を見送り、2015 年に改めて ES Modules を待つ姿勢を示している。https://1000ch.net/posts/2018/running-environment/Sun, 22 Jul 2018 00:00:00 +0000https://1000ch.net/posts/2018/running-environment/Q2 の目標で掲げている通り、健康を目的にランニングを定期的にしている。そのランニング環境を最適化してきたので、現状を記録しておく。 ランニング時の装備 これらに落ち着いている。 スポーツウェア: 綿のモノだと汗で身体に密着しやすく、脱ぐときに脱ぎにくい スマートフォン: ランニングをログしつつ、音楽またはポッドキャストを再生する ヘッドホン: 何か聴こえていると疲れていてもある程度気が紛れるので PASMO: 帰り道に買い物をするため、ある程度チャージしておく 家の鍵: 普段使っているキーケースは嵩張るので、スペアキー ポーチ: スマートフォン、PASMO、家の鍵を入れておく Apple Watch を持っている時は、それだけでランニングのログを取れたし、内蔵の Suica で買い物も出来たが、都営大江戸線を使うようになったため Suica が使えない上に、オフィスの入館も Suica では出来ないので、Apple Watch を持つメリットが小さくなり売ってしまった。 また Apple Watch だと容量が心許なく、音楽を十分に保持できなかったり、ファイルの同期がいちいち面倒だったりしたが、それはスマートフォンにしたことで解消されている。 骨伝導ヘッドホン 一回のランニングにつき 30 分以上走るので、この間ずっと環境音だけ聴こえているのもつまらない。というか、何か聴こえている方が心理的に気が紛れるので、何かしら再生するようにしている。 普通のイヤホンだとランニングの振動で外れてしまうので、スポーツタイプを強くオススメしたい。Bluetooth かどうかはどっちでも良かったが、今回は Vidonn F1 Titanium Bluetooth スポーツ用ヘッドホン を購入してみた。 一般的なイヤホンと違い、直接、耳へ挿入しないため、ジョギング、サイクリング、ダイエットなどの運動を、より安全に、より快適に楽しむことができます。音楽を聴きながらでも、クルマの近づく音など周辺の様々な音も同時に聞こえるため、運動時の安全が更に保障されます。骨を通して聴覚神経に伝わるため、聴力を損傷する心配がありません。180mAhリチウムバッテリーにより、連続音楽再生6時間、通話3時間、240時間の待機時間を可能にしました。充電時間は、2時間のみです。防水・耐汗・防塵レベルはIP55。ジョギングやダイエット運動、ダンス、クライミング、サイクリング、テレビ視聴など、室内外を問わず、防水・耐汗を発揮します。耳への水や汗などの侵入を、心配することはありません。 このヘッドホンの良いところは、何より骨伝導という点だ。骨伝導は耳を塞がないので、環境音も聞こえる。ランニング時がより安全になるだけでなく、自転車を耳を塞いで運転していると警官に止められてしまうが、これならば恐らく止められない気がする。また、耳から外れることを気にしなくなるし、スポーツタイプなのでホールド感も充分である。 ポーチ 先の理由で Apple Watch を売ってしまったので、スマートフォンを携行する必要がある。また、家の鍵や PASMO といった各種小物もあるので、ポケット運用に限界を感じて PORTHOLIC のランニング用ポーチを購入した。 【高品質伸縮性のある素材採用】：🥇ジャージ系の伸縮性のある素材を使用し、以外と入る収納力！🥈撥水性のある生地を使用 、汗にも強い、急な雨から大切な荷物を守ります。🥉毎日洗濯してもすぐ乾き汚れもいい吸汗速乾素材です。 スマートフォンのスクリーンが見えるだけでなく、カバーの上から操作できるのである程度の操作なら、ポーチから出さすに済ませられるのが案外便利である。ポケットにモノを入れて走っていると揺れて気になるが、このポーチに入れてみたところ、そういった振動も解決された。 エアコンの自動化 去年から Nature Remo と Google Home で家電を操作している が、声で操作するだけでなく、自分の位置情報を元に自動でオンオフするように設定している。 最近の気温は耐え難いものがあり、家に着いたときにエアコンが効いていないと、涼しくなるまでがそれなりにストレスなので、自分が家の半径 300 メートルに入ると自動でオンするようにしている。これでランニング時はもちろん、仕事から帰った時もエアコンが作動して少し経っているので、涼しい。 オンだけでなく、自分が家の半径 300 メートルから出ると、ライトとエアコンをオフするようにしている。エアコンについてはこまめにオンオフすると空調効率が良くないが、こまめにオンオフするのが目的ではなく「家に近づいたときに確実にオンし、家から遠ざかったときに確実にオフする」のが目的なので気にしない。そもそも、こまめにオンオフされてしまう瞬間はランニングや近所に出歩く時くらいなので、無視して良い。https://1000ch.net/posts/2018/sense-starts-with-knowledge/Tue, 10 Jul 2018 00:00:00 +0000https://1000ch.net/posts/2018/sense-starts-with-knowledge/タイトルの通り「センスは先天的感覚から成るものではない」ということを、具体的な例を交えて、首尾一貫として伝えている。ひたすら噛み砕いた説明で、冗長なくらいだが、説得力はある。紙のページ数で 194 ページという分量、且つ文章も平易で読みやすい。 インターネット産業はコモディティ化しつつあり、ここから先はビジュアルや機能、あらゆる面においてセンスの差別化が問われることが述べられている。字面だけ見るとややモヤモヤするが、そもそもこの本ではセンスという言葉を、いわゆる第六感的なセンスとは捉えておらず、むしろその解釈を真っ向から否定している。 終盤の、物事の客観的評価の話では、「論理性のない好き嫌いで決定している限り、マスの心を掴むことは出来ない」というメッセージをどことなく感じる。 水野 学https://1000ch.net/posts/2018/creativity-inc/Sun, 08 Jul 2018 00:00:00 +0000https://1000ch.net/posts/2018/creativity-inc/ピクサー社のモノづくりにまつわる様々なストーリーを軸に、組織や人のマネジメントについて示唆している本。チームのクリエイティビティを維持するために必要だったこと・ディズニー社による買収劇の裏側・ジョブズのパーソナリティなどについて書かれている。紙にして 424 ページというボリュームで内容も濃く、読み応えがある。 Ed Catmull (著)、Amy Wallace (著)、石原 薫 (翻訳)https://1000ch.net/posts/2018/second-quarter/Sat, 30 Jun 2018 00:00:00 +0000https://1000ch.net/posts/2018/second-quarter/2018年の半分が終わってしまった…。 Q2（2018年4月~2018年6月） 麻雀のスコア集計アプリを完成させる 完成と言っていいクオリティかどうかは微妙だが、なんとなく動く状態になった。仲間内で使いながら、もう少しブラッシュアップしていきたい。 vim + tmux 再入門 やってない。vim はたまに使うが、tmux を使えていない。 自転車を買う 宣言通り購入した。結局検討していた通り、TOKYOBIKE SPORT 9s を購入した。自転車本体に加えて、スタンド・ライト・キー・ベル・空気入れなど、込10万円弱だった。ここまで高額（な部類に入ると思っている）な自転車を買って乗るのは初めてだったが、なるほど、快適だし速い。 Finally. #納車 #tokyobike A post shared by Shogo Sensui (@1000ch) on Jun 8, 2018 at 8:58pm PDT これから夏真っ盛りではあるが、自転車通勤を検討している。六本木駅の近くに港区区営の駐輪場があるが、かなりハイテクで、自転車ひとつひとつに ID を付与してあとは機械で自動で出し入れ管理をしてくれる。 六本木駅近くのハイテク駐輪場 A post shared by Shogo Sensui (@1000ch) on Jun 26, 2018 at 8:17am PDT 3Q（2018年7月~2018年9月） 筋トレする 1日30回、腹筋する。 読書する 月に 2 冊を掲げているが、月に 1 冊ペースに落ち着いている。読書に気を向けておらず、単純に時間を作れていない。 最近試しているのはカフェで読書するという方法。カフェと言ってもただのカフェではなく、初台にある読書のためのカフェ fuzkue に行くことで、読書する時間と環境を作っている。このカフェはで利用者に様々なルールを敷くことで、読書のための環境を実現している。集中力を強いられて、良い環境である。 ランニングする 月に 20km を掲げており、これは実践できているので続ける。同じコースを同じペースで走っているせいか、やや飽きを感じるので、同じルートの逆周で走ってみたりポッドキャストを聞きながら走っている。ランニングについてはルーチン化できているので、あとは Nike Run Club でログすることを忘れずに走りたい。https://1000ch.net/posts/2018/gitbook/Sun, 13 May 2018 00:00:00 +0000https://1000ch.net/posts/2018/gitbook/技術書典５ への参加を目指して、執筆環境をセットアップしたのでそのメモ。今回は GitBook を使って Markdown から PDF を生成する。選択肢としては更に高機能な Re:VIEW もあるが、筆が進みやすいようにとりあえず使い慣れている Markdown を選んだ。足りない機能があったり余力があれば、Re:VIEW のセットアップもしてみるつもり。 プロジェクトの作成 プロジェクトのフォルダに移動したあと、gitbook の npm モジュールをプロジェクトローカルにインストールする。インストールすると gitbook コマンドが使えるようになるので、プロジェクトを初期化する。 $ npm init $ npm install --save-dev gitbook-cli $ ./node_modules/.bin/gitbook init . warn: no summary file in this book info: create README.md info: create SUMMARY.md info: initialization is finished すると、 README.md と SUMMARY.md が作成される。あとは原稿を Markdown 形式で用意し SUMMARY.md から参照していくだけで良い。 README.md は特別なファイルで SUMMARY.md から参照しなくても自動で挿入される。 # Summary - [Foo](foo.md) - [Bar](docs/bar.md) ... HTML と PDF の生成 gitbook build で静的な HTML ファイルが _book フォルダ配下に生成される。gitbook serve で生成される HTML を localhost:4000 にホストしつつ、原稿の変更を検知してライブリロードしてくれる。https://1000ch.net/posts/2018/merpay-tech-meetup/Sat, 12 May 2018 00:00:00 +0000https://1000ch.net/posts/2018/merpay-tech-meetup/もう締め切りが過ぎていますが、5月18日に株式会社メルカリで開催される merpay Tech Meetup #5 に出演します。遊びに来る人は声をかけてくれると嬉しいです。 5月はこの他にも 日本のお金をアップデートする。#01 お金の価値はどう変わる？: 5月21日、Techplay（渋谷） merpay×FOLIO×CAMPFIRE×ROLLCAKE Design TALK! : 5月22日、株式会社メルカリ（六本木） と、イベントが目白押しです。6月以降も色々なイベントが開催されるはずなので、日本のお金に興味がある人はチェックしてみてくださいね。https://1000ch.net/posts/2018/hitachi-bd-sv110bl/Fri, 04 May 2018 00:00:00 +0000https://1000ch.net/posts/2018/hitachi-bd-sv110bl/Panasonic のプチドラムを買ってパンツが吹っ飛んでから早三年、ドラム式洗濯機を新調した。 もともとは、手入れはしていたものの3年も使っていると見えていない部分の汚れが気になりはじめて、まるごと洗ってもらおうと、業者をくらしのマーケットで探していた。しかし、ドラム式洗濯乾燥機の清掃に対応している業者がかなり少ないのと、対応していても料金が 40,000 円 ~ 50,000 円とかなり高額である。更に、分解掃除してもらった後に壊れてしまった話も聞いていたので、いっそ買い替えてしまおうと思い立った。 今回買ったのは日立のドラム式洗濯乾燥機 BD-NV110BL で、前まで使っていたプチドラムとは異なり、ビッグドラムという名前がついている。プチドラムのような小さいサイズを展開しているメーカーは、最近では少ないようだ。 洗濯機能 : 洗浄方式 : ナイアガラ洗浄、「洗剤・汚れ」センサーシステム、温め自動モード・黄ばみ除去、予防機能 : 温水ナイアガラ洗浄・節水機能 : 強力循環ポンプ・すすぎ機能 : ナイアガラすすぎ、お湯取機能、清水すすぎ・脱水機能 : ほぐし脱水、温風ほぐし脱水 乾燥機能 : 乾燥方式 : 風アイロン、ヒートリサイクル乾燥・除湿方式 : 2way除湿方式 (空冷/水冷) 清潔機能 : 洗濯機お手入れ : 自動おそうじ、内面フラットホース、槽洗浄、槽乾燥・衣類清潔 : 消臭除菌、花粉除去 お役立ち機能 : スチームアイロン・脱水/乾き具合ボタン 駆動方式 : インバーター・予約機能 : 洗濯 : 3～24時間/洗濯～乾燥 : 5～24時間/乾燥 : 5～24時間・目安時間 : 洗濯 : 33分/洗濯～乾燥 : 約165分 プチドラムからビッグドラムへ 前に使っていた Panasonic のプチドラムは、洗濯 7kg で乾燥 3.5kg という一般的な集合住宅の防水パンであれば収まるサイズだった。今回の日立のドラム式洗濯乾燥機 BD-NV110BL は BIG DRUM と名前がついている通り、洗濯 11kg で乾燥 6kg と大きくなっている。伴って、外形寸法も幅 73.https://1000ch.net/posts/2018/techbookfest-vol4/Sun, 22 Apr 2018 00:00:00 +0000https://1000ch.net/posts/2018/techbookfest-vol4/会社がスポンサーをしていたり、知り合いや同僚が出展していたりと、行く機運が高まったので技術書典4に初参戦してきた。現地に到着する前から入場制限に関するツイートを観測していて、混雑具合が心配な状態で向かったが、案の定凄い人の数だった。 入場を果たすも Web っぽいゾーンの混雑が凄まじかったので、一次退散して友人と鮨を食してお茶を濁した。Web ゾーン以外も知り合いがたくさんいて、スタッフとして参加していたり、サークル出展していたり、はたまた参加者として出くわしたり。イベントとしては、お祭り感も然ることながら、いる人が一同に技術で盛り上がっていることがとても良かった。 改めて Web ゾーンに突撃し、日経電子版のチームが無料で配布していた新聞と以下2冊を購入した。冊子で読む機会は減っているのだが、薄い本ということも手伝ってサクサク読めて、3冊合わせて1時間程度で読了。 #技術書典 戦利品 pic.twitter.com/rRFthZgXLY — 🍵 #超速本 (@1000ch) 2018年4月22日 日経電子の本 ハイパフォーマンスで話題になった日経電子版（ https://r.nikkei.com ）の舞台裏が書かれている本が無料で配布されていた。本というか新聞形式で配布されていて、新聞社ならではだと思う一方で、縦文字と新聞特有のレイアウトに惑わされ、読むのに苦戦した。ボリュームもかなり大きく読み応えがある。色んな背景で無料になったようだが、お金を出したいレベルである。また、せっかくなので後日電子媒体上で公開されることを期待したい。 個人的には左傳の欄がとても良かった。 SPA なんぞ要らんと言わんばかりに https://t.co/X0JB9v1vJS が速い。静的リソースは h2 で push しつつ、HTML も Service Woker でキャッシュ。画像はキッチリ最適化して、<picture> 要素でレスポンシブにロードしてる。etc — 🍵 #超速本 (@1000ch) 2017年11月6日 イヌでもわかるHyperapp 約 1KB の超軽量 JavaScript ビューライブラリ hyperapp/hyperapp について、設計思想や構成要素、コンポーネントライフサイクルといった基礎から、Markdown エディタといったサンプルアプリケーションの実装を通して応用を学んでいくという構成の本。紹介しているのが v1 についてだが、v2 についても簡単に触れている。 応用編で扱っている Markdown エディタでパーサーに marked を使っているが、一時期問題になっていた気がするセキュリティの問題はどうやら解消されたらしい（個人的に最近は markdown-it/markdown-it を使っていた）。また、Markdown を変換した結果の HTML を innerHTML に代入している箇所があるが、ここを hyperapp の vdom を使って HTML を差分適用できたりしないのかなと読みながら思った（完全な思いつきなので、できるかどうか不明。無責任）。 イヌでもわかるウェブフォント Web フォントに関することを幅広く取り扱った本、38ページ、500円。Web フォントとは何か、フォントファイルの種類、Webフォントを扱うときの各種最適化などカバーしているバランスの良い一冊。https://1000ch.net/posts/2018/first-quarter/Wed, 04 Apr 2018 00:00:00 +0000https://1000ch.net/posts/2018/first-quarter/年始に目標を掲げたのでその振り返りと、次の三ヶ月の目標を立てる。 Q1（2018年1月~2018年3月） WebPonize を開発する https://github.com/webponize で運用する Homebrew でインストールできるようにする 両方達成した。アプリケーションのリポジトリとランディングページのリポジトリしかないが、自分のリポジトリも増えてきたので、org という形でグルーピングできるものはしていきたい（大半は該当しなそうだが）。 麻雀のスコア集計アプリを開発する データベースを設計する Ruby on Rails で API サーバーを実装する 着手して何らかの進捗を出すという目標だったが、API レイヤは違う人がやってくれているので、いつも通り Web 部分を実装している（Web Backend <-> Web Frontend）。 「人間は何事も始めるまでの腰は重たいが、一度始まってしまえば進みはじめる」 という言葉を思い出した。 実装のアレコレや成果物はもう少し形になったら記事としてアウトプットする、はず。 読書とランニング 月間に読書 2 冊とランニング 20km を掲げて、実施はしているが順調ではない。 読書に関しては、1月になるほどデザインを読んだのと、2月に君主論を読んだのみで、もう少しペースを上げる必要がある。iPhone が防水なので風呂場に持ち込んで、読もうと画策している。積読の中ではピクサー流　創造するちからあたりから読もうかと。 ランニング 20km は週に 5km 走れば良いのだが、怠けていた。体力的に 5km を走ることは難しくないので、ランニングウェアに着替えて外に出ることを努力してみる。 2Q（2018年4月~2018年6月） 麻雀のスコア集計アプリを完成させる Q1 で始まってくれたおかげで趣味コードを書くのが楽しいので、このまま動く状態まで仕上げたい。Ruby on Rails で作っている API 側にも PR を出す。 vim + tmux 再入門 門を叩いては出てきているので、再度やってみようかと。 自転車を買う 友人達に付き合ってもらって Y’s Road に行ったり、tokyobike などで、そこそこ良い自転車を買おうと探している。tokyobike は可愛らしいデザインの自転車ばかりでとても良いのだが、修理保証が tokyobike でしか受けれない気配などのロックインが悩ましい。安くはない買い物だし、デザイン等も好みじゃないと乗らない気もするので、いやはや。https://1000ch.net/posts/2018/manabiya-tech/Wed, 28 Mar 2018 00:00:00 +0000https://1000ch.net/posts/2018/manabiya-tech/3月23日、24日の二日間で開催された MANABIYA -teratail Developer Days- に出演しました。二日目に Web のトピックを集めたトラックがあり、その中で 2018年の Web 標準というセッションで講演しました。 3331 Arts Chiyoda 会場は千代田区外神田にある 3331 Arts Chiyoda という、閉校した中学校を改修して作ったアートスペースで、イベント名とずばりマッチ。空き教室がセッション会場になっていて、記憶に懐かしい木のタイル床に学校椅子という、なんとも懐かしい雰囲気です。セッションに使われた教室以外は展示スペースになっていて、色んなアート作品が飾られていました。 校舎の 1F には常設されているカフェがあります。天気が良かったので、ここでパンとコーヒーを買って外の階段に座って Web 勢で昼食を取りました。5時間目に屋上で開催される CrossSession のアンカンファレンスになりかけたところでハッとなり自粛したところでランチは終了。自分の担当セッションは2時間目だったので、大変晴れやかな気持ちで昼食を取っていました。 教室のほか、屋上に設営されたテントがセッション会場になっていて、Web の CrossSession もここで開催されました。セグウェイの試乗コーナーもあり、体験してみたかったけど混んでいたので断念。 セッションの様子など ありがたいことに満員御礼でした。2018年の Web 標準ということで Service Worker、Web Components、Web Payments の話をしました。この3つは決して真新しいものではないですが、強力かつどれもブラウザ実装が進んでおり、これから導入事例が増えてほしいという期待を込めてのトピック選定です。 今年のはじめに gihyo.jp の新春特別企画ということで、同じタイトル 2018年の Web 標準 という記事を寄稿しました。セッションに近い内容を書いていますので、こちらも合わせて御覧ください。https://1000ch.net/posts/2018/leave-cyberagent/Wed, 28 Feb 2018 00:00:00 +0000https://1000ch.net/posts/2018/leave-cyberagent/2018年2月末日を以て、株式会社サイバーエージェントを退職します。2012年の7月に入社したので、5年8ヶ月という長い期間在籍したことになる。 const diff = new Date('2018/2/28') - new Date('2012/7/1'); const days = diff / (1000 * 60 * 60 * 24); console.log(`${days} days`); // => 2068 days SIer で受託開発に勤しんでいた中で、ある日見たテトリスを1時間強で作ってみたという動画に衝撃を受けた。技術者として「エンジニアリングをもっと追求したい」と思った中で、それを取り組んでいくために適した環境ではないと悟ったのが理由の一つにある。受託開発という事業性質上、いかにエンジニアリングに工数をかけないかという企業利益の根底があるので、この方針を覆すのは難しい。 転職エージェントと話したところでいくつか Web 系の会社を提案してもらった。SIer に所属して受託開発に従事していた中で、Web 業界は眩しく見えていたのをよく覚えている。そんな中、サイバーエージェントは2012年11月末までにスマホ向けに109個のサービスを提供することを掲げている最中だった。 入社できたのは、本当に運が良かったと思っている。転職活動中に関わっていた企業向けのイントラシステムの Web アプリケーションを実装している中で、一定の興味関心を Web に注いでいたものの、業務コンテキストもスキルセットも異なる中で、よく採用されたなと今でも思う。前職の SIer で関わっていた業務システムのプロジェクトで jQuery に感動して、DOM 操作のライブラリを自作するなどをしていたが、そうした活動が高評価だったのかもしれない。 退職の経緯も複合的でコレと言ったものがない。他の会社のエンジニアリングが気になったり魅力的に見えることもあるし、長らく働いていれば少なからず飽きることもあるし、組織で働く必然として組織の倫理や他人との摩擦に疲れることもあるし、自分が感じる社会的な問題を解決するプロダクトに関わりたいと思うなどなど、理由は様々だ。今回の決断に際して転職活動をした中でいくつかの企業様と話をさせてもらったりオファーを頂いたりしたけど、在職中にも同じことをしたことはある。自分の選択肢を考え直したり増やしたりを繰り返してきたけど、その中で5年8ヶ月という長い年月、残る選択を続けてこれたのはサイバーエージェントが楽しく魅力的で優れた企業だったことに他ならない。サイバーエージェントという環境が自分のエンジニア人生の転機になったことは間違いない。 自分がどのくらい会社に貢献してこれたかは自分ではわからないことも多いけど、退職を報告した同僚に引き止めてもらったり一定惜しんでもらえたことは冥利に尽きる。本当にお世話になりました、どうもありがとうございました。 Wishlist です。https://1000ch.net/posts/2018/webcomponents-in-production/Fri, 16 Feb 2018 00:00:00 +0000https://1000ch.net/posts/2018/webcomponents-in-production/とあるプロジェクトの技術監修をして、大まかに Web Components + Payment Request API な構成で進めてみたのでその話を思い出しながら書く。ちなみに FRESH! ではないです。 決済基盤をサービスで使うための SDK Payment Request API でお察しの通り、新たな決済基盤のプロジェクトで、それを使うための SDK を読み込んでボタンを配置すれば決済できる…みたいなものを作った。Payment Request API は、対応している環境ではそれで、対応していない環境では旧来の通り決済代行業者が用意しているフォーム付きページへ遷移させるという形でビジネスサイドへ提案した。 技術面に関しても、FRESH! で導入済みだったこともあり、いざとなればサポートできるという意味で心配はあまりないつもりだった。実際には iOS Chrome の Payment Request API 実装に幾つかバグがあったり、決済代行業者との通信時にデータを指定のフォーマットで暗号化しなければいけなかったりと、いくつか地雷は踏みぬいたが…。 806272 - Cannot type sonant mark (Japanese) on any input area of Payment Request API dialog - chromium - Monorail 806666 - Total amount validation is wrong on Payment Request API - chromium - Monorail ボタンを Web Components で配布したい 配布したい機能を含む JavaScript と CSS をロードさせて使ってもらう、昔ながらの形ではなく、Web Components で定義し配布させることにした。https://1000ch.net/posts/2018/inside-frontend-vol2/Wed, 14 Feb 2018 00:00:00 +0000https://1000ch.net/posts/2018/inside-frontend-vol2/第二回となる Inside Frontend を2月11日に開催しました。今年は超速 AMA 枠で出演しつつ、スタッフ業をこなしました。 会場は日本経済新聞社 昨年は、紀尾井町にオフィスを構える Yahoo! Japan での開催でしたが、今年は大手町にある日本経済新聞社の日経カンファレンスルームにて。Frontend Meetup Tokyo の開催等で何回か行ったことがありましたが、大手町駅直結しています（C2b 出口）。 駅地下街も栄えていますが、日曜日ということで軒並み閉店という噂がタイムラインを賑わしていたので、急遽渋谷のモスバーガーにて朝食を取りました（超速 AMA プレゼントの超速本を取りにオフィスに行ってた）。 公式でアナウンスしたほうがいいんじゃないかレベルの休業状況 — 🐕 Hiroki tani ☕ (@hiloki) 2018年2月11日 早めに来て珈琲でも飲もうと思ったらビルの飲食店が壊滅的に開いてない — :masuP9: (@masuP9) 2018年2月11日 トラック 去年は3トラックでしたが、今年は2トラック構成でした。例年通り AMA の時間もありましたが、昨年の反省を活かして休憩を適度に挟んだタイムテーブルに。スタッフ労働しながら、合間時間を縫ってセッションを拝聴しました。 当日の様子は AMA と非公開セッションを除き、アーカイブされています。 Inside Frontend #2（Seminar A） | FRESH!（フレッシュ） - 生放送がログイン不要・高画質で見放題 Inside Frontend #2（Seminar B） | FRESH!（フレッシュ） - 生放送がログイン不要・高画質で見放題 freeeのアクセシビリティ、いまとこれから 伊原さんが freee でやっているアクセシビリティの推進活動について。まさに （いきなり全部ではなく）できる部分からやる を体現している話でした。 組織におけるアクセシビリティの意義を、「正当性で殴るのか、はたまた KPI で納得させるのか」みたいな話がこのセッションではないどこかでありましたが、両面で訴えているのが印象的でした。「協力者が欲しい」話はｳﾝｳﾝという感じ…。 Web Payments / Payment Request API について何でも訊いて下さい 最近立て続けに Web Payments に関わるプロジェクトをやっていたこともあり、理解が及んでいなかった部分を聞けてよかったです。Web Payments / Payment Request API そのものが決済機能を持つという誤解をしている人も多かったのではないでしょうか。https://1000ch.net/posts/2018/android-shared-preference/Thu, 18 Jan 2018 00:00:00 +0000https://1000ch.net/posts/2018/android-shared-preference/Android のアプリケーションでデータの永続化をしてくれる SharedPreference だが、これがなかなかつらい。SharedPreference はコンストラクタに ApplicationContext を渡してインスタンスを生成するが、肝心の値の取得と保存が面倒である。 値の取得と保存 SharedPreference のインスタンスを取得して、アレコレする。インスタンスの生成は PreferenceManager からじゃなくても良い。 val p: SharedPreference = PreferenceManager.getDefaultSharedPreferences(context) // getString() で文字列を取得する val data: String = p.getString("key", "default value") // putString() + commit() で文字列を保存する val editor: SharedPreferences.Editor = p.edit() editor.putString("key", "new value") editor.commit() 保存時は SharedPreferences.Editor インスタンスの put***() メソッドで値をセットし、 commit() メソッドで保存を実行する。保存先は XML ファイルなので、IO を最小限にするためのインターフェースになっている。 保存したいデータモデルとSharedPreferenceへのアクセスの抽象化 やり方はいくつか思い浮かんだが、最適解が浮かばないのでひとまず以下に落ち着いた。Context をコンストラクタの引数にとり、メンバ変数に SharedPreference を初期化する。 import android.content.Context import android.content.SharedPreferences import android.preference.PreferenceManager class Preference(context: Context) { val p: SharedPreferences = PreferenceManager.https://1000ch.net/posts/2018/webponize-v2/Wed, 03 Jan 2018 00:00:00 +0000https://1000ch.net/posts/2018/webponize-v2/大晦日と正月で WebPonize を色々アップデートし v2.0.0 としてリリースした。 Swift-WebP libwebp を自前でラップしていたが、ainame/Swift-WebP を使うようにした。ついでに CocoaPods から Carthage へ移行した。 libwebp のオプションはたくさんありラップするのも一苦労だったが、Swift-WebP はかなり丁寧にラップしてあったので、重い腰をあげて実行時オプションを設定できるようにした。 主に使うと思われる設定を General タブに、フィルタ関連は Filter タブ、アルファ関連は Alpha タブにコントロールを配置した。余程細かく設定したいときを除けば、Filter タブと Alpha タブを使う必要はない。 webponize チームの作成 プロジェクトサイトのために github.com/webponize を作っていたが、アプリケーションのリポジトリもここで運用することにした。 webponize.org の新設 webponize.github.io にあったプロジェクトサイトを、リニューアルがてら webponize.org へ引っ越した。アプリケーションの自動アップデートする Sparkle から参照するアップデート情報を記載した appcast.xml も、ここから配置した。 webponize.org は Google Domains で取得し、静的サイトは Firebase Hosting でホストし、GitHub へのコミットで自動デプロイという組み合わせである。特別、Google Domains と Firebase Hosting の親和性が高いわけではないが、どちらもサービスとして使いやすいし、HTTPS の設定も簡単で非常に良い。https://1000ch.net/posts/2018/naruhodo-design/Tue, 02 Jan 2018 00:00:00 +0000https://1000ch.net/posts/2018/naruhodo-design/誰のためのデザイン と比較するなら、より実践的なデザイン論が書かれているのが本書。「なぜ」「いつ」「どこで」といった目的にフォーカスしているのが良かった。 Chapter 1 でデザインのケーススタディと基本戦略、Chapter 2 でデザイナーが気をつけるべき7つのポイント（どちらが大事か、何を目立たせるか、何を想起させるか、何が関連するか、ジャンプ、細部、愛）、Chapter 3 でデザインの構成要素（文字組、言葉と文章、色、写真、グラフ）について書かれている。 筒井 美希 デザインを具体例を比較しながら進むので、納得しやすく、わかりやすい。活字も少なめでサクサク読み進められる。その具体例のせいか少しだけ DTP 寄りな話にも見えたが、Web の人間だからそう感じただけかもしれない。https://1000ch.net/posts/2018/goal/Mon, 01 Jan 2018 00:00:00 +0000https://1000ch.net/posts/2018/goal/1年間の目標を立てたいところだが、ゴールを年末にしてその目標を追いかけ続けるのが難しいものもあるので、大きいゴールと小さいゴールに分割して、3ヶ月間と1年間という単位で分けて追ってみようと思う。 1年間で追うものは、既に習慣化しているあるいは習慣化させたいものであったり、達成に長期間が必要なもの。3ヶ月間で追うものは、より短期的に成果を振り返りたいもの。 1年間 ブログを24回更新する ポッドキャストを24回配信する 本を24冊読む 年間240km、月間20km走る 体重を 56kg~58kg に維持する 3ヶ月間（2018年1月~2018年3月） WebPonize を開発する https://github.com/webponize で運用する Homebrew でインストールできるようにする 麻雀のスコア集計アプリを開発する データベースを設計する Ruby on Rails で API サーバーを実装するhttps://1000ch.net/posts/2017/look-back-over-2017/Sun, 31 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/look-back-over-2017/WIP 社内の啓蒙活動 業務では、パフォーマンスやアクセシビリティといった Web の品質や技術支援、プロジェクトの体制等に関わってきた。色々やったけど、主だった部分だとこの辺り。 FRESH! Web パフォーマンス改善 〜クライアントサイド編〜 「アクセシビリティに取り組むことが価値あるサービスづくりにつながる」サイバーエージェント技術者たちの取り組み 横断組織の力を借りてプロダクトをより良くするには？電子書籍サービス「読書のお時間です」パフォーマンス改善の進め方 WebパフォーマンスとプロダクトKPIの相関を可視化する話 社外の啓蒙活動 2月に開催された Developers Summit 2017 にはじまり、Inside Frontend #1、HTML5 Conference 2017、Polymer Japan Meetup #1、AKAMAI EDGE JAPAN2017、html_modules_studyと、たくさんの勉強会に出演させていただいた。 超速本の出版 かれこれ約2年間執筆していた超速! Webページ速度改善ガイド、通称#超速本が世に出た。 ほぼ趣味の領域で、特設サイトも作ってみた。 ポッドキャスト 細々と strobo.fm を開始した。GarageBand の使い方もわかってきたし、マイクやオーディオインターフェースも購入して徐々に環境が整いつつあるので、まずは継続を意識してやっていく。https://1000ch.net/posts/2017/sonshi/Fri, 29 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/sonshi/もともと三国志が好きで、小説（演義）を読んだりゲームの三国志はよくやっていて、物語中でもでてくる孫子という兵法書が存在することは知っていた。著者の孫武は、三国志の呉を統治する孫堅・孫策・孫権の祖先にあたるらしい。 兵法書ということで、戦乱の世をどのように戦い抜くかが記述されている。といっても、特段変わった戦法や戦術が示されているわけではなく、戦に勝つための要素が13篇に分解されて書かれている。戦の勝敗は天運に左右されるわけではなく、事前にしっかり準備し、臨機応変に行動し、軍勢から勝機を判断し…といったような、然るべき次項を着実にやるというもの。ので、基準が戦争になっているが、普段の行動に反映できるものばかりである（戦争→日常生活だとジャンプが大きい気もするが）。 金谷 治(著) 孫子は色んな出版社から出版されているが、岩波文庫の本書は1篇毎に「漢文（白文）」「書き下し文」「日本語訳」の三段構成になっている。自分は日本語訳しか読まなかった。https://1000ch.net/posts/2017/steinberg-audio-interface/Wed, 27 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/steinberg-audio-interface/今年から細々とはじめたポッドキャストの環境を、少しずつ整え始めた。 マイクについては Audio-Technica ATR2100-USB ダイナミック USB/XLR マイクを購入して使っていた。音質はかなりクリアで流石マイクといったところだが、感度が低くパソコンにインプットされたデータはソフトウェアによる増幅が必要で、そのためホワイトノイズが入りがちなのが気になっていた。 Handheld dynamic microphone with USB digital output and XLR analog output. USB output connects to your computer for digital recording, while the XLR output connects with your sound system conventional microphone input for use in live performance. Smooth, extended frequency response ideally suited for podcasting, home studio recording, field recording, voiceover, and on-stage use. Built-in headphone jack allows you to directly monitor your microphone output without audible delay.https://1000ch.net/posts/2017/fuglen-tokyo-test-roast/Mon, 25 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/fuglen-tokyo-test-roast/Coffee Advent Calendar 2017 の5日目の記事「コスパの良い豆を入手できるお店」で紹介されている、Fuglen Tokyo のテストローストの豆を購入した。 パッケージ このコーヒーはテストローストです。店頭で販売するために最適な焙煎プロファイルであるとは言えませんが、スーパーマーケットやコンビニエンスストアのコーヒーに比べますと、品質は間違いなく高いものになります。価格はテストロースト価格とさせていただいております。オフィスなどのコーヒーとして、ぜひお試しください。 ホンジュラスの豆だが、他の産地のテストローストがあるかどうかはわからない。 豆 この前に飲んでいた某所で購入した豆が、焙煎方法のせいかベタベタしていてミル部分に引っかかって困っていたのだが、この豆はサラサラしている。 1kgということで少し多く風味の劣化が心配なところもあるが、まずまずの頻度で飲んでいるし、もちろん美味しいのでコスパは間違いなく良い。https://1000ch.net/posts/2017/nature-remo-google-home/Sun, 24 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/nature-remo-google-home/既に情報は出回っており目新しいものではないが、ようやく Google Home と Nature Remo を連携して声で家電を操作できるようになったので、その作業ログをまとめておく。 Nature Remo とは Nature Remo は家電をスマートフォンなどから操作するためのハブとなるデバイスである。 Nature Remo は赤外線を発信できるようになっており、これによってエアコンやライトなどの赤外線リモコンで操作する家電を操作できる、という理屈である。Nature Remo はインターネットを通してアプリなどから操作できるので、家にいるときはもちろんのこと、外出中でも Nature Remo を操作し、家電の管理が可能である。赤外線で操作できるデバイスならなんでも良いので、抜群に汎用性が高い。 Nature Remo でエアコンやライトを操作する 手始めにエアコンを Nature Remo から操作できるようにしてみる。といっても、もともと赤外線リモコンで操作する家電なので Nature Remo をセットアップし、エアコンまで赤外線が届く場所に配置すれば良い。あとは Nature Remo のアプリをインストールすれば使えるようになる。スマートフォンよりは使う頻度が低いせいか、よくリモコンを見失うので、使う必要がなくなるだけでも便利だったりする。 あとは天井の照明を Nature Remo で操作できるようにしてみよう。もともと家に備え付けのライトはなく、無印良品のペンダントライトに LED 電球を付けて使っていた。 口金：E26 演色指数(CRI)：80Ra以上 入力電圧：AC100－240V　50/60HZ 入力電流：0.11A 定格消費電力:13W　全光束：1100lm ビーム角：270°　色温度：6000K　サイズ：Φ95*138mm そのため照明のオンオフを切り替えるには壁にあるスイッチを押すしかなかったのだが、これについては @horimislime に教えてもらった天井とペンダントライトの間に装着するリモコンスイッチを中継することで、まずは赤外線リモコンで操作できるようにした。 サイズ:8.3×9.6×4.5cm 本体重量(kg):0.115 Nature Remo アプリの Control タブから+ボタンをクリックし、新たなコントロールを追加する Nature Remo 本体に向けて登録したいリモコンの操作を実行する プリセットとして登録されている場合は自動的に認識されるのでそれを利用する プリセットとして登録されていない場合は、それが何の操作なのかわかるような名前やアイコンを設定する これで Nature Remo アプリの Control タブに新しいコントロールが追加される。この時点で、追加したコントロールから家電を操作できるかどうか確認しておくと良い。https://1000ch.net/posts/2017/nakamoto/Tue, 12 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/nakamoto/蒙古タンメン中本 Advent Calendar 2017 12日目の記事です。 ちなみに去年も 蒙古タンメン中本 2016 Advent Calendar 2016 に参加して味噌卵麺について書いた。今年も味噌卵麺ですが、最近ハマっている豆腐変更オプションについて。 豆腐変更券は60円で、ラーメンメニューの麺を豆腐に変更できるオプションだ。冷し麺や半ラーメン系には適用できないが、普段味噌卵麺を食べている私にとっては非常に興味深いものだった。 お腹の肉が気になる年頃に差し掛かり、食生活も気にするようになってきた。麺の糖質がいかほどで、豆腐に変更することでどれほど絞れるか詳しい数字はわからないけど、豆腐の成分表を見てみると大部分はタンパク質である、麺のそれに比べて明らかに炭水化物の割合が小さいのがわかる。これがどれほどダイエットに寄与するのかはさておき、物は試しだ。食べてみよう。 一見して普通の味噌卵麺だが、もやしを少し避けてみると豆腐が現れる。 辛いスープに入っている麺が豆腐になるともはや麻婆豆腐だとか鍋だとかいう声もあるが、美味しければなんでも良い。 豆腐そのものも美味しいが、麺による炭水化物プレッシャーがなく心理的安全性が保たれたまま楽しめる一品になる。ということで「麺だと炭水化物が気になる…」という人に、一度試して欲しいオプションだ。https://1000ch.net/posts/2017/fujisoba-yoyogi/Thu, 07 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/fujisoba-yoyogi/代々木に引っ越したのは一年半程前になる。 駅から程ない場所に富士そば代々木店は佇んでいるが、通うようになったのはごく最近である。きっかけは思い出せないが、おそらく富士そばおじさんに影響されたせいだろう。 昔から富士そばという存在自体は知っていたし行ったこともあるが、私の中でここまで存在感を大きくしたのは富士そばの魅力に取りつかれたことに他ならない（たぶん、一度入って慣れただけだが）。 富士そば代々木店は駅から徒歩5秒の地点にある。周辺の車通りもあまり多くなく、交番の真裏にあるので治安もバッチリだ。 店の外に券売機がある。Suica が使えるのは外の券売機だけなので、注意が必要だ。 店の中にも券売機があるが、こちらは現金のみ対応している。 店の中はあまり広くない。立ち食いを含めて、合計15席程度だったはず。 普段は肉富士、ゆず鶏ほうれん草あたりでうどん系を攻めることが多いが、今日はもりそばを注文してみた。 早い、安い、そこそこ美味い。 富士そば Advent Calendar 2017 7日目の記事でした。https://1000ch.net/posts/2017/bought-in-2017/Tue, 05 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/bought-in-2017/今年買ってよかったもの Advent Calendar 2017 5日目の記事です。ちなみに去年は Apple Watch の話を書きました。 髪の毛くるくるポイ 髪の毛くるくるポイが革命的だったで書いてある通り、これで風呂場の排水口の問題の大半が解決された。 サイズ:(約)外径寸法 直径120mm 厚さ45mm。本体重量:35g。素材:本体/ポリプロピレン。原産国:日本 風呂場の排水口についている備え付けの目皿には、毛が絡みついて剥がし取りにくく、シャンプーやリンス、ボディソープの泡などが付着して汚い。しかし、この目皿に取り替えてからというものの、毛は中心部の凹みにまとまり、泡やヌメリがたまっていることはほとんど無い。 Bluelounge Kickflip MacBook Pro MacBook Pro の底面につけてフリップ開くと、ボディ部分が浮く。これによって放熱効果が増し、キーボード面に角度が付くことでタイピングがしやすくなるというツールである。 吸着パッドで貼り付けて足を立たせ、空間を作り熱を逃す薄型エアスペーサー。ハイテク吸着素材でしっかり固定 アプリケーションをたくさん起動したり、重い処理を走らせたりするとファンがフル稼働する、というのはしばしばある。macOS であればアクティビティモニタで CPU に負担をかけているアプリケーションを探すやら、Chrome で開いているタブを最小限に抑えるなどの対策も考えられるが、熱くなってしまったものは冷やすしかない。 またキーボード面に角度がついたことで思った以上にタイピングがしやすくなった。こればかりは一度体験してみないとわからないけど。 MacBook Pro とあるが、底面が凸凹していなければ他のノートパソコンにも装着できるだろう。接着部分は樹脂になっていて、粘着力が落ちて来た場合はキレイに洗うことでまた復活するとのこと。違うパソコンに付け替える場合があれば試してみたい。　CARRY saKASA ビニール傘だと大切にする気持ちが薄れてしまうため、ある時からしっかりした傘を買うようになった。ここ最近は Makuake で購入した 超撥水傘「Nu-Rain（ヌレイン）」 を持ち歩いていたが、折りたたみではない傘を持っていても良いかなと思い、評判を知っていたこちらの CARRY saKASA を買った。 逆折り式傘(実用新案第3200570号)。重量:480g / 長さ:80cm / 開放時直径:105cm / 親骨材質:グラスファイバー / 親骨:8本 この傘の最大の特徴は傘の閉じる向きが逆さである点である。指した時に雨を防ぐ外側が、畳んだ時に内側に来るようになっているので、濡れた面に触れにくく、構造上強風にも強い。また、自立するので、干す時に場所を取らず電車などでも邪魔になりにくい。 CARRY saKASA の凄さはこの動画が一番わかりやすい。 従来の傘では車に乗り込む時にギリギリまで指していると乗りにくいが、CARRY saKASA であれば動画のように全く濡れずに乗り込める。車を持っていずとも、タクシーに乗り込むときなどにかなり有用である。 Public Model という廉価版もある。お手頃価格なので、まずは試したいという人はこちらが良さそう。 逆折り式傘(実用新案第3200570号)。重量:500g / 長さ:80cm / 開放時直径:114cm / 親骨材質:グラスファイバー/ 親骨本数:8本https://1000ch.net/posts/2017/muji-coffee-maker/Sat, 02 Dec 2017 00:00:00 +0000https://1000ch.net/posts/2017/muji-coffee-maker/私はコーヒー好きである（詳しいわけではない）。しかし、カフェ等で買って飲む以外の選択肢を取ってこなかった。ミルで挽く、ドリップするという手間が惜しい以前に、台所をほとんど使っていないので、水回りをメンテナンスするのが面倒という理由だ。 しかし各位のコーヒー熱に触発されて機器を揃えてみても良いかなと高まっていたところで、下北沢の無印良品に赴いてみると豆から挽けるコーヒーメーカーの姿があった。結論から言うと買ってしまったわけだが、購入に至ったモチベーションや使っている感想などを綴っていく。 豆から挽けるコーヒーメーカーの良いところ 買っても良いと思えた一番の理由は全自動という点である。手動のミルで豆を挽いて、決められた温度のお湯でハンドドリップする楽しみもありそうだが、やっているうちに面倒臭くなる気がしたので、豆を挽いてドリップするところが自動というのは最大のポイントである。 一度に3杯分までドリップできる。備え付けの軽量カップに豆を入れ、杯数分の水を入れ、ロート部分にペーパーフィルタをセットし、あとはボタンで操作するだけでドリップしてくれる。購入前まではペーパーフィルタを都度買うのが面倒な気がしていたが、いざ使い始めてみるとドリップ後のコーヒー豆をペーパーフィルタごと捨てれて楽である。金属網ならランニングコストがより少なく済むかもしれないが、微々たるものだ。 豆を挽くときにダイヤルで粗さを指定できる。粗くすればお湯が豆に触れている時間が短くなるので味が薄くなり、細かくすればお湯が豆に触れている時間が長くなるので濃くなる。同じ豆でもこの設定差で味が結構変わってくるので、好みに合わせると良い。また、上から二番目のボタンであらかじめ挽いてある豆もドリップできる。 タイマーもセット可能で、夜のうちに豆と水を仕込んでおいて朝7:00に☕を飲めるように予約しておくこともできる。ドリップされたコーヒーは下の受け皿に溜まるが、保温機能が付いているので冷めることなく、常に温かいコーヒーを楽しめるようになっている。 手作業じゃないので細かな調節はできない反面、手作業で面倒な部分をおまかせできるのが最大のポイントだろう。 コーヒー豆を買うのが楽しみになった 今までは凝ったカフェに行ってもコーヒーを飲むだけだったし、豆の専門店に行っても香りを楽しむだけだったが、コーヒーメーカーを手に入れたことで豆を選ぶ楽しみを覚えた。最近だと、渋谷ヒカリエにある Paul Bassett に連れて行ってもらって、ルワンダとグアテマラのコーヒー豆を購入した。 コーヒーを飲んでいても酸味や苦味の有無くらいしかまだわからないが、詳しい皆さんに更なるコーヒーのイロハを教わっていきたい。渋谷でオススメのコーヒーショップとか、産地固有の香りや味わい、など。そのうちコーヒーカップやらにも手を出しそうで、若干怖い気もしている。 Coffee Advent Calendar 2017 二日目の記事でした。https://1000ch.net/posts/2017/module-preload/Sun, 26 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/module-preload/<link> 要素の rel 属性に、新しく modulepreload という値が ES Modules を先行してロードする仕様として追加され、Chrome 64 に実装された。リソースを先行してロードする手段としては既に <link rel="preload"> があり、スクリプトファイルには as="script" を指定すれば良いが、ES Modules をロードするためにはいくつか問題があり、新しく rel="modulepreload" が検討されている。 <link rel="preload" as="script"> ではダメなのか もとい <link rel="modulepreload"> にすべき理由が Preload and Modules に書かれている。 <link> 要素によるリクエストの credential が <script> 要素と一致している必要がある 事前に module なのかどうかわかっていないとパースに困る (v8 固有？) <link rel="preload"> は単一リソースをロードする仕様である 保存先が preload cache ではなく module map である必要がある (chrome 固有？) <link rel="preload"> の保存先は preload cache/HTTP cache である as="" で対応しようとすると modulescript / moduleworker / modulesharedworker / moduleserviceworker と、様々な値を定義しなくてはならない つまり Normal Script と Module Script を区別する必要アリということだ。https://1000ch.net/posts/2017/hair-kurukuru-poi/Sat, 25 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/hair-kurukuru-poi/風呂場の排水口についている備え付けの目皿では、色んな毛が絡みついて剥がし取りにくい上に、シャンプーやリンス、ボディソープの泡などが付着してとても汚い。 髪の毛くるくるぽいはその代わりとなる目皿だが、工夫が施されており水流が渦を作る形状になっている。これによって、髪の毛が中心部の凹みに溜まるようになっており、石鹸カスなどは流れる仕組みだ。 安かったので買ってみたところ、期待以上の働きをしてくれている。同じ問題にお悩みの人は、試してみてほしい。 サイズ:(約)外径寸法 直径120mm 厚さ45mm 本体重量:35g 素材:本体/ポリプロピレン 原産国:日本https://1000ch.net/posts/2017/responsive-iframe/Wed, 22 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/responsive-iframe/当ブログのようなシングルカラムレイアウトに、外部のコンテンツを <iframe> 要素で埋め込む場合、要素の横幅を 100% にして親要素の幅いっぱいに広げたいが、その時に縦横比を維持して縦幅を追従させる場合に工夫が必要である。 デフォルトの埋め込みコード YouTube などの動画コンテンツを <iframe> 要素でエンベッドする場合、次のようなものが用意される。 <iframe width="560" height="315" src="https://www.youtube.com/embed/gTHAn-nkQnI" allowfullscreen> </iframe> 横幅 560px、縦幅 315px で配置されるので、モバイルデバイスで閲覧すると横スクロールができてしまう。これを 16:9 の縦横比を維持しつつ横幅を親要素一杯まで広げたい。 <iframe> 要素そのものをレスポンシブにするには「<iframe> 要素の横幅を親要素まで満たしたい」「親要素の縦幅がテキストなどに依存するので不定である」という制約がある。CSS の width と height プロパティに max-content を指定しても、<iframe> 要素のサイズが読み込みページに依存してしまう。 16:9な親要素を用意して子要素で満たす タイトルの通り、任意の縦横比の親要素を用意して <iframe> 要素をその中に縦横一杯に満たすのが解のようだ。 キモとなるのは親要素の高さの取り方で、素直に height プロパティで指定しようとすると先に述べた通り親要素に対するパーセンテージになってしまうので、padding-top を指定することで高さを確保している。横幅は親要素いっぱいにするので、100% で問題ない。 .YouTube { position: relative; width: 100%; padding-top: 56.25%; } .YouTube iframe { position: absolute; top: 0; right: 0; width: 100%; height: 100%; } 親要素を用意せず <iframe> 要素に対して padding-top を指定しても、読み込んでいるコンテンツに対してパディングが用意されるだけである。https://1000ch.net/posts/2017/resize-observer/Tue, 21 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/resize-observer/便利な Observer シリーズのひとつ ResizeObserver が Chrome 64 に ship された。Chrome 55 からフラグ付きで入っていたが、フラグなしで動作するようになっている。 旧来のやり方と問題 これまでの方法としては resize という DOM イベントを監視することで、要素の変更を検知できた。しかしサイズや位置といった変更の多寡を知るには、Element#getBoundingClientRect() や window.getComputerStyle(Element) といった関数を呼び出す必要があり、これによって強制的にレイアウト処理が実行される。そのため、対象要素の量や処理の重さによってはレンダリングパフォーマンスを大きく損なってしまう。 document.querySelector('div').addEventListener('resize', e => { // レイアウト処理が強制的に実行される console.log(e.target.getBoundingClientRect()); }); ResizeObserver ではこうした問題を解決し、レイアウト処理を呼び出さずに変更を取得できるようになっている。 ResizeObserverの使い方 ResizeObserverの簡単な説明から。 インスタンスの生成と要素の監視 MutationObserver や PerformanceObserver と同様に new してインスタンスを生成後、ResizeObserver#observe() メソッドに監視対象の要素を引数として渡して実行する。 const resizeObserver = new ResizeObserver(entries => { for (const entry of entries) { ... } }); const target = document.querySelector('div'); // target の監視を開始する resizeObserver.observe(target); // target の監視を終了する resizeObserver.unobserve(target); ResizeObserverEntry ResizeObserver に渡すコールバック関数の引数には、検知した変更の構造体である ResizeObserverEntry が配列で渡される。https://1000ch.net/posts/2017/webperf-guide/Sat, 18 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/webperf-guide/事前に各所で告知していた通り、この度 超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる という共著の書籍が、技術評論社より出版されます。名前の通り Web サイトを高速化する知識を得るための本です。 本書の概要 技術評論社の Web サイトの通りですが、目次は次のようになってます。 まず1章で Web パフォーマンスとはなんなのかを、ビジネスへの影響やユーザー環境の多岐化、高度化する Web 技術などの観点で解説します。2章以降では、Web パフォーマンスをネットワーク、レンダリング、スクリプトといった技術要素に分解し、それぞれの基礎知識を抑えつつケーススタディを学んでいきます。また、8章では画像全般（画像フォーマット、最適化方法、レスポンシブなロードなど）について、9章ではネットワーク周辺の新たな技術（Service Worker と Resource Hints）について解説しています。 第1章：Webページの速度 第2章：ネットワーク処理の基礎知識 第3章：ネットワーク処理の調査と改善 第4章：レンダリング処理の基礎知識 第5章：レンダリング処理の調査と改善 第6章：スクリプト処理の基礎知識 第7章：スクリプト処理の調査と改善 第8章：画像の最適化に役立つテクニック 第9章：ネットワーク処理の効率化に役立つポイント 本書は 「○○ファイルを結合してリクエスト数を減らす」 「GPU を有効化する○○プロパティを適用する」 「Service Worker を使ってアセットをキャッシュする」 といったような Tips を集めたものではありません。Web ページやブラウザ内部の仕組みを体系的に解説することで、Web ページが遅くなってしまう原因を調査する力と対処する知識を抑えつつ、Web パフォーマンスについての本質的な理解を促します。続・ハイパフォーマンスWebサイト、ハイパフォーマンス ブラウザネットワーキング あたりの内容を、昨今の Web 事情にあわせてアップデートしている一冊です。 しばしば「どっち（@ahomu or @1000ch）がどこを書いたんだ」と聞かれますが、草稿時点で大まかな分担はあったものの、全体のリファクタリングを両者で繰り返した結果、誰がどの文を書いたのかは正直わからない状況です。真実は git blame のみぞ知る。 書き終えてみて 今まさに業務で Web の品質を啓蒙する立場にあり、そのひとつとしてパフォーマンスにも取り組んでいますが、思い返してみると Web パフォーマンスに関して勉強しはじめたのはサイバーエージェントに転職して間もないころに、Fluid User Interface with Hardware Acceleration という動画をパイセンの逐次翻訳+解説付きで見たのがきっかけでした。どちらかというとブラウザ内部のレンダリングの仕組みそのものについて解説されていて、当時の自分にとっては非常に衝撃だったのを覚えています。 そこから Web パフォーマンスという分野に没頭していったわけですが、自分のアクティビティを漁ってみると Web パフォーマンスに関するアウトプットが思いの外ありました。https://1000ch.net/posts/2017/polymer-japan-meetup-1/Sun, 05 Nov 2017 00:00:00 +0000https://1000ch.net/posts/2017/polymer-japan-meetup-1/11月4日に開催された Polymer Japan Meetup #1 に出演しました。トップバッターだったので、発表までハラハラすることなく、イチ参加者として楽しめました。 Web Components Re-Introduction Polymer のイベントとはいえ前提技術として Web Components の話が必要ということで、Web Components の基礎部分について解説しました。HTML5 Conference 2017 で話した内容と被るところもありますが、全体感をまとめてお届けしました。 Polymer もとい Web Components の良さについては、このデモが一番わかりやすいです。 Web Componentsでできること。タグ一発でこんなノブやスライダーが表示できたりします。 #polymer_jphttps://t.co/9enKsWalkL pic.twitter.com/7TJDx7MBKg — Eiji Kitamura (@agektmr) November 4, 2017 WebAudio のコントロールのリッチな UI ですが、これが素晴らしいのは Web 標準技術で実現している点です。リッチな UI を提供するライブラリは数え切れないほどありますが、jQuery UI は jQuery など、大半は他のライブラリに依存してたり、独自の作法があります。Web Components であればサードパーティライブラリに依存すること無く、HTML という Web の基礎となる技術を通して拡張し、再配布できます。 ユースケースは Web アプリケーション全般にあると思いますが、いわゆる主に関わるアプリケーション部分だけでなく、サードパーティウィジェット（Twitter、Facebook、Google など）や UI フレームワーク（Bootstrap、Primer など）にも有用な技術でしょう。 セッションとかハンズオンとか懇親会とか どのコンテンツも面白くて、特にハンズオンはよくできていました。が、内容が現時点で安定版である Polymer v2 ベースだったので、Polymer v3 のロードマップにはない Bower や HTML Imports を扱わざるを得ない感じは、どの事前のセッションでも Bower や HTML Imports は今後非推奨と伝えていただけに、なんとも歯がゆかったです（いや、どうしようもないんだけど）。https://1000ch.net/posts/2017/a11y-links/Tue, 03 Oct 2017 00:00:00 +0000https://1000ch.net/posts/2017/a11y-links/毎回検索している気がするので、自分用のメモ。 macOSのアプリ + Sketchのプラグイン Contrast: コントラストをチェックする macOS のアプリ stark-contrast/stark-sketch-plugin: 文字と背景のコントラストをチェックしたりや色覚をシミュレートする Sketch のプラグイン getflourish/Sketch-Color-Contrast-Analyser: コントラストをチェックする Sketch プラグイン DevTools + Extension + ブックマークレット ChromeLens: Web ページで色覚をシミュレーションする Chrome の拡張機能 aXe: Web ページのアクセシビリティをチェックする Chrome の拡張機能（DevTools の Audit に取り込まれた） Accessibility Developer Tools: Web ページのアクセシビリティをチェックする Chrome の拡張機能（DevTools の Audit に取り込まれた） ChromeVox: Web ページの読み上げをする Chrome の拡張機能 tota11y: Web ページのアクセシビリティをチェックするブックマークレット Node.js + CLI dequelabs/axe-core: a11y チェックツールである aXe のコアエンジン dequelabs/axe-cli: 対象 URL のアクセシビリティをチェックできるコマンドラインツール addyosmani/a11y: 対象 URL のアクセシビリティをチェックできるコマンドラインツール ドキュメント + その他 OATMEAL: アクセシビリティのテスト手法についての本 A11Y Style Guide: アクセシブルなコンポーネントを作るためのドキュメント Accessible design patterns: 各種 UI コンポーネントのアクセシブルな実装パターン集 Inclusive Components: 各種 UI コンポーネントのアクセシブルな実装パターン集 Vox Product Accessibility Guidelines: 職域別のアクセシビリティチェックリスト enchroma: Web で試せる色覚テスト HTML5 Accessibility: ブラウザのアクセシビリティサポート状況 a11ycasts: Rob Dodson による各種 a11y の解説動画 Web Accessibility | Udacity: Udacity の a11y コースhttps://1000ch.net/posts/2017/akamai-edge-japan-2017/Mon, 25 Sep 2017 00:00:00 +0000https://1000ch.net/posts/2017/akamai-edge-japan-2017/少し先ですが、11月10日(金) に開催される Akamai Edge Japan 2017 のトークセッション「顧客のデジタルシフトに追いつけ！攻めのWebサイトへの次の一手」（PD-1、17:05-18:35）に出演します。ANAインターコンチネンタルホテル東京で開催され、既に申し込みは始まっているようです。 私が弊社でやっている Web プロダクトの品質向上、特に Web パフォーマンスへの取り組みについて、パフォーマンス指標の決め方、プロジェクトでの改善の進め方、取り組んできてどうだったか・これからどうか、みたいなことをお話します。たぶん。 ここ半期の取り組みについては、以前会社のブログに寄稿したWebパフォーマンスとプロダクトKPIの相関を可視化する話という記事をご覧ください。 どうぞ宜しくお願い致します。https://1000ch.net/posts/2017/lit-html/Wed, 13 Sep 2017 00:00:00 +0000https://1000ch.net/posts/2017/lit-html/PolymerLabs/lit-html という Polymer チームによる実験的プロジェクトがある。JavaScript のテンプレートリテラルを通して、<template> 要素を使いつつテンプレートの機能を実現するライブラリで、API ドキュメントを見たのでそのメモ。 Tagged template literals のおさらい ES2015 の Tagged template literals が前提になるので、機能を振り返っておく。 function tag(strings, ...values) { const str1 = strings[0]; const str2 = strings[1]; const val1 = values[0]; return str1 + val1 + str2; } const foo = '括弧内の文字列'; console.log(tag`「${foo}」`); Tagged template literals として使いたい関数を定義すると、関数の第一引数にはテンプレートリテラルで渡した文字列の配列が渡ってくる。第二引数以降は可変長で、テンプレートリテラル内で埋め込んだ変数が配列で渡され、それに分割された文字列が第一引数の配列になる。 html() と render() lit-html は大きく分けて html() と render() という2つのパートに分かれている。 html() は Tagged template literals として使う関数で、実行すると TemplateResult というオブジェクトを返す。 import { html } from '.https://1000ch.net/posts/2017/webcomponents-specs/Tue, 12 Sep 2017 00:00:00 +0000https://1000ch.net/posts/2017/webcomponents-specs/二週間後の素振り入ってます、連投ですが悪しからず。Web Components v0 から Web Components v1 へのアップデートに関しては、去年の DevFest Tokyo 2016 で発表した Web Components 2016 & Polymer v2 にまとめてあるが、それを改めて見直している。 HTML Templates HTML Templates は HTML ドキュメントに埋め込まれてもコピーして使うまで非活性であるような、本来的な雛形の機能を実現する <template> 要素の仕様である。 <script type="text/template">...</script> やら <div style="display: none">...</div> やらの、ハックを使わずに済む。 <template> <!-- 非活性なので bar.jpg へのリクエストが発生しない --> <div class="foo"> <img src="bar.jpg"> </div> </template> <script> const template = document.querySelector('template'); const clone = template.content.cloneNode(true); document.body.appendChild(clone); </script> Web Components に分類される他の仕様に比べて、与えられている役割が単純なので、仕様が大きく変更されることは想像しにくい。IE11 を除いてブラウザの対応状況は良い し、ポリフィルである webcomponents/template のファイルサイズも小さい。 ポリフィルでは、 HTMLTemplateElement が未定義の場合に <head> 要素に <style>template{display:none;}</style> を埋め込んで <template> 要素を非表示にする HTMLTemplateElement.https://1000ch.net/posts/2017/html5conference-2017/Sun, 10 Sep 2017 00:00:00 +0000https://1000ch.net/posts/2017/html5conference-2017/来たる 9/24(日) に開催される HTML5 Conference 2017 に、The State of Web Componentsというタイトルで出演します。既に満員の状況なので、恒例の是非ご応募くださいはないですが、もし興味がある方はセッションにお越し頂ければと思います。会場はおなじみの東京電機大学です。 さて、Web Components については去年の DevFest Tokyo 2016 というイベントでも Web Components 2016 & Polymer v2 というセッションで発表させていただきました。この時は Web Components v0 -> v1 のアップデートにフォーカスした内容だったので、時世に合わせてまとめなおしてみようと思います。どうぞ宜しくお願い致します。 ※無事終了しました #html5j #html5j_a セッション資料です、ご清聴ありがとうございました 🙏 / "The State of Web Components" https://t.co/1IpoQ6hT99 — 煎茶 🍵 (@1000ch) 2017年9月24日https://1000ch.net/posts/2017/wdpress-vol100/Thu, 24 Aug 2017 00:00:00 +0000https://1000ch.net/posts/2017/wdpress-vol100/WEB+DB PRESS の Vol.100 というメモリアル号の 「あのときの自分へ ── もし、過去に戻ってアドバイスできるなら」 というエッセイ企画に 「Web 技術の変化に適応し続けるには」 というタイトルで寄稿しました。この業界に飛び込んではや五年が経ちますが、Web の変遷を振り返って思うところを書き綴っています。 表紙に名前を載せていただいていますが、並びが非常にアレで恐縮しています。どうぞお手柔らかにお願い致します。 100号記念エッセイは「あのときの自分へ」で、深津 貴之さん（@fladdict）、泉水 翔吾さん（@1000ch）、佐藤 太一さん、artonさん、松田 明さん（@a_matsuda）執筆です。#wdpress — WEB+DB PRESS編集部 (@wdpress) 2017年8月24日https://1000ch.net/posts/2017/openfresh-super-image/Fri, 11 Aug 2017 00:00:00 +0000https://1000ch.net/posts/2017/openfresh-super-image/React を使った Web プロダクト開発では、遅延ロードやアクセシビリティといった画像として基本的な機能を備えつつ、ステートレスな <Image> コンポーネントを実装することがしばしある。 FRESH! の Web 開発チームでは以前Intersection Observerを使った要素の出現を検出するReactコンポーネントを公開したが、今度は画像を扱う汎用 React コンポーネントを公開した。今日はその紹介と、それらを組み合わせた <Image> コンポーネントの実装をしてみる。 こちらも FRESH! 以外でも使えたら便利だなと思った次第で、機能の切り出しは作業は富澤さん @tommy-san がやってくれた 🙏 SuperImage 仮で付けていた SuperImage がそのまま名前に採用されてしまった。openfresh/super-image にて公開されている。 このコンポーネントの機能はシンプルに絞ってある。 object-fit を使ったレイアウトが可能で、非対応ブラウザでも background-size でフォールバックする alt 属性が未指定の場合に、空文字を付与する。object-fit がフォールバックされ <img> で描画されない場合は aria-label を使う 素で使うには少し面倒な <picture> 要素や srcset 属性を使ったレスポンシブな画像の表示なども、このコンポーネントでうまくラップできると良さそう。 ViewportObserverとの連携 ViewportObserver と組み合わせれば、画像表示に関して用意しておきたい機能はおおよそカバーできるはず。 次のコードは、スクロール同期で画像をロードしつつ、フォールバック付きで object-fit でレイアウトできる <Image> コンポーネントのサンプルである。 import * as React from 'react'; import * as PropTypes from 'prop-types'; import * as SuperImage from 'super-image'; import * as ViewportObserver from 'viewport-observer'; const DUMMY_IMAGE = 'data:image/gif;base64,R0lGODlhAQABAIAAAP//////zCH5BAEHAAAALAAAAAABAAEAAAICRAEAOw=='; const ROOT_MARGIN = '200px 0'; export default class Image extends React.https://1000ch.net/posts/2017/web-performance-product-kpi/Thu, 10 Aug 2017 00:00:00 +0000https://1000ch.net/posts/2017/web-performance-product-kpi/CyberAgent Developers Blog に、ここ最近の Web パフォーマンスへの取り組みについて寄稿しました。Web パフォーマンスとプロダクト KPI の相関を可視化して、事業目標化する話です。 最近の活動です📊 / "WebパフォーマンスとプロダクトKPIの相関を可視化する話" https://t.co/FUff3DaL2R — 煎茶 🍵 (@1000ch) 2017年8月10日https://1000ch.net/posts/2017/zeit-hazel-now/Sat, 05 Aug 2017 00:00:00 +0000https://1000ch.net/posts/2017/zeit-hazel-now/Trello のデスクトップアプリ 1000ch/whale や esa.io のデスクトップアプリ 1000ch/quail は Electron 製だが、この macOS バージョンに、重い腰を上げて自動アップデート機能を実装した。 Electronの自動アップデート機能 Electron には autoUpdater という自動アップデートを提供するクラスが備わっている。これは Squirrel/Squirrel.Mac というフレームワークの機能で、Electron 側についてはそれをラップした autoUpdater を通して簡単に実装できる。 const { autoUpdater } = require('electron'); autoUpdater.on('checking-for-update', () => console.log('アップデートの有無をチェック中')); autoUpdater.on('update-available', () => console.log('アップデートを利用可能')); autoUpdater.on('update-not-available', () => console.log('アップデートを利用不可能')); autoUpdater.on('update-downloaded', () => console.log('アップデートをダウンロード済')); autoUpdater.setFeedURL('...'); autoUpdater.checkForUpdates(); autoUpdater.checkForUpdates() を使うと autoUpdater.setFeedURL() で設定したサーバーにアップデートの有無を問い合わせて、アップデートがあるとダウンロードを行いつつ、各種イベントを発火する。ダウンロードしたアップデートは autoUpdater.quitAndInstall() を実行すれば再起動してアップデートが適用される他、次回起動時に自動で適用される。whale と quail の場合は後者を選んだが、UI 上で再起動を促したい場合は前者を使うことになる。 autoUpdater(Squirrel.Mac)のサーバー側の実装 Electron 側の実装は簡単だが、サーバーは仕様も実装もなかなか面倒臭い。サーバー側の仕様は Squirrel.Mac#Server Support にあり、autoUpdater.setFeedURL() に指定した URL へのリクエストで規定通りのレスポンスが返ると初めて自動アップデートが機能する。 この仕様通りのサーバー実装は、オープンソースに既にいくつもある。 nuts: A smart release server for your applications, using GitHub as a backend.https://1000ch.net/posts/2017/sublime-theme-switcher/Tue, 18 Jul 2017 00:00:00 +0000https://1000ch.net/posts/2017/sublime-theme-switcher/Sublime Text のテーマやカラースキーマの変更は、メニューの Preferences から Theme ないし Color Scheme を辿るか、⌘ + , で開く JSON の設定ファイルを編集するか、のいずれかである。そう思っていた時期が私にもありました…。 コマンドパレットから切り替え出来るプラグインを発見した テーマを探しに dreikanter/sublime-bookmarks を眺めていると、 Sublime Theme Switcher というプラグインを見つけた。 メニューから辿るのも設定ファイルをいじるのもかなり煩わしいが、これを使うと ⌘ + Shift + P で開くコマンドパレットのメニューに Select Theme と Select Color Theme が追加される。これでコマンドパレット上からテーマとカラースキーマそれぞれを切り替え出来るようになる。 インストール ⌘ + Shift + P でコマンドパレットを開く Package Control: Install Package を選択する Themes Menu Switcher で検索し、インストールする パッケージ名がリポジトリ名と異なることに注意。https://1000ch.net/posts/2017/throttle-decorator/Sat, 15 Jul 2017 00:00:00 +0000https://1000ch.net/posts/2017/throttle-decorator/掲題の通り、throttle してくれる 1000ch/throttle-decorator というモジュールを作った。ES Decorator については全力で ES Decorator使ってみたが参考になると思う。標準化されるか問題は一旦さておいて。 インストールと使い方 npm でインストールする。 $ npm install --save-dev throttle-decorator 旧来 throttle() するときは宣言してあるイベントハンドラに throttle() を挟んで新たな名前付き関数を宣言していたと思う。React のコンポーネントの例だと次のようになる。 import throttle from 'lodash.throttle'; class Foo extends React.Component { constructor() { this.onChange = throttle(this.onChange, 100); } onChange() { console.log('changeイベントを間引きたい'); } render() { return <input onChange={this.onChange} />; } } そこで throttle-decorator を使うと、次のように書ける。 import throttle from 'throttle-decorator'; class Foo extends React.Component { @throttle(100) onChange() { console.log('changeイベントを間引きたい'); } render() { return <input onChange={this.https://1000ch.net/posts/2017/yamaki/Fri, 14 Jul 2017 00:00:00 +0000https://1000ch.net/posts/2017/yamaki/去年もお世話になった山喜旅館に、今年もお世話になることになった。今回は読書のお時間ですというプロジェクトの技術サポートをしている立場で同行してきた。プロジェクトと私については横断組織の力を借りてプロダクトをより良くするには？電子書籍サービス「読書のお時間です」パフォーマンス改善の進め方 | CyberAgent Developers Blogに詳しく書かれている。 「読書のお時間です」は Web を主戦場としており、その品質は事業指標に直結してくる。また、リリースから約4年が経過し、様々な負債を抱えている状態でいち早い返済が必要な状況だった。そこで、私が少し前のアーキテクチャ刷新から技術レビュアとして関わる延長で、更なる改善を見据えてコミットしていくことになった。 今回の開発合宿はその一環だった。…と言っても、写真が主な遠征ログ。 伊東オレンジビーチ 旅館に到着してから昼食の時間まで少し時間があったので、すぐ近くの海岸まで歩いた。水際でバチャバチャしたわけでもないが、戦士達はつかの間の休息を楽しんだのであった。 山喜旅館 前回通り、古き良き旅館という感じだった。開発に使った場所が前回と異なり、2階の会議室のような場所だった。前回は地下だったせいか(?)旅館の Wi-Fi が弱くて苦しんだ記憶があるが、反省を活かしてポケット Wi-Fi を持参したのと、2階だったことも手伝ってか、比較的良好な電波状況で開発できた。https://1000ch.net/posts/2017/omron-weight-scale/Mon, 10 Jul 2017 00:00:00 +0000https://1000ch.net/posts/2017/omron-weight-scale/前回の健康診断から 4kg 増えている（58kg -> 62kg）とのことで、計測員のお姉さんに心配されて以来体重を気にしている。年齢的にも本格的に運動で絞っていかないとマズイと危機感を感じたので、ゴールデンウィークあたりから継続的に週一程度でランニングをしている。実際に体重がどうなっているのかを知りたい時に、ふと体重計がないことに気づき、買ってみた。 サイズ:約幅285×高さ28×奥行280mm。本体重量:約1.6kg(電池含む)。素材・材質:ABSガラス、ABS樹脂。体重:0～100kgまで/100g単位、100～135kgまで/200g単位 どうせなら Wi-Fi で接続して、計測したら自動で集計して…みたいな機能付きのものを探して買っても良かったのだが、安くて安心のオムロンに着地した。自分の基礎データ（年齢と身長と性別）を登録して測ると、体組成データも出力できるっぽい。 自分の健康管理は iOS 純正のヘルスケアアプリを使っているので、計測結果をアナログ入力している。睡眠状況等も自動で計測されている他、ランニングの結果も Apple Watch を通してログが取れているので、自動で同期されている。 ランニングを始めて2ヶ月程度だが、買った直後の体重は 59.9kg だった。その後は 60kg 前後をウロウロしているので、もう 2kg~3kg は絞りたい。https://1000ch.net/posts/2017/visualize-audio-input/Mon, 19 Jun 2017 00:00:00 +0000https://1000ch.net/posts/2017/visualize-audio-input/とある技術相談が舞い込んできて、その時の返答を念のため後で技術検証した話。やりたいことは大まかに「ブラウザで音声入力をリアルタイムに可視化する」「ブラウザで音声入力を記録する」の2点で、音声入力は getUserMedia() で取得できて、可視化はそのデータを Canvas or WebGL でいじり、録音は MediaRecorder でやるのだろうと思いつつ、組み合わせて一応動く状態まで組んだ。 navigator.mediaDevices.getUserMedia() ユーザーのカメラやマイクの入力は getUserMedia() で取得できるが、一昔前までは navigator から生えていて、これが MediaDevices というメディア接続をまとめたオブジェクトへ移動したとともに、API も Promise インターフェースになっている。 navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(stream => { console.log(stream); }).catch(error => { console.log(error); }); 音声入力ストリームを解析し波形表示 次に AudioContext を利用して音声入力を解析し、Canvas に描画していく。AudioContext から音声入力のノードと解析ノードを生やしてそれぞれ接続する。AutioContext の destination へ接続すればブラウザから音声として出力されるが、ハウリングするので避けている。 解析ノードを参照して描画しているのが draw() で、これを requestAnimationFrame() 経由でドローコールしている。 const canvas = document.querySelector('#canvas'); const drawContext = canvas.getContext('2d'); navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(stream => { const audioContext = new AudioContext(); const sourceNode = audioContext.https://1000ch.net/posts/2017/react-router-hashlink/Sun, 11 Jun 2017 00:00:00 +0000https://1000ch.net/posts/2017/react-router-hashlink/React Router を使っているプロジェクトで、できれば「ハッシュリンクを踏んだ時に、対象位置までスクロールしたい」というのがあり、少し調べていた。そもそも React Router はハッシュリンクが正しく機能しないという不具合があったり、既に公開されているライブラリでは機能を満たせない、メンテナンスが不安、コードがアレ…等等、スクラッチで書くところから始まった。 react-router-hashlink React Router の <Link> コンポーネント をラップして、ハッシュリンクに対応したのが 1000ch/react-router-hashlink である。 import { HashLink } from 'react-router-hashlink'; function render() { return ( <ul> <li><HashLink to="/foo#bar">/foo#bar</HashLink></li> <li><HashLink to="/foo#bar" behavior="smooth">/foo#bar</HashLink></li> <li><HashLink to="/foo#bar" delay={500}>/foo#bar</HashLink></li> </ul> ); } な感じで使う。behavior と delay を除き、React Router の <Link> コンポーネントを指定できると思ってもらえば良い。 Element.prototype.scrollIntoView() と ScrollBehavior 内部的に #bar へは document.getElementById('bar').scrollIntoView() で移動しているが、この Element.prototype.scrollIntoView() 実行時などのスクロールの挙動を制御する仕様、 ScrollBehavior が新たに策定されつつある。ScrollBehavior の適用先としては MDN の Element.prototype.scrollIntoView() にはあるが、CSSOM View Module の 6. Extensions to the Element Interface にはないようで、最終的にどうなるかは不明。全て CSS の scroll-behavior に吸収される可能性も大いにある（この辺りの動向を突き止められていないので誰か知っていたら教えてください）。https://1000ch.net/posts/2017/markdown-headings/Mon, 05 Jun 2017 00:00:00 +0000https://1000ch.net/posts/2017/markdown-headings/Markdown の見出しだけを抽出したい欲求が高まり 1000ch/markdown-headings というツールを作った。単純な文法なので正規表現だけでも充分抜いてこれるが、今回は markdown-it/markdown-it の AST を使うことにした。 コマンドラインで使う 自分が欲しかったのはコマンドラインのインターフェース。 $ npm install --global markdown-headings 引数にファイルパスか glob を指定すると、対象の Markdown の見出しをまとめて出力する。 $ markdown-headings ./**/*.md > outlines.txt 標準入力も --stdin オプションで受け付けている。 $ cat readme.md | markdown-headings --stdin > outlines.txt require()して使う プロジェクトローカルにインストールして require('markdown-headings') しても使える。 const assert = require('assert'); const markdownHeadings = require('markdown-headings'); const markdown = ` # h1 あいうえお ## h2 かきくけこ`; assert.deepEqual(markdownHeadings(markdown), [ '# h1', '## h2' ]);https://1000ch.net/posts/2017/cheero-clip-light/Sun, 04 Jun 2017 00:00:00 +0000https://1000ch.net/posts/2017/cheero-clip-light/デスクが何かとケーブルで散乱しがちなので、まとめるべく試しに買ってみたら思いの外便利だった。 【マグネットなので利便性◎】 ケーブルだけでなく、お札を挟んでマネークリップとして使ったり、メモをとめておくマグネットとしても利用できます。まさに使用方法は無限大！ぜひ皆様オリジナルの使い方を探してみてください。 【お値打ち価格】 なんと発売当初より大人気の「cheero CLIP」5色セット分の価格よりお値打ちです！見た目も、お値段もさらに可愛くなってお買い得に◎見ていて明るい気持ちにさせてくれるポップな色合いは、プチギフトにピッタリ！友人や恋人、家族へのちょっとした贈り物としていかがでしょうか。 【絡みやすいケーブルまとめに】 モバイルガジェット携行の悩み、ケーブルの煩わしさを解消。 「cheero CLIP Light」は、cheero のバッテリーシリーズ付属のケーブルをはじめ、お手持ちのイヤホンケーブル等をすっきりとまとめることができる万能クリップです。 ケーブル類を束ねるためのゴムバンド。両端にマグネットがついていて、それらがくっつく仕組み。このマグネットにある程度重さがあるので、束ねたケーブルがその場所で留まってくれる。もちろん冷蔵庫やら扉にもくっつくし、ケーブルを束ねるだけじゃなく汎用性が高い。https://1000ch.net/posts/2017/speedindex-for-web-performance/Mon, 29 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/speedindex-for-web-performance/Web パフォーマンスの文脈で語られてきた DOMContentLoaded や load といった、いわゆるロード速度として括られてきた指標は、ユーザー体験とパフォーマンスの相関を俯瞰する上でいまや適切ではない。 DOMContentLoaded は DOM ツリーと CSSOM ツリーを組み合わせたレンダーツリーの準備完了を指し、ひとつの Web クライアントサイドでできる最適化の指標だが、それでも描画状態はレンダーツリーの複雑さやスクリプト処理との兼ね合いに依存してくるので、如何に素早くページが表示されているか ということを正確に表現できない。 load は HTML ドキュメントから参照する画像などのサブリソースのロードが全て完了した状態で、この頃にはページ全体が表示完了している状態に近い。しかし長大なコンテンツでは、ユーザーがページの最下部まで見る保証はなく（むしろ見ないのが大半）、より重要であろうファーストビューの表示が早かったか はわからない。 Speed Index は Google が提唱する、ロード開始からファーストビューが如何に早く表示されるかを表すスコア である。 Speed Indexの考え方 同じコンテンツのページ A とページ B があったとして、どちらもロード開始から 11 秒時点でファーストビューの表示が 100% 完了するものとする。しかしページ A とページ B では経過時間に対するファーストビューの表示状況が異なり、ページ A はロード開始から 1 秒時点で 80% 表示されていて、かたやページ B はロード開始から 1 秒時点で 20% しか表示されていない。この時、ページ A の方がユーザー体験が良いのは明らかである。 この時ページ A とページ B の差は、 ロード開始からの経過時間に対する描画進捗 である。両ページの描画進捗を、X 軸に経過時間、Y 軸に描画進捗にとるグラフにすると次のようになる。 このグラフによって、ファーストビューがロード開始から如何に早く多く描画されているかを表現できている。この色付き部分を比較しても良いが、仮に描画が 99% でずっと止まるようなケースでは色付き部分の面積が大きくなり続けてしまう。なので、経過時間に対して描画されていない量（面積）を計算することで、スコアを有限にできる。これが Speed Index である。https://1000ch.net/posts/2017/dotfiles/Tue, 23 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/dotfiles/ghqとpecoを使ったプロジェクト管理が便利なのは真新しくないが、コマンドラインを見られて質問されたこともあり、自分の運用方法などを記しておく。 ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば peco、ghq、gh-openの組み合わせが捗る - Webtech Walker ghqを使ってgitプロジェクトを管理する motemen/ghq はクローンした git リポジトリを管理する Go 製のコマンドラインツール。 # Homebrewでghqをインストールする $ brew install ghq # リポジトリをクローン $ ghq get git@github.com:1000ch/grd.git $ ghq get 1000ch/grd # ghqでクローンしたリポジトリのリスト表示 $ ghq list -p 他にも機能はあるが、リポジトリのクローンやリスト表示を、カレントディレクトリを選ばずに実行できるだけでもありがたいツール。 クローン先はデフォルトで ~/.ghq だが、 .gitconfig の [ghq] で指定できる。なので、 ~/dev にリポジトリをクローンしているのであれば git config --global ghq.root ~/dev を実行すればそのまま移行できるし、今の Go 環境をシームレスに使いたければ $GOPATH/src でも良さそう。 [ghq] root = ~/dev ghqをpecoと連携する peco/peco は入力をインタラクティブにフィルタリングするツール。同種のツールで Python 製の mooz/percol があるが、peco は Go 製なので単一バイナリで動いてくれるのがありがたい。https://1000ch.net/posts/2017/openfresh-viewport-observer/Wed, 17 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/openfresh-viewport-observer/Intersection Observer を使った要素の検出については、過去に記事にしていたり、Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.ioなどでより具体的に触れられている。また最近関わっている FRESH! でも導入した経緯があるが、今回はその React 実装部分を切り出し、オープンソースとして公開した話。 ViewportObserver 元々付けていたものや目ぼしい名前空間は軒並み取られていて、結局 ViewportObserver というコンポーネント名に着地した。openfresh/viewport-observer にて公開されている。 $ npm install --save viewport-observer でインストールして、 import { Component } from 'react'; import ViewportObserver from 'viewport-observer'; export default class Foo extends Component { render() { return ( <ViewportObserver onChange={() => console.log('onChange')} onEnter={() => console.log('onEnter')} onLeave={() => console.log('onLeave')} /> ); } } な感じで使う。詳しくは README を参照のこと。 内部実装は IntersectionObserver に依存しているが、このパッケージにはポリフィルを含んでいないので、別途 WICG/IntersectionObserver あたりでポリフィルしておく必要アリ。 openfreshでのソフトウェアの公開 FRESH! の開発で生まれた副産物は github.com/openfresh での公開を徐々に進めていて、Web クライアントサイドだと ESLint の設定や stylelint の設定なども公開されている。これだけでも、マイクロサービス化されている FRESH!https://1000ch.net/posts/2017/a11y-interview/Sat, 13 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/a11y-interview/インタビュー記事が公開された。 「アメブロ」や映像配信プラットフォーム「FRESH!」でアクセシビリティに取り組む技術者たちに話を聞きました。 『「アクセシビリティに取り組むことが価値あるサービスづくりにつながる」サイバーエージェント技術者たちの取り組み』https://t.co/gZC4IqQSs0 — サイバーエージェント　広報＆IR担当 (@CyberAgent_PR) 2017年5月12日 （インタビュー中、インタビュアによるリアルタイムに書き起こし（音声録音ナシ）という離れ業が、記事公開の裏にあったことをここに報告したい…。） 動画サービスにおけるアクセシビリティ 今は FRESH! でのアクセシビリティへ取り組みをガイドラインという形で公開を目指している。これは主に WCAG 2.0 に沿ったドキュメントになるはずだが、デザインや HTML 実装では超えられない動画という壁も感じつつある。 FRESH! や AbemaTV のような動画サービスが配信するのは映像と音声の動画コンテンツだが、音声をオフにして視聴したい人や聴覚障碍を持つ人には映像だけでコンテンツを 100% 楽しむことが今のところ難しい（アクセシブルではない）。 こうしたときにアクセシビリティとしては字幕や手話通訳を用意したいという話になるが、ここで技術やコストが立ちはだかる。YouTube には自動字幕起こし機能があり、アップロードされた動画内の音声を自動で解析し、文字に起こしてくれる（あとで手直しもできる）。音声認識のような技術は一朝一夕で手に入るものではないが、動画プラットフォーム事業者としては言うまでもなく価値がある。https://1000ch.net/posts/2017/update-pinfeed/Fri, 05 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/update-pinfeed/PinFeed は趣味で作っている Pinboard の iOS クライアントで、自分がフォローしているユーザーのブックマークにフォーカスしているのが特徴（HBFav に強くインスパイアされている、というかそのまま）。リリース自体はかれこれ1年以上前だが、こつこつメンテナンスを続けていて、Swift のメジャーアップデートなどにも追従している。 新しいアイコンとデザイン調整 アイコンを新調した。Sketch の使い方を勉強する良い機会なので、今まで使っていた Public Domain のアイコンを参考に、ゼロから描いた。 アイコン以外にも、UI 周りのカラーコントラストなどを細かく調整している。 内部処理のアレコレ リリース当初は保持しているトークンを使って、毎度 API へリクエストしたデータを表示していた。が、ロードが重い上にサーバーにもクライアントにも優しくないのはわかっていたので、途中から Realm を使ってデータをキャッシュし始めた。新しいデータを毎回取得したい気もするが、ひとまずキャッシュデータを優先的に表示させることで、一応の改善を果たした。 Swift のメジャーアップデート対応はそれなりに辛くて、毎度骨が折れる。というのは、これに手を付けるときは毎回のように Xcode のアップデートやら iCloud の認証やらが入るからだ。コードベースがそこまで大きくないこともあり、Swift のマイグレーション自体はそこまで辛くない。Web クライアントサイドのプロジェクトを開始するときの環境整備も一仕事だが、本作業に入る前の避けようがないタスクとして近い感覚を覚える。https://1000ch.net/posts/2017/typescript-without-babel/Mon, 01 May 2017 00:00:00 +0000https://1000ch.net/posts/2017/typescript-without-babel/最近は社内で Web おじさん業をやる傍ら、プロジェクトコードなども少し触っている。最近では FRESH! でアレコレしていて、クライアントサイドとサーバーサイドの改善もやったり。 FRESH! Web パフォーマンス改善 〜クライアントサイド編〜 | CyberAgent Developers Blog FRESH! Web パフォーマンス改善 〜サーバサイド編〜 | CyberAgent Developers Blog ふたつ👆ともよくまとまっているので、未読の人は是非読んでください。 あとは開発環境周りもコツコツ直していたりする。Web クライアントの構成要素 - Client Side of █████fresh.tv で触れられている通り、TypeScript と Babel の多段ビルドで運用していた。型を使いたいモチベーションと JSX をコンパイルする事情が合わさってのことだが、最近では TypeScript が JSX に対応しているので、TypeScript ビルドへの統一に踏み切った。 JavaScriptをTypeScriptでビルドする TypeScript と JSX それぞれの JavaScript へのコンパイルに分かれていて、設定が2箇所に分かれている気持ち悪さと、ビルド結果を Browserify でバンドルする都合で双方の待ち合わせがあったりなどの、ビルド処理の複雑化を招いていた。TypeScript ビルドへ統一することでそれらが一気に解消された上に、ビルド時間への短縮にも繋がった。 ひとまず allowJs を駆使しながら TypeScript への一本化を果たして、ビルド時間が 90s から 70s 程になった。exports.__esModule = true; の優しさ。https://t.co/1nBGdZNcJ0 — 煎茶 🍵 (@1000ch) 2017年4月28日 対応内容としては単純で、babel でビルドしていた .js ファイルを代わりに tsc でビルドするだけ。ここで JavaScript ファイルのコンパイルを有効にするため tsconfig.https://1000ch.net/posts/2017/frontrend-vol9/Sun, 30 Apr 2017 00:00:00 +0000https://1000ch.net/posts/2017/frontrend-vol9/2017/04/28にFrontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホンを開催しました。登壇資料やブログ枠などは既にイベント資料一覧にまとまっています。 当日の様子は FRESH! で生配信され、アーカイブも残っているので見逃した方は是非どうぞ。https://1000ch.net/posts/2017/node-guetzli/Fri, 21 Apr 2017 00:00:00 +0000https://1000ch.net/posts/2017/node-guetzli/imagemin/guetzli-bin という、Node.js のモジュールを作った。imagemin のプラグインもあるし、gulp-image や grunt-image もサポートしている。 Guetzliとは Guetzli は Google が開発している JPEG エンコーダで、従来よりも少ない劣化で圧縮できる。劣化しているかどうかは butteraugli という品質評価アルゴリズムを用いてチェックしている。 Guetzli／Butteraugliに関するあれこれ google/guetzli: Perceptual JPEG encoder google/butteraugli: butteraugli estimates the psychovisual difference between two images パラメータを変えて圧縮を繰り返し、最も劣化が少ない試行を選ぶという処理なので、処理速度は遅い。というより、圧縮スピードに主眼は置いていない。同じファイルサイズであれば Guetzli の方が良い結果が得られるのなら、多少遅くとも Guetzli で圧縮したほうが良い気はする。しかし手元で色々試していても遅いなぁと感じる遅さなので、導入するときは開発フローのどこで行うかは考える必要がある。https://1000ch.net/posts/2017/compare-compression/Tue, 11 Apr 2017 00:00:00 +0000https://1000ch.net/posts/2017/compare-compression/圧縮アルゴリズムは gzip・zopfli・brotli と色々あるが、それらによる圧縮効果を簡易的に試したいときがしばしばあったので、関数にしてみた。 function compare() { echo "original size (bytes): $(cat "$1" | wc -c)" echo " gzip size (bytes): $(gzip -c "$1" | wc -c)" echo " zopfli size (bytes): $(zopfli -c "$1" | wc -c)" echo " brotli size (bytes): $(bro --input "$1" | wc -c)" } 関数名は適当に調整してもらうとして、これを .bashrc とか .zshrc あたりに書いておくと、compare filename で圧縮によってどの程度小さくなるかをコマンドライン上で試せる。 gzip は大抵の環境にインストールされている気はするが、zopfli や brotli はインストールしておく必要がある。Homebrew なら次のコマンドで簡単にインストールできる。 $ brew install zopfli $ brew install brotlihttps://1000ch.net/posts/2017/automagic-ep188/Tue, 28 Mar 2017 00:00:00 +0000https://1000ch.net/posts/2017/automagic-ep188/ヤスヒサさんの Automagic Podcast にお呼ばれして、クライアントサイドのデザイナーとエンジニアの間にある様々な課題について話しました。Webフロントエンドにおけるコンポーネント化のアプローチ の延長戦のような感じ。収録後のほうが調子が出てた感があり若干悔やまれますが、どうぞ宜しくお願い致します。 #automagic に出演しました / "Automagic Podcast — 株式会社サイバーエージェントのフロントエンドエンジニア..." https://t.co/OqWsIoz31W — 煎茶 🍵 (@1000ch) 2017年3月28日https://1000ch.net/posts/2017/component-of-web-frontend/Sun, 26 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/component-of-web-frontend/株式会社サイバーエージェント、日本経済新聞社、ヤフー株式会社の三社共催の Web フロントエンドの技術カンファレンス Inside Frontend が 2017/2/25 に開催され、スピーカー兼スタッフで参加してきた。 発表資料と雑感 技術寄りな話をすることが多いけど、今回は Web クライアントサイドのエンジニアとデザイナーの協業について話した。 コンポーネント化は、開発や運用のコストを小さくしたり、アプリケーションの品質を高める上で欠かせない。成果物を整理・抽象化したいのはデザイナー・エンジニアを問わず開発者皆が思うところ。でも今までの Web フロントエンドにおけるコンポーネント化したい欲求は、エンジニアの心の中にしかなくて、うまくいってなかった。開発プロセスにおいて、全体像を求められるデザイナーとモジュラーにプログラムを構築していく職能間の意識の齟齬や、Web フロントエンド固有の技術課題である CSS もある。そういった背景がある中で、コンポーネント化を進めるには何に取り組めばいいか、という話をした。 コンポーネント化の話は、やはりデザイナーにもその概念を理解してもらうのが肝なんだな、と。再利用性、保守性、開発コストなど、エンジニアが楽したいからじゃなくメリットがあるんだよという説得材料を示すのが大事、とのこと。#insideFE — miyuki (@wtnb) 2017年2月25日 デザイナーにもコンポーネントベースで作ってもらう取り組み。 フロントは分割統治が染み付いているからコンポーネント化は自然に考えることができるがデザイナーはページ全体から考えるゆえに溝が深い。 納得できるが故、辛い現実。 組織の力に頼ることが現実解か。。#insideFE https://t.co/mopzx5DhRd — dayoshix (@dayoshix) 2017年2月25日 AMA (Ask Me Anything) 今回は技術カンファレンスでは初の取り組み AMA (Ask Me Anything) もあったが、これがとても好評で、Twitterでもアンケートでも非常に良かったとの意見が多かった。 私自身も各ブースを回ったが、事前公募した質問に加えて会場でも絶えず質問が出ており、とても活発に議論が行われていた。特にヤスヒサさんの「フロントエンドの課題を啓蒙する方法」は圧巻のプレゼンテーションから始まり、私の発表内容でもあったデザイナーとエンジニアの協業に関する話もあり、大変勉強になった。 セッションの方は Seminar A と Seminar B ともに FRESH! で生配信・アーカイブされているので、当日会場に来れなかった人も楽しめるが、残念ながら AMA の方は映像として記録されていない。参加した人だけのお楽しみと言いたいところだが、公開されないのは勿体無い内容ばかりだった。AMA についても、映像としては残っておらずとも何らかの形でアーカイブしたいとは考えているので、少々お待ち頂ければ。折角 GitHub の issue に質問がリスト化されているので、各位のレスを残せば簡易だが議事録になる（それが最適なアーカイブの形かどうかはさておき）。 #insideFE で良かったのは、セッションの間に30分のAMAを挟んでた所。スピーカーとのコミュニケーションはもちろん、息抜きやネットワーキングの時間に活用できて、下手にセッション詰め込むよりも個人的には実りが多かった。今後の参考にさせて頂きます。 — Eiji Kitamura (@agektmr) 2017年2月25日 AMAよかった。懇親会でありきたりにピザとビール並べるより有意義だったと思う。 #insideFE — okunokentaro (@armorik83) 2017年2月25日 感想 会場は Yahoo!https://1000ch.net/posts/2017/transition-of-web-frontend/Tue, 21 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/transition-of-web-frontend/Developer Summit 2017 にて Web フロントエンドの変遷とこれから というタイトルで講演した。 前後半のスライド インターネット黎明期から昨今にかけて Web がどのように変遷してきたかを振り返りつつ、この進化の早い Web の世界で私達開発者はどのように向き合っていけばよいのかという内容でした。 私が Web 業界に飛び込んだのがサイバーエージェントに転職した 2012 年で、「Web フロントエンドは技術の流行り廃りが早い」と言われ始めたのもこの頃からだろうか。これ以前の Web 業界の動向は知る良しもなかったけど、個人的には移り変わりの早さを相対的に感じることはなくて、それが当たり前だったというかなんというか。 分析するには幾つかポイントがあって、まずひとつクライアントサイドのアーキテクチャとか開発環境だとか、そもそも関心が向いてなかったところに急速発展したのが技術者にとってギャップだったせいでこういう声が出てきたのではと思っている。あとは、Web がプラットフォームとしてまだ成熟しておらず、実装にバグが多かったりブラウザ間の互換性が低かった。今でこそ溝は埋まりつつあるけど、特に当時はモバイルデバイスの普及真っ盛りで Android と iOS の動作の違い（いわばバグ対応）をクライアントサイドで期待通りに動作するように作る苦労もあった。 とは言え、 技術の成熟と標準化の浸透を待たざるを得ない Web のプラットフォームとしての特性 を踏まえれば、これからも少なからずデバイス（OS）間のギャップはあるわけで、Web に関わる開発者として泣き言は言ってられないわけで。動向の変化に対応する地力を身に付けるのはもちろんのこと、Web がこれから更により良くなるために自分ができることも模索していかなければと、改めて考えるきっかけになった。 デブサミと目黒雅叙園 会社の会議等でも何度か足を運んだ記憶がある目黒雅叙園だが、デブサミにスピーカーとして招かれるのは初めてで、案内された控え室が大奥（個人のイメージ）のようなやたら格式高いスペースだった。 デブサミのスピーカー控え室凄い👀 pic.twitter.com/K7Ho5krjq5 — 煎茶 🍵 (@1000ch) 2017年2月16日 会場の大きさ、スタッフの多さ、綿密なメール連絡・前日リハーサル・フォローアップ等等、大きいイベントは違うなと思った（小並）。スピーカー控室から講演会場へ向かう道も、専用の裏ルートから通されて、なかなか貴重な体験だった。 冷し味噌卵麺で〆 Shogo Sensuiさん(@1000ch)がシェアした投稿 - 2017 2月 15 9:28午後 PST 目黒駅に程近い中本で〆のラーメンを食べた。いつもの渋谷店にはない、冷やし味噌卵麺を注文してみた。 観測したブログ記事など Developers Summit 2017 - wolfmasa’s blog #devsumi 2017参加レポ (Developers Summit 2017) 初日 (2/16) デブサミ2017に行ってきた（１日目） Developers Summit 2017 1日目 #devsumi 【デブサミ2017】1日目E会場 #devsumiEhttps://1000ch.net/posts/2017/cote-et-ciel-isar-rucksack/Sun, 19 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/cote-et-ciel-isar-rucksack/結局 M サイズを買った。Black 、Black Melange 、Gray Melange の三色があるが、Black Melange を選択。使っている人もチラホラ見かけるけど、まぁいいかという想い。 Apple で買った Incase のバックパックが壊れて以来、headporter の 3way を使ってきたけど、急に cote&ciel のバックパックが欲しくなってきた… M と L でサイズどのくらい違うんだろう… https://t.co/3eDayZO2DB — 煎茶 🍵 (@1000ch) 2017年2月13日 これまで使っていた HEADPORTER の TANKER の 3way はメルカリで売った。cote&cielのバックパックの購入価格に近い価格で売れたので良かった。 正面 生地がとても丈夫そう。買ったばかりでまだ硬いが、馴染んでくるのが楽しみ。 背面 使っていた HEADPORTER の 3way の不満点を挙げるとすれば、ショルダーストラップの根本が少し頼りなくリュック用途で使う時に若干の不安があった。cote&ciel のバックパックは、ショルダーストラップと本体部分の生地が繋がっており、生地自体もかなり丈夫なので安心して背負える。 正面口を開けた状態 このバックパックを象徴するデザインとも言えるのが、この正面側の口だろう。開け口が大きく、ものを出し入れしやすい。容量もなかなか大きく、数泊の旅行であればこれで全て収まりそう。 背面口を開けた状態 背中側の口を開けるとノート PC を収めるスペースがあり、ここに MacBook Pro 13inch を入れている。構造上ショルダーストラップの後ろなので、若干開けにくい。生地の硬さや新品ファスナーの開けにくさも相まっている気がするので、使いながら緩和されるのを待ちたい。 外側収納：ファスナーポケット×2/固定バンド×2 前面収納：PC収納ポケット×1/ファスナーポケット×1/仕切りありオープンポケット×1 サイズ：縦×横×厚：約55×32×21.5cm/ショルダーストラップ：約53～88cm 素材：エコヤーン/カーゴキャンバス カラー：Black Melange(27711)https://1000ch.net/posts/2017/javascript-memory-leak/Fri, 17 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/javascript-memory-leak/2014年1月25日に Frontrend in Fukuoka というイベントが開催された（もう3年前か…）。その時に Browser Computing Structure というタイトルで、ブラウザの仕組みやらスクリプト処理について発表している。 たまたま当時の資料を掘り起こす機会があったので、メモリリークのサンプルを直したついでにリークする JavaScript のパターンについて書き起こしてみる。サンプルは 1000ch/memory-leak に公開してあり、手順通り操作するとメモリリークを再現できるようになっている。 GCで回収されないオブジェクト JavaScript はランタイム上で動的にメモリを確保する GC（ガベージコレクション）を採用しているので、JavaScript の書き手がメモリの確保・開放を意識することは少ない。しかしプログラムの書き方によっては、確保したメモリが GC によって開放されずにメモリが肥大化し、内部処理を圧迫していくことになる。 開放されないメモリは、対象の変数への参照が残っている場合である。どこかで使われている変数であれば GC で回収してはまずいが、不要になった変数が回収されないのはプログラム上のミスと言える。 class Leaker {} let leaker = new Leaker(); この JavaScript を実行してみる。実行は Chrome DevTools の Console 上で問題ない。実行したら Memory パネルを開いて Take Heap Snapshot を選択して実行すると、ヒープのスナップショットを保存できる。保存したスナップショットの内部を Leaker で検索すると、オブジェクトが見つかる。グローバルに存在する Leaker インスタンスが GC によって回収されていないためだ。 次に leaker = null; を Console で実行すると leaker は参照元がなくなり GC による回収対象となる。再度ヒープのスナップショットを保存してみてみると、先程検出された Leaker オブジェクトはいなくなっているはず。これがメモリリークの単純な例、もとい GC の基本的な仕組みである。 解除されないタイマーやイベントリスナー null を代入して GC による回収を促しても、実行したタイマーや登録したイベントリスナは暗黙的に解除されない。次の Leaker はインスタンスを作成した時点でタイマーが発動するが、そのインスタンスに null を代入してもタイマーは実行され続ける。https://1000ch.net/posts/2017/reachable-urls/Wed, 15 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/reachable-urls/前略、 1000ch/reachable-urls というテキストファイルに含まれる URL が有効かどうかチェックするツールを作った。一応程度に @inao さんに報告したらなんと使ってくれて、案外便利だったようで色々フィードバックをもらいながらコツコツ直した。今はバグも取れてきて安定してきたので、そろそろメジャーリリースしようかと考えている。 原稿中のURLが有効かどうかを調べてくれるツールを @1000ch さんが公開してくださった！ https://t.co/6qG3wpTJYu — 稲尾尚徳 (@inao) 2017年2月8日 インストールと使い方 Node.js 製なのでインストールは npm で。インストールすると reachable-urls コマンドが使えるようになる。グローバルにインストールしてもいいし、ローカルにインストールして npm test で実行するのも悪く無さそう。 $ npm install -g reachable-urls 引数にはファイルパスか glob を指定する。テキストファイルならなんでも OK なので、プレーンテキストなのかマークダウンなのかは問わない。テキストファイルから正規表現で URL を抜き出して sindresorhus/is-reachable でチェックするという単純な仕組みで出来ている。 $ reachable-urls ./*.md CLI だけでなく、もちろん require() しても使える。 const assert = require('assert'); const reachableUrls = require('reachable-urls'); reachableUrls('https://github.com https://foobarbaz.com').then(result => { assert.deepEqual(result, { 'https://github.com': true, 'https://foobarbaz.com': false }); }) 実装するかもしれない機能リスト http / https プロトコル以外のチェック @Jxck 氏によるバグ報告で気付いたが、 sindresorhus/is-reachable で WebSocket のプロトコルである ws と wss をチェックできない。これは内部で使っている silverwind/port-numbers で WebSocket が使うポート番号を引いてこれていないことが問題。https://1000ch.net/posts/2017/uber-eats/Thu, 02 Feb 2017 00:00:00 +0000https://1000ch.net/posts/2017/uber-eats/昨日、タイムラインで噂の UberEATS を使ってみた。注文したのは渋谷ガパオ食堂のガパオライスで、とても美味しかったことに加えて、UberEATS 体験が思いの外良かった。 #UberEATS で渋谷ガパオ食堂のガパオライスを注文してみた。店も豊富だし、注文も簡単、支払いもシームレスで良かった。思ったより便利なので早く普及して欲しい🚗 新規の人は招待コード「 eats-uber1000ch 」を使うと1500円分無料で注文できます😋 Shogo Sensuiさん(@1000ch)が投稿した写真 - 2017 2月 1 4:46午前 PST UberEATSとは 飲食店のメニューを UberEATS のアプリから注文して自宅まで届けてくれるサービス。その飲食店の従業員ではなく UberEATS の配達員が届けてくれる。提携している店舗がまだ少ないせいか、今のところ渋谷・恵比寿、青山・赤坂、六本木・麻布エリアのみ利用できる模様。きっと順次拡大していくだろう。 UberEATS のアプリで注文したいものを選ぶ アプリ上で決済し、注文を確定する 指定の場所に配達される アプリ上で決済が完了するので、ピザのデリバリーのように配達時に会計をしなくてよい（これに関しては出前館でも解決されている問題である）。あとは Uber と同様に配達状況をアプリのプッシュ通知で逐一知らせてくれるのも地味に嬉しいところ。 仕組みが気になる UberEATSの配達員をやってみたら、長文になった に配達員さんの経験談が赤裸々に書かれていて、面白い。 どうやら、配達員は任意の時間に任意の場所で待機し、お客様から店にオーダーが入ると、その店に近い配達員が配達係としてアサインされるようだ。この辺りの仕組みはタクシーのUberと似ている気がする。 配達員への報酬は配達件数単位で支払われるようで、繁忙期等は配達員が不足しないように最低保障もあるようだが、基本的にはタクシーのように歩合制。アプリ内で販売されている品に対して相応のマージンを掛ける必要がありそうだが、眺めている限りはそれほど高く感じないし、移動の労力をゼロにできると思えばかなり安い気はする。 UberEATS未体験の人は 招待コード eats-uber1000ch を使うと1500円分無料で注文できるので、良かったらどうぞ。https://1000ch.net/posts/2017/inside-frontend-vol1/Sun, 29 Jan 2017 00:00:00 +0000https://1000ch.net/posts/2017/inside-frontend-vol1/Inside Frontend #1 に「Web フロントエンドにおけるコンポーネント化のアプローチ」というセッションで出演します。 「Webフロントエンドの現場とこれからをつなぐカンファレンス」 Inside Frontend #1 を開催します。多様化している現場と、Webのこれからを一緒に考えていく場です。是非お越しください！ #insideFEhttps://t.co/BWtG0nMDQg pic.twitter.com/OizFjQOaL4 — Inside Frontend (@insidefrontend) 2017年1月27日 Inside Frontend は Web フロントエンドの勉強会を独自で開催している、ヤフー株式会社、日本経済新聞社、株式会社サイバーエージェントの三社の有志で運営する勉強会です。その第一回目がヤフー株式会社の新社屋で行われます。 通常のセッション枠に加えて、AMA（Ask Me Anything）という枠が合間に設けられており、有識者と交流するブースがあります。こちらも勉強会としてはやや珍しい枠組みではありますが、興味のあるトピックを真剣に議論できる良い機会になるのではないでしょうか。 一般参加枠300人募集のところ、既に500人突破していますが、参加可否は抽選なので今から応募してもチャンスがあります。もしよかったらご応募くださいませ👀https://1000ch.net/posts/2017/apple-watch-cradle/Sun, 08 Jan 2017 00:00:00 +0000https://1000ch.net/posts/2017/apple-watch-cradle/Apple Watch には磁気充電ケーブルが付属されているが、予備を兼ねて会社にも欲しいと思いクレードルを購入した。 iVAPO Apple Watch / iPhone 充電スタンド iVAPO Apple Watch / iPhone 充電スタンドは iPhone と Apple Watch をセットできる充電スタンド。 iPhone も Apple Watch もケーブルから充電しているだけだと不格好…とまでは言わないまでも、格好良くはない。 充電ケーブルは別売りだが、 iPhone や Apple Watch に付属してきた充電ケーブル群をまとめる目的も果たしている。アルミニウム製でスタイリッシュな見た目もなかなか気に入っている。 2つのUSBポートを搭載し、家庭用コンセントから2台のスマートフォンを同時に充電可能です。 スマートフォンを約2.5時間でフル充電できる急速充電タイプです。 コンパクトなキューブ型で、急速充電できる高出力タイプとして国内最小クラスを実現しています。 未使用時は電源プラグを折りたたんで充電器本体に収納可能です。 Poweradd Apple Watch専用磁気ワイヤレス充電ケーブル 充電スタンド付き Poweradd Apple Watch専用磁気ワイヤレス充電ケーブル 充電スタンド付きは、携帯用の充電ケーブル・会社に置いておく用のクレードルとして購入した。https://1000ch.net/posts/2017/developer-summit-2017/Thu, 05 Jan 2017 00:00:00 +0000https://1000ch.net/posts/2017/developer-summit-2017/デブサミこと Developer Summit 2017 に出演します。目黒雅叙園にて2月の16日・17日の2日間開催されますが、初日の Web セッションを鳥の人と担当します。 出演します w/ @ahomu 初日の E 会場 の 10:00~10:45 です 🙏 / "【16-E-1】 Web フロントエンドの変遷とこれから（仮） | Developers Summit 2017" https://t.co/28ju9FImos — 煎茶🍵 (@1000ch) 2017年1月5日 Web フロントエンドの変遷とこれから というタイトルで講演します。 Web を取り巻く環境は変化をし続けています。HTML5 が注目を集めたころから Web アプリケーションはさらに高度なサービスを提供するようになり、それに応えるようにブラウザも進化を続けています。そのような流れの中で Web フロントエンドのフレームワークやビルドツールも、その時々の多様なニーズを満たすために流行り廃りを繰り返しています。 このような変遷を遂げてきた昨今の Web を俯瞰し、これからの Web フロントエンドとの向き合い方についてお話します。 壮大ですが、業界に飛び込んで早4年半の Web 技術者生活を振り返る良いきっかけになりそうです。 初日（2/16）の 10:00 ~ 10:45 E会場（2F）華しずか です。宜しくお願い致します。https://1000ch.net/posts/2017/awesome-bought-in-2016/Tue, 03 Jan 2017 00:00:00 +0000https://1000ch.net/posts/2017/awesome-bought-in-2016/個人的に観測したリストのみピックアップした。 2016年買ってよかったもの - 面白コンテンツ探求日記 2016年に買って良かったと思ったもの ::ハブろぐ 2016年、今年買って良かったものをまとめてみた - tehepero note(・ω<) 2016年買ってよかったモノ - MOL 今年買ってよかったものトップ５ 2016 - Firespeed 2016年に買って良かったもの - 1000ch.net 今年買ってよかったもの10選-2016- – 石黒 卓弥/Takaya Ishiguro Things I Bought In 2016 – Tatsuhiko Miyagawa’s Blog tacamy.text — 2016年の買ってよかったものリスト 2016年の買ってよかったものリスト | Tediumhttps://1000ch.net/posts/2017/life-hack/Mon, 02 Jan 2017 00:00:00 +0000https://1000ch.net/posts/2017/life-hack/ライフハックというものでもないが、お金を節約するワザ - oinume journal に感化されたので、普段実践していることを書いてみる。 Amazonへ依存する 生活する上で必要なものを購入するだけでなく、音楽・映画・書籍などを便利に利用できるプラットフォームとして Amazon をよく使っている。マンションに宅配ボックスがあるのであまり使わなくなったがコンビニでも受け取れるし、 Amazon プライムの即日配達はやはり便利だったりと、受け取りに関するストレスが少ない。 Amazon MasterCard こうして Amazon へ依存する覚悟を決めてから、 Amazon MasterCard を契約している。 Amazon MasterCard は Amazon での買い物で 1.5~2.5%、 Amazon 以外での買い物で 1% のポイントが付与される。 Amazon での買い物はもちろんのこと、電気・ガス・水道・インターネット・各種サービスなどの利用料金もこのカードに統一し、日常生活のお金の支払いもなるべくこのカードを使うようにしている。カードを出すのはそれなりに野暮だが、 Apple Watch で Apple Pay を使い始めてからはこのカードから Suica へのチャージしているので、カードを出す面倒さをなくしつつカードから引き落とすということ実現できた。 日常生活の支出がどれほどあるか正確なところは把握できていないが、例えば年間支出が100万円だとすると、最低でもポイントが 1% つくので、1万円分は Amazon で買い物できるようになる。 プライム会員の特典 プライム会員で受けられる特典は、配送特典・会員限定先行タイムセール・プライムビデオなど様々だが、よく使っているのは配送特典とプライムビデオ。配送特典はとにかく早いので、急ぎの折には非常に便利である。プライムビデオは Philips 43型 ワイドディスプレイと合わせて、映画やドラマを快適に視聴している。以前は Hulu を使っていたが、プライムビデオによって役割を終えた。音楽サービスに AWA を使っているが、プライムミュージックの使い心地が良ければ移行するかもしれない。 要らないものをこまめに売る 読み終わった本・着飽きた服・古くなったデジモノなど、使わなくなったモノは積極的にメルカリや Amazon マーケットプレイスに出品している。メルカリは使いやすく全体的によくできている（特にらくらくメルカリ便が優秀）が、値下げしろというコメントが当たり前のようにつくなど、リテラシー疲れする部分もある。その点、 Amazon マーケットプレイスの方が楽な部分もあるが、出品手数料が高かったりアプリのデキがあまり良くないなど、一長一短である。 MacBook Pro や iPhone などは比較的早いサイクルで買い換えるようにしている。早いサイクルで買い換えると、今まで使っていた Mac や iPhone が製品として新しい状態なので高く売れやすい（かなりざっくり計算だと、購入時の半額程）。結果的に最新の製品を安く買えることになるので、新しいものを安く手に入れ続けるにはこれが良いのではと思っている。ちょっと面倒だけど。パソコンはスマートフォンについては、近所のじゃんぱらに持ち込んで査定してもらっている。メルカリや Amazon マーケットプレイスとは異なり、その場で現金化できるのが良い。ちなみに毎週火曜日はじゃんじゃん火曜日といって査定価格が 5% アップする。https://1000ch.net/posts/2016/look-back-over-2016/Sat, 31 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/look-back-over-2016/こうして振り返ってみると色々あった…。 講演活動 DevFest Tokyo 2016: 東京電機大学で Web Components と Polymer の最新事情について話した StartUp Tech Talk Night: 就職活動をする学生向けに話した Frontrend Vol.8: 復活した Frontrend で Resource Hints の話をした Frontend Weekly Meetup 2016: 100号記念でメルカリさんのオフィスをお借りして、Frontend Weekly 初のミートアップを開催した #fwtokyo2016 Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 12月 15 3:45午前 PST QoL活動 QCY QY8 ワイヤレスイヤホン: コストパフォーマンスが良い Dyson V6 Fluffy: 高いけどそれに値する品質 珪藻土バスマット: 布製のバスマットなんて要らなかった Philips 43型 4K ワイドディスプレイ: 大は小を兼ねる 美食活動 特に美味しかった記憶のあるお店をピックアップしたら、ほとんど肉🍖になった。 味のなかむら: 広尾にある 渋谷百軒店ノ小屋: 渋谷の道玄坂にある ローストホース: 広尾にある ゆうじ: 渋谷の宇田川町にある 焼肉 稲田: 目黒にある 焼肉芝浦 赤坂 別邸: 赤坂にある 正真正銘のユッケhttps://1000ch.net/posts/2016/stop-using-fontawesome/Mon, 26 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/stop-using-fontawesome/このブログでは Font Awesome を使っていたが、それをやめた。Webフォントのロードをやめたことに引き続いて、これで Web フォントの利用から脱却したことになる。 Font Awesome を使っていた箇所の修正 今回修正したのは次のリスト。利用頻度は多くないが、ロードしているリソースサイズが大きく見合わないと感じ、今回に至る。 ページングの <i class="fa fa-arrow-left"></i> を 👈　に変更 ページングの <i class="fa fa-arrow-right"></i> を 👉　に変更 RSS の <i class="fa fa-rss"></i> を SVG ファイルに変更 ♡ の <i class="fa fa-heart"></i> を SVG ファイルに変更 Facebook の <i class="fa fa-facebook-square"></i> を SVG ファイルに変更 Twitter の <i class="fa fa-twitter-square"></i> を SVG ファイルに変更 Google Plus の <i class="fa fa-google-plus-square"></i> を SVG ファイルに変更 それぞれの SVG ファイルは Sketch でトレースしたベクターデータから出力し、svg/svgo で最適化してある。また、素直(?https://1000ch.net/posts/2016/ga-measure-performance/Sat, 24 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/ga-measure-performance/Performance Calendar » Prefer DEFER Over ASYNC を見たのがきっかけ。 このブログでもサードパーティのスクリプトをいくつかロードしているが、言及されているように <script async> と <script defer> でパフォーマンスを比較計測してみる。 Google Analyticsで計測 まずはパフォーマンスを計測しなければということで、カスタム速度 | ウェブ向けアナリティクス（analytics.js）を参考に以下のスクリプトをブログに仕込んだ。今回は Navigation Timing API の navigationStart とdomInteractive の差分を集計する。 window.addEventListener('load', () => { if (window.performance) { ga('send', { hitType: 'timing', timingCategory: 'Navigation', timingVar: 'domInteractive', timingValue: performance.timing.domInteractive - performance.timing.navigationStart }); } }); GA にはページトラッキングやイベントトラッキングの他に、パフォーマンスの任意のメトリクスを集計するインターフェースがある。まじまじと触ることは少ないが、眺めるほど多機能で面白い。値は、 行動 > サイト速度 > カスタム速度 以下に集計される。 サードパーティスクリプトをdeferで読み込む Prefer DEFER Over ASYNC で言われているのは、 <script async> も <script defer> も HTML のパースはブロックしないが、 <script async> はスクリプトの実行が非同期でされるため UI スレッドを抑止する、つまり描画は遅れるという話。雑に言えば左右するのは DOMContentLoaded のタイミングということになりそうだが、 DOMContentLoaded を早めたいかどうかは Web ページの作りに大きく依存するので例によって「時と場合に依る」ということ。このブログに関して言えば、静的な HTML を配信しているのみでロードしているサードパーティスクリプトがページに作用する割合も大きくないので <script defer> が効果的に思える。https://1000ch.net/posts/2016/bought-in-2016/Mon, 19 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/bought-in-2016/2015年に引き続き、2016年バージョン。 Apple Watch Series 2 先月11月に原宿の Nike にて、 42mm モデルを 44,000 円で購入した。 おもちゃとしては高い買い物だっだが、想定以上に日常の無駄が省かれているのを実感している。一度この便利さに慣れてしまうと、財布を出した小銭の支払いやパスケースに入った Suica による支払いも煩わしさが際立つ。 詳細はApple WatchでApple Payを便利に使っている話にて。 Philips 43型 4K ワイドディスプレイ 引っ越したときにPC環境を新調したが、ディスプレイは 4K 対応の43型ディスプレイにした。以前から使っていたこともあり、信頼する Philips のディスプレイを今回も購入したが、今や Apple の準公式ディスプレイとなった LG UltraFine 4K Display も気になる。 基本的には ⌘ + Tab でアプリケーションの切り替えを行うものの、各種チャットツールや Whale といったメイン作業に関わらないけど常駐させておきたいアプリケーション群を画面端に置いておくと、なかなか捗る。それ以外にも Amazon プライムやらで動画を見るときに画面が広いのはとても良い。 Magic Keyboard - US と Magic Trackpad 2 を合わせて購入したので、実際にはもう少し高く付いたとも言えるが、快適に使っている。 画面サイズ: 42.5インチ、液晶パネル: IPS、ノングレア(反射防止)、解像度: 3840×2160、輝度: 300 cd/m²、入力端子: D-Sub15 ×1、HDMI2.0(MHL) ×2、DisplayPort1.2 ×2、USBポート: USB 3.0 ×4、保証期間: パネル、バックライトを含む5年間フル保証(センドバック対応) 詳細はPhilips 43型 4K ワイドディスプレイにて。https://1000ch.net/posts/2016/nakamoto/Sat, 10 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/nakamoto/蒙古タンメン中本 アドベントカレンダー 2016 4日目の記事です。 中本に行って注文するのは基本的に味噌卵麺。普段は渋谷店で食べているが、今日は新宿店で食べてきた。今気づいたが、食べログの評価、両方とも3.5以上なのね。 今年は、年間何杯食べているのかを数えるために Instagram に毎度アップロードするようにした。数えてみたところ2016年は32杯だった。 https://www.instagram.com/p/BN1y-gxjsTa/ https://www.instagram.com/p/BNnzO8TDu9W/ https://www.instagram.com/p/BNVwi3hD21N/ https://www.instagram.com/p/BNGUH9mj8BM/ https://www.instagram.com/p/BLuutBzjF7x/ https://www.instagram.com/p/BLPzZ9VjPWa/ https://www.instagram.com/p/BK5xO77Dwbb/ https://www.instagram.com/p/BKVOTFVDWUO/ https://www.instagram.com/p/BKCm1F9jCb0/ https://www.instagram.com/p/BJfGATrD_My/ https://www.instagram.com/p/BJJ98rsjEZe/ https://www.instagram.com/p/BIl3tzVDgXh/ https://www.instagram.com/p/BIcpZXYjNf7/ https://www.instagram.com/p/BIMwrIbDnio/ https://www.instagram.com/p/BHtQGLzjEDR/ https://www.instagram.com/p/BHQ_QPHjsKc/ https://www.instagram.com/p/BG8NcAZBpwm/ https://www.instagram.com/p/BGnqN5Ihp3K/ https://www.instagram.com/p/BGI9X2ehp3E/ https://www.instagram.com/p/BF1P61VBp0d/ https://www.instagram.com/p/BFntVaMhp-z/ https://www.instagram.com/p/BFfoyrWhp2H/ https://www.instagram.com/p/BFOag4ehp2_/ https://www.instagram.com/p/BE2aIaEBp26/ https://www.instagram.com/p/BEfNdayhp91/ https://www.instagram.com/p/BEXhJnlBpxN/ https://www.instagram.com/p/BEFf4phhp1e/ https://www.instagram.com/p/BD-rJeJBp6f/ https://www.instagram.com/p/BDpRKjUhp-y/ https://www.instagram.com/p/BC0Iq99Bpwm/ https://www.instagram.com/p/BAWm7UBhpyt/ https://www.instagram.com/p/BOCIeQKDQmv/https://1000ch.net/posts/2016/apple-watch-series-2/Fri, 09 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/apple-watch-series-2/昔から腕時計を付けないタイプだが、人様の Pebble を見てからスマートウォッチに興味を持ちはじめ、その Pebble の新しいバージョンである Pebble 2 および上位モデルの Time 2 のプロジェクトが、今年5月に Kickstarter で発表された。 Time 2 の Pledge を $179 で募集していたので衝動的に back して楽しみにしていた所で、今年の9月に Apple Watch Series 2 が発表される。 衝動的に Apple Watch 2 を購入してしまって、近日中に到着予定の Pebble Time 2 がどうでも良くなってしまったアカウントがこちらです https://t.co/sMaoOaeDbu pic.twitter.com/ZDVMx8lPIL — 煎茶 (@1000ch) 2016年11月6日 FeliCa 対応の OS アップデートもされたし、 Time 2 の到着を待たずして Apple Watch を購入してしまった。また、奇しくも Fitbit による Pebble の買収が発表され、Time 2 が世にでることはなくなってしまった。 その Apple Watch を使い始めて1ヶ月ほど経つが、かなり便利なのでその記録。 Apple Payでできること Apple Watch Series 2 は FeliCa を通した Apple Pay に対応している。概観は Apple Pay - 始め方 - Apple（日本）にあるが、これらがどのような仕組みで実現されているのかがよくわからなかったので、 Apple Pay を使いながら覚えたことを整理がてらメモ。https://1000ch.net/posts/2016/frontrend-vol8/Thu, 08 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/frontrend-vol8/ファイナルを謳った Frontrend Conference を開催した2015年2月21日からしばらくぶりの Frontrend Vol.8 を開催した。およそ1年8ヶ月の充電期間を経て復活した Frontrend には約100名の参加者にご来場頂き、アンケートの結果もまずまずで、主催側としてはやや安心。 Introduction to Resource Hints Resource Hints について発表したので資料を載せておく。 #frontrend 長引きましたすみません 🙏 発表資料です / "Introduction to Resource Hints" https://t.co/aWOfplZGCQ — 煎茶 (@1000ch) 2016年12月5日 そして connpass にもイベント資料一覧なるページがあるのを知った。これは良い。 観測している感想ブログ 今回の Frontrend には、参加枠として ブログ絶対に書くマン枠 というものが3席あったこともあり、参加レポートブログをチラホラ見かける。 Frontrend Vol.8 - 帰ってきたフロントレンド に行ってきたメモ #frontrend Frontrend Vol.8 - 帰ってきたフロントレンド 行ってきたメモ frontrend vol.8 へ行ってみた人の戯言 CA主催『Frontrend』に行ってきた話 「Frontrend Vol.8 - 帰ってきたフロントレンド」開催レポートhttps://1000ch.net/posts/2016/esa-app/Thu, 01 Dec 2016 00:00:00 +0000https://1000ch.net/posts/2016/esa-app/※この記事は Electron Advent Calendar 2016 1日目の記事です。 プロジェクトで esa を頻繁に使っているので、 Electron でラップして Dock に常駐できるようにした。鳥から連想して、ウズラを意味する Quail という名前にしてみたが、深い意味はない。 インストールするには 1000ch/quail/releases からアーカイブファイルをダウンロードして、アプリケーションファイルを任意の場所に配置してもらうだけ。 サードパーティーesaツール ありがたいことにサードパーティーesaツールに載せてもらった。Windows ビルドも用意でき次第、追加してもらおう。 【お知らせ】esa 非公式 Mac/Linux app “Quail” by @1000ch をサードパーティーesaツールに追加しました ( ⁰⊖⁰) #ﾄﾉｺﾄhttps://t.co/3H2SQqj6H6https://t.co/Ap6RJZESIj — esa_io (@esa_io) 2016年11月27日 使い手のコンテキストとパフォーマンス TrelloをElectronでラップしてアプリにしたでコンテキストの区別の話をしたが、他にも気づいたことがある。 画面遷移が少ない Trello とは異なり esa では遷移が頻繁に発生する。 esa は SSR だが SPA ではないので2回目以降のナビゲーションでは画面が白くなる時間があるのだが、これが案外気になる。これもコンテキストの話だ。 Web アプリを Electron でラップして思うのは「 Dock に常駐するアプリなのに画面真っ白になるのなー」という気持ち。ブラウザだと気にならないのにネイティブアプリにした途端、不思議なくらい気になる。 — 1000ch (@1000ch) 2016年11月27日 これについては次のような安直スクリプトを各ページに仕込んで、主な導線への遷移を高速化しようとしたがダメだった。静的なリソースじゃないとですね。 function createPrerender(url) { const link = document.createElement('link'); link.rel = 'prerender'; link.https://1000ch.net/posts/2016/okinawa-3rd-day/Sat, 19 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/okinawa-3rd-day/最終日は飛行機の時間もあり、観光に取れた時間は少なかった。 川平湾 島の北西にある川平湾でグラスボートに乗ってきた。グラスボートは船の中央部の底が透明になっており、そこから海中の様子を見ることができる。川平湾の海は海の底が見れるくらい綺麗なので、魚・貝・珊瑚といった沖縄の海ならではのものを見れる。 海の色の美しさはココが一番だったと思う。石垣島の観光スポットとして、川平湾は行って損は無さそう。 石垣空港 あとは石垣空港でフライトまでの時間を過ごすことにした。 写真は空港内の売店で食べられる石垣牛のステーキ丼970円。あとはお土産を購入したが、今回の旅行で一番金を使ったかもしれない。 今回の沖縄旅行のまとめ アレがアレで飲み歩きが出来なかったが、今回の個人的な収穫としては次の通り。 竹富島の西桟橋 には是非行っておきたい マリンスポーツは全般的に楽しい（友人談） ANA インターコンチネンタルはとても良い 羽田・石垣間はやはり直行便が楽である みなさんお疲れ様でした。 余談だが、最近買った Apple Watch がなかなか活躍してくれた。日本国内であれば Suica が使える所は非常に多いと感じる。https://1000ch.net/posts/2016/okinawa-2nd-day/Fri, 18 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/okinawa-2nd-day/天気にも恵まれ終日自由行動だったので、予め立てていた計画通り離島散策を実施した。 波照間島 波照間島は日本の最南端にある有人島で、石垣島からはフェリーに乗って45分程で到着する。 島内は歩いて散策するには広いので、レンタルサイクルにて自転車を借りる。1人500円でママチャリをゲット。島内は思った以上に高低差があるので、下りはさておき、坂道を上るのは中々辛かった。2000円で電動自転車が借りられるならそちらを選んでいただろう。なかったけど。 島内は見渡す限りさとうきび畑の田園風景が続く。 島内には野生ではないヤギが居る。自転車で巡っている最中に、放たれているヤギと繋がれているヤギ、合わせて20頭程は見かけただろう。 親ヤギは繋げておいて、子ヤギは放して飼っているということを住民の人に聞いた。こうすることで、子ヤギが餌となる植物を島内を散歩しながら確保し、最終的には親元まで戻ってくるらしい。なんというエコシステム。 せっかく日本最南端の島に来たので日本最南端の場所に行こうということで、日本最南端の牌があるスポットに行ってきた。 写真のような断崖絶壁の場所だった。こうして日本最南端に来てみると、今度は日本最北端の場所に行ってみたくなるものだ。 次は、日本最南端のペムチ浜に向かう。途中、明らかに自然発生ではない防空壕のような穴があった。戦争の名残だろうか。 普通の砂浜だった。 猫もいた。近づくと地面に身体を擦り付けていた。 お昼の時間になったので、民宿件ランチスポットとなっている民家にて、ソーキそばを食べる。初日にソーキそばを食べてアレしたので、若干のトラウマがあったものの、心配を他所に美味しかった。 波照間島の次は竹富島を目指すが、波照間島から竹富島へ直行するフェリーはないので、ひとまず石垣島へ帰還する。この帰りのフェリーが尋常じゃないほど揺れたが、竹富島内を自転車で巡るのが余程疲れたのか眠っていた。人間どこでも眠れるんだなと思った。 竹富島 竹富島は石垣島からフェリーで10分程の距離に位置する有人島。人口は300人程。 島内は歩いて観光もできるが、水牛車のツアーがあったのでひとまずそちらを利用することに。水牛のシマ君が案内してくれた。島内の水牛にはヨーロッパ系とアジア系がいて、シマ君はヨーロッパ系。 一般的にヨーロッパ系はアジア系より身体が一回り大きく、怠け者な性格らしい。一方でアジア系は真面目で働き者らしいが、これは水牛の用途が関係しているらしく、ヨーロッパでは主に乳製品が目的なのに対しアジアは農耕用であるため、それがこのような性格的な傾向にも表れているとのこと。 見分けは身体の大小ではなく角を見れば一発で、角が丸く渦巻いているのがヨーロッパ系、シュッと真っ直ぐ伸びているのがアジア系らしい。 竹富島では、これぞ沖縄と言わんばかりの伝統的な民家の風景が見られる。こうした伝統的な風景を守るために、竹富島の家は「平屋で赤レンガの屋根の〜…」といった条件を満たす必要があるそう。確かに、2階建ての家屋はほとんどなかった気がする。 綺麗なハイビスカス。沖縄らしかったので撮影。 シマ君に島内を案内してもらった後は、西桟橋に行ってきた。写真の通り「ここが天国か」と思わされるような、静寂に包まれた海だった。「沖縄旅行で離島に行かないのは素人」なんていうジョークもたまに聞くが、 竹富島の西桟橋 は今まで見た光景で一番凄かったかもしれない。何時間でもボーッとしていられそうだった。 西桟橋から望む竹富島の海岸線。ちょうどこの反対側に幻の砂浜という場所もあるが、遠くて写真には収めていない…。 石垣牛を食す 夕食はてっぺんというお店で。 料理全般良かったが、石垣牛の肉寿司がひときわ美味しかった。写真でお楽しみください。https://1000ch.net/posts/2016/okinawa-1st-day/Thu, 17 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/okinawa-1st-day/前日入りの甲斐あって6:30起床で済んだので、7:00集合を物ともしなかった。 羽田空港を出発、那覇空港へ なんだかんだで2:00くらいまで飲んでいたので微妙に二日酔いを感じつつ、那覇空港への飛行機へ乗り込む。 羽田→那覇のフライトがかなり遅れたせいで、乗り継ぎにバタついた。直行便のありがたさを知る。 沖縄本島を経て石垣島へ 石垣島に来るのは人生2回目で、その時は夏だった。その時は漠然と暑かった記憶があるが、今日は11月の半ばというのに気温が28度あって、想像以上の暑さだった。 初日はマリンスポーツ組・食い倒れ組などに分かれて、石垣島を散策するプラン。天気にも恵まれて、良い旅行になりそうである。 味処のりば食堂 のりば食堂という処で、豆腐そばとゴーヤチャンプルーを食した。食べログのスコア3.5~という数字のみをアテにしていったが、とても美味しかった。 …と思った矢先に体調不良に見舞われ、昼食後から戦線離脱して病院へ。その後ホテルへ直行して体調の回復を待つ… ANAインターコンチネンタル石垣リゾート 今回の旅行でお世話になるホテルはANAインターコンチネンタル石垣リゾート。部屋から望むオーシャンビューが素晴らしいが、撮り損ねたのでまた明日。https://1000ch.net/posts/2016/okinawa-0th-day/Wed, 16 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/okinawa-0th-day/明日からプロジェクトメンバーでの沖縄旅行が始まる。集合が7:00ということで朝が辛いことが予想されるので前日入りしようと考え、羽田空港に併設されているFIRST CABIN 羽田ターミナル1に宿泊することにした。 国際線ターミナルは24時間営業だが、国内線ターミナルにある飲食店はだいたい21:00あたりで閉まってしまうので注意が必要（FIRST CABIN は国内線第一ターミナルにある）。食事を羽田空港で済ませようとしている場合は、お目当てのお店の営業時間を調べておいたほうが良い。 国内線ターミナル夜の人が少ない空港は新鮮な気分を味わえる。 FIRST CABIN 羽田ターミナル1 FIRST CABIN はカプセルホテルのチェーンである。 大浴場やシャワールーム、ラウンジ、Wi-Fi、各種アメニティも完備しており、静かで快適に過ごせる。モーニングコールもしてくれるので、次の朝の早起きをあまり気にしなくて良い精神的開放感はかなり良い。 ラウンジでは皆が思い思いに時間を潰している。私は前泊を決意した同僚2人と酒を飲みながら話をした。 レストランあずさ 仕事終わりに羽田空港に向かったが、前述の通り注意しなくてはならない。 レストランあずさで天ぷらうどんを食べた。https://1000ch.net/posts/2016/trello-app/Tue, 15 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/trello-app/Trello を Electron でラップしただけの単純なアプリケーション、Whale をリリースした。 Trello という名前が付けられないので色から安直に連想して Whale とした。こちらは Mac で起動している様子。 インストールするには 1000ch/whale/releases からアーカイブファイルをダウンロードして、アプリケーションファイルを任意の場所に配置してもらうだけ。 Electronでラップする理由 Web 版の Trello はよくできていて、 Electron でラップしないと実現できない機能は思い当たらない。 Slack のアプリも Electron でラップしているが、 Slack のチームを左カラムにまとめるという目的がある。これはチーム単位でユニークな URL が存在しているため、ブラウザでは難しい。ブラウザで複数チームを使うにはタブを個別に開いておく必要がある。 また、アプリケーションにする理由としてコンテキストの区別がある。「ブラウザは●●を閲覧するため、 Atom は◯◯を編集するため、…」のように、アプリケーション単位で用途を分けることもあるので、もし Trello を別コンテキストにしたい需要があれば、便利かもしれない。https://1000ch.net/posts/2016/yamaki/Fri, 04 Nov 2016 00:00:00 +0000https://1000ch.net/posts/2016/yamaki/静岡県伊豆伊東にある山喜旅館へ、1泊2日の開発合宿にプロジェクトメンバーと行ってきた。渋谷に出勤しているとどうしてもまとまった時間が取れないこともあり、プロジェクトの技術的負債を返済するべく、静岡へ赴いた。 山喜旅館 山喜旅館は静岡県JR伊東駅から徒歩7分の立地にある老舗の旅館。開発合宿の地として有名で、数々の実績がある温泉宿である。 エンジニアが選ぶ。開発合宿で泊まりたい日本の宿7選【2013年版】 − IT技術者必見！　一度は行きたい「開発合宿所」10選 開発合宿にオススメ！旅館5選（Wi-Fiやモニタなど充実設備！） 【2016年版】エンジニアにおすすめの開発合宿所4選＆企画のポイント アクセス JR品川駅→JR熱海駅→JR伊東駅というルートで、品川から熱海までは新幹線こだまで36分、熱海から伊東までは伊東線に乗り換えて各駅停車の電車で25分程なので、なんだかんだで1時間半程で現地に到着してしまうという距離感。 設備 設備としては、24時間解放の温泉・懐石料理・Wi-Fi・会議室・アメニティ・アダプタや延長コードの貸出・近辺のコンビニなどが挙げられる。 会議室を借りてそこで開発をしていたが、Wi-Fiはやや重く時折ストレスを感じながらの作業になった。13人が同時に繋いでいた状況で重さを感じたので、もしかしたら4~5人なら重さは気にならないのかもしれない。ベストエフォートとは言え、もう少し潤沢だと嬉しかった。 電源についてはタコ足延長コードの貸出もあったので不自由はなく、椅子と机については立派なものではないので長時間座っていると腰痛を招くかもしれない。が、旅館にアーロンチェアを望むのもアレなので、運用でカバーしたいところだ。 雰囲気 伊東駅からほど歩くと、風情ある外観に出迎えられる。 良い意味で老舗旅館という感じで、新しくはないけど清潔に保たれている様子。海辺という立地もあり風が強かったが、窓はガタガタ騒がしい。今回に関して言えば、会議室に立て籠もって開発していたせいで部屋でゆっくりした時間はなかったので、それを聴いたのも寝る直前だけ。疲れ果てていたので耽る間もなく寝た。 外観だけでなく内観も情緒に溢れている。宿泊者にはコーヒー☕のサービスがあったので、ありがたく利用させてもらった。 1日目 朝9:00に品川に集合して出発すると昼には現地に着いていた。会議室に入って、机などをセッティングして開発できる環境を整えてから昼食のために楽味家まるげんに向かう。会議室にある机や椅子は自由に使っていいけど、撤収するときはもとに戻してねというスタイル。 昼食を終えるとセブンイレブンで飲み物やお菓子などの買い出しをしてから旅館に戻って、旅館の夕食の時間（19:00~）までしばし作業をする。 夕食後（~20:00）から作業を再開し、かれこれ22:00まで続いた。22:00の段階で一応初日終了の合図はされたものの、作業のキリが悪いのか皆再び作業に戻る。そこからは買いだした酒を飲みはじめたり、合宿に来ていないメンバーから差し入れを頂いたり、Hangoutしたりとゆるりと休憩ムードへ。温泉に使ってからもまた作業に戻ったりして、結局寝たのは日付が変わった2:00頃だった。 2日目 7:00起床というスケジュールだったが、案外皆起きてくる。昼前まで作業の続き。 2日目の昼食はうなぎのまといというところで鰻重を食べた。非常に美味しかった。 昼食を終えて例のごとくコンビニに寄ってから旅館に戻ると夕方の成果発表までラストスパート。夕方に各チームに分かれての成果発表として、チームで抱える課題・この合宿での成果・今後の課題などのプレゼンテーションを行った。 所感 合宿の目的として技術的負債の返却（の足がかり）だったので、やるべきことが明確な分、事前の準備もしやすく現地での作業も悩む時間は少なかったのではないか。事前にピックアップした技術的負債を全て消化しきれなかったチームもあったが、それはあまり気にしなくて良いと思う。負債の多寡に対してリソースは限られているので、その場でどうするかより今後の開発で継続的にリファクタリングをしていくきっかけにすることが重要なわけで（や、もちろん返却しきるに越したことはない）。言うなれば日々のFacebookを見る時間を削ってリファクタリングできるのだから。 負債を返却することを目的にした合宿を頼りにすると、人によっては普段の開発での心構えが弱くなりそうなのでそれは注意が必要。とは言え、温泉地に赴いてリファクタリングだけに集中することは大事だし、楽しいし、事業の一環として（表現がやや無理矢理だが）許容してもらえるのは非常にありがたいことだ。マンネリ化するのも良くないので、クオーター・半期に1回くらい行けると合宿としての意義が生まれやすいかもしれない。あとは、1泊2日だとそれなりに移動に疲弊してしまうので、できれば2泊3日だとより良かった。この辺は業務との兼ね合いもあるので難しいけど。https://1000ch.net/posts/2016/dispatch-queue/Sat, 22 Oct 2016 00:00:00 +0000https://1000ch.net/posts/2016/dispatch-queue/自作の iOS クライアントのコードを Swift 3 に移行した。その時に非同期処理について色々調べたのでメモ。 GCD (Grand Central Dispatch) macOS や iOS といった Apple のプラットフォームにおいて非同期で処理したい場合は GCD (Grand Central Dispatch) という仕組みを使う。 UI に関する更新はメインスレッドで行う必要があるので dispatch_get_main_queue() で取得するメインキューに処理を追加し、通信などの非同期でも差し支えない処理はグローバルディスパッチキューという並列処理用のキューを dispatch_get_global_queue() で参照する。それぞれのキューに処理を追加するには同期か非同期かを、 dispatch_sync() と dispatch_async() で指定できる。 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), { // グローバルキューで実行される dispatch_async(dispatch_get_main_queue(), { // メインキューで実行される }); }); dispatch_sync() で処理を追加すると同期的に実行されるので、追加した処理が終わるまで次の処理に進まない。逆に dispatch_async() で追加された場合、追加された処理の実行完了を待たずに次の処理に進む。 Swift の GCD についてはSwift GCD入門という記事により詳しく書かれている。 DispatchQueueクラスが追加された これをiOS+Swiftの非同期処理のヘルパークラスのような形でラップしていたが、 Swift 3 からは DispatchQueue というクラスが追加されている。これを使うと非同期処理は次のように書ける。 DispatchQueue.global().async { // グローバルキューで実行される DispatchQueue.main.async { // メインキューで実行される } } メインキューを取得する dispatch_get_main_queue() は DispatchQueue.https://1000ch.net/posts/2016/heroku-automatic-deploy/Fri, 21 Oct 2016 00:00:00 +0000https://1000ch.net/posts/2016/heroku-automatic-deploy/何事も自動が大事という前置きはさておき、GitHub のリポジトリへのコミットを契機に Heroku へ自動でデプロイを行いたい話。機能が存在していることは認識していたが、実際に使ってみたら便利だったのでメモ。といっても、難しいことはないので、詰まることもなかったが。 Heroku Gitによるデプロイ Heroku にある Git リポジトリに変更をプッシュすると、それが Procfile に沿ってデプロイされる。最も一般的というか基本的？だと思われる。 1000ch/cobra というプロジェクトを例に説明する。 Heroku にアプリケーションを作成すると、その名前で Git のリポジトリが作成される。今回は GitHub を origin としているので、 Heroku のリモート名を heroku とする。 $ git clone https://github.com/1000ch/cobra.git $ cd cobra $ git remote add heroku https://git.heroku.com/cobra.git $ git push heroku master プッシュすると、それを検知して Heroku 側でデプロイが行われる。 HerokuとGitHubを連携する Heroku に GitHub へのアクセス権を与えると、 GitHub リポジトリと Heroku アプリとの連携が可能になる。その後 Personal Apps から対象アプリを選び、 Deploy タブを選択すると Deployment method というデプロイ方法を選ぶセクションが見つかる。 ここで GitHub を選択して、連携したいリポジトリと接続する。すると次のように Automatic deploys のセクションに自動デプロイに関する設定が現れる。https://1000ch.net/posts/2016/chromiup/Wed, 12 Oct 2016 00:00:00 +0000https://1000ch.net/posts/2016/chromiup/通常 Chromium をインストールするには Download Chromium からアーカイブをダウンロードして解凍し、アプリケーションフォルダにコピーという手順だが、この手間をどうにか簡略化できないか考えていた。シェルスクリプトでもできるけど npm でインストール出来ても良かろうと、 1000ch/chromiup という Node.js 製のコマンドラインツールを作った。 インストールと使い方 README に書いてある通りだが、 npm でグローバルにインストールして、 chromiup を実行するだけ。 $ npm install -g chromiup $ chromiup すると次のようにインジケータが表示され、ダウンロード→インストールが行われる。 Chromum に自動アップデートがないのは何故？ Chrome や Chrome Canary については自動アップデートの機能があるが Chromium にはない。正確な情報か不明だが、Why is Chromium not updated automatically as Firefox is? にかかれているような Multi Distribution も関係していそうではある。まぁ大抵の場合は Canary で事が足りるのでここまでして Chromium を最新に保つ必要はない気がする。https://1000ch.net/posts/2016/devfest-tokyo-2016/Mon, 10 Oct 2016 00:00:00 +0000https://1000ch.net/posts/2016/devfest-tokyo-2016/10月9日に開催された DevFest Tokyo 2016 に出演しました。 先程の Web セッションのスライドです！ / "Web Components 2016 & Polymer v2" https://t.co/hPlKgYINdP #devfest16 — 1000ch (@1000ch) 2016年10月9日 2016年現在の Web Components と、来週に迫った Polymer Summit 2016 で発表されるであろう Polymer v2 の 話をしました。改めて文字起こしをする予定なので詳細は割愛しますが、スライドは既に公開してある（実は当日の一週間前からしてあったけど）ので、v0からの変更点は感じ取れるかと思います。 当日は FRESH! でリアルタイム配信があったようなので、興味のある人はそちらもどうぞ。 参考リソース 基礎からわかる Web Components 徹底解説 〜仕様から実装まで理解する〜 Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes Custom Elements W3C Working Draft 02 October 2016 Shadow DOM W3C Working Draft 30 August 2016 HTML Imports W3C Working Draft 25 February 2016 The template element What’s New in Shadow DOM v1 (by examples) w3c/webcomponents/issues Mozilla and Web Components: Update The state of Web Components Shadow DOM (unprefixed) – Welcome to the Windows developer feedback site!https://1000ch.net/posts/2016/kindle-paperwhite/Sat, 24 Sep 2016 00:00:00 +0000https://1000ch.net/posts/2016/kindle-paperwhite/先月に Kindle Paperwhite を購入していた。 Kindle Oasis と迷ったが、最終的には両者価格差がアップグレード内容に見合わない気がして Paperwhite を選んだ。 Kindle と Kindle Paperwhite は、時折開催されるプライム会員セールの割引対象になるので、それを狙うのも良い。 Kindleシリーズのスペック 詳細は公式ページの比較表を見てもらうとして、どうしても外せない機能は内蔵ライトくらいだった。Paperwhite の内蔵ライトは Oasis に比べてライトの数が少なくて明るさにムラがあるとのことだが、今のところ気になる程度ではない。 解像度は Paperwhite 以降は同じ 300ppi だし、ディスプレイやストレージのサイズも同じ。バッテリーについては Paperwhite が数週間で Oasis が数ヶ月ということで大きく差がありそうだが、主に布団に潜って寝るまでに読む用途で使っており、持ち歩いて使う頻度は少ないので全く気にならない。 Voyage と Oasis にはページ送りの物理ボタンがついており、タッチパネルを指フリックでページ送りするのは少し面倒なので、これは確かに便利そう。重さについては Paperwhite が 205g なのに対して Oasis は 131g （持ち手側の重心）と魅力的である。 使った感想と後悔 Oasis を使えば「こちらのほうが良い」と確実になるだろうけど、使っている分には Paperwhite のスペックで不都合はなく満足してしまっているというのが現状である。「どうせ買うなら良いものを」という気持ちで奮発しても良かったけど Paperwhite → Oasis で上乗せされる額が大きいし、それなら PS4 を買うなぁと思いつつ（ Rebuild: 142: Creative Manager (naoya) より ）。 店舗等で実際に両者を比較できなかったのもある。最近 Amazon は店舗での販売をやめたようで家電量販店では順次撤退が進んでいるので、手にとって試す機会は今後もないかもしれない。 読書のための専用端末 - E Ink(イーインク)ディスプレイで、紙のように読みやすい。直接目を照らさないフロントライト方式だから、目に優しく、長時間の読書でも疲れにくい。本数千冊(一般的な書籍の場合)がこの一台に。これまでのKindle Paperwhiteの中で最も薄く、最も軽い。ベゼルがフラットになったモダンなデザイン。300ppiの高解像度で、小さな文字もくっきりキレイ。反射しないディスプレイだから、明るい陽射しの下でもまぶしくない。防水機能搭載(IPX8等級)。ビーチでも、プールでも、お風呂でも快適に読める。長時間バッテリー。一度の充電で数週間利用可能。明るさ調節により、屋外でも室内でも、昼も夜も、快適に読書。700万冊以上の本、マンガ、雑誌、洋書を低価格で。日替わりセールほかお得なタイトルも。プライム会員なら、追加料金なしで対象のタイトルが好きなだけ読み放題(Prime Reading) Kindle史上最高のPaperwhiteディスプレイ。7インチ、フラットベゼル、300ppi。色調調節ライトを初搭載。ホワイトからアンバーに色の暖かさを調節可能。防水機能搭載(IPX8等級)でお風呂でもプールでも読書を。薄く、軽い、人間工学に基づいたデザイン。ページ送りボタン搭載。本物の紙のような読み心地。最新のe-ink技術採用でページ送りもスラスラ。700万冊以上の本、マンガ、雑誌、洋書を低価格でhttps://1000ch.net/posts/2016/github-japan/Tue, 20 Sep 2016 00:00:00 +0000https://1000ch.net/posts/2016/github-japan/芝大門にある GitHub Japan を訪問してきた。 GitHub のワークスタイルがリモートワークベースということもあり、出社率は高くないらしいが、ビルの1フロアを借り切ったコンパクトで可愛らしいオフィスだった。 応接スペース的な テーブルの上には WEB+DB PRESS をはじめ各種雑誌が散らばっていた。 フロアの中央に陣取る和室 フロアの中央に和室の区画がある。某氏の占領頻度が多くてもはや専用ルーム化しているとかしていないとか。 和室の外側はこのようなオレンジの壁。窓にオクトキャットが飾られていた。世界各国の拠点のオフィスも、オレンジ配色が多いらしい。 ミーティングルーム オクトキャットでコーティングされているミーティングルーム。中身は写してないけど、壁に大きなディスプレイが貼り付けられていて世界各国の拠点と繋いでビデオチャットをするらしい。 その他 壁に無造作に立てかけられた Hubot のポスター。これはGitHub Shopでも販売されているものだ。 あとはトイレ・キッチン・備品ルームなどもあった。デスク＋チェアが並んでいるいわゆる作業スペースもあったが、写ってはいけない物が写るといけないので自重した。https://1000ch.net/posts/2016/custom-elements-v1/Fri, 16 Sep 2016 00:00:00 +0000https://1000ch.net/posts/2016/custom-elements-v1/Custom Elements v1 が Chrome の 54 からサポートされた。 これまでの document.registerElement('custom-element') によるカスタム要素の定義は v0 にあたり、 v1 は様々な見直しがなされた Custom Elements の新しいバージョンである。 定義方法の変更 v0 document にぶら下がる registerElement() で要素を定義してきた。 registerElement() は定義されたカスタム要素のコンストラクタを返す。 // カスタム要素の定義 const FooElement = document.registerElement('foo-element', { prototype: FooElementPrototype }); // <button is="bar-button"></button> const BarButton = document.registerElement('bar-button', { prototype: FooElementPrototype, extends: 'button' }); v1 window に customElements というオブジェクトが追加される。 customElements は CustomElementRegistory という IDL である。 カスタム要素に関する操作はこの customElements を通して行われ、customElements.define('element-name') でカスタム要素を定義し、 customElements.get('element-name') でカスタム要素を参照し、 customElements.whenDefined('element-name') でカスタム要素が定義されるタイミングを取得する。 whenDefined() の返り値は Promise である。https://1000ch.net/posts/2016/soft-skills/Sun, 04 Sep 2016 00:00:00 +0000https://1000ch.net/posts/2016/soft-skills/ソフトウェア開発者のキャリアマネジメントについて書かれた啓発本。原著はSoft Skills: The Software Developer’s Life Manualで、今年の6月に発売された和訳版にあたる。 ジョン・ソンメズ (著), 長尾 高弘 (翻訳), まつもとゆきひろ (監修) 独立・筋トレ・セルフブランディング・投資など多くな開発者が興味を持つ（将来に描く？）トピックについて生々しく語られている。ストイックな人には特に面白い内容だと思う。https://1000ch.net/posts/2016/web-font/Mon, 22 Aug 2016 00:00:00 +0000https://1000ch.net/posts/2016/web-font/このサイトではフォントに Roboto と Roboto Mono を適用している。以前までは Google Fonts で配信されているそれぞれのフォントをロードしていたが、それをやめて font-family の指定のみに変更した。 プログレッシブな適用とOS共通フォントの選択 まず前提として、テキストのベースフォントとして明朝（serif）を、 <h1> ~ <h6> の見出しにはゴシック（sans-serif）を、コードには等幅（monospace）を適用する前提方針がある。明朝・ゴシック・等幅の中から自分の好みに近く、尚且つ Mac と Windows にインストールされているものを優先的に選ぶようにした。 body { font-family: YuMincho, serif; font-weight: normal; } h1, h2, h3, h4, h5, h6 { font-family: Roboto, Helvetica, Arial, sans-serif; font-weight: bold; } code { font-family: "Roboto Mono", "Source Code Pro", Consolas, "Courier New", monospace; font-weight: normal; } 最も広域になるであろう <body> には Mac にも Windows にもインストールされている可能性が高い游明朝体（YuMincho）を指定した。游明朝体は Mac であれば OS X Mavericks (10.https://1000ch.net/posts/2016/amazon-payment-history/Sat, 20 Aug 2016 00:00:00 +0000https://1000ch.net/posts/2016/amazon-payment-history/ブックマークレットが流行ったが、拡張機能として作りなおした。APH - Chrome Web Storeからダウンロードできる。 モチベーション 日常的に使うものではないので拡張機能である必要がないが、以下の理由で都合が良い。 インストール 任意のページへの誘導（注文履歴で JavaScript を実行する必要有り） 去年以前の結果のキャッシュ ポップアップでの結果表示 使い方 内部で認証つき HTTP リクエストをする必要があるので、注文履歴を開いていない場合は開き、開いている場合はポップアップを表示して集計を開始する。この手順を拡張機能内でシームレスにできれば良いのだが、 新しいタブを開きつつその後に拡張機能のポップアップを表示する ことが可能なのか不明。https://1000ch.net/posts/2016/philips-display-43inch-4k/Mon, 08 Aug 2016 00:00:00 +0000https://1000ch.net/posts/2016/philips-display-43inch-4k/以前まで Philips 23型 AH-IPSパネル採用 ワイドディスプレイ を使っていたが引越し前に断捨離して、 Philips 43型 4K ワイドディスプレイ を購入した。 Philips 43inch 4Kディスプレイを買った。大は小を兼ねる。 Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 8月 7 9:49午後 PDT 会社で使っている Thunderbolt Display は 27inch なので、これよりふた回り程大きい。 Thunderbolt Display と MacBook Pro を併用したデュアルディスプレイだが、 43inch もあるとデュアルすら必要のない程充分な大きさである。また、大きさ故に必然的にディスプレイと至近距離で作業することがないので目にも幾分優しそう。 無印良品のオーク材デスクが到着したのでセットアップした。ネットも開通したし、これで色々捗る☕️ Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 8月 10 11:53午後 PDT テレビ要らない族なので、 PC やゲームなどの出力先ディスプレイとして全てを賄っている。かなり大きなディスプレイなので PS Vita TV や MacBook Pro の出力が追いつくかどうか心配だったが、今のところ問題無い様子。 画面サイズ: 42.5インチ。液晶パネル: IPS、ノングレア(反射防止)。解像度: 3840×2160。輝度: 300 cd/m²。入力端子: D-Sub15 ×1、HDMI2.0(MHL) ×2、DisplayPort1.2 ×2。USBポート: USB 3.0 ×4。保証期間: パネル、バックライトを含む5年間フル保証(センドバック対応)https://1000ch.net/posts/2016/keisodo-bath-mat/Mon, 01 Aug 2016 00:00:00 +0000https://1000ch.net/posts/2016/keisodo-bath-mat/布系のバスマットを利用していたが、珪藻土のバスマットを購入した。 従来のバスマットだと吸水力に限界があるし、一度使うと次に踏む時の不快感が拭えない。乾くのも遅いのでどうしても匂いがつくし、都度洗わないければならない。珪藻土のバスマットはこうした不満点を全て解消してくれる、かなり画期的なアイテムだった。 素材・成分：珪藻土・植物繊維・その他。商品サイズ：約60cm×39cm。カラー：ホワイト。付属品：お手入用サンドペーパー付 珪藻土のバスマットは1枚の板で、吸水力が高く乾くのも早いという特徴がある。まだ使用して間もないので、吸水力が落ちたという状況にはなっていないが、ヤスリで削るなどのメンテナンスで復活するそう。あとは割れやすいとのウワサもあるが、そんなに乱暴に踏んだりしなければ大丈夫だと思われる。https://1000ch.net/posts/2016/muji-led-bluetooth-speaker/Sun, 31 Jul 2016 00:00:00 +0000https://1000ch.net/posts/2016/muji-led-bluetooth-speaker/以前からSONYのLED電球スピーカーが気になっていたが、無印良品に赴いたところ同等の商品が偶然あったので、衝動的に購入してしまった。ペンダントライト本体が9000円、LED電球型Bluetoothスピーカーが9800円と、照明より高い。個人的に無印良品が好きなので今回はセットで購入したが、型（口金E26）さえ合えば違うものでも使える。はず。 無印良品のペンダントライトとLED電球型Bluetoothスピーカー Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 7月 30 11:52午後 PDT 電球と一体型で場所を取らず、音が部屋全体に拡散して、給電を気にする必要がない、などのメリットがある。MacやiPhoneと接続して使用しているが、Bluetoothの感度は良さそう。スピーカーの出力は2Wで音質を問われると決して良いわけではないが、BGMを流すなどの個人用途では今のところ不便は無い。まぁ面白半分で買った節があるので、飽きたら普通のLED電球として働いてもらうことになりそう…。 LED電球の寿命は一般的に約10年（40000時間）と言われているが、実際には使用頻度にもよるので前後する。が、仮に5年だとしても9800円で5年働いてくれれば1年あたり2000円しない計算なので十分ペイできるだろう。https://1000ch.net/posts/2016/optimize-image-on-workflow/Tue, 26 Jul 2016 00:00:00 +0000https://1000ch.net/posts/2016/optimize-image-on-workflow/画像の最適化をビルドプロセスでやるのか、コミット前にやるのかという話。 ビルド時の画像の最適化 ビルドプロセスに画像の最適化を行うことはしばしばある。 Gulp や Grunt のプラグインとしては sindresorhus/gulp-imagemin や gruntjs/grunt-contrib-imagemin があったり、追加プラグインのインストールやオプションの設定が面倒な人のために、拙作の gulp-image と grunt-image などもある。その他の CSS や JavaScript といったアセットのビルドと併せて、こうしたツールを実行するのが一般的である。 👍 Pros 最適化し忘れのリスクを防げる 大抵の場合は glob でパス指定してあるはず?だし、少なくとも手作業よりは抜け漏れは少ない 手動で行うという作業の手間が発生しない 👎 Cons 画像それぞれの特徴に併せた細やかな最適化処理を施せない 問答無用に png を 8bit ダウンコンバートしている場合に、透過でフルカラーな png があると　意図せず 劣化する（本来的にはこういった画像を運用上作らない努力をすべきだし、大抵の場合選ばずに済む） 対象の画像が多くなると処理にかかる時間が長くなる ビルドパイプライン的に個別に実施してリリースが出来れば良いが、フルビルドしないというのもそれはそれで（個人的に）微妙 処理にかかる時間が長くなるというのは中々に厄介で、リリース作業の長時間化だけでなくローカル開発時の効率にも関わる問題で、中長期的な生産性に関わる恐れもある（やや大げさかもしれないが）。 バージョン管理時の画像の最適化 他の解決策としては、バージョン管理に含める段階で最適化をしておくというものがある。つまり、 JPEG ・ PNG ・ GIF ・ SVG ・ WebP を処理した上でgit commitして、デプロイ時には行わないというものだ。 👍 Pros ビルド時に最適化処理を行わないのでビルドにかかる時間が短く済む（実際には成果物フォルダへのコピーなどはあるかもしれないが、それでも最適化に比べれば微細である） 軽いファイルを扱うので、 git への負担が少ない（git clone時やgit push時のコストが小さく済む） 👎 Cons 最適化処理の手間が発生する 作業漏れにより、最適化されていないファイルがリリースされてしまう恐れがある ペイロードが大きくなるのでダウンロードに時間がかかる ビットマップを扱うコストが高くなりメモリを圧迫する 一度リリースされてサーバーやクライアントのキャッシュされてしまうとそれらをパージするのは不可能に近いケースも多くある コミットに含まれる画像を git の pre-commit で最適化する バージョン管理する段階で実施すると問題のある程度が解決するので、何か方法はないかと思っていたところ、 git の pre-commit でやったらいいよねという話になる。 pre-commit で画像を最適化するサンプルを編集長が教えてくれたので、それを改変したのがこちら。https://1000ch.net/posts/2016/web-app-manifest/Thu, 23 Jun 2016 00:00:00 +0000https://1000ch.net/posts/2016/web-app-manifest/Web App Manifestは、Webページのメタ情報をJSON形式でフォーマット化したものである。 Web App Manifestのサンプル 次のようなJSONファイルを用意して、<link rel="manifest" href="manigest.json">な感じでHTMLから参照する。<link>で指定するのでルートになくても動きそうだが、ファイルの性質的にルートに置いておきたい気持ちになる。 { "name": "Awesome Example App", "short_name": "Example App", "start_url": "index.html", "icons": [ { "src": "images/icon-144x144.png", "sizes": "144x144", "type": "image/png", "density": "3.0" }], "display": "standalone" } Webページの振る舞いを直接制御する機能は持ちあわせておらず、ブラウザがロードしたときにWeb App Manifestがあるとそれに基づいて機能を補助するような位置付け。 具体的には、AndroidのChromeでWeb App Manifestが配信されているページを複数回訪問すると、バナーが表示されモバイルデスクトップへのインストールを促される。iOS Safariで実装が進んだ時にどのように機能するか不明だが、Progressive Web Appsの流れが進めば近い振る舞いが予想できる。が、Appleの場合はiOSのマーケットの事情もあると思うのでなんとも…。 Web App Manifestに定義されている属性 dir: テキストの向きを表す属性。ltr（左から右）・rtl（右から左）・auto（自動判定）のいずれか lang: 日本語ならja、フランス語ならfrのようにページで使っている言語。値はTags for Identifying Languagesに準ずる name: Webアプリの名前 short_name: Webアプリの名前の短縮形 description: Webアプリの説明 scope: アプリケーションのコンテキストとなるページのURLスコープ。サブディレクトリなどを指定したい場合など icons: WebアプリのアイコンのサイトやURL。詳細を後述 display: Webアプリ起動時の表示モード。fullscreen・standalone・minimal-ui・browserのいずれか orientation: Webアプリ起動時の画面の向き。any・natural・landscape・portrait・portrait-primary・portrait-secondary・landscape-primary・landscape-secondaryのいずれか start_url: Webアプリ起動時のURL theme_color: Webアプリのテーマ色。実装に依ってブラウザUIに適用され、Chromeではアドレスバーに適用される模様 related_applications: 関連するアプリケーションのURL。詳細を後述 prefer_related_applications: related_applicationsで指定された関連するアプリケーションを推奨するか否か。true・falseのいずれか background_color: Webアプリの背景色。起動時のスプラッシュに使われたり、プレースホルダー色になったり icons インストールバナーなどに使われるアイコンを指定する。少なくとも 144x144のPNG がひとつ指定されている必要がある。某アプリでJPGだけをiconsに指定したところ、インストールバナーが表示されなかった。https://1000ch.net/posts/2016/mac-apps/Tue, 21 Jun 2016 00:00:00 +0000https://1000ch.net/posts/2016/mac-apps/実際にはもう少し色々なアプリをインストールしているが、多用しているものだけピックアップしたリスト（自分用）。 テキストエディタ（IDE） Sublime Text: 軽快に動作するテキストエディタ。アイコンがダサいのでt32k/sublime-text-iconに変えている Atom: Sublime Textより痒いところに手が届くが、大きなファイルだと重い Web Storm: やっぱり強力 Markdownエディタ iA Writer: 左右スワイプで表示されるようになったメニューが要らない Caret: 使いやすいしお洒落。バグを報告したらすぐ直してくれた 画像編集系 Filtron: 画像にフィルタをかける ImageAlpha: PNGを8bitにダウンコンバートする ImageOptim: 各種画像を最適化する JPEGmini: JPEG画像を圧縮する Sketch: 個人用途ではこれがあればAdobe系は要らない 開発補助系 Kaleidoscope: ファイル同士の差分をチェック・編集する Tower: Gitのクライアント。diffを見るのに使う ユーティリティ 1Password: 言わずと知れたパスワード管理アプリ。iOS・Chromeの拡張機能と合わせて Alfred: 言わずと知れたランチャーアプリ。Powerpackがあると尚良し AppCleaner: アプリを削除するときに、設定などのゴミファイルも一緒に消してくれる Bartender: メニューバーに常駐するアプリのアイコンをしまっておける BitBar: 任意のスクリプトを定期的に実行し、その結果をメニューバーに表示する Caffeine: オンにするとMacがスリープに入るのを防ぐ LICEcap: スクリーンを録画してGIFアニメにする。アイコンがダサいのでt32k/licecap-iconに変えている PopClip: テキスト選択時にポップアップを表示し、コピーやカットなどのアクションを提供する。Chromeの拡張等とは異なり、Macであればアプリを選ばないのが良い Reeder: RSSリーダー。Feedbinのアカウントを連携して使っているが、FeedlyアカウントやRSSの直登録も可能 Spectacle: アプリのウィンドウサイズをショートカットキーで調整する。個人的にはこれがあればDivvyは要らないhttps://1000ch.net/posts/2016/social-button/Wed, 15 Jun 2016 00:00:00 +0000https://1000ch.net/posts/2016/social-button/世間では久しく聞かなくなったWeb Componentsの話題だが、各種スペックのアップデートは着々と行われている。そんな中、昔作った<social-button>というTwitter・Facebook・Google+のソーシャルボタンのWeb Components実装のShadow DOM部分を、アップデートした。 トランスパイル無しでES2015 ES2015のclass構文で書くWeb Componentsでも書いているように、classシンタックスを使ってリライトしている。ES2015のブラウザサポートも、Safari TPが100%、Chromeがtail call optimisation以外、FirefoxとEdgeも頑張っているのでそろそろ良かろうということで、トランスパイルなしで書くようになってきている（バベるの面倒）。 世間では阿鼻叫喚のWindows 10への強制アップデートを僕は密かに応援していて、アレが進めば進むほどIEがいなくなってくれるので、Microsoftさん頑張ってくれないかなぁと思っている。アップデートを嫌がるエンプラ業界やら世間一般の人、どうしたら説得されてくれるんでしょう。Chrome・Firefox・Safari・Edgeのブラウザ群雄割拠時代になればもっとWebは良くなる気もするので、どうにかなって欲しい。 Web Componentsのアップデート関連 Shadow DOM周りは実装されているが、Custom Elementsに関しては実験的実装にすら至っていないようで、document.registerElement()のままである。Web Componentsに関しては、もうちょっとスペックと実装が揃ったらまとめなおそうかと思う。 それだけ。https://1000ch.net/posts/2016/performance-api/Tue, 14 Jun 2016 00:00:00 +0000https://1000ch.net/posts/2016/performance-api/◯◯ Timing APIはW3CのWeb Performance Working GroupのIlya Grigorikを中心に策定が進められている、ブラウザのパフォーマンスを計測するブラウザAPIである。 User Timing API: 任意のラベルを用いてプログラムの実行にかかったを取得する Navigation Timing API: ブラウザライフサイクルの発生した時間を取得する Resource Timing API: リソースのロードに際して発生した各種時間を取得する Frame Timing API: ブラウザフレームの内訳を取得する Server Timing API: サーバー処理の内訳を取得する High Resolution Time API: 高精度のタイムスタンプを提供する ブラウザのwindowオブジェクトにperformanceというプロパティがあるので、DevToolsを開いてConsoleパネルでwindow.performanceと入力すると、何やら見覚えのあるプロパティに数値が入っているのがわかる。 なかでもFrame TimingとServer Timingは若く、ブラウザに実験的実装はおろかスペックに関する資料も少ない。ここで記載している内容はこれから変わる可能性は高いのでご注意を。 User Timing API User Timing APIは、performance.mark()とperformance.measure()で任意のタイミングのパフォーマンスを計測するAPI。performance.mark()で任意のタイミングにマークをし、performance.measure()でマーク間の差分を取得するような使い方。 以下はXMLHttpRequestによる非同期リクエストのパフォーマンスを計測する例。performance.mark()やperformance.measure()したデータは、performance.getEntriesByType('mark')のように計測タイプを指定して取得可能になっている。 let xhr = new XMLHttpRequest(); xhr.open('GET', '/', true); xhr.onload = e => { performance.mark('mark-xhr-end'); performance.measure('xhr-start-end', 'mark-xhr-start', 'mark-xhr-end'); console.log(performance.getEntriesByType('mark')); console.log(performance.getEntriesByType('measure')); }; performance.mark('mark-xhr-start'); xhr.send(); 以前まではDevToolsのTimelineパネルにこのマークした情報が表示されていたが、53周辺では消えている気がする。Canaryだからかもしれないけど。 Navigation Timing API Navigation Timing APIは、ブラウザのページロード完了までのDOMContentLoadedやloadのようなライフサイクルイベントを取得するAPI。https://1000ch.net/posts/2016/nu-rain/Mon, 06 Jun 2016 00:00:00 +0000https://1000ch.net/posts/2016/nu-rain/またまた Makuake で出資したアイテムで、一振りで水を弾き飛ばすという折り畳み傘。色は黒・青・黄の三色から選べたが、遊び心で黄色を選んでみたら思ったより派手で、ほんの少しだけ後悔した。 元々折り畳み傘を持っていなかったこともあり、これで常備する習慣もつきそう。 こちらも #makuake で出資した「超撥水傘 Nu-Rain」。思ったより派手。 Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 5月 31 7:12午後 PDT 商品が到着してからまだ雨が降っていないので、実際の性能を体感できていないが、これから梅雨時期なのでその威力を遺憾なく発揮してくれるだろう。https://1000ch.net/posts/2016/waterproof-hoodies/Fri, 20 May 2016 00:00:00 +0000https://1000ch.net/posts/2016/waterproof-hoodies/Makuake で出資した「LIFE SPEC WEARを世界に届けたい！第一弾は水を弾くコットンパーカー」というプロジェクトの商品が届いた。 #makuake で興味本位で買った ALL YOURS の「水を弾くコットンパーカー」。 Shogo Sensuiさん(@1000ch)が投稿した写真 - 2016 5月 19 7:53午後 PDT 弾く素材とは言っても洗わずにはいられないので、洗濯機で洗えるのか心配であったが、ちゃんと洗えているようだ。https://1000ch.net/posts/2016/abematv-runtime-perf-audit/Tue, 17 May 2016 00:00:00 +0000https://1000ch.net/posts/2016/abematv-runtime-perf-audit/最近業務で、巷で話題のAbemaTVのパフォーマンス改善をしている。個別具体性が高いが調査改善の雰囲気を感じ取ってもらえればそれで良いかと思い、記事にした。 AbemaTVのフロントエンドの構成 話の前提となるAbemaTVのフロントエンドの構成は次の通りで、まさに流行りのといった感じ。 facebook/react facebook/immutable-js Reactive-Extensions/RxJS reactjs/react-router css-modules/css-modules ビルド周りはbabelとwebpack、あとはlintツールがちょこちょこ入ったりしている。この改善の話と関係してくるのは、ReactとImmutableJSとRxJSだけ。 番組再生画面のコメント開閉が重い 今回ケーススタディとして挙げるのは番組再生画面のコメント開閉機能。 再生されている内容は無視してもらってGIFアニメの通り、右下のコメントアイコンを押してコメントを開閉するアクションがある。FPSが低くてわかりにくいが、クリック後に200ms程遅延した後にようやく右からコメント領域がせり出てくる。会社の高スペックなMacBook Proでこの状態なので、これはマズい。 コメント領域を全て開くまでに200msかかっている クリック後の反応は速いが、アニメーションの最中に何かにつっかかる。コメントを表示して非表示にする一連の処理を、DevToolsのTimelineで計測してみると以下の様な結果が得られた。 見たところスクリプト処理（黄色い部分）がアニメーション処理（紫色の部分）の手前で邪魔をしていることがわかる。200ms全てスクリプト処理に持って行かれているので、FPSは0の状態が続いている。応じて、メモリもピークまで達したあとガクッと低下している。 アニメーション処理そのものの負荷 先程のタイムラインを見てもわかるように、アニメーション処理そのものの負荷は低い。DevToolsのドロワーメニューのRenderingタブに、 Paint Flashing と Layers Borders というメニューがあるので、これらにチェックをすると画面上に緑色の領域（描画処理が発生している領域）と、オレンジ色の枠（レイヤの境界線）が表れる。この状態でコメントの表示・非表示を切り替えてみる。 すると、コメントの領域はオレンジ色の枠で囲まれているだけで、緑色にはなっておらず描画処理は行われていないことがわかる。この時点で、コメント領域は既に描画されているが画面内に入っておらず、アイコンがクリックされたタイミングでアニメーションしながら表示されることがわかる。アニメーションのタイミングでは描画処理が行われていない（というと語弊がありそうだが）ので、GPUでテクスチャ化されているものが動いているだけということもわかる。 CSSを確認してみると、以下のようになっていた。 .right-slide-base { height: 100%; overflow: hidden; position: fixed; right: 0; top: 0; transform: translateX(100%); transition: transform var(--duration) var(--ease-out-cubic); z-index: var(--z-footer); } .right-comment-area { composes: right-slide-base; background-color: var(--lt-bg-regular); width: 310px; } .right-slide--shown { transform: translateX(0); } 予想通り、クリック時.right-slide--shownを付け外すことでtransformX(n)で表示状態を切り替えている。これならば.right-comment-areaが適用されている要素が変化しビットマップが更新されない限り、アニメーションによる再描画は発生しない。コメント表示は、機能としてポーリングで新しいコメントをロードするようになっているので、GPUに再度送っちゃう問題が起こりそうだが、一旦置いておく。 開閉に伴うスクリプト処理 クリック時のスクリプト処理を抜粋。 showCommentList(toShow = true) { this.closeAll(); this.showElement(this.refs.commentList, toShow); if (!https://1000ch.net/posts/2016/intersection-observer-lazyload/Sun, 15 May 2016 00:00:00 +0000https://1000ch.net/posts/2016/intersection-observer-lazyload/画像をスクロール同期でロードする<lazyload-image>というWeb Componentsの内部処理を、IntersectionObserverで書き直した。 可視領域に要素が入っているかどうかの判定 リライトする前までは、要素それぞれにscrollイベントのリスナを発行して、その中で画面内に要素が表れているかを判定していた。throttleしているとはいえ、それぞれのリスナで以下の処理を行っていたのでややパフォーマンスが気になっていた。 getBoundingClientRect()で要素の矩形を取得する document.documentElement.scrollTopとdocument.documentElement.clientHeightで画面の上下端を取得する 要素が可視領域と交差しているかどうかを判定し、交差していたらオリジナルの画像パスをsrcに指定する 気になるとは言え、こんな感じの判定処理をどこかしらでやらざるを得ないはずで、ネイティブで実装されたIntersectionObserverもブラウザの内部処理は近いことをやっているのではとは思う。 IntersectionObserverとは IntersectionObserverは要素同士の交差状態の監視を可能にするAPI draftである。 function intersectionChanged(changes) { for (let change of changes) { console.log(change.time); // 変更が起こったタイムスタンプ console.log(change.rootBounds); // ルートとなる領域 console.log(change.boundingClientRect); // ターゲットの矩形 console.log(change.intersectionRect); // ルートとガーゲットの交差町域 console.log(change.intersectionRatio); // 交差領域がターゲットの矩形に占める割合 console.log(change.target); // ターゲットとなるウピsp } } let observer = new IntersectionObserver(intersectionChanged); observer.observe(document.querySelector('#target')); ルートはIntersectionObserverのコンストラクタの第二引数のオプションのroot属性で指定可能で、省略するとブラウザのビューポートとの交差判定が行われる。これがあれば、scrollイベントを監視して要素同士の重なり具合を地道に判定して…ということがなくなる。やったね！ パフォーマンスに関して言えば、スクロールイベントの大量発行以上にgetBoundingClientRect()の実行やdocument.documentElement.scrollTopとdocument.documentElement.clientHeightへのアクセスのほうが気になっていたので、これがなくなるのは大変良い。 <lazyload-image>のブラウザ互換性 IntersectionObserverは現時点でChromeにしか実装されていない。リリースノート的にはChromeは51かららしいけど、手元のv50.0.2661.102には入ってるように見える。Operaはバージョン38からだそう。 <lazyload-image>ではこれに加えて、Web Components関連のAPIを使いまくっているので、動作保証範囲は広くない。が、それはスクロール同期で画像を読み込む機能に関しての話で、未実装ブラウザに関しては通常通り画像を読み込むようにフォールバックするので、それなりに動くのではと思われる。 実際の動作状態はデモページで確認できる。普通にスクロールすると画像のロードが高速なときにスクロール同期でロードしているかどうかがわかりにくいので、DevToolsを開いた状態で見てもらえるとわかりやすい。https://1000ch.net/posts/2016/service-worker-message/Fri, 13 May 2016 00:00:00 +0000https://1000ch.net/posts/2016/service-worker-message/Service Workerでハンドルするリソースは、Service Workerのスクリプトに静的に記述しているケースが多い。Service Workerでやっているアレコレをメッセージングで動的にできないか試行錯誤したログ。 よくある?キャッシュパターン チュートリアル等でもよく見かける、Service Workerのインストール時に指定のリソースをキャッシュしているパターン。 const CACHE_KEY = 'cache-key'; const CACHE_LIST = [ 'index.html', 'app.js', 'app.css' ]; self.addEventListener('install', e => { // CACHE_KEYをキーにとるCacheオブジェクトを開いて // CACHE_LISTをキャッシュするPromise let promise = caches.open(CACHE_KEY) .then(cache => cache.addAll(CACHE_LIST)) .catch(error => console.log(error)); e.waitUntil(promise); }); 小さい用途であれば、これで何ら問題はない気はする。開発規模が大きくなってくるとリソースの増加やらで人力でメンテナンスするのが辛くなってくる。 GoogleChrome/sw-precacheはService Workerのスクリプトを書き出すツールで、キャッシュしたいパスのパターン指定などが可能。これでひとまず人力で管理していくリスクは低減できるが、細かい処理を書くには不向き。なので、Service Workerの処理内容を自由に書く余地を残しつつ、何をキャッシュするかを動的にできないかを模索したところ、手段の1つとしてメッセージングを使う方法が浮かんだ。 fetchイベントでリクエスト内容を見て動的に判断するなどはできるが、後述の Service Workerが最長24時間更新されない問題 などもあるので、コントロール手段のひとつとして覚えておくのは良さ気。 メッセージングでService Workerのコントロール Service WorkerはJavaScript Workerのひとつ。なので、ブラウザスレッドとService Workerとでメッセージのやり取りが可能。Cache APIもPromiseな設計なので、e.waitUntil()もあることだし処理はPromiseで書くと良さ気。 // browser.js function sendMessage(message) { return new Promise((resolve, reject) => { const channel = new MessageChannel(); channel.https://1000ch.net/posts/2016/color-picker/Mon, 02 May 2016 00:00:00 +0000https://1000ch.net/posts/2016/color-picker/D3.jsの素振りをしていて、何か練習台になるものはと探していたらA Simple Web Developer’s Guide To ColorでDribbbleやらDesignspirationにあるようなカラーピッカーが紹介されていたので、真似てColor Pickerを実装した。機能としては、予め用意してある色がパレットのように陳列されていて、クリックするとそのカラーコードをコピー出来るという単純なもの。ある程度整頓された色の中から選んで使いたいことは多々あったので、その個人的な問題はコレで解決できそう。 クリックでコピーできる機能についてはclipboard.jsを使っているのでFlashに依存していない代わりに、execCommandがアレなSafariではコピーは機能しない。 D3.js雑感 少ししか触っていないけど、以下雑感。 D3.jsはデータに応じたDOM操作を担うライブラリでありデータビジュアライズ専用のライブラリではない 結果的にSVGとの相性が良いがそれはビジュアライゼーションでの話であって、HTMLにももちろん活用できる 提供しているAPIはjQueryに似ているが、Selectionsの概念は通じないものがある データに応じる柔軟なビジュアライゼーションをするべきであり、プログラム（アルゴリズム）力が要求される（普段のWebフロントエンド開発では使わない頭を使った気がする…） 作者や有志によるチュートリアルやD3.jsを使ったギャラリーがとても良く出来ている かなり綺麗に抽象化されたAPIだが、あくまでデータとDOMの仲介者。↑のようなのを描くにはSVGの知識もある程度必要 次のコードはコアAPIの簡単な使い方。 const svg = d3.select('body') // bodyを参照する .append('svg') // svgをappend()し、参照する .attr('width', '100vw') // widthに100vwを指定する .attr('height', '100vh'); // heightに100vhを指定する const rects = svg.selectAll('rect') // svg要素下のrectを参照するが、この時点では何もない .data([10, 20, 30, 40, 50]) // selectAll()によるセレクションに対してデータをバインドする .enter() // セレクションにバインドしたデータの数だけプレースホルダーを作る .append('rect') // プレースホルダーにrectをappend()する .attr('width', d => d) // バインドしたデータのひとつひとつをwidthに指定する .attr('height', d => d) // バインドしたデータのひとつひとつをheightに指定する .attr('x', (d, i) => 100 * i) // 第2引数にはインデックスが返るので、これを使ってx座標は100ずつずらす .https://1000ch.net/posts/2016/recommend-books/Fri, 01 Apr 2016 00:00:00 +0000https://1000ch.net/posts/2016/recommend-books/タイトルがなんか釣りっぽい。特定のWeb技術に関する本ではなく、Web開発に関わるあらゆる職域の人が読むべきと僕が考えている5冊を挙げてみる。結果的に鉄板の5冊に着地している。 表題にはデザイン・マネジメント・ハッカー・パフォーマンスというワードが並んでいる。トピックが散らかっているようにも見えるけどWebに従事する以上横断的な知識は備えているべきで、「エンジニアだからデザインの知識は…」や「デザイナーだからWebパフォーマンスの知識は…」というのは怠慢だと思っている。…と言っても、別に皆がフルスタックになるべきと言いたいわけではなく、隣の職能を理解する努力は自分の職能を理解するためにも必要という話。 誰のためのデザイン ― 認知科学者のデザイン原論 自分はデザイナーに分類されるスキルは持ち合わせていない。が、Webの仕事に3年程従事する中で、開発やモノづくりのプロセスについて考える機会がそれなりにある。 D. A. ノーマン (著), 岡本明 (翻訳), 安村通晃 (翻訳), 伊賀聡一郎 (翻訳), 野島久雄 (翻訳) How Google Works ― 私たちの働き方とマネジメント Googleが世界一の企業になるまでに、どのような成長過程を辿ったかが綴られている。ラリー・ペイジ（共同創業者）とセルゲイ・ブリン（共同創業者）を始めとした人物が、何に重きを置き重要であると考えてきたか。 エリック・シュミット (著), ジョナサン・ローゼンバーグ (著), アラン・イーグル (著), ラリー・ペイジ (その他), 土方 奈美 (翻訳) ハッカーと画家 コンピュータ時代の創造者たち 自分がエンジニアだから面白いのかもしれないけど、ソフトウェア・エンジニアリングに対する考え方はこれで大きく変わった。あと「ものつくりのセンス」という章もオススメである。 ポール グレアム (著), Paul Graham (原著), 川合 史朗 (翻訳) 続・ハイパフォーマンスWebサイト 2010年4月に発行された本ということで各セオリーは変わりつつあるが、Webのパフォーマンスの最適化原則を満遍なく得るには良い本である。ビジネスゴールに向かう過程でWebパフォーマンスは未だに軽視されがちだが、速いWebが正義であることは数々の研究調査結果にも表れているし、Chromeがシェアを伸ばしてきた根底にはコレがある。 Steve Souders (著), 武舎 広幸 (翻訳), 福地 太郎 (翻訳), 武舎 るみ (翻訳) リーン・スタートアップ 「金持ち父さん貧乏父さん」を挙げようとしたらもはやWeb開発と関係なくなってるので、起動を戻して最近読んだ本を紹介。スタートアップという言葉が使われているけど、スタートアップベンチャーに限った話ではなく、モノづくりのプロセスであれば充てがえる話。 PDCAを最大限小さく回す。効果検証を適切に行う。顧客と価値の模索。 エリック・リース (著), 伊藤 穣一(MITメディアラボ所長) (解説), 井口 耕二 (翻訳)https://1000ch.net/posts/2016/pinfeed-for-pinboard/Mon, 28 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/pinfeed-for-pinboard/趣味で作っていたiOSアプリが完成したので、AppStoreで公開した。PinFeedという名前でお察しの通り、Pinboardのラッパーアプリ。巷のPinboardアプリだとPinnerあたりがデファクトかもしれないけど、使い心地にそこまで満足してなかったのと、Macアプリを作った延長でSwiftの勉強をまたやろうということで作った。 最新のリリースバージョンはv1.0.1だが、初回申請時は思っていたより面倒くさいこと続きだった。特にキャプチャを画面サイズ毎に用意しなくてはならず、シミュレータを切り替えてはキャプチャをとって、Sketchでサイズを調整を繰り返した。もうやりたくない。けど、UI変えたらやらなきゃいけない。 申請してからIn Reviewになるまで丸1週間かかったが、レビューに入ってからはたった20分で通過した。趣味のアプリなので、自分（ユーザー）にとっての使いやすさを追求していく作業を自由に出来るのはそれなりに楽しい。https://1000ch.net/posts/2016/dyson-v6-fluffy/Sat, 26 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/dyson-v6-fluffy/今まで床の掃除をクイックルワイパーで運用していたが、表参道のdysonで圧倒的なデモンストレーションを見せつけられて、まんまと購入。 仕様 本体重量は2.34kg。軽くはないけど、重くもない。コードレスクリーナーに分類される掃除機であればこの程度の重さなんだろうか。 稼働は連続約20分に対してフル充電に3時間半程かかるが、広い家全部を一気に掃除する等でなければ掃除に20分間もかからない。 あと、Dyson V6 Fluffyにはメインのヘッドに加えて、ミニモーターヘッドとコンビネーションノズルと隙間ノズルのヘッドが付いてくるので、用途に応じてヘッドを変えれる。 dysonはヘッドの別売りをしていない ので、モデル毎にどういうヘッドが付いてくるのかを確認したほうが良い。 詳細なスペックは公式サイトを確認のこと。 感想 憧れのdysonということで吸引力も然ることながら、デザインもお洒落で気に入っている。見た目がかっこ良くないと使う気が起きない自分にとっては結構重要な要素である。 安い買い物ではないけど、数回の使用で既に値段分の対価は得られている実感がある。ドラム式洗濯乾燥機を買った時も思ったけど、文明の利器に頼るのも中々良いものだ。物理で殴るとはたぶんこういうことだろう。 本体サイズ:W250 x D1211 x H208mm[バッテリー、パイプ、クリーナーヘッド含む]。製品重量:2.34kg。使用時間:20分間[モーター駆動のヘッドで16分間、強モードで6分間の使用が可能。]。メーカー保証:2年間。付属品:ソフトローラークリーナーヘッド、ミニモーターヘッド、コンビネーションノズル、隙間ノズル、充電器、収納用ブラケットhttps://1000ch.net/posts/2016/qcy-qy8/Thu, 24 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/qcy-qy8/このスペックでこの価格はどうなのと若干疑いつつ、ポチってみたらとても良かった。 Bluetooth 4.1 マイク内蔵 ノイズキャンセリング − 防水 / 防汗 ヘッドホンはParrot Zik2.0を使っているが、ランニング時に使うには重いのでこちらを購入。軽いし、Bluetoothの性能も充分だし、イヤホン部のフィット感もまずまず（ランニング時にはまだ試していない）。 音周りも不満はない。流石にParrot Zik2.0と比べると劣る気がするけど、このワイヤレスイヤホンで余程音質にこだわる利用シーンも浮かばないので、大半の人は大丈夫だと思われる。https://1000ch.net/posts/2016/flexbox-grid/Wed, 16 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/flexbox-grid/GrdというFlexboxを使ったCSSグリッドフレームワークを使った。Flexboxで実装しているグリッドフレームワークは既にたくさんあるし、何かに困ったからというわけでもなく、 もし自分が実装したらどうなるかなー くらいのノリで作った。 将来的にはdisplay: grid;があったりするけど、多機能な分、使い方が少し複雑である。なので、これはこれで需要があるかもしれないし、ないかもしれない。使い方は1000ch/grdのREADMEを参照のこと。 セレクタの命名規則の経緯（余談） しばし悩んだが、最終的に-modifierというハイフン1つをプレフィックスにした命名に落ち着いた。modifierと言うだけでBEM感が出るの、どうしようもない。 --modifier BEMの影響で --で始まるセレクタをmodifierと理解しやすい というのが一番の理由で、開発当初はこれだった。スペック的にはダメだがモダンブラウザ達は--で始まってても一応解釈してくれるので、これでもいいかみたいな。が、カスタムプロパティ周りとバッティングしても微妙かと思い直し、再考し始める。 Class--modifier BEMの影響で一般的にすらなりつつある(?)、ベースクラスをプレフィックスとしてハイフン2つで繋ぐスタイル。 <div class="Grid Grid--left"> <div class="Cell Cell--2of12"></div> <div class="Cell Cell--2of12"></div> <div class="Cell Cell--8of12"></div> </div> ベースクラスがどれかを容易に連想できてわかりやすいが、少し冗長かなという。 あとは、Grid--leftやCell--8of12のように単一クラスで成立するようにするアイデアもある。最初はこれは一番シンプルかと思っていたが、共有するスタイルが全てのベースクラスに書かれるので無駄が多い。どちらにも対応可能なように基底となるルール群は:rootにルールを切り出して、postcss-applyで変換するようにしている。 CSS @apply Ruleが現実味を帯びれば、PostCSSナシで出来るようになってとても良い。もし帯びれば、の話だが。 modifier グリッド上のセルを右寄せにする--rightというmodifierがあるが、これをrightと書くのは流石に攻め過ぎかなと自重した。あるいはpull-rightのようにルールセットの意図をより表現するセレクタにする案もあるが、冗長になりそう+綺麗な命名が浮かばなかったのでボツになった。 __modifier BEMの影響で要素感が凄くてボツになった。スペック的にも問題ないし、エディタ上でダブルクリックして選択できるし、案外良い気がしているが。 -modifier modifierぽさが無くなっている気もするけど、これは個人の感想というかBEMの認知度に左右される話だし、プロジェクトのクラスと上書きし合う可能性も低いはずだし、出たアイデアの中で違和感が最も少なかったのでこれに着地した。https://1000ch.net/posts/2016/display-grid/Sat, 12 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/display-grid/CSSによるレイアウトの問題はFlexboxでほとんどが解決されたと言って良いが、複雑なグリッドレイアウトを実現するためにCSS Grid Layout Moduleの策定が進められている。display: grid;ないしdisplay: inline-grid;といったように、displayプロパティに値が追加されており、それらが指定された要素はブロック要素またはインライン要素のように振る舞い、内包されるコンテンツがグリッドモデルに従ってレイアウトされる。 Chromeは50から、Firefoxは46から対応しているが、Chromeは現安定バージョンの49でもchrome://flags/でExperimental Web Platform featuresを有効にすれば使える。 そんなdisplay: grid;について調べたメモ。 大まかな構造 display: grid;によって定義されるグリッド要素と、その子要素として配置されるセルから構成する。例えば、よくあるヘッダー・フッター・メインコンテンツ・サイドカラムがあるページ構造を作るとすると、次のようなHTMLとCSSになる。 <main> <header>Header</header> <article>Article</article> <aside>Aside</aside> <footer>Footer</footer> </main> main { display: grid; grid-template-rows: 50px 1fr 50px; grid-template-columns: 100px 1fr; } header { grid-row: 1 / 2; grid-column: 1 / 3; } aside { grid-row: 2 / 3; grid-column: 1 / 2; } article { grid-row: 2 / 3; grid-column: 2 / 3; } footer { grid-row: 3 / 4; grid-column: 1 / 3; } See the Pen display: grid; by 1000ch (@1000ch) on CodePen.https://1000ch.net/posts/2016/swift-async-dispatcher/Wed, 09 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/swift-async-dispatcher/iOSではネットワークを介するような処理は非同期で実行するように書かないと、メインスレッドを専有されて描画処理が大変なことになる。例えば以下の様に画像をNSURL → NSData経由で取得するケース。 if let imageURL = NSURL(string: "https://1000ch.net/img/1000ch.png") { if let imageData = NSData(contentsOfURL: imageURL) { imageView?.image = UIImage(data: imageData) } } こういうのをTableViewのdelegateあたりで実行していると逐次実行されてまともにスクロールできない。ので、別スレッドで実行して良きタイミングでメインスレッドにdispatchする必要がでてくるが、生でdispatch_async()を駆使するとややコードが汚い。そんな時のために簡易的なヘルパー関数を2つ用意した。 import Foundation class AsyncDispatcher { static func main(closure: () -> ()) { dispatch_async(dispatch_get_main_queue(), closure) } static func global(closure: () -> ()) { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), closure) } } これを使って先程の処理を非同期にすると、（NSURLSessionを使う云々はさておき）以下のように記述できる。 if let imageURL = NSURL(string: "https://1000ch.net/img/1000ch.png") { AsyncDispatcher.global { if let imageData = NSData(contentsOfURL: imageURL) { AsyncDispatcher.main { imageView?https://1000ch.net/posts/2016/the-design-of-everyday-things/Wed, 02 Mar 2016 00:00:00 +0000https://1000ch.net/posts/2016/the-design-of-everyday-things/デザインという言葉はとても広義だが、この本に語られてることこそがデザインに他ならないだよなという感想。デザインとアートの区別が付かない人・区別を付けたい人にオススメな本。 Design is not just what it looks like and feels like. Design is how it works. "Design is not just what it looks like and feels like. Design is how it works." Happy 60th birthday Steve Jobs! pic.twitter.com/leqWlaeLAh — CloudMagic (@CloudMagic) 2015年2月24日 Kindle版〜。 D. A. ノーマン (著), 岡本明 (翻訳), 安村通晃 (翻訳), 伊賀聡一郎 (翻訳), 野島久雄 (翻訳)https://1000ch.net/posts/2016/web-components-es2015-class/Sun, 28 Feb 2016 00:00:00 +0000https://1000ch.net/posts/2016/web-components-es2015-class/これまでのボイラープレート 指定したオブジェクトのプロパティを持たせるべく、Object.create()でオブジェクトで生成し、そこにCustom Elementsのライフサイクル関数（createdCallback・attachedCallback・detachedCallback・attributeChangedCallback）を生やしたり、永続的なプロパティを定義したりしている。 <template> ... </template> <script> window.SampleComponent = (function () { 'use strict'; let ownerDocument = document.currentScript.ownerDocument; let SampleComponentPrototype = Object.create(HTMLElement.prototype); Object.defineProperty(SampleComponentPrototype, 'attr', { configurable: true, enumerable: true, get: function () { return this.getAttribute('attr'); }, set: function(value) { this.setAttribute('attr', value); } }); SampleComponentPrototype.createdCallback = function () { let template = ownerDocument.querySelector('template'); let clone = document.importNode(template.content, true); this.createShadowRoot(); this.shadowRoot.appendChild(clone); }; return document.registerElement('sample-component', { prototype: SampleComponentPrototype }); })(); </script> これからのボイラープレート class構文を使ってよりわかりやすくしたのがこちら。プロトタイプになるオブジェクトにライフサイクル関数を都度生やすよりスマートに見える。https://1000ch.net/posts/2016/iframe-content-size/Fri, 19 Feb 2016 00:00:00 +0000https://1000ch.net/posts/2016/iframe-content-size/前提として <iframe>を記述するHTMLドキュメントは外部のモノで触ることは出来ない <iframe>でロードするリソースはこちらの支配下にある である。Twitterがembed機能を提供しているが、そのTwitter側を想定した話だと思ってもらえると良い。 <iframe>でロードされるリソースが<iframe>の高さを決定出来ない <iframe>の高さは<iframe>を埋め込んでいるHTMLドキュメント側が決定する。HTMLドキュメントの高さはdocument.documentElement.scrollHeightで取得できるが、コンテナ側から<iframe>のsrcに指定されたHTMLドキュメントを参照することが出来ない。HTMLドキュメントを参照する手段自体は<iframe>のcontentWindowを通じてiframe.contentWindow.document.documentElementのようにアクセス出来るが、ロードしているリソースがドメインを跨いでいると例外が発生して出来ない。 postMessage()で高さをやり取りする 色々読み漁ったが、今のところwindowオブジェクトのpostMessage()を使うのが正攻法っぽい。以下のように<iframe>でロードしているコンテンツ側からコンテナにメッセージを投げることが出来る。 // iframeでロードされていないケースを考慮し、window.parentの存在をチェックする if (window.parent) { let height = document.documentElement.scrollHeight; window.parent.postMessage(height); } 実際には、複数の<iframe>がロードされている可能性があるので、どの<iframe>とやりとりしているかを管理する必要がある。自分の場合は、まずコンテナ側で<iframe>に割り当てた#idを<iframe>でロードしているHTMLドキュメントにpostMessage()で送って、onmessageのハンドラ内でコンテンツの高さを送られた#idとともにコンテナ側にpostMessage()で返答するというやり方をとった。 コンテナ側のJavaScript window.onmessage = function(e) { let json = JSON.parse(e.data); document.querySelector(`#${json.id}`).style.height = `${json.height}px`; }; let iframes = document.querySelectorAll('iframe'); for (let iframe of iframes) { iframe.contentWindow.postMessage(iframe.id); } <iframe>のonloadハンドラでメッセージを送るようにして、srcは後程設定するような実装だと◎。 <iframe>でロードされたHTMLドキュメント側のJavaScript window.onmessage = function(e) { let json = { id: e.data, height: document.documentElement.scrollHeight }; window.parent.postMessage(JSON.stringify(json)); }; <iframe>でロードするページが非同期描画しているケースは、それを待たないと正確なコンテンツ高を取得出来ない。描画完了をイベントでハンドリングできればいいが、場合によってはタイマーを使うことにもなりそう…。この辺を上手くやっているライブラリとしてdavidjbradshaw/iframe-resizerというものがあるそう（自分は使ってない）。 スペックないのか iframe要素にはseamlessという属性が定義されているが、ブラウザのサポートが進んでいなかったこともあり、WHATWG側からは先日削除されている。 しかし、この流れを受けてか新たな提案もなされている。 iframe { height: max-content;https://1000ch.net/posts/2016/wdpress-frontend-series-pwa/Wed, 10 Feb 2016 00:00:00 +0000https://1000ch.net/posts/2016/wdpress-frontend-series-pwa/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.91が2月24日に発売されます！連載最終回は、Chrome Dev Summit 2015でも取り上げられ話題になったProgressive Web Appsについて。 さて、@ahomuさんと@1000chさんによる「Webフロントエンド最前線」は今回で最終回。プッシュ通知をはじめとするネイティブアプリのような体験を備えた「Progressive Web Apps」を作るためのさまざまな技術についてまとめていただきました！ #wdpress — WEB+DB PRESS編集部 (@wdpress) 2016年2月24日 WebページからWebアプリケーションを経てその先へ Progressive Web Appsとは一体何なのかについては、既に日本語の記事もいくつかあり、去年末に自分もざっくりまとめている。そもそもの起源はAlex Russell氏がブログで提唱したのが発端で、端的に言えば 「（進化してきた）技術を使って、ネイティブアプリにも劣らない、そしてWebの特徴も活かしたWebアプリを作っていこう」 というもの。 プッシュ通知やパフォーマンスといった利点からネイティブアプリの土俵だったモバイルアプリ界隈だが、GoogleやAppleのプラットフォームに依存、ネイティブアプリの一元化できない開発コストなど、様々な課題もあった。一方でWeb元来のメリットもあることだし、ネイティブでできていたことがWebでも実現できればもっと良くなるのでは？というのがメッセージに含まれている。 そんなProgressive Web Appsを詳細に取り扱っています。Webフロントエンド最前線は今回で最終回ということで、これからのWebを占うラストを飾るに相応しい内容だったのではと思います。 丸山 晋平 (著), 清水 雅人 (著), 舘野 祐一 (著), 小野 将之 (著), 佐藤 歩 (著), 泉水 翔吾 (著), 伊藤 直也 (著), 佐藤 太一 (著), 海野 弘成 (著), 福本 貴之 (著), うさみ けんた (著), 西尾 泰和 (著), 中島 聡 (著), はまちや2 (著), 竹原 (著), WEB+DB PRESS編集部 (編集) よろしくお願いします(´・ω・`)https://1000ch.net/posts/2016/the-lean-startup/Fri, 05 Feb 2016 00:00:00 +0000https://1000ch.net/posts/2016/the-lean-startup/リーン・スタートアップという本の読書感想文。 LEAN の付くサービス開発や企業経営に関する本は数多にあるが、中でも評判の良さそうな一冊を選んだ。 エリック・リース (著), 伊藤 穣一(MITメディアラボ所長) (解説), 井口 耕二 (翻訳) シリコンバレー発 注目のマネジメント手法 リーン・スタートアップとは、新しい製品やサービスを開発する際に、作り手の思い込みによって 顧客にとって価値のないものを作ってしまうことに伴う、時間、労力、資源、情熱のムダをなくし、 時代が求める製品・サービスを、より早く生みだし続けるための方法論です。 リーン・スタートアップという言葉とそれが示す行動方針は、スタートアップ界隈のみならず色々な開発現場で導入されつつある。導入事例として有名なのはクックパッドあたりだろう。リーン・スタートアップの重要なエッセンスのひとつに「仮説と検証」があるが、A/Bテストのフレームワークも自社開発するなど、成功事例の1つとして挙げられるだろう。 スタートアップということでスモールチームに充てがわれる言葉に聞こえるが、チームの大きさに関わらないプロセスだし、チームのリーダー層だけでなくモノづくりに関わる全ての人が読める本。 「リーン・スタートアップが一体どういったものなのか」がこの本に凝縮されているわけだが、ストーリーを交えていることもありやや冗長（400P超）なので、読んでられないという人は以下のスライドでも要点はわかりそう。 10分でわかったつもりになるlean start up ~リーンスタートアップって何ですか？~ from 圭 進藤 僕自身はスタートアップを率いたわけではないし、プロダクトの先頭に立って成功を収めたこともないけど、検証で示されるデータに納得の元で進める開発をしたいとは思ってる。 長年、開発とか仕事とかどういうときに幸せでどういうときに辛いのかと考えてきたが、答えは「納得できてるかどうか」だなと結論づけた。環境の善し悪し、好きか嫌いか、興味あるかないか、技術的にどうこうではなく、やることに納得がいってるかどうか。それさえあれば何であろうと前向きに取り組める — Naoya Ito (@naoya_ito) 2016, 1月 15 これに尽きる（文脈は違うかもしれないけど）。https://1000ch.net/posts/2016/og-card-simulator/Fri, 29 Jan 2016 00:00:00 +0000https://1000ch.net/posts/2016/og-card-simulator/オープングラフのデータを取得して表示する機能は、FacebookやらTwitter、Google+では当たり前のようにある機能だが、業務上必要になったので調査して、ツールを作った話。 文字列や画像のURLといった表示させたいデータを<meta>や<link>で記述するのは御存知の通りだが、HTMLにどのように記述するかは各プラットフォーム毎に定義がなされている。FacebookであればOpen Graph、TwitterであればTwitter Cardsといった名前が付いている。 <!-- Open Graph --> <meta property="og:title" content="The Rock"> <meta property="og:type" content="video.movie"> <meta property="og:url" content="http://www.imdb.com/title/tt0117500/"> <meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg"> <!-- Twitter Cards --> <meta name="twitter:card" content=""> <meta name="twitter:site" content=""> <meta name="twitter:url" content=""> <meta name="twitter:title" content=""> <meta name="twitter:description" content=""> <meta name="twitter:image" content=""> これだけではなく、Googleの検索結果からネイティブアプリを起動させたい場合はApp Indexingの対応が必要だったり、iOSはカスタムのURLスキーマを使う必要があったりと、かなり複雑で様々な対応が必要になる。これについてはネイティブ・ソーシャル時代にWeb・アプリでやっておくべきことまとめ (ネイティブSEO)に詳しくまとまっているので読んでもらうとして、今回はOpen GraphやTwitter Cardsに記述されているデータを取得してカードに表示する実装をした。 ブラウザからはcors制限で取得できない 特定のURLのHTMLを閲覧しているページコンテキストから取得できれば、Open Graphのタグなどを参照できるが、corsの制限でHTMLを得ることが出来ないことが多い（ほとんど？）。なのでまずは、Node.jsのプログラムからリクエストしてHTMLを取得してくることを試みる。 プログラム自体は難しいものではなく、1000/rogのような実装になった。 const rog = require('rog'); rog('http://google.com').then(data => { console.log(data.title); console.log(data.type); console.log(data.url); console.log(data.image); console.log(data.site); console.log(data.description); console.log(data.locale); }).catch(error => { console.error(error); }); この例でいうdata.https://1000ch.net/posts/2016/markdown-mac-app/Tue, 12 Jan 2016 00:00:00 +0000https://1000ch.net/posts/2016/markdown-mac-app/ブラウザ上にも便利なMarkdownエディタは幾つかあるが、ブラウザのヒストリーバック時に消えたりパフォーマンスもあまりよくなかったり等の理由で、実際には手元の専用アプリで書いていることが多い。 Mac用のMarkdownエディタも沢山あって、自分もいくつか試してきたのでそれをメモがてら紹介する。 iA Writer Version 3から機能が多数追加され、左右スワイプでドキュメントライブラリメニューとHTMLプレビューが出るようになった。個人的には余計な機能で、縦にスクロールしたいときにも反応したりするので、シンプルなVersion 2の方が良かった。 MacDown 開発停止中となっているMouの影響を受けた後発のMacアプリがMacDown。GitHub上でオープンソースとして開発されている。 表示が左右2ペインになっており、左ペインが編集エリア、その描画結果が右ペインに表示される。編集モードの設定や、フォントやカラーテーマ、プレビュー部分のスタイルなどもカスタマイズ可能になっている。 Whiskey Nothing MagicalというSam Soffes氏によるプロジェクトが開発している。Beta版であることもあり機能は少なめだが、シンプルで使いやすい。 Caret Antonio Stoilkov氏とEmanuil Rusev氏によるプロジェクト。プリオーダー時は$5だったが、今は$10でライセンスを購入できる模様。 見た目も機能も一番バランスが良いが、Undo (⌘ + Z)がバグっており、今のところ使い物にならない。Version 2から修正されることを期待したい。 Focused 通常の編集機能に加えて、タイプライターモードとフォーカスモードという2つの編集モードや、シェア機能、BGM再生などを備えている。ライセンスは$31で購入可能。 typora こちらもシンプルで使いやすい。特徴的なのは編集機能とプレビュー機能が同居している点で、マークダウンの文法で編集が行われるとそのままプレビュー結果として表示されていく（言葉で説明し難い）。自分はマークダウンはマークダウンとして編集したい派だが、この使い心地が好みの人もいそう。https://1000ch.net/posts/2016/chromeos-developer-mode/Sat, 02 Jan 2016 00:00:00 +0000https://1000ch.net/posts/2016/chromeos-developer-mode/Chromebookを去年の10月に購入したが、主にHulu観賞にしか使っていなかったので、もう少しアレコレカスタマイズしてみることにした。 Chrome OSはWebに特化したオペレーティング・システムで、全てのアプリケーションはChrome（Chromiumプラットフォーム）で実行される。そのため、ベースカーネルはGentoo（Linux）だが、システム部分へのアクセスが制限されている。ターミナルもcroshというブラウザから実行するディベロッパーシェルがあるものの、やりたいこと（いわゆるNode.jsのインストールとかそういうの）がほとんどできない。 今回はChrome OSをDeveloper Modeで起動する手順を紹介する。試してみる時は自己責任でどうぞ。 Developer Modeの有効化 まずはシステムbashをフルで使うために、Chrome OSをDeveloper Modeにする必要がある。手順的にはDeveloper Mode - The Chromium ProjectsとHow to Enable Developer Mode on Your Chromebook - How-To Geekの2つが参考になるが、もっと端的に見たい人のために日本語で箇条書きにする。 Escape+Refresh+Powerを押す。すると、リカバリモードで再起動する “Chrome OS is missing or damaged.“というメッセージが表示されるが、気にしないでOK。この画面で、Control+Dを押す “To turn OS Verification OFF"という確認メッセージが表示される。ディベロッパーモードが有効化されるとシステム部分を更新できてしまうので、それでもいいの？という確認だが、Enterを押すとそのままディベロッパーモードでの再起動が始まる。ローカルデータも消去されるが、自分の場合はGoogleアカウントベースで同期している情報がほとんどなのでそのままOKした “OS verification is OFF"という表示がされ、あとは自動的にディベロッパーモードでの再起動が行われる 自分のGoogleアカウントでログインする ターミナル Chromeを起動してControl+Alt+Tを押すと、新しいタブでcroshというディベロッパーシェルが起動する。ここでshellというコマンドを実行すると、Chrome OS内部までアクセスできるbashが起動する。https://1000ch.net/posts/2015/bought-in-2015/Fri, 25 Dec 2015 00:00:00 +0000https://1000ch.net/posts/2015/bought-in-2015/個別で記事を書いているものもあるが、改めて紹介。 PHILIPS ソニッケアーで快適歯磨き生活 BOSE SoundLink Mini ドラム式洗濯乾燥機「プチドラム」で快適洗濯生活 ドラム式洗濯乾燥機「プチドラム」 これはとても良い買い物だった。これのおかげで、雨の日も風の日もなんのその、干し忘れの生乾き臭に悩むことが無くなった。洗濯機の買い替えを考えている人は、是非御検討を。 BOSE SoundLink Mini @t32k 氏に触発されて買ったミニスピーカー。小さいけどパワーあるし、Bluetoothでコードレスなのも良い。余程こだわりがなければ、音質も十分だと思う。 自分が持っているのはv1だけど、新しいバージョンも出ているので、そちらに買い換えたい。 大きなサウンドと深みのある低音でフルレンジのリスニング体験。ワイヤレス、超コンパクトサイズで、どんな場所へでもBoseサウンドを持って行くことが可能。内蔵スピーカーフォンにより、明瞭な通話音声の出力が可能。音声ガイドによるBluetoothペアリング手順案内で、非常に簡単に設定可能。充電式バッテリーで最大10時間の連続再生が可能 PHILIPS ソニッケアー 手で磨いていたことがアホらしくなるくらいツルツルになる。お手頃だし、買って損はないと思う。 サイズ:34×34×252mm。本体重量:127g。素材・材質:ABS。生産国:中国。電源:AC100~240V 50/60Hz。消費電力:1.4W 充電式(約24時間充電。保障期間:2年 Parrot Zik 2.0 Bluetoothでノイズキャンセリングなヘッドフォン。v1からのアップデートで軽量化をはじめ、様々な改善がなされている模様。前のバージョン持ってないからわからないけど。 少々値が張ったが重宝している。 フィリップ・スタルクがデザインした密閉型Bluetooth対応ノイズキャンセリングヘッドホン。Bluetooth/NFC接続対応。曲送り、音量調整等を行える本体側面のタッチ方式のコマンドパネル。環境に自動適応する強力なアクティブ・ノイズキャンセラー。アプリで様々な設定をコントロール docomoからみおふぉんへの乗り換え 買い物とはちょっと違うけど、携帯電話のキャリアをdocomoからみおふぉんへ乗り換えた。iPhone 5sからSIMフリーの端末に乗り換えようと思ったのがきっかけで（結局iPhone 6sにした）、端末キャッシュバックをもらうために携帯キャリアホッパーするのも面倒なので、月々の料金が格安になる mvno にした。 キャリアは乗り代わったが回線自体はdocomoだし、何も不満はない。そもそも家と会社にいる時間が大部分を占め、Wi-Fiにつないでいる時間がほとんどということを考えれば、最大限無駄を省くための選択になった。https://1000ch.net/posts/2015/progressive-web-apps/Thu, 24 Dec 2015 00:00:00 +0000https://1000ch.net/posts/2015/progressive-web-apps/今年の Chrome Dev Summit でもセッションにあった Progressive Web Apps について。Progressive Web Apps は特定の技術を指す言葉ではなく、 Web の進化していくべき姿 を提唱しているものだ。Alex Russell 氏が自身のブログで綴ったのが事の始まりで、Chrome Dev Summit でも初日は Progressive Web Apps をテーマにセッションが組まれた。 Web アプリとネイティブアプリ 昨今、パソコンで Web を閲覧する時にパフォーマンスがボトルネックになることは少なくなってきている。パソコンの性能はネットワークインフラに比べれば進化が順調であり、ネットワークも光回線のように十分に速度が得られる環境でインターネットをすることが大半ではないだろうか。 しかしモバイルデバイスではどうだろうか。iPhone や Android 端末の性能も良くなってきているとはいえ、MacBook Pro とは比較にならないし、4G の提供エリアであっても建物の中や地下鉄に乗っていれば相応の影響を受けるといったように、ネットワークも不安定であることが多い（それでも着実に整備が進んでいると思うが）。 要するに、閲覧環境が不安定なのだ。HTML・CSS・JavaScript・画像・動画といったようなリソースをネットワークを介して適時取得する必要がある Web にとっては、サービスの価値を左右する要因になってしまう。低スペックの端末だろうと、貧弱なネットワーク環境であろうと、ユーザーはスムースに閲覧できることをいつも期待しているからだ。 それに比べてネイティブアプリは、リソースの大半がアプリにバンドルされているため、起動後はネットワークからリソースを読み出す回数が Web に比べて少ない。オフライン時にもキャッシュデータをロードするなど、オフラインになったことを意識させない設計になっていることが多く、Web のように画面が真っ白になってしまうことが少ない。動作も OS ネイティブのランタイムで動作するため、ブラウザエンジンというレイヤを介す Web はどうしてもパフォーマンスが出難い。 加えて、Web ではサービスの要件を機能面で満たせないことが多かった。カメラ、ジャイロスコープ、最近だと iOS の 3D Touch など。プッシュ通知もその中のひとつである。 A year ago, I asked what features made you turn to native. #1 response: push notifications. Today, they're available: http://t.https://1000ch.net/posts/2015/wdpress-frontend-series-svg/Wed, 23 Dec 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-frontend-series-svg/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.90が12月23日に発売されます。今回は、ベクター形式の画像フォーマットとして良さが見直されてきているSVGについてです。 お次は@ahomuさん、@1000chさんによる連載「Webフロントエンド最前線」のご紹介。今回は、古参ながらも最近ついに（？）注目を集めるようになってきた画像形式、SVGについて解説いただきました！ アニメーションもできるというのは強いですね…… #wdpress — WEB+DB PRESS編集部 (@wdpress) 2015, 12月 24 イマドキのWebとSVG SVGそのものは真新しい技術ではありません。現在最も普及しているSVG 1.1は2003年にW3Cによって勧告されており、ブラウザの普及も進んでいます。この古くからあるSVGが昨今になり良さが見直されていることにはいくつか理由があります。 マルチデバイスとベクター形式 SVGと聞いて真っ先に思い浮かぶのは ベクター形式 という特徴でしょう。PNG、JPG、GIFのようなドットの集合で表現されるラスター形式の画像とは異なり、ベクター形式は座標とそれらを結ぶ線や図形で画像を表現するので、配置される領域の大きさに左右されません。端的に言えば、縮尺に強いということであり、Retinaディスプレイのような高解像度端末やタブレット端末のために、同じ画像をサイズ違いで用意する手間が省けることになります。レスポンシブウェブデザインの強い味方と言ってよいでしょう。 Web技術との相性 他のWeb技術と相性が良いのも特徴です。CSSで装飾が可能であったり（もちろんCSSアニメーションも）、HTMLと同様にDOMインターフェースが利用できたりと、とても柔軟な技術と言えます。外部SVGとして利用するもよし、複数のSVGを組み合わせてスプライトシートとして利用するもよし。また、SVGはHTMLに直接埋め込むことで本領を発揮しますが、ここから先は本誌を手にとってご覧いただけると嬉しいです。 ディベロッパーもデザイナーも ディベロッパーはもちろんのこと、デザインに関わる人も抑えておくべき技術です。 江口 和宏 (著), 吉田 太一郎 (著), 内田 優一 (著), 青山 公士 (著), 石本 光司 (著), まつもと ゆきひろ (著), おにたま (著), 田籠 聡 (著), 竹内 郁雄 (著), 南川 毅文 (著), 伊藤 直也 (著), 佐藤 太一 (著), 髙橋 侑久 (著), Magnolia.K (著), 佐藤 歩 (著), 泉水 翔吾 (著), 西尾 泰和 (著), 中島 聡 (著), はまちや2 (著), 竹原 (著), 宮崎 亮輔 (著), 安藤 祐介 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2015/wdpress-devtools/Mon, 19 Oct 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-devtools/WEB+DB PRESS Vol.89が10月24日に発売されます！Vol.89は連載「Webフロントエンド最前線」をお休みして特集1の 「[詳細] Chrome Developer Tools」を@ahomuさんと担当させていただきました。 特集1は「詳解Chrome Developer Tools」。著者は@ahomuさん、@1000chさんという、連載「Webフロントエンド最前線」のお二人です。連載のほうはお休みですが、そのぶん「まさに詳解！」という網羅的な特集となっておりますので、お楽しみに！ #wdpress — WEB+DB PRESS編集部 (@wdpress) 2015, 10月 26 特集1の目次 書き終えてみたらトータル36ページという着地で、かなり読み応えのある内容になっています。 ElementパネルとConsoleパネルを使ったWebページのデバッグにはじまり、ネットワーク処理・レンダリング処理・スクリプト処理それぞれに フォーカスしたパフォーマンスの調査と改善、そしてDevToolsの更なる便利機能と、5章構成になっています。 第1章 「Chrome Developer Tools 入門」 基本的な使い方を身に付ける 第2章 「ネットワーク処理の調査と改善」 データの転送を最適化し、Webページの初期表示を高速化する 第3章 「レンダリング処理の調査と改善」 ブラウザ内のイベントを可視化し、描画のボトルネックを取り除く 第4章 「JavaScript処理の調査と改善」 実行状態をプロファイリングし、コードを最適化する 第5章 「そのほかの便利機能」 開発環境のエミュレーション、モバイルデバイス連携、拡張機能 Web開発を加速させるために備えておくべき知識として ブラウザの開発者ツールの登場によってWeb開発は比較にならない程効率化されました。今回はその中でもGoogle ChromeのDevToolsにフォーカスしていますが、その進化は留まることを知らず、機能も使い切れないほど豊富なので、この特集を読んでもらってDevToolsを使いこなすきっかけにしてもらえると嬉しいです。 佐藤 歩 (著), 泉水 翔吾 (著), 村田 賢太 (著), 門田 芳典 (著), 多賀 千夏 (著), 奥 一穂 (著), 伊藤 直也 (著), 鍛治 匠一 (著), 中山 裕司 (著), 高山 温 (著), 佐藤 太一 (著), 西尾 泰和 (著), 中島 聡 (著), はまちや2 (著), 竹原 (著), 青木 大祐 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2015/update-mobile-phone/Sat, 17 Oct 2015 00:00:00 +0000https://1000ch.net/posts/2015/update-mobile-phone/自分はiPhone 5sを2013年9月から使っている。キャリアはdocomo。 iPhone 6はサイズ感から見送ったが、同じサイズでiPhone 6sが発売されたので、これでもいいかと思ったのでそろそろ買い換えようと思った。ついでにプロバイダ契約周りも見なおした。 docomoからみおふぉんへの乗り換え docomoでiPhone 5sを購入したときに2年割(?)的な契約というか縛りが発生していた。いわゆる、iPhone 5sくらいの金額を24分割して月々の料金から割り引いて相殺してあげますよというやつ。 毎月割り引かれていた2000円も、購入からちょうど2年経ったことで終了したので、まずプロバイダ契約を見直すことにした。 これからもdocomoでiPhoneを使おうとすると 月々割が終了した話をしたが、これがなくなったことにより契約しているdocomo回線の月々の料金は以下のようになった。 基本料金: 743円 Xiパケ・ホーダイ for iPhone定額料: 5200円（~7GBまで帯域制限無し） 付加機能使用料: 300円 - SPモードやdocomo.ne.jpのキャリアメール利用料 docomoでiPhone 5sを使っていくにはこれらの料金が基本になりプラス消費税と通話料が上乗せされて、およそ6700円〜という状態になりそうだった。SPモードってよくわからないし、キャリアメールも何年も前から使っていない。 プロバイダ選び docomoのカバーエリアは魅力的なのでdocomoのネットワークインフラを提供するプロバイダであって欲しいのと、iPhone 5sの買い替えをするまえにまずプロバイダの乗り換えを完了させたかったので、docomoのSIMロックがかかったiPhone 5sでも動くSIMカードを提供するプロバイダが良かった。この2つの条件は結果的にお互いがお互いを満たす条件になるわけだけど。 docomoを含めてauやSoftbankなどの大手プロバイダはもれなく2年縛りがついてくるし、使うこともないキャリアメールなどのサービスに暗黙的に加入させられるのも微妙だった。乗り換えによる端末の料金割引は魅力的だけど、オプションやら何やらもう少しシンプルだったらいいのにと思う。 みおふぉんでiPhoneを使おうとすると プロバイダは色々あるけど、その中からIIJのみおふぉんを選んだ。みおふぉんはIIJのSIMサービスの中で音声通話機能をデータ通信機能を提供するプラン。料金形態も「ミニマムスタートプラン」「ライトスタートプラン」「ファミリーシェアプラン」の3つがあるが、小さく初めてみようということでミニマムスタートプランを選んだ。ミニマムスタートプランの月々の料金形態は以下のようになる。 基本料金: 900円 音声通話機能付帯料: 700円 これに3GB分のバンドルクーポンがついてくるので毎月買い足しナシで3GBまでは通信ができる。自宅やオフィスではWi-Fiが使えるので、よっぽどのことが無い限りは3GBを超えることがないだろう。docomoの5200円で7GBまでのプランを持て余していたことを考えればかなり余計なモノを減らせた感じがある。 通話の手段は電話回線以外にいくらでもあるので、普通に過ごしている限り月に1600円に収まるはず。docomoでそのまま使っていた場合は6700円〜なので、差額は月に5100円〜ということになる。 プロバイダ乗り換え作業 作業というのは所謂、MNP予約番号の取得とかSIMのアクティベーションとか、そういうの。docomoのSIMロックがかかったiPhone 5sをみおふぉんのSIMカードで使えている状態がここまでのゴールということになる。 手順的には以下を踏んだ。 IIJに転入するためにdocomoのお客様WebサイトでMNP予約番号を取得 IIJのWebサイトでみおふぉんの申し込み 郵送されてきたみおふぉんのSIMカードで開通設定 現在のSIMカードを挿した状態で指定の電話番号に電話 現在の電話番号を入力 新しいSIMカードのID下四桁を入力 APN構成プロファイルを端末にインストール ステップ3を実施することでMNPが完了し、docomoのSIMカードは数時間で使えなくなる。あとはみおふぉんのSIMのカードをiPhone 5sにセットすれば完了だが、IIJから送付されてきたみおふぉんのSIMカードはdocomoの容姿をしていることに注意。 ステップ4は自身のiPhoneのOSがiOS9の場合で、iPhoneをWi-Fi等に接続してインターネット上からダウンロードしインストールすることになる。iOS8以前の場合はAPNを設定アプリから設定可能。詳しくはみおふぉん公式マニュアルを見てもらうと良い。 みおふぉん紹介コード せっかくなので紹介コード載せておきます。これを使ってもらうとバンドルクーポンの10%増量という特典があります。紹介リンクを踏んで登録してもらうか、コード（ 964 0593 9059 9448 ）を直接入力してもらうと適用されます。 iPhone 5sからiPhone 6sへの乗り換え SIMロックのかかったiPhone 5sも使えているわけだけど、そもそも買い換えたいところから今回の乗り換え作業が始まったので、iPhone 5sは下取りにだして新しいスマートフォンを買いたい。今後大手3社がどう出てくるかわからないけど、もうSIMフリーのやつしか買わないと思う。 SIMフリーのiPhone 6sを購入 Appleストア表参道でSIMフリーのiPhone 6sを購入した。 自分がキャリアを乗り換えることはしばらくないと思うが、自分が違う端末を買ってiPhone 6sが不要になった時に売るアテがなるべく広いほうが良さそう。https://1000ch.net/posts/2015/linter-textlint/Sun, 20 Sep 2015 00:00:00 +0000https://1000ch.net/posts/2015/linter-textlint/azu/textlintというテキストのlintエンジンがある。Node.js製なのでCLI周りは既にあるが、エディタでもできたら良いなと思ってAtomのプラグインを作った。TextLintについては「textlintで日本語の文章をチェックする」という記事を見てもらえると良い。 プラグインのインストール apmコマンドでインストール、または Settings → Install から linter-textlint で検索してもらうと出てくる。 $ apm install linter-textlint 使い方 Atomで開くプロジェクトに.textlintrcを配置し、プラグインやらオリジナルのルールを配置する。 例えばtextlint-rule-max-tenという一文に句点を3つ以上入れるなよというルールを使う場合、プロジェクトディレクトリでnpm install [--save] textlint-rule-max-tenを実行し、node_modules配下にルールをインストールする。次に.textlintrcを以下のように記述し、max-tenルールを有効にする。 { "rules": { "max-ten": true } } あとは、マークダウン形式を含めたプレーンテキストを開くだけ。 このようにチェックしてくれる。 Atomで開いているワークスペースのプラグインをロードする textlintの基本的な作りとして、 textlintが配置されているパスにあるプラグインを自動でロードする textlintコマンドを実行しているパスの.textlintrcを読み込んで実施するルールを選ぶ のようになっている。プロジェクトディレクトリで各種コマンドを実行したりGulpのプラグインを使う場合は、これで何の問題も無いがAtomのプラグインを作ろうとすると AtomがバンドルしているNode.jsの実行パス（/Applications/Atom.app/Contents/Resources/app.asar）にtextlintを配置する Atomで開いているディレクトリにあるプラグインを自動でロードする Atomで開いているディレクトリにある.textlintrcを自動でロードする という振る舞いを実装しなければならなそう。IssueやらPull Request投げたらazuさんが光速で対応してくれた。 feat(engine): add TextLintEngine#loadRule · azu/textlint@b23a91e resolve path with context if passed · azu/textlint@901fabe setRulesBaseDirectory() and addRule() #23https://1000ch.net/posts/2015/docker-introduction/Mon, 14 Sep 2015 00:00:00 +0000https://1000ch.net/posts/2015/docker-introduction/やってみよう系の記事は既にチラホラあるけど、手元の環境に合わせて書き直したただの作業ログ。 Dockerとは 従来のような物理的な仮想化ではなくコンテナ型仮想化を実現するソフトウェア 例えばLinuxの上に独立したLinuxをシステムを起動できる ハードウェアをシミュレートするのではなくLXCという技術を使ってリソースを隔離する ファイルシステムやプロセス・CPUを共有するので省メモリ・低コストで仮想化できる ざっくりこのような感じだが、パッとこない場合は以下の記事が参考になる。 15分で分かるLXC（Linux Containers）の仕組みと基本的な使い方 クラウド時代のオープンソース実践活用 | 第41回　Linuxコンテナ(LXC)の基礎をまとめ直す Mac OS XにDocker環境を準備する 以下のものをインストールする必要アリ。公式で配布されているDocker Toolboxでも良いが、インストーラ使うとroot領域いじられそうなので、VirtualBox以外はHomebrew経由でインストールする。boot2dockerは使わない。 VirtualBox v5.0.4 docker v1.8.2 docker-machine v0.4.1 $ brew install docker $ brew install docker-machine あとは公式のチュートリアルに沿ってDockerの振る舞いを理解していく。 Docker Machineで仮想マシンを作成する Docker Machineで仮想マシンを立てる。VirtualBoxを使うので、--driverで指定し、マシン名も引数に取る（ここではlocalというマシン名を指定）。作成すると~/.docker/machine/machines/localというフォルダが作成され、マシンの各種設定が保存される。 $ docker-machine create --driver virtualbox local Docker Machineで作成したマシンはlsコマンドでリストアップできる。マシンを削除するにはrmコマンドで。 $ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM local virtualbox Running tcp://192.168.99.100:2376 $ docker-machine rm local 仮想マシンの各種環境変数 作成したマシンの各種環境変数はenvコマンドで取得可能。出力結果をevalするとそのまま変数を定義できる。 $ docker-machine env local export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.https://1000ch.net/posts/2015/frontend-weekly/Tue, 18 Aug 2015 00:00:00 +0000https://1000ch.net/posts/2015/frontend-weekly/今日はFrontend Weeklyというメールマガジンを紹介します。私自身も編集に関わっているので宣伝にはなりますが、Frontend Weeklyが何を目的としているか、Frontend Weeklyを購読することで読者がどんなメリットを得られるかを考えてみます。 Frontend Weeklyの概要 まずは Frontend Weeklyとは一体何なのか を説明する必要がありそうです。Frontend Weeklyは、HTMLやCSS、JavaScriptなどのWebフロントエンド技術に関する記事・ライブラリなどの情報を中心に、週に一度水曜日に配信しているメールマガジンです。 キュレータは@cssradar・@hiloki・@t32k・@ahomu・@1000chの5人です。この5人で集めたリソースの中から、今後のトレンドになりそうな、あるいはキャッチアップすべきリソースをピックアップし、それぞれに日本語のサマリーを付けて配信しています。 英語が中心のリソース 紹介するリソースの多くは英語ですが、これには理由があります。 技術仕様に関するリソースのドキュメントのほとんどは英語で書かれています。英語が国際的な公用語に最も近い言語であることも理由の1つですが、技術経済が英語圏で生まれ、今も存在していることが最も大きな理由でしょう。これは、Web技術も例外ではありません。 こうした情報を英語から日本語に翻訳してくれるメディアもありますし、有志もたくさんいます。しかし、これらだけを期待することにはいくつかリスクがあります。 英語から日本語へ誤訳される可能性が生まれる 翻訳を待つ時間、情報の鮮度が落ちる 問題解決の宝庫Stack Overflowが無価値になる こうしたリスクとFrontend Weeklyの 最新情報を届けるというメディアの性質 を考慮すると、英語リソースの紹介が必然的に多くなります。日本語が世界のデファクトになることは恐らくないでしょうから、最新動向を追っていく上で英語は避けて通れません。 英語を恐れる必要はありません。英語は苦手という人も、時間をかけて1記事ずつ消化してみてください。その時は、ウェブデベロッパのための英語という記事も是非見てください。 もちろん、日本語にも素晴らしいリソースがあります。こうした記事をピックアップして届けることもミッションの1つですが、同時に素晴らしい日本語リソースが増えていくことも期待しています。 情報源を絞るということ こうしている間にも、新たな情報が世界中で発信され続けています。その中から価値のある情報を探し出すには、次のような労力が発生します。 大量のメディアの中から 信頼できる購読する情報源を選択する 古い・誤っているなどの 価値の小さい情報源をフィルタする これらを実践し続けることは、とても労力の要ることです。Frontend Weeklyでは情報を集める過程でこれらを行うことで、価値の高い情報を求める人が払う労力をなるべく取り除けるとも考えています。 キュレーターは私を含めて5人います。私はさておき、皆Webに造詣の深く、最新の動向を追いかけている人ばかりです。とりわけ、編集長の@cssradarはFrontend Weeklyが生まれる前からこうした活動を続け、そして実績を挙げていることは皆さんも疑わないと思います。もちろん私も、よりよい情報を提供できるように、常に注意して情報を探っています。 Frontend Weeklyを購読するメリット ここまで説明した通り、Frontend Weeklyは Webにまつわる技術動向を追う上で発生するコスト を小さくしているメディアです。 Web界隈の技術進化は目覚ましく、今は最新と呼ばれる技術も一年後には陳腐化しているかもしれません。枯れた技術を棄て、新たな技術を選択し続けていくことも、Webに生きる人間にとって必要な技術ではないでしょうか。そんなご時世を生き抜くツールの1つとしてFrontend Weeklyを活用してください。 また、Frontend Weeklyはまだまだ未完成のメディアです。皆さんのフィードバックを受けながら、常にブラッシュアップしていきたいと考えています。近いうちに意見箱を用意しますので、皆さんの意見を聞かせてください。 日本のWebを前に進める 最後になりますが、 Frontend Weeklyの購読は無料 です。購読していない人は、これを機に是非登録してみてください。登録はコチラからどうぞ。 また、 「どんなメールが来るのか気になる…！」 、 「過去の配信記事を見てみたい！」 という人のために、配信したメールもバックナンバーとしてアーカイブしてあります。 Frontend WeeklyがWebのメインストリームに飛び込むきっかけになれば幸いです。 それでは、次号の配信をお楽しみに。https://1000ch.net/posts/2015/service-worker-push-notification/Mon, 17 Aug 2015 00:00:00 +0000https://1000ch.net/posts/2015/service-worker-push-notification/Service Worker でブラウザにプッシュ通知をする方法については、既に解説記事が幾つかあるのできっと面白くありません。ただの作業ログです。概論についてはウェブのプッシュ通知、何がそんなにすごいのか？ - Tender Surrenderという記事を見てください。 前提と大まかな手順 例によって Service Worker 周りの実装が進んでいる Chrome Canary で試す。また、配信元は HTTPS 環境でないと Service Worker をインストール出来ないので、GitHub Pages でホストする。プッシュは、今のところ GCM（ Google Cloud Messaging ）のみ対応しているので、そのあたりの準備もすることになる。 GCM にプッシュデータ配信を行うサーバーのプロジェクトを用意する 1.で作成したプロジェクト ID を Web App Manifest の gcm_sender_id に指定する HTML ページ及びサーバープッシュを受ける準備をした Service Worker を用意する 3.を HTTPS 環境下で配信する（今回は GitHub Pages ） 4.で用意したページに Chrome Canary でアクセスし、Service Worker をブラウザにインストールする 1.で作成したサーバーにプッシュの配信リクエストを行う GCMとは 以下 Google Cloud メッセージング（GCM）の使用 からの引用。 Google Cloud メッセージング（GCM）は、デベロッパーが Android、iOS、Chrome といった複数のプラットフォームにメッセージを送信できる無料のサービスです。たとえば、サーバーから 1 つの端末、端末グループ、または特定のトピックを定期購入している端末に、メッセージを直接送信できます。また、端末に搭載されたアプリも、サーバーや同じグループに属する端末にメッセージを直接送信できます。 Google Developer Consoleにプロジェクトを作成 Google Developer Console から「プロジェクト作成」。https://1000ch.net/posts/2015/wdpress-frontend-series-render/Fri, 14 Aug 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-frontend-series-render/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.88が8月22日に発売されます。連載8回目は、スムーズなWeb体験を実現するためのレンダリングのパフォーマンスについて。 大事な大事なレンダリングパフォーマンス 普段から描画パフォーマンスを意識して開発している人は、そこまで多くはないでしょう。しかし、Webを見ている時にスクロールの引っ掛かりを感じたり、画面のガタつきにイラッとした体験は誰しもあるのではないでしょうか。前回のネットワークパフォーマンスと同様にスムーズなWeb体験もサービスの価値を左右します。 これは@ahomuさんがHTML5 ConferenceでセッションしたWeb Frontend Rendering Performance Knowledge & Tipsというセッションの資料です。この辺の内容をアップデートしてまとめたのが今回の内容です。 よろしくおねがいします(´・ω・`) 是非お買い求めください。 佐々木 拓郎 (著), 高柳 怜士 (著), 鶴原 翔夢 (著), 小野 侑一 (著), 中村 俊介 (著), 佐藤 春旗 (著), 長野 雅広 (著), 佐々木 健一 (著), 久保 達彦 (著), 若山 史郎 (著), 佐藤 太一 (著), 伊藤 直也 (著), 道井 俊介 (著), 佐藤 歩 (著), 泉水 翔吾 (著), 坪内 佑樹 (著), 海野 弘成 (著), 西尾 泰和 (著), 中島 聡 (著), はまちや2 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2015/atom-csscomb/Mon, 20 Jul 2015 00:00:00 +0000https://1000ch.net/posts/2015/atom-csscomb/CSSのプロパティをソートするCSSCombというNode.jsのモジュールがある。CSSプロパティのソートは書き順が統一されてコードの可読性が上がるだけではなく、サーバーから配信されるときに実施されるであろうGzipの圧縮効率も高まるというメリットがある。そんなCSSCombをAtomのプラグインにした。 …と言っても、作ったのはだいぶ前。CSSCombをかけるとインデントとかがグチャッと崩されてしまうのが気に入らなくて、 使い心地にやや不満があったんだけど、フォーマッターをかけるようにアップデートしてみた。 インストール Atomのアプリを開いて Settings → Install から、atom-csscomb で検索してもらうか、apmコマンドで以下を実行するとインストールできる。 $ apm install atom-csscomb 使い方 CSSファイルを開いて、またはCSSの一部分を選択した状態で Control + Option + C アプリケーションメニューの Packages > CSSComb > Sort properties 右クリックし、 Sort properties をすることでソートが適用される。あるいは、保存時に都度実行するためのオプションも作ったので、こちらはお好みで。 Settings > Packages > atom-csscomb に Execute on save という項目があるので、チェックすると保存の度に実行されるようになる。 ソート順を自前で設定したいという人は、プロジェクトルートに.csscomb.jsonという定義ファイルを用意してもらうか、インストールされたパッケージフォルダ配下にある~/.atom/packages/atom-csscomb/csscomb.jsonを編集すればOK。https://1000ch.net/posts/2015/philips-sonicare/Wed, 01 Jul 2015 00:00:00 +0000https://1000ch.net/posts/2015/philips-sonicare/「電動歯ブラシやばい」「ソニッケアーで歯磨きのクオリティ上がった」「磨き上がりが段違い」と、各所からそそのかされて、騙されたつもりで買ってみたら噂に違わぬ使い心地だった。 磨き上がりが違う 何を隠そう、私も「普通の歯ブラシでも綺麗に磨けるでしょ〜」と思ってたクチだ。しかし、ソニッケアに出会って歯磨き生活のクオリティがアップした（念のため断っておくがPHILIPSの回し者ではない）。 磨くエリアを丁寧になぞっていくだけなので楽だし、磨き残しが無い。何よりツルツル具合が違う。こればかりは使ってみないと違いを体感できない。ボタンを押すと、2分間振動が始まる。2分間でまんべんなく歯をなぞるくらいが1度のブラッシングに丁度良いようだ。 ランニングコスト 本体は充電式で半永久的に使えるが、ブラシ部分は3ヶ月おきに交換することが推奨されている。替えブラシは4本入りで約3000円なので、約1年で3000円ということになる。1日に換算すると約8円。普通の歯ブラシも1ヶ月~2ヶ月で交換することを考えれば、ほぼトントンということになるだろう。 サイズ:1.9×1.9×8.6。本体重量:34g。素材:ポリプロピレン。生産国:アメリカ。 お試しください 「電動歯ブラシ要る？普通ので良くね？」という人も、安いモデルであれば6000円程度の初期コストだし、騙されたつもりで試してほしい。 サイズ:34×34×252mm。本体重量:127g。素材・材質:ABS。生産国:中国。電源:AC100~240V 50/60Hz。消費電力:1.4W 充電式(約24時間充電。保障期間:2年 高いものだと~20000円弱まであるようだけど、こちらは使ったことがないのでわからん。何が違うんだろう。https://1000ch.net/posts/2015/even-faster-web-sites/Sun, 28 Jun 2015 00:00:00 +0000https://1000ch.net/posts/2015/even-faster-web-sites/読みなおす機会があったので、簡単だけどレビューを書いてみる。 目次 Ajaxアプリケーションとパフォーマンス 応答性の高いアプリケーション 初期ロードの分割 実行をブロックしないスクリプトのロード 非同期スクリプトの組み合わせ インラインスクリプトの適切な位置 効率的なJavaScriptコード Comet gzip圧縮再考 画像の最適化 主ドメインの細分化 ドキュメントのフラッシュ iframeの取り扱い CSSセレクタの単純化 付録A パフォーマンス関連ツール 付録B Yahoo! JAPANが実践するWebの高速化 付録C ブラウザの最新技術を活用したWebの高速化 付録D Web高速化に対するGoogleのアプローチ 2010年の4月に発売された本なので、今と比較するのも微妙な話だが気になる点が少々あったものの、基本的な高速化理論については広い範囲をカバーしていて染み染み良書だなと思い知らされる。 Cometというワードを初めて目にした気がする。Ajaxとロングポーリングを使ってリクエストのオーバーヘッドを感じにくくするアプローチのようだ。恐らくWebSocketの台頭によって去っていった技術だろう。今後はWebSocketだけでなく、httpでも双方向通信は実現していく。 例によって、画像の最適化の章を興味深く見ていたわけだが、Stoyanが担当した章であることを初めて知ったのだった。Stoyanこそ、私が画像に取り組むきっかけになったGive PNG a chanceという記事を書いた人である。また、JPEGについてはファイルサイズの観点からプログレッシブではなくベースラインでの保存を推奨していた。今どきはATFにおける体感速度を優先してプログレッシブが主流になっているので、Web高速化分野の進化を感じる部分でもある。 感想 高速化アプローチとして、現在のWeb技術事情と大きく差分が出てくるのはやはりネットワーク部分かと思うが、それについてはハイパフォーマンスブラウザネットワーキングを見てもらうと良い。とは言え、本書に書いてある内容も、HTTP1.1の特性を考慮したアプローチとして理解して損はない内容ではある。 Web開発に関わる人なら、職種を問わず読んでおきたい一冊。 Steve Souders (著), 武舎 広幸 (翻訳), 福地 太郎 (翻訳), 武舎 るみ (翻訳)https://1000ch.net/posts/2015/input-suggest/Mon, 22 Jun 2015 00:00:00 +0000https://1000ch.net/posts/2015/input-suggest/<input>の入力補助には<datalist>を使ったものがある。補助候補を<datalist>と<option>を使って定義し、そのIDを適用先の<input>のlist属性に付与する。以下サンプル。 See the Pen Input suggestion using datalist by 1000ch (@1000ch) on CodePen. Chromeだと領域の右端に▼が表示されているし、候補のドロップダウンやその▼はまさにブラウザネイティブのUIといった感じだが、どうもスタイリングが出来ない。古いという意味で信頼性に欠けるがRelevant Dropdowns: Polyfill for Datalistにも不可能っぽいことが書いてある。Shadow DOMだろうからインスペクタ使ってセレクタを調べようとしたけど、フォーカスアウトするとダメで断念した。 これらに加えて、テキストエリアでは機能しない。僕はテキストエリアでサジェストされて欲しいんです。 input-suggest jQueryプラグインだとチラホラ見かけるけど、jQueryナシが良いし、自分の勉強も兼ねて実装してみた。InputSuggestコンストラクタに<textarea>要素・<input type="text">要素、ないしそれらを参照するセレクタを渡すと実行される。また、ポップアップはそのままだとスタイルが当たっていないので各自でCSSを書いてもらう必要がある。 See the Pen Input suggestion using input-suggest by 1000ch (@1000ch) on CodePen. <datalist>を<textarea>でも機能させるというコンセプトにしようかとも考えたが、定義されてもいないポリフィルを実装するような感覚に陥りそうだったのでやめた。https://1000ch.net/posts/2015/html5-allstars/Mon, 15 Jun 2015 00:00:00 +0000https://1000ch.net/posts/2015/html5-allstars/2015年6月13日はhtmlday 2015ということで、因んで開催されたHTML5オールスターズ勉強会に登壇した。html5j主催・dots.さん協力の下、自分を含めて8つのセッションが行われた。 当日のスライド は、こちら。セッション時間が20分だったので枚数も少なめだが、それなりに凝縮できた気はする。 詳しいフォローアップ記事はまた後程。 セッション 『いつになっても議論が終わらないパフォーマンス関連のWeb標準たち』 川田 寛氏 トップバッターは川田さん！
『いつになっても議論が終わらないパフォーマンス関連のWeb標準たち』川田 寛氏（@_furoshiki）

#dotshtml5 #htmlday pic.twitter.com/RAgTdOQlz9 — eventdots (@eventdots) 2015, 6月 13 アニメーションについて・ネットワーク（オフライン）について・モニタリングについてと、パフォーマンスに関する情報をまんべんなく取り扱ったセッション。独特な挿絵(?)はどうやって用意しているのか気になるところ。 『まだまだ ServiceWorker のはなし。Background Sync も来るよ！』 安田 絹子氏 お二人目です！
『まだまだ ServiceWorker のはなし。Background Sync も来るよ！』安田 絹子氏（@kinu）
#dotshtml5 #htmlday pic.twitter.com/5cz7LyIu9g — eventdots (@eventdots) 2015, 6月 13 大注目のService Workerについて、Chromeチームでまさにそれを実装している@kinuさんのセッション。Service Workerの全体図を把握できる内容だった。個人的にはもう少し踏み込んだ部分を聞きたかった気もする。 『オフラインWebアプリの再到来で今、再び注目されるAPIの本命　ーJavascript SQL-like database』 吉川 徹氏 第2セッション開始です！
『オフラインWebアプリの再到来で今、再び注目されるAPIの本命　ーJavascript SQL-like database』吉川 徹氏（@yoshikawa_t）
#dotshtml5 #htmlday pic.twitter.com/dFZ25skbEf — eventdots (@eventdots) 2015, 6月 13 オフラインアプリケーションはこれからのWebにおける1つのキーワードかと思いますが、その中でIndexedDBは大事になってきます。前の2セッションでどちらもService Workerに触れてきたけど、IndexedDBも関係してくる。google/lovefieldは名前がオシャレですね。 『ついに来たぞ！Polymer1.0!!!』 小松 健作氏 第2セッションお二人目！
『ついに来たぞ！Polymer1.0!!!』小松 健作氏（@komasshu）
#dotshtml5 #htmlday pic.https://1000ch.net/posts/2015/wdpress-frontend-series-network/Sun, 14 Jun 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-frontend-series-network/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.87が6月24日に発売されます。連載7回目は、Webフロントエンド高速化に於いて最も基本的とも言えるネットワークの最適化について。 いくらカッコよくても遅かったら台無し Webサイトのパフォーマンスがユーザー体験にどれほど影響されるかは今囁かれ始めた話ではありません。GoogleとMicrosoftはページロードが2秒遅くなるたびサービスにとって4.3%の減益につながるとの研究を示したり、Amazonだと売上が数%落ちるだとか、定番的に話されている話も多いので耳タコの人もいるでしょう。 ページロードはWebページの閲覧フローのうち、ユーザーが最初に体験するフェーズです。ページロードで10秒かかったらユーザーはそのサイトへ二度と帰ってこないかもしれません。 HTTP/2の台頭でフロントエンドの最適化が要らなくなる と誤変換された情報が流れているのをたまーに見ますが、変化するだけで要らなくなるわけではありません。そのことについても書いてます。 よろしくお願いします(´・ω・`) 是非お買い求めください。 佐藤 鉄平 (著), 小林 明大 (著), 石村 真吾 (著), 坂上 卓史 (著), 上原 誠 (著), 鳥居 英 (著), 佐藤 歩 (著), 泉水 翔吾 (著), うさみ けんた (著), 伊藤 直也 (著), 高橋 侑久 (著), 佐藤 太一 (著), hayajo (著), 橋本 翔 (著), 西尾 泰和 (著), 中島 聡 (著), はまちや2 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2015/we-should-optimize-images/Mon, 25 May 2015 00:00:00 +0000https://1000ch.net/posts/2015/we-should-optimize-images/※この記事はMediumに投稿したWe should optimize imagesの日本語訳です。 Steve SoudersはHigh Performance Web Siteで、次のように述べています。 エンドユーザーへのレスポンスに費やされる時間の80-90%はフロントエンド において発生している。まずはフロントエンドを最適化することだ。 Webサイトのパフォーマンスの多くはフロントエンドに起因するものです。つまりWebサイトを速くするためには、フロントエンドを最適化しなければなりません。例えば、最適化には次のような要因があります。 ラウンドトリップタイムを最小化する リクエストのオーバーヘッドを最小化する ペイロードサイズを最小化する ブラウザのレンダリング処理を最適化する その他いろいろ… 中でもペイロードサイズの最小化は、最も実施しやすいものの1つです。ペイロードサイズの最小化には、HTML、CSS、そして画像のファイルサイズを削減します。中でも特に、画像データはネットワーク帯域の多くを占めます。そこで、画像を最適化するためのツールをいくつか紹介したいと思います。 ImageOptim - 様々な最適化ライブラリ（PNGOUT・Zopfli・PNGCrush・AdvPNG・拡張したOptiPNG・JPEGOptim・JPEGReScan・JPEGTran・GifSicle）を内包し、PNG・JPEG・GIFを最適化するMacのアプリケーション ImageAlpha - 24bitのPNGを8bitにダウンコンバートしファイルサイズを大きく削減するMacのアプリケーション JPEGmini - JPEGを少ない劣化で減色しファイルサイズを削減するMacのアプリケーション RIOT - PNG・JPEG・GIFを最適化するWindowsのアプリケーション pngoo - PNGを圧縮するWindowsのアプリケーション WebPonize - PNG・JPEGをWebPフォーマットに変換するMacのアプリケーション これらはGUIアプリケーションなので、簡単に利用することができます。ここにPNGを圧縮したサンプルがあります。 これは圧縮されていないオリジナルの画像です。24bitのPNGで、位置情報・日付・時刻といった様々なメタ情報が含まれています。 これはImageAlphaで8bitにダウンコンバートし、ImageOptimでメタ情報を削除するなどして最適化したPNGです。ほぼ劣化していないように見えます。 こちらはJPEGのサンプルです。メタ情報はImageOptimで削除済ですが、劣化を伴う減色処理はされていません。 更にJPEGminiによって減色処理を施しています。劣化は目立ちませんが、ファイルサイズはオリジナルのおよそ34%程（66%も削減されています！）になっています。写真のような画像は非常に多くの色があるため、減色処理を行った後によく確認しなくてはならないでしょう。これは面倒な作業ですが、より良いことです。 私はコマンドラインのツールも欲しかったので、GruntとGulp用のモジュールを作りました。 grunt-image - GUIでの操作なく画像を最適化するGruntのモジュール gulp-image - grunt-imageのGulpバージョン これらを使ってPNG・JPEG・GIF・SVGを最適化することができます。インストール？もしGruntやGulpを使ったことがあればとても簡単です（きっと一度は使ったことがあるでしょう☺）。 # download them using npm $ npm install —-save-dev grunt-image $ npm install —-save-dev gulp-image 詳細な設定はGitHubのプロジェクトリポジトリを参照してください。 WebPも素晴らしいです。WebPはGoogleが開発する新しい画像フォーマットで、公式サイトで次にようにあります。 可逆圧縮のWebPはPNGと比較して、ファイルサイズが26%小さくなります。非可逆圧縮のWebPは同等画質のJPEGと比較して、ファイルサイズが25%-34%小さくなります。 WebPは、Chromeやその他のChrome Frameをバンドルしているブラウザがサポートしています。FirefoxとSafariはWebPをサポートしていません。しかし興味深いことに、SafariのWebKitを利用しているはずのiOSのChromeはWebPを表示することが可能です（おそらくChrome Frameを内包しているものと思われます）。https://1000ch.net/posts/2015/introduction-to-webp/Fri, 22 May 2015 00:00:00 +0000https://1000ch.net/posts/2015/introduction-to-webp/※この記事はMediumに投稿したIntroduction to WebPの日本語訳です。 以前述べたように、画像はWebにおけるネットワーク帯域の約60%~70%を占めています。これは、画像がWebパフォーマンスにおいて最も重要な因子の1つであることを意味します。そんな画像の中でも、WebPは他のフォーマットに比べて幾つかの点において優っています。 WebPの特徴 可逆圧縮と非可逆圧縮 PNGやGIFは可逆圧縮をサポートし、JPEGは非可逆圧縮をサポートしますが、WebPは可逆圧縮と非可逆圧縮の両方を利用することが出来ます。更に特筆すべきは、その圧縮率が他のどのフォーマットよりも高いということです。 可逆圧縮のWebPは、PNGに比べて26%程サイズが小さくなります。非可逆圧縮のWebPは、同等画質のJPEGに比べて25%~34$程サイズが小さくなります。 ※公式サイトより引用 透過（アルファチャネル）とアニメーション WebPは可逆圧縮・非可逆圧縮を問わず、PNG同様にアルファチャネルとGIF同様にアニメーションをサポートします。 WebPは、およそ22%程データを追加することで可逆圧縮で劣化のない透過（アルファチャネル）を利用することが出来ます。透過は非可逆圧縮においても利用可能で、透過付きのPNGに比べて3倍以上もファイルサイズを抑えられます。 ※公式サイトより引用 ブラウザサポート WebPは次のブラウザで表示することが出来ます。 Google Chrome Opera Chrome for Android Chrome for iOS 今のところ、FirefoxとSafariはWebPをサポートしていません。しかし興味深いことにiOSのChromeではWebPの画像が表示されています。きっと、WebPのデコーダを内包しているんでしょう。 これはつまり、WebPのデコーダを内包していれば、AndroidやiOSのどんなアプリケーションでもWebPを利用することが出来ることを意味しています。 他のフォーマットへのフォールバック <picture>要素と<source>要素 御存知の通り、<picture>要素と<source>要素はレスポンシブにリソースをロードする比較的新しい方法です。<source>要素にはリソースの mime-type を指定するtype属性が存在し、それを指定することでブラウザがそれをサポートしている場合にロードさせることが出来ます。 <picture> <source srcset="image.webp 1x" type="image/webp"> <img src="image.jpg"> </picture> この場合、ブラウザがWebPをサポートしていればimage.webpを、サポートしていなければimage.jpgがロードされます。 WebPJS WebPJSはJavaScriptのライブラリで、WebPの画像をdataURIの文字列にクライアントサイドで変換します。 サーバーサイドでAcceptヘッダのチェック ブラウザはリクエストの際に、リクエストそれぞれに次のようなAcceptヘッダを付与します。 Accept: image/webp, image/png, image/jpeg, image/gif, image/svg+xml, image/bitmap よって、サーバーはクライアントサイドから送信されるリクエストヘッダに Accept: image/webpが含まれるかどうかをチェックし、ブラウザに返却する画像を選択することが出来ます。 image/webp を含んでいない場合は、WebPに変換する前のオリジナルであるPNGやJPEG、あるいはGIFを返せば良いでしょう。 これについては次のリソースも読むことをオススメします。 Deploying WebP via Accept Content Negotiation — by Ilya Grigorik Faster, smaller and more beautiful web with WebP — by Ilya Grigorik Deploying New Image Formats on the Web — by Ilya Grigorik igrigorik/webp-detect — WebP with Accept negotiation by Ilya Grigorik WebPのツール cwebp-bin 画像をWebPに変換したいときは、cwebpのNode.https://1000ch.net/posts/2015/webponize-is-released/Wed, 29 Apr 2015 00:00:00 +0000https://1000ch.net/posts/2015/webponize-is-released/WebPonizeは前に触れた通り、JPEGやPNGをWebPに変換するMacのアプリケーション。App Storeに登録するために色々と試行錯誤していたんだけど、アプリの目的と反する可能性が出てきたので断念し、ダウンロード形式を取ることにした話。 アプリに掛かる制限が色々と厳しい App Storeで公開するためにはAppleの審査を突破する必要があるが、最初に申請したときにRejectされた理由は、ユーザーインターフェースのこと、期待する動作をしていないことの2点だった。 From Apple 2.3 - Apps that do not perform as advertised by the developer will be rejected 6.1 - Apps must comply with all terms and conditions explained in the Apple Macintosh Human Interface Guidelines 2.3 The app does not achieve the core functionality described in your marketing materials or release notes. ユーザーインターフェース ユーザーインターフェースについてはFileメニュー内にOpenアイテムがなく、ドラッグアンドドロップだけでなく、Macアプリの基本的なインターフェースガイドラインとしてヘッダーメニューも整備しなさいという指摘だった。これは単純に失念していたので実装した。 サンドボックスキー 問題は後者の期待する動作をしていないというもの。色々調査した結果から推測すると、特定の条件に該当するアプリケーションの動作を許容するアプリにはサンドボックスキーと呼ばれるフラグをオンにしないとApp Storeの公開に漕ぎ着くことができないらしい。フラグは以下の様なもの。 Network Incoming/Outgoing Connectionにアクセスできるか Hardware カメラ・Microphone・USB・印刷機能へアクセスできるか App Data 連絡先・位置情報・カレンダー情報へアクセスできるか File Access ユーザー選択・ダウンロードフォルダ・ピクチャーフォルダ・ミュージックフォルダ・ムービーフォルダへアクセスできるか こうした情報に闇雲にアクセスできてしまうと、ユーザーが意図しない事故も起きてしまうこともあるだろう。App Storeに公開されているアプリは比較的安心できるということになる。 「このアプリはカメラ機能へのアクセスを求めています」 的な確認ダイアログとか出るんだと思う。https://1000ch.net/posts/2015/wdpress-frontend-series-serviceworker/Wed, 15 Apr 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-frontend-series-serviceworker/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.86が4月23日に発売されます！連載6回目は、HTTPリクエストの操作・サーバープッシュの受信・バックグラウンドスケジューラといった、Webに長らく求められてきた機能の基盤となるService Workerについて。 Service Workerで変わるWebアプリの常識 Service Workerで実現されるのWebページのオフライン化に限りません。これはFrontrend Conferenceのときに話した通り。 ブラウザスレッドのリクエスト検知と操作 プッシュサーバからのプッシュデータの受信 バックグラウンドで実行されるスケジューラ どの機能もネイティブのプラットフォームにはあったもののブラウザにはなく、そしてアプリにとっては重要なものであったので、これらの差でネイティブアプリという選択が数多くされてきた。Service Workerによってこれらが実現することは、Webにとって追い風になるのは間違いない。 ネイティブアプリ活況下でのWeb - Nothing ventured, nothing gained. ウェブのプッシュ通知、何がそんなにすごいのか？ - Tender Surrender モバイルの未来はアプリベースではなくなる？ - readwrite.jp パフォーマンスの差も確実に埋まるし（追い付く・追い越すというのは有り得ない話ではあるが、人が気づかないレベルにはいつか到達する。はず）、パフォーマンス以上に決定的な差であったプッシュ通知やバックグラウンドスケジューラも実現する。 ただ、 Google PlayやApp Storeからダウンロードしてスマートフォンのデスクトップに配置する ということが一般化しているので、ブックマークをホームに置くことをどこまで浸透させれるかがポイントかなと思っている。が、これもIncreasing engagement with Web App install bannersのようなブラウザの機能によって、案外あっさり定着するのかも。 ※画像はHTML5Rocksより引用 宜しくお願いします(´・ω・`) Service Workerはオプトインの機能として取り入れやすい技術でもあります。今から積極的に試しておきたいところです。 結城 洋志 (著), 沖元 謙治 (著), 足永 拓郎 (著), 林 健太郎 (著), 大竹 智也 (著), 内田 誠悟 (著), 伊藤 直也 (著), 中山 裕司 (著), hiroki.o (著), 泉水 翔吾 (著), 佐藤 太一 (著), 高橋 俊幸 (著), 西尾 泰和 (著), 舘野 祐一 (著), 中島 聡 (著), 橋本 翔 (著), はまちや2 (著), 竹原 (著), 麻植 泰輔 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2015/dotfiles/Sun, 05 Apr 2015 00:00:00 +0000https://1000ch.net/posts/2015/dotfiles/久々にdotfilesを整理した。黒い画面に長けているわけではないので、然程モリモリしているというわけではないけど、だいぶダイエットできた。 Dropbox管理をやめてGitHubのリポジトリに Dropboxにdotfilesを配置して、それらに対してシンボリックリンクを貼ることで設定を共有していたが、gitのリポジトリにした。これで、設定をGitHubで見れるし、変遷もコミット履歴を辿ればOK。 1000ch/dotfiles dotfilesリポジトリをユーザールート（~/dotfiles）に置くことにして、次のような感じでシンボリックリンクを貼るのは同じ要領。これはsetup.shに書いておく。 $ ln -s ~/dotfiles/.vimrc ~/.vimrc $ ln -s ~/dotfiles/.zshrc ~/.zshrc $ ln -s ~/dotfiles/.zprofile ~/.zprofile $ ln -s ~/dotfiles/.gitconfig ~/.gitconfig $ ln -s ~/dotfiles/.gemrc ~/.gemrc 実際にこの設定を使うには、リポジトリを~/dotfilesにクローンして、setup.shを実行するだけ。 $ git clone git@github.com:1000ch/dotfiles.git ~/dotfiles --recursive $ sh ~/dotfiles/setup.sh oh-my-zshをサブモジュール化 oh-my-zsh + oh-my-zsh-powerline-themeユーザーなので、それらのリポジトリを適当な場所にクローン・インストールしていたが、git管理に伴いサブモジュール化した。場所が~/dotfiles/oh-my-zshといったように決まることで迷わないし、更新も自動で出来る。 $ git submodule add git@github.com:robbyrussell/oh-my-zsh.git $ git submodule add git@github.com:jeremyFreeAgent/oh-my-zsh-powerline-theme.git dotfilesリポジトリのgit clone時はサブモジュールもダウンロードさせるために--recursiveもつけること。 setup.shにサブモジュール化したoh-my-zshとpowerlineテーマを有効化させるために以下のコマンドをsetup.shに書いておく。 # set up oh-my-zsh ~/dotfiles/oh-my-zsh/tools/install.sh | ZSH=~/dotfiles/oh-my-zsh sh # create hard-link to oh-my-zsh-powerline-theme from oh-my-zsh/themes ln -f ~/dotfiles/oh-my-zsh-powerline-theme/powerline.https://1000ch.net/posts/2015/position-sticky/Tue, 31 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/position-sticky/業務中にposition: sticky;的な表現をする必要があって、JavaScriptで実装したり、その辺の仕様がどうなってるのか調べたメモ。スティッキーの挙動を言葉で説明するのは難しいので、デモを見てもらったほうが話が早い。 Fixed-sticky - filamentgroup Demo: Position Sticky 広告をスクロールに応じて一定位置まで追従させたいシーン等によく利用されているイメージ。範囲が限定されているposition: fixed;と言えばいいんだろうか。 スペックなど Sticky Positioning from Edward O’Connor on 2012-06-26 (www-style@w3.org from June 2012) 6.2. Sticky positioning - W3C Editor’s Draft - CSS Positioned Layout Module 6.7. Choosing a positioning scheme: position property - W3C Editor’s Draft - CSS Positioned Layout Module 仕様は生きているようだけど、Chromeで使えない。と、いうか、途中まで（35くらいまで？）はフラグ付きで使えたような気がしてたけど、使えなくなってた。各種ログを追ってみると実装が途中で削除された形跡がある。 Why doesn’t position: sticky work in Chrome? - Stack Overflow Issue 231752: Meta bug for position:sticky - Chromium Dashboard Remove position: stickyhttps://1000ch.net/posts/2015/html-css-common-sense/Fri, 27 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/html-css-common-sense/ペンギンが本書いたらしく、恵贈頂いた。 目次 現場でやりたいことが項目化されており、それについての詳しい解説があるような構成になっている。 Introduction　最近のコーディングの潮流 現在の現場におけるモダンなワークフロー CHAPTER1　目的に合わせたコーディングの環境整備 Node.jsとRubyの環境を整える バージョン管理システムGitのインストールと使い方 検証を楽にしてくれるツール 仮想環境を構築する パッケージマネージャーの使い方 CHAPTER2　HTMLコーディング HTML5でのマークアップ 短縮記法で高速コーディング フォーム関連の新機能 HTML5カスタムデータ属性の有効活用 SVGでベクターグラフィックを描画する 音声と映像をWebページに埋め込む Canvasで広がる新しい表現の世界 セマンティックWebのための構造化マークアップ SNSのシェアボタンを設定する HTML5でのマルチデバイス対応 今から始めるWebアクセシビリティ CHAPTER3　CSSコーディング Sass・LESSなどのCSSプリプロセッサ スタイルガイドを作成する レガシーブラウザへの対応 CSSのセレクタを使いこなす CSS3で追加されたプロパティ Webフォントを活用する CSS3のアニメーションを活用する Media Queriesを使ったレスポンシブWebデザイン CSSフレームワークの導入方法と使い方 管理しやすく破綻しないCSS設計の手法 CHAPTER4　最適化・検証 タスクランナーで定型作業を自動化する 表示パフォーマンスを最適化する ブラウザに搭載されている検証ツールを利用する CHAPTER5　そのほかよく利用される技術・ツール HTMLテンプレートのためのテンプレートエンジン 静的サイトジェネレータで高速Web開発 効率よくコーディングを進めるエディタ（IDE）紹介 作業の手間を軽減する便利ツール 最近のJavaScriptの動向を理解する 内容 Gitや仮想環境、Node.js等を使った最近の開発環境・HTMLとCSSの包括的な知識、ツールなど、Webに関するトレンドを幅広く取り扱っている。よく使われるライブラリ・ツール・アプリの紹介がかなり充実しているので、トレンドをキャッチアップし直すには本書を通して読むことで大分追いつけると思う。ターゲットはWeb開発者の初級者〜中級者層だろうか。ディベロッパーはもちろん、HTML/CSSを触ることのあるデザイナーも読んで損のない内容。 フロントエンドエンジニア養成読本と被るのかなと思いきや、こちらの本は、 現場で実践しやすい知識を取り揃えている ような印象を受けた。かと言ってTip集というわけでもなく、これからのWeb開発者にとって必要になる前提知識をしっかりと踏まえながら解説されている。 大竹孔明 (著), 小川裕之 (著), 高梨ギンペイ (著), 中江 亮 (著), 株式会社まぼろし (その他) 趣味の問題かもしれないが、個人的には CHAPTER4　最適化・検証 の項をオススメしたい。Web開発の現場において今後必須（というか前提）になるであろう色々な作業の自動化と、ページを組み上げてオシマイではなくユーザービリティの最大化に欠かせないWebパフォーマンスのチューニングの項は是非とも身につけておきたいところ。https://1000ch.net/posts/2015/webcomponents/Mon, 23 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/webcomponents/Web Components については暫く理想を語ってきたが、正直そうは上手くいかないと思っている。 Web Componentsが変えるWeb開発の未来 Web Componentsを構成する4つの仕様 ー Web Components基礎編 Web Componentsでカルーセルギャラリーを作る ー Web Components実践編 Web Componentsを簡単・便利にするライブラリ「Polymer」を使いこなそう 基本的な要素・機能を提供するCore ElementsとMaterial Designを実現するPaper Elements Web Components を司る4つの仕様、Custom Elements・Template・Shadow DOM・HTML Importsは、確かに HTML/CSS の弱点を解決してくれる。 しかし、作られた・配布されているコンポーネントを使う側はともかく、Web Components の仕様を抑えてコンポーネントを構築していくのは、HTMLにCSSでスタイリングをしていく従来のやり方に比べていささか敷居が高い。CSS の言語としての簡易さと引き換えに顕在化してきた弱点にフォーカスされているから Shadow DOM のありがたみがあるものの、Web Components によるコンポーネント実装と配布が一般化するかについては、いささか疑問符が残る。 CSS の設計に悩まなくなる点は前進しつつ、コンポーネント化する単位といったような Web Components を使っていく難しさに問題は引き続きあるだろう。 Web Componentsの技術そのものへの敷居 CSS の問題を取り払いたいだけのはずなのに、Shadow DOM を使う敷居が高い。もっと言えば宣言的 (Declarative) から命令的 (Imperative) への思想の移行はプログラマでない人にとっては辛いかもしれない。 <template> <style> input {} button {} </style> <input type="text"> <button>Button</button> </template> <script> var ownerDocument = document.currentScript.ownerDocument; var SampleElementPrototype = Object.https://1000ch.net/posts/2015/hugo-boilerplate/Sun, 22 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/hugo-boilerplate/Hugoのドキュメンテーションはとても充実していて良いのだが、最小構成がそもそも小さいのでコードレベルで把握してしまったほうがわかりやすい可能性がある。 1000ch/hugo-boilerplateは、Hugoの主な機能を最小限の形にまとめたリポジトリ。 HugoのインストールとHugo Boilerplateの利用 HugoはHomebrewでインストール。既にインストールしてある場合はアップデートすること。 $ brew install hugo $ brew update インストールしたらリポジトリをクローンして、npm startするだけ。 $ git clone git@github.com:1000ch/hugo-boilerplate.git $ cd hugo-boilerplate $ npm start npm startはhugo server --watchのエイリアスで、実行されるとlocalhost:1313で表示できる。--watchオプションでファイルを監視しているので、更新があるとリアルタイムにビルドが実行される。 ファイル構成 Hugo Boilerplateのファイル構成は以下のようになっている。Source Organizationに詳細がのっている。 content・layouts・staticフォルダ contentとlayoutsはその名の通りコンテンツとそれをレイアウトするファイルを配置するフォルダ。 content配下にサンプルのMarkdownをいくつか置いてあるが、content/archives/sample-post.mdであれば [DocumentRoot]/archives/sample-post.html に変換される。 layoutsにはarchives・indexes・partialsフォルダがあるが、大枠を構成しているのはarchives/single.htmlというファイルで、先ほどのcontent/archives配下のMarkdownファイルはこちらをレイアウトとして利用する。また、_defaultフォルダに同じくsingle.htmlを作れば、明示的にレイアウトファイルを用意しない場合に参照される。 partialsフォルダには共通となるHTMLを切り出して、archives/single.htmlからインクルードしている。indexesフォルダにはarchives.htmlがあるが、これはcontent/archives配下のコンテンツを列挙する命名規則。 staticフォルダにはCSSやJSのような静的ファイルを配置する。 各種設定ファイル .editorconfig .gitignore config.yml Hugoの設定ファイル。設定すべき項目はおおよそ指定してあるけど、さらなる詳細はConfiguring Hugo readme.md リポジトリのREADME wercker.yml Werckerの設定ファイル。 この辺は好みに応じて編集すべきファイル。.editorconfigがわからない人はEditorConfigで文字コード設定を共有して喧嘩しなくなる話 | Ginpen.comを見ると良い。 package.json bower.json gulpfile.js Gulpで静的ファイルをビルドし、staticフォルダに配置するようにしている。Hugoの--watchもあるので、ターミナルの別タブでgulp watchをすると静的ファイル群の監視ができるので、プロジェクトのレイアウトやJSでの構築といった段階では必須になるかも。 Werckerによる自動デプロイ Hugoの成果物（ビルド結果）は_publicフォルダに出力されるので、ホストサーバーにはそれを配置すれば良い。が、GitHub Pagesで運用している場合はWerckerを使った運用をオススメしたい。 Automated deployments with Werckerに完璧なドキュメントがあるので割愛するが、wercker.ymlは作ってあるのでWerckerからGitHubのリポジトリにアクセスするためにGitHubのトークンを作ってジョブに登録するだけ。 これで、masterブランチにpushするとビルド結果が_publicフォルダ配下がgh-pagesブランチにpushされる。https://1000ch.net/posts/2015/bundle-binary-in-mac-app/Sat, 21 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/bundle-binary-in-mac-app/WebPonizeには画像をWebPフォーマットに変換するために、WebM Projectにて配布されているWebPのライブラリ群をバンドルする必要があった。 A new image format for the Web - WebP — Google Developers cwebpをバンドルして実行するアプローチ 実行可能形式のcwebpをプロジェクトに配置して、Swiftから実行する。バンドルされたcwebpへの参照はNSBundleを、実行はNSTaskを使えばできる。以下の様な雰囲気。 func execute() -> String { let task = NSTask() let pipe = NSPipe() task.launchPath = bundle.pathForResource("cwebp", ofType: "") task.currentDirectoryPath = "~" task.arguments = "-q 80 input.png -o output.webp" task.standardOutput = pipe task.launch() let data = pipe.fileHandleForReading.readDataToEndOfFile() return NSString(data: data, encoding: NSUTF8StringEncoding)! } iTunes Connectにsubmitできない いざMacのストアにsubmitしようとすると、同梱物に実行可能ファイルがあるので怒られる。厳密に言えば、その実行可能ファイルにも自分（ここでは私）が書いたプログラムの一部だということをセキュリティ的に証明する必要がある。よくよく考えてみれば正体不明な実行可能ファイルをバンドルできてしまったら大変なことになりそうだ。納得。 自分で書いているSwiftのコード（というかコンパイルした成果物）に対してはCode Signと呼ばれるMacのディベロッパーとしてiTunes Connectに登録すると得られる証明書が、Xcodeがビルド時に付与される。 コンパイル済バイナリへのCode Sign cwebpに自分のCode Signを付与することが良い事か悪い事かは一旦置いておいて、できるかどうか試した。 $ codesign --entitlements .https://1000ch.net/posts/2015/bose-soundlink-mini/Fri, 20 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/bose-soundlink-mini/BOSEのSoundLink Miniがとてもオススメ。 コンパクトな本体 本体は片手で掴んで持ち運べるくらいコンパクト。また、充電式になっているので、充電されていれば好みの位置において再生することができる。もちろん充電クレードルに置きっぱなしで再生することもできるので、用途に合わせて使えば良い。重さも655gと軽いので、充電させて持ち運んで、移動先で楽しむこともできそう。 自分はMacやらiPhoneからBluetoothで接続しているが、φ3.5mmステレオミニジャックの入力部があるのでBluetooth非対応の機器でも利用することができる。 パワフルな出力 コンパクトな本体の割に低音域がとても良く出る。Macの出力とは違う音楽を聞いてるくらい良い音。5.1chサラウンド〜みたいな超本格的なものとは比較できないけど、個人用途では十分な音質と出力かと思う。この辺りはさすがBOSEといったところ。 外形寸法 180(W) x 51(H) x 59(D)mm 質量 655g カラー シルバー 電源電圧 AC 100V-240V (50/60 Hz)(専用電源アダプター使用) 外部音声入力 φ3.5mmステレオミニジャック×1 防磁対応 非防磁 付属品 充電クレードル、専用電源アダプター ※公式ホームページより引用 買って損はない 気軽に買える価格ではないかもしれないが、コンパクトすぎる本体とパワフルな音質出力を考えれば、コストパフォーマンスはとても良いと思う。 ウルトラコンパクトな本格サウンド。音楽をどこにでも持ち運べます。Bluetooth 対応機器の音楽をワイヤレス接続で楽しめる。サイズからは想像もつかない本格サウンド。高いデザイン性と簡単な操作性 コンパクトスピーカーでは最強かも。https://1000ch.net/posts/2015/webponize/Wed, 11 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/webponize/最近はSwiftを書いている。 作っているのはMacアプリでWebPonizeというもの。名前で察しの人もいるかもしれないが、PNGとかJPEGといったフォーマットの画像をアプリにドラッグアンドドロップしてWebPに変換する、というシンプルなアプリ。Swiftの練習できればiOSでも良かったんだけど、こんなのあったら便利だなという妄想をしているとどうしてもディベロッパー向けのツールになる。 WebPonizeという命名については、名詞に~izeという接尾語をつけることで「〜らしくなる」のような形容詞になることをもじってWebP + nizeに。尚且つ、同僚のアメリカ人に発音を考慮してもらってWebPonizeになった。WebPはbを発音しないので、weapon（武器・兵器） + izeになることを想定。 見ての通り、ImageOptimの見た目をパクって踏襲している。 Cocoa + Swiftの情報がネット上に少ない MacのアプリはCocoaというフレームワークを使うのだけど、iOSのSDKやらに比べると圧倒的に記事の量が少なくて調べるのに苦労した。本家のドキュメントはあるもののコード例が少なくて試すことすら出来ないし、所々古かったりして辛い。Objective-Cでもいいんだけど、それすらない（あっても古いSDKの記事だったりする）。 Xcodeが難しい 最初はSwiftでプログラムを書くことよりXcodeの操作が辛かった（特にAutoLayout周りとIBOutlet / IBAction周り）。GUIをエディタで作っていく作業は、WindowsのクライアントアプリをVisualStudio + C#で作った以来だけど、操作云々については慣れの問題だと思うので先程の問題と違ってどうにでもなる。 App Storeに出す手順が難しい こちらも現在進行中で辛い問題で、解決出来ていない。実際、アプリの実装自体は2週間くらいでおおよそ終わっていたけど、いざストアに公開しようとすると、Developer登録とかアプリの認証情報とか、バンドルするバイナリにサンドボックス情報を追加するだとかで、色々難航している。iTunesコネクトがイマイチ分からない。さらに、これまたネット上に新しい情報が少なくて辛い。なので、App Storeへの公開は今暫くお待ちください。https://1000ch.net/posts/2015/url-opener/Tue, 10 Mar 2015 00:00:00 +0000https://1000ch.net/posts/2015/url-opener/自分用に作ってしばらく放置していたChrome Extension「URL Opener」をアップデートした。 URL Openerの機能 ブラウザ常に開いておきたいページは誰しもあると思うが、毎度アドレスバーに打ち込んだりブックマークから開くのも面倒なので、ワンクリックでやろうというコンセプト。オプションページ（拡張機能のアイコンを右クリックか、chrome://extensionsから開ける）で開いておきたいページのURLを登録する。あとはExtensionのアイコンをクリックするだけ。ついでに、そのページをピン止めして開くかどうかも指定可能。既に開かれている場合は、ピンし直すようにしている。 ソート機能 アップデートしたきっかけはSupportに機能要望があったからなんだけど、確かにあっても良い機能だと思った。追加したURLをドラッグアンドドロップで順番を入れ替えできるようにした。タブを開く時に、ここで指定した順番通りに並び替えられるようにしている。 しかし、仕様かどうか不明だがピン止めしているタブの並びまではコントロール出来ないようなので、ちょっと中途半端になってしまった気もするがこれも仕様とすることにする。タブの順序まで気にする人が果たしてどれだけいるのかわからないけど。 この要素の並び替えの実装はSlipというライブラリを使った。タッチデバイスのほうが力を発揮するライブラリなんだろうけど、機能を活かして、URL Openerでも登録したURLをスワイプで削除できるようになっている。https://1000ch.net/posts/2015/service-worker-passive-cache/Fri, 27 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/service-worker-passive-cache/前略（Service Workerとはなんぞやという方はこちら）、キャッシュさせたいリソースをService Workerのインストール中に全てインストールさせている例が多いが、そのリソース全てをキャッシュさせることを保証しなくても良いケースが大半だと思う（オフライン化ではなくパフォーマンス向上という観点だと特に）。 優先度を付ける 以下、Service Worker内の処理（The offline cookbookから拝借）。event.waitUntil()及びその中の処理はPromiseでチェーンされているので、Promiseを返却しているcache.addAll()はキャッシュが確実に行われるが、チェーンさせていないcache.addAll()はキャッシュ作業が実施されるものの保証はされない。 self.addEventListener('install', function(event) { event.waitUntil( caches.open('mygame-core-v1').then(function(cache) { cache.addAll( // キャッシュ作業が実施されるけど保証されない ); return cache.addAll( // 保証される（失敗しなければ） ); }) ); }); 優先度の高いリソースだけ保証させるとか、リクエスト数とのバランスも含めて設定すると良さそう。仮に、キャッシュリソースを100個設定して、何らかの理由でダウンロードが1つでも失敗すると、そのService Workerにインストールは失敗したことになるので、fetchイベントで行うはずのプロキシも適用できなくなってしまう。 消極的にキャッシュする もっと言えばinstall中にキャッシュをせずとも、fetchイベントでキャッシュをチェックし、見つからずにfetch()してきたリソースをキャッシュのように、消極的なキャッシュでも良い気がしている。 self.addEventListener('fetch', function (e) { e.respondWith( caches.open(CACHE_KEY).then(function (cache) { return cache.match(e.request).then(function (response) { if (response) { // e.requestに対するキャッシュが見つかったのでそれを返却 return response; } else { // キャッシュが見つからなかったので取得 return fetch(e.request.clone()).then(function (response) { // 取得したリソースをキャッシュに登録 cache.put(e.request, response.clone()); // 取得したリソースを返却 return response; }); } }); }) ); }); インストール時にキャッシュするのかどうかの差であって、発生するリクエスト数は同じだし、インストールの失敗リスクを避ける意味でも選択肢として有りかとは思う。このコード例だと発生しているリクエストを全てキャッシュしてしまっているので、e.https://1000ch.net/posts/2015/farewell-docpad-hello-hugo/Tue, 24 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/farewell-docpad-hello-hugo/Hugoはじめました。 DocPadからHugoへ 1000ch.netというドメイン自体は2009年から持っていたけど、技術ブログを書くようになったのは2012年11月から。暫くはJekyll+GitHub Pagesでホストしていたけど、ビルドが重かったり、GitHub Flavored Markdownが使えなかったりの不満を感じて途中でDocPadに移行。 Jekyll時代 JekyllはRuby製の静的サイトジェネレータ。GitHubの公式サポートが得られるっていうこともあったし、@cssradar氏がJekyll | CSS Radar | Little Books For Front End Developersという記事を書いていたこともあって、スクラッチで書き始めた。それまでは、なんとなくレベルでWordPressを立てていた。 JekyllはGitHub製というだけでなく、GitHubのusername.github.comというリポジトリ、もしくはその他リポジトリでもgh-pagesブランチであれば、Jekyllのプロジェクトソースをコミットすることで自動でコンパイル・デプロイが行われる。他の静的サイトジェネレータであれば手元でビルドした結果なり、CIサーバーでビルドした結果の静的リソースをそれらのリポジトリにコミットしないとGitHub Pagesとして公開されない。そんなに手間でもないけど、ブランチが汚れないしお手軽である。 移行はしたけど、決してモノが悪いというわけではない。実行速度も改善されてきたという噂もあるし、僕が移行したのは、重さに不満をもったというよりはNode.js製のCMSに変えてみようかなーと、その程度のものだったと思う。 DocPad時代 DocPadはNode.js製のJekyllリプレイスとも言われる静的サイトジェネレータ。巷ではOctpressとかも流行っていたけど、DocPadを選択。Jade・Stylus・RSS出力などなど、いろんな機能がプラガブルに追加できたし、使い勝手もそこそこ良い。ちなみに自分が構築周りをやったJS Girlsのサイトでは、DocPadを採用している。 しばらく不満のないブログ生活を送っていたけど、いつの間にかビルド時にDocPadがコマンドラインでプロジェクトに寄付を求めるログを出すようになってきたのと、パーシャル化したり記事が増えるに連れて（DocPadの仕事が増えるに連れて）ビルドに時間がかかるようになってきた。寄付はさておき。ビルド時間の短縮のために、JadeにしていたところをHTMLにしたり、パーシャル化していた部分をマージしたり、地道な工夫を凝らしていたんだけど、システム的な想像をツールに抑止されるのもアレだよなぁとか。 Hugoにした Hugo自体はもっと前から知っていた（きっかけはまたもや@cssradar氏なんだけど）けど、まだツールとして成熟していなくてあまり興味が向いていなかったところ、ちょろちょろと「Hugoに移行しました」という記事を見かけるようになった。 OctopressからHugoへ移行した - SOTA Jekyllが許されるのは小学生までだよね - Mol 仕組み周りを移行する（しかも今回はデザインもそのまま移植する）のは腰の重い作業なんだけど、やってみたらビルドは速いのなんのって。30秒くらいかかっていたビルドが0.1~0.2秒で終わるもんで、最初はバグってるんじゃないかと思ったくらいだ。これを体感してしまうとそこまで重さを感じていなかったDocPadも余計に重さが相対的に気になってくる。 おおよその作業（デザイン移植とコンテンツ作成）は1時間くらいで終わったんだけど、ページングとかRSSの生成みたいな細かいところのデバッグにかなり時間（2時間くらい）を取られた。わからないところを手探りでやるのは、コレに限らず辛い作業だとは思うんだけど、たまにこういうことしないとダメだね。新しい技術を触るのってやっぱ大事なことだと思ったのでした。そして、終わってしまえばかなり快適。t32k/molに習って、werckerでmasterにプッシュしたら自動でデプロイされるようにした。 自分は完全移行を目指したから無駄に苦労した部分があるけど、Hugoにもデフォルトでよさ気なテーマがあるのでそれを使えば楽だし、それをちょっとずつカスタマイズするほうが良さそう。英語だけど、ドキュメントもとても充実しているのでオススメ。成果物は1000ch/1000ch.net。https://1000ch.net/posts/2015/wdpress-frontend-series-es6/Mon, 23 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/wdpress-frontend-series-es6/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.85が2月24日に発売されます！連載5回目はECMAScript 6の概要・歴史、主要な追加機能、ブラウザサポートが不完全な今どのように取り入れるか等等を書いています。 はじめようトランスパイラ生活 JSerならES6を聞いたこと無いっていう人は流石にいないと思うが、もう「まだ先だからいいでしょ」って言ってられる段階ではなくなってきてると思う。 現状ブラウザサポートは弱いけど、今から使っていくために出来る工夫はいくらでもあって、Chrome ExtensionsやFirefox Add-onのように実行環境が限定されるツールを作る時に書いてみるとか。比較的大きめプロダクトだとしても、トランスパイラが賢くやってくれるのでビルド前提でコード書いていくのもコスパの良い投資。 iojsも--harmonyフラグなしでES6のシンタックスが使えるし、 Node.js 0.12向けでもブラウザ向けでもトランスパイル前提で書いていくとか、いくらでもやりようはある。 画像をdataURIに変換するライブラリをES6で書きなおす もうES6 (ES2015) でいいんじゃないか 6to5がbabelに 記事内で紹介しているES6→ES5のトランスパイラである6to5が、原稿が入稿された後にbabelに名前が変わるという悲劇が起こってしまったのでご注意ください。こちらは別途アナウンスがあると思います。どこかから。 菅原 元気 (著), 磯辺 和彦 (著), 山口 与力 (著), 澤登 亨彦 (著), 濱田 章吾 (著), 宮田 淳平 (著), 松本 亮介 (著), 海野 弘成 (著), 佐藤 歩 (著), 泉水 翔吾 (著), 佐藤 太一 (著), hide_o_55 (著), 青木 良樹 (著), 武本 将英 (著), 道井 俊介 (著), 伊藤 直也 (著), 橋本 翔 (著), 渡邊 恵太 (著), 舘野 祐一 (著), 中島 聡 (著), はまちや2 (著), 竹原 (著), 牧 大輔 (著), 工藤 春奈 (著), WEB+DB PRESS編集部 (編集) よろしくお願いします(´・ω・`)https://1000ch.net/posts/2015/frontrend-conference/Sun, 22 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/frontrend-conference/Frontrend Conferenceを以って、Frontrendが活動を休止。過去最大規模に因んで、カンファレンスという名前で開催された。そんな中、スピーカーとして混じって参加してきた。 Introduction to Service Worker 日本語・英語を問わずService Workerに関する資料が少なくて調べるの結構大変だったけど、なんとか漕ぎ着けた。発表も45分に収まらなくて、後半の一部を端折ってしまったけど、伝えるべきは前半の「オフラインWeb」だと思っていたので、あまり後悔していない。 端折ったデモです。えーじさんのPolymerデモをService Workerでオフライン化してます https://t.co/aT8FwWwAMV #frontrend — 1000ch (@1000ch) 2015, 2月 21 Service Workerで派手さを出すデモは難しかったので、オフラインでも使えるTODOアプリケーションを作った。 navigator.onLine navigator.onLine、Android2、PhantomJSで注意 #frontrend — 過激派 (@kyo_ago) 2015, 2月 21 ブラウザサポートはおおよそ大丈夫ってセッション中に言ってしまったが、PhantomJSは完全に失念していた。agoさんありがとうございます。 Service Workerコンテキストのデバッグ @1000ch ServiceWorkerについて質問めっちゃあるんですがあとで質問しにいっていいですか！ — 理解者 (@mizchi) 2015, 2月 21 「ServiceWorker 内に console.log 仕込んだのに、ログが出ない」は初心者あるある。ワーカ内のログは ServiceWorker 専用のコンソールにしか出ない。 #frontrend — Jxck (@Jxck_) 2015, 2月 21 mizchi氏、見かけたことは何回かあったけどちゃんと話したのは初めてだった。 1点目はService Worker中に仕込んだconsole.logはどこに吐かれるのっていう質問。Chromeだとchrome://serviceworker-internalsにデバッグページがある。ここで、登録されたService Workerが列挙されるので、デバッグしたいService Workerを選択肢てInspectをクリックすると、Service WorkerコンテキストのDevToolsが立ち上がる。 2点目はatom-shellで作っているアプリに仕込むService Workerの話で、やや凝った話だったので意見レベルでしか言えなかった。atom-shellで作っているアプリのコードを実際に見れたらもうちょっと喋れるかも。ちょっとすると強い人達がやってきてちょっとした議論になって、こういうのいいなーと思った（小並感）。 ほかのセッション Pragmatic Front-end Developer: From Artisan to Expert ぐっとくる話だった。やや重い。https://1000ch.net/posts/2015/panasonic-petit-drum/Sun, 15 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/panasonic-petit-drum/もともと洗濯は好きだった方だけど、ドラム式洗濯乾燥機という高価な買い物を久々にしたら、快適になり過ぎてパンツが吹っ飛んだ話。 Point.1 「洗濯から乾燥まで全自動」 それまでは、いわゆる一槽式の洗濯機を使ってた。今どきは、乾燥までやってくれるタイプの一槽式もあるみたいだけど、自分が使っていたのはもちろん脱水まで。雑巾絞りの後のようになった洗濯物を、ハンガーや洗濯干を駆使して一つ一つ干していた。 ところがドラム式洗濯乾燥機は、洗濯した服がふっくらホカホカの状態で出てきてくれるので、あとは畳んでしまうだけ。急ぎであればそのまま着ても気持ちいい。 だから、 乾燥場を使うこともないし、雨の日に干す場所に悩むこともない。洗った洗濯物を忘れて、生乾きなんてこともない 。 もちろん「洗濯→乾燥」だけじゃなくて、「洗濯だけ」「乾燥だけ」のコースもあるので、洗濯・乾燥のどちらかだけやりたい場合でも大丈夫。私の場合は、シャツやボトムス類はシワにならないように洗濯までして、その他のTシャツやタオル等は乾燥しても問題なさそうなので、フルコースにしている。 Point.2 「ヒートポンプ乾燥で衣類が縮みにくく、電気代も安い」 「ドラム式洗濯乾燥機で乾燥したら、衣類が縮んだ！」なんていう話もチラホラあるようだけど、自分の場合はこれに遭遇したことがない。購入した洗濯機の乾燥はどうやらヒートポンプという技術で乾燥をしているらしく、より少ないエネルギーで乾燥できる上に、従来よりも縮みにくいらしい。 以下Wikipediaより引用。 ヒートポンプ（英: heat pump）は、熱媒体や半導体等を用いて低温部分から高温部分へ熱を移動させる技術である。手法はいくつかあるが主流は気体の圧縮・膨張と熱交換を組み合わせたもので、一般家庭でもみられる製品でヒートポンプを使っているものとして冷凍冷蔵庫、エアコン、ヒートポンプ式給湯器などがある。 縮みにくいとはいえ、高価な服だったり、シャツみたいにシワを付けたくない部類の洋服は乾燥までしないほうが無難そう。大事をとって洗濯だけのコースにして、今までどおりハンガーで干す方が安全かと思う。 Point.3 「コンパクトでスペースを取らない」 ドラム式乾燥洗濯機というと、かなり大型なイメージがあったけど、各メーカーが一人暮らし向けのドラム式のラインナップを出しているそうで、これもその中のひとつになる。 当方ワンルームだけど、搬入に苦労することもなく備え付けの洗濯機置き場にすっぽり収まった。 幅・奥行きともに60cmに収まれば問題無い ようで、一般的な集合住宅の洗濯機置き場であれば充分に満たしているサイズみたい。 洗濯容量は7.0kg。乾燥容量は3.5kg。一人暮らしであれば充分な容量だし、干す手間が省ける分こまめに洗濯するようになったので、洗いきれずに大変ということもない。 まとめ その他の機能としては「エコナビ」「自動槽洗浄」「泡洗浄・ダンシング洗浄」「お急ぎコース」と、至れりつくせり。 場所・天気と干すことに気を遣わなくなったし、洗ったものはホカホカふっくら出てくるし、何より 洗濯という家事に対して、かける時間が減ったのに満足度がグッと上がった 。 QoL挙がること間違いなし。https://1000ch.net/posts/2015/hackers-and-painters/Wed, 04 Feb 2015 00:00:00 +0000https://1000ch.net/posts/2015/hackers-and-painters/これを初めて読んだのはプログラマーとして駆け出しの頃だったと思う。著者は、（当時知らなかったが）かの有名なポール・グレアム（Paul Graham）だ。 コンピュータに向かってプログラムを書き続けるハッカーと、創造を凝らして作品を描き上げる画家は一般的には対照的に映るかもしれないが、その実とても通じる部分があるのではないかという話。ハッカーと画家が似てる云々という命題より、その側面をなぞるエッセイがとても面白い本。 プログラムは、人々がそれを読むために書かれるべきである。 プログラマーに、あるいはそれを志す人に一読して欲しい。プログラマーとしてのスタンスを考えさせられる内容。 ポール グレアム (著), Paul Graham (原著), 川合 史朗 (翻訳) ポール・グレアムについてはLisperというよりはY Combinatorの創始者としての印象が強い。Y Combinatorはスタートアップへの投資を行うベンチャーキャピタルだ。 Y Combinatorが輩出した企業はDropbox、Airbnb、Heroku、Redditなど、今となっては有名なものばかりである。最も特徴的なのは、資金援助を行う他、ポール自身がそのスタートアップに対して指導を行う点だ。 他のVCと比較しても別格のスタートアップ企業を輩出している実績も、氏の指導あってこそだろう。https://1000ch.net/posts/2015/polymer-is/Fri, 30 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/polymer-is/Polymerを使ったWeb Componentsに<twitter-button>、<facebook-button>、<gplus-one>・<gplus-follow>がある。Polymerのバージョンが古かったのでプルリクエストを送ったんだけど、修正しながら考えてたことを書いてみた。 Polymerに依存するWeb Components Polymerで作ったWeb Componentsは、jQueryとそのプラグインの関係に似てると思ってる。それが配布されることを考えてみよう。 そのコンポーネントのバージョンはPolymerのバージョンに依存することは、使いたいコンポーネントが依存するPolymerが複数存在してしまう可能性を示唆している。Polymerがまだベータ版で後方互換性のない変更が起こる可能性を考えると、依存バージョンがてんでバラバラのWeb Componentsが散乱しかねないんじゃないかと。 実際、Polymerの0.8previewでは、Web Componentsの定義を<polymer-element>ではなく、<template> + <script>に変更するっぽい。この変更については素のWeb Componentsとの互換性を加味したアップデートかもしれないけど、今まで<polymer-element>で作成してきたコンポーネントは早くも埃を被る結果になってしまう。 このように、Polymerを使ったWeb Componentsを配布することには、現段階ではややリスクがあるかなと思っている。ただ、配布はしないにしてもプロダクトには何の躊躇もなく使ってしまいそうではある。 不可能を可能にする ブラウザデフォルトでは実行できなそうなコードもPolymerの手にかかれば動いてしまう。以下の2つを例示。 Shadow DOM配下のlink要素は無効である 7.1 Inert HTML Elements A subset of HTML elements must behave as inert, or not part of the document tree. This is consistent how the HTML elements would behave in a document fragment. These elements are: base link All other HTML elements in the shadow trees must behave as if they were part of the document tree.https://1000ch.net/posts/2015/http-spdy-http2/Thu, 29 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/http-spdy-http2/Webの通信プロトコルとして普及するHTTPも、HTTP2に向かって大きな変貌を遂げようとしている。最初期のHTTP0.9からどういう変化をたどってきたのか気になったので、調べたメモ。ネットワーク・HTTPの予備知識にWebにおけるネットワーク通信もどうぞ。 各プロトコルの特徴 HTTP0.9からHTTP1.0になった辺は割愛。ログイン状態みたいに状態を保持する機構のためにCookieが登場したり、80番ポートがデフォルトになったりしたのはこの辺りらしい。 HTTP1.0からHTTP1.1にかけてとそれ以降は、急速に進化し肥大化してきたWebコンテンツを支えるための変遷。データは大きくなるし、リクエストも増加の一途を辿ってきたのでネットワークにも進化が要求されている。 HTTP1.1 IPアドレスだけでなくホスト名で通信相手を特定できるようになった（HOSTヘッダのサポート） TCP接続を維持する機能が追加された（Keep-Alive） リクエストヘッダー・レスポンスヘッダーがテキストフォーマット ひとつのTCPコネクションにつき、ひとつのリクエストとレスポンス それぞれのTCP接続が独立して輻輳制御を行っている SPDY HTTPをベースに高速化が図られた、Googleが開発するプロトコル HTTP1.1の作法は変わらないので互換性があり、既存環境とも共存できる 接続手順やセッション管理といった部分の効率化がなされた セッション層を使うためTLSが必須、つまりHTTPS環境において利用可能 TLS連携からのプロトコル自動選択や、HTTPヘッダの圧縮 HTTP2に継承された通信の優先度付多重化とサーバープッシュ HTTP2 SPDYをベースに考案されたプロトコル リクエストヘッダー・レスポンスヘッダーがバイナリフォーマット ひとつのTCPコネクションにつき、複数のリクエストとレスポンスが可能（仮想ストリームチャネルによる多重化） クライアントからのリクエストがなくともレスポンスをプッシュできる（サーバープッシュ） ストリームに優先度を指定可能で、後方のリクエストでも前方のリクエストより優先度が高ければそちらを優先して返却する（HTTP2プライオリティ） ブラウザでは最新のChromeとFirefoxで有効であり、IEではテクニカルプレビュー HTTP・HTTPS（平文でもOK）を問わず、TLS利用は必須ではない chrome://net-internals/#spdy 仕様策定については、RFC標準化目前ぽい。IETFのHTTPワーキンググループがメンテナンスしているHTTP2の公式サイトにも、デカデカと書かれている。 IETF Last Call HTTP/2 and HPACK are currently in IETF Last Call. HTTP/2とService Workerで実現するWeb Push Service Workerに関する仕様とか機能とかの最後で触れているが、Push APIというものがある。こちらはお待ちかねのWebでPushを実現するAPIだが、このサーバーから送られるメッセージはService Workerが受け取る、つまりPush APIの利用にはService Workerが要るわけだ。更に、HTTP1.1まで出来なかったサーバーからのPushは、HTTP2の双方向シーケンスによって可能になる。何が言いたいかというと、Web Pushは両者によって初めて成り立つ機能ということ。以下、ざっくりとした手順。 Service Workerがプッシュサーバーに対し、クライアントの登録をする プッシュサーバーにポーリングしつつ、通知用のプッシュチャネルを作成する プッシュサーバーへの登録情報をアプリケーションサーバーに登録する アプリケーションサーバーに通知イベントが発生したら、プッシュサーバーにデータを渡す 通知用に作成されたプッシュチャネルを使って、プッシュサーバーからService Workerにデータを渡す 詳細はService WorkerとHTTP/2が切り開く新しいWeb Pushの世界という記事を見て下さい。死ぬほどわかりやすいです。 双方向通信といえばWebSocketを思い出す。Service WorkerコンテキストにもWebSocketはいるみたいだし、同じようなことをWebSocketでやる話ってあるんだろうか。HTTP2でWebSocketを取り込む話をどこかでチラッと見かけた気がする。けど、気のせいかもしれない。この辺の情報、誰か下さい(´・ω・`) 参考リソース SPDY - The Chromium Projects HTTP/2の現状とこれから - SlideShare 2015年1月25日 A Simple Performance Comparison of HTTPS, SPDY and HTTP/2 - HttpWatch 2015年1月16日 HTTP/2 を追いかけて - SummerWind 2014年12月25日 Service WorkerとHTTP/2が切り開く新しいWeb Pushの世界 - 2014年12月4日 HTTP/2 入門 - Yahoo Developer Network 2014年6月19日 Web表示の高速化を実現するSPDYとHTTP/2.https://1000ch.net/posts/2015/high-performance-javascript/Sat, 24 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/high-performance-javascript/昔買ったN.Zakasの本を掘り当てたので読みなおした。 2年前に買った本を掘り当てたので読み返してみる A photo posted by 1000ch (@1000ch) on Jan 23, 2015 at 4:25pm PST ハイパフォーマンスなJavaScriptとは 今やJavaScriptはブラウザに留まらないので、一口にハイパフォーマンスなJavaScriptを括るのは難しい。この本に関しては Build Faster Web Application Interfaces とあるようにブラウザ環境におけるJavaScriptにフォーカスしている。 ブラウザのJavaScriptと言っても、Webアプリケーションの形態も多種多様になってので、最適化の形もケースバイケースとしか言えない。最適化アプローチの選択肢を増やすための本と言える。アプリケーションが複雑化してもブラウザで何が起こっているかわかれば、自ずとすべきことが見えてくる。この本にはそういうことが書かれている。 Nicholas C. Zakas氏 (@slicknet) について JavaScript界隈では有名な人なので、前のめりな人なら知っている人も多いと思う。Yahoo!のリードディベロッパーであり、YUIのコントリビュータも務めていた人。今はBoxで働いているそうで、最近はES6/ES7の仕様に口出ししたり、ESLintにコミットしてる様子。この本以外だとメンテナブルJavaScriptが有名。 ブログも濃い記事ばかりなので、英語が苦手じゃなかったら読んでみて欲しい。英語が苦手でも読んでみて欲しい。 ブラウザJavaScriptの最適化に向けて 前述の通り、プログラムのアルゴリズム的な部分だけを取り扱っているわけではなく、ブラウザの描画をブロッキングしないために<script>をどう考えれば良いかであったり、DOMスクリプティングを効率的に実行するにはどうすればいいかなど、JavaScriptから作用しうるパフォーマンスのファクターについて網羅的に書かれている。 目次 読み込みと実行 - JSファイルロードの妙技 データアクセス - グローバルへのアクセスコストやスコープの話 DOMスクリプティング - 効率的なDOM操作・イベントのハンドリングについて アルゴリズムと処理の制御 - ifや再帰等のアルゴリズムの最適化 文字列と正規表現 - 文字列処理と正規表現、及びそれらの連携 反応性のよいインターフェイス - ブラウザスレッドを邪魔しないために Ajax - XMLHttpRequestのイロハと使いどころ プログラミングの実践的手法 - 4章を発展させた話 高パフォーマンスなJavaScriptアプリケーションのビルドと配置 - デプロイする前にやっておくべき、結合・圧縮・キャッシュ等について ツール - 各ブラウザベンダーのデバッグツールについて 実行上の最適化についてはV8をはじめとしたJavaScriptエンジンの進化が進みすぎて、何もせずともブラウザが気を利かせてしまう可能性もあるけど、知っておくに越したことはない。Tipを集めることより、ブラウザで何が行われるかを理解するほうが本質である。 JavaScriptのMVCがどうとか、流行り廃りのあるライブラリや思想より、Webを作っていく上で大事で必要な知識だと思う。逆にこの本をおさえておけば、いま巷で話題の技術にも、これから現れるであろう新たな流行にも応用が効く。2011年刊行ということで、10章のツール部分は流石に古さがあるけど、駆け出しWebエンジニアが読むべき内容が詰まっている。 Nicholas C. Zakas (著), 水野 貴明 (翻訳)https://1000ch.net/posts/2015/html5-cook-book/Thu, 22 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/html5-cook-book/読みなおした。 バズワード A photo posted by 1000ch (@1000ch) on Jan 23, 2015 at 4:27pm PST バズワードとしてのHTML5とリビングスタンダード HTML5の草案が発表されたのが、ちょうど7年前の2008年の1月22日。そして、2014年10月28日に勧告されたのも記憶に新しい。段階的に対応してきたブラウザベンダーも、最新版ではすっかり対応がされている。 色んな尾ひれを生やして急速に広まった印象があるHTML5だが、どこからどこまでがHTML5なのか認識が人によって曖昧なところがある中で、この本では次の内容を取り扱っている。 目次 基本的な構文とセマンティクス プログレッシブなマークアップとテクニック フォーム ネイティブオーディオ ネイティブビデオ マークロデータとカスタムデータ アクセシビリティ 位置情報 <canvas>要素 高度なHTML5 JavaScript - ローカルストレージ・Web Worker等の新たなブラウザAPI群について 5回目の改定ということでHTML5だけど、そういった括りも、段々とバージョン（エディション）を意識しないようになってきているなと思う。HTMLの仕様はHTML5として捉えるべきではなく、あくまでHTMLとして捉えるべき。HTMLの仕様は常に更新される。 HTML5におけるマークアップ 8章の位置情報、9章の<canvas>要素、10章のAPI群に加えて各所にJavaScriptからの取り扱いの解説が散りばめられているが、個人的にはHTMLに追加されたマークアップとしての機能が印象的だった。 ブラウザの対応状況見てると改めてIE8以前の辛さを感じる。もちろん、バージョンを明確に分けて後方互換性を保ってきた故のことだけど。先日新ブラウザの発表もあったので、流れは少しずつ変わってくるとは思うが、それでもエンタープライズ等での対応を考えたりすると、未だに足枷になっていることと思う。こういった対応していないブラウザへのフォールバックについても、本書では触れている。normalize.cssとModernizrの偉大さたるや。 <input>要素に追加された新たなtypeについてだったり、フォームの必須属性はrequiredとしたり、hiddenとか<details> + <summary>だったり。JavaScriptでコントロールすることが開発する中で当たり前になってしまっているので、HTMLレベルで実現される振る舞いについては知らないことばかりであった。 アクセシビリティの章もあるが、本来こういった属性を適切に指定したり、ドキュメント構造を意識すべきなんだと思う。「開発者同志で齟齬が出るくらいなら全部<div>で！」という意見もおおよそ同意な部分もあるけど、適切に実施出来るならやっておくに越したことはないのも間違いなさそう。 Christopher Schmitt (著), Kyle Simpson (著), 株式会社クイープ (翻訳) HTML5は、既にバズワードではなく当たり前になってきている。HTMLの知識をアップデートしたい人にオススメ。https://1000ch.net/posts/2015/github-pages-custom-domain-in-https/Mon, 12 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/github-pages-custom-domain-in-https/このブログはGitHub Pagesで運用している。ホスト名を書いたCNAMEファイルをドキュメントルートに配置してドメインを1000ch.netとしているが、これだと証明書がないせいでGitHub Pagesが対応しているHTTPSを利用できない。つまり、 http://1000ch.github.io → http://1000ch.net https://1000ch.github.io → http://1000ch.net となり、 (http://1000ch.github.io → https://1000ch.net) https://1000ch.github.io → https://1000ch.net とならない。 なぜHTTPSにしたいか 話はGoogle I/O 2014に参加した時に見たHTTPS Everywhereというセッションに遡る。 ネットワークレイヤ疎い自分は、SSLのオーバーヘッドの方が大きいのではと薄っすら妄想してしまったけど、事はそう簡単ではないらしい。 HTTP vs HTTPS TestはHTTPとHTTPS通信化において、Webサイトのパフォーマンスがどうなるかを検証するサイトだが、見ての通りHTTPSの方が高速という驚くべき結果になっている。 このカラクリは、@kazuhoさんのなぜHTTPSはHTTPより速いのか - Kazuho’s Weblogという記事にある考察を見てもらうとわかる。 話題のService Workerもセキュアな環境じゃないと無効だし、パフォーマンスの観点からも2015年はHTTP→HTTPSという潮流が生まれる予感。これについてはHTTPからHTTPSへ - Hail2u.netという記事も見て欲しい。 CloudFlareをDNSサーバーとして利用する GitHub PagesにCNAMEで設定しているカスタムドメインでHTTPSを使えないか探していると、それらしき情報がGitHub Pages Now Supports HTTPS, So Use Itという記事にあった。CloudFlareがユニーバサルSSLを提供しているのでそれを使うことで実現可能ということらしい。有料プランでなくとも良いとのこと。 指定ドメインのDNSサーバーをCloudFlareに向ける ドメインプロバイダだと、プロバイダ側でDNSサーバーを用意してくれていたりするが、CloudFlareの用意するDNSサーバーに向くようにする。DNSサーバーはxxx.ns.cloudflare.comみたいなやつが2つ。 変更後にMy Websitesで、ドメインプロバイダ側でDNSサーバーのアドレスを更新したドメインの、 Re-Test を実行すると、裏で再テストが実行される。ドメインがCloudFlareに向いて疎通が確認出来た。めでたい。 常にHTTPSになるように ドメインの右の方にあるギアのアイコンをクリックすると、ドロップダウンメニューの中に Page rules という項目があるのでクリックする。 ここでは指定のURLパターンに対して挙動を設定可能。ドメイン全てのURLに対してHTTPSが有効になるようにしたいので、1000ch.net/*というパターンに対し Always use https をonにする。 上手く動いた👌 結論 GitHub Pagesにカスタムドメインをあてて、それをHTTPS化は可能であることがわかった。もうちょっと手が込んだことが必要なのかと思っていたところ、いとも簡単に出来てしまったので、詰まったログ等も残せずに終わってしまった…。https://1000ch.net/posts/2015/vagrant-ansible/Sat, 10 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/vagrant-ansible/Vagrantは今更説明するまでもないけど、仮想環境の作成や起動・破棄を自動化したりするツール。VagrantはChefやAnsibleといったようなプロビジョニングツールとも連携可能なのでそれも少し。 Vagrantで仮想環境を作る 自身には仮想化する機能を備えておらず、仮想化ソフトウェアとしてVirtualBoxやVMWareなどを使う。今回はVagrant + VirtualBoxでCentOSの仮想環境を作ってみる。 以下のサイトに環境ごとのインストーラがあるので、ダウンロードしてインストールする。 Vagrant Oracle VM VirtualBox CentOS 6のBoxファイルをダウンロード 今度はどのOSで仮想化するか決める。VagrantではOSイメージをBoxと呼ばれる形式で管理する。有志で配布されているBoxの一覧はVagrantbox.esにあるので、違うOSで試したい場合はそちらを。 # boxファイルのダウンロード $ vagrant box add centos6 https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box # Vagrantに保持されてるboxのリスト $ vagrant box list # ダウンロードしてきたcentos6を使って初期化 $ vagrant init centos6 centos6というキーに対して.boxファイルが紐づいて、そのダウンロードしてきたBoxファイルでVagrantプロジェクトの初期化をしている。これでVagrantfileが作成され、仮想環境の起動の準備が完了してしまう。簡単すぎる。 起動と終了と削除と仮想環境へのログイン 起動と終了はupとhaltで行う。起動するとデフォルトだと2222ポートで仮想環境が立ち上がり、VirtualBoxを見るとインスタンスが追加されているのが確認できる。 # 仮想環境の起動 $ vagrant up # 仮想環境の終了 $ vagrant halt # 仮想環境の終了と削除 $ vagrant destroy ログインはsshコマンド。vagrantユーザーでログインし、もちろんルートにもスイッチできる。sudo su -とか。 # 仮想環境へSSHログイン $ vagrant ssh Vagrantfileの中身 vagrant initで作成されたファイルは設定可能な箇所が色々とコメントアウトされている。コメントアウトされている内容が、各項目の初期値におおよそなっている。以下は抜粋。 Vagrant.configure(2) do |config| # vagrant box addで取得したboxの指定 config.vm.box = "centos6" # ローカルの8080へのアクセスが仮想環境の80へポートフォワードされる config.https://1000ch.net/posts/2015/intention/Thu, 08 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/intention/ある後輩とランチした。 いきなり会社のスケジュールにアイドルランチという謎の予定に入れられてたときは何かと思ったが。某雑誌のインタビューを受けるとのことで、よく登壇や執筆をしている先輩方に質問したかったそう。てか、アイドルって何だ(´・ω・`) 良い回答を出来た気はしないけど、中々面白い会話だったので書き起こしてみる。その後輩の話題にも触れたいところだが、雑誌のインタビューのこともあるので、念のため伏せて置く。おおよそ以下のような話をした。 アウトプットをすること 2014年はFrontrend in Fukuokaに始まり、6回も登壇させて頂く機会に恵まれた。 「お金を貰えないセミナーなのに何故時間を割けるのか」という質問をされたこともあるけど、僕としては気にしたこともなかった。もちろん、2014年にやった講演にも有料のセミナーはあったけど、手元に利益として支払われたお金は一切ない（会社が支援している勉強会で、旅程に関わる部分は援助してもらったことはあるが）。 会社の技術広報的な側面があるとはいえビジネスの一環でやっていることではなく、あくまでいち個人の活動と捉えているので、通常業務中にこうした活動に関する作業をするのは避けている（というかそもそも、業務に追われて出来ない）。そうなると必然的に作業時間は定刻後だったり休みの日ということになる。 40分のセッションだったら、アウトラインにもよるけど大体100枚ほどのスライドを作成する。100枚のスライドを作るというのはとても労力の要ることだ。皆の前で間違ったことを喋るわけにはいかないので、たくさん調べてひたすら検証を繰り返す。調べた内容を、今度は発表のためにストーリー化する。その後でスライドにして、体裁を整えたら、初めから見直してリファクタリングをする。更に、僕は発表が上手くないので、よく人をとっ捕まえてアドバイスをもらって、また発表アウトラインから書き直しなんてこともよくある。 アウトプットの形として執筆・寄稿と比較すると、成果物が読み物として残らず一過性のものになりやすいし、投じた時間に対して見返り（金銭的な部分を含めて）を求めるなら、割に合わないという言い方すら出来るかもしれない。 それでも僕は前に立ちたい。セルフブランディングという目的ももちろんあるけど、自分を追い込むことで勉強する意欲を生むとか、Webをより良くする推進意識とか、色々だ。自分に与えられる発表時間を、そして自分の発表を聞くために視聴者が割いてくれる時間を、出来る限り有意義にするためにやってる。 エンジニアとしての志向性 この辺りは現在進行形で悩んでいる部分ではあるが、この（ブランディングの）先にどういう自分をイメージするか、だ。5年後・10年後を妄想出来ればそれがベストかもしれないけど、これだけ変化の激しい業界にいてずっと固定し続けるのも逆にリスクかもしれない。ひとまず近未来前提で、エンジニア像の話をしよう。 今現在の肩書は、自称こうだ。 SIerでのプログラマー（C#・Java）を経て、株式会社サイバーエージェントにてWebフロントエンドの技術に従事。業務では自社Webサービスのパフォーマンス改善と、技術推進がミッション。HTML5関連の技術に浸かりつつも、分野や言語は問わない雑食系。だいたい何でもやる。 節操の無さを気にしつつも、フロントエンドでのエバンジェリズムを基本スタンスとしているので、社内ではパフォーマンス（画像減色）おじさんやったり、社外ではWeb Componentsおじさんやったり、一応アイデンティティを自分なりに持つように意識はしている。 でも、移り変わる技術に興味は常に向いてるし、色んな技術に触れていくうちにセールスポイント（アイデンティティ）がわからなくなってきた。2014年バズワード代表格である フルスタックエンジニア になれない器用貧乏まっしぐらな感じだ。 バックエンド・フロントエンド・インフラ・ネイティブ問わず、ひと通り出来るようになって置きたいなんていう欲張りな気持ちはあるけど、今のところ「こんなアプリを作りたい！」という目的が先行している（目的＞手段）ので、それならまだいいかなと思っている。その結果がフロントエンドに特化したT字型になるのであればゼネラリストとしての需要にも答えられる…のかな。 最近は、ウェブ業界で起業したいならMarcoを目指そうなんていう記事もみた。ゼネラリストの、ひとつの成功モデルに違いない。https://1000ch.net/posts/2015/centos-minimum-config/Wed, 07 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/centos-minimum-config/メモを掘り起こしたので、思い出すついでに記事にしてみる。VPSを借りて、ドメイン充ててみたり、ブログを置いてみたり、メールサーバー立ててみたりしていた当時（2年前）のメモなので、悪しからず。 ユーザーの作成と、SSHのログイン周りに制限をかけている。もちろん、サーバーを大量に用意するようなWeb現場でこういった設定をコツコツやるなんてことはまず無いけど、前提知識で持っているべきものだとは思う。 ので、chefだのansibleだのfabricだのについては触れていません。 サーバーへのログイン sshコマンドの引数に、IPアドレスなりドメインなりのホスト名を渡してログインする。 $ ssh [hostname] ログインすると~/.ssh/known_hostに、ホスト名とRSA公開鍵のフィンガープリントが記録される。ので、その後、公開鍵を変更して同一のホストにログインしようとすると失敗する。その場合は、~/.ssh/known_hostの該当のホスト名が記録されている行を削除してからやると良い。 ユーザーの作成 ログイン先のOSにrootではないユーザーを作成して、パスワードを設定する。 ユーザーを追加 $ useradd [username] ユーザーの有効期限とかグループとかログインシェルといったような設定はuseraddのオプションで可能なので、ググってみてください。 パスワードを設定 $ passwd [username] SSHログイン周りの設定 セキュリティを考慮して以下の2点を実施。sshdの設定を変更したいので/etc/ssh/sshd_configを編集。以下の修正をやったら、忘れずにデーモンの再起動をして変更を適用すること。 # sshdの設定ファイルを編集 $ vim /etc/ssh/sshd_config # sshdを再起動 $ /etc/init.d/sshd restart rootログインの拒否 もしrootでサーバーにログインされてしまうと大変なことになるのでやっておく。 PermitRootLogin no sshポートの変更 不正ログインのリスクを低減させる意味で、デフォルトのポートである22から変えるべくPortの値を変更。 Port [portnumber] ローカルの秘密鍵を利用してログインする設定 今回は、そのサーバー用のSSHキーを用意する。サーバーからログアウトしておく。 SSHキーの作成 ローカルでSSHキーを作成。 $ ssh-keygen -t rsa $ Enter file in which to save the key...: hoge_rsa -tで指定しているのは鍵の種類。ファイル名はhoge_rsaとしている。すると~/.ssh配下にhoge_rsaとその公開鍵hoge_rsa.pubが作成されているはず。 公開鍵をサーバーに登録する 先程作成した鍵ペアのうち、公開鍵をVPSに持っていてもらう。まず、サーバーにログインし、ホームディレクトリに.sshフォルダを作成。 $ cd ~ $ mkdir .ssh $ chmod 700 .https://1000ch.net/posts/2015/image-encoder-es6/Tue, 06 Jan 2015 00:00:00 +0000https://1000ch.net/posts/2015/image-encoder-es6/だいぶ前に書いたコードを掘り当ててそれをES6で書き直したのと、エディタのバグらしき現象にぶつかった話。ライブラリはファイルパスを渡して、Canvasに突っ込んだ後、データをdataURIにして出力する。インターフェースがPromise。特に変わったことしてないです(｡-人-｡)ｺﾞﾒﾝﾅｻｲ ちなみに、リポジトリは1000ch/image-encoderです。 ES5で書かれた実装 ES5と言っておきながらPromiseを使っている点には突っ込まないこと。 (function (window) { function ImageEncoder(path, width, height) { this.path = path || ''; this.width = width || 1; this.height = height || 1; } // ... ImageEncoder.prototype.getDataURI = function () { var that = this; return new Promise(function (resolve, reject) { var image = new Image(); image.setAttribute('crossOrigin','anonymous'); var onLoad = function (e) { var canvas = document.createElement('canvas'); canvas.width = that.width ? that.width : image.width; canvas.height = that.https://1000ch.net/posts/2014/service-worker-internals/Mon, 29 Dec 2014 00:00:00 +0000https://1000ch.net/posts/2014/service-worker-internals/今巷で流行りのService Workerについて調べ物してたので、まとめたメモ。 Service Workerが解決してくれること Service WorkerはHTML・CSS・JS・画像等などのリソースを、JavaScriptのAPIから命令的にコントロールすることを実現する。Webページのパフォーマンスに関する指標としてネットワークを介して得るリソースをキャッシュさせたりすることが効果的であることは今更改めて挙げないが、Service Workerによって保持されたリソースは、オフライン状態でも返却することが可能という凄さを持っている。つまり、更新性の低いコンテンツであればオフラインでも閲覧させることが可能ということ。 更新性のあるコンテンツでも、回線が不安定な時はローカルに変更を保持して、サーバーに対してデータを遅延で同期するみたいなテクニックは既に存在している。ので、こういったテクニックと組み合わせて、よりクライアントの画面がホワイトアウトすることを減らしていける。はず。 こちらは、Jake Archibald氏とAlex Russell氏によるGoogle I/O 2014でのセッション「Bridging the gap between the web and apps」。@myakura氏による解説記事もある。 Application Cache 先程の動画でも少し触れられているように、Application Cacheとよく対比される。リソースをキャッシュする機能として現れたのがApplication Cacheだったが、キャッシュリソースのコントロールがし難かったり、動的なコンテンツを生成する際、構成がApplication Cache前提になってしまう等、いささか問題を抱えていた。それを解決してくれるのがService Workerでもある。 Application Cacheの問題点については、@kyo_agoさんが執筆したモバイル対応Webアプリケーションのキャッシュ戦略という記事にまとまっている他、TwitterでメンションしてもApplication Cacheの話題であれば何かしらレスをくれる。かもしれない。 ブラウザキャッシュ ブラウザキャッシュもパフォーマンスを向上させる上で非常に重要な存在であることには間違いなさそうだが、JavaScriptからコントロールすることは不能だし、ブラウザによって挙動もまちまちである。なんせ、ブラウザキャッシュはW3Cに載っているような仕様の類ではなく、ブラウザベンダーが気を利かせて実装している機能に過ぎないからである。 ブラウザキャッシュと言えば、Nicholas Zakas氏によるThe changing role of the browser cacheというブラウザキャッシュの役目の移り変わりについての記事も興味深い。 オフラインアプリケーションの夢 ホワイトアウトを減らすどころか、必要なリソースを全てService Workerでコントロールすればオフラインアプリケーションの作成も可能である（キャッシュするリソースを取得する最初のダウンロードは必要になるが）。 つまりService Workerは、Application Cacheの屍を超えて生まれた今までにないリソースのコントロール機構であると言える。 Service WorkerのAPIと挙動 Service WorkerはWeb Workerなんかと同じように（Web Workerの一種と言ったほうが正確なのかも）、ブラウザの表示とは別スレッドで実行される（だから、DOMのAPIとかを叩いたりすることは出来ない）。Service Workerでは、ページから行われるリソースの要求等に対し、独自の処理を挟むことが出来る。 プロキシを自前で用意出来る と言ったほうがイメージしやすいかも。 リクエストをフックし、Cache APIを介してアレコレする。あるURLへのリクエストに対するレスポンスを受け取った時にそのリソースを保持したり、はたまた再度そのリクエストが発生する時にはCache APIから保持したリソースを引っ張りだしてブラウザに返却する。といったような処理をService Workerにしてもらうことになる。 しれっとCache APIが出てきたが、これもService WorkerのAPIの一環で、Service Workerコンテキストで利用可能なキャッシュリソースを管理するためのAPIである。 もうちょっと実際の処理に近い説明 リクエストされたリソースをキャッシュさせたり、リクエストに割り込んでキャッシュされたリソース等を返却するような処理が記述されているservice-worker.jsを用意 index.htmlでservice-worker.jsをService Workerとして登録する（この時、index.html内の評価は行われていない）。 service-worker.jsに定義してあるリクエストがindex.htmlから行われた場合、フックする。既にキャッシュに存在している場合はそれを返却したり、キャッシュされていなければそのままサーバーへリクエストしてあげる。 画像をService Workerでcachesにキャッシュさせるサンプル 実際のコードを動かしてもらって、デバッグしてもらう方がイメージしやすいと思うので簡単なサンプルを作った。https://1000ch.net/posts/2014/look-back-over-2014/Tue, 16 Dec 2014 00:00:00 +0000https://1000ch.net/posts/2014/look-back-over-2014/もう何回かポストしそうな気もするけど、師走ということで振り返る時間があるうちに振り返る。 社内で活動してきたこと 年始からずっとPerformance Evangelist的な立場で社内に点在するWebサービスのチューニング活動をしてきました。草の根活動が功を奏したのか、社内でも少しづつパフォーマンスに関するリテラシーが生まれてきた（気がする）。 大きな体制変更を経て、現在は社内でも主力サービスの部署で今なお奮闘中。フロントエンドという領域は変わっていないけど、技術支援者という立場からは一転して、コードを書く人間に戻れた気がする。パフォーマンスという観点とはまた違う形でサービスに貢献することに挑戦中。 社外で活動してきたこと ありがたいことに、東京を含めて各地で登壇させてもらう機会を頂いたり、WEB+DB PRESSで連載を書かせてもらったり、HTML5Experts.jpに寄稿させてもらったり。ありがとうございます（2回目）。 活動ドリブンで勉強も捗るさなか、海外カンファレンスに2回参加した。 6月にGoogle I/Oに参加したり、 Google I/O 2014 11月にはCSSConf.Asia+JSConf.Asiaに参加。 シンガポール遠征初日 CSSConf.Asia 2014 JSConf.Asia 2014 1日目 JSConf.Asia 2014 2日目 JSConf.Asia 2014を振り返って 6月に参加したGoogle I/Oのアメリカが人生発海外で、11月のシンガポールが2回目。海外の大きなカンファレンスに参加できたことはもちろん良い体験だったんだけど、やっぱ英語力の無さは浮き彫りになったなーという（耳にタコが出来るくらい同じこと言ってる）。 英語でLTしたのもいい思い出。 http://t.co/ZmBVO31saP 2014でプレゼンしました。無事終わってよかった（小並感） https://t.co/phDA3K143B — 1000ch (@1000ch) 2014, 11月 20 2014年の1000ch.net人気記事 やってみたかった。 Android Studio+GenymotionではじめるAndroid開発 画像の最適化をCLIだけで行うgrunt-imageを作った Raspberry PiにChromiumとかJenkinsを入れてみた Web制作者のためのCSS設計の教科書 書評 フロントエンドエンジニア養成読本 PHILIPS 23型AH-IPSパネル採用ワイドディスプレイを買った Gzipを有効にしてサイト表示速度を向上させる PythonとMongoDBとPolymerでRSSリーダーを作った Zepto.js ver1.0がリリースされました Googleの隠しコマンド Webフロントエンドの記事ばかり書いている中、Androidに関する唯一の記事が堂々の1位。4位~6位はレビュー記事だけど、意外な人気が。5位のフロントエンドエンジニア養成読本は、@cssradar氏を筆頭に、怪しめな面子で寄ってたかって頑張った、フロントエンドエンジニアに必要な知識を網羅的に扱った共著。何卒宜しくお願い致します。 2015年にやりたいこと箇条書き Macのネイティブアプリをリリースする Swiftもやれるし、ストアにアプリを出すということをしてみたい。Xcodeの使い方覚えればiOSのアプリを作るときも取っ付き易くなりそう。 レアジョブしっかりやる 英語の記事は積極的に読むようにしたけど、聞けないし、喋れないので。文法云々は学生時代に受けてから暫くやってないけど、DUOで勉強しなおしてみようかと。TOEICのスコア800超え目指す（数値化したいだけ）。 サーバーサイドエンジニア 久しくサーバーサイドプログラムを組んでいないので。規模が大きいWebサービスを扱う会社にいるのだから、折角なのでそういう環境も大事にしなければと思う。https://1000ch.net/posts/2014/wdpress-frontend-series-modulesystem/Mon, 15 Dec 2014 00:00:00 +0000https://1000ch.net/posts/2014/wdpress-frontend-series-modulesystem/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.84が12月23日に発売されます。 今回も@ahomu氏と書きました。2人で書くと分量が減る以外にも色々と捗る。 モジュール管理の理想と現実解 今回はWebフロントエンドのモジュール管理ということで、npmやbowerといったパッケージマネージャと、CommonJSスタイルの依存管理をブラウザで実現するBrowserifyに主眼を置きつつ、RequireJS・webpack・duoを併せて考察しています。 フロントエンドJavaScriptに仕事が寄ってきたのは今に始まった話ではありませんが、それに伴いモジュール管理が求められるようになりました。が、JavaScriptにはモジュール管理の仕組みが言語的に備わっておらず、次期仕様であるECMAScript6にようやくmodule / exportを使ったモジュールシンタックスが加わります。シンタックスの追加になると当然後方互換性はないので、暫くはES5へのトランスパイル前提で書かざるを得なかったり。Node.jsのrequire()に統一をひとまず求めたり。その辺の話です。 僕は基本的には「concatでええやん」派なんですが、使ってみるとBrowserifyはやっぱり便利です。 興味がある方は是非 宜しくお願い致しますm(_ _)m 藤 吾郎 (著), 桑野 章弘 (著), 福永 亘 (著), 谷井 靖史 (著), 野村 晋之介 (著), 蛭川 皓平 (著), 岡田 友輔 (著), 藤本 真樹 (著), 伊藤 直也 (著), 宮崎 靖彦 (著), 佐藤 健太 (著), 高橋 俊幸 (著), 佐藤 太一 (著), 海野 弘成 (著), 佐藤 歩 (著), 泉水 翔吾 (著), 渡邊 恵太 (著), 舘野 祐一 (著), 中島 聡 (著), 橋本 翔 (著), はまちや2 (著), 竹原 (著), 伊賀敏樹 (著), WEB+DB PRESS編集部 (編集)https://1000ch.net/posts/2014/limetext/Fri, 12 Dec 2014 00:00:00 +0000https://1000ch.net/posts/2014/limetext/Lime Textのビルドをしてみた http://t.co/aKbm2dzOAM pic.twitter.com/6U8Q253gkx — 1000ch (@1000ch) 2014, 12月 12 Lime TextはSublime Textの後継を目指したオープンソースのテキストエディタ。Goで書かれており、インターフェースはSublime Textとよく似ている。 Lime Text is a powerful and elegant text editor primarily developed in Go that aims to be a Free and open-source software successor to Sublime Text. 最近はSublime Textの開発もあんまり活発じゃ無さそうだし…ということで使ってみただけの、ただの作業ログ。 limetextのビルド バイナリ配布してないので、使うためにはソースコードを入手して、自分でビルドする必要がある。この辺はWikiに書いてある通りにやっているだけです。 ビルド時に必要になるライブラリとかのインストール Python 3.4 Oniguruma Git Mercurial Go 1.3.3 installed and some familiarity with writing code in Go. 鬼車を久々に目にしたのはさておき、これらをインストールしておく必要がある。MacであればHomebrewあたりが楽。Goの環境についてはGo事始め作業ログにメモがあるので、もしかしたら参考になるかも。 $ brew install pkg-config go mercurial oniguruma python3 僕の場合Pythonはpyenvで管理しているのでbrewではインストールしていない。が、pyenvでは、今のところ3.https://1000ch.net/posts/2014/networking-on-web/Wed, 03 Dec 2014 00:00:00 +0000https://1000ch.net/posts/2014/networking-on-web/「ネットワークってなんだろう？」と考えたことはあるだろうか。前職でもプログラマとして働いていたものの、（恥ずかしながら）知識は皆無に近かったし、Webのフロントエンジニアとして舵を切った2年と5ヶ月前は、この手の話がフロントエンドに関わるとは思ってもいなかった。 HTTPだの、WebSocketだの、言葉は耳にするけど実態はよくわからない …という人も多いと思う。私自身も深く密着しているわけではないし、語るほど詳しいかと言われれば疑問符が残る。それでも、今までモヤモヤしていたところを少しでも晴らす手助けが出来ればと思い、今日はインターネットの世界で何が起こっているかについての記事を書きたい。 そもそもサーバーとは？ サーバーって一体何だろうと思っている人も多いのではないだろうか？手元のパソコン、iPhone、Androidといった クライアントからの要求を待ち、応答する役割を担っているのがサーバー である。応答するプログラムであれば端末の種別は問わないが、起動しっぱなしのパソコンと思ってもらえばわかりやすいかもしれない。 電話におけるサーバー クライアントからの応答を待つ役割をするサーバーは、インターネットに限った話ではない。例えば電話でのやりとりに於いても、サーバーは存在する。 電話のかけ手が、番号を入力し発信する サーバーが入力された番号を探す 電話の受け手が受信する サーバーを介して通話を開始する このように、家の置き電話や携帯電話があるだけでは通話は成立せず、通話が確立するまでや、その後の通話（音声データのやりとり）もサーバーを介して行われている。 Webにおけるサーバー ブラウザにURLを入力し、表示されたWebページを閲覧するということは誰しもが当たり前のようにやっていることだが、実はここでもサーバーが一役買っている。 入力されたURLのサーバーに対し、ブラウザが接続要求をする サーバーが接続要求に対し、応答する（接続開始） ブラウザがURLに関するリソースの要求をする サーバーがリソース（HTML）を送信する 厳密に言えば、URLに対してブラウザが接続要求を実行するタイミングでDNS解決というURL（ホスト名）からIPアドレスへの変換が行われる。インターネットにおける端末間の通信には、お互いを一意に認識するデータとしてIPアドレスを知っている必要があるためだ。先程の電話の場合は、電話番号がその役割を果たしている。 このクライアントの要求を リクエスト 、サーバーからの応答を レスポンス という。 サーバーとクライアントのやりとり Webページの表示するために、クライアントとサーバーがやりとりを行っていることがわかった。次にどのようなやりとりを行っているかを見てみよう。 やりとりの中にはルールが存在している。普段の生活で言えば、 日本語のような決まった言語でやりとりをする であったり、 面と向かって、または何かしらのツール上でメッセージの交換をする といったように、何かしら縛りがあるはずだ。 クライアントがサーバーとやりとりを行う際も、ある一定のルールの中でやりとりが行われる。このコンピュータが行うやりとりにおけるルールをプロトコルと言う。以下、Wikipediaより引用。 プロトコルまたはプロトコール（英語 protocol 英語発音: [ˈproutəˌkɔːl] プロウタコール、[ˈproutəˌkɔl] プロウタコル、フランス語 protocole フランス語発音: [prɔtɔkɔl] プロトコル）とは、複数の者が対象となる事項を確実に実行するための手順等について定めたもの。日本語では「規定」「議定書」「儀典」などと意訳される。もともとは人間同士のやりとりに関する用語としてのみ用いられていたが、近年では派生的に、情報工学分野でマシンやソフトウェア同士のやりとりに関する概念を指すためにも用いられるようになった。 インターネットにおけるプロトコル プロトコルの中でも、特に通信に関するプロトコルは通信プロトコルと言う。そして昨今のインターネットにおいては、HTTP（Hypertext Transfer Protocol）が最も多くの割合を占めている。以下、Wikipediaより引用。 Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、WebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコルである。ハイパーテキスト転送プロトコルとも呼ばれる。 静的なWebサイト・動的なWebアプリケーションを問わず、この一定のルールの元でやりとりが行われ、ブラウザにデータが返却される。つまり、 サーバーとクライアントがHTTPというルール（プロトコル）のもとで、データのやりとりを行う ということになる。 HTTPはその名の通り、ハイパーテキスト（HTML）の転送を主な目的としているが、それ以外にも画像や音声等のバイナリを含めて、様々なデータを扱うことが出来る。 HTTPを含む、ネットワークプロトコルは何層かに分かれており、HTTPはアプリケーション層と呼ばれる上位レイヤにあたるが、レイヤに関しての詳細は割愛する。先程の「やりとり」がTCP/IPのような下位レイヤのルールの元行われていると思ってもらえれば良いと思う。 Webページで発生しているHTTPリクエスト 前述の Webにおけるサーバー の項で触れたが、HTTPでは1つのリクエストにつき、以下のようなやりとりを行っている。 入力されたURLのサーバーに対し、ブラウザが接続要求をする サーバーが接続要求に対し、応答する（接続開始） ブラウザがURLに関するリソースの要求をする サーバーがリソース（HTML）を送信する このやりとりのうち、1~3のステップがHTTPの下位レイヤにあたるTCPで行われることを (TCP)3-Way Handshake という。 ブラウザにURLを入力してWebページを表示するために、クライアント（ブラウザ）がリクエストし、サーバーがレスポンスする。ブラウザにおけるURL入力やリンクの押下はページ表示における最初のリクエストにあたり、WebサーバーはHTMLを返却する。https://1000ch.net/posts/2014/look-back-in-singapore/Sat, 22 Nov 2014 00:00:00 +0000https://1000ch.net/posts/2014/look-back-in-singapore/とりあえず脳内メモリを書き出しておく。追記するかもしれない。 CSSConf.Asia+JSConf.Asia 各セッションの様子は、ざっくりであれば前日のポストを見てもらえれば大丈夫かと思う。 CSSConf.Asia 2014 JSConf.Asia 2014 1日目 JSConf.Asia 2014 2日目 セッション動画は、後日YouTubeなどで公開されると思うので、公開され次第そちらへのリンクも追記する。 CSSConfもJSConfも、良かった。技術の先端を取り扱っているというよりは、各シーンにおけるWebの立ち振舞のようなセッションだった。最先端技術のキャッチアップならChrome Dev Summit、パフォーマンスに関することならVelocity、プラットフォーム云々ならFluentに参加するのが良いのだろう。カンファレンス毎のコンセプトがあるんだなというのを体感した。 日本で開催されないかなと初日に呟いたが、同じアジアの日本で開催するには何が障壁になるのだろう。 アクセス的な話は飛行機が前提になると思うので、マニラ（JSConf.Asia 2013）だろうとシンガポールだろうと、そして日本だろうと差はないような気がしている。幸い、日本は地下鉄も充実しているし。 マニラやシンガポールに比べると、言語の壁が最大のギャップかなとは思う。もちろん傍聴者は日本人だけでは無いので、スピーカーに日本語で喋ってもらうわけにもいかないし、通訳をつけるのも何か違う。この言語ギャップに対しては、日本人が英語頑張る云々より、日本へ外国から訪れた人が日本語へ感じる不便のほうが大きいかとは思っている。 まぁ、開催の本線ではなくて周辺に関する部分なので、然程問題ではないのかも。目指せランゲージバリアフリー。 And so it ends! The morning after.. #jsconfasia Hope you all had a blast! We had! pic.twitter.com/rEuoyvNHW3 — JSConf.Asia (@jsconfasia) 2014, 11月 22 トーマスをはじめ、開催に携わったスタッフの皆さん、ありがとうございました。 Thanks Thomas and all staffs for the great conference! シンガポールの街・治安 シンガポールの街は、高層ビルが立ち並んでおり、道路も地下鉄も、とても綺麗。その美を維持するための条例系も日本より厳しい印象があるが、もたらされる環境的安定・政治的安定を国民が望んでいるということだろう。 Google I/O 2014への参加でサンフランシスコに行った時は、本能的に身の危険を感じる部分が多かったけど、シンガポールではそれがあまりない。治安が良いというのも本当だろう。とはいえ、夜の街にはそれなりに変な人達がウロウロしているので、身を守り切る自信がないなら避けたほうが良いとは思う。 ホテルに当たり外れがあるかどうかは不明だが、泊まった感想としてRendezvous Hotel Singaporeは少なくともオススメ出来る。 Breakfast A photo posted by 1000ch (@1000ch) on Nov 11, 2014 at 3:30pm PSThttps://1000ch.net/posts/2014/jsconf-asia-2014-2nd/Fri, 21 Nov 2014 00:00:00 +0000https://1000ch.net/posts/2014/jsconf-asia-2014-2nd/Intro to BitTorrent & WebTorrent by @feross BitTorrentをWebで実現するのがWebTorrentだ的な話だった。元々PeerJSを手がけていた人っぽい？WebRTCの素のAPIは確かに使いにくいので、その隠蔽策は参考になる。 Versioning, Syncing & Streaming large datasets using DAT + Node by @maxogden Gitのようなデータのバージョン管理をリアルタイムに何とかかんとかするって言ってたんだけど、途中からだんだん難しくなってきて理解できなかった。内容的には気になる方面なので、要復習。 Versioning, syncing & streaming large datasets using DAT + Node by @maxogden #jsconfasia pic.twitter.com/jB9oBpQq6n — 1000ch (@1000ch) 2014, 11月 21 maxogden/dat ※個人的メモ：データはローカルのlevelDBに保存され、blobのストア先は、Amazon S3なりローカルなり、好きに選べるぜと言っていた気がする。これだけじゃよくわからんことには変わりない。 Reactive Programming made simple by @imslavko Meteorのコアコミッターの人で、Reactive Programmingイイよねという話から、どうすれば簡単に実現出来るか。Trackerなるものを使うとDOM操作から、通信等、しかも依存するライブラリを問わずにいとも簡単にReactiveに出来るらしい。 とてもプレゼンが上手くて、Trackerのデモもかなり鮮やかだったので、後日公開されるであろうビデオを是非。 Gibbering at Algoraves: JS in live audiovisual performances by Charlie Roberts Gibber charlieroberts/Gibber コードエディタアプリの紹介。このWebアプリを起動するとWeb上にIDEが表示され、そこで各種APIを実行するとそれに応じた音楽や視覚効果が表示されるというモノ。 そのドラムやらスネア等々の再生APIを覚える前提ではあるけど、DJ的なことができる。既に導入利用実績があるらしい。 これは最後のライブコーディング+デモが凄くて一番拍手が起こってた。 Let’s make a game with Phaser by @gabehollombe ゲームを作るには、アセットをダウンロードして・それらを描画して・アニメーションさせて・ユーザーの入力をハンドリングして・角度を計算して・音楽を鳴らして・得点とかの状態を管理して…など、とにかくやることが沢山ある。https://1000ch.net/posts/2014/jsconf-asia-2014-1st/Thu, 20 Nov 2014 00:00:00 +0000https://1000ch.net/posts/2014/jsconf-asia-2014-1st/今日はRegistrationも無いので、7:30にホテルを出る。 #jsconfasia A photo posted by 1000ch (@1000ch) on Nov 11, 2014 at 4:22pm PST 昨日のCSSConfより参加者が多いようで、席が2割増。OctcatのBracketsを使ってラテを体に注入した。 Building Isomorphic Apps by @spikebrehm AirbnbのSpike Brehmのセッション。英語聞き取りやすい気がした。 JavaScriptはブラウザ環境でもNode.js環境でも実行される。だからこそIsomorphicにするべき フロントエンドの比重は大きくなっているが、SPAなどで極端にクライアントに処理を寄せてしまうとパフォーマンスに影響する 1.Download skelton HTML 2.Download JavaScript 3.Evaluate JavaScript 4.Fetch data from API 5.User sees content 従来のように、HTMLをサーバー側で構築して返却する場合はやはり手順が少ない 1.Download fill HTML 2.User sees content パフォーマンスはもちろん、SEO的にも、うまく組み合わせたい。 Flickerはmojitoで、Instagramはreactとdjangoで実現しているらしい。 AirbnbのモバイルWebはBackboneとExpressで作った自家製ライブラリらしい。 ASANA - クライアントとサーバーで同期されているランタイムらしい。Meteorも同じ類のアプローチ？ これらの実現のために、環境の差異を吸収する。”Enviroment agnostic & Shimmed per environment” 例えばCookieの抽象化は、cookie + Browserifyで良いのでは？ リクエストであればvisionmedia/superagentとか。 webpackを使ったアプローチも、InstagramやFacebook、Yahooで使われている。 どうやってshimmed-per-environmentなモジュールをつくるのか？ package.jsonのbrowser属性を使おう https://github.com/spikebrehm/set-cookie facebook/react yahoo/flux-examples Isobuild: why Meteor created a new package system Pixel Art and Complex Systems by @vinceallenvince 自然にある複雑な事象をピクセルで抽象化したらどうなるかのような話だった。気がする。デモがどれも凄い。https://1000ch.net/posts/2014/cssconf-asia-2014/Wed, 19 Nov 2014 00:00:00 +0000https://1000ch.net/posts/2014/cssconf-asia-2014/最初のセッションは9:00開始、Registrationが8:00開始、ホテルは会場まで電車で1時間弱という状況だったので、7:00にホテルを出発。 ディズニーランドを彷彿とさせる電車に乗って、現地へ向かう。 アトラクションみたいな電車 A photo posted by 1000ch (@1000ch) on Nov 11, 2014 at 3:43pm PST 現地へ着いたらパスポートを見せて、参加登録を済ませた。 #cssconfasia A photo posted by 1000ch (@1000ch) on Nov 11, 2014 at 3:57pm PST 面白かったセッションを幾つか紹介。 NO MORE TOOLS by @fox ツールっていっぱいあって、どれがベストなのかわからない… SIMPLICITY 目的がわかりやすく、複雑でないものを選ぼう “Complexity is a fact of the world, simplicity is in the mind.” AUTOMATION 自動化がキモ AutoprefixerやらCSSLintやらCode BloatやらStressCSSやらを駆使 共有にはnpmもといpackage.jsonを利用するのが良いかな ランナーにはGruntでもGulpでもMakeでも！ COLLABORATION 皆が使うことを前提にする プロジェクトにジョインする人みながバイアスをもっている “Knowledge makes everything simpler” “its easy to introduce that unnecessary complexity by adding tools that manage other tools”https://1000ch.net/posts/2014/singapore-the-1st-day/Tue, 18 Nov 2014 00:00:00 +0000https://1000ch.net/posts/2014/singapore-the-1st-day/掲題の件、2014/11/19に行われるCSSConf.Asia 2014、および2014/11/20 ~ 2014/11/21に行われるJSConf.Asia 2014に参加のために、シンガポールに来ている。 暑い。雨季ということも相まって、蒸し暑さ抜群だ。 JSConf.AsiaとCSSConf.Asiaと、待ち望まれる日本版 海外遠征経験は今年の夏にGoogle I/O 2014に参加したのみで、今回は2度目になる。その時にはアメリカだったので、次は違う場所にも行ってみたいと思っていたこともあり（サンフランシスコは治安的問題で怖かったのもあるが）、JSConf.AsiaとCSSConf.Asiaに参加する運びとなった。 JSConf.AsiaとCSSConf.Asiaの立て付けについての詳しいところはよくわかっていない。JSConfを見る限りは、フランチャイズのようなものではあるようだ。 JSConf is a unique conference organization, because we aren’t really a conference organization at all. We are a very loose federation of developers who share the same general idea about how a technical conference should be held. We don’t believe that one model or process fits all communities, in fact we are big advocates of locally run events driven by passionate individuals dedicated to the community.https://1000ch.net/posts/2014/wdpress-frontend-series-image/Wed, 15 Oct 2014 00:00:00 +0000https://1000ch.net/posts/2014/wdpress-frontend-series-image/「Webフロントエンド最前線」という連載を担当させてもらっているWEB+DB PRESS Vol.83が10月24日に発売されます！ 連載の第3回目ということで「Webフロントエンドの画像形式と最適化」という、その名の通りWebにおける画像について執筆しました。 今回は@ahomu氏と共同で執筆しました。各章の担当分担については良いとして、執筆後の体裁をならす作業大変そうだなと心配していましたが、お互いの校正を繰り返しつつ@inaoさんの編集も頂きつつ（毎度ご迷惑をお掛けしておりますorz）で何とか見れる文章に収まったかなと思います。 記事サマリー 一口に画像と言ってもトピックとして色々あると思いますが、今回は パフォーマンスをゴールに見据えた画像の取り扱い を知るべく、JPEGやPNGといった各種画像形式の特徴や利用シーンに加えて、Googleが開発し新たな画像のフォーマットとして注目されるWebP・ベクター画像であるSVG各種画像の最適化やワークフローへの導入手法などなど、8ページに渡り画像について語っています。 たかが画像されど画像 圧縮されたjQueryが32KBだのなんだのと言っても、未減色の画像ならそのサイズの10倍とかを平気で突破するケースも多々ありますし、iPhone 6 Plusのdevice-pixel-ratio=3も各所で報告されましたし、画像ファイルのサイズは尚の事シビアな問題として今後挙げられていくでしょう。このあたりで画像の取り扱いについて再考しておくのもきっと今後のWeb開発に役立つはずです。 原田 騎郎 (著), 吉羽 龍太郎 (著), 山口 陽平 (著), 青木 雅弥 (著), 松下 誠太 (著), 三宅 英明 (著), 高橋 征義 (著), 南川 毅文 (著), 伊藤 直也 (著), 海野 弘成 (著), 高安 洋輝 (著), 佐藤 歩 (著), 泉水 翔吾 (著), 佐藤 太一 (著), 横江 直輔 (著), 舘野 祐一 (著), 橋本 翔 (著), 渡邊 恵太 (著), 中島 聡 (著), はまちや2 (著), 小沢 邦雄 (著), 長沢 智治 (著), WEB+DB PRESS編集部 (編集) 是非お買い求め下さい！https://1000ch.net/posts/2014/c-in-golang-with-cgo/Thu, 09 Oct 2014 00:00:00 +0000https://1000ch.net/posts/2014/c-in-golang-with-cgo/Goの練習がてらコマンドラインツールを書いている最中に詰まったので作業ログとして残す。 Goでコマンドラインのインターフェースを実装するには、osやflag等のデフォルトライブラリ群でそこそこ簡単に作れるけど、今回やりたいことに「Cで書かれたバイナリをGoから利用したい」というものがあった。 同じことをNode.jsでやろうとするなら、スクリプトを含めたパッケージ群としてnpmで配布することが可能なので、postinstallあたりで 都度ソースコードをダウンロードしコンパイル 、あるいは コンパイル済みバイナリをダウンロード くらいで良かった。以下Node.jsの例。 https://github.com/imagemin/pngcrush-bin https://github.com/imagemin/jpegoptim-bin Goの場合はどうだろう。 @1000ch linkすればいいんじゃないかな。Cのライブラリみたいに — すぎもと@ (@sugimoto1981) 2014, 10月 2 色々ググっててもcgoというワードが出てくるけど、これはgoのコンパイラでcのプログラムも一緒にコンパイルするみたい。詳しい内部処理わからないけど、GoからコンパイルされたバイナリとCからコンパイルされたバイナリをリンクという処理は見えない。表面上は。 Command cgo - The Go Programming Language C? Go? Cgo! - The Go Blog cgoを使ったミニマルな例 main.cとmain.goというファイル名で用意。 #include <stdio.h> void func_to_export(const char* message) { printf("(✌՞ټ՞)✌ %s!!!\n", message); } package main /* #include <stdlib.h> extern void func_to_export(const char*); */ import "C" import "unsafe" func main() { p := C.CString("lorem ipsum") defer C.free(unsafe.Pointer(p)) C.func_to_export(p) } このくらい単純なら僕でもわかるんだけど、やりたいのは既存のcで書かれたライブラリをgo buildでコンパイル。https://1000ch.net/posts/2014/inherited-content-with-html-imports/Tue, 07 Oct 2014 00:00:00 +0000https://1000ch.net/posts/2014/inherited-content-with-html-imports/https://github.com/pazguille/github-card/blob/master/webcomponent/github-card.html これってなんでdoc.registerElementになってるんだろう・・ っていう質問をされたので調べたメモ。内容的にはHTML ImportsするHTMLのコンテキストになるdocumentの続きにあたるかも。 registerElementの実行者とカスタム要素の登録先 以下の様なカスタム要素を作成し、ロードする場合を考える。 sample-element.html <script> var doc = document.currentScript.ownerDocument; doc.variable = 'this is the variable in sample-element.html'; window.SampleElement = document.registerElement('sample-element', { prototype: Object.create(HTMLElement.prototype) }); </script> loader.html <html> <head> <meta charset="utf-8"> <link rel="import" href="sample-element.html"> </head> <body> <sample-element>Sample</sample-element> </body> </html> document.currentScript.ownerDocumentをdocにキャッシュしないと、sample-element.html内に書いた要素を取得する時に困る話は前述のエントリでしてある。 document.registerElement('sample-element', {});しているのは、sample-element.htmlをインポートするHTMLのdocumentになる。 でも<github-card>ではこの例で言うところのsample-element.htmlのdocumentでregisterElement()を実行している。 感覚的に言えばインポートする側のdocumentで登録を実行するほうがしっくりくるんだけどそうでもないんだろうか。 HTML Importsでカスタム要素の定義もインポートされる 感覚の話はさておき、<github-card>を見る限りregisterElement()したカスタム要素は引き継がれるよう。 sample-element.htmlでわざとらしく宣言したvariableという変数も見てみる。引き継がれないだろうけど、一応。 当然のごとくvariableはdocにしかない。が、document.createElement('sample-element')は両方とも成功している。 Firefox Nightly 35.0a1でも試してみた。 インポートしているsample-element.html内で宣言しているdocがundefinedになってしまっているんだけど、docに登録している<sample-element>はちゃんとインポート先のdocumentに登録されていた。 スタイルシートも引き継がれる sample-element.html内でsample-element.cssをロードし、そのsample-element.htmlをインポートするとインポート先でsample-element.cssで定義しているクラスは利用出来る。 このとき、sample-element.cssはdoc.styleSheetsにぶら下がっているけど、当然document.styleSheetsには属さない。 HTML ImportsとCustom Elementsの仕様を見てみる http://www.w3.org/TR/html-imports/#loading-imports HTML Importはこんな感じでlink関係をツリー上に持つらしい。で、このHTML Importsのツリーは The import tree order of a given custom element of an import tree is determined by tree order in an import tree that was flattened by replacing every import link with the content of its imported document.https://1000ch.net/posts/2014/philips-wide-display-23inch/Thu, 11 Sep 2014 00:00:00 +0000https://1000ch.net/posts/2014/philips-wide-display-23inch/良いという噂が飛び交っているPHILIPSのAH-IPSパネルディスプレイを購入した。 Apple製品が多いのでThunderbolt Displayが欲しくなるところだが、現行のThunderbolt Displayは厚みがあり、重厚感があったり（というか実際に重い）、ちょっとお高いし…ということで見送った。iMacの外観を踏襲した新型もいつかは出るんだろうけど、確約もないし、例によって高いだろうしということで。 AH-IPSパネルとはなんぞ -　IPS方式 - Wikipedia 以下Wikipediaより引用。 液晶分子を基板と平行な面内（in-plane）で回転させ、複屈折の変化で光をスイッチングする液晶駆動方式のこと。 基板の面方向に電界を加えて液晶分子を駆動し、電界が存在しない無電圧状態で光を遮蔽する。 うん、わからん。 上下左右178度の広い視野角をもち、どの位置で見ても色の変化が殆ど無いため、ワイド画面や大画面、近距離で見る携帯端末画面に向いている。(TN方式やVN方式は上下160度左右170度) どうやらワイドなディスプレイに向いている液晶ディスプレイの種類らしい。iPhoneのRetinaディスプレイ等にも採用されているとのこと。 23型のモデルを購入した ディスプレイのサイズは、21.5型・23型・27型の3種類あるが、僕はタイトルの通り23型モデルを購入した。21.5型が16,080円、23型が17,898円、27型28,188円で、Thunderbolt Displayと同じサイズにあたる27型は比較的高めとはいえ、非常に廉価な印象。 HDMI端子入数:2 [HDMI 1、HDMIMHL1]。USB機能:なし。スピーカ無し。TV機能無し 詳しいスペックについては公式サイトをどうぞ。 PHILIPS - PC 製品と電話機 > モニター > ホームモニター 前面と背面 見ての通り非常にスリムな体型をしている。写真だとわかりにくいが、フチ部分・ディスプレイ部分がつや消しブラックになっている。 この薄さに相まって非常に軽量で、片手で持ち上げることも可能。 机のサイズとのバランスを考慮して23型にしたものの、27型でも圧迫感は少ないかもしれない。 入力端子 これは背面にある各種入力端子部。入力は、HDMI・MHL-HDMI・VGAの3種類で、USBはない。とはいえ、MacにはもちろんHDMIを使うので特に不便は感じない。 電源スイッチはディスプレイの右下のフチに目立たないように並んでいる。 実際の出力 電源を入れた感じはこんな感じ。 付けて気づいたのが、 ディスプレイに背後の照明が写り込まない 。これは快適なポイントのひとつかもしれない（Thunderbolt Displayはテカテカしており、映り込みが非常に鬱陶しい）。 Retinaディスプレイではないので、目を凝らしてMacBook Pro Retinaと比べてしまえば粗さは見えるけど、十分鮮やかで綺麗かと思われる。 iPhoneのカメラで鮮明さを伝えるのはハナから諦めているので、ご容赦頂けると。 感想 この価格でこの品質。 コスパはとても良い 。Thunderbolt Displayと比べて美しいかと言われると、解像度は 1,920 x 1,080 vs 2,560 x 1,440 だし劣るとは思われる。でも、安心のPHILIPSブランドということでデザインも中々オシャレだし、実際の表示もとても鮮やかで気に入っている。https://1000ch.net/posts/2014/reduce-http-requests-with-polymer-vulcanize/Fri, 05 Sep 2014 00:00:00 +0000https://1000ch.net/posts/2014/reduce-http-requests-with-polymer-vulcanize/Web Componentsの旨味はコンポーネントの再利用が出来る所にあるので、そのためにはそのリソースは断片化は避けられない。 <x-element>を構成するリソースはx-element.htmlに集約し、使うときにはHTML Importsでロードする。 実際には複数のWeb Componentsを利用したいケースは当たり前にあることなので、素直にやろうとすると以下のように。 <link rel="import" href="x-element.html"> <link rel="import" href="y-element.html"> <link rel="import" href="z-element.html"> このHTMLではこのWeb Componentsをロードしている というのが明確ではあるけど、インポートには当然HTTPリクエストを伴うので、パフォーマンスの観点からはあまりよろしくない。 今回はPolymerチームが提供しているVulcanizeを使ってこの辺りを最適化してみる。 Concatenating Web Components with Vulcanize Polymer/vulcanize インストールと使い方 npmからインストール出来るので早速インストール。 # vulcanizeのインストール $ npm install -g vulcanize vulcanizeコマンドを使って、インポートを行っているHTMLを指定する。 指定したHTMLファイル中でインポートしているHTMLを、インポート先に書き出して<link rel='import'>を除くような処理をする。 # index.html内の<link rel='import'>をアレコレしてbuild.htmlとして出力 $ vulcanize -o build.html index.html 実際にビルドされたリソースはインポートするHTMLを<div hidden></div>で挟んである以外は、結合だけされているような感じ。 HTML Importsの仕組みを考えれば、指定しているHTMLファイルを引っ張ってきてパースしているだけなので、直列に繋げた所で実行時に問題が起きないのも納得できる。 以下は、とある<y-elements>に依存している<x-element>のイメージ。 <link rel="import" href="y-element.html"> <template id="x-element-template"> <x-element> <content></content> </x-element> </template> <script> //... </script> これをVulcanizeしてみると <div hidden> <template id="y-element-template"> <div> <content></content> </div> </template> <script> //.https://1000ch.net/posts/2014/html5-links-rel/Mon, 01 Sep 2014 00:00:00 +0000https://1000ch.net/posts/2014/html5-links-rel/Web Componentsの流れでHTMLImportsをよく見るようになったり、パフォーマンス周りでプリフェッチ系の属性が<link>で指定するようになったりしている今日この頃。気になったのでW3Cの Links in HTML documents を眺めたメモ。 Links in HTML documents そもそもリンクとは一体何なのか？ Webにおけるリンクは、<a>と<link>の2種類がある。それらには、 Webのあらゆるリソースの場所 を示す役割が与えられている。つまり、hrefで指定しているURLがそれにあたる。そのURLの振る舞いの種類については、relやrevで記述する、と。revって削除されるんだっけ？ <img>や<form>といったように、リソースへのリンクはその他のHTML要素でも行う。が、<link>についてはドキュメントの<head>にだけ記述し描画されず、<a>はドキュメントの<body>にのみ現れる。 気になるrelの種類 relに指定するのは リンク元から見たリンク先の種別 。だから、利用シーンをあまり見ないけど、<a>でもrelは指定可能である。 6.12 Link types HTML4.01のRecommendation 4.8 Links — HTML5 HTML5のCandidate Recommendation HTML5の方を列挙してみる。 種類 <link> <a> & <area> 説明 alternate Hyperlink Hyperlink 代替となるドキュメントを指定する。 author Hyperlink Hyperlink ドキュメントや記事の著者へのリンクを指定する。 bookmark not allowed Hyperlink 最も近い先祖セクションへのパーマリンクを指定する。 help Hyperlink Hyperlink ドキュメントに対するヘルプへのリンクを指定する。 icon External Resource not allowed 現在のドキュメントを代理するアイコンをインポートする。 license Hyperlink Hyperlink 現在のドキュメントのライセンスを説明するドキュメントを指定する。 next Hyperlink Hyperlink 現在のドキュメントはシリーズの一部であることを示し、連続する次のドキュメントを指定する。 nofollow not allowed Annotation 現在のドキュメントのオリジナルの著者や発行者が参照されたドキュメントを支持しないことを示す。 noreferrer not allowed Annotation ハイパーリンクに飛ぶ際、HTTPリファラを送信しないことを要求する。 prefetch External Resource External Resource 先行してキャッシュされるべきリソースを指定する。 prev Hyperlink Hyperlink 現在のドキュメントはシリーズの一部であることを示し、連続する前のドキュメントを指定する。 search Hyperlink Hyperlink 現在のドキュメントや関連するページを探すためのリソースへのリンクを指定する。 stylesheet External Resource not allowed スタイルシートのインポート。 tag not allowed Hyperlink 与えられたアドレスで特定されるタグを付与する。 <link rel='dns-prefetch' href='[URL]'とかも対応ブラウザでは動くけど、ドラフトにもない。https://1000ch.net/posts/2014/web-components-and-html-imports/Sat, 30 Aug 2014 00:00:00 +0000https://1000ch.net/posts/2014/web-components-and-html-imports/慣例的に<link rel='import' href='x-element.html'>な感じでロードされているけど、前提として、 HTMLImportsである必要はない 。何故ならば、Web Componentsを構成する4つの仕様はそれぞれ独立しているからである。だから、インポートを使わなくてもdocument.registerElement()でカスタム要素の定義は出来るし、HTMLのひな形を使いたい場合に<template>タグを使っても良い。 HTMLを部品として含む場合 HTMLやCSSを部品として含む場合は、<template>タグや、ShadowDOMを駆使しながらパーツを構成していくので、HTMLファイルに書かざるを得ない。もちろん、JavaScriptだけで書けないこともないんだけど、本質ではない。 先日画像をスクロール同期的にロードする要素、 1000ch/lazyload-image を作ったけど、こちらはHTMLファイルではなく、単一のJSファイル。GitHubが作っている github/time-elements なんかも、time-elements.jsだけで構成されているけど、こういう場合は<link rel='import' href='x-element.html'>ではなく、<script src='x-element.js'></script>で事が足りる。 他のWeb Componentsに依存している場合 <x-element>が<y-element>に依存している場合は以下のように、x-element.html内でy-element.htmlをインポートする。 <link rel='import' href='y-element'> <template id="tmpl"> <div>This is x-element!</div> </template> <script> var XElementPrototype = Object.create(HTMLElement.prototype); XElementPrototype.createdCallback = function () { console.log(document.querySelector('#tmpl')); }; window.XElement = document.registerElement('x-element', { prototype: XElementPrototype }); </script> そのコンポーネントからの相対パスを得たい これは @hokaccha 氏が詳しく書いているが、Web Componentsとして配布するときに、画像等のサブリソースを含む場合は一工夫が必要になる。 HTML Importsで読み込まれたドキュメントからの相対パスを得る - Webtech Walker 例えば<x-element>というカスタムエレメントが以下のように、imgフォルダの配下にfoo.pngとbar.pngを含んだ構成とする。 x-element x-element.html img foo.png bar.png bowerなんかでインストールされればx-elementというフォルダごとダウンロードされて、いざインポートするときには<link rel='import' href='bower_components/x-element/x-element.html'>のようになる。 このとき、foo.pngとbar.pngを含むフォルダはbower_components/x-element/imgというパスになるけど、x-element.html側で素直にimg/foo.pngと参照していると、インポート元のドキュメントルートからそのパスを辿ることになるので、上手く参照出来ない。 だからdocument.baseURIを使って相対パスを得たいということになるが、この場合に、HTMLファイルでないとdocument.currentScript.ownerDocument.baseURIと、x-element.htmlからみたベースのURLを辿れない。URLオブジェクトと組み合わせるとアレコレするときに幾分スマートかも。 <script> var doc = document.https://1000ch.net/posts/2014/link-rel-stylesheet-in-shadow-dom/Wed, 27 Aug 2014 00:00:00 +0000https://1000ch.net/posts/2014/link-rel-stylesheet-in-shadow-dom/@nakajmg 氏がWeb Components使うときにハマったポイント3つという記事を書いてて気になったので調べてたメモ。 Web Componentsを構成する中でコンポーネントのスタイリングをするのは往々にしてあるけど、それに<link>は使えないので<style>にCSSを書くしかなさ気な話。 Shadow DOMに<link>が入っているNGケース <template id="tmpl"> <link rel="stylesheet" href="x-element.css"> <div>This is x-element!</div> </template> <script> window.XElement = (function () { var doc = document.currentScript.ownerDocument; var XElementPrototype = Object.create(HTMLElement.prototype); XElementPrototype.createdCallback = function () { this.shadowRoot = this.createShadowRoot(); var template = doc.querySelector('#tmpl'); var clone = document.importNode(template.content, true); this.shadowRoot.appendChild(clone); }; return document.registerElement('x-element', { prototype: XElementPrototype }); })(); </script> CSSをカプセル化したい気持ちを考えれば誰しもがこういうことをするんじゃないかと思ったりするけど、結論から言うと、ShadowDOMに埋め込まれる<link>は無効だそう。何故かは http://www.w3.org/TR/shadow-dom/#inert-html-elements を眺めてみると良い。以下引用。 7.1 Inert HTML Elements A subset of HTML elements must behave as inert, or not part of the document tree.https://1000ch.net/posts/2014/html-imports-context/Mon, 25 Aug 2014 00:00:00 +0000https://1000ch.net/posts/2014/html-imports-context/Polymerに慣れたあとに、いざピュアなWeb Componentsでやろうとするとハマるかもしれないポイント。 document.registerElement()と<template>やらを使ってWeb Componentsを構成するときに、ライフサイクルコールバック中にそのテンプレートタグを当然参照すると思いますが、インポートをしているとコンテキストになるdocumentがずれる話。 コードで見たほうが早いと思われるので早速例を。 Polymerを使ってx-elementを作る場合 x-element.htmlの例。 <link rel="import" href="lib/polymer/polymer.html"> <polymer-element name="x-element" attributes="foo bar"> <template id="tmpl"> <div>This is x-element!</div> </template> <script> Polymer('x-element', { ready: function () { // <template id="tmpl">を難なく取得出来る。 console.log(this.$.tmpl); } }); </script> </polymer> コメントに書いてあるけど、x-element.html内の要素を簡単に参照できる。なぜならばPolymerが上手いこと https://twitter.com/hokaccha/statuses/479063274881683457 みたいな仕組みを作っているからなんだけど、いざこれをピュアなWeb Componentsでやってみようとすると、どうなるか。 Polymerを使わずx-elementを作る場合 x-element.htmlの例。 <template id="tmpl"> <div>This is x-element!</div> </template> <script> var XElementPrototype = Object.create(HTMLElement.prototype); XElementPrototype.createdCallback = function () { console.log(document.querySelector('#tmpl')); }; window.XElement = document.registerElement('x-element', { prototype: XElementPrototype }); </script> 実は、いざこれをインポートしようとするとエラーが起きる。具体的にはdocument.querySelector('#tmpl')している箇所でエラーが起きるのだけど、なぜならばこのスクリプトを評価しているコンテキストが x-element.htmlをインポートしているHTML だからである。（逆に言えば、先程の<link rel='import'>ではなくHTMLにベタ書きすればコンテキストはそのままなのでOKではある。）https://1000ch.net/posts/2014/android-development-with-genymotion/Fri, 08 Aug 2014 00:00:00 +0000https://1000ch.net/posts/2014/android-development-with-genymotion/クライアントサイドのネイティブアプリを作れればiOSでもAndroidでも良かったのだけど、プラットフォームへの興味もあるし、Javaのリハビリもしたかったし、そんなこんなでAndroidをはじめた。 今回はAndroidの開発を始めるにあたり、どんな環境を構築したかのお話。 Android Studio or Eclipse まだAndroid StudioがBeta版なせいか、トップにはEclipseのダウンロードリンクが貼られていたりするけど、Android Studioを選んだ。Android Studioを推奨している雰囲気をひしひしと感じるのと、私は 『IDEといえばIntelliJかWebStormでしょ』 という属性の人間なので、IntelliJ Platformなら間違いないだろ！という偏った視点もありつつ。 古いデバイスを考慮するにしても、SDKがあれば後方互換性については特に気にすることなく開発が出来るはずなので、Eclipseはアプリ開発の互換性というよりプロジェクトの開発互換性のために残されているのでは。 Android StudioもCanary Buildを使う もはや気持ちの問題かと思いますが、新しいビルドのものを使っておこうということで設定をする。 Preferences (cmd + ,)を開いて、 Updates を選択すると、更新チェックするチャネルを選べるので、 Canary Channel を選択。 スタンドアロンなSDKを用意する EclipseにもAndroid StudioにもSDKは同梱されているんだけど、別途用意して指定した。以下からダウンロードし、適当な場所に配置。 Installing the Stand-alone SDK Tools IDEにバンドルされているSDKでも基本的に問題は無さそうだが、気分的に別途管理したかったのと、詳しい人に聞いてみると、Eclipseからも同じSDKを参照したい場合等にスタンドアロンにしておかないと面倒と言っていた。なるほど。 Android StudioからスタンドアロンなSDKを参照するので、 Project Structure (cmd + ;)を開いて、 SDK Location > Android SDK Location にダウンロードして解凍したディレクトリルートを指定する。 エミュレータの設定 ここまで設定して、ようやくコードを書いていけるようになる。チュートリアルに沿ってプロジェクトを作成すると、いわゆる Hello World! が用意された空プロジェクトが出来上がる（このプロセスは割愛）。 自動作成されたプロジェクトは既にコンパイルして実行することが可能になっているが、 Run から実行しようとすると Choose Device という画面が表示され、どの環境で実行するかを聞かれる。最初はここが空の状態のはず。 Launch Emulator - Android Studio上で仮想のAndroid環境を作ってそれを指定することが出来る。その仮想環境は Android Virtual Device の頭文字を取って AVD と呼ぶみたい。 AVD Manager からデバイスの種類やターゲットになるAndroidのバージョン等を細かく指定してイメージを作ることが出来る。 Choose a running device こっちは接続中のデバイスを使ってアプリケーションを起動する。たぶん、コードをビルドして.https://1000ch.net/posts/2014/css-architexture-textbook/Mon, 04 Aug 2014 00:00:00 +0000https://1000ch.net/posts/2014/css-architexture-textbook/( •́谷•̀)「CSSの本書いたよーヽ(=´▽`=)ﾉ」 ということで@hilokiさんから頂きました。ありがとうございます。 著者（@hiloki）について 前著も有名で、私から改めて紹介するまでもないかもしれませんが、カンファレンスや様々な勉強会でCSSについての講演を数多く行ってきており、 CSSが持つ弱点を理解し、設計の重要性を訴えてきた有識者の一人 です。 スライドを見ると分かる通り、CSSプリプロセッサの話に始まり、CSSの設計の話や、最近ではWeb Componentsを交えた話もされていて、CSSと戦ってきた傷跡が生生と感じられます（大袈裟）。今回の著書は得てきたナレッジの集大成といえるのではないでしょうか。 谷 拓樹 (著) 内容について 各章の概要をざっと振り返ってみます。 第1章 CSSにおける設計とは 第2章 CSSの基本を振り返る 第3章 コンポーネント設計のアイデア 第4章 コンポーネント設計の実践 第5章 CSSプリプロセッサを用いた設計と管理 第6章 コンポーネントの運用に必要なツール 第7章 Web Componentsの可能性 第1章 CSSにおける設計とは + 第2章 CSSの基本を振り返る では、CSSの特徴を踏まえた基礎理念について書かれています。この辺りはCode smells in CSSに感化されている部分もあるかもしれません。 第3章 コンポーネント設計のアイデア + 第4章 コンポーネント設計の実践 では、HTMLとCSSで作成したUIパーツのコンポーネント化（流用しやすい形にする）について。CSSには、一般的なプログラム言語が備えるスコープが存在せず、同名のクラスが宣言されるとスタイリングが上書きされてしまうという特徴があります。 そういった問題に対しては命名規則を工夫するというアプローチが数多くされてきました。コンポーネント設計を念頭に置きつつ、OOCSS、SMACSS、BEM、MCSSの理念や、それらの手法を咀嚼した谷氏が新たに発案するCSSの手法としてFLOCSSについても触れています。 第5章 CSSプリプロセッサを用いた設計と管理 + 第6章 コンポーネントの運用に必要なツール では、Sass等のプリプロセッサを用いてCSSの運用を行う際に気をつけることや、StyleStatsやスタイルガイドを用いたCSSの品質管理及びデザイナーとの連携を前提にした運用の手法、そしてGruntに代表されるタスクランナーを使ってそれらの作業をどのように自動化していくか等について触れています。 黎明期のWebは所謂ホームページとしての役割が濃かったですが、昨今のWebはよりアプリケーションとしての性質が強いです。開発規模は比較にならないほど大きくなり、UIも複雑化し、パフォーマンスも重要視されるようになっています。そんな現代のWeb開発に必要な知識がまとまっています。 第7章 Web Componentsの可能性 第3章と第4章で触れていたCSSの弱点に対する工夫に対し、近年では Web Components というHTMLとCSSにスコープを実現する新しい仕様が策定されつつあります。Web Components によって弱点が補われますが、ブラウザネイティブに実装され、安定して使えるようになるのはまだ先ですし、Web Componentsが実現してもCSSの設計が重要であることは変わりません。第7章では、Web Componentsを構成する4つの新しい仕様と、特徴および具体的に何が解決されるかについて書かれています。 買いの一冊 各章のサマリーを書きましたが、Web開発におけるCSSの重要性をここまで説いた本は今まで無かったのではないでしょうか。HTMLとCSSのマークアップをする開発者はもちろん、フロントエンドのワークフローを理解して欲しいという個人的な理由で、 デザイナーの方々にもオススメな一冊 です。 この本を読んで、より良いWeb開発を。 谷 拓樹 (著)https://1000ch.net/posts/2014/html5-and-other-vol49/Thu, 31 Jul 2014 00:00:00 +0000https://1000ch.net/posts/2014/html5-and-other-vol49/第49回 HTML5とか勉強会 -HTML5最新情報 @Google I/O- でWeb ComponentsとPolymerについてお話してきました。 Google I/O 2014に参加したことは前段の通りで、 今回はEric Bidelmanによる、 Polymer and Web Components change everything you know about Web development のフィードバックという形でセッションしました。 会場はグリー@六本木ヒルズで開催されましたが、そのセミナールームをほぼ埋める300人超の参加者がいまして戦々恐々としてました。 当日の資料等 諸事情でスライドに十分な時間を割くことが出来ず、当日時点ではシンプルなスライドになっていたのですが それを参加者の人に指摘されました。手を抜いたつもりは更々ありません（確かに簡素ではあったけど！）。 というわけで、Speakerdeckに事後装飾済みの資料をアップしてあります。 Google I/O 2014でのWeb Components/Polymerに関する新ネタとしては、やはりMaterial DesignからのPaper Elementsが色濃かったような印象で、その他は2014年の状況に合わせてアップデートされた内容でした。 フォローアップも兼ねてHTML5 Experts.jpに Web Componentsが変えるWeb開発の未来 という記事も書いていますので、宜しければどうぞ。 Web Components ∈ Polymer 発表中に話しましたが、私個人の意見としては Web Componentsの各種仕様を理解し、ネイティブAPIを触ってみる それを踏まえてPolymerが何をしているかを学習し、利用する という流れをオススメします。Polymerは便利でWeb Componentsの普及に欠かせない存在であることについては疑う余地がありませんが、故にWeb ComponentsとPolymerがやや混同されているような印象を受けるので、それを拭いたい気持ちがぼんやりと。 jQueryが流行り過ぎて、あたかも JavaScript = jQuery のような誤解が一時期溢れていたことに非常に違和感を感じていたので、同じ道は辿ってほしくないなぁ…。 あくまで、 JavaScript ∋ jQuery であり、 Web Components ∋ Polymer です。jQueryやらPolymerから学習することを止める気は更々ありませんが、jQueryをやってみたい人にはJavaScriptを勉強することをオススメするように、今からWeb Componentsをやってみたいと考えている人には、まずWeb Componentsの基礎からやってみるといいですよ！と言うでしょう。 Let’s Web Components!https://1000ch.net/posts/2014/x-notification/Tue, 15 Jul 2014 00:00:00 +0000https://1000ch.net/posts/2014/x-notification/巷で話題のWeb Componentsですが、コンポーネント化していくのは所謂UIパーツだけに留まりません。 XMLHttpRequest部分を抽象化しているcore-ajaxとか、core-localstorageとか。 そんなわけで試しにNotification API周りをラップしたx-notificationを作ってみた。 これを使えば、今までJavaScriptから実行していた部分を、HTML内で宣言的に記述することが可能になる。有意義かどうかは、さておき。 ダウンロード npmかbowerでどうぞ。もちろんリポジトリをクローンでも。 $ npm install x-notification $ bower install x-notification 使い方 使いたいページで、x-notification.htmlをインポートする。 <link rel='import' href='x-notification.html'> あとは<x-notification>タグを記述する。 <x-notification autoshow title='バルーンのタイトル'>バルーンの本文</x-notification> 自動で表示したい場合はautoshow属性を付与することで自動で表示されて、 JavaScript側でコントロールしたい場合は対象の<x-notification>要素を取得し、show()を実行する。 document.querySelector('x-notification').show(); 属性等の詳細はリポジトリを参照して下さい。 環境とか NotificationのAPIが実装されていないとダメなのはもちろんのこと、 HTMLImportやらDocument#registerElement()やら、Web Components周りのAPIが無いと動きません。 ただ、Web Components側のAPI群に関してはPolymer/platform等でPolyfillすれば動きます。 Re-designed x-notification landing page with Polymer including Paper Elements. http://1000ch.github.io/x-notification #Polymer #WebComponents #PaperElements — 1000ch (@1000ch_en) 2014, 7月 2 x-notification自体はピュアなWeb Componentsだけど、デモ用にx-notification-editorというPolymerを使ったWeb Componentsを作った。 x-notification-editor内にx-notificationを内包し、PaperElementsを駆使して動的にx-notificationの属性値をいじれるようにしている。 http://1000ch.github.io/x-notification/ - デモページ https://github.com/1000ch/x-notification/blob/master/x-notification-editor.html - x-notification-editor要素 Customize Example の所にソースコードを表示するようにしてあって、 そこはPolymerが提供している2-way bindingをたっぷり使っている。これは便利だと思った。 CustomElements.io You can find x-notification on http://t.https://1000ch.net/posts/2014/google-io-2014/Fri, 27 Jun 2014 00:00:00 +0000https://1000ch.net/posts/2014/google-io-2014/サンフランシスコに来ています。 各セッションは後ほど公開されるものもあるし、Keynoteのサマリー等はHTML5Experts.jpを見てもらうとして、主に 初海外・初Google I/O の感想を。 参加したセッション等 1日目 Keynote [Session] Performance culture [Session] Polymer and Web Components change everything you know about Web development [Session] HTTPS Everywhere [Session] Designing for wearables [Session] After Hours [Party] 2日目 Optimizing for the user experience with WebPagetest [Developer Sandbox: Chrome] Cardboard: VR for Android [Session] Mobile Web performance auditing [Session] Nippon meet up [Community Lounge] 5 Chrome DevTool tricks for a faster mobile website [Developer Sandbox: Chrome] Making music mobile [Session] Material Design: Visuals & Imagery [Session] Speechless at I/O [Session] Keynoteは次世代のAndroid L を中心とした話だった。マテリアルデザインに力を入れてくようで、Material Design Systemなるものが発表された。SDKにもこの手のものが増えたり、デザインレギュレーションが前より強化・充実するのでしょうか。WebだとPolymer Coreを拡張しているPaper Elementsあたりが、実際にMaterial Design Systemを実装しており、UIエフェクトを中心としたインタラクションが充実している様子。https://1000ch.net/posts/2014/wdpress-frontend-series-webrtc/Thu, 19 Jun 2014 00:00:00 +0000https://1000ch.net/posts/2014/wdpress-frontend-series-webrtc/来たる6月24日に発売するWEB+DB PRESS Vol.81から「Webフロントエンド最前線」という連載を担当させていただくことになりました。巷に溢れかえっているフロントエンド技術の中でも特に注目すべきモノを、 「流行に乗り遅れず、そして踊らされないようにキャッチアップしていく」 というコンセプトの連載です。 連載は@ahomuさんと共同で執筆していくことになります。各号を交代で担当するのか、はたまた分割して執筆していくのか決まっているわけではなく、状況に応じてやっていくことになりそう。 連載第1回目は「WebRTCでブラウザ間P2P通信」 今回（Vol.81）については私が WebRTC について執筆しました。通信にサーバーを経由せず、ブラウザ同士で通信させちゃうアレです。 内容としては、P2P通信やリアルタイム通信と表されるWebSocketとの比較といったようなWebRTCの基礎理論から、WebRTCのAPIを実際に使ったビデオチャットのコードの詳細な解説、最後にPeerJSとSkyWayの簡単な紹介が盛り込まれています。 この記事で何かとてつもないアプリが作れるようになるわけではありませんが、 なぜWebRTCを使うのか 、 WebRTCのどこがイケてるのか はきっとわかるはずです。基礎の理解、大事。 Special Thanks to @sugimoto1981! 長嶋 享 (著), 藤 吾郎 (著), 八木 俊広 (著), 日高 一明 (著), 滝口 健太郎 (著), 田中 慎司 (著), 泉水 翔吾 (著), 海野 弘成 (著), 佐藤 太一 (著), 吉村 総一郎 (著), 伊藤 直也 (著), 川上 大喜 (著), こしば としあき (著), 舘野 祐一 (著), 中島 聡 (著), 橋本 翔 (著), 渡邊 恵太 (著), はまちや2 (著), 竹原 (著), 川添 貴生 (著), 沢渡 真雪 (著), WEB+DB PRESS編集部 (編集) 連続で著書の紹介になってしまいましたが、どうぞお手にとって見てください！（アフィリンクです）https://1000ch.net/posts/2014/frontend-engineer-training-book/Mon, 16 Jun 2014 00:00:00 +0000https://1000ch.net/posts/2014/frontend-engineer-training-book/フロントエンドエンジニア養成読本という本を共著で執筆しました。技術評論社さんから刊行されます。 7/2発売です！ / “http://t.co/cxQm0qCTFU： フロントエンドエンジニア養成読本 [HTML、CSS、JavaScriptの基本から現場で役立つ技術まで満載! ] (Software Design plus…” http://t.co/IeOxwfY1ZY — 1000ch (@1000ch) 2014, 6月 13 変化の激しいWeb技術ですが、昨今の要所を抑えつつ、（出来るだけ）息長く今後に活かせるような内容を取り扱っています。 カバー範囲が広い（後述）1冊になっていますが、自分に足りない、あるいは興味のある章だけ掻い摘んでもらっても、きっと何か得るものがあるかと。 私自身、執筆にあたって勉強したのはもちろんですが、他の章を見ながらたくさん勉強させて頂きました。 構成と概要 以下の様な構成になっています。 特集1 フロントエンドエンジニアとしての基礎と準備 求められるフロントエンジニアの姿から、HTML/CSS/JavaScriptやウェブブラウザ・UI/UX入門といったような、基礎理論の第1章。 第1章 フロントエンドエンジニアとは?…斉藤祐也 第2章 Webブラウザの基礎知識…斉藤祐也 第3章 UI/UXデザイン入門…石本光司 第4章 HTML/CSS/JavaScript基礎…加藤賢一 特集2 フロントエンド開発フィールドガイド Gitを使ったバージョン管理や・テスト・セキュリティを含めた、より実践的なテクニックを得るための第2章。 第5章 マークアップクイックレシピ…水野隼登 第6章 CSS実践入門…谷 拓樹 第7章 JavaScriptの設計と指針…泉水翔吾 第8章 モバイル・マルチデバイスへの対応…原 一成 第9章 フロントエンドの開発環境…石本光司 第10章 JavaScript開発におけるテスト…平木 聡 第11章 パフォーマンス入門…佐藤 歩 第12章 Gitでバージョン管理…原 一成 第13章 現場で使える品質管理…平木 聡 第14章 セキュリティ対策の基本…杉本吉章 特集3 フロントエンド開発最前線 第3章では、投資編として、Web Components・WebRTC・ECMAScript 6を今後キャッチアップしていくべき技術として解説。 第15章 Web Components入門…谷 拓樹 第16章 ECMAScript 6…泉水翔吾 第17章 WebRTCの実装…杉本吉章 感想とか どんな感じで進行するのか予想できていなかったですが、いざ執筆が始まると、pushによる牽制のし合いに加えて、大勢の共著体制という大人の責任感によってスケジュールにも然程(?https://1000ch.net/posts/2014/high-performance-browser-networking/Thu, 22 May 2014 00:00:00 +0000https://1000ch.net/posts/2014/high-performance-browser-networking/オライリー・ジャパン様より本を頂きましたので、その感想を。 頂いたのは ハイパフォーマンス ブラウザネットワーキング という、Ilya Grigorik氏執筆の日本語訳本。 サブタイトルに ネットワークアプリケーションのためのパフォーマンス最適化 と付いている通り、TCP、UDPといったトランスポートレイヤからアプリケーションレイヤまでのプロトコルの原理に始まり、Webアプリのパフォーマンス最適化アプローチ、ブラウザの通信系API（XHR・WebSocket・WebRTC）と現存のネットワーク技術を幅広く、そして詳細に取り扱っている書籍です。 Webパフォーマンスとしてのネットワーク Webサイトのパフォーマンスの重要性についてはもとより、それを構成するファクターは複雑化を辿る一方です。Webサイトのあり方が凄まじい勢いで変化している中で、とある1つのWebサイトにおいてどれが重要なパフォーマンスファクターになるのかは事の次第によります。 スマートフォンの性能が瞬く間に向上してきたように、クライアントデバイスの進化が早いことに対し、ネットワークの進化はとても遅いです。そして、モバイルであれば基地局との距離や、周辺の建物の電波状態に左右されるように、非常に不安定な状況にあります。 そのような背景に加え、ネットワークはユーザーにコンテンツを届けるフローの最初に当たる、一番始めに最適化するべき指標と考えます。本書ではそのネットワークに関するアプローチも、サーバーの配信の最適化からブラウザの挙動の観点からのコンテンツ要求の接続管理に至るまで、網羅的に解説してあります。 本書の読者ターゲット ネットワークについては各所で仕入れて用語と概要がなんとなくわかるレベルの私にとっては、第Ⅰ章のネットワークの基礎や第Ⅲ章のHTTPのような低レイヤに触れている章が、特に読んでて非常に面白い内容でした。この辺りのTCP、UDP、TLSといった基礎理論も多いので、本当に真っさらな状態（IPやHTTPリクエストと言った用語がぼんやりレベルですらわからない）だと辛いかもしれません。 モバイルネットワークにおける最適化・Webパフォーマンス・アプリケーション配信最適化についてもそれまでの基礎理論を踏まえた内容になっているので、最適化の章だけ読むよりはネットワークのコンテキストを得てから読む方が効果的です。業務でもWebサービスのパフォーマンス改善をやっているので、掘り下げて併せて理解することが出来ました。 約360ページで内容も非常に濃いものになっており、お手軽とは言えませんが、4000円と時間を投じて消化する価値があります。フロントエンドのエンジニアにとっても、バックエンドのエンジニアにとっても、双方のレイヤを理解するきっかけになる、抑えておくべき一冊です。 Ilya Grigorik (著), 和田 祐一郎 (翻訳), 株式会社プログラミングシステム社 (翻訳) 英語版であればWeb上で閲覧可能ですが、ボリュームもありますし、日本語訳を読めるのはやはりありがたいです。 HPBNj #HPBNjがハッシュタグです。流れているツイートの通り、いわゆる 絶対読め系の本 です。 10章「Webパフォーマンス入門」が大変良かったので書きました / フロントエンドエンジニアから見た『ハイパフォーマンス ブラウザネットワーキング』 - じまぐてっく http://t.co/fXHAXorK2e #HPBNj — じまぐ (@nakajmg) 2014, 5月 13 読了ハイパフォーマンス「ブラウザ」ネットワーキング ::ハブろぐ http://t.co/hYFX0ZgMHr ありがとうございました #HPBNj — あほむ (@ahomu) 2014, 5月 19 余談 余談ですが、本書の冒頭で、現在FastlyでChief Performance Officerを務めるSteve Souders氏（以前までGoogleでHead Performance Engineerとして働いていた）は、著者のIlya Grigorick氏を「ネットワークの神様」と称賛しています。 Steve Souders (著), 武舎 広幸 (翻訳), 福地 太郎 (翻訳), 武舎 るみ (翻訳) Steve Souders (著), 武舎 広幸 (翻訳), 福地 太郎 (翻訳), 武舎 るみ (翻訳)https://1000ch.net/posts/2014/english/Mon, 19 May 2014 00:00:00 +0000https://1000ch.net/posts/2014/english/近々、隣の席の友人が語学留学で比国に発つのでたまにはこういう記事も書いてみたくなる。語学というのはもちろん、Web界隈にいると避けて通れない英語。 きっかけと今に至るまで 今の会社への転職がそのままWeb業界へ足を踏み入れるタイミングで、約1年10ヶ月前のこと。転職の際に、とある恩師にWebにおける英語の重要性を説かれたのがきっかけ。幾つか購読するべき英語のRSSを紹介されて、読むようになった。最初は会話で飛び交っていてもさっぱりわからなかった海外の著名人も、今ではすっかり顔と名前がマッピングされてきた。 元々英語の技量については、学校英語をそれなりにやってきた程度で、大学の進級要件にTOEICもしくはTOEFLで一定のスコアを取らないと進級出来ないというのがあったので、それを突破するために一時的に勉強した時期はある。が、海外留学をしただとか、英会話教室に通った等の経験は無く、リスニング・スピーキングに関する部分はお手上げレベル。日本の英語教育ってこうなる（今現在のカリキュラムはまた違うのかもしれないけど）。 翻訳のアウトプット RSSリーダーに流れてくる記事を眺める他は、enja-ossやhtml5j-englishといった場所で翻訳をしている。 前者はオープンソース・ソフトウェア（OSS）のドキュメントをGitHubを使って複数人で翻訳するコミュニティ。活動停滞気味なので、活性化して欲しい。後者はhtml5jの部のひとつで、html5rocksやwebplatform等を翻訳ターゲットとする(?)コミュニティ。こちらはリアルの勉強会の場で集まって翻訳をする。 翻訳した結果は訳者のクレジットと共に何らかの形でWebに残るようになっている。フローに監訳があるので、英語が苦手な人も安心して誤訳出来る。間違えても学習すれば良いと思う。 英語から日本語に変換する過程で難しいのは、英文に対する日本語を考えるところ。ある程度の語彙力と英文法に対する理解があっても、翻訳力は別物と考えるべきだと思った。 原文の筆者が伝えたいメッセージを齟齬なく沢山の人が納得する形で日本語に直す というのはとても難しいことだ。普段は英語を読む時にいちいち日本語に直さないので、翻訳力を鍛える場になっている。 ライティング 英語でのアウトプットとしては、英語圏の人とのチャットは英語でするようにしている。あとはMediumに記事を投稿してみた。redditに投げてみたら議論の対象になったようで、伝えたいこともなんとなく伝わったよう。こちらも翻訳以上に、フィードバックして英語のリファクタリングを繰り返さなければ上手くならなそう。 文章は下手なりにゼロから組み立てた。リーディングも然りだが、英文を解体して、文法に当てはめないとリーディング力・ライティング力の向上には繋がらないと思ってる。一度組み立てた文章は、少しずつWeblioに貼り付けて他の言い回しを調べながらリファクタリングした。 リスニング・スピーキング リスニング・スピーキングに関しては皆無である。記事冒頭で、海外の著名人がわかるようになってきた話をしたが、その著名人達が日本で講演する機会に会ったり、札幌に行ったときに@simuraiに会ったりもした。が、いずれも満足に喋れずに終わっていて非常に勿体無く思った。 同じ言語だが、リーディング・ライティングとは異なる技術だと捉えていて、それはその学習環境を作り上げる難しさにあると思っている。日本であれば、英会話教室で、他は英語圏全般だろうか。いずれも、時間的にも物理的にも安くない投資になる。これについてはレアジョブを選んでみようと思ってるけど、それでも拘束力は弱いので、結局ヤル気をどこまで維持出来るか、如何に習慣化出来るか。 英語を学習する意義 Webに関するリソースは、日本語に比べるというよりも英語が圧倒的な量なので、英語読めたり、聞けたら比較にならない量をインプット出来る。書いたり、喋れたら英語圏へリーチ出来て尚良いけど、まずはインプットから始めたい。別に日本語リソースを読まないわけじゃなくて、参考にさせてもらってる日本語ブログは沢山ある。 英語リソースを獲得することで、前述の量の観点以外に、情報の鮮度も期待出来る。Webを牽引しているのはW3Cであり、Googleであり、Mozillaである。そしてそれらは英語で発信されるので、日本語に変換されるのを待っているよりは、英語を読む力を身につけてしまったほうが、良い。極論、日本がWebを牽引して日本語が基準になるなら英語やらなくても良いのかも。https://1000ch.net/posts/2014/flask-mongodb-polymer/Wed, 12 Mar 2014 00:00:00 +0000https://1000ch.net/posts/2014/flask-mongodb-polymer/Pythonで何かアプリ書きたいなと思ってはいたので、RSSリーダーを作った。フレームワークは薄いやつが良かったのでFlaskを、データはMongoDBに突っ込んでいる。 Flask + MongoDBのところまで実装して暫く放置していたけど、最近思いつきでPolymerをねじ込んだので記事にしてみる。 やってること スケジューラでopmlに登録してあるRSSから記事を取得しMongoDBに保存 トップページで50件ずつ記事の表示 & 非同期で50件づつ取得 購読しているRSSで表示する記事をフィルタ Opml(XML)のパース→記事の取得 に非常に時間が掛かるので、データストアに入れておいてそこから取得しないとRSSリーダーとして非実用的。この定期的な取得処理をHeroku Schedulerで実行している。あと遊び半分でNew Relicも入れてある。ここまで色々遊べて無料。Heroku良い。 最初は格納してあるデータを全件取得して表示していたが、50件ずつ表示にしたことで使い心地はやや下がった。Polymerを使いたかっただけ。 PythonとFlask Flaskは、軽量なWebアプリケーションフレームワーク。マイクロフレームワークの意味するところはシンプルなコアな機能と拡張性を持たせている点であり、それ自体にはデータベースレイヤへのアクセスモジュールなどはないが、様々な拡張モジュールが存在する。例えば、これについてはSQLAlchemyというORマッパーがある。日本語のハンズオンとドキュメントも充実している。 Pythonは、プロパティアクセスとかリテラル（配列・オブジェクト）がJavaScriptとほぼ同じだし、JavaScriptやってる人ならあまり違和感なくやれるのではと思ったり。 // JavaScriptでのArrayとObject var array = [0, 1, 2]; var object = { key: 'value' }; // 出力 console.log(object.key); # PythonでのArrayとObject array = [0, 1, 2] object = { key: 'value' } # 出力 print(object.key); 言語レベルでインデントを強制されるので、実装がばらつかない。 MongoDBへのアクセス MongoDBへのアクセスはpymongoで実装。MongoDBを使ったことはなかったが、ここに関してもあまり悩まず実装できた。ローカルでデバッグするときはHomebrewでインストールしたMongoDBをデーモン実行しておくのと、Herokuのときは環境変数からURLを得るようにする。 # install mongodb $ brew install mongo # run mongo $ mongod # run application $ python run.https://1000ch.net/posts/2014/grunt-image/Mon, 03 Feb 2014 00:00:00 +0000https://1000ch.net/posts/2014/grunt-image/Webにおける画像については以前記事にしたが、 そのフローをより良くするべく最近gruntのモジュールを作ったのでその話を。 前置き 私の業務は弊社サービスのパフォーマンス改善を業務。何がボトルネックになっているかは各プロジェクトでまちまちだが、共通しているのが 「とにかく画像が多い」 というところ。どのサービスもペイロードサイズの80%程を画像が占めている。 画像の最適化を忘れるだけで（例えば）100KBとか平気で増えるので、これではCSSやJavaScriptのファイルサイズを減らしても本末転倒である（もちろんCSSもJavaScriptも結合と圧縮は非常に重要だけど！）。 各種最適化ツール ではどうやって画像を最適化するのか、という話になるが、GUIだと以下の3つが有名で優秀。 ImageAlpha: フリーソフト。24bitのPNGの8bitコンバートを行う。256色~2色までパレットのカラー数もコントロールすることが可能で減色後の状態も視認出来る。 ImageOptim: フリーソフト。画像の最適化ライブラリを各種内包している。PNG、JPG、GIFのメタ情報周りを主にダイエットしてくれる。 JPEGmini: 有料ソフト。JPG画像を劣化の少ない状態でダイエットしてくれる。 GUIを使った開発フローがあっても、最適化し忘れというのが必ず起こる。人間だし。これを突き詰めていくと、自然と自動化という発想に至る。 gruntjs/grunt-contrib-imagemin: gruntモジュール。内包ライブラリがちょっと少ない。 JamieMason / ImageOptim-CLI: ImageOptimとImageAlphaをCLIから実行するgruntモジュール。自動化出来るが、GUIをキックしているだけなのでLinux等で実行出来ない。 JamieMason/grunt-imageoptim: ImageOptim-CLIのgruntモジュール。 Jenkins等のCIツールで使うことを考えるとLinux環境で実行できることが条件になる。gruntjs/grunt-contrib-imageminはLinuxでもMacでも実行出来るけど内包ライブラリが不十分だし、grunt-imageoptimはImageOptimとImageAlphaを使うだけあってほぼ完璧な最適化をしてくれるけどMac環境が必須…。 というわけで、作った。 grunt-image ImageAlphaとImageOptimで使っているライブラリ群を内包している他、追加でjpeg-recompressというライブラリも含んでいる。 CLIで完結しているものはrubyでは既にあったりするが、Node.jsのほうが便利な気がしている。これでローカル環境での実行はもちろん、CIツールとの連携も楽になるはず。 いつも通りnpm install --save-dev grunt-imageでインストール可能。gruntfile.jsの設定はREADMEを参考にどうぞ。他にも設定したい項目があったり、この圧縮オプションも使うと良いですよ等あれば、issuesから一報ください。 Node.jsのモジュールも幾つか作った 余談だが、ライブラリの依存関係をnpmで解決したかったのでNode.jsでラップされていないモジュールは自分で作った。 1000ch/node-zopflipng-bin 1000ch/node-pngcrush-bin 1000ch/node-jpeg-recompress-bin ライブラリ単独で使う要件があればどうぞ。 ぼやき 画像が増えてしまうことはある種宿命だとは思っているものの、デザイナーとその辺の意識を分かち合えないと最高のWebパフォーマンスは出ない。かと言ってデザイナーがクリエイティビティを失う結果になってもまずいし。 でもWebパフォーマンスが重要なのは事実だし、画像を使えば少なからずコストがかかる（モバイルWebに於いては特に）のも事実。バランスを取りながらやっていかないといけない。https://1000ch.net/posts/2014/frontrend-in-fukuoka/Sun, 02 Feb 2014 00:00:00 +0000https://1000ch.net/posts/2014/frontrend-in-fukuoka/2014年1月25日にFrontrend in Fukuokaが開催されました。 Frontrend/fukuoka FRONTREND IN FUKUOKA Frontrend in Fukuoka - Togetterまとめ Frontrend in Fukuoka レポート ｜1 pixel｜サイバーエージェント公式クリエイターズブログ 今回はエンジニア向け・デザイナー向け・ハンズオンと3つのトラックで並行してセッションが行われました。 福岡のWebコミュニティFukuoka Frontend Frogs、特定非営利活動法人 AIP、弊社CyberAgentの福岡オフィスの皆さんのご協力の元、 最終的には約200名という規模の勉強会でした。 感想とか 参加者は社会人の方の他、地元の学生さんもたくさんいたのがとても印象的でした。 専門学校でWebの勉強をしているそうで、意識高くてびっくりしました。 ここまで若い時からWebに触れていられるのはとても羨ましいです。福岡のWebの未来も明るいですね。 職種もデザイナーさん・ディレクターさん・エンジニアさんと様々で、 初の試みだった3トラック制やハンズオンですが、参加者が興味のある部分を選ぶ形もいいなと思いました。 デザイナートラックに人が多かったところを見ると、比率的にデザイナーさんが多かったんでしょうか。 私のセッションではBrowser Computing Structureということで、WebサイトのパフォーマンスをComputingの観点から攻めるべく ブラウザの仕組みを知り、メモリの仕組みを知り、JavaScriptを制すといったような内容でした。 参考リンクはこちらをどうぞ。ボリューム多いですが、参考になるリンクばかりです。 ありがとうございました 前日当日ともに皆さんとお話が出来てとても楽しかったです。 みなさん本当にお疲れ様でした。ありがとうございました！ また色んなアウトプットは続けていきますので、どうぞ宜しくお願い致します。 P.S. 福岡に行って衝撃の鉄鍋餃子でお出迎えをしていただきましたが、 まんまとハマってしまい、皆が渋谷で鉄鍋餃子を探す日々が続いております。https://1000ch.net/posts/2013/es6-features-2/Fri, 27 Dec 2013 00:00:00 +0000https://1000ch.net/posts/2013/es6-features-2/先日の記事で、 続き(?)はまた新年 と、言ったばかりだけど、続きを。引き続きFirefox Nightlyで試していく。 Default Parameters 関数の引数にデフォルト値を与えることが出来る。今まではこのような形で引数のチェックをする必要があった。 function fn(arg1, arg2) { arg1 = arg1 || 0; arg2 = arg2 || 1; console.log('arg1 is ' + arg1); console.log('arg2 is ' + arg2); } fn(10); // arg1 is 10 // arg2 is 1 fn(undefined, 5); // arg1 is 0 // arg2 is 5 Default Parameterを使うと、 function fn(arg1 = 0, arg2 = 1) { console.log('arg1 is ' + arg1); console.log('arg2 is ' + arg2); } fn(10); // arg1 is 10 // arg2 is 1 fn(undefined, 5); // arg1 is 0 // arg2 is 5 うーん、便利だ。が、厳密に言うと上下でやっていることは違っていて、例えば、nullを入れるとデフォルト値は代入されずに評価される。nullはnullという値なので当たり前といえばそれまでだけど、挙動を理解した上で使ったほうが良い。デフォルトパラメータの挙動はアレコレやってるみたいなのでこの先も要チェック。https://1000ch.net/posts/2013/es6-features-1/Thu, 26 Dec 2013 00:00:00 +0000https://1000ch.net/posts/2013/es6-features-1/ES6のフォローについては書こうとしていたものの後手に回っていて、ようやく書くに至る。SetやらMapやら、追加クラスのあたりは実装されても試そうとした時にそんなに障壁にならない気がしてるけど、letとかconst、アローファンクション等々、シンタックスが関わる辺はつっかえ棒になりかねないので消化しておく。 この段階での実装状況はNightly > Canary Chrome Canary 34.0.1760.0 Firefox Nightly 29.0a1 (2013-12-25) この2つをECMAScript 6 compatibility tableで比較するとNightlyのほうが先行実装は進んでいるのでNightlyでアレコレする。Canaryだと試したいシンタックス部分がまだ実装されていないので断念。 Canaryでデバッグしたい人はES6実装を有効にするフラグをたてる必要があるので、chrome://flagsにアクセスして#enable-javascript-harmonyでページを検索すると JavaScript の試験運用機能を有効にする という項目があるのでそれを有効にする。あとはDevTool開いてConsoleでいつも通り試せる。が、今回はFirefoxなのでScratchpadでやる。使い慣れてない…。 let letを使うことでブロックスコープの変数宣言が可能になる。 まず、今までのvarを使ったパターン。（これだとそもそもlintで怒られるけど、挙動のテストということで。） var x = 1; if (true) { var x = 2; console.log('x is ' + x); // x is 2 } console.log('x is ' + x); // x is 2 このケースだと最初に宣言したxがif内で上書きされ、2回とも2が出力される。ここでletを使ってみる。 let x = 1; if (true) { let x = 2; console.log('x is ' + x); // x is 2 } console.https://1000ch.net/posts/2013/sacss-follow-up/Tue, 10 Dec 2013 00:00:00 +0000https://1000ch.net/posts/2013/sacss-follow-up/人生初の北海道でした。新千歳空港降りた瞬間に「あ、これはヤバイかも」と思うほど寒かった。でも聞いていたとおり室内とかは暖かくて、とても過ごしやすい。 Simuraiに会ったよ そう、あの世界のUI/UX Designer、@simurai氏にお会いしてきた。BonBon Buttonあたりが有名だろうか。氏が札幌にいるということは知ってたので、誘ってみようということで@hilokiさんが誘ったら来てくれた。 @hiloki Is it http://t.co/Ueod5YFkwX? I won’t understand much since my Japanese is not that good. But sure, I’ll come anyways. ;-) — simurai (@simurai) 2013, 11月 18 セッション後の懇親会にも来てくれて、話もしてきた（英語喋れないけど、片言でなんとか）。すごい気さくでいい人だった。 @1000ch @hiloki @pocotan001 Thanks for coming. That was great. Enjoy Otaru. — simurai (@simurai) 2013, 12月 8 フォローアップ さて、本題。セッションの後半でのデモで（デモになってなかったけど）HTMLInspector、CSSLint、JSHintのエラーサンプルを解説したが、コードと紐付けて説明が出来ていなかったので、HTMLInspector、CSSLint、JSHintを実際に試すあたりを1000ch/brushup-sampleに詳しく書いた。 SaCSSはとても素敵なコミュニティ 滞在期間は2.5日ほどでしたが、かなり濃かった。参加者の皆さん、とても勉強熱心で温かい人達ばかりで、とても楽しかった。また機会があれば是非行きたい。札幌の皆さんありがとうございました！ こちら石山さんよりの頂きものの絵。私は左下。平木さんは左上。何かがおかしい気もするけどよく似てる！ こちら@nakajmgさんより。いい写真！ 参加者の皆様のブログ（随時更新） SaCSS Special4 Frontrend in Sapporoへ行ってきました。 by @marimelody11さん SaCSS Special4 Frontrend in Sapporoに参加してきた by @nakajmgさん SaCSS Special4 Frontrend in Sapporo -最新フロントエンド技術アップデート特集- に参加しました！ by コモモさん SaCSS Special4 Frontrend in Sapporo に参加しました by mamilineさん SaCSS Special4 Frontrend in Sapporo を開催しました by @h2hamさんhttps://1000ch.net/posts/2013/try-raspberry-pi/Mon, 02 Dec 2013 00:00:00 +0000https://1000ch.net/posts/2013/try-raspberry-pi/この記事はFrontrend Advent Calendar 2013 2日目の記事です。 この前フロントエンドな同僚の方々にRaspberry Piをプレゼントしていただいたので、アレコレしてみたログを晒してみる。Frontrendのアドベントカレンダーに書いて良いのか些か迷ったものの、フロントエンドディベロッパーたるものLinuxやらJenkinsやらも触れるようにならないとね！ そのまま飾っておくのは勿体無いので周辺機器買い揃えて動くようにしてみた。そもそもラズベリーパイとは、 Raspberry Pi（ラズベリーパイ）は、ラズベリーパイ財団によって英国で開発されたARMプロセッサを搭載したシングルボードコンピュータ。 via Wikipedia となっている。 手のひらサイズで非常に小さいながらも、CPU、GPU、メモリ、USB2.0 x 2、HDMI、イーサネット等を備えている。SDカードが挿せるようになっており、OSのイメージをSDカードに焼いて、 USBケーブルから電源を供給し、起動するようなイメージ。 Raspberry Pi Raspberry Pi - Wikipedia 用意したもの 電源を供給しなければ始まらないのでMicro-USB(A-MicroB)という規格(?)のケーブルを購入。あと、OSイメージを焼くSDカードがないと話にならないのでそれも購入。 USB(Aタイプ:オス)のインターフェイスを持つパソコンに、USB(MicroBタイプ:オス)のインターフェイスを持つスマートフォン(Xperia(TM)やDesire)などの機器を接続し、充電やデータ転送ができるMicro-USBケーブルです。 ブランド: SanDisk、モデル名: Extreme SD、フラッシュメモリタイプ: SDHCカード、メモリストレージ容量: 32 GB、色: ブラック|ゴールド USBは2口しかないけど、ハブ等駆使すればラズパイだけでそれなりに楽しめそうな。 OSイメージをSDカードに焼く Linuxなら何でも動くっぽいけど、基本の Raspbian をDownloads | Raspberry Piからダウンロードしてみる。ダウンロードしてきたzipを解凍すると、.img拡張子のイメージファイルがある。そのイメージファイルをSDカードに焼けばRaspbianの起動ディスクの完成。ということで、MacにSDカードを挿し込む。 挿す前 $ df -h Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/disk1 233Gi 106Gi 126Gi 46% 27952569 33026246 46% / 挿した後 $ df -h Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/disk1 233Gi 106Gi 126Gi 46% 27973543 33005272 46% / /dev/disk2s1 15Gi 2.https://1000ch.net/posts/2013/pinput-for-pinboard/Wed, 13 Nov 2013 00:00:00 +0000https://1000ch.net/posts/2013/pinput-for-pinboard/Pinboard - 雑音の少ないブックマークサイト Pinput - Chromeストア 1000ch/Pinput -リポジトリ なんか、周りのPinboardユーザーに使ってもらったら思った以上に好評だった。@t32k氏と『既存だといいのがないですね』という話をしていたら、いつの間にかプロトタイプが出来てた。 最初は他のExtensionみたいにiframeでやっていたんだけど、やっぱiframeだと重いうえに、iframe内のイベントを拾えないのでポップアップウィンドウを閉じれない。使い心地で1番ネックだったのはここなので、PinboardのAPIを使って1から画面を作った。ら、結果的にかなり軽快に動作した。 Simple is BEST! Bookmarkするだけの、単純なものです。削除くらいはあってもいいかなと思ったりもするが、様子で。 iframeをなくしたのでPinboardに対する認証が必要になる。HTTP AuthとAPI tokenがありますが、このExtensionではAPI tokenを入力してもらうことで実現している。アイコンを右クリックか、拡張機能ページからオプションページを開くことが出来るので、そこから設定してください。PinboardのAPIトークンは、特別な設定もなく、Setting > Passwordから入手可能。 タイプしてる最中のサジェスト iframe実装をやめたことによる唯一の弊害がこれ。公式のPinboard - Save a Bookmarkだと tags の場所には文字列のサジェストが出る。どうしようと思った矢先に頭をよぎったのがtypeahead.js。これがまーよく出来てる。 ちょうどjQueryも使ってることだし、やってみたらかなり簡単に使えた。サジェストするキーワードは、そのユーザーが使っているタグをローカルにキャッシュしたけど、リモートにクエリ投げて動的に取得することも出来るっぽい。https://1000ch.net/posts/2013/frontrend-in-sapporo/Mon, 11 Nov 2013 00:00:00 +0000https://1000ch.net/posts/2013/frontrend-in-sapporo/2013/12/7(土)に札幌でお話させていただきます！ Frontrend in Sapporo 開催します! SaCSS Special4 Frontrend in Sapporo - イベントページ 私は Brush up your Coding 2013 Winter というタイトルで、HTML/CSS/JavaScriptそれぞれの最適化について発表させていただきます。メンテンナンス性、そしてパフォーマンスにフォーカスする内容になってます。 他の3セッションにつきましては、弊社のディベロッパーがCSS3、jQuery、黒い画面についてそれぞれセッションします。 早割は今日まで！ 今日までの申し込みだと、通常2000円のところを、早割の1500円で申し込みいただけます。 SaCSS Special4 Frontrend in Sapporo - 申し込みページ 私は北海道初上陸ということもあり、とても楽しみにしております。少しでも良い情報をお届け出来るよう頑張りますので、札幌近郊の皆様宜しくお願い致します(´・ω・`)https://1000ch.net/posts/2013/emoji-workflow/Sun, 27 Oct 2013 00:00:00 +0000https://1000ch.net/posts/2013/emoji-workflow/GitHubとかTrelloとかで使える絵文字 GitHubで使える絵文字はどうやらこんなにあるらしい。とても覚えきれん。 EMOJI CHEAT SHEET 更にGitHubだけじゃなくて、TrelloやQiita、Kippt等のいろんなサービスでこの絵文字が使えるそう。知らなかった。 いちいちWebサイトで絵文字調べるの面倒臭い GitHubは:を入れると候補が表示されるからまだいいけど、候補出してくれないサービスがほとんどなのでAlfredから入力できるようにAlfredのWorkflowを作った。完全に@ruedap氏にインスパイアされてる。 ダウンロード 1000ch/emoji-workflow 使い方はAlfredを開いて、キーワードはemoji。 スペースに続けて、キーワードを打ち込むと、絞り込みが出来る。 紹介してもらった Just added another useful Alfred workflow for quickly Emoji lookup ~ https://t.co/H3b6584mAc pic.twitter.com/nL02B6Mhgq — Zeno Rocha (@zenorocha) November 6, 2013 所感 AlfredのPowerpackユーザー且つ、前述の絵文字が使えるサービスのユーザー ということで、ターゲットが狭そうだけど、この両方に属する人は割といると信じてる。AlfredのWorkflowにしたところで、一覧性がそこまであるわけじゃないけど、いちいちチートシートから探すよりは、キーワード入れてヒットする絵文字を使うほうがまだ楽かなと。https://1000ch.net/posts/2013/html5beginners/Fri, 25 Oct 2013 00:00:00 +0000https://1000ch.net/posts/2013/html5beginners/2013/10/23(金)に行われたHTMLビギナーズ第3回に参加して、喋ってきた。 真ん中のスクリーンが映らないという機材トラブルに加えて、吉川さんとひろみつさんのとてもわかりやすいCSSの話の後というプレッシャーの中、 「あれ、2人がCSSで俺だけちょっと違う話だけど大丈夫かコレ」って思いながら 話をさせていただいた。 スライドはこちら。 当日使ったようで使っていなかったデモファイルはこちら。 懇親会 参加者の方々と話してたら「黒い画面使ってみようと思いました！」とか「CSSLintの話参考になりました！」とか感想を頂いて非常にありがたかった。少しでも足しになったなら冥利に尽きます。 黒い画面についてはWebデザイナーの為の「本当は怖くない」”黒い画面”入門が丁寧でオススメ。 苦手意識がある方もいると思うけど、僕から言わせればPhotoshopのほうがよっぽど難しい。ちょっと苦しめばある程度できるようになるので覚えておいて損はないかと思う。 npmの話すっ飛ばした これは簡単に解説しておこうと。 npmはnodeのパッケージ管理ツール。nodeをインストールするとnpmも自動でインストールされる。 Node.js 日本ユーザグループ node.js - インストーラはここから入手可能 が、nodeの開発は非常に活発でバージョンアップもどんどん行われる。なので、nodeのバージョン管理ツールを使うことをオススメします。いくつかあるけど、ここではnvmを簡単に紹介。といってもREADMEの通りではありますが。 まず、nvm本体のインストール。 $ curl https://raw.github.com/creationix/nvm/master/install.sh | sh これでホームディレクトリに~/.nvmというフォルダが作成されている。あとはnvmのパスを通すために.bashrcとかが書き換わっている。これでnvmというコマンドが使えるようになる。nodeはnvmを使ってインストールし、インストールしたnodeは~/.nvmの中で管理されるようになる。 あとはnodeを、バージョンを指定してインストール。 # nodeの0.10.21をインストールする $ nvm install 0.10.21 # nodeの0.8.25をインストールする $ nvm install 0.8.25 # nvmでインストールしたnodeの0.10.21を使う $ nvm use 0.10.21 これでOKです。ターミナル立ち上げる度にnvm useとかするのもアレなので.bashrcとか.zshrcとかに書いたほうが良い。alias作ったり、.nvmrcを使った運用はREADMEを参照のこと。 最後に マークシティはダンジョンだ！https://1000ch.net/posts/2013/web-image-optimization/Wed, 18 Sep 2013 00:00:00 +0000https://1000ch.net/posts/2013/web-image-optimization/デリケートと言っても常に最高画質でやるべきなんてことを言うわけではなくて、『こういう場合にはこういう画像』ということをしていくことが必要になってきている。 ファイルサイズとリクエストの天秤 Webのパフォーマンスにおいて、コスパが高いのはネットワーク部分。 リクエスト数の削減 CSSとJSの結合 画像のCSSスプライト化 Keep-Aliveのon ローカルキャッシュ効かせる レスポンスサイズの削減 CSSとJSの圧縮 画像の圧縮・最適化 サーバーから返すリソースのgzip化 これらは比較的簡単に行うことが出来る上に、効果も大きい。しかし、CSSとJSの結合やら圧縮やらを行っても、画像が1ファイル300KBあったり、更にそれが何ファイルもあったりしたらCSSやJSの最適化も効果が小さいものになってしまうわけで、漏れ無く実施することが重要と言える。中でも、画像はテキストファイルに比べて、少し手を加えればファイルサイズが大幅に減らせるので、今回はそちらにフォーカスしてみる。 PNGとJPG PNGは現代のWebにおけるグラフィックの主流フォーマットと言って良い。透過できるし、JPGよりジャギらないし、圧縮率もGIFより高いケースがほとんど。拡張データ等は多いのでGIFよりファイルサイズは大きくなりがちだが）。 圧縮率をどうするか PNG24は非圧縮だとファイルサイズが大変なことになるので、まず、PNGはPNG24ではなくPNG8で保存することを検討する。PNG24は、1677万色という膨大な色（JPGと同じ）を表現できるが、当然その分情報量は大きい。8bitは256色+アルファチャネルなので24bitに比べてかなり小さい情報量になる。 PNGとJPGの圧縮レベルを比較したものを用意したので以下参考。 1000ch/compress-image/compress-png 1000ch/compress-image/compress-jpg PNGについては、PNG24bitからPNG8bitに変えただけで58KB→14KBと、ファイルサイズが四分の一程になっている。表現できる色が少なくなっているので、若干の劣化はもちろん見られるが、許容できる場合も多々あるはずだ。 JPGについてはPhotoshopの圧縮レベルを10~100で用意した。こちらも100→90にするだけでファイルサイズが大幅にダイエットされていることがわかる。画像のそのものの重要度によるけど、表示サイズが小さかったり、jpg10でも劣化が目立たなければ差し支えないケースもあるはず。 ユーザーが本当にその画質を求めているか を考えるべき。iPhone4S以降のためにRetina用の画像を用意すれば、大きさは4倍で、ファイルサイズもそれ相応に肥大化する。しかし、それは本当にユーザーにとって大事な画像なのか。闇雲にRetina対応をすればいいということも念頭に入れなければならない。 ImageAlphaとImageOptim 24bitで保存されたPNGの8bit化はImageAlphaというツールが有名で優秀。またImageOptimという、こちらも様々な最適化機能を備えたツールがあるが、併用すると更に効果的。ちなみに作者は同じ。 ImageAlphaはpngquantという24bitのPNGに8bitコンバートを行ってくれるライブラリのGUIラッパー。ImageOptimも画像の様々な最適化を行ってくれるアプリケーション。画像には撮影日時やた場所やら、表示には関係のない情報が付与されているが、ImageOptimはそういったメタ情報を削除してファイルサイズを削減してくれる。 例によって自動化 こちらもGUIということでファイルを選んでいちいちやってられねーよということで、自動化する。 JamieMason/grunt-imageoptim こちらはImageAlphaとImageOptimとJPEGmini for Macを実行するgruntのモジュール。ただ、内包するライブラリを叩くわけではなく、アプリケーションをCUIから実行するようなイメージなので、ImageAlphaとImageOptimがインストールされていないと実行することはできない。 プログレッシブとベースライン JPEG形式にはプログレッシブとベースラインという2種類の保存形式が存在する。ベースラインで保存されたJPGは、画像の上から段階的に表示されるが、プログレッシブだと最初ぼんやりした画像が現れて、徐々に鮮明に表示されていく。 Progressive Image Rendering Progressive JPEGs FTW! Optimizing web graphics プログレッシブは低解像度の状態を含めるいくつかの段階の画像情報を保持するため、ファイルサイズが若干大きくなる傾向にある。こちらも好みによりける部分があるが、低解像度でも先に表示をすることで体感表示速度の向上が見込める可能性が高い。PNGについては同様にインターレースというオプションがある。 dataURIはどうなのか 結論から言うと自分は推奨しない。バイナリデータに比べてサイズが1.3倍とかそのくらい大きくなる。あと、HTMLやらCSSに含めることになるので可視化されず、わかりにくい。そして管理しにくい。 さらに、dataURI使いまくってHTMLやCSSファイルが膨らむと、もっと根本的なレンダリングブロックに繋がる傾向にある。あとは、CSSのキャッシュは効いても、毎回デコードしなきゃいけないよね、とかとか。 DataURI化する目的としてはリクエストを減らすことがゴールだけど、それと引き換えになるデメリットが大きく映ることが多いうことで非推奨。 ※追記 |-`) 隅だけどDataURIはgzip効くから1.3倍まるまる大きくはならないよーな / Webにおける画像の最適化について考える | http://t.co/aeV3vAZQzF http://t.co/1y49VC9bd4 — あほむ (@ahomu) September 19, 2013 gzipの言及足りていなかった。一応全部画像サイズ検証してリポジトリに追記したが、まるまる大きくならないどころかgzipしたdataURIとPNGデータはほとんどサイズが変わらなかった。デコードの実施コストはあることは変わらない。 所感 長々と書いたが、その手法もその時その場合に応じて適切な方法を選べることが重要。メタ情報の削除は最低限、PNGの減色(8bitコンバート)およびJPGの減色も可能な限り実施したいところ。 その画質が必要なのか。その画像にRetina対応が要るのか。頻繁に更新される画像なのにスプライト化しなければいけないのか。みなさんも再考してみてください。https://1000ch.net/posts/2013/gist-revealjs/Wed, 11 Sep 2013 00:00:00 +0000https://1000ch.net/posts/2013/gist-revealjs/以前Gistを簡易スライドにするGistSlideを作ったという記事を書いた。 Reveal.jsで作られたスライドをたくさん見るようになってきた。gistにReveal.jsを適用出来ても便利なんじゃないかと思い、ChromeのExtensionを作った。 インストールしたら、スライドにしたいgistを表示中にボタンをクリックするだけでスライドになる。 Reveal.jsのリソースを動的にページに gistのページにreveal.jsのリソースをロードさせることを念頭に置くと、JavaScriptはまだしも CSSを常に適用させていると当然レイアウトが壊れてしまうので、クリックを契機にページにCSSをロードさせなければならない。 chrome.tabs.insertCSS(tab.id, {file: '/hoge.css'}); CSSはこれでOKだが、CSSの中で定義されているフォントへのURLは相対パスで記述されているため、そのままだとhttp://gist.github.com/.../hoge.ttfのようになってしまい、Extension内のリソースをロードしにいくことができない。 そこでchrome.extension.getURL()でExtension内の絶対パスを使って、CSSを適用させた。 var fontDefinition = '@font-face {' + 'font-family: "League Gothic";' + 'src: url("' + chrome.extension.getURL("/font/hoge.ttf") + '");' + 'font-weight: normal;' + 'font-style: normal;' + '}'; chrome.tabs.insertCSS(tab.id, {code: fontDefinition}); が、適用されない。chrome-extension://スキーマでもローカルリソースとは認識されないためだった。ロードするフォントを、manifest.jsonのweb_accessible_resourcesに追加。 { "web_accessible_resources": [ "/font/hoge.ttf" ] } これでOKだった。https://1000ch.net/posts/2013/middleman-travis-ci/Fri, 30 Aug 2013 00:00:00 +0000https://1000ch.net/posts/2013/middleman-travis-ci/gh-pagesブランチの更新自動化がゴール。masterブランチにpushするだけで内容を動的に取得してgh-pagesブランチにpushする。今回もTravisの力を借りる。以下がポイント。 gh-pagesブランチの内容はmiddlemanによる出力 masterブランチにコミットしたあと、Travisからmiddlemanのビルドを実行 生成された内容をgh-pagesブランチへpush middlemanのインストール middlemanはrubyで動く静的サイトジェネジェネレータ。テンプレートをほぼHTMLで記述することが出来て、ブログ等の管理を非常に簡単にすることが可能。jekyll使ったことのある人なら学習コストはさらに低め。詳しくはこの辺りが参考になる。 まずはmiddlemanのインストールから。 $ gem install middleman プロジェクト名を指定し、middleman init。 $ middleman init middleman-playground カレントディレクトリにmiddleman-playgroundというディレクトリが作成され、その配下に色々とファイルが生成されている。 ├─ source │ ├- images │ │ └... │ ├- javascripts │ │ └... │ ├- layouts │ │ └... │ ├- stylesheets │ │ └... │ └- index.html.erb ├─ .gitignore ├─ config.rb ├─ Gemfile └─ Gemfile.lock middleman buildを実行するとsourceフォルダ下を出力のリソースとし、buildフォルダに静的ファイルが生成される。このbuild配下をデプロイすることになる。 config.rb ルートディレクトリに、config.rbという設定ファイルがあるので、設定を自分好みに変えてみる。 set :css_dir, 'stylesheets' set :js_dir, 'javascripts' set :images_dir, 'images' お分かりの通り、何をCSSディレクトリとして扱うかの設定。ただし、source配下のディレクトリはそのままbuildに出力されるだけで、システム内部で扱う変数に過ぎない。ということで、source配下のディレクトリ名とconfig.rbをそれぞれ以下のように編集。 set :css_dir, 'css' set :js_dir, 'js' set :images_dir, 'img' コメントアウトすればjsやcssの圧縮もしてくれそうな行もチラホラ。https://1000ch.net/posts/2013/github-travis-ci/Mon, 19 Aug 2013 00:00:00 +0000https://1000ch.net/posts/2013/github-travis-ci/今更感が否めないけど、簡単にまとめた。Travis CIとはなんぞやという方はこちら。継続的インテグレーションとはなんぞやという方はこちら。 例えばテストの自動化をして、リファクタリングのしやすい環境を作って、コードの品質向上を継続的に行っていくサイクル。というイメージ。今回はGitHubとTravis CIで自動化を測るけど、Jenkinsでビルド環境を整えて、継続的にデプロイをしていくのもひとつのCIである。 テスト周りの環境とか オレオレライブラリにCI環境整えた。mochaでBDDのテストケースを書いて、イベントのバインド周りのテストはsinon#spy()を。testem + PhantomJSでそのテストをで実行させるといった流れ。 PhantomJS testem mocha sinon mochaのサンプルは公式ドキュメントがわかりやすい。イベント周りにSinonを。mocha単体だと少しテストしにくいからだけど、その理由については@hokacchaさんのスライドが非常にわかりやすいのでこちらを見て欲しい。 サンプルリポジトリと詳しい手順 1000ch/travis-ci-scaffold 上記を踏まえて最低限のScaffoldを作成した。Travis CIではC++やらJavaやらRubyやらGoやらと、色々な言語に対応しているが、今回はnode.jsを使ったJavaScriptのテストについて。もともとはRubyのためのサービスとして始まったそう。 Getting started .travis.yml Travis側に自動で認識される設定ファイル。このファイルにTravis CI側から実行される処理を定義します。今回はnode.js経由で行うJavaScriptのテストを定義する。その他のケースでどうするかは公式ドキュメントを見て欲しい。 Building a Node.js project こちらは.travis.ymlのサンプル。 language: node_js node_js: - "0.10" before_script: - npm install bower - ./node_modules/bower/bin/bower install script: - "npm test" 特に指定なくても、npm testがデフォルトで実行される。Gruntとかにテストタスクを書いてある場合はそれをscript:の箇所に記述すれば良い。 bower.json before_scriptはお分かりの通りscriptの前に実行されるコマンドだが、ここではテストライブラリのインストールをbower経由で行うべく、事前にbower自体のインストールと、bower.jsonに定義したテストライブラリをダウンロードしている。npm経由だとnodeとしてパックされたものが落ちてきてしまうので。 また、sinonについてはbowerでもnode用でダウンロードされてしまうようなので、直接指定している。（サンプルリポジトリのbower.json参照） package.json 順番が前後するが、.travis.ymlで実行されるscriptの前にnpm installが実行される。ここではdevDependenciesにtestemを指定し、scriptsのtestにローカルインストールされるtestemを指定した。 testem周り airportyh/testem require.js 環境で mocha + expect + testem を使った JavaScript テスト npm installされて、package.jsonに定義されているnpm testされて、./node_modules/testem/testem.js -l PhantomJS ciが実行されるところまで出来た。testemの設定はtestem.jsonに指定する。https://1000ch.net/posts/2013/brush-up-your-coding/Thu, 01 Aug 2013 00:00:00 +0000https://1000ch.net/posts/2013/brush-up-your-coding/「なんとなく書きたくないけど、どう意識してコーディングしていけばいいのかわからない…。それを解消するためのツールがあるので、紹介する。 HTMLInspector philipwalton/html-inspector Introducing HTML Inspector こちらはHTMLを解析して悪いところを指摘してくれるツール。たぶんガイドラインとかそれぞれあると思いますが、基本的にはコレに沿ってもいいかと。スクリプトを差し込んで実行すると、指摘事項がconsoleに出力される。githubのリポジトリからダウンロードするか、bowerで落としてくるか。 $ bower install html-inspector 次に、解析したいページに以下のコードを埋め込む。 <script src="path/to/html-inspector.js"></script> <script> HTMLInspector.inspect() </script> HTMLInspector.inspect()には引数を与えられる。設定を渡すことでどういう解析を実行するかを指定できる。 Configuring HTML Inspector デフォルトだと以下のようになっている。解析ルールの追加などは都度更新されていくと思うので、公式ドキュメントを参照して欲しい。 { useRules: null, //(Array) 解析のルールの指定 domRoot: "html", //(selector | element) 解析を開始するルート exclude: "svg", //(selector | element | Array) 解析の対象としない要素を指定 excludeSubTree: ["svg", "iframe"], //(selector | element | Array) 解析の対象としないサブツリー要素を指定 onComplete: function(errors) {//(Function) 解析完了時のコールバック errors.forEach(function(error) { console.warn(error.message, error.context) }) } } HTMLInspectorをGruntで実行出来たらいいのかなとか、むしろなぜそうなってないのか一瞬考えたけど、JavaScript側でテンプレート持ってたら無理（PhantomJSはさむとか？）かとか、サーバーサイドで動的にHTMLを返していると面倒くさいな、むしろそれでこういうスクリプト埋め込んでもらう形式なんだろうな、と。 それでも開発時にしか必要のない2行なので、ChromeのExtensionにしてみた。 H:inspector これで一応、解析したいページを好きなタイミングで解析できるようになったと思う。inspect()メソッドに渡す引数はDevToolsのパネルで編集・指定できるようにした。ChromeExtensionなら導入はそれなりに楽かと。 CSSLint こちらはNicole SullivanとNicholas C. Zakasが作った、CSSのlintツール。https://1000ch.net/posts/2013/gist-slide/Fri, 05 Jul 2013 00:00:00 +0000https://1000ch.net/posts/2013/gist-slide/gistslideに影響されて、もうちょっとキレイに作れないかなと思い作成した。デザインは@hiloki氏に作ってもらった。 GistSlide 1000ch/gistslide 使い方 たぶん意識してないgistでもある程度見れるが、一応スライドで発表した前提のほうがいい。 GistSlideにいく リンクボタンをブックマークバーにドラッグ&ドロップする Gistを見る 先程ブックマークに登録したリンクをクリックする 左右キーでスライド送りhttps://1000ch.net/posts/2013/smacss-ja/Wed, 03 Jul 2013 00:00:00 +0000https://1000ch.net/posts/2013/smacss-ja/@cssradar氏翻訳によるSMACSSの日本語書籍が発売された。 Scalable and Modular Architecture for CSS(日本語訳サイト) Scalable and Modular Architecture for CSS 書籍もしくは印刷本で購入することが可能。 そもそもSMACSSとは Scalable and Modular Architecture for CSS の略で、Jonathan Snook氏が提唱するCSSのガイドライン。 SMACSSはデザインプロセスを分析するための手法であり、厳格なフレームワークを柔軟な思考過程とする手法だ。 そしてCSSを使ったウェブサイトの開発に対する一貫したアプローチをドキュメント化する試みでもある。 CSSという非力な言語の開発をしていく上で、混乱などをなるべく避け、再利用しやすく、メンテナブルなスタイルを書いていくための基本的な設計概念の話。110ページとボリュームも大きすぎず、読みやすい内容になっている。 こういった新しい設計概念などが日本語訳されるケースはそこまで多くないと思うので、 「SMACSS読みたいけど英語は辛い…。」 という方は購入を検討してみてはいかがでしょう。https://1000ch.net/posts/2013/one-year-has-passed/Mon, 01 Jul 2013 00:00:00 +0000https://1000ch.net/posts/2013/one-year-has-passed/少しですが、たまには感想とか。 1年前のこと 転職を決意したのは2012年の5月くらいだと思う。サイトに登録して、活動しだして、内定をもらったのが5月末か6月頭くらいだった気がする。最初に選考が進んで最初に内定を貰った。転職活動をし始めてからはとても早かった。 HTML/CSSは学生の頃から趣味でやってて、前職のラスト6ヶ月くらいはWebシステム作ってた兼ね合いでjQueryを触りだした。その辺の兼ね合いもあってちょうどJavaScriptに興味が傾きだしていた関係で、ディベロッパーとして面接を受けて、ディベロッパーとして採用してもらった。 面接の時に@cssradar氏と会った。今ディベロッパーとして従事出来ている(?)のは、この時にフロント技術の奥深さを垣間見たのが、とても大きく影響している。1年前に比べれば多少なりとも覚えてきたことはあるが、当時はWebの知識はほとんどなかったし、周りは優秀な人達ばかりで、それはそれは不安だった。ほんとに。 今だから言いうが、正直、@ahomu氏に会って年齢を聞いた時は衝撃を受けた。@ahomu氏は私の1歳上だけど、自分が1年後あのレベルに到達してるイメージはしにくかった。とはいえ萎えはなくて、むしろ楽しんで傾倒してこれた方かもしれない。その辺は性格かも。 技術とか ちょうどHTML5/CSS3が騒がれだしたころで、モバイルデバイス向けのHTML/CSSを組んだことがなかった僕はついていけるか心配だった。が、HTML5/CSS3を学習しつつそれ以前のマークアップ技術がそれなりにあったようでなんとかやってこれた。JavaScriptも割りとみっちり書くチャンスを貰ったのでなるべく早く慣れるようにやってきた。「JavaScriptはボタンのクリックイベントを定義するやつ」なんていうイメージは一気に吹き飛んだ。 あとは、英語リソースをよく読むようにした。基本的に英語リソースしか読まなくなった。これも@cssradar氏の教えで、日本のWebは遅れている、と。その意味も、今ならわかる。海外の記事を見れば見るほどインターネットの世界の公用語は英語だなぁと思わされる。 Webを牽引しているのはGoogleであり、Mozillaであり、W3Cである。発信される情報が英語なのは至極当然のこと。英語はそこそこ得意だったので、障壁にはならなかった。 サイバーエージェントについて 作る人を大事にする会社だと思う。優秀な技術者も多いし、且つ熱い。そういう人がミックスアップしてお互いを更に高め合っている、そんな環境だと思う。付け足しじゃないけど、これは技術者に限った話ではない。会社が自分に求めることと、自分の性格とかはフィットしているのかなとは思ってる。 デスクは大きいし、MacBook ProとThunderbolt Displayが支給される。ドリンクは無料で飲めるし、リラクゼーションルームもある。どうしても前職との比較になってしまうが、スーツでプログラミングしてた頃とは比較にならないくらい良い環境。 感想とか サイバーエージェントにジョインさせてもらったことも、エンジニアからディベロッパーに転身したことも、とても良かったと思っている。1msも後悔したことない。 貰ってきた（得てきた）ものが大きくて、自分がどれだけ還元出来ているのかわからない。なんとかして「1000chを採用して良かった」と思わせたいし、そう努力していきたい。 『世の中絶対受動的じゃない。能動的に動いた結果。』 @t32k ほんと、その通りだ。https://1000ch.net/posts/2013/website-performance/Sun, 16 Jun 2013 00:00:00 +0000https://1000ch.net/posts/2013/website-performance/一口にWebサイトのパフォーマンスと言っても色々あって、 通信部分のパフォーマンス（Networking） スクリプト部分などの実行パフォーマンス（Computing） 表示に関するパフォーマンス（Rendering） などなど。今回はWebサイトのどこがボトルネックになっているかなどの調べ方とか。 GoogleChromeのPageSpeedを使う Dev Tools(command + option + iで開くやつ)の進化が凄まじすぎて追いかけるのが大変な今日このごろ、その中のアドオンとして働くPageSpeed Insightsというものがある。 PageSpeed Insights (by Google) - Chromeウェブストア Using PageSpeed Insights for Google Chrome これをインストールすると、Dev ToolsのパネルにPageSpeedが追加されるので、あとは検証したいページを開いてAnalyzeするだけ。すると、そのページの検証が行われて、何が改善可能かを教えてくれる。Gzip効かせろだとか、minifyしろだとか、<script>は後ろでロードせいだとか、リダイレクト減らせだとか、cssスプライトにしろよだとか…、手軽に色んなことを教えてくれる。まずはこのツールでScoreを伸ばすことが先決です。 DevToolsについて 前述の、NetworkingやComputingなどの細かい解析は、デフォルトで搭載されているDevToolsの各機能で行う。NetworkパネルでAjaxのタイミングとか見たり、画像のダウンロードにかかってる時間を見たり。タイムライン見てるだけでも、「ここ時間かかってるなー」っていうのが見えるかと。 あと、Timelineでペインティングコスト見たり、ProfilesでJavaScriptの実行コスト見たり。これらに関しては各パネルでレコーディングをする必要がある。下部の虫眼鏡の右にあるアイコンでレコーディングの開始と終了をする。それぞれ、レコーディングされている間に行われた描画や、スクリプトの実行をプロファイルとして閲覧することができる。 CompositeLayerの生成に関してはあんまりこのパネルで見てなくて、SettingsのGeneralのRenderの Show paint rectangles（赤がpaint rectangle） Show composited layer borders（オレンジがcomposite layer） にチェックをすることで得られる視覚的なほうで確認して、リフロー多いなおい…ってこととかをTimelineパネルで見たりしている。果たしてこれが常套手段なのかどうかは、不明。 Sitespeed.ioを使って解析する これはAriyaのRTで今日知った。 Just set up http://t.co/1phATVNerY (by @soulislove) locally on my windows machine. Up and running in 5 minutes. Great tool. — Thomas Puppe (@thomaspuppe) June 14, 2013 こちらはコマンドラインから使うツールで、サイトのURLを指定して実行し、解析結果はhtmlで出力される。観点としては前述のPageSpeedと大差ないが、より細かく、関連ページの解析までしてくれるツール。PhantomJS1.9とJava1.6~が必要。https://1000ch.net/posts/2013/chrome-extensions/Mon, 10 Jun 2013 00:00:00 +0000https://1000ch.net/posts/2013/chrome-extensions/以前一度作ったけど、新しく欲しい機能が出来たのでまた作った。ついでにChrome ウェブストアで公開した。 OneClickClear ワンクリックで確認ダイアログが表示されて、OKを押すとブラウザの閲覧履歴がクリアされる。履歴消すためには設定タブ開いて、履歴開いて…とするのが煩わしくて作った。 CookieManager 業務中にクッキーを消す場面が何回かあって。こちらもいちいち設定を開いて…と、いう同じような動機。こちらは消すクッキーを選べるのと、URLで絞込が出来る。https://1000ch.net/posts/2013/google-easter-egg/Tue, 14 May 2013 00:00:00 +0000https://1000ch.net/posts/2013/google-easter-egg/昔のメモ書きを掘り起こしたので再度まとめる。これらのイースターエッグは検索のみだが、Google Mapsなどにもあるっぽい。 tilt 画面が傾く。 askew こちらも画面が傾く。 do a barrel roll 画面が一回転する。 let it snow 画面に雪が降り、窓のように白くなる。冬限定? hanukkah answer to life the universe and everything 生命、宇宙、そして万物についての究極の疑問の答え。 recursion 「もしかして」の内容が再帰する。 zerg rush oの字で画面が侵食される。 comway’s game of life 細胞が現れ、分裂していく。 binary 検索結果の件数が2進数で表示される。 hexadecimal 検索結果の件数が16進数で表示される。 google gravity 重力に負けてコンテンツが下部に落下する。現在の置き場はこちら。 google sphere 球状に回転する。現在の置き場はこちら。 google pacman パックマンが遊べる。現在の置き場はこちら。 google les paul ギブソンのレス・ポールの生みの親、レス・ポールの誕生日にちなんだロゴが表示され 演奏することが出来る。現在の置き場はこちら。https://1000ch.net/posts/2013/event-bubbling/Tue, 07 May 2013 00:00:00 +0000https://1000ch.net/posts/2013/event-bubbling/最近はプロジェクトの異動やらなんやらで非常にドタバタしてまして、中々調べものとかに没頭出来ていない。そんな異動先のプロジェクトでイベントのバブリングについて再考したので覚書。 イベントのバブリング? イベントは発火元のノードから、親のノードにどんどん伝播していく。親のノードで発火元のイベントを拾う事が出来る。 例 5: イベント伝播 (propagation) バインドのターゲットと発火順 以下のような記述を見つけた。 window.addEventListener('DOMContentLoaded', function() { console.log('document is ready.'); }); windowにバインドされてる。バブリングすることを考えれば納得出来るが、意図はわからないまま…。 window.addEventListener('load', function(e) { console.log('window:load'); }); window.addEventListener('DOMContentLoaded', function(e) { console.log('window:DOMContentLoaded'); }); document.addEventListener('DOMContentLoaded', function(e) { console.log('document:DOMContentLoaded'); }); 実行すると、 document:DOMContentLoaded window:DOMContentLoaded window:load という順で出力される。 イベントの正体 次のイベントオブジェクトの中身を見てみる。 var windowDomReady = null; var documentDomReady = null; window.addEventListener('load', function(e) { console.log(windowDomReady === documentDomReady); }); window.addEventListener('DOMContentLoaded', function(e) { windowDomReady = e; }); document.addEventListener('DOMContentLoaded', function(e) { documentDomReady = e; }); 実行してみると、 true と。イベントのtypeもDOMContentLoadedだし、targetもdocumentだった。ということは、https://1000ch.net/posts/2013/jquery-2-0/Fri, 19 Apr 2013 00:00:00 +0000https://1000ch.net/posts/2013/jquery-2-0/jQuery 2.0 Released IE6~8のサポートを切って、再設計されたjQuery 2.0がリリースされた。開発には10ヶ月程かかったそう。 ファイルサイズ Uncompressedで1.9と比較してみると… jQuery 1.9のデフォルトパッケージ→9597行 jQuery 2.0のデフォルトパッケージ→8755行 ファイルサイズはあまり軽量化されていない。 IE対応を削ったところでそこまで軽くならないっていう。12%程軽量化されていると共に、パフォーマンスが良くなったらしい。 対応ブラウザ Webkit(もとい、Blink)とGeckoは良いとして、IEは9から動く様子。あとはこのあたり。 Google Chrome add-ons Mozilla XUL apps and Firefox extensions Firefox OS apps Chrome OS apps Windows 8 Store (“Modern/Metro UI”) apps BlackBerry 10 WebWorks apps PhoneGap/Cordova apps Apple UIWebView class Microsoft WebBrowser control node.js (combined with jsdom or similar) APIとか jQuery1.9と互換性がある。1.9以前との互換性についてはMigratePluginを導入することで対応出来るが、個人的には頼らず、2.0のAPIでリファクタリングすることをオススメしたい。それは削除されたAPIなのだから。 カスタムビルド もはや当たり前(?)になってきているカスタムビルド。jQueryもgruntを使ったカスタムビルドを提供しているので、要らない機能は省いた構成に。 ajax - ajax周りの関数諸々。 ajax/xhr - XMLHttpRequestのシンプルな実装。 ajax/script - scriptの非同期ダウンロードメソッドの提供。 ajax/jsonp - クロスドメイン用。当然、要らないなら入れない。 css - .https://1000ch.net/posts/2013/history-clear-chrome-extension/Sat, 09 Mar 2013 00:00:00 +0000https://1000ch.net/posts/2013/history-clear-chrome-extension/@t32k氏に影響されてChromeの拡張機能を作った。アイコンのクリックで全履歴を消すという非常にシンプルな機能。ソースも非常に小さい構成になっている。機能・実装がブラッシュアップされてきたらウェブストアへの登録もしてみようかな、と。 以下の手順でも使える。 GitHubからソースをクローン アドレスバーにchrome://settings/と入力し左の「拡張機能」を選択 「ディベロッパーモード」にチェックを入れる 「パッケージ化されていない拡張機能を読み込む」でクローンしたフォルダを選択 Extensionの構成 ChromeのExtensionは大まかに言って、html / css / js / manifest.jsonの4つから構成されている。 つまり、拡張機能といってもc++を書く訳ではない。HTML・CSS・JavaScriptで構成されており、実装も「JavaScriptでChromeのAPIにアクセスしたり」という単純なものなので、想定しているよりもずっと敷居が低かった 肝となるのはmanifestファイル Extensionにも実行されるタイミングが色々ある。特定のURLを開いたとき とか、 拡張機能のアイコン をクリックした時など。そのコントロールをしているのがmanifest.json。どのファイルがどこでどのタイミングでロードされるなどもこのmanifest.json次第なので、これがわからないとJSのデバッグまで辿り着けない。逆に、これがわかればconsole.logを駆使して何でもできる。 manifest.jsonのサンプル 後述の公式ドキュメントに詳しく載っているが、以下は今回作った拡張機能の例。 { "name": "OneClickClear", // 拡張機能の名前（必須） "version": "0.0.1", // 拡張機能のバージョン（必須） "manifest_version": 2, // マニフェストファイルのバージョン（必須） "description": "", // 拡張機能の説明（推奨） "permissions": ["history"], // historyオブジェクトにアクセスするための許可 "background": { "scripts": ["js/main.js"] // バックグラウンドで実行するjsファイル }, "browser_action": { // Chromeのツールバーに配置されるアイコン "default_icon": "img/trash.ico", // 配置されるアイコン "default_title": "OneClickClear" // タイトル } } 実行されるmain.jsの中でツールバーのアイコンがクリックされる瞬間をハンドリングし、履歴オブジェクトにアクセスして削除するという単純な造り。でもその指定を、"background":...に指定しなければならなかったり、履歴オブジェクトを操作するので、"permissions": ["history"]と記述しなければならなかったり。やはりmanifest.jsonが肝な感じ。 デバッグの取っ掛かり 使う手順の話で出たが、拡張機能の実装が配置されたmanifest.jsonがあるディレクトリを、ディベロッパーモードにしてロードするだけ。実に簡単。console.logの出力もディベロッパーツールで確認することができる。 ただし、今回のような出力先のビューレイヤーがないbackgroundでの実行は、chrome://extensions/の、ロードした拡張機能のビューを調査で生成されているbackground.htmlで確認が可能。事前に作っておいても大丈夫。 参考URL Google Chrome拡張機能とはなにか？ - ドットインストール Formats: Manifest Files - chrome extensions chrome.https://1000ch.net/posts/2013/gruntjs-0-5-roadmap/Thu, 07 Mar 2013 00:00:00 +0000https://1000ch.net/posts/2013/gruntjs-0-5-roadmap/先日Grunt0.4がstableになったが、早速0.5に向けてのロードマップが発表されている。ロードマップもちょくちょく変わるとは思うけど、軽めになぞってみる。 タスクは全てイベントとして実行される（ようになる） 複数タスク間のデータを繋ぎ合わせて使うことが出来るらしい。CoffeeScriptのコンパイル結果をそのままUglifyでMinifyしたり。こんなイメージらしい。 // load a set of tasks to be run in parallel grunt.registerTask("name", ["jshint", "concat"], { parallel:true }); こんな感じで複数タスクを繋げてエイリアスを作成し、並列実行が出来るようになるっぽい。ファイルのIOなくなるからスムーズになりそう。 Glob展開ライブラリの更新 配列形式ので指定されるGlobを解決できるようになる。って書いてある。参照パスの指定の仕方だと思われるが、サンプルがないのでよくわからない。 Gruntfileの設定がnodeのタスクの実行に準拠した形式になる node.jsということで、require('grunt-hoge')のような形式になるっぽい。 loggerがeventを拾って出力するようになる stderr/stdout、もしくはビルドインのロガーを使うそう。 まとめ 0.4がどれだけ続くかもわからないし、ロードマップに書かれている0.5の仕様もこれでfixではないだろうけど、現状はこういう感じらしい。設定ファイルの更新は面倒だけど、Grunt便利だし、仕方ない。心の準備だけしておこう！ そういえば 動かないと騒いでいたgrunt-contrib-stylusの記事だけど、grunt-contrib-stylusの不具合だったらしい。 Gruntによる継続的なビルド環境を求めて 〜 package.jsonと0.4.0のこと upgrade to grunt 0.4.0rc7 generates an error · Issue #26 · gruntjs/grunt-contrib-stylus ow.ly/ieJDy... — mitsuruogさん (@mitsuruog) 2013年3月3日https://1000ch.net/posts/2013/zeptojs-1-0/Tue, 05 Mar 2013 00:00:00 +0000https://1000ch.net/posts/2013/zeptojs-1-0/v1.0rcが11ヶ月間も続いていたが、ようやくRelease Candidateではなくなり正式リリースとなった。 http://zeptojs.com/ https://github.com/madrobby/zepto おさらい おさらいすると、Zepto.jsはjQueryとAPIの互換性があるモダンブラウザ向け軽量ライブラリ。 jQueryはIE対応とか$.AnimationとかDeferredとかあるけど、その辺りを除いて実装してあるようなイメージ。現状、iOSやSafariにはIE対応とか必要ない訳で、これ使うとファイルサイズ落とせますねっていうコンセプトで作られている。 ビルドについて rakeファイルがいつの間にか消えてる！ Zeptoはカスタムビルドが出来るようになっていて、欲しい実装のみを選んで使える。rcの頃はrakeファイルがあった気がしたんだけど、今はmake経由でビルドするようだ。 Zepto modules モジュール一覧を引用して少し解説する。★がついているのはノーマルビルドに含まれるもの。 polyfill★ - iOS3.x向けのString#trimとArray#reduceの実装。要らないと思う。 zepto★ - Coreモジュール。これはないと話にならない。 event★ - on()とかoff()とか、イベント周りの実装。 detect★ - UserAgentの判定の実装。必要に応じて。 fx★ - アニメーションを実現するanimate()の実装。 fx_methods - animate()を使ったshow()やhide()などの実装。fx依存。 ajax★ - 非同期通信(XMLHttpRequest)の実装。 form★ - form要素の値からQueryStringを作ってくれたりsubmitしてくれるあたり。 assets - iOSのimgのmemory対策用モジュール。コアのremove()のオーバーライド。 data - ノードのdata-へのアクセスではなくメモリベースで情報を格納する機構。コアのdata()のオーバーライド。 selector - jQueryの拡張CSSセレクタ(:firstとか:visibleとか)の実装。 touch - タッチデバイスでのswipeやtapなどのイベントの実装。 gesture - タッチデバイスでのpinchイベントの実装。 stack - andSelf()とend()の実装。 polyfillは要らないケースが多いし、detectもfxも必要に応じて入れればいいので、まずは少ない構成で試してみては如何だろう。 更新履歴の気になるあたり 「 Twitter Bootstrapに対応！ 」 「node.jsベースのビルドになったよ。」 「PhantomJSとTravis CIによる自動テストになった。」 「touchモジュールをデフォルトビルドから外した。」 「 バグがいっぱい直った 」.｡ﾟ+.(･∀･)ﾟ+.ﾟｲｲ!! 「Ajaxで{cache: false}をサポート」 「each()のコールバック中でfalseが返されるとループを止めるようにした。」 Ajaxの{cache: false}は同じリクエストで結果がキャッシュされる話だと思うが、対応策としてダミーでDate.https://1000ch.net/posts/2013/gruntjs-0-4/Tue, 22 Jan 2013 00:00:00 +0000https://1000ch.net/posts/2013/gruntjs-0-4/以前の記事が説明足らずだったので補足記事。今npmからgrunt周りのモジュールを素直にインストールすると0.3系stableが落ちてくるので、0.4系と混在すると、うまく動かない。0.4系で整備していく方が今後のために良いと思うのでその説明。rcなので、あまり文句は言えない。 ということだけあらかじめ断っておくとして。 grunt-cliをグローバルインストール gruntコアをローカルインストール モジュールをローカルインストール gruntfile.jsに設定を記述する という流れはそのまま。モジュールをローカルインストールの辺りを詳しく説明。package.jsonも修正するなり、作り直すなり。 grunt-contrib-xxx 公式で配布しているモジュール群は grunt-contrib-xxx/master grunt-contrib-xxx/grunt-3.0-stable というように安定版ブランチと開発ブランチが切られている。開発ブランチは0.4系に向けた開発が行われているので、この開発ブランチを手に入れる。登録されていればnpm経由でもインストールできるが、GitHubのリポジトリからであれば、常に最新のものを入手できる。 grunt-contrib-watchのgitリポジトリをクローンする # 作業ディレクトリに移動 $ cd /Users/[UserName]/workspace/[ProjectName]/ # gruntfile.jsがあるディレクトリ $ ls -la # grunt-contrib-watchを配置するディレクトリに $ cd ./node_modules/ # リポジトリをクローン $ git clone https://github.com/gruntjs/grunt-contrib-watch.git npm経由でインストールされるリソースはnode_modulesに配置されるので、その場所にクローンしてgruntに参照してもらう。私の場合はconcat/mincss/uglify/watchの5つを使用しているが、問題なく動いている。package.jsonも作り直したけど、前述の通りlink出来ないものもアリ。 grunt@0.4でstylusのコンパイルを自動化してみよう stylusのファイルに変更がかかった場合に自動でコンパイルされるタスクを作ってみる。animate.css をフォークしてstylusから生成するという無駄なことをしながら実践したので、サンプルとしてgithubに置いておく。 1000ch / animate.css 必要なモジュールとgruntfile.js grunt@0.4.0rc7 grunt-contrib-watch@0.4.0rc5 grunt-contrib-stylus0.2.0rc5 module.exports = function(grunt) { grunt.initConfig({ stylus: { compile: { files: { "animate.css": "animate.styl" } } }, watch: { files: ["animate.styl"], tasks: ["stylus"] } }); grunt.loadNpmTasks('grunt-contrib-stylus'); grunt.https://1000ch.net/posts/2013/jquery-1-9-rc/Fri, 11 Jan 2013 00:00:00 +0000https://1000ch.net/posts/2013/jquery-1-9-rc/JQUERY 1.9 RC1 AND MIGRATE RC1 RELEASED jQuery1.9のリリース候補版ver1が公開された。beta1の続きということで、懲りずに変更とか追っかけてみる。 Sizzleが対応するCSS3セレクタが増えた 追加されたものと、簡単な解説を。ネイティブじゃないので相変わらずIE6でも使えるそうで。:link・:visited・:hoverの3つに関してはサポートしていない。オーバーヘッドが大きいこともあって、実装予定はないとのこと。 :nth-last-child() - ()の条件式に該当する子要素の最後の要素。引数の形式は:nth-childと同様。 :nth-of-type() - ()の条件式に該当する同一属性要素。引数の形式は:nth-childと同様。 :nth-last-of-type() - ()の条件式に該当する同一属性要素の最後の要素。引数の形式は:nth-childと同様。 :first-of-type - 同一属性要素の最初の要素。:nth-of-type(1)と同義。 :last-of-type - 同一属性要素の最後の要素。:nth-last-of-type(1)と同義。 :only-of-type - 同一属性要素が単独の場合該当。:first-of-type:last-of-typeとか:nth-of-type(1):nth-last-of-type(1)と同義。 :target - アンカーで遷移した先の要素に該当。 :root - ルートを意味する。htmlで言うとhtml。 :lang() - ()の指定と、lang=“ja"が一致する要素。 finish()が追加された .stop(Boolean, Boolean)のように真偽値を渡すのをやめたいそうな。stop()の引数の渡し方で制御をするような複雑なことをしたことがないが、ほとんどの場合は.clearQueue(a)や.finish()で解決できるからだそう。 サンプル Source Mapに対応 minifyされてたら無理ということでSource Mapを用意してくれた。生ソースが得られてもjQueryをデバッグする気にはあまりならないけど。Source Mapについては以下のリソースが参考になる。 Source Map Revision 3 Proposal SourceMapについて調べました。 たくさんあるchangelogで気になるところ ajax.typeがajax.methodにリネームされた。 $("some-selector")の性能が10%~30%向上した。 Sizzleはどこまで進化するんだ。 まとめ ロードマップは、2.0はIE6IE8のサポートを打ち切り、再設計して改良。軽量化と高速化を図るそう。1.9は引き続きIE6IE8をサポートを続ける。バグフィックスは2.0.xと1.9.xのマイナーアップデートにされるってことになるのかな。内部APIを色々と整理したのでたくさんテストして下さいとのこと。https://1000ch.net/posts/2013/how-to-optimize-javascript-by-google/Fri, 04 Jan 2013 00:00:00 +0000https://1000ch.net/posts/2013/how-to-optimize-javascript-by-google/13 JavaScript Performance Tips Google I/O 2012発 JavaScript高速化Tips集の日本語訳 Google I/O 2012で発表されたJavaScriptの高速化のテクニックについて。基本的なテクニックの他、JavaScriptエンジンの挙動に対する最適化もある。「v8におけるのJavaScriptの最適化」 における話。 Be Prepared - Hidden Classes 1.オブジェクトメンバはコンストラクタですべて初期化する 2.オブジェクトメンバを常に同じ順序で初期化する クラスはhidden classという形でキャッシュされる。よって、初期化するメンバがまちまちだったり、違う順序で初期化されるとキャッシュを利用出来ず、新しいキャッシュを作成しなければならない。 Be Prepared - Numbers 3.可能な限り31bit符号付き整数を使う v8がコンパイルするときに、変数に対して分類のためにタグ付けをするらしくて、31-bit signed integerだと参照される順番が速いそう。変数の判断が、まず31-bit signed integerかどうかを見て、次にdoubleかどうか、それでもなかったらobjectである。というロジックのよう。 Be Prepared - Arrays 4.配列のキーに0から始まる連続する値を使う この辺りは理解に苦しんだので、アメリカ人の同僚に聴いてもらって解説もらった。0~をキーとする配列は配列として扱われるけど、以下のようなケースは連想配列（というかオブジェクト）として扱われて、低速になるよという話。 var array1 = new Array(); array[25000] = 123; //0~24999 is empty //[xxxxxxxxxxxxxxxxxxxxxxxxxxx_____]これは配列として扱われる //[xxxxxx__________________________]これはオブジェクトとして扱われる //らしい。「配列が満たされているかどうか」が重要らしい。まばらな配列も駄目。 5.要素数が64000個を超える配列がある場合、予め用意するのではなく必要に応じて都度追加する 初期化時に大きなメモリを確保するなということで、単にメモリの圧迫の問題だろうか。64000個というのは滅多になさそうなのでさておき、個人的には1000個とかでも多いと感じる。仕様や構造の見直しも検討してみるのもアプローチのひとつとしてあってもいいかと。 6.配列の要素を削除しない（数字の配列の場合は特に） ##Be Prepared - Full Compiler 7.初期化されていない要素や削除されている要素をロードしない 展開されているメモリ上にないものを参照するとundefinedを返すはずなので、多少イレギュラーなロジックっていうことかな。内部的に例外が発生する可能性も考えらる。 8.要素数が少なく、固定数の配列の初期化には、配列リテラルを使う var array1 = new Array(); array1.push("static value1"); array1.https://1000ch.net/posts/2012/enderjs/Thu, 27 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/enderjs/Enderはnode.jsで動くJavaScriptのパッケージビルド管理システム。 JavaScriptのライブラリは非常にたくさんあって、その中から複数選んで使いたいケースはたくさん有る。まとめて使うときに欲しいものをダウンロードして、使いたいライブラリが増えたらまたビルドして…というのはとても面倒な作業。Enderはこういった問題を解決してくれる。 Ender.jsの薦め jQueryはとても良く出来たライブラリだけど、闇雲にjQueryを使うのはベストとは言えず、必要な機能を必要な分だけ用意するという作業が求められるようになってきた。jQuery互換のAPIで軽さを求めたZeptoを始め、最近ではBackbone.jsやUnderscore.jsといった様々なライブラリがある。 ライブラリを選定して使う際に、結合と最小化などを行うが、例えば後々ライブラリを追加したりするときに面倒だったりする。Enderはこうしたライブラリ達の依存関係の解決や結合と最小化をやってくれる。手でいちいちやるより楽だし、安全である。 具体的な導入方法 ender-js/Enderを見てもらえるとわかるが、コマンドラインからの操作。 enderのインストール $ npm install -g ender これでインストール完了。試しにenderと入力し、実行出来るかどうかテスト。 buildしてみる Backboneをビルドしてみる。 $ ender build backbone # ender.js successfully built! # ender.min.js successfully built! このパッケージに何のライブラリが含まれているかを確認する。 $ ender info # Active packages: # └─┬ backbone@0.9.2 - ... # └── underscore@1.4.2 - ... ここで注目したいのが、依存しているUnderscoreも一緒に含まれていること。あくまでBackboneと一括管理になるので、削除も出来ない。もちろん、追加しようとしても既にあると言われる。 パッケージにライブラリを追加する場合はadd、削除する場合はremove。試しにZeptoを追加してみる。 $ ender remove underscore # Nothing to uninstall. $ ender add underscore # Specified packages already installed. $ ender add zepto $ ender info # Active packages: # ├── zepto@0.https://1000ch.net/posts/2012/jquery-1-9/Wed, 19 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/jquery-1-9/先日jQuery1.9beta1が公開されたが、ロードマップは変わらないだろうし、変更点をまとめる。 前々から非推奨アナウンスがあったものを削除するなど主に内部APIの整理で、ファイルサイズの削減とパフォーマンスが向上される予定。2.0は古いIE等のサポートを止め、再設計・軽量化なので1.9とAPIは変わらないそう。 最近のjQueryはフルコメントで10000行くらいあったが、2.0でどのくらいになるのか。超軽くなったりしないかな。恐らくないな。 jQuery Blog > jQuery 1.9 Beta 1 Released jQuery Core 1.9 Upgrade Guide ↑のUpgrade Guideを読み流してみる。 .add() 内部処理の仕方を変更。 .addBack(selector)が.addSelf()に 一応エイリアスとして残るみたい。 .after()と.before()と.replaceWith() 親を持たないノードの変更はバグを生む可能性があるので、内包する対象ノードが 親を持たない場合はこれらを使っても何もしない 。 .appendTo()と.insertBefore()と.insertAfter()と.replaceAll() 要素の追加や削除系の関数ですが、1.9以降は.end()をしなくても、要素が追加や削除された状態のjQueryオブジェクトを返す そう。 checkboxのクリック時イベントのハンドラ中の状態 未チェックのチェックボックスをクリックするとクリックイベントが発火されるけど、クリックイベント中でのチェックボックスの状態が、v1.8以前は未チェックだったことに対しv1.9からはチェックされた状態でコールバックされるようになった。 ユーザーアクションと反対の状態で取得出来る っぽい。我ながらわかり難い日本語。 focusイベント ネイティブのfocusイベントは、DOMがフォーカスされてから初めてイベントが発火されるけどv1.9は、DOMがフォーカスされなくてもfocusイベントの実施を最後まで行う。focus()あるいはtrigger("focus")で、内包する要素に対しfocusを発火するが、focusイベントがハンドルされない要素があっても、全ての要素に発火をする、ということになりる。 $(htmlString)と$(selectorString) 引数にhtmlタグが含まれていたらhtmlStringとして扱う。 タグ形式であってもhtmlタグではない場合は認識されず、$.parseHTML()を通すことで初めてDOMノードが生成される。 プラグインは用意されるっぽいが、有効なCSSセレクタでも今までのようには動かないようで、移行の際は注意。なるべく#idと.classNameで走査しろということなんだろうか。 .data()メソッドからイベントは発火されない set/getで監視しないようになった。また、.data("abc.def")はabc.defの値のみ取得し、abcからは取得しないとのこと。 jQueryの独立したノードの順序 うーん、これはいいか。 要素中にscriptがある場合実行するようになった HTML文字列を扱うメソッド（.append()とか.wrap()とか）にscriptがある場合は 1.9以降はscriptを実行する ようになり、再実行されるのを防ぐため、そのscriptのノードは除かれるらしい。ほほう。 scriptは同期的に評価されるため実行に時間がかかり、また、scriptの挙動に対してアクセスするインターフェースは用意しませんとのこと。 「scriptの実行のためにこの挙動を利用するな！」 、新しいscriptをロードするときにはjQuery.getScript()を使ってくれとのこと。 .attr()と.prop() .prop()はプロパティの値の取得と設定のために1.6から用意されて、.attr()は値の設定には使わないようにされてきた。1.9においては特別なケースの.attr()の使用をサポートするそう。例えばチェックボックスの値の設定時の挙動。 古代IEにおける$("input").attr("type", newValue) 1.9においてもIE6/7/8だと例外が発生するものの、許容するブラウザのために残し、使える場合はどうぞ使ってくださいとのこと。個人的にはこんなイレギュラーなことしないけど。 擬似イベントhover mouseenter + mouseleaveと同義なのでサポートしない。 jQueryオブジェクトの.selectorプロパティ 元々非推奨のプロパティだが、v1.9からはメソッドチェーンの場合などにこのプロパティの整合性を保つことをしない。まぁ、これもあまり使わない。 jQuery.attr() 明示されていなかったjQuery.attr(elem, name, value, pass)をサポートしなくなる。よって、今後はpassを引数として使うことが出来ない。 jQuery.ajax()のJSON結果が空文字の場合 jQuery.ajaxが、JSONの結果が空文字の場合を考慮するようになった。v1.9以降、空文字の場合は不正な形式とし、例外をスローする。ただしnullの場合を除く。 jQuery.proxy()のcontext コールバック中のthisがproxy()によって適切に割当たるようになった。コールバックの呼び出し元がnullかundefinedの場合、thisはwindowになるっぽい。https://1000ch.net/posts/2012/backbone-ajax/Tue, 18 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/backbone-ajax/この記事はBackbone.js Advent Calendar 2012 18日目の記事です。 JavaScriptにMVCの波を巻き起こしているBackbone.js、今回はそのAjax周りについて。想像していたより、皆さん突っ込んだこと書いててどうしようと思ったけど、まぁいいや。 Backbone.jsのAjax Backbone.jsのMVCは、ModelとCollectionにサーバーとの非同期通信関数を備えている。依存しているUnderscore.jsは配列操作などのUtility関数を提供しているが、Ajaxそのものの処理は備えていない。そこで出てくるのが、Backbone.jsはサーバーとの非同期通信をどのように行っているのかという疑問。 jQueryなどのライブラリのajax関数を使っている 10日目のエントリーBackbone.js1.0に向けての変更点 - NAVER Engineers’ Blogで紹介されているが、Backbone.jsはロード時にグローバルのjQuery / Zepto / enderのいずれかを格納する。 var $ = root.jQuery || root.Zepto || root.ender; BackboneではBackbone.syncメソッドが通信の起点になっており、あれこれしたあと最後で$.ajax()をコールして非同期通信を行う（もちろん$.ajax()以外も使用されている）。Backbone.syncはBackbone.Model(or Backbone.Collection)で提供されるfetch() / save() / destroy()の中で通信する際に使用される。 これは、各ライブラリの$.ajax()のパラメータインターフェースが共通なのでこのような受け方が可能になっている。fetchなどで渡すパラメータのsuccessとerrorは、$.ajax()のsuccessとerrorに渡される形になるっぽい。 Model.fetch() | Collection.fetch() データの取得系の処理はこのメソッドを通して行う。 Model.save() データの保存または更新の処理はこのメソッドを通して行う。Backbone.Collectionのcreate()はここを内部的に通る。 Model.destroy() データの削除系の処理はこのメソッドを通して行う。 emulateHTTPとemulateJSON リクエストヘッダのapplication/jsonは、古いサーバーだと対応できない。その場合emulateJSONをtrueにすることで、リクエストヘッダのcontentType、application/jsonをapplication/x-www-form-urlencodedに書き換える。 また、古いサーバーだとPUT、DELETE、PATCHリクエストに対応していない場合がある。emulateHTTPをtrueにすることでリクエストヘッダを上書き、POSTリクエストする。その際、emulateJSONがtrueの場合_methodのパラメータに元のリクエストメソッドを保持する。 レガシーサーバー用なので、古いサーバーに対応する必要がない場合は、どちらもtrueにする必要はない。 まとめ 明確なAPIラップ関数の用意と、それ以上にchange / destroy / syncとイベントの発行に関わっている。また、underscore依存といいつつ、事実上jQueryに依存している。https://1000ch.net/posts/2012/jquery-bind-and-delegate/Wed, 12 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/jquery-bind-and-delegate/この記事は、軽めのjQuery Advent Calendar 12日目の記事です。 曖昧な認識のまま進みがちなjQueryのイベントハンドリングについて。軽めということだが、あまり簡潔にまとまっていないかも。 jQueryのbindとdelegate 現在は2つともonによってカバーされているイベントバインドだが、敢えてこの2つのメソッドで説明。どちらも要素に対するイベントの定義に使用するメソッドだが性質が異なる。 bindは要素に対して直接イベントハンドラの登録をし（いわゆるaddEventListenerとかattachEventで）、delegateは親要素に対しイベントハンドラを登録しバブリングで呼び出し元の要素を判定する間接的な方法。 $element.bind(type, callback) イベントハンドラはその要素に対して紐付き、保持される。 <body> <button id="foo">ボタン</button> </body> // 要素押下時のイベントを定義する $("#foo").bind("click", function() { console.log("#fooがクリックされました"); }); $element.delegate(selector, type, callback) 引数には、イベントの種類とセレクタとイベントハンドラを渡す。上の例と同様に#fooの要素押下時のイベントを定義するには、#fooの要素を内包する要素に対してdelegateを定義する。 <body> <button id="foo">ボタン</button> </body> // bodyがid=fooの要素を内包するため、bodyからdelegateを実行する。documentなどでもOK $("body").delegate("#foo", "click", function() { console.log("#fooがクリックされました"); }); イベントハンドラはbodyに対してバインドされる。つまりbodyの押下時に毎回コールされることになり、発生するイベント（この場合はclick）が、bodyが内包する要素から伝播（バブリング）する。 jQueryのdelegateは、呼び出し元の要素をチェック（ここでは#fooが呼び出しものかどうか）し、一致する場合にイベントハンドラが実行される、といった流れになる。 両者の特徴と$element.on() bindは要素に直接登録するため、イベントハンドラの実行が即座に行われる。それに対し、delegateは指定されたCSSセレクタとの一致検索を都度行うため、追加された要素に対してもCSSセレクタが一致すれば適用される。 $element.on()は引数のによってどのようにハンドルするかを振り分けており、引数の与え方によってbindあるいはdelegateとして振る舞う。尚、jQueryはonを推奨しており、Zeptoもこの流れを踏襲している。 非推奨なやつら $element.bind() $element.unbind() $element.live() $element.die() $element.delegate() $element.undelegate() bindとdelegateの方がわかりやすいのに、と思ったりもする。$element.live()はdocumentからのdelegateになる。ちなみにどれも内部でonを通る。 まとめ delegateするためにセレクタのマッチング処理とundelegateのためにクロージャを内部的に保持するので、処理は増加する。それでも、Ajaxなどで動的に生成するコンテンツに対してイベントを定義する場合は、都度bindするよりdelegateを1つ貼っておく方がブラウザに優しいと言える。https://1000ch.net/posts/2012/gruntjs-introduction/Sat, 08 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/gruntjs-introduction/もはや説明不要の可能性もあるけど、gruntがコマンドラインのインターフェースを分離してgrunt-cliへの移行をしたこともあり、まとめてみた。 GruntはNode.js製のタスクランナー。JavaScriptで記述する設定ファイルに、ファイルの結合（concat）や最小化minifyといったようなタスクを定義し、コマンドラインから実行する。 言葉だけだとイメージ湧きにくいと思うので、使ってもらうのが一番と言い張って導入手順の説明をする。 Node.js+npmをインストールする インストーラからダウンロードするならNode.js Node.jsのバージョンマネージャを使う場合はcreationix/nvmとかhokaccha/nodebrew 0.8.17で動作確認済み。安定版なら問題ないと思われる。 npmからgrunt-cliをインストールする $ npm install -g grunt-cli これで核となるCLIモジュールのインストールは完了。ターミナルでgruntというコマンドが実行できるようになっている。ただ、設定ファイルがないためこのままだと実行できない。 gruntコアをインストールする ここから先はローカルインストールするので、プロジェクトディレクトリに移動。gruntのコアモジュールをインストールする。 $ cd /Users/[UserName]/workspace/[ProjectName] # 以降ここをカレントディレクトリとして作業 # gruntのコアモジュールをインストールする $ npm install grunt gruntで使うモジュールをインストールする このままだと何も出来ないので、その他モジュールもインストールする。今回は 「複数cssファイルを1枚のcssファイルに結合し、最小化を自動で行う。」 ということをしてみる。 $ cd /Users/[UserName]/workspace/[ProjectName] # [Project]ディレクトリ下にcssフォルダがある想定 # ファイルの変更を監視するwatchモジュールをインストールする $ npm install grunt-contrib-watch # ファイルを結合するconcatモジュールをインストールする $ npm install grunt-contrib-concat # cssファイルを最小化するmincssモジュールをインストールする $ npm install grunt-contrib-mincss [ProjectName]フォルダにnode_modulesというフォルダが作成されて、その中にインストールしたモジュールのフォルダがあればOKです。 gruntfile.jsに設定を記述する gruntが認識する設定ファイルは gruntfile.js という制約がある。v0.3以前はgrunt.jsだったけど、これは前からアナウンスがあって命名制約が変更になった。 以下設定ファイルのサンプル。CoffeeScriptで書いてgruntfile.coffeeでも大丈夫。 module.exports = function (grunt) { // ターゲットとするcssファイルを定義する // ['css/hoge1.css', 'css/hoge2.css']のように個別指定でもOK。 var cssFiles = ['css/*.https://1000ch.net/posts/2012/gzip/Thu, 06 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/gzip/Gzipはファイル圧縮の形式の1つで、ほぼ全てのUNIXに搭載されている。拡張子は.gzで、MIME-Typeはapplication/x-gzip。標準入力から受け取ったデータを圧縮し、標準出力から取り出す事が可能。当然、コマンドで使用する事が出来るがここでは割愛。 httpサーバーのgzipを有効にしてサイト表示速度を向上させる Webサイトの表示は、ブラウザがHTMLドキュメントをサーバーから受け取り、受け取ったHTMLを解釈し、画面に描画する事で成立する。つまり受け取るHTMLのサイズが大きければ大きい程、転送する量が増加し、必然的にロード時間が長くなる。このロード時間を短くするためにGzipでデータを圧縮しよう！という話。 Google ChromeのPageSpeed 自分のサーバーの設定がどうなっているのかわからないという人は、PageSpeedで調べるのがお手軽。例えば、解析結果でGzipを有効にしましょうと言われる場合は、Gzipが効いていないということになる。 PageSpeedはGzipが有効になっているかどうかをチェックする他にも、様々なパフォーマンスの改善案を挙げてくれる非常に良く出来たツール。PageSpeed周りの詳しい使い方は以下が参考になる。 ついに出た！Chrome版「Page Speed」の使い方 - Stocker.jp Google PageSpeed Insights でパフォーマンスチューニング もう少し詳しい仕組み サーバーがGzipしてデータを転送する前に、 「クライアントがgzipを解凍することが出来る」 という点が保証されなければいけないが、ブラウザがGzipをサポートしている（Gzipされたデータの解凍ができる）場合は、サーバーにリクエストするときにリクエストヘッダに自動的で Accept-Encoding:gzip, deflate を付与し「Gzipで送ってもらっても大丈夫ですよ」という情報をサーバーに送る。なので、このヘッダが付与されたリクエストに対して、Gzipしてデータを返してあげる準備をしてあげれば良い。 ざっくり以下のような処理の流れになる。 クライアントがサーバーにデータを要求する。クライアントがgzipに対応している場合はその情報をリクエストヘッダに付与する サーバーが転送する前に、データをgzipで圧縮する。リクエストヘッダにAccept-Encoding:gzipが含まれている場合はGzipする。このときレスポンスヘッダに Content-Encoding:gzip を付与する サーバーがクライアントにデータを転送する クライアントがデータを受け取る。レスポンスヘッダに Content-Encoding:gzip がある場合、解凍する Apacheの場合 Apache2系は mod_deflateモジュール を使用してGzipする。httpd.confを以下のように編集。 # /etc/httpd/conf/httpd.conf # 以下のコメントアウトを外しdeflateモジュールをロードする LoadModule deflate_module modules/mod_deflate.so # 以下を適当な箇所に記述 <Location /> SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html SetEnvIfNoCase Request_URI\.(?:gif|jpe?g|png)$ no-gzip dont-vary Header append Vary User-Agent env=!dont-vary </Location> # 対象とするMIME Typeを指定する場合は # 以下のコメントアウトを外しfilter_moduleモジュールをロードする LoadModule filter_module modules/mod_filter.https://1000ch.net/posts/2012/point-of-javascript/Sun, 02 Dec 2012 00:00:00 +0000https://1000ch.net/posts/2012/point-of-javascript/煩雑なDOMのAPIをラップして扱いやすいインターフェースを提供するjQuery。非常に便利なjQueryだけど、DOM操作のコスト自体が低くなる訳ではないので、実装方法によってはブラウザに大きな負荷をかけてしまう。特に、モバイルデバイスのようなか弱い環境にとってはそれなりにシビアになってくる。端末の性能も飛躍的に向上してきてるとはいえ、最適化された実装を目指さない理由はない。 jQueryでコーディングしていく上で気をつけると良いというポイントを挙げてみる。jQueryと銘打ってるけどそれに限らず、ZeptoでもピュアなJavaScriptでも同じこと。 CSS Selectorのキャッシュ 大半のケースで、要素の再検索は必要ないはず。クエリの実行結果はキャッシュする。 // これはNG $('#hoge').hide(); $('#hoge').css('background', '#ccc'); $('#hoge').show(); jQueryは$()の中にCSSセレクタを渡す事で、指定の要素を探す。つまり、上の例はidがhogeの要素を3回探して、jQueryのインスタンスを3つ生成していることになる。 // これが望ましい var hoge = $('#hoge'); hoge.hide(); hoge.css('background', '#ccc'); hoge.show(); こちらが検索結果を保持し、最適化したコード。要素検索とjQueryオブジェクトの生成が1回のみになっている。変数に格納するしない、あるいはメソッドチェーンするかどうかは、コードの見通しの善し悪しで決めれば良い。 ループ文の書き方 よく書かれがちなループ文。 var array = ['data1', 'data2', 'data3', 'data4', 'data5']; for (var i = 0; i < array.length; i++) { var data = '<div>' + array[i] + '</div>'; // ... } まず、forの継続条件評価式にi < array.lengthとある。継続条件評価はループの度に行われ、配列のlengthプロパティは都度参照されることになる。また、for文の中でvar dataを定義しhtmlを受け取っているが、特殊な理由がない限り、for文の外で定義すべき。これだとループの度にdataが宣言されることなる。 // 上記をふまえたループ文 var array = ['data1', 'data2', 'data3', 'data4', 'data5']; var i, len = array.https://1000ch.net/posts/2012/minify-css-and-js/Wed, 28 Nov 2012 00:00:00 +0000https://1000ch.net/posts/2012/minify-css-and-js/転送量削減のためのアプローチについてはgzipの他に、テキストファイルそのものの圧縮がある。これを行うと転送にかかる時間が短くなるだけでなく、ブラウザがJavaScriptを評価する時間や、キャッシュされたときのメモリの削減にも繋がるので、是非実施したい。 最小化・最適化 使っていない関数や余分な変数宣言を削除したり、共通化をしっかり行い、冗長なコードを除くこと。cssに関しては構造の最適化までしてくれるcssoというツールがある。ホワイトスペースの除去など一般的な圧縮の他に、ショートハンドで書けるところをショートハンドに変換してくれる。素晴らしい。Gruntのプラグインもある。 開発中はコメントを適切に書いて、見通しの良いコードを書くべきだが、ブラウザに認識させる段階ではその必要がない。改行コードが取り払われて一行になっていたとしても認識してくれる。そして除かれた余分な文字の分、ユーザーの待ち時間は短くなる。なので、実際にサーバーに置くファイルはminifyすること。 ローカル環境でminifyする ここでは代表的なGoogle Closure CompilerとYUI CompressorとUglifyJSの3つを紹介。Google Closure CompilerとYUI CompressorはともにJavaで書かれており、jarファイルをダウンロードしJVMを通して実行する必要がある。UglifyJSはNode.jsで実行されるので、npm経由でインストールする。 Google Closure Compilerの場合 --js=で入力ファイルを、--js_output_fileで出力ファイルを指定。入力順にJSファイルが結合されて、圧縮される。 $ java -jar compiler.jar --js=input1.js --js=input2.js --js_output_file=out.js YUIの場合 こちらも入力ファイルと出力ファイルを指定して実行するだけ。 $ java -jar yuicompressor-x.x.x.jar /path/jsfile.js -o /path/jsfile.min.js UglifyJSの場合 UglifyJSをnpmでインストール。 $ npm install --global uglify-js 入力ファイルと出力ファイルを指定して実行。 $ uglifyjs /path/jsfile.js /path/jsfile.min.js オンラインツールでminifyする もっと手軽にやりたい場合は、オンラインツールを使用するのも良い。Google Closure CompilerもYUI Compressorもオンライン版がある。 継続的に実施していくために 開発現場で実践していくことを考えると、いちいち手作業ではやっていられない。そういった場合はGruntのようなタスクランナーを使ったり、Jenkinsのジョブに組み込むなど何らかの方法で自動化するのが現実的。GruntはNode.js製のタスクランナーで、ファイルの変更を監視してそれをトリガーにファイルを圧縮するといったような処理が簡単な設定で自動化できる。Gruntのビルド処理をJenkinsに組み込むことも可能なので、まずはローカル開発環境で整備してみると良いだろう。 havelog - Grunt - havelogのGruntタグ gruntをインストールする - jekylog