今、日本のAppStoreで「The Coffee Inc 2」という経営シミュレーションゲームが人気を博しています。その人気ぶりは、アプリストアランキングで一時マインクラフトやスイカゲームを超えるほ...
技術選定、してますか? こんにちは!エンジニアリングマネージャーの佐藤(@unsoluble_sugar)です! 今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。 エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc... 挙げだすとキリがないですよね。 個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。
列の項目はここではざっくりと言った通りなので、本来であれば注目すべき観点をもう1段掘り下げたものであるほうが良いでしょう。特にシステムはざっくりすぎるかなと思います。 場合によっては個々の言語の機能を表現する必要があります。 ただ、戦略という点に置いては機能そのものよりも、機能や言語がもたらす周辺効果にこそ注目する必要があるでしょう。 次に、◯や☓についてです。これは、現在と未来のギャップを考えたときに良いかどうかです。 基本的に未来に向けた選択をするため、既存の会社の標準やシステムのリプレースなどでの技術選定のときに現状維持が悪い影響を与えるときは問答無用でバツをつけるべきです。 使っている技術について尖りすぎていたり、陳腐化していたりすると、採用のスコアが悪くなります。 採用スコアは将来のチームの状況とも言えるので、よほどの狙った戦略が無い限りは◯を選ぶべきかと思います。状況によっては
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション)」という興味深いポストをX(旧Twitter)で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション) コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
使わない日はない、というほど身近な『Webブラウザ』。 でもよく考えてみたら、見えないところで結構色々やってくれているんじゃないか…?気になる!どうしたら作れるんだ! というわけでギリギリ最低限、GUIを描画してHello, world!するまでだけの仕様ですが、作ってみました。自作入門書というよりも、開発日記的な建付けです。 ※ご購入の際の注意:インプレスR&D様より同タイトルの商業版が発行されております。商業版は「Webブラウザの機能追加」の章を追加しているほか、価格が異なります。 第 1 章 はじめに 1.1 なぜ Web ブラウザを自作するか 1.2 本書の範囲 1.3 開発環境 1.4 構成を考える 1.5 開発の順番を考える 第 2 章 GUI 2.1 下準備 2.2 フォントのレンダリング 2.3 フレームバッファの操作 2.4 画面の描画 2.5 動作確認 第 3 章 ソケ
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは2時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう?すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
これは何 Kubernetes クラスタ管理者とアプリケーション開発者が分業しているプロジェクトで,開発者が必ずしも Kubernetes に詳しくない場合を想定し,開発時に使いそうな kubectl のコマンドをまとめたものです。 クラスタ管理者から開発者にこのドキュメントを適宜改変して渡し,開発者がある程度自立して操作できるようになることで,管理者への問い合わせ負荷を減らすのが狙いです。 場合によってはハンズオンで講座を開いてもよいでしょう。 ドキュメント案 ここでは Amazon EKS でクラスタを構築する場合の例を示します。 別のインフラに構築している場合は適宜書き換えてください。 事前準備 インストール kubectl AWS CLI AWS 環境設定 AWS CLI からアカウントを操作できるような設定方法を書きましょう。 コンテキスト作成 操作する対象の Kubernete
マーキュリー宇宙船のナビゲーション マーキュリー宇宙船には、コンピュータの類は搭載されておらず、飛行コースはアトラスブースターの誘導装置任せであった。 また、再突入コースは地上のリアルタイム・コンピューティング・センター(RTCC)で算出され、必要な逆噴射時間、噴射姿勢などが宇宙船に送信されていた。 ジェミニ宇宙船のコンピューター ジェミニ計画においては、アポロ計画で必要なランデブー技術の習得のための複雑な軌道変更、 安全な打ち上げのためのタイタンIIブースター誘導システムのバックアップ、 再突入の精度向上、そして打ち上げ前の膨大なチェックの自動化のため、 “Gemini digital computer”が搭載されることとなった。 1962年4月19日、IBM Federal Systems Divisionは、2億6千6百万ドルでこのコンピュータの開発を受託し、1965年12月までに2
本記事で紹介されている記事はあくまで個人の独断・偏見に基づいたものであることは予め述べておきます。今回の記事で紹介する記事は、いいねの数がQiitaであれば4桁、Zennであれば3桁であるものを中心に紹介していきます。 開設後3週間で収益10万円を得た個人開発サイトでやったことの全部を公開する 個人開発の面白さ、アイデアの作り方、個人開発でやってはいけないことや個人開発で収益を得るための具体的なテクニックまで解説されている。これから個人開発をやりたい人は絶対にこの記事を読むべき。 【夫婦で開発】1年かけて1週間を振り返えるアプリを本気で開発してみた 夫婦でReact NativeとFirebaseで開発したタスク管理アプリをリリースした体験談。モックの作り方、役割分担などの方法を実例を踏まえて丁寧に解説されている。ただ単に自分が開発したアプリの特徴や使用した技術を書いているだけではなく、開
扱う領域が多岐にわたり、それぞれに専門性が必要とされるプロダクトマネージャー。日々の業務や意思決定の合間の限られた時間に、学習を進める必要がありますが、短時間で質のよいインプットを行うには、今も昔も書籍は有効な手段の一つです。一方で、一言でプロダクトマネージャーといっても、キャリアの変遷や得意とする領域が異なり、必要とする参考書も人それぞれです。そこで本稿では、全体像を押さえつつ、自分に適したラーニングパスを見つける上で参考になる、筆者の読書経験にもとづいたプロダクトマネージャーのための読書地図をご紹介します。 最初から「プロダクトマネージャー」という人はほとんどいない 「プロダクトマネージャーは忙しい」 あらゆる職場で耳にする言葉です。 それもそのはず、プロダクトマネージャーはその仕事の性質からカバーすべき範囲が多岐にわたり、それぞれに専門性を持って臨む必要があります。 そのため、キャリ
LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて 以下記事も Four Keysだけじゃない開発者生産性フレームワーク 開発生産性の可視化フレームワークであるSPACEを活用するために、どのようなメトリクスをどう取得するかについて考えてみる 要約 SPACEは開発者の生産性を計測するためのフレームワーク 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字 satisfaction and well being performance activity communication and collaborati
2017年12月23日紙版発売 2017年12月23日電子版発売 B5判/168ページ 定価1,628円(本体1,480円+税10%) ISBN 978-4-7741-9433-2 ただいま弊社在庫はございません。 Amazon 楽天ブックス honto ヨドバシ.com Fujisan(定期購読のみ) 電子版 Gihyo Digital Publishing 本書のサポートページサンプルファイルのダウンロードや正誤表など 特集1 はじめてのペアプロ/モブプロ メキメキと人が育ち,プロダクトの質を高める 本特集では,2人1組になってコードを書くペアプログラミング(ペアプロ)と,チーム一丸となってコードを書くモブプログラミング(モブプロ)について解説します。ペアプロ/モブプロでは,すべての開発作業をペアやチームで行うことで,ペアやチーム内の情報伝達効率を最大にし,プロダクトの質を高めます。こ
会社のチームが半年前からモブプロを推進しているため、振り返る良い機会になりました。 筆者のスペック JIRAを全社導入した経緯でアジャイルを軽く推進していました。 社会人8年目 アジャイル歴2年 ペアプロ/モブプロ歴 6ヶ月 モブプロは現プロジェクトのPMが推進しており、私自身も半年前から実践しています。 記事について 本記事では元記事(WEB+DB PRESSの記事)の内容について、以下3点を振り返ります。 紹介されていた内容がチームとして実施できているか 紹介されていた内容が個人として実施できているか 備考 チームと個人の評価方法は以下とします。 ⭕ できている ❓ できていないこともある ❌ できていない
内製化支援コーチ 杉井です。 2022年01月05日(水)〜2022年01月07日(金)に開催されたスクラムイベント『Regional Scrum Gathering℠ Tokyo 2022』(RSGT2022)のレポートです。 本年は現地とオンラインのハイブリッド開催となっており私は現地参加してきました。 登壇者の緊張が伝わる感じ、セッション後の質問の盛り上がり、通路やブースでの雑談・・・。久しぶりのリアルカンファレンスを楽しみました。 本レポートではいくつかのセッションから感じたアジャイルの現在地・潮流を記したいと思います。 RSGT2022で紹介されたフレームワーク・手法 様々なセッションで「ソフトウェア開発方法論」にとどまらない手法や考え方の紹介がありました。 Keynote : Agile Program Management: Scaling Collaboration Acr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く