タグ

ブックマーク / mizchi.hatenablog.com (22)

  • Edge 終了に寄せて - mizchi's blog

    初報を聞いたとき、描画系だけ blink に入れ替えて処理系は V8 使わず ChakraCore などに入れ替えるのかな、と思っていたが、どうも V8、というか chromium 一式を使うらしい。 正直に言って、Edge が死ぬことに、そこまで強く思うところはない。Edge は内部的に自身のベンダープレフィックスで webkit と名乗るぐらい (標準ではなく) webkit との互換性の意識が高いので、お前自分のことを webkit だと思ってるもんな、みたいな気持ちがあった。 webkit みたいなブラウザが消えて、webkit 後継のブラウザをベースに作り直される。開発者として追うべきは、個別の実装ではなく依然として標準仕様であって、それだけの話。 リリースサイクル 僕が思うに、 MS の抱えていた真の問題は、Windows に紐付けられたリリースサイクルとサポートにあって、Wi

    Edge 終了に寄せて - mizchi's blog
  • 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
  • 最近のフロントエンドのエディタ事情 - 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

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

    すべてのプログラマが機械学習を受け入れる準備をする時代になった - mizchi's blog
    nibushibu
    nibushibu 2018/05/09
  • フロントエンドの負債と向き合う - mizchi's blog

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

    フロントエンドの負債と向き合う - mizchi's blog
  • エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog

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

    エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog
    nibushibu
    nibushibu 2017/12/13
  • 当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog

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

    当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog
  • 自分でコードを書きながらブロックチェーンを勉強した - mizchi's blog

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

    自分でコードを書きながらブロックチェーンを勉強した - mizchi's blog
  • いかにしてJavaScriptを教えるか - mizchi's blog

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

    いかにしてJavaScriptを教えるか - mizchi's blog
  • 「最初に学ぶべきプログラミング言語」 - mizchi's blog

    初心者に最初にぶち当たるのが『環境構築』という大きな壁なんですよね。そこで何割の人がスタートラインにすら立てずに挫折するだろうか…5割は超えるかもしれない…— ビタワン@社畜ちゃん②巻2/27発売予定 (@vitaone_) 2017年2月5日 環境構築が壁で、楽しい(かどうかは人によるが)プログラミングにたどり着けなくてモチベーションが、というのはわかるが、環境構築を経験してその辺の洞察身につけてもらわないと現場で困る、というような話もあって、二ヶ月速習でiOSエンジニア、みたいな講習はその視点欠けててダメ— 現場の声 (@mizchi) 2017年2月5日 よほどよくできた環境でもない限り、何作ろうとしても初動でうまいこといくケースが少ないので、それを解決するための勘と体力は絶対に必要なんだよなー— 現場の声 (@mizchi) 2017年2月5日 僕も完全独学でプログラミング始めたの

    「最初に学ぶべきプログラミング言語」 - mizchi's blog
    nibushibu
    nibushibu 2017/02/06
    自力で進める(面倒臭さ・辛さを乗り越えるくらいの楽しさを実感する)までの助走さえうまく行けば、勉強の対象は何でも(何から始めても)良いっていうのは、プログラミング以外にも言える思う。
  • 最近のフロントエンドの変化とビルドツールについて - mizchi's blog

    界隈の雑な会話です。注意点として、フロントエンドガチ勢寄りの方面なので、一般的な感覚とは乖離してる可能性があります。 基的には http://www.s-arcana.co.jp/blog/2016/12/12/3438 や kikuchi1201.hateblo.jp を念頭に。 動き早いって言われるフロントエンド界隈、この1年何も進んでないからな— 現場の声 (@mizchi) 2016年12月14日 今年のフロントエンドの統括、es2016でしょぼかったので皆es2015+ みたいなノリが抜けなかったのと、redux以外のfluxが脱落したのと、angular2+今年も出なかったねというのと、たぶん eslint の採用が増えてそう(肌感)のと、flowの採用が増えたぐらい— 現場の声 (@mizchi) 2016年12月14日 実際browserify/webpackは先行実装だ

    最近のフロントエンドの変化とビルドツールについて - mizchi's blog
  • 本を書くためのアウトラインエディタを作ってる - mizchi's blog

    少し前からアウトラインエディタを作ってる。 こんなの (画面は開発中のものです) ファイルツリー 複数シート同時編集 ファイルツリーUIというのをスクラッチで初めて作ってみたんだけど、「当然こう動いて欲しいよな」というヒューリスティックな挙動をたくさん作るハメになってて学びがある。 なぜ作ったか 技術書を書いて Kindle Direct Publishing で販売しようと思って、Macで売れてるアウトラインエディタを一通り試したんだけど、惜しい物が多くて、個人的にしっくり馴染むものがなかった。なので、技術書を書く前に、自分がを書くために必要なツールを作るところから始めることにした。 作家・藤井太洋に聞く 「小説を書くためのツール、Scrivener」 - DOTPLACE を読んで、その辺のアプリに対する感覚を自分でも意識して作ってる。Scrivener は wysysig なんで自

    本を書くためのアウトラインエディタを作ってる - mizchi's blog
    nibushibu
    nibushibu 2016/08/23
  • JavaScript の難しさとは何か - mizchi's blog

    JSの学習コスト高いかという問題、言語のコア自体はシンプルだが細かい == とかのハマりどころが多いのと、言語機能自体がシンプルすぎてエコシステムを理解してモジュールを扱うところに辿り着くのが大変、という問題に分類できる— 現場の声 (@mizchi) 2016年8月15日 jQueryの学習コストは、DOMはツリーなんだよという概念の獲得と DOM API の抽象サブセットを覚えるというだけで、2016年現在は jQueryによるUI設計論(ここが高まるとBackboneとかその辺)みたいなものに手を出す必要がないなら、そんなでもないんだろうな— 現場の声 (@mizchi) 2016年8月15日 Reactが難しいと言われる場合、仮想DOMという概念がやや難しい、というか非常にCS的なアルゴリズムとデータ構造が背景にあって、その上で単純なトップレベルAPIとアルゴリズムを理解してないと

    JavaScript の難しさとは何か - mizchi's blog
  • フロントエンドへの複雑化について、一つの視点 - mizchi's blog

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

    フロントエンドへの複雑化について、一つの視点 - mizchi's blog
    nibushibu
    nibushibu 2016/04/14
  • さよなら CoffeeScript - mizchi's blog

    prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5

    さよなら CoffeeScript - mizchi's blog
  • スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog

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

    スターエンジニアはキラーアプリを生み出すのか? - mizchi's blog
  • 俺専用ReactのSVGスケッチ環境作った - mizchi's blog

    https://github.com/mizchi/sketch-board 自分は簡単な図形の描画にSVGの手書きは全然アリだと思っていて、Jadeテンプレートで書きなぐることができるようにした。 AtomShellで作った

    俺専用ReactのSVGスケッチ環境作った - 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
  • 「CoffeeScriptのリファクタリング」の実践とレビュー - mizchi's blog

    CoffeeScriptのリファクタリング - ワザノバ | wazanova CoffeeScriptのリファクタリングと聞いたので、いてもたってもいられなくなった。まず、お題の結果を見ずにやってみる。 これが元のコード $(document).ready -> photoHTML = (photo) => "<li> <a id='photo_#{photo.id}' href='#{photo.url}'> <img src='#{photo.url}' alt='#{photo.alt}' /> </a> </li>" $.ajax url: '/photos' type: 'GET' contentType: 'application/json' onSuccess: (response) => for photo in response.photos node = $(phot

    「CoffeeScriptのリファクタリング」の実践とレビュー - mizchi's blog