Web Developer Checklist: Website Launch Checklist | Toptal®The ultimate checklist for all serious web developers building modern websites. Make sure your site follows web development best practices.
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
Source Code Counter
Source Code Counter (SCC) SCC is a cross-platform tool written in Java to count the number of lines in source code files. Counting the number of lines in source code files can usually be done using command line tools under Unix or with an IDE, but SCC extends this to be a far easier and more customisable process. This is achieved using the following methods: A GUI is used to give the user complete
Telerik JustDecompile is Retired
Telerik JustDecompile is RetiredLearn more about Telerik JustDecompile discontinuation and end user options. Why is Telerik JustDecompile Being Retired?Empowering development teams to work with the most comprehensive toolset requires a periodical revision of Progress Developer Tools offerings. It goes both ways - adding new products to meet evolving business needs and retiring products that have s
アジャイルチームにおけるコードレビュー - Sean_SF’s blog
@daipresents さんが「アジャイルなレビューをサポートするツールを5つ」というブログ記事を書かれていました。 コードレビューによりコードの品質を改善することは知られていますが、@daipresents さんのチームのように実際にコードレビューを行っているチームはそれほど多くないと思います。 アトラシアンにおいては、基本的に全てのコードをレビューしています。その方法やヒントなどを説明したブログを以前にいくつか公開しておりますので、参考までに抜粋して下記します。 アジャイルチームにおけるコードレビュー - パートII コードレビューを行う際に留意すべき点として以下の9つを挙げています。 軽量に保つこと 強制しないこと 細かく管理しないこと 非同期のレビューを奨励すること コードレビューを通して、興味深い発見、構成、設計上の決定を積極的に共有すること - チャンピオンになりましょう コ
5つの世界 - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない：あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ！ ソフトウェア開発には
プログラマブルなインフラ、Ruby、JavaScriptなどが重要なテクノロジと評価される。ThoughtWorksのレポート
プログラマブルなインフラ、Ruby、JavaScriptなどが重要なテクノロジと評価される。ThoughtWorksのレポート オブジェクト指向やアジャイル開発などを広めてきたMartin Fowler氏が所属し、アジャイル開発のコンサルティングなどを行っている企業としても知られているThoughtWorks。同社は、IT業界内のさまざまなテクノロジーの中から、重要性を増しつつあるテクノロジーや、逆に影響力を失いつつあるテクノロジーなどを紹介するレポート「Technology Radar」を不定期に公開しています。 そのTechnology Radarの2011年1月号が公開されました。いままでPDFバージョンしかなかったのですが、今回はHTML版も公開され、より見やすくなっています。 Technology Radarは、開発技法を対象とした「Techniques」、ツールを対象とした「T
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
プログラマが直面する２つの「世界」 - elm200 の日記(旧はてなダイアリー)
プログラマというのはとてつもなく難しい仕事だ。 職業的なプログラムは、それが会社であれ、個人であれ、顧客の何らかのニーズを満たすために存在している。プログラマは、顧客の要求を満たすように、プログラムを設計・実装する。ここで注意しなければならないのは、「顧客の要求」と「プログラムの設計・実装」という全く異質な 2つの仕事を同時にこなさなければならないということだ。 顧客の要求は、社会というシステムに属し、プログラムは、技術というシステムに属する。この2つは全く似ていないし、何の関係もない。それが、「顧客要求を表現したプログラム」という一つの場で切り結ぶ。異質な2要素がぶつかり合い、プログラムコードはまさに戦場と化す。 書かなければならないプログラムの種類によって、この緊張度は異なってくる。たとえば、組み込みソフトウェアや科学技術計算などの場合は、要求自体がかなり技術的であるから、プログラムと
プログラマはもう要らない？、南米発のアプリ自動生成ツール | スラド IT
ITproに南米発のツールがIT業界に与えるインパクトという興味深い記事が掲載されている。GeneXusという南米拠点の会社のツールについての記事であるが、データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、JavaやC#、Ruby、COBOL、Cなどのソースコードを設計情報から自動生成する機能を備え、テーブル定義情報はMicrosoft SQL Server、Oracle Database、DB2、MySQL、PostgreSQLなど各種データベースソフトのフォーマットに合わせて自動生成するという代物らしい。 「プログラマはもう要らない」、「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。 そんなスーパープログラマを雇ったのと同じ効果が得られる」といった素晴しい言葉が並んでいるのだが、記事の3ページ目には、そもそも表現力
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gerrit - Google Code