とりあえず書いてみます

興味がある事や考えなどとりあえず記事にしてます。

仕事に活かしたい!「超集中ハック」を読んでみました

先日京都ハンナリーズの応援で千葉ジェッツとの試合を見に行き、声がガラガラになってしまったオビーです。

 

最近捌けている仕事の量が少ないなーと感じることがあったので本屋さんで「超集中ハック」という本を読みましたのでそのメモ書きです。

※自分の為の備忘録として使っています。。

やっぱり本読んでも一度じゃ覚えきれないですよね。。。汗

 

  • パーキングロット
    • 作業に関係ないやる事が頭によぎったら紙にメモで残しておく事で作業を止めずに続けれる
    • どうしてもするなら無意識でできるレベルまでする
    • 工程チェック表をつくりどこまで進んだか残す
  • 読んだ本を忘れないために
    • 記銘集中をする
      • 読んだ情報を取り出し深く考える
      • リトリーバル学習
      • 読んだ本にたいして
        • 「筆者はこう言ってるが本当にそうなのか?自分なりに整理しよう」
        • 「本に書いてる方法を仕事に活かす方法はないか」
          など考えながら読む
    • 25分実施 5分休憩を4回繰り返し20-30分休憩する
    • これで集中を維持できる
  • 単純な作業でもフロー状態で集中する
    • 単純な作業に関しても自分で挑戦レベルを高めてやってみる
    • 内容にこだわる、時間を決める、など何か挑戦レベルを高めて作業してみる
  • タスク管理のGTD(Get Things Done)
    1. 頭に浮かんだすべてのタスク候補を書き出す
    2. 今やらなくていいタスクを削除(絞り1)
    3. 2分以内にできるタスクはすぐに処理してリストから削除(絞り2)
    4. 人に任せられるものはまかせてしまいリストから削除(絞り3)
    5. 残ったものだけをToDoリストに記載
    6. 不安や焦りを感じたら上記を実施し、取り除く
    7. タスクの一つ一つに所要推定時間を記入する
  • メールはすぐ返さない
    • 今すぐにやる必要がない事が多い為90分に一度など時間を決めて実施して作業の手を止めない
  • 疲れて来たら身体をゆする
    • 貧乏ゆすりなど効果があるが周りに注意
    • 立って作業することもいい
  • 気分を変えて別の場所で作業する
  • 気分が乗らないときは1分だけすると決めてやると続くことが多い
    • 簡単なタスクだけしてみるなど
  • 一先ず7時間睡眠を目指す
  • いつも同じで判断疲れをなくす

 

読んだ本に対して「本に書いてる方法を仕事に活かす方法はないか」って読むのは個人的に

一番おすすめな気がしています。

 

PS:

京都ハンナリーズのホームゲームは9割ぐらい参加していますが、お金がかかるなーと感じます。。。

でもその分、楽しみが増えるので仕事とお休みとのメリハリがついていい感じです!

 

パズルのようなプログラミングの醍醐味

今年初めて紅白を最初から見ているオビーです。

 

今年の初めに勢いで始めたブログですがめっちゃ飛び飛びですが30記事ぐらいは投稿できました。。

 

最近paizaというサイトでプログラムのスキルアップができるということで前からAtcoderなど気になっていたのですが今回初めてpaizaを利用してみました!

↑こんなやつですね!

 

Bランクの問題解いただけですが頭の体操にはなる感じがしています。

今度AランクとかSランクとかチャレンジしてみようと思います。

 

まだBランクしただけでの所感ですが、これができると仕事でプログラムが書けるか?と言われたらどうなんだろう?って感じの印象は受けましたが

仕様通りに実装はできるのかな?という感じはします。

あと、頭の中でやりたいことがわかっていたらコード書ける力はつく気がします。

 

業務で書く際に1ファイルに全部書くことは少ないなと思います。

DDDとかクリーンとかオニオンとかあると思いますがそのチームでの書き方に沿って書くというのがあるので冗長でもあえて長く書いたりしたりもあってその時によるなと感じます。

 

とは言っても結構パズルみたいでやるのが面白いのでこれからも続けてみようと思いますー!

 

PS:

来年からは京都ハンナリーズをめっちゃ応援していきたい!

