KotlinConfに登壇しました。海外カンファレンスでの登壇はなかなか出来ないので良い資料になればと時系列で出来事全て書き残しておきます。 （そしてまた海外カンファレンスで登壇出来る日が来て、このエントリーを自分が見直す日がくることを祈ります） だいぶ長いし、エモいし、技術者としてのコツとかはないので、こういうのが嫌いな方は戻るボタンを押して下さい。ほぼ推敲もしていない雑文です。 こんなポエムで批判とかされると嫌なので、批判する可能性がある方はぜひ時間を浪費せず、戻るボタンをクリックして下さい。 またKotlinConfの内容は一切ありません。別途記述します。 KotlinConfが開催されることが発表 開催のアナウンスされたのが3/15あたりで、3/28に何かKotlinに関することを検索していたら偶然サイトを見つけて、KotlinConfの存在に気づきました。 おおおう！？https

http://2017.rubyworld-conf.org/ja/program/2017.rubyworld-conf.org RubyWorld Conferenceきてます！！１ 一日目の11/1に15分で「Rubyで機械学習が出来る未来を目指すRed Data Toolsの現状と今後について」という内容で話してきました。 speakerdeck.com 今回は人生はじめての同時通訳付きで朝に打ち合わせがあったりと中々慣れない中でしたが楽しかったです。 発表では僕がプライベートで参加しているRed Data ToolsというRubyでデータ処理ツールを提供するために活動をしているプロジェクトの話をしてきました。 今回言いたかった事としては、まとめにも書きましたがいきなりすべての処理をRubyをやろう！と言ってるわけではなくApache Arrowを使用することで、一部から始められる

ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日

どうもせせりです:) 19歳の頃からほぼ1人でRailsでWebサービスを作り始めて早7年 紆余曲折ありなんだかんだで作ったサービスは30個ほどになりました 7年ほど前に一番最初に作ったTwitterアカウントで「僕の夢は25歳までに3億円を稼いで残りの人生を楽しむ事です」などと言っていました あれから7年がたち26歳になり、3億円は無理でしたが残りの人生贅沢しなければ働かずに生きていけるくらいにはなりました Rails勉強会、ハッカソン、未踏、などなど色々参加していましたし、狭いRails界隈なのでもしかしたら勉強会などでお会いした方は覚えている方もいるかもしれません 色々お話を聞いてくださりアドバイス下さった先輩方ありがとうございます あの頃の初心者は無事に夢にたどり着きました！ 振り返ってみれば訴訟起こすぞって怒られたり、警察から電話がきたり、サーバー会社にサービス止められたり、サー

エンジニアがスキルを磨きたいとき。キャリアプランに迷ったとき。モチベーションを高めたいとき。いつも助けになってくれるもの。それは、本。 優秀なエンジニアを目指すのであれば、良質な多くのインプットが不可欠です。それでは、各領域の著名なエンジニアにとって、良質なインプットとは？ 本稿では、19名の著名エンジニアに、自身のキャリアを支えてくれた“この一冊”というべき名著を伺いました。 各領域で活躍するエンジニアたちは、数多ある書籍からどんな一冊を選び、そこから何を学んできたのでしょうか？ 自身のスキルやマインドを磨くために、絶対に読んでおくべき珠玉の書籍を、ご本人と書籍の関わりエピソードとともに紹介してもらいました。 ※人名の50音順に掲載。回答者は敬称略とする。 池澤あやかが推薦！『Prototyping Lab』 サイバーエージェント 板敷康洋が推薦！『リファクタリング』 リーバンス 今井彩

はじめまして！田中です！ 普段はヌリカエというサービスで、主に経理関係を中心としたバックオフィス業務をしております。 そんな非エンジニアの私ですが、この度10/6-10/7にクックパッド社で開催された 「Rails Girls Tokyo 8th」に参加させていただきました！ （朝日新聞様が書かれたRails Girlsレポート記事はこちら☆） ※右が私です 参加したきっかけ エンジニアさんの仕事って凄いなあ 請求システムの開発などでお世話になっているエンジニアさんの仕事をちょっとでも理解したい エンジニアさんがよく開いているPCの黒い画面で何が起こっているのか知りたい エンジニアさんのイベント（SpeeeKaigiなど）が盛り上がっていて楽しそう 弊社では、社内外のエンジニアさんが交流するイベントが活発で、みんなでプレゼンして盛り上がるようなイベントが沢山あります などの想いがあり、参加

