ToMo指数〜チームのモチベーションを可視化〜 - Qiita
あなたは何のために働いていますか？ お金（生存, 家族を養う, 趣味の満喫）がほしいから？ 誰かを失望させたくないから？ 楽しいから？ ToMo指数とは 「ToMo」は「Total Motivation」の略 日本語でいえば「総合的動機」 2016年に発売された「マッキンゼー流最高の社風のつくり方」という本で定義 労働の動機を6つに分類してそれぞれの動機に対する回答結果から算出 ToMo指数の概要 ToMo指数は、以下の6つの動機に基づいて計算されます。 直接的動機 楽しさ 仕事自体を報酬に感じる 目的 仕事の結果に価値が感じられる 可能性 仕事の二次的な結果が自分の価値観や信念と一致する 間接的動機 感情的圧力 自分や周囲からの失望/罪悪感/羞恥心 経済的圧力 報酬を得るため。 解雇されないため。 惰性 続ける理由もないが、やめる理由もない。 なんとなく。 ToMo指数を測ってみよう 以
「プラチナ企業」いろいろ考えますね。 - Ｍレポート
仕事関係の話、趣味の写真・映画の紹介、愛犬についての情報提供。オーラソーマ、ダイエットにもチャレンジ！ 今日の日経新聞１３面に「プラチナになれますか」というタイトルで プラチナ企業ランキングが紹介されている。 なんかそれらしいのですが、数字で具体的なランキングで社名が出ると そうかなと思ってしまう。 この記事の内容は 上場企業を「働きやすさ」と「働きがい」の2軸で類型化した。 業績との連動などを分析した。 働きやすさが高く、働きがいが低い企業を「ホワイト」、 その逆を「モーレツ」と分類した。 2つとも高評価な企業は「プラチナ」とした。 反対に2軸とも低評価な企業を「ブラック」と分類した。 確かに、この概念はわかりやすいですね。 これはこれである一面でとらえた会社の分類とするに値すると 思います。 でも、厳密にいえば、「働きがい」「働きやすさ」の低い企業が プラック企業かといえばそうでもない
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
GitHub Copilot Workspace: Welcome to the Copilot-native developer environment
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
note の Aurora MySQL を v2 から v3 へアップグレードしました｜tic40
note ではメインデータベースとして Aurora MySQL を採用し、日々発生する膨大なトラフィックを処理しています。Aurora MySQL v2 (MySQL 5.7 互換) の標準サポートは2024/10/31 に終了するため、これを機に v3 (MySQL 8.0 互換) へのアップグレードを行いました。 アップグレードは無事に完了しましたが、いくつかの問題にも直面しました。これらを共有することで、これからアップグレードを検討している方へ参考になればと思います。 事前に検討した課題アップグレード後に致命的な問題が起きたらどうするかv3 へのアップグレード後に v2 へ切り戻すことは容易ではなく、スナップショットなどからの復元が必要になります。データをロールバックすることになるため、ユーザ影響が極めて大きく避けたい事態です。 そのため、基本的に切り戻しはできないという前提でアッ
「Valkey」がRedisを急速に置き換えつつある ー バックエンドエンジニアは地殻変動に備えよう
4月20日、DevOps.comが「Valkeyが急速にRedisを置き換えつつある（Valkey is Rapidly Overtaking Redis）」と題した記事を公開した。 この記事では、Redisのソース利用可能なライセンスへの移行と、その結果として生じたValkeyへの大規模な移行について詳しく紹介されている。以下に、ポイントを絞って内容を紹介する。 Redisのライセンス変更による影響 ちょうど一ヶ月ほど前（3/20）、 RedisがBSD 3-clauseライセンスからRedis Source Available License (RSALv2)およびServer Side Public License (SSPLv1)へとライセンスを変更 した。 BSD 3-clauseライセンスは非常に寛容なオープンソースライセンスで、著作権表示と免責事項の維持が含まれるが、商用利用
アクセシビリティ改善プロジェクトを立ち上げました - Qiita Blog
はじめに こんにちは、Qiitaのデザイナーのかべちよです。 （最近はSUZURIさんで販売中のQiitaグッズをデザインしました ） Qiitaでは誰もがQiitaを利用できるように、アクセシビリティ改善プロジェクトを進めています。 今回はその取り組みの背景、現状、そして今後の展望についてご紹介します。 Qiitaがアクセシビリティの向上に取り組む理由 Qiitaは、「エンジニアを最高に幸せにする」というMissonを掲げています。 この「エンジニア」には、年齢や障害の有無にかかわらずあらゆる人たちが含まれます。 そのため、アクセシビリティ向上に取り組むことは私たちのミッション達成に必要であると考えています。 加えて、Qiitaは技術情報を共有するためのプラットフォームです。 環境や状態に関わらず誰でもQiitaを利用できるようにすることが、技術情報の共有をより促進できると考えています。
[アップデート]TerraformのProviderが関数を定義できるようになりました | DevelopersIO
2024/4/10にGAになったTerraformのVersion1.8にて、Providerが関数を定義できるようになりました。各Providerの開発者はそのProvider固有の問題解決に特化した関数を作成できるようになりました。 本エントリでは新関数たちを触ってみてレポートします。 Providerって？ Terraformをあまりご存じない方向けに説明すると、ProviderはTerraformのプラグインです。実はTerraform単体ではAWSのリソースなどをプロビジョニングすることはできません。AWSリソースをプロビジョニングしたい場合はAWS provider、Google Cloudのリソースをプロビジョニングしたい場合はGoogle Cloud providerなどといったように、対応するproviderと組み合わせてTerraformを使うことではじめてリソースをプ
![[アップデート]TerraformのProviderが関数を定義できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a77b081e14c8d61a2e80498092f8ffb9b60da03/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Fterraform-eyecatch.png)
ハイフンに似た文字が Shift_JIS でエンコードできない問題とその解決策 - Sansan Tech Blog
初めまして！ 2022年の3月に入社しました渡邉です。 現在はデータ戦略部という部署に所属しておりまして、多種多様なデータを収集・活用するためのサービス開発に携わっています。 タイトルにある通り、今更になって Shift_JIS と格闘する羽目になったのですが、その背景として長期に渡って稼働していたシステムの一部をリプレイスすることになったことがあります。 旧システムは他社のシステムとデータを Shift_JIS でエンコードしたファイルでやりとりしているのですが、これは他社が保守しているシステムとのファイル連携であり、リプレイスプロジェクト期間中に連携ファイル仕様を変えることは現実的ではないという判断です。 背景 突然ですが、皆さまはこれらの文字の違いがわかりますか？ 1. − 2. － 3. ー 正解はそれぞれ、 1. 全角のマイナス 2. ハイフン 3. 漢字の一 となっています。
なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog
CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
git worktreeを使ってプルリクレビューを効率化した話 - freee Developers Hub
共通マスタ基盤チームにおけるソフトウェアエンジニアのyugoです。 共通マスタ基盤チームは、従業員、商品、取引先といった製品横断で利用できるマスタデータを一元管理し、ユーザーにfreeeプロダクトにおける統合体験を提供できる基盤開発をミッションとしております。 そんな共通マスタ基盤チームチームですが、製品横断で利用されるとだけあり、日々の開発フローでPRレビューの割り込みが多いです。そんな中で、開発フローにgit worktreeを導入してみて、個人的にはPRレビューの割り込み作業時に割と使いやすかったので紹介します。 git worktreeを使うに至る背景 実はfreeeで働く以前、前職で先輩シニアエンジニアが「レビューするときにgitのstagingにあげていない自分の変更を、stashしたり、テキトーにcommitしてからrebaseするなりするの嫌だったら、worktree使った
非エンジニアがエンジニアとスムーズに話すために大切な「なんとなくわかる」 - Qiita
本記事の概要 非エンジニアの私ですが、これまでエンジニアと働く上で、「コミニュケーションが難しい」「言っていることがさっぱりわからない」みたいなよくある悩みを感じたことがないのですが、なぜなのかが最近言語化できた気がするので記事にしてみました。 結論、エンジニアのやっていることが「なんとなくわかる」というのが大事なんじゃないか、という記事です。 ※本記事を読んでいただいたエンジニアの方、「いやいやこれくらい知っておいてくれ」「こんなレベルじゃ話にならない」等あればツッコミお待ちしております！ 前提 これまで一緒に働いたエンジニアがいい人たちすぎて「わかりやすいよう歩み寄ってくれている」みたいなありがたい環境ということは大前提 Qiita株式会社でマーケティングやセールスに従事する私自身のエンジニア経験はゼロ Progate、ドットインストール等でHTMLやCSSをかじったことがある程度 業
プロダクト開発エンジニア全員で取り組むオブザーバビリティ | ドクセル
プロダクト開発エンジニア全員で取り組む オブザーバビリティ 株式会社ユーザベース 安藤裕紀 TechBrew in 東京〜オブザーバビリティのベストプラクティス〜 2024/4/11 00 自己紹介 安藤裕紀 / あんどぅ 株式会社ユーザベース NewsPicks事業 SRE Unit Leader SREチームのマネージャー 兼 テックリード 特技：AWSコスト削減や障害対応を愚直に100本ノックすること 好きなSREのプラクティス：非難なきポストモーテム文化 Incident Response Meetupというイベントを運営しています ©Uzabase, Inc. All Rights Reserved.
[アップデート]AWS Config が定期的な記録をサポートするようになりました: 変更追跡を効率的にスケールします #AWSreInvent | DevelopersIO
[アップデート]AWS Config が定期的な記録をサポートするようになりました: 変更追跡を効率的にスケールします #AWSreInvent AWS Configのリソース変更記録頻度を「Continuous」か「Daily」か選択できるようになりました！これよりConfigの構成変更の収集量とコストを削減できるようになります。 こんにちは！AWS事業本部のおつまみです。 AWS re:Invent 2023が始まってますね！ AWS Configでアップデート情報があったので、お届けします！！ 3行まとめ AWS Configのルール設定時に記録頻度を「Continuous」か「Daily」か選択できるようになった。 これまでは「Continuous」の記録のみであったため、構成変更のリソースが多い場合にはコストがかかっていた。 各々のメリットを考慮し、これからは記録頻度を選択する必
![[アップデート]AWS Config が定期的な記録をサポートするようになりました: 変更追跡を効率的にスケールします #AWSreInvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f099104aaa09df58f234f4f90b04b2f5cefbb675/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F11%2Feyecatch_reinvent-2023-newservice-update.png)
XZ Utilsにバックドア攻撃が行われるまでのタイムラインまとめ
2024年3月29日に、圧縮ツールの「XZ Utils」に、悪意のあるバックドアが仕込まれていたことが明らかになりました。どのようにバックドアが仕掛けられたのかについて、Googleのエンジニアであるラス・コックスさんが時系列順にまとめました。 research!rsc: Timeline of the xz open source attack https://research.swtch.com/xz-timeline XZ Utilsおよび設置されていたバックドアについては下記の記事で解説しています。 Red HatやDebianなどLinuxディストリビューションの組込み圧縮ツール「XZ Utils」に悪意のあるバックドアが仕掛けられていたことが発覚 - GIGAZINE XZ Utilsへの攻撃を行った「Jia Tan」という名前の攻撃者は2021年後半ごろから数年に渡ってXZ
Terraform 公式がスタイルガイドを出したので読んで要約した - Qiita
3/30 に X で Terraform がトレンド入りしていて何事かと思ったら Terraform が公式ドキュメントとしてスタイルガイドを出したようです。 Terraform Style Guide いままで Terraform のスタイルに関して信頼できるドキュメントといえば Google Cloud の Terraform を使用するためのベスト プラクティス ぐらいしか知らなかったのですが、 Terraform 公式がようやく出してくれてありがたい限りです。 これでわざわざ社内の Terraform 規約を設けずとも「公式ドキュメントに従いましょう。」の一言で済みます。 ということで一通り読んだのでまとめました。 原文だと構文の簡単な使い方なども書いてありますが以下の要約ではだいたい省略しています。 詳細は原文を読んで確認してください。 要約 スタイルガイドについて コードのスタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社エイチームコマーステック - Qiita
MySQL Bugs: #112767: SELECT COUNT(*) degraded performance on 8.0 compared to 5.7
How to Reset VS Code Settings
エンジニア基礎 ウィルゲート2024年度エンジニア新卒研修