来年もよろしくお願いします!!

HTTP/3までの歴史

先日京都ハンナリーズ 対 宇都宮ブレックスのGAME1に観戦行き声がガラガラになったオビーです。

 

HTTP/3までの歴史

最近積んでて読めてなかったソフトウェアデザインの本読んで行っています。

個人的に最近流行っている情報などはサイト見たりブログみたりするのですが

ソフトウェアデザインもお金払って読むということで定期的に情報を仕入れることができて購読しています。

その中でHTTP/3までの歴史的な記事があったので覚えながらメモ書きしたので勉強のために残しておきます。

iPad買ってから本読みながらメモ残すの楽になった気がします。

 

HTTP/0.9

  • リクエストとレスポンスはシンプルなものGETメソッド以外はなかった

HTTP/1.0

  • HTTPヘッダーフィールド
  • HTTPメソッド(HEAD、POST)
  • 課題
    • 1リクエスト1レスポンスのやり取りでTCPコネクションを閉じていた
    • リソースの数だけ3ウェイハンドシェイクが発生する

HTTP/1.1

  • Keep-Aliveが追加されTCPコネクションを使い回せるようになった
  • 同一ドメインに対するリクエストではTCPコネクションを使い回す挙動がデフォルトになった
  • 上記の理由でオーバーヘッドが解消
  • 課題
    • Webコンテンツがリッチになった事によりドキュメントに含まれるリソースが多くなったことでコンテンツの表示速度が問題となっていた
    • 1.1では順番にリクエストとレスポンスを処理されるため後続のレスポンス待ち時間が発生してしまっていた
    • 上記をHTTPレイヤでのHead-of-Line Blockingと呼ばれていた
    • 並列に処理をしようとTCPコネクションを分けた場合にサーバ側のリソースが食いつぶされてしまうため、主要ブラウザはTCPコネクションの接続本数を制限していた

HTTP/2.0

  • Googleによって開発されたSPDY(読み:Speedy)というプロトコルをもとに2015年に発行
  • HTTP/1.xとの互換性がなくなったため2とメジャーバージョンが上がった
  • 特徴
    • ストリームによる多重化
    • 優先度制御
    • フロー制御
    • 擬似ヘッダフィールド
    • HTTPヘッダフィールド圧縮
    • サーバプッシュ
  • ストリームによる多重化により1.1で発生していたHTTPレイヤでのHOL Blockingを解決できるようになった
  • 1ストリーム(1Req:1Res)となりストリームIDをもとに順不同で送ることができるように
  • ストリームに優先度をつけることで重要なリソースを先に送れるようにもなった
  • 課題
    • 実際に常に2%のパケットロスがある非常に低品質なネットワーク環境ではHTTP/1.1の方が性能的に優れているという報告もあった
    • プロトコル変更に基づいて正しく拡張されたフォーマットパケットであってもフォーマットに対応している場合は、異常とみなされる場合がありパケットが破棄されたり通信遮断されたりすることがある
    • 高速化する工夫がされたが優先度制御が難しくブラウザ実装にばらつきがあるといった問題があった
    • TCPレイヤでのHOL Blockingの問題は残っている
    • TCPレイヤのHOL BlockingとはTCPレイヤで、あるパケットの到着が遅れたり、パケットロスしてしまったり後続のパケットの処理待ち時間が発生してしまう問題
    • プロトコル硬直化という問題

