パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。
![ログイン - はてな](https://cdn-ak-scissors.b.st-hatena.com/image/square/aae41a7eff84391fead5dded32138f669a1d3e24/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Finfablic%2F20170926%2F20170926103653.jpg)
民法債権法改正が国会で成立し、品質保証が請負やサービスなど、全てに適用されるようになります。私達が、普段、商品や食品に対して品質保証を求めるように、Webサイト制作や、Webサービスにも品質保証が要求されるのです。「自分達を損害賠償から守るために品質保証をしなくては」というよりも、「自分達の仕事の価値、提供するサービスの価値を高め、差別化するための品質保証」として積極的に活用しませんか?今まで、「テクニック」として語られる事が多かった「Webパフォーマンス」ですが、「品質管理」として本気で取り組みませんか? このセッションでは、Webサイト制作や、Webサービスの現場で、DevOpsの三本柱の一つである「品質保証」を実行していくために必要な、Webパフォーマンス管理・改善に必要な基礎知識を解説します。 HTML5 Conference 講演資料
今週,社内で「技術的負債」をテーマにしたイベントがあり,トーク枠で発表をしてきた.タイトルは「技術的負債を "なるべく" 作らないためのコツ」で,意図的に技術の話をせずに,エモ系のストーリーに仕上げた. 特に伝えたかった部分は最後の「組織パフォーマンス」を改善する Tips で,雑談の重要さ,質問の重要さ,相互理解の重要さ,表情の重要さなどを語った.その中でも「ノンバーバルなコミュニケーション」の Tips はイベント中も気になっていて,発表者がもっと気持ちよく話せるように反応しましょー!と,緊張をほぐすようなアプローチもした. もっと「組織パフォーマンス」を改善していきましょ!!! 発表資料 関連記事 「組織パフォーマンス」を改善する Tips はコーチングの文脈からもインスパイアされていて,コーチングを学ぶならまずこの本から読むのが良いのではないかなと思う. kakakakakku.h
AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
こんにちは。アプリエンジニアの五味です。 2017年4月にリクルートホールディングスの新卒Web採用枠で入社した新卒社員のうち、21名がリクルートテクノロジーズに配属となりました。(いらっしゃい!) リクルートテクノロジーズでは「ブートキャンプ」と呼ばれる新卒社員向けの技術研修を3か月間実施しています。 もともと高い能力を持つ彼・彼女らですが、「これからのリクルートをリードしていく存在」になって欲しいという期待を込め、プロとしての重要な立ち上がり期を支援しています。 今年からは社外講師の既存プログラムに加え、より実践的な内容を求める経験者をターゲットに、総勢12名の現場エンジニアが担当する特別講座を開催しました。 各分野のスペシャリストがこれまで現場で培ってきた「本当に必要な生きた知識・技術」のインプットは、彼・彼女らの成長を加速させ、これからのエンジニア人生の礎になってくれるものと僕らは
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Docker と Amazon ECS で DevOps を進化させる 6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 の Develoeprs Confrence のセッション「Docker と Amazon ECS で DevOps を進化させる」を聴講しました。本記事はそのレポートです。 コンテナ技術である Docker と、Amazon EC2 のクラスタ上でコンテナを管理できる Amazon EC2 Container Service (ECS) を利用することで、アプリケーションとインフラという2つの密結合したライフサイクルの管理から脱出し、新しい DevOps へと向かう方法、及びその事例をいくつかご紹介します。 スピーカーは 岩永 亮介 氏(アマゾン ウェブ サービス ジャパン株式会社 技術本部 メディア・エンターテインメント部
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す(現在 Early Relase 版や Free Chapters が入手できる)ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
最近プロビジョニングにchefよりansibleを使うことが多くなってきて、その都度コピペもあんまりよろしくないので、ベストプラクティスにそった雛形を自動生成するスクリプトを作成しました。 github.com 環境 serverspec (>= 2.17) ansible (>= 2.0.0) python (~> 2.7) 使い方 usage: ansible-init [-h] -p PLAYBOOK_NAME [-b BOX_NAME] [-i IP_ADDR] [-m MEMORY] [-c CPU] オプション optional arguments: -h, --help show this help message and exit -p PLAYBOOK_NAME, --playbook_name PLAYBOOK_NAME playbook name -b BOX_NAM
技術的課題を書くと、それを解決してくれるエンジニアが採用できるって話は本当ですか?というのは冗談としても、今の技術的課題をブログにまとめて公開するノーガード戦法も良いかと思う。— Kazuyuki Honda (@hakobera) May 25, 2015 このツイートがそれなりに反応があったので、有言実行してみる。 最初に書いておくと、これはQuipperの採用のための記事です。Quipper では下記のようなお仕事、技術的課題の解決に興味がある DevOps エンジニアを絶賛大募集しております。興味のある方は、Wantedlyの募集ページ から「話を聞きに行きたい」をクリックしてみてください。応募までは行かないけど、もっと詳しい聞いてみたいという方は私個人にでも良いのでご連絡ください。(Twitter で @hakobera にメンション or DM、または hakoberaアットg
Home > Ansible | AWS > Ansible で EC2 インスタンスを起動して、Route53 に Public DNS を登録する Ansible は、構成管理ツールとして認知されていますが、AWS 関連のモジュールが多数実装されており、各コンポーネントの起動や設定ができます。 このエントリでは、Ansible で、検証環境用の EC2 インスタンスを起動して、その Public DNS をRoute 53 に登録してみます。 以前書いたこのエントリの内容 を Ansible で自動化するイメージですね。 準備 今回は、AWS を操作するので、Python の AWS SDK である boto をインストールしておきます。boto は、pip なり、yum なりでインストールできます。 OSX $ pip install boto RHEL / CentOS $ rpm
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く