インフラチームの西川です。 当社ではGitHubを利用しています。いろいろ便利な機能があるのですが社内でコマテクを募集してみたところ意外と知らないものがあったので共有してみます。 行動の見える化 特定コミットのリンク取得 通知 行動規範 ガイドライン .github リポジトリ テンプレートリポジトリ タグをたくさんプッシュさせない ドラフトプルリクエスト チケットの自動リンク化 ベースブランチの更新を取り込む まだレビューが終わってないプルリクエストの一覧化 レビュアーの自動割り当て コードの所有者 ファイル単位でレビュー済みをチェックする レビュー中のファイルを全部閉じる 具体的な修正を提案する レビューコメントをラベル化 デプロイ管理 リリースノートを自動作成 行動の見える化 以下の設定をすることで、GitHub上の行動を見える化することができます。 docs.github.com

これまで私はプロダクトマネジメントやデザインディレクションを行う立場として、BtoBにBtoC、iOSにAndroidにWebにWatchOSにIoT、ゼロイチにグロース。様々な分野、プラットフォーム、フェーズでサービスを開発する機会に恵まれてきました。 その中で一緒にチームを組んだフロントエンド、サーバーサイド、iOS、Android、インフラ、データ、様々なエンジニアの方を思い出しながら「ああ、心強いな」と感じた色々なタイプの特徴を、リスペクトの想いを持って、プロダクトマネージャーやデザイナーの視点でまとめてみました。 それではいってみましょう。 目的にフォーカスしている 要件をただ実装するのではなく、ビジネスの目的はなにか、ユーザーが真に求めているものはなにか、なにがサービスの生死を分けるのか、技術は目的を達成するための手段だと客観的に捉え、真の目的に対して解決策を提案し続けてくれる

この記事では次のブログの内容を参考にしながら、バンドルサイズに優しい tree shakeable な JavaScript ライブラリの作成方法について紹介します。細かい内容が気になる方は、是非原文の方もご確認ください。 作成方法のまとめ 結論から知りたい人向けに、まずは作成方法のまとめから記述します。バンドルサイズに優しい tree shakeable な JavaScript ライブラリを作成するためには、次の点に気をつけると良いです。 ESM 形式でライブラリを配布し、package.json の module フィールドを指定する ライブラリで使用する npm パッケージも可能な限り tree shakeable なものを利用する １つのファイルにバンドルせず、モジュールツリーの構造を保持したまま配布する package.json の sideEffects フィールドに fal

概要 データ移行やAPIの検証等で大量のデータをkintoneのアプリに登録する方法について書きます。 環境 macOS 10.15.7 cli-kintone 0.13.0 cli-kintoneについて 以下を参照ください。 読み込みデータ Geolonia 住所データを利用します。 Geolonia 住所データ 全国の町丁目、大字、小字レベルの住所データ（277,191件）をオープンデータとして公開いたします。 本データは、国土交通省位置参照情報ダウンロードサービスで配布されている「大字・町丁目レベル位置参照情報」をベースとしていますが、「大字・町丁目レベル位置参照情報」データは年に一回更新であるのに対して、本リポジトリで配布するデータは毎月更新しています。

本日9月23日は、B'z・稲葉浩志さんの誕生日です。 そこで質問。B'zの好きな楽曲を1曲だけ挙げてください。

サービシンクの名村が25年に渡るWeb制作のプロジェクトマネジメントで「テキストで情報を伝える」上で認識齟齬に至る点を洗い出した「誰がどう見てもそうとしか受け取れない文書術」のセミナースライドの2020年3月29日公開版です。 Web制作・システム開発に関わる人以外には事例等が分かりにくいかもしれませ…

実行しなければならないことは、それが実行されないとストレスが溜まるようにデザインする。やる気という積極的なモチベーションが十分にあるなら不要かもしれないが、やる気があるなら大抵の場合はすぐに実行されており、やる気が湧かないからこそタスクとして残るといえる。そういう場合は、やる気とは違う消極的なモチベーションに頼ることをする。 たとえばTODOの管理は、タスクが残っている状態が不快であるようにする。間違っても、タスクが整然と並んでいる様子に満足感を覚えるようなデザインではいけない。残っているタスクが常に意識にちらつき、さっさと片付けないとイライラするような仕方を心がける。たとえばディスプレイや作業スペースにベタベタと付箋を貼り付けるのは、その見栄えが悪いことに意味がある。片付けたくなるように、あえて散らかすことに意味がある。 積読もそうしたデザインと捉えられる。物理的に本を積み上げてデスクや

howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。

組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

めもりーさんと語るFindy Engineer Lab オフ会＠東京 LT https://findy.connpass.com/event/294069/