サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC25
qiita.com/alfa
はじめに Rails6がリリースされて早3ヶ月、 先週、大きめの案件が終わって暇になったので、社内のプロジェクトを全てRails5からRails6にアップデートしました。アップデート作業に伴い Zeitwerk について調べたところ、最高のGemだったのでまとめます。 Zeitwerkとは Zeitwerk (読み方: ツァイトヴェルク) とは新しく開発されたオートロードの仕組みです。Gemとして独立しており、Railsに限らず様々なRubyプロジェクトで利用可能です。 なぜ開発されたのか? Rails で 古くから採用されてきた const_missing を利用したオートロードの仕組みには、処理順序によって発生する不具合など、エッジケースな落とし穴がいくつかありました。 Zeitwerkはそういったレガシーなオートロードの仕組みを改善する目的で開発が始まり、エッジケースの解消はもちろん
はじめに もうすぐ平成が終わりますね。 元号変更に伴い、漢数字を処理しなければならないエンジニアもそこそこ多いのではないでしょうか?( 私です ) 思考停止したい そこで漢数字を数字に変換する方法を検索すると、 漢数字を変換するgemやサンプルコードが見つかるものの、ループや再帰などを使用したもので、安心して思考停止できないことが気になりました。 そこで、思考停止するために本気で思考し、上手く思いついたので内容を共有します。 わずか7行 ループも再帰も使わない、わずか7行のコードになりました。 多分これが一番簡単だと思います。 def convert_kansuji(text) text.tr('〇一二三四五六七八九', '0123456789') .gsub(/(\d+)?十(\d+)?/) { ($1 || 1).to_i * 10 + $2.to_i } .gsub(/(\d+)?百
はじめに 2~3ヶ月前 「Railsは終わった」と言われる理由 という記事を読みました。 Railsが流行した要因とそれらの現状についてよく考察された記事ですが、 それでもなお私がRailsを使っている理由は健在だったので、ラーメン食って寝て忘れてました。 昨日 Railsの最新情報をチェックするためにGoogleで検索をかけると... そこには あのPHPですら受けたことがないような仕打ちを受けるRails公式サイトの姿 がありました。 「Railsを今使っている理由を書かかなきゃ!」 そう使命感を感じた私はここまで記事を書き、ビール飲んで寝ました。 これが昨日のことです。 Railsは終わったのか? Railsが登場した 平成中期 に比べウェブに高機能な仕組みが要求される 令和 においては、Railsでそれらの要求を満たすことが難しくなっています。 難しくなったと言うと語弊が生じるので
はじめに こんにちは、ここ最近AzureからAWSに主戦場を移したalfaです。 AWS なので早速地雷を踏みました。 具体的には、Auroraでフェイルオーバーが発生した際にDBへ書き込みが出来なくなってしまい、アプリが再起動されるまで正しく動かなくなってしまうといった症状です。 何が起こったのか AuroraのフェイルオーバーとActiveRecordのコネクションプールの仕組みは相性が悪かったという事ですが順を追って説明していきます。 クラスターに障害が発生した場合、クラスタエンドポイントのDNS(CNAME)を書き換えることで参照先を切り替える仕組みです。 クラスタエンドポイントをDBの接続先に設定したRubyアプリケーションがあったとき フェイルオーバーしてマスターが切り替わると... アプリケーションは再接続するだけで昇格したマスターを参照できます。 ウルトラハイパーメチャクチ
qiita.com/alfas
{ "compilerOptions": { /* 基本オプション */ "target": "es5", /* ECMAScriptのターゲットバージョンを指定します: 'ES3'(デフォルト), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018'または 'ESNEXT' */ "module": "commonjs", /* モジュールコード生成: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015',または 'ESNext'を指定します。 */ // "lib": [], /* コンパイルに含めるライブラリファイルを指定します。 */ // "allowJs": true, /* javascriptファイルをコンパイルできるようにします。 */ // "checkJs": true, /*
Yosami とは Mithril.js をベースにした SPA+SSR のフレームワークです。 このフレームワークは前回ご紹介させていただいた通り私が制作したものです。 しかし、世の中には Vue/Nuxt や React/Next など、素晴らしいフレームワークが既に存在します。 そのような状況でなぜ今更「Yosami」を作ったのか3つの理由を紹介します。 Mithrilを使うため Mithrilは高速で軽量なフレームワークで、公式のベンチマーク結果によると主要フレームワークの中で最速・最軽量です。 そのパフォーマンス良さに惚れ、趣味、業務ともに採用してきました。 しかし、昨今では SPA+SSR が当たり前の時代になってきており(偏見)、そのための仕組みや定番の方法がないMithrilでは追加の実装が必要となります。 プロジェクトごとにその仕組みを実装すると、実装が統一されず保守コス
Yosami とは Mithril.js をベースにした SSR + SPA のフレームワークです。 Mithril.js といえば軽量&高速のフレームワーク(参考: 最速MVCフレームワークMithril.jsの速度の秘密)ですが、 その Mithril.js をコアに使用して軽量&高速の恩恵を受けつつ、Railsの基本理念「DRY原則とCoC原則」に沿ってコードを書けるようにした、いわばMithril on Railsです。 今回は Hello! World 的なプロジェクトを作りつつ、yosamiの触りを少しだけご紹介します。 想定環境 node 9.x 以上をインストール済み 記事の執筆環境 (debian9.0 / node9.2.0) インストール たった数ステップでインストールは完了します。 # インストール先ディレクトリの作成と移動 mkdir example-yosami
はじめに 最近qiita内で目にしたVagrantに関する情報で、誤ったVagrantのはじめ方をしているものが多く見られ、あまりよろしくないと思ったのでこれからVagrantを触ってみようという方向けに正しいはじめ方を書きました。 前提 Vagrantがインストール済みであること (完結) よくある間違ったはじめ方 あくまでも、これから入門してみようという方に向けた記事です、意味を理解したうえで理由を持って行うのであればそれは間違ってはいません。 vagrantbox.esからBoxを選ぶ Boxの入手先としてよく名前を挙げられる vagrantbox.es ですが、そもそもVagrantが公式に用意しています。 Vagrant公式には、信頼できるチームが用意しているBoxが存在し、きちんと保守されています。 centos https://atlas.hashicorp.com/cent
結論としては自分のせいという事なのでしょうが…。 どうしようもないので、ここに愚痴ることにしました。 ことの始まり 今年2月にAWSに興味があってアカウントを作成しました。 10月初頭にゲーム用サーバーなどをいろいろ調べていたところ、GameLiftに興味がわきました。 チュートリアル GameLiftにはチュートリアルがあります。 無料枠でテストできるとの謳い文句も記載されてます。 そこでチュートリアルを進めてみることにしました。 チュートリアルは全部で5ステップ AWS謹製のサンプルゲームのビルドがあるのでそれに名前を付ける。(ステップ1) そのビルドを配置する。(ステップ2) やったことはこれだけです。 なぜだったのか覚えがありませんが、ステップ3のクライアントのダウンロードができなくて、接続もできなかったので、そのままとなりました。 そして、チュートリアルを進めたことなど、すっかり
はじめに 最近Vue.jsを頻繁に使用するのですが、他のSSR(サーバーサイドレンダリング)の仕組みと組み合わせる場合、容易にXSSを生み出してしまうケースが存在するので、注意喚起も兼ねて事例を紹介させていただきます。 9月7日 追記を追記しました 前提 サーバーサイドで動的に要素をレンダリングするシステムとVue.jsを組み合わせた場合 この記事はrailsのSSRとの組み合わせで解説しますが、プレーンなPHP等、動的にHTMLをレンダリングシステムとの組み合わせでも発生します。 サンプルコード まず、こちらのコードをご覧ください。 user.erb <div id="app"> <div class="user"> <%= @user.name %> </div> <button v-on:click="registerFavorite" data-user-id="<%= @user
はじめに 2016年12月現在、SlackAPIでは公式に全チャンネルの全発言をリアルタイムに取得する方法が用意されていません。 つまりこれはSlackが我々に叩きつけた挑戦状ではないでしょうか?(?) 全能感を味わうツールを作りたかった私は試行錯誤の上、検索APIを利用する方法で全チャンネルの全発言を取得することができたので、今回作ったツールを含め紹介します。 slackの検索APIについて https://api.slack.com/methods/search.all を使用します。 実は中身は… この検索APIのバックエンド実はsolrなんです!様々なクエリを投げていろいろ実験してるときに白状しました! このリクエストは - 昨日以降の発言 - タイムスタンプでソート とだけ指定してSlackの検索APIを殴っています。 なんとこれだけで、10秒くらいの遅延はあるもののほぼリアルタ
このページを最初にブックマークしてみませんか?
『qiita.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く