sh3_2022_kw

SecHack365 2022年度川合ゼミの説明

(by K, 2022.04.13)

こちらは、2022年度用です！（SecHack365事務局の手違いで、こちらのURLが案内されています）
2023年はこちらです！→ sh3_2023_kw

↑

(1) こんな人を募集します！

「SecHack365 2022年度開発駆動コース川合ゼミ」では、こんな人を募集します。
- [1]プログラミング言語を作りたい人（これが川合ゼミでのおすすめテーマ#1になります）。
- [2]ライブラリを作りたい人（これが川合ゼミでのおすすめテーマ#2になります）。
- [3]そのほか川合が興味を持ちそうな開発をやりたい人（これが川合ゼミでの持ち込みテーマになります）。
いずれにせよ、私がトレーナとしてもっとも大切にしているのは、みんなが開発を楽しめることです。「SecHack365のせいで開発が嫌いになってしまった」というのを避けたいです。「前から好きだったけど、もっと好きになった。すごく楽しい」これを目指しています。
だから無理強いすることはないですし、効率よく早く正解を学ばせることよりも楽しみにながら試行錯誤して実感を伴って学んでもらうことを重視します。そもそも何が正解か、そんなに簡単に決められるものじゃないですよね。
どうしてもうまくいかなくてギブアップしたら私に質問してもらって、私は最低限のヒントを与えてあとは自力で突破してもらう、これが私の理想とする方法です。多くの人は、本当にあとちょっとのところまで来ているものなのです。

[3]を選ぶ場合、私が今までどんなことをしてきたのかを知っておく必要があるでしょう。
- 1996年～ V98というエミュレータを開発
- 2000年～ OSASKというPC向けの超軽量型の自作OSを開発
- 2002年～ naskというx86用のアセンブラを開発
- 2003年～ tek5というLZMAをベースにした可逆圧縮形式を開発
- 2005年～書籍「30日でできる！OS自作入門」を執筆
- 2010年～ blikeというC言語用のグラフィックライブラリを開発
- 2013年～ OSECPU-VMという仮想マシンを開発（このバイトコードでプログラムを書くと驚異的に小さくなる）
- 2019年～ kcl03というC言語用の基本ライブラリを開発
- 2019年～ kcll00というC言語用のプログラミング言語開発支援ライブラリを開発
- 2019年～ ES-BASICというスクリプト言語を開発（詳しくはこちら→esbasic02a）
- 2020年～ aclライブラリを開発
- 2021年～「10日くらいでできる！プログラミング言語自作入門」を書く（詳しくはこちら→a21_txt01）

まとめるとこんな感じです。
- エミュレータ自作、PC向けのOS自作、言語自作、圧縮、理想のCPU命令を考える、ライブラリを作って自身の開発力を底上げ

[1]でも[2]でも[3]でも、「自分の開発物を自分で常用しようと思っている人」が私は大好きです。
- これに関する私の考え方はp20200311aに書いてあります。
- 一方で「これを作ることで〇〇を実証するのだ」みたいなのも私はOKなので、自分で常用しなければ絶対だめだというわけではないです（私もそういう目的で開発することが時々あります）。

[1]の場合、SecHack365で作るからには、ただのプログラミング言語であるわけにはいきません。セキュリティに配慮した言語を目指しましょう。
- しかし最初からセキュリティを意識して作るのは大変かもしれないで、途中からセキュリティ機能を付与していけばいいと私は思います。
- 自分で作るからには、日々、「こんな言語機能があれば絶対に便利なのに」と思ったことをまず盛り込んで、その上でセキュアにしましょう。
[2]の場合でも、セキュリティを意識したライブラリ仕様であることが期待されますが、応募段階ではそこまで考えていなくてもOKです。「このライブラリがあればこんなことやあんなことがこんなに簡単にできる」まずはそこを頑張りましょう。セキュリティは後付けで大丈夫です。

↑

(2) 補足

[Q]プログラミング言語を作ってみたいのだけど、作ったことがないのでできるかどうかわかりません。
- [A]a21_txt01（およびその続き）を読んでみてください。これを読んで「なるほどこれだったら自分でもできるかも」と思えたら、もうOKです。
- 応募までにすべてを読み終わる必要はありません。今どのあたりをやっているか（どこまで理解できているか）をぜひ書いてもらえたら、選考上さらに有利になると思いますので、「ばっちり〇〇までは理解できています！」ってアピールしてください。

