エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

子供がプログラミング教室に通い始めまして。

この記事は、子育てエンジニア Advent Calendar 2023の6日目の記事です。

こんにちは。Webサービスの開発マネージャをしております。
私には8歳(小2)になる長男と、3歳の次男がいます。
今日は、長男がプログラミング教室に通い始めた話を書きたいと思います。

きっかけ

きっかけは、長男の、某・有名小学生向け通信教育のプログラミング教材でした。国語や算数がメインの教材ですが、昨今は小学校でのプログラミング教育をするということで、プログラミング教材(タブレットで実施する)がついていたのです。
Scratch状の文法・UIで、キャラクターに対して「前に進む」、「右に曲がる」などの命令を並べてゴールまで誘導するものでした。(低学年向けだったので、分岐やループもまだなし)
そして、4-5ステップ程度のブロックを「正解通り」に並べるとキャラクターが動く一方、「正解通り」でなければ、

「あれれ~」

という声が流れて何も動かない。というものでした。
この仕様が私は大変不満でした。

プログラムを学ぶ時は、とりあえずお手本を写経してなんとなくの文法を学び、その後「自由な発想で定数を書き換えてみたり、処理を足してみたり、順番を入れ替えたりしてみて」徐々に学んでいくものだと思います。
「『間違った挙動』をさせられない」なんて、なんとつまらない教材か!

と感じました。
一方で、長男自身はプログラミングに興味があるようでした。もしかしたら私の職業も関係していたのかも知れません。
せっかく息子が興味を持っているのになんともったいない、「おれが本当のプログラミングってやつを教えてやるぜ!」*1と考えました。

なお、そもそも前提として、私自身は現時点で息子に、「プログラムを書けるようになって欲しい」ということは求めていません。
あえて比較するなら、それより水泳教室に通って泳げるようになってくれたほうがいいなと思っています。
一方で、ソフトウェアは何ができて何ができないのか という間隔はぜひ身につけてほしいと考えていました。ソフトウェア・プログラムがどういったものであるかを理解することで、今後むやみやたらに『AI』を恐れること・過大評価することや、逆に「エンジニアは魔法使いで何でもできるといった感覚を持つこと」を避けてほしいなと考えています。

教室探し

教室の選定に当たっては、妻*2が、何件か候補を選んでくれ、私が息子と一緒に体験入学してきました。
4件ほどお伺いした中で、最終的に現在の教室に決めさせてもらいました。

(恥ずかしいので具体的な校名は避けさせていただきます…が)決め手となったのは

  • マンツーマンではなく、他の子との交流があること。どうせ通うなら、知り合い・友だちを作ってほしかった。
  • 教材が、エンジニアによって作られたものであり、エンジニア目線で作られていること。*3
  • カリキュラムの中に、「その技術が現実世界で何に使われているか」という要素が、(ちょっとだけですが)含まれていて、学んでいることと現実を繋げてくれること
  • 隔週ではなく、毎週教室があること

でした。

入ってみてどうなった?

始めてから半年弱が経過したのですが、親としてはとても満足しています。

  • 息子が非常に興味を持ってくれていて、毎週楽しみにしている
  • とはいえ、「お勉強」なので気分が乗らないときもある。毎週教室があり、また、多少の宿題もあるおかげで、習慣化して継続的に続けられている
  • 息子が、分岐、繰り返し、変数、関数などの一通りの考え方を理解してくれた。これがわかってれば大体のプログラムは本質的には理解できる
  • 程よい難易度。普通に動かすことはできるんだけど、「Sランク」を取るためにはステップ数をギリギリまで削る必要あるという要素がある。
  • そのためには、重複コードをやめて繰り返しにするなどの工夫が必要なのだが、これがパズル状で難しく、息子から相談されたお父さんのほうがウンウンうなりながら図を描いて考えていることがあります。
  • (元々期待していたわけではなかったが)毎月、自分の作った作品をプレゼンテーションする機会がある。少々のプレゼンスキルの育成をしてくれる。
  • (元々期待していたわけではなかったが)タイピングを教えてくれる。ホームポジションや、指とキーのマッピングを教えてくれる。
  • 毎週、生徒一人ひとりの受講内容、様子に対してレポートをくれる。(一日に10名程度は受けているようなので、作業量がやばい… 本当に尊敬)


ということで、特に「一流プログラマーになってくれ!」とか「親父の後をついで君もエンジニアに!」などとは全く思っていないのですが、
今後もプログラミングを楽しんでくれるといいなと思います。

*1:そもそも教室など通わずに私が教えればいいのでは? という考えもありましたが、親子間で何かを教え続けるというのは、双方に相当の根気が必要になります。

*2:彼女は「ごく普通の人」なので、プログラムは全くわからない