はじめに サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。 背景 現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。 メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置さ

ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ　プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ

雑にまとめる。 締切のない仕事は仕事ではないという言葉がある。誰が言ったかは忘れたが、たしか偉い人が言ってた言葉だと思う。 締切がない仕事というのは、たしかに存在する。そんな仕事があるのは贅沢な会社かだらけた会社かのどちらかであるが、たまにそういう『やろうと思えば無限に時間をかけられる仕事』というのを見ることがある。 もちろん会社からすると無限に時間をかけていいわけはない。締切がないのではなく、明確じゃないだけなのだ。自分の経験だが、締切が明確じゃない仕事をうまく進められない人のほうが多い。要はだらけるのだ。特に100点症候群あるいは恐怖症の人はいつのまにかすごく時間をかけてしまいがちだ。 ビジネスマンなら当事者意識を持ってキッチリ線を引いて終わらせろよという話なのだが、皆が皆そううまくやれるわけではない。特にチームでの仕事の場合はやっかいで、責任者が明確でないと集団心理が働いてダラダラし

こんにちは、ウェブアプリケーションエンジニアのid:syou6162です。秋まっさかり、読書の秋/論文読み会の秋ですね。はてな社内で国際会議論文読み会を開催したので、今回は読み会で取り上げた論文について簡単に紹介していきたいと思います。異常検知、情報検索、自然言語処理といった多様な分野の論文が登場し、読み会も盛り上がりました。なお、論文PDFは各学会ページまたは著者のWebサイトで公開されているものを参照しています。 Sparse Gaussian Markov Random Field Mixtures for Anomaly Detection Change Detection using Directional Statistics Linguistically Regularized LSTM for Sentiment Classification BitFunnel: Revi

Mackerelサブプロデューサーの id:Songmu です。表題の件、ユーザーの皆様には度々ご迷惑をおかけしており大変申し訳ありません。 本件の詳細に関する説明と、今後の対応に関してお知らせいたします。 死活監視のアラート誤報に関して Mackerelでは、mackerel-agentから一定時間メトリック投稿が途絶えた事をもって、サーバーがダウンしたと判断し、死活監視アラートを発報する仕組みになっています。 現在、 mackerel.io ドメインの名前解決が不安定になっております。それに伴い、 mackerel.io ドメインの名前解決が一定期間失敗し、Mackerelへのアクセスが一時的にできない環境において、 mackerel-agent がMackerelへのメトリック投稿をおこなうことができず、Mackerelシステム側でサーバーがダウンしたと判断してしまい、死活監視のアラ

最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設

がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。 儲かる機能をマイクロサービス化する マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。 それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。 マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリース

Twilioで、受けた電話を他の電話に繋ぐとき、Call命令を使います。 https://jp.twilio.com/docs/api/twiml/dial このとき、通話者同士の動作によってステータスが変わり、Dialで指定しているactionのurlにステータスの状態が通知されます。電話を切った時とタイムアウトの時に通知のリクエストがサーバに飛んできます。 Dialのアクション指定はこのようにします。 どの動作の場合に、どのような通知になるか不明だったので実際に実験しました。これだけあれば、次の動作やログに何を記録した方が良いかなど判断できると思います。 これだけ見れば、電話が通じなかったのか、通話した時間、通話上限時間に達したのかが判断できると思います。 発信者が転送コール音中に電話を切った場合 DialCallStatus : no-answer CallStatus : comp

Speeeエンジニアの義田（@yoppiblog）です。SpeeeではUZOUというアドネットワークである広告配信システムを開発・運用しています。 今回は広告配信システムを裏で支えるバッチのDocker imageの作り方のtipsをお届けしようと思います。 GoのバッチをECSで動かす UZOUのシステムは広範囲に渡ってGoを採用しており、広告配信サーバや配信する広告を選定するバッチもGoで書いて運用しています。 UZOUを導入されるメディアさんが増えるにつれて、処理するデータ量が段階的に増加していくシステムなので、常にバッチサーバを稼働させ続けるよりは、バッチ動作時に必要な台数だけ起動して実行するほうがコストパフォーマンスが良くメンテナンスも不要なため、ECS(Amazon EC2 Container Service)で動作させています。 GoはクロスコンパイルをGoのtool cha

