報告: 結婚しました - mizchi's blog
なんか今日は2がいっぱいあるので @syakejs と入籍しました。 以下例のリンクですhttps://t.co/dnzQMbvxdu pic.twitter.com/FrEcrOGUAz— ヌー (@mizchi) 2020年2月21日 私事ですが(と個人ブログでいうのもなんですが)、syakejs:(blog) と結婚しました。彼女は Webエンジニアだったり、大学でセキュリティの研究をしてたりしています。競プロやCTFもやってるらしいです。 話を聞いてみると、昔から僕のブログやTwitterをみていたファン？だったらしいのですが、最近なんやかんやあってコンバージョンしました。 入籍いつしよっかーという話になって、西暦2020年(令和2年)2月22日というゴロがよかったので、この日に決めました。 なにかしたからと言って別段何かが変わるというわけではなく、これからも普段どおりやっていくの
今年お世話になったCLIコマンド集 - mizchi's blog
ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境
Webpack の考え方について - mizchi's blog
なぜ初心者は 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
「この〜を導入すると、なんとこうなりました！どうです？わかりやすいと思えませんか？」 - mizchi's blog
主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され
二世の呪い - mizchi's blog
僕はエンジニアで、このブログで書くことは、そういうテーマを期待されていることを知っている。それ以外はノイズだから、あんまりやらないでほしい、とも。 でもこれは自分のアイデンティティの根幹に関わることで、そういう前提で、一部で話題になってたこの動画を見た。幸福の科学の大川総裁の息子の、幸福の科学との断絶宣言。 www.youtube.com happy-science.jp エンタメの文脈でそれはどうなんだと思うところはあれど、内容自体は非常に思うところがあった。 8歳ぐらいまで、家の宗教に疑問を持つことはなかった。幼稚園までは、人に隠れて食前の祈りを捧げていたと思う。それが褒められると知っていたから。 ティーンエージャーの頃、自分は怒りに支配されていた。自分の家の異常さを客観視できるようになり、その異常さを許せなくなった。自派以外を否定する排他的な教義、一時期採用された一夫多妻、そしてその
マストドンについて所感 - mizchi's blog
鉄は熱いうちに叩け。 表面上はただの Twitter、というかTweetDeck フェデレーションの抽象は一般ユーザーには理解が難しすぎる せめて Yammer ぐらいは倒してほしい フェデレーション(連邦) ユーザーレベルだとTwitterと同じサーバー抽象にみえるが、その上流にサーバーレベルP2Pとでもいうのだろうか、サーバー同士が接続して大きなストリームを形成する。 fshinさんが指摘するように、リモートの削除に難があるが、炎上するような連中はそこまで考えないので、普及するとした場合、それが普及のボトルネックになることはないと考えている。これは善悪でかくあるべしという話ではなく、そうならざるをえないという話。 マストドンに関する現時点での解釈と感想 | F's Garage 中のコード https://github.com/tootsuite/mastodon 読んだ。 Rails
仕事とは、プログラミングとは - mizchi's blog
これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
QiitaやってるIncrementsに転職した - mizchi's blog
これ @mizchi がIncrementsにJoinしました - Qiita Blog 特に転職したとは一言も報告してなかったけど、先月末でQuipperを退職し、二週間ほどのモンハン廃人を経て、先週からQiitaを運用しているIncrementsで働いている。 自分が使ってるサービスのドッグフーディングが出来て、将来性があって、大きすぎずに自分の手が届く範囲にやり甲斐があり、JavaScriptエンジニアとして自分にとっての技術的課題がたくさんありそうなIncrementsに行くことにした。 一週間ぐらい働いて、やっと慣れてきて、デプロイももう何度かやったし、Githubのstatsみると一週間で25000行ぐらい書き換えてユーザーの手元に届いてるっぽいんだけど、これは最初に取り組んだのが外部アセットを連結して圧縮したりこねくり回したりしたりするという作業で、作業量以上に行数に出ている
仕様の決まる速度で実装する - mizchi's blog
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
新卒1,2年目に自己投資してQoL上がったもの - mizchi's blog
この記事みた。 給料全部使う - yulily100's blog 自分はIT業界3年目のエンジニアで、2年間ぐらい、口座残高尽きるまでいろいろ買いまくっててたので、そのログ兼ねてQoL向上に貢献したものを載せておく。 注意点として、自分は大学生時代はほとんどバイトせずに月5万の仕送りで生きてて、何かと安物買いの銭失いしてた反省もあり、多少無理してでも良い物を買う傾向がある。 常飲用炭酸飲料:月2000円 目も覚める。おすすめ。 ジュースがぶ飲みしてたらめっちゃ太ったので無糖の炭酸水がいい。 アサヒ ウィルキンソン タンサン 500ml×24本 出版社/メーカー: アサヒ飲料メディア: 食品&飲料購入: 27人 クリック: 84回この商品を含むブログ (2件) を見る 自分の周囲はペリエ派とウィルキンソン派がいるけど、自分は炭酸が強いウィルキンソン派。 キーボード: 1万~3万 IT系に限
Yoに人生を救われた - mizchi's blog
今ちょっと携帯見つからないだけど 誰か 080 8819 5053 かけるかYo連打して— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24 同じ部屋にあるのはわかる— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24 ＠各位 みつかりました！Yo各位ありがとうございます！！！— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24 Yoすごい— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24 携帯、３日ぐらい見つからなかったんだけど、ソファのシートの下に埋もれてたのを各位のYo連打で無事発見できた。Yoすごい。Yo最高だ。これはステマじゃない！— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24 電池切れてなくてよかった— いま、一番勢いのあるヤツ (@mizchi) 2014, 6月 24
Swift ファーストインプレッション - mizchi's blog
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
6年かけて大学を卒業しました 振り返って - mizchi's blog
昨日のLT でも言ったんですが、6年間かけて卒業しました。 卒業までの経過 普通に単位を取る 3年でゼミ配属 4年で大学院の内定を取る 4年の11月頃、研究に興味をなくし大学院辞退 大学へのやる気が失せて、卒論(とスペイン語)を放置する 就職活動してなかったので、ブログで職を募集 学生のまま就職(契約社員) 5年次、仕事が忙しすぎて卒論書けず 転職(正社員) 6年で卒業 卒業待たずに就職、卒業待たずに転職して、来年で業界3年目の新卒になります。語句の定義が難しいです。 他の業界は知りませんが、この業界、そういう新卒もどきは多いです。 追記: 最後の2年は休学+残単位数が既定値以下で、学費はほとんど割引されています 卒論 卒論は公開しませんが、卒論の成果物はこれになります。 mizchi/TypedCoffeeScript 所属は隠してなかったので別にいいんですが、早稲田大学の人間科学部です
新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog
読みにくい日記です。 一応今の会社はRubyやRailsの会社ってことで通ってると思うんだけど、自分はほとんどRails触ったことなかったので、何かと色々やる必要が出てくる。 今はJavaScriptのフロントのタスクがあんまりなくてRailsやった方がいい感じで、じゃあ勉強がてらやるかって突っ込んだらちょっとウゥムって感じになった。 問題 勉強側に振ってしまいすぎたのもあるんだけど、かなり生産性低かった自覚がある。結局1週間やって出せたのがやりかけのPullRequest一件で、しかもwork in progress で残りお願いします… みたいな感じになってしまった。 で、今回新しいことをやるにあたって問題になったのは、次の点だと思った。 新しい登場人物の多さによる認知負荷の高さ パフォーマンス要件の厳しさ 最初からプロダクション前提の品質要求 ペアプロしてくれる人の確保 実は今の会社
エンジニア 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倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報量が低い記事 - mizchi's blog
