Cのプログラム先頭付近に，“#”で始まる命令がいくつか固まって書かれていることがある。中でもよく見かける#includeは，拡張子“.h”の「ヘッダー・ファイル」をソースコードに取り込む命令だ。「取り込まれるヘッダー・ファイルの中には宣言や定義が記されている」などと，本には書いてある。この宣言とか定義とは一体どのようなもので，どんな役割を果たしているのだろう？ ヘッダー・ファイルと#で始まる命令について調査した。 Cのコンパイルは2段階に分かれている Cの，特にコマンドライン・インタフェースのプログラムには， #include ＜stdio.h＞ という1行が，半ば「おまじない」のように記述されている。もちろんこれはおまじないなどではないが，printfなどの関数やifなどの命令語とも違う。#includeや#defineのように，Cプログラムで使われる“#”の付いた予約語を「プリプロセサ

リモート勤務を始めてから２週間が経ちました。 今回はその中で感じた色んな「予想以上」について書きたいと思います。 「予想以上」に遠隔地のハンデを感じないこれは一番不安視していたことでもあるんですが、現時点では遠隔地にいることで仕事に支障が出るということは感じていません。 ハートレイルズでは資料やコードは色んなクラウド環境を利用して共有しています。 その資料は膨大で見きれないなんてことはなく、良い意味で単純化されていて理解しやすい資料となっています。 そのため、ゴールや大体の方向性は共有した資料を通じて自然と合ってきます。 また、業務中はSkypeをオンラインにしていて疑問／質問等があればメッセージでやりとりして解決しています。 やりとりする中で言って頂いたんですが 「分からないことは何でも聞いてください、納得するまで聞いてください」 というスタンスでやりとりしているので、方向性がズレそうな

連載目次 「TIPS：コマンド・プロンプトを表示せずにコンソール・アプリケーションを実行するには？」では、Windowsアプリケーションなどから外部のコンソール・アプリケーションを実行する場合に、コマンド・プロンプトを表示させずに実行する方法について解説しているが、この際、実行する外部アプリケーションによっては、その画面出力がプログラムで必要になることがある。 本稿ではプログラムからコンソール・アプリケーションを実行し、その出力を取得する方法について解説する。 標準出力とそのリダイレクト 本題に入る前に、コンソール・アプリケーションの出力について簡単に説明しておこう。 たいていのコンソール・アプリケーションは実行結果などを画面（通常はコマンド・プロンプト）に表示するが、これはコンソール・アプリケーションが画面に描画を行っているわけではない。コンソール・アプリケーションは文字を「標準出力」に

コーディング規約は非常に色々なものが提案されているが、その色々なものを見て来た中で、かなり自分勝手な方向でまとめてみる。 はじめに コーディング規約というのは、さまざまな団体で独自に定められており、時にはそれが競合することもあろうかと思う。特にC++のプレフィックス関連が顕著だと思う。それに比べて、C#は割りと落ち着いたコーディング規約が根付いているのか、私の短いプログラミング人生の中で、そこまで読みにくいと思ったコードを見たことがない。これは、C#の言語構造やVisualStudioの自動整形も関係しているのかもしれないが。 というわけで、厳格なコーディング規約を設けずとも、それなりに読めてしまうC#でも、やはり規約を定めて、より読みやすく、統一性を持たせたコードを生産することは、非常に有意義なことだと考える。 代表的な記法 C#の命名規約についてを参考にしてほしい。一部を抜粋しておく。

GPLのコードを１行でも取り込んだ場合は、ソフトウェア全体をGPLで配布しなければいけませんが、BSDやMITライセンスのコードを一部取り込んだ場合のライセンス表記ってどうなってるんだろう？と思っていろいろ調べてみた。 BSDライセンスに関しては、Wikipediaによると以下のような記載がある。 「無保証」であることの明記と著作権およびライセンス条文自身の表示を再頒布の条件とするライセンス規定である。この条件さえ満たせば、BSDライセンスのソースコードを複製・改変して作成したオブジェクトコードをソースコードを公開せずに頒布できる。 ようするに、「無保証の明記」と「著作権表示」をどこかに書いておけばOKということのよう。 ちょっとひっかかるのが「ライセンス条文自身の表示」の部分。ライセンス条文を書いてしまったらBSDライセンスのコードを再利用しているソフトウェア全体がBSDライセンスで配布

