🐺👀
![監視せなあかんし、五大紙だけにオオカミってな🐺🐺🐺🐺🐺](https://cdn-ak-scissors.b.st-hatena.com/image/square/50b14cae14eff3ebf8abefd3138be129f27b5861/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F3db148ed5e0c43238196e00155488097%2Fslide_0.jpg%3F24224331)
はじめに こんにちは! モジュール開発部の yamakazu (@yamarkz) です。 あけましておめでとうございます。2023年もよろしくお願いします。 本記事が新年最初のプロダクトブログになるのですが、何を書こうかとても迷いました。笑 抱負的な何かが無難だと思いつつ、1年先のことまでは見通すことができない。10Xはドラスティックに事業や組織が変わるので、中長期な目線で1つのテーマを説くのは難しいなと。そう色々と考える中で、ちょうど足元で成果が出始めている具体の取り組みを紹介したい!というモチベーションが生まれてきました。 なので今回は、半年先までの将来的な抱負の意図を交えながら、直近の取り組みで手応えを感じ始めている、アーキテクチャ改善のプラクティスを紹介しようと思います。 具体的にはタイトルにもある”適応度関数”と呼ばれるプラクティスで、巷では概念としては認識されているものの、ま
年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期(10月)よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ!では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ
上記のトピックについてもう少し突っ込んだ議論をしたい。 背景: GraphQL におけるエラーの表現の手法Web API において、正常系以外の、例外(エラー)的な状況をレスポンスの情報に埋め込みたい場合、REST API では HTTP ステータスコードがよく用いられる。 一方、GraphQL API では、複数のリソースを同時に取得することが前提にあるので、「リソースXはエラーであるがリソースYは正常である」のように Partial Error の状況を表現したいことがままある。そのためステータスコードは不適であることが多い。 また、GraphQL の仕様として、返すデータのトップレベルに data と並列に errors を返すことが出来る。(手法aとする) { "errors": [ { "message": "forbidden", "path": ["x"] } ], "dat
この記事は、Merpay Advent Calendar 2022 の15日目の記事です。 こんにちは。メルペイのvvakameです。 最近、社内向けにGraphQL Client Architecture Recommendationというドキュメントを書きました。社内のiOS/Android、そしてバックエンドのエンジニア向けにGraphQLをやるならこの辺りの条件を満たしておかないと恩恵を感じられなくなっちゃうかもよ、と伝えるためのものです。嬉しいことに、今までに100名弱の人たちがこのドキュメントを閲覧してくれたようです。 これをAdvent Calendarで公開するために、ちょっと調整したものがこの社外版です。 すでにGraphQLをやっているけどあまり便利じゃないな…なんでだろ?とか、これから導入したいんだけど何を気をつけるべきかな…と考える時の材料にしてください。 併せて、
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か?」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
こんにちは、筋肉料理人です! 以前ご紹介した、大分の庶民派グルメ「にら豚」。にらと豚肉、キャベツをしょう油ベースの甘辛いたれで炒めたビールもご飯もガンガンいける料理です。 www.hotpepper.jp 今回は、そのにら豚を筋肉料理人も御用達の鶏むね肉でアレンジした「にら鶏」を紹介します。鶏むね肉とにらの組み合わせで、美味しく食べて元気が出るレシピですよ。 筋肉料理人の「鶏むね肉でにら鶏」 【材料】2人分 鶏むね肉 200g にら 1束(100g程度) キャベツ 葉を1~2枚(100g程度) タカノツメ 1/2本 ごま油 小さじ2 (A) しょう油 大さじ1+1/3 日本酒 大さじ2 砂糖 小さじ2 (B) 片栗粉、日本酒 各小さじ2 鶏がらスープの素、しょう油、おろしにんにく 小さじ1/2 黒こしょう 適量 作り方 1. キャベツは太い葉脈を切り取り、ひと口大に切ります。 切り取った葉
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
システム開発における技術選定とはこの記事でいう技術選定とは、その名のとおり「どんな技術を使うかを選ぶこと」です。領域はインフラやサーバーサイド、フロントエンド、また種類としては言語やフレームワーク、ミドルウェアなどが対象になります。 この記事ではライブラリの選定基準については書いていません。これについては「ライブラリの選定基準」で詳しく書いていますので、あわせてご覧ください。 なぜ技術選定をするのか技術選定の目的は「事業価値を最大化するため」だと考えています。技術選定というと、ついシステム要件を満たすために決めてしまいがちです。もちろんこれも必要ですが、選定の観点という意味では一部でしかありません。 企業において、開発は事業を運営するために行います。OSSの場合は「事業」を「ソフトウェア」に置き換えられると思いますが、使う技術は事業に大きく影響します。たとえば、技術を使える人の採用コストだ
エンジニアのスキルレベルチェックという文脈で System Design Interview が気になっていたので、自チームのエンジニアにやってみた。 System Design Interview とは? どうやって実施したのか? 実際にやってどーだったか? エンジニアとしてのレベル感がそのまま結果として出る傾向にある コミュニケーション能力 得意分野と不得意分野が明確に出る 出題する側も難しい Spannerへの圧倒的な信頼 まとめ System Design Interview とは? ググれば出てくるので説明は割愛します。 どうやって実施したのか? チームメンバーには System Design Interview のことは伏せて、 ミーティング開始時に「System Design Interview をやります」って感じで始めたので、 System Design Intervie
トリ(@toricls)です。 カミナシに入社してから早いもので3ヶ月 + α が経ちましたが、さすがのアーリーステージなスタートアップという感じです。前職では想像もしなかったようなスピード感で激☆動イベントがポコポコ発生し、つい先日書いた入社エントリがすでに遠い過去のことのように感じます。 というわけで、本日(2022年7月1日)付けでカミナシの執行役員 CTO に就任しました。 本記事では、あらためてカミナシという会社やサービス、それらを支えるエンジニアリング組織の話とともに、就任にあたっての今後への思いをしたためようと思います。 CTO 就任の経緯これまで公にはしてなかったのですが、実はもともとカミナシからの入社オファーは『CTO 候補』というタイトルでもらっていました。僕はこれまで CTO という役割を経験したことがないため、まずは入社して一緒に働いてみて、僕も会社もお互いに期待に
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか? 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く