Zig なんもわからん〜あるいは学びのモチベーション〜

なんもわからん  〜あるいは学びのモチベーション〜  Smith  kanzen ni rikai shita   nanmo wakaran 
Dunning–Kruger Curve  

• わたしはだれ？  • この資料でお伝えしたいこと  • ってなんですか？  • 新しい言語を学んでみた  • 学びのモチベーション 
• まとめ  Agenda 

Smith  BtoB 事業本部 AROW部  • 部長  • プロデューサー  • エンジニア 
SRE部クライアントグループ  • グループ長  • 御用聞き  わたしはだれ？  @dolow  @do_low 

この資料でお伝えしたいこと 

なにかをまなぶって、たのしいね！ 

ってなんですか？ 

ってなんですか？  まずはこれを見て欲しい。  var a = b + c.d; foo(); var();

ってなんですか？  まずはこれを見て欲しい。  これ、なんと・・・  var a = b + c.d; foo();
var();

ってなんですか？  まずはこれを見て欲しい。  これ、なんと・・・見た目通りに処理されるんです。  var a = b + c.d; foo();
var();

var(); プロパティアクセスに見せかけたアクセサがない！  

var(); 演算子オーバーロードなんてない！   プロパティアクセスに見せかけたアクセサがない！  

var(); 演算子オーバーロードなんてない！   プロパティアクセスに見せかけたアクセサがない！   勝手に例外起こして変な所でキャッチされない！  

var(); 演算子オーバーロードなんてない！   プロパティアクセスに見せかけたアクセサがない！   勝手に例外起こして変な所でキャッチされない！   だから絶対実行されるやーつ！  

var(); 演算子オーバーロードなんてない！   プロパティアクセスに見せかけたアクセサがない！   勝手に例外起こして変な所でキャッチされない！   だから絶対実行されるやーつ！   B-E-A-Utiful !!! 

https://ziglang.org/learn/overview/ ってなんですか？ 

ってなんですか？  あとこれも見て欲しい。  fn MyType(comptime T: type) type { return struct
{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; }

{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } • 無名の構造体を返せるのね  

{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } • 無名の構造体を返せるのね   • 引数は型、なるほど、これはジェネリックみたいなもんね 

{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } • 無名の構造体を返せるのね   • 引数は型、なるほど、これはジェネリックみたいなもんね  • init は静的メソッドみたいなもんで、これで MyType のインスタンスが作られるのね 

{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } • 無名の構造体を返せるのね   • 引数は型、なるほど、これはジェネリックみたいなもんね  • init は静的メソッドみたいなもんで、これで MyType のインスタンスが作られるのね  ここまでは「ほーん」って感じだけど。 

ってなんですか？  fn sum(my_type: MyType(u8)) u8 { return my_type.get() + 10;
} test "value as type" { const t = MyType(u8).init(10); const v: u8 = 20; try std.testing.expectEqual(v, sum(t)); } んで、これはさっきの MyType を使った実装ね・・・ 

} test "value as type" { const t = MyType(u8).init(10); const v: u8 = 20; try std.testing.expectEqual(v, sum(t)); } んで、これはさっきの MyType を使った実装ね・・・    ・・・ん！？ 

} test "value as type" { const t = MyType(u8).init(10); const v: u8 = 20; try std.testing.expectEqual(v, sum(t)); } んで、これはさっきの MyType を使った実装ね・・・    ・・・ん！？    あ、値が型ーー！？！？  アイエエー！！ニンジャナンデ！？ 

ってなんですか？  コンパイル時間で型解決してくれるスグレモノ！  fn MyType(comptime T: type) type { return struct
{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } fn sum(my_type: MyType(u8)) u8 { return my_type.get() + 10; } test "value as type" { const t = MyType(u8).init(10); const v: u8 = 20; try std.testing.expectEqual(v, sum(t)); }

ってなんですか？  コンパイル時間で型解決してくれるスグレモノ！  fn MyType(comptime T: type) type { return struct
{ const Self = @This(); v: T, pub fn init(v: T) Self { return Self{ .v = v }; } pub fn get(self: Self) T { return self.v; } }; } fn sum(my_type: MyType(u8)) u8 { return my_type.get() + 10; } test "value as type" { const t = MyType(u8).init(10); const v: u8 = 20; try std.testing.expectEqual(v, sum(t)); } B-E-A-Utiful !!! 

よくわかんないけど  すごく書いてみたい気持ちになったでしょ！？  （言語の概要はググれば出てくるので端折ります）  ってなんですか？ 

というわけで 

新しい言語を学んでみた 

モチベーションについて知る前に、実際に学んだ Smith の行動を眺めます。  • Install and Hello World  • 表現力を高める 
• なにか作る  • アウトプットする  やったこと 

1. Install and Hello World 

Install and Hello World  ダウンロード https://ziglang.org/download/  Hello World  https://ziglang.org/documentation/0.9.1/#toc-Hello-World 

Install and Hello World  ダウンロード https://ziglang.org/download/  Hello World  https://ziglang.org/documentation/0.9.1/#toc-Hello-World  とにかくサクッと終わらせる 

Install and Hello World  最初は必ず Hello World をする。  Hello World
の達成には次の効果がある。  • やった感を得られる  • 開発イテレーションが回せるようになる  • もっと触りたくなる  • これさえできなかったら根本的な何かがおかしいと気付ける  • 完全に理解したと言っても過言ではない (過言)  一気に難しいことをやろうとすると挫ける。  繰り返します、最初は必ず Hello World しましょう。 

での Hello World は、とくに詰まらずにできた。  Install and Hello World  const std
= @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); } % zig build-exe hello.zig % ./hello Hello, world!

2. 表現力を高める 

表現力を高める  Hello World からちょっとずついじる内に、表現力を高めたくなってきた。  色々と調べるうちに、はまだほとんど情報がないことがわかった。    現状で最も参考になるソース  • 公式ドキュメント
(とても読みにくい)  • 標準ライブラリのソースコード (とても読みやすい) 

構造体の表現  他の言語でも構造体はあったり、似たところでクラスがある。  でもシンプルな構造体の表現は既知の知識で半分くらい理解できた。  pub const MyStruct =
struct { const Self = @This(); items: u8, pub fn get(self: Self) u8 { return self.item; } pub fn set(self: *Self, v: u8) void { self.item = v; } }; 表現力を高める 

pub const MyStruct = struct { const Self = @This();
items: u8, pub fn get(self: Self) u8 { return self.item; } pub fn set(self: *Self, v: u8) void { self.item = v; } }; 表現力を高める  構造体の表現  ここだけでも言語の特徴が多く垣間見える。  関数レシーバとしての self かな？ python っぽい  構造体インスタンスとしての Self 定義かな？  レシーバがポインタかどうかの違いがある  go と同じ感じかと思ってた (実際は結構違う) 

pub fn Container(comptime T: type) type { return struct {
const Self = @This(); item: T, pub fn init(v: T) Self { return Self{ .item = v }; } pub fn get(self: Self) T { return self.item; } pub fn set(self: *Self, v: T) void { self.item = v; } }; } 表現力を高める  ポリモーフィズム  型 (type) を引数に渡すことで、コード上で動的に構造体を定義するように記述できる。  実際はコンパイル時間に解決される。  構造体を返す時の型は type 。 

表現力を高める  ポリモーフィズム  呼び出し側はこんなかんじ。  C++ のテンプレートみたいな感じですね。    もっと応用すると・・・  const container
= Container(u8);

表現力を高める  「値は型」  const Containers = struct { pub const U8:
Container(u8); pub const I8: Container(i8); pub const Usize: Container(usize); }; できた！すげー！！  fn sum(c: Containers.U8) u8 { return c.get() + 10; } test "value as type" { var c = Container(u8).init(1); const e:u8 = 11; try std.testing.expectEqual(e, sum(c)); } これだけで大興奮、日本酒 3合はやってる。 

