データサイエンスや機械学習のチートシートを最も効率的に収集する方法 - Qiita
機械学習・データサイエンスのチートシート集、便利なものがたくさん出回っていますが、ちまちまブラウザからダウンロードしていたりしませんか？そんな貴方にお勧めなのがこちらのレポジトリ。 FavioVazquez/ds-cheatsheets https://github.com/FavioVazquez/ds-cheatsheets はい、クリックあるいはコマンド一つで100を超えるチートシートが一括でダウンロードできちゃいますね。以上、釣りタイトル失礼しました。 と、これだけではなんなので、個人的に有用性が高いと感じたものを、大きなサムネイル付きでまとめてみました。ソースとして、DataCamp及びRStudio公式ページの情報量は圧倒的なので、一読をお勧めします。 科学計算・データ操作・可視化 Python (NumPy/SciPy/Pandas/matplotlib/bokeh) Pyt
１００名に聞いた！エンジニアリングマネージャーの給与と責務の実態調査 - Qiita
はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ
不均衡データへの決定打となるか！？「Affinity loss」の論文を読む、実装する - Qiita
陰性のデータは1万件近く集めることができましたが、陽性のデータは100件しか集められませんでした。このように、陽性・陰性というクラス間でデータ数に明らかな偏りがあるケースを不均衡データ（inbalanced data）といいます。 不均衡データの問題点 評価上の問題 これは教科書的な問題で、「精度（Accuracy）が機能しない」という点です。例えば先程の例で陰性がデータ全体の99%なら、ありとあらゆるデータに対して陰性と判定（$y=0$）する分類器を作れば、その時点で精度99%を達成してしまいます。 こんなイメージです。機械学習なんていらないですね。笑っちゃうかもしれませんが、実は機械学習を使っても「return 0」みたいな状態に最適化が向かうことがあります（後述）。 今最適化での解の問題はおいておくとして、あくまで評価上の問題なら、Precision, Recall, ROC曲線、F
【データ分析】新規データを受領したら最初にすべき10ステップ - Qiita
はじめに 新規データを受領した際に、統計モデリングや機械学習の前に実施すべき10ステップをまとめてみました すぐにモデリングや機械学習による予測・分類をしたくなりますが、間違えた分析結果や作業の手戻りを避ける為に基本的な下記ステップをまず実施することが重要と思います データ型の確認 データ形の変換(日付型) データ形の変換(カテゴリ型の作成) 基本統計量の算出 単変量データの可視化 異常値の置換・除去 欠損値の補完・除去 相関(数値×数値)の可視化：ペアプロット&相関行列 相関(数値×カテゴリ)の可視化：ボックスプロット 相関(カテゴリ×カテゴリ)の可視化：ヒートマップ 対象データ概要 今回はサンプルとして下記のようなデータを対象にします 有名なTitanicのデータを加工しました（オリジナルデータは現実には存在しないくらい綺麗だったので） こちらのデータを参考に10ステップを紹介していこ
Rettyの意思決定を最大化！データ分析チームの取り組みをご紹介 - Retty Tech Blog
この記事は Retty Advent Calendar 18日目の記事です。 昨日は@isaoekaさんの会社の行動規範浸透を図るため、メニューバーからいつでも確認できるアプリを作ったの話でした。 はじめまして、Rettyのデータ分析チームでマネージャーをやっている平野です。 Rettyのデータ分析チームは今年4月に立ち上げ現在9ヶ月目です。 この記事では立ち上げから9ヶ月でやってきた組織的取り組みについて中心に書きました。 今アドベントカレンダーではデータ分析の技術的取り組みついてを、一緒にデータ分析チームを立ち上げた@takegueが書いてますので、そちらも合わせて読んでいただけますと幸いです。 ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog Webサービスを支えるユーザログ基盤開発＠Retty - Retty Tech Blog 目次
(翻訳) データエンジニアの始まり - satoshihirose.log
訳者まえがき 原著者 Maxime Beauchemin の許可を得て以下の記事を翻訳・公開しました。 medium.freecodecamp.org 原著者は、Apache Airflow や Apache Superset のクリエーターで、現在は Lyft で Data Engineer をしています。 データエンジニアの始まり（翻訳） 私は 2011 年にBIエンジニアとしてFacebookに入社しました。2013年に退職するときには、私はデータエンジニアでした。 昇進もしくは新しい役割に就いたわけではありません。そうではなく、Facebookは、私たちが行っていた仕事が伝統的なBIを超えていたことに気づいたのです。私たち自身のために作り出した役割は、まったく新しい専門分野でした。 私のチームはこの変革の最前線にいました。私たちは新しいスキル、新しいやりかた、新しいツール開発し、そ
ブラックボックス化したデータ基盤を作りなおすことを決意した貴方へ
ここ一年くらいデータパイプラインを基盤ごと作りなおしていました。毎時一億レコードくらいは捌くやつです。 わりと長く続いているプロダクトのため、いわゆる技術的負債が溜まっていたりブラックボックス化していたところも多く、当初はエンジニアを倍くらいに増やさないと対処できない見込みでしたが、みんなで奮闘した結果、チームサイズを変えず新規開発の手も止めずに、目立ったダウンタイムや障害なく移行することができました。 振り返って「こうしておいてよかった」「こうしておけばよかった」と思うところを書き残しておこうと思います。また同じようなことに直面した未来の私へ、もしくは貴方へ。 0. 不吉な匂いを嗅ぎわけよう とあるプロダクトにジョインした貴方は、なにかしら不吉な匂いを感じました。 そうです、みんなお馴染み「不吉な匂い」です。たとえば次のようなことがあったのでしょう。 使っているライブラリやフレームワーク
私の考えた最強のログ＆モニタリング設計 - 下町柚子黄昏記 by @yuzutas0
この記事はRecruit Engineers Advent Calendar 2018 - 8日目の記事です。 注意点 タイトルは煽りです。「新規事業におけるデータエンジニアリングの勘所」の方が正しいかもです。 クオリティというか記事の信頼度は、投稿時間がギリギリになってしまったことから察してもらえるとありがたいです。 本エントリーの内容は個人的な見解であり、所属する組織を代表するものではありません。データの取り扱いは非常にセンシティブなトピックでもあるため気軽に発信すべきではないということは重々承知しております。もし誤りや考慮不足だと感じる点があれば、それは全て私個人の力不足によるものですので、どうぞ私個人当てにご指摘のコメントをいただけると幸いです。 もくじ 注意点 もくじ 背景 前提 体制 システム 開発スコープ 機械学習WebAPIは分離 データ基盤設計 全体の設計ポリシー データ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ / 20180727 - Speaker Deck