高見知英のかいはつにっし(β)

高見知英のアプリケーション開発日誌 のほか、地域活動などの活動報告ブログ。

プログラマはどうやってスキルアップしていけばいいのか(.NETラボ勉強会に参加しました) #dotnetlab

今日11月30日は、ちょっと久しぶりに.NETラボ勉強会に参加してきました。

f:id:TakamiChie:20191130132706j:plain

とてもひさしぶりだったので、LT発表もしてきました。

資料は以下です。動画についてはしばらくお待ちください。

speakerdeck.com

で、今回ブログに書いたのは参加レポートというより、聞いていて思ったことがあったので。

今のプログラマに必要とされていること

今回スピーチではASP.NETBOT Framework、Power Automateなど、Microsoftの最近のテクノロジーに関するスピーチが豊富にあったのですが、最近のMicrosoft関連技術って、どれもプログラミングだけでなく、データの正規化やMVCの使い分けなど、結構高いスキルが必要になるなあ という感じ。

たしかにコーディングが少なくなったり、制作が楽になったのはあるのですが、そのぶんプログラミング以外のスキルをかなり要求されているような。

もちろん他の環境を使っても複数言語に対する知識や複数モジュールの知識が必要になることは多いし、なにを今更な感じはありますが、なんというか、「プログラミング(というより、プログラマがやること)ってほんと複雑になったなあ」という感じがします。

制限された環境でどう動くか

とくにPower Automateなどは、わたしも最近ちょくちょく使っているのであらためて感じますが、本当に難しい。

プログラミングをするだけならそれほどでもないんですが、Sharepointリストを使ったフローを書いたりすると本当に難しく、プログラミングスキルだけでは太刀打ちができないなあ という感じがします。

プログラミングは確かに、最近需要も増えて、講習会や教室も増えてきたという感じがありますが、じゃあこういったデータの正規化や、Power Automateみたいな制限された環境での立ち回りはどうやって勉強するのだろう?と、話を聞いていて思いました。

Power Automateは、他と違ってコーディングができないので、他の言語ならコーディングやSQLのパワーで押し切れるところが押し切れない。その環境でもやりたいことが実現できるプログラミング力というのは、なかなか高度だと思います。

そういう感覚を、どうやって教えるか

そして、わたしも一応SBCamp.などで講座をやる身として、こういう感覚をどうやって教えるのか というのが課題だなと思いました。

プログラミングそのものを教えることはまあなんとかできるし、コーディングについての心構えを教えることも、一応できる。

ただ、どうやってプログラミングに最適なデータ配置を行うか、どうやってモジュールをきれいに分割するか などといったものは、どうやって教えればいいのだろう?

わたし自身がそんなにうまくない というところもありますが、サンプルが用意しづらい というところもあり、どうすればいいのかが今後の課題だと思いました。

ITの格差と、プログラマの格差

そして話を聞いていて思ったのは、ITリテラシーの有無による格差(いわゆるデジタルデバイド)もあるものの、プログラマの技術力格差もあるような気がします。

こういう場でスピーチができたり、最新技術を追っていけるようなハイスキルのプログラマは、もちろんいます。

ただし逆に、こういった技術をうまく飲み込めず、プログラマとしてのスタートラインにすら立てないプログラマも、たくさんいる。

そういう人同士の格差も一つの課題なのではないだろうか と思いました。

発表することが一番の勉強!とはいうけれど・・・

こういう勉強会ではよく「発表することが一番の勉強」とはいいます。

自分の考えを整理できるし、曖昧だった知識をはっきりとしたものにできるし、わたしもそのとおりだとは思うのですが、発表できるところまで知識を身につけるのも、そうかんたんな話じゃない。

「じゃあわからないことを言語化すればいいじゃない」とも言いますが、本当になにもわからないと言語化すらできないのです。

そういう人は、一体結局どこにいけばいいんだろう そういう人たちをステップアップさせるために、わたしたちはなにをすればいいんだろう と、今回のスピーチを聞いていて思いました。

今プログラミングをはじめるなら、Windowsがいいかもしれない

最近思った話し。

プログラミングには、事前に整えておかなければいけないものがあります。

コンパイル言語であったらコンパイラやその動作のための環境、インタプリタ言語ならインタプリタ。そしてコードエディタ。

最近では高度な処理をライブラリに任せることも多くなったため、必要に応じてライブラリも揃えなければいけません。それらの環境を整えるのってだいぶ面倒くさい。

ただ、それらの設定を行っているうちに、最近表題のようなことを考えるようになってきています。

なぜそう思ったか

たとえばPython

WindowsにはPythonの実行環境こそ入ってはいませんが、公式サイトから簡単にインストールすることができますし、最近ではWindowsストアでの配布もはじまっています。

www.microsoft.com

そして、CGライブラリであるOpenCVPythonで使うためのモジュール、OpenCV-Python

news.mynavi.jp

こちらも、見た限り一行だけでインストールが終わるのは、Windowsだけ。

