TDD of Infrastructure as Code on CircleCI 2.0
概要Docker + Ansible + ServerSpec + CircleCI 2.0でTDDなCIビルドを行う話です。 今僕が在籍している企業では、プロビジョニング周りはAWS OpsWorksで管理されており、Chefのカスタマイズレシピが適用されて、ポンっと環境が構築されます。 個人的にはChefとItamaeの運用はしたことがありますが、OpsWorksを除けばAnsibleの方がStar数も多く活発に使われていそうなのと、どうせならDockerとServerSpecを使ってポータブルなテスト環境を作ってみよう、それをCircleCI2.0で効率的に回そう、と思い立って、やってみました。 ディレクトリ構成. ├── Dockerfile ├── README.md ├── ansible │ ├── ansible.cfg │ ├── ci.yml │ ├── circlec
コインチェック事件は『対岸の火事』ではない
私は創業してからおよそ２年のベンチャー企業を経営しており、CTO兼唯一のプログラマだ。私含め3人の共同創業者と、多くの支援者の力により、これまで自己資本でなんとか開発を続けてきた。 先日、私達の会社は大きなマイルストンを迎え、サービスをβ公開させ、これから大きく勝負に出ようと思っていた。その最中、今回のコインチェック事件が発生した。 私達が行う事業は暗号通貨とは全く関係が無いため、本来であればこれは『対岸の火事』だ。しかし、総額580億円という被害額を生んだ今回の事件は、暗号通貨市場だけでなく、スタートアップ界隈全体へ影響を及ぼすことが容易に想像される。 事件の余波今回の事件で最も強く感じたのは、技術の力で新領域を切り開くスタートアップ企業こそ、時には成長を犠牲にしてでも、技術的安全性・信頼性を優先するべき、ということだ。 顧客にリスクを押し付けることが絶対に起きてはいけないし、少しでも顧
良い業者と悪い業者の判別方法
ある人に教えてもらって、間違いないなぁと感じたのでメモしておく。 悪い業者「なんでもできます！頑張ります！」 わかってないで返事してる。結果できない。 まぁまぁの業者「社に持ち帰って検討させて頂きます！」 持ち帰った結果わかってるヤツが返事くれるかもしれない。 良い業者「それは技術上難しく、またコストが余計にかかるため、その方法を実現するにはこちらの方法を選択するべきです」 現場の人間がちゃんと来ていて、かつできることとできないことを適切に会話できる。 という話。
８年で５つのスタートアップを経験したエンジニアがもうスタートアップをやらない理由
このノートは昨年、お世話になった方のために近況報告としてまとめました。 株式の取り扱いなど含めて整理できてなかったので、各方面にご挨拶できておらず申し訳ございませんでした。詳しい理由については個別に連絡させて頂きます。 Thank you Startup, And Good By. ２０１６年２月に１年間取り組んでいた、スタートアップを辞めました。そして、このスタートアップを最後に自分がスタートアップをすることはもうないと思います。 代わりに、スタートアップとは呼べない地味な事業を始めます。発達障害の人にプログラミングを教えるという地味で大変で面倒な事業です。IPOもEXITも目指しません。 http://camp-fire.jp/projects/view/5... この決意に至るまでの道筋を整理する上で、 今までの人生の中で関わったスタートアップとそこで学んだことを整理し、 そして何故
Migrating from AWS to AWS
This is a story about how we migrated from AWS Elastic Beanstalk to a Terraform + Consul + Nomad cluster in AWS EC2. Some backgroundPDVend started using Heroku. It’s a very nice option to startups, since you just deploy your application, not having to deal with complex infrastructure concerns and huge CI/CD flows. When you need to get bigger, there will come a time that you’ll realize that Heroku
オライリーから「仕事ではじめる機械学習」が出版されます
どういう本なの？まえがきのスクリーンショットを貼りましたが、この本は多くの機械学習の本とは異なり、機械学習の実務で使えるようになるために知りたい、機械学習を含めたシステムのアーキテクチャや機械学習プロジェクトの進め方、効果検証をどうするのかということをまとめました。 めざすところのイメージ既に多く刊行されているTensorFlowやChainerでディープラーニングをしてみようというものでもなければ、機械学習の理論をわかりやすく解説するといった類のものでもありません。ゼロから作るDeep LearningやCourseraのMachine Learningで学んだけど、実際の仕事に活かすにはどうしたら良いだろう？という疑問に答えているつもりです。また、大学の講義などで機械学習は学んだけど、実際仕事で機械学習のプロジェクトを進めるときはどうすればいいんだろう？という人にも得るものがあると思い
フロントエンド開発の概要について
ここでは、フロントエンド開発の概要について説明していきます。 ＊元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
NPM Task Running Techniques
Task running — it’s not sexy, but it makes the world go ‘round. — Madonna Updated 11 Oct 2017: Thanks to for their feedback on handling never-ending processes. I’ve updated the last section accordingly. BackgroundAs a software engineer, I use software to automate boring tasks. If I can’t find an existing software tool to do what I need, I can write my own. In the NodeJS ecosystem, this is as simpl
エンジニア採用面接の難しさ
エンジニアを採用していく中で「採用面接」は非常に難しい問題と言える。 経験上、今までかなり多くの面接をこなしてきたが、未だに「完璧な面接」というものにはほど遠い。 60分といった短い時間でお互いを知るには時間が足りない。 また面接は「お見合い」であり、極々短い時間の間にお互いに「相手と結婚するか」を決めなければならない。 失敗するとお互い不幸なことになることが解っているのにもかかわらず。 ……とはいえ、数百回と繰り返してきた面接の中で見えたこともあり、それを書いていくようにする。 主にゲーム関連のエンジニアを対象にしてきたケースが多いが、領域としては、クライアント、サーバ、インフラと一通りの人を見ている。 担当したプロダクトに使われている技術をどれくらい理解しているかを尋ねる
config/routes.rb の書き方を見直した – r7kamura – Medium
開発を手伝っている Rails アプリの config/routes.rb の書き方を見直した。 ルール以下のようなガイドラインを設け、これを守るように書き換えた。 resource(s) などの DSL の利用を避けるパスの辞書順に定義するHTTP メソッドの部分だけ特別にインデントする具体例こういう形の、素朴なルーティングがひたすらに羅列されていくコードになる。実際のコードでは数百行以上に及ぶ。基本的に1行に1つのルーティングが定義される。 MyApp::Application.routes.draw do get '/' => 'top_pages#show', as: :top_page delete '/api/applications/:applicaiton_id' => 'api_applications#destroy', as: :application get '/a
成長期のベンチャーにおける採用の失敗 – Isoparametric – Medium
成長期のベンチャーにおける採用の失敗2011年2月「任侠道」などのゲームがヒットし、売上が伴ってきたとき、それは終わらないマラソンが始まったことを意味していた。 そして、以後横展開した「道」シリーズがヒットを飛ばしていくために、様々な問題が噴出し始める時期である。 プロジェクトを広げようにも、どのプロジェクトも人が足らない。 加えてエンジニアだけではない「初期の頃のメンバー」が退職を重ねていく時期でもあった。 バックオフィスも開発も、見よう見まねでやっていたところに経験者が入ってきて、ポジションが入れ替わるようなことが頻繁に起きていた。 「自分の好きだったgumiは死んだ」というような事を言って辞めていく人たちもいた。 開発現場でも、のんびりと仲良く売れないゲームを運営していれば良い時代は終わってしまったのである。 「任侠道」が明確なヒットを飛ばしている傍らで、のびのび結果のでないプロジェ
CTOと技術執行役員就任 – Isoparametric – Medium
CTOと技術執行役員就任会社の最も大きな課題であった「ゲームが売れていない」は解決し、それぞれの技術的な課題も解決できないほど大きなものではなかった。 しかしながら、そうしてゲームを高速に水平展開することを進めていく中、ヒットゲームの運用ノウハウを持っていないために、チームは疲弊を溜め込んでいた。 運用の仕組みをつくる前に運用が始まって負荷が急上昇したのだから、必然とも言える。 速度が必要とされるソーシャルゲームでは、ゲーム内イベント開始の前日に正式なグラフィックが出来てきて、テストプレイしたら修正依頼が入り、直前であっても修正を余儀なくされるということが頻発していた。 朝７時に始まるイベントをギリギリまで開発していて夜中の２時に「これは無理だな」といって延期のお知らせを出したことさえある。 また、積み重ねがないため、障害時のトラブルも頻発していた。 夜中だろうと何だろうと、たった一人しか
崖っぷちからの生還 – Isoparametric – Medium
崖っぷちからの生還気がつけば会社は売上がない状況なのにもかかわらず社員は100人を超えようとしていた。 計算すればわかることだが、100人の給与を払うことを考えるといかに安い給料だとしても100人×60万（保険、税金や間接費含む人件費）として、月に6,000万かかる計算である。 100人の組織を毎月維持することはメチャクチャ大変なのである。 安定的に月に6,000万の利益を出せるサービスを作ることは並大抵の話ではない。 会社は2009年に複数社から7,000万を調達していたわけだが、それが１ヶ月ちょっとで溶けてしまうレベルだ。（だから、普通は売上が立つまで組織を拡大しない） が、國光さんはそういう意味では凡人ではなかったといえる。 そして、その頃に丁度ホットだったのが、Mobage、GREE問題である。 どの会社もどちらのプラットフォームにゲームをリリースするかを考えていた時代だ。 （個人
知らないうちにどんどん人が増えていく会社 – Isoparametric – Medium
知らないうちにどんどん人が増えていく会社gumiに入って一ヶ月か二ヶ月が過ぎたころ、チームに所属して様子を見てみると、gumiには一ヶ月の間にかなりの多くの人（5人とか10人とか）が入ってくるのに気がつかされた。 幾つかのチームが組成され、それぞれがゲームを開発、運用しており、解析班などと呼ばれるようなチームもあった。 （そして、それは機能していなかった。売れてないのだから、解析する内容などあるはずもない） そして、入ってきたプログラマは時折適当にプロジェクトにアサインされたりした。 私のチームにも新しいプログラマがやってきたわけだが、そのことを切っ掛けに、うやらプログラムがまともに組めない（仕事を任せられない）人が入ってきていることに気がつかされることになる。 困ったので当時のCTOにどういう基準で人を採っているのか訊いてみた。 特に基準はない、みんな頑張ればできる、とのことだったので、
株式会社gumiを退職して2年が経った – Isoparametric – Medium
株式会社gumiを退職して2年が経った株式会社gumiを辞めてから2年が経った。 なので、あの頃のことを少しずつ書ける範囲で書いていくとみんなの役に立つんじゃないかなということで、書き始めてみる。 私がgumiに入社したのは社員数40人くらいのときで、正直よく考えてgumiに入った訳ではない。 「ソーシャルアプリ開発現場の今」というイベントで見かけた國光さんが夢を語るのが面白そうだったり、Pythonを使っていることが面白そうだったり、gumiというSNSは800万人もユーザーがいるというのを見て面白そうだと思ったからだ。 800万人もユーザーがいるなら、面白いことができるだろうという漠然とした期待もあった。 しかし、登録数とDAUは決して一致しないという悲しい現実がそこになあるのだった。 そういえば、面接の時に國光さんがアバター（映画）がメチャ凄いという話をしていたのを今でも憶えている。
Pythonの環境構築を自分なりに整理してみる
機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python に… 私の立ち位置もともとは、数年前まで 年に一回Python3でNLTKやらscikit-learnやら機械学習や自然言語処理の環境を作ろうと試みては失敗してPython使うものかと思っていた人でした。それが、Anacondaで環境導入すると、面倒なことは何も考えずに済むということを知り、CookpadではAnacondaを前提に環境構築を勧めていました。 今は、ymotongpooに「郷に入っては郷に従え」と言われたため、pip+virtualenv/venvで全てをこなしていますが、これで困ったことは特にありません。macOS, Windows, Linuxそ
Docker Cheat Sheet
DisclaimerThis content is part of / inspired by one of our online courses/training. We are offering up to 80% OFF on these materials, during the Black Friday 2019. You can receive your discount here. I’ve been using Docker for years now, in my previous professional experiences and for my company (eralabs.io) customers and I wanted to share my knowledge, that’s why I started Painless Docker Course.
サポートエンジニアが読む「医療とコミュニケーションについて」
「レジデント初期研修用資料 医療とコミュニケーションについて」を読みました。これは、内科医である筆者が視点を医療現場に置きつつ、普遍的なコミュニケーションの技術を紹介する一冊です。 普段、ソフトウェアのプロダクトサポートを生業としている自分にとって、顧客とのコミュニケーションは避けて通れません。顧客が報告してくる問題をいち早く解決するのは当然の業務ですが、その過程におけるコミュニケーションのあり方についても常に向上させる必要があるのです。特に、サポート契約を継続してもらうことで大半の利益を得ているサブスクリプションビジネスにおいて、問題に遭遇した顧客に、満足したと思える体験を提供するのは至上命題ですが、難しいのも事実です。なぜなら、サポートエンジニアは問題を解決して当然、と思われるのが常からです。 本書で取り上げられる、内科医として患者とどうコミュニケーションすべきか、という技術は私たちの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Emacs実践入門 出版記念イベントで話したこと
Simplified User Management for AWS