はじめに 個人的な考え方が変わったことであって、宣伝ではないしただのポエム的なもの。 LAPRASとは リンク こんな風にスコアを出してくれる。 こんな感じでスカウトも来る。 今まで インプットはそれなりにしていた。 アウトプットはほどほどにという感じ。 文章にすることとか、うまくまとめることが苦手だった。コード書くのは好きなのに。 アウトプットした方がいいとか、社外評価がとか言われるとすごく納得するし、やらなければなと思うんだけど、インプットして仕事でアウトプットして外には出さずに終わっていた。 きっかけ 単純に登録したLAPRASで意外と足跡がついていてスコアを上げたかったから。 あとは、機械学習の勉強しているときにちょっとアウトプットしてみるか、的なモチベーション。 別に綺麗な理由なんてないけど、今までよりgithubにcommitするようになった。 そんな感じでやっていたら、アウト

Web系の会社にいると，仕事用のPCとしてMacを支給されることが多いと感じている．例にもれず俺も会社ではMacBook Proを使っていたのだけれど，最近Macが使い物にならないくらい遅くなってきた． そもそもそんなに新しいMacではないというのはあるんだけれど． もはやローカルでの開発はほぼDocker化してしまっているので，なにをするにもDockerを起動する必要がある． しかし，Docker for Macは遅い．とくにvolume mountが遅すぎて，webpackなんか走らせたらお茶を入れに行くくらいの猶予が発生する． ---追記--- webpackだけならdockerじゃなくていいじゃんと言われたので，一応弁明しておくと，webpack以外もあります． DjangoとかElasticsearchとかElasticsearchとかlocalstackとかredisとかDja

序節：はじめに 近年、日本型の開発プロセスとして メテオフォール型開発 - 実践ゲーム製作メモ帳2 が注目を集めている。 eiki.hatenablog.jp 上記のメテオフォール開発では、適用対象は開発チームである。 （本稿ではこれをオリジナルMF開発とよぶ） 一方最新の研究では、これをより大きな企業レベルで適用する事により、更なる災厄効果をもたらす事が明らかになってきた。 本稿では、企業レベルでメテオフォール開発を適用する為の手法「スケールドメテオフォール開発」について、概要を説明する。 (オリジナルの方に迷惑かかるとアレなので補足:オリジナルMFを書いた方とは全然関係ない人のポストです) 第一節：スケールドメテオフォール開発 オリジナルMF開発では、単一の開発チームを想定している。 そしてこうなる。 一方、スケールドメテオフォール開発では、複数の開発チームを含む、企業全体が対象となる

LAPRASは、すぐれた機械学習技術とクローリング技術を使い、インターネット上でオープンになっている情報を集め、「プロフィール」を自動生成します。

Abstract Microservicesにおいて，サービス間の通信はネットワーク越しに行われ，そのために必要となるリトライやタイムアウト，アクセス制限等をコントロールするものとして，ServiceMeshがあります． そして，Kubernetes上でのServiceMesh実装としてIstioがあります． Istioは昨年1.0がリリースされ，今年は1.1にバージョンアップし，非常に手軽に導入が可能となりました． 本セッションでは，Istioが提供する機能や基本的な構成に加え，実際にどのようなコードを書くことによりトラフィックをコントロールできるようになるのかということについてお話します． また，Microservices構築のために，AWS ECSからKubernetesに移行し，さらにIstioを本番に導入した際に当たった困りどころについてもお伝えします． トピック: Servic

今回は2018年の振り返りです。 …といっても、ないぱかとして活動し始めたのが11月中旬なので実質約1ヶ月間の振り返りになります。 一言で言うと「一歩を踏み出すことで自分の世界が動き始めた」1ヶ月間でした！ 踏み出し始めたもの 1. Twitter 2. ブログ 3. アプリ開発の勉強 4. 勉強会への参加 踏み出し始めたキッカケ 来年の抱負 踏み出し始めたもの 今まで生きてきた中で１番新しいことを始めた1ヶ月だったように思います。 始めたものは主に以下の4つです。 1. Twitter ”エンジニアないぱか”としてのアカウントを作成し、他のエンジニアさんたちとの交流を始めました。 Twitterを始めたことにより、自分だけだったらたどり着けないような情報や今後のキャリアを考える上で参考になる人、ロールモデルとなるような人に出会うことができました。 また、#100DaysOfCode など

