kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

使いたい API がきっと見つかる!public-apis リポジトリ

フロントエンドのプロトタイプ実装をするときや API を使ったアプリケーションを実装するときなど「ササッと使える API があると便利なんだけどー!」という場面はよくある!本当によくある.今回紹介する GitHub の public-apis リポジトリは,2022年8月時点で「1400 以上」の API が載っていて,使いたい API がきっと見つかるはず!

僕自身は2019年頃から public-apis リポジトリを参考にしていて,今までブログで紹介していなかったことに気付いた!今回は public-apis リポジトリと個人的によく使っているおすすめ API を紹介する.ちなみに GitHub issue を見るとすぐに気付くけど,リポジトリ運営に課題があるらしく,特に今年になって状況は悪くなっていると思う.今後どうなることやら...

github.com

public-apis リポジトリには,2022年8月時点で「1400 以上」の API が「51 カテゴリー」に分類されている.多すぎー!と言いたくなるほどに多岐にわたる.また Auth / HTTPS / CORS といった API を実行するときに考慮するべき要素も確認できる.

  • Animals(動物)
  • Anime(アニメ)
  • Anti-Malware(マルウェア対策)
  • Art & Design(アート & デザイン)
  • Authentication & Authorization(認証 & 認可)
  • Blockchain(ブロックチェーン)
  • Books(書籍)
  • Business(ビジネス)
  • Calendar(カレンダー)
  • Cloud Storage & File Sharing(クラウド ストレージ & ファイル共有)
  • Continuous Integration(継続的インテグレーション)
  • Cryptocurrency(暗号通貨)
  • Currency Exchange(為替)
  • Data Validation(データ検証)
  • Development(開発)
  • Dictionaries(辞書)
  • Documents & Productivity(ドキュメント & プロダクティビティ)
  • Email(メール)
  • Entertainment(エンターテイメント)
  • Environment(環境)
  • Events(イベント)
  • Finance(ファイナンス)
  • Food & Drink(食べ物 & 飲み物)
  • Games & Comics(ゲーム & 漫画)
  • Geocoding(ジオコーディング)
  • Government(政府)
  • Health(健康)
  • Jobs(仕事)
  • Machine Learning(機械学習)
  • Music(音楽)
  • News(ニュース)
  • Open Data(オープンデータ)
  • Open Source Projects(オープンソースプロジェクト)
  • Patent(特許)
  • Personality(パーソナリティ)
  • Phone(電話)
  • Photography(写真)
  • Programming(プログラミング)
  • Science & Math(科学 & 数学)
  • Security(セキュリティ)
  • Shopping(ショッピング)
  • Social(ソーシャル)
  • Sports & Fitness(スポーツ & フィットネス)
  • Test Data(テストデータ)
  • Text Analysis(テキスト分析)
  • Tracking(トラッキング)
  • Transportation(交通手段)
  • URL Shorteners(URL 短縮)
  • Vehicle(車)
  • Video(ビデオ)
  • Weather(天気)

おすすめ API

個人的によく使っているおすすめ API を「5種類」紹介する.まだまだ他にも使えそうな API はあるはず!

皆さんのおすすめはどれですか!?

1. RandomDog(Animals カテゴリー)

github.com

「RandomDog」は犬の画像とファイルサイズをランダムに取得できる API で,とてもシンプルに使える.また /doggos エンドポイントを実行すると犬の画像の一覧を取得できるため,リストビューなどを実装するときに使える.ワンちゃんカワイイ🐶

$ curl -s https://random.dog/woof.json | jq .
{
  "fileSizeBytes": 703054,
  "url": "https://random.dog/46754b31-a450-4afe-9063-d7c5b981ca28.jpg"
}

$ curl -s https://random.dog/doggos | jq .
[
  "00186969-c51d-462b-948b-30a7e1735908.jpg",
  "00564ba3-e5cb-4b2b-8d97-c65a9ef26c23.png",
  "00b417af-0b5f-42d7-9ad0-6aab6c3db491.jpg",
  (中略)
]

2. Zoo Animal API(Animals カテゴリー)

