SecHack365 2021年度 川合ゼミの説明
(1) こんな人を募集します！
- 「SecHack365 2021年度 開発駆動コース 川合ゼミ」では、こんな人を募集します。
- [1]プログラミング言語を作りたい人（これが川合ゼミでのおすすめテーマになります）。
- [2]そのほか川合が興味を持ちそうな開発をやりたい人（これが川合ゼミでの持ち込みテーマになります）。
- [2]を選ぶ場合、私が今までどんなことをしてきたのかを知っておく必要があるでしょう。
- 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]でも、「自分の開発物を自分で常用しようと思っている人」が私は大好きです。
- これに関する私の考え方はp20200311aに書いてあります。
- 一方で「これを作ることで〇〇を実証するのだ」みたいなのも私はOKなので、自分で常用しなければ絶対だめだというわけではないです（私もそういう目的で開発することが時々あります）。
- [1]の場合、SecHack365で作るからには、ただのプログラミング言語であるわけにはいきません。セキュリティに配慮した言語を目指しましょう。
- しかし最初からセキュリティを意識して作るのは大変かもしれないで、途中からセキュリティ機能を付与していけばいいと私は思います。
- 自分で作るからには、日々、「こんな言語機能があれば絶対に便利なのに」と思ったことをまず盛り込んで、その上でセキュアにしましょう。
- セキュリティ機能ってどんなことをすればいいの？って思いますよね。私が思いついたことをまとめてあります。→seclang01
(2) 補足
- [Q]プログラミング言語を作ってみたいのだけど、作ったことがないのでできるかどうかわかりません。
- [A]a21_txt01（およびその続き）を読んでみてください。これを読んで「なるほどこれだったら自分でもできるかも」と思えたら、もうOKです。
- 応募までにすべてを読み終わる必要はありません。今どのあたりをやっているか（どこまで理解できているか）をぜひ書いてもらえたら、選考上さらに有利になると思いますので、「ばっちり〇〇までは理解できています！」ってアピールしてください。
- [Q]もう作り始めているのですが、その続きを作る（改良をする）みたいなのでもいいでしょうか。
- [A]それは技術力と熱意の証明だと思うので、大歓迎です！
- むしろこれから作ろうと思っている人も、SecHack365での合格通知など待たずにどんどん作ってほしいです。応募前から作ってほしいくらいです。どこまでできたか教えてください。
- [Q]川合ゼミでは、わからないことは何でもたくさん教えてもらえると思っていいでしょうか？
- [A]プログラムの開発の仕方は、何から何まで川合が教えてくれる！という「おんぶにだっこ」な対応は期待しないでください。トレーナーからの指導がなくても、6割くらいは自分で調べて作れるスキルがあるのが前提です。
- ・・・とはいえそれだけだと言語の作り方がわからなくて、言語自作にチャレンジできない人が増えそうだったのでa21_txt01は用意しました。これを読めばできそうな人が言語開発のテーマを選べます。
- 「6割どころか、全部自力でできると思います！」の人も大歓迎です。私はさらにきっかけを与えて完成度を120%や200%にすることを目指します。
- [Q] グループでの応募はできないけれど、開発が進行していくにつれて他の合格者と一緒にやりたいって思うことがあるかもしれないですよね。その場合、その人とグループを組んで開発をすることはできますか？またその場合にその人のテーマに合わせたりすることもあり得ると思うのですが、それもOKですか。
- [A] そういう状況になれば、OKできると思います。
- [Q]実力を示すためにコンテストでの受賞歴があったほうがいいですか？
- [A]川合は、コンテストでの受賞などをプラスには見ません（もちろんマイナスにもしませんが）。だから優勝したとか高得点を取ったなどのアピールは重要ではありません（もちろんそれでもアピールしたければしてもいいですが）。
- そうじゃなくて、そこでどんなものをどうやって作ったのかをアピールしてください。・・・結局、コンテストなどの受賞歴は、私からすれば他人の評価でしかないのです。私は私の基準で評価したいので、他人にどう評価されたことがあるかは関係がないのです。
- [Q] 代表作なんかないです・・・
- [A] ここでいう代表作っていうのは、世間に公開したものがあったらそれを書いてね、という意味では「ない」のでご安心ください。自分がこの言語で作ったものの中で、一番よくできたのは〇〇です、ちなみにかくかくしかじかの内容です、って書いてくれたら十分です！・・・誤解しやすい書き方でごめんなさい。
- [Q] 応募時に作りたいと思っていたものと、選考合格後に作りたいものが微妙に変わってしまったのですが大丈夫でしょうか？
- [A] どうして作りたいものが変わったのか、その話は面白そうなのでぜひ熱く語ってもらいたいですが、その上で、たいていはOKできると思います。・・・一応書いておきますが、合格するためにもともと興味もないような開発テーマを書いてみても、それはほぼ一発で見抜かれて落とされますのでそんなセコイことは考えないでくださいね。
- とまあそういうことですので、作りたいものが変わったらどうしよう、今後約1年間もこのテーマに縛られるとしたら慎重に書かないといけないかな、と身構える必要はありません。
(3) 掛け持ちについて
- 私としては、他のことと掛け持ちしない人が好ましいと思っています。他のイベントにも積極的に参加しています、したいです、っていう人はきっと時間が足りなくなって、成果が中途半端になりやすいと思うのです。まあそれも人生なので仕方ない面はありますが、できればSecHack365に集中できそうな時期を選んで応募してくれたらうれしいです（まあ多少のことなら並行してやってもいいのですが・・・）。
- また大学などの研究テーマ（今やっているやつ）をそのまま持ってこられたりするのは少し困ります。なぜなら、どこからどこまでがSecHack365の成果なのかわかりにくくなるからです。趣味で前からコツコツやっていた、とかはOKです。それなら成果の区切りがあいまいになっても、大きな問題にはならないからです。同じ理由で、今年の未踏でやっているテーマをそのまま持ってきた、というのも困ります。未踏に限らず、他のイベントとの掛け持ちはすべて該当します。
- もしこれらの掛け持ち問題がありそうな人は、応募時に自己申告して、かくかくしかじかの理由でうまく切り分けられるので心配しないでくださいって教えてください。
- まあでも、掛け持ちするくらいなら、そっちをメインで最後まで頑張るほうがいい結果になりそうな気はしますよ！「二兎を追う者は一兎をも得ず」っていうじゃないですかー。
(4) このゼミ独自の取り組み
- （他のコースやゼミも川合ゼミの真似をすることはありうるので、川合ゼミ以外では絶対にやらないということではありません。）
- （注意）いずれも一度はやりたいと思っていますが、その時に不評だったら二度目はやらないかもしれません。
- [1] SecHack36.5min
- これは何をやるか事前に決めて、さらに事前に多少の準備をした上で、36.5分間、みんな一緒に、とにかく猛烈に集中して開発してみようぜ！というただそれだけの企画です。
- 開発内容は、自分の開発テーマの一部であってもいいですが、関係ないものであってもいいです。
- 終わった後に、何をやろうとしてどこまでできたのかを順番に発表しておしまいですが、たまに自由時間内に個人的に延長戦をやることもあります。
- 2019年度にやったときは結構好評でした。
- 私もやりましたが、成果は結構出ます。しかしその後の疲労感も結構あります（笑）。
- [2] オープンソース開発スタイル体験
- これはSecHack365の同期の誰かの開発物に対して、ここはこうしたらどうかな？と提案する試みです。
- その際に、提案を日本語で好き勝手に言うのではなく、改造したプログラムで示すのです。
- （改造が大規模になると、なんか提案じゃなくて乗っ取りみたいになるので、100行程度を目安にします。）
- この企画の意図ですが、私たちオープンソースプログラマは、「外野からの提案なんて何を言われても大して役に立たない、そんなものよりパッチをくれ（＝コードをくれ）」というのが本心なので（笑）、つべこべ言う前にまずは改造してみましょう、というのをやってみようというわけです。
- なお、提案された側は、提案を受け入れて改造部分を本家に取り込んでもいいですが、拒否して入れなくてもいいです。
- 受け入れてもらえなかった場合には、本家開発者の許可を取ってフォーク（別バージョンとして独自進化）することもできます。
- この企画の意図するところを説明します。
- 2019年度に私がES-BASICを開発していたところ、学習駆動コースの坂井トレーナーが面白がって改造してくれて、私はその改造を大喜びでマージした出来事がありました。
- その直後に「こんな機能が入ったのだから、じゃあ今度はこの機能も入れよう」と私はアイデアをたくさん思いついて、さらにES-BASICを発展させることができて、それを見て坂井さんはさらに改造版を作って送ってくれました。
- こうして、お互いにビジョンを相談したり開発計画を話し合ったわけでもなんでもないのですが、しかし結果的に私たちは非常に楽しく、かつ高速に開発ができたのです。
- これはチーム開発ではないけど、でもこういう共同開発もあるよな、そういう経験ができたらすごくいいんじゃないかな、と、そういうわけです。
(5) ちなみに
- ちなみに、学習駆動コースも川合ゼミに似たテーマを扱っていますので、そちらも確認しておくと、後になって「ああ、それだったら学習駆動コースにしておけばよかった！」と後悔しないで済むと思います。
(6) 共通問題への回答について
- 2020年度から、NICTからの共通問題もでるようです。それらへの回答は簡潔に書いてもらっても大丈夫です（だって二回も同じような説明をするのは大変でしょうから）。その分、コース別の回答は詳しく丁寧に書いてください。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
