AIR GEARのMXMLデザイナViewでのAccordionの表示を、それなりのAccordionっぽく表示するように修正完了ー。
これって大変だろうなぁって思っていて手を付けるのを後回しにしていたんですが、今回ぐらいの対応であれば思ったより簡単でした。
大変。。。って思っていた理由としては、同じModelのものをどのContainerにいれるかによって見かけを変えないといけないから。
例えば、Canvasというものでも、WindowedApplicationに張り付いている時と、Accordion内で張り付いているときと見かけを変える必要がある。
でも、思ったより簡単だった理由としては、
EclipseGEFでは、Model,View,EditPart(Controller)としっかり分かれている作りになっていたからこそ！
そして、手を加えたい場所には、大概、その目的にあった上書きできるメソッドがある。
んー、さすがだな。。
ということで、目の上のたんこぶを取り除いて、ホッした一日でしたー。
2008年6月22日日曜日
2008年6月20日金曜日
AIR GEAR に集中
ectoを使おうとしましたが、Bloggerでの自動改行設定をしていると、改行(br)が2つになってしまっていまいち。。ectoの設定場所も分からないしって事で、WEBからの投稿です。
最近は、家に帰るともっぱらAIR GEARの作成をやっています。
というのも、6月中には一通りのメドをつけてリリース体制になるように頑張る！。。。と、ある意味自分にハッパをかける発言をしたためです。。
そうでもしないと、なかなか脱線が多くて進まないんですよね。
これは必要だろーって機能よりも、こんなんできるんかなぁ？と興味があることとか、自分がとりあえず欲しい機能とかを優先しちゃいますよねぇ。
ということで、今日はViewStackのコンポーネントをレイアウトできるように追加しました。
Stack内のパネルに切り替える方法がどうしたらいいもんか、、、というのは難しい。
FlexBuilderではどうなってるんかな？と見ようとしたら、評価版の期限切れで動かないし(涙)
とりあえず簡単な方法で対処してしまいました。時間もないし(言い訳)
ViewStackの右クリックで切り替えメニューの追加と、OutLineViewでの選択による切り替えとをつけました。
メニューの部分にはハマりました。。。MenuからMenuItemの削除ができないんですよー！
MXMLViewでのコンポーネント選択のタイミングでMenuを作り直しても、親Menuに反映する方法も分からず。。
暫くEclipseのソースを追っかけましたが、断念。
Menuは作り直さず、MenuItemのVisibleを切り替えるという。。。なんともベタな方法でとりあえず実装しました。
まぁーこれも、期限を言わなかったらもっと探っていただろうから、断念できるきっかけになってよかったかも。(と、思うことにしよぅ)
あとは、明日からはドキュメントを書いていきながら、テストをしようかと思ってマス。
それで、余裕が出てきそうであれば、もう少しコンポーネントの追加を。
(あ、AccordionのデザインViewもなんとかせねばあかんのもあるなぁ 忘れたかったけどw)
使う人には気になるコンテンツアシストは、最初のリリースには無理そうです。
すいません。。。
ちょっと出てくるんですが、予約語とTopLevelのものだけなので意味ないですw
旦那を巻き込んでみている所ですが、ソースの解析って大変。。。
EclipseのJavaコンテンツアシストは凄いです。
あれに慣れると、同じような挙動をするものを期待してしまうんですけど、どう考えても、あそこまでは無理って思ってしまう。
どこかにAS3のコードアシストをするEclipseプラグインないかなぁ。
もちろんオープンソースで(笑)
リリースできたら、SlimTimerのAirクライアントに挑戦だあー！だあー！だあー！
2008年6月13日金曜日
Bloggerのエディタ
flockブラウザのものを使ってたんですけども、flockでGmailが上手く見れなくなった。
ということで、FireFox3に移行かなぁーとしているんですが、Bloggerのエディタをflockのものを使っていたのでこれが使えなくなるのが、イタイ。
で、いま試しにecoを入れてみて書いてます。シェアウェアなんですけども、使い勝手がいいんであれば、買うかなぁ。どうするかなぁ。。。
2008年6月12日木曜日
素直に耳を傾ける事
最近は、よくアジャイルだのリーンだの、開発を行なうにあたっての手法やら思想みたいな本を、よく読んでいるんですけども、思った事。
「まぁ理想よね。でも自分の職場には無理よね」
「そんな事は昔から考えてたよ」
「うまくいきっこない」
「どうせ、ブームなだけでしょ」
みたいな、否定的な概念がある状態で始めは読んでいたような気もします。
今思うと。。。ですけども。
でも、
自分一人であーかな、こーかなって考えるよりも、行動を起こして結果を出せている人の話の方がよっぽど意味あるんだと思うようになってきました。
今の職場環境は悪い、なんとかせねば とは思っている。
そこで自分で考えた方法なんて、誰かが既に考えていて結果も分かっていたりするんだろう。
しかも、その情報は本やネットで入手しやすい世の中。
そんな中、他の情報も入手せず。。。真面目に理解しようともせず。。。
自分が思った事を押し進めて、過去に人が既に失敗しているだろう失敗を繰り返す、、ってのは悪を振りまいているんちゃぅかなぁ と。
昔は「もっと始めにしっかり計画をたてて、それを崩す事なくやろうよ」とか「マネージャーは、管理だけに集中すべきだ」とか。。。ITに入ったばかりの時に陥りやすい事を思っていた自分もあるんですが、会社内の若手が同じ意見を発しているのをみて、なんか余計に思いました。
人間は、経験によって成長していく人間ではありますが、人の話を聞く事により疑似体験して階段を飛ばすことはできるはず。
そうやっていかないと、時代は進んでも人が変わることにより、同じ発想、失敗をグルグル回るだけになっちゃいます。
技術の話であれば、「過去に絶対この事をやっている人がいるはず！」と思いググったりするんですが、マネージメントのような抽象的な事も一緒なんですよね。
抽象的な事であるので、状況に合わせて応用は必要ってのは大きいですけども。
過去に色々チャレンジした人達に敬意を表しつつ、素直に耳を傾ける事というのは意識してやらないとなー。
「まぁ理想よね。でも自分の職場には無理よね」
「そんな事は昔から考えてたよ」
「うまくいきっこない」
「どうせ、ブームなだけでしょ」
みたいな、否定的な概念がある状態で始めは読んでいたような気もします。
今思うと。。。ですけども。
でも、
自分一人であーかな、こーかなって考えるよりも、行動を起こして結果を出せている人の話の方がよっぽど意味あるんだと思うようになってきました。
今の職場環境は悪い、なんとかせねば とは思っている。
そこで自分で考えた方法なんて、誰かが既に考えていて結果も分かっていたりするんだろう。
しかも、その情報は本やネットで入手しやすい世の中。
そんな中、他の情報も入手せず。。。真面目に理解しようともせず。。。
自分が思った事を押し進めて、過去に人が既に失敗しているだろう失敗を繰り返す、、ってのは悪を振りまいているんちゃぅかなぁ と。
昔は「もっと始めにしっかり計画をたてて、それを崩す事なくやろうよ」とか「マネージャーは、管理だけに集中すべきだ」とか。。。ITに入ったばかりの時に陥りやすい事を思っていた自分もあるんですが、会社内の若手が同じ意見を発しているのをみて、なんか余計に思いました。
人間は、経験によって成長していく人間ではありますが、人の話を聞く事により疑似体験して階段を飛ばすことはできるはず。
そうやっていかないと、時代は進んでも人が変わることにより、同じ発想、失敗をグルグル回るだけになっちゃいます。
技術の話であれば、「過去に絶対この事をやっている人がいるはず！」と思いググったりするんですが、マネージメントのような抽象的な事も一緒なんですよね。
抽象的な事であるので、状況に合わせて応用は必要ってのは大きいですけども。
過去に色々チャレンジした人達に敬意を表しつつ、素直に耳を傾ける事というのは意識してやらないとなー。
Blogged with the Flock Browser
2008年6月9日月曜日
Agile開発を行う最適人数？
少しずつ、AgileProjectManagementの本を読んでいっています。
納得したり、反省したりすることも多くて、読むペースが結構時間かかる本になってます。
さっき見た文面の一つにいかのものがありました。
余った人に対して、「やってもらう事を見つけてその用意する」のを優先するようになって、本来優先するところが後回しになってしまう って･･･あります。
そんでもって、本来優先するところが疎かになるために、後戻りもあったりして。
「人を遊ばせておくことはできない！」 というのは当然の話なんですけども･･･それが、↑のようになってしまう理由にならないんですよね。
自分の仕事 の前のフェーズでは、ウォーターフォールでの開発はやめようよ。
と 自分では言っておきながら、
自分以降の仕事では、ついついウォーターフォールになっていたんかもなぁ。。。と。
とはいえ！
20人のプロジェクトで、最初からAgileで進むぞ！ というのは、やっぱり上手くいくようには思えないのは、正直な所です。
もし、その20人が まかせて大丈夫！って思える･･･よく知っている人･･･だったら、できるかも！って思いますが、そぅいぅメンバーが集まることってほぼ無いでしょうし。。全く同じメンバーで次のプロジェクトも行うって事もマレですし。。
Agileでの開発は大規模じゃー難しそうって漠然と思っている理由の一つは、コレなんかも。
5,6人くらいがベストかなぁー なんても漠然と思っていたりして。
でも、よく知っているチームメンバー同士であれば、いけるんかもしれないです。
案件によりその都度チーム編成するのではなく、
常にチームメンバーが決まっていて、案件にはチーム単位でアサインされる･･･
ってしたら、大規模もOK！なAgileチームが生まれるのかも。
Agileでぇーーなんて言わなくても、チーム内で自然とAgileな習慣をやるようにもなりそう。。
納得したり、反省したりすることも多くて、読むペースが結構時間かかる本になってます。
さっき見た文面の一つにいかのものがありました。
それこそが大規模プロジェクトの人員配置での問題だ。このような体制になることって結構あります。 どきっ! とするところ。
プロジェクトに20人のメンバーがいるが、最初は5人分の作業しかないという場合、
チームの効率を上げるために、余った15人のための作業を見つけ出そうとする傾向が強い。
これはつまり、システムが、そのプロジェクトに合った境界ではなく、20人の開発者のスキルに沿って区切られるということである。
余った人に対して、「やってもらう事を見つけてその用意する」のを優先するようになって、本来優先するところが後回しになってしまう って･･･あります。
そんでもって、本来優先するところが疎かになるために、後戻りもあったりして。
「人を遊ばせておくことはできない！」 というのは当然の話なんですけども･･･それが、↑のようになってしまう理由にならないんですよね。
自分の仕事 の前のフェーズでは、ウォーターフォールでの開発はやめようよ。
と 自分では言っておきながら、
自分以降の仕事では、ついついウォーターフォールになっていたんかもなぁ。。。と。
とはいえ！
20人のプロジェクトで、最初からAgileで進むぞ！ というのは、やっぱり上手くいくようには思えないのは、正直な所です。
もし、その20人が まかせて大丈夫！って思える･･･よく知っている人･･･だったら、できるかも！って思いますが、そぅいぅメンバーが集まることってほぼ無いでしょうし。。全く同じメンバーで次のプロジェクトも行うって事もマレですし。。
Agileでの開発は大規模じゃー難しそうって漠然と思っている理由の一つは、コレなんかも。
5,6人くらいがベストかなぁー なんても漠然と思っていたりして。
でも、よく知っているチームメンバー同士であれば、いけるんかもしれないです。
案件によりその都度チーム編成するのではなく、
常にチームメンバーが決まっていて、案件にはチーム単位でアサインされる･･･
ってしたら、大規模もOK！なAgileチームが生まれるのかも。
Agileでぇーーなんて言わなくても、チーム内で自然とAgileな習慣をやるようにもなりそう。。
Blogged with the Flock Browser
2008年6月1日日曜日
EclipseLaunchでDebugUITools.launchを使う
今日はAIR GEARのAIR実行Launch部分を修正しましたー。
今まで、実行する際、ファイル未保存だったら、保存して実行するんですが...buildの終了をまたずにAIR起動していたみたい。なので、修正して実行しても...修正箇所が反映されてない事がある状況でした。スンマセン。。
しっかり見てみたら...おやまぁ、buildの完了なんぞは待たずにAIRアプリ起動を開始してますがな。
つーことで、修正をしました。
org.eclipse.debug.ui.ILaunchShortcut の実装のクラスの中で、ILaunchConfigurationで起動構成を作成し、
ILaunchConfiguration config =....
config.launch(ILaunchManager.RUN_MODE, new NullProgressMonitor());
ってしていたんですが、
config.launch(ILaunchManager.RUN_MODE, new NullProgressMonitor(), true);
と第三引数の boolean build にtrueを与えてあげると、buildが終わってから実行するようになりました。
ただ、これだと、buildに時間かかっていると進捗状況も見えないしフリーズしたかと思ってしまう状況。
ということで、楽にイイProgressMonitorの実装方法ないもんかーとGoogle先生にお聞きした所、まったく別の方法を発見。
ILaunchConfiguration#launchを使わずに、org.eclipse.debug.ui.DebugUIToolsを使えばいけるみたいです。
ILaunchConfiguration config =....
DebugUITools.launch(config, ILaunchManager.RUN_MODE);
ってすると、Progressにでてくる。スバラシイ！
デフォルトはBackgroundでProgressが動作するんですが、作成するILaunchConfigurationのプロパティに
config.setAttribute(IDebugUIConstants.ATTR_LAUNCH_IN_BACKGROUND, false);
ってプロパティを設定しておくと、ProgressDialogが表示されるようになります。ぶらぼぉ
今まで、実行する際、ファイル未保存だったら、保存して実行するんですが...buildの終了をまたずにAIR起動していたみたい。なので、修正して実行しても...修正箇所が反映されてない事がある状況でした。スンマセン。。
しっかり見てみたら...おやまぁ、buildの完了なんぞは待たずにAIRアプリ起動を開始してますがな。
つーことで、修正をしました。
org.eclipse.debug.ui.ILaunchShortcut の実装のクラスの中で、ILaunchConfigurationで起動構成を作成し、
ILaunchConfiguration config =....
config.launch(ILaunchManager.RUN_MODE, new NullProgressMonitor());
ってしていたんですが、
config.launch(ILaunchManager.RUN_MODE, new NullProgressMonitor(), true);
と第三引数の boolean build にtrueを与えてあげると、buildが終わってから実行するようになりました。
ただ、これだと、buildに時間かかっていると進捗状況も見えないしフリーズしたかと思ってしまう状況。
ということで、楽にイイProgressMonitorの実装方法ないもんかーとGoogle先生にお聞きした所、まったく別の方法を発見。
ILaunchConfiguration#launchを使わずに、org.eclipse.debug.ui.DebugUIToolsを使えばいけるみたいです。
ILaunchConfiguration config =....
DebugUITools.launch(config, ILaunchManager.RUN_MODE);
ってすると、Progressにでてくる。スバラシイ！
デフォルトはBackgroundでProgressが動作するんですが、作成するILaunchConfigurationのプロパティに
config.setAttribute(IDebugUIConstants.ATTR_LAUNCH_IN_BACKGROUND, false);
ってプロパティを設定しておくと、ProgressDialogが表示されるようになります。ぶらぼぉ
Blogged with the Flock Browser