Skip to main content

Posts

Showing posts from 2022

必要性が優先度を決める

つい最近、知り合いに頼まれて、学生向けに自分の過去の経験などを語る機会があった。 個人的にはそう言った機会はあまり好きではない。 なんというか、自分がどういう人間であれ、学生という身分から見ると経験の差が圧倒的で、ともすると、その人がどうすごいのかといったことをあまりよく吟味できずに、いろいろな物事を鵜呑みにし、その上で、定型句のように「貴重なお話、ありがとうございました」と言う。 そして、語ったこちらもまたその言葉を鵜呑みにし、自分の話す内容は価値があり、非常に有用であった、という有能感を必要以上に感じてしまう、自分の力を過信してしまう。そういう側面があるように思っている。 が、まあ、1年に1度くらいならいいかなと思って引き受けてみた。 そこで話の中に盛り込んだ内容は次のようなもの。 フィードバックの受け方(最近研修で自分が習った) Do the right thingsとDo the things right(DeNAの南場さんの話) GRIT(という名の根性) Lerning How to Learn(という魚の釣り方) EQにおける4象限の話(自分と他人、認識と管理) 幸福と成功の話(ドラマ監査法人の名台詞) まあよかったかどうかはわからないから一旦置いておくとして、自分自身の振り返りにもなってよかった。 TDDで有名な和田さんがよく同じ資料を、2022年春版、のようにブラッシュアップして話しているのを見るけれど、あれと同じように、一定のテーマで話す時、積み上げたものをブラッシュアップする形で用意できると過去の考えとの気付きとかもあって良さそうだなとも思うので、その第一歩として今回みたいな機会があったのはよかったなあ。 学生向けに話した中で、キャリア理論で有名な、Planned Happenstance Theoryという考え方について触れた。というか触れることを資料準備で決めていた。 のだけど......予備知識として、Planned Happenstance Theoryで触れられている要素は最初期で語られているもので、その後は理論が発展していて、Happenstance Learning Theoryというものでより強調したい点が強調されているというところまでは知っていて、関連する論文も取り寄せていた。が、積読になること数か月以上が経過していた。 相手

昔を振り返る

知人からの紹介を受け、現大学3年の学生さんと1on1をした。 自分が話したことをメモしておく。 ゼミ活動について 過去にしたことを話した。 当時考えていたことは、特に前半は、いかに効率的に学習を進められるかということ。 それから、怠惰は罪、ということで、懐事情が厳しいメンバーの実情を理解した上で、遅刻したら課金が発生するような制度を運営していたことを思い出す。 そして、それは思い返すと誤りだった、という話をした。 その当時、指導教授から「勉強は一人でもできるがチームでしかできないこともある」といった趣旨のことをコメントとしてもらっていた。 ただ、それが当時は腑に落ちておらず、期限通りに進めてこない人の存在に苛立ちを覚えたりしていた気がする。 課金についてもそう。有名な話で、保育園のお迎えに遅れる母親たちをどうにかしたい思いから課金制度を導入したところ、お迎えに遅れる人はむしろ増えてしまったということがあったというのは有名。 内発的動機付けと外発的動機付けの話で、課金が発生させられる場合、逆にお金を払えばいい、という気持ちになってしまって、間に合うか間に合わないかという状況の時に急がずお金を払って解決するという方向に進んでしまったのだとか。 ゼミ活動はコミュニティ活動の一種で、その中には必ずと言っていいほどやる気のある人もいればやる気のない人もいて、自分の思う通りには必ずしも動いてくれないというのが現実だと今ならよくわかる。 それを前提にすれば、そのような引き締めではなく、来てくれるとどう助かるのか、どうしてそのような協力が必要なのか、などについて滔々と話すのがとるべき道だったのだろうなあと思う。 メンバーがうまくついてきてくれない感じがする、ということで、自分の意見が通りやすい状況になってしまっている(メンバーが無関心、同じレベルでの関心を持っていない)という話も出た。 そこについては、心理的安全性の話と裸で踊る男の話をした。 メンバーが心理的に、現在のコミュニティの中で安全だと感じることができていないかもしれないので、そういう観点で改善できることはないか探ってみるのは大事だという話。 それから、裸で踊る男の話は、どうにか協力を引き出そうとしても実は結構難しいので、引き出すのではなく、思わず参加したくなるように仕向けるのが必要かもしれないという話をした。 コミュニテ

Twitter APIをcurlで呼び出す場合のSignatureの生成

学習の一環として、Twitter APIを既存のライブラリなどを使用せずにLow Level(curlなど)で呼び出して実行していた。 このときに些細な点で1-2時間ほど時間を溶かしてしまったので記録しておく。 先に3行でまとめておくと CLIなどコマンドベースでTwitterの認証トークンを使用する場合はPIN Based OAuthを使う 取得したKeyやTokenを使用する場合にはSignatureと呼ばれる、データの完全性を保証するためのHMAC-SHA1形式の暗号データを作る必要がある これをコマンドで作る場合には echo -n "value" | openssl dgst -sha1 -binary -hmac "key" | base64 のようにする 使用するAPIとドキュメント 基本的には公式ドキュメントを読めばできる、とまでは言えないが、できるちょっと手前まではそれなりにしっかり書いてあった。 今回主として見る必要があったのは次の4つ。PINベースの認証の中で後の3つのAPIをそれぞれ呼ぶ。 PIN-Based OAuth developer.twitter.com POST oauth/request_token developer.twitter.com GET oauth/authorize developer.twitter.com POST oauth/access_token developer.twitter.com アクセストークンを取得するまでのつまづきポイント 少しつまづいたのはcurlでのURLの記載方法。 call_backにoobを記載すれば次のステップの時にリダイレクトされない、と書かれていたのだけれど、実際にはリダイレクトされてしまって困った。 最終的には、URLを""で囲むことで正しく処理されたのだけど、そこは正しく解釈されるだろうと思い込んでしまっていたのが盲点だった。 curl --request POST \ --header "Authorization: Bearer AAAAAAAAxxxxxxxx" \ --url "https://api.twitter.com/oauth/request_token?oa