最近、インストールの準備に関するコードを見ると、Windowsが一番シンプル というケースをぼちぼち見るようになってきたように思います。

Windowsではすぐにプログラミングはできないけれど・・・

Windowsには最初から使えるプログラミング環境が、バッチファイルとWindows Scripting Hostくらいしかありません。

最近になってPowerShellC#VB.NETが追加されましたが、それくらい*1

結局、ちゃんとプログラミングができて、実行ファイルまで作れるような環境はそんなに存在しません。

ただ、逆に、最初は余計なものが入っていないので、環境を構築しようとしたら比較的すんなり構築できる。

たとえばMacの場合だと、最初から入っているPython2を削除する というところからはじめないといけないときもあり、面倒くさい*2

そのへん、元からなにも入っていないからこそ、逆にシンプルに片がつくというのが、Windowsだな ということを最近感じています。

それでもインストールが難しいものはあるけど

それでもインストールが面倒くさいといわれているツールはいっぱいあります。自分が最近使ったツールの中では、Pandocとか、Dockerとか。

pandoc.org

www.docker.com

ただ、これについて、Windowsには最近、Chocolateyというツールもあります。

chocolatey.org

これはざっくりいうとWindows版のapt-getのようなもので、管理者コンソールでchoco install ***というコマンドを叩けば、それだけで簡単にアプリをインストールできる。

この中には、PandocやDockerなどのツールも含まれているため、インストールはとても簡単。

PandocでPDFを生成するために必要なLaTeXはChocolateyからはインストールできませんが、Chocolateyからインストールできるwkhtmltopdfというツールを使えば、PDFを生成することも可能。

さらに、ChocolateyGUIを入れればインストールしたアプリの一覧を生成することも。

これを使うことで、新しい環境へのソフトウェア自動インストールも可能になります*3

プログラミング「以外の」情報の豊富さ

そして、プログラミング以外の情報が豊富であるということもあります。

Macは実際、プログラミングには向いているのかもしれませんが、ユーザーが少ないぶん、どうしても一般的な利用に関する情報が不足しがち。最低限情報を自分で判断して処理するスキルが必要になります。

とくにMacはあくまでUNIXベースですから、本来Macが得意な(デザイン分野などの)範囲を少しでも抜けると、剥き出しのUNIXが待っています。上級者にとってはそれはいいことなのかもしれませんが、初心者にとってそれはとても難しいことだと思います。

プログラミング以外のことに変に煩わされないこと。それは現状、Windowsが最も煩わされにくいのではないかなと。

今はDockerやWSL(Windows Subsystem for Linux)もあるし

それに今は、DockerやWindows Subsystem for Linuxにより、容易にLinuxなどの開発向け環境を構築することも可能です。もし、どうしてもそれらの環境が必要になったら、Windowsならあとでいくらでも追加できる。

案外Windowsにあると昔言われていた、「プログラミングをしづらい要素」は無くなっていたりする。

だからこそ今はWindowsなのかなあ と、最近思います。

*1:そもそも開発環境と言えるようなものがないため、C#VB.NETでまともにプログラミングするのは、けっこうキツい

*2:自分が持っているPCの話しならそれでも良いんですが、他の人が持ってるPCの環境構築となると、けっこう面倒くさかったりします

*3:これにより、我が家ではPCを初期化後、実作業時間1時間(夜間運転時間を除く)程度でPCを再セットアップすることが可能です

プログラミングLT 2019で喋ってきました #プログラミングLT

4月30日(火)は、茅場町のFinGATE KAYABAで開催された、プログラミングLT 2019というイベントに参加してきました。

f:id:TakamiChie:20190430101001j:plain
プログラミングLT OPスライド

なんだか割と久しぶりのこの手のITイベント参加です。

このイベントは、元々学生LTという名前の学生主体のLTイベントで、学生以外にも参加しやすくするために今回の名前に改名した とのこと。

司会の参加者・スピーカーのフォローがとても上手く、同様のイベントと比べとても楽しい雰囲気で進みました。司会の方もさすが慣れているな と感じます。

動画についてもすごく慣れているな という印象。裏を見たら専用のハードウェアを作っているようで、やりたいことが見えている学生の力 のようなものを感じます。

www.youtube.com

次回は夏を予定している ということ。わたしも時期が合えば参加したいですね。

f:id:TakamiChie:20190430153036j:plain
次回予告

スピーチ内容

当日のスピーチ内容は、プログラミングが関わっていればなんでもOKということで、アルゴリズムについての話題や、すでにあるプロダクトについての解説、自作ハードウェアとプログラミングの連携についての話など、色々なものがありました。わたしとしても聞いていて楽しかったです。

続きを読む

プログラミングに必要な「言語」は

最近、渋谷のTECH PLAYで毎月行われている、シニアプログラミングもくもく会にちょくちょく出ています。

シニア中心ということではありますが割と若い人も来ていたりしますが、どちらかというとプロのプログラマ というよりホビープログラマ・これからプログラミングをはじめよう という人が多く、わたしでも気後れすることなく参加できる場です。

techplay.jp

ほかのIT勉強会と違ってわたしも背伸びすることなく話ができる場で、なんというかふらっとステーション・とつかで技術的な物事にとても興味がある人と話しているような気分。

場所が場所なのと時間が時間なので、懇親会終わって帰るとなると終バスがあるかないかという場所ですが、それでも月一こういう場所に行けるというのはとてもいい気分転換になります。

プログラミングを学ぶ際にまず身につけるべき「言語」は何か

さて、4月のプログラミングもくもく会で話題に上がったものとして、「プログラミングを学ぶ際にまず身につけるべき「言語」は何か」というものがありました。

これについては時々他所でも話題になるのですが、ブログに書く機会はなかったのでいちおうまとめとして。

さて、プログラミングに最も必要な言語は。こう聞かれたとき、わたしは「母国語(日本語)」と答えています。

なぜかというと。

  • プログラミングの手順について考えるとき、大抵の人は母国語でまず考えるから。
  • 母国語の語彙が貧弱だと、検索ができないから。
  • ネットや現実の近しい人に意見を伝えるとき、たいていの場合それには母国語を使うから。

仮に、英語が堪能で日本語より英語で思考する、周りの人も英語圏の人が多い というのなら、もちろんそれでもいいのですが、そうでないのならたいていの場合、まずは日本語から覚えておくべきなのではないかな と、思います。

続きを読む

CoderDojo 中野 成果報告会に参加してきました

3月27日(水)は、東京都中野の中野サンプラザで開催された、プログラミングができるようになった未来の話(CoderDojo 中野 成果報告会)に参加してきました。

f:id:TakamiChie:20190327100257j:plain

このイベントは副題の通り、CoderDojo中野の成果発表会。いつもCoderDojo中野で活動している小学校中学年~中学生による、成果発表会でした。

CoderDojo中野のみなさんは、Scratchをやっていたお子さんが多く、今回の成果発表はScratchの作品が主でした。

続きを読む

Hatena Engineer Seminar 11 @ Tokyoに参加してきました #hatenatech

昨日1月23日(水)は青山のはてな東京オフィスで開催された、Hatena Engineer Seminar #11に行ってきました。

hatena.connpass.com

はてなのサービスはこのブログ含めて使ってますし、技術的な取り組みについてもよく記事を読んでいましたが、実際オフィスに行くのは初めてでした。木目調の入り口や芝生のある会議室などきれいなところでした。

f:id:TakamiChie:20190123190913j:plain

f:id:TakamiChie:20190123201645j:plain

詳細については上記connpassサイト等を見ていただくとして、とても濃い技術の話が主でした。昨年12月14日(金)に参加したfreee Tech Nightが技術面の話メインだったのに対し、こちらはどちらかというと、(システムの移行やデータ解析手法など)技術の運用面の話。

まちづくりエージェント SIDE BEACH CITY.はじめ地域関係で活動していて、このような実運用環境での技術の話を伺う機会は全くといっていいほどないので、とても聞いていて楽しかったです。

まあ、技術力不足もあり内容は半分も理解できませんでしたが(特に、freee Tech Nightのようなソフトウェア・フレームワーク周りの話だけならともかく、運用となると、わたしの体験では全く想像できない分野が多かったもので)。

ただ、このような濃密な話を聞ける というのはそれだけでも刺激的で、よかったなあ と。たまにはやはりこのような技術100%なスピーチイベントも聞かないといけないな と思いました。

実際この技術を運用できる機会があれば、もっと実感がわいてくるのでしょうが。やはり手近なところではWebサービスの開発しかないか(まあ、ネタがないわけではないのですが)。

続きを読む

UWSC風動作モジュールを作ってみました

ふらっとステーション・とつかの作業など、いままで簡単なプログラム処理にはUWSCを使ってきていました。

それは、主に途中で簡単なGUI処理(コンボボックスで項目を選択させるとか)が必要だったときのためだったのですが、去年書いたとおり、UWSCは割と前から公式サイトにアクセスできず、未だ今後がどうなるのか全く不明な状態です。

blog.onpu-tamago.net

さて、そんなこんなでずっとこの状態を黙って見ているわけにもいかないので、いままでUWSCでやってきたことを徐々にPythonで実現できないか と、現在UWSC互換モジュールをいろいろ検討中。

github.com

UWStyleというモジュールです。海外からのプルリクエストも受け付けたいな ということで一応英語ベースで進行中。大して変わらないような気がしなくもないですが(どちらにしてもプルリクエストは来ない という意味で)。

いちおう、以下のようなダイアログを簡単なコードで表示可能です。UWSCのSLCTBOXにあるダイアログのタイムアウト(指定した秒数が経過すると、処理をキャンセルとして閉じる)も一応実装済み。

f:id:TakamiChie:20190116044404p:plain

そのほかExcelやブラウザ(現在Chromeのみ)の操作にも対応しています。必要に応じてメソッドやモジュールは増やしていく予定。

続きを読む