タグ

設計に関するmapk0yのブックマーク (14)

  • スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog

    今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し

    スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
  • ADR を1年間書いてみた感想 - 一休.com Developers Blog

    宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要  |  Cloud アーキテクチャ センター  |  Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? #設計 -

    ADR を1年間書いてみた感想 - 一休.com Developers Blog
  • EC2が複数VPCにENIを足出しできるように!でもみんな戦々恐々としてるのはなぜ…? - Qiita

    AWSVPCに大きなアップデートが! 今週10/26、AWSにこんな機能アップデートが発表され大変話題になりました。 簡単に言うと 「EC2インスタンスから複数のVPCに対してENI(NIC)を足出しできるようになった」 という大きなアップデートでした。 みんな戦々恐々? しかし、Twitterのオンプレミス経験者たちは口を揃えて懸念を漏らしています。 「これ、クラウド初心者がオンプレからの移行で "監視セグメントVPC" みたいなものを作ってしまうんじゃなかろうか…」 今回のアプデを見て「ウッ…😅」と感じた方も、改めて何が問題なの?と聞かれると意外としっかり言語化できないかも知れません。これを機にAWSの代表的なサービスであるマネージド論理ネットワーク「VPC」の基をおさらいしてみましょう。 オンプレ時代の基を振り返る パブリッククラウド普及前のオンプレミス時代では、企業のシステ

    EC2が複数VPCにENIを足出しできるように!でもみんな戦々恐々としてるのはなぜ…? - Qiita
  • ミラティブでのアウトゲーム設計の紹介 - Mirrativ Tech Blog

    こんにちは。ミラティブUnityエンジニアの菅谷(tetsujp84)です。 今回はミラティブのライブゲーム開発で行ったアウトゲームの設計について紹介します。 以前アウトゲーム設計に関してXでポストしたらレスポンスをいただけたのでできるだけ丁寧に解説してみました。こんな話も聞きたいよというのがあったら是非教えてください。 よくありそうなソシャゲアウトゲームの設計について今更記事化してるんだけどどれだけ需要あるんだろう。MVPの概念とかクリーンアーキテクチャライクな知識って業界的な浸透率どんなもんなんだ。— 鉄 -TETSU- (@tetsujp84) 2023年8月28日 アウトゲームについて ゲーム開発者にとっては馴染み深いと思いますが、ゲームにはインゲームと呼ばれる部分とアウトゲームと呼ばれる部分に別れます。インゲームゲーム体験のコアでキャラクターを操作したり、アクションがあったりと

    ミラティブでのアウトゲーム設計の紹介 - Mirrativ Tech Blog
  • 決済システムを壊さずに拡張した話 | メルカリエンジニアリング

    メルペイのBackend Engineerの @Hiraku です。与信決済システムのmicroserviceのTech Leadをしております。 この記事は、Merpay Advent Calendar 2022 の5日目の記事 メルカードの舞台裏編です。 2022年11月8日にメルペイ初のクレジットカードであるメルカードがリリースされました。これに伴い、システムにも広範囲に変更が加わっています。この記事ではその中でもちょっと分かりにくい、メルペイスマート払いの請求タイミングの変更について解説します。 月末ごろにメルカードによる決済を行うとわかるのですが、「処理中」と表示され、翌月の請求に含まれないものがあります。こちらはメルカード特有の実売上処理が終わってから請求する挙動です。順番に解説していきます。 カード決済の流れ 決済は大きく2段階の処理で成り立っています。「オーソリ」や「仮売上

    決済システムを壊さずに拡張した話 | メルカリエンジニアリング
  • 「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena

    「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売!クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太(うひょ),川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ!という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開

    「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
  • トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight

    トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight

    トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight
  • 東海環状道の橋脚で施工不良、発注者に知らせず“見た目”だけ直す

    中日高速道路会社が岐阜県巣市内に整備している東海環状自動車道の高架橋で、橋脚1基を設計よりも短く施工していたことが分かった。測量ミスで基礎を設計よりも高い位置に造ったと気づいた施工者のTSUCHIYA(岐阜県大垣市)が、上端の位置を合わせるため柱部を短くしていた。中日高速が2022年1月11日に明らかにした。 TSUCHIYAは契約金額約7億円、20年6月~22年5月の工期で、東海環状道の見延第二高架橋など3橋の下部工事を担当している。 ミスがあったのは、同社が施工する計16基の橋脚のうち、見延第二高架橋の内回り側のP5橋脚だ。上端から下端までの長さを、設計よりも約0.7m短い11.3mとしていた。上端の高さは設計通りだが、根入れ深さが不足した。同社の現場代理人が21年12月8日、中日高速の監督員に報告した。 中日高速は、橋脚の安全性や長期耐久性を確認できないと判断。問題の橋脚を

    東海環状道の橋脚で施工不良、発注者に知らせず“見た目”だけ直す
  • 冪等なデータ処理ジョブを書く - クックパッド開発者ブログ

    こんにちは、マーケティングサポート事業部データインテリジェンスグループの井上寛之(@inohiro)です。普段はマーケティングに使われるプライベートDMP(データマネジメントプラットフォーム)の開発を行っています。稿では、その過程で得られた冪等なデータ処理ジョブの書き方に関する工夫を紹介したいと思います。今回は、RDBMS上で SQL によるデータ処理を前提に紹介しますが、この考え方は他の言語や環境におけるデータ処理についても応用できるはずです。 まずクックパッドのDMPと、冪等なジョブについて簡単に説明し、ジョブを冪等にするポイントを挙げます。また、SQL バッチジョブフレームワークである bricolage を使った、冪等なジョブの実装例を示します。 クックパッドのDMPと冪等なジョブ クックパッドのプライベートDMPは、データウェアハウス(社内の巨大な分析用データベースで、クックパ

    冪等なデータ処理ジョブを書く - クックパッド開発者ブログ
  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
    mapk0y
    mapk0y 2018/04/06
    だからといって、「「悪いほう」をまず選ぶべき」 と考えないようにしないといけない気がする
  • 人工衛星開発から学んだエンジニアにとって重要なこと - Qiita

    前例がないため、どこにも答えが存在せず、基的に色々なものを1から考えて作ることが多くなります。 その時重要になってくるのが、と、 キャッチアップ力 と 基礎理解力 だと思っています。 私の場合、衛星が撮影した画像を処理して蓄積する処理をVHDLで組むというのがあったのですが、全くVHDLを知らない状態から1ヶ月半ほどで実装する必要が生じ、何とか間に合わせたという経験がありました。 その時は、基的な知識をやWebから調べ、回路を組みながらあれこれ試して勘所を掴み、最終的に実装に落としていくというような事をしましたが、昨今テクノロジーの進化と変遷が激しくなる中で、未知の技術を学習して「使える」状態に持っていくための、 自分なりのフレームワーク を持っておくことが非常に重要であると思っています。 逆に言うと、何かした時に、常にそれを自分の中にフレームワークとして蓄積するという意識を持って取

    人工衛星開発から学んだエンジニアにとって重要なこと - Qiita
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • DB設計の難しさ

    今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB

    DB設計の難しさ
  • 1