LAPRAS の森元です。AI LAB でのはじめての投稿になります。私は、修士課程・博士課程を通して自然言語処理学の研究をしてきました。特に推論や因果関係に興味があり、主に含意関係認識の研究を行ってきています。先月4月よりリサーチャーとして LAPRAS に入社しました。 本記事は、2019年4月現在の文自動生成に関してのサーベイを行った結果をまとめたものです。 はじめに LAPRAS の提供している LAPRAS SCOUT では、スカウトメール作成支援システムを導入しています。現在は、候補者情報とテンプレートを用いたスカウトメール作成支援システムを導入していますが、よりメール作成のコスト削減を目指すために、文の自動生成を用いることができないかと考えました。そこで、文の自動生成に関する研究がどのような現状であり、その技術が我々のプロダクトに使えるものであるのかという視点で調査を行いまし

ブログやSNSをAIが分析して技術力の順位などを算出。自身の市場価値を測れます。企業からのスカウトで転職活動もできます。

概要 LAPRASを選んだ理由 広報記事の内容に説得力が有る 組織体制がおもしろい インターン選考 現在までにやった仕事 取り組んだ課題 仕事の方法論 LAPRASにインターンとして入った後の印象 オープンであれ エンドユーザーファースト 最後に 概要 2019年3月25日から、LAPRAS株式会社（旧scouty）でアルゴリズムエンジニアとしてインターンを始めました。 LAPRASについて簡単に説明すると、GitHubやSNSなどをクロールして構築したDBと機械学習技術を用いて、エンジニアと企業をマッチングさせるサービスです。4月10日からto Cのサービスが開始し、今まで採用担当者だけが閲覧可能だったプロフィール画面がエンジニア本人にも公開されました。 LAPRASプロフィール LAPRASを選んだ理由 私は大学で機械学習の研究をしており、また趣味やアルバイトでWeb開発の経験がありま