表現力を高める  const はずし (コピー)  const u_1 = [2]u8{1,2}; var u_2
= u_1; // u_1[1] = 15; u_2[1] = 16; const e: u8 = 16; try std.testing.expectEqual(e, u_2[1]); 迷子になりがちな部分を攻略  *const と dereference (コピー)  const u_1 = &[2]u8{1,2}; var u_2 = u_1; var u_3 = u_1.*; // u_1[1] = 14; // u_2[1] = 15; u_3[1] = 16; const e1: u8 = 2; const e2: u8 = 16; try std.testing.expectEqual(2, u_1[1]); try std.testing.expectEqual(16, u_3[1]);

完全に理解した 

3. なにかつくる 

なにかつくる  2つくらい書いた。  • JSON to YAML  • オウム返し HTTP サーバ 

JSON to YAML  なにかつくる  ファイルパスを受け取り、ファイルの内容を YAML に変換する。 

オウム返し HTTP サーバ  なにかつくる  指定のポートとアドレスで listen し、GET なら GET したパスを含めたレスポンス、それ以外ならリクエストボディを含めた
レスポンスを返す。  ブラウザで GET  JavaScript の fetch で POST   サーバ起動 

おまけ  やっぱ完全に理解してないかもしれない。  ならではのハマりどころをいくつか踏みました。  ハマったとこ 

メモリ効率最強かよ  標準ライブラリで JSON 扱えるから、 JSON の解析は余裕じゃん 

メモリ効率最強かよ  標準ライブラリで JSON 扱えるから、 JSON の解析は余裕じゃん  って思うじゃん？ 

メモリ効率最強かよ  標準ライブラリで JSON 扱えるから、 JSON の解析は余裕じゃん  って思うじゃん？  ファイルコンテンツの文字列を 

メモリ効率最強かよ  標準ライブラリで JSON 扱えるから、 JSON の解析は余裕じゃん  って思うじゃん？  ファイルコンテンツの文字列を  参照している  
(コピーではない) 

メモリ効率最強かよ  標準ライブラリで JSON 扱えるから、 JSON の解析は余裕じゃん  って思うじゃん？  ファイルコンテンツの文字列を  参照している  
(コピーではない)  parse の直後に file_content を使わないからってリリースしたら、parsed の中身の u8[] もリリースされる・・・ 

HTTP サーバは、net モジュールが想像していたよりは整えられていたが・・・        RFC からやり直してきやがれ 

HTTP サーバは、net モジュールが想像していたよりは整えられていたが・・・    • あれ、 HTTP ボディの終端ってどうやって判断するんだっけ？     
RFC からやり直してきやがれ 

HTTP サーバは、net モジュールが想像していたよりは整えられていたが・・・    • あれ、 HTTP ボディの終端ってどうやって判断するんだっけ？  • Content-Length
が不正な場合の正しいサーバの振る舞いは？    RFC からやり直してきやがれ 

が不正な場合の正しいサーバの振る舞いは？  • サボらないでメソッド名見ないと・・・  RFC からやり直してきやがれ 

が不正な場合の正しいサーバの振る舞いは？  • サボらないでメソッド名見ないと・・・  RFC からやり直してきやがれ  あれ、思ったより HTTP サーバ実装してるじゃん？ 

RFC からやり直してきやがれ  accept からする実装が新鮮、HTTP というより TCP 仕様を読む   https://www.rfc-editor.org/rfc/rfc793#section-3.4  
クソダサヘッダーフィールドディテクション   https://www.rfc-editor.org/rfc/rfc2616#section-4.2   GET 以外で Content-Length がなければ 400、「私が法だ」   https://www.rfc-editor.org/rfc/rfc7230#section-3.3.2  

RFC からやり直してきやがれ  accept からしなければならないのが新鮮、HTTP というより TCP   https://www.rfc-editor.org/rfc/rfc793#section-3.4   クソダサヘッダーフィールドディテクション
  https://www.rfc-editor.org/rfc/rfc2616#section-4.2   GET 以外で Content-Length がなければ 400、「私が法だ」   https://www.rfc-editor.org/rfc/rfc7230#section-3.3.2   めっちゃ RFC  読んでるじゃん？ 

学ぶことがおおかったなぁ・・・  (学びなおし含む) 

4. アウトプットする 

github に公開しているのはもう習慣として。  (そもそも作業記録のために push してるものが公開されてるだけ)    作業中も、思ったことは Twitter でぽつぽつつぶやいたり。  •
#ziglang タグ付ける  • 素人だけど臆さない  基本的には、遊ばせてもらっている恩返しのスタンス。  アウトプットする 

成果物を共有したり  素人丸出し発言  中身のない発言をしたり 

素人を介護してくれるやさしいインターネッツ 

新しく言語を学んでみた    end 

本編: 学びのモチベーション 

モチベーション 

人間は本質的に怠惰だ。 

どうしようもない。 

学びが楽しいと感じる人は  とても幸福だ。 

そもそもなぜ学ぶのか？    モチベーション 

そもそもなぜ学ぶのか？  • 学んだことを手段として目的を達成するため (仮言命法)  • 学ぶこと自体が目的の道の精神 (定言命法)  モチベーション 

そもそもなぜ学ぶのか？  • 学んだことを手段として目的を達成するため (仮言命法)  • 学ぶこと自体が目的の道の精神 (定言命法)    後者の境地に至っている人はそうそういないでしょう。  今回は、前者におけるモチベーションをパターン別に解決します。 
モチベーション 

学び始めるきっかけは、大体この3パターン。  モチベーション    課題・仕事  趣味・遊び  不安・焦燥 

モチベーション    課題・仕事  趣味・遊び  成果  不安・焦燥  目的達成のために   やらざるをえない  
発散しがち  飽きたらやめられる   なんとなくやってる   場合が多い 

モチベーション    課題・仕事  成果  目的達成のために   やらざるをえない  

モチベーション    課題・仕事  成果  学習以前に、成果に対して   モチベーションを持っているハズ   そうでない「やらされ」ケースは  
ここでは取り扱わない  

モチベーション    課題・仕事  成果  進捗や成果が目に見えると   モチベーションが加速する   機能、品質、効率 etc…
  学習以前に、成果に対して   モチベーションを持っているハズ   そうでない「やらされ」ケースは   ここでは取り扱わない  

モチベーション    課題・仕事  成果  進捗や成果が目に見えると   モチベーションが加速する   機能、品質、効率 etc…
  学習以前に、成果に対して   モチベーションを持っているハズ   そうでない「やらされ」ケースは   ここでは取り扱わない   コツ: 得られる成果を最大化する  学習そのものが目的ではない典型パターン  • 学習は手段、成果が目的  • 成果に反映される学習を行う  • 成果が出ていることを確かめる  • 成果を共有する  • 勘違いしない 

モチベーション    趣味・遊び  発散しがち  飽きたらやめられる  

モチベーション    趣味・遊び  課題  放っておいてもしばらく続く   しかし無目的になりがち  

モチベーション    趣味・遊び  課題  課題を定めて  学びの方向性を定める   課題の達成を体験する   放っておいてもしばらく続く
  しかし無目的になりがち  

モチベーション    趣味・遊び  課題  課題を定めて  学びの方向性を定める   課題の達成を体験する   コツ:
意義のある遊びにする  始めるのは簡単、続けるのは難しい  • 自分なりの課題を設定する  • できることがわかりきった課題は設定しない  • 大きい課題ひとつよりも、こまめな課題を多く設定する  • シェアする  放っておいてもしばらく続く   しかし無目的になりがち  

モチベーション    不安・焦燥  なんとなくやってる   場合が多い 

