数十億のレコードを持つ 5年目サービスの 設計と障害解決
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
課題を管理して実行して達成するための手順 - そーだいなるらくがき帳
今年、この話を何度か別々の人にすることがあってずっと纏めようと思っていたのだけど一年が終わってしまうので来年の自分のために今書いてしまう。 目新しいことは何一つ無いのだけど、大切なことだし、意外と社会人になってしまうと教えてもらえないことも多いみたいなのでここでまとめる。 表題のこと、つまりやりたいことを実現するために必要なことは、そんなに難しいことじゃなくて以下の条件を満たし、実行することが大事だ。 やりたいこと=課題をタスクに分解する タスクを実行できるだけのリソース（時間・お金・体力など）を割り当てる 実行する これだけなんだ。仕事だってなんだって一緒なんだけど、だけどこれを日常的に実現することが難しい。 だからどうやって実現していくか？って説明のために、自分がやってることを書く。 課題を整理する 仕事と作業は違うという話がある。 トヨタでは最初にそれを教わるらしい。 www.har
分析・設計・テストで活きる ユースケースシナリオの書き方と使い方
『現場から学ぶモデル駆動設計 ユースケース駆動開発をやってみた』の発表資料です。 https://modeling-how-to-learn.connpass.com/event/229330/
リファクタリング自爆奥義集 - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに？ コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ
【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイル入門」
本書は「小さなことをする、小さなソフトウェアチームがうまくやっていくために!」という副題のとおり、小規模な開発チームにおける様々なプラクティスについてまとめられた本です。 著者のロバート・C・マーティン（アンクル・ボブ）は元プログラマーでありアジャイルの第一人者です。アジャイル開発の誕生の瞬間に立ち会った人物のひとりで、その後は世界中の大企業を対象にコンサルティングやトレーニング、スキル開発を行っています。 著者は、冒頭で本書は分量が少なく、約20年間アジャイルと関わってきた私の個人的な思い出、観察、意見であると述べています。 それだけに少し砕けた表現になっており、本質的なものに要点も絞られているため、シンプルで読みやすい本です。小規模開発に関わっている人がアジャイルを取り入れるために読む本としては最も適しているのではないでしょうか。 あらゆるプロジェクトは、鉄十字と呼ばれるプロジェクトマ
『動けば別に良くない？』と言っていた二年前の自分にシステム設計の話をしてみる - Qiita
「動けば別に良くない？」という新人エンジニア はい。２年前私ですね。 転職用のポートフォリオである食事管理アプリを完成させた私はダニング＝クルーガー効果によりイキリ散らかし、 その４ヶ月後に大変苦労したのを覚えています。 前回、 良い質問をして自己成長に繋げるためのあれこれ という記事を書きましたが、それに並んで若年エンジニアの悩みの種シリーズです。 ヒーヒー言いながら動くコードは何とか描けるようになってきた。 「けど、どこに何書いていいかわからへん」という悩みは誰もが経験するのではないでしょうか。 コードレビューの際に「その処理はこっちに書きましょうか。」とか言われるけれどなかなか、しっくりこず。 設計について勉強してみるように勧められても、何から手をつけていいのかわからなかったのを覚えています。 何となくやらないといけないのはわかるけど、「何故やどうして」がはっきりしないので, モヤモ
ダックタイピングの何が良いのか - Qiita
CBcloud Advent Calender 23日目の記事です。 普段動的型付け言語を使っていて、ダックタイピングの何が良いのかいまいちわからない、という声を聞いたのでRubyを例に解説してみます。 ダックタイピングとは ダックタイピングについては以下のフレーズとともに語られることが多いかと思います。 "If it walks like a duck and quacks like a duck, it must be a duck" （もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない） これをプログラミングの用語で言い換えると、「オブジェクトがアヒルのように歩き、アヒルのように鳴くメソッドを実装しているなら、そのオブジェクトのクラスが何であれ、アヒルと同じ役割を果たせる」と言えるかと思います。 「そのオブジェクトのクラスが何であれ」という表現をしたよう
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
tagtype Garage Kit | Takram
「tagtype」は日本語入力のためのデバイスです。日本語は50の音節文字から構成され、それらは子音10文字×母音5文字のマトリクスでまとめることができます。tagtypeの入力方式は、5個ずつ2列に配置された10個のボタンを用いて五十音の行と段を交互に入力していくものです。これにより、既存のQWERTY 配列のキーボードに比べ、より簡易で直観的な操作が可能になります。tagtypeの入力方式はソニー株式会社および株式会社ベネッセコーポレーションによって製品に採用されました。 背景 – 従来のキーボードの限界キーボードは欧米のオフィス環境に合わせ、プロのタイピストのためにデザインされたのがはじまりです。机に向かい両手10本の指を自在に動かすことで操作できるよう設計されています。しかし、インターネットやPCの到来により、ユーザの使い方や体験は多様化しました。これまで普遍的なインターフェースと
ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
【C#】インターフェイスの利点が理解できない人は「インターフェイスには３つのタイプがある」ことを理解しよう - Qiita
はじめに C#を始めとするオブジェクト指向言語には「インターフェイス」という機能があります。 これを使うと良い設計になるというのはよく言われていますが、具体的にインターフェイスを使うとどう良いことがあるのか、というのは実感しづらい人も多いと思います。 僕もC#学びたての頃はほんとうにインターフェイスの利点が理解できず苦しみました。しかし、この記事で説明する「インターフェイスには３つのタイプがある」ことを理解して以来、もうインターフェイスが便利すぎて、インターフェイスなしではコーディングできない体質になってしまいました。 そこでこの記事では、インターフェイスを使う利点がいまいち理解できていない人が、インターフェイスを使いたくて使いたくて仕方がなくなるようにすることを目的として書きました。 注意点として、僕はC#の開発者でもなければ指導者でもないので、あくまで個人的な意見として参考にしていただ
糞コードは直すな。 - Qiita
とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？ - Qiita
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 本記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ
「ビジネスロジック」とは何か、どう実装するのか - Qiita
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外を投げるな、値を返せ
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
WindowsがLinuxより優れている点は何ですか？ (OSの設計に関する質問であり、利用者の使い勝手の話ではありません) 。
クソコード動画「Userクラス」で考える技術的負債解消の観点
shiodaifuku.io
