スマフォアプリゲーム開発における問題と対策 その２ - Qiita
上記のようにすれば、後からメンバーがどのタスクを処理したかは、担当者別でフィルタすれば確認できるので、振り返りにも便利です。 将来やるタスクが忘れ去られてしまう 忘れないために、実行する必要のあるタスクはすべてbacklog上にのせて、さらに将来の適当な日付をうって、backlogのガントチャート上にのるようにしております。 これで忘れない！はず。 クライアントからサーバにエラーが起きていると言われるがどのようなリクエストを投げたかわからない よくあるのがクライアントがサーバレスポンスが原因で、アプリが落ちた(500とかがかえってきた)けど調べてくださいというパターンです。 デバッガからの報告などの場合もあり、どうしても時間差があるので、どのリクエストかわからなくなってしまいます。 ユーザIDをもらっても多くのリクエストから探すのは骨がおれます。 そのための対策としては以下が考えられます。
スマフォアプリゲーム開発における問題と対策 その１ - Qiita
自分が関わっているスマフォゲーム開発で起こる様々な問題と、それをどのようなツールで解決しているのかを共有したいと思います。 同僚と話していたときに、他のチームがやっていて便利な事が共有されたらいいよねという話があったので、まず自分のチームのことから共有したいと思います。 pythonで開発していますが、どこでも起きうる一般的な問題が多いかなと思います。サーバのエンジニアをしているので若干サーバ視点です。 環境 クライアントはcocos2d-x サーバは python 2.7 + Django 1.8 クライアントはサーバにAPIで接続 サーバとクライアント開発は別グループ (それぞれ5人くらいずつ) ソースコード管理はgit 問題と対策メニュー 問題 対策
リモートワークでのコミュニケーションはGyazoを使いまくって会話している | リモートワーク - anywher
今回は、スクリーンショットを共有できるソフトウェアGyazo（ https://gyazo.com/ ）などを開発されているNOTA Inc.代表の洛西氏にリモートワークの取り組みについてインタビューさせていただきました。 名前も住所も性別も知らない人と５年間一緒にリモートワークをしていた Kato: リモートワークをはじめたきっかけはなんですか？ Rakusai: 10年以上前に紙copi（ http://www.kamilabo.jp/ )というソフトを開発してまして、サポート掲示板を設けてたんだけど、掲示板が荒れたりしてですね。「あのバグどうなってるんや」とかユーザーがどんどんサポート掲示板で勝手にやり取りするなかで、特定の人がずーっとサポートしてくれるようになったんですよ。 Kato: 特定のユーザーがですか？ Rakusai: そう。ずっと他のユーザーの質問とかに答えるようになっ
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita
はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。 アジェンダ 以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。 ツールはGithub,
【保存版】スクラム初心者でも5分で総おさらい！スクラムの超重要単語と導入方法
スクラムの導入は、わからない事が多くて知っている人がいないと導入が難しいという意見をよく聞きます。そこで、ステップバイステップで手順に沿って実施していくと、スクラムの導入がある程度完了していることを目指す説明をしたいと思います。 > スクラムとは?スクラムとは? スクラムはアジャイル開発手法の1つで、スクラムは「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされています。スクラムはフレームワークであり、スクラムガイドというスクラム標準の定義もあります。 > 大事な用語大事な用語 スクラムを実施するに当って、スクラムの文脈で頻出する用語の定義を説明します。 > 役割に関する用語役割に関する用語 【プロダクトオーナー】 プロダクトオーナーは、そのプロダクトについて何をどの順番で作るのかについて責任を持っています。 【スクラムマ
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
デザイナーがXcodeを使って 開発効率をUPさせた 5つのエピソード + 現場エンジニアのコメント付き
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。Read less
イカしたエンジニアになるためのイカしたコミットメッセージ - mmyoji's diary
2015-10-16 イカしたエンジニアになるためのイカしたコミットメッセージ Git 今お仕事させていただいている会社で、以前 【コミッター登壇】プログラマーのための「Rubyの世界」 - connpass で登壇された @idesaku さんとも一緒に働かせていただいてて、今日ありがたいことにマンツーマン(死語?)でgitのコミットメッセージについて講義をしていただいて、それがめちゃめちゃよかったのでブログに残しておこうと思います😊 commitメッセージに関する記事などを以前色んな人が書いてるのを見た気がしますが、個人的な経験として今日得られたのがインパクト強かったので、多少被ったりはしているかもしれませんが、そこらへんはスルーしてくださいmm 経緯 僕のPull Requestに付くコメントが毎回コード自体というよりは commit に関することばかり 「このコミットメッセージは
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
githubの運用戦術 - Qiita
前提 過去のチームといまのチームでどうやっているかの話 master以外なら force push 可能なことが条件 コミットコメント 一行で概要 WhyやHowを書かせる。 WhereやWhatはいらん、diffを見ればわかる。 (必要なら)詳細 なんでここにこういうことをした？ という細かい説明。 時間に追われてdirty hackをせざるを得なかったのならここにも書いて欲しい。 書かずに変なことしたら俺がハリセン issueだのメモだのへのリンクでもいい 諸注意 日本語OK 英語オンリーにするとみんな面倒臭がって little change for debug とか平然と入れる 詳しく書かせたいし読むのに苦労したくないので日本語を許す コミットのタイミングと粒度 粒度はできるだけ細かく。 １コミット単位でレビュワーがお前何がしたかった？をみるため。 レビュー中にレビューが入った部分は
進行中のデザインをクライアントも私もあれこれコメントつけあいながら確認できるサービス
クライアントさんに進行中のデザインを確認してもらうとき、どーしてます？ メールで画像を送る。確認してもらったあと、修正の要望をまたメールで返信してもらう。やっぱりこれが一番多いのかな。で、互いにうまく理解しあえない箇所は電話で詰めるという感じで。 本当は、クライアントさんもデザイナーさんも肩を並べて確認しあえたらベストなんですけどね。横で一緒にデザインを眺めながら、「ここをこういうふうに」「いやここはこういう意図があったもんで」なんて言い合いっこしながら進められれば、意思の疎通に苦しむことは、少なくなるでしょう。同じ箇所に対して、「ちょっとよくわかんないんだけど」とか、なんどもメールやメッセージのやりとりをすることからも解放されます。 でも、そんなに毎度顔を合わせた確認作業ができるわけなくて。クライアントさんも忙しいでしょう。もちろんボクも。そもそもネットと電話の回線だけで案件を進めるとい
朝Lint活動で細かな技術的負債を返済する - クックパッド開発者ブログ
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸGitGitHub Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
オレの理想の組織
2015/08/27 22:00 ※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】 「 サービスがある程度完成してるクッ○○○○にエンジニアが居ついている理由も興味ある 」 サービスの大まかな形ができあがるとエンジニアは新しい何かを求めて辞めてしまうことがあると思っているので、ふと不思議に思いました。 ※念のため言っておくと今自分が属しているエンジニアチームはサービス立ち上げ前から1人も辞めていません（もっといえばその前の動画共有サービスを旅する元AWSエバンジェリスト？から 押しつけられて もとい、引き継いで以来6年間誰も辞めていません。あくまでも現時点では…だけれども）。 理由も とあるのはもう一つ興味のあることが同時にあって、 「 あれ？D○N○ってフラット組織なの？あの規模でどうなってるのか興味ある 」 上意下達というか、上司がいて部下へ
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
スクリーンショットにコメントをつけてシェアできるツール
2017年11月23日 便利ツール Webサイトに修正指示を出す時、どんなツールで、どのようにシェアしていますか？該当ページのスクリーンショットを撮影し、その画像に指示を入れていく…という方が多いかな、と思います。今回はWebサイトの制作者のみならず、制作者に指示をだす人や、クライアント側も使える、修正指示がグンと楽になりそうなツールをいくつか紹介します！ ↑私が10年以上利用している会計ソフト！ AUN[あうん] AUN[あうん]はふせん紙の感覚でWebサイトや画像にコメントを残し、共有できるツールです。登録不要！無料で気軽に利用できるところが魅力的。対象となるWebサイトのURLを入力するだけでスクリーンショットを撮影でき、指示やコメントを残していけますよ。さっそく試してみましょう。 サイトからURLを入力し、読み込みが終わると、画面をトリミングするかどうかの選択画面が表示されます。読
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
人を使うということのオーバーヘッド | タイム・コンサルタントの日誌から
なんだかひどく忙しい。そう、あなたは感じている。やらなければならない仕事が山のようにたまってしまった。このままでは期限までにアウトプットが出せそうにない状況だ。自分の下に誰かつけてもらって、やるべき仕事量を分担して進めるしかない。 あなたは上司に窮状を訴え、一時的な手助けのために、なんとか若手を一人つけてもらえることになった。この部に入ったばかりの、まだ右も左も分からない新米だ。しかし贅沢を言っていられる状況ではない。周りも皆、忙しいのだ。儲かってもいないのに、ウチはなぜこんなに忙しいんだ？ あなたは独り言をつぶやきつつ、そもかくその新米を席に呼ぶ。頼みたい仕事を説明するためだ。 頼む仕事は、比較的単純だ。あなたが作ったExcelシートに条件の数字をインプットして、何種類かケーススタディをしてほしい。あなたは、ある案件の原価と収支を計算して、売価や条件を関連部門に連絡しなければいけないの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
