CoolなソロとHotなペアプロのあいだ
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「（WIP）プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、２人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ
この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞
書籍「プリンシプル オブ プログラミング」を執筆しました - Strategic Choice
「プリンシプル オブ プログラミング」という本を執筆しました。少し先ですが、2016/03 下旬 発売予定となっています。 書籍紹介・目次 どのような本？ 構成は？ どうして必要？ どうやって説明？ 読んでほしい人は？ 書いた人は？ 最後に どのような本？ ソフトウェア業界で高名な、よいコードを書くための「プリンシプル」を紹介します。 プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」のことです。これらは、歴史の審査を受けて生き残った、よいプログラミングのためのエッセンス（「普遍的」「定説的」「本質的」な知識）です。 構成は？ プリンシプルを、７つのカテゴリに分けて説明しています。 第1章 前提 〜 プログラミングの変わらぬ真実 〜 第2章 原則 〜 プログラミングのガイドライン 〜 第3章 思想 〜 プログラミングのイデオロギー 〜
クラスの「継承」より「合成」がよい理由とは？ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD
コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが（または両方一緒に）衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。
[リーダブルコード] - Strategic Choice
どういうこと？変数や関数などの構成要素の名前は、抽象的ではなく具体的なものにします。例えば、「ServerCanStart()」という名前のメソッドがあったとします。任意のTCP/IPポートをサーバがリッスンできるかを確認するメソッドです。しかし、「ServerCanStart()」という名前は、少し抽象的です。具体的に「CanListenOnPort()」とするべきです。これなら、メソッドの動作をそのまま表しています。どうして？「名前が抽象的だと困ったことになる」という、こんなエピソードがあります。あるプログラムに、「--run_locally」という名前のコマンドオプションがありました。このオプションをつけると、プログラムがデバッグ情報を印字するようになります。ただし、動作が遅くなります。このオプションは、デスクトップなどのローカルマシンでテストをするときに使っていました。リモートサー
リスコフの置換原則 - 西尾泰和のはてなダイアリー
拙著「コーディングを支える技術」のp.216では、リスコフの置換原則について説明しています。しかし、p.217の「条件qを満たさないTが発生する」という表現はわかりにくいようですので、ここでストーリー仕立てにして補足説明をします 今日 まず、現時点でT型の値はすべて条件qを満たしているとします。 あなたはT型の引数をとる関数fを実装したいとします。あなたはきっと「T型の値はすべて条件qを満たしている」ということを前提としてコードを書くことでしょう。 1ヶ月後 あなたはSを作ろうと考えます。S型の値の中には条件qを満たさないものもありますが、あなたはあまり意識していません。 あなたは「SはTを継承して作ると楽だな」と思ったので、そうしました。 Javaなどの言語処理系では、SがTを継承すると、T型の変数にS型の値を入れることができるようになります。つまりこの時点でT型の引数を取る関数fにS型
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
Qoncept, Inc.
Realtime Visual Tracking Technology Specialists 画像処理によるリアルタイムトラッキングをコア技術として 高い専門性を持ったメンバーが集まり 実社会に活きる技術を開発し続けます Latest News ゴルフ弾道計測アプリ Golfboyが全世界で累計50,000ユーザーを突破 2022.10.19 - Tracking・その他 月間アクティブユーザー数は4,000ユーザーを突破 Golfboy（ゴルフボーイ）は、iPhoneのカメラを利用したゴルフの弾道計測アプリです。 スマートフォンと三脚さえあれば誰でも手軽に利用でき、独自の画像処理技術により 飛距離、ボールスピード、打ち出し角度、クラブ速度などをリアルタイムに計測します。 またスイング自動撮影、フォーム解析、パター解析、シミュレーションゴルフ機能など、 1つアプリで実現。他の追随を許さな
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
マルチコア時代のプログラマは関数脳になろう〜Java8のススメ〜 - Tech-Sketch
CPUのクロックアップに限界が訪れ、マルチコア化することで処理性能向上を目指す時代になりました。これからのプログラマには、マルチコアで処理性能が向上するプログラム＝マルチスレッドで並列処理が可能なプログラムを書く能力が必要になります。今回は「関数型」でプログラムを書くことによって、いとも簡単に並列化ができることを実例を元に解説します。 関数型プログラミングと並列処理 「関数型でプログラムを書くことで簡単に並列化できる」と書きましたが、そもそもここで言う「関数」とは何なのでしょうか？ 関数型プログラミングの特徴 関数型プログラミングの「関数」を理解するためには、数学における「関数」を想像するとわかりやすいでしょう。 例えば三角関数を用いた y=cos(x) という式を考えてみます。この式に入力値 x=0 を与えた場合、いつでも必ず結果は y=1 になります。x= π/3 の場合は y =
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
ペアプロ・TDDの『お題』をまとめてみた #tddbc #coderetreat #pp_con - Diary of absj31
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
Functional reactive programming in JavaScript
Mid May, I gave a talk at NodePDX on functional reactive programming in JavaScript. I discussed the general ideas behind the programming paradigm and various implementations that exist. The video is finally available online and the slides are also available. Here’s some links to the various different approaches to functional reactive programming: Flapjax Reactive Extensions (RxJS) Shafty Javelin B
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
これからRuby on Railsをはじめる人へ - VTuberになったプログラマーの魂の残滓
Ruby（on Rails）使い始めて半年、まだ自分自身探り探りという状態なのですが幸いにもお手本になる先生のお陰でなんとかやれているという感じです。 個人で勉強してる範囲でいろいろ見てきたものや読んだもの、参考にしている本などをざっとまとめておきます。 id:ukstudioによる勉強会の資料 まずざっくり概要を得るためにこれ読むとよさそう 特異メソッドあたりの解説は一旦スルーしていいかも Ruby&Rails勉強会 認証周りについてid:udzuraによる資料 自分で主催したRuby勉強会で（邪悪な顔で）発表してくれた資料 渋谷で勉強会してきました。（邪悪な顔で）発表もしました。 « blog.udzura.jp テスト周りについて @takaiさんのブログエントリ RSpecによるユニットテストの書き方 - tech.recompile.net またid:ukstudio先生の資料じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
jsdares
オブジェクト指向できていますか？
