AirBnb がReactNativeをやめることが話題になってますね。 medium.com RNの未熟さ、社のRNのForkのメンテナンスコスト、JavaScriptのスケールのしなさ、JavaScriptCoreの実装の違い、クラッシュレポートが信頼できない、開発者は主に片方のプラットフォームしか知らないのでOSSのライブラリはバグってる、結局ブリッジを描く人間が必要、人が雇えない、山ほど出てくる…— Hello (@rejasupotaro) 2018年6月19日 以下私見です。 RN採用可否のフローチャート 自分がRN使いたいといって相談された際にはこういう感じで返してます。基本的にはExpo 採用可能か否かで判断してます。 Expo ではじめる ReactNative 開発環境 - Qiita プラットフォームごとにUXを突き詰める必要がある => RN やめとけ Q: 社内に

これは、個人でどんなエディタを使うべきか、ではなく、「チームとして」新しいものを採用するとき、あるツールがエディタ横断で便利かどうかを考える必要がある。 自分個人としては、基本はAtomを使って、TypeScriptを書くときだけVS Code を使っている。ターミナルでは Vim。 環境でエディタを選ぶ 最近の新規プロジェクトでは、とくにブロッカーがなければ TypeScript を使っていいと思う。TypeScript を使うなら当然 VS Code を使うことになる。Atom や Vim でもいいが、TypeScriptのエディタとしては、流石に完成度が頭一つ抜けてる。JavaならJetBrains 的なノリで、TSならVSCode、そういうものと思ったほうが楽。 TS以外なら、エディタはなんでもいいが、ある程度流行ってるものでないとエコシステムに追いついてくれない。 prettie

この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し

前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として

という予感がしたので書く。正確に言うと機械学習の成果としての訓練モデルを。 まず事前に前置きしておくと、僕は機械学習をほとんど抑えていない。トレンドだけ追ってる。 大学生の時にニューラルネットワークを実装してみてフ～ンって言ってた程度に知識しかなくて、ディープラーニングが流行る前だから、「バックプロパゲーションってややこしかったけど、今は自動でモデルの最適化いい感じにやってくれるんでしょ？」ぐらいの雑な理解しかない。(この時点で怪しい) で、今はフロントエンドやってて、ここは機械学習は縁遠いように思えるかもしれないだろうけど、最近のGoogleはなんとブラウザで tensorflow を動かすのに情熱を注いでいる。 で、こんなのが Hacker News で流れてきた。 medium.com とりあえず試した。デモをそのままデプロイした。 PoseNet - Camera Feed Dem

10年前に上京して、Twitterをはじめて、昔はどの勉強会やオフ会いっても最年少かそれに近い感じだったが、今となってはそんなこともなくなった。 働き始めた後、25歳頃に自己分析した結果、「好きなことしかできない」「勝つのが好き」というあまり社会人適正が高くない特徴を自覚した。なので、とりあえず現状自分が勝ててる分野をそのまま突き詰めることにした。フロントエンドとSPA。その戦略は間違ってなかったが、コンフォートゾーンに甘んじている感覚もある。俺の評価が上がったんじゃなくて、時流にいい感じに乗れてたという感もある。 今はフリーランスとしてやっていけてる。幸い仕事は十分ある。でもなんか妙にこじんまりとした感じに収まっている。なんというか、冒険していない。20代はベンチャー企業で働いてあわよくば一発と思っていた。それも途中で諦めてしまって、今はフリーランスでコンサルとエンジニアの真ん中みたいな

デッキ構築 + ローグライク + ダンジョン。 アーリーアクセスで少々コンテンツが足りない感はあるものの、とても面白かった。日本語の wiki や攻略情報が現在ほぼ一切存在しないので、布教兼ねて紹介したい。 プレイアブルの2キャラでクリア済み。クリア = Stage 3 のボス撃破としている。 Slay the Spire on Steam 概要 基本的にはドミニオンのようなデッキ構築ゲーム。最初のカードはキャラクターごとに固定、毎ターン +3 Energy で 5 ドロー、Attack|Power|Skill のアクションカードをコストを払って実行する。 カードは敵を倒したりショップで購入することで手に入れる。他のデッキ構築ゲーと一緒で圧縮が重要で、イベントマスのストアで金払って1枚廃棄したり、特定のイベントで廃棄したりできる。休憩ポイントで各カードは一回だけ強化できる。 英語か機械翻訳

