サーバレスGPUにModalがいいぞ！
GPUを使いたいこと、あると思います。 ただしご家庭に強いGPUはないこともあるでしょうし、かといってGPU搭載したインスタンスを立て続けているととてつもないお金がかかります。 そんなあなたにサーバレスGPU、使った秒数分だけ課金が発生するので、いきなりすごい金額がかかることにはならず手軽にGPUを使ったプログラミングが始められます。 私は今の所ModalとRunPodを試したのですが、ModalのDXが良すぎるため今回イントロ記事を書く筆を取りました。 始めにざっくりいいところを述べると 一つのファイルで完結する。 RunPodとの比較だと「RunPodではDockerのイメージを自前でビルドしてどこかしらのregistryにpush、都度タグを付け替えてRunPodの方にも反映」みたいなのが必要だったがModalでは全部要らない ローカルパッケージをちょろっとした関数で送れたり、テキス
ローコードテスト自動化ツールの mabl がすごい
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
