クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
何でもデバッグできるようになるスキル - ワザノバ | wazanova
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
成長したいエンジニアは良いエンジニアの本棚を真似るといいんじゃない？ - Lean Baseball
あいさつ はてなブログでは初のエントリーです。 こんばんは、野球でPythonなガジェット*1の人です。 最近、私も年齢だけ無駄に「中堅」になったせいか、 仕事もプライベートも自分より若いエンジニアとコミュニケーションをとることが増えました。 みんな意識が高い人達がおおく、勉強会とか日曜プログラミングとか何とか、 前向きな話題が多くて、話をしていてすごく楽しくなります。 自分が楽しすぎて喋りすぎて「聖域*2」になってないか心配なぐらいです（汗） そんな話をしているうちに、自分のエピソードを思い出したのでちょっと書いてみたいと思います。 理解できる本を読んで、沢山読んで、キーマンをみつけること 初心者プログラマ向けの本の選び方 - Togetterまとめ いきなり引用で恐縮ですが（笑）、結城浩さんのつぶやきまとめ、これはすごくいいこと言ってると思いました。 自分が理解できる本を選んで、それを
シンプルさが勝つ。人間はシンプルではない。 - mizchi's blog
迷ったらシンプルな方— 片手間以上 (@mizchi) 2014, 7月 19 僕は主にUIを作るエンジニアなのだけど、以下の話題について。 時間をかけて、つまらないものを作りたいか？ - futoase.hatenablog.com ニコニコ動画はSynvieプロジェクトが原型 - はてな村定点観測所 UIの有効性を証明する仮説とその検証において、ほとんどの場合において次の二つが根源的な問題となる。 だいたいのものはシンプルな方が勝つ 人間はシンプルではない 二点間の距離を求める三平方の定理は、(ディスプレイが歪んでいない限り)簡潔でシンプルだが、二点のボタンを順番に押すときのマウスの軌道、そのあいだのユーザーのメンタルモデルの変化は、まったくもってシンプルではない。 人間はシンプルなものの価値を認めたがらない、というバイアスがある。金を産まないといけないソフトウェア開発の現場は、コアフ
スクールガールストライカーズの 内製クライアントエンジン
近年、ハイスペックなスマートフォン、高品質なネットワークが普及し、それによりモバイルゲームの制作手法やそれを取り巻く環境も変化してきました。スクウェア・エニックスでは、そのような環境の変化に対して、日々新たなチャレンジをし続けています。そして、このようなスピード感溢れる業界の流れには、会社の枠を超えた技術情報の共有、交流が欠かせないと感じております。 そこでこの夏、社内のエンジニア・テクニカルディレクターによる最新のモバイル開発の技術情報や社内モバイルエンジン、開発秘話によるセッションをメインに、スクウェア・エニックス モバイル オープンカンファレンスを開催する運びとなりました。また、セッションの後は登壇する弊社スタッフと直接ディスカッションやフリートークができる場を設けております。この機会にスクウェア・エニックスという会社についても、より詳しく知って頂ければ幸いです。 マネージャー・テク
色んな会社さんの新人エンジニア研修まとめ - oranie's blog
ちょうど今のチームに新卒メンバーが一人配属になり、「何からやっていこうかー」「今年の研修何教わった？」「今までどんな事やった事ある？」とか聞いている段階だった所にドワンゴさんの新卒研修の記事が流れてきたので、せっかくなので公開されている色んな会社さんの新人研修をメモっておく。なお、見たことがあるやつとか、ちょろっと調べてあくまでも自分と同じ職種に近いやつだけセレクトしているので、気の向いた人は「◯◯エンジニア編」とか作ると良いかもですね！ 他社さんの充実したメニュー見ているだけじゃなくて、うちのチームの配属になったメンバーが「このチームに配属されて良かった」と思えるような事を僕もやらないとですね。 @okb_mさんのまとめブログ Web系会社の新卒研修の内容をまとめた(自分の調べた範囲) 既に去年の段階で似たようなまとめを作られている人が。以下かぶっているのも結構あるので、そこはまあお察し
［SQEXOC 2012］FFXIVで使われているAI技術〜敵NPCはどうやって経路を探索しているのか？
［SQEXOC 2012］FFXIVで使われているAI技術〜敵NPCはどうやって経路を探索しているのか？ ライター：米田 聡 スクウェア・エニックスが2012年11月23日と24日の両日開催した「スクウェア・エニックス オープンカンファレンス」の最後には「AIセッション」が用意されていた。AIセッションは前半と後半に分かれ，前半は「ファイナルファンタジーXIV: 新生エオルゼア」（以下，新生FFXIV）における経路探索の実装に関する実践的な解説，後半はゲームAIの第一人者とも評される三宅陽一郎氏による，Luminous Studio用AIエンジンのやや概念的な話という構成だった。本稿では，まず前半の，より実践的なセッションから紹介してみたい。 テーマは，「MMORPGでマップ上を移動する敵NPCの経路をどう決めるのか」である。複雑で広いマップを有するMMORPGでは，移動する経路を賢く選択
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました matsuiです。 先週末の2014年6月13日～14日に、札幌でオープンソースカンファレンス 2014 Hokkaidoが行われました。 弊社インフィニットループもスポンサーとして、セミナーの発表を1コマと、ブースを出させていただきました。 その際に使用したスライド資料を公開しましたので、どうぞご覧下さい。 http://www.slideshare.net/infinite_loop/ss-35901898 おかげさまで満席でした。来て頂いた方ありがとうございます。 講師の佐々木、なぜか白衣です（理科の先生に憧れてるらしい）。 ブースはこのような感じです。 新作ゲームである「勇者と1000の魔王」と、Android用のタイムカードアプリである「かざしてシュキーン」を展示しました。 ツイート
昔の自分に教えてあげたい、新人プログラマへ伝えていること | Act as Professional
最近、この春に職業プログラマになった人達と話す機会に恵まれているので、共通して話すことを書いてみる。 大概、○○について、聞かせてください。とか、いろいろ聞いてくる人達は、羨ましいぐらい、すごく意識高い。 彼らは会社での仕事のプログラミングを上手にやりたい。ってのは、あたり前だし、 どうやってテストを綺麗に書くか？ テスト書きながらプログラミングするってのをどう学ぶか？ 綺麗な設計はどうやるのか？ 仕事でコードを書いていくってのは、どういうことなのかとか？ すごいコードはどうやって書くのか？ とか、いろんな事を学びたくて、何から学ぶべきなのか見失っているのではないかというぐらい、やる気に満ちあふれている。人それぞれ、やる気の方向性や現在のスキルセットが違うから何をしたいのか、した方が良いのかは異なっている。 だけど、ざっくり共通しているのは、結局のところ「ある程度のプログラマとしての実力を
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
programming - コードを書き続けるためにやってること - Qiita
プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1 . README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら Trello にタスクを移す 2 . 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く よく iPhone でコードを書いているのだが、オレオレ言語で書いている Erlang っぽい
デザイナーのわたしがプログラミングの基礎をだいたい3日で覚えた1つの方法
works デザイナーのわたしがプログラミングの基礎をだいたい3日で覚えた1つの方法 Posted by Miki Ishijima on May 20, 2014. フルスタックエンジニア！フルスタックエンジニア！ 最近なんでもかんでも出来る人が求められていますね。Webデザイナーの人でも簡単なプログラムに触れる機会は以前より格段に増えています。 わたしもプログラムを覚えたいと思い、勉強していました。しかしそれは、禁煙と同じようなもので触ってはやめて、触ってはやめて、飽きてしまうの繰り返しでした。 身につかない原因 プログラムの勉強会や、本、ブログなどを読んでもなぜ身につかないのか。難しいというのは理由ではありません。 むしろ、基礎の「き」くらいであればコーディングと同じくらい簡単です。 わたしが一番の原因だと考えるのは作りたいものがないというコトです。 子供向けプログラム学習アプリケー
プログラマが勉強すること - きしだのHatena
今日もプログラマになる勉強する人のところで話をしてきました。 で、また適当にいろいろ書いてました。 http://www.slideshare.net/nowokay/20140228-31742219 今日は特に、この図の内容についてまとめておきます。 ※ このエントリは、主に今日の話を聞いた人を対象としています。前提や補足については省略しています。 まずはプログラミング言語を プログラマというのは、利用者に直接サービスを提供することはできません。コンピュータの上でプログラムを動かして、そのプログラムを使ってもらうことでサービスを提供します。 ※組み込みは前提から外しています。 そのプログラムも、コンピュータで動くものを直接記述することは現実的にできません。 なんらかのプログラミング言語で、プログラムを書くことになります。つまり、プログラマの仕事は直接的にはプログラミング言語をいじくる作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
はてなブログチームの開発フローとGitHub
非同期処理の基礎
http://plus.appgiga.jp/masatolan/2014/04/04/51522/
