オープンセミナー2017@岡山
![レガシーコードの触り方 / Working Effectively with Legacy Code](https://cdn-ak-scissors.b.st-hatena.com/image/square/937a6cc63647a61b0456c6fca111b7631b1fb6b1/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4be05ace3144495795b9a5fbad0e6b57%2Fslide_0.jpg%3F7970687)
おつかれさまです.今回はタイトルの通り,ベイズ学習を勉強する上で参考になる教科書やウェブの資料,論文等を紹介したいと思います. ベイズ学習は確率推論に基づいた機械学習アルゴリズムの構築論です.ベイズ学習を使えば,あらゆる形式のデータに対して,未観測値の予測や隠れた構造を発見するための統一的なアプローチをとることができるため,特に現代の機械学習アルゴリズムを深く理解し使いこなすためには必須の方法論になっています. 1, ベイズ学習の位置づけ まず,データサイエンスにおける他の方法論と,ベイズ学習の位置づけを簡単に俯瞰したいと思います. 僕の知る限り,ベイズ学習は1990年代ごろから登場してきた機械学習の方法論で,既存の学習アルゴリズムを確率モデルによって構築し,学習や予測の計算をすべて確率推論(条件付き分布と周辺分布の計算)で解決してしまおうという試みによってはじまりました.これにより,従来
ディープラーニングの大流行の中、様々なフレームワークが登場し、気軽にプログラミングができるようになりました。しかし、そんな中どのフレームワークを選べば良いかわからないという人も多いと思います。そんな人に少しでも参考になればと思い記事を書きます。 はじめに Chainer 特徴 柔軟な計算グラフの構築が可能 Pythonによる実装 直感的な計算グラフの構築が可能 メリット・デメリット メリット デメリット まとめ Keras 特徴 とんでもなく簡単に計算グラフを記述可能 高速計算ライブラリのディープラーニング用ラッパー もはやプログラミングの経験すら不要 メリット・デメリット メリット デメリット まとめ TensorFlow 特徴 圧倒的な利用者数 テンソル計算を行うライブラリ Define and Run 追加のライブラリが豊富 メリット・デメリット メリット デメリット まとめ PyT
アジア最大級の広告をテーマにしたイベント「Advertising Week Asia 2017」が5月29日から6月1日に東京で行われる。その開催を記念して、同イベントのアドバイザーによるコラムがスタート。第1回は、LINE 上級執行役員 コーポレートビジネス担当 田端信太郎氏です。 この文章は広告についてのものだ。広告業界では、未だに議論が続いているだろうが、私の中では結論は出ている。 オーケー、認めよう。広告はもはや「嫌われもの」なのだ。デジタルネイティブ世代にとって「熱狂」する対象ではない。例えば、その証拠に2016年半ばからiOSの有料アプリランキングのトップにいるアプリをご存知だろうか。それは、広告ブロッカーだ。多くのユーザーがお金を払ってまで、広告など見たくないと思っているのだ。 なぜ広告は、そこまでユーザーから嫌われるようになったのだろうか。多くの広告業界人はなぜ広告が嫌われ
2017年5月12日頃から、世界各地でランサムウェアに感染する被害が相次いで報告されています。ランサムウェアはWannaCry等と名前が付けられているもので、これに感染する原因として、Windowsの脆弱性、及びその脆弱性を用いたNSAが開発したツールが関係している可能性があると各国のCSIRTやセキュリティベンダが注意喚起等を公開しています。Microsoftは今回の感染事案を受け、WindowsXPなどのサポートが切れたOSを対象とした緊急の更新プログラムも公開しました。 ここではこの世界中で発生したランサムウェア WannaCry の感染被害などについてまとめます。 インシデントタイムライン 以下は主に国内の関連事象を整理したもの。 日時 出来事 2016年9月16日 MicrosoftがSMBv1の使用停止を強く推奨する記事を公開。 2017年1月16日 US-CERTがSMBv1
「スゲー。これが今の日本の技術か……」 「世間はここまで進歩していたのか」 開発したのは、兵庫県西脇市に本社を置くシステム開発会社・ブレイン。創業35年、いまも社員20人のうち約16人がエンジニアという、生粋の技術者集団だ。 約10年前にゼロから開発スタート マシンの名前は「BakeryScan」(ベーカリースキャン)。「お店に提供を始めたのは今から4年ほど前。最近になって突然『ネットですごい反響がある』と人に言われて驚いた」――ブレインの原進之介執行役員はこう話す。 BakeryScanの開発が始まったのは2008年にさかのぼる。きっかけは、地元・兵庫県のパン店社長から相談を受けたことだった。 「人が足りなくて困っている。経験の浅い外国人スタッフでもレジ打ちや接客ができるようなシステムを作ってほしい」――。 だが、同社のパンに関する専門知識はゼロ。そこから待ち受けていたのは、約6年にわた
最近、Ninja650に乗り換えたSREチームの菅原です。今までマルチばかり乗ってきたんですが、ツインもなかなか面白いですね。シフトペダルをガチャコンいわせながら方々に出かける毎日です。 この記事では、サービスが配信しようとして何らかの理由で差し戻されたメール—バウンスメールの管理をどのように行っているかという話しを書きます。 バウンスメール サービスがユーザに向けてメールを配信しようとすると、多かれ少なかれバウンスメールは発生します。メールアドレスが間違っている・携帯電話の設定で受信を拒否している・メールボックスが一杯にになっている・IPアドレスがブラックリストに載ってしまったためサーバにメールの受信を拒否されている…etc。完全になくすことは難しいですが、バウンスメールを放置するとメールの到達率を下げたり、送信先から一時的にメールの受信を拒否されたりすることがあるため、差し戻されてしま
「端的にポイントを突いて情報を把握しやすいのが Typetalk の強み」と語るのは、ブックオフコーポレーション株式会社IT統括部の成田昌義氏。外部のシステム開発会社6社と進めているプロジェクトでの Typetalk の活用方法と、メールから Typetalk への移行により業務がどのように改善されたのかお伺いしました。 Typetalk まとめ機能 の独自の活用も必読です。 ブックオフコーポレーション株式会社IT統括部 成田昌義氏 業種:小売業 規模:1001名ー1500名 導入部署:IT統括部(1名-30名) ・導入目的:外部のシステム開発6社を交えた情報共有を、リアルタイムで円滑に進めたい ・課題:システム開発の進捗やテスト結果をメールでやりとりするのは手間と時間がかかる ・効果:タイムラグ無しで情報を共有できるようになり、プロジェクトの進捗が早くなった プロジェクトを共同で進めるシ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
前置き 情けないことだが、自身の過失により、GitHubで長年Privateリポジトリで運用していたリポジトリを、とある事情でpublicに変更したのだが、その中にAWSのS3のアクセスキーとシークレットキーがファイルに直接ハードコーディングされているのにすっかり気づかず、自身のAWSのアクセスキーとシークレットキーが流出してしまうという失態を起こしてしまった。 その不正利用により届いた請求金額は約300万円。請求を見た時は頭が真っ白になり冷や汗ものだったが、過去に同様のミスとその状況と対応をまとめてくださっていた方々のおかげで、なんとか深呼吸して対応することができたので、自分も少しでも今後起きうる同様の状況の方に対する助けになればと、一部始終を共有しておくことにしようと思う。 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 AWS で不正アクセスされて凄い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く