2017年のディープラーニング論文100選 - Qiita
これはFujitsu Advent Calendar 2017の18日目の記事です。 掲載内容は富士通グループを代表するものではありません。ただし、これまでの取り組みが評価されて、富士通がQiitaに正式参加することになりました[リンク]。なお、内容の正確性には注意を払っていますが、無保証です。 はじめに この記事では今年発表されたディープラーニング論文（ArXivでの発表時期、発表された国際会議が2017年開催またはジャーナル掲載が2017年のもの）から私が個人的に重要だと思った論文を収集しています。また、2016年末ごろの論文も重要なものは採用しています。 以下の投稿も合わせてご覧ください。 2016年のディープラーニング論文100選[リンク] ディープラーニングにとっての2017年 2017年のディープラーニング技術は主に画像系技術で革新的な進歩がありました。それをけん引したのは敵対
Bing検索の裏側―BitFunnelのアルゴリズム - Hatena Developer Blog
はてなアプリケーションエンジニアの id:takuya-a です。 この記事では、Microsoft の検索エンジン Bing で採用された BitFunnel アルゴリズムを紹介します。 昨年のエンジニアアドベントカレンダーでは、文字列検索のアルゴリズム全般について紹介しました（文字列アルゴリズムの学びかた - Hatena Developer Blog）。今年はそのなかでも、インデックス（索引）を使った全文検索アルゴリズムについてのお話になります。 この記事の前半は全文検索の入門にもなっていますので、検索技術になじみがない方にも楽しんでいただけるのではないでしょうか。 逆に、「そんなのもう知ってるよ！」という方は、本題である「BitFunnel アルゴリズムの詳細」から目を通していただければと思います。 この記事は、はてなエンジニア Advent Calendar 2017の21日目の
V8 javascript engineについての細かい話 (Node.js Advent Calendar 2017) - abcdefGets
Node.js Advent Calendar 2017 25日目の記事です。トリとなります。 さて先日11/26・27日に行われたNode学園祭でv8について発表させて頂いたが、 30分という制約上色々カットせざるを得なかった。 またv8のコードを読む・コントリビュートする上で伝えられる事も色々と溜まったので一度アウトプットすることにした。 というわけでまとまりのない記事になる可能性が高いがご容赦いただけると助かります。 事前資料 以下のスライドがNode学園祭の発表資料なので読んどいていただけると理解がはやいかも speakerdeck.com 前準備 チェックアウト v8はGitHubに直接はホスティングされていない。 GitHub上にあるv8リポジトリはミラーで実際にはchromium.googlesource.comにホスティングされている。 ただし開発の際にはGitHubのリポ
PrometheusとGrafanaを組み合わせて監視用ダッシュボードを作る | さくらのナレッジ
Prometheusには簡易的なグラフ作成機能が用意されているが、これには必要最低限の機能しか実装されていない。そこでおすすめしたいのが監視用コンソールを提供するソフトウェア「Grafana」だ。以下ではPrometheusとGrafanaを組み合わせて利用する流れを紹介する。 多機能な監視画面を作成できるGrafanaとの連携 Prometheus Serverには、取得したデータをグラフ化して表示する機能が用意されている。クエリ機能や関数を駆使することでさまざまなデータを表示できるものの、この機能では基本的には折れ線グラフでの表示のみしか行えない。また、複数のグラフを同時に表示することはできるが、異なるデータを1つのグラフにまとめたり、グラフの体裁を調整する機能についてはあまり十分ではなく、一覧性や見やすさにはやや欠ける。そこでPrometheusと併用したいのが、高度なグラフ表示を実
新QiitaでReactをやめてhyperappを採用した背景 - Qiita
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
reselectでReact Reduxにvalidationの仕組みを実装する 2/2 - Qiita
function mapStateToProps(state) { const validation = rootSelector(state) return { state, validation } } これでRootコンポーネントからvalidationの結果をprops.validationとして扱えるようになりました。 Rootコンポーネントのprops経由で各コンポーネントに渡す あとはprops.validationを他のpropsと同様にコンポーネント内で好きに使うだけです。 完成したサンプルはこちら *1 ValidationIconがvalidationStatusを表示するコンポーネントです。 *2 ValidationStatusがERRORのときはエラーであることを表すアイコンを表示します。 *3 ERRORにmessageが設定されていればそれをTooltipと
Reduxでのクライアントサイドvalidationをどこでやるべきか？ - Qiita
入力フォームを利用するとやっぱり大事になってくるValidationについてあれこれ悩んだ。 結論が完全に自分の中でも出てないが、とりあえず考え尽くした所まで 前提など validationとひとくちに言っても色々考える事がある 出力するエラーは一つ？複数？ エラーが出たフォームを赤くしたいとかある？ 複数の値を見てvalidationしたいとかある？ validateするタイミングは随時？ボタン押されたら？ 今回の話 Redux + Reactを使う 簡易なTodoリストを想定する Actionの形式はFlux Standad Actionを使う 一旦細かいことは脇に置きつつ、下記のvalidationを想定して実装してみる エラーメッセージは一つ Todoのinputが空だったらエラーとする Todoの追加ボタンが押されたタイミングでvalidateする redux-form、redu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
