並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 235件

新着順 人気順

mizchiの検索結果1 - 40 件 / 235件

  • 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

      TypeScript入門以前ガイド - mizchi's blog
    • 手足がもがれる感覚 - mizchi's blog

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

        手足がもがれる感覚 - mizchi's blog
      • 春からはじめるモダンJavaScript / ES2015 - Qiita

        春ですね!人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ

          春からはじめるモダンJavaScript / ES2015 - Qiita
        • SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog

          最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ

            SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
          • なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか

            最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか!」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として

              なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
            • プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法

              プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js(ただし暫く何も足さない)がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ

                プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
              • フリーランス完走した感想 - mizchi's blog

                2 年ほど走ってみました。 Qiita の Increments を退職します - mizchi's blog からの 転職活動 https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa の結果 この記事は、自分の体験を書くことで、どういう人がフリーランスに向いてるか、というのをわかるように書いたつもりです。自分に近い属性ということで、ある程度プログラマとして経験を積んだ人向けです。 フリーランス辞める理由 フリーランスが嫌になったわけではないです。機会があればまたやりたいとも思っています。今回はフリーランスを続けるより良い選択肢があった、というだけの話です。 個人事業主を 2 年やって、消費税の徴収方式が変わるタイミングがあり、法人化してフリーランスの働き方を続けるか、個人事業主をやめるか、という 2 つの選択肢があり

                  フリーランス完走した感想 - mizchi's blog
                • 大規模 JavaScript その設計と実装と現実

                  実録 WordPress Twenty Sixteen のカスタマイズ | WordBench東京 2月勉強会 「みんなのテーマ開発」〜自分の好きな作り方...Akira Tachibana

                    大規模 JavaScript その設計と実装と現実
                  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

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

                      オブジェクト指向の呪いと、その避け方 - mizchi's blog
                    • 地方都市という地獄 あるいは関東圏の「私が住んでるところは田舎だよ(笑」が如何に残酷かについて - mizchi log

                      都会に住む人間は、その価値を過小評価している。というのが僕の持論だ。そしてそれは東京に6年住んでより強固になった。 都心住まいの価値とは何か - よそ行きの妄想 http://d.hatena.ne.jp/chnpk/20130115/1358204323 この記事の感想としては、およそ渋谷に特徴的な衛生問題が多いという事実には同情するとしても、常になにかしらの機会が与えられていることを無自覚だ、という点が地方の人間を刺激するだろう。 子供用の自転車が買えなかったとしても、買える距離に生きているのだ。さすがに子供用の自転車ぐらいは田舎でもみつかるが、嗜好品の類はそもそも手に入るかが怪しい。 今ではインターネットで緩和されたとはいえ、それを実際に目にする機会があるかという点において、それを好きになる機会すら与えられないかもしれない。 表題は、地方出身者を最も怒らせる一言である。 僕は、18歳

                        地方都市という地獄 あるいは関東圏の「私が住んでるところは田舎だよ(笑」が如何に残酷かについて - mizchi log
                      • やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog

                        と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ

                          やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
                        • 当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog

                          追記: 2019/11/12 2年経ったけど体験が悪化し続けた結果、 Firefox がこの記事の通りになりましたね… www.fxsitecompat.dev プッシュ通知、ネイティブアプリの機能郡をWebに持ち込むPWA技術の売りの一つだが、当初から懸念されていたとおり、非常にノイジーなものとなってしまっている。自分も気づけばあらゆるサイトの購読確認を、無意識で拒否を押すようになってしまった。 hagex.hatenadiary.jp 少し前の記事。最近はどこかで wordpress のプラグインになったのか、目にする機会が非常に多くなり、非常にストレスフル。最初は技術的な目新しさからか、ある程度容認していたが、さすがにこの状況が悪化する一方で、本気でやばいんじゃないかと思っている。とくに初見のブログの記事を読む前に、購読確認が出るのが最悪の体験となっている。 そもそもプッシュ配信とは

                            当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog
                          • プログラマという現代の傭兵 - mizchi's blog

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

                              プログラマという現代の傭兵 - mizchi's blog
                            • 睡眠障害で辛い - mizchi's blog

                              一緒に働いたことがある人は知ってると思うけど、自分は尋常じゃなく朝に弱い。 で、自分でもさすがに酷いと思っており、様々な努力をしたが改善せず、結局睡眠科をうけて睡眠障害だと診断された。 自分がそうだと疑った理由は 睡眠障害らしきものとわたしの20年間振り返りメモ - 青いの のおかげ。inoaoさんとは違うけど、自分は 睡眠相後退症候群 DSPSに罹患して9時5時生活を送ることは、毎日6時間の時差ぼけを体験しているようなものである。患者は週日には数時間しか眠ることができないので、週末には午後まで眠って睡眠時間を補うことがよくある。週末によく眠ったり、普段昼寝をしたりすることで、DSPS患者は昼間の眠気から解放されるが、遅い睡眠相はそのまま続く。 DSPS患者は、極端な夜型の傾向がある。彼らは、夜が最も頭が冴えていて、物事がうまくでき、創造力にも溢れていると感じる。彼らは単純に早く眠ることが

                                睡眠障害で辛い - mizchi's blog
                              • 世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog

                                2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか?基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし

                                  世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
                                • 20 年代のフロントエンド.md

                                  Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. 明日の下書き これはなに 高円寺.dev #3 用の資料 https://koenji.connpass.com/event/160886/ フロントエンド専門じゃない人向けの、フロントエンドの最先端〜やや未来の話です このレイヤーでは Node.js を使うべき/使うと強いという部分がありますが、他言語を否定しているわけではありません。むしろ他言語でこのアーキテクチャを模倣してほしいという話です。 10 年代のフロントエンドのポストモーテム 10 年代まとめ IE が死ななかったので各種ポリフィル、メタ言語からのトランスパイルが発達。しかしモダンとレガシーの乖離が深刻に。 node と npm エコシステムの成立

                                    20 年代のフロントエンド.md
                                  • 2020 年、 React 軸で学ぶべき技術 - mizchi's blog

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

                                      2020 年、 React 軸で学ぶべき技術 - mizchi's blog
                                    • フロントエンドの負債と向き合う - mizchi's blog

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

                                        フロントエンドの負債と向き合う - mizchi's blog
                                      • Swift ファーストインプレッション - mizchi's blog

                                        とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV

                                          Swift ファーストインプレッション - mizchi's blog
                                        • 読まれるテキストは読者へのおもてなしの構造を持っている - mizchi's blog

                                          大学生だった当時、梅田望夫の本を読んではてなにやってきた僕は、ブログ論壇への憧れだけがあって、技術者にもなれず、時流のテーマに対して書くべきテーマを持たず、ただ実家の宗教に対する恨みだけを書き綴っていた。 もちろん、そんなものを好きこのんで読む人はいなくて、ただ虚無へとテキストを放り込んでいたのだけだど、いつからか、ある程度パターンを獲得して、その真似をするようになって、成功失敗を繰り返して、それなりにPDCAを回してきたと思う。思えば、その過程でいろんな人のヘイトを買った気がする。 人間のテキストの読み方、その反応、というのはパターンを、いくつか書き起こしてみる。 読者は、ファーストビューのレイアウトで、読む読まないを決める タイトルは記事の印象の5割 章タイトルが残りの半分 本文はほとんど読み飛ばされる 書き手としては単語の印象の連なりでイメージを形成することになる 段落が均等に分割さ

                                            読まれるテキストは読者へのおもてなしの構造を持っている - mizchi's blog
                                          • ゲーマーのエンジニアが転職先としてソーシャルゲーム業界を選ばない理由 - mizchi's blog

                                            今回の転職にあたって、各方面から「なんでゲーム業界にいかないの?」と何度も訊かれたので、書いておく。 僕のキャリアはソーシャルゲーム業界から始まって、教育の会社にいって、次はxxxだ。転職先に関しては後日。 僕はそもそもスーパーファミコン時代にスクエニ黄金期の洗礼を受けた古い気質のゲーマーで、ソーシャルゲームを一切楽しめない人間で、ソーシャルゲームに開発として関わった人間でもある。バイアスが掛かっているのは認める。 古巣がどうこうって問題ではなくて、業界全体の問題なので、そこらへんは誤解しないように。 ソーシャルゲーム業界 今のソーシャルゲーム業界の開発現場は、開発の現場が「面白いゲームを作ろう」というモチベーションにはなりにくい。 感覚として、ソーシャルゲームってのは「課金させる場」を作ることであって、面白いゲームを作ることはあまりフォーカスされない。 それを言えばコンシューマだって売り

                                              ゲーマーのエンジニアが転職先としてソーシャルゲーム業界を選ばない理由 - mizchi's blog
                                            • いかにしてJavaScriptを教えるか - mizchi's blog

                                              経緯 ドワンゴ様から恵贈頂いた。 高校生からはじめる プログラミング 作者: 吉村総一郎出版社/メーカー: KADOKAWA発売日: 2017/04/14メディア: 単行本この商品を含むブログを見る …読んでみたけど、HTML/CSS/JS の初歩的な部分を、初学者にやらせるとこうなる、という素朴な世界観で、CSSフレームワークもJSライブラリも出てこない。いや、出せと言ってるわけじゃない。理解せずにフレームワークを使う習慣がつくと、スクリプトキディ的な振る舞いによっていくし、教える側としても、変数が大きくなってコントロールできないのが問題だろう。 じゃあ基礎を抑えたとして、この先どう教えるといいんだろうな、というのは、たしかに自分も前から考えてはいて、それを書いてみる。 この文章のターゲット JavaScriptを教える人、またはポインタがあれば自学できる中級者以上 追記: すべての初学

                                                いかにしてJavaScriptを教えるか - mizchi's blog
                                              • あなたがReactを使うべき理由 - mizchi's blog

                                                最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか? 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue

                                                  あなたがReactを使うべき理由 - mizchi's blog
                                                • フロントエンドへの複雑化について、一つの視点 - mizchi's blog

                                                  これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記

                                                    フロントエンドへの複雑化について、一つの視点 - mizchi's blog
                                                  • ウェブエンジニアの生存戦略 - mizchi's blog

                                                    最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。

                                                      ウェブエンジニアの生存戦略 - mizchi's blog
                                                    • プログラミングを学ぶにあたって詰まったことと、そこから学んだこと - 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
                                                      • 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

                                                          Webpack の考え方について - mizchi's blog
                                                        • スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog

                                                          日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。 キラーアプリの出現と技術的イノベーションに相関あるかと言われたらあるとは思うけど枯れた技術の水平思考的な余地も十分あるんでキラーアプリが必ずしも技術的なイノベーションを果たしている必要はない。ただし技術優位がない場合は企画レベルで制限かかるので、それを許容するかどうかという話— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた

                                                            スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog
                                                          • 「仕事にも支障が」 Twitterを凍結され、日本法人を訪れて抗議したエンジニアに聞く

                                                            「身に覚えがないのに、Twitterアカウントを凍結された」と訴えるユーザーが増えている。凍結されたことを不当と感じ、日本法人を訪れて抗議したエンジニアのmizchiさんに経緯を聞いた。 「身に覚えがないのに、Twitterアカウントを凍結された」――こう訴えるユーザーが増えている。アカウントを凍結されると、情報収集や友人とのやりとりがしづらくなる上、Twitterを仕事で使っている場合は、仕事先との交流にも支障が出るなど死活問題にもなる。 フリーランスエンジニアのmizchiさんは9月27日、Twitterアカウントが突然凍結され、仕事先との連絡も取れなくなって途方に暮れたという。他にもアカウントが凍結されて困っているエンジニアがおり、「Twitterに話を聞きたい」と、都内にあるTwitter Japanのオフィスを電撃訪問した。 mizchiさんに、凍結の経緯や、Twitter Ja

                                                              「仕事にも支障が」 Twitterを凍結され、日本法人を訪れて抗議したエンジニアに聞く
                                                            • Google Chrome上でマイクから録音した声をリアルタイムで文字に書き起こしてくれる「The Recording Studio」

                                                              「Recording Studio」は、Chromeに対応している音声認識API「SpeechRecognition API」を利用してマイクから録音した声を音声認識によってその場で文字に起こしてくれるウェブツールです。オンラインのブラウザ上で動作するのでダウンロードやインストールは不要で、開発したみずちさんが無料で公開しています。 Recording Studio https://recording-studio.netlify.com/ ブラウザでマイク入力から書き起こしを行うツールを作った - mizchi's blog https://mizchi.hatenablog.com/entry/2019/01/20/203241 Googleは音声ファイルをAIが認識して文字にしてくれる「Cloud Speech-to-Text」という有料サービスを提供しています。Google Clo

                                                                Google Chrome上でマイクから録音した声をリアルタイムで文字に書き起こしてくれる「The Recording Studio」
                                                              • エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog

                                                                この記事は退職者アドベントカレンダーの12日目です。 adventar.org 経歴としては、新卒で設立してすぐのゲーム会社 => 小規模教育系ベンチャー => Incements(Qiita) => フリーランス。 今年で29歳、20代で3回退職しました。20代のうちは冒険してベンチャー企業で働いてみよう、と思ってたのですが、結局29を目前にフリーランスになってしまいました。 ベンチャーで働くこと ベンチャーで働くのはリスクを取るということ。一番言いたいのは、ストックオプションもたずにベンチャーやるな、ストックオプションも確実に換金できるわけじゃない、ということ。上場するときに行使するか、バイアウト時に買い取ってもらわないといけません。 また、ストックオプションの期待だけ給与は下がるので、他の会社で同じことをやるのに比べて、 -100~-150万ぐらいの相場です。少数精鋭志向で最初からじ

                                                                  エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog
                                                                • フロントエンドを楽にするために

                                                                  フロントエンドを楽にするために Qiitaを支えたい技術 at 時雨祭 About HN: mizchi Qiitaの方からきました(入社半年たったらしい) Reactオジサンはそろそろ飽きてきた Angularに興味が無いのでこっちにきた 最近の業務 Kobito for Windows Closedβ中: もうちょい待ってろ お前らウェブエンジニアはWindows使わないのでβユーザー集めにくいんじゃ 省力モード 一昨日がClosedβリリースだったんで察してくれ!!! ついさっきまでバグフィックス用のビルド作ってた Qiitaを支える技術? 4ヶ月ほどほぼソロ作業 正直カウボーイぎみ OSSでドキュメントガンガン書いてカバー(したい) 業務から派生したOSS mizchi/arda Flux フレームワーク mizchi/stone-skin IndexedDb ラッパー mizch

                                                                    フロントエンドを楽にするために
                                                                  • スイッチの入れ方 - mizchi's blog

                                                                    自己分析 どうやったらスイッチが入るか コーヒー飲む 作業机に着席する エディタが開いてある 次にやることが自明 => やる 集中継続の仕方 取り組んでる対象が面白い いい音楽がある 通すべきテストがあったり、タスクが明確だったりで、なんらかのリズムがある 課題が小さい(小さく分割してあるという状態) スイッチの切れ方 コンテキストスイッチのタイミングで開発環境の再セットアップしてると萎えてくる 対象がそもそも気が重くて逃げる(タスクが分割されていない)​ Twitter で気になる話題が流れてきて別のスイッチが入ってしまう 定期的に腰の調子が気になる 定期的に肩の調子が気になる 定期的に首の調子が気になる 音楽 飽きっぽいので常に新しい音楽がほしい 昔はメタルやプログレッシブ・ロックが好きだったが、最近は作業を害さない程度のエレクトロニカに寄ってる Spotify はいい感じなのだが、た

                                                                      スイッチの入れ方 - mizchi's blog
                                                                    • すべてのプログラマが機械学習を受け入れる準備をする時代になった - mizchi's blog

                                                                      という予感がしたので書く。正確に言うと機械学習の成果としての訓練モデルを。 まず事前に前置きしておくと、僕は機械学習をほとんど抑えていない。トレンドだけ追ってる。 大学生の時にニューラルネットワークを実装してみてフ~ンって言ってた程度に知識しかなくて、ディープラーニングが流行る前だから、「バックプロパゲーションってややこしかったけど、今は自動でモデルの最適化いい感じにやってくれるんでしょ?」ぐらいの雑な理解しかない。(この時点で怪しい) で、今はフロントエンドやってて、ここは機械学習は縁遠いように思えるかもしれないだろうけど、最近のGoogleはなんとブラウザで tensorflow を動かすのに情熱を注いでいる。 で、こんなのが Hacker News で流れてきた。 medium.com とりあえず試した。デモをそのままデプロイした。 PoseNet - Camera Feed Dem

                                                                        すべてのプログラマが機械学習を受け入れる準備をする時代になった - mizchi's blog
                                                                      • 最近のフロントエンドのエディタ事情 - mizchi's blog

                                                                        これは、個人でどんなエディタを使うべきか、ではなく、「チームとして」新しいものを採用するとき、あるツールがエディタ横断で便利かどうかを考える必要がある。 自分個人としては、基本はAtomを使って、TypeScriptを書くときだけVS Code を使っている。ターミナルでは Vim。 環境でエディタを選ぶ 最近の新規プロジェクトでは、とくにブロッカーがなければ TypeScript を使っていいと思う。TypeScript を使うなら当然 VS Code を使うことになる。Atom や Vim でもいいが、TypeScriptのエディタとしては、流石に完成度が頭一つ抜けてる。JavaならJetBrains 的なノリで、TSならVSCode、そういうものと思ったほうが楽。 TS以外なら、エディタはなんでもいいが、ある程度流行ってるものでないとエコシステムに追いついてくれない。 prettie

                                                                          最近のフロントエンドのエディタ事情 - mizchi's blog
                                                                        • 自分でコードを書きながらブロックチェーンを勉強した - mizchi's blog

                                                                          マネーゲームとしての仮想通貨は興味はないのだが、技術的に興味があって自分で簡単なコードを写経しながら勉強した。 定義 ブロックチェーンの実体はブロックを繋いだリスト構造 ブロックはいくつかの入力値(生成日時など)と、自分自身のハッシュを持っている 前のブロックのハッシュ値と、入力値を元に自分自身のハッシュが決まる。その手順は公開されている。 要はハッシュ値とそのメタデータが連続するただの配列なりの LinkedList。面白いのはここから。 ネットワークに参加するそれぞれが任意に新しいブロックを追加することができる ブロックチェーンは検証結果が正しく、より長いものが信頼される なのでビットコインみたいな仮想通貨は、生成コストが重く、検証コストが軽いものが好まれる。 他のネットワーク参加者からブロックチェーンの更新を受け取った時、手元のブロックチェーンとそれを比較し、より長いものを自分のブロ

                                                                            自分でコードを書きながらブロックチェーンを勉強した - mizchi's blog
                                                                          • 仕事とは、プログラミングとは - mizchi's blog

                                                                            これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら

                                                                              仕事とは、プログラミングとは - mizchi's blog
                                                                            • Qiita の Increments を退職します - mizchi's blog

                                                                              4月からフリーランス。直近半年の仕事は埋まってるけど、パイプ作っときたいとかあれば mizchi2w@gmail.com までメールください。 なんでやめるの? 要約: 自分のスキルの、ベンチャー企業の社員としてスキルミスマッチ フロントエンドの、とくにSPAで高速で堅牢なアプリを作る、という自分のスキルセットを振り返ると、「需要はあって必要なことには必要だが、どうしても瞬間風速が高いそのタイミングを超えると扱いに困る」という人材適正があると認識しており、前職のQuipperから引き続き2社連続で、「そのために入った最初のプロジェクトが終わると、やや手持ち無沙汰になる」という状態になっていました。 とくにスタートアップのような、予算が厳しい上にピボットする可能性ある現場だと、自分のスキルが活かせないフェーズがある、というのが、会社にとっても、個人のモチベーションとして厳しいものがありました

                                                                                Qiita の Increments を退職します - mizchi's blog
                                                                              • 「フロントエンド領域」を再定義する

                                                                                Frontend Study #1 訂正: 最後のzennの記事のリンク先は、正しくは https://zenn.dev/mizchi/articles/c638f1b3b0cd239d3eea です

                                                                                  「フロントエンド領域」を再定義する
                                                                                • クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog

                                                                                  前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として

                                                                                    クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog