otherworldのブックマーク - はてなブックマーク

Yahoo! 知恵袋フロントエンドをリアーキテクトしている話

Yahoo! 知恵袋のフロントエンドには26000行を超えるユニットテスト(1つのcontrollerのユニットテスト)や、多くのロジックを含むcontrollerがあります。これらによって追加実装・保守が難しい状況です。この問題を解決するために、リアーキテクトを行いました。以下について主に話そうと思っています。・リアーキテクトで取り組んだこと・リアーキテクトの結果・学び・反省点

otherworld 2024/05/05

神化しやすいUtilityを最初から置いてしまっていたりと、ToBeの図を見ても整理しづらそうな予感がする。まずは愚直に4層レイヤー化アーキテクチャ系（Ports&Adapters等）を実践するアプローチをお勧めしたい。

リンク

「シェフが教えるペペロンチーノ」を「パスタは目分量」で生きてきた人間がレシピ通り真面目に作ってみたら

トゥギャッターオリジナル編集部のふ凡社です。先日、社内で﹁ペペロンチーノが上手く作れない﹂という話が出た。ペペロンチーノは、オリーブオイル、ニンニク、唐辛子、塩だけで味付けするシンプルな料理。しかし、よく料理をする人ほど﹁ペペロンチーノみたいなシンプルな料理こそ難しい﹂と言うものだ。私も自炊をする中で数々のパスタを作ってきたが、シンプルなペペロンチーノはどうやっても味がいまひとつ。﹁まぁ普通に美味しいんだけど、お店の味にはとうてい及ばない﹂という着地になってしまうので、﹁ペペロンチーノは素人が手を出さずに、店で食べたほうがいい﹂という認識だった。いっぽうで、YouTubeやレシピサイトを見ていると﹁プロのシェフが教える本当に美味しいペペロンチーノの作り方﹂はたくさん出てくる。﹁ひょっとして、”真面目に”やれば家でもお店みたいなペペロンチーノを作れるのか？﹂ということで、改めてペ

otherworld 2024/04/12

自分も適当に目分量でやりがちなので、今度レシピ通りにやってみよう～！（手抜きしたいなら鶏がらスープの素とか適当なうま味調味料を雑に入れればいいと思うよ…）

リンク

Slackのtimesチャンネル文化が好きじゃない - りまりまだんの本拠地

speakerdeck.com はてなブックマークやxでこの資料が話題になっていた。80%くらいは同意できるが、Slackの部分は個人的にはうーんと思った。特にtimesが好きではなくて、﹁timesじゃなくてチケット管理システムを使え﹂と思ってしまった。なんで好きじゃないんだろう？と思ったので整理しておく。情報が垂れ流しだと探しづらいから timesには思考や調べたことを投稿して、後から見返せるようにしましょうという役割がある。でもそれ、本当に見返せるのだろうか？Slackの検索クエリはGoogleほど絞り込みが効かないし、部分一致の検索でもかなりフィルタリングされた情報がヒットする印象がある。本当に探し出せる気がしない。また、投稿した人ではない誰かが仕事を引き継いだときに困るんじゃないか、という思いが拭えなくて好きじゃない。例えばエンジニアの退職でリポジトリのメンテを引き継ぐことに

otherworld 2024/04/06

なぜ分報を見返す前提で考えてるのだろう。職場での独り言や会話と同じだよ。分報で何かを決定したしちゃうのは別の問題。

リンク

生産性指標をFour Keysから変更した話 - Sansan Tech Blog

技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。生産量2倍計画現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。ポイントとして、技術本部のレ

otherworld 2024/03/05

ソフトウェアアーキテクチャメトリクス本で触れられていたけど4keysのデプロイの定義を変えるほうが良さそうな…

リンク

本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ

前振りタイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。いい加減﹁私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう﹂﹁私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない﹂という二重思考を他人にするようお願いするのにも飽きましたしね。さて本題といきましょう本題世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。﹁うちはスクラムやってます﹂カジュアル面談で耳

otherworld 2024/02/28

ほぼ怪文書なのに読めているようなブコメが多くてビビる…。良いことを言っているのは﹁スクラムガイドを読め﹂という部分ぐらいだと思う。本に書いてあるスクラムを参考にするからダメ。スクラムガイドを読もう