[Q]ライブラリを作るのは言語を作ることと比べたらだいぶ難易度が低そうですが、それでもこのゼミでやるんですか？
- [A]はいそうです。多くの言語はライブラリを使うことで、できることがうんと広がります。「新しいことをできるようにしたいと思ったら言語を作らなければいけない」なんてことはないはずです。ライブラリを作るだけでもできることはたくさんあるはずです。そうであるならば、言語を作らずに済むのならそのほうが賢いと私は思うのです。・・・簡単にできることをわざわざ難しくする必要は全くありません！
- 私自身もライブラリを作ることで「いい思い」をしています（笑）。それを紹介する文章を現在準備中です。
- とりあえず一つ書きました。→a22_memman06

[Q]もう自分の作りたいものを作り始めているのですが、その続きを作る（改良をする）みたいなのでもいいでしょうか。
- [A]それは技術力と熱意の証明だと思うので、大歓迎です！
- むしろこれから作ろうと思っている人も、SecHack365での合格通知など待たずにどんどん作ってほしいです。応募前から作ってほしいくらいです。どこまでできたか教えてください。

[Q]川合ゼミでは、わからないことは何でもたくさん教えてもらえると思っていいでしょうか？
- [A]プログラムの開発の仕方は、何から何まで川合が教えてくれる！という「おんぶにだっこ」な対応は期待しないでください。トレーナーからの指導がなくても、6割くらいは自分で調べて作れるスキルがあるのが前提です。
- ・・・とはいえそれだけだと言語の作り方がわからなくて、言語自作にチャレンジできない人が増えそうだったのでa21_txt01は用意しました。これを読めばできそうな人が言語開発のテーマを選べます。
- 「6割どころか、全部自力でできると思います！」の人も大歓迎です。私はさらにきっかけを与えて完成度を120%や200%にすることを目指します。

[Q] グループでの応募はできないのはわかってますが、開発が進行していくにつれて他の合格者と一緒にやりたいって思うことがあるかもしれないですよね。その場合、その人とグループを組んで開発をすることはできますか？またその場合にその人のテーマに合わせたりすることもあり得ると思うのですが、それもOKですか。
- [A] そういう状況になれば、OKできると思います。

[Q]実力を示すためにコンテストでの受賞歴があったほうがいいですか？
- [A]川合は、コンテストでの受賞などをプラスには見ません（もちろんマイナスにもしませんが）。だから優勝したとか高得点を取ったなどのアピールは重要ではありません（もちろんそれでもアピールしたければしてもいいですが）。
- そうじゃなくて、そこでどんなものをどうやって作ったのかをアピールしてください。・・・結局、コンテストなどの受賞歴は、私からすれば他人の評価でしかないのです。私は私の基準で評価したいので、他人にどう評価されたことがあるかは関係がないのです。

[Q] 代表作なんかないです・・・
- [A] ここでいう代表作っていうのは、世間に公開したものがあったらそれを書いてね、という意味では「ない」のでご安心ください。自分がこの言語で作ったものの中で、一番よくできたのは〇〇です、ちなみにかくかくしかじかの内容です、って書いてくれたら十分です！・・・誤解しやすい書き方でごめんなさい。

[Q] 応募時に作りたいと思っていたものと、選考合格後に作りたいものが微妙に変わってしまったのですが大丈夫でしょうか？
- [A] どうして作りたいものが変わったのか、その話は面白そうなのでぜひ熱く語ってもらいたいですが、その上で、たいていはOKできると思います。・・・一応書いておきますが、合格するためにもともと興味もないような開発テーマを書いてみても、それはほぼ一発で見抜かれて落とされますのでそんなセコイことは考えないでくださいね。
- とまあそういうことですので、作りたいものが変わったらどうしよう、今後約1年間もこのテーマに縛られるとしたら慎重に書かないといけないかな、と身構える必要はありません。

