タグ

2012年9月27日のブックマーク (6件)

  • 第15回 端末ごとにデザインを変更する | gihyo.jp

    最近のTitanium つい先日(6月13日)にTitanium Mobile 1.7がリリースされ、Android開発に便利な機能がいくつか増えました。特にFastdev for Androidという、コードの変更を高速にエミュレータに反映する機能はAndroid開発をかなり加速してくれそうです。この機能については今回の記事の後半で解説します。また今回は解説しませんが、Titanium Stduioという統合開発環境も正式版が発表になり、今後はTitainum Developerからこちらに移行されていくことが表明されています。 デバイスごとのUIデザイン さて、前回の記事でなんとかAndroidでもTwitter Clientが動作するようになりました。HVGAの解像度を指定してエミュレーター実行すると調度よいデザインで表示されます。しかしWVGA800やWVGA854といった解像度で

    第15回 端末ごとにデザインを変更する | gihyo.jp
  • WebエンジニアやスーパーハッカーのロールモデルWebエンジニア武勇伝

    Webエンジニアやスーパハッカーの生い立ちや今までの経歴をインタビューしています。先人からキャリアプランを学びます。Webエンジニア武勇伝があなたに提供するものとは? ロールモデルを知ることであなたの”これから”が見えてくる!! すごい人を見ちゃうと「絶対に自分にはできない」とか思いがちですけれど、決してそんなことはありません。パソコンの触れたスタートは皆同じ。どこで差がついてしまったのか紐解いてみると、これからなすべきことや進むべき道が見えたりするかもしれません。Webエンジニア武勇伝は、すべてのエンジニアにロールモデルと提供するコンテンツです。 今までの武勇伝 第39回 宮下剛輔氏 株式会社 paperboy&co技術責任者  今回は、paperboy&co.技術責任者を努め、Perlのコミュニティでも活躍中の宮下剛輔さんにお話をお聞きしました。宮下さんは技術責任者として尖ったネットサ

  • Redmineでアジャイルチームのスピードやパワーを見える化する

    burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか?チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ

    Redmineでアジャイルチームのスピードやパワーを見える化する
  • Redmineのトラッカーやチケットの設定をする

    トラッカーやチケットには、様々なパラメータを設定する事ができる。デフォルト値でも十分使える気はするが、後で分析できるように考えながら設定してみる。懲りすぎると逆に混乱するので注意が必要。。。 プロジェクト この単位でトラッカー、メンバー、ソースコード管理システムのリポジトリ、Wiki、アナウンス、文書などを登録、公開する。ソフトウェア開発の場合は、管理対象のソフトウェア毎に作成するのが普通。 今回は、主にIS仕事タスク管理に使うので以下プロジェクトを作成した。 既存システム目標管理(AD構築など数ヶ月かけて行う作業)その他何でも入れるプロジェクトを1つ1プロジェクトで全て管理する事も考えたが、数年使い続ける事を考えると、何らかの単位で分けたほうがいい。後々公開する事も考慮。 トラッカー トラッカーは、チケットの入れ物で、チケット発行時にどのトラッカーに含めるかを選択する。(ただし、後から

  • Redmineの使い方ベストプラクティスを考えてみる

    RedmineやTracのようなBTSはデータの持たせ方でいくらでも使い道が広がる。 しかし、裏を返せば、なんでもできるからどうやったらいいかが分かりにくかったりする。 そこで、これまでの経験から、最低限の使い方をきめておこうかと。 Redmineはデフォルトの状態(Ver0.8.0)として、カスタムフィールドは使わないで、使い方のベストプラクティスを考えてみる。 トラッカー トラッカーは以下を作成する。 設計 開発 テスト バグ 運用 会議 プロジェクトで使う場合は、だいたい上記作業が大分類になると思うので、トラッカーは作業大分類としている。「要件定義」とかもあるなら入れてもいいかもしれない。 ステータス 初期は「新規」。作業に入ったら「担当」。終わったら「終了」。この3つだけ使う。やらなくてよくなった作業は進捗を100%にして「却下」に設定してCloseする。 優先度 これはそのまんま

    Redmineの使い方ベストプラクティスを考えてみる
  • トラッカーの種類 - ようじのにっき

    ここ最近ずっと Redmine を使ってプロジェクトを運営してるんだけど、どうもしっくりこない、というか面倒臭い、というかわかりずらい…んで、運営方法を色々と見直しているんだけど「トラッカーの種類」。これが諸悪の根源。たぶん複雑すぎた。WBSのすべてのフェーズのタスクと1対1でチケット化してしまっていることや、作業実績を細分化して統計情報を取ろうと思っていたこともあって、トラッカーをかなり細かく設定してしまっていた。いろいろと試行錯誤してみたんだけどたぶんこの程度↓で充分な気がする。Feature 機能. 設計やプログラミング、テストなどはすべてこれ。 基盤構築と言われるような作業(サーバー構築や初期設定など)もこれで良い気がする。Note メモやアイデア。Support ユーザー(顧客)からの問い合わせなど。 このチケットは Close するか、または Issue や Request や