zoo-animal-api.herokuapp.com

「Zoo Animal API」は動物園で飼育されている動物のデータをランダムに取得できる API で,レスポンスの情報量が多いので,フロントエンドの UI をより複雑に実装するときに便利だったりする.以下の例は Laughing Kookaburra(ワライカワセミ)でカワイイけど,たまーにヘビとか少し苦手な動物が出てきたりするとドキッとすることもある🐍

$ curl -s https://zoo-animal-api.herokuapp.com/animals/rand | jq .
{
  "name": "Laughing Kookaburra",
  "latin_name": "Dacelo navaeguineae",
  "animal_type": "Bird",
  "active_time": "Diurnal",
  "length_min": "1.4",
  "length_max": "1.5",
  "weight_min": "0.8",
  "weight_max": "1",
  "lifespan": "20",
  "habitat": "Forest",
  "diet": "Insects, snakes, lizards, rodents, and small birds",
  "geo_range": "Australia, Tasmania and New Zealand",
  "image_link": "https://upload.wikimedia.org/wikipedia/commons/9/9b/Laughing_kookaburra_dec08_02.jpg",
  "id": 104
}

3. Gutendex(Books カテゴリー)

gutendex.com

「Gutendex」は著作権切れになった書籍を電子化するプロジェクト Project Gutenberg の API で書籍データを取得できる.電子書籍サイトのプロトタイプ実装をするときに便利!以下はサンプルとして「Alice's Adventures in Wonderland(不思議の国のアリス)」の情報を取得している.また API エンドポイントに ?languages=ja を追加すると日本語の書籍も取得できて,例えば「羅生門」の情報も取得できる.

$ curl -s https://gutendex.com/books/\?ids\=11 | jq '.results[0]'
{
  "id": 11,
  "title": "Alice's Adventures in Wonderland",
  "authors": [
    {
      "name": "Carroll, Lewis",
      "birth_year": 1832,
      "death_year": 1898
    }
  ],
  "translators": [],
  "subjects": [
    "Alice (Fictitious character from Carroll) -- Juvenile fiction",
    "Children's stories",
    "Fantasy fiction",
    "Imaginary places -- Juvenile fiction"
  ],
  "bookshelves": [
    "Children's Literature"
  ],
  "languages": [
    "en"
  ],
  "copyright": false,
  "media_type": "Text",
  "formats": {
    "application/epub+zip": "https://www.gutenberg.org/ebooks/11.epub.images",
    "application/rdf+xml": "https://www.gutenberg.org/ebooks/11.rdf",
    "application/x-mobipocket-ebook": "https://www.gutenberg.org/ebooks/11.kindle.images",
    "text/html; charset=utf-8": "https://www.gutenberg.org/files/11/11-h.zip",
    "image/jpeg": "https://www.gutenberg.org/cache/epub/11/pg11.cover.medium.jpg",
    "text/plain; charset=utf-8": "https://www.gutenberg.org/files/11/11-0.zip",
    "text/html": "https://www.gutenberg.org/ebooks/11.html.images"
  },
  "download_count": 24462
}

$ curl -s https://gutendex.com/books/?languages=ja | jq '.results[0]'
{
  "id": 1982,
  "title": "羅生門",
  "authors": [
    {
      "name": "Akutagawa, Ryunosuke",
      "birth_year": 1892,
      "death_year": 1927
    }
  ],
  "translators": [],
  "subjects": [
    "Japan -- Social life and customs -- Fiction",
    "Short stories"
  ],
  "bookshelves": [],
  "languages": [
    "ja"
  ],
  "copyright": false,
  "media_type": "Text",
  "formats": {
    "text/html": "https://www.gutenberg.org/ebooks/1982.html.images",
    "application/x-mobipocket-ebook": "https://www.gutenberg.org/ebooks/1982.kindle.images",
    "application/epub+zip": "https://www.gutenberg.org/ebooks/1982.epub.images",
    "application/rdf+xml": "https://www.gutenberg.org/ebooks/1982.rdf",
    "image/jpeg": "https://www.gutenberg.org/cache/epub/1982/pg1982.cover.medium.jpg",
    "text/plain; charset=utf-8": "https://www.gutenberg.org/files/1982/1982-0.txt"
  },
  "download_count": 330
}

4. CountAPI(Development カテゴリー)

countapi.xyz

「CountAPI」は今までの API とは違って,情報を取得するという用途ではなく「回数を数える」ために使える.イメージとしては Redis の INCR コマンドに近いと思う.https://api.countapi.xyz/hit/{namespace}/{key} という API に任意の namespace(名前空間) と key(キー) を指定して実行すると,値をインクリメントできる.以下には kakakakakku/blog に3回リクエストを送った例を載せてみた.幅広く使えそうな API でおすすめ!

$ curl -s https://api.countapi.xyz/hit/kakakakakku/blog | jq .
{
  "value": 1
}

$ curl -s https://api.countapi.xyz/hit/kakakakakku/blog | jq .
{
  "value": 2
}

$ curl -s https://api.countapi.xyz/hit/kakakakakku/blog | jq .
{
  "value": 3
}

5. weather-api(Weather カテゴリー)

github.com

「weather-api」は指定した都市の天気予報を取得できる API で,3日後までの予測も取得できる.wttr.in というサイトに依存してるらしく Shibuya-ku なども使える.たまに Heroku のエラーで使えないことがあったり,予測結果が表示されないこともあって挙動に不安定ではあるものの,お題として天気予報を表示するフロントエンド(そしてエラーハンドリングの練習も!笑)を構築するときなどに使える.天気予報の精度はよくわからず,あくまでサンプル API として気軽に使えることがメリットかなと!

$ curl -s https://goweather.herokuapp.com/weather/Shibuya-ku | jq .
{
  "temperature": "+23 °C",
  "wind": "9 km/h",
  "description": "Partly cloudy",
  "forecast": [
    {
      "day": "1",
      "temperature": "30 °C",
      "wind": "16 km/h"
    },
    {
      "day": "2",
      "temperature": "+29 °C",
      "wind": "14 km/h"
    },
    {
      "day": "3",
      "temperature": "+32 °C",
      "wind": "36 km/h"
    }
  ]
}

まとめ

ササッと使える API を探すときに GitHub の public-apis リポジトリが便利!使いたい API がきっと見つかるはず!

github.com

なお,最初に書いた通り,public-apis リポジトリ運営に課題があるらしく,最近では以下の APIsList など,Fork したサイトもリリースされていたりする.今後どうなることやら!

apislist.com

プログラミングを上手に教える 10 Tips / 論文「Ten quick tips for teaching programming」を読んだ

2018年に発表された論文「Ten quick tips for teaching programming(意訳 : プログラミングを教えるための簡単な 10 Tips)」を読んだ.直近は技術講師(インストラクター)として4年間ほどクラウドなどを教えていて,コースによってはプログラミングを教える機会はあるし,2018年までは2年間ほど TechAcademy で Ruby / Rails 講師をしていたし,キャリアとして「今まで」も「今後」もプログラミングを教える続けると思う.そこで,今までの教授戦略を振り返るためにも本論文に興味を持った!

(PDF) Ten quick tips for teaching programming

本論文に載っている 10 Tips は以下で,日本語訳は意訳してみた!

  • Tip 1: Remember that there is no geek gene(ギークの遺伝子は存在しない)
  • Tip 2: Use peer instruction(ピアインストラクションを活用しよう)
  • Tip 3: Use live coding(ライブコーディングを活用しよう)
  • Tip 4: Have students make predictions(生徒に予測をしてもらおう)
  • Tip 5: Use pair programming(ペアプログラミングを活用しよう)
  • Tip 6: Use worked examples with labelled subgoals(ラベル付けしたサブゴールを活用しよう)
  • Tip 7: Stick to one language(プログラミング言語は1つに固定しよう)
  • Tip 8: Use authentic tasks(わかりやすいお題を活用しよう)
  • Tip 9: Remember that novices are not experts(入門者は専門家ではない)
  • Tip 10: Don’t just code(プログラミングだけじゃない)

