Nobi Hayashi 林信行 @nobi Gmailの乗っ取り(!?)被害にあった方は誰でも疲れてて間違うことはあるのであんまり謝らなくていいので、何をやっていて乗っ取られたのか、もし心あたりがあってわかっていれば、それをハッシュタグ使って共有してもらえれば被害減らせそう。タグはこんな感じ?→ #GmHackHigai
はじめまして!Ameba事業本部プラットフォームDivでアプリケーションエンジニアをしている池田(@yukung)です。 私は2011年5月に大手SIerから転職し、サイバーエージェントへ入社しました。前職では主に金融業界をターゲットにしたBtoB向けのシステム開発に多く携わってきましたが、開発作業の中でこんな経験を割とたくさんしてきました。 ・ソースコードやドキュメントの管理にバージョン管理ツールを使わずに、Hoge_yyyyMMdd.javaとかDB設計_yyyyMMdd.xlsみたいなファイル管理をしてどれが正しいドキュメントかわからなくなりカオスになる ・ソースコードの静的チェックツール(CheckStyleやFindbugsなど)を使わずに、目視と気合でひたすらソースコードレビューする ・Excel表で書かれたテストケースを睨みながら、手でケースに沿ったオペレーションをしてデバッ
マルチプロジェクトは個人的には大変なので余りやりたくないのだが、規模が大きくなると様々な理由で必要になってくる。Gradleにももちろんマルチプロジェクトをサポートする機能がある。今回はそれを紹介。 そもそもマルチプロジェクト化する理由って? プロジェクトによって色んな理由があると思うが、うちだと以下のような理由がメインかな。 ビルドのルールを標準化したい ビルド時のソースエンコードとかビルドターゲットのバージョンとかバラバラにならないように統一したい。 依存ライブラリのバージョン定義を集約したい 各プロジェクトで使っているOSSライブラリのバージョンがバラバラ...なんてことを避けたい。 ビルドスクリプトを簡略化したい 同じような処理を各プロジェクトで記述するのは無駄だし、メンテナンスも大変。どこかに共通化して定義して、各プロジェクトのビルドスクリプトはすっきりさせたい。 サブプロジェク
元々は TDD Advent Calendar jp: 2012 : ATND で人数が足らなかった時の予備として用意していたのですが、めでたく人数が埋まったため単発で上げてみます。 僕は自他共に認めるTDDマニアですが*1、敢えてテストを書かないことの重要性について説きたいと思います。 id:shuji_w6e さんの 軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ と近いですが、shuji_w6eさんのがテストを軽くするのに対しこっちはそもそもテストを書かないようにするということです。 テストを書かなくてもいい(書く必要のない)ケース 寿命の短いプログラム TDDというのは最初にテストを書くコストというのがどうしても発生するため、寿命の短いプログラムだとTDDの恩恵を受けづらいです。 自分の経験上、半年以上メンテする必要があるプログラムだと保守フェーズ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く