mizchi君の記事を見て、だいぶ感想が違ったので書くことにした。 なお、僕はTypeScript信者であることを踏まえてこの記事を読んでほしい。 あと、最初はまじめに記事にしようと思ったけどダルくなってきたのでメモをそのまま投げる。 TypeScriptより良い型推論 Flowパイセンの一番偉いところはTypeScriptより型推論が強いところだと思った。# /* @flow */ function foo(x) { return x * 10; } foo('Hello, world!'); 関数foo内部のxは、* 演算子を利用しているのでnumberであると推論している。 これが実際の利用箇所でstringを引数にしているので怒ってくれるわけだ。偉いな! Flow is a static type checkerと謳っているとおり、完全にpure JavaScriptで書かれている
Code Faster.Tired of having to run your code to find bugs? Flow identifies problems as you code. Stop wasting your time guessing and checking. Code Smarter.It's hard to build smart tools for dynamic languages like JavaScript. Flow understands your code and makes its knowledge available, enabling other smart tools to be built on top of Flow. Code Confidently.Making major changes to large codebases
ネットベンチャーに「企画しかできない人」はいらないと思う。 特に、文系でプログラム経験がなくて企画しかやってきてない人は、論理的思考能力がない人がめちゃくちゃ多い。大企業ではそれでいいけど、人も時間も予算も無い状況だとコミュニケーションロスとオーバーヘッドがでかすぎる。条件をつめたり、ロジックを埋める作業が出来ない。条件漏れとかめちゃくちゃ多い。デバイスの仕様制限すら分かってない人も多い。 GPSがすごい正確で一瞬で位置を取得できることを前提にしたアプリの企画とか、すべてのスマートフォンがiBeaconが動くことを前提にした企画とか、顔認識が100%であることを前提にしたアプリとか、プッシュ通知しまくるクソアプリとか、アプリの更新とデータ更新の切り分けが分かってないとか、お前の状態遷移を修正している時間のほうが時間が掛かる企画とか、もう、いやだ。それで、企画の発想が飛びぬけて面白い人なら、
今年の3月に、米国のオースティンで開催されたSxSW2014で発表されたkinoma create。 Indiegogoのクラウドファンディングで目標額を大幅達成したデバイスが、ついに我が家へやって来ました。 ■Kinoma Create とは? 近年、hueやNestなどwifiを介してインターネットへ繋がる家電が増えてきました。ざっくりな話だと、"何かデバイスとインターネットへ繋がる"ということがInternet of Things(IoT)と呼ばれています。(ユビキタスとどう違うの?とか、IoTの深くて厳密な話は是非ラーメンでも食べながら語りたいです) (3月の発表前からSxSWのデモ制作のために、Kinoma Createを触らせてもらってました。) Kinoma Createは、そんなIoTプロダクトを開発するためのデバイスです。 Raspberry Piも似たようにインターネッ
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
怖話を作っていてインフラを含めた設計で迷っている箇所がいくつか溜まってきたのですが、もしいい方法があったら教えて欲しいという点をブログに書いていきたいと思います。 前提 エンジニアは僕一人だけなので極力手間を減らしたい怖話は広告モデルなのでアクセス辺りの収益が低い。なるべく安く(できれば無料に)したいデザイナーやインターンの人も開発するので複雑にしたくない(例えば怖話をローカルで開発する環境を作るのにredisとかfluentdとかいろんなサーバープロセスを立てないと画面が確認できないとか) 画像の置き場所に困る怖話はアクセス負荷的にappサーバーの2台目が必要かな?ぐらいの状態にあります。 appサーバーが複数台になると画像などのアップロードされるファイルの置き場を共通にする必要が出る。 一度はappサーバー2台でS3 + CloudFrontにしましたが、転送料が高いからappサーバー
11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。 現実にアカデミックで起きていること WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く