大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』が出版されます - Magnolia Tech
ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。 www.oreilly.com 訳者は、増田 亨さん！！ 2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが（元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...）、そんな時におすすめできる1冊です。 2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD（
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか？ 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方（通称徳丸本）」を出したのが2011年3月でして、それから13年以
WEB+DB PRESS総集編［Vol.1～136］
2024年4月18日紙版発売 WEB+DB PRESS編集部 編 B5判／128ページ 定価3,300円（本体3,000円＋税10%） ISBN 978-4-297-14156-1 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 『WEB+DB PRESS』全号のバックナンバーを収録 Webアプリケーション開発のためのプログラミング技術情報誌「WEB+DB PRESS」は，2000年から2023年までの23年間という長きにわたり，現場で活躍するWeb開発者の方々に向けた技術情報を提供してまいりました。そして2023年8月発売のVol.136をもって，隔月刊誌としては休刊いたしました。 本総集編には，WEB+DB PRESSVol.1から隔月刊最終号となるVol.136までのバックナンバーと，今まで刊行した総集編7冊の書き下ろし記事を収録しています。1冊1ファイルの記
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
[レポート] 『Data Engineering Study #23 Data orchestration 特集』 #DataEngineeringStudy | DevelopersIO
アライアンス事業部 エンジニアグループ モダンデータスタック(MDS)チームの しんや です。 データ分析に於いて、「データオーケストレーション(Data orchestration)」という分野、カテゴリが存在します。端的に言うと「サイロ化されたデータを複数のストレージから一元化されたリポジトリに移動させ、そこで結合、クリーニング、エンリッチ化し、アクティブ化（ビジネス・インテリジェンス・ツールでのレポート作成など）するプロセス」(端的じゃなかった...) という定義となるのですが、2024年03月05日(火)に開催された『Data Engineering Study #23』にてこの「データオーケストレーション(Data orchestration)」を特集するということでイベントに参加(オンライン視聴)しました。 当エントリでは、その参加(視聴)内容についてざっくりではありますがレポ
![[レポート] 『Data Engineering Study #23 Data orchestration 特集』 #DataEngineeringStudy | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b3b596d5f14f08f5d17d2a8dc9e2fa0dc0823d5/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2024%2F03%2Fdata-engineering-study-23_1200x630.jpeg)
プログラミングの終焉と生存戦略｜k1ito
この文章は何： 近年の生成AIブームにより、革命的なまでにプログラミングという仕事の形は変わることが予想され、実際、今までにない速度で世界が効率化され様々なサービスがローンチされていく中「使う側」としても「作る側」としても「IT業界(特にSaaS業界など)での生存」は難しくなっているように感じます。正解を知っていたらとっくに僕は大儲けをしているわけですが、当然わかるはずもなく生存戦略に苦しむだけの中での寝言です。 まとめと結論めいたもの：AI技術の発展により「プログラミング」と呼ばれる「人間の仕事を機械に引き継ぐ行為」のほとんどはゼロコストで行えるようになり、少なくとも今ほどの価値や競争優位の源泉とはならないだろう。今やるべきは、AIを自社の競争優位の源泉とするべく、まるで人材投資のようにAIへの引き継ぎ書を書くことと、AIの研修制度を作ることかもしれない。 プログラミングという仕事の終焉
チームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかも
＼スニダンを開発しているSODA inc.の Advent Calendar 10日目の記事です!!!／ こんにちは！！！！SODA開発部の矢野です！！！ はじめに 私のチームでは一年前からコードレビューを最優先に実施するという取り組みをしています。この取り組みを継続した結果開発生産性にも良い影響を与えてくれたかもしれないので記事にしようと思います！ ちょうどこの記事を作成しているときにX(旧Twitter)で「PRのレビューを最優先にしたらチームの生産性が上がった」の投稿にたくさんのいいねがついていたので、コードレビューを最優先に取り組んで効果を実感している組織やチームが多いのかもしれないですね。 レビューを最優先にした結果 結果から書くと、 「コードレビューを最優先にする」取り組み前後の「レビューからアプルーブまでの平均時間」を比較すると6.5時間から2.5時間に縮まりました（本当かな
Organizing a Go module - The Go Programming Language
A common question developers new to Go have is “How do I organize my Go project?”, in terms of the layout of files and folders. The goal of this document is to provide some guidelines that will help answer this question. To make the most of this document, make sure you’re familiar with the basics of Go modules by reading the tutorial and managing module source. Go projects can include packages, co
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
そりゃスパゲティーコードにもなるよな - orangeitems’s diary
お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。 大企業のプロジェクト運用体制に、１つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し
文化祭で某チェーン店を再現して失敗した話 - Qiita
要約 Wifiは無いに等しいと考えること。 (来場者1万強/日 なんていう状況下でWifiが動くと想定するのが駄目でした) 進捗管理する第三者を設けること。 ソースコード https://github.com/Na4Yu/EasyEats (RTDBのURLやSquareの個別キーは抜いているのでそのままは使えないです) はじめまして はじめまして、高校2年のNaYuです。 今回は文化祭で派手に失敗した話をさせて頂きます。 血反吐を垂れ流しながら書いていましたが、もし皆さんが文化祭を経て「この人のしたことをしなくて良かった~」なんて言っていただければ幸いです。(人の不幸は蜜の味) お願い 本記事は知見の共有を目的として個人が執筆したものであり、本記事の内容について学校、学校関係者への問い合わせはご遠慮頂けるようお願い申し上げます。 これを読んでいる後輩の方々へ この記事が私からの引き継ぎに
How to recover from microservices
I won't deny there may well be cases where a microservices-first architecture makes sense, but I think they're few and far in between. The vast majority of systems are much better served by starting and staying with a majestic monolith. The Prime Video case study that blew up the internet yesterday is but the latest illustration. Maybe once you reach the scale of Netflix or Amazon, there are areas
積極的な技術選定と消極的な技術選定 - uhyo/blog
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極
Pythonでtomlファイルを用いたlogging - Qiita
[tool.poetry] name = "template" version = "1.0.2" description = "ロガー使用例" authors = ["Snorlax"] [tool.poetry.dependencies] python = "^3.11.0" [build-system] requires = ["poetry-core>=1.0.0"] build-backend = "poetry.core.masonry.api" # logの設定 [logging] version = 1 [logging.formatters.simple] format = "[%(levelname)s] %(name)s %(asctime)s - %(message)s " [logging.handlers.consoleHandler] class = "log
映画『Winny』｜公式サイト
東出昌大 三浦貴大 皆川猿時 和田正人 木竜麻生 池田大 金子大地 阿部進之介 渋川清彦 田村泰二郎 渡辺いっけい / 吉田羊 吹越満 吉岡秀隆 監督・脚本：松本優作 STORY 殺人に使われた包丁をつくった職人は逮捕されるのか——。 技術者の未来と権利を守るため、 権力やメディアと戦った男たちの真実の物語。 2002年、開発者・金子勇（東出昌大）は、簡単にファイルを共有できる革新的なソフト「Winny」を開発、試用版を「２ちゃんねる」に公開をする。彗星のごとく現れた「Winny」は、本人同士が直接データのやりとりができるシステムで、瞬く間にシェアを伸ばしていく。しかし、その裏で大量の映画やゲーム、音楽などが違法アップロードされ、ダウンロードする若者も続出、次第に社会問題へ発展していく。 次々に違法コピーした者たちが逮捕されていく中、開発者の金子も著作権法違反幇助の容疑をかけられ、2004
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3
Taijin on Twitter: "この元fbで年収800k(控えめに言って8000万円)のテックリード兼マネージャのチャンネルすごく良い。面接だけではなくエンジニアとして成功するための仕事での有用なチップスがたくさん。英語も聞き取れやすい。 https://t.co/EnnvId2ehY"
https://twitter.com/itohiro73/status/1598994604912939009
How to say goodbye to technical debt
