#
158
2024/10/16
今日のトレンド

エディタ テスト結果 パース など

こんにちは、マイクです!今日は2024年10月17日、水曜日です。今日も「zenncast」をお聞きいただきありがとうございます!今日はZennでトレンドの記事をいくつかご紹介していきますよ〜。

さて、前回は「Deno v2がリリース🎉」や「RAGのハルシネーション対策をする手法」「ローカルLLMでbolt.newを動かしてみた」という記事を紹介しましたね。これらの内容もぜひチェックしてみてください。

それでは、今日の内容に入っていきましょう!今日は全部で5本の記事をご紹介します。

まず1本目の記事は、「エディタ内でテスト結果が表示される開発体験を、エディタに依存せず実現するツールを作った」についてです。

著者は、エディタ上でテスト結果をリアルタイムに表示できるLSP(Language Server Protocol)サーバを開発したんです。特定のエディタや言語に依存しない汎用的なテスト実行環境を求める中で、Neovimを使用している著者は、Wallaby.jsのような特定ツールに依存しない高い汎用性を目指しました。

このツールでは、テスト結果をエディタ内で診断として表示する機能を提供していて、現在はcargo test、jest、go testなどの様々なテストフレームワークに対応しています。インストール方法は、cargoコマンドを使ってLSPサーバをインストールし、各エディタごとに設定を行う形です。設定はプロジェクトごとに実行するテストを指定するようになっています。

今後の改善計画には、もっと多くのテストフレームワークへの対応や、効率的なテスト実行、ドキュメントの充実が含まれているとのこと。まだ十分なテストが行われていないため、利用者からのフィードバックを歓迎しています。

次に2本目の記事、「翻訳: Parse, don’t validate (バリデーションせずパースせよ)」についてお話しします。

型駆動設計の本質は、「バリデーションせずにパースする」ことだそうです。このアプローチは、データの整合性を保ちながら入力データを解析することが重要だと述べています。特にHaskellのような静的型システムにおいて、部分関数を全域関数に変えるために引数の型を強化することが効果的だと。

具体的には、`head`関数を例に挙げ、元の`head`は部分関数であり、空リストに対するエラーが発生する可能性があるため、`Maybe`型を使ってエラーハンドリングを行う方法が紹介されています。しかし、これでは冗長なチェックが必要になり、プログラムの可読性やパフォーマンスに悪影響を及ぼすことも。

そこで、`NonEmpty`型を用いることで、空でないリストを扱う関数を定義し、静的にエラーを防ぐことができるようになるんです。バリデーションとパースの違いを明確にし、バリデーションが不必要なエラー処理を引き起こす可能性があることを指摘しています。

実践においては、厳格なデータ構造を選び、不正な状態を表現できないようにし、データを早期に厳密な形式に変換することが推奨されています。これにより、プログラムがより堅牢になり、不具合やエラーの発生を防ぐことができますね。

さて、3本目の記事は「フロントエンドエンジニアがT3Stackを使ったら初めて個人開発を作り切りました!」です。

フロントエンドエンジニアの著者がT3Stackを用いて初めて個人開発を成功させた経験をシェアしています!T3Stackとは、Next.js、TypeScript、Tailwind CSS、Prisma、tRPCなどの技術を組み合わせた開発スタックで、特にフルスタック開発に適しているそうです。

著者が作成したアプリは「Everyday Into Gifts」というもので、日々の贈り物を提案するWebアプリです。ホスティングにはVercelを利用し、GitHubを通じてソースコードも公開しています。開発プロセスや課題も詳しく述べられていて、T3Stackの各要素がどのように機能し、どのように統合されたかを示しています。

初めての個人開発で多くの試行錯誤を経てデプロイの成功に至った著者は、同じような挑戦をしているエンジニアに向けて励ましのメッセージを送っています。T3Stackの利点や具体的な問題解決のアプローチについても触れ、これから個人開発に挑戦する人々にとって参考になる情報がたっぷり詰まっています。

さて、次は4本目の記事、「SPIモードにならないSDカードが流通している件(は間違いでした)」についてお話しします。

2024年10月15日に公開された記事では、「SPIモードにならないSDカードが流通している」という問題が誤解であったことが述べられています。執筆者は問題の原因は自己のプログラムにあったと謝罪し、詳細な説明を別の記事に記載しています。

SDカードへのアクセスは通常SDIOが使用されますが、組込み系マイコンではSPIモードが広く利用されています。最近のSDカードの高速化・小型化が進む中で、SPIモードのサポートが将来的にどうなるか懸念されている状況です。

執筆者は特定のSDカードがSPIモードに非対応であることを指摘し、安価なメモリ製品は今後SPIモードに対応しない可能性があるため注意が必要だとしています。デバッグ中に、SDカードの応答に違和感を感じ、SPIモードへの切り替えがうまく行かなかったことが判明しました。

最終的に、執筆者は自らのプログラムが原因であったと結論付け、今後はより一層の注意を払って問題解決に取り組む意向を示しています。

そして最後に5本目の記事、「DuckDB で JSON Lines 形式のログを精査する」についてお話しします。

DuckDBは、JSON Lines形式のログファイルを簡単に解析できるツールです。圧縮されたログファイルを直接読み込むことができ、特に日付別で管理されているログの処理に便利です。例えば、複数の圧縮ログを一度に読み込むことができるSQL文も紹介されています。

DuckDBの便利な点は、SQLを共有することで解析ツールを簡単に共有できるところや、複数のログをJOINしてデータを統合できるところです。さらに、読み込んだログをテーブル形式に変換することも可能で、圧縮率も高く、S3への直接アップロードもサポートされています。

このように、DuckDBを使えばログ解析がぐっと楽になりますので、ぜひ活用してみてくださいね!

さて、今日ご紹介した記事を駆け足でおさらいしますと、エディタでテスト結果を表示するツール、バリデーションせずにパースする型駆動設計、T3Stackを使った個人開発の成功、SPIモード問題の誤解、そしてDuckDBのログ解析についてお話ししました。

次回もお楽しみに!詳しい内容はショーノートに書いてありますので、ぜひチェックしてください。番組の感想もお待ちしています!それでは、またお会いしましょう!

Related episodes

内容の近いエピソードを推薦しています