Draw.ioというサービスをご存知ですか?
知らない人や聞いたことはあるけど使ったことない人が、今すぐ使いたくなる魅力を10コ伝えてます。
続きを読むこんにちは。久しぶりの投稿となります。斉藤です。
新型コロナウイルスの感染拡大に伴う緊急事態宣言が発令されて2週間となりました。
大変な世の中となっておりますが、弊社で行っている取組みとリモートワークになった所感を共有します。
続きを読むどうも小野です。
弊社はフレックスタイム制度が正式に導入されているわけではありませんが、就業規則に記載されている就業開始時刻の前後1時間の範囲内であれば、スケジュールに予定として登録することで可能になっています。通常は9時半開始なので、8時半〜10時半の間でシフトが可能です。もちろん、早出、遅出の分、終了時刻も変わります。ここはフレックスと同じです。
私は毎週水曜日は子供の習い事のお迎えがあるため、30分早出(9時出勤)してたのですが、今まで遅出をしたことはなかったので、今回、1時間遅出をしたらどうなったか検証しました。
普段は子供が登校するまで、子供の相手をするので自分の時間がなかなか取れません。1時間遅出にすることで、朝の時間を有効活用することが出来ます。
ちなみにこの日行ったことは、以下の通りです。
このように、有意義な朝を過ごすことができ、「1時間という時間」以上の価値があると感じました。
通勤ラッシュ時間帯は大体7:30〜9:30あたりなので、1時間遅出にすることで、通勤ラッシュの時間帯が過ぎたあとに通勤することができます。
座席には確実に座れるわけではありませんが、空いているのでとても快適です。 ストレスの原因の1つとして、満員電車があるので、これが解決できるのはだいぶ大きいです。
朝ほどではありませんが、帰宅ラッシュも避けられます。これは遅出をしたことによって、業務時間も後ろに延びるためです。 仕事終わった後にまた満員電車もきついですよね。このストレスからも開放されます。
そもそも出社しないリモートワークが一番望ましいのですが、社員の状況が見えないなどの不安もあり導入しづらい部分もあるので、まずはフレックス導入をして日々のストレスから開放されましょう。 弊社では、リモートワークも作業報告をするという条件付きで行っています。
どうも、小野です。
毎年恒例である、翔泳社主催の「Developers Summit 2020」(通称デブサミ)に行ってきました。
今回のテーマは、
「ともにつくる」
です。
場所は昨年と同様、目黒にある雅叙園でした。今回のようなジャンルを問わないイベントは各業界の人が集まってくるので、会場はとても混み合っていました。 来場者数に対しての、会場のキャパが足りてないように感じました。
今回、私が参加したセッションは以下の通りです。
どうも、小野です。
今回は、Springがメインのイベント「Spring Fest 2019」に行ってきました。
springfest2019.springframework.jp
過去にも何回か開催されていたのですが、今回が初参加です。 懇親会まで参加したかったのでしたが、諸事情により途中で抜けました。
場所は御茶ノ水ソラシティでした。
イベントが開催されていたのはカンファレンスセンターというところだったのですが、 他はオフィスフロアになっています。こんなところで働きたいですね。
ここから、基調講演を聞いて印象に残った内容をご紹介します。
続きを読む
どうも、小野です。
今回は、LINE DEV DAY 2019 2日目のレポートです。
今年のLINE DEY DAY 2019は台場にあるグランドニッコーホテルで行われました。
LINE DEV DAYに参加して良かったポイントがいくつかあったのでそのご紹介と、印象に残ったセッションについてのお話したいと思います。
続きを読むどうも、小野です。
GitHub Actionsがついに一般公開されましたね。個人的には待ち望んでいた機能でもあります。
突然ですが、皆さんはCI/CDに何を使ってますか?
私は現在、業務でCI/CDにJenkinsを利用しています。 このJenkinsはAWSのEC2インスタンス上に構築しています。
と思う方もいらっしゃると思います。これには理由があります。
Jenkinsを使い始めたころは、まだCircleCIはありませんでしたし、ましてやAWSのCode系サービスもなく、 当時はJenkinsが主流でした。その頃から使い続けていたので、ある程度の知識も持っています。 あとは、ビルド、デプロイするためにそこまで複雑な設定はなく、カスタマイズも柔軟にできたという理由で使っていました。
Saas型のサービスは無料プランなどもあるのですが、業務で利用するスペックとなると、料金がかかってしまいます。 EC2のコストも掛かってるじゃん。と言われればそれまでですが。。。 あとは、Jenkinsから移行してまでのメリットが感じられなかったのが正直なところですね。
AWSのサービスは、環境ごとにルートアカウントを分けているので、どのアカウントのCode系を使えばいいかが明確でないし、 Code Build、Code Deployなど複数のサービスをまたがって使う必要があったため、個人的には敷居が高く感じました。
ここから本題です。
JenkinsからGItHub Actionsに移行を検討している理由を述べたいと思います。
月々2500円のTeamプランを利用しています。 実はGitHub Actionsは完全無料ではなくて、Privateリポジトリの場合は従量課金になります。 ただ、無料で利用できる範囲が加入しているプランによって変わってきます。
実行時間無料枠
プラン | 分/月 |
---|---|
Free | 2000 |
Pro | 3000 |
Team | 10000 |
Enterprise | 50000 |
無料枠を超えた場合、以下の料金がかかってきます。
OS | ドル/分 |
---|---|
Linux | 0.008 |
Windows | 0.016 |
MacOS | 0.08 |
つまり、Teamプランを利用しているので、月に10000分は実行できることになります。 今絶賛開発中のシステムのビルド時間が10分程度なので、1000回は実行できることになりますが、 実際は100回程度なので、実質無料で利用できるわけです。これでEC2の利用料が浮きますよね。
ちなみに、Publicリポジトリについては完全無料となっております。
ソース管理にはGItHubを利用しているので、親和性がとても高いです。(当たり前ですが) 例えば、他のサービスを利用する場合、PrivateリポジトリからPullする際に何かしらの認証情報を設定する必要があります。
あとは、ワークフローを実行するトリガーのパターンが多いです。 他のサービスの場合、大体PullRequestがマージされたタイミングで行うことが多いと思いますが、 GitHub Actionsの場合、Issueが登録された、ブランチが作成されたなど、GitHubで可能なアクションを数多く網羅しています。
ソースに変更がないのに、Issue登録トリガーでワークフローを走らせる意味あるの?と思うかもしれませんが、 ワークフローで定義できるJobも色々あって、例えばSlackに通知などもできるので、Issueが登録されたら、Slackへ通知とかもできます。
やはり、クラウドサービスを利用する際、サービスの将来が気になると思います。 昨年、GitHubはMicrosoftに買収され、今はMicrosoftの傘下になりました。 親がMicrosoftである以上、GitHubが消えることはないでしょう。
サーバはAWSのEC2を使っていますが、EC2の管理は自分たちで行う必要があります。 その上、Jenkinsのメンテナンスも必要になってきます。 GitHub Actionsの場合は完全フルマネージドなので、サーバを意識する必要は全くありません。
あとは、理由その1でも述べましたが、サーバ運用をやめることでランニングコストの削減にも繋がります。
絶賛調査中ですが、現時点では可能だと思ってます。結局、シェルが使えるので何でもできますよね。
あと、調査時のメモをまとめた記事がありますので、興味がある方は読んでみてください。
皆さんも、GitHub Actionsを使っていきましょう。