ChatWork社内勉強会で発表した際の資料

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ

(編注：2016/5/31、頂いたフィードバックを元に記事を修正いたしました。) larry wall 怠慢と勤勉 コンピューティングにおいて、”laziness(怠惰)”は幅広い意味の単語です。大抵は、もし必要が無ければ何もしないということを意味します。その正反対を指すのは”eager(勤勉)”です。後で必要になる場合に備えて、できるだけ働くということを意味します。 以下のJavaScriptを見てみましょう。 function ifThen (a, b) { if (a) return b; } ifThen(1 === 0, 2 + 3) //=> undefined ここで、問題です。「JavaScriptは 2+3 を評価する？」答えはお分かりですね。「評価する」です。呼び出し関数に、引数を引き渡すこととなると、JavaScriptは eager(勤勉＝先行評価) で、式の全てを

佐々木です。クラスメソッドも4月から新しい仲間が増えました。今日はWAF(Web Application Firewall)の基本的な知識を整理してみました。 基礎知識 WAFとは WAF(Web Application Firewall)とは、Webアプリケーションの脆弱性を狙う悪意ある通信(攻撃)から、Webアプリケーションを保護するものです。本来論で言えば、Webアプリケーションに脆弱性があるのであればWebアプリケーションを修正するのが正しい対応です。しかし未知の脆弱性があったり、修正コストが大きくWebアプリケーションでの対応が難しい場合や、緊急度が高くすぐに防御しなければならないが修正が間に合わない場合も、残念ながらあります。ユーザーとWebアプリケーションの間にWAFを入れることで、悪意ある通信を防ぐことが出来ます。 ファイアウォールとは ファイアウォールは、IPヘッダやTC

書いていないネタは多いのですが、アンケートで C# についてと言われました。 次なんの記事がいいですか？ #書く記事募集中— guitarrapc_tech (@guitarrapc_tech) April 23, 2016 そこで、私自身 C# を学ぶにあたって参考にしているものをまとめておくことことにします。*1 はじめに感謝と尊敬を。ここに載せていないサイト、書籍の多くからも学びも得ています。今現在もそうです。 私自身が何か恩返しをできればと思いつつ、同じように悩まれている方への参考となれば幸いです。 目次 目次 個人ブログ Microsoft関連 困ったときの まとめ 個人ブログ 順番には大きな意味はありません。 サイト ブログ主 参考にしている分野 備考 ++C++; // 未確認飛行 C ++C++; // 管理人: 岩永 (@ufcpp) / Twitter C#, プログラ

* for PHPBLT #4

前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((

1 はじめに 下記のページでは、Xamarinが異常に早いことをレポートしています。 Mobile App Performance Redux テストの内容によって色々あるとは思いますが、Xamarin.iOSが、Objective-Cより早く、Xamarin.AndroidがJava Androidとほぼ互角と言うのは、正直すごいグラフだと思いました。 少なくとも、XamarinがObjective-CやJavaのコードを吐いているわけでは無いことだけは直ぐに分かります。 今回は、Xamarinが、どういう仕組みでiOSやAndroid上で動作しているかを可能な限り簡単に紹介したいと思います。 っと、偉そーに言ってますが、実は、これちゃんとした公式の資料を基づくものでなく、私が勝手に解釈している内容ですので、専門家からのツッコミを得て完成するエントリーと意味で投稿させて下さい。 [201

こんにちは。エクセルソフトの田淵です。 Visual Studio 2017 がリリースされましたね！Visual Studio のインストール記事を書きました。 ytabuchi.hatenablog.com 10分でわかる無料になったXamarin from Yoshito Tabuchi 今は Visual Studio 2015 でもすごく良くなっていて、普通にインストールして普通にビルドすると、Android SDK は追加で入れないといけないかもですが、恐らくビルド通るはずです！ ytabuchi.hatenablog.com 一応記事を残しておきます。 見てらんない… どうやら、ニュースを見て Xamarin を触ろうとしてくださっている方々が大変苦労されているようです。 2016/4/9 ピックアップさせていただいた以下の 3名は皆さん問題が解決して快適な（？）Xamari

私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時

#CookpadTechConf 2016 での、 クックパッドでのユーザファーストについての考え方を、 技術と組織の二つの点から話した発表資料です。

会場に1,000人が集まった「GitHub Universe」 オンライン視聴者を含む延べ人数約15,000人が参加した「GitHub Universe」。そのほとんどがエンジニアなのかと思いきや、登壇者のリストを見てもわかるように、今ではNPOや自動車メーカー、NASAなど様々な企業やプロジェクトがGitHubをコラボレーションツールとして活用しています。これまでにGitHubが使われたプロジェクトの総数は、2,700万件に及びます。 2012年、世界有数のベンチャーキャピタル「Andreessen Horowitz」の共同ファウンダーであるマーク・アンドリーセン氏は、“Software is eating the world”と予見しました。それが今まさに、GitHubのような立役者のもとで現実のものになりつつあります。ソフトウェアが世界を食い尽くしていく。 「これからは、全ての企業が

Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による

最近 Java で web アプリケーションを開発しようと思って、アプリケーション構成やら開発環境周りやら悩んだりしていたのだけれど、ある程度良さそうな構成に落ち着きつつあるので現状をメモしておく。 アプリケーション構成 とりあえず HTTP 周りは JAX-RS に任せるのが良さそう。 JAX-RS 実装としては Jersey を選択。 JBoss RESTEasy とかも試してみたけど、JAX-RS の参照実装ということもあって Jersey は癖が少なくて使いやすいのかなーと思ったりした。 Web 上の情報も多そうな気がする。 JAX-RS 2.0 Jersey 2.4 Servlet コンテナ内で動かすことを想定 ビルドツールとしては Gradle を選択。 IDE との連携を考えると Maven の方が有利かなーとも思ったけど、実際 Eclipse と NetBeans で試した

ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん