▼ご挨拶
プログラミングにおいては、いきなりプログラムを書き始めるのではなく、事前に問題の分析を充分に行なうことが必要です。この点については、2020年からのプログラミング教育の導入について文部科学省が言っているこのと一つとして、「プログラミングでは試行錯誤ができる」という内容が問題となります。
プログラミング、とくにコーディングにおいて理想となるのは、書下したプログラムに一切のバグが存在しないことです。しかし、文部科学省の方針、指導要領においては、コーディングにおいての試行錯誤を教員、児童・生徒に求めていると読めます。コーディングにおいて試行錯誤をよしとする姿勢は、むしろこれまでの数十年にわたる、児童・生徒に対するプログラミング教育に関する研究の知見、および一般のプログラミング教育に関する研究の知見を無視し、またそれらのプログラミングの方法論と反するものです。
プログラミングにおいて試行錯誤が必要となるのは、プログラムを書く前の、問題の分析においてであると言えます。これは「マインド・ストーム」〔シーモア・パパート〕において「計画」として示されているとともに、UMLにおいても (UMLのすべての記述方法は使わないとしても)、その存在理由でもあります。
この、プログラムを書く前の問題の分析に重点を置いた環境や教材を提供するための環境の整備 (以下、「本企画」という) を、このプロジェクトがサクセスした際には実行していきたいと考えています。
▼本企画で実現したいこと
本企画においては、適切な課題の選択および提供と、課題を分析する環境、そしてプログラムを書きそれを実行する環境の実現のための試験的な各種サーバの構築およびネット環境の整備を目的とします。また同時に、それらの試験的な各種サーバを、少人数のサービス利用者を対象に実験的に公開を目指します。
本プロジェクトがサクセスした場合には、まずサーバなどの購入と、外部からの接続環境の整備を行ないます。本格的な各種サーバの構築は本プロジェクト・本企画の後となりますが、本プロジェクトのサクセスの後の本企画では、以下のようなものの構築を目指します:
1. 課題の選定およびサービス利用者への提示方法の検討 (サービスとは、本企画および本企画以後に提供する各種サーバによる以下の機能を指します。)
2. 同内容の、サービスとしての整理
3. 問題分析環境を提供する記述方法の検討、およびその記述を支援するサーバの設計と構築
4. 問題分析の記述に対しての、Prologなどをバックエンドとした検証システムのサーバの設計と作成 (この検証システムは万能であることは困難であるため、1.および2.のような課題の選定などが必要となります。)
5. 教材用プログラミング言語の選定と実行の確認、あるいは教材用プログラミング言語の設計と実装。 (既存のプログラミング言語を使用する場合、異なるパラダイムの複数の言語の実行系を導入したいと考えています。)
6. 教材用プログラミング言語の実行のためのサンド・ボックス環境を提供するサーバによる実習システムの設計と実装。 (教材用プログラミング言語の無制限の利用を認めた場合、サービスを提供しているサーバに対して悪意を持った操作を記述することも可能と考えられるため、サンド・ボックスとして各々隔離した実行環境を用意します。)
本プロジェクト・本企画の後となりますが別のプロジェクト・企画として、上記1.から6.の再検討および高機能化に加え、次のものを予定しています。
7. 少人数を対象とした実験的公開ののちに、クラウドなどを利用した一般公開
このようなシステムと似たものとしては、コードモンキー、Laby、Kturtleなどがありますが、それらは上記5.および6.におおむね対応するものであり、それらに対して問題の分析についての検討が本企画の大きな課題であり、また大きな特徴となります。
▼資金の使い道
350,000円: サーバ (比較的高性能なPC) の購入費。
250,000円: テスト用クライアント (複数OSを仮想システム上で動かせる程度のPC) の購入費。
200,000円: プリンタなどの購入費。
150,000円: RAIDなどバックアップメディアの購入費。
150,000円: 無停電電源装置の購入費。
100,000円: サーバ公開のための費用。
実際の金額は、上記金額からCampFireの諸手数料 (17%) を引いた、つまり0.83をかけた値になります。
▼最後に
ぜひ、ご支援をお願いいたします。
最新の活動報告
もっと見るコンピュータを使わない、コンピュータとプログラミング#9
2018/04/02 23:14こちらのページにて、「コンピュータを使わない、コンピュータとプログラミング入門#9」の予告と、予定している内容について簡単に紹介しました。 よろしければ、見ていただければと思います。 もっと見る
仕様記述
2018/03/21 17:40問題の分析には、現在ではUMLがあります。また、テキストでUMLの各種記述を行なう記法もあります。 では、テキストでのUMLを用いての仕様記述を考えているかと言うと、考えていません。 まず、文芸的プログラミングをベースに、特に「珠玉のプログラミング」における不変表明においてはVDMを参考にした記法が可能ではないかと考えています。 そのあたりはあり物を参考にできるのですが、問題はデータ構造です。UMLの場合、あくまで「オブジェクト」ですので、データ構造は書きやすいものとしてはレコードに制限されます。 対して、データ構造としては木、リスト、グラフ、スタックなどなどがあります。ここをうまく書ける方法はないか調べ、および検討しています。 木やリストの場合なら単純に a := [ a | a ] というような書き方ができます。 木とリストは区別したいところでもあるのですが、この時点ですでに悩んでいます。 書き方としては、a := [ h | a ] , h := a というような書き方もできないことはありません。 ただ、リストによって木を書けることも考えると、区別する必要があるのかという疑問もあります。 基本的なデータ構造は数が限られているので、a := tree と書いてしまうこともできないわけではないかと思いますが。 もっと見る
課題案、疑似コード、テキスト
2018/03/17 18:54現在用意してあるいくつかの文書の中から、さらにその一部を抜き出したものを以下に示します。 疑似コード(案) この疑似コード(案)のペラに記載されている関数定義では、for、whileに相当するloopの機能の実装はできません。それは、ペラの内容がフル仕様ではないためです。 この例に限れば、次のように定義するのがフル仕様の一部となります。 loop : func [ a `in b] : 中身 ;| func [ a ] : 中身 ; ここで、"func" は関数定義であることを示しますが、その引数の違いにより、とくに"`in" というクオートされたリテラルの存在により、上の方はforに相当し、その不在により下の方のwhileに相当するものとなります。 もっとも、untilに相当するのはいまいちうまく書けません。 loop : func [ a `in b] : 中身 ;| func [ a ] : 中身 ;| func [ `until a ] : 中身; とは書けますが、この場合 "loop until 条件" となり、untilっぽさが薄くなります。 また、";|" は、ブロックに対しての "or" であり、この場合、引数の違いにより、3つのいずれかが選択され実行されます。 課題案 一応現時点で用意してある課題案です。内容のすべてをテキストにしているわけではありませんが、整理中、検討中を含め、概ねノートに手書きでは書き出してあります。 テキストサンプル テキストのラフですが、おおまかなイメージとして、課題のすべてをこのようなテキストとしてまとめるつもりです。 このテキストサンプルは本プロジェクトのリターンには含まれませんが、今後のプロジェクトのリターンに含めたいと考えています。 もっと見る
コメント
もっと見る