https://blog.qiita.com/like-to-lgtm/ Qiitaさんの変更。思想はまぁわかるものの、「全部読んでから押してほしい」といいながら、開いた直後に押せるところに配置するのは意味がわからないかなあ。https://t.co/HEtwKg0txr— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2020年3月12日 これについては chokudai さんに完全に同意なのですが、その理由として、自分の在職時に企画したサービス設計意図が強くあって、退職者がそれについて今更どうこういうのはどうか思うところもあるのですが、当時の同僚がほぼ全員退職してしまっているため、ここでその意図を伝えます。 お前は誰 & 何 当時の Qiita の開発で、ストックといいねを分離して、いいねをベースにしたランキングの実装のを提案したのが自分です。社内の Qiita:

なんか今日は2がいっぱいあるので @syakejs と入籍しました。 以下例のリンクですhttps://t.co/dnzQMbvxdu pic.twitter.com/FrEcrOGUAz— ヌー (@mizchi) 2020年2月21日 私事ですが(と個人ブログでいうのもなんですが)、syakejs:(blog) と結婚しました。彼女は Webエンジニアだったり、大学でセキュリティの研究をしてたりしています。競プロやCTFもやってるらしいです。 話を聞いてみると、昔から僕のブログやTwitterをみていたファン？だったらしいのですが、最近なんやかんやあってコンバージョンしました。 入籍いつしよっかーという話になって、西暦2020年(令和2年)2月22日というゴロがよかったので、この日に決めました。 なにかしたからと言って別段何かが変わるというわけではなく、これからも普段どおりやっていくの

2020年になり、先の10年のゲームを振り返るのが話題になってたので、自分も書く。 RPGが多く、洋ゲー寄り。あくまで自分がこう思っているというだけで、なにかの総意というわけではないのに注意。 jp.ign.com anond.hatelabo.jp 追記: 最初は 8本だったが、 Bloodborne を追加して 9本になった ウィッチャー 3 ワイルドハント store.steampowered.com Bethesda のゼロ年代の TES IV: Oblivion と Fallout3 という２つの傑作が、テン年代のオープンワールドを方向性を決定づけた。テン年代のオープンワールドからベストを一本選ぶなら、その続編の TES V: Skyrim も Fallout4 も、そしてもちろん任天堂のゼルダの伝説:BotW も素晴らしかったが、自分はウィッチャー 3 を選ぶ。 ウィッチャー

なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介

hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま

エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。

なぜ初心者は webpackが解らないのか？- Why can’t you understand the webpack? - from 健人 井関 www.slideshare.net この記事バズってたけど、わからない人がよりわからなくなる、という点で問題だと思っていて、webpack の目的の本質的な部分から整理する必要があると思います。 (あと友人が webpack に挑戦していたので入門資料も兼ねてる) Webpack の本質的な部分は次の3つです。それ以外は全部おまけ機能だと思ってよいです。 ES Modules のエミュレート node_modules のリンカ 拡張子ごとの変形 Webpack が本当にやりたいこと こういうコードがあるとします。 // src/a.js export default () => console.log('hello'); // src/in

なんでそんな手が速いのか聞かれたので、最近使ってるSPAボイラープレートを紹介しておきます。 github.com $ git clone git@github.com:mizchi-sandbox/minfront.git --depth 1 myspa $ cd myspa $ yarn install $ yarn dev # Start app server 終わり。 src/main.tsx か src/index.html を編集して、 yarn build && yarn deploy で netlify にアップロードできます。(要 netlify アカウント) こんな感じ https://gallant-yalow-997008.netlify.com プロダクションで使えるちゃ使えるかもしれないけど、議論の余地があるようなものを含まない最小構成。 含まれるもの yarn

