サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
間違っています。JSONは仕様が簡潔で融通が利かないところがメリットであり、ケツカンマやコメントを許容しないこともそれに一役買っています。ケツカンマやコメントが欲しければYAMLを使いましょう。YAMLはJSONのスーパーセットなので、JSONにケツカンマやコメントをつければYAMLとして読むことは出来ます。 JSONとYAMLにはそれぞれに良さがあり、それぞれの良さを他方に求めると、その価値を毀損します。言ってしまえば、JSONはシンプルでありYAMLはイージーなのです。 参考:Simple Made Easy JSONはシンプル ご存知の通り、JSONはルールや覚えることが少ない反面、表現力に乏しいです。結果として人間にも機械にも比較的優しいシリアライゼーションフォーマットとして優れています。「ひとつのことをうまくやる」です。必ず1行に圧縮できる強みもあり、ログフォーマットとしても使
2025/02/28(金) JSConf.jp おかわり Node学園46時限目
例えば次のようなテーブルがあったとする。 -- PostgreSQLCREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, dataTEXT,created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); --MySQLCREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, dataTEXT,created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data,created_at) VALUES (1, 'First
このSpring Bootを使ったクリーンアーキテクチャの例は、データの詰め替え過剰にみえる。 https://www.baeldung.com/spring-boot-clean-architecture これだけのモデルと詰め替えが必要なのだろうか? 『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている NoMapping (レイヤ間でモデルを共有し、詰め替えをしない) 2-wayMapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う) FullMapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う) またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。 このスライドでまとめているのは SaaS とは、ビジネスモデル x技術であることを理解する SaaS アーキテクトでどのように SaaS を作っていくのか？を考える SaaS KPI で…
ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か？」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま
DDD を理解したいあなたのための DDD 入門以前Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
PHPerKaigi 2024の登壇資料のほうが図面がわかりやすいので記載する。 ※2024/06/25 追記speakerdeck.com どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒め
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
※初出は HEY World の https://world.hey.com/hitoshi.nakashima/post-8214d314 です ソフトウェアで万人に響く機能はない。なのでサブスクリプションのソフトウェアサービスでフルセットのプランだけを作ってそれを売るとユーザーから値引き要求がくる。フルセットのプランのうち、機能 A だけ必要であとはいらないので負けろと言われる。 ソフトウェアは限界費用が限りなくゼロに近いので、使える機能の多寡で価格を変えるのは売り手からすると合理的ではないし、複雑な商品メニューの維持管理、サプスクリプションのプラン変更によるアップグレードやダウングレード、決済プラットフォームの移行などを考えると極力支払いプランはシンプルにしておきたい。この辺りを複雑にすることで肝心なソフトウェアの機能開発スピードが落ちてしまったら本末転倒だ。 多分有償のソフトウェア
有償ソフトウェアを売る方法分かんなすぎるから、気軽に相談できる人欲しくなってきた...。 ・寄付募集型か、有料で一部の機能を解放する型か ・価格設定 ・有料で一部の機能を解放するなら、どこまで有料にするか ・買い切り型か、月額サブスクリプション型か とかとか、考えること無限にある。。 — Cside (@Cside_) October 2,2023個人開発ではないが、課金については仕事で結構やってきてまぁまぁの知見を得た。かつて自分も情報を得ようとネットで探してみたが、極めて情報が少なかった。ソフトウェア開発についてのノウハウは結構ネットに転がってるが、値付けなどについての情報は少ない。エンジニアとマーケッターでは文化が違うのかもしれないが、そもそも値付けに関しては商材（ソフトウェア）によって様々なので定石がなく、結局のところ自分で試してみないと正解がわからないのではないかと思う。そう
オライリーから出た「大規模データ管理」という新刊を読んだ。 大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス 作者:Piethein Strengholt オライリージャパンAmazon 私の担当するような基幹系システムでも、特に業務は変わっていないと思うのだけど、扱うデータ量は日々増加しており、昨今の機械学習の進展やDXなる謎キーワードの登場でデータの重要性が叫ばれる中、その傾向には拍車がかかっている。 ということで、非常に興味を持って読み始めたのだけど、個人的には違和感を持ってしまった。誤解を招くと良くないが、トピックを網羅的に扱っている真面目な本で、決して悪い本ではない。*1 違和感の理由を考えてみたのだけど、ひとつは切り口が機能に寄りすぎてニーズがはっきりとしないところにあると思う。書いてないわけではないけれど、あくまで世の中にはこういう機能があってこう使う
メルペイのBackend Engineerの @Hiraku です。与信決済システムのmicroserviceのTech Leadをしております。 この記事は、Merpay Advent Calendar2022 の5日目の記事 メルカードの舞台裏編です。2022年11月8日にメルペイ初のクレジットカードであるメルカードがリリースされました。これに伴い、システムにも広範囲に変更が加わっています。この記事ではその中でもちょっと分かりにくい、メルペイスマート払いの請求タイミングの変更について解説します。 月末ごろにメルカードによる決済を行うとわかるのですが、「処理中」と表示され、翌月の請求に含まれないものがあります。こちらはメルカード特有の実売上処理が終わってから請求する挙動です。順番に解説していきます。 カード決済の流れ 決済は大きく2段階の処理で成り立っています。「オーソリ」や「仮売上
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計 遷移なく表示コンテンツを変更できるシングルページアプリケーションでは、ページの状態管理が重要になります。現在はReactによるUI構築とReduxによる状態管理を選択しているChatworkは、jQueryなどの技術的負債と共存しながら、フロントエンド設計の見直しを重ねてきました。クライアントサイド・アーキテクトの火村智彦（@eielh）さんと、エンジニア採用広報の高瀬和之（@guvalif）さんによる解説です。 クラウド型ビジネスチャットツール「Chatwork」は、2011年3月にローンチされて10年以上にわたり開発を継続してきました。このように長く続くサービスがユーザーに価値を提供し続けるには、時間経過による変化に適応するため設計の見直しが必要になります。 しかし、設計を
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
▼イベント▼ Spring Fest 2021 https://springfest2021.springframework.jp/ ▼配信アーカイブ▼ https://www.youtube.com/watch?v=9-yDaFlGTxE
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