Tip 1: Remember that there is no geek gene(ギークの遺伝子は存在しない)

プログラミングスキルは生まれつきのものではなく,練習によって獲得できるし,向上できると書いてあった.その通りだと思う!インストラクターとして,プログラミングに向いている生徒や向いていない生徒という偏見は持たず,それぞれのペースで一歩一歩学んでもらうことが重要だと思う.プログラミングを学ぶ時期に遅いなんてことはないし,誰しもプログラムは実装できるようになる💪

Tip 2: Use peer instruction(ピアインストラクションを活用しよう)

マンツーマンなら1人の生徒に集中して教えられるので学習効率は高まるけど,教育の現場では複数人(数名 / 数十人 / 数百人)に同時に教えることが多く,どのように学習効果を高めるかという教授戦略が重要になる.本論文では Eric Mazur によって普及された「ピアインストラクション」を使うと書いてあった.ピアインストラクションの詳細は Wikipedia などを見てもらうとして,簡単に紹介すると,講義中に生徒同士がお互いに相談しながら進めるアクティブラーニングの手法の一つと言える.インストラクターの講義を聞く従来のスタイルよりも生徒中心で学んでもらうアプローチになる.

en.wikipedia.org

本論文にもWikipedia にも載っているけど,ピアインストラクションは一般的に複数のステップで構成される.何かしらの問題を出して,まずは個別に考えて回答して,次にグループディスカッション形式で考えて回答する.本論文には問題を出すときのポイントが載っていて,全員が正解するような難易度の問題ではあまり意味がなく,正解率が 40% ~ 60% ぐらいになる問題を作るべきと書いてあった.間違えることは悪いことではなく,同じ問題を個人とグループで考えることで,より理解を深められる.本論文には「ループと整数比較の問題例」が載っていた.プログラミング入門者を集めたら確かに回答はバラけそう💡

// 実行すると Yes は何回表示されますか?
// a) 10
// b) 5
// c) 4
// d) 3
for (int i = 1; i < 10; i++) {
    if (i < 3 || i >= 8) {
        System.out.println("Yes");
    }
}

Tip 3: Use live coding(ライブコーディングを活用しよう)

プログラミングを教えるときに「スライド」を使うのではなく,インストラクターが「ライブコーディング」をするべきと書いてあった.具体的に以下のメリットが挙げられていた❗️

  • ライブコーディングなら「もし○○のときはどうなる?」という生徒の疑問に答えながら柔軟に進行できる
    • スライドだと「高速道路」になってしまう
  • ライブコーディングをすることによって「もともと教えようとしていたこと以外」も観察してもらえる
    • コードを実装する順番/エディタ操作/ショートカット操作など
  • スライドを使うよりも教えるペースが遅くなることによって理解できていない生徒を置き去りにしてしまうリスクを減らせる
  • インストラクターが「どのように間違えてどのように解決するのか」という流れを見せられる
    • プログラミング入門者は多くの時間をデバッグに費やすのに講義だとそこが学べない😱
  • インストラクターがその場で間違えることで「全然間違って良いんだ!」ということを教えられる

僕自身の講義でもプログラミングを教えるときは,できる限りスライドは使わず「自分で実装したプログラム」を使うことを重要視している.また「ライブコーディング」をすることもあるけど頻度はそこまで高くなく,今後はもっと活用していこうと思った!そして「どのように間違えてどのように解決するのか」というメリットを読んだときは「ドットインストール」を思い出した.ドットインストールのビデオでは予定していなかったであろう typo や構文エラーなどが出て,エラーメッセージなどを見ながら直すという場面がたまにあって素晴らしい!

dotinstall.com

さらに本論文にはライブコーディングのデメリットも明確に書いてあった.まず,インストラクターがプログラミングに慣れてなく,タイピングが遅かったり,メモを見ながらライブコーディングをするとグダグダになって逆効果になってしまう.またライブコーディングだとは言え,ゼロから実装すると伝えるべきポイントとズレる可能性もあるので,ボイラープレートのような雛形を作っておいて,そこから実装をはじめる.

