フォト
無料ブログはココログ

MyList

プログラミング

2022年5月29日 (日)

AWSでサービス構築

日々AWSのジャングルを探検している。

週2日勤務している職場で、AWSでサービスを立ち上げようとしているのだけど、週3日は別の職場で「ほぼ1人情シス」をやっているし、知見はLAMPあたりで止まっているから、クラウドやフレームワークからお勉強しなければならないので、なかなか捗らない。

立ち上げようとしているシステムは昔だったら外注するくらいの規模だと思う。
昔システムを外注するときには、電気工事屋さん、サーバー屋さん、ソフトやさん、元請の営業さんと打ち合わせが必要だったけど、今時は内製できるようになったから、ほぼ、自分の席で完結している。
“ほぼ”なのは、テレワークできないから。

自席で完結しているとはいえ、昔、サーバー構築した経験は無駄ではない。
思うような動作をしない時の原因の特定手法や手段は同じだ。
さらに、GUIが無くても困らないことが、結構重要ではないかと思う。

GUIといえば、今でもUIは苦手だ。
プログラミングを勉強し始めた時にはGUIはなかった。
そして、簡単にGUI作れるようになったが、自分が作ったGUIを見るとイマイチだ。
はっきり言って、ダサい。

WebアプリもPHPでゴリゴリ書いていたけど、UIは自分でもダサいと思っていた。
イケてるサイトのUIをパックって参考にするのだが、ダサさが滲み出てくるのだ。orz
センスがないのだと諦めている。

フレームワークを使うと、UIとロジック、MVCパターンのViewと Model、Controlが分離できる。
開発要員が足りなくて1人で書くことになるから関係なかったりするのだけれど、分離できればあとからセンスがある人に書き直してもらうことがでる。

UIデザインができて、コードも書ける人は貴重なんだろうな。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2022年1月 6日 (木)

Excelの配列式

Excelの関数は配列(範囲)を入力できたり、出力できることを最近(と言っても1年前)知った。

入力はサポートが終わったExcel2010でも対応していた。

例えば、品名、単価、数量、で合計を求める集計表は品名ごとに金額を求めて、SUM関数で合計を求める。
↓こんな感じ

Sum1

SUM関数に配列式を使うと、

Sum2

商品ごとの金額を求めなくても、SUM関数1つで合計を求めることができる。
でも、これだけでは、あまり有り難みがないかもしれない。

Excel for Microsoft365や Excel2021では、配列を出力できるFILTER関数が使える。

表から列を条件で検索して、該当する行を抽出したいことは結構ある。
FILTER関数を使わなくてもできるけど、作業用の列が必要で、かなり面倒だから、FILTER関数だけで実現できるとありがたい。

↓は生徒を科目ごとに5段階評価した一覧表から、最も良い評価の生徒を抜き出すという例。
(5があれば5が最も良い評価だが、5がなければ4が最も良い評価になる)

Photo_20220105222202

セルG3に

=INDEX(FILTER($A3:$E22,RANK(B3:B22,B$3:B$22)<=$H$1),,1)

を入力して、H3からJ3にコピーすると作業用の列やシートがなくても抽出することができる。
ところが、この式を一発で入力することは難しい。
実際にこの式を入力するために、作業用の表を作った。(^^;

仕事でユーザが更新した一覧表を基にメールの設定を行うという作業がある。
行(レコード)が挿入、削除されたり、項目が変更されるのだが、一覧表が大きくなると、変更部分がわからないくなる。
これまで目視で変更部分をチェックしていたらしい。
はっきり言って、目視のチェックは人間の仕事ではない!!

ということで、FILTER関数とVLOOKUP関数を組み合わせて変更部分を抽出するシートを作った。
30分でできると思ったら、1日近くかかってしまった。orz
プログラムが書けるならVBAやPowerShellで処理するほうが楽だと思った。

ここから本題

FILTER関数はマクロやスクリプトと比べてわかり易いわけではない。
説明なしに上のようなシートを受け取ったら、マクロやスクリプトと同じように「ナンノコッチャ」である。

FILTER関数に限らず、受け取った人が理解できないなら、ブラックボックス化するしかないのだが、Excelなら誰かがメンテナンスできると誤解している人は多い。

後々メンテナンスできなくなるからと、スクリプトやRPAを使うことをためらう人がいたりする。
Excelは個人作業は効率化できるけれど、業務フローを変えることは難しい。

ExcelかRPAかではなく、業務フローを変えるために必要なことは何かを考えることが必要だ。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2021年11月 7日 (日)

ローコード・プログラミング

 最近「DX」「内製化」「ローコード」がIT業界で流行っていて、日経コンピュータでANAの内製化が紹介されていた。

 ITC業界で長く働いてきて、今は小さな事業所で「ほぼ1人情シス」をやっている。「ほぼ1人情シス」の立場で「内製化」を考えてみた。
「ほぼ1人情シス」は通常業務があるので大掛かりなシステムは作れない、手間や時間がかかる業務フローを効率化するくらいだ。

 今流行りのノーコード、ローコードプログラミングで簡単にシステムが作れるという、売り文句は 1/4くらい正しい。ツールを売る立場ならそう言うだろう。
用意されたテンプレートで間に合うかちょっと手を入れるくらいなら、Excelでデータベース関数が使えるくらいのスキルがあれば作れると思う。

 ところが、現実の業務がテンプレートにハマることは稀だ。業務をテンプレートに合わせなくてはならなくなる。

 例えば、PowerAutomateのテンプレートに休暇承認フローがある。
申請者がSharePointのリストにタイトル、取得日を入力すると、マネージャ(承認者)にメールとTeamsで通知され、メッセージ中の承認/却下ボタンを押すと、リストに、承認/却下が入力されるというもの。このフローは簡単で初心者でも作れるようにマイクロソフトが考えている。説明もあるので試してみるにはちょうどよい。

しかし、作れることと運用できることは違う。
現在、休暇承認を違うフローで運用している場合、変えられるかどうかが内製化の効果が現れるかどうかの分かれ目だ。

 さらに、テンプレートの構造まで手を入れてようとすると、プログラミングのスキルが必要になる。
たまたま、プログラミングのスキルを持った人、例えば、Excelマクロが書ける人がいる場合は、テンプレートを参考に独自にシステムが作れるだろう。

しかし、慎重に考えなければならない。
解決すべき問題と解決方法を考えないで、思いつきで初めたり、「ちょっとやってよ」のような要求を引き受けると、時間と労力をかけたけど使われないシステムが出来上がる。

外注しても解決したい問題を解決できるシステムが、内製できるなら価値がある。しかし、問題が解決できないなら内製しても価値はない。

ノーコード、ローコードで内製しようとしたときに、
標準の機能で実現できない場合、現状の作業の効率化になっていないか、考えたほうがよい。
紙+ハンコでもクラウド+RPAでも、その仕事がやらなくてよいなら、無駄だということだ。
やらなくて良い仕事を効率化しても意味はないのだ。

 さらに^2、
標準の機能だけで実現できず、拡張機能を使わなければならない場合は、「1人情シス」では難しいと思う。「1人情シス」に求められているのは内製化ではなく、解決すべき問題をを外注先に伝えられることだろう。

###

 PowerAutomate/PowerAppsのカスタムコネクタやOffice scriptを使うとできることが広がるのだけど、全然ローコードではない。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2021年4月12日 (月)

すきなプログラミング言語ランキング

2021/4のTIOBEランキングが発表された。

Cが首位に返り咲いたとか、Java3位に転落し、代わりにPythonが2位に躍進したようだ。
誰も触れないのだが、注目したのは、22位のScratchだ、もう少しで20位圏内に入るんじゃないだろうか。
そのうち、業務用のプログラムもScratchでないと書けないという新人が現れるかも。

scratchはMITが教育向けに作った visual型の言語で、小中学校で多く使われている。

タイピング・スキルが低いときにテキスト型言語でプログラミングを始めると、ソースコードの入力に時間がかかったり、タイプミスが多くなる。
タイプミスは文法誤りになり、コンパイル時、実行時にエラーになるので、アルゴリズムやプログラムの論理構造を考える前に、文法誤りを直さなければならない。初心者はまず、この壁を乗り越えなくてはならない。
最近の処理系は親切なのでエラーやウォーニングをたくさん出力してくれるけど、閉じかっこを1つ忘れただけでいくつもエラーが出てきたら心が折れてしまう。

visual型の言語はキーワードや構造をブロックにすることで、キーボードを使用せずマウスで操作できるようにしてあるので、文法誤りは発生しない。
子供の教育用に使われる言語は命令ブロックを使用したvisual型の言語か、ブロックエディタを使った環境が用意されているようだ。

昔マイコン少年だったオヤジたちは、Syntax Errorと戦って言語をマスターした。だからといって、今の子供達にそれを求めるべきではないと思う。昔は、テキスト型言語しかなかっただけのことだ。

昔のマイコン少年たちは、当時のオヤジたちに、昔は手書きでコーディングして、パンチカードで入力したものだ。エディタを使うからデバッグができないんだ。などと勘違いの指摘を受けたものだ。

昔のコンピュータはコンパイルに時間がかかったし、共用していたから、コンパイルの回数を減らすために文法誤りは事前にチェックしておかなければならなかった。
教育用に使うには不便なので、実行しながらエラーやバグを修正しながらプログラミングできるインタプリタのBASICが使われた。

昔のマイコン少年は今でも子供達にBASICを教えるたがるのだけれど、もし、昔にJavaScriptや PythonがあったらそれでもBASICを選んだのだろうか?

ここに「IchigoJam」と「SmileBASIC」と「MIT Scratch」の比較がある。辛辣な意見だけど結構当たってる。

昔はBASICで業務に使うプログラムを作ることは考えられなかったが、言語が拡張され、CPUパワーが高くなったら、BASICで業務用のプログラムが作られるようになった。
ひょっとすると、Scratchで業務用のプログラムを書くようになるかもしれない。

Scratchで8Queen問題を解くプログラムを書いてみた。 
緑の旗を押すと始まる。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2020年11月15日 (日)

テキストプログラミング <大人の先入観で決めてはならない>

「テキストプログラミングは小学生には難しいは大人の思い込み」松田孝氏 ReseMom.biz (2020/10/29)

★重要なことは、大人の先入観で決めてはならないということ。誰にとっても、ビジュアルプログラミングよりテキストプログラミングが良いわけではない。

松田孝氏は、

 大人は、テキストプログラミングは小学生には難しいと考えがちだ。しかし、松田氏はこれは大人の思い込みだという。松田氏の経験から、子どもたちは「テキストプログラミングはかっこいい」といい、ビジュアルとテキストを選ばせると「テキストをやりたい」という子どもが多いのだという。「子どもたちは、実はゲームを通してキーボード操作に慣れている。文字の入力に慣れていないのは、トレーニングしていないから。最初はキーボード入力できなくても、子ども同士の学び合いで身に付けていくのです。もうひとつ、3年生からはローマ字を習い、英語活動が始まります」と説明し、「そういう意味からも、テキストプログラミングはこれからの時代にマッチしていると思います」とする。

とおっしゃる。そのとおりだと思う。昔のマイコン少年はテキストプログラミングしか選択肢がなかったが、ちゃんとプログラミングしていた。

 Scratchなどビジュアルプログラミング言語でプログラムを書くときに、ちょっと凝った構造にすると構造がわかりにくくなる。

 例えば、↓はネコが矢印キーで動く方向を変えるプログラムだ。がデフォルトの大きさの場合は下が切れるのでスクロールしなければ全体が見えない。

Blockeditor1

全体が見えるまで縮小する機能(マイナスの虫眼鏡)はある。しかし、当然小さくなる。

Blockeditor2

これより複雑な構造をプログラムを書いているのを見ると感心する。「うまく動かないんです」と相談を受けたときに、肩越しに画面を見ただけで構造を理解するのは大変だったりする。

 Scratchで書いた立派なゲームが公開されているが、コードを見るとすごく不雑で構造が分かりにくい。自分がこの量のコードを書くなら、とてもブロックエディタでは書く気になれない。

 昔のエディタは25行とか40行だった。関数や手続きなど一まとまりの処理は1画面に収まるように書けと言われていた。条件分岐や繰返しなどの構造が画面跨ぎになってスクロールしなければ処理の全体が見えないコードは格段にバグが増える。

 そう考えると、ビジュアルプログラミングでブロックエディタを使う場合は簡単なサンプルくらいのシンプルなプログラムを書くくらいがちょうど良くて、プログラミングに興味を持った人には、テキストプログラミングを教えた方が良いと思う。

★重要なのは、ビジュアルプログラミングよりテキストプログラミングが良いわけではないということ。

 人それぞれに向いたプログラミング環境があるのだ。さらに、プログラミングより、絵と絵を動かすことに興味がある子には、複雑なコードを書いていてもScratchが良いのだ。 大人の先入観で決めてはならないのだと思う。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2020年10月27日 (火)

Scratchの疑問

 Scratchのサンプルをみていると、疑問に感じることがある。

疑問1:「ずっと」ブロック

 とりあえず「ずっと」ブロックを使ってその中で処理を行っているサンプルをよく見かける。疑問は、なぜ、ずっとブロックの中で終わるのか? である。
例えば↓のようなサンプルだ。

Forever

このプログラムの意図は「スプライトが端に触れたら止まる」であろう。そうであれば、繰り返し処理は「ずっと」ではなく「<>まで繰り返す」が適当だろう。

While

そういえば、「ずっと」繰り返すの意味や、「ずっと」と「<>まで繰り返す」の違いを説明しない。

Forevervsuntil

「ずっと」ブロックの意味を説明しないから、学習者がサンプルを改造するときに、よく間違う。学習者に子供が多いからといってもちゃんと説明すべきだと思う。

 NHK for Schoolの「Whyプログラミング」では、スクラッチを始めよう。(04:54あたり)で「ずっと」ブロックを説明している。

疑問2:イベントドリブン

 Scratchはイベントドリブンで書けるようになっている。
ところが、↓のようなサンプルを見かける。

Forever2

「ずっと」ブロックの中で押されている↑↓→キーで条件分岐している例だ。
どうしても条件分岐を使いたいなら、わからなくもないが、キー押下はイベントが用意されているので↓のように書くとスッキリする。

Evantdriven


Scratchの「全てを止める」ブロックは、イベントの発生まで止めないので、↑の例では、スプライトが端に触れると移動は止まるが、↑↓→キーで向きは変わる。ちょっとハマってしまった。


最近の投稿
最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2020年10月14日 (水)

ルビィのぼうけん

ルビィのぼうけん リンダ・リウカス作 鳥居雪訳

Photo_20201010213401

 この絵本は、新しいことを覚えるのが好きな女の子、ルビィ(Ruby)、変わり者と呼ばれているペンギンたち、孤独が好きな雪豹(Snow Reopard)、ときどきオジャマ虫を育てている狐、カップケーキを作っているロボット、ニシキヘビがペットのジャンゴが登場する。

 IT業界にいる人は思わずニヤリとしてしまう。 そうそう、仕事で旅行にでかけているルビィのお父さんの写真は、まつもとさんに似ている。 もし、主人公がパールちゃんだったら、おばさんだから、物語が変わってしまう。

 この絵本は、リンダ・リウカス氏は子どもたちが「プログラマー的思考」ができるようになるために書いたようだけど、文科省がはじめた「プログラミング教育」の「プログラミング的思考」で参考にされているようだ。

 この本の「プログラマー的思考」にある要素のうち、「プログラミング的思考」で扱いにくい要素があるようだ。
「データ構造」「抽象化」「関数(一般化)」「デバッグ」が扱いにくく、「シーケンス」「小さく分ける(分解)」「ループ(繰り返し)」「アルゴリズム」は扱いやすいようだ。

 大人向けの部分に書いてある、「れんしゅう1」から「れんしゅう22」までのすべての要素を継続的に教えると「プログラマー的思考」ができるようになるのだけど、一部それも単発では「プログラマー的思考」は無理だと思ってしまう。

閑話休題

 大人向けの解説に↓こんなのがある。

Algorisms

 最近モヤモヤしていたことだ。

 プログラミング教育でよく使われる、code.orgの古典的な迷路(angry birds)アルゴロジックはアルゴリズムを題材にしたものだ。 これらサイトでは正解すると少ないステップ数があることが示される。

 それはそれで良いのだけれど...少ないステップ数のアルゴリズムの方が良いアルゴリズムと教える人がいる。

2s

↑これより、↓これの方が良いのだと。

1s

「ルビィのぼうけん」の解説にあるように

異なったアル ゴリズムは、それぞれの用途によって使い分けるものです。

なのだ。

 一般的には、簡潔なアルゴリズムの方が最適であることは多い。しかし、プログラムを高速化するときに、ループを展開して順次処理にするのは常道だから、簡潔なアルゴリズムがいつも最適とは限らない。

 状況や場面によって最適のアルゴリズムは異なるから、状況や場面に合わせて選択しなければならない。 だから、複数のアルゴリズムを考えられる、頭の柔らかさ、発想の柔軟さがとても×2重要だ。

 教える人は、迷路の問題のアルゴリズムを教えるときに、「最小ステップが最適だ。」ではなく、「少ないステップにするにはどうしたらよいか?」という問いかけが必要なのだと思う。


最近の投稿
最近の投稿】【最近の書籍・雑誌】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2020年9月15日 (火)

micro:bit <BLEが乗った低価格マイコンボード>

ずいぶん前に買ったmicro:bitを出してきた。

Microbit_set

micro:bitは英BBCが作った教育用マイコンボードで、英国では2015年に11歳と12歳の小学生全員に無料で配布したらしい。

マイコンボードとしては、(https://tech.microbit.org/hardware/)

  • CPU:nRF51822 Cortex-M0 ROM:256kB RAM:16kB Clock:16MHz Bluetooth4.1内蔵
  • DAPLink:MKL26Z128VFM4 Cortex-M0+
  • IO:5x5LED, SWx2, SPI, I2C, GPIOx18(LED,SW,SPI,I2C排他使用)
  • Sensor: 3軸加速度センサー、地磁気センサー、温度センサー(on chip), 明るさセンサー(LED使用?)

マイコンボードとして見ると盛りだくさんで、¥2,000はお買い得かもしれない。


Microbit_rea


Microbit_front

プログラミング環境はOnlineで提供されている。(https://makecode.microbit.org/)
教育向けを謳っているだけあって、ブロック型ビジュアル・プログラミング環境が公開されている。
困らないくらいブロックは揃っているが、文字でプログラミングしたいと言う人向けにjavascriptでもプログラムが書ける。

micro:bitの最初のプログラムは、Lチカでなくハートマークを点滅させるらしい。

Microbitidem

これくらいなら、ブロックエディタで書けるけど、ちょっと大きくなるとブロックエディタでは見通しが悪くなる。

ダウンロードのリンクをクリックすると、HEXファイルがダウンロードされる。micro:bitにはDAPLinkが乗っているので、ダウンロードされたHEXファイルを"MICROBIT"という名前のドライブにコピーすることで、micro:bitに書きまれる。

左にシミュレータがあるので、micro:bitを書き換える前に動作を見ることができる。

ところで、このIDEはHEXファイルを読み込むと、プログラムを編集することができる。HEXファイルはバイナリデータなのになぜプログラムを復元することができるのか不思議だ。 HEXファイルの中にプログラムが書いてあるのかと思い覗いてみたが見当たらない。

調べてみると、micro:bitはMicroPythonで動いていて、IDEでダウンロードされるHEXファイルには、MicroPythonインタプリタのバイナリとMicroPythonのスクリプト(中間言語?)が入っているらしい。IDEはHEXファイルを読んでMicroPythonのスクリプト部分を読み出しているようだ。

関数も使えて、再帰呼び出しもできるようなので、5Queenをやってみた。深くなるとスタックが足りなくなるようだ。

blutooth LEがオンチップで乗っているので、micro:bitのセンサーの値をスマホやPCに送って処理させたり、スマホやPCからmicro:bitを制御したり、micro:bit同士でメッセージが送受信できる。


最近の投稿】【最近のCPUボード】【最近のプログラミング】【2017の投稿】【2016の投稿】【2015の投稿

2020年8月18日 (火)

なぜ大学生はプログラミングが上達しないのか <技術者としての観点>

なぜ大学生はプログラミングが上達しないのか Qiita (2020/08/11)

 現役大学生による、大学生がプログラミング上達しない理由について考察した投稿。

実際、私の友人を何人か思い浮かべてみてもほとんどの人が簡単な計算程度のプログラムしか書けないと思います。

しかし、ほとんどの学生がエンジニア志望なのです。

らしい。

まず、

 日本人は技術に携わる人を技術者と一括りにするけれど、欧米では、エンジニア、テクノロジスト、テクニシャンに区別しているそうだ。 エンジニア、テクノロジスト、テクニシャンで求められる知識と技能のレベルは異なる。

 どのレベルを想定しているのだろうか? ひょっとして、プログラミング・スキルではなく、プログラミング言語でのコーディング・スキルを習得しようとしているのではないだろうか。

 職業プログラマーの多くはテクニシャンだ。職業プログラマーになるならコーディング・スキルは必須だろう。そして、コーディング・スキルを習得するなら、専門学校のような技能習得を目的にした教育機関のほうが良い。20時間程度でコーディング・スキルを習得するのは極めて難しい。

プログラミングの目的

 プログラミングの目的はコンピュータを使って問題を解決することだ。そして、問題を解決する手法としてコーディングがある。

 プログラミング講義のゴールは、プログラミングで問題を解決できるようになることだろう。 だから、正解があってそれを教えてもらうものでもなく、記憶するものでもない。

 プログラミングで解決できる課題は、身の回りのそこら中にある。ICTの発展で、「こうだったらいいのにな~」という妄想(課題)も解決できることが多くなってきた。

上達しない原因

 筆者は、上達しない要因として、

  1. 講義時間が少ない
  2. アウトプットの時間が少ない
  3. テストは筆記試験が多い
  4. 大学は研究をする場所
  5. アルゴリズムの勉強が多い
  6. 日常に活かせる機会が少ない(地方学生)
  7. 課題に追われて自習の時間がない
  8. 学んでいる内容が何に活きるのかがわからない
  9. コードのレビューをしてくれる人が少ない
  10. 受け身の学生が多い

を挙げ、「10.受け身の学生が多い」ことが最大の要因と結論付けている。

 しかし、深刻かつ重大な問題は「8.学んでいる内容が何に活きるのかがわからない」と思っていることではないだろうか。

 学んでいる内容が何に活きるのかがわからないのは、生活の中に課題が見付けられないのかもしれない。 その姿勢は技術職として致命的だ。

 1週間寝ないで作業したら解決しそうな課題が見当たらないとか、その解決方法が人海戦術しか思いつかないなら、技術者は不要なのだ。

経験では

 今から40年前に20歳を過ぎてから独学でプログラミングを始めた。 プログラミング・スキルは、60年生きてきて、最も役立ったスキルだ。自転車に乗れることより役に立つかもしれない。プログラミング・スキルを習得したら、1週間寝ないで作業しなければできないような作業が1日できるようになる。

 プログラムの学習を始めた頃は無線関係の仕事をしていたのでITとは関係がなかった。当時、プログラミングで最初に解決した課題は、3次混変調積が発生する組み合わせの検索だった。周波数A,B,Cが2A-B=Cとなる関係にある場合に、AとBの周波数の受信レベルが大きくなると、受信機内部で周波数Cが発生するので、この3波の組み合わせは使わないようにしなければならない。 使用している周波数が多い場合はこの組み合わせを調べるために多くの計算が必要になる。

 つまり、計算自体は四則演算だが計算量が多い問題だ。候補がn個の場合、計算量は単純化すると nP(n-3)で、候補nの3乗くらいで増えるから、人力で計算できる候補は限られる。その結果、予想外の混信が発生するのである。

 このプログラムを作って夜通し回したら、作業量は1/10以下になって、10倍以上の候補まで検索できるようになった。

 プログラムは簡単な計算程度のプログラムである。そして、職業プログラマでなくても、プログラミングで問題が解決できるのである。

重要なことは、

 プログラミングで解決できる問題を見つけることだ。そのために、プログラミングを学ばなければならない。


最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿

2019年2月 8日 (金)

プログラミング教育

 60年足らずの人生だけど、最も獲得してよかったと思う能力はプログラミング能力だと思う。

 技術系の仕事ではプログラミング能力は必須だ。 しかし、職場の研修やOJTで、教育やトレーニングしようとするとなかなか難しい。

 職場でのプログラミング教育の問題は

  • プログラミング能力獲得の目的があいまい
    誰もが職業プログラマになるわけではないから、手段としてのプログラミングを教えるべき。
  • 講師がプログラミング能力獲得方法を形式知化していない
    プログラミング能力を持っていても、その能力の獲得方法を形式知化していない者は他人に教えられない。 

ことだと書いた。(プログラミングの講義(2019/02/01))

 この問題は、これから始まる小学校で始まるプログラミング教育でも言えることかもしれない。

 唐突だけど、

 プログラミングの技能を車の運転に例えるなら、多くの人は問題を解決するための手段として運転技能を獲得している。 問題解決とは、目的地に移動するためや荷物を運ぶためとか趣味としてのドライブとか。

 もちろん、バス・タクシーの運転手、トラックの運転手、F1ドライバーなどの職業ドライバーになろうとすると一定レベル以上の運転技能が必要なことは言うまでもない。 職業ドライバーには、安全に運転する、操縦しにくい車を運転する、速く運転する技能が求められる。

 それらと比べて、普通の人は最低限の運転技能があればことが足りるということ。

 普通の人にとって重要なのは、どこに行くのか、なぜ行くのかだ。 そして、車で移動することが合理的であれば運転する。 当然、徒歩や列車で移動することが合理的なら車は運転しない。

 プログラミングに置き換えると、必要のないコーディングはやらない。アプリケーションソフトで問題が解決できるならアプリケーションソフトを使う。 Excelのような汎用ソフトを使うことが合理的ならば汎用ソフトを使えばよい。

 重要なことは、

 どの問題をプログラムで解決するのかを分析すること。 解決手段(既製アプリ、アプリ作成)を考えること。 そして、プログラミングが必要であればアルゴリズムを考えることだ。

 注意しなければならないことは、

 趣味で車を運転する人がいるように、趣味でプログラミングしている人がいる。
プログラミングすること自体が目的の人だ。 このような人に、教えてもらうときには注意した方が良い。 プログラミングは手段ではなく目的だからなぜプログラミングが必要かは教えてくれない。

 さらに重要なことは

 それと、何か聞いてみて、ちゃんと言葉で説明できない人は、人に教えることができないと思って間違いない。 プログラミング言語は曖昧さを排除した言語だ。 母語で明確に説明できない人は抜けのないアルゴリズムを考えられないし、正確なコーディングができないと思って間違いない。


最近の投稿】【最近のプログラミング】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