でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。

はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？　予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。

ﾍﾟﾛﾍﾟﾛチンチン @majikitchy 絶対に『挨拶しても無視する人』が職場に居て、なにも知らない新人さんが「あっ！」ってなって手話で挨拶しだして周りは肩震わせるし本人は恥ずかしくなって顔赤くしてたって話思い出した 2024-03-20 18:07:58

これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力

この記事の概要 tmuxとneovimを組み合わせている様子… こんにちは！食パン🍞と申します🏜 普段はフロントエンドを中心にパソコンをｶﾀｶﾀしている者です💻 私は普段のコーディング時のメインエディタとして、ターミナル環境下で、Neovimを用いています。 (Neo)Vimは、その独特な操作体系ゆえ慣れるまでがちょっぴり大変ですが、一度習熟すると非常に効率よくテキスト操作を行えるため、日々愛用しています。 また、開発作業の過程では、複数の画面を都度切り替えながらコーディングをしたり、複数のシェルを用いてコマンド操作を実行したくなる機会が多々あります。 例えば、 Viteでフロント開発環境を立ち上げてリアルタイムでコード変更を確認したい docker composeで複数のコンテナを立ち上げつつターミナルでログを確認したい それはそれとしてNeovimも並行して使いたい といった具合

単著ならではの一貫性と、筆者のノウハウをありったけ突っ込んでやろう！というあっつい想いを感じる素晴らしい書籍です。 「2018年から2024年、コンテナ界隈もいろいろ変わったもんだなぁ…（しみじみ）」 献本いただいた「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を眺めながら、ハマコーはそんな感慨にふけっておりました。 5年前、Docker始める人はまずこれ！書評「Docker/Kubernetes 実践コンテナ開発入門」で旧版の書評を書いたご縁で、著者の山田さんより改訂新版の献本をいただき、今この場にその本があるというわけです。 改めて中身読んでいたのですが、単著でこれはマジでやばいです。今コンテナを使った開発を進めようとしたときにでてくるであろう、開発〜運用面でのトピックが幅広く凝縮されている本で、「これ一冊読んどけば、マジはずれないよ」というぐらいの力が入った書

「Uizard」はAIを使ったUIデザインツールで、ワイヤフレーム、モックアップ、プロトタイプを短時間で作成できます。最新の「Generate with Autodesigner」サービスはUI画面を自動で生成可能。今回は実務に根ざしたサンプル生成で、UIの精度を検証します。 こんにちは。CXデザイナー事業本部のスギヤマです。普段はモバイルアプリケーションやLINEアプリケーション開発に携わっております。 「Uizard」は、デンマーク コペンハーゲンのソフトウェア企業が開発しました。AIを利用したUIデザインツールで、ワイヤフレーム、モックアップ、プロトタイプを短時間で作成することが出来ます。手書きスケッチもワイヤフレームに変換し、簡単にプロトタイプ化すること出来ます。 以前から、「手書きのUIスケッチを美しい画面デザインに変換してくれるサービス」として話題だった「Uizard」ですが、

RHEL互換ディストリビューション、SUSEも参入へ。制限なく誰でも利用できるRHEL互換OSを開発していくと エンタープライズ向けのLinuxディストリビューション「SUSE Linux Enterprise Server」などを提供するSUSEは、Red Hat Enterprise Linux（RHEL）をフォークし、制限なく誰でも利用できるRHEL互換ディストリビューションを開発し保守していくと発表しました。 同社はこのプロジェクトに今後数年で1000万ドル（1ドル140円換算で14億円）以上を投資し、プロジェクトをオープンソース財団に寄贈すると次のように説明しています。 SUSEは、オープンソースコミュニティと協力して、RHELとCentOSのユーザーのための長期的かつ永続的な互換性のある代替製品の開発に取り組んでいます。SUSEは、このプロジェクトをオープンソース財団に寄贈し、

こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想

Red HatにRocky LinuxとAlmaLinuxが反論。OSSの精神と目的に違反している、ダウンストリームのリビルドは価値をもたらす、など Red Hatは6月、Red Hat Enterprise Linux（RHEL）のクローンOSベンダに対して排除する方向性を打ち出しました。このことが、多くの議論や影響を引き起こしています。 Red Hatが起こしたアクションは2つです。1つはCentOS StreamをRed Hat Enterprise Linux（RHEL）関連の唯一パブリックなソースコードリリースのリポジトリにすると発表し、事実上、RHELのソースコードの一般公開を取りやめにしたことです。 参考：Red Hat、今後はCentOS StreamがRHEL関連のパブリックなソースコードの唯一のリポジトリになると発表 RHELのソースコードへのアクセスは有料のサブスクリ