HTTP/3

  • HTTP over QUICという名前で策定が進んでいる
  • QUIC(Quick UDP Internet Connection)とは
    • UDPを使用し、TCPより高速な接続を提供
    • パケットは暗号化されている
    • ユーザースペースでの実装になっている為短い頻度でバージョン更新される
  • 特徴
    • QPACKとはHTTP/3で使用される圧縮アルゴリズム
      • ヘッダー圧縮
      • ハフマン符号
      • インデックステーブル
      • リセット機能
    • Round Trip Timeとはデータが送信元から宛先に到達しそれが宛先から送信もとに返ってくるまでの時間を示す通常RTTはm秒単位で測定される
    • ストリームによる多重化やTCPが担っていたコネクションはQUICに任せるようになった
    • 優先度制御はHTTP/3が対応
    • TCP HoL Blockingが発生しない
    • 暗号化が必須
    • コネクションマイグレーションが可能
    • ヘッダ圧縮にQPACKを利用
    • O-RTT(Round Trip Time)もしくは1-RTTでハンドシェイクが完了
  • HTTP/3が有効なケース
    • コネクションのマイグレーションが必要になるケース
    • 電車や新幹線など頻繁にアクセスポイントが切り替わったりするような場合など
  • UDPになったことで機能が不足する部分についてはQUICで制御する
  • HTTP/3の暗号化必須部分についてはQUICに内包されるTLS1.3で担当される
  • 暗号化必須となった背景
    • TCPで担っていたトランスポート層における問題をTCPを改善するというアプローチではなくUDPUDPで不足する部分をQUICで担当するように改善したことが理由
    • UDPを利用しないといけないというデメリットが生まれたがHoL  Blocking問題やハンドシェイクのオーバーヘッドがかさむ問題は解消された
  • パケットロス時の再送制御をQUICで行う
  • HTTP/3はUDPを利用するためUDP443ポートを解放する必要がある
  • コネクションマイグレーション
    • 通信相手のIPやポート番号が変化してもセッションを継続できる機能
  • 利用してもらえるために
    • alt-sec: h3=“:443”
    • Alt-SvcヘッダでHTTP/3で接続可能なことを追記
    • DNSHTTPSリソースレコードにHTTP/3が利用できる旨記載する必要がある
  • 課題
    • UDPポートを解放することでUDP Flood攻撃に対して脆弱な面がある
  • メリット
    • オーバーヘッドの削減による接続開始時のパフォーマンス向上
    • パケットロス発生時のパフォーマンス低下の防止
    • QUICとTLS1.3の連携によるセキュリティの向上
  • デメリット
    • UDPを利用することによる新たなDoS攻撃リスク
    • UDPという新しい技術スタックを利用するリスク
    • 適切な設定をしなければクライアントがHTTP/3で接続してもらえない

 

本当にメモ書きです。書いていきながら覚えようと思ってまだ覚えれていないですが

自分のブログを自分の勉強用のためにアウトプットも兼ねて利用していこうと思います。

 

PS:

GAME2も京都かたおかアリーナに観に行くので楽しみです!勝って欲しい!!

愚痴はチームのことを気にかけている証拠

ブライトンの三苫選手が復帰し出して一段と試合見るのが楽しみになオビーです。

 

前回の続きで「世界最高のチーム」という本を読んだので忘れないうちにメモ

愚痴はチームのことを気にかけている証拠

マネージャーは愚痴の中に「チームの改善に役立つメッセージが含まれている」と考えて「チームをよくするチャンス」と歓迎するべき
例:
残業しているときに
メンバー:「面倒くさい」
マネージャー:「もっと早く帰りたいんですね?」
メンバー:「当然じゃないですか!!」
マネージャー:「じゃあ今度チームミーティングで残業時間と仕事内容を見直してどこがボトルネックになっているか話し合って見ましょう!」
メンバー:「わかりました」
マネージャー:「じゃあこのミーティングはあなたがリードしてください。私がサポートするから!」
メンバー:「わかりましたやってみます」
一緒にやろうよという前向きな提案になるように話し合う
「よく言ってくれたありがとう」と言った感謝の言葉でしめる
 
など本でありました。
愚痴を前向きな提案として捉えて行動するというのはなかなか難しいなとも感じますが
こういったことをメンバーと会話できることでチーム力が向上するんだなとも感じますので意識していきたいです!
 
PS:
ブライトンの試合が平日深夜に行われると寝不足になってしまうなと感じます。。
でも試合見ているのが楽しいので勝ったりしたら逆にハイになってしまいますね。

良いチームには「心理的安全性」が欠かせない

京都ハンナリーズが3連勝して嬉しいオビーです。

 

「世界最高のチーム」という本を読んだので忘れないうちにメモ

良いチームには「心理的安全性」が欠かせない

「生産性の高いチームの特性」とは次の5つ
  1. チームの「心理的安全性」が高いこと
  2. チームに対する「信頼性」が高いこと
  3. チームの「構造」が「明瞭」であること
  4. チームの仕事に「意味」が見出していること
  5. チームの仕事が社会に対して「影響」をもたらすと考えていること