モチベーション    不安・焦燥  「なぜこれを学んでいるのか」   が常につきまとう最も厄介なパターン  

モチベーション    不安・焦燥  「なぜこれを学んでいるのか」   が常につきまとう最も厄介なパターン   チュートリアルを 1日1つ写経する  
などの脳死ルーチンから始める  

モチベーション    不安・焦燥  「なぜこれを学んでいるのか」   が常につきまとう最も厄介なパターン   チュートリアルを 1日1つ写経する  
などの脳死ルーチンから始める   コツ: 負荷の少ないことから始める  意義はそのうち見つければいい  • 「本当に必要なのか」は最初に自問すること  • 気長に取り組む  • まずは教科書どおりすすめる  • クリエイティブなことは高負荷  • 反復学習で修得を体感する 

学んでみた編で実践されていたこと   

モチベーション   Smith の場合 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  大体の場合、事業に近い技術を遊びでやってる 

モチベーション    趣味・遊び  Smith の場合  学び続けなければヤバイよね  っていうプレッシャーも  課題・仕事  大体の場合、事業に近い技術を遊びでやってる 
不安・焦燥 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  遊びが主軸なので、  興味を持ったら  触り始めるのはチョロい  不安・焦燥 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  そこから先は・・・  不安・焦燥 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  追い込む  不安・焦燥 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  追い込む  不安・焦燥  SNS を利用し、人の目と自意識を逆手に取る
 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  いつもの課題をやる  課題 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  いつもの課題をやる  課題  新しい言語に触るときの定番課題を自分で用意している
 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  いつもの課題をやる  課題  新しい言語に触るときの定番課題を自分で用意している
  Rust サーバ: https://github.com/dolow/server.rs   Go サーバ: https://github.com/dolow/server.go   JavaScript サーバ: https://github.com/dolow/server.js (これは経緯がちょっと違う)   Go フォーマット変換: https://github.com/dolow/nt-go   今回の Zig: https://github.com/dolow/zig-playground  

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  課題 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  成果を共有する、  仕事に活かす  課題 

モチベーション    趣味・遊び  Smith の場合  課題・仕事  不安・焦燥  成果を共有する、  仕事に活かす  課題 
隙あらばねじ込むための自己学習でもある・・・      

モチベーション  テクニックとして、自分自身の熟達を早いサイクルで体感できると良い。  熟達を体感できるコツ  • 開発イテレーションを高速に回す  • 小さなリファクタを行う  • 小さな挑戦を一つずつ  •
覚えたことを試す (反復学習)  • こまめに git にコミットする  • 難しそうなことや大掛かりなものは先送りにする 

初めてのことは難しい  ↓           

初めてのことは難しい  ↓  難しいことは諦めやすい  ↓       

初めてのことは難しい  ↓  難しいことは諦めやすい  ↓  短時間で成果を体感しよう  ↓   

初めてのことは難しい  ↓  難しいことは諦めやすい  ↓  短時間で成果を体感しよう  ↓  小さな事を積み重ねよう 

ちなみに 

インストールから  Hello World までは         

インストールから  Hello World までは    勢い     

インストールから  Hello World までは    勢い    じゃないと一生やらない 

さも当たり前のように  「新しいこと学んだよ」って発表したけど、  人間にはモチベーションってものがあるのよ 

おまけ (時間があれば)  その他の学びの基本テクニック 

取捨選択する 

取捨選択する時間は有限だ  • できることはやらない  できるかわからないもの、知らないことを中心に取り組む  • トップダウンの学習でいい  公式ドキュメントや標準ライブラリを全部読まなくていい  (もちろん、時間があるなら全部読んだ方がいい)   

json モジュールのコードを読んだ時に見た union(enum) 、初めて見たときは「これ何だよォォー！」って思ってても、理解しちゃったら使いたくなるのがエンジニアの性   取捨選択するできることはやらない  できないこと、知らないことを知る。 
例)  JSON モジュールでやっているマーシャリングの実装が想像できなかった。  → コードを読んで理解を深めた 

取捨選択するトップダウンの学習でいい  トップダウンの数をこなすだけでもカバー範囲が広がります。  やっていく内に分からないことにたくさん出会うので、それらは深く掘り下げるように努力します。(≠放置)  完全に理解した→なんもわからん、へ成長する一つの過程です。  Zig なんもわからん 

捨てたもの  • JSON トークン解析  • HTTP サーバーのルーティング処理  拾ったもの  • ref/value,
imutable/mutable の理解  • HTTP 学び直し (ちょこっと)  取捨選択する

全体像理解 

目の前の技術を広い視野で捉えます。  • いま学習している技術が木の枝葉なのか幹なのか  • 他のどの技術とつながりがあるのか  • 若い技術か、研究されつくされているか  • その技術が生まれた背景は何か   
必ずしも正解である必要はなく、自分が今後その技術を使ったり、付き合っていく具体的なイメージが湧けば良いです。    全体像理解

全体像理解メモリ  CPU  linux  Ruby  Rails  Go  Zig  アセンブリ 
HTTP  Docker  Unity  iOS  Android  C#  C/C++  Java  Script  AWS  ブロック  チェーン  DB  TCP  GCP  Solidity  FS  ※ ←適当に配置しただけなので、宗教観とか歴史認識の相違とかで文句言わないでね 

全体像理解メモリ  CPU  linux  Ruby  Rails  Go  Zig  アセンブリ 
HTTP  Docker  Unity  iOS  Android  C#  C/C++  Java  Script  AWS  ブロック  チェーン  DB  TCP  GCP  Solidity  FS  ※ ←適当に配置しただけなので、宗教観とか歴史認識の相違とかで文句言わないでね  • すべての技術はつながっている  • 今、触っている技術が枝葉なのか幹なのかを把握する  • 枝葉の技術はトレンドになりやすいが、うつろいやすくもある  • 枝葉の技術は、幹の技術に習熟していれば修得が早くなる  (逆に、枝葉の技術をそんなに頑張ってもなぁ、って取捨選択もできる)  

の場合  • Rust と同じ立ち位置  ◦ Rust の方が複雑と言われているが、そうでもない気がする・・・   • まだ若いので導入判断は慎重に 
• 弊社事業領域の主要サービスですぐに使うことはない  • C/C++ を書くシーンではを検討したい  • メモリ操作やポインタなどのパラダイム  • golang って本当にバランスいいなぁ・・・　　　  全体像理解

まとめ 

まとめ  のまとめ  • C/C++ やメモリ管理の理解があれば取っつきやすい  • 思ったよりも表現力が高い  • メモリ効率が徹底している  •
const やポインタが C/C++ よりも多彩で複雑  新しい技術を学ぶまとめ  • 自分の状態に適したモチベーションコントロールをしよう  • いま学ぶもの、後に回すものを取捨選択しよう  • 全体像を理解し、どのように使うかイメージしよう 

エンジニアリングの世界では、時代とともに手に触れられる技術領域が多様化していき、各領域の専門性も深くなっていっています。  スペシャリストであることは貴重だし、ひとつのサービスを一人で作りきれるくらいの守備範囲の広さも貴重です。  しかしエンジニアである以上、どんなキャリアを選ぼうと絶え間なく学習しなければ第一線で戦い続けることはできません。  効率よく学習するコツを掴み、自分自身のモチベーションを観察しながら楽しく学んでいきましょう。  まとめ

ご清聴ありがとうございました  This presentation is encouraged by   cameos amigos 

Zig なんもわからん 〜あるいは学びのモチベーション〜

Zig なんもわからん 〜あるいは学びのモチベーション〜

More Decks by Smith

Other Decks in Technology

Featured

Transcript

Zig なんもわからん〜あるいは学びのモチベーション〜

Zig なんもわからん〜あるいは学びのモチベーション〜