もう人生で何個目かわからない markdown エディタ作った。が、今回のは結構気に入っている。 https://markdown-buffer.netlify.com/ で遊べる。 用途としては、GitHub か Qiita か はてなブログかわからないが、なにか書こうと思ったときに、どのサービスも中途半端に重いので、とりあえずのバッファが必要、という感じで作った。なので速度重視。 ブラウザのストレージで永続化してる。オフラインで動く。できるだけエディタとしてはスコープを大きくせず、単に編集バッファ(textarea)でしかない、というのを意識している。 結構頑張って作り込んでしまった https://nedi.app が色々肥大化してしまっていて入力時にラグを感じるので、編集体験を見つめ直す自戒もある。 機能 数式対応 コードハイライト対応 バックグラウンドで自動保存 改行を br に

某社で自分が 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

最近乗り換えたもの Twitter: 夜フクロウ => Tweetdeck ブラウザ: Firefox(Vimperator) => Vivaldi RSSリーダー: Livedoor Reader => Inoreader ただ、これらにかなり不満がある。 情報には上流がある。情報の上流は、一次情報が乱雑に転がってる未整備の荒野みたいなもので、下流はその二次情報やまとめみたいなもの。キャズム理論でいうと、一次情報に接する人がイノベーター、イノベーターを観測する人がアーリーアダプター、イノベーターまたはアーリーアダプターによる編集物を閲覧する人がマジョリティという分類になると思う。 自分が思う近年のインターネットの問題は、一次情報を整理していたイノベーターやアーリーアダプターに対するサービスが本格的に終わってきたこと。 最初に挙げた3つのサービスは、どれもサービス終了やサポート終了などの必

このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

最近では、Gradual Typing、漸進的型付けと呼ばれる型システムを備えた言語(拡張)が増えてきています。 次のようなもの JavaScript: TypeScript / Flowtype Python: mypy / pyre-checker PHP: hack / php-storm flow/pyre-checker/hack と facebook 製が多いですね。 この記事は、それらを使う動機と運用について書きます。この記事の出発点として、 おそらく TypeScript/Flow で発生した問題が後発の言語で発生すると思っており、それらを使う方や、設計する人への提言でもあります。 自分は昔 https://github.com/mizchi/TypedCoffeeScript というAltJS作ろうとして、実装のツラミはなんとなく知ってるつもりです。ホビーレベルで作るもの

フロントエンドの中でも、JS書くプログラマと、CSSを書くマークアップと、デザインカンプを作るデザイナで、コンポーネントという概念がズレる。だいたいこれらが一人だったり兼任だったりで1~2レイヤーの開発ステップになるが、完全分業だったり人が多くなると混乱の元になる。 誰かが決定的に間違ってるというつもりはない。正直、どっちかというと本来のデザイナ側の用語定義に倒した方がいい気がしているが、プログラム上の都合もいろいろ混ざってきて、話が簡単ではない。 自分の理解が間違ってる可能性もある。この記事はレビューをもらうために書いている側面もあり、指摘されたら追記していく。 読んだもの。 Atomic DesignとCSS設計 - Atomic Designとは何か | CodeGrid Atomic Designの考え方と利点・欠点 – wkr. Atomic Design の大雑把な理解 基本的

これは、個人でどんなエディタを使うべきか、ではなく、「チームとして」新しいものを採用するとき、あるツールがエディタ横断で便利かどうかを考える必要がある。 自分個人としては、基本は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

ライセンス表記みるぐらいで深掘りはしてない シャニマスのコード読むか— human eslint --fix (@mizchi) 2018年4月24日 シャニマス、pixijs ですね— human eslint --fix (@mizchi) 2018年4月24日 pixi-ae.min.js たぶん after affect のコンバータなんだろうけどググっても引っかかんないな、内製かな— human eslint --fix (@mizchi) 2018年4月24日 s/after-affect/after-effect After effects to pixi.js | CodeSeek なら見つかったが、該当のライブラリ名で探してるが見つからず パーティクルはこれ https://t.co/NtIqPBBq7n— human eslint --fix (@mizchi) 201

某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない