テスト投稿です。
#たまもく 2019/11/23 成果
たまもくも少し間をあけましたが、再開してトータル第6回を数えています。
やるからにはちゃんと成果を記録に残さねば、と思いまして、作業記録を残します。
今回は、来月のアドベントカレンダーのネタであるところの、「AWS LambdaでPHPでスクレイピングする環境を整える」件の調査を進めました。
AWS Lambda に Serverless CLI をつかってデプロイする
インストールとかは、以下の手順。sudoとかは適宜つけてください。
$ pip install awscli aws-sam-cli
$ npm i -g serverless
まずはawsにログインします。アクセスキー、シークレットの入手は次の節でまとめます。
$ aws configure
AWS Access Key ID [None]: XXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]: ap-northeast-1
Default output format [None]:
テンプレを使ってプロジェクトを作ります。
$ sls create -t aws-provided -p aws-php-selenium-docker
まずは、テンプレそのまんまをデプロイしてみます。
$ sls deploy
権限が足りないエラー発生、権限追加、を何度か繰り返して、ようやくデプロイできました。
呼び出してみます。
$ sls invoke -f hello
{
"body": {
"input": {},
"msg": "Wecome to serverless!"
}
}
JSONが返ってきました。
AWS IAM で適切な権限のユーザをつくる
これ、だいぶ試行錯誤しました。正解かどうかも若干あやしいところ。ひとまず、やったことを残します。誰かツッコんでください。（切実）
- ルートアカウントでログイン
- IAM でグループを作成する
- IAM でユーザを作成し、グループに割り当てる
- アクセスキー、シークレットを取得する
IAMの画面です。
グループを作成します。
グループに適当に名前をつけます。
適当にポリシーをアタッチします。
確認画面で、作成ボタンで作成します。
次に、ユーザを作成します。
適当にユーザ名を作成します。
ユーザを先ほど作成したグループに加えます。
こうしてできたユーザの認証情報から、アクセスキーの生成を行います。
あとから思ったんですけど
これ、awscli から全部できるんじゃね？と思って、調べてみたらできるっぽいです。
ルートアカウントのセキュリティ資格情報を開きます。
「アクセスキー (アクセスキー ID とシークレットアクセスキー)」から、新しいアクセスキーを作成します。
これを、aws configure で入力してルートアカウント権限になります。あとは、コマンドをバシバシと打つ。
・・・はずなんですけど、今日は時間切れ。
仕事の楽しさ
久しぶりのブログです。が、あまり明るい内容ではありません。(´・ω・`)
謎の
少し前、詳細は伏せますが、謎の2on1がありました。（なんだそりゃ
そこで、「今の仕事は楽しいか？」と問われ「楽しいとは何だろう。今まで仕事で楽しいと感じたことがない。今までずっと仕事は辛く厳しいものだった。今は辛くはないのは確か。きっと楽しいのだと思う」と答えました。
聞いていた2人は「（楽しくなさそうな）謎がとけた」「それは問題だ」と。
仕事が楽しい状態とはどんなものかを定義します。以下かと思います。
- 責任を持って任されている
- 困難な課題に対し着実に成果を出せている
- やり甲斐がある
一方で、自分の仕事の環境、評価は次のような状態が長く続きました。
- 任されず、評価されない
- 結果を出せない
- うまく行かないことの方が多い
- 叱責される
- 成果は出せても短期的なものにとどまる
また、以前の記事でも触れましたが、いろいろ困難な状態が続くことが多くありました。（こうやって見ると、本当に仕事できない奴ですな…）
ひとことでまとめれば、「自己肯定感が得られない」状態が多かったと思います。
昔語り
自己肯定感が得られなかった要因の一つに、背景に子供の頃の体験と大人になってからのギャップがあるかと思いました。
私は、自慢に聞こえるかも知れませんが、勉強ができる子供でした。小学校の頃の勉強は理解できるのが当たり前、中学でも校内10位前後をキープし、それなりの進学校へ進み、旧帝大を出ました。10代は、できて当たり前、できて当然の世界を生きていました。
一見順風満帆に見えますが、大学に入る頃からうまく行かなくなります。大学に入るのにニ浪し、大学では勉強について行けなくなり、いろいろあって一年留年しました。
そして、就職によって世界が変わります。仕事ができない奴の誕生です。
仕事上の失敗は誰にでもあることですが、私は失敗のリカバリーがとにかく下手でした。よくやったのは、小さな失敗を軽視し、または気づかずにそのまま突き進み、後で大事になる、というのをよくやりました。
そしてしばしば上司と衝突しました。些細なこと（と当時は思ってました）をネチネチ言ってくるのも気に入らなかったですし、失敗そのものを受け入れられず、落ち込むだけ落ち込んで、改善行為を行いませんでした。
結果、理想と現実のギャップに苦しみ、体を壊して休職に至ったのは過去の記事のとおり。
楽しむ、とは
昔語りが過ぎました。
では、仕事が楽しくなるには、どうしていったらいいのか。
大きく分けてふたつのフェーズがあるかなと思いました。
- 過程を楽しむ
- 結果が全てを癒やす
現在ではいい歳のおっさんになりまして、仕事が「基本うまく行かないもの」であることを理解しました。
都度、軌道修正し、自身を成長、変化させ、乗り越えたり迂回したりしてゴールへの道筋をつける、その行為自体をゲームとして楽しむことが重要かなと思えるようになりました。
また、二つ目は前職の社長の座右の銘なんですが、なんだかんだゴールにたどり着くことがカタストロフィを生むのですよね。
今のところ、入社して4ヶ月が経とうとしています。結果はまだまだ出せていないですから、過程を楽しむ必要があります。
果たして、出来ているだろうか。うーむ…
（答え、出ず）
入社して一週間を振り返りました
まぁいろいろたどっていけば分かるんですけど、まだ正式に許可いただいてないので社名は伏せますが、無職から転職して一週間が経ちました。
ほぼほぼ今の組織の状況、課題感に追いつくので精一杯でした。
自社サービスの開発をやっているへーしゃでは、業務フローとプログラムが密接につながっていると感じまして、その辺を私の方から「教えてー」と聞けたのは、ナイスプレイだったと思います。
一方、コードを読んで理解する、という方面では、なんとなく漫然と眺めてしまっており、ちょっとやり方を見直す必要があるかなぁ、と反省しています。
今後へーしゃでは勉強会やMeetupなど積極的にやっていく流れなので、その辺でのコミットもやっていきます。
採用活動については、最初は、まずはエンジニアとしての成果をしっかり出したうえでコミットしていくべきかなぁ、とか思っていたんですが、ちょうど同じ7月1日から新しい会社に転職されたてぃーびーさんのご活躍を見て、むしろ全方位に対してぐいぐい突っ込んで行った方がいいのではないか？と思い直しました。（無論てぃーびーさんは超弩級のスーパーマンであることを差し引いて考えたとしても）
怒涛の1週間目が終わった。
各所から1週間目っぽくないという言葉をいただいた。これは
・1週間らしからぬ活躍をしてくれている
・1週間らしからぬ図々しさを発揮しているあたりの二択だろう。
どっちだ！※マジレス不要。大喜利歓迎
— てぃーびー-スタディスト人事 (@tbpgr) 2019年7月5日
へーしゃでは週一で1on1が実施されており、課題や方向性の共有がスムーズにやれることが期待できるので、ぐいぐいと食い込んでいく姿勢を維持していきたいです。
あーそんなことより来週のCryptopsyの来日が楽しみで仕方がないんじゃー！！
初出社
二ヶ月ちょいの無職期間を経て、新しい会社に初出社なうです。
次は、しっかりやって行きたい。（ケツイ
退職エントリ【七ヶ月ぶり二回目】あるいは、或る転職失敗事例
4/25付けをもって、某ウェブベンチャーを退職しました。
この先、大変暗い内容となっております。
昨日からの流れ
4/29。
令和を実家で迎えるため、帰省の途につく。
まったり羽田空港を満喫すべく、昼ごろ着いてランチ。
お土産買う。
さーてチェックインするか、とカードを通すと、弾かれる。
嫌な予感を振り払うように有人カウンターへ行って確認したところ、飛行機代が支払われた形跡がないことが判明する。
血の気が引く。
実家に電話し、トラブったことを伝える。
北海道への飛行機はもはや当日だと事前予約の倍近い値段。帰省を諦める。
吐きそう
— kazto 求職中 (@bainarian) April 29, 2019
「しゃーないベ。じゃあ代わりにどっか行きたい！」と妻の発案。
東京駅へ向かう。
新幹線の空き状況をチェック。30日新大阪行きのチケットを購入。
飲み屋で大阪で何するか決める。
東京駅で飲んだくれている
— kazto 求職中 (@bainarian) April 29, 2019
とりま帰宅し、詳細を詰める。
翌朝、東京駅へ向かう（←イマココ
#もくもく会 を生やしてみました。 #たまもく
去る3/9（土）、無事、もくもく会をやり遂げることができました。まずは、ご参加くださった皆さん、声援を送ってくださった皆さんに感謝を述べさせてください。本当にありがとうございました。
ことのきっかけとしては、もくもく会に参加したいなあと感じてきたことでした。
なんせ、いろいろ年初の目標は立ててみたものの、なかなかこなしていく時間が取れない。これは良くない。
一方で、魅力的なもくもく会は大抵都内開催です。銀座とか秋葉原とか渋谷とか、きらびやかな場所まで行くのは田舎暮らしには若干のハードルがあるのです。
そこで、OSSの精神、無ければ作ってしまえ、とばかりにつぶやいてみたところ、
地味に多摩地区もくもく会を主催したい気持ちが発生している。需要あんのか知らんけど。ちなみに主催のノウハウも無い。
— 𝕜𝕒𝕫𝕥𝕠 (@bainarian) 2019年2月4日
ありあきさんにズドンと背中を押していただきました。
多摩地区でもくもく会の会場探されてるようです！興味ある企業様は是非お声がけください。 https://t.co/cXaQfhmK4D
— ariaki (@ariaki4dev) 2019年2月4日
最大の難関かなと考えてた場所の確保も、Twitterで拡散していただいた結果、ご紹介いただいて無事、というか一週間経たずに決まり、公開に到りました。
国立駅近で良ければもしかしたら、、！
— bmf (@bmf_san) 2019年2月4日
最終的になんだかんだで全くのご新規さんが4名、登壇の会の方4名、合計8名の方にお集まりいただき、規模感としても想定していた通りくらいの規模になりました。まぁ何事もなくと言いますか、あまりにもいい感じに事を運ぶことができまして、帰り道で最寄りに着いたところで感極まって涙に暮れる一幕もあり。涙腺がゆるいお年頃です。
やはりこういう会は長く続けてこそ価値が出てくるものだと考えていまして、できれば何年という単位で続けて行きたいものです。
調子ぶっこいてサイトも立ち上げました。
次回開催は4/20（土）を予定しております。近日中にconnpass立てます。お引き立てのほど、よろしくお願いします。
デブサミ2日目に行ってきました。 #devsumi
自分が聞きに行ったのは、以下のような感じです。
- プロダクトマネージャーという生き方
- CI/CDを使い倒して数段上のソフトウェア開発をしよう！
- 【導入事例】Lychee Redmineのユーザが語る！トラブル予防としての使い方
- エンジニアの皆さんに贈る最速キャリア戦略
- これをまだ知らない Web エンジニアへ贈る – 私が愛する Elixir/Erlang の楽しさと辛さ –
- 「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話
- 休憩（イマココ
- アウトプットのススメ ～技術同人誌・LT登壇・Podcast～
順に雑な感想。
プロダクトマネージャーという生き方
今仕事しているチームにも、お客さん側にプロダクトマネージャがいまして、その姿を思い浮かべながら聞いていました。
「PMが入ると、Issue、Goal、KPI、Scopeがクリアになる」という一節がありましたが、その点あまりクリアになってないなぁ、エンドユーザに引っ張られてないかなぁ、と思いました。
CI/CDを使い倒して数段上のソフトウェア開発をしよう！
CircleCIの中の人の話。
自分はずっとJenkins使ってきて、導入やら布教やらやったんですけどなかなかうまく行かなくてつらみを経験した方だと思うんですけど、そんでもやっぱりCI/CDの実現にはやっぱりあこがれを感じます。
今はそんなん導入してる余裕は全くないんですけど、落ち着いたら。。。
【導入事例】Lychee Redmineのユーザが語る！トラブル予防としての使い方
Redmineの商用カスタマイズ版導入事例といった感じ。
なかなかねー、商用プラグインの導入には敷居が高いんですけど、使えたらいいなぁ。
エンジニアの皆さんに贈る最速キャリア戦略
DMM.comのCTOの人。東大出身ですって。
相応に頭いいひとだとそりゃー駆け上がれるでしょうよ。凡人にはなかなかそこまでのアタマが無いから苦労してんだよぅ、と恨み節半分で聞いていました。
これをまだ知らない Web エンジニアへ贈る – 私が愛する Elixir/Erlang の楽しさと辛さ –
今日一番で軽妙なセッションだったように思います。
一見難しそうなElixirも、導入の手順を間違えなければいい感じだよ、というお話。
「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話
今のところ一番エモい話でした。
振り返ると、今まで仕事ではつらい思い出ばっかだったように思います。でも最近は今の会社に入ってようやく、工夫をしたり、意見を言ったりして、それでうまく行くことも出てきたり、そんでも忙しさに流されそうになってたりしますが、そういう環境の中で自分自身を振り返ったりして、定量的に振り返ったり、改善してったりしてけば、仕事も楽しくなるのかなぁ、などと目頭を熱くしながら聞いてました。
アウトプットのススメ ～技術同人誌・LT登壇・Podcast～
でも今日はこれが本番ですよ。奥さん！！
行ってきます！！
laravel-permissionでguardつきroleをアサインする
たまには（すんげぇピンポイントな）技術ネタを。
一般的にLaravel-permissionsを用いてdb:seedを行う際、Seederの中でassignRoleする方法は、以下の通り。
$user = User::create([
'name' => '社長',
'email' => '[email protected]',
'password' => Hash::make('owner'),
]);
$user->assignRole('owner');
なんですけど、assignRole関数はguardを受け取らない仕様になっている。（2019/02現在）
これでは、guardを使って例えばAPI経由の時だけパーミッション参照させたい場合などに困る。
この辺とか この辺の実装を見てみると、getDefaultGuardName()でデフォルトの奴しか参照してない。ダメだこりゃ。
正解としては、このIssueの通りなんだけど、本当に最低限（チェックとか省いた）バージョンは以下でいいのかなと思います。
$roles = app(Role::class)->findByName('owner', 'apiguard');
$user->roles()->saveMany($roles);
$user->forgetCachedPermissions();
roleとかguardの存在確認とか省いてしまっているので、ご参考程度までに。
Laravel使い始めて５ヶ月ほどですけど、ほんと内部のソース読み込まないと使いこなせませんね。