Bun.SQL now supports MySQL and SQLite, alongside PostgreSQL. Native YAML support. 500x faster postMessage(string). Bun.build() compile API, with...
文章から画像を自動生成する DALL・E2 が先日一般公開された。画像の商用利用も可能とのことなので、うまくすれば note 記事のアイキャッチ作成に使えるかもしれない。 使用は基本無料だが申請制である。かなり待ち行列が長いらしく、僕は7月6日に申請したら7月30日に通った。住所や職業や使用目的などの面倒な入力欄はなかった。SMS 認証があるので電話番号を取られる点だけ注意されたし。 テキスト(英文)を入力すると、15秒ほどで1024×1024の画像を4枚生成してくれる。初月は無料で50回、それ以後は毎月15回分のクレジットが発行される。もっと使うには課金が必要で、15ドル115回なので1回17円。OpenAI とか名乗っていながらずいぶん商業的なフリーミアム形態だが、ちょっと遊んでみる分にはちょうどいい。 とりあえず触ってみるてっきり Python 等から API を叩くのだと思っていた
ソフトウェア&ツール-Software&Tool テクスチャ ソフト Normalmap_generator v1.0 - でんのこ氏が手軽に法線マッ... 2025-04-06 でんのこ氏(@dennoko_vrc)が法線マップを生成できるツール「Normalmap_generator v1.0」をリリースしました!縁の傾斜生成も行ってくれるようです。 続きを読む Unreal Engine アセット アセット-Asset FluidNinja LIVE 2.0 PRE-ALPHA - Niagara活... 2025-04-05 Andras Ketzer氏によるUnreal Engine向け2.5D流体ソリューション「FluidNinja LIVE」の次期メジャーアップデート版の動画がちらほら公開されております。 続きを読む
はじめに 2022年で新卒エンジニア2年目になりコードレビューの機会が増えてきたので、1年振りに「リーダブルコード」を読み直しました。 リーダブルコードを読んでいく中で要点を整理し、実務の現場でコードを書いたりレビューをする際にどのように活用していけば良いのかを自分なりにまとめてみました。 この記事を読むことで、リーダブルコードの要点と初級者から中級者目線で実際の現場でどのように活用すればよいのかが学べます。 この記事の主な対象者 リーダブルコードの要点をサクッと知りたい人 初級~中級者(実務歴1~3年目)の人 コードレビューの機会が増えてきた人 これまで我流でコードを書いてきた人 リーダブルコードについて リーダブルコードはあくまで「こう書きなさい」と押し付け口調ではなく「こう書いた方がもっとよくなるよ」といった丁寧な語り口で書かれています。 それを踏まえた上で要点や活用方法をまとめてい
何か重要な作業を効率的にしようと思うのに、次々と考えが思い浮かんでしまい集中できないときは、まず、頭の中で、以下のように上下左右に強力な磁石のようなものが設置されている様子を想像する (ここで磁石には N 極と S 極があるがどっちの方向を向いて配置されているのかといった論理的なことは考えなくても良い。とにかく磁石のようなものがある、という程度で良い)。 磁石のイメージをリアルに思い浮かべる必要は全くない。だいたい磁石のような、何かを吸い寄せるような性質のものがあるな、という程度で良い。 次に、その磁石で囲まれた空洞の中央部分に、少し重いけど、手で簡単に持てる程度の鉄球 (鉄を思い浮かべなくても、磁石のような何かに吸い寄せられるような何か) を思い浮かべる。 背景のイメージは Microsoft Windows XP の壁紙からの引用であり、コンピュータのディスプレイを見ながらイメージをす
はじめに:この記事を書いた動機 これらの素晴らしい先行記事を見て、「言語学を用いれば、共通点を見つけ出して一般化・大項目化したり、取り違えやすいエッジケースを明確化できるんじゃないか?」と思ったことが、この記事を書き始めたきっかけになります。 1章は3つの主要なパターンとその詳細・例外、2章はそれらに関する文法的な解説になっています。 構造化・体系化が必要な理由 太郎くんと花子さんが英作文の問題を解いています。 次の日本語を英文に訳せ。 (1) 彼女は楽しい人だ。彼女といると退屈することがない。彼女はいつも新しいことに挑戦して…… 太郎くん(『楽しい』って英語で何やったっけ……) 狩井先生@ 1年6月「exciting は楽しいって意味やで~」 ~~ 月日が流れる ~~ 柱鈴先生@ 2年4月「excited は楽しいって意味やで~」 太郎くん(……って教わったけど、exciting か e
JavaScriptの仕様であるECMAScriptはEcma Internationalによって定められています。ECMAScript 2015(ES6)の登場以降は、ECMAScript 2016、ECMAScript 2017・・・と、年次で仕様が更新されています。ECMAScript 2022(ES2022)は2022年6月22日のEcma InternationalのGA 123rd meetingにて、ECMAScript 2023(ES2023)は2023年6月27日のGA 125th meetingで承認されました。 ES2022とES2023はすでに多くのブラウザやNode.js環境で利用可能です。本記事では新仕様と使いどころを紹介します。 ES2023 - 配列の非破壊操作 ES2023では配列を非破壊で操作できるメソッドが追加されています。非破壊とは、元の配列を変更せ
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー&ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
こうです。 新しい住居を探そうとしたとき、「会社から歩いてちょうど 30 分のところに住めたら QOL 高くない?」と思いました。(運動できる、公共交通機関と無縁、買い物もできるetc...) でも ある一点を中心とした移動可能エリアを知りたいとき、円でざっくりと表示をする以外のアプローチがほぼない ことに気がつきました。海外サイトも含めかなり調べてみましたが、類似のサービスは見当たりません。 という経緯でつくったのが How far can I go? というサイト。 ぽちぽちやっていただければわかりますが、結果の精度はかなりのものと思われます。特に道の有無や川沿いなどを検証してもらえるとその効果がすぐにわかるかと。 転職先が決まっているなら、そこにピンを差して交通手段と所要時間を設定してください。HOME'S などの住宅検索サービスには条件絞り込みをしたあとにそれらを地図上にまとめてマ
こんにちは。この記事は筆者が製作した ESLint 向けプラグイン eslint-plugin-import-accessを紹介する記事です。 このプラグインにより TypeScript プログラムに擬似的なpackage-private exportの概念が生まれます。JSDoc で@packageとアノテートされたexport宣言は、そのファイルが属するディレクトリの外からインポートすることができなくなります。 従来、TypeScript で可能なカプセル化の最大の単位は「ファイル」であり、ファイルからエクスポートしない変数はそのファイル(モジュール)の中に閉じている一方で、一旦エクスポートしたものはプロジェクトのどこからでもインポート可能になります。これでは不都合な場合がありました。 最近の具体的な例としてはRecoilが挙げられます。筆者の以前の記事では、Atom や Select
私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生50年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを2つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Corner case" – news · newspapers · books · scholar · JSTOR (August 2019) (Learn how and when to remove this message) In engineering, a corner case (or pathological case) involves a problem or situation t
ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。 例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。 こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ル
ある仕事でそれまでRubyで書かれていたサーバーサイドをGo言語ですべて書き直すことになって、それまでRubyのコードを書いていた僕はそのままGo言語を書くことになった。その仕事そのものはお客様(僕は外部委託のエンジニアとして参画していた)との関係も良好で素晴らしい仕事をさせてもらうことができたと思っているが、Go言語だけは好きになれなかった。 はじめは流行っている言語だから何か素晴らしい魅力があるのではないかと期待していた。しかし書き始めるうちにどうも自分には合わないなと思うようになり、2年ほど書いて案件の契約が終わる頃にはGo言語でサーバーサイドを書くことは危険だとさえ思うようになった。 あれから数年がたちますますGo言語の案件は増えている。サーバーサイドを書く選択肢としてGo言語を選択する会社も増えている。しかし本当にそれでいいのか?ただ流行っているからという理由だけで選択するにはあ
How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く