去る5月18日、19日に社内ハッカソンを行った。 その企画・運営の１人として裏方の仕事を一手に引受け、色々と面白い経験が出来たのでまとめてみる。 1.目的 最初は「なんかみんなでワイワイやりたいね」的なところから始まったと記憶しているのだが、 えらい人「会社のお金使うからなんか有意義なことしたいね」 人事「じゃあ社外の人呼んでうちのエンジニアの空気を知ってもらってPRに使えたらよくね？」 えらい人「社外ゲスト付きハッカソンだ！」 ということで、多分うちの会社でも初であろう、社外ゲスト＋社内のエンジニアによるイベントということで方針が決まった。 俺氏「でも初のエンジニアイベントで社外の人招いてやるのは（主に俺が）大変では」 えらい人「一番むずかしいと思うことは最初にやっとくんだよ」 2.企画 ハッカソンに参加したことはない。だから実は何も分からなかったが、他のハッカソンのレポートとかを読みま

先週金曜日に慶應SFCのPBLの授業の中でチーム開発ではなぜタスク管理が必要なのか、タスクはどのように作るべきなのかについて基本中の基本を説明しました。 その際の資料を公開しておきます。 既にチームとして開発を行っている方にはたいして役にたたないと思いますが、新入社員とかへの説明には役にたつかもしれません。 プロの方でも役にたつかもしれないのは最後のページだと思うので再掲しておきます。 タスクの管理の仕方。 やらなければいけないことをなるべく網羅する（いきなり全部は無理） 誰がみても分かるように 何が出来るとそのタスクが終わるのかの条件をはっきりさせる 計画をたてやすくするために大きなタスクは処理しやすい大きさに分ける 進捗状況を分かるようにする（誰がやってる？もう終わった？） リストは定期的に見直す

対象OS：Windows 2000 Professional／Windows XP Professional／Windows Vista Home Premium／Windows Vista Business／Windows Vista Enterprise／Windows Vista Ultimate／Windows 7 Home Premium／Windows 7 Professional／Windows 7 Enterprise／Windows 7 Ultimate 解説 クライアント版Windows OSであるWindows 2000 ProfessionalやWindows XP Professional、Windows Vista、Windows 7には、Webサーバ／FTPサーバ機能を実現するためのIIS（Internet Information Services）が標準で提

RAIDは複雑な技術であり、その導入・運用にはさまざまな知識が必要だ。その中でも最初の難関といえる「RAIDレベル」について、分かりやすく解説。 重要な情報を蓄えるディスク・サブシステムを、不意のディスクの故障などから守ったり、あるいは高速化したりする技術として、RAID（Redundant Arrays of Independent（Inexpensive） Disks）はすでに一般的になった感がある。少なくとも、ローエンドを除くサーバについては、もはやRAIDを組み込んだディスク・サブシステムは必須といっても過言ではない。また、「動向解説：最新IDE RAID事情」で触れているように、IDE RAIDの登場によって、ハードウェアRAID製品の初期導入コストも下がってきており、ローエンド・サーバはもとより、クライアントPCでもRAIDを採用しやすくなってきている。 このように、コスト面で

米国の調査機関Pew Research Centerが現地時間2013年6月5日に公表した調査結果によると、同年4～5月時点における米国成人のスマートフォン所有率は56％となり、2年前に行った同様の調査の35％から大きく伸びた。米国成人の携帯電話所有率は91％で、そのうち61％がスマートフォンを利用しているという。 この調査は、2013年4月17日～5月19日にアンケートを実施し、18歳以上の米国人2252人から回答を集めた。スマートフォン所有率が50％を上回るのはPew Research Centerが同様の形式で調査を開始して以来初めてという。 これによると、スマートフォン普及率が最も高い年齢層は25～34歳で、81％がスマートフォンを所有している。この後18～24歳が79％でこれに次ぎ、以下は年齢が上がるほど普及率が低下する。35～44歳は69％、45～54歳は55％、55～64歳は

状態遷移表による設計手法について解説。今回は「状態遷移表を使用したテスト手法」の【前編】として、ホワイトボックステストとブラックボックステストについて詳しく解説する。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です――。ということで、これまで状態遷移表設計手法について詳しく解説してきました。具体的には、“要求分析モデル”“設計モデル”“状態遷移表からの実装”などのテーマを中心に、その設計手法を見てきました。 ご存じの通り、組み込みソフトウェア開発において、“手戻り作業”は非常にコストが掛かり、とても非効率なものです。そのため、前工程で不具合要因をきちんと抑えることが重要です。ただし、不具合が前工程で抑えられたからとい