複数タスクを並行でこなすとき、時間軸で振り分けを考える
最近タスク整理業が多すぎるのでそこで文章化したかったことをまとめる。
並行タスクの問題点
あふれるタスクを整理するときに時間軸で整理する
- そのタスクは依頼を必要とするものか
- そのタスクは期限が求められるものか
- そのタスクは後続のものがあるか
などの観点で判断する。
振り分けの発想
基本的には待ち時間が発生するもの（例えば返事が欲しいメールや長いバッチ処理）などはなるべく早く手を付ける、なぜかというと
という観点から先に作業を行う。
依頼タスクがたくさんある場合どうするか
そのように待ちが多く発生するタスクが同時多発的にある場合、次の考え方で優先順位を決める
- そのタスクの完了が遅延すると全体のクリティカルパスに影響しないか
- 待ちの時間の長さに差があるか
基本的には全体的な遅れや、致命傷などにならないように回避する策を考えるというのが肝要である。
たとえば「待ちの時間の長さに差があるか」はメールなどで考えるとわかりやすく返事の欲しいメールを送って、すぐ返ってくる相手ならいいが、とても忙しい相手などには早めに送っておいて、相手のタスクとして潜り込ませて余裕のあるタイミングで処理してもらうように促すなどのほうがよく回ったりもする
気をつけること
先にさばいた待ちタスクは、返事が戻ってくるまで他のタスクにとりかかれる一方で、戻ってこないとタスクそのものを忘れてしまうことがあるので、気をつけること。
ビジネスメールにおけるインラインとは
結構無意識で使ってたけどよく考えるとこれは一般用語なのか不安になったので調べてみた
メールにおけるインラインとは
メールの返信において、もらったメールの本文を使って返答文を書くこと。
実例
shinkufencer様 いつも大変お世話になっております。 株式会社exampleの例太郎です。 7月2日の会議の開催について問題ありませんでしょうか。 お手数ですが、ご確認よろしくお願いいたします。
というメールが来るときに返信をすると大概のメーラーは > が先頭につく
> shinkufencer様 > > いつも大変お世話になっております。 > 株式会社exampleの例太郎です。 > > 7月2日の会議の開催について問題ありませんでしょうか。 > > お手数ですが、ご確認よろしくお願いいたします。
こちらに対して返信文を書くときに以下のように書くとインラインとなる
ほげ太郎様 お世話になります。 shinkufencerです。 インラインで返信いたします。 > 7月2日の会議の開催について問題ありませんでしょうか。 上記の日程で問題ございません。 以上、よろしくお願いいたします。
補足事項
たまに参考例文だと
インラインで失礼いたします。
という形の表現があるが、これは「メールを引用して返信することに不快感を抱く人がいる」ということに関してのクッションとして使われることが多いので、人によっては表現のパターンとして考えるとよい
参考リンク
公式で配布しているAppStoreとGooglePlayのアイコンのレギュレーションと場所
知らない人はあんまり知らない
サイト
Apple
マーケティングリソースとアイデンティティに関するガイドライン - App Store - Apple Developer
サイトで使う際の注意
- marginのレギュレーションなどがあるので守ること
- 解像度とか低いと怒られるので注意する
関連リンク
Faraday(にてNet::HTTPを使う場合)で証明書検証をスキップする
2日連続Faradayネタ
環境
faraday (0.15.4)
考え方
FaradayではHTTP接続のadapterが指定できるので、そちらで Net::HTTP を使えばSSLの認証モードとして証明書検証が失敗しても続ける指定ができるのでそちらを使う
やり方
Faraday.new do |faraday| faraday.adapter :net_http do |http| # Adminは内部のネットワークのため、認証局がない証明書を使う。 http.verify_mode = OpenSSL::SSL::VERIFY_NONE end end
という形で指定することができる。ちなみに OpenSSL::SSL::VERIFY_NONE を指定すると挙動は以下のようになる
クライアントモード: サーバから受け取った証明書は検証されますが、失敗しても ハンドシェイクは継続します。 ハンドシェイクの結果は OpenSSL::SSL::SSLSocket#verify_result で 取得できます。
このフラグは単独で用いられるべきです。 - constant OpenSSL::SSL::VERIFY_NONE (Ruby 2.6.0)
参考リンク
RubyのFaradayで送信するURLはURIエンコードを勝手にかけてくれる
表題の通りネタ
環境
faraday (0.15.4)
実演
下記の用にクライアントクラスを作る
client = Faraday.new do |faraday| faraday.response :logger #ログが見れる用に faraday.adapter Faraday.default_adapter # デフォルトアダプタ指定 end
まずは普通のパラメータでリクエスト
client.get {|req| req.url "https://example.com?a=b" }
そうするとままGETリクエストをなげているのがわかる
I, [2019-06-12T23:57:05.830884 #41948] INFO -- request: GET https://example.com?a=b D, [2019-06-12T23:57:05.830941 #41948] DEBUG -- request: User-Agent: "Faraday v0.15.4" I, [2019-06-12T23:57:06.308756 #41948] INFO -- response: Status 200 D, [2019-06-12T23:57:06.308828 #41948] DEBUG -- response: accept-ranges: "bytes"
次にURLにエンコードが必要な文字列がある場合、今回は % を入れてみる
client.get {|req| req.url "https://example.com?a=%%%" }
I, [2019-06-12T23:57:50.739439 #41948] INFO -- request: GET https://example.com?a=%25%25%25 D, [2019-06-12T23:57:50.739516 #41948] DEBUG -- request: User-Agent: "Faraday v0.15.4" I, [2019-06-12T23:57:51.091595 #41948] INFO -- response: Status 200 D, [2019-06-12T23:57:51.091719 #41948] DEBUG -- response: accept-ranges: "bytes"
参考リンク
『エンジニアのためのコーチング入門』に行ってきたよメモ
エンジニアのためのコーチング入門 に行ってきたのでメモ
各発表の感想とか
この会の導入説明
スライドで導入説明があったのでリンクだけ
人と話すことが苦手な人のほうが、コーチングは上手くなる
発表メモ
社内コーチなどの経験をされてきてコーチングに関して
- 勇気
- 人生の目的
- コーチングで一番大事なこと
という3点で話をしていただいた
「勇気」に関しては自分のできることや強みを把握して、必要なものだけになるように削ぎ落として、何者かになるということに関してエピソードを通して話していただきました
「人生の目的」に関しては他人の人生のために生きるのではなく、自分が何を目的にしているのかを考え、それに沿って自分の人生として生きていくことというのを考えるのが必要という話でした。
「コーチングで一番大事なこと」では”相手の可能性を信じる”というのをワークショップやピグマリオン効果というワードと合わせて紹介していただきました
感想
- 発表者の三橋さんの体験を通して、コーチングする側のありかたの話
- 普段考えてそうで考えてないことを改めて見つめ直す機会になった
- 信じることの大事さというのは人生経験上あったので、それをこうやって誰かの口から語られるとやってきたことの確からしさがわかった感じ
関連リンク
1on1で使えるコーチングスキルの活かし方
「エンジニアのためのコーチング入門」で発表したスライドです！https://t.co/iRAZqS3Ule#engineer1on1
— たにさん🌈なんかゆかいな人 (@tany3_) 2019年6月11日
発表メモ
1on1観点で下記の4点に関して語っていただきました
- 自己探求
- 向き合い方
- 場作り
- スキル
上記の4点に対して、それぞれどんな話があったかというと…
- 自己探求は、コーチングをする上で自己管理に関してのアプローチに関して
- 向き合い方に関しては下手に気にして本音を隠すと気づかれるので相手を信じて話すこと
- 場作りにおいてはちゃんと導入に話し合ってちゃんとお互いの認識を合わせること、特にその場での話は口外しない。外に話す場合はちゃんと同意形成をする
- スキルにおいてはまずは傾聴が基本。傾聴も自身の声を聞く、相手の声を聴く、周りの声を聴く（空気を読む）などを意識して使う。1on1においては喋り相手が自身の声を引き出してもらうようにする。
感想
- 具体的な1on1方法論のような形でのお話。
- 個人的には自己管理というフレーズが響いた、大枠の意味でもそうだが、答えを先導したくなる場面はあったりするので、自身からひねり出すことをコントロールしながら与えることがコーチングに置いては重要性が高い
- 関連書籍がめちゃくちゃ出てきたので読みたい（ので備忘のためにアマゾンリンクを作った）
関連リンク
エンジニアリングマネージャー育成におけるコーチング
「エンジニアのためのコーチング入門」でお話したスライドをアップしました。
— やっさん | Tsuyoshi Yasunishi (@tsuyok) 2019年6月12日
エンジニアリングマネージャー育成におけるコーチング 2019-06-11 #engineer1on1 https://t.co/f1MhY1ERAs
内容メモ
（スライドの補足的内容です）
- エンジニアリングマネージャーの育て方の話
- あり方に関してフォーカスを当て、オーセンティックであるようにし、自分らしさを持つ
- 明確な答えのない問題にぶつかりやすくなるので、それに対しての姿勢を保つ
- 1on1での事例では2例紹介があった
- 英語でしかコミュニケーション取れなかった上司との1on1だったが相手の印象がよかったという事例。言葉の通じる通じないではなく、ちゃんと相手のことを引き出す姿勢だったり振る舞いが大事であるエピソード
- 若い人がマネージャーだからということで強がって知らないことを喋らないことによって良くない方向に転んだが、最終的にわからないことをちゃんと明かすようになったら良い形で物事が進んでいった事例
感想
- オーセンティックという言葉は初めて聞いた言葉だったのでなるほどという形になった
- コミュニケーション能力や言語の壁みたいなものがあるのかと思ったんですが、そういうものではないということを事例を通して再認識することができた。
関連リンク
![オーセンティック・リーダーシップ (ハーバード・ビジネス・レビュー [EIシリーズ])](https://m.media-amazon.com/images/I/41GIT2-P9YL._SL500_.jpg "オーセンティック・リーダーシップ (ハーバード・ビジネス・レビュー [EIシリーズ])")
全体を通しての感想
環境変数にRAILS_ENVが無いときに指定しないとdevelopmentで実行される
当たり前すぎるけど直球ワードで調べると出てこないし、ガイドとかにもざっとググるに明示されていないので備忘
環境
$ bin/rails -v Rails 5.2.2
検証
$ echo $RAILS_ENV $
何も設定されていない空文字であることを確認
$ bin/rails c Loading development environment (Rails 5.2.2) irb(main):001:0> Rails.env => "development"
