タグ

チーム開発に関するmasayoshinymのブックマーク (383)

  • チームとして少ないミスで素早くアプリを継続的・持続的に作り続けるためのメソッド - Qiita

    この投稿は DroidKaigi で話そうと思ったけど採択されなかった RejectedKaigi な内容です。 プログラムは、書けば書くほど複雑になります。行数が増え、分岐や繰り返しが増え、メソッドが増え、クラスが増え、パッケージが増え、管理するものは日に日に増えていきます。これらのものを使う側からすると、使うものが増えるということは、それだけ覚えることが増えることになります。勿論、IDE やエディタプラグインによって、そのような労力が極力減らされることもありますが、覚えることが少ないに越したことはありません。 この記事では、IDE やエディタプラグインはひとまず脇に置き、チームでコミュニケーションを取りながらコードを書くという観点で、従来のプログラミングのプラクティスを基に、開発時のミスを少なくし、チームで素早くアプリを作り続けていく方法論を深めていこうと思います。 Agenda 型を

    チームとして少ないミスで素早くアプリを継続的・持続的に作り続けるためのメソッド - Qiita
  • 破綻しにくいCSS設計の法則 15 - Qiita

    ブラウザスタイルは平坦化しておく リセットCSSはオプトアウト可能にしておく 登場頻度の高い組合せはplaceholderとして登録してから利用する 可能な限り画像はスプライト生成してから利用する それ以上分解不可能なコンポーネントは要素のように扱う コンポーネントは自己完結型のものを使う BEMはDRYになるよう粒度を下げる 可能な限り@extendは利用しない レスポンシブでない場所では、Utilitiesクラスを活用する shame.cssはいつも綺麗にしておく 詳細度または特異性の高いものほど後方に記述する 可能な限り!importantしない 可能な限りハックしない 変数をデザインガイドとして活用する CSSファイルを分割するメリットはほとんどないので一つにまとめる 1. ブラウザスタイルは平坦化しておく 例えば、こういうScrap & Buildは単に通信量のムダ。 * { f

    破綻しにくいCSS設計の法則 15 - Qiita
  • VMイメージ内でMACアドレスとインターフェース名(eth0とか)の関係が固定化されるのを防ぐ - Qiita

    今時のLinuxはudevが親切にもネットワークインターフェース名とMACアドレスの関係を固定化してくれるんだが、この機能って同じディスクイメージの複製が使いまわされることが前提の仮想マシンを前提にすると非常に邪魔になる。具体的にはコピーしたイメージ上ではeth0が出来なかったり、eth1になっちゃったりとか…。 このMACアドレスの固定化設定は/etc/udev/rules.d/70-persistent-net.rulesというファイルにシェルスクリプトして保存されている。なのでこれを削除してやれば次回起動時は期待通りにeth0が使えるようになる、のだがその際にまたこのファイルが再生成されてしまうので非常に邪魔! というわけでVMイメージの場合は消すだけじゃなく、以下のようにファイルが出来るべき場所にディレクトリを作っておくことでファイル作成が出来ないようにして防ぐってことをしている。

    VMイメージ内でMACアドレスとインターフェース名(eth0とか)の関係が固定化されるのを防ぐ - Qiita
  • 炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita

    ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない!これも出来てない!どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 (ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。) ただ

    炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
  • チーム間のコミュニケーションを円滑にしたい時に試してみるべきツールやWEBサービス色々 | バンクーバーのうぇぶ屋

    別にWEB屋に限らず、誰かとチームを組んで作業する時、いかにしてコミュニケーションの質を上げるかと考える人は多いと思うんですね。 かくいう僕なんかは、たかが数人のチームコミュニケーションでも相当大変な思いをしているので、これが数十人と規模が拡大した時のことを考えると憂なので、ぼちぼち対策を考えないといけないなと思うんですね。 そこで今日は、とりあえず手っ取り早くコミュニケーションの質を上げる為になんか良いツールが無いか探してみる事にしたので、ちょっと共有してみようと思います。EvernoteとかDropboxとかBasecampとかはとりあえず省いて、ここ数ヶ月の間に使い出した/知った物を中心にご紹介させて貰えればと思います! もちろん、コミュニケーションの質をあげようという考え方自体人によってまちまちでしょうし、必要なのはツールでは無く意識の問題であることが多いのは承知の上なのですが、

    チーム間のコミュニケーションを円滑にしたい時に試してみるべきツールやWEBサービス色々 | バンクーバーのうぇぶ屋
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
  • 大規模スクラムの失敗から学んだこと #AgileJapan2015

    7. 大規模スクラム PO Lead Company Board UX Specialist Portofolio Architect PO Lead Architect Releaser Architect Releaser Product Product Scrum Support

    大規模スクラムの失敗から学んだこと #AgileJapan2015
  • Gitでやらかさないための事前予防策 - Qiita

    Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

    Gitでやらかさないための事前予防策 - Qiita
  • プロジェクト管理や共同作業をより効率的に--生産性向上ウェブツール10選

    Jack Wallen (Special to TechRepublic) 翻訳校正: 石橋啓一郎 2015-04-09 06:30 生産性を向上するためのツールは、この5年間で劇的に変わった。かつてよく使われていたスタンドアロンのアプリやクライアント・サーバ型のアプリの多くは使われなくなった。今では、ビジネスのスピードはウェブで決まる。ウェブは、企業が抱えるタスクのほとんどを支えられるようになっている。ローカルにインストールされたクライアントアプリからウェブベースのアプリに移行するには、IT部門が抱えるユーザーの仕事のやり方を一新する必要がある。そのため、選択するウェブベースの生産性向上ツールについては十分な検討が必要だ。 信じられないかもしれないが、これらのツールの多くは、従来使われていたものよりもはるかに費用対効果が高い。さらに、信頼性も高く、従業員がはるかに高い生産性を発揮できるよ

    プロジェクト管理や共同作業をより効率的に--生産性向上ウェブツール10選
  • コードレビューに費やす時間を短くする - クックパッド開発者ブログ

    はじめに こんにちは、広告事業部の芳賀(@func09)です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ1年になるのですが、初めはエンジニア以外の人(営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます)と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTG相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。

    コードレビューに費やす時間を短くする - クックパッド開発者ブログ
  • bitbucketからの自動デプロイ - Qiita

    gitでの話ですが、bitbucketにpushして自動でサーバにデプロイするまでの一連の流れをメモ ネットで探すと見つかるのですが、ちょっとわかりにくかったので 開発初心者なのでいろいろよろしくないやり方も多いと思います もしご指摘あれば頂けるとうれぴーです こんなんでも誰かの役に立てばいいなと思いました 全体の流れとしては、 1. bitbucketにpush 2. (自動的に)bitbucketからサーバにPOST 3. PHPでPOST受けて、(自動的に)git pullする って感じ 環境とか 下記の環境やら想定でやってます bitbucketでgitでコード管理している サーバ:さくらVPS 1Gプランのやつ サーバでgit,PHPが動く bitbucketの設定 ログインしたら、右上の方にある歯車アイコンをクリック 左メニューのServicesをクリック 下のような画面になる

    bitbucketからの自動デプロイ - Qiita
  • 共通化でモチベーションと効率が低下した話 - Qiita

    自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ

    共通化でモチベーションと効率が低下した話 - Qiita
  • HoiとSlackで内緒話をする

    社内のチャットツールをSlackに移行中です。Slack使いやすくて満足度高いのですが、クラウドサービスゆえにこれまで社内IRCサーバ上でやりとりしていた情報の一部を載せてはいけなくなりました。 以前つくった「ほい、これ」ってファイルを渡せる Hoi というツールを使うことで外部から参照できないページのURLをやりとりに使えるのですが、やりとり用にファイルが必要だったり、URLを別途通知するという手番が面倒になってきました。(GH:EのGistでも同様ですね) monochromegane/hoi 面倒は解決しましょう。以下、Hoiのソリューションです。 メッセージをやりとりする 今までのファイルやりとりに加え、メッセージにもURLを付与できるようになりました。 使い方は今までと同じで、引数が存在しないファイルの場合にメッセージと見なします。 以下のようなURLが出力されます。 http:

    HoiとSlackで内緒話をする
  • スタイラスペンメーカー「Adonit」の無料とは思えない高機能お絵かきアプリ「Forge by Adonit」

    「Jot Pro」や「Jot Mini」、「Jot Touch」などスタイラスペンの開発・販売を手がけるAdonitが、ついにiOS向けお絵かきアプリ「Forge by Adonit」をリリースしました。Forgeは無料でありながらも機能が豊富で快適な操作を堪能できるとのことなので、実際に使用してみました。 Forge by Adonit on the App Store on iTunes https://itunes.apple.com/us/app/forge-by-adonit/id959009300 上記URLを開いたら「INSTALL」をタップ。 インストールが終了したらForgeのアイコンをタップして起動します。 「START」をタップ。 チュートリアルが始まるので画面の指示に従って終わらせます。 チュートリアルが終わったら「SKIP EMAIL SIGNUP」をタップ。 ホ

    スタイラスペンメーカー「Adonit」の無料とは思えない高機能お絵かきアプリ「Forge by Adonit」
  • 名前付けのすすめ / GMOペパボ株式会社 鹿島恵実(かしめぐ)

    2. 自己紹介 • 鹿島恵実(かしまめぐみ) • 千葉市出身 28歳 • ブログサービス「JUGEM」の デザイナーとしてペパボに入社 • チームのリーダーをしたりスクラム マスターをしたりたまにデザイナー • 好きなパイルドライバーは スタイナー・スクリュー・ドライバー

    名前付けのすすめ / GMOペパボ株式会社 鹿島恵実(かしめぐ)
  • PART4 全員のタスクを見える化

    タイムリー開発の現場では、メンバー間の情報伝達の速度が重要だ。DevOpsツールで情報の連携やプロセス状況の共有を図る。実際に効果を上げたNTT先端技術やイトーキの取り組みを見てみよう。 NTTデータ先端技術:ツール連携で伝達漏れ防止 Redmine、Git、Gerrit、Jenkins など ソースコードを素早く改修しても、後のレビュー作業が遅れたり、テスト用の環境が不足したりすると、全体の開発スピードは上がらない―。このことを以前のプロジェクトで痛感したと話すのは、NTTデータ先端技術の志田隆弘氏(ソリューション事業部 クラウド基盤ビジネスユニット クラウドグループ シニアエキスパート)だ。 志田氏らのチームは、クラウド基盤を構築するためのOSS「OpenStack」の拡張機能を開発するプロジェクトに参加した。このプロジェクトは当初、作業の引き継ぎがうまく行かずに、レビューやテストでた

    PART4 全員のタスクを見える化
  • ソーシャルコーディングの時代に置いてはエンジニア以外もレポジトリ(GitHub等)を見るべき : D-7 <altijd in beweging>

    ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。 昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。 が、21世紀に入って10年以上過ぎてい

    ソーシャルコーディングの時代に置いてはエンジニア以外もレポジトリ(GitHub等)を見るべき : D-7 <altijd in beweging>
  • 正式版がリリースしたAvocodeの便利な使い方をご紹介(コリス限定の優待コードもあるよ) | コリス

    制作の効率が劇的にアップする『Avocode』の正式版が、1/29にリリースされました! Avocodeは簡単に言うと、PSDのプレビューや書き出しをPhotoshop無しで行うもので、書き出しは画像だけでなく、SVGCSSにも対応しています。画像のスライスやスタイルシートのコーディング作業がググッと楽になるWin/Mac/Linux対応のアプリです。 正式版で、特に大きく変わったのがデザイナー用簡単GitHub。これは無料で単体利用できる機能で、PSDファイルの共有やリビジョン管理が非常に簡単にできます。 ベータ版の時から、そして正式版がリリースされてからみっちりと試したので、Avocodeの使い方や登録方法を紹介します。 Avocode Avocodeには無料と有料のプランがあり、有料プランの優待コードがコリスのビジター限定でもれなく使用できます。無料プランだけを使ってもよし、有料プ

    正式版がリリースしたAvocodeの便利な使い方をご紹介(コリス限定の優待コードもあるよ) | コリス
  • [2]「FUJI HACK」体験記(後編)――「つながりマップ」開発にチーム力を結集した結果

    [前編から読む] (前回までのあらすじ)徳田恒司氏は、富士通の社会基盤システム事業部第二システム事業部に所属するSE。上司の指示で、富士通の社内ハッカソン「FUJI HACK」に参加することになった。当初、普段の職場環境と違う会場の雰囲気に気圧されていたが、次第に自分のアイデアを形にしたいと思うようになる。ハッカソン1日目の後半に実施したチーム分けの際、来リーダー候補に選ばれていなかったものの、自ら立候補してリーダーを買って出た。 富士通の徳田恒司氏(写真1)は立候補によってリーダーになり、チームを率いることになった。今回のハッカソンでは、プログラマー、デザイナー、ビジネス担当を混ぜてチーム編成する決まりだった。ハッカソンに参加する際、自分はどのスキルを持っているかを名札で色付けされていた。プログラマーは青、デザイナーは黄色、ビジネス担当は緑だ。 徳田氏の下に集まったメンバーには当初、

    [2]「FUJI HACK」体験記(後編)――「つながりマップ」開発にチーム力を結集した結果
  • Evernote社もご愛用~InVision(インビジョン)の使い方:登録編

    ※各固有名詞のカタカナ読みはユーザーによって異なるため、一つの参考としてください。 InVisionってどんなサイト? InVisionは、デザインのラフスケッチを共有し、複数人でアイデアを出し合いながらデザインプロトタイプを作成できるサービスです。以下のような、Web業界をけん引している一流企業もデザイン段階でInVisionを取り入れているそうです。 Evernote、ebay、razorfishなどの、世界中で知られているWeb企業も、こぞってInVisionを愛用しています。スタートアップ企業として「アジャイルで競争に打ち勝つ」ため、グローバル企業として「より良い製品をデザインする」ため、またデザインに特化したエージェンシーとして「顧客との関係を進化させ続けていく」ため――より良いサービスを作り世界にチャレンジするために、デザインの力が注目されています

    Evernote社もご愛用~InVision(インビジョン)の使い方:登録編