米国に移住して一年が経過した。正直なところ日本のほうがいいところはめっちゃある。特に生活面は、日本はホンマに素晴らしいと実感している。ただ「職場環境」は米国に圧倒的に負けていると思う。たとえ英語のハンデを背負ったとしてもこちらの方が圧倒的に快適だ。日本に一時帰国して感じた違和感とその分析、対処策について考えてみた。 日本で感じた「違和感」 日本を出た１年前と比べると、働き方改革の成果か、多くの人が日本の職場環境に疑問を抱くようになっていてそれはとても素晴らしいことだと思う。ただ、一方でインターネット上の議論を読んでいると、今まで圧倒的な「権力」を持っており、ある意味表面上は「尊敬の対象」だった「年齢の高い人」が「老害」や「昭和」などとバッシングされているのを見て非常に違和感を感じた。私も来年早々５０だし、昭和だし、日本に帰ってきたら年齢で就職できないから自分で会社やるしかないかなとかぼんや
Dockerで何が変わるのか - 世界線航跡蔵
DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
2018年の段階で私が知らないこと
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
2016/01/23 Cookpad TechConf 2016 http://techconf.cookpad.com/
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか？～サーバレス基盤上での評価～ / How fast does GraalVM's...Shinji Takao
フロントエンドエンジニア / バックエンドエンジニア / DevOpsエンジニア@poly_soft 先日2018年の最先端フロントエンドエンジニアになろうという記事を訳したのですが、そのリポジトリにはバックエンドとDevOpsのロードマップ画像も置いてあります。 しかしバックエンドのテキストにはTODOの1行だけで、動きがありませんでした。 解説が追加されないかなー、と思ってたら別の人がやってたのを見付けました。 ということで以下はModern Backend Developer in 2018の日本語訳です。 Modern Backend Developer in 2018 こんにちのWeb開発の様相は、数年前とは全く別物です。 Web開発には多すぎる選択肢があって何をすればいいのか迷います。 それが、これらのステップを視覚的に表し、段階的にWeb開発を行っていくためのガイドラインを作
とりとめもなく書いてみる。主にルーキー向けです。 サーバの運用とかやっていると、不定期ではあるが、たまにタイトルのようなディスク容量が逼迫する話題に直面します。 まぁ、それが起こるのは一旦良いとして、みんなこういう時、どうやって調べているのだろう？ とりあえず、僕がどうやってるか書いてみます。 何はともあれ現状確認 みんな大好き"df"コマンドです。細かい説明は省きますが、各パーティション・ファイルシステムごとにディスクの使用状況を確認。 # df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/sda3 130G 88G 36G 72% / /dev/sda1 494M 23M 447M 5% /boot tmpfs 12G 0 12G 0% /dev/shm正確とは言いませんが、だいたいどのパーティションにどのくらい容量が空いているかが確認できます。 ど
クックパッドを退職しました - 昼メシ物語
2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ
2013年3月19日 Tokyo Linux Study #5 #tlstudy の発表スライドです。 ZABBIX(赤) × Munin(緑) 。どうして両方を使う事になったのか？という話しがメイン。 サブタイトル「@zembutsuがホスティングサービスの監視パワーを強化しようとするけどとんでもないことになる話」
はてなで新しくWebサービスを作るときのインフラの作り方 - Hatena Developer Blog
この記事ははてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blogの17日目の記事です．昨日は id:yashigani_w の Promiseを学ぶためにSwiftでPromiseを実装してみた話 - yashigani?.days でした． こんにちは、はてなの id:wtatsuru です。はてなのインフラ全般をみています。 はてなでは、しばしば新サービスを構築する機会があります。正式サービスもあれば、はてラボ のような実験的サービス、内部の Microserviceの一部になっているものなど多種多様なものがあります。新規サービスのインフラを構築する際は、最小構成でありつつ後のスケールやメンテナンスを考えた仕組みを作っていくことになります。この記事では、2015年12月現在のはてなでの標準的な構成を紹介していきます。 新サービスの最小構成 こち
Free for Developers
Developers and Open Source authors now have a massive amount of services offering free tiers, but it can be hard to find them all to make informed decisions.
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話 - まいんだーのはてなブログ
はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動き AWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
2016/12/27 更新Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。 元旦に実施される うるう秒の対策 まとめ2016/07/08 更新2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新)下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの２バージョンはパ
背景 今月始めにMicrosoftからRemote Development Extension Pack. というのが発表された。簡単に言うと、VSCodeでコードを書くOSとプラグインが実行されるOSを別にすることが出来る。 よくあるパターンで、「MacでNokogiriがビルドできません」「WindowsでESLintを実行するにはどうしたら良いですか」みたいな質問がある。 最終的にサービスを公開するときにはどうせLinux使うのに、開発するときしか使わない別のOSで同じものを動かす苦労って無駄だよなあ、と思っていた。 じゃあ最初からLinuxで開発すればいいかというと、最近の高度化したWeb開発はIDEの支援なしに実行することが困難で、RubyだったらRuboCop、JavaScriptだったらPrettierやESLintで文法チェックしてもらわないと人類にはついていけない。これら
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
虚構新聞を支える技術｜nagisaworks
NagisaWorksでは時折世間を陥れる虚構新聞のシステム全般を担当しております。このシステム、様々な制約により少々ユニークなものになっていますので、今回このシステムについて少しお話をします。 まず制約条件/目標として以下が挙げられます。 1.とにかく低コスト 2.運用が虚構新聞社内のみで行えること 3.でもそこそこに速く 4.web/app両対応 1.とにかく低コスト 虚構新聞はSAKURA internetのサーバー、種別としてはさくらのレンタルサーバーを使用しています。 これは元々使っていたという理由からなのですが、新しいシステムでもそのまま使用することにしています。 ネットワークとしてかかる費用はこれだけのはずですので、とにかく安い。 PVの割にこれほど安いものを使用しているサービスも少ないかと思われます。 まぁケチっているわけでもなさそうなので、インカムの問題でしょうか。 2.
調整の心得 - クックパッド開発者ブログ
会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
Googleではこれまで、生産性が高く、働きやすい組織を作るために、従業員に対して大規模な調査を行ってきました。 その結果として、2009年には「Project Oxygen」として、最高の上司になるための「8つのルール」を定義しています。 ※1番から、重要だと思われる順に並んでいます。 ＜チームのパフォーマンスをあげる優秀なマネージャーの条件＞ いいコーチであること チームを勢いづけ、マイクロマネジメントはしない メンバーの成功に気を配り、積極的に関与する 生産的、かつ成果主義であること 良いコミュニケーターであること メンバーのキャリア開発を手助けすること チームのための明確なビジョンと戦略を持っていること チームにアドバイスできる技術的な専門知識を持つこと ※こちらから参照 Googleの強みは技術が優れていることだと思われていましたが、意外にも技術的な専門知識がマネジメント能力に及
![Googleが実践する「心理的安全性」の高いチームを作るためのマネジメント手法【5選】 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d8f800d33902f652b89eff8b8c1a04b77d6ca7da/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F06%2F08235622%2Frogo.jpeg)
モダンWebシステム開発
Qcon Tokyo2015 での発表スライド
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
この資料は「Kubernetes という名前ぐらいは知っているけど、実際には使ったことがない、何ができるのかよく知らない」という人を対象に、Kubernetes の基本的な使い方を説明しています。 この資料を読めば、Kubernetes 上に単純な Web アプリケーションをデプロイできるようになるはずです。
AIとAWSで現世から離れる試み-仕事がちょっと大変な時もあったりするから�俺のかわりにAIにシステム作ってもらえるシステム作った話.pptxJun Suzuki
はじめに 皆さんのログに対する理解はどんなものでしょうか？仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は？ ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
はじめに 自分がAWSをこれっぽっちも知らない頃、 ググって出てきたどこか知らんサイトからだと、「欲しい情報はこれじゃない」ってのが多くあった。 そんなこと繰り返していると エラー、トラブル時に即対応できない 間違って構築したせいで運用時に悪化してしまう 古いソースコードでエラーがでて動かない これで無駄な時間を過ごすことになる。 要は「ググって得たその情報で、作ったものは正しいのか？」 AWSは常にアップデートされ続ける 欲しい情報を手に入れるまで調べる時間を割くなら、 公式展開してるサイトから得たほうが正確である。 ということで、最速でAWSを攻略するサイトをまとめる。 この記事をブックマークでもしておくと、ググる手間も省けるだろう。 目次 AWSドキュメンテーション AWSサービス別資料 トレーニングライブラリ AWSブログ アーキテクチャーセンター ワークショップをする よくある質
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催されました。 国内企業のDevOps実践例から学ぶセッションで登壇したのが、クックパッドの成田一生氏。「迷ったら健全な方」というテーマで、同社におけるDevとOpsの良好な関係を構築する方法論を、Opsチームの責任者の視点で解説しています。内容をダイジェストで紹介しましょう。
【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
米国から一時帰国して「老害」がなくなるといいなと思った話 - メソッド屋のブログ
データベースアプリケーション開発を炎上させる負のスパイラル
Javaトラブルに備えよう #jjug_ccc #ccc_h2
2018年の最先端バックエンドエンジニアになろう - Qiita
Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々
サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
閏秒を迎えるにあたってLinuxでは何を対策すべきか？ | Act as Professional
VSCodeのRemote Development機能が革命的な話。 - Crieit
日本でアジャイルが流行らない理由 - @ledsun blog
ロギングベストプラクティス - kawasima
Googleが実践する「心理的安全性」の高いチームを作るためのマネジメント手法【5選】 | SELECK [セレック]
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
開発フロー研修 @ Wantedly - Qiita
Introduction to Kubernetes
Devsの常識、DBAは非常識
今さら聞けないログの基本と設計指針 - Qiita
分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
ググり時間をぶった切る。AWSを最速で攻略するサイト13選 - Qiita
自宅サーバのインフラ設計書を公開します - @int128
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita