Microsoft の開発も最初から DevOps だったわけではありません。地道に 1 つ 1 つの技術や手法、組織の変更が積み重なって、今のような開発スタイルになっています。この投稿では Azure DevOps という Microsoft の DevOps の根幹となっているツールの開発チームが、どのように環境を DevOps にトランスフォームしてきたか紹介します。 DevOps についてはいろいろ議論があるところです。「ツールだけ揃えてもカルチャーが変わらなければ DevOps じゃないよね」とか「CI/CD してるだけで DevOps してるとか言ってるよ (笑)」とか。 個人的には、日本の Waterfall がメインの IT 業界 は、なかなか DevOps というか Agile の世界にも行けていない現状があるので、あるべき論よりも「とりあえず何か 1 つやろう。」という
qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの?という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
およそ一月前くらいに、同僚の id:hitode909 さんとモブプログラミングをやってみようということになった。 hitode909さんとはチームは別なのだけれど、最近週一で別チームに行ってペアプロなどをしつつ、知見の横展開や課題の発見などをやろうという試みをされていて、ではせっかくなので、と自分たちのチームに招いて軽くお試しでモブプロをやってみた。 blog.sushi.money モブプログラミングとは、ペアプログラミングをチーム全員にまで拡大したようなもので、1つのプログラムをプロダクトオーナーも交えたチーム全員で取り組む形式である。 セミナールームにエンジニア8人ほどで集まって、大画面ディスプレイにソースコードを共有しつつ、「コードを書く人(ドライバ)」と「それ以外の人(ナビゲータ)」とで1つの課題に取り組んでいく。 実装をチーム全員で取り組むため、知見が共有できたり、設計上の課
Chrome の Developer Tools→Network→Timing にはリソース取得の各ステップにかかる時間が俯瞰できるようになっていて、このデータへアクセスする JavaScript API も用意されている。 諸般の事情により、これと同等のデータを cURL を使ってコマンドラインから取得する方法をメモ。 というか、必要なことは次のブログにまとめられている Timing Details With cURL https://josephscott.org/archives/2011/10/timing-details-with-curl/ cURL デフォルトの出力 cURL デフォルトの表示は以下のようになる(レスポンスデータは -o オプションで /dev/null に捨てる) $ curl -o /dev/null http://www.nasa.gov/images/
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」(後編)~DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催、海外から来日した多くのゲストスピーカーによるセッションが行われました。 (本記事は「GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」(前編)~DevOps Day Tokyo 2013」の続きです) チャットを共有のターミナルとして使う 次は「Hubot」について。HubotはJavaScriptで書かれていて(注:Node.jsを用いたサーバサイトJavaScript)、メッセージを受けてその内容に従って動作します。僕は何か問題があるとHubotのせいにしています(笑) ターミナルをシェアす
(おおきいの - http://storage.osdev.info/pub/idmjt/diaryimage/1405/neta140509l1.png ) ETW(Event Tracing for Windows)を使用するとDTraceやftraceのようなスケジューリングトレースを(比較的低いオーバヘッドで)取得することができる。ETWのログビューアとしてはWPA(Windows Performance Analyzer)が提供されているので、直ぐに内容を検証することができる。 ↑では、BoehmGCのparallel markを有効にしたnmoshでR6RS test suiteを実行し、GCが動作したところをズームしている。ポインタが指している部分がメインスレッド(TIDが一番若い)で、残りがBoehmGCが起動したGCスレッドとなる。実際には、メインスレッドもGC動作を行う
(Photo:Event: Meet The Media Guru | Cory Doctorow by Meet the Media Guru) 最近、開発チーム内でQiita:Teamを導入し、情報共有・コミュニケーションが目に見えて活性化してきています。 自分の作業ログにもなるし、同時にメンバにもシェアでき、さらにはいいねやコメントなどでフィードバックを得られるので、最近は何でもQiita:Teamに書いています。 個人的に気にっている点をご紹介します。 情報発信するモチベーションがわきやすい Markdownで手軽かつ綺麗に記述できる 簡単なMarkdownによって、整形されたドキュメントを素早く作成することが可能です。 入力フォームも、タブでインデントされたり、自動補完されたりと入力の手間を軽減する仕組みも多く実装されています。 macでは、kobitoというクライアントが用意さ
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
2014.03.24 働き方 エンジニアにとって、本当に「働きやすい環境」ってどんなのだろう? という疑問を解消すべく、組織づくりや職場環境に秀でたTech企業にインタビューを敢行するこの企画。インタビュアーは、エンジニアのためのポートフォリオサイト『Forkwell』や、エンジニア目線の求人・転職サイト『Forkwell Jobs』を運営する株式会社garbs取締役おおかゆかさん。エンジニアが「幸せに働ける職場」のあり方を探る! 株式会社garbs 取締役 Forkwellプロダクトマネージャー おおか ゆかさん 関西学院大学経済学部を卒業後、独立系SIerを経てインフォシーク社に入社。楽天による買収後も含めて、インフォシークのログイン周辺機能や各種コミュニティサービスの開発を担当。その後フリーランスとして活動、業務委託で入ったgarbsで提案したエンジニアのスキルマッチングの企画が採用
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
2012年12月25日火曜日 Web開発を革命する(かも知れない)Web Componentsという仕様について Web Componentsは、現在のところ余りまとまった日本語の情報がないようですが、Web開発を大きく、本当に大きく変える可能性を持つテクノロジーです。 Web Componentsは、現在のWebが抱える大きな問題点を解決する手段としてW3Cで仕様が策定中です。仕様策定を主導しているのはGoogleで、現時点ではGoogle Chrome(WebKit)がWeb Components(の一部)を実装している唯一のブラウザです。 Google Japanのエンジニアも、Web Componentsの実装には深く関わっているとのことなので、そのうち日本語の情報も充実してくると思われますが、本エントリはそれまでのつなぎ、ということで書いてみたいと思います。 しかし、Web Co
クックパッド株式会社様で開催されたchanko勉強会に行ってきました。 chanko: https://github.com/cookpad/chanko chanko以前は、本番サービスとは別の閉じた環境(社内のテスト環境のような)を作って新機能などの仮説検証を行うという、普通の開発スタイルであったのが、 本物のユーザからのフィードバックを得ることで、より正確な仮説検証を行う また、その際に実験的機能が他の機能に影響を与えることのないこと を可能とするために、chankoが開発・導入された。これによって、速く、正確な仮説検証サイクルを回せるようになったとのこと。このあたりは、まさに『リーンスタートアップ』にしつこく語られているような内容で、それを、書籍刊行以前から開発・導入していたのはすごいなと思う。単によりよいプラクティスを実践していたら、それがいつの間にか名前をつけて呼ばれるようにな
新年明けましておめでとうございます。本年も宜しくお願いします。 さて、今年最初のPOSTは、僕が今一番興味を持っているAPIの "Web Intents" について取り上げます。 この、"Web Intents"は、Androidの "Intent" に非常に良く似た仕組みで、異なるWebアプリケーションを自由に連携することを可能とするAPIです。Webサイトの不足機能に対し、他のWebアプリの機能を利用することが可能になるため、スピーディーなWebアプリの開発を実現してくれます。利用するユーザーにとっても、手慣れたWebアプリを利用できるメリットが有ります。 このAPIの更に興味深いところは、 Device機能の利用 デバイス内の固有の機能(カメラや、住所録など)をブラウザから利用する。 Web of things スマートフォンやテレビなどのマルチデバイス連携サービスをWebで実現する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く