カジュアルに機械学習するお話をしてきました。的な話がほんのり程度になってしまったのが今回の反省点です。詳しい話を知りたい場合はこちらをご覧ください。機械学習を利用する際のワークフローをすべてカバーするのがいいかというとそんなことはない、と私は考えています。ほとんど使ったことないので、この辺りは僕の主観が色濃く出ています...)。機械学習を活用するのがいいんじゃないかと思っています。いう話をちらほらと耳にします。向上したのか、みたいなビジネス上の指標値を設定することは可能だと思います。そのような指標値をせずに機械学習を導入してしまうと、それはチューニングはできない・機械学習アルゴリズムをおいそれと変更することもできない、ただただ辛みのつまったパンドラの箱に成り下がってしまうので、僕の身の回りでこういうことにならないように、気をつけないといけないよなー、と思った次第でした。大会にスピーカーとしてエントリしたものの、会社イベントを優先する必要があって止む無く断念したこともありましたが...)。コミュニティではないので、発表する内容は理解を優先した構成にしてみました。その分、「この内容は果たして聴講者に伝わるんであろうか」とヤキモキしたりすることもあって、久々に資料作りで消耗しました。発表してきたのでした。集約しており、普段扱っているコミュニケーションツールの中でも特段利用時間が長い状況になっています。エンジニア的には自然と沸き起こってくるわけです。実装を用意する方法を紹介しました。(発表中にお見せしたコードはまだ整備しきれていないので現在は非公開としていますが、いずれ公開する予定です)。オブジェクト経由でスレッドを立ち上げるといいそうです。触っていて、圧縮エンコードについて調べることがあったのでメモメモしておきます。月時点での情報であることと、わりとざっくりとした確認だったので不正確な情報が混じっているかもしれないのでご承知おきください。選べばだいたいいい感じだと思う。認証系を自作する、というニッチな話をしてきました。昨今のパスワード流出系のセキュリティインシデントが業界内で話題になるたびに「認証系なんてものは自作するようなもんじゃない」という認識が醸成されつつあると思います。アプリケーションフレームワークなどを利用しているとそうもいってはおられず、認証系が用意されていないときはやむなく認証系の自前実装が要求されることもあるでしょう。自分自身も周りを見渡していても、過去何度かそういうことがありました。実装者の認証セキュリティに対する認識や知識によって脆弱な認証系を作り込むことも少なくなく、そういうのをなるべく減らしたいなー、という思いを込めて今回の発表に至りました。しても認証系を自前実装しなければならないときに気をつけたいこと前述した発表資料に書いてあることにはなりますが、今一度文章に起こしておきます。やつとパスワードを組み合わせたものをハッシュする」ということぐらいは知っているものと思います。}のような実装になることでしょう。使えばいい、というほど簡単ではありません。関数を使ってストレッチングすべき、となります。用いたパスワードのハッシュ化コードは以下になります。(過去何度もダメな認証系を作ってしまったし...)。僕は使ったことないですが、多分このあたりの面倒なお仕事をこなしえくれるのではないでしょうか。接続しようとしたときにこのエラーが発生した。127.0.0.1が設定されていたためであった。クラスのお世話になるかと思います。表現に変換することが必要とされていました。エンコーディングされたプロパティファイルを扱う方法についてメモしておきます。クラスそれぞれについて説明します。以下のような実装になるでしょう。クラスのサブクラスを用意して対処する方法をとります。クラスのコンストラクタ引数にそのオブジェクトを指定します。エンコーディングなプロパティファイルを取り扱うことができるようになります。