こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

この記事は 個人開発 Advent Calendar 2021 の18日目の記事です。 「もうスマホアプリ市場はレッドオーシャン」とか、「個人アプリは埋もれてしまって全然ダウンロードされない」とかいう話をちらほら聞きます。 実際、過去に個人でアプリをリリースしたけれど、ヒットしなくて辞めてしまった、という人もいるのではないでしょうか。 では、もし… ヒット作が出ないまま10年間個人アプリ開発を続けたら、どうなってしまうのか という話をします。 作ったものまずは、これまで作ったアプリやダウンロード数などのデータをまとめます。 これまでにリリースしたアプリは、 iOS（ツール系）：39本 Android（ツール系）：1本 ゲーム：29本 で、計68本です。 （Androidアプリは、iOSアプリのAndroid版なので合計にはノーカウント） ツール系アプリは、「写真／ビデオ」カテゴリが多いです

こんにちは、ネットではウマたんというハンドルネームで活動していて普段はスタビジというメディアやスタアカという教育サービスを運営しています。 普段は主にAIデータサイエンスまわりの発信活動や事業を展開しているのですが、2024年から海外に移住し海外向けのサービスを作っています。2024年はとりあえず12ヶ月で12個のサービスを作る挑戦をしています。 その挑戦に関しては以下の記事に書いてますので興味のある方は見てみてください。 ただ、とりあえず海外でサービスを作ってもなかなか上手くいくわけがない。 そこで先人たちの知恵を借りるために、海外の成功してる個人開発者をリサーチしてニュースレターで配信してます。 ということでこの記事では、今までリサーチしてきたすっごい海外個人開発者たちの情報をまとめていきたいと思います（※随時更新予定）。 Pieter Levels（ピーター・レベルズ）氏 （出典：h

はじめに こんにちは、SRE部 検索基盤SREブロックの花房です。普段は、ZOZOTOWNの検索関連マイクロサービスにおけるQCD改善やインフラ運用を担当しています。 以前まで、検索基盤を支えるチームではElastic Cloudの特権アカウントをメンバーで共用していました。本記事では、2023年4月にリリースされたElastic CloudのRBAC（Role-Based Access Control）機能を活用して、特権アカウントの共用から脱却した取り組みについて紹介します。さらに、既存機能と組み合わせることで実現した、効率的な権限管理についても紹介します。 同様の課題を抱えている読者の方には、下記の部分で参考になれば幸いです。 Elastic CloudにおけるSSOの活用 Elastic CloudのRBACによる権限管理の実例 Elastic Cloudアカウント情報を利用した、

はじめに こんにちは、検索基盤部の広渡です。検索基盤部では、検索クエリのサジェスト（以下、サジェスト）の改善を行なっています。ここでサジェストは一般的に「Query Auto Completion」と呼ばれる、検索クエリを入力した際に入力の続きを補完したキーワードを提示する機能を指します。 ZOZOTOWNにおいては検索クエリを入力したとき、最大10件の検索クエリのサジェスト（以下、サジェストリスト）が表示されます（なお、ランキングを考慮しない場合はサジェスト集合と呼ぶこととします）。また、サジェストリストのランキングはユーザーの行動ログを用いて計算されたスコアによって決定されます。サジェストの具体的な説明や過去の改善事例は以下の記事を参照してください。 techblog.zozo.com techblog.zozo.com サジェストリストをチーム内で定性評価したところ、類似したサジェス

あけましておめでとうございます！uenikiです。2024年が始まってしまいました。 こちらの記事で、2023年に読んだ技術書Top5を紹介しました。 2023年は、技術書は12、3冊しか読めませんでしたが、毎年大体15冊〜20数冊程度で安定しているようです。（マネジメント系の本を含めるともう少し増えますが、ここではピュアに技術寄りの本のみ対象とします。） ということは、2024年も10冊は読めるということですし、すでに発売している（発売を予定している）本でもそれぐらいの数はあるだろうということで、雑に10冊を選んでみたいと思います。この企画としては、すでに読んだことある本を再度読み通すのも1冊とカウントすることとします。辞書的に必要な箇所だけ読むのは1冊とはカウントしません。 そして、必ずこの10冊は読むことします。 10選のご紹介 ［試して理解］Linuxのしくみ　―実験と図解で学ぶO

