テスト返却・解説＋参照カウンタ法
テストの回答・解説を行う。
メモリの使用量の総括
後期中間までの授業内容を総括し、処理速度をあげるためのテクニック紹介であった点を強調する。 しかし、プログラミングでは「速度」、「処理の複雑さ」、「メモリ使用量」が重要であるとの 視点から、「メモリの使用量」の話しをする。
リストなら、M(N) = (sizeof( data部 ) + sizeof( ポインタ )) * N 配 列 なら、M(N) = sizeof( data部 ) * N ただし、想定データ件数＝実際データ件数の場合。 現実は、C なら配列サイズは、固定なので、 M(N) = sizeof( data部 ) * MAX
参照カウンタ法
前の説明の「リストではポインタのデータ量が無駄」との話しを発展し、 malloc() は、もうちょっと無駄がある点を話したいので、参照カウンタ法の話しをする。
最初に、リストによる和集合計算のプログラムと、全リストの開放処理のプログラムを示し、 共有の発生するプログラムでは、全リスト開放で２重ポインタ開放が発生する可能性をしめす。 その解決法として、参照カウンタ法を示す。
最後に、参照カウンタ法の実例として、unix ファイルシステムでの参照カウンタの説明を行う。 参照カウンタ法の欠点(循環リスト)については、次週。
オープンな任天堂?
任天堂は、ファミコン時代の隆盛時の「ソフトコピーをさせないためゲームカートリッジ」 という方針を曲げなかったために、スーパーファミコン以降は『PlayStation にボロ負け』 というのが通説である。 しかし、次世代ゲーム機の戦いの中で Wii での『一人勝ち』には、 PlayStation での敗北への反省が活かされている様子。
逆に PlayStation3 でハイパフォーマンスの Cell プロセッサで打ち出した Sony に勝つために、 普通のプロセッサメーカーでは考え付かない 「プロセッサアーキテクチャのロードマップに乗らない」 という発想で、立ち向かっている様子。
Linux のオープンソースの考え方に染まっている身からすれば、 Closed アーキテクチャの任天堂は好きになれなかったが、 DS , Wii による復活は、経営者の英断のたわものなのなんだなぁ…
# ということで、任天堂も好きになってきたし、 買いてぇ〜♪
意外な喜びの商品、意外な喜びの価格
いつも、大量に届いている SPAM の中に、誤判定のメールが無いか探すのだが、 最近は、笑わせてくれるネタも多い。
http://yahoo.jx005.com こんにちは、いつもおせわになります 私の店をご光臨賜わることを歓迎するhttp://yahoo.jx005.com/
サイトをアクセスすると、自動判定(日本語)だと、文字化けで読めず、 エンコーディングを自動判定(中国語)にすると、ひらがなを含めた文字が表示されるという、 変なサイトであるが、 「おまえ、本当に買い物して欲しいのか？」 と突っ込みたくなる。
プロコン１回目、皆さん真面目に取り組む。
パソコン甲子園の方式にならったプログラミングコンテスト形式の１回目を実施する。 前半の１・２回目用に準備した問題は 20 問 。 極めて基礎的な問題だとは思うけど、 不慣れな学生さんは、予想通り最初の問題で悩んでいる。 でも、プログラミングの最初は、時間をかけてでもきちんと自分の「力」で完成させた 「経験」こそが、実力に結び付くんだから、「悩んでも自力で…」と…
実施方式で説明していた 『相手の間違いをみつけたらポイント50%ぶんどれる…』 でのポイントの移動は少なかった。 また 加点』 という点については、１回目で簡単な問題に集中したため、 説明でポイントを取った学生はいなかった。
自分の直感的には、面倒な問題のポイントがあまり高くないので、 難易度が中ランクの10点を数多くこなす方が、得点をかせげるはず。
小テスト作成中
講義の理解度評価用に実施する小テストの問題を作っている。 傾向は例年通りの穴埋め＋記述問題。 穴埋めは専門用語が多いので沢山のキーワード群の中から選んでもらう。 んで、簡単にしないためにも関係の無いキーワードを作る作業に、一手間かけている。
例年、無関係キーワードには、ネットワーク技術の穴埋め欄に、 Star Treck の SF 3 文字言葉を探してきたりと、遊びぎみ。
学科内プログラミング甲子園
プログラミングの技術を伸ばすためにも、様々な問題を考える練習をして欲しいので、 パソコン甲子園のネタと同様に、学科内の「プログラミング甲子園」とした コンテスト方式で演習を進める予定。
学科内プログラミング甲子園実施要項
- 基本はパソコン甲子園の実施方式に準じ、 課題正解に応じて課題毎に与えられた完成ポイントの積算結果で優劣を判定。
- クラスを3分割し、3人の先生の指導で演習。
- 前半２回は、適当なグループ分けで実施
- 後半２回は、前半の成績に応じて３分割。(ただし成績意識が出ない様に適当に入れ換え)
- 前半80分は、課題を作成する時間とする。 途中で解説が必要であれば、書く先生毎で簡単な解説を交える。
- 後半20分は、隣り合う学生同士で、実行結果を検証する。
- 課題が完成し、動作検証が正しいと判断できたら、完成ポイントの 100% を加点。
- 相互チェックで、動作が間違ってると確認できたら、 完成ポイントの 50% を減点。
- 誤動作を確認した学生は、動作検証パターンをレポートに記載し、 減点分を自分に加算。
- 各演習の度に、
- 自分の獲得したポイントの一覧表。
- 動作確認したプログラムのリスト、
- 動作確認したパターン LI プログラムのアルゴリズム等の解説。
解説は、教員がチェックし解りやすい説明であれば完成ポイントの50%を加点
を提出する。
- 第1,2回の後、第3,4回の後には、
- 中間発表・最終結果発表を行う。
- 各教員が受け取ったレポートをみて、改良テクニックなどの解説を行ってもらう。
前説
コンテスト形式の実施を前に、方針を説明する。 ただし、プログラムを作るだけでなく、フローチャートも書きながら…というのも 大切だよ….というネタにもしたいので、 後半には、プログラミングの開発工程を話す。
Jig.jp 福野氏による特別講義
昨年度より実施している専攻科における企業実務者を交えた特別講義ということで、 Jig.jp の福野氏による特別講義を実施。 OS と現在の業務に関係した講演をたのんでいたので、OS の必要性のあたりから、 携帯の OS を交えた話題となった。
講演要旨(共通化して扱うための『層』を作ればアプリ開発の利便性に)
- OS は操作性・開発の共通化のために重要。
- 携帯電話では、機種毎の違いを携帯のOSが吸収してるけど、 携帯はメーカーで Symbian,Linux,BREW…と様々あって、共通化プラットフォームが必要。
- しかし Javaの仮想マシン Java VM があり、プログラム開発が共通化された。 アプリケーションの視点からすれば、Java VM は OS としてとらえることもできる。
- しかし、Java環境も OS 毎でプロファイルを扱う"Java拡張ライブラリ"が、 DoJa,MIDP,etc…と違いがあり、共通化するプラットフォームが必要。
- Jig.jp では、JigletVM という環境により、Java拡張ライブラリを共通化している。 この視点では、Jiglet の視点では、JigletVM 配下すべてが OS の様なもの。 これにより、プログラム開発が容易になっている。
- 一方最近では、ユーザは携帯やPCと様々な環境を利用する。 しかし、データを各環境毎に持つのは不便。 ネットワークで共通化して利用できることが重要。 最近は Web 上にデータを持つ事で、スケジューラ等の利便性は、上がっている。 利用者の視点では、ネットワークによりデータが共通化されれば、 ネットワーク配下すべてが『OS+ネットワーク』で共通化されているとみなすこともできる。
- この中で Google や Amazon では、Web データを扱う API が公開され、 これらの情報をアプリケーションで自由に扱える時代になりつつある。
- これからは、様々な Web データを扱う API を共通化して扱える『何か』 を開発すれば…..
現代GPフォーラム
福井高専での現代GPフォーラムへの取り組みとして実施している内容の発表を行われた。 講演者として電子情報の卒業生の福野氏(jig.jp)による起業についての講演がありました。 また、jigさんと協力して行っている、インターンシップや同好会活動での発表として、5年,4年,専攻科の電子情報の学生さんも発表がありました。