Red HatがクローンOSベンダを非難、「付加価値もなくコードをリビルドするだけなら、それはオープンソースに対する脅威だ」と Red Hatは、Red Hat Enterprise Linux（以下RHEL）のクローンOSを提供しているベンダを「オープンソースに対する脅威だ」と非難する内容を、6月26日付けのブログ「Red Hat’s commitment to open source: A response to the git.centos.org changes」（Red Hatのオープンソースへのコミット：git.centos.orgの変更に対する返答）で明らかにしました。下記はその部分の引用です。 Simply rebuilding code, without adding value or changing it in any way, represents a real t

※実行時間の単位は全てmsです パーティション数が1,000になると汎用プランの再検証で1000パーティションへのスキャンが発生するため、bindが遅くなっていることが分かります。気になっていたunnamedなPrepared Statementについては名前付きのPrepared Statementに比べて早いような気もするし、誤差のような気もするし...ここはもう少し計測回数を増やして詳しく見ていきたいところです。 WHERE句をリテラルで記述した非Prepared Statementの場合は1000パーティションかつforce_generic_planの場合でも6.2msで処理できており、汎用プラン再検証のオーバーヘッドが発生していないことが伺えます。 1000パーティションのテーブルに対して1000回クエリを発行してbindのオーバーヘッドを確認してみる 先程の検証結果から 100

こんにちは！フロントエンド開発課のkoki_matsuraです。 この記事では、僕が開発に携わっている製品のE2Eテストに取り入れたページオブジェクトモデル(POM)という実装パターンの概要と取り入れたキッカケ、POMへリファクタリングする簡単な例をご紹介させていただきます。 僕と同じようにE2Eテストに関わっている方、E2Eテストに興味を持っている方などに読んでいただけると幸いです。 目次は下記のようになっています。 POMとは なぜPOMを使い始めたのか POMへのリファクタリング ログイン画面 テスト内容 POM導入前のテストコード ページオブジェクト作成 POM導入後のテストコード 終わりに POMとは Webアプリケーションのテスト自動化において、テストコードとWebページを分離して管理する手法です。 POMを使わない従来のテストコードはWebページと分離しないため、どうしてもD

Bun.build({ entrypoints: ['./src/index.tsx'], outdir: './build', minify: true, // その他設定があれば }); Reducing complexity in JavaScript フォームフィールドの自動入力から始まったJavaScriptは、今ではロケットを宇宙に打ち上げる機器に活躍するところまできています。 当然の成り行きですが、JavaScriptエコシステムの複雑さは爆発しました。 TypeScriptのファイルはどうやって実行する？ 本番用コードはどうビルドする？ そのパッケージはESMで動作する？ ローカル設定を反映するにはどうすればいい？ バージョン互換性をどう解決すればいい？ ソースマップはどうやって作れば？ 複雑であるということは、すなわち時間がかかるということです。 npmパッケージのインス

Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 ■Geeks Who Drink https://nulab.connpass.com/event/68737/ ■PostgreSQL Conference Japan 2017 https://www.postgresql.jp/events/jpug-pgcon2017

2022.11.15に発表した内容になります。 https://www.youtube.com/watch?v=ScNN3uGXFd0

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ

こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/

この記事について この記事は、 Web制作の基礎から学べる「Webコーディングスクール」 などの資料制作をお手伝いして頂いているemiさんによる寄稿記事です。 emiと申します。USAGI DESIGN emi.というサイトでWebデザインやコーディング練習用のデザインデータを配布しています。Webデザインをメインにストックイラストレータ、グッズデザインなどしております。 ChatGPTとは ChatGPTはOpenAIが開発した対話型のチャットボットです。質問を入力すると質問に対する回答が出力されます。 今回はChatGPTを使って、効率よくコーディングを進めてみます。 headタグ内のコードをChatGPTで生成しよう HTMLの大枠をChatGPTを使ってコーディングしてみよう グロナビをChatGPTで生成してみよう ボタンをホバーした時のCSSをChatGPTで生成してみよう H