サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事は LayerXTech Advent Calendar 2025 12 日目の記事です。 前回は@tigerさんのslack-blockbookというslack appのUI確認を爆速にするライブラリについての記事でした。 こんにちは。株式会社LayerXソフトウェアエンジニアのyataです。 皆さん、もちろん緯度経度は好きですよね？ 今回は、緯度経度と住所を用いた開発に取り組んだ際のお話です。 「緯度経度から住所を割り出す」。 一見簡単そうに見えるこの要件の中で、日本の住所に絶望し、そこから希望を見つけるまでの物語をお届けします。 やりたかったこと 今回実装したのは、大まかに説明すると「デバイスの位置情報を記録し、画面上から確認することができる」という機能です。 緯度経度を取得すること自体は、WebAPI である GeolocationAPI を使えば簡単に実現できます。
2025-11-14に開催されたYAPC::Fukuoka 2025での登壇資料です
type そのもの、 あるいは _type のようなsuffixを持つ名前を変数や、構造体・クラスのメンバーや、データベースのcolumnなどに付けてしまうことがしばしばあると思うのですが、個人的にはあまりこれはやらない方が良いのではないかと考えています。 理由としては type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い。Ruby onRailsにおいてはDelegated Typesという機能において、 _type というcolumnは特別な意味を持つ (もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無いのですが)。 その他のフレームワークに似たようなものがあるのかは知りませんが…… というものがあると思っており、そういった概念との衝突を避けるために特別かつ強
はじめに 生成AI（ChatGPT、Claude、GitHub Copilotなど）でコードを書く機会が激増している中、開発スピードは劇的に向上していますが、「動くコード」と「安全なコード」は別物です。 特に本番環境では、パフォーマンスやセキュリティ、保守性まで考慮する必要があります。AIが特に書きがちな（または書いたら嫌な）危険パターンを15個 厳選してみてみました。それぞれに「何が危険か」と「修正例」をセットにしています。 【 この記事の対象読者 】 ◇ 生成AIを使ってPythonコードを書いているエンジニアとか ◇「動くけど本番に載せて大丈夫？」と不安を感じたことがある人とか ◇ チーム開発でAI生成コードを安全に活用したい人とか とりあえず、「覚えておいたら便利かも！」ってところです。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 昨今のAIエージェント界隈の競争が激化していることは周知の事実だと思います。 先日リリースされたCodex CLIによりClaude Codeが押され気味であることは否めません。 しかし！！そんなClaude Codeが確実に優っている点があります！！！ はい。活発かつ成熟したコミュニティですね。しばらくは覇権を取っていただけに、様々な関係ツールが公開されています。 というわけで、Claude Codeをより便利に使うことができる周辺ツールを集めてみました。 ccusage 言わずと知れたコスト・使用状況可視化ツールです。 開
ある開発者が自身のLLMを用いたコード生成ワークフローを次のように語っている。 tl;dr まずブレインストーミングで仕様を固め、次に “計画そのものを計画” し、それから LLM のコード生成で実装。小さなループを回していき、あとは魔法 ✩₊˚.⋆☾⋆⁺₊✧ Step 1: アイデアを絞り込む 対話型LLMに、アイデアを磨き上げさせる。 Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea... Remember, only one question at a time. （訳：このアイデアを徹底的かつ段階的な仕様に落とし込むために、一度に一つずつ質問してください... 覚えておいて、質問は一度に一つだけです。） これでかなりsolidなspec.mdが手に入
こんにちは。ruby-devチームの遠藤（@mametter）です。 次期バージョンのRubyでは、pathnameがRuby本体組み込みとなり、require "pathname"なしで利用可能になる予定です。Rubyで書き捨てスクリプトを書いてる自分のような人は地味にうれしいかもしれません。 Feature #17473: Make Pathname toembedded class ofRuby -Ruby -Ruby Issue Tracking System さて、pathnameの組み込みがマージされた直後、非常に興味深いバグが発生しました。 今回はそのデバッグの経緯を技術ブログとして共有したいと思います。 問題の発生：特定環境でのみ失敗するテスト コミッタのhsbtさんがpathnameの組み込み化をマージした後、なぜかRubyのCIの一部が落ちるようになりました。
Sansan Engineering Unit マスターデータグループ（データ戦略部門）の松本です。 私たちのチームは、「Activating Business Data」というミッションを掲げ、企業の活動の礎となる重要なデータ、いわゆる「マスターデータ」とその利活用という課題に、技術を駆使して向き合っている組織です。 さて、ビジネスデータを扱う上で「住所」は欠かせない情報です。 それは単に「モノを届ける場所」を示すだけではありません。 お客様を深く知るための「解像度」になる: 顧客のオフィスの位置を正確に知ることは、効果的なマーケティングや営業戦略を立てる上で不可欠です。 データ統合の「鍵」になる: 複数のサービスやデータベースに散らばったお客様の情報を「同一人物である」と正しく繋ぎ合わせる（名寄せする）際、住所は氏名と並んで最も重要なキー情報となります。 このように、正確な住所データは
コードを読んでいるときに「なんかよく分からんが複雑でわかりにくいな...」と感じることはありませんか？ 私は既存のコードを読んでいるときはもちろん、自分が書いたコードを読むときもそう感じることがあります。 複雑さの要因を理解していないと、適切な改善ができませんよね。 今回は、「脳に収まるコードの書き方」という書籍を参考に、コードの複雑さの可視化とその複雑度を軽減させる方法を解説していきます。 前提 当たり前ですが、コードは書く回数よりも読まれる回数の方が多いです。 コードの価値には、アプリケーションが動くことだけではなく可読性も大きく関係しています。 目先のリリースを優先して「とりあえず動くコード」を許してしまうと、将来、他の誰かあるいは未来の自分がそのコードを読むときに必ず苦しむことになります。 可読性を二の次にせず、「脳に収まるコード」のための最適化を常に検討しましょう。 コードの複雑
GitHubは、生成AIがプログラミングなどを支援してくれる「GitHub Copilot」の新機能として、「GitHub Copilotコードレビュー」が正式版になったことを発表しました。コードレビューは開発に欠かせないが時間がかかるコードレビューは、新しくコードを書いたときや変更するときなどさまざまな場面で、そのコードにバグなどの問題がないか、目的に沿った内容や表現になっているか、などのチェックや評価を行う作業です。 チームでシステム開発を行ううえでコードレビューは欠かせませんが、コードレビューは基本的にレビューを行うプログラマ（レビュワー）がコードを目視で読み取り、チェックしていくことになるため、レビュワーにとって負荷の高い時間のかかる作業となっています。 最低限のコードレビュー作業を生成AIが代行GitHub Copilotコードレビューは、GitHub Copilotに作業
はじめに こんにちは、ダイニーの ogino です。 この記事では、コードの読みやすさを比較判断するために役立つメンタルモデルを紹介します。本記事を読むと、「このコードは良い / 悪い」という感覚が身につき、その理由を自信を持って説明できるようになるはずです。 コードの読みやすさとは何か コードを読む時には大抵、何か特定の目的があります。例えば、API /foo にリクエストした時の動作を知りたい、ある画面で発生しているバグの原因を知りたい、などです。 この時、コードベースの隅から隅まで読み尽くすのではなく、特定のポイントから出発して関連する箇所を芋蔓式に辿りながら読むはずです。 人が一度に理解して覚えておける情報量には限界があるので、辿らなければいけないコード量が少ないほど当然読みやすくなります。 つまり、ある目的に関連するコードの箇所が局所的かつ明示的であるほどコードは読みやすいと
SOLID原則というのがあるのだけど、原則といつつ やりすぎに注意なみたいなことを言われ、自分で塩梅を探らないといけないなら全然原則じゃないやんということであまり好きではないのだけど、その中でもここではOにあてはまる開放閉鎖原則って意味ないよねって話を。 開放閉鎖原則の原典はメイヤーの「オブジェクト指向入門」で、第2版には次のような記述があります。(初版も書いてることはだいたい同じで、2版のほうが整理されて記述も多くなってます) モジュールは開いていると同時に閉じているべきである ただ、このメイヤーの文脈でいうようなモジュールの拡張ってやらないよねと。 ここでメイヤーの文脈での拡張というのは、モジュール自体に手をいれずに、機能の追加や変更ができるというものです。継承使っていい感じに機能追加ができる設計が「拡張に開かれている」ということです。 でもまあ、そんなライブラリの拡張をやらないですよ
Parquetは便利なファイル形式で、列志向のフォーマットとしてはデファクトの1つと言っても過言ではないでしょう。 ですが、jsonやcsvとは違い、ファイルを見ただけでどんな構造かわかるものではありません。 この記事は、Parquetの具体的な構造について記述します。 はじめに この投稿は、Parquetの構造について、バイナリを見ながら確認するものです。 ただし、Parquetの大枠に注目した投稿なので、delta encodingやrun-lengthなど、個別の圧縮方法については取り扱いません。 ※ Parquetの作成には https://github.com/parquet-go/parquet-go を使用していますが、goの知識は必要ありません tldr Parquetは以下の構造を持っています。 ファイルはRowGroupとメタデータに分かれている RowGroupの中に
米国防総省DARPA、C言語のコードからRustへの自動変換実現を目指す「TRACTOR」プログラム開始アメリカ国防総省 DARPA（Defense Advanced Research Projects Agency：国防高等研究計画局）は、C言語のコードからRust言語のコードへ高い精度での自動変換実現を目指す「TRACTOR」（Translating All C toRust）プログラムの開始を発表しました。 DARPAは軍事技術の開発および研究を行う機関であり、現在のインターネットはDARPAの前身となるARPAが1967年に開始した「ARPANET」がその起源であることはよく知られています。 DARPAが発表したTRACTORプロジェクトは、C言語のコードからRust言語のコードへの自動変換を高い精度で実現することで、過去にC言語で開発された多くのソフトウェアをメモリ安全なソフ
こう言うのがあって。 class Hoge { public static void main(String[] args) { Object hoge = null; hoge.toString(); } } 実行すると当然NPEになるんだけど、こんな感じで出る。 %java Hoge.java Exception in thread "main"java.lang.NullPointerException: Cannot invoke "Object.toString()" because "<local1>" is null at Hoge.main(Hoge.java:8) 一昔前は Cannot invoke "Object.toString()" because "<local1>" is null なんて出なかったんだけど、 JEP 358: Helpful NullPo
なぜ令和にもなって動的型付け言語を使うのか シフトレフトという概念が生まれたのは二十年以上も前のはずだ。 それにもかかわらず動かしてみるまで答え合わせもできない言語で開発をするという発想自体がどうかしている。 同じ動的型付けといってもJavaScriptはブラウザという事情があるし、型の表現力に優れたTypeScriptがあるからまだよい。 しかし、Pythonはどうだ。他にいくらでも選択肢があるなかで、サーバーサイドにわざわざ選定する言語ではなかろう。 貧弱な型ヒント、しかも書いたところで大した効用もない。 使っている外部ライブラリにひとつでも型ヒントがクソなものがあれば即座に破綻する。 型というガードレールもシートベルトもなしで糞を撒き散らしながらする開発にはうんざりだ。 シンタックスもキモい 動的型付けもさることながら、シンタックスもキモい。とにかく思考を妨げる語順になっている。 m
概要 プログラミングをしていると実装の方式を試してみることがあると思います。あるいは、別の実装でうまくいくか自信のない時、今あるものはコメントアウトしておいて別の実装を試してみたり。そんな場合、今時はエディターの機能で簡単にブロックをコメントアウトしたりできますが、言語仕様をうまく使って一文字編集するだけでコードブロックをコメントアウトする小技を大昔に思いついていて今でも使うことがあるので紹介します。実装中の試行錯誤の時には便利です。 この技はC++/Java/Javascript系の、ブロックコメント/* ... */とインラインコメント//がサポートされている言語で利用できます。 ブロックを/の削除でコメントアウトする 以下のように書いておくと、一番最初の/を削除すると最初の行がインラインコメントからブロックコメントに切り替わり、ブロック全体がコメントアウトされます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