心理的安全性の高いチームなら「自己認識・自己開示・自己表現」ができる
端的に言えば「メンバー一人ひとりが安心して、自分が自分らしくそのチームで働ける」ということ
自分らしく働くとは「自己認識・自己開示・自己表現ができる」ということ
要は「安心してなんでも言い合えるチーム」
 
心理的安全性があればメンバーを信頼できるようになって、尊重するようになる。
 
GE(ゼネラル・エレクトリック)では従来の評価制度を全部やめた
なぜなら評価を気にする事自体が社員の心理的安全性を損なう為

 

価値観ベースの会話で心理的安全性を高める

「ライフ・ジャーニー」
A3の紙に自分がどんな人生を歩んできたのか、
ターニングポイントにおける「1:行動 2:その意図 3:味わった感情」がわかるように具体的に書いてもらう
書式は自由、描き終わったら4分程度みんなに説明してもらう
→これにより「知らなかった」「面白い人生だね」「苦労したんだね」といった会話が生まれる
ファクト(事実)ペースではなく「価値観ベース」「信念ベース」
心理的安全性を高めるためにはこうした会話「本音」を言い合うことがとても大切
 
「目の前にいるメンバーを人として承認することなしに、チームの心理的安全性を高めることはできない」
メンバー一人ひとりをそのまま人として承認することが大事
それがなければ1on1でどんなにいい質問してもメンバーは決して心を開かない
きちんとメンバーを見ること。

 

心理的安全性というワードは本当に良く聞くなと感じます。

メンバーを人として承認することというのは、ほんまに大事だなーと思います。

 

PS:

バスケW杯以降Bリーグを見るようになりましたが、身近に応援できるチームがあるのは毎週の楽しみが増えていい感じです。

いつか遠征も行ってみたいな。

 

 

LambdaでOpenAIのAPIを使ってLINEbotを作ってみた

こんにちは

ChatGPTのプロンプト色々と調べて質問するのに最近ハマっているオビ―です。

はじめに

LINEbotですぐに質問できる自分だけのChatGPT的なの作れたら面白いなーと思って試してみた記事です。

自己満足で作成した内容を忘れないうちに記事にしているのでロジックがイケていないだとか、やりかたブサイクだとかめっちゃあるかと思いますが優しい目で見てもらえたらうれしいです!

作ったのは下記です。

前提

各サービスのアカウント作成方法などは詳細に書いていない為、適宜調べながら作成お願いします。

利用するサービス

1:OpenAIのアカウント作成

OpenAI API

上記でアカウント作成してから下記にアクセスし「SEACRET KEY」を取得

Account API Keys - OpenAI API

2:LINEDeveloperのアカウント作成

LINE Developers

上記よりアカウントを作成しておく

3:AWSのアカウント作成

アマゾン ウェブ サービス(AWS クラウド)- ホーム (amazon.com)

上記からアカウント作成

手順

早速作っていきます。

1:PythonのOpenAIモジュールを落としてくる

pip install openai

インストールされたモジュール群を「python」フォルダ作成してそこに移動させてzipで圧縮

2:Lambdaのコード作成

Lambda→関数作成→Pythonで作成

※python3.8で作っていました。

関数名は任意、下記コードをコピーして貼り付ける

import logging
import os
import urllib.request
import json
import openai

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    
    message_event = json.loads(json.dumps(event))["events"]
    reply_token = message_event[0]["replyToken"]
    message = message_event[0]["message"]["text"]

    openai.api_key = os.environ['OPEN_APIKEY']
    res = openai.Completion.create(
        model='text-davinci-003',
        prompt=message,
        temperature=0, 
        max_tokens=1000, 
        top_p=1.0, 
        frequency_penalty=0.0, 
        presence_penalty=1.0 
    )

    res_text = ''.join([choice['text'] for choice in res.choices])

    url = "https://api.line.me/v2/bot/message/reply"
    
    headers = {
        "Content-Type": "application/json",
        'Authorization': 'Bearer ' + os.environ['ACCESS_TOKEN']
    }
    
    data = {
        'replyToken': reply_token,
        'messages': [
            {
                "type": "text",
                "text": res_text.lstrip("\n"),
            }
        ]
    }
    
    req = urllib.request.Request(url=url, data=json.dumps(data).encode("utf-8"), method="POST", headers=headers)
    
    with urllib.request.urlopen(req) as res:
        
        logger.info(res.read().decode("utf-8"))
        
        return {
            "statusCode": 200,
            "body": json.dumps("Hello from Lambda!")
        }

