ベストを尽くせ！

明日がいよいよ情報の国家試験、
情報処理技術者の春季試験です。
生徒は試験に備えて
同じ時間帯で各々
過去問題や模擬問題に挑戦していました。
まず、午前の部は9時半から12時まで
そのあと１時間の休憩をはさみ
午後の部が13時から15時半まで
2時間半の2セットで計5時間の試験です。
私はほとんど口出ししませんので
自分たちで自主的に…。
素晴らしい！

２月から今日まで本当によく頑張りました。
私も、過去問題しこたま用意しました。
最後の教室には配り残した過去問題が勢ぞろい。

さて、次の試験に備えて
片付けるとするか…(-_-)

今回の試験から
情報セキュリティに関する出題が多くなり
長文を読解しなければならない午後問題では
アルゴリズム（疑似言語）と並んで
必須解答問題になりました。
昨今、情報セキュリティ分野は
大きな問題になっていますから
国家戦略として
情報セキュリティに関する
人材の育成が急務であるとの
認識なのでしょう。

さあ、後は体調を整えて
本番は時間にゆとりを持って行動！
ベストを尽くせ！！

アナログは死なない

部屋を整理していたら久しぶりに
まだ駆け出しのころの授業で作った
流れ図とＣＯＢＯＬの
コーディングシートが出てきました。

なつい！！

今から10年ほども前になります。
大学を卒業したばかりの私は商業科目など全く分からなく
社会人になって初めてプログラミングを体験しました。
（簿記は、大学のころ少し勉強してましたけど）
情報処理だけでなく様々な授業を見学させてもらいながら
自分の授業の教材研究に必死だったことを覚えています。
その頃、睡眠時間は４・５時間だったような…。
今思うと当時は若かったです（笑）

生徒と一緒にというより生徒に教わりながら
まずは、お題を解決するための流れずを書き書き。


そして、コーディングシートに
ひたすらプログラムを書いていきます。

ひと通り終わると、入力して試してみるのですが
一発で解決することはありません。
文法やスペルを間違っていたり、
時には、アルゴリズム自身を間違っていて
流れ図から書き直しなんてこともざらでした。

すでに汎用機ではなくパソコンで実行できる
ＣＯＢＯＬの実習環境だったので
いちいちコーディングシートに書く必要もなかったのですが
当時は、テンプレートなどを使って丁寧に記入していました。
大げさに言うとコンピュータに
魂打ち込んでるって感じがしてました。

最近では言語もＣＯＢＯＬから
ＶＢＡやＪａｖａに変わり、
実習環境や言語の特徴も変わっていますから
アルゴリズムや文法の学習もそこそこに
すぐに実習に移ってしまっています。
とりあえずコンピュータで実行してみる
というスタイルを取ると、
授業も手っ取り早く済み、
いろんな問題に取り組ませられますので、
飽きっぽい最近の生徒には
このスタイルがマッチしています。

しかし、当時の資料を見ていて

なんでもチャッチャと終わらすのではなく
プログラムコードを手書きするといった
アナログ的な作業をすることも重要なんじゃないか。
プログラム言語や技術の習得より
むしろじっくりと考える時間を
与えることこそが大切なんじゃないか。

と小難しいことを考えてしまいました。（笑）

情報の実習といえばデジタル要素満載ですが
新年度の授業ではアナログ的要素も
復活させていこうかと思っています。

アクセス解析

このブログ、最近になってアクセス数が増えています。
簿記検定やその用語を検索されているみたいで
このブログやWEBにたどり着かれています。
商業高校生の簿記検定に対する関心が高い上
次の日曜日は全商の簿記検定ですからね。

アクセスされた方には申し訳ないのですが
残念ながらこのブログは内容が薄っぺらいもので
あまり有益な情報は提供できそうにありません。
本当に申し訳ありません。

さて、アクセス解析について。
最近では、どんなサービスにも
どこからアクセスがあって
どのページを見られていたか
などの記録が様々な場面で利用されています。
もちろん、そのデータを
アクセス解析として詳細にみる仕組みもあります。

アクセス解析なんて難しそうで
分かんないと思っていても
知らないうちに
いろんなところに使われています。
私は、やったこと無いのですが
話題のツイッターやフェイスブックにも
アクセス解析の仕組みは利用されています
「足あと」とか「友だち」とか
アクセス元が分からなければ
実現できない機能ですからね。

以前、hpに記載していた
　「アクセス状況把握のため、
　アクセスされた方のIPアドレス、
　閲覧したページや利用環境などの情報を
　のブラウザから自動的に受け取り、
　サーバーに記録していますが…」
の文言に噛み付かれた事がありました。

当時は、アクセス解析が
一般ユーザに浸透していなかたことも
あったし、なんか仰々しい書き方でしたからね。
反省です。

でも、この仕組みは使い方を誤ると
個人を特定できる仕組みにもなり得ます。
アクセス解析について十分理解することが大切です。

もらった！

昨日から外部講師を招いた講習会がありました。
お題は「ＩＴパスポート講座」
生徒も教師も同じ教室で共に受講します。
専門学校の講師の先生の授業は
わかりやすくためになりますから、
授業にも役立ちます。

講座中は、他の生徒の対応と突発の業務で
中座すること数回。
講師の先生には大変失礼でご迷惑をおかけしましたが
いやな顔せず、いろいろ情報をいただきました。

さて、講習の中で「もらった！」っていう教え方が
いくつかあるのですが
今回は、これをご紹介。

ＭＴＢＦとＭＴＴＲ
コンピュータシステムの稼働状況を表す用語です。
この用語、
mean time between failures
mean time to repair
の略なのですが、よく情報の試験には出てきます。
訳すると平均故障間隔と平均修復時間です。
でも少しわかりにくい。

平均故障間隔は故障から故障の間だから
つまり、動いている時間

平均修復時間は修理中の時間だから
つまり、動いていない時間、故障中の時間

なんです。
なんで、こんな遠まわしな言い方なんでしょうか？
英語独特の言いまわしなんでしょうかね。

この用語とにかく覚えにくいんです。
そこで、
ＭＴＴＲの最後の２文字だけに注目し
覚えてしまえばいいんです。
ＴＲはtrouble（トラブル）の略だから
故障中の平均時間なんだと。

これはもらいました！
さっそく、３学期から使おうっと。

33回U-20プロコン

U-20プロコン最終審査が終わったようです。
審査結果がWebページで公開されていました。
http://www.johokagekkan.go.jp/u-20/index.html

受賞作品を見て、作品づくりの反省点も見えてきました。

どんなユーザを対象としているのか
開発作品がなんの役に立つか

ここがしっかりしないとだめだということです。
ドキュメントで補うには限界があります。
作品自体が何を目的としているのか明快にわかり、
有用性を感じさせるというのは
審査員の先生のコラムでも
指摘があった通りだと思いました。

部活動で作品制作をする目的は
授業や部活で学んだ知識
検定で得た技能などが
どう生かされているのかを体験し
グループで仕事を行う経験を通して
物事に取り組む姿勢を学ぶことです。

入選や受賞にこだわるわけではありませんが
出品する以上、それを目標にするわけですから
できるだけ良いサポートができればと思っています。

今はとりあえず10月21日の
情報処理技術者試験に向けて
作品制作はひとまず休み。
中間考査もありますから
しっかり勉強しなければなりません。
そうそう、私はテストを作らねば（汗）！！