大学生だった当時、梅田望夫の本を読んではてなにやってきた僕は、ブログ論壇への憧れだけがあって、技術者にもなれず、時流のテーマに対して書くべきテーマを持たず、ただ実家の宗教に対する恨みだけを書き綴っていた。 もちろん、そんなものを好きこのんで読む人はいなくて、ただ虚無へとテキストを放り込んでいたのだけだど、いつからか、ある程度パターンを獲得して、その真似をするようになって、成功失敗を繰り返して、それなりにPDCAを回してきたと思う。思えば、その過程でいろんな人のヘイトを買った気がする。 人間のテキストの読み方、その反応、というのはパターンを、いくつか書き起こしてみる。 読者は、ファーストビューのレイアウトで、読む読まないを決める タイトルは記事の印象の5割 章タイトルが残りの半分 本文はほとんど読み飛ばされる 書き手としては単語の印象の連なりでイメージを形成することになる 段落が均等に分割さ

と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ

この資料のアレ。 mizchi.hatenablog.com Reducer は単なる (State, Action) => State の関数で、redux.combineReducers は複数の reducer を名前空間でマップした新しい reducer にするもの。 Rx分かる人、Redux分かる人向けに、 redux.combineReducers を実装して、Rx.Observable.scan で reducer として実際に動くコードを書いた。 const Rx = require('rx') const combineReducers = reducerMap => { const initialState = Object.entries( reducerMap ).reduce((acc, [key, reducer]) => { return Object.ass

前作ギリギリS+、今作150時間ぐらい。今Sでうろうろしてるプレーヤーなのでガチ勢ではない。一緒にやってる人達がS+ばかりなので、足を引っ張らない程度になろうと、ヒーヒー言いながらやってる。 前作は、ダイナモでハコフグヒラメエリアだけで厳選でS+に上げたので、実質S適正ぐらいだったと思う。自分には入力精度と視野と決め打ちな戦術プランが不足している、という自覚があり、それらは経験で補わないといけないが、それらを得るための体力と時間を捻出しないといけないのが難しい。 この記事で、あれこれ文句言ってるが、面白いからこそ出る不満であって、アプデに期待している。展望として、2年ぐらいは飽きずに遊ばせてくれという感じ。あと自分の意見じゃなくて、自分よりうまいS+環境の人達の意見を鵜呑みにしている部分もある。 インフレ抑止 & 前作トップメタへの懲罰的なナーフ 前提として、前作でインフレしきった状態をリ

前提 面白いのは間違いないし、Switchのスタートダッシュに大きく寄与していて、自分も90/100あげたいゲームで、この路線で次の作品もやってほしい、が、現時点で不満に思う点も多く、またネットでも絶賛ばかりで気持ち悪いので、思うところを書いておく。 自分は比較的、他のオープンワールドゲームに慣れてる方だと思う。ゼルダの比較対象は Skyrim, Fallout4, Witcher3、ゼノブレイド、ゼノブレイドクロス。ただこれ以外にもRPGやりすぎていて、趣味がこじれている自覚はしている。 文句言ってるから面白くないというわけではなく、単に Not for me という意味合いが強い。 難易度曲線が緩やかで上限も低い RTAや一部の縛りプレーを除いて考えると、順繰りにいってデスマウンテンあたりで難易度が頭打ちで、以降ダレがち。 メインシナリオから外れれば上位のライネルもいるが、それはエンド

作った。GWの間、コンビニと近所のカフェ以外に外出してないし、ゲームもしてない。 https://mizchi-sandbox.github.io/rpg-prototype/ で触れる。デザインはしょぼい。Chrome以外で動いてる気がしない。 コードはここ https://github.com/mizchi-sandbox/rpg-prototype 仮素材はウディタに付いてくるサンプル素材をお借りした。 WOLF RPGエディター公式サイト 【RPG作成フリーソフト】 仕様 Spaceでポーズ＆リスタート クリックでスキルの使用 一度スキルを使ったらクールダウンがある Player1 だけ操作できる あとはなんか察してほしい。 何故作ったか 前々から、ゲーム、とくにRPGを作りたいと思ってたのだけど、メインループがすんなり綺麗にかけたためしがない。趣味プロジェクトは技術的に辛いとやる

経緯 ドワンゴ様から恵贈頂いた。 高校生からはじめる プログラミング 作者: 吉村総一郎出版社/メーカー: KADOKAWA発売日: 2017/04/14メディア: 単行本この商品を含むブログを見る …読んでみたけど、HTML/CSS/JS の初歩的な部分を、初学者にやらせるとこうなる、という素朴な世界観で、CSSフレームワークもJSライブラリも出てこない。いや、出せと言ってるわけじゃない。理解せずにフレームワークを使う習慣がつくと、スクリプトキディ的な振る舞いによっていくし、教える側としても、変数が大きくなってコントロールできないのが問題だろう。 じゃあ基礎を抑えたとして、この先どう教えるといいんだろうな、というのは、たしかに自分も前から考えてはいて、それを書いてみる。 この文章のターゲット JavaScriptを教える人、またはポインタがあれば自学できる中級者以上 追記: すべての初学

鉄は熱いうちに叩け。 表面上はただの Twitter、というかTweetDeck フェデレーションの抽象は一般ユーザーには理解が難しすぎる せめて Yammer ぐらいは倒してほしい フェデレーション(連邦) ユーザーレベルだとTwitterと同じサーバー抽象にみえるが、その上流にサーバーレベルP2Pとでもいうのだろうか、サーバー同士が接続して大きなストリームを形成する。 fshinさんが指摘するように、リモートの削除に難があるが、炎上するような連中はそこまで考えないので、普及するとした場合、それが普及のボトルネックになることはないと考えている。これは善悪でかくあるべしという話ではなく、そうならざるをえないという話。 マストドンに関する現時点での解釈と感想 | F's Garage 中のコード https://github.com/tootsuite/mastodon 読んだ。 Rails

契約先 週3でアカツキ様、週2でリクルートテクノロジー様で開発に関わらせてもらっている。どちらも公開の許可を貰った、というかむしろ宣伝してくれと言われた。アカツキは @seizans さん、 リクルートテクノロジーズは @yosuke_furukawa さんの繋がりで仕事をとった。事前に面識がある人に相談することで、人格面や技術面のすり合わせが楽で、ゼロベースの信頼関係にならず対人関係のストレスが減るようにコントロールした、つもりではある。 全く違う仕事をしているのではなく、どちらも redux 周りをやっている。みんなそこで苦しんでいる。今、界隈を絶望させているのは react-router v4 であり、これが諸悪の根源であるといって差し支えない。既に辛い気持ちなっている。絶対に倒したい。 ネットの人格 契約先の話で思い出したんだけど、僕はネットで暴れてる方と、リアルで卑屈になってる人

当方ボーカル、フルスタックPaaS募集 ほしいもののコンセプト SPA職人としてそこに全力を尽くしたいので、それ以外を全部やってほしい とはいえストレージへのアクセスはAWS Lambda/Cloud Function等を介してちゃんとしたコントロールをしたい プロトタイピング時は何も考えずにORMを叩いていたい 運用フェーズでは金を払ってスケールしたい。とはいえボトルネックは常に監視したい。極端にやばいスケールサイズはどうせ人を雇うのでその先は考えなくていい。 より細かい要求 認証はPaaS側が全部持ってほしい JSONSchema でクライアント/サーバーサイドのアクセス制限を定義したい サーバーはフルマネージド Lambda/CloudFunction で関数単位でパフォーマンス監視/障害検知 ローカルで本番と同じ構成が建てられる アセットは勝手にCDNに投げといてほしい バックエン

4月からフリーランス。直近半年の仕事は埋まってるけど、パイプ作っときたいとかあれば mizchi2w@gmail.com までメールください。 なんでやめるの？ 要約: 自分のスキルの、ベンチャー企業の社員としてスキルミスマッチ フロントエンドの、とくにSPAで高速で堅牢なアプリを作る、という自分のスキルセットを振り返ると、「需要はあって必要なことには必要だが、どうしても瞬間風速が高いそのタイミングを超えると扱いに困る」という人材適正があると認識しており、前職のQuipperから引き続き2社連続で、「そのために入った最初のプロジェクトが終わると、やや手持ち無沙汰になる」という状態になっていました。 とくにスタートアップのような、予算が厳しい上にピボットする可能性ある現場だと、自分のスキルが活かせないフェーズがある、というのが、会社にとっても、個人のモチベーションとして厳しいものがありました

Rebuild.fm の mirakui さんの回聴いてたんだけど、インフラの世界観だと、ロックインさせたい Amazon/Google VS 自由を手に入れたいDocker みたいな構図がある、な話があって、思うところがあった。 rebuild.fm 勿論、話はそう単純じゃないし、それぞれがそれぞれの成果を利用しあってるので、どっちが正義だみたいな話にはならない。第三者目線としては、寡占にならず競争が続くのが望ましい。僕個人の意見としては、金が生まれるところには、正しく金が生まれてほしい。それで全体としての健全性が育まれるなら。日本にいてあんまり面白くないのは、その辺の基盤技術に関われる機会があんまりないことだが…。 とはいえ、利用者目線としては、できるだけ自由なポジショニングを可能な限り選び続けるべき。だが、自由を手に入れるには、それだけの知識が必要となるし、そこを諦めたところをアウト