リングフィットアドベンチャーをクリアして 8kg 痩せて筋肉質になった (71kg => 63kg) - mizchi's blog
ちょっとはてなブログを放っておいたら90日以上進捗がない人の広告が出るようになってしまい、最近やり続けたことといえばリングフィットなので、その話。 (ちなみに、最近このブログの投稿数が減っていたのは、技術記事を別のブログ で書くようにしたからです) クリア自体は 62 日目、今は 101 日目で二週目の後半。体重の変化はタイトルのとおりです。 ビフォアアフター before 去年の11月頃。似た構図の写真がない。腹が出てるのを隠している after さっき撮ったやつ 身長169cm なので 62.8kg が標準体重です。63kgなのでほぼそれぐらい。14年前の高校生以来の水準です。 体重がただ減っただけではなく、体全体がかなり筋肉質になっています。 ダイエットの動機 突然病気の話なのですが、去年の 12 月頃から 1 月にかけて長期間、体温が37.5度から下がらず、病院にいったところウイル
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:
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
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
Qiita の Increments を退職します - mizchi's blog
4月からフリーランス。直近半年の仕事は埋まってるけど、パイプ作っときたいとかあれば mizchi2w@gmail.com までメールください。 なんでやめるの？ 要約: 自分のスキルの、ベンチャー企業の社員としてスキルミスマッチ フロントエンドの、とくにSPAで高速で堅牢なアプリを作る、という自分のスキルセットを振り返ると、「需要はあって必要なことには必要だが、どうしても瞬間風速が高いそのタイミングを超えると扱いに困る」という人材適正があると認識しており、前職のQuipperから引き続き2社連続で、「そのために入った最初のプロジェクトが終わると、やや手持ち無沙汰になる」という状態になっていました。 とくにスタートアップのような、予算が厳しい上にピボットする可能性ある現場だと、自分のスキルが活かせないフェーズがある、というのが、会社にとっても、個人のモチベーションとして厳しいものがありました
さよなら CoffeeScript - mizchi's blog
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
OSS界隈について - mizchi's blog
最近の不満、日本人はライブラリ使って満足してる人が多くて、他人が作ったライブラリがすごいし便利最強みたいな人が勉強会コミュニティのボスになってたりするんだけど、海外だったらそのボスがプロダクトオーナーだったりするわけで、明らかに情報格差になってる— 損益分岐点 (@mizchi) 2015, 3月 14 技術文書は翻訳コストが高いのでそのコスト払った人に敬意が払われるのはいいとして、降ってきた変更に対してフィードバックもせずに文句いう人が(俺含めて)多いのでどうにかしたいなという気持ちがある— 損益分岐点 (@mizchi) 2015, 3月 14 言語が障害になってて報告経路がわからんってのが理由の一つだったけど、最近はGithub Issueで一本化されつつある。とはいえ要望出すフェーズ超えてディスカッションになると日本人の平均的な英語の能力だと明らかに不足で何も言わなくなる人が多い気
仕事とは、プログラミングとは - mizchi's blog
これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら
ゲーマーのエンジニアが転職先としてソーシャルゲーム業界を選ばない理由 - mizchi's blog
今回の転職にあたって、各方面から「なんでゲーム業界にいかないの？」と何度も訊かれたので、書いておく。 僕のキャリアはソーシャルゲーム業界から始まって、教育の会社にいって、次はxxxだ。転職先に関しては後日。 僕はそもそもスーパーファミコン時代にスクエニ黄金期の洗礼を受けた古い気質のゲーマーで、ソーシャルゲームを一切楽しめない人間で、ソーシャルゲームに開発として関わった人間でもある。バイアスが掛かっているのは認める。 古巣がどうこうって問題ではなくて、業界全体の問題なので、そこらへんは誤解しないように。 ソーシャルゲーム業界 今のソーシャルゲーム業界の開発現場は、開発の現場が「面白いゲームを作ろう」というモチベーションにはなりにくい。 感覚として、ソーシャルゲームってのは「課金させる場」を作ることであって、面白いゲームを作ることはあまりフォーカスされない。 それを言えばコンシューマだって売り
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
昔ながらの「片手間に書く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
#ガチ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化
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
どんなJavaScript開発環境でも*必ず*導入するライブラリ10選 - mizchi's blog
lodash.js moment.js mocha.js sinon.js chai.js es5-shim どんなにライブラリを導入しても、顧客との心の距離は一ミリも縮まりませんでした。
巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