リンク

チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog

近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機

otherworld 2024/01/09

素敵。最初から出来ないのは当然。出来ない理由をあげるのではなく、経験主義に基づいてイテレーティブにこの原則を目指すマインドが大事。アトミックはメンバー同士で調整じゃなくて協力しあう（一丸）という意味。

リンク

﹁事実誤認や著しい誤りがある本は出版されるべきではない﹂という主張について見解を教えていただきたいです。私は、内容が正しいものであってもなくても、出版される事自体は問題なく、出版後に適切な批判を受けるでよいのでは、と感じているのですが、いまいちすっきひ論理的に整理できずに悶々としています。|新たな発想を生み出す質問箱 Querie.me

● 450 users ● querie.me ●学び

﹁事実誤認や著しい誤りがある本は出版されるべきではない﹂という主張について見解を教えていただきたいです。私は、内容が正しいものであってもなくても、出版される事自体は問題なく、出版後に適切な批判を受けるでよいのでは、と感じているのですが、いまいちすっきひ論理的に整理できずに悶々としています。いや健康にかかわるデマ本とかもそうですけど､他人に害を与える本は出版されるべきではないし､著者や出版社はそういう有害な本を出さない道徳的義務があるに決まってますよ｡一般的な規範として､嘘をついてはいけないとか､誤った情報で他人の判断を誤らせてはいけないとか､差別発言で他人の尊厳を傷付けてはいけないとかには誰でも同意すると思いますが､何でそれを本にして出したらセーフになると思うんですか｡なるわけないだろって話なんですよ｡そもそもあなた､あなた自身は医療や災害に関するデマを流してもいいしヘイトスピーチ

otherworld 2023/12/11

基本的に出版社は慈善事業ではなくビジネスでやってるので無意味にリスクを取らないというだけで、自費出版なら誰にも止められずに出版できるし批判も自由に受けられるかと。

リンク

リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog

どうも、レコメンド商品のシステム開発をしている野川と申します。私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。図‥レコメンド商品表の流れ入社当時私は、ソフトウェアエンジニアとして、﹁可読性の低いコードは駆逐するべきだ﹂﹁読みやすいコードだけが正義である﹂﹁理解しやすいシステムだけが皆を幸せにする﹂と心の底から考えていました。加えて、﹁なぜ先輩たちは可読性の低いコードを放置して平気なのか？﹂と疑問を持つこともしばしばありました。レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私

otherworld 2023/11/28

リファクタリングは挙動を変えない確信が持てるような書き換えの繰り返しで行いたいけど、この記事は仕様の確認も行っているあたり設計の変更にまで踏み込んでいるから、大変になっているのかなぁと。

リンク

ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design

2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/

otherworld 2023/11/22

コンウェイの法則は組織のコミュニケーションの構造が、ソフトウェアの内部設計の構造となってしまうというもの。一方この資料は品質の話をしているのでちょっと違いませんか。

リンク

【翻訳】Prettier の新しい三項演算子のフォーマットを試してみてください

この記事はAlex Rattrayさんの A curious case of the ternaries を、本人の許可を得て翻訳したものです(タイトルは大幅に変えてしまっていますが)。記事の最後にあるように Google Forms から新しい機能についてのフィードバックを求めています。私以外のメンテナーも読めるようにできるだけ英語で書いてほしいですが、「日本語でなら書いてもいいよ」という人がいたら日本語で書いてもらっても大丈夫です。三項演算子のフォーマットは長年の課題でした。Prettier の v3.1.0 では新しいフォーマットのスタイルを導入することで、ついにこれを解決しました(訳注: 後述の通り、まだ experimental なので、--experimental-ternaries をつけたときのみ有効になります)。このブログ記事では、これまでの経緯と背景、実際に触って

otherworld 2023/11/14

読むのはすぐ慣れるけど、書くのが難しそう。このフォーマットの欠点は条件を変えたいときにどこを変更すればいいか分かりづらいことと、Prettierがないとこのインデントを再現できなさそうなことじゃないかなぁ。

リンク

