Into the Core - Squeezing Haskell into Nine Constructors by Simon Peyton Jones
Keynote talk from Erlang USer Conference 2016 http://www.erlang-factory.com/euc2016/ Erlang and Haskell are childhood friends who grew up together. Throughout the years, they have learnt a lot from each other. And just because they have become adults does not mean the learning stops. GHC translates all of Haskell into a tiny but super-expressive intermediate language called Core, does a lot of o
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
もはやウオーターフォールだけでは戦えない理由
もはやウオーターフォールだけでは戦えない理由：“黒船”たちがde:codeで語ったDevOpsの極意（1/2 ページ） 2016年5月24、25日に開催されたde:code 2016で、多くの参加者の印象に残ったであろう『黒船襲来! 世界DevOpsトップ企業×マイクロソフトによるトークバトルセッション』。そのポイントを、今あらためて振り返る。 日本においてはまだ、ウオーターフォールに代表される従来型の開発スタイルが主流となっている。これには日本企業やIT部門の慣習、ビジネス部門とIT部門、IT部門とSIerとの関係性など、さまざまな背景と必然的な理由がある。しかし、「全ての企業はソフトウェア企業になる」と各方面で指摘されているように、ソフトウェアがビジネスの成果に直結するケースが増え、開発・改善の「スピード」が差別化の要件とされている今、もはやウオーターフォールだけで戦うことは難しくなっ
「DevOpsは地道な改善活動」 エバンジェリストが語る、DevOpsの始め方（後編） | SELECK [セレック]
〜小さなリリースサイクルの見直しから始まるDevOpsの実践により、障害の発生率が1/60に、デプロイまでのリードタイムが1/200になることも 〜 「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編）では、DevOpsが誕生した経緯から、その本質までを伺った。DevOpsは技術的側面、組織的側面の両面から語られる必要があり、単純にツールを導入するだけでは実践しているとは言えないと、米Microsoftの牛尾 剛さんは語る。 しかし、ツールの導入だけでは解決しないとしたら何から始めていけばいいのだろうか。海外では既に大企業の多くがDevOpsを実践し始めており、日本企業との間には大きな差が開いてしまっている。後編の今回は、大企業でもDevOpsを実施できている理由、そしてDevOpsを始めるためのコツについてお伺いした。 海外では大企業もDevOp
![「DevOpsは地道な改善活動」 エバンジェリストが語る、DevOpsの始め方（後編） | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/cd2fa98f120ab45c671e64b671ecaf7105dd80df/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2016%2F03%2F16152053%2Fc13b1b09-5219-4693-ad6f-05e217b07d50.jpg)
「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編） | SELECK [セレック]
〜「1日に10回デプロイできる環境があること」が「DevOpsが出来ていること」の証明〜 DevOpsとは、開発担当者と運用担当者が協力しソフトウェアライフサイクルやビジネス価値の創出を改善する活動である。 しかし、その定義自体があいまいなこともあり、「何を実現することがDevOpsなのか」という理解は人によって様々である。国内でも、数年前から流行の兆しを見せているが、本当の意味でDevOpsを理解し、実践できている企業はいくつあるのだろうか。 「日本ではツールだけを導入して DevOps を導入したことになっていることも多い」と語るのは、米Microsoftの牛尾 剛 さんだ。DevOpsのエバンジェリストとして、導入支援やイベントの開催などを行い、技術的な側面と組織的な側面の両方から正しく理解させるための活動を行っている。 前編の今回は、DevOpsが生まれた背景から、本質的に理解して
![「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編） | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/173c6430e45374a985fd6aafeb4da4c5f3266ca3/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2016%2F03%2F16153706%2F983e7a78-f848-4cc8-afbb-bc6e60b69575.jpg)
新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ
以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バリューストリームマッピングはソフトウェア開発でも有効か？