Tip 4: Have students make predictions(生徒に予測をしてもらおう)

ライブコーディングなどを見せるときに,単に見せるのではなく生徒に実行結果を予測してもらうことで,より効果を高められると書いてあった.個人的な経験からも考えながらデモを見るのは本当に効果的で重要なプラクティスだと思う.Cyber-Dojo の predict? 機能も似ている.

kakakakakku.hatenablog.com

Tip 5: Use pair programming(ペアプログラミングを活用しよう)

ペアプログラミングはプロダクト開発だけじゃなく教育でも優れていると書いてあった.「ピアインストラクション」にも関連するけど,生徒同士がお互いに相談をしながらプログラミングを進められる.またペアプログラミングを活用するときの注意点として,ペアプログラミングを支配してしまうような生徒がいる可能性もあるので,ペアは固定にするのではなく交代しながら全員ペアになれるように工夫するべきと書いてあった.関連して,ペアプログラミングの効果に関しては過去記事にまとめてある!

kakakakakku.hatenablog.com

Tip 6: Use worked examples with labelled subgoals(ラベル付けしたサブゴールを活用しよう)

プログラミングは構文を覚えれば実装できるわけではなく「どういった流れで実装するか」も重要で,入門者にとって流れを考えるのが難しかったりする.そこで,コンテンツの中に「ラベル付けしたサブゴール(ガイドのようなもの)」を追加することにより,プログラムを実装する流れを理解しやすく,また今後プログラムを実装するときにも役立てられるようになる.本論文には以下の例が載っていた.

⭕ 従来

  • [1.] "AccelerometerSensor1" をクリックします。
  • [2.] "AccelerometerSensor1.Acceleration- Changed" ブロックをドラッグします。
  • [3.] "cowbellSound" をクリックします。
  • [4.] "cowbellSound" をドラッグします。"AccelerometerSensor1.AccelerationChanged" の後に再生して接続します。

❌ ラベル付けしたサブゴールあり

  • ブロックのイベントを処理する
    • [1.] "AccelerometerSensor1" をクリックします。
    • [2.] "AccelerometerSensor1.Acceleration- Changed" ブロックをドラッグします。
  • ブロックの出力を設定する
    • [3.] "cowbellSound" をクリックします。
    • [4.] "cowbellSound" をドラッグします。"AccelerometerSensor1.AccelerationChanged" の後に再生して接続します。

Tip 7: Stick to one language(プログラミング言語は1つに固定しよう)

特に入門者はプログラミング学んでもすぐには応用できないため,学んでいるプログラミング言語を変えず,固定することが重要と書いてあった.そこそこプログラミング経験があると,構文などに違いがあっても考えながら進められるけど,入門者には難しすぎる.さらに混乱してしまうし,うまくプログラムを実装できず自信を失ってしまうこともある.

この Tips は僕自身も TechAcademy で Ruby / Rails 講師をしていたときに経験があって納得感があった.せっかく Ruby を勉強しているのにフロントエンドを実装するために JavaScript を学ぶ必要があるし,ネット記事などを読んで最近は Go なども流行っていることに気付き「全部学ばないといけないのですか?」と質問をもらうことも多かった.僕は当時から「エンジニアならテクノロジーの変化に柔軟に対応しましょう!」なんてことは言わないようにしていて,意図的に「まずは今回学んでいる Ruby に集中しましょう!」と伝えていた.本論文に載っていた「自信を失ってしまう」という側面もあるけど,個人的な経験だと「今まで Ruby を学んだ時間は無駄だったのか?」と頭を悩ませてしまう方が多かったように思う.

Tip 8: Use authentic tasks(わかりやすいお題を活用しよう)

プログラミングを実装するときのお題として,より身近に感じられる「わかりやすい(イメージしやすい)」お題を活用すると良いと書いてあった.以下に本論文に載っていた例を挙げた.「単純に数列から最大値を見つけるお題」よりは,「学校の先生が生徒のテスト結果を分析して最高点を見つけるお題」の方が,わかりやすく魅力的に感じる.プログラミングに対するイメージを「難しくて退屈なもの」から「簡単でエキサイティングなもの」に変化させることも重要と書いてあった.

  • 数列から最大値を見つける(コンテキストがないお題)
  • 生徒の最高点を見つける(コンテキストがあるお題)

