はじめに こんにちは。DevRelブロックの@wirohaです。2024年3月22日〜24日に「try! Swift Tokyo 2024」が開催されました。ZOZOはGOLDスポンサー・DIVERSITY & INCLUSIONスポンサーとして協賛し、ブースを出展しましたので現地のレポートをお届けします！ 目次 はじめに 目次 会場 スポンサーブース アンケートの回答 印象に残ったセッション Swiftの型推論を学ぼう コード署名を楽しく乗り切る方法 Party、その他 アフターイベント LT1. SwiftPM マルチモジュール構成への第一歩 LT2. SwiftとC++を利用した画像処理プログラミング LT3. Introducing Pkl 感想戦 最後に 会場 会場は前回（2019年）と同じ、ベルサール渋谷ファーストです。try! Swiftのマスコットキャラクター「Riko」ち
5 月末頃に、Twitter で 「Tailwind CSS はプロジェクトにとって将来的に技術的負債になるかもしれない」という趣旨の意見を発端として Tailwind CSS について多くの議論が起きました。[1] Tailwind CSS は世界的に人気な CSS フレームワークとして、今までも何回もその良さや課題について議論が起きてきましたが、「Tailwind CSS で得られる価値」について主張する意見において、CSS(や、CSS の関連技術)がなぜ技術的負債になるか、Tailwind CSS を使ったらなぜ CSS が技術的負債になることを回避できるかという視点から Tailwind CSS の特性を整理している意見や記事はインターネット上に多くないと思いました。この記事ではその点に注目しつつ、Tailwind CSS が CSS 設計にもたらす利点について整理したいと思います
identify CTO兼「ワインと鍋」オーナー岩崎さんに聞く。過去の技術選定とそこから得た学び - what we use（技術スタックデータベース）
identify株式会社は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。その「DeLMO」では、クリエイターがスキマ時間に動画を撮影・販売し、報酬を得ることができる複業支援サービス「DeLMO for creator」と、企業が縦型ショート動画素材を簡単に収集し、クリエイティブ制作に活用できるサービス「DeLMO for advertiser」の2つを提供しているのです。 同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前（茅場町、人形町、日本橋）にあるレストラン「ワインと鍋」のオーナーでもあるという変わった経歴の持ち主です。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。 GoやNext.jsを採用。“攻めた”技術選定をした意図とは――このインタビューで
こんにちは、karahiyo(@karahiyo_n)です。 今回はZucksアドプロダクト事業本部における技術的負債返済との付き合い方とその変化の話になります。 事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。8年間は今までのやり方でいい感じにやってこれたのですがシステムも人も事業も業界も変化し今までのやり方だけでは不十分ということで、今後も事業を支えられるシステムであり続けるためにもあらためて技術的負債について向き合いました。 tl;dr 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理 チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定
月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ 本ブログはEventbriteでCPO（Chief Product Officer）を務めるキャセイ・ウィンタース（Casey Winters）氏のブログ記事「Should You Pay Attention To Competitors? It Depends On Your Company’s Conflict」をご本人の許可を得て翻訳したものです。 高校の国語の授業で習ったことはあまり覚えていませんが、ストーリーにおける対立軸（コンフリクト）の種類に関しては、重要なフレームワークとして記憶に残っています。今日インターネ
書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売された。 まだ読んでいない人がいるなら兎に角オススメなので読んでほしい。 先日も少し話題にした業務委託でお手伝いしている会社、VOYAGE GROUPの主要な各事業を作ってきたエンジニアたちにフォーカスしたインタビュー集だ。 「そーだいさんはVGの人と仲が良いから底上げ評価でしょ？」と思う人がいるかもしれない。 もしあなたがレガシィコードと戦う現場で悩んでいるなら、大小関わらずプロダクトを作り、事業と共に歩む人なら自信を持ってオススメできる。 また今からエンジニアを生業として生きていこうと思っている人たち*1にも自信を持ってオススメできる。 そして、ソフトウェアを軸とした事業を作っていきたい人、関わっているエンジニア以外の人たちもぜひ読んでほしい。 ソフトウェアでサービスを作る際に大事なことが沢山読み
0. 本記事について免責と想定読者本投稿は、浅見個人の意見や信念を多く含む"ポエム"です。必ずしも所属組織を代表する意見ではありません。 また、本記事の想定読者は、データ分析（データ活用）を担当する課に配属された行政職員です。特に専門職採用というわけでもなく、データ分析・モデリングの特別な教育を受けていない読者を想定しています。 あくまで行政職員をイメージしているため、民間企業では適切ではない事例も多いかと思います。ご了承ください。 データ活用の主語についても、あくまで「行政職員」を想定しています。「国民」を主語にしたデータ活用の課題（例えば、神Excel問題や煩雑な紙申請問題など）は本記事ではスコープ外としています。 なお、本記事では「政策」「施策」「事業」について、特に区別を設けず「政策」という言葉で統一しています。 要約1. 最初の一歩 まずメトリクスを定義して、監視する習慣をつけま
しくじり先生のように学ぶ「NFS+sqliteで苦労した話から学ぶ、問題解決の考え方」という勉強会をやってみました | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 インフラLinux勉強会SQLiteNFS こんにちは、羽山です。 今回は社内で実施した勉強会をほぼそのままブログ記事にしています。 ITエンジニアたるものドキュメントを残したり勉強会を実施したり分かりやすい設計にリファクタリングしたりなど、日々 知見の伝達 を意識していると思います。主要な知見はたいていそれらの方法で満たせるのですが、しかし残念ながら中には画一的な方法では伝えにくいものもあったりします。 ところで伝統芸能や工芸の世界では技術の継承において 背中を見て学ぶ という方法が用いられることがあるようです。 これと似た手法はITエンジニアの世界にもあって、先輩エンジニアとペアプログラミングをすることで文書では伝わりにくい技術や考え方・テクニックを学ぶ
![しくじり先生のように学ぶ「NFS+sqliteで苦労した話から学ぶ、問題解決の考え方」という勉強会をやってみました | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/9477296f61e752f8b6816cb517cdb9166a028f2c/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F10%2Fscience_hakase_shippai_s.png)
負債返済プロジェクトがチームの動き・意識に与えた変化 - CARTA TECH BLOG
こんにちは、こんちゃん(@konchanSS)です。 今回はZucksアドプロダクト事業本部で、2年ほど前からはじまった負債カンバンを作成する動きから 負債返済へのアクションを起こして1年経ったのでそれを振り返ったものです。 負債カンバンとは 負債カンバンとは簡単にいうと、弊事業部にあるさまざまなサービスの負債をまとめたものです。 なぜ始まったかというのはゆっけ(@karahiyo)さんのtech blogを読んでもらえるとよりわかります。 以下、記事から抜粋したものです。 苦手なこと 課題とは認識しつつも対応が進まない、優先順位があがりきらないタスク どこにどんな技術的負債があるか把握しきれていない 気づいたタイミングでの根本的な負債返済の対応は簡単ではない 運用期間が長くなり、当時の最適解が今の最適解と違ってきているものがある 具体的に負債をどのように管理しているかも記事から抜粋したも
はじめに これは Qiita Advent Calendar 2021 D言語カレンダー の 8日目 の記事です。 近年プログラミング言語の1つであるD言語のコミュニティフォーラムで言及されるようになった「精神的摩擦（Mental friction）」という概念について、個人的な考えも交えつつ整理したもの公開しておこうと思います。 ある程度読んでいただくと、以下のような課題に対して改善が図れたり理解が進むのではないかと思います。 プログラミング等で自分の怒りや不満を抑えるポイント、改善に向けた方法論 稀に見るヘイトにあふれた技術記事や日ごろ発生する不満への対処法 プロダクトの価値としてぼやけがちな「心地よさ」の明確化 もちろん話を単純化したうえで予想を多く含むので、怒りや不満の心理を理解したとか言うつもりはまったくありません。全然違うこともあると思います。以下実際のやり取りをまとめたものな
ごあいさつ 記事の対象 記事のモチベーション ジャム当日までの準備 開発PCや実行環境 ノートPCの例 スペックが低い環境の極端な例 マウスを使用する(重要) USBメモリ コントローラ XInput形式のものを持ち込む 年季の入ったコントローラや自作のアーケードコントローラ やってみたいことの妄想 ジャム当日：アイデア出し ワードマップから始める アイデアの大枠が決定した時、UE4のテンプレートが使えそうか考える ToDoリストを作成する ジャム当日：最初にやること バージョン管理システム(VCS)を決める？ VCSを使用せずにUSBメモリを使用する VCSを使用する場合 Content直下にゲームジャム用のフォルダを作成する 各々の名前のフォルダで作業する 外部デバイスや使用したいコードのプラグインがある場合は、C++プロジェクトを作成する UE4Duino：Arduinoとのシリアル
Railsのテンプレートエンジンを、slimやhamlから、erbに戻して乗り換えた話 - ITANDI Engineer Blog
はじめに OHEYAGOの開発をしている田渕です！ Railsのテンプレートエンジンには、デフォルトのerbや、代替のslimやhamlなどがあります。 OHEYAGOではslimを採用していましたが、先日、テンプレートエンジンをslimからデフォルトのerbに変更しました。 細かい理由は後述しますが、OHEYAGOチーム内ではslimが技術的負債になっているという結論が出たからです。 また、自分が以前開発していた別のシステムでも、テンプレートエンジンをhamlからerbに変更したことがあります。 こちらも同様にhamlを負債だと考えたからです。 slimやhamlで開発しにくいという話はたまに聞きますが、実際にslimやhamlを削除するという話はネット上の記事でも殆ど見たことがないため、修正した方法を紹介します！ 技術選定の理由 slimやhamlのメリットとデメリットを考えます。まず
ペアプロを極めて最強の開発チームをつくる（1/4）ペアの組み方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: On Pair Programming 原文公開日: 2020/01/15 著者: Birgitta Böckeler -- ドイツのThoughtWorks社で開発とコンサルティングを担当しています。カスタムソフトウェアチームのテックリードとして日々を「コーディングの日」「コーチングの日」「コンサルティングの日」「仕事を楽しく続ける日」に分けています。 著者: Nina Siessegger -- ドイツのハンブルグ出身の開発者/テックリード/コンサルタント。元ThoughtWorks。コーディングの楽しさ以外に、特にソフトウェア開発の人間的な側面にも強い関心を抱き、高品質ソフトウェアは「コミュニケーション」「共同作業」「信頼関係」を重んじるチームによって成し遂げられると強く信じています。 サイト: martinfowler.c
モノリシックなアプリケーションを疎結合にする取り組み - 弁護士ドットコム株式会社 Creators’ blog
こんにちは。弁護士ドットコム クラウドサイン事業本部 Product Engineering 部の須山と申します。CloudSign はサービスを開始してから約 7 年が経過しています。その間数多くの機能追加・拡張を続けている中で技術的な負債を残していくことは、どの企業でもよくある話ではないでしょうか。そんな中 CloudSign では技術的負債を解消することを主な目的としたチームを 2 年程前から結成して、日々改善活動を進めています（それ以外にも、新機能の技術検証や基盤開発も担当しています） 今回はチーム発足時から活動しているモノリシックアプリケーションの分割に関してやってきたことをまとめました。これまでの活動を大きく 3 つの段階に分けて紹介します。 その1. モノリシックなアプリケーションの分割 ローカル環境とそれ以外の環境での差異 アプリケーションを実行環境ごとに分割 アプリケーシ
開発責任者がやるべきことの気づきと"Think Like a CTO" - クラウドワークス エンジニアブログ
1年をふりかえる 年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長の@hihatsです。 本記事はクラウドワークスAdvent Calendar 2023 シリーズ2の25日目の記事です。 今回は、プロダクト開発部として今年取り組んできたことと、その中での気づき、「Think Like a CTO」という書籍の話にも触れていきます。 今年やってきたこと 技術的負債解消への取り組み 昨年のアドベントカレンダーでも書きましたが、2023年も技術的負債の解消に取り組んで参りました。 結果としては、フロントエンドでの注力の割合が大きかった一年でした。詳しくは@okuto_oyamaさんの1日目の記事をご覧ください。 記事にもありますが、Vue.js化をフロントエンドを触る全チームが行える体制に整えることで加速させてい
こんにちは､びしょ～じょです｡ メモリアルなんでなんか書こうかなと思いました｡ プログラミングをはじめて10年目になる プログラミングの旅は、大学に入ってから始まった。入学直前にDxRubyに触れ、forループを使って「hello」を出力しまくったのが、おそらく最初の経験であったと思う。大学時代、学部2年にはLinuxConに参加するなどしていたが、結局は言語系の道に進んだ。本格的にプログラミング言語自体に興味を持ち始めたのは、1年生と2年生の終わり頃にLuaでZコンビネータを書いたときだった。 それ以降、プログラミングとともに歩む日々が続いている。大学在籍中には、様々なプログラムを作成し、友人や先生からの評価も得ていた。また、自身のスキルアップのために、オンラインでの情報収集や書籍を読み漁ることも欠かさなかった。卒業後、初めて入った会社では、これまでの学びを活かし、新しいプロジェクトに取
こんにちは、リファクタリング大好きなミノ駆動です。 2021年4月にREADYFOR株式会社にジョインしました。 概要 本記事は、なぜ私がREADYFORへのジョインを決断したのか、背景理由を記したエントリ記事です。 READYFORはサービス開始から約10年が経過。システムに相当な技術的負債が蓄積しているため、今後スピーディーにサービス拡大するためには負債解消が目下取り組むべき重要課題となっております。その課題解決のために私は誘われたわけですが、リファクタリングが十分に効果を発揮するには、設計技術面以外の様々なハードルを乗り越えなければなりません。 READYFORの組織ビジョン「乳化」が、ハードルを解消し、リファクタリング効果の大きな促進に貢献すると考えたため、ジョインを決断しました。 本記事では、技術的負債やリファクタリングにまつわる一般的な問題構造を解説した上で、READYFORが
はじめに 2020年2月14日に開催されたDevelopers Summit2020に参加してきました。 event.shoeisha.jp テーマ 【14-B-4】プロダクトを10年運用するチームをつくる カテゴリ エンジニア組織 登壇者 粕谷 大輔さん [はてな] @daiksy はてな 2012年入社 KPTとは かすや ぱねえ 天才www Mackerelチームディレクター 認定スクラムマスター Mackerelとは サーバ監視をSaaSで行っている 発表資料 speakerdeck.com 講演メモ 変化し続ける周辺環境とSystem プロダクトを10年安定稼働させる極意とは？ 昔はCloudなんてなかった。基幹システムなどがメイン 当時の格言 動いているシステムはさわるな 10年触らないことが極意？ 今日のセミナーは、完wwww 周辺環境の変化が激しい OSのメジャーアップデー
この記事は トレタ Advent Calendar 2019 12日目*1の記事です。 こんにちは。最近、子供に荷物に買い物かばんにとリアルポーターごっこに腰がつらくなってきた@joy04dです。 前回のAdvent Calendarでこんな事を書いていた自分ですが、その後、今年1月から VP of Engineering の役割を頂いております。まだ1年足らずのひよっこですが、日々頑張ってお仕事しております(=ω=) 今回の記事では、せっかくなのでこの1年の振り返りと知見(あるいはアンチパターン)の共有を兼ねて、つらつらと*2書いてみたいと思います。 どんなことしたか 今年のコンセプトを一言でいうと 個からチームへ になります。 トレタの開発組織では、創業期から 自治 をコンセプトとしており、フラットな組織のなかでエンジニアそれぞれが自身の裁量と責任を持って行動することを大事にしていまし
セキュアで信頼性のあるシステム構築
システムのセキュリティと信頼性は表裏一体です。セキュリティは、プロダクトの品質、パフォーマンス、可用性と密接にかかわるため、スケーラブルなシステムの設計と運用にとって極めて重要です。本書は、GoogleのセキュリティとSREのエキスパートが、根本からセキュアで、スケーラブルかつ信頼性の高いシステムを設計するためのベストプラクティスを紹介します。 既刊書『SRE サイトリライアビリティエンジニアリング』と『サイトリライアビリティワークブック』は、企業がソフトウェアシステムをスムーズに構築、デプロイ、監視、保守するうえで、サービスライフサイクル全体への取り組みが重要な理由とその方法を解説しました。本書では、システムの設計、実装、保守に関する考え方と実践法を解説します。また、ベストプラクティスに取り組むために必要となる組織の文化についても説明します。 本書への推薦の言葉 Royal Hansen
SPACEでの指標選びは網羅性ではなく関連性と一貫性を持たせて絞り込むことが大切である、さらに…… - mtx2s’s blog
SPACEフレームワークを活用するなら、選択する指標に関連性と一貫性を持たせて絞り込むことが大切です。思いつくかぎりの指標をただやみくもに集めて網羅性を高めても、そこから得られる情報はほとんどないでしょう。 これが、ニコール・フォースグレンらによる論文 "The SPACE of Developer Productivity: There's more to it than you think." を読んだ時に私が感じたことです。 queue.acm.org 本稿は、上述論文に基づいてSPACEフレームワークを解説するとともに、その活用方法についても考察しています。 特に、5つのディメンションについては、論文から読み取りづらい点をフォローするようにしました。ここが理解できないと、フレームワークの魅力がなくなってしまいます。実際、開発チームのマネージャーらやメンバーらと話していると、SPAC
こんにちは、Product Securityチームの@gloriaです。前回は、昨年のAdvent Calendarイベントでセキュリティテストについて記事を書きました。 今回は、メルカリSecurity TeamのSecurity Tech Blogシリーズの一本目として脅威モデリングについて紹介したいと思います。脅威モデリングの基礎、なぜ脅威モデリングがセキュア開発ライフサイクル（SDLC）に必要なのか、メルカリの脅威モデリングプロセスについて説明したいと思います。 脅威モデリングとは？ 脅威モデリングは、システムを分析してセキュリティの脆弱性を洗い出す活動です。つまり、システムやアプリケーションの設計を深く分析し、実装前に先手を打って、起こり得る脆弱性を見つけることです。攻撃者をシステムに一歩も踏ませないので、プロアクティブ・セキュリティの一つの手段だと言われます。 プロアクティブ・
ダブルメンテ状態は、なんとしても避けたかった ーーフルリプレイスに対して、社内で反対はなかったんですか？ 戸井田裕貴氏（以下、戸井田）：土日の48時間を使ってバシッと移行しきるのは、けっこうリスクがあるという雰囲気は出ていましたね。僕は絶対にやりたかったので、そこは話し合いました。 ーーそれをどう説得したのですか。 戸井田：新・旧システムのダブルメンテ状態は、なんとしても避けたかったんですよね。なんでかというと、営業はまずプロダクトを売っているから、両方を理解しなきゃいけないじゃないですか。新・旧で思想や使い勝手がぜんぜん違うし、しかも開発のスピードとかも変わってくるんですよね。こちらは速いけどこちらは遅いみたいな。 そんなことをしたら、営業もCSも辛いと思うんですよ。両方使うお客さんとかが出たら、さらに辛いと思うんです。どちらにしても、両方理解して売っていく状態になる。もう大変だし、開発
サービス間連携のためのGraphQL APIをClojureで開発している話 - Opt Technologies Magazine
社内共有のマスタデータ基盤としてのGraphQL APIをプログラミング言語Clojureで開発している事例をご紹介します。 あいさつ 新規API開発の背景 現行システムの問題点: 共有データベース 解決策: データベースをラップするサービス 技術選定の経緯 API方式: GraphQL メイン開発言語: Clojure アプリケーションのアーキテクチャ設計 The Clean Architecture コードの全体像 resolver use case entity boundary 主な要素技術 アプリケーション構成の整理とライフサイクル管理: Duct GraphQL APIサーバ: Lacinia + Pedestal 入力バリデーション: malli DBアクセス: clojure.java.jdbc + Honey SQL テストとカバレッジ計測: clojure.test +
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。プレゼンテーション「技術で創る事業成長」に登壇したのは、Sansan株式会社CTOの藤倉成太氏。 Sansanのミッションとプロダクト 藤倉成太氏：よろしくお願いいたします。Sansan株式会社でCTOをしています、藤倉と申します。 自己紹介ですけど、別にあまり深く読んでいただく必要はないかなと思いますので、適当に流してください。 これもちょっと会社のミッションに触れておこうかなと思って用意しただけなんですけど、ちなみにSansanという会社を知っている方ってどれくらい
この記事は個人開発Advent Calendar 2022 1日目の記事です。 2022年6月13日、私が個人開発でリリースしたサービス「テストメーカー」がTwitterで2,000RT、7,600いいね以上の大バズリを記録しました。 「テストメーカー」は穴埋めテストを直感的に作れるツールです。 マウスで穴埋めにしたいテキストを選択して離すと、その部分が穴埋め問題に変わります。 リリース以降、主に全国各地の中学校、高校、大学などの授業で使っていただいたりしながらユーザー数が増えています。 他にも、社会人の方が国家資格を受験するときの受験勉強に使っていただいていることもあります。 ITMediaさんに取材も受けました。 そして、リリースからおよそ1ヶ月が経過した7月に課金機能を実装し、そこから少しずつですが課金してくださるユーザーさんも増え続けています。 本記事では、そんなテストメーカーを支
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「アジャイル開発は世界を変える夢を見るか 」をテーマに株式会社レッドジャーニーの市谷氏が登壇。まずは、チーム・組織の「もやみ」と闇落ちについて話します。 レッドジャーニーの市谷氏 市谷聡啓氏：みなさんこんばんは。金曜日のこんな遅い時間まで、お疲れかと思います。私も疲れていますが、この話をするまで6月が終われないので、よろしくお願いします。 あらためて、市谷と申します。レッドジャーニーという会社を立ち上げて、世の中のDXを進めたい企業に寄り添いながら支援している者です。DXといっても、新しい事業を作ったりプロダクトを作ったり、人材教育など、そこにはいろいろな中身があります。企業の状況や狙いどころに応じて、一緒に取り組んでいます。 今日のテーマであるアジャイル開発は、これととも
おはようございますこんにちはこんばんは。ROUTE06 取締役 CTO の重岡です。 創業 4 年目に突入した今年の 1 月に Tech blog を開設し、四半期を経て、私もようやく記事を執筆することができました。記事のネタを社内のエンジニアに相談したところ、 Q) 私も Tech blog 記事を書こうと思ってるので、どんな内容がよさそうか相談させてください 💭 A) ”マネーフォワード CTO が考えていること”を社外向けに公開しているのは良さそうだなーと思ってました 👀 という有益なアドバイスを頂きまして、真似して実践してみることにしました。 昨年 2022 年 11 月、CTO 就任時に考えていたことは ROUTE06 の取締役 CTO に就任しました の記事にてご紹介させていただきました。 本記事では CTO 就任後、5 ヶ月を経ての振り返りと、今考えてることについてご紹介
ゲームエンジンを自作しながら思ったこと - Qiita
本稿では、私が長く続けている個人でのゲームエンジン開発で得られた知識や経験を紹介します。 嘘ですポエムです。アルコールとか入ってます。 本当はかっこいいこと言ってみんなの役に立つこと書きたかったです。書きたかったけど無理だったよ…。 ひとつのゲームエンジンを作り続けてもう何年も経ちます。その間コンセプトも定められず満足なメジャーリリースもできないままだらだら作り続けてしまったので、あんまり役に立つことは書けなさそう。 とりあえず昨今のゲームエンジンの開発に必要な技術要素と、私が開発している Lumino というゲームエンジンでの代表的な実装例を紹介する、みたいな体で書いてみようと思います。なにか間違ってそうでしたらコメントお願いします。 多分、ちょっとでも役に立つかもしれないのは、「ゲーム作ってたけど気が付いたらゲームエンジン作ってて、ゲームが出来てないけどゲームエンジン公開してみたくなっ
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
アジャイル開発における品質の考え方 - Mirai Translate TECH BLOG
こんにちは。プラットフォーム開発部 EMのchikaです。 先月、アジャイル開発におけるQAの考え方 という記事を投稿しました。 miraitranslate-tech.hatenablog.jp 今回は、その中で触れられなかった、品質ってなんだっけ？アジャイル開発では品質って今までと同じ考え方でいいの？ということ考えたときに調べたことなどを紹介しようと思います。 品質って、何ですか？ 品質の定義・分類のモデル ソフトウェア品質特性の８分類（ISO/IEC 25010:2011） 外部品質、内部品質 狩野モデル （参考文献） プロダクト開発のときに品質モデルが教えてくれること 統計的品質管理における品質の代用特性 アジャイル開発における品質の代用特性 品質とスピードはトレードオフなのか？ 品質は保証できるものなのか？ まとめ 参考 We are hiring! 品質って、何ですか？ 「この
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。続いては、組織における技術的負債の返済のための現場と意思決定層のアクションについて。前回の記事はこちらから。 技術的負債の現場視点のアクション 原トリ氏（以下、原）：では、ここからは技術的負債の返済inアクションという感じで、まずは現場視点での返済の進め方について、ちょっと見ていきましょう。現場視点の整理が済んだら、次は意思決定層の視点です。 まず一般的に、技術的負債の返済の提案や実行は、現場の立場から行われることが多いです。いわゆるボトムアップと呼ばれるものです。日々開発をして、運用している人たちです。理由は明確で、その技術的負債によって生産性低下の悪影響を直接的にモロに受ける立
Merpay Advent Calendar 2019 の８日目は、メルペイ backend payment platform チーム の @knsh14 がお送りします。 はじめに 私はメルペイでお客様の残高を管理しているマイクロサービス(以下Balance Service)の開発を担当しています。 Balance Serviceは次のような定常的に動かしているバッチがあります。 有効期限があるポイントの失効処理 会計データの突合 毎日知りたいデータのレポート Balance Serviceではメルペイリリースに向けて限られたスケジュールの中で開発を進めていました。 サービスとしての実装を優先して開発をしていたため、まずはテストのカバレッジを挙げて動作を担保する方針をとっていました。 結果としてリリースから今まで大きな事故もなく運用できています。 ですが、1日目の記事にもあるように7月か
成功する実践的モブプログラミング
※Qiitaで書いた記事を移動したものです。なお JTF2020 で発表したときのスライドは https://speakerdeck.com/erukiti/mob-programming-practice です。 モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（4〜5人を推奨）でやるものであり、また、目的や効果も全く違うものです。 モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというチーム戦 です。これ最重要なので、あとで何回も登場します！ この記事には「成功する実践的モブプログラミング」というタイトルを付けています。ここでいう成功の定義は、モブプロが実際に効率よく実践できることとします。モブプロに関する記事・情報は「イ
estie VPoEの青木です。 前回の記事では、「ハリネズミを飼おうかと検討しています」と書いたのですが、晴れて生後2ヶ月のハリネズミを家に迎えました。 世話の仕方に苦戦しながら（慣れるまでなかなか針を立てずに持たせてもらえない...）楽しい日々を過ごしています。 データドリブンな意思決定を支援する社内データ分析基盤 - estie inside blog さて、今日は”estie”（オフィス探しプラットフォーム）開発チームの開発手法の歩みについて、これまでの経験を書きます。 まだまだ改善したいことがたくさんあり文章に残すのも恥ずかしいなと感じますが、ここまで開発チームとして、事業にどれだけ高速に貢献するかを考えて試行錯誤してきたそのプロセスが、この記事を読んでいる方の少しでも参考となればと思います。 そもそもestieって何しているの？ estie pro estie 開発したいことが
こんにちは、虎の穴ラボの山田です。 この記事は虎の穴ラボ2024 夏の連載企画24日目の記事になります。 前回はy.fさんによる「「関数型デザイン」を読んで、設計と実装の幅を広げよう！」が投稿されています。 こちらもぜひご覧ください。 はじめに 内容 第1章 開発生産性とは何か 第2章 開発生産性向上のためのステップを知る 第3章 生産性向上の取り組みを阻害する要因とその対策 第4章 パフォーマンスを測るための指標 第5章以降 感想 終わりに 採用情報 はじめに 先日、「開発生産性」に関するイベントが開催されました。興味はあったのですが、予定があったためその際は参加を見送りました。 その後、書店のWebサイトで「開発生産性」のタイトルが目につき、思わず手を伸ばしたのがこちらの本になります。読んでみると有用な内容で、とても参考になりました。 今回はこちらの本の書評記事となります。 エンジニア
銀の弾丸はない - 偶有的複雑性と向き合うためのログラスのEnabling & Platform戦略 - loglass_product_teamのブログ
こんにちは。ログラスでVP of Engineeringとしてエンジニアリング組織全体のマネジメントをしております、いとひろ@itohiro73と申します。 前回、「銀の弾丸はない - 経営の本質的課題に向き合い続けるログラスのプロダクト開発」と題して、ログラスのプロダクト開発がいかに本質的課題と向き合ってきたか、そしてこれからどのようなチャレンジが待ち受けているのかを書きました。 今回は、「本質的な課題」を解くために本質的な複雑性に付随して存在する、「偶有的複雑性」について、開発組織としてどのように向かっていこうと考えているのかを記します。 前回の記事で引用した、『人月の神話』（Frederick P. Brooks,Jr. ,丸善出版,2014）という書籍にも収録されている論文（Brooks, Fred P. , "No Silver Bullet -Essence and Accid
サービス運用10年以上の重み、弁護士ドットコムのユニットテスト速度改善 - 弁護士ドットコム株式会社 Creators’ blog
初めまして、弁護士ドットコムでエンジニアをやっている @namizatork です。 第1回目で @komtaki さんが書いた 「弁護士ドットコムサービスのビジネスと共にみるマイクロサービスの進化」 がプチバズりしていたので第2回目となる今回、少し 滑らないか 心配ですが頑張って書きます。 本記事では、サービス開始から10年以上が経過したサービスのユニットテストを改善したという内容をお話しします。 ユニットテスト改善チームの立ち上げ 改善前に必要なことを明確化 キックオフ ユニットテストを並列実行する GitLab parallel 時間の掛かっているユニットテストを特定する 実行方法 テストが遅い原因を特定&解決 (1) 多くのループ処理やスリープ処理を利用している (2) 誤ったsetUpやtearDownの使い方をしている (3) DBに依存しており、アクセスに時間が掛かっている
プロダクト思考で開発が進む「みてね」の今とこれから～みてねの生みの親笠原健治氏、開発マネージャ酒井篤氏が考える、プロダクトとエンジニアリングの素敵な関係 リリースから5年が経ち、800万ユーザを超えた家族向け写真・動画共有アプリ「家族アルバム みてね」。 今回、プロダクトの生みの親でもありプロダクトオーナー、そして、株式会社ミクシィ取締役会長笠原健治氏、みてね開発マネージャ酒井篤氏に、みてねを支えるエンジニアリングについて、開発に関する体制やプロダクトの開発・運用、さらにこれからのみてねのビジョンについて伺いました。 株式会社ミクシィ取締役会長笠原健治氏（左）、みてね開発マネージャ酒井篤氏（右） みてね誕生の背景 ――リリースから5年が経ち、ユーザ数も着実に増えていると聞きます。ここで、改めて、みてね誕生の背景について教えてください。 笠原： 最初のきっかけは自分に子どもが生まれた
品質を測定するとは？ 技術的負債、という言葉を知っていますか？ 技術的負債とは、“何らかの理由により、必ずしも最善とは言えないが、実現が容易な手法を選択した結果生じる、将来の追加コスト” のことです。コード品質の世界にも技術的負債はあります。例を挙げれば、“納期に追われて安易にコードをコピペしちゃう”、とかですね。その場は切り抜けられるかもしれませんが、そのコピペに関連する様々な不具合を将来にわたって負債として引き受けることになります。 さて、この負債。負ってしまったらどうしましょう？ 真面目な方はすぐ返済したくなるかもしれませんが、負債の大きさが許容範囲内であれば、とりあえず利息だけ払って借り続けるという選択もありえます。コード品質の負債も、無理にコードを直して返済しない方がよいことがあります。コードを直すのにも費用がかかるので、開発予算や開発スコープなどと天秤にかけると、そのままにして
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
5年ぶりの開催！「try! Swift Tokyo 2024」参加レポート - ZOZO TECH BLOG
Tailwind CSSはCSS設計に何をもたらすか
技術的負債との付き合い方とその変化 - CARTA TECH BLOG
競合他社を気にすべきか？自社が戦うべき相手の見極め方 | Coral Capital
事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳
行政職員のためのデータ活用一歩前｜METI-DX 経済産業省DXオフィス
プログラミングにおける精神的摩擦（Mental friction）と向き合い方
ゲームジャムでUnreal Engine 4を使ってみよう - SEGA TECH Blog
すまん､他社行くわ (ボツ案: プログラミングを始めて10年目になるし､新卒で入った会社もやめて転職する)
リファクタリング効果を促進する組織ビジョン「乳化」 - READYFOR Tech Blog
【デブサミ2020レポート】プロダクトを10年運用するチームをつくる #devsumiB - 紙一重の積み重ね
トレタ開発組織振り返り 2019年版 - トレタ開発者ブログ
メルカリの脅威モデリングプロセス | メルカリエンジニアリング
ダブルメンテ状態は、Hacobuにとっては“死” 「フルリプレイス」をやり遂げるためにCTOが決断したこと
SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”
【個人開発】2000RT超えの大バズリ〜初課金まで至った穴埋めテストメーカーを支える技術
可もなく不可もないチーム・組織は“闇落ち”する可能性がある 引き金を引く5つの感覚と、日本の組織が持つ判断基準の問題
ROUTE06 CTOが考えていること（2023年4月） - ROUTE06 Tech Blog
リファクタリングを避けるコードデザイン(Railsを題材として)
重要なのは経営層の視点と現場の課題をつなぐこと 技術的負債の返済に向けた現場の説明責任
バッチコマンドをテストしやすいようにリファクタリングする | メルカリエンジニアリング
estieの開発手法の歩みを赤裸々に語ってみた - estie inside blog
「エンジニア組織を強くする開発生産性の教科書」を読んで - 虎の穴開発室ブログ
プロダクト思考で開発が進む「みてね」の今とこれから～みてねの生みの親笠原健治氏、開発マネージャ酒井篤氏が考える、プロダクトとエンジニアリングの素敵な関係 | gihyo.jp
どうやってコード品質を測るのか？ ソースコード品質の測定指標とその活用