SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
プログラマという現代の傭兵 - mizchi's blog
エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。
Edge 終了に寄せて - mizchi's blog
初報を聞いたとき、描画系だけ blink に入れ替えて処理系は V8 使わず ChakraCore などに入れ替えるのかな、と思っていたが、どうも V8、というか chromium 一式を使うらしい。 正直に言って、Edge が死ぬことに、そこまで強く思うところはない。Edge は内部的に自身のベンダープレフィックスで webkit と名乗るぐらい (標準ではなく) webkit との互換性の意識が高いので、お前自分のことを webkit だと思ってるもんな、みたいな気持ちがあった。 webkit みたいなブラウザが消えて、webkit 後継のブラウザをベースに作り直される。開発者として追うべきは、個別の実装ではなく依然として標準仕様であって、それだけの話。 リリースサイクル 僕が思うに、 MS の抱えていた真の問題は、Windows に紐付けられたリリースサイクルとサポートにあって、Wi
大量のテキストを食っても速い Markdown Editor 作った - mizchi's blog
もう人生で何個目かわからない markdown エディタ作った。が、今回のは結構気に入っている。 https://markdown-buffer.netlify.com/ で遊べる。 用途としては、GitHub か Qiita か はてなブログかわからないが、なにか書こうと思ったときに、どのサービスも中途半端に重いので、とりあえずのバッファが必要、という感じで作った。なので速度重視。 ブラウザのストレージで永続化してる。オフラインで動く。できるだけエディタとしてはスコープを大きくせず、単に編集バッファ(textarea)でしかない、というのを意識している。 結構頑張って作り込んでしまった https://nedi.app が色々肥大化してしまっていて入力時にラグを感じるので、編集体験を見つめ直す自戒もある。 機能 数式対応 コードハイライト対応 バックグラウンドで自動保存 改行を br に
TypeScript入門以前ガイド - mizchi's blog
某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty
手足がもがれる感覚 - mizchi's blog
最近乗り換えたもの Twitter: 夜フクロウ => Tweetdeck ブラウザ: Firefox(Vimperator) => Vivaldi RSSリーダー: Livedoor Reader => Inoreader ただ、これらにかなり不満がある。 情報には上流がある。情報の上流は、一次情報が乱雑に転がってる未整備の荒野みたいなもので、下流はその二次情報やまとめみたいなもの。キャズム理論でいうと、一次情報に接する人がイノベーター、イノベーターを観測する人がアーリーアダプター、イノベーターまたはアーリーアダプターによる編集物を閲覧する人がマジョリティという分類になると思う。 自分が思う近年のインターネットの問題は、一次情報を整理していたイノベーターやアーリーアダプターに対するサービスが本格的に終わってきたこと。 最初に挙げた3つのサービスは、どれもサービス終了やサポート終了などの必
すべてのプログラマが機械学習を受け入れる準備をする時代になった - mizchi's blog
という予感がしたので書く。正確に言うと機械学習の成果としての訓練モデルを。 まず事前に前置きしておくと、僕は機械学習をほとんど抑えていない。トレンドだけ追ってる。 大学生の時にニューラルネットワークを実装してみてフ～ンって言ってた程度に知識しかなくて、ディープラーニングが流行る前だから、「バックプロパゲーションってややこしかったけど、今は自動でモデルの最適化いい感じにやってくれるんでしょ？」ぐらいの雑な理解しかない。(この時点で怪しい) で、今はフロントエンドやってて、ここは機械学習は縁遠いように思えるかもしれないだろうけど、最近のGoogleはなんとブラウザで tensorflow を動かすのに情熱を注いでいる。 で、こんなのが Hacker News で流れてきた。 medium.com とりあえず試した。デモをそのままデプロイした。 PoseNet - Camera Feed Dem
キャッシュフレンドリーなステートレスアプリケーション設計について考える #CDN_Study - mizchi's blog
CDN_Study という勉強にいってきた。 https://http2study.connpass.com/event/81469/ そこで、Akamaiの方が、「個人の意見だけど、アプリケーション側がもっと基礎設計でステートレスでキャッシュフレンドリーな設計になってないといけないよね」という旨の発言をしていて、最近そのことにアプリケーションエンジニアとして同じようなことを考えていたので、書き出してみる。 SPAとかSSRとかフロントの不毛な話は出さないようにしてるが、主にサーバレス環境を意識している。 前提 世の中のアプリケーション内のモジュールは、Statefull or Stateless に分類でき、それをツリー状に表現できれば差分検知できる、という React の仮想 DOM 的な世界観が自分にある 以下の話は、基本的には Fastly のサロゲートペアーとそのためのミドルウェ
ServiceWorker as a Service, または Universal ServiceWorker という発想 - mizchi's blog
ServiceWorker とは本質的に リクエスト＆レスポンスモデルであるので、それをサーバーサイドで実装で一種のサーバーロジックとして動かしてしまって良いはずだ ー という発想に目から鱗だったので、ちょっと考えてみたいと思う。 www.publickey1.jp ここで試せる。 https://cloudflareworkers.com/#a9bc9ef6b4248289c71518581df30bc7:https://tutorial.cloudflareworkers.com Cloudflare はCDN業者なので、 それに特化して Service Worker as a Service みたいな表現はしていないが、実態としてはサーバーサイド ServiceWorker だ。Fastly では varnish のミドルウェアなどでキャッシュ破棄設定のロジックやリダイレクトを書いて
マストドンについて所感 - mizchi's blog
鉄は熱いうちに叩け。 表面上はただの Twitter、というかTweetDeck フェデレーションの抽象は一般ユーザーには理解が難しすぎる せめて Yammer ぐらいは倒してほしい フェデレーション(連邦) ユーザーレベルだとTwitterと同じサーバー抽象にみえるが、その上流にサーバーレベルP2Pとでもいうのだろうか、サーバー同士が接続して大きなストリームを形成する。 fshinさんが指摘するように、リモートの削除に難があるが、炎上するような連中はそこまで考えないので、普及するとした場合、それが普及のボトルネックになることはないと考えている。これは善悪でかくあるべしという話ではなく、そうならざるをえないという話。 マストドンに関する現時点での解釈と感想 | F's Garage 中のコード https://github.com/tootsuite/mastodon 読んだ。 Rails
Vimperatorの思い出とVivaldiへの期待 - mizchi's blog
※はじめに これは Vimp やめて Vivaldi 使おうぜとアジる記事ではない。最近何書いてもアジってると誤解されるの困る。 思い出 僕のプログラマになるきっかけの一つに、2008年頃にリナカフェに遊びに行った時に @mashiro にVimperatorを勧められたのがある（本人はおぼえてないかもしれない）。当時の僕は大学に入ったばかり。Firefoxは使っていたが、プログラミングは多少興味あるけど、難しそうだなぁ、程度の認識で、もちろんVimなんか使ったことがなかった。 初期設定はその場で教えてもらって、あとは家に帰って調べた。最初は、とりあえず便利なショートカットキーを提供してくれて、QuickSilverライクな絞込UI(今だとMacのSpotlightもそうなんだろうが、当時はQuickSilverというMacアプリぐらいしか似たようなものがなかった、気がする)を持つインター
最近のフロントエンドの変化とビルドツールについて - mizchi's blog
界隈の雑な会話です。注意点として、フロントエンドガチ勢寄りの方面なので、一般的な感覚とは乖離してる可能性があります。 基本的には http://www.s-arcana.co.jp/blog/2016/12/12/3438 や kikuchi1201.hateblo.jp を念頭に。 動き早いって言われるフロントエンド界隈、この1年何も進んでないからな— 現場の声 (@mizchi) 2016年12月14日 今年のフロントエンドの統括、es2016でしょぼかったので皆es2015+ みたいなノリが抜けなかったのと、redux以外のfluxが脱落したのと、angular2+今年も出なかったねというのと、たぶん eslint の採用が増えてそう(肌感)のと、flowの採用が増えたぐらい— 現場の声 (@mizchi) 2016年12月14日 実際browserify/webpackは先行実装だ
Re: React.js界隈の人に聞きたい - mizchi's blog
React.js界隈の人に聞きたい 前提 Reactより前に僕がやりたかったこととして、冪等性の担保の為に毎フレーム document.body.innerHTML を書き換えたかったがパフォーマンス的にそれが許されなかったが、Reactは擬似的にそれを達成させてくれたという圧倒的感謝🙏がある— ダイナモポグラマ (@mizchi) 2016年5月23日 SPA 世の中にSPAの需要があるのか？という点考えていたけど、需要がないからSPA技術がいらない、というのはたぶん間違ってて、SPA技術を持たない人が多いからその発想もなく、SPAで達成できることがイメージ出来ないのがアプリケーション設計の縛りになっている、という感じな気がする— ダイナモポグラマ (@mizchi) 2016年5月23日 GmailやTrelloやPivotalやグラブルは異常な技術の集大成ではなく、個別に分解可能な
スターエンジニアはキラーアプリを生み出すのか？ - mizchi's blog
日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。 キラーアプリの出現と技術的イノベーションに相関あるかと言われたらあるとは思うけど枯れた技術の水平思考的な余地も十分あるんでキラーアプリが必ずしも技術的なイノベーションを果たしている必要はない。ただし技術優位がない場合は企画レベルで制限かかるので、それを許容するかどうかという話— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた
睡眠障害で辛い - mizchi's blog
一緒に働いたことがある人は知ってると思うけど、自分は尋常じゃなく朝に弱い。 で、自分でもさすがに酷いと思っており、様々な努力をしたが改善せず、結局睡眠科をうけて睡眠障害だと診断された。 自分がそうだと疑った理由は 睡眠障害らしきものとわたしの20年間振り返りメモ - 青いの のおかげ。inoaoさんとは違うけど、自分は 睡眠相後退症候群 DSPSに罹患して9時5時生活を送ることは、毎日6時間の時差ぼけを体験しているようなものである。患者は週日には数時間しか眠ることができないので、週末には午後まで眠って睡眠時間を補うことがよくある。週末によく眠ったり、普段昼寝をしたりすることで、DSPS患者は昼間の眠気から解放されるが、遅い睡眠相はそのまま続く。 DSPS患者は、極端な夜型の傾向がある。彼らは、夜が最も頭が冴えていて、物事がうまくでき、創造力にも溢れていると感じる。彼らは単純に早く眠ることが
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
#ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
(追記): このブログで一部のJSをgithubに置いてたら 「The website abuses rawgit.com」という警告が出てました。現在修正しました。ご迷惑おかけしました。 @kyo_agoさんの主催で、 @mizchi(シングルページ系フロントエンドJSer) と @damele0nさん(ゲーム系HTML5のJSer)でJavaScriptについて話をした。すごく有意義な話だったので、会話を思い出せる限り書いてみる。 このエントリを読む前にこの記事を読むと幸せになれる。 幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回 - damelog このまとめは僕の主観であり、僕が理解できた部分と自分の発言を一番覚えてるのでどうしてもそれが多めになりますが、ご容赦ください。ついでに酒入ってる。 iOS SafariのIE化
とにかくシンプルで簡単で高速なViewのコンポーネントを作れるHorn.jsを作った - mizchi's blog
JavaScriptでリアクティブっぽくとにかく短くシンプルにビューが書けるライブラリを作った。 mizchi/horn.js https://github.com/mizchi/horn.js 名前は背骨とか角とかっぽければ何でもよかった。 方針 Angularっぽいユーザー定義のdirective Knockout.js っぽいデータバインド Backbone風の軽量なAPI 依存はjQueryのみ とにかく短くビューのコンポーネントの塊を書けるのを目的とした。UnityとかFlashのコンポーネントに影響を受けている気がする。 HTMLのテンプレートによって、ビューがどういう属性を持つか決定される。それをJavaScriptから使う。 インストール bower install horn 使い方 こんな感じでテンプレートを用意する <div data-template-name="st
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