『転スラ』や『葬送のフリーレン』を本当に「ファンタジー」と呼ぶべきなのかどうか考えてみた。 - Something Orange

こんなツイートを見かけたので、ちょっと言及してみた。そういえば、どうせ魔法も神も居るファンタジー異世界なら、そもそも大地が丸くないとか、宇宙とそこに浮かぶ惑星上じゃないとか、そういう異世界を見たい気もするんだけど、近年のRPGとかそれ風世界作品とかでそういうのは不思議と見ない気もしますね… — 理間高広（COMITIA145 E35a"Strangeness"） (@Rima_tk) 2023年10月3日近年の日本の作品ではないけれど、テリー・プラチェットの『ディスクワールド』シリーズは「巨大な亀の背中に4頭の巨大な象に支えられ、ゆっくり回転する「円盤」」の上が舞台ですね。あと、タニス・リーの『平たい地球』は「地球が平らかなりし頃」の物語です。 https://t.co/w3JCwAajNP — 海燕 (@kaien) 2023年10月4日ツイートしたあと思い出したのだが、ひかわ玲

otherworld 2023/10/05

ローファンタジーは現実世界をベースにファンタジー要素があるものを指すのであって、独自の世界観の作りこみ具合を指してローとかハイとか言うわけではない…。指輪物語風ならコピーのコピーでもハイファンタジー

リンク

Visual Studio Code June 2023

Version 1.88 is now available! Read about the new features and fixes from March. June 2023 (version 1.80) Update 1.80.1: The update addresses these issues. Update 1.80.2: The update addresses this security issue. Downloads: Windows: x64 Arm64 | Mac: Universal Intel silicon | Linux: deb rpm tarball Arm snap Welcome to the June 2023 release of Visual Studio Code. There are many updates in this versi

otherworld 2023/07/09

あとで読む

リンク

ツイッターはオラクルへの支払いも遅延している | スラド IT

支払い拒否で有名なツイッターがオラクルへの支払いを拒否した模様。ちなみにオラクルの経営者エリソンはマスクがツイッターを買収する際に10億ドル(円じゃないよドルだよ)を貸した恩人(ツイッターからすれば疫病神?)の模様。 OracleはTwitterにクラウドサービスを提供しているが、その対価の支払いが数か月にわたり未払いとなっていると報じられている。TwitterのCEOであるイーロン・マスク氏とOracleの共同創業者であるラリー・エリソン氏は古くからの友人だった。その上、エリソン氏はマスク氏がTwitterの買収する際、10億ドルを出資している立場だ。にも関わらず、未払いが生じていることから、Oracle側は支払いを回収するため、Twitterの従業員や元従業員に直接電話をかけ始めたなどの報道もあるようだ︵Business Insider Japan、Data Center Café︶

otherworld 2023/07/05

あとで読む

リンク

Sprint Planning をやめた話 - スタディサプリ Product Team Blog

小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである﹁学習コアチーム﹂において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。なお、本

otherworld 2023/06/30

スクラムマスターはチームの裁量だけでアイテムを完了に持っていけるように取り計らうべきで、この場合ならチーム外に依存が入らないようにPBIを分割すべき…。スクラム風であってスクラムではない…。

リンク

「終わらなかったから次のスプリントにまわそう」なんてありえない

イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。仕事を終わらせるために仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。予想以上に仕様が複雑になった予想以上に調査に時間がかかった予想以上にはまってしまったこれはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずけるというように、終わらないと気がついた時点で調

otherworld 2023/06/29

終わるように尽力するのは当たり前だけど、その上で終わらないような不確実さは往々にしてあるかと。ベロシティが下がる影響があるかも…ということはSBLを変更しろと言っているのかな…？

リンク

分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要

分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要 WebAssemblyランタイム「Wasmer」の開発元であるWasmer社は、エッジロケーション上のデータセンターにWebAssemblyランタイムを展開し、分散モノリスなアーキテクチャを用いたサーバレス型の新しいアプリケーションプラットフォーム「Wasmer Edge」を発表しました。 The Cloud is dead, long live the Cloud! Announcing Wasmer Edgehttps://t.co/VjGsbMwopy pic.twitter.com/5mTtKBBjsZ — Wasmer (@wasmerio) June 15, 2023 上記のツイートに示されているように、Wasmer E

