転職透明化らぼで運用しているBotの話
みなさん、おはこんばんにちは。ぐーどらです。
この記事は「#転職透明化らぼ アドベントカレンダー Advent Calendar 2019 - Adventar」の8日目の記事です。
どんなBotを作ったの？
Connpass上で作成した転職透明化らぼのイベントに対し、connpass APIを5分毎に叩き、人数を取得します。
次に、取得した人数は毎回キャッシュに入れるのですが、毎回キャッシュに入れているので、5分前の人数と比較し、変化が出ていたらチャットサービスへ通知する、というBotを作りました。
増えた時
減った時
週次での報告
まだまだ改善点が多くあり、手を入れるところが多いのですが、取り急ぎ運用を開始できるところまで持っていけました。
実装のお話
転職透明化らぼでは運営用のチャットサービスにTypetalkを使っています。NulabさんのTypetalkブログに「キーワードに反応するTypetalkボットの作り方（総務・人事の活用例） | Typetalk ブログ」という記事があり、まず参考にしました。
これだけでは足りないので、connpassのAPIリファレンスや、GASからGETメソッドのAPIを送信する方法などを調べて実装しました。また、GASのブラウザ上でのエディタでは少々編集がやりにくかったので、Claspも使いました。
というわけでリポジトリです。
GASやそもそもJSが初めてだったこともあり、実装には1週間ほどかかってしまいました。まあでも、とても面白かったですね！
実際に実装を始めてから、2,30分程度でGETメソッドのAPIを送信出来たのは感動でした。GASすごい。
スクリプトを見て、ここどうなってるの？とか、どうしてこういう実装したの？とか、こうしたほう良いのではなどありましたらコメントお待ちしています！
Chief Insyu Ojisanがオススメする、ベルギービール3選
みなさんおはこんばんにちは。ぐーどらです。
この記事は「飲んべえ・酒くず（のつもりでいる人）の Advent Calendar 2019 - Adventar」の 8日目 7日目(遅刻してすみません！)の記事です。
自己紹介
普段は自社サービスの会社でPHPを使い、不動産業界向けのSaaS型Webアプリケーションを開発しています。
突然ですが、皆さんベルギービールは好きですか？僕はとても好きです。そして幸せなことに、職場近くにとても素敵なベルギービール専門のバーがあるのです！というわけで、そこに通い詰めて、僕が好きになった選りすぐりのビールを紹介しようと思います。
好きなビール第3位 グーテンドラーク
僕のHN由来のビールです。都内のあるお店でグーテンドラークを頼むと「グードラ」と略されるところから取りました。
味はというと、コクが有りつつ苦味の少ない、ナッツのような香りがするビールです。ぜひ一度お試しあれ。
好きなビール第2位 デュベル・トリプルホップ
ホップの香りがとても気持ちの良いビールで、香りだけではなく泡まで美味しい、初めて飲んだ時は衝撃を受けたビールです。
好きなビール第1位 ウェスマール・トリペル
ビールらしさも有りつつ、スパイスのような香りもある複雑な味わいが飲んでいて非常に楽しく濃厚な味わいのビールです。あるところにあるとほぼほぼ飲んでいる気がします。
番外編
ここからは、ビールって美味しくないとか苦いとか感じている人向けにご紹介。
- セリス・ホワイト
所謂ホワイトビールです。ホワイトビールはヒューガルデン・ホワイトが有名ですが、セリス・ホワイトも僕は好きです。ヒューガルデン・ホワイトよりあっさりの爽やかな飲み口です。
- フルーツビール（銘柄ではないですが）
本当にフルーツを使っているビールで、チェリー、ピーチ、フランボワーズなどなど、様々あります。女性にウケが良い。
というわけで、雑におすすめなビールを挙げました。気になるビールありましたでしょうか。みなさん、気になった人は是非、「ベルギービール」で検索してみてください！
転職透明化らぼのイベントに参加し、書類を書いて転職活動してきた
皆さんお久しぶりです。ぐーどらです。僭越ながら、転職透明化らぼ、アドベントカレンダー1日目の記事を書かせていただきます。
前回僕が書いた記事は、転職希望エントリー記事でした。ところで僕のTwitter固定ツイートは例の転職希望エントリー記事でしたね。それを今は固定ツイートにしていません。勘の良い皆様なら既にお気づきでしょう。僕が内定を貰っていることに！！
ということで、今回の記事では転職透明化らぼで得た知識をどのように使い書類を書いたか、そして実際にどの程度選考を通っていたかなどを赤裸々に書いていこうと思います。
転職透明化らぼレジュメチェック編おさらい
まとめページ
イベントページ
tbpgrさん（転職透明化らぼ主催者）のまとめ記事
イベントタグtogetter
ぐーどらによるまとめ
- 人事としてはカルチャーマッチから見たいので、考え方や人となりがわかるエピソードが書類上に欲しい。もしくはブログ。
- どんなことを他人から直接言われたかを書類に盛り込めると良い。
- 細かくではなく、何をどういうふう考えてどういうことをしたのか、「解像度の高い」書類が嬉しい。
- 志望動機、履歴書はほとんど見ない。
イベント参加後に作った職務経歴書
イベント内容をもとに修正した点
- 「解像度の高さ」を意識し、どのようなことをやってきたのかを採用担当者がイメージしやすいように、主な業務内容を簡単に記載。
- 考え方を見せるためにも、実績の項目ではやったことだけではなく、どのような背景で何を問題視し、どのように改善したのかを書いた。
- 志望動機は削った。
- 他人から評価時に言われたことは面接で回答した。
書類の通過率
前置きが長くなりましたが本題です。それではさっそく結果をどうぞ。
| カジュアル面談 | 書類選考 | 書類通過 |
|---|---|---|
| 8社 | 3社 | 3社 |
というわけで、選考過程に進ませていただいた全ての企業で書類は通過していました！
昨年転職していた時とは全く違い、転職活動そのものがとても捗り、リファラル採用の強さを改めて感じました。カジュアル面談にお誘いいただいた方々にも、この場を借りてお礼申し上げます！ありがとうございました！
次はどんな会社？
受託開発をしており、LaravelやRails、スマホアプリなどを得意とする企業です。ようやく念願叶い、Laravelを仕事で触ることができます。
余裕が出来たらフロントエンド、スマホアプリ、構成管理などもやっていきたいと思っています。
最後に
ここまでお読み頂きありがとうございました。
エンジニアになって1年目の人間でも転職できる知見が共有される転職透明化らぼ、今後ともよろしくお願い致します！
あ、直接話しを聞きたい方、是非飲みに誘ってください。
透明化らぼに参加する理由と第3回イベント開催のお知らせ
みなさんおはこんばにちは。ぐーどらです。実は2週間ほど前から、転職透明化らぼというコミュニティのコアスタッフをやり始めました。
先日、とある勉強会に参加してきました。自己紹介タイムがあり、「告知したいことがあればどうぞ！」と言われていたので頭の中では転職透明化らぼの告知をするんや！と考えていたのです。
その結果告知した内容が以下のツイートです。
今日PHP勉強会で自己紹介タイムあったのに、自分がコアスタッフ参加しているコミュニティの告知をすっかり忘れたポンコツスタッフです。
— ぐーどらくらんち (@gulDra_cranch) September 25, 2019
とんだポンコツですね！告知し忘れたなら、自分のブログに書けばいいじゃない！ということで、本日はコミュニティの紹介をしつつ、どのようなモチベーションで参加しているかを書こうと思います。
- コミュニティの実施目的に共感した
- コミュニティに貢献したい気持ちがあった
コミュニティの実施目的に共感した
出発点は主催者であるてぃーびーさんのブログ記事です。
自分も昨年転職活動を経験し、そしてまさに今も転職活動中です。
突然ですが、転職活動で作る書類ってめちゃくちゃ大変じゃないですか？自分は1年前も今回も、書類にはとても手を焼いています。作り始めてから、1,2週間は経っています。苦手という意識もあり、とても時間を使っています。しかも転職活動は書類だけではないですよね。転職媒体選び、企業選び、面接など考えなければならない要素は盛り沢山です。苦しい。本当に苦しいです。辛いです。
そんな転職活動が何故辛いのか。転職活動をする側の視点からすると、有用な情報がまず少ないことが挙げられると思います。転職媒体選び、書類の書き方、自分の転職に対する態度。どれを取っても有用な情報が纏まっている媒体は非常に少ないと感じます。
転職透明化らぼは転職者のための情報を提供し、人事や企業との情報格差を埋める＝転職を透明化するという意味でネーミングされています。自分はこの部分に非常に共感しました。というか、自分は今まさにそういう情報が欲しい！つまりスタッフとして参加すれば積極的に聞く機会が作れるじゃないか！という若干の下心もあり、コミュニティに参加しています。このコミュニティの活動がさらに活発化し、転職に対する知見が共有されることはとても良いことだと思っています。自分と同じように苦しむ人は多いと思いますし、そういう人の役に立てるコミュニティであると思っています。
コミュニティに貢献したい気持ちがあった
運営に参加した理由としてはもう一つあり、コミュニティに対して何か寄与したいという思いが前からありました。私は今年に入ってからエンジニアを始め、業務に取り組んできましたが、決して一人だけの力で全て解決してきたわけではないのです。勉強会やカンファレンスという、どんな背景の人でも関係なく質問に答えてくれる場があったからこそ、今まで楽しく仕事を続けてこられたという感覚があります。
自分が業務や学習で困った時、もちろん最初はインターネットを使いますが、それでも解決できないことが多々ありました。そんな状態で参加したコミュニティでは、正解を明示してもらえたり時には自分がこれから吸収すべき知識を提示してもらえたり、本当に一人で得ることが難しいものを惜しげもなく提供してもらえたのです。
このような経験をとても有り難く感じたことから、徐々にコミュニティに何か寄与したいという思いを抱き始めました。そんな思いを抱える中、知り合いであるてぃーびーさんがコミュニティを主催されるお話を聞いたので、加わりました。
次回、転職透明化らぼイベントの開催のお知らせ
というわけで、最後はイベントのお知らせです。
- 株式会社カヤック 人事部長
- SanSan株式会社 人事
- 株式会社メルカリ Engineering Manager
という豪華ゲストでで送る、「レジュメチェック」をテーマにした回です！
電車の中で転職媒体を見ようとして、でもTwitterに手を伸ばしてこの記事にたどり着いてしまったそこのあなた！どういうレジュメを作ればよいかわかれば、あなたの転職は楽になるのでは？転職中で無い方もいつ転職するとも限りません。転職をする時、だいたいレジュメの作成は大変ではないですか？そんな人たちのためのイベントです！是非参加してください！
転職エントリー
皆さんおはこんばんにちは。ぐーどらです。今更しれっと書きますが、先日の7/27（土）に技書博の1日スタッフやっておりました。
1日スタッフ目線ですが、一般参加者やサークルさんにとってとても安心感のあるイベントだったと思います。第二回も開催決定しているので、またスタッフとして参加させていただこうと思っています。
あともう一つ、Builderscon最高でしたね。スピーカーの方、スタッフの方やスポンサー企業様、参加者の皆さん本当にありがとうございました。
転職エントリー
ガラッと話題は変わりますが、転職活動を本格的に始めます。
今回の記事は自分の整理した考えを書き、自分と会ってくださる採用担当の方やエンジニアの方とのギャップを埋めるために書いていきたいと思います。
自己紹介
2019年1月に異業種からエンジニアへ転職しました。前職では派遣でコールセンターの業務をやっていました。
その前には半年程度HTML,PHPやLaravelなどを独学で学習しました。その時のリポジトリも残っているのですが、今見ると所謂ファットコントローラーなアプリケーションかつメンテナンスもしていないため、こちらに直接掲載するのは控えます。（GitHubのプロフィールから辿れば見られますので、見てみたい方はたどって下さい）
元々プログラミングに関しては完全に未経験だったわけではなく、10年以上前に高校の部活動でC言語やN88-BASICなどを経験してた背景があります。一旦は大学も情報工学科に進学はしましたが、家庭の事情などから通学を諦めることとなりました。時間が経ち改めて突き詰めてどんな仕事がしたいかと考えた時に、もう一度ITを仕事にしたいと思い学習をし、そして転職をすることが出来ました。
転職の動機
転職の動機は現職でデファクトスタンダードな技術を使ってプロダクトに関わることが難しいためです。
まず補足しておくと、現職に対する不満を言うつもりはありません。しかし業務を遂行してきた中で、自社の環境がレガシーであると徐々に認識し始めました。レガシーであると判断した要素はデプロイ方法と開発環境、VCSにあります。デプロイ方法SCPソフトによる手動アップロードが採用されています。開発環境は共通の開発者用のEC2インスタンスが用意されており、そこにSCPソフトで手動アップロードを行い、動作確認を行う方法が使われています。またVCSはSVNが使われています。
レガシーな技術がプロダクトに使われていることが問題だとは捉えていないのですが、一方で私はデファクトスタンダードとされる技術を業務で使いたいという思いを持っています。世の中をより良くするプロダクトを作るという行為には、広く採用されている技術を理解している前提が必要だと思っているからであり、エンジニアになってから日が浅い今のうちにスタンダードな技術を扱うことこそ重要だと感じているからです。
今までにやってきたこと
業務上やってきたこと
- 不動産業界向け業務効率化Webアプリケーションの機能開発と保守
- テストコードが無かったため、テストフレームワークの導入と実装
- VCSにGitLabと運用モデルにGit Feature Flowを提案
- 新人の研修用にPHP実行環境（LEMP）を簡単に用意できるVagrantfile、シェルスクリプト、ドキュメントの作成
シェルスクリプトについては最近作ったもので個人的にもアピールしたかったのですが、CentOS 6で動くように書いたため、公開するのに気が引けました。CentOS 7向けに書き直すか、8が出たら8で動くように書き直したものを公開したいと思います。個人的に書いた初めてのシェルスクリプトかつ、LEMPを構築する経験も初めてのことでソフトウェアやPHPのビルドに対する経験を積めたことは大変良い経験だっと思います。PHP-FPMとnginx間もTCPではなくUNIXドメインソケットで通信させました。
与えられたタスクを粛々とこなせば良いという考えはなく、改善できる箇所は積極的に改善したり、何よりも自分の実力を伸ばしたいと強く思っています。また上記で上げているやってきたことのほとんどは直接与えられたタスクではなく、自発的に動いているものがほとんどです。API仕様書に関してもフォーマットは特に指定されていなかったため、社内で誰も使ってなかったaglioを使い、今後の生産性の改善に繋げました。
個人的にやってきたこと
- 勉強会やコミュニティへの参加と運営
- DockerとDocker Composeで開発環境を自作
connpassのプロフィールページ：https://connpass.com/user/cranch-crown/
運営コミュニティ
自作開発環境
スキル
言語
PHP、HTML、CSSに関しては独学期間を合わせるとそろそろ1年越えています。SASSやSCSSの経験はまだありません。
- Phalcon 3.4
- Laravel 5.7
業務ではPhalconを使っています。Laravelは独学レベルになります。
データベース
- MySQL 5.7
どういうエンジニアになりたいのか
私は「自分の技術や知識を使って、世の中を便利にしてゆくエンジニア」を目標に据えています。会社組織やコミュニティ、社会に対して「便利なもの」を提供し、社会をより便利にしたいという思いを言語化しています。
一方でエンジニアになってからの日も浅く、自分がなにかの価値を提供していけるほどの力を持ち合わせているとは思っていません。少しでも世の中になにか出来る力を付けたいという思いもあり、特にここ半年間、プライベートな時間のほとんどはカンファレンスや自主的な学習に充てていると思います。技術的な学習をしている背景は、「自分より若く優秀な人材がいることを理解していること」と「純粋に楽しいこと」の両方を持ち合わせています。
今現在はWebアプリケーションをインフラからフロントエンドまで広く見られるようになりたいと感じ始めています。そのための自分のスキルもまだまだ不足してる現状も理解していますので、少なくとも今のように学習を続ける生活はまだまだ続けます。
技術的な興味は、言語レベルではKotlin、Go、Clojureです。学習を始めていない理由としては、オブジェクト指向やデザインパターンの知識がまだ無く、別の言語に横展開できる状態になっていないと思っているからです。逆にそこを身に着けてからは言語の横展開もしていきたいと考えています。
インフラやサーバーサイドの話ばかりでしたが、フロントエンドも興味がありReactもしくはVue.jsをやりたいと思っています。
自分の強み
性格的なものは先日書いたストレングスファインダー記事を読んで頂くと掴みやすいかと思います。割と現在の性格を色濃く反映していると納得している結果です。
能力的な強みと呼べるものはまだありませんが、強いて挙げるとすれば学習と成長への意欲でしょうか。アプリケーションをインフラからフロントまで見られるようになるまでは学習を止めるつもりはありません。
転職の軸
技術の様々な方面に興味があり、フロントエンド、サーバーサイド、インフラなど広くやらせてもらえる環境だと長く在籍すると思います。そのため、転職の軸は下記になるかと思います。
- フロントエンド、サーバーサイド、インフラなど役割を問わず挑戦させてくれること
- フレームワークはLaravel、もしくはCakePHPのプロダクトがあること
- VCSはGitHub（次点でGitLab）を使用している
- ReactもしくはVue.jsを使用している
連絡先
もし読んでいただいて、カジュアル面談などお誘い頂けるようでしたら是非Twitter上で一旦リプライ頂き、DMでやり取りさせて頂けますと嬉しいです。レスポンスする時間帯は9時-11時または20時-24時頃になると思います。ここまで拙い文章を読んで頂きありがとうございました。
DockerでPHP開発環境を作ってみました
リポジトリ
目的
- 業務でDockerを使わないため、Dockerを使った開発を個人で経験する
- Data Volumeの理解を進める
- 今後、個人で開発＆運用するための基盤にする
単純にDockerを使いたかった
構成コンテナ
ディレクトリ構成
. ├── app ├── docker | ├── mysql | | └── my.cnf | ├── nginx | | ├── Dockerfile | | └── fpm.conf | └── php | ├── Dockerfile | └── php.ini ├── logs | ├── mysql | ├── nginx | └── php ├── .env └── docker-compose.yml
docker-compose.yml
version: "3" services: php-fpm: build: context: ./docker/php args: - TZ=${TZ} ports: - 9000:9000 volumes: - ./app:/var/www/html - ./logs/php:/var/log/php working_dir: /var/www/html environment: - TZ=${TZ} nginx: build: ./docker/nginx depends_on: - php-fpm ports: - 80:80 volumes: - ./app:/var/www/html - ./logs/nginx:/var/log/nginx working_dir: /var/www/html db-mariadb: build: ./docker/mysql volumes: - db-store:/var/lib/mysql - ./logs/mysql:/var/log/mysql environment: - MYSQL_DATABASE=${DB_NAME} - MYSQL_USER=${DB_USER} - MYSQL_PASSWORD=${DB_PASS} - MYSQL_ROOT_PASSWORD=${DB_PASS} - TZ=${TZ} volumes: db-store:
こだわった点
Data Volumeを使う
目的にも書きましたが、Data Volumeの理解を進める目的で今回このdocker-composeとDockerfileを書きました。docker volume lsやdocker volume rmなどのコマンド、Data Volumeの性質などの理解が深まりました。
MariaDBを使う
正直なところMariaDBとMySQLのどちらが優れているという判断は筆者は出来ません。しかし、MySQLのオリジナルのソースコードの作者がMariaDBの作者である事実と、MariaDBがOSSであることの2つの理由からMariaDBを扱っておくことにはOSSを扱うことに慣れるという意味を含んでいると判断し、今回の構成にしました。
コンテナ技術をより深く理解するために、JSTに設定するタスクは最適でした。筆者の開発環境がWindowsホストのためパーミッションの問題にぶち当たり、Linuxとの差を実感しつつWindows機で開発する時の注意点を実感できました。
今後の目標
今回のdocker-composeを更に開発し、個人的に開発するWebアプリケーションの基盤としたいという思惑があります。そのため、今後Laravelやredisなどをcompose、コンテナに追加していく予定です。
参考にさせていただいた記事
今後とも個人での学習を継続していこうと思います！
自分の学習スタイルに関する考察
皆さんおはこんばんにちは。ぐーどらです。突然ですがDockerとDocker ComposeでPHPの開発環境を作ってみました。構成は下記です。
近いうちにGitHubリポジトリを公開しようと思います。公開した時はまた別の記事で躓いたところなどを書きたいと思います。
（追記）書きました。
今回の記事は制作物を作った経験を抽象化して、自分の学習方法の最適化と効率化を狙ったオレオレ記事になります。
今回のことを記事に残す理由
独自ドメインとVPSを契約しているので、折角なら自作のアプリケーションをコンテナ化して運用したい思いがありました。
しかし開発職へ転職し初年度であることや職場でDockerを使った開発をしていないなどの要素が合わさり、Docker自体の学習速度が出ていませんでした。
しかし興味本位でData VolumeやVolumeコンテナなどの記事を読み、Docker Composeでの開発環境を自作したことで、Volumeへの理解が急激に進みました。そこで速度が上がった要因を分析しようと思います。
考えられる要因
- 学習のスコープを絞り、Data VolumeとVolumeコンテナのみの理解に努めた
- 概念の理解を深めるために適した良い記事を見つけることができた
- 理解したものを使用して実装する記事も見つけ、実装してみた
今後の学習への活かし方
- 学習する際に網羅的にやろうとしがちなため、学習する対象を絞る（Dockerという漠然としたテーマではなくVolumeに絞ったように）
- 概念的な部分を理解するための記事、書籍などを読む
- 実際に小さいものを実装すると決め、理解を必要とするものから学習を進める
だいぶオレオレ記事でしたが、以上のことを今後活かして学習を進めていきたいと思います。
