nDiki : コンポーネント

コンポーネント - component

構成要素。構成部品。

コンピュータの分野では、機能をもったプログラムの部品(ソフトウェアコンポーネント)や、ハードウェア部品などをさす。

UML

UML においては、システム内の物理的で交換可能な部分。インタフェースを実現するもの。ビット列として存在するもの。

実行形式モジュール(EXE ファイル等)・ライブラリ(DLL 等)・データベースのテーブル・ファイル・ドキュメント・ソースファイル・実行時にインスタンス化されるオブジェクトなど。

コンポーネント用の標準ステレオタイプとしては以下がある。

  • executable
  • library
  • table
  • file
  • document

関連情報

適応型ソフトウェア開発

適応型ソフトウェア開発では、フィーチャーの集合のことをコンポーネントと呼ぶ。 オブジェクト群・ビジネス上のフィーチャー群・GUI・コンテナなど。

主要コンポーネント(機能を提供するもの)・技術コンポーネント(ネットワーク・ハードウェア・OS・RDBMS 等)・補助コンポーネント(それ以外のもの)の3種類がある。

スポンサード リンク

2004年1月29日 (木)

D端子+ピンプラグx2 ケーブル

帰りに5m のを買ってくる。

あれ、ウチのテレビ D4対応だったのか。 てっきりD2までだったと思っていた。 コンポーネント3入力端子もあったのか(ま、今回はプレーヤー側がD2なのでD端子接続でいいけど)。


[ 家電 ]

スポンサード リンク

[ 1月29日全て ]

2004年12月25日 (土)

地磁気による画像の傾き

最近テレビ画像が傾いていて、とても気になっていた。 地上波もコンポーネント入力も。

ということで説明書をひっぱりだしてくる。 磁界によって発生する傾きの補正をメニューから選んで調整。

買って以来場所もほとんど動かしていないんだけれど、何の影響だろ。


[ 家電 ]


[ 12月25日全て ]

2005年10月19日 (水)

コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

  • 作業時間がある程度精度よく見積もれる
  • 作業時間と成果が比例的である

であるような場合はガントチャート計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

ガントチャートを利用したマネジメントの特徴

  • マネージャからのトップダウン的なスケジュール向き
  • リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
  • 比較的多人数のチームでもいける
  • リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
  • 人月計算/コスト積算できる
  • プロジェクト外からの割り込みの発生によって狂いやすい
  • 成果がみにくい
  • チェックしにくい
    • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
  • ぱっと見、計画できている気がする
  • 期間が長いと、チャートが見にくくなる
  • 1日単位で見積もりたくなる
  • 休日が気になりだす

コミットメント・リストを利用したマネジメントの特徴

  • 担当の裁量を尊重・重視
  • コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
  • 期日前にせっぱつまりやすい
  • 依存関係が複雑だと把握しにくい
  • 専用のソフトウェアがなくても可能
  • 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
  • 線表派からみると計画だと思ってくれないかも

自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

  • スケジュールの変更があった時に面倒
  • 現状とあわなくなってくるとだんだん見なくなった
  • 結局だんだんメンテナンスしなくなってしまう
  • 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

コミットメント・リストでうまくいっている点

  • 成果が達成できているか、そうでないかが明確
  • 達成できていないコミットメントのチェック、フォローができている
  • 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
  • コミットメント一つ達成するたびに「いい気分を味わえる」

まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。


[ 10月19日全て ]

2008年10月27日 (月)

Visual C# 2008 Express Edition で必須コンポーネントを同梱

Visual C# 2008 Express Edition で Windows インストーラ 3.1 と、.NET Framework 3.5 SP1 を「アプリケーションと同じ場所から必須コンポーネントをダウンロードする」ような ClickOnce アプリケーションを発行するための設定。