経緯 筆者は外国語大学で中国語を専攻しているのですが、偶然にも中国語のプログラミング関係の記事を読む機会がありました。その中で日本語だと直接カタカナで使用している用語も、中国語では意味のある漢字に置き換えられており、興味をそそられたので基礎的な用語を調べてみました。私自身は漢字文化圏で育った者として、こうした用語の漢字表記には元素記号の漢字表記のような魅力を感じます。また同時に、漢字は表意文字であるため初学者にもやさしく見えるので、日本でも（自然言語好きな変人たちの間で）もっと広まっていってほしいな、と思います。 個人的6選 Guard:守衛 かっこえぇ！錯誤（error）が発生しても、コードの安全性をしっかりと担保してくれそうな強さを感じますよね？　ええ、感じます。 Delegate: 代理 初心者には取っ付きづらいDelegateも代理とされたら、仕事の一部を任せるんだな、ということが

はじめに みなさん、『世界一流エンジニアの思考法』読みましたか？（唐突） 結構 X（Twitter）で話題になっていたり、周りに読んでいる人も多かったので 年末年始のお休みに読もうと思ったら、あっという間に読了しました。 （電車の中で読んでいたら、同僚から「課題図書です」と連絡がきました。すごいタイミング） 知識の定着という意味でも、読んだことを書き出しておきたいと思います。 ※本の要約ではなく、私自身気になった点をピックアップしています。 偉大な習慣を身につけたプログラマになる 本書の「はじめに」にて 彼らはなにも全員が常人と比べて著しく頭の回転が速いわけでも、天才的記憶力を持つわけでもない。 主に「思考法」（マインドセット）が高い生産性を形づくっているのだ。 小手先のテクニックでもなければ Tips でもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。 いわゆる「一

こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー

はじめに こんにちは、SRE部 検索基盤SREブロックの花房と大澤です。普段はZOZOTOWNの検索関連マイクロサービスのインフラ運用を担当しています。 ZOZOTOWNの検索基盤では、商品検索に関わる大規模なデータを取り扱うためにElasticsearchを利用しています。Elasticsearchを運用していく中で、私たちはパフォーマンスとインフラコスト、運用トイルの問題に直面していました。本記事では、私たちが抱えていた問題と、それを解決したアプローチとしてシャーディング最適化とオートスケーラー開発の取り組みについてご紹介します。 目次 はじめに 目次 背景・課題 パフォーマンスの課題 インフラコストの課題 運用トイルの課題 解決策 シャーディング最適化 Elasticsearchのシャーディング ノードのインスタンスタイプ変更 負荷試験によるパフォーマンス検証 コスト見積 安全なリリ

日本CTO協会が主催の「Developer eXperience Day 2023」は、“開発者体験” をテーマに、その知見・経験の共有とそれに関わる方々のコミュニケーションを目的としたカンファレンスです。ここで登壇したのは、株式会社カウシェの柴田芳樹氏。45年の歴史から振り返ったソフトウェア開発とキャリアの変遷について発表しました。全3回。3回目は、柴田氏が影響を受けた出来事と、技術教育への取り組みについて。 米国駐在・Javaの登場・日本オラクルの社長の言葉…柴田氏が影響を受けた出来事 柴田芳樹氏：影響を受けた出来事について、ちょっと簡単に話をしていきます。 まず、初めてアメリカに駐在する時の送別会で、駐在経験のある先輩から、アメリカに行った時は「与えられた開発タスクをこなすと、さらに難易度の高い開発タスクが与えられるから注意しろ」と言われたんですね。 最初はピンと来なかったんですけど

この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視１年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 １年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると

『イーデス』は、複数の企業と提携し情報を提供しており、当サイトを経由して商品への申込みがあった場合には、各企業から報酬を受け取ることがあります。ただし当サイト内のランキングや商品の評価に関して、提携の有無や報酬の有無が影響を及ぼすことはございません。 また当サイトで得た収益は、サイトを訪れる皆様により役立つコンテンツを提供するために、情報の品質向上・ランキング精度の向上等に還元しております。※提携機関一覧 将来のお金に関する漠然とした不安から、資産運用に興味はあるものの「何から始めればいいのか分からない」と感じている人は多いのではないでしょうか。 特に「投資」は複雑で難しそうな印象から、一歩を踏み出せないという人も少なくなさそうです。 今回寄稿いただいたエンジニアのSongmuさんも、投資に対し手続きや運用に手間がかかりそう、と長らく投資を始めてこなかったと語ります。 そんなSongmuさ

