やればできる 卒業論文の書き方 中田 亨 2003年10月15日初版。2009年4月27日改訂 工学部の標準的な卒論の書き方について説明します。修士論文でも博士論文でも書き方は同じです。 第1部 卒論クイックスタート 卒論とは? 他人の真似ではないアイデアが、 それが理論的に可能である理由、 やってみた証拠、 どんなふうに役に立つか、 とともに記述されている、組織立った文書。 卒論は習作であり、基準は甘い。対外発表論文では第1条が「他人のアイデアより明らかに優れたアイデア」と厳しくなる。 「新しい意味を伝えることが、命題の本質である。」(ウィトゲンシュタイン) 標準的な卒論の構成 題目: 説明的なタイトルを付ける。例えば「人体計測装置の研究」では舌足らずであり、「赤外線平行投影法を用いた人体計測装置」とか、「海中でも使用可能な人体計測装置」などがよい。(私の上司の金出武雄氏の方式)。 要約
梅雨。部屋干しした洗濯物による異臭騒ぎに苦しむmikioです。今回は、Tokyo Cabinetのテーブルデータベースで超お手軽に全文検索をする方法について説明します。 使い方 テーブルデータベースについてまずおさらいしておきましょう。PerlやRubyのハッシュのようにコラム名とその値を関連づけた構造を、主キーを識別子として保存するデータベースです。例えばRubyからデータを保存するに以下のように行います。データベースであることをほとんど意識させないというのが素敵ポイントです。APIはCでもPerlでもRubyでもほとんど同じなので、言語にかかわらず同じようにレコードを操作できます。 require 'tokyocabinet' include TokyoCabinet # データベースを開く tdb = TDB::new tdb.open("casket", TDB::OWRITER
あまり広報していませんが、昨年、両手親指キーボード tagtype Garage Kit が、ニューヨーク近代美術館のパーマネントコレクションに選定されました。 この選定は、私にとっては、特別な意味を持ちます。tagtypeキーボードをデザインする以前の私は、様々なプロダクトをデザインしながら「まだ理想には遠い」と感じていました。製品は、技術開発の根幹から、外観も中身も、ソフトウェア至るまですべて一貫した美意識に貫かなければならない。そう考えていたのですが、そんなことを依頼するクライアントがあるはずもなく、自分でやる技術力もなく…。 その状況が変わったのは、2000年前後。東京大学で私の教え子であった田川欣哉が、私のスタッフとなり、本間淳が外部スタッフとして参加してからでした。 二人は、ともに優秀なメカトロニクス・エンジニアであり、プログラマでした(特に本間は、そのうち奇人・天才シリーズで
Emacs 最新版の解説は Emacs24 のインストールと新機能 を参照してください。 概要 Mac OS X 上で Emacs23 の利用を始めてから使いこなしまでの解説。 今の所この文章はあまりコンピュータ初心者向けとは言えません。Emacs をまったくしらない場合はJFの文章である Emacs Beginner's HOWTO が参考になるでしょう。 またこの文章は http://macemacsjp.sourceforge.jp/ に書いた物を中心に個人的なメモをまとめた物です。 以下で Mac Emacs のメーリングリストを運営しています。Mac上で Emacs を利用している方は加入してみてください。 http://lists.sourceforge.jp/mailman/listinfo/macemacsjp-users またはてなで Emacs グループを運営しています
Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation. For the best experience please use the latest Chrome, Safari or Firefox browser. '("Kyoto.lisp Tech Talk #1" . "@taiju") 免責 当スライドで使用するLispコードはGaucheにて評価可能です。また、一部でGauche独自のメソッドを利用している箇所もあります。 当スライドでは、JavaScriptとECMAScriptという名前を使っておりますが、厳密に使い分けているわけではありません。文脈によって、適当
何故、エンジニアはUIのセンスがないのか、という自分にも当てはまるようなことについて書いてみる。 まずエンジニアがダメなUIを作ってしまう理由について、いくつかの仮説を立ててみる。 1.その画面を作るエンジニアは全てを知りすぎていて、もはやわからない人の気持ちがわからない説 2.エンジニアはITリテラシーは高いけど、自分ができることを人に理解できるように説明するのは下手説 3.技術的に実現する方に興味が偏って、ハナからUIの使い勝手に興味が無い説 4.国語力がない、自分が実現する文脈を表現するのはできるが、ユーザーの文脈に配慮した言葉を想像する力が無い説 5.仕様書を読まない、人の言う事を聞かない説。例えばOSが定めているユーザーインターフェースガイドラインに従わないので、UIパーツが意図した使い方をしておらず統一性に欠ける。 6.わかりやすい色や文字、レイアウトに関する知識が無い。センス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く