本記事は[退職者 その2 Advent Calendar 2018[(https://adventar.org/calendars/3243)の10日目の記事です。 adventar.org 今年の5月末に退職して現職に至ります。前職も現職も変わらずWebアプリケーションエンジニアをしています。会社が変わることによって使用する言語がRubyからPythonにかわりまして、文末の : 忘れや後置 if が使えないことに悩んだり、Railsと違ってDjangoはオートロードがなく逆に安心感を感じるなど言語の違いを愉しんでいます。 退職者アドベントカレンダーではあるのですが、退職者が言いたいことを言うというところだけお借りして、あえて退職された側の気持ちを綴ってみたいと思います。 主に自分が感じる気持ちなのであまり一般性がないかも知れませんがご了承ください。 メンバーが退職するとき残された側の思

この記事はscouty Advent Calendar 2018 の3日目です． ECSで動かしているサービスのスケジュールジョブが多くなってきた． もともとECS Scheduled Taskを使っていたんだけど，数十個レベルになってくると，これで管理するのはだいぶつらい． というわけでRundeckを構築したメモ． そもそもECS Scheduled Taskやる気あんの？ ECS Scheduled Taskの辛いところ． Scheduled Taskは既存のTaskDefinitionを上書きしてタスクを実行するため，Override用にjsonでTaskDefinitionの一部を与える必要がある Scheduled Taskの一覧画面はあるのだが，そこから「何時に，どのタスクIDで実行されたか」を知る術がない そんなだから，タスクが正常に終了したのか，何かのエラーで途中終了した

LAPRAS代表の島田です。LAPRASはアメリカで発祥した「ホラクラシー組織」という形態をとって運営されています。今回はLAPRASの実運用例を含めて、ホラクラシー組織とは何か、どのような形で運用されているかをご紹介します。 ホラクラシー組織に関する誤解日本では、一般にホラクラシー組織というと 上下関係の無いフラットな組織自由度が高く、ルールが少ない組織情報がオープンな組織といった特徴をもつ組織として認知されているようですが、これはアメリカで発祥した本来のホラクラシー組織の定義とは異なります。 本来、ホラクラシー組織というのはHolacracy Oneの創設者であるBryan.J.Robertsonがアメリカで提唱した組織体系で、組織のフラットさや情報の透明性などの文化だけで本質づけられるものではありません。 実際に、Bryanも自著「HOLACRACY –  役職をなくし生産性を上げる

なんか気がつけば2017年8月から始めたBlogも1万アクセスを突破してました。めでたい。 さて、最近はDjangoよりもScrapyに触ってる事が多いです。結構日本語の情報も増えてきましたが、Django等に比べるとまだまだ利用者が少ないのか情報が少ない部分もあります。 このBlogではScrapyにはじめて触れますが、いきなりテストについてメモ代わりにまとめておきます。ScrapyではSpiderというコンポーネントをクロール対象ごとに作成します。このSpiderのテストをどうするかについてです。 サンプルの構成 今回のプロジェクトは以下のような構成です。といってもscrapy startprojectしてdenzowblogというspiderを一つ追加しただけの状態です。 . ├── scrapy.cfg └── testscrapy ├── __init__.py ├── item

2018年6月で株式会社Nextremerを退職しました。理由はお察し下さい。 1年半チョットの在籍中、LEGOを動かしたり、ホビーロボを組み合わせて動かしたり ( ディープラーニングで「うまい棒」と「都こんぶ」を仕分けるマシン 20万回の訓練でつかむ位置まで正確に学習 - ねとらぼ)、ロボットシミュレーションの為にxml書いたりしていた。 後、機械学習でPythonも少し書いてた。 結果的に、遥か昔に辞めたはずのロボット開発に戻ってきたのは不思議な感じだった。何でもやっておくと役に立つもんだなあ。 そんなに深くやったわけではないけど、20年位前のロボット開発と比べて思うのは、色々パーツとかキットが抱負になったのと、3Dプリンターが安価になって使われてることか。 次の会社では再び職業Common Lisperになる予定 (2年ぶり2回目)

アジア最大級のIT・エレクトロニクスの展示会「CEATEC JAPAN 2017」で、黙々と「うまい棒」と「都こんぶ」を仕分けするマシンを発見しました。 すごい この物流革命を感じさせるマシンを開発したのは、AIによる対話システムを強みとするネクストリーマー。なぜ対話AIと一見無関係な、「うまい棒」と「都こんぶ」の仕分けマシンを……？　担当者に率直な疑問をぶつけてみたところ、実は近年、ディープラーニングの研究を本格的に行っており、1年ほど前からロボット関係の研究も進めていたことから、CEATEC用の展示として、2カ月程度で同マシンを作り上げたとのこと。 うまい棒と都こんぶを正確に仕分けていきます 卓上では「陳列棚」に見立てたカゴを2つ設置。カゴの中身がなくなるとマシンは「在庫切れ」と認識し、背後の「倉庫」にあるうまい棒と都こんぶを補充してくれます。マシンに取り付けられたカメラで形状を認識。

（追記 2017/5/10） だいぶ放置していた形になってしまい申し訳御座いません。 僕自身ここまでの反響が（炎上が？笑）起こったことに驚いております。 賛同してくださった方・批判してくださった方、どちらも最後まで記事を読んでいただき、コメントまでしていただいたことに感謝でいっぱいです！ 自身の考え方としても勉強になりますし、何よりみなさんがこれだけ真剣になっていることが僕自身はとても嬉しい限りです。本当にありがとうございます。 前書き エンジニアとして1年経ち、振り返ってみると、業務中にわからないことがあるたびに調べ、 Qiita (記事投稿者の皆様方) には大変お世話になりました。ありがとうございます。（今頃になって自分は登録しましたが笑） 社会人1年目って人生１回きりしかありません。自分も2年目となり指導する側になる身として、 1年目で抱いていた心をいつまでも忘れないために、これを残

これはNextremer Advent Calendarの23日目の記事です。 現在、株式会社Nextremerでは早稲田大学の田中宗様と量子アニーリングに関する共同研究を行っております。 はじめに 量子アニーリングは組合せ最適化問題を解くための有効なアルゴリズムと言われています。 本記事では、量子モンテカルロ法による量子アニーリングを用いて、代表的な組合せ最適化問題であるTSP(巡回セールスマン問題)に対して解を求めたいと思います。 量子論の基礎 TSPの議論に入る前に、少しだけ量子論の基礎的なことに触れておきます。 物理量(エネルギーや運動量など)は、量子の世界では演算子というものに対応します。例えば、エネルギーという物理量に対応するものはハミルトニアン($\hat{H}$と表します)という演算子です。 このハミルトニアン $\hat{H}$ という演算子は、ある量子状態 $\psi$

こんばんは。Nextremerの壹岐です。 深層学習が破竹の勢いで進展していく今日この頃。 計算機が人のできることをどんどんできるようになってきているわけですが、彼らだからこそできることも伸ばしてあげるのも大事だと思ったりします。 そこで、今回はwebカメラでの脈拍推定をやってみようと思います。 どういうものかというと"普通のwebカメラで人物を普通に撮影して、肌の色の変化から脈拍を推定する"というものです。おそらく、ほとんどの人は対面している人の、例えば、顔の色を見てもその人の心臓の鼓動を認識することはできないと思います。 しかし、計算機にはそれができてしまうようなのです。 心拍数に関してはWeb Cameraで頑張らなくてもより適したセンサーが手軽に購入できるのですが、彼らなりの方法でインプットを解析して状況を認識し、私たちの手の届かないところを補ってくれるようになると頼もしいものです