同環境のAWSサーバを複数構築したい、という状況が発生した。 調べたことをメモしておく。 イメージとしてはVagrantfileやDockerfileのように 設定ファイル書いてコマンド叩いたらはいできたー、っていうのが理想。 方法1 AWS CloudFormationを利用する。 そもそもAWSがプロビジョニングの機能を提供していた。 知らなかったけど言われてみればまああるだろうな、というかないといろんな会社が困るだろうな。 方法2 Terraformを利用する。 Vagrantを提供しているHashiCorp社のツール。 AWSに限らず、Herokuなど様々なクラウドサーバのプロビジョニングができるみたい。 下記の記事を読んでみると、CloudFormationより痒いところに手が届きそうな感じに見えるが、 コンポーネントによっては対応していないものもあるよう。 dev.classm

ASKを触ってみるという記事を書きました。 その後も触ってみてはいるのですが、前段階で色々と調べる必要があることが多く進捗がよろしくないため、 ある程度形になってからまとめて投稿しようか迷っていました。 が、毎日投稿しないと続かなさそうなので、まとめるのは後にして、 その日やったこと、思ったことを書いていくことにします。 以下画面で「Alexa Skills Kit」を選択。 するとこんな画面に移動して、作るSkillのことを色々訊かれる。 「何のために作るんだ」「これでお金儲けるつもりあるか」「Skillの対象年齢は?」など。 適当に選択して進めていってみると、AWS LambdaのService Endpointを指定するように言われる。 こんな感じで。 EndpointというとURIか。 調べてみるとどうやらSkill作成においてはAWS Lambdaを使う、ていうのがスタンダードっ

The Maskarade project · GitHub 最近イマイチAndroidの活動ができてないんですが、Androidライブラリのメンテを諦めたわけではなくて、たとえばOrmaとかはまだやりたいことがいくつかあるのでやるつもりはあります。一方で、ちゃんと新しいメンテナがいたほうがいいなーというプロジェクトもあって、とりあえず私のメンテする気のあるなしに関わらずユーザーがいそうなAndroidライブラリを全部まとめて maskarade（マスカレード）というorganizationに移すことにしました。 何故これが必要なのかというと、新しくオーナーシップをもったメンテナを受け入れられる体制にするためにorgが必要だからです。GitHubは個人アカウントにあるリポジトリのオーナーシップをコラボレータに渡すことはできないんですよね。なので、オーナーシップを誰かに渡したいときは (1)

先日催されたRejectKaigi2017にて、gfxさんがGraphQLをRailsで使う、というお話をされていました。 blog.bitjourney.com 本家を見てみてると、Rubyではこんな感じで使えるみたいです。 ありがたいことに閉会後gfxさんとお話する機会があり、 RESTful APIに対する利点として下記を挙げられていました。 クエリと返却値の形が似るように設計されており、制約があるためAPI設計がしやすい。 API consoleであるGraphiQLが使いやすい。 API設計がしやすいことは大きな利点だと思いました。 私は作ったことないのでわからないんですけど、 Web APIの設計って難しそうですよね。 もしRESTful APIで外部公開のAPIを作るならば、 他のWebアプリのAPI設計を見て、 あーなるほどこんな感じがわかりやすいんだろうなーじゃあこうする

7年前の僕はひとたび外に出ると何者でもないエンジニアでした。会社で周りよりも仕事を覚えてこなすのが少しだけ早い、会社の独自仕様に詳しい、それぐらいだったように思います。 ある日、自分が本屋に行ってふと一冊の技術雑誌を開いた時に、そこに書かれている技術はほとんどわからず、自分の得意分野の技術でさえ、社内でやっていることは当たり前のこととして書かれていた上で、さらにそれを高度に一般化し解決する技術が解説されていました。それを見た時に、自分の技術が単に社内独自の業務を経験的に知っているだけであったことになんとなく気付かされました。 ただ、この雑誌に書いている人は本当にプロフェッショナルな専門家なのだろうとしばらくは思っていたのですが、後に執筆陣も自分と同様に会社で働いているエンジニアであり、何も状況は変わらないことに気づき、その人達の経験に基づく一般化された知識とその応用力、それを可能とする視座