*3:具体的にどこが? って言われると難しいのですが、冒頭の用に「プログラムを知らない人がプログラムの教材を作れと言われて作りました」感がありませんでした

CookieのSameSite属性は何を持って「同じサイト」と判断するのか…と思ったら、びっくり手運用だった

CookieのSameSite属性。
そもそも何を持って「SameSite」と判断するのか、サブドメインをつけただけで別サイト判定されると困るなぁ…
なんて今更思っていたのですが、
結構な手運用で「ここまでがPublicなドメイン」な運用をされていることを知ってびっくり。

blog.jxck.io

迷ったら帰る場所 「『テレビを作りたかった』自分」

一年半ぶりの記事が全然技術ネタじゃないのですけども…。

自分がなぜ今その職についているのか、ふとした時に思い出せる、「帰る場所」を持っているのは大事なことだと思う、という話です。


かの大捕手、野村克也氏はよく仰っておりました。
「迷ったら原点、外角低めに投げるのだ」と。

この話と同じかどうか…は怪しいところですが、
毎日仕事してればいろんなことがありますよね。嫌なこと、辛いこと、思い通りに行かないこと、テンションの上がらないこと、失敗したこと…
そんなときに、「あ、そういえば自分はこれがしたくて今の仕事についていたんだった」と、ふと思い出す、『原点』を自分の中に持っておくことってとても大切だと思うのです。
いつもいつもその『原点』は覚えていなくてもいいんだけど、ふとしたときに帰れる場所が持てるといいですよね。


私にとっての原点は…すでに以前書いているのでリンクだけ張って割愛。
taichiw.hatenablog.com

「子供に『このテレビはお父さんが作ったんだよ』っていう」という、おぼろげな夢というかイメージ。
これが自分の原点になっています。

ブラウザがCSSキャッシュしてしまうのを止める方法

CSSに限らないのですが、こんな感じでブラウザはダウンロードしたコンテンツをキャッシュする機能を持っています。
f:id:taichiw:20200724210451p:plain
200 OK とか言ってますが、サーバに何らかのリクエストを投げることすらしていないわけですね。

これが過剰に効いてしまうと、HTML/CSSを修正したのにCSSだけキャッシュが使われてしまって思いっきり画面が崩れてしまう…なんてことが起こり得ます。

これを解消する方法としてよく紹介されているのが、

<link rel="stylesheet" href="hoge.css?ver=20200724">

こんな感じでCSSのURLに適当なクエリストリングをつけ、変更のたびにパラメータを変えていくというもの。

しかしこの方法ですと、単にCSSを差し替えたいだけでもHTML側を修正しなくてはならず、HTMLをプログラムで生成しているような場合には「プログラムのリリース」が必要になってしまいます。
サーバ上でCSSファイルのタイムスタンプを取得してパラメータにする… というのも見つけたのですが、これではアクセスがあるたびに(ちょっととはいえ)ファイルI/Oが発生してしまうので、システムにあまり優しくなさそうです。

で、今更ながら調べていたところ、
HTTP responeヘッダのCache-Controlを使えばキャッシュ期間が指定できること、
および、Apacheの場合はmod_expiresを使えばCache-Controlを返せるようになることがわかりました。

実際にやってみた

apacheのconfファイル。試しに1秒でキャッシュが切れるようにしてみます。

LoadModule expires_module modules/mod_expires.so

...

<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 second"
</ifModule>

f:id:taichiw:20200724212108p:plain
Cache-Control ヘッダが返るようになりました。

f:id:taichiw:20200724212236p:plain
ちゃんとサーバにアクセスした上で、304を受け取っています。

Windowsでsshしてターミナル作業してるときに「テロン」「テロン」ってうるさい音を消す

基本的にオフィスではPCの音は全消ししてたので、いままでは気にしてなかったのですが、
世の中はすっかり在宅勤務時代。

同僚の方とZoomなどでつないで、時にはサーバに入って作業している状況をシェアすることも増えました。
そのときに… tabキーで補完をするたびに「テロン♪」「テロン♪」 ってうるさーーーーい!!


ググってもググっても ぴったりなものが見つからなかったのですが*1……


やっと見つけました!
infotech.hateblo.jp

「一般の警告音」をオフにすることによって、止められました-!

*1:Bash on Windowsでビープ音を消す というのは見つかるのだが、これで止められるのはローカルでターミナル作業しているときだけで、サーバ上だとダメポ

SRE Lounge #12 に参加しました!

やったこと

こちらに参加しました!
sre-lounge.connpass.com

今回は、オンライン参加でハードルが低かったこともあり、運用に近いところをやってくれている、これからやろうとしてくれているメンバー2人を誘って一緒に参加しました。
セッション中は、Twitterでワーワーいうのもやってたんですが、同時に、社内のMS Teamsで、セッションの内容を自分たちの事例に置き換えながら雑談する、というのも並行してやってました。

