オートチェス入門 - mizchi's blog
今自分の中で熱いゲーム、それが Dota Autochess。この熱はスプラトゥーン以来。 dota auto chess が張り切った麻雀みたいで面白い - mizchi's blog 僕自身の最高レートはナイト 8 で、まったく高レートプレーヤーではありませんが、GW を溶かして最初に学ぶべきことは一通り覚えたつもりです。日本語の記事が少なく、初心者がなにを知るべきか網羅的な資料がなかったので、自分で書くことにしました。 最初に: 負けても気にしない！ このゲームは勝敗によってレートがついていますが、現在の野良マッチではレートが考慮されていません。一人やフレンドと一緒に潜るだけなら、どんなに下がっても大丈夫です。 ビジョップ以上の高レートになるとレート専用部屋を立ててプレーする文化がありますが、最初は存在を忘れて大丈夫です。 このゲームでまず大事なことは、自分が取れる選択肢の多さです。
いかにしてJavaScriptを教えるか - mizchi's blog
経緯 ドワンゴ様から恵贈頂いた。 高校生からはじめる プログラミング 作者: 吉村総一郎出版社/メーカー: KADOKAWA発売日: 2017/04/14メディア: 単行本この商品を含むブログを見る …読んでみたけど、HTML/CSS/JS の初歩的な部分を、初学者にやらせるとこうなる、という素朴な世界観で、CSSフレームワークもJSライブラリも出てこない。いや、出せと言ってるわけじゃない。理解せずにフレームワークを使う習慣がつくと、スクリプトキディ的な振る舞いによっていくし、教える側としても、変数が大きくなってコントロールできないのが問題だろう。 じゃあ基礎を抑えたとして、この先どう教えるといいんだろうな、というのは、たしかに自分も前から考えてはいて、それを書いてみる。 この文章のターゲット JavaScriptを教える人、またはポインタがあれば自学できる中級者以上 追記: すべての初学
今、SPA/ReactNativeにとっての必要な PaaS を考える - mizchi's blog
当方ボーカル、フルスタックPaaS募集 ほしいもののコンセプト SPA職人としてそこに全力を尽くしたいので、それ以外を全部やってほしい とはいえストレージへのアクセスはAWS Lambda/Cloud Function等を介してちゃんとしたコントロールをしたい プロトタイピング時は何も考えずにORMを叩いていたい 運用フェーズでは金を払ってスケールしたい。とはいえボトルネックは常に監視したい。極端にやばいスケールサイズはどうせ人を雇うのでその先は考えなくていい。 より細かい要求 認証はPaaS側が全部持ってほしい JSONSchema でクライアント/サーバーサイドのアクセス制限を定義したい サーバーはフルマネージド Lambda/CloudFunction で関数単位でパフォーマンス監視/障害検知 ローカルで本番と同じ構成が建てられる アセットは勝手にCDNに投げといてほしい バックエン
「最初に学ぶべきプログラミング言語」 - mizchi's blog
初心者に最初にぶち当たるのが『環境構築』という大きな壁なんですよね。そこで何割の人がスタートラインにすら立てずに挫折するだろうか…5割は超えるかもしれない…— ビタワン@社畜ちゃん②巻2/27発売予定 (@vitaone_) 2017年2月5日 環境構築が壁で、楽しい（かどうかは人によるが）プログラミングにたどり着けなくてモチベーションが、というのはわかるが、環境構築を経験してその辺の洞察身につけてもらわないと現場で困る、というような話もあって、二ヶ月速習でiOSエンジニア、みたいな講習はその視点欠けててダメ— 現場の声 (@mizchi) 2017年2月5日 よほどよくできた環境でもない限り、何作ろうとしても初動でうまいこといくケースが少ないので、それを解決するための勘と体力は絶対に必要なんだよなー— 現場の声 (@mizchi) 2017年2月5日 僕も完全独学でプログラミング始めたの
さよなら CoffeeScript - mizchi's blog
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