otherworld 2023/06/19

これはただのモノリスじゃないかな…。distributedなモノリスであるけどそれを直訳して分散モノリスと訳してしまっているのかな密結合低凝集でリリース困難な分散システムを揶揄して分散モノリスというのが一般的なは

リンク

プログラミングにしか興味のないエンジニアに困っている

今年の頭にうちの会社にやってきたエンジニアの話。彼は実装がめちゃくちゃ速く、コードもきれい。テストもちゃんと書く。とてもできるエンジニアなのだが、一つだけ困っていることがある。実装完了した機能をすぐに本番環境にデプロイできないと、とても不機嫌になるのだ。うちの会社が開発しているのはtoBのシステムで、実装内容によっては営業やカスタマーサポートからお客さんにアナウンスがされてからでないとデプロイができないものがある。急にUIが変わったり新機能が追加されるとお客さんが混乱するしカスタマーサポートに問い合わせが殺到するので、デプロイ前に調整が発生するのは致し方ないことなのだが、こうした背景を説明しても彼は納得してくれない。﹁とにかく早くデプロイをさせろ﹂の一点張りで、彼が勝手にPRをリリースブランチにマージして、機能が出てしまったこともある。それによってカスタマーサポートへの問い合

otherworld 2023/05/23

思うところはありつつ、four keysの観点でオンデマンドなデプロイができない事はたしかにデメリットであるので、フィーチャートゥグルを実装して、デプロイと機能の有効化のタイミングを分離できるようにしたら良さそう

リンク

『崩壊：スターレイル』のプレイ日記書いてくれって言われたけどバッドエンド踏んだので初回で最終回です

冷静に考えてみよう。今どき﹁プレイ日記﹂なんて誰も読まない。冷静に考えてみよう。他のWeb媒体やらなんやらで出てきた﹁プレイ日記﹂が大して面白くないことを。そもそも﹁日記﹂の面白さは、﹁他人の赤裸々な思いが書かれた恥ずかしいノートをこっそり覗く﹂という悪趣味な面白さに依存しているところが多いのではないだろうか。ゆえに、得てしてこういう公の場に出てくるプレイ日記は書いてる側が恥ずかしがったり、変に遠慮したりしてつまらなくなってしまいがちに思える。じゃあ一体何が言いたいのかっつーと、﹁ホントに無遠慮なことがたくさん書かれてるプレイ日記だから優しく読んでね﹂ってコト！！！ ……と、冒頭にこんな訳のわからないことを書いてしまうくらい、今回のプレイ日記に意気込んでいたりするんですね。だってこのプレイ日記の話、半年ぐらい前から聞いてたんすよ……？しかも対談︻※1︼もカウントしたら、もう﹃崩壊‥

otherworld 2023/05/12

リンク

検索が爆速になるデータベース設計を公開します

こんにちは。エンジニアの谷井です。フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。フォルシアにおける検索DBについてまず前提としてフォルシアで扱うデータについて軽く説明します。扱うデータの複雑さたとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としてはホテルの情報﹁〇〇ホテル﹂︵~約2万件︶プランの情報﹁朝食付き・ロングステイ△△プラン﹂︵0~1500件/施設︶客室の情報︵~100件/

otherworld 2023/04/29

RDBのみで頑張るスタイルだ。参照用DBに分離したり非正規化までしているのであれば、いわゆる全文検索に限らずともSolrCloudやElasticsearchを使うほうが検索向けの機能も充実しているし、いろいろ簡単になると思う。

リンク

積極的な技術選定と消極的な技術選定 - uhyo/blog

この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。積極的な技術選定と消極的な技術選定 IT エンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。積極的な技術選定は、選定される︵あるいはされない︶技術そのものが原因となる意思決定です。一方、消極

otherworld 2023/02/13

レイヤーが違うというのはそうで、一般的には異なる非機能要件に該当するものかと思う。どう合理的にバランスを取るかという設計の話なので、気持ちはわかるけど積極的・消極的という命名は避けたほうが無難そう。

リンク

はてなブックマーク

タグ

otherworldのブックマーク (3,619)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス