EmacsでJavaを書く - nekop's blog
この記事は古い情報です。EmacsでJavaを書くという話 - Qiitaを参照してMaghanadaを利用してください。 日常的にJavaを書く人たちのたぶん99%くらいはEclipseかNetBeansかIntelliJ IDEAといったIDEを利用しているであろうと思われる現代において今日も元気にEmacsでJava書いている絶滅危惧種のnekopです。Emacs Advent Calendar jp: 2010の12月15日分のエントリは、EmacsでJavaを書くというあまり一般的ではないであろうトピックについてさらっと紹介します。昨日はkwappaさんでした。 お仕事ではRed Hatという会社でJBossというオープンソースソフトウェアのソフトウェアエンジニアをしています。詳細はばっさり省きますが、それなりの量のソースコードを毎日読み書きすることになります。それなりの量、とは
28歳から挑戦するITアーキテクト（4） その設計はちゃんと動くのか？
「プログラミング？ そんなことやってんじゃないよ。お前は管理者、見積もって下請けの会社に投げるのが仕事だろ。プログラミングなんてお金にならない仕事やるな」。 最近の若年層において、人気のある職種が「ITアーキテクト」であり、その対極として、最も嫌がられている職種は「プロジェクトマネジャー」といわれている。こうした多くのプロジェクトやSI企業では、十分なプログラミング経験を経ることなく管理者としてのスキルのみが要求されることが多い。ましてや、オフショアリングの浸透により、実際のプログラミングを日本では行う機会がどんどん少なくなってきているといわれている。 筆者のこれまでかかわってきた仕事においても、多くの若手「技術者」が、プログラミングコードではなく、WordやExcelなどを使った設計書作成ばかりに四苦八苦している状況を実に多く見てきた。こうした作業者の多くは、学校でC言語の基礎程度を学ん
オブジェクト指向開発を理解した開発者に、設計書は不要：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
プログラミング：プロの作り方が求められる実現工程
プロのプログラミングはアマとは違う プログラミングの工程は、設計内容を現実のソフトウェアへと変換する作業である。決められた言語やツールを使い、仕様書に記述された処理内容のプログラムを作成する。見付かったバグを解消するまで作成作業は続く。一般的に、単体テストだけはプログラムの作成者が行い、それ以上のテストは別な担当者が実施する。テストでバグが見付かると、プログラムの作成者が直し、この繰り返しが開発の最後まで続く。 仕事で作成する（＝プロの）プログラムは、趣味で作る（＝アマチュアの）場合と大きく違う。信頼性はもちろんのこと、変更しやすい柔軟性に加えて、処理内容が分かりやすい把握性も求められる。また、対象となる分野によっては、処理速度を限界まで向上させなければならない。このうちどれを重視すべきかは設計段階で考慮され、個々のモジュールごとに明示する。 プログラムに要求される特性のうち、アマチュアと
プログラミングは「設計」である - モジログ
「設計」を、以下のように定義してみる。 ・設計とは、設計図をつくることである。 ・設計図とは、「それに従えば、誰が作っても同じものができる」ものである。 ここで「誰が作っても同じ」というのはもちろん、作る人に一定のスキルがあるというのが前提で、また「同じ」といっても、許容しうる程度の違いはあるものとする。 建築の場合、建築家が「設計」し、工務店などの施工業者が「施工」する。 設計がきちんと作りこまれていれば、施工業者が作り出すものにはそれほど大きな開きは出ない。 しかしソフトウェアでは、「設計」と「実装」をそれほど明確に切り分けられない。 ソフトウェア開発において、「そこから先は、誰が作っても同じものができる」レベルとは、一体どのあたりだろうか。 モジュールやクラスを決めるくらいでは、「そこから先は、誰が作っても同じものができる」レベルにはほど遠い。 では、関数やメソッドのインターフェイス
オラクル対オープンソース： 今度はHudson - karasuyamatenguの日記
日本人(http://twitter.com/kohsukekawa)がリードする継続的インテグレーションツール(http://ja.wikipedia.org/wiki/Hudson)の開発コミュニティーとオラクルの間に摩擦が生じている。 http://www.hudson-labs.org/content/whos-driving-thing バックグラウンド： Hudsonはフリーソフトウエア(MIT License)だが、Kohsuke KawaguchiさんがSunにいたころ開発されたため、同社がプロジェクトのトレードマークを持っていたらしい。 買収によりSunのHudsonにたいする権利もオラクルのものになった。 元記事に詳しいタイムラインがあるが、肝心なところを拾うと： 開発はjava.netでホスティングされていたが信頼性の問題などからメーリングリストはgoogle gro
ソースコードの質：気難しいプログラマ：エンジニアライフ
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
