苦Cの内容の転載などは自由ですが、苦Cからの引用であることを明記してください。 (どこかに「苦Cより」と書かれていればOKです。) 学校や会社などで生徒(新入社員)へのテキストとして使用することも自由です。 その際、内容を修正したり、印刷して配布するのも自由です。
サイト更新情報 2006/12/06 よく使われているページを検索窓から簡単に辿れるようにしました。(検索窓に「prototype」と入力) 2006/11/27 JavaScript入門/応用サイトJavaScriptistオープン! 2006/11/23 試して確認できるJavaScriptオンラインエディタを公開 2006/11/20 JavaScriptリファレンス、逆引きサンプル集を公開 2006/11/19 JavaScriptライブラリ活用ページ公開 2006/11/15 JavaScriptistベース機能の構築完了 過去のサイト更新情報
Java Programming Language Googleの20%プロジェクトからJava向けの新しい技術「cofoja (Contracts for Java)」が公開された。既存の実装に大きく手を加えることなく、デバッグをより簡単にしてくれる効果が期待できる。バグは些細なコードが起こすものだったりするが、それを追跡して発見するのは時に困難を極める。これは問題が発生した箇所と、実際にバグがある箇所が大きく離れていることが理由になっていることもある。問題発生箇所とバグ発生箇所を近くにまとめることができれば、それだけバグ発見も取り組みやすくなる。 cofojaはこれを簡単に実現するための技術。インタフェースに制約表現を追加可能にするところがポイントとなっており、クラスの実装に手を加えなくてもインタフェースに制約表記を追加することで実行時にチェックできるようになる。ブログに掲載されている
以下の様な構成でレイアウトにしたいと思います。 ファイル構成 Main.xml ougi.xml shake.xml MainActivity.java ougiActivity.java shakeActivity.java ShakeListener.java レイアウト構成 今回のサンプルアプリではxmlファイルが3枚、Javaファイルが4枚必要となります。 LayoutXMLとJavaClassの生成 まず、ougiActivity用のJavaクラスファイルを用意してみます。 プロジェクト/src/isa.androidにフォーカスをあてて右クリック。 「新規」→「クラス」を選択します。 名前に「ougiActivity」を入力して完了。 スーパークラスに「android.app.Activity」を入力 次にxmlファイルを用意してみます。手順は次の通りです。 プロジェクト/re
Unix系コマンドラインユーザーのための、 gcc/g++/g77 による開発におけるデバッグ術を簡単に紹介します。 以下の内容は gcc 2.7.2.3 での動作は確認しています。 g++/g77 でも恐らくは通用すると思うのですが、 ひょっとすると異なる部分があるかもしれません。 筆者は g++/g77 の使用経験がないので、その場合は御容赦を願います。 実行前 キーワード「コンパイルオプション, -Wall, -O2, -O4」 まずは gcc にオプション opt'-Wall' を付けてコンパイルし、 警告がなくなるまでソースを修正します。 これは 常識 です。 次に opt'-O4 -Wall' でコンパイルします。 「未初期化変数の使用」の警告 (`foo' might be used uninitialized in this function) は、 opt'-O4' を付
makeって何? † ソースファイルを分割して大規模なプログラムを作成していると、コマンドでコンパイルするのが面倒です。また、一部のソースファイルを書き換えただけなのに全部をコンパイルし直すのは時間の無駄です。 そんな問題を解決するのがmakeです。Makefileと呼ばれるテキストファイルに必要なファイルと各ファイルのコンパイルのコマンド、ファイル間の依存関係を記します。そして、“make”というコマンドを実行するだけで、自動的にコマンドを実行してコンパイルしてくれます。これだけではスクリプトと大差がないのですが、makeはMakefileに記された依存関係に基づいて更新されたファイルの内関連のあるものだけを更新することで、コンパイル時間を短くします。 makeは特定のプログラミング言語に依存したものではありません。C言語のソースファイルのコンパイルにも使えますし、Verilog-HDL
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書(Document)だ。文書は日本語や図から構成されており、読
いくつかの事に気をつけてコードレビューを実施するだけで、効率的にコードの品質を高めることができる。効果的なコードレビュー方法をまとめてみた。 (1)複数の有識者でレビューを実施する レビューアも人間なのでレビューが面倒になってしまうときもある。複数のレビューアが一緒にレビューすることによって、一人だけ「指摘なし」と言うわけにもいかず手抜きし辛くなる。 (2)事前に指摘事項をまとめておく ソースコードを読む速度はレビューアのスキルによって異なるため、レビュー時に読み合わせするのは時間がもったいない。調査が必要となることもあるし、じっくりと考えたいこともある。レビューは前もって行っておく。指摘箇所のフィードバックだけは対面で行うのがよい。 (3)印刷してレビューする エコではないが、指摘箇所を気軽に書き込めるのがよい。書き込み量をみるだけでレビューアがどれだけ丹念にレビューしてくれたのかが一目
Ruby on Railsをはじめとする最近のWebアプリケーション・フレームワークの多くは,MVCと呼ばれるデザイン・パターンを採用しています。今回は,このMVCパターンの「正体」について考えます。 MVCはGUIを備えたプログラムを設計する際の指針となるデザイン・パターン*1の一つです。「モデル」(Model),「ビュー」(View),「コントローラ」(Controller)という3つの構成要素の頭文字から命名されました。多くのデザイン・パターンはプログラムの一部のみの構成を決めています。しかし,MVCはアプリケーション全体の構成を決めることが多いため,「アーキテクチャ・パターン」と呼ばれることもあります。 MVCは,元々プログラミング言語Smalltalkにおいて,ウインドウ(GUI)を持つアプリケーションを構築する際の指針として誕生しました。 MVCを発明したのは,当時,米Xero
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス
「Code Reading―オープンソースから学ぶソフトウェア開発技法」(毎日コミュニケーションズ発行,写真1)という本があります。私はこの本の監訳者ですから,やや自画自賛になってしまいますが,ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール,データ構造,アーキテクチャ,さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家,他人の筆づかいを研究しなかった偉大な画家,同僚の肩越しに技を盗まなかった腕のよい外科医,副操縦席で実地の経験を積まなかった767機長――果たして,そんな人たちが本当にいるのでしょうか? たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち,他の人の
ここは…エクストリームプログラミング(eXtreme Programming = XP)を紹介するページです。 もしあなたがXPをはじめて知るのであれば、 最初に 導入記事 か、 FAQ を読むことをお薦めします。 また、当ページ内容は、「XP-jpメーリングリスト」で議論されています。 入会方法は、このページの末尾にあります。 自分たちの良いところを認識することからはじめるXP(07/11/07) 「テスト駆動開発(TDD)が分かると従来の設計手法の問題が見えてくる」 (04/04/27. by arton, IT Pro) http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/1/ XPの導入記事から、Martin Fowler, Kent Beck, Ron Jeffries, Ralph Johnson, William C. Wak
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く