※コード汚いとかは内緒で。。。

上記コードで一応動いています。。

3:Lambdaのレイヤーにモジュールアップロード

コード書いているところの最下部に「レイヤーの追加」というのがあるのでそこから1で作成していた「python.zip」ファイルをアップロードして追加する

4:Lambdaの環境変数設定

コード上に直接トークンやKeyなどを書きたくないので環境変数に登録します。

今回はOpenAIのAPIキーとLINEのAccessトークンを設定します。

Lambda関数→設定→環境変数

から追加できます。

「OPEN_APIKEY」にOpenAIのAPIキー

ACCESS_TOKEN」にLINEのAccessトーク

を設定しています。

・LINEのAccessトーク

前提2で作成したLINEDeveloperでアプリを作成し下記添付の「Channel access token」部分を環境変数に適用

LINEDeveloper
・OpenAIのKey

前提1で作成したアカウントで「SECRET KEY」を作成して環境変数に設定

5:AWSのAPIGatewayの設定

APIGatewayを使ってアクセスできるようにします。

自分は「APIの作成」からRestAPIを選択して作成しました。

登録後Lambdaで作った関数を指定します。

設定後「リソース」→「アクション」→「APIのデプロイ」すると下記添付のように青枠のURL出てくるのでURLをどこかにメモしておきます。

※個人で好きに作っているだけなので設定などはデフォルトのままでprod一択です笑

6:LINEDeveloperのWebhook URLを設定

下記添付のWebhook URLの場所に5で作ったURLを設定

7:Lambdaのコードを自分の好みに書き換えて遊ぶ

Lambdaのコードで「Deply」してもらうことで好きに書き換えれるのでAPIのパラメータを書き換えながら試してみてください!

以上です!

 

PS

LINEのBot作成する際に一度名前決めると変更できないのでChatGPTbotって書いたがOpenAIのAPIを使ったbotなので後で名前変えようかなーと思います。。

夜道から学ぶ報告する力

こんにちは

地面が凍ってて滑りそうになってすごい格好で踏ん張ったオビ―です。

夜道の自転車のライト

夜に高校生が自転車に乗っている際にライトをつけていないという事で
警察に注意されているのを目撃しました。

警察官:「ライトをつけなさーい!」
高校生:「はーい!」

みたいな感じでかなりポップな感じだなーと思いながら
確かに夜道に自転車でライトつけずに運転するのは危ないなと思いました。。。

別の日に夜道を歩いていると前からライトが付いていない自転車が来てぶつかりそうになりました。
その際に

「自転車のライトがついていたら遠くから気づけて危なくなかったのになー」

としみじみ感じました。

その時に感じたのが自転車のライトは「運転する人が危ない」からという意味の他に
ここに自転車がいるよ!」と周りに知らせている役目もあるんだなと思いました。

そう思った時に仕事でも進捗を報告する際に周り(上長またはチーム)に
自分は今ここに居ます」というのを知ってもらう意味があるんだと感じ
自分の判断で「先が見えていなくても大丈夫」と勝手に思わずに
全体のスケジュールの現在地を知ってもらうことでテコ入れする必要があるのか
またはそのままでいいのかという上長への判断材料となるように報告をする。
そして上長またはチームにどのタイミングにおいても
あの人は今何をしているかわからない」と言われないように
ただ進捗報告するのではなく理解してもらい
上長の行動を促せる(そのまま進めるや他の作業をする)ように
報告する力が必要になると思いました。
※事故にならないように。

そんな事を夜道を走る自転車にぶつかりそうになった後に考えました。。。
是非みなさん自転車で夜道を走る際は
ライトをつけて事故にならないようにお気をつけください

PS

昔雪道を歩く際にひげダンスの要領で歩くと滑らないのを見ましたが

なかなか外でひげダンスして歩くのはかなり勇気がいりますよね。。。