はてなブログチームの開発フローとGitHub
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
ハイパーバイザの作り方
「ハイパーバイザの作り方」公開ページ こちらのページはSoftware Design誌の連載記事「ハイパーバイザの作り方」の公開ページです。 「Linuxのしくみを学ぶ - プロセス管理とスケジューリング」も公開中ですので、こちらも是非ご覧ください。 公開中の記事 第１回 x86アーキテクチャにおける仮想化の歴史とIntel VT-x [HTML] [PDF] [ePub] [mobi] [Kindle] 第２回 Intel VT-xの概要とメモリ仮想化 [HTML] [PDF] [ePub] [mobi] [Kindle] 第３回 I/O仮想化「デバイスI/O編」 [HTML] [PDF] [ePub] [mobi] [Kindle] 第４回 I/O仮想化「割り込み編・その１」 [HTML] [PDF] [ePub] [mobi] [Kindle] 付属資料 最近のPCアーキテクチャにお
Qt - Qt Developer Day Tokyo
[プログラム] ラースノール、DIGIA、QtのCTOとQtプロジェクトチーフメンテ テクニカルセッション/トピック： Qt と Qt Creator Qt 5 Qt 組み込み開発 Qt モバイル開発 Qt Quick UI テクノロジー Qtの開発戦略にウェブを統合 Qt の開発者デイ東京2014には、Qtの専門家と対話し、日本語でQtの最新の動向について学ぶため最高の場所です。Qtのエンジニアや専門家が、全ての ご質問に答え、あなたと御社の時間とコスト節約のみならずQt活用に最大限役立つプレミアイベントです。詳しい発表はDigiaサイトをご参照いただき、お知らせメーリグリストへのサインアップをお待ちしております! [English version] Qt Developer Day Tokyo is one full-day of keynotes and technical se
グーグルのDIYスマホ｢Ara｣、開発者用キット公開
夢のカスタマイズスマホに向けて着々と進んでる。 グーグルはユーザー自身が自在にカスタマイズできるモジュール型スマートフォンAraについて情報をかなりオープンにしています。今週は開発者向けにモジュール開発キット（MDK）が公開され、技術的な面も含めてさらに詳細が明らかになってきました。 MDKに付属のドキュメントの内容は当然技術的なものですが、個々のモジュールと｢Endo（Endoskeletonの略かな？）｣と呼ばれるメインフレームとの反応の仕組みまで見られて興味深いです。 その他にも｢バッテリーが複数載せられる｣という性能についても書かれていました。ちょっと紹介しますね。 Araユーザーは、端末に対して複数のバッテリーを使うこともできる。複数搭載することができれば、消耗したバッテリーを新しいものと交換することもできるし、その際電源をオフにする必要もない。Araに搭載されたこれらのバッテリ
「60万人の一流プログラマ」が「成功率93％のSI」を実現するtopcoder
topcoderというと「競技プログラミングのサイト」というイメージを持っている人が多いだろう。もちろん今でもその性格は色濃く残っているが、最近では「企業がシステム構築（SI）に利用できるサービス」という面が強くなっている。企業が、自らが必要とするソフトウエアの開発をtopcoderでコンテストとして掲示し、そのコンテストに参加するプログラマの解答を募るのだ。 クラウドコンピューティングに強みを持つSIerの米Appirioは、2013年9月にtopcoderを買収した。Appirioの日本法人であるアピリオ 代表取締役社長の藤田純氏（写真）によると「93％強の案件で、コンテスト開催企業が満足する解答を得られている」という。逆にいえば、失敗率はわずか7％弱。一般的なSIでどれだけの顧客が結果に満足しているかを考えると、驚くべき数字だ。Appirio自身も、顧客のシステムのプロトタイプ作成や
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか？』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
Raspberry Pi（ラズベリー・パイ）でここまで出来る！12のクールな使い方 | readwrite.jp
35ドルの小さなコンピューター、Raspberry Piのいろいろな使い方を一気に紹介！手頃な値段で買えるカードサイズのコンピューター「Raspberry Pi（ラズベリー・パイ）」が、世間のメカ好き達の創作意欲を奮い立たせている。本来は子供たちにコンピューティングに興味をもってもらう目的で作られたものだが、各種プロジェクト用により小さくて安いコンピューターを求めているプログラマー達の開発にも多く使われているのだ。 Raspberry Piに関する最初の紹介記事で、我々は初心者に向けた10のシンプルなチュートリアルを紹介した。しかしこれらのチュートリアルは、Raspberry Pi信者達が開発した事例のほんの一部にすぎない。まだまだ多くのプロジェクトがPiのコンピューティング能力を限界まで活用し、この小さなデバイスの様々なすばらしい用途を我々に示してくれている。 関連記事： 新しい「Ras
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
本気でAndroid用のアイコンを作る
この記事はAndroidAdvent Calendarのエントリーです。 はじめにAndroidが国内に出回って5年が経ちました。 当初の標準アイコンのままアプリがAndroid Marketに公開されるような状態は落ち着き、時代とともにデザインも洗練され一定の秩序が見られるようになってきました。 しかし、未だにデザイン面を考察した形跡が見えないアプリも少なくありません。 スマートフォンは多数のアプリを使うため、ルールに基づいたプラットフォームで一貫性のあるデザインを土台にするのが操作性の良さにつながります。 独自性を出すためや新たな操作性を開拓するためにあえてルールを守らないと言う事もありますが、まずはデザインルールを知りその上で設計することが大原則になります。 ランチャーアイコンアプリデザインについて語る上でランチャーアイコンから入らない訳には行きません。 ランチャーアイコンはアプリの
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
イノベーションを起こせないエンジニアに価値はない─トライフォート小俣氏が語る、優秀なエンジニアの条件 | キャリアハック（CAREER HACK）
SIerとは違う、全く新しい受託開発のスタイルで存在感を発揮しているトライフォート。その代表でありCTOの小俣泰明氏に、今回は「市場価値の高いエンジニアとは何か」を定義してもらった。小俣氏いわく「自分でサービスを創れるか、否か」がエンジニアの価値を大きく左右するという。 ▼トライフォート CTO 小俣泰明氏へのインタビュー第1弾 エンジニアはCTOなど目指すべきではない―トライフォート 小俣泰明氏の提言。 注目スタートアップの代表兼CTOが語る、市場価値の高いエンジニアになる方法。 ※こちら2013年8月に取材した記事となります。2015年12月に小俣泰明氏はトライフォート社を退任済みです［2016/06/30/17:00 編集部追記］ SIerとは違う、全く新しい受託開発のスタイルで存在感を発揮しているスタートアップ、それが小俣氏率いる、“あえて”自社サービスを持たずに、技術を追求してい
Vagrantをはじめてみたい方へ「Vagrant入門ガイド」を書きました
「Vagrant入門ガイド」という電子書籍を技術評論社さんから出版しました。Kindle ストア と Gihyo Digital Publishing にて購入できます。 Vagrantは、まだエンジニアが中心に触っている状況ですが、いずれはWebデザイナーやコーダーの方など、サーバ構築を自分ではやらない人にも、制作するWebサイト、システムの動作検証を行う環境として利用する場面が増えていくと思います。 blog エントリなども多数あるのですが、断片的な情報も多く、また、Vagrant自身の進化が早いため、最新の環境だと上手くインストールできなかったり、動かないということがままあります。（このblogの過去エントリも。。。） もちろん、じっくりと調べていけば解決できる問題なのですが、できれば、はじめの一歩くらいは、まとまった情報が日本語であると良いなと思い、本書を書きました。 目次 本書は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Log in with Atlassian account