分かったこと

  • NewRelicのブログすごい。ボリュームが凄くて読みきれないけど、リンクとして残しておきたい…のでメモ。

あとは要所要所「なるほど!」とか「そうだよね!」ってのがあったのですが、twitter.com
自分が門外漢だからなのかな、いまいち消化しきれませんでした。

それよりも、途中途中、
自分たちの部署の事例に置き換えながら、3人で雑談してたのがなかなか楽しかったです。
「この3人で話すのか」っていう、ちょっとレアな組み合わせだったのもあって新鮮でした。

部署内のパブリックなチャネル*1で会話していたので、このやりとりが、誰かの目には止まってたかも。

次にやること

常々、みんながもっともっと自主的に勉強するエンジニアを組織を作りたい、勉強会とかバンバン行ってほしい…と思いつつ、
自身が背中を見せられていない不言不実行状態が続いておりました。
そういった意味で、今日はとても楽しい時間でした。
特に都内はまだまだオンラインでの勉強会が続くかな…?と思いますので、
積極的に周りのメンバーを誘って、また他の勉強会に参加し、部署内に雰囲気を作っていきたいと思います。

*1:勉強会などについて語る専用のチャネルです

守備には3種類あると思った

今、自分の中では世紀の発見をしたくらいのキモチになってまして、忘れないように書きとめておこうと思います。
多分後で読み返したら「なにを当たり前のことを言ってるんだ」って感じだと思うんですけど。

その昔書いたこの記事のように、サッカーだったり剣道だったり、時々野球だったりをイメージしてるんですが、団体競技でも個人競技でも何かしら攻防のある、お好みのスポーツをイメージしてもらえれば意味は通じる…と思います。多分。
ログイン - はてな(仕事の話です)剣道とサッカーと交渉ごとって似ていると思うんですよ - エンジニア的なネタを毎週書くブログ

さて、その上でタイトルに書いたとおり、「守備には3種類ある」のだと思い至りました。
1. 相手の攻撃を止める守備
2. 相手の攻撃を止めた上で攻撃に転じる守備
3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

1. 相手の攻撃を止める守備

サッカーであればとりあえずシュートを止めるとか。自陣内で相手からボールを奪うとか。
剣道であれば打ってきた面をとりあえず竹刀で受けるとか。
相手がポイントを取ろうとしてきた攻撃をなにかの方法で防いで、失点を0にする、最も直接的な守備です。

2. 相手の攻撃を止めた上で攻撃に転じる守備

1.で相手の攻撃を止めた上で、その機を逃さずに攻撃に転じることです。狭義では「守備」ではないかもしれませんが、
相手に攻撃を仕掛ける → 相手が守りに転じる → 相手の攻撃の機会を奪う
となり、結果的に相手に攻撃させない、広義での「守備」となります。
スポーツで言えばカウンターが相当すると思います。

3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

1.は相手の攻撃に対して応じた動き、2.はそこで終わらずにそこから攻撃に転じることによって相手の攻撃機会を減らすアクションでした。
3.は、よりこちらから働きかけていく守備です。
右サイドを固めておくことで左側へ誘導する…といったことです。

システムの「運用」も同じ!

ここまで、一体何の話が始まったんだ!? という内容をお送りしてまいりました。
システムの開発/運用における「守備」とも言える運用においても、同様に3つの守備 が定義できると思います。

1. 相手の攻撃を止める守備

とにかく被害を出さないアクションです。
トラブルが発生しているのであれば復旧する、バグがあるなら直してリリースする、期日までに終えないとサービスに問題がある作業があるのであれば終える。
などです。
流通など、実際のサービスへの影響が起きない、または置きても小さくて済めば成功と言えると思います。

2. 相手の攻撃を止めた上で攻撃に転じる守備

1.で被害を出さなかった上で、1で起こるような問題の原因を潰しに行くようなアクションがこちらです。
手順がまとまっていないオペレーションが原因でトラブルが起きやすいので再発防止のために手順書をちゃんと書く とか
SQLに不慣れなメンバーが多くてバグが多いのでSQLを勉強してもらう とか
何か能動的なアクションを起こすことによって、これまで発生している問題を潰しに行くのが2です。
一見、次の3.のようにも感じますが、
何か悪いコトがまず起こり、発生した問題に対応するなにか施策を行う
というアクションですので、2.です。

3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

では3.は何かというと、そもそもまだ発生していない問題を察知し、先に潰しに行く というアクションです。
例えば、

  • トラフィック増に伴って検索処理の性能劣化が見られるので、システム増強しておくことでトラブルを未然に防ぐ

など、まだ問題の形にすらなっていない種を発見し、潰しにかかるのがこちらです。