コードレビューで気をつける言葉や行い - macotox’s blog
コードレビューにstashを使ってます。 こいつはgitのブランチ間の差分に対してコメントをつけることができるツールです。 ただ、ネットを介したコミュニケーションって何故か気が大きくなってしまったり、感情が見えづらかったりで誤解を生みがちです。 特にコードレビューって間違いを指摘するとかあんまり楽しい会話をするわけでもないので、言葉には気を使わないといけません。 今日は自分が気をつけている言葉や行いを上げてみます。 否定しない def get_name(name) @user.find(name: name) end ☓：getは軽量なアクセッサとして使うのが常識なのでやめて下さい。 ◯：findしてることが分かるメソッド名が良いです いちいち否定する必要はないです。素直にどうして欲しいか書きましょう。 否定しない2 「けど〜」 def search(name) @user.find(na
プログラマーの強い味方！国内で代表的なソースコード共有サービス5選
プログラミングをしていて、「なぜ動かないんだろう」「同じことをしたくてもコードが分からない」ということはプログラマーなら一度は経験しているのではないでしょうか。 そんな疑問を解決するサービスが「ソースコード共有サービス」です。国内外のプログラマーが様々な言語のソースコードをインターネット上に共有し、協力して開発していくこともできます。 これによって開発者同士の協業を可能にし、開発のスピードアップや完成物のクオリティの向上にも繋げることが可能です。 今回は実際の開発現場の問題・課題を解決する手段としてソースコード共有サービスがいかに有効か、そしてサービスにはどのようなものがあるのかをご説明します。 このニュースを読んだあなたにオススメ baseタグ、styleタグ、linkタグの使い方 知らなきゃ損！パソコン上でホームページのモバイルでの見え方を爆速でチェックする方法 本当に使えるコーディン
成功したチームと成功しなかったチーム 20160608
10. 人数の多さだけではない？ No 種別 メンバ構成 成功？ 失敗？ 理由 プロデュ ーサー フロント サーバ ネイティブ 合計 1 SNS開発 1 3 4 2 10 成功 メンバ変更も少な く安定開発 2 解析基盤 0 0 3 - 3 失敗 業務が増え人手 不足で回らない 3 ツール開発 0 1 2 - 3 成功 少人数で安定開 発 4 ツール開発 1 1 1 - 3 成功 少人数で安定開 発 5 ツール開発 1 2 3 - 6 失敗 炎上＆空中分解 6 ツール開発 ？ 3 5 2 10 失敗？ ？ 11. 人数のメリデメ メリット デメリット おすすめのスタイル 8 小回りがきく 休めない 困ったらすぐ集合 4〜6人 チーム分割可能 「あれそんなことしてた の？」 誰かがチーム全体意 識しよう ７人以上 さらに チーム分割可能 夏休み取りやすい PM必須 PMは開発しない
デザイナー視点で見るサービス開発の舞台裏 - astamuse Lab
アスタミューゼデザイン部のMatsumotoです。 自社サービスastamuse.comとastaIDのビジュアルデザインを担当しています。 私のエントリでは、デザイナーによるエンジニアとはちょっと違う視点で見たサービス開発の話や、デザインに関するあらゆる情報を、今後お伝えしていきたいと思います。 技術ブログに期待して見に来てくれた方ごめんなさい。来週からエンジニアのエントリ始まりますので、お楽しみに！ 本日は、デザイン部の初回エントリなので、アスタミューゼのサービスやデザイナーの仕事を知ってもらい、なんとなくデザイナーの業務内容がイメージできるような記事を書いてみました。 デザイナーは日々何をやっているのか、何にこだわってデザインしているのか、全面リニューアルした2013年当時のastamuse.comの制作を振り返りながら、現在のサービス運用方法、今後の改善点などまとめてみました。 目
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
Linuxビジネスの成功者Red Hatが組織運営で心がける「オープンな意思決定フレームワーク」とは？
Linuxディストリビューション「Red Hat Enterprise Linux」を販売・サポートするRed Hat(レッドハット)は、技術者が分散した状態で製品開発を行っています。Linuxビジネスの中でも世界有数の成功企業のRed Hatのジム・ホワイトハーストCEOは、たびたび「一体、どうやって分散した場所の技術者の意見をまとめて一つのプロジェクトとして昇華させているのか？」という質問をされるとのこと。そこで、Red Hatが大切にしている「Open Decision Framework(オープンな意思決定フレームワーク)」について、プレゼンテーション資料として公開。オープンな意思決定フレームワークが、「オープンな意見交換」「参加型」「実力主義」「コミュニティ」「迅速かつ頻繁なリリース」という5つの原則から成り立つことを明らかにしています。 Red Hat Releases the
[翻訳] コードレビューについて
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。誤り・修正などがありましたら、@iwashi86までご連絡いただけますと幸いです。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化
![[翻訳] コードレビューについて](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b2b513cd4b9941cd623836a282bad7afa76c330/height=288;version=1;width=512/https%3A%2F%2Fiwashi.co%2Fassets%2Fimages%2Fogp-min.png)
社内の技術情報共有に GitLab Issue を使っている話 | バシャログ。
社内研修の準備でストレングスファインダーというのを受けてみた結果「適応性・最上志向・戦略性・収集心・着想」となったtanakaです。 社内の情報共有ツールとしてGitLabを使っている話を紹介します。 社内での技術情報共有って難しいですよね。それ自体で会社の売上や自分の給料が増えるわけではありませんし、でもやったほうがいいと大体の人は思っているはずです。 シーブレインでは入社した当時は社内サーバにMTOSを用意して情報共有ブログとして使っていました。あまり使われなくなっていまから3年前に社外サーバにWordPressサイトを用意して情報共有ツールとして使うようになりました。14ヶ月で450記事、月平均32記事とそこそこ使われていましたが、情報共有ツールとして以下のような問題を抱えていました 記事はMarkdownで書けるようプラグインをインストールしていたが、コメントはMarkdownで書
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
Slackでイラッとしない、コミュニケーションのコツ - 雲ようかん
社内コミュニケーションツールとしてサーバーワークスではSlackを使っています。 Slackは便利な一方でテキストでのコミュニケーションは注意が必要なため、以下のようなガイドラインがあります。 否定しない 叱責しない 2回で伝わらなければf2f これはこれで大事なのですけど、やっぱりちょいちょいイラッとすることってありますね。言葉の言い回しってテキストではより重要です。文章はニュアンスが伝わりづらいので誤解を招きやすく、それを見た相手が不愉快さを感じるとその後に少なからず影響する。それが積み重なるとコミュニケーションロスが発生する。悪い循環です。 Slack見てると、それが上手い人と下手な人っています。でもよく見るとちょっとした言い回しくらいしか違いがありません。3つほど紹介します。 1. 語尾をちょっと緩める 語尾を少し口語というか緩い感じにするだけで随分違います。 ＊＊＊してください。
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
デザイナーが書くコードについて思うこと（1） | ツクロア - DESIGN LAB
あらためてなるほどな、と思えるいい記事でした。 【これからのスキル】デザイナーとエンジニアの境界線がどんどん無くなる | freshtrax | btrax スタッフブログ 自分にも重なる部分があると思って経験と雑感込みで書いてみた、毎週水曜更新のデザインラボbyツクロア、今週私のターンではデザイナーがコードを書く意味についてです。 一枚絵では通用しないアプリデザイン 某携帯電話メーカーからAndroidアプリデザインの依頼があったときの話です。 電話着信画面や起動直後の待受ロック解除のデザインを含め、使い心地や操作感から画面構成まで一緒に考えてもらえるデザイナーを探しているということでした。 担当者いわく「静止画だけではアプリデザインの良し悪しが決められないんですよ」という話から始まり、では「実際うごくデザインモックを作りながら一緒に考えましょう」という作業の流れを提案して検証からリリー
アジャイルな開発には安全性が不可欠 : 現実世界の安全機構との3つのアナロジー | POSTD
(2016/7/15、著者プロフィールを修正いたしました。) 仮に、高速道路の自動車をより速く走らせることがあなたの務めだとします。もしあなたが、ドライバー全員にただ「アクセルを思いきり踏むように」と言ったら、一体どうなるでしょうか？ 結果は明らかに、大惨事となるでしょう。それなのに、ソフトウェアの構築を速めようとする時に、多くの開発者がまさにそんな態度を取っているのです。その理由として持ち出されるのは、以下のようなことです。 「本当にアジャイルに進めたいので、デザインやドキュメントには時間をかけられない」 「これは本番環境にすぐ反映しなきゃいけないから、テストを書く時間はない」 「何もかも自動化する時間はなかったので、コードのデプロイは手作業でやる」 自動車が高速道路を高速で走るには、安全性が欠かせません。より速く走るためには、ブレーキやシートベルト、エアバッグといった、いざという時にド
社内Wikiに情報を書くときに守ってほしい、たったひとつのルール - 無印吉澤
このページについて これは、社内 Wiki に情報を書くときに、私が個人的に守っていて、チームメンバにもできるだけ守ってほしいルールの紹介記事です。このルールを実際に運用するためのコツについても、基本ルールの派生という形で紹介します。 想定する環境 この記事は、社内に Wiki があって、フォーマットが決まったドキュメント（仕様書や手順書など）とは別に、各人がメモを自由に書いて共有できるような環境を想定しています。 Wiki の種類は問いません。PukiWiki、MediaWiki、Confluence、Esa、Redmine などのプロジェクト管理ツール付属の Wiki などなど……何でもいいです。Word 文書などにも適用できなくはないですが、文書を気軽に分けるのが難しい場面には、あまり向かないかと思います。 ルール：「このページについて」という欄をページの先頭に用意し、そのページの概
どのようにして高速に iOS アプリの UI を作り上げるか：動作モックの活用と実装時の UI 作りこみ - クックパッド開発者ブログ
Holiday デザイナーの多田です。 皆さんは Web アプリやモバイルアプリを開発する時、モックアップ作成にどれだけ時間を割いているでしょうか？もしくはモックアップを作成せずにすぐに実装に入るでしょうか？私はこれまで Web アプリ開発ではいきなり実装に入ることが多かったのですが、Holiday iOS アプリ の開発では Web アプリの時のように上手くいかないことに気づき、やり方を考え直しました。iOS アプリ開発の過程で、モックアップ作成や実装をどのように捉えるか、具体的にどう行うか、ということが自分なりに見えてきたので、それらについてご紹介します。 目的は、価値のあるプロダクトを速くユーザの手に届けること Web アプリやモバイルアプリの開発過程においてモックアップなどを作る目的は、あくまでも ユーザに届く プロダクトの価値を高めてそれを速くリリースすることです。適切な前準備は
朝会で進捗共有はやらない - ゆるふわカウンターアタック
朝会で進捗共有する。どこの現場も多いと思います。 必要ですかね？？ うちのチームでは朝会で進捗共有はやってません。 進捗のステータスはだいたい3つだと思ってます。 「オンスケ」 「早く終わった」 「ちょっと遅れそう」 そもそも3ヶ月くらい先の仕事がある程度チームでスケジューリング出来てる前提ですが 出来てなかったらマネージャがいないかマネージャが無能のどちらかです。 または、明日には明日の風が吹く現場だったらそもそも朝会とかマクロな話してる場合じゃないです。。 「オンスケ」これは明らかにいらないですね。朝会で全員の稼働を使っての共有？。。いらんいらん。だって問題ないんだもん。 「早く終わった」と「遅れてる」という状況は朝会ですべきじゃないです。それじゃ遅い。特に後者は。それがわかった時の新鮮な状態で教えて。なんで朝会待つの？？ だいたい「ちょっと遅れそう」はずるずる行くんだし・・。 進捗は
やさしいPHPコーディング規約の導入・完全版 - コネヒト開発者ブログ
はじめに こんにちは、社内でコーディング規約おじさんと呼ばれ始めて久しい高野(@fortkle)です！ ここ2ヶ月間ほどに渡って通常の開発業務とは別に社内のアプリケーションにコーディング規約を導入する試みをしており、PHP7 Casual Talks や PHP BLT などのPHP関連の勉強会で都度共有してきました。 今回はそれらをまとめ、共有したいと思います。興味のある方の参考になれば幸いです。 開発効率を阻害するもの 弊社が運営している ママリjp、ママリQといったサービスが順調に成長していっている中、その成長を支える開発チームの人数も少しずつ拡大しています。今後もこの流れは続くと思いますが、エンジニアたるものそういった場合でも「コードの質」は落とさずに成長させたいものです。 弊社では非常に丁寧にコードレビューを実施していますが、質の高いコードを維持し続けるためにはコードレビューをよ
エンジニア版“しくじり先生”に学ぶ、失敗を糧に成長する人、しない人【キャリアごはんvol.3レポ】 - エンジニアtype | 転職type
エンジニア同士が交流し、ごはんと悩みをシェアしながら 仕事人生の次の一手を探るためのワークショップ型イベント「キャリアごはん」のイベント情報やイベントレポートを紹介します 「失敗は成功のもと」という使い古された言葉を引くまでもなく、明日の成功をつかむためには、失敗からいかに多くを学び取るかが一つのカギとなるだろう。 だが、失敗を糧に大きく成長する人がいれば、いつまで経っても同じ失敗を繰り返してしまう人もいる。その差を分けるのは何だろうか。 エンジニアtypeと@typeが主催する、エンジニアのキャリアを考えるためのワークショップ型イベント『キャリアごはん』。第3回は3月24日、「サービス開発の失敗学～仕事の”しくじり”をその後のキャリアに活かすには～」をテーマに開催した。 ゲストスピーカーには経験豊富な以下の4人の著名エンジニアを迎え、失敗を成功へとつなげるために必要なこと、さらには開発、
GitBucket 3.13をリリースしました - たけぞう瀕死ブログ
Scalaで実装されたオープンソースのGitサーバ、GitBucket 3.13をリリースしました。 https://github.com/takezoe/gitbucket/releases/tag/3.13 ワイドスクリーンに適した新しいUIへの変更 GitBucketはこれまでなるべくGitHubに近いUIを提供してきましたが、このバージョンからワイドスクリーンに適したサイドバー付きの独自UIに方向転換しました。 この方向転換はGitHubとの類似性を排除するための措置です。詳細については以前のブログエントリを参照してください。 takezoe.hatenablog.com Issue一覧取得APIのレスポンスにpull_requestキーを追加 GitBucketのIssue一覧取得APIはペイロードにpull_request というキーを含まないため、GitHubプルリクエストビ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
標準化規約 2.Java標準化規約 - Fujitsu Japan