Mar 5, 2016Download as PPTX, PDF4 likes3,970 views
Mar 5, 2016Download as PPTX, PDF4 likes3,970 views
2016年3月11日（金）に、『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 ＋α』というイベントに参加してきました。 @t_wadaさんの下記スライドが、今まさに自分がやっているテスト自動化支援・アジャイル支援のヒント満載だったため、どうしても直接お話を伺いたく参加した次第です。 『組織にテストを書く文化を根付かせる戦略と戦術』 http://www.slideshare.net/t_wada/test-strategy-and-tactics 以下、個人的に気付きがあった点のメモです。 戦略編（6-19ページ） 7ページ目 導入を目的にしてはいけない。 ついやりがち。 現実を見せ、現実に即した解決策で改善していくことになる。（伊藤） 11ページ目 文化を変えるのには、2-5年はかかるとのこと。 環境は変わり続けるので、コードに触れないわけにはいかない。 13ページ目 AS-I
皆さんこんにちは お元気ですか。私は元気です。 今日は前回の以下のページからだいぶ更新が立ち、Kaggleのコンペ的にも多くの開催がありました。 そこで、新しいページでリンクを纏めてみました。 中にはインタビューやフォーラム、githubなど様々なものが混合しているのはお許し下さい。 nonbiri-tereka.hatenablog.com Prudential Life Insurance Assessment 1st - 1st place solution - Prudential Life Insurance Assessment | Kaggle 2nd - Solution -- 2nd place - Prudential Life Insurance Assessment | Kaggle Homesite Quote Conversion 3rd- Homesite Q
Use multi-stage buildsMulti-stage builds let you reduce the size of your final image, by creating a cleaner separation between the building of your image and the final output. Split your Dockerfile instructions into distinct stages to make sure that the resulting output only contains the files that are needed to run the application. Using multiple stages can also let you build more efficiently by
※最初に断っておきますが、この記事はもちろん、このブログ全体もそうですが、私の個人ブログであって、会社の公式見解とは一切関係ありません 自分のチームや会社でGitHubを使いたいんだけど、チームメンバーにGitHubを使ったことのある人が自分以外いないよ、みたいなケースがあるかと思います。 そんな時に役立つリンク集を紹介しておきます。 英語のリソース GitHub Guides Mastering Markdown Mastering Issues Understanding GitHub Flow GitHub Training YouTube channel GitHub Services curriculum "Kit" GitHub for Developers GitHub for Everyone Pro Git 2 eBook GitHub Git Cheat Sheet P
参加してから既に1週間過ぎてて今さら書くの！って言われそうだけど，先週土曜に参加してきた「Docker Meetup Tokyo #6」のメモを残しておこうと思う．倍率2倍以上の抽選に当選できて良かった．去年夏にあった #5 にも参加してるし，Docker Meetup に関しては今回で2回目だった． dockerjp.connpass.com kakakakakku.hatenablog.com 資料 全てまとまってる場所は無さそうだけど，以下のソースからほぼ全て辿れる感じにはなっている． Docker Meetup Tokyo #6 - 資料一覧 - connpass 参加ログ::Docker Meetup Tokyo#6 #dockerjp | BOHE-Lab. Docker Meetup Tokyo #6 - Togetterまとめ ピックアップ 特に勉強になった発表をピックアッ
様々なAPIを利用していると、次第に自分でもAPIを作りたくなりませんか？ Rの関数を利用してHTTP経由でデータの受け渡しができると嬉しいですよね。加えて、Rの作図機能を使って、APIを叩くだけで作図してくれると超ハッピーですよね。 前置きも何もなく唐突ですが、{plumber}パッケージを使ってお手軽にRでAPIサーバーを構築できるヨ、という話です。{plumber}はまだCRANに登録されていないので、利用する際にはGitHubから開発版をインストールしてきてください。 🤔RでAPIサーバー? 「RでAPIサーバーを作る」という話自体は昨年末のJapan.Rでゴミ箱さんが話されていたのですが、運営側だったこともあってしっかりと聞けていませんでした（この記事を書こうとして、そういえばゴミ箱さんがRでAPIを作る、みたいな話していたよなというのを思い出した）。ゴミ箱さんの話の中でも{p
Graph analytics has a wide range of applications, from information propagation and network flow optimization to fraud and anomaly detection. The rise of social networks and the Internet of Things has given us complex web-scale graphs with billions of vertices and edges. However, in order to extract the hidden gems of understanding and information within those graphs, you need tools to analyze the
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
以下の記事内容について、奥一穂氏（@kazuho）より、「connectのエラーコードが信頼できなくなるといった欠点もあるのに透過 SOCKS プロキシが汎用的に良いように読めてしまう」というご指摘をいただきました。確かに、下記内容は当社が抱えていた複数の課題を短期間で解消できる「ワークアラウンド」として透過 SOCKS プロキシという技法もあることを紹介したものであり、NAT と比較して常に良いという主張をしたかったわけではありません。また、記事内では解説を省きましたが、従来より HTTP(S) 通信は NAT ではなく HTTP プロキシを利用しています。謹んで補足・訂正とさせていただきます。 猫が好きだけど猫アレルギーで近寄ることができない山本泰宇です。 先日アーキテクチャ刷新プロジェクト「Neco」を紹介しましたが、今回はその活動の一環として実施したネットワークアドレス変換(NAT
ユーザーファースト推進室 デザイナーの橋本（＠hashcc）です。 クックパッドでは、安定した品質のモバイルアプリケーションをユーザーさんに届けるために、デザインリリースマネージャ という試みを2015年秋頃から始めました。 今回はこの試みについて発端や成果などをお話しします。 「あれ、なんでこんなデザインになってるの・・？」 クックパッドには日々多くのコード変更が加わっています。そうした中でも品質を安定させる（クラッシュや機能破壊を起こさない）ために、テストエンジニアなどが取り組んでいます。 関連： クックパッドモバイルアプリの開発体制とリリースフロー 安定したリリースを継続するためのテストとテストレベルの話 デザイナーも「デザイン変更が伴う修正は必ずデザイナーがチェックする」というルールを作り、デザイン品質の安定化に努めていました。 にも関わらず、リリース直前/直後になって「あれ、なん
- SmartNews uses stream processing to deliver news quickly as the lifetime of news articles is very short. Kinesis Streams play an important role in processing user activity streams and metrics in near real-time. - Data is ingested using Kinesis Producer and Consumer Libraries and processed using Spark Streaming to generate metrics for ranking articles. Metrics are stored in DynamoDB. - An ETL wor
ハミルトニアンモンテカルロ法(HMC)の動作原理をアニメーションを用いて理解してみようという記事です。 先日の記事、「【統計学】マルコフ連鎖モンテカルロ法(MCMC)によるサンプリングをアニメーションで解説してみる。」の続編にあたります。 豊田先生の書籍「基礎からのベイズ統計学」の例題を使わせていただき、サンプリング対象の分布は今回ガンマ分布とします。本記事ではアニメーションに使った部分の理論的な解説しかしませんので、HMCの詳細な解説はこちらの書籍をご参照いただければと思います。 はじめに 推定する対象は$\theta$を変数としたガンマ分布です。ベイズ推定で推定したいパラメーターを$\theta$で表すので、$\theta$の分布として表されます。1 ガンマ分布はこちらです。 $$ f(\theta|\alpha, \lambda) = {\lambda^{\alpha} \over
リーン開発チームの亀山（ @kametec_jp ）です。最近のブームは、Kotlinです。 私が所属する開発チームでは、案件見積もりの際にプランニングポーカーを活用しています。 活用してるメリットとしては、見積もり段階でさまざまな観点（デザイナーやエンジニアやQA等）の意見を聞けるので、どのように仕様変更するのが工数が少なくリリースが可能かの議論する場として非常に役立っています。 ただ、何度も行っているうちに下記のデメリットが気になるようになってきました。 （1）ディレクターから「毎回カードを配ったり回収したりするのが面倒」という意見 （2）人数が多くなった際に、それぞれのポイントと意見を把握するのに手間取る 不を解消するべく要件を考える 1つの画面に全員のポイントを表示できる データを保持する必要がなさそうなのでDB不要、ログもためる必要なし サーバーを立てても良いけど、野良サーバーは
How does Netflix build code before it’s deployed to the cloud? While pieces of this story have been told in the past, we decided it was time we shared more details. In this post, we describe the tools and techniques used to go from source code to a deployed service serving movies and TV shows to more than 75 million global Netflix members. The above diagram expands on a previous post announcing Sp
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
MySQLではできないことができるデータベース(広義)達
自分は一応暫くMySQLの開発者だったので、MySQLでできることできないことはすぐわかる訳です。現実的な問題と対峙すること１年間、MySQLは使えることにしか使わないわけで、そうすると構築してしまうと、アラートメールが全く来ないので、水や空気のように存在を忘れてしまいます。でも、使えないことには全く使う気がしないわけで…。というわけでMySQLは結局逆にあまり触れていません。限られた範囲では完成を見ているというわけでしょうか。 データを処理して何か貯めて利用できるものをデータベースとするならば、MySQLを適用する気も起きないような領域があって、近年はそのような領域に挑む別の道具が出てきています。 今回は趣向を変えて、いろいろ現状MySQLでは扱えない問題の解決法を模索したことについて少し触れます。MySQLを離れた話題ですが、いつか遠い未来にMySQLの世界に持って帰る事柄かも知れませ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