[Q]こちらのゼミでは、年齢情報を選考に利用しますか？
- [A]はい、します。基本的に若い人には加算します。ですから「自分はまだスキルが足りないかもしれないから・・・」って応募を先送りしてもいいことはないと思います。とにかく今の自分は何が作りたくてどのくらいのことができるのか、書いてみてください！

↑

(3) 掛け持ちについて

私としては、他のことと掛け持ちしない人が好ましいと思っています。他のイベントにも積極的に参加しています、したいです、っていう人はきっと時間が足りなくなって、成果が中途半端になりやすいと思うのです。まあそれも人生なので仕方ない面はありますが、できればSecHack365に集中できそうな時期を選んで応募してくれたらうれしいです（まあ多少のことなら並行してやってもいいのですが・・・）。
また大学などの研究テーマ（今やっているやつ）をそのまま持ってこられたりするのは少し困ります。なぜなら、どこからどこまでがSecHack365の成果なのかわかりにくくなるからです。趣味で前からコツコツやっていた、とかはOKです。それなら成果の区切りがあいまいになっても、大きな問題にはならないからです。同じ理由で、今年の未踏でやっているテーマをそのまま持ってきた、というのも困ります。未踏に限らず、他のイベントとの掛け持ちはすべて該当します。

もしこれらの掛け持ち問題がありそうな人は、応募時に自己申告して、かくかくしかじかの理由でうまく切り分けられるので心配しないでくださいって教えてください。
- まあでも、掛け持ちするくらいなら、そっちをメインで最後まで頑張るほうがいい結果になりそうな気はしますよ！「二兎を追う者は一兎をも得ず」っていうじゃないですかー。

↑

(4) このゼミ独自の取り組み

（他のコースやゼミも川合ゼミの真似をすることはありうるので、川合ゼミ以外では絶対にやらないということではありません。）

（注意）いずれも一度はやりたいと思っていますが、その時に不評だったら二度目はやらないかもしれません。

[1] SecHack36.5min
- これは何をやるか事前に決めて、さらに事前に多少の準備をした上で、36.5分間、みんな一緒に、とにかく猛烈に集中して開発してみようぜ！というただそれだけの企画です。
- 開発内容は、自分の開発テーマの一部であってもいいですが、関係ないものであってもいいです。
- 終わった後に、何をやろうとしてどこまでできたのかを順番に発表しておしまいですが、たまに自由時間内に個人的に延長戦をやることもあります。
- 2019年度にやったときは結構好評でした。
- 私もやりましたが、成果は結構出ます。しかしその後の疲労感も結構あります（笑）。

[2] オープンソース開発スタイル体験
- これはSecHack365の同期の誰かの開発物に対して、ここはこうしたらどうかな？と提案する試みです。
- その際に、提案を日本語で好き勝手に言うのではなく、改造したプログラムで示すのです。
- （改造が大規模になると、なんか提案じゃなくて乗っ取りみたいになるので、100行程度を目安にします。）
- この企画の意図ですが、私たちオープンソースプログラマは、「外野からの提案なんて何を言われても大して役に立たない、そんなものよりパッチをくれ（＝コードをくれ）」というのが本心なので（笑）、つべこべ言う前にまずは改造してみましょう、というのをやってみようというわけです。
- なお、提案された側は、提案を受け入れて改造部分を本家に取り込んでもいいですが、拒否して入れなくてもいいです。
- 受け入れてもらえなかった場合には、本家開発者の許可を取ってフォーク（別バージョンとして独自進化）することもできます。

この企画の意図するところを説明します。
2019年度に私がES-BASICを開発していたところ、学習駆動コースの坂井トレーナーが面白がって改造してくれて、私はその改造を大喜びでマージした出来事がありました。
その直後に「こんな機能が入ったのだから、じゃあ今度はこの機能も入れよう」と私はアイデアをたくさん思いついて、さらにES-BASICを発展させることができて、それを見て坂井さんはさらに改造版を作って送ってくれました。
こうして、お互いにビジョンを相談したり開発計画を話し合ったわけでもなんでもないのですが、しかし結果的に私たちは非常に楽しく、かつ高速に開発ができたのです。
これはチーム開発ではないけど、でもこういう共同開発もあるよな、そういう経験ができたらすごくいいんじゃないかな、と、そういうわけです。

↑