個人的にはプログラミングを実装するときのお題として CodeKata を参照する機会がそこそこある.全てとは言えないけど,例えば「Kata01: Supermarket Pricing」などはコンテキストがあってイメージしやすいお題になっていると思う.

codekata.com

Tip 9: Remember that novices are not experts(入門者は専門家ではない)

「入門者は専門家ではない」というのは当たり前のことで「トートロジー(小泉進次郎構文?)」のようにも聞こえる.内容としては,入門者は専門家と同じように考えられないし,学んだ構文やアルゴリズムを思い出すだけでも難しく,一般的に「簡単」と言われるお題だとしても壁を感じてしまう.よって,生徒のレベルに適したお題や説明を意識する必要があると書いてあった.

Tip 10: Don’t just code(プログラミングだけじゃない)

最後の Tips には,プログラミングを教えるときに「必ずしもプログラミングをしなくて良い」と書いてあった.入門者にとっては,構文やアルゴリズムを組み合わせて考えるなど,経験者にとって簡単なことでも圧倒されてしまう.よって,具体例としては「Parson's Problems」を使って,プログラムを実装せずにドラッグアンドドロップで試行錯誤できるプラクティスなどを活用することも効果的であると書いてあった.Parson's Problems に関しては前回の記事にまとめてある!

kakakakakku.hatenablog.com

まとめ

2018年に発表された論文「Ten quick tips for teaching programming(意訳 : プログラミングを教えるための簡単な 10 Tips)」を読んだ.今までプログラミングを教えるときに意識していたことが正しいと確認できて良かった.また Tips 3(ライブコーディング)や Tips 10(Parson's Problems)は今後積極的に試したいと思った.

(PDF) Ten quick tips for teaching programming

Parson's Problems : 入門者にプログラミングを教えるときに使えるプラクティス

プログラミングを教えるときに使える「Parson's Problems(もしくは Parson's Puzzles とも言う)」というプラクティスを最近知った!「Parson's Problems」はコードの各行がバラバラになっていて,インデントも含めて正確に並び替えたら正解になるというパズルのようなプログラミング学習スタイルという感じ.以下に載せた parsons.problemsolving.io のキャプチャ(お題 : 数列から最大値を見つける)を見ればイメージできると思う.

「Parson's Problems」は特に入門者にプログラミングを教えるときに効果的!コードを書かずにドラッグアンドドロップで試行錯誤できて,パズルのように楽しめる.また入門者がコードを読む機会にもなる.入門者にとって,コードをゼロから実装するのは難しく,挫折する理由になることもある.そこで,実際に教育の現場でも「Parson's Problems」が活用されているのことだった.僕自身もプログラミングを教える機会があるし今度試してみようと思う.

en.wikipedia.org

Parson's Problems 関連ツール

1. js-parsons

js-parsons は「Parson's Problems」を作る JavaScript ライブラリでウェブサイトに組み込んで使える.Python をサポートしている.しかし JavaScript 実装 parsons.js は7年間も更新されてなく,継続的なメンテナンスはされてなさそう.

github.com

js-parsons のウェブサイトでは実際に「Parson's Problems」のサンプルを試せる.

js-parsons.github.io

2. Parsons Puzzle

Parsons Puzzle ではフォームにコードを入力すると自動的に「Parson's Problems」を生成できる!便利!

parsons.problemsolving.io

3. CODE PUZZLE

CODE PUZZLE もフォームに入力すると自動的に「Parson's Problems」を生成できる!実装は js-parsons を使ってるとのこと.

www.codepuzzle.io

Parson's Problems 論文

2006年に発表された論文「Parson's programming puzzles: A fun and effective learning tool for first programming courses」もあった.気になる!今度読んでみよう!

(PDF) Parson's programming puzzles: A fun and effective learning tool for first programming courses

