IPv6対応する必要があるのはiOSだけじゃない
驚いた所を太字にします。 動機 Google Developer Summit 2016:Android 知らなかったこと驚いたことメモで聞いた話はあったのですが具体的にはよくわかっていない部分などがとても多いので1つずつ何が必要か整理したいと思います。 http://qiita.com/takahirom/items/aa3cb6ff69958128e958 とりあえず今回はマルチウインドウです(通知とか他のものも調べていきたい) マルチウインドウ 画面を2つに分割したりできる機能です。何が必要なのか見ていきましょう。 Activityが他のアプリからstartActivityForResultで起動する可能性がある場合、マルチウインドウに対応する必要がある android:resizeableActivity="false"にしようが、画面回転に対応させないようにしようが、マルチウイン
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Apache Hadoop (以下Hadoop) が登場して10年が経ち、その間にHadoopとそのエコシステムも誰も予想できないほど大きく進化してきた。当初バッチ処理専用と言われていたHadoopも、今やSQLエンジンや機械学習など様々なアプリケーションを動作させることができる汎用基盤となっている。しかし、「Hadoopとは何か?」「Hadoop入門」のような初心者向け記事は未だに初期の頃のHadoopを想定した説明しかしておらず、現在のHadoopについて正しい情報を伝えていないように見える。一方、「最新のHadoop」といった類の
機械学習の分類の話を、主に決定境界と損失関数の観点から整理してみました。 とはいっても、k-NNとか損失関数関係ないのもいます。 最初ははてなブログに書こうとしたのですが、数式を埋め込むのが辛かったのでjupyter notebookにしました。 github.com [追記] githubだと日本語を含む数式のレンダーが壊れるので、nbviewerの方がいいかもしれません。 https://nbviewer.jupyter.org/github/chezou/notebooks/blob/master/classification.ipynb [/追記] パーセプトロンが見直されたのはなんでだっけ、SVMってどういう位置づけだっけ、というのを確認できればなぁと思っています。 多層パーセプトロンまでに至るところの流れがうまく伝わればなぁと思っています。 間違いなどがあれば、是非ご指摘いただ
parsetime という時刻文字列をいい感じに parse する Go のライブラリを書きました。 Example 使用例です。 package main import ( "fmt" "github.com/tkuchiki/parsetime" "log" ) func main() { p, err := parsetime.NewParseTime() if err != nil { log.Fatal(err) } t, err2 := p.Parse("2016-01-02T03:04:05") if err2 != nil { log.Fatal(err) } // Local timezone: JST // 2016-01-02 03:04:05 +0900 JST fmt.Println(t) } 以下、NewParseTime と Parse の説明です。 NewP
Word2Vec というと、文字通り単語をベクトルとして表現することで単語の意味をとらえることができる手法として有名なものですが、最近だと Word2Vec を協調フィルタリングに応用する研究 (Item2Vec と呼ばれる) などもあるようで、この Word2Vec というツールは自然言語処理の分野の壁を超えて活躍しています。 実は Item2Vec を実装してみたくて Word2Vec の仕組みを理解しようとしていたのですが、Word2Vec の内部の詳細に踏み込んで解説した日本語記事を見かけることがなかったので、今更感はありますが自分の知識の整理のためにもブログに残しておきます。なお、この記事は Word2Vec のソースコードといくつかのペーパーを読んで自力で理解した内容になります。間違いが含まれている可能性もありますのでご了承ください。もし間違いを見つけた場合は指摘してもらえると
本サイトでは、ラーニング・パターンの考え方や個々のラーニング・パターンについて紹介します。 ラーニング・パターンは、自律的で創造的な学び方のコツをパターン・ランゲージという形式でまとめたものです。どのような状況でどのような問題が生じやすく、それをどのように解決すればよいのかの発想がまとめられています。このようなコツを「言語」として共有することで、個人の自律的で創造的な学びの支援と、学びのコミュニティの活性化を目指しています。 ラーニング・パターンは、2009年4月から毎年、慶應義塾大学総合政策学部・環境情報学部の全学生(一学年約900人)に配布されているほか、本ウェブサイトやtwitter等で、幅広い世代の方に広まりつつあります。ぜひご活用ください。 ラーニング・パターン(Learning Patterns)のtwitter配信をしています! よりよい学びのコツを記述した「ラーニング・パタ
Facebook Messenger PlatformやLINE BOTが話題になっていますが、下記の記事でも言及されているように、BOTサーバーとして大量メッセージに対応するには「並行処理」がキモになってきます。 大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ そしてElixirといえばやっぱり「並行処理」なわけです。ということで「BOTサーバーを効率よく開発するにはElixir/Phoenixってとても良い選択なのでは?」という仮定のもと、色々と検証してみました。 並行処理のコード Elixirでプロセスを起動・管理する方法はいくつも用意されていますが、BOTサーバーの要件的に「状態」を管理する必要はありませんし、プロセスから「戻り値」を返してもらう必要もありません。要するにプロセスは「使い捨て」というか、実行が終わったら勝手に終了してくれればそれでオッケーなわけで
AV Foundation を用いて動画処理を行う(=カメラ入力をリアルタイムに処理する)プログラムを書いていると、回転・向きの取り扱いで混乱してしまうことが度々あります。 関連しそうなプロパティやら何やらが多すぎてややこしい、となんとなく思ってるけど洗い出してみればそうでもないのかも、とも思うので、ドキュメントに目を通しつつ、コード書いて実機で挙動を確認したりもしつつ、いったん整理みようと思った次第です。 AVCaptureDevice の position による向きの違い AVCaptureDevicePosition には Back と Front があって、要はバックカメラ(背面カメラ)か、フロントカメラか、の違い。 バックカメラの場合は、 return AVCaptureDevice.defaultDeviceWithMediaType(AVMediaTypeVideo) gu
「わかった?」は意味のない言葉 似たようなことでいうと、メンターは何かを教えた後に「わかった?」と確認してしまうことがあります。このとき、メンティが「わかりました」と答えたとして、何か意味があるでしょうか。先ほどの「心構え」と同様に確認しても観測できないことを問いかけている状態になってしまいます。 そうではなく、具体的に「今言ったことを、ひとりで試しにやってみて」とか「以下の話を図に書き起こしてみて」とかアウトプットを要求しない限り、わかったかどうかなんてわかりません。 学生時代に私は塾講師をしていたのですが、課題のプリントを生徒たちに渡して、「わからなかったら手を上げて」と言ってたのですが、そのときは誰も手を上げられなかったという体験があります。そのあと、どうしたらいいんだろうかと考え、「問題を解く手が止まったら手を上げて」と伝えるようにすると、手を上げてくれる生徒が現れました。 抽象的
About Kazuyuki Kohno: Nothing here yet Kazuyuki Kohno photo gallery: Nothing to show here at this time 「人生の明確な目標があってそのために意思決定と努力をしてきた」という感覚は実はあまりないんですよね。ただ現実を直視して自分をごまかさないようにする「癖」みたいなのがあって、それでなんとかやってこれた感じですね。人生の各所でビビってしまうできごとってあると思うんですね。例えば僕の場合は初めて参加した海外のカンファレンスで、飛び込みで5分間の発表をやってみたら?と知り合いに言われ、ここで尻込みしたらびびってる俺めっちゃカッコ悪いやん、めっちゃダサいやん、って思ったんですね。スポーツでも一緒で、僕は大学中退後スノーボードをしばらくやってたんですが、ビビってたら全然うまくならないんですよね。この
珍しく日記が続いています 何をやらせても3日と続きやしない私がブログを3日連続で書いている時点で、空からヤリが降ってもおかしくないこの年度末、皆様いかがお過ごしでしょうか。 最近すっかり拙著ネタばっかりになってしまいましたが、急に「昨日はengine.ioいじって挫折してました」とか書いても話題が飛びすぎるので、書籍つながりでドメイン駆動設計(DDD)について個人的な意見を書いてみたいと思います。 ドメイン駆動設計(Domain Driven Design) 一部の方には釈迦に説法になってしまうかもしれませんが... ドメイン駆動設計(英: Domain-driven design, DDD)とはソフトウェアの設計手法であり、 '複雑なドメインの設計はモデルベースで行うべきであり'、 'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメイ
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された.この変更について「ちゃんと」理解するため,アルゴリズムレベルでGoのGCについて追ってみた. まずGoのGCの現状をパフォーマンス(レイテンシ)の観点からまとめる.次に具体的なアルゴリズムについて,そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する. GoのGCの今 最初にGoのGCの最近の流れ(2016年5月まで)をまとめる. Go1.4までは単純なStop The World(STW)GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された.導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった.Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた. 以下は公開されているベンチマーク.まずはGo1.5を見る. Gophe
GoConでは毎回エラー処理について面白い知見が得られる.Go Conference 2014 autumn においては(実際のトークではないが)居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた. Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite(やRead)のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった. そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から(僕にとっては)新たなエラー処理テクニックが紹介された. Gocon Spring 2016 実際に使ってみて/コードを読ん
スレッドローカルは便利なクラスです。 いつでもどこでもスレッドセーフなグローバル変数を定義することができます。 ごく稀にですが、スレッドローカルを使わないと解決できない問題もあるでしょう。 しかし、思うのです。スレッドローカルを使うのは基本的に「負け」なのだと。 例えば 例えば、こんなコードがあったとします。 public class FooAction implements WebAction { // 入力フォームのバリデーションを行う。 @Override public void validate(Form form) throws ValidationException { if (form.get("name") == null) { throw new ValidationException("name is null"); } if (form.getInt("age") <
こんにちは、Sustain チームの山口です。 今サイボウズリモートサービスというVPN・中継サービスで使用する L7LB を nginx に移行しようといろいろ調査をしています。 nginx をリバースプロキシとして使用する際に少々障害となる動作があり、それに関するアップデートが最近あったので、今回はそのお話です。 3行で分かる本記事の内容 nginx をリバースプロキシとして使う場合、リクエストがバックエンドサーバに二重で飛ぶ可能性がある 対策として proxy_request_buffering off が使えそうだが、使えない nginx 1.9.13 で仕様変更が入り、POST, LOCK, PATCH メソッドのリクエストは二重で飛ばないことが保証された nginx の受動的な health check とリクエストのリトライ動作 nginx はリバースプロキシとして使う場合に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く