プログラミングを学ぶにあたって詰まったことと、そこから学んだこと - mizchi's blog
toyokeizai.net satoru-takeuchi.hatenablog.com 全然レイヤーが違うが、自分が何に悩んで、どういう風に理解したか、思い出しながら書き出してみる。 プログラミング歴 20歳からなので、現時点で10年ぐらいだが、中学生の時ちょっと触ったことがあった。 14 歳: 病気で入院したときに暇すぎて、2 週間ほど VBA を触った 大学 1 年: 大学の選択科目で Java, 夏休みに Python と Ubuntu の独習 大学 3 年: Python で自然言語処理のバイト 大学 4 年: Android アプリを作るバイト、就活ポートフォリオとして node/Websocket で MMO 一社目: Unity, ActionScript, Haskell, JavaScript 以降~: JavaScript/CoffeeScript/TypeScri
プログラマという現代の傭兵 - mizchi's blog
エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。
今年お世話になった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 する。テザリング環境
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
クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog
前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し
当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog
追記: 2019/11/12 2年経ったけど体験が悪化し続けた結果、 Firefox がこの記事の通りになりましたね… www.fxsitecompat.dev プッシュ通知、ネイティブアプリの機能郡をWebに持ち込むPWA技術の売りの一つだが、当初から懸念されていたとおり、非常にノイジーなものとなってしまっている。自分も気づけばあらゆるサイトの購読確認を、無意識で拒否を押すようになってしまった。 hagex.hatenadiary.jp 少し前の記事。最近はどこかで wordpress のプラグインになったのか、目にする機会が非常に多くなり、非常にストレスフル。最初は技術的な目新しさからか、ある程度容認していたが、さすがにこの状況が悪化する一方で、本気でやばいんじゃないかと思っている。とくに初見のブログの記事を読む前に、購読確認が出るのが最悪の体験となっている。 そもそもプッシュ配信とは
本を書くためのアウトラインエディタを作ってる - mizchi's blog
少し前からアウトラインエディタを作ってる。 こんなの (画面は開発中のものです) ファイルツリー 複数シート同時編集 ファイルツリーUIというのをスクラッチで初めて作ってみたんだけど、「当然こう動いて欲しいよな」というヒューリスティックな挙動をたくさん作るハメになってて学びがある。 なぜ作ったか 技術書を書いて Kindle Direct Publishing で販売しようと思って、Macで売れてるアウトラインエディタを一通り試したんだけど、惜しい物が多くて、個人的にしっくり馴染むものがなかった。なので、技術書を書く前に、自分が本を書くために必要なツールを作るところから始めることにした。 作家・藤井太洋に聞く 「小説を書くためのツール、Scrivener」 - DOTPLACE を読んで、その辺のアプリに対する感覚を自分でも意識して作ってる。Scrivener は wysysig なんで自
さよなら CoffeeScript - mizchi's blog
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
仕事とは、プログラミングとは - mizchi's blog
これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら
小さいモジュールに分割しまくる時の気持ち - mizchi's blog
最近、業務と趣味の副産物で、一日に1~2個のnpmモジュールを作っている。基本的にGithubで公開している。 node界でそういうことをしているのは主に substack (James Halliday) 氏だ。 趣味と仕事の横断 自分は基本的に、仕事で使うテクノロジーと趣味で使うテクノロジーを合わせていることが多い。会社ではツールを作っていても家では同じテクノロジースタックでゲーム作ってたりする。 最近だと mizchi-sandbox/ar2 がそれに該当する 会社のコード、自分はあんまり家に帰ってまで触りたいという気持ちがあんまりないんだけど、どうせ家でもコード書いてて、業務中のコードを切り出してOSS化してあると家で触るモチベーションになって便利。 趣味でノウハウが溜めて、業務にフィードバックするというループに載せることで、26歳としてもそこまで高くない社会人としての自覚をコーデ
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
Angularが嫌い - mizchi's blog
僕は本当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう本当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが本当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン
昔ながらの「片手間に書く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
タッチタイピング矯正器としての無刻印キーボードが良いという話と、無刻印の辛い点 - mizchi's blog
これみて思い出した。 私はブラインドタッチが出来ない - はてな村定点観測所 僕も昔は右手のホームポジションが右に一個ずれてた我流で、たまに手元見ながらタイピングしちゃう癖があったんだけど、HHKB無刻印にしたら綺麗なフォームになってたので、ちゃんとタッチタイピングしたい人はHHKB無刻印使うといいと思う。 PFU Happy Hacking Keyboard Professional2 墨/無刻印 英語配列 USBキーボード 静電容量無接点 UNIX配列 WINDOWS/MAC両対応 ブラック PD-KB400BN 出版社/メーカー: PFU発売日: 2006/03/23メディア: Personal Computers クリック: 192回この商品を含むブログ (23件) を見る HHKB無刻印炭、たしか前職で @shishi4tw が使ってるのみてあーこれカッコイイと思って買ったんだけ
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