ペアプロって本当に効率的なの? / 論文「The Costs and Benefits of Pair Programming」を読んだ

2000年に発表された論文「The Costs and Benefits of Pair Programming(意訳 : ペアプログラミングのコストと利点)」を読んだ.個人的にペアプログラミングやモブプログラミングの経験はそれなりにあって,メリットとデメリットは理解しているつもりだけど,論文としてどうまとまっているんだろう?という点に興味を持った!

発表されてから20年以上も経過するけど,今読んでも内容は陳腐化してなく,参考になるし,納得感もあった.もし,現場にペアプログラミングなどのプラクティスを導入したくても「ペアプログラミング?単純にコスト2倍で非効率!ダメゼッタイ🙅」なんて言ってくる上司がいたらこの論文を使って説得しましょう!笑

(PDF) The Costs and Benefits of Pair Programming

開発時間は 15% 増えるけど...?

本論文を読んで,まず印象的だったのは「ペアプログラミングによって開発時間は 15% 増えるけど,設計品質が向上してバグが減ることで問題なく回収できる」と書いてあったことだった.当然ながら最初はペア作業に不慣れだと思うし,阿吽の呼吸になるまではコミュニケーション面でのオーバーヘッドも増えるだろうけど,中長期的に考えれば「QA 時間 : 6週間続く地獄の QA という話も載っていた💦」を減らせるなどメリットも多くある.僕自身の実体験と同じ内容が書かれていた.

  • 設計品質 : Up ↑
  • バグ : Down ↓
  • 人員配置リスク : Down ↓
  • 技術スキル : Up ↑
  • コミュニケーション : Up ↑

プログラミングを楽しめるように!

伝統的にプログラミングは孤独な作業であると思われているけど,ペアプログラミングに慣れると,何よりも「楽しい!」と感じられるようになったと書いてあった.さらに「コードに自信が持てるようになった」とも書いてあった.定性的なメリットではあるけど,チームの雰囲気が良くなるということは何よりも重要なことで,本論文で言及されていて良かった.

コードも短くなる!

