Edge Worker PaaS の fly.io が面白い - mizchi's blog
なかなかよいおもちゃを見つけたので、紹介します。 fly.io fly.io は CDN Edge Worker で JavaScript に特化した PaaS です。既存のサービスで近いものだと CloudFlare Workers もしくは Lambda@Edge でしょうか。 アカウント登録をして、次のようなコマンドを叩くとエッジで動くアプリケーションを作成することができます。 npm install -g @fly/fly fly login # mkdir my-flyio; cd my-flyio fly new 最小コードはこんな感じ。CloudFlare Workers と同じような ServiceWorker 風と、Google Cloud Function 風の 2 つのパターンでワーカーを定義できます。 // index.js addEventListener('fe
最近のフロントエンドの変化とビルドツールについて - 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は先行実装だ
スターエンジニアはキラーアプリを生み出すのか？ - mizchi's blog
日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。 キラーアプリの出現と技術的イノベーションに相関あるかと言われたらあるとは思うけど枯れた技術の水平思考的な余地も十分あるんでキラーアプリが必ずしも技術的なイノベーションを果たしている必要はない。ただし技術優位がない場合は企画レベルで制限かかるので、それを許容するかどうかという話— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた
Rx.js, Immutable.js について - mizchi's blog
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab
Flux設計論 - mizchi's blog
scala.jsの実用が真面目にペイされる環境を考えると、jsとscalaのアダプタ部分を考える俺と、scalaレベルで何ができて何ができてないか考える俺が二人いればプロダクションで成立しそう— ガソリンの味 (@mizchi) 2015, 4月 28 Scala.jsが生きる場所、たとえば次のプロジェクトはウェブ版シムシティを作ることですって言われたら、ドメイン部分がピュアでかつ複雑になるのでScala.jsを選択するのはありだと思う— ガソリンの味 (@mizchi) 2015, 4月 28 ドメインがピュアでかつ複雑、基本的にatljsが活かせる部分なので、人によってはpurescript選んでもよいわけだし— ガソリンの味 (@mizchi) 2015, 4月 28 アダプタの書き方が altjs => js か js => altjsかで運用勘が結構変わる— ガソリンの味 (@m
reiny開発メモ - mizchi's blog
大筋は reiny - Reactに最適化したテンプレートエンジンを作り始めた - Qiita 内部的処理のなメモ JSXへの問題意識 nodeの変数代入で、コードによる出現順と実際に埋め込まれる位置が異なるのが可読性を落としている listをmapしてelementに変換する処理が直感的ではない react-jadeの拡張を検討 最初はreact-jadeを拡張するのを検討した。調べた感じ、react-jadeは元のjadeをhackyに拡張している。作者が同じだからこそできる感じ。外部からPR出すのも面倒だったので、全く異なる一つの処理系を作った グランドデザイン HTMLツリーをインデントブロックによる閉じタグ省略で生産的に書けるようにする インラインスタイルを書きやすくする インラインコードを書きやすくする reactで表現できることを制限しない 最初はslimのように()なしで
OSS界隈について - mizchi's blog
最近の不満、日本人はライブラリ使って満足してる人が多くて、他人が作ったライブラリがすごいし便利最強みたいな人が勉強会コミュニティのボスになってたりするんだけど、海外だったらそのボスがプロダクトオーナーだったりするわけで、明らかに情報格差になってる— 損益分岐点 (@mizchi) 2015, 3月 14 技術文書は翻訳コストが高いのでそのコスト払った人に敬意が払われるのはいいとして、降ってきた変更に対してフィードバックもせずに文句いう人が(俺含めて)多いのでどうにかしたいなという気持ちがある— 損益分岐点 (@mizchi) 2015, 3月 14 言語が障害になってて報告経路がわからんってのが理由の一つだったけど、最近はGithub Issueで一本化されつつある。とはいえ要望出すフェーズ超えてディスカッションになると日本人の平均的な英語の能力だと明らかに不足で何も言わなくなる人が多い気
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