技術記事を書くまでのステップについて順にコツを解説していきます。 特に、技術記事を書きたくてもテーマ選定が難しい、文章が苦手だ、なぜか筆が進まない、うまくまとめられないといった方に読んで欲しい記事です。 一応、エンジニア歴としては数年以内のジュニアレベルの方を想定しています。 以下のように技術記事を企画して、書いて、公開するためのプロセスごとにちょっとしたコツをまとめています。気になるセクションだけでも読んでいただければ幸いです。 テーマを決めよう 対象読者を決めよう 章立てを決めよう 書こう タイトルを決めよう 【余談】技術記事を書く理由とは 筆者について QiitaとZennにて6年以上の記事発信経験があり、 Qiitaでは5,942Contributionsを記録、 Zennでは3,253Likesをいただいています。 テーマを決めよう コツ：テーマのカテゴリによって執筆のポイントや

おれたちは生成AIに苦手なことをやらせがち〇〇について教えて系の質問は全部ダメ。堂々と嘘をつくのは勿論、回答が抽象的すぎて役に立たないことが露呈した。 この批判がまさにそうなのだが、どうもわれわれ日本人は「ChatGPTが一番苦手なこと（≒自分が知らないことを教えてもらう）にChatGPTを使おうとする」という傾向があるらしい。日本の経営者に聞いたChatGPTの使い道のアンケートでは、「仕事で調べものをする時に活用する」が39.3%でトップだ。これが米国の職場でのChatGPT利用法の調査だと、上から順に、 アイディアを出すコンテンツを作成するメールに返信するプログラムコードを書くレジュメやカバーレターを書くプレゼンテーションを作成する となっていて、情報検索や調べもののタスクは上位5位に入っていない。総じて米国の働き手は、ChatGPTを自分に情報をインプットするためのツールではなく、

こんにちは！メルカリ Engineering Office チームの@aisakaです。 メルカリのエンジニア組織は、メンバーが相互に学び合い、メンバー自身が自走し、成長できる組織を目指し、「互いに学び合い、成長し合う文化」の醸成を行っています。 こうしたメルカリの「互いに学び合い、成長し合う文化」を体現する仕組みの一つが、社内技術研修「DevDojo」シリーズです。 昨年から、一部のDevDojoシリーズを外部公開(参考)していますが、今回さらに新しいコンテンツを公開することになりました！ 今日のブログでは公開するセッションとその内容をご紹介します！ Learning materials Website 技術研修DevDojoとは DevDojoは、技術開発を学ぶ場として「Development」と「Dojo(道場)」をかけ合わせて名付けられた完全In-houseの社内研修シリーズです。

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

むかしからなんでも斜にかまえるクセがある。 行列を見ては「よく並ぶねえ」と思い、流行りの曲を聞いては「これが流行ってんのね」と少しうがった目で見てしまうのだ。 そこでふと「斜にかまえる」「かまえない」を意識的に切り替えるとどういう感情になるのか気になった。実験してみます。 やり方 簡単にやり方を説明すると ①何かモノなどを目の前に置く ②それに対し、1分間は斜にかまえ、もう1分間は斜にかまえずに感想を言う。これだけだ。 ちなみに「斜にかまえる」を辞書で調べると、「物事に正対しないで、皮肉やからかいなどの目で見ること」とある。 わかりやすく言えば、1分間は皮肉めいた目で見て、1分間は素直に感想を言ったり肯定してみたりする実験である。 ひとりじゃ心もとないので、今回は後輩と一緒にやることにした。 後輩の郡司さん（左）と山宮さん（右）。二人とも斜にかまえがちな性格を自覚しているそうだ。 とりあえ

23新卒技術研修で実施したGit研修の講義資料です。 動画：https://youtu.be/lWkO8bQ9pSo 資料の利用について 公開している資料は勉強会や企業の研修などで自由にご利用頂いて大丈夫ですが、以下の形での利用だけご遠慮ください。 ・受講者から参加費や授業料などを集める形での利用（会場費や飲食費など勉強会運営に必要な実費を集めるのは問題ありません） ・出典を削除または改変しての利用

「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行