ペアプログラミングをすると同期的にレビューを行うことになり,学びながら設計品質を向上できる.また本論文を読んでいて興味深かったのは「ペアプログラミングをするとコードも短くなった」と書いてあったことで,もしかしたらペアプログラミング中に相談しながら,DRY (Don't Repeat Yourself) 原則や単一責任原則を満たしやすくなったとも考えられる.そして,初心者がベテランに対してメソッド名の typo を早期に指摘して貢献するような場面もあったという話も良かった💪

食わず嫌い?

本論文に以下のコメントが載っていて面白かった!最初トウガラシを食べると嫌いだけど「食べれば食べるほど好きになる」ようにペアプログラミングも好きになっていくという話だった.

The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you might not like it because you are not used to it. However, the more you eat it, the more you like it.

まとめ

2000年に発表された論文「The Costs and Benefits of Pair Programming」を読んだ.一般的にマネージャーはプログラマーを貴重なリソースと考えていて「リソースを無駄にすること」に消極的ではあるけど,ペアプログラミングというプラクティスを取り入れることによって設計品質を向上できて,プログラマーは今以上に楽しく働けるようになるという結果だった.本論文では以下の「8 種類の観点」で評価をしているため,興味を持ったら読んでみると良いのではないでしょうか!

  • 経済性 (Economics)
  • 満足度 (Satisfaction)
  • 設計品質 (Design quality)
  • 継続的レビュー (Continuous Reviews)
  • 問題解決 (Problem solving)
  • 学び (Learning)
  • チームビルディングとコミュニケーション (Team Building and Communication)
  • スタッフとプロジェクトマネジメント (Staff and Project Management)

Killercoda : ウェブ上ですぐに試せる Kubernetes 環境 と Ubuntu 環境

今回の記事では Killercoda を使ってウェブ上ですぐに試せる学習コンテンツを作る.前回の記事で紹介した「Katacoda インポート機能」 ではなく,以下のドキュメントを参考にイチからシナリオを作る.

killercoda.com

環境

現在 Killercoda は「3種類」の環境をサポートしている.

  • ubuntu(Ubuntu 20.04)
  • kubernetes-kubeadm-1node(Kubernetes v1.24.0 : 1台構成)
  • kubernetes-kubeadm-2nodes(Kubernetes v1.24.0 : 2台構成)

Linux 操作やミドルウェア検証など,環境を自由に使い倒すなら ubuntu 環境を使う.ubuntu 環境には Python や Go もセットアップされていてコード実装の演習環境としても使える.Kubernetes の検証なら kubernetes-kubeadm-1node 環境と kubernetes-kubeadm-2nodes 環境を使う.ドキュメントにも書いてある通り,可能なら kubernetes-kubeadm-1node 環境を使う.

ディレクトリ構成

今回は以下のディレクトリ構成でコンテンツを作る.index.json には設定を記述して,Markdown にはコンテンツを記述する.

.
├── kubernetes-1node
│   ├── finish.md
│   ├── index.json
│   ├── intro.md
│   └── step1.md
├── kubernetes-kubeadm-2nodes
│   ├── finish.md
│   ├── index.json
│   ├── intro.md
│   └── step1.md
└── ubuntu
    ├── finish.md
    ├── index.json
    ├── intro.md
    └── step1.md

GitHub リポジトリにコンテンツを push すると Webhook で自動的にデプロイされる!便利!

kubernetes-kubeadm-1node 環境を試す

まずは kubernetes-kubeadm-1node 環境を試す.index.json は以下のように書く.ポイントは backend.imageid でここに環境名を設定する.details.steps は配列になっているため,複数ステップを含めることもできる.

{
  "title": "playground-kubernetes-1node",
  "description": "playground-kubernetes-1node",
  "details": {
    "intro": {
      "text": "intro.md"
    },
    "steps": [
      {
        "text": "step1.md"
      }
    ],
    "finish": {
      "text": "finish.md"
    }
  },
  "backend": {
    "imageid": "kubernetes-kubeadm-1node"
  }
}

具体例として step1.md を以下のように書く.{{exec}} 構文を使えばコマンドをクリックで実行できる.

# step1

ノードを確認します。

`kubectl get nodes`{{exec}}

nginx Pod を起動します。

`kubectl run nginx --image nginx:1.21`{{exec}}

Pod を確認します。

`kubectl get pods`{{exec}}

実際に動作確認をすると Kubernetes v1.24.0 を使えるようになっていた.Pod を起動したり,基本的な操作はできそう.

controlplane $ kubectl get nodes
NAME           STATUS   ROLES           AGE   VERSION
controlplane   Ready    control-plane   75d   v1.24.0

kubernetes-kubeadm-2nodes 環境を試す

次に kubernetes-kubeadm-2nodes 環境を試す.同じように index.json に kubernetes-kubeadm-2nodes を設定する.

実際に動作確認をすると Kubernetes v1.24.0 で controlplane ノードと node01 ノードの2台構成になっていた.

controlplane $ kubectl get nodes
NAME           STATUS   ROLES           AGE   VERSION
controlplane   Ready    control-plane   83d   v1.24.0
node01         Ready    <none>          83d   v1.24.0

ubuntu 環境を試す

最後は ubuntu 環境を試す.同じように index.json に ubuntu を設定する.

実際に動作確認をすると Ubuntu 20.04 だった.

ubuntu $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

また Killercoda はどの環境にもデフォルトでエディタが同梱されている.VS Code に似ている Theia が同梱されていて,IDE でコードが書けるのは便利!

まとめ

Killercoda で現在サポートされている「3種類」の環境でコンテンツを作ってみた.ウェブ上ですぐに Kubernetes を試せるのは特に初学者にとって便利だし,エディタも同梱されているので,Ubuntu 上でコード実装をするのも便利!消す可能性はあるけど,今回作ったシナリオは以下で試せる.

killercoda.com

関連記事

その他シナリオサンプルは GitHub に公開されている!

github.com

Katacoda インポート機能に関しては以下の記事にまとめてある!

kakakakakku.hatenablog.com