ホーム » 2022 (ページ 12)
年別アーカイブ: 2022
2021年度 卒業研究発表会
2021年度 電子情報工学科 卒業研究発表会が 3/2(水),3(木) と行われています。
コロナ対策で、リモートを交えながら実施しています。5年間に勉強してきたことをこの1年間の卒研で総仕上げとしての発表で、緊張している人もいますが皆さん頑張ってしてしています。
情報構造論2021全講義録
- 情報構造論2021ガイダンス
- 繰り返し処理と処理時間の見積もり
- 再帰呼び出しと再帰方程式
- 再帰処理時間の見積もりとポインタ操作
- ポインタとメモリの使用効率
- malloc()とfree()
- 様々なデータの覚え方のレポート課題
- 様々な2次元配列
- リスト構造と処理
- リスト処理
- リストへの追加処理
- スタックと待ち行列
- 集合とリスト処理
- 双方向リスト
- 2分探索木
- 深さ優先探索と幅優先探索
- 2分探索木の処理とデータ追加処理
- AVLと2分ヒープ
- 意思決定木と構文解析
- 演算子と2分木による式の表現
- B木とデータベース
- ハッシュ法(導入)
- ハッシュ衝突の対策
- プログラムの処理時間の測り方
- 文字列のハッシュ関数
- 共有のあるデータの取扱い
- ガベージコレクタ
- 動的メモリ管理 malloc() と free()
- 関数ポインタ
- 情報構造論とオブジェクト指向
自室UPSの交換
今年に入り、たびたび自室の UPS がピーピー鳴くようになってきた。バッテリーの日付を確認すると7年以上前だった。apcupsd などのツールで監視はしていて、バッテリー供給可能時間 30分 はあったので、さすがに古くても瞬間停電には耐えられるだろうと使っていた。最近は1日に数回アラームが鳴るし、apctest コマンドを使って バッテリーの日付を新しくしておいたけど、やっぱりアラームが鳴る。
年度末に向けて、交換用の 新しい UPS (APC ES 750 USB: 外観は違うけど中身は今まで使っていたのと同じ) を購入しておいたので、ようやく交換した。バッテリーも購入したので、古い UPS の中身と入れ替えて、別に使う予定。
Emotet チェックツール EmoCheck
Emotet は、メール添付の マクロ付き Word / Excel によって拡散するマルウェアで、感染者のメールの Reply などを装って送信されるため間違って開く可能性が高く、広範囲に被害がでている。
全国の高専の中でも発生が確認されており、注意が必要となっている。(私の手元には、2月4日現在では届いていないけど)
このため、「Emotet の感染確認のためのツール EmoCheck での確認せよ」とのお達しが出ている。
ぜひとも、EmoCheck で感染確認をしましょう。
セキュリティワークショップin鯖江
セキュリティワークショップ
新しく作ったCTF問題(簡単)
壊れかけたHDDから取り出したファイルを復元
知り合いのパソコンが壊れかかっていたようで、chkdsk.exe が動き出し、File0000.chk, File0001.chk といったファイルが作られた。そのファイルの1つが zip 圧縮で送られてきた。そのファイルの中から CTF のフラグ FLAG{xxxxx} といった情報を見つけてください。
この川の名前がフラグ
この写真に写っている川の名前を答えてください。ただし、流域全体で呼ばれている名前ではなく、この地区で呼ばれている名前が答えです。
この問題、File0000.chk をメールで送ったりすると、最近のメーラやブラウザは頭がいいので、答えがすぐに見えたりするので、zip 圧縮の設定にしたり、担当者の方に川のファイルを Facebook メッセンジャーで送ったら、Exif 情報が消されたりと、色々とデータのやり取りで手間取りました。
NoSQLと Google firestore
データベースシステムとして、最近は NoSQL (Not Only SQL) が注目されている。この中で、広く使われている物として、Google FireStore などが有名である。教科書以外の最近のデータベースの動向ということで、最後に NoSQL の説明を行う。
リレーショナルデータベースシステムの問題
リレーショナルデータベースのシステムでは、大量の問い合わせに対応する場合、データのマスターとなるプライマリサーバに、そのデータの複製を持つ複数のセカンダリサーバを接続させる方式がとられる。しかしながら、この方式ではセカンダリサーバへのデータ更新を速やかにプライマリサーバに反映させる、さらにその結果が他のセカンダリサーバに反映させる必要があることから、大量のデータに大量の問い合わせがあるようなシステムでは、これらのデータ同期の性能が求められる。しかも、プライマリサーバが故障した場合の復旧なども考えると、こういったプライマリ・セカンダリ・サーバ構成での運用・管理は大変である。
NoSQLの利点
NoSQLのデータベースでは、すべてのデータを複数のサーバ(別のデバイス,ネットワーク)に冗長化したうえで分散して保存する。この際に、どのサーバがプライマリサーバといった概念はない。もし1つのサーバが故障したとしても、分散して保存されたデータから元のデータを自動的に修復できるような構造となっている。
データの分散保存であれば、ハードディスクの RAID システムなども関連知識となるであろう。
- RAID0 – ストライピング(データを別デバイスに分散保存し、並行読み出しで高速化)
- RAID1 – ミラーリング(データを複数デバイスに同じものを書き込んで、データ故障耐性を実現)
- RAID5 – データを複数デバイスに分散保存する際に、データ誤り訂正のデータも分散保存し、高速化と故障耐性を実現
- RAID6 – データ誤り補正のデータを複数もたせて、分散保存
リレーショナルデータベースで大量のユーザからアクセスされる場合、データが安全に取り扱うことができたり、システムに障害が発生した時の対応や、システムのスケーラビリティ(利用状況に応じて処理するプロセッサなどを増やしたり減らしたりする機能)が重要となる。NoSQLのシステムでは、中心となるプライマリサーバを作るのではなく、データを複数のシステムに分散して保存し、障害が発生しても、分散したデータから自動的にデータを修復できるような構成とする。
NoSQLのシステムでは、データ格納形式から、キーバリューストア型、カラムストア型、ドキュメントデータベース、グラフデータベースに分類される。最も代表的なものは、保存するデータ(Value)に対し検索するためのキー(Key)だけの基本的なデータ検索だけを提供する キーバリューストア(Key-Value store)である。こういった構成ではSQLとは違い、複数のテーブルをまたがった検索などができない(サブコレクションなどを使えば代用可能)。
Google の Firestore
NoSQLのデータベースを構築したのは、Google が先駆けであった。現在、このGoogle の NoSQL のシステムは、Firestore として利用されている。(データベースはFireBase)
Firestore は、ドキュメントモデルデータベースの一種であり、すべてのデータはドキュメントとコレクションに保存される。ドキュメントは、データベースでのレコードに相当するが、属性名とそれに対応したデータの JSON オブジェクトである。コレクションは、キーにより対応するドキュメントを取り出せるデータ群である。ドキュメントの中に、サブコレクションを保存することもできる。