タグ

ブックマーク / dev.classmethod.jp (150)

  • Ryuzee氏に学ぶ『エンジニアリングマネージャーのしごと』 #Forkwell_Library | DevelopersIO

    近年は、エンジニアを束ねるエンジニアリングマネージャー(EM)を採用する組織が増えています。 デリバリーに軸足を置くプロダクトマネージャーに対して、EMエンジニアのピープルマネージメントに軸足を置いています。 そんなEM渇望の一冊が、先月末にオライリーから出版されました。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 : James Stanier 社内でも、今週月曜から部門横断の読書会が始まったばかりです。 その翌日に、Forkwell のイベントで同書の翻訳に関わった 吉羽龍太郎/@ryuzee 氏によるエンジニアリングマネージャーに関する講演を視聴する機会がありましたので、かんたんにレポートを共有します。 Forkwell イベント概要 エンジニアリングマネージャーのしごと - Forkwell Library #5 - connpass 公式レ

    Ryuzee氏に学ぶ『エンジニアリングマネージャーのしごと』 #Forkwell_Library | DevelopersIO
  • 自己流の手順書フォーマットを公開してみた | DevelopersIO

    手順書フォーマットは千差万別 みなさんは自己流または、組織やプロジェクトで定められた手順書のフォーマットはありますか? 私は自己流の手順書フォーマットがあります。 自己流の手順書フォーマットがあるといっても、かなり扱いがふわふわしているので、備忘やメモの意味合い強めでまとめていきます。 「もっとこうした方がいいよ!!」などフィードバックがあれば、ぜひお願いします! いきなりまとめ 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書はgitで管理する 5W1Hを意識して手順書を書く 基的にはCLIを使った手順書にする 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書をExcelやスプレッドシートで書くメリット・デメリット 手順書をExcelやスプレッドシートで書いている方も多いと思いますが、私はMarkdownで書いています。 Exce

    自己流の手順書フォーマットを公開してみた | DevelopersIO
  • secretlint を使って機密情報を git commit できない環境を作る | DevelopersIO

    AWSアクセスキーセキュリティ意識向上委員会って何? 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 tl;dr 開発をはじめる前に、次の手順を実行しよう シェルスクリプトの保存 次のシェルスクリプトを ~/.git-template/hooks/pre-commit として保存しよう。 #!/bin/sh FILES=$(git diff --cached --name-only --diff-filter=ACMR | sed 's| |\

    secretlint を使って機密情報を git commit できない環境を作る | DevelopersIO
  • TypeScript で記述した Google Apps Script を clasp と GitHub Actions を使ってデプロイする | DevelopersIO

    TypeScript で記述した Google Apps Script を clasp と GitHub Actions を使ってデプロイする TypeScript で記述した Google Apps Script を clasp と GitHub Actions を使ってデプロイし、トリガーを使った定期実行をしてみました。 @google/clasp を使うことで CLI で Google Apps Script (GAS) を扱えるため、コードを Git で管理できるようになります。 今回はコードを GitHub で管理し、テストと clasp push を Github Actions で実行できるようにしてみます。 最終的な完成物は下記のリポジトリになります。 https://github.com/hbsnow-sandbox/clasp-github-actions-exampl

    TypeScript で記述した Google Apps Script を clasp と GitHub Actions を使ってデプロイする | DevelopersIO
  • くらめその情シス:社内基幹のIdPをAzureADに切り替えたおはなし | DevelopersIO

    はじめに どうも、情シスやってますアノテーションの徳道です。 社内のMDM移行もいろいろ目途がつき、2021年2月にGoogle WorkspaceやSalesforceなど社内基幹のシングルサインオンをAzureADに切り替えました。 1年近くほぼAzure関連の導入・運用検討をしつつ記事を書いてきましたが、ここが一つの区切りかな、というところです。 今回はXデーにAzureADをIdPとしたシングルサインオン設定の設定事例(主にハマったポイント)を紹介します。 Special Thanks:植木 和樹 基幹システムのシングルサインオンの構成 今回設定したシングルサインオンの構成を図で示します。SAML2.0認証が可能なSaaSについて今後追加されていくことになります。 IdPの設定準備 AzureADエンタープライズアプリケーションでSAMLによるシングルオン設定は以前の記事でも紹介し

    くらめその情シス:社内基幹のIdPをAzureADに切り替えたおはなし | DevelopersIO
  • 管理職のための役職引退マニュアル | DevelopersIO

    はじめに クラスメソッド株式会社で取締役及びAWS事業部の部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業部の部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって部長を引退することにしました。 部長や部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は部長という役職で、事業部の中に部があり

    管理職のための役職引退マニュアル | DevelopersIO
    braitom
    braitom 2021/02/27
    ふむ。“大事なのは自分と全く同じ事ができる人ではなく「あるポイントにおいて自分よりも優れている人」を選出して育成することです。”
  • 2020年版 モダンアプリケーションでのDB選定 | DevelopersIO

    目的別データベース選定 それぞれのDBの特徴や特性を軽く紹介していきます。 リレーショナル(Amazon Aurora) RDSに管理されるMySQL/PostgreSQL互換のRDBです。 RDSのMySQL/PostgreSQLと比較したAuroraのメリット 対障害性 並列クエリ Global Database パフォーマンス: MySQLの最大5倍, PostgreSQLの最大3倍高速 RDSでは特段理由がなければ、Auroraを選択することになるかと思います。 適しているユースケース ERP CRM 財務・銀行 SaaS(マルチテナントアプリケーション) 構成要素 DBCluster DBInstance プライマリインスタンス(Writer)(書き込み/読み込み) Auroraレプリカ(Reader) エンドポイント クラスターエンドポイント 読み取りエンドポイント カスタムエ

    2020年版 モダンアプリケーションでのDB選定 | DevelopersIO
    braitom
    braitom 2020/12/09
    AWSのマネージドなデータベースの比較。各データベースの特徴や特性についてまとめられている。
  • AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO

    こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと

    AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
    braitom
    braitom 2020/07/28
    AWSでシステムを作るときの非機能要件ヒアリングシート。可用性、運用などのカテゴリごとに確認項目が書かれている。これはよい。
  • レビューしやすいプルリクエスト | DevelopersIO

    普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ

    レビューしやすいプルリクエスト | DevelopersIO
    braitom
    braitom 2020/07/16
    レビューしやすいPRについて。差分の目的が1つ、分割されすぎていない、ファイル間の関連が分かるなど。
  • Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO

    開発時にはみなさん GitGitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な(と考えている)ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid

    Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
    braitom
    braitom 2020/04/09
    GitHubでチーム開発を行うときのガイドラインについて。commit時、PR時、merge時に分けてシンプルにまとめられている。
  • 知っておくと便利かも!!レピュテーションサイト3選 | DevelopersIO

    こんにちは!! 筧( @TakaakiKakei )です。 突然ですが、不審な通信を検知した時に、当に危険な通信であるかをあなたはどのように判断しますか? 今回はこんな時に判断材料の1つとして役立つ、レピュテーションサイトを紹介します! 紹介するサイトで送信元 IP を調査することで、悪意のある攻撃者からの通信かを判断する一助になるかもしれません。 それでは早速やっていくっ!! 今回紹介するサイト 以下の3サイトを紹介しますっ! VirusTotal AbuseIPDB aguse 1. VirusTotal VirusTotal VirusTotalの説明を Wikipedia より引用。 VirusTotalとはファイルやウェブサイトのマルウェア検査を行うウェブサイトである。ファイルをVirusTotalにアップロードしたりウェブサイトのURLを指定すれば、そのファイルやウェブサイト

    知っておくと便利かも!!レピュテーションサイト3選 | DevelopersIO
    braitom
    braitom 2020/03/19
    IP レピュテーションサイトのまとめ
  • テレワークでも100%パフォーマンスを出すための企業カルチャーの作り方 | DevelopersIO

    はじめに 新型コロナウイルス(COVID-19)の影響により、在宅を含めたテレワークの導入が急激に進んでいます。先週発表されたマーサージャパン株式会社のプレスリリースでは、調査対象企業の8割が何らかの形で全社又は一部部門にてテレワークを実施しているとの発表がありました。 クラスメソッド株式会社でも全オフィスを閉鎖し、原則全社員リモートワーク(在宅勤務)の体制となっております。とは言え、クラスメソッドでは東日大震災を契機として一貫してリモートワークを推奨してきましたので、大きな影響もなく業務を遂行できています。しかし、これまでテレワークを導入していなかった方々にとっては、突然在宅勤務をしろと言われても戸惑うことも多いのではないでしょうか。 勤怠管理、業務評価、人事考課、工数管理、健康管理、コミュニケーション...昨今では多くのSaaSサービスが提供されており、テクノロジーの観点ではほぼ全て

    テレワークでも100%パフォーマンスを出すための企業カルチャーの作り方 | DevelopersIO
  • 勉強会生放送の技と真髄 | DevelopersIO

    事業開発部の塩谷 (@kwappa) です。 新型コロナウイルスの感染拡大にともない、人が集まるイベントの中止や延期が相次いでいます。我々エンジニアとしても、勉強会やカンファレンスなどが中止になることで、影響を感じざるを得ない状況です。 ぼくも登壇予定だった勉強会が2件中止になったり、出展予定だった「技術書典8」が中止になったりして、残念な思いをしています。中止を決めた主催者の方々が一番つらかったろうな…。心中お察しします。 とはいえ、エンジニアとしては勉強して腕を磨いていくことを止めることはできません。無用なリスクをとることなく、コミュニティや勉強会による「学び」を継続していくためにはどうしたらいいんだろう?SNSなどを眺めていると、同じ課題感を持った人たちから「オンライン勉強会」というワードが聞こえてくるようになりました。 そういえばぼくも先日、社内向け勉強会にオンラインで登壇したばか

    勉強会生放送の技と真髄 | DevelopersIO
    braitom
    braitom 2020/03/07
    イベントのオンライン配信のノウハウがまとめられている。
  • エンジニアが技術登壇する時に考えるべき事 | DevelopersIO

    社内の登壇勉強会で登壇したときの資料です。基的にはまだ登壇にあまり慣れていない人向けの内容になってますが、当日参加した他のベテラン登壇者の資料も紹介しているので、誰にでも参考になると思います。 「みんな、登壇するとき、何に気をつけて喋ってんの?すげぇ聞きたい」 そんな素朴な疑問から、「登壇勉強会〜それぞれの流儀がそこにある〜」という社内イベントを企画しました。登壇者は自分含めて3人。 当日他の登壇者(藤村、塩谷)という歴戦のツワモノの発表を聞いていて思ったんですが、はっきり言って登壇って100人100様です。めっちゃ個性がでまくります。 唯一の正解なんてなく、それぞれが独自のやり方で登壇の技を磨いているんだなぁと心底思いました。これ自分が企画した勉強会でしたが、自分が一番楽しんでたと確信してます。このブログでは、自分が普段登壇する時に気をつけているところを主観丸出しで書いてます。「それぞ

    エンジニアが技術登壇する時に考えるべき事 | DevelopersIO
    braitom
    braitom 2020/03/02
    カンファレンスや勉強会で登壇するときのポイントまとめ。登壇する機会の作り方、内容のストーリーの作り方、話し方のポイントなどが書かれている。
  • リモートワークのオンライン会議やペア作業で心がけている8つのTips | DevelopersIO

    クラスメソッドのリモートワーク(テレワーク・在宅勤務)は、リモートワークをすることが目的ではなく、より良い成果を出す手段の1つです。 そんなリモートワークですが、私自身は「オンライン会議(朝会)」や「ペア作業(ペアプロ)」等をすることが多いです。 下記の記事を見て、「みんな色々と考えているんだなぁ」と思い、私も含めた参加メンバーが少しでも効率よく・気持ちよく作業するために心がけていることを書いてみることにしました。 やっぱり難易度の高い在宅勤務をちょっとでもうまくやるために心がけていること | Developers.IO 心がけていること リアル対話と比べて、オンライン対話は情報量が減ります。表情・身体の動き・声色などです。 これらをオンライン対話でも意識的にやっていこう!という考え方です。 顔芸をする オーバーリアクション 相づちを打つ 手を挙げる 問いかけの場合は、最初に相手の名前を言

    リモートワークのオンライン会議やペア作業で心がけている8つのTips | DevelopersIO
    braitom
    braitom 2020/02/26
    確かにオーバーなくらいリアクションしないとダメだよなと思った。
  • 心温まるSlackの投稿を抽出するためにサーバーレスなデータ分析基盤を構築しよう!! | DevelopersIO

    CX事業部@大阪の岩田です。 クラスメソッドでは社内標準のチャットツールとしてSlackを活用していますが、「分報」という形でSlackを活用しているメンバーも数多くいます。「分報」って何?という方は以下のリンクをご確認下さい。 社内にSlack上での分報を導入しないかと提案してみた Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう Slackで「分報」を導入したらめっちゃ作業効率があがった 人気の分報ともなると参加者が50人を超え、人のいないところで好き勝手に雑談が繰り広げられていたりします。このレベルになると人気が高いのか、それとも単に治安が悪いだけなのかよく分からなくなってきます。 「俺の分報がこんなに治安が悪いわけがない!Comprehendで証明してみた」ブログはよ ?!!! ということでSlackの投稿を

    心温まるSlackの投稿を抽出するためにサーバーレスなデータ分析基盤を構築しよう!! | DevelopersIO
    braitom
    braitom 2020/02/25
    Slackの投稿を感情分析しPositiveな投稿を抽出する方法について。Amazon comprehendで感情分析、S3に保存してAthenaで集計。おもしろいな。
  • MacのTerminalでsudo実行時にタッチIDを使用する方法 | DevelopersIO

    こんにちは、CX事業部の夏目です。 MacのタッチバーのタッチIDが非常に便利なのですが、Terminalsudoを叩かないと行けないときに使えたらなぁと思ったので、情報を共有します。 使う方法 /etc/pam.d/sudoにauth sufficient pam_tid.soを追加します。 書き込みには管理者権限が必要になるので次のようにして編集します。 # 自分の環境では最初管理者でも書き込みができないようになってたので、できるようにする $ sudo chmod +w /etc/pam.d/sudo $ sudo vi /etc/pam.d/sudo もともとはこんな感じになっていると思うので、 # sudo: auth account password session auth sufficient pam_smartcard.so auth required pam_ope

    MacのTerminalでsudo実行時にタッチIDを使用する方法 | DevelopersIO
    braitom
    braitom 2020/02/23
    MacのTerminalでsudoするときにTouch IDを使えるようにする方法について。便利。
  • カオスエンジニアリングツールGremlinにてネットワーク障害を注入してみた #reinvent | DevelopersIO

    カオスエンジニアリングツールGremlinは、システムに障害を注入することができるサービスです。 エントリでは、Network Gremlinsを利用して、ネットワーク障害(トラフィック遅延、損失など)を注入してみたいと思います。 カオスエンジニアリングツールGremlinは、システムに障害を注入することができるサービスです。 エントリでは、Network Gremlinsを利用して、ネットワーク障害(トラフィック遅延、損失など)を注入してみたいと思います。 以下のようなイメージです。 前提 Gremlin PROアカウント Gremlin Freeではネットワーク障害が利用できないのでご注意ください 参考:Pricing やってみた Gremlin Clientインストール まずは、カオス実験(以下、攻撃)の対象となるサーバに、Gremlin Clientをインストールします。 以下

    カオスエンジニアリングツールGremlinにてネットワーク障害を注入してみた #reinvent | DevelopersIO
    braitom
    braitom 2020/01/01
    Chaos EngineeringシミュレートツールGremlinについて。レイテンシー攻撃、パケットロス攻撃、DNSブロックなどのテストができる。
  • Amazon API Gatewayは「HTTP API」と「REST API」のどちらを選択すれば良いのか? #reinvent | DevelopersIO

    Amazon API Gatewayの新機能「HTTP API」 re:Invent 2019期間中、Amazon API Gatewayの新機能「HTTP API」が発表されました。現在プレビューとして、US East (Ohio), US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), EU (Frankfurt), EU (Ireland)で提供されています。 HTTP APIはREST APIの上位互換というわけではなくAPI Gatewayのコアな機能に特化して低コストで利用したい場合に適した機能という位置付けになっています。つまりREST APIと比較するとできないことがいくつかあります。 記事では以下のドキュ

    Amazon API Gatewayは「HTTP API」と「REST API」のどちらを選択すれば良いのか? #reinvent | DevelopersIO
    braitom
    braitom 2019/12/31
    API GatewayのHTTP APIとRest APIの比較。認証、連携、デプロイ、セキュリティなどのカテゴリごとに機能の比較が書かれている。
  • テキストコミュニケーションを円滑に進めるコツ | DevelopersIO

    こんにちは!入社して11カ月目を迎えました。たなぱんだです。 前職ではTV制作ディレクターやアパレル販売員など、人と接する仕事をしていました。 そんな私が入社して1番最初のカルチャーショックは、社員同士のコミュニケーション手段がチャットだったことです。 わたしはテキストコミュニケーションはビジネスメールしか使ったことがありませんでした。 どのくらい砕けた話し方がOKなのか。絵文字は使ってよいのか。メンション(通知)は使ってよいのか。勤務時間外でもメンションしてもよいのか……などなど、今までのコミュニケーションの取り方の違いにとても戸惑った記憶があります。 実際は、クラスメソッドの皆さんはそんな非言語コミュニケーションの壁をもろともせず、年齢や性別、住んでいる場所の違いを乗り越えて活発にコミュニケーションをとっています!(ステキだね) 今回は、私が入社10か月間で得た「テキストコミュニケーシ

    テキストコミュニケーションを円滑に進めるコツ | DevelopersIO