Scala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban

列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi

私は日付時刻の処理が大好きです。 タイムゾーンの問題でデータ抽出が9時間分漏れていたとか、朝9時の始業前のログが昨日付けになってしまっていたなんていう問題が起こると喜んじゃうタイプ。 そんな私にとって、各プログラミング言語が標準で持っている日付時刻型クラスにはそれぞれ思うところがあり、今日はちょっとその品評会をしてみたいと思います。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の2日目です。 至高の日付時刻型を持つ言語、BigQuery SQL 不足はないが蛇足、Java 8 日付時刻で画竜点睛を欠いたC# C#よりややまし、Python 型は良い構成、なのに命名と処理関数で損しているPostgreSQL まとめ We ar

この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって

こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。

今回は、何らかのパラメータを扱うAPIを設計する際に、どこにパラメータを含めるべきかという問題について。 選択肢は3つあります。 1. クエリストリングに含める 2. リクエストボディに含める 3. パスに含める それぞれどんなユースケースに適しているのか例を挙げます。 1. クエリストリングに含める 何らかのリソースのフィルタリング、ソート、ページングを実現したいときに用います。 クエリ と名前がついているくらいですからね。 一覧や検索が主ですね。ゆえに GET 以外で見ることはほぼありません。 ただし、認証のような例外もあります。これは後述します。 検索

はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです！ 設計に関する記事 ソフトウェアデザインとアーキテクチャは、DevOpsやUXデザインのように、コンピューティングの領域の中でも独自の研究分野となっています。ここでは、クリーンコードからマイクロカーネルまで、ソフトウェアデザインとアーキテクチャの幅広さを説明するマップを紹介しま

UUIDの生成には、乱数を使う場合の仕様 RFC4122 がありますので、できればそれに従うようにしましょう。 コードなら、こんな感じ。 (gistより引用) function uuid() { var uuid = "", i, random; for (i = 0; i < 32; i++) { random = Math.random() * 16 | 0; if (i == 8 || i == 12 || i == 16 || i == 20) { uuid += "-" } uuid += (i == 12 ? 4 : (i == 16 ? (random & 3 | 8) : random)).toString(16); } return uuid; }

名前付けのガイドラインでは、アセンブリ、名前空間、型、メンバー、およびパラメーターなど、クラス ライブラリの構成要素に対して適切な識別子を選択するためのガイダンスを示します。 これらのガイドラインに従った識別子を選択すると、ライブラリの使いやすさが向上します。このため、ユーザーはライブラリを使用するために新しい一連の規則を習得する必要性を感じずに済みます。 開発者にとって一貫性のある環境を提供するには、パブリック クラスやプロテクト メソッドなど、公開される要素にこれらのガイドラインを適用する必要があります。 ただし、コード全体での一貫性を維持し保守性を向上させるには、これらの規則をコード全体で一貫して使用することを検討します。 Portions Copyright 2005 Microsoft Corporation. All rights reserved. Portions Copy

おはようございますこんにちわこんばんわ。どうもぶたです。 以前、チーム内で「変数や関数の名前に妥協したくないなー。どうしたら上手く命名できるんだろう？やっぱり英語の勉強？」という話になったので、今回は名前付け、命名についてまとめます。 とは言え、自分自身多くの記事やドキュメント、書籍などに助けられているので、ほぼ紹介記事になります。 ただ、順番には気をつけた方がいいと個人的には思っています。 何事もそうですが、なぜやるのかを知ってからどうやるのかを学ぶべきかな、と。 例えば、「この単語とこの単語はニュアンスが違う」「そんな単語存在しないよ」「単数と複数が間違ってる」 そんなレビューを受けたことがある人もいると思います。僕も言われたことがあります。 そういった内容の記事もたくさんあります。僕も読み込んでいますしストックして参照できるようにしています。 それはそれで有用ですし、是非意識していき

こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい

ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで

JJUG CCC 2023 Spring 発表資料（ステップアップセッション）。 私がクラス設計をするときに重視している考え方とやり方を紹介。 主な内容 ・クラス設計のスキル　3段階 ・クラス設計の技能を習得するシナリオ ・７つの基礎知識 ① 入出力と計算判断 ② プログラムの中核と周辺 …

はじめに 最近コードレビューの機会が増えてきたので、「リーダブルコード」を読み直しました。 リーダブルコードを読んでいく中で要点を整理し、実務の現場でコードを書いたりレビューをする際にどのように活用していくべきかを自分なりにまとめてみました。 この記事を読むことで、リーダブルコードの要点の把握と実際の活用例を学ぶことができます。 この記事の主な対象者 リーダブルコードの要点をサクッと知りたい人 初級~中級者(実務歴1~3年目)の人 コードレビューの機会が増えてきた人 これまで我流でコードを書いてきた人 リーダブルコードについて リーダブルコードはあくまで「こう書きなさい」と押し付け口調ではなく「こう書いた方がもっとよくなるよ」といった丁寧な語り口で書かれています。 それを前提として要点や活用方法をまとめていきます。 1章 理解しやすいコード 優れたコードについて リーダブルコードで優れたコ

「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識／運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ

当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう？　あらゆるソフトウェアに通用する原則はあるのでしょうか？　そもそも「原則」とは何を意味するのでしょう？ 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良

yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