Qiitaのランキングの最初の設計者としての「いいね」の設計と、「LGTM」は下においてほしいという話 - mizchi's blog
https://blog.qiita.com/like-to-lgtm/ Qiitaさんの変更。思想はまぁわかるものの、「全部読んでから押してほしい」といいながら、開いた直後に押せるところに配置するのは意味がわからないかなあ。https://t.co/HEtwKg0txr— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2020年3月12日 これについては chokudai さんに完全に同意なのですが、その理由として、自分の在職時に企画したサービス設計意図が強くあって、退職者がそれについて今更どうこういうのはどうか思うところもあるのですが、当時の同僚がほぼ全員退職してしまっているため、ここでその意図を伝えます。 お前は誰 & 何 当時の Qiita の開発で、ストックといいねを分離して、いいねをベースにしたランキングの実装のを提案したのが自分です。社内の Qiita:
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
プログラマという現代の傭兵 - mizchi's blog
エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。
Edge 終了に寄せて - mizchi's blog
初報を聞いたとき、描画系だけ blink に入れ替えて処理系は V8 使わず ChakraCore などに入れ替えるのかな、と思っていたが、どうも V8、というか chromium 一式を使うらしい。 正直に言って、Edge が死ぬことに、そこまで強く思うところはない。Edge は内部的に自身のベンダープレフィックスで webkit と名乗るぐらい (標準ではなく) webkit との互換性の意識が高いので、お前自分のことを webkit だと思ってるもんな、みたいな気持ちがあった。 webkit みたいなブラウザが消えて、webkit 後継のブラウザをベースに作り直される。開発者として追うべきは、個別の実装ではなく依然として標準仕様であって、それだけの話。 リリースサイクル 僕が思うに、 MS の抱えていた真の問題は、Windows に紐付けられたリリースサイクルとサポートにあって、Wi
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
QiitaやってるIncrementsに転職した - mizchi's blog
これ @mizchi がIncrementsにJoinしました - Qiita Blog 特に転職したとは一言も報告してなかったけど、先月末でQuipperを退職し、二週間ほどのモンハン廃人を経て、先週からQiitaを運用しているIncrementsで働いている。 自分が使ってるサービスのドッグフーディングが出来て、将来性があって、大きすぎずに自分の手が届く範囲にやり甲斐があり、JavaScriptエンジニアとして自分にとっての技術的課題がたくさんありそうなIncrementsに行くことにした。 一週間ぐらい働いて、やっと慣れてきて、デプロイももう何度かやったし、Githubのstatsみると一週間で25000行ぐらい書き換えてユーザーの手元に届いてるっぽいんだけど、これは最初に取り組んだのが外部アセットを連結して圧縮したりこねくり回したりしたりするという作業で、作業量以上に行数に出ている
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
シンプルさが勝つ。人間はシンプルではない。 - mizchi's blog
迷ったらシンプルな方— 片手間以上 (@mizchi) 2014, 7月 19 僕は主にUIを作るエンジニアなのだけど、以下の話題について。 時間をかけて、つまらないものを作りたいか？ - futoase.hatenablog.com ニコニコ動画はSynvieプロジェクトが原型 - はてな村定点観測所 UIの有効性を証明する仮説とその検証において、ほとんどの場合において次の二つが根源的な問題となる。 だいたいのものはシンプルな方が勝つ 人間はシンプルではない 二点間の距離を求める三平方の定理は、(ディスプレイが歪んでいない限り)簡潔でシンプルだが、二点のボタンを順番に押すときのマウスの軌道、そのあいだのユーザーのメンタルモデルの変化は、まったくもってシンプルではない。 人間はシンプルなものの価値を認めたがらない、というバイアスがある。金を産まないといけないソフトウェア開発の現場は、コアフ
昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog
Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
Swift ファーストインプレッション - mizchi's blog
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
データバインディングについてVue.jsと Backbone.stickitを比較する - mizchi's blog
これは会社でvue.jsを採用を説得するための資料なのでstickitを罵倒する vue.js http://vuejs.org/ backbone.stickit http://nytimes.github.io/backbone.stickit/ Backbone.stickitとVue.jsの比較 「#menuを押したら右に100px動く」みたいなコードを書いてみるとする。 template関数はJadeテンプレートを展開する関数だと思ってほしい Backbone.stickit の場合 class MenuView extends Backbone.View initialize: -> @model = new Backbone.Model() @render() render: -> @$el.html template(""" #menu.js-open """) @stic
エンジニア Mac アプリ 環境 おすすめ - mizchi's blog
Macで捗るオススメのアプリひたすら書いてくわ : IT速報 が余りにも消化不良だったので書く。 (タイトル考えるの面倒臭かったのでワードサラダ風) homebrew入れる brewfileをつくる brew bundle おわり 以下、最近作った ~/brewfile です。デスクトップアプリもbrew caskから突っ込む。 もういろんなサイト巡ってアプリを入れて回る時代は終わったんだよ、爺さん tap phinze/homebrew-cask || true tap homebrew/versions|| true update || true install brew-cask || true install git || true install hg || true install ag || true install gist || true install gibo ||
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
Dartについての私見 - mizchi's blog
Jxckさんのこの記事についての感想 Dart について思っていること - Qiita http://qiita.com/Jxck_/items/1bb00cfd84400e08f525 Dart 悪い言語じゃないけど Altjs 繚乱の時代に出てきたのがよくなくて、ポテンシャルの割にはOne of them になってしまってる気がする。正確にはトランスパイラではなくDartVMが開発されてるわけだけど Google手動じゃなくて共同開発とダメだったのでは。— 高意識エネルギー (@mizchi) 2014, 2月 19 s/手動/主導— 高意識エネルギー (@mizchi) 2014, 2月 19 Dartの悪い点、新しい言語なのに無難にまとまりすぎてて突出したメリットを感じない。推論に面白いシステム(Optional Typing)が実装されてるけど派手さはない。Java inspir
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
markdown->TeXの変換だけで卒論を仕上げるのに便利だったツール10個まとめ - mizchi's blog
卒論書き上がったので環境を後続の人類のためにどうやって作ったかメモっておく。 環境はMacだったけどMacTeX以外たぶんLinuxでもいける。その指導教員に入れられたmacportsのTeXとTeXShopを窓から投げ捨てろ。というのが要旨。 MacTeX MacTeX - TeX Users Group http://tug.org/mactex/ 2014年において他の環境を入れる必然性は殆ど無い。これ一本。 iconv この時代sjisを扱うのは人生をムダにするだけなので、研究室の秘伝タレたるtexもまずutf8に変換。 その後 ¥ を \ に置換するのは必要だったけどオプションでどうにかなるのかもしれない。 iconv -s -f SHIFT_JIS -t UTF-8 hoge.sty > hoge.utf8.sty pandoc markdownをtexに変換できるツール。革命
「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは？ - mizchi's blog
CoffeeScriptの関数は明示的にreturnするべき | CreativeStyle 本当に遅いのか、それを確かめましょう。 適当にでっちあげたコードです f1 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j f2 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j return console.time "f1" for i in [1..100000] then f1() console.timeEnd "f1" console.time "f2" for i in [1..100000] then f2() console.timeEnd "f2" 実行してみます $ coffee hoge.coffee f1: 105ms f2: 4ms 約26倍違う、ということがわかります。
自分の強みを生かすこと on Quipper - mizchi's blog
今リリース前にしてはタスクがあんまりないのでブログ書いてみる。 Quipperに入社してから一ヶ月半ほど経過した。それで感じたことをあれこれ書いてみようと思う。 あんまり熱心に書くと前の会社に入ったばかりのことを思い出して恥ずかしくなったりするので、ほどほどにする。 エンジニア文化の共有 会社に入ってまず最初にやることは、エンジニアが文化を共有することだと思う。 どんなマインドかは、僕より Quipper のスピード感 - @kyanny's blog とかを読んだ方が伝わるはず。 QuipperはOSS文化というかRuby文化的なものを強く志向している感じがあって、そこらへん馴染みやすかった。 入社してからやったこと まず前提として、ベンチャーなので整った教育制度などはない。(そもそも自分も研修など期待していない)。 エンジニアとしての文化を共有しているから、最初からすぐ仕事に入れた。具
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
ソースコード上の主語は誰か、という話 - mizchi's blog
ふとTwitterで投げたらリプライたくさんきた これ素朴な質問なんだけど、ソースコードで英語でコメント書くとき、守護はIなのかWeなのかコードそのもので受動態で書くのか、どっちなの— 性格は糞 (@mizchi) 2013, 9月 23 @mizchi 一行目は主語無し（命令形）、長い説明をつける場合は 1.言い訳がましいコメントは I を主語に 2. 誰かと合意済みの事柄は We を主語に 3. 仕様に沿う振る舞いに変更する場合は It should be ~ などコード自体が主語であるように、と書いてる— Kensuke Nagae (@kyanny) 2013, 9月 23 @mizchi "add …": このコードは…を足します、"added …" このコードは…で足されました、"adding …" このコードは…を足しています— 中村氏 (@r7kamura) 2013, 9
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