以下 C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages を %Packages% と書くこととする。

  1. %Packages%\WindowsInstaller3_1 に WindowsInstaller-KB893803-v2-x86.exe を置く。
  2. %Packages%\DotNetFx35SP1\product.xml ファイルを開いて PackagesFiles 要素の下に以下を追加。
    • <PackageFile Name="TOOLS\clwireg.exe" />
    • <PackageFile Name="TOOLS\clwireg_x64.exe" />
    • <PackageFile Name="TOOLS\clwireg_ia64.exe" />
  3. %Packages%\DotNetFx35SP1\product.xml の中で Name が dotNetFX30\XPSEPSC-x86-en-US.exe のものと、dotNetFX30\XPSEPSC-amd64-en-US.exe のものの PublicKey を ※1 に変更。
  4. http://go.microsoft.com/fwlink?... から dotnetfx35.exe をダウンロード。
  5. dotnetfx35.exe /x:. を実行して展開する。
  6. wcu\dotNetFramework の中身を %Packages%DotNetFX35SP1 にコピー。
  7. dotnetfx35langpack_x86ja.exe ( http://go.microsoft.com/fwlink?... ) を %Packages%DotNetFX35SP1\ja\DotNetFX35\x86 におく。
  8. dotnetfx35langpack_x86ja.exe ( http://go.microsoft.com/fwlink?... ) を %Packages%DotNetFX35SP1\ja\DotNetFX35\x64 におく。
 ※1: 以下折り返さないで1行で
 3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D5
 26C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD
 9706D05744765CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2
 B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E395
 8977609BE7AD77C1378D33142F13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D50
 74412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F2
 7B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001

参考資料: http://download.microsoft.com/...


[ 10月27日全て ]

2009年2月4日 (水)

就職して初めての仕事は Mouchu でした

naney:3252059769

今の会社に就職して初めての仕事は、当時売り出されたファンシーなマウス「Mouchu (マウチュ)」関連のソフトウェアコンポーネント開発だった。

今日 Mouchu が話題になったので、オフィスの棚に実物があったのを思い出してひっぱりだしてきた。 今でも2ボタン USB マウスとしては普通に使える。 使わないけど。


[ 2月4日全て ]

2009年12月6日 (日)

今日のさえずり - なんだ今日の西友男レジ係率は

2009年12月05日

2009年12月06日


[ 12月6日全て ]

2014年1月26日 (日)

万能Jrくんでキッチンシンクと、風呂の鏡と握りバーがピカピカに

naney:12133523934

昨日ホーマック(ホームセンター)に行ったついでにマルシンの「スーパークリーナー万能Jrくん」を買ってきて、昨日と今日とでキッチンのシンクと風呂の鏡と握りバーの掃除に使ってみたところピカピカになって感激した。

今のキッチンはシンクにクレンザーとか研磨剤入りのもの使いたくないなあと思って、デイリーのお手入れだけして1年以上経ったんだけれど汚れが落ちなくてだんだん汚なくなってなってきてしまっていた。でコンポーネントキッチンの取扱説明書をみたらこれがおすすめ便利グッズとして掲載されていたので買ってみたと。ちなみにシステムバスルームの取り扱い説明書にもこれが紹介されていたので、それなら違いないと思ったわけ(しかし実はキッチンはサンウエーブ → LIXIL で、バスルームは INAX → LIXIL であれっと)。

感じとしては靴クリームのような感じ。スポンジか布につけて綺麗にしたい面に塗り、汚れが浮いてきたら擦って汚れを落とす。

シンクのずっと落ちなかった汚れは何回か繰り返すことですっきり落ちてピカピカになった。

しばらくサボっていたレンジフードの掃除にも使ってみたけれど、固まった油汚れも万能Jrくんをつけてちょっと待つと取れるようになる。仕上げに水洗い不要なので助かる。ただ、つける・ちょっと待つ・こすって落ちなかったらもうちょっとつけて繰り返すというのレンジフードだとちょっと大変なのでこれは別の洗剤の方が良いかも。

風呂は鏡と握りバー(シャワーのスライドフックがついている棒)の掃除に使ってみた。鏡のウロコ取りというと研磨剤系が多くて躊躇するのだけれど、万能Jrくんは研磨剤が入っていないのでその点は安心できる。こちらもほぼ綺麗になった。ただ1回では落ちなくて何回も繰り返しつけてはスポンジでこするのを繰り返した。まだちょっと残っているので以降は定期的に掃除する時に使って落とそうと思う。

あと金属の握り棒についていた、お風呂洗剤やメラミンフォームでは落ちなかった水垢も結構落ちてピカピカになった。これは嬉しい。

そもそもあのバー、シャワーフック用のだと思ったのだけれど取扱説明書をみたら浴槽に入るときの握りバーだったという方が驚きであった。握りバーなんだ。握りバー。


[ 製品レポート ]


[ 1月26日全て ]

2015年4月28日 (火)

LINE DEVELOPER DAY_2015 Tokyo #linedevday

naney:17269564386

「エンジニアチームの様々な経験を、未解決の課題も含めて共有する」というテーマで開催された LINE 株式会社のエンジニア向けイベント LINE DEVELOPER DAY_2015 Tokyo に行ってきた。

会場の装飾やクリエイティブなどお金をかけていてすごいなと。始まる前にプレス向けにきちんと立ち位置や照明まで案内していて、とても行き届いていて運営力もすごい。

細かいところだけれどイベントサイトや事前案内は「LINE DEVELOPER DAY_2015 Tokyo」で当日の会場が「LINE DEVELOPER_DAY 2015 TOKYO」と表記を変えていてどんな理由なのかなというのが気になった。まあどうでもいいことだけれど、物を書くのにちょっと困る。

スライドはシンプルで洗練されているんだけれど、完成されすぎていて素材ぽくも感じた。

全体的に microservices アーキテクチャというのが印象に残るイベントだった。

A-1 オープニング 代表取締役社長 CEO 出澤剛氏

LINE の成長とサービスなどの紹介。ウォーミングアップ的に聞いていた。

A-2 LINE Global Culture 上級執行役員 CTO 朴イビン氏

LINE のグローバルな開発組織や文化について」

ちょっと綺麗にまとめられすぎていて感じがした。泥臭さが感じられない。より現場的な話をぜひ聞きたいなと思った。

ペンディング・先送りされた「cold-case プロジェクト」について、また取り組むきっかけを用意するというのは良いな。

A-3 LINE Messenger for the World 上級執行役員 サービス開発担当 池邉智洋 @ikebe 氏

「色々な国の通信各社、様々な環境に対応するために進めた実験や改善方法について」

LINE アプリのバイナリは1つとのこと。各国の事情について「LINE 遠征隊」として現地で実際に使って改善していくという取り組みがきちんとできているというのは素晴しいと感じた。グローバルなサービスではなく国内向けのサービスでも参考にできるな。

ストアのレビューについて、レビュー文章のキーワード分析や変化の把握もきちんとしているとのこと。(アプリではないけれど)化粧品業界などが良くやっているやつか。 この辺りは自分の部署でも取り組んでみたい。

A-4 LINE Platform Development Chronicle Tom.T @tsurutom 氏

LINE Platformを支えるアーキテクチャ、組織、文化について」

鶴原翔夢氏による LINE のアーキテクチャの変遷について。

  • polling / push / long polling
  • Erlang で LINE Event Delivery Gateway
  • SPDY

など。アーキテクチャは microservices に移行している。

Abusing も独立したバックエンドになっているとのことだった。abuse 対策のコンポーネント化は考えてはいるんだけれど、サービス毎に要件が結構異なるので本体とどの程度の結合にするかが迷いどころなんだよね。いつかはやりたいところ。

A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ Shunsuke.N @sunsuk7tp 氏

HBase と Redis の話し。桁違いだ。

A-8 Webサービスの国際化にあたり LINE Creators Market 開発がどのように行われたか Tokuhiro.M @tokuhirom 氏

最近 Java を書かれているようだけれども LINE Creators Market はやっぱり Perl で書かれているとのこと。ちなみにアプリケーションサーバでは Starlet を使っているそうだ。

実際に開発する上で問題になったことも混じえた @tokuhirom 氏らしい語り口のセッションだった。

B-5 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発 Jun.N 氏

なみかわじゅん氏。

まずはスタンプ間の(レコメンド的な)距離を計算し、その上でユーザー-スタンプ間の距離を計算するというフローでレコメンドを生成しているとのこと。処理には Hive も使っているらしい。

コールドスタート問題については、Naver Labs と共同研究開発した画像類似度計算を使って似た絵のものをレコメンドできるようにして対応しているとのことだった。

以上

午後は途中オフィスに戻ったりしながら面白げなセッションを聞いてきた。夕方に歯医者があるので 17:30 まで聞いて退散。


[ 4月28日全て ]

Related term

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS の企画開発を行うグループのマネージャーをしています。CS 向上・コミュニティマネジメント・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス

Process Time: 0.060329s / load averages: 0.51, 0.47, 0.41
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker