今まで使ってたEclipseから、インストールしてたフィーチャーを簡単にインポートできるよ！ 1. File -> Importを選択 2. Install -> From existing Installationを選択 3. 既存のEclipseのパスを指定 するとでーんとインストールしていたフィーチャー一覧が表示されるよ。 あとはインポートしたいフィーチャーを選択してね！ そんじゃーね。
Eclipse 3.7を使い始める前に知っておくといいこと - Fly me to the Luna
今まで使ってたEclipseから、インストールしてたフィーチャーを簡単にインポートできるよ！ 1. File -> Importを選択 2. Install -> From existing Installationを選択 3. 既存のEclipseのパスを指定 するとでーんとインストールしていたフィーチャー一覧が表示されるよ。 あとはインポートしたいフィーチャーを選択してね！ そんじゃーね。
5分でEclipse PluginをGroovyで書くよー。 - Fly me to the Luna
ぼーっとしていたらEclipse PluginをGroovyで書いてました！他のJVM言語でもEclipse Plugin書けるんです！ Eclipseはe4プロジェクトでJava以外の言語(例えばJavaScript)でもPluginの実装を実現しようと頑張ってますが、なんか3系でもできちゃった。 必要なもの(環境) JDK 6 Eclipse for RCP and RAP Developer Groovy Eclipse を上記Eclipseにインストール こっからはほぼ画像ペタペタ貼っているだけです。この通りに作業すれば同じようにプラグインが作れます。 ほいじゃ、実際に作っていくよー。 まずGroovyプロジェクトを作るー プロジェクト名は「 eclipse-plugin-by-groovy 」って作りました｡ GroovyプロジェクトをPluginプロジェクトにコンバート MAN
次第に腐るテストコード - Fly me to the Luna
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
@Ruleは素晴らし。 - Fly me to the Luna
@Rule。このアノテーションは、あまり知られていないようですが、ヤバいです。このアノテーションが追加されたのは4.7からなので結構古いのです。@Ruleのうれしさは、カスタムで作られているRunnerをほぼ置き換えられる、ということを言われていました。ただ、僕はあんまり使った事がなかったですし、周りでも使っている話はあまり聞いた事がありません。でも、使ってみて非常に便利だと感じました。 例えばTemporaryFolderを利用して作成されたファイルは、テストの終了時に自動的に削除されます。ちなみにTemporaryFolderの使い方はこんな感じです。 public static class HasTempFolder { @Rule public TemporaryFolder folder= new TemporaryFolder(); @Test public void test
モジュラリティを考える - Fly me to the Luna
ソースコードの分かりやすさは、「単一責務の原則」と「関心毎の分離」により適切に構造を分割した、バランスのいいところにあると前のエントリに書いた。では、そこにモジュラリティが加わるとどうなるだろうか。 モジュラリティとは、システムを幾つかのモジュール*1に分離し、さらに分離したモジュールを組み合わせて新しいシステムを組むソフトウェア開発法、とここでは定義する。分かりやすい例はEclipseだ。例えばPyDevを導入すればPythonの開発環境が手に入る。このように言語環境ごとに作られたプラグインを導入すれば、それぞれの言語で開発ができるIDEが構築できる。EclipseはIDEとして必要な機能の全てをプラグインという形のモジュールに分離し、組み合わせる事でモジュラリティを実現している。*2 モジュラリティの利点と欠点を上げてみよう。 利点 モジュール毎に独立して開発できる モジュールに分割で
System#exitを呼び出してもVMを終了させない方法 - Fly me to the Luna
こんな感じででけた。もしこのコードを試すのであれば、ラーニングテストなので、適宜org.junit.Testをインポートしてね。 @Test public void exitしないことを確認しよう() throws Exception { System.setSecurityManager(new SecurityManager() { @Override public void checkExit(int status) { throw new SecurityException(); } @Override public void checkPermission(final Permission perm) { } @Override public void checkPermission(final Permission perm, final Object context) { }
いよいよEclipse3.6(Helios)がやってくる。 - Fly me to the Luna
後数時間でいよいよEclipse3.6(Helios)がやってきます。(ただいまFriends of Eclipse権限でダウンロード中)今回のリリースでは、39個のプロジェクトが同時リリース。そして初めてe4も同時にリリースです。e4については、後日レポートします。(がんばる)簡単に触れると、e4は、Eclipseの次期バージョンを目指し、開発が進んできたIDEです。Eclipse Platformの開発にて、初めてコミュニティが主体になって進めてきたプロジェクトです。新たな開発プラットフォームとなるべく開発が進んでいます。Eclipse 3系の中心のorg.eclipse.uiはかなり巨大なBundleに成長してしまいました。その中でも特に重要なクラスであるWorkbenchクラスの実装コードは5000行(!)近く、改善を加えるにも結構限界があったんではないか、と思われます。e4では「
Mockitoノススメ - Fly me to the Luna
モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの？」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか？そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの？プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの？ みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから
OSGiがエンタープライズアプリケーションに与えるインパクト - Fly me to the Luna
Eclipseベースのツールを開発し始めてから3年近く立ちました。1年半くらい前に、SeasarプロジェクトでOSGiサポートをしないのはなぜだろうと、はてダに書いたところ、OSGiはプラットフォームを構成するにはとてもよい仕様だけれど、Webアプリケーションには過剰な仕様だ、と、とある方から答えられました。それからもずっとなんだかんだでOSGiと関わってきましたが、だいぶ状況も変わってきました。まずモバイルやEclipse以外の環境でも広くOSGiが使われるようになりました。そしてプラットフォーム以外での利用も考えられるようになりました。プラットフォーム以外での利用は、エンタープライズアプリケーションの開発モデルを変えるだけのインパクトを起こす可能性が見えてきたのでまとめてみます。OSGiについて、どういう技術か、気になる方はOSGiの記事を参照してください。 どんな分野でOSGiが使わ
Continuous Integrationの12の勘所 - Fly me to the Luna
個人的にCIは大好きで、いろんなところで首をつっこんでは、仕組みを学んで来ました。その勘所をかりかり書いてみました。内容が固いので文体も固いですが、この記事書いている人はこんなに固くないです。むしろゆるゆるです。 最初で全ての環境(ビルド・テスト・CIサーバーの設定)を整えられればパーフェクトだけれども、一度に全部やりきるのはきっと現実的ではない。開発環境としてフルスタック揃ったものはいくつもでているけれども、プロジェクトごとに違う設定は必ずどこかにあるからだ。例えば開発用のDBは各マシンに用意しているけれども、インテグレーション用のDBは別途用意している、とか。設定は「こうすれば良くなるかも」という継続的な改善をしていくつもりで、一番最初は軽めに1時間くらいでできる範囲で一本通す。 小さく産んで、環境を壊さない程度の改善を少しずつ加えて育てていく。育てられるのは製品コードやテストコードだ
Eclipseの設定のデフォルト値を変更する方法 - Fly me to the Luna
Eclipseを使っていると、ワークスペースをまたいで値を設定したい場合が良くある。自分の場合、例えば行番号はどのワークスペースでも見られるように設定しておきたい。そういう時はどうしたらよいか。 まず、eclipse.iniに下記の行を追記する。追記するのは、-vmargsよりも前の行。 -pluginCustomization plugin_customization.ini 続いてplugin_customization.iniファイルを用意し、eclipse/以下に配置する。gistで自分の使っているものを公開している。これを使ってもいいと思う。もしくはeclipse/plugins以下に眠っているので、plugin_customization.iniを検索すれば、必ず見つかる。 種明かしをしてみる。このplugin_customization.iniは、起動時に必ず読み込まれている
Testing Context(仮)という考え方 - Fly me to the Luna
ちょっと前Quick JUnitの管理者でもあるかくたにさんとQuick JUnitをどう改良しようか、話してきました。その時に聞いてきたアイディアに名づけるとするならTesting Context。 以前はTesting Pairだけ考えてればよかったのに。 Quick JUnitでは実装クラスに対するテストクラスが1対となって存在するという、Testing Pairという考えを元に作られています。Ctrl+9でテストクラスと実装クラスを切り替えられる、というあれです。JUnit3の時代までは必ずTestCaseクラスを継承しなければならない、テストメソッド名はtest_で始まらなければならないなど、いくつか制限がありました。なので名前で実装クラスとテストクラスを対応づけられるよう、実装クラス名+Testをテストクラス名として検索できるようになっています。実は隠してるんですが、その対応を
Eclipseプラグイン開発に良くある10の過ち - Fly me to the Luna
Planet Eclipse経由で流れていた良記事を翻訳してみた。Eclipse Tipsの記事です。 翻訳の元記事 http://blog.eclipse-tips.com/2009/01/top-10-mistakes-in-eclipse-plug-in.html 元のタイトルは「Top 10 mistakes in Eclipse Plug-in Development」なので、「Eclipseプラグイン開発の間違いトップ10」の方が正しいんだろう。10位から順番に上がっていきます。また、画像は引用していません。 引用ここから 私はEclipseプラグイン開発をし始めた方をトレーニングしてきました。そしていつも同じように間違えてしまう点を見つけました。そこで今回、そうやって見つけてきた10の良くある過ちを一覧にしました。もしあなたがこれらの間違いをしていたとしても、それはあなただけ
0.11でTracMacroを書く - Fly me to the Luna
Shibuya.trac新年会で結構みんなの待望だったRSSマクロが公開されていました。このRSSマクロ、最新版のTrac 0.11では動かないみたい。なぜならTracは0.11からClearSilverではなくgenshiというテンプレートエンジンへ載せかえられているから。*1 *2 今日はRSSマクロを0.11へ移植してみた。その際学んだことをつらつら書いていきます。今回はLinux上ではなく、TracLightning2.1-beta4を使ってみました。Windows上です。 え？Tracはマクロとかを修正したときにサーバーの再起動が必要なの？ のっけからビックリしたんですが、Tracはサーバーのソースを修正すると自動的に更新するわけではないようです。否「自動的に更新」じゃなくて、望「毎回スクリプトを実行する」か。サーバとして起動するときにスクリプトをコンパイルして読み込んでおくよう
ソフトウェア開発の不思議 - Fly me to the Luna
なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。 例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか？なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。 いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。 この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも
そうっすか。泥のように働けと。 - Fly me to the Luna
なんか毎年流行語大賞狙ってるんじゃないかといぶかしがってしまうIPAのIT業界ネガティブキャンペーンが先日あったそうですね。 http://www.atmarkit.co.jp/news/200805/28/ipa.html 昨年の「3Kの“帰れない”は、帰りたくない人が帰れないだけ。」とか今年の「10年は泥のように働け」とか、そんなモーレツな人が偉くなれるのがSI業界なんですね。*1 偉い人たちは、基本的にMな人が自己鍛錬と修練の場としてこの業界を選んでる人が多いとか、そういう感じで見えていたんでしょうか？実際は違いますよね。ほんとは他の仕事をしたかったけど就職できなかった人もいますよね。他にも専門的な技術を生かしたソフトウェアを開発したいけど、システム開発だと仕組みをつくる事の方が重要だからそっちに力をかけようねとか、どうもその辺りがずれてましたね。いくら討論だとしても、業界の方からみ
ダイチャン転職おめでとう呑み - Fly me to the Luna
ということで、ダイチャンことid:daiske-mさんの転職祝いとして、昨日は朝まで飲んでました。集まったのはid:itengeneerさんと世界の矢野ことid:t_yanoさん。矢野さんとは初めてお会いしたんですが、非常に気さくな方でおもしろかったです。というか、僕はコンピューター以外の世界を最近話していない、というかうまく話せなくなっていることに若干ショックを受けました。(自分の中で)脱線しますが、たとえば僕は中国の三国志とか、春秋戦国とか、殷史とか、横山光輝の漫画が描いている時代が大好きなんですが、その辺好きな人って少なくないと思うんですが、語り合ったことってあんまりないんです。みんな孔明大好きですが、結局孔明も寿命には勝てなかったですし。（そう言ってしまうと、なんだかんだで一番持っていったのは司馬家だったりするのか。）策略家の末路ってあんまりいいもんじゃないっていうのを、横山漫画で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
