記事一覧: 開発カテゴリ

Straightanswer.orgは問いに対する回答を素早く得られることを目的としたWebサイトです。サイトの目的のようなコンセプト部分以外のところでも、問いに対する回答を素早く得てもらうための工夫をしています。

そんな工夫の一部を紹介します。ここに書いてあること、当たり前だと思う人もたくさんいると思います。

先日Straightanswer.orgのログにエラーの発生が記録されていました。今回はたまたまログをチェックしていて気がつくことができましたが、想定外のエラーの発生は受動的に知る仕組みになっているべきだと思います。

そこで、自分しかいないDiscordのサーバを作り、そこにエラー発生時にその旨を投稿する処理をStraightanswer.orgに加えることにしました。

引き続きStraightanswer.orgの改良を続けています。

Straightanswer.orgでは各問いと回答のOG画像に、回答を全文載せていました。今回の更新で、答えの代わりに問いを載せるようになりました。

Straightanswer.orgは最速で答えにたどり着けるようにしようと考えています。OG画像に答えを載せれば、場合によってはサイトにアクセスすることなく、答えを見せられます。それなのに答えを載せるのを止めるようにするのは残念ですが、理由があります。

新OG画像

引き続きStraightanswer.orgの改良を続けています。

Straightanswer.orgでは各問いと回答のOG画像に、回答を全文含めるようにしています。

今回の変更前は、全角文字と半角文字の両方がが回答に含まれていると、OG画像内の文字がガタガタになってしまっていました。

改良後のOG画像

これは改良後のOG画像です。

満足いくできに至っていませんが、改良前よりはだいぶマシになったと思います。

しばらくKi6cooを開発していましたが、この一週間別の開発をしていました。

2022年3月4日にこんなアイデアが浮かびました。

「Webで検索すると、検索結果の上位に内容が薄いブログがたくさん出てくる。もっと簡単に答えにたどり着けるようにできないか。」

そしてすぐに開発を開始し公開したのが直球回答 Straightanswer.orgです。

Straightanswer.org
案が期待通り動作し、IndexedDBに情報が保存された様子

前回の記事はこちら

パソコンとスマートフォンの両方で同じデータにアクセスできるように、ブラウザ版の作成とブラウザ間でデータを同期するための仕組み作りを進めます。

サーバとブラウザで動作するクライアント間でデータを同期するのに、Web Workerを使う案を考え、それが実現できることを確認した、その記録です。

Ki6cooのスクリーンショット

今回から私が私自身が使いたくて開発を始めたKi6cooというアプリケーションの開発の記録を書くことにしました。 読み方は「きろくー」です。

次回の記事はこちら

最初に断っておきますが、私はRustの初心者です。久しぶりのRustに四苦八苦しながら、この記事中に出てくるプログラムを書きました。

私はPythonでWebアプリケーションのAPIを作っているときに、デコレータをあまり使いたくないと考えていました。RustのマクロとPythonのデコレータは別物ですが、同じく使わずに済むのであれば使わずに済ましたいと考えていました。RustのaxumというWebアプリケーションフレームワークが「Route requests to handlers with a macro free API.」と謳っていることを知ったので、これを使って何か作ってみることにしました。

お題はDropboxのAPIを真似た、ディレクトリのファイルの一覧、ファイルのアップロードとダウンロードを実装することとしました。

この記事中で実装しているAPIはファイルへのアクセス制限がなく、外部に公開するのはとても危険です。この記事を参考に実運用するプログラムに組み込む人は、この点に十分に注意して自身で安全のための変更を加えてください。

Nuxt Bridgeのドキュメントはこちら

これまでNuxt2とVue3でアプリケーションを作ってきました。2021年の終わり頃に新しくウェブサイトを開発する際に、SSRが必要なことからNuxtを使うことにしました。Nuxt3がすでに公開されていたのですが、今も当時もNuxt3はUnstableであると公式ドキュメントに書かれています。遊びであればそれでもNuxt3を使おうかなとなるのですが、今回は遊びではないので、Nuxt Bridgeを使うことにしました。今からNuxt2を使うのは安定していますが、コストのかかる移行の必要に迫らてるのが近そうだと考えて止めました。

数か月のNuxt Bridgeを使って遭遇した問題とその回避策を紹介します。

このブログのことではないのですが、markdown-itを使ってMarkdownで書いた記事を表示する際に、目次(Table of Contents, TOC)を記事の外に表示したいと思いました。記事の外とは、例えばサイドバーです。

markdown-itで目次を記事中に表示するプラグインはいくつかあるようですが、記事外に表示することはプラグインでは達成できないようです。自分でTypeScriptを書いて実現しました。

私はCSSが苦手で、これまでBootstrapやBulmaに頼ってきました。最近、CSS (SASS)を書く機会がたくさんあり、自分でCSSを書いても思い通りのレイアウトにできるようになりました。

そこで、このブログからBulmaを取り除いてみました。

@media screen and (min-width: 1920px) {
   body {
     background-color: red;
   }
}

CSSのメディアクエリではこれまで、画面の解像度によって適用するブロックを変更するmin-widthmax-widthだけを使っていました。

最近、初めて画面の縦横比によって適用するブロックを切り替えるaspect-rasioを使いました。

@media (min-aspect-ratio: 16 / 9) {
  body {
    background-color: red;
  }
}

16 / 9の部分が1.77778と計算結果が書かれていると、Firefox (Servo)では機能するのですが、Chrome (Blink)やSafari (Webkit)では機能しませんでした。

もともと、このブログはPageSpeed Insightsのスコアが携帯電話で95点、デスクトップで99点でした。ブログのテンプレートを調整して、どちらも100点を達成しました。

Page Speed Insightsのモバイルのスコアのスクリーンショット

携帯電話で100点

Rustの練習のために中間に要素を挿入できるLinkedListを作りました。同様の例が見当たらなかったのでここに残します。

Pythonは自身を持って書けるのですが、Rustはまだそこに至りません。このLinkedListにも不備があると思います。

私はつい最近まで、JavaScriptが送ったHTTPリクエスト(AjaxやFetch)に対するレスポンスでは、クッキーをセットできないと思い込んでいました。そのため、それ相当のことをするには、レスポンスでクッキーに入れたい値を受け取り、document.cookie = newCookie;のようにJavaScriptでセットしないといけないものだと思い込んでいました。そのためHttpOnlyディレクティブを使うことができないとも。

これは間違いで、JavaScriptからのHTTPリクエストに対するレスポンスがSet-Cookieヘッダーを持っていれば、自動的にブラウザにそれが保存されます。喜ばしいことに、このときHttpOnlyディレクティブを有効にすることもできます。

ただしJavaScriptでCookieをセットするときに、HttpOnlyディレクティブを使えないのは真です。HttpOnlyディレクティブつきのCookieはJavaScriptから読めないだけではなく書くこともできません。

← 古い記事1 / 2ページ新しい記事 →