タグ

2020年9月5日のブックマーク (5件)

  • Splashtop Business(mac→Windows10)の日本語入力切り替えを「英数」「かな」キーでしたい男 - Qiita

    私の職場ではリモートワークのツールとして、Splashtop Businessを使用しています。 しかし、自宅がmac、リモート先がWindowsなのです... macでSplashtop Business 使うと日本語入力しにくい macは「英数キー(スペースの左)」で英字入力。「かなキー(スペースの右)」で日本語入力。 でも、リモート接続先だと以下のようなキーマッピングにされているんです。 英数キー → 「caps lock」 かなキー → 「@」 commandキー → 「Windowsキー」 普段macを使用している私は、こんなんじゃ日本語入力できないってなってしまうわけです。 そこで以下の方法で解決することにしました。 mac側で「英数キー」「かなキー」に、2つのキーの組合せを設定してする リモート先で「1.」の組合わせに、IMEの有効化/無効化を設定する。 ついでに、mac側で

    Splashtop Business(mac→Windows10)の日本語入力切り替えを「英数」「かな」キーでしたい男 - Qiita
  • 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ

    システム開発の世界において「技術的負債Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

    【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
    manhole
    manhole 2020/09/05
    “負債の返済手段はリファクタリングであり、リファクタリングの目的は自分たちのドメイン理解と現時点のプログラムの乖離の解消です。”
  • チームの改善のためにベロシティを計測することへの懸念

    アジャイルチームは自分たちのスプリントごとのベロシティを計測する。そうすることで彼らは、計画をたて、進捗をトラッキングし、プロダクトオーナーにプロダクトのリリースプランを作るための手がかりを与えることができるようになる。チームは、自らを改善したいときに、ベロシティのデータを利用できるのだろうか? 何人かの著者がベロシティについて書いており、チームの生産性を高めることを目的としてベロシティを計測することについての懸念を伝えている。 Catia Oliveira 氏はScrum AllianceのWebサイトで「チームとプロダクトに役立つベロシティの計測と活用のしかた」について書いた。彼女は、ベロシティの計測がチームにとってどんな役に立つのかについて、このようにまとめている。 自分たちのベロシティがわかれば、こんなことがわかるようになるでしょう。 どれだけの価値を今までに届けたか(ストーリーポ

    チームの改善のためにベロシティを計測することへの懸念
    manhole
    manhole 2020/09/05
    "ベロシティが予測可能性よりも価値の高いものではないからです"
  • 1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita

    1. はじめに 稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり積極的に今のやり方を変えようと思っていないチーム メンバーは、中堅(私)が1名と入社2年目と3年目の3人(後に新人が配属して途中から4名に) 全員、技術記事を書いたことがない 全員、社外の勉強会などのイベントに参加したことがない 全員、開発知識は、業務で教え

    1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita
  • ユーザーにとってどれだけ価値を提供できたかで生産性をお手軽に計測した話 - Qiita

    はじめに あるプロダクトの開発チームの生産性を計測したいと思いました。 昔は、開発したソースコードの行数で生産性を計測していたと思います。ただ、ソースコードの行数では、正しく生産性は計測できないと言われています(例えばこちらの記事など)。 では生産性は、どうやって算出するのが良いのか、具体的な方法(そのまま真似できる方法)を探したのですが、見つからなくて困っていました。 ということで、生産性を計測する方法を考案して計測してみた結果、そこそこ良い効果があったので、その方法を紹介します。 成果とは何か [生産性] = [成果] / [かかった工数] で算出する前提とします。ということで、まず成果とは何かを考えます。 たくさんソースコードを書いても、たくさん関数を作っても、たくさんデプロイしても、それが顧客の価値につながらなければ意味がないように思います。 だからファンクションポイント法や d/

    ユーザーにとってどれだけ価値を提供できたかで生産性をお手軽に計測した話 - Qiita
    manhole
    manhole 2020/09/05