その誕生を地元新聞も経済新聞も記事にしなかった。2年後、『コードの情報を白黒の点の組み合わせに置き換える』と最下段のベタ記事で初めて紹介された時、その形を思い浮かべることができる読者はいなかった。いま、説明の必要すらない。QRコードはなぜ開発され、どう動くのだろうか。 QRコードは、自動車生産ラインの切実な要請と非自動車部門の技術者の「世界標準の発明をしたい」という野心の微妙な混交の下、1990年代前半の日本電装(現デンソー)で開発された。 トヨタグループの生産現場では、部品名と数量の記された物理的なカンバンが発注書、納品書として行き来することで在庫を管理する。そのデータ入力を自動化するバーコード(NDコード)を開発したのがデンソーだ。 バブル全盛の1990年ごろ、空前の生産台数、多様な車種・オプションに応えるため、部品も納入業者も急激に増え、NDコードが限界を迎えていた。63桁の数字しか
この記事はコードの書き方について、書き方そのものを推奨するものではなく、このような書き方も出来るという紹介です。コメント欄まで一緒にみていただくと学びになります。 ※記事はいただいたコメントを反映しましたので、当時のコメントと記事の内容に差分があります 1.破壊的メソッドを避ける 破壊的メソッドとは、元の配列の要素を変えるメソッドです。以下の例ではconstで宣言した変数numbersが、pushメソッドにより更新されています。 対応前 const numbers = [1, 2, 3] numbers.push(4) console.log(numbers) // [1, 2, 3, 4] この場合、元の配列の要素を更新するのではなく、スプレッド構文を使って新しい変数に代入します。変数はなるべくイミュータブルにしておくと、意図しない不具合やプログラムの可読性や保守性が向上します。push
令和にもなって自分でメールサーバーを作ってみたのでメモ。 OS は Ubuntu 22.04。 パッケージ更新後に自動的に再起動 メールとは関係ないけど apt で再起動が必要な更新があった場合は自動的に再起動するようにした。 /etc/apt/apt.conf.d/50unattended-upgrades: Unattended-Upgrade::Automatic-Reboot "true"; Lets Encrypt TLS 証明書を作るために certbot をインストール。自分はさくらのクラウドのDNSを使ってるのでそれ用のモジュールも追加。 # apt install certbot python3-certbot-dns-sakuracloud https://certbot-dns-sakuracloud.readthedocs.io/en/stable/ に従って /r
はじめに 今回は夜間光のデータを用いて、日本のコロナによる影響を調査してみます。 今回もGoogle Earth Engine(GEE)とGoogle Colabを用いて解析を行っていきます。 「まずそれなに?」という方は、以前初学者向けに書いた登りたい山を探す企画の記事があるので、ぜひご覧ください。 今回は、新型コロナウイルス(COVID-19)によって、日本の夜間光にどのような変化があったかを調査していきます。 統計学的な知識に疎いので、今回は簡単に夜間光の推移を見る程度ですが、いずれは相関など詳細な調査を行いたいと考えています。 また、夜間光データに関してはWorld Bankがチュートリアルを公開していますので、興味を持った方はぜひそちらで勉強してみてください。 夜間光データについて 夜間光のデータには、主にDMSPとVIIRSと呼ばれるデータがあります。 GEEではDMSPの19
最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。 前提としてはこんな感じ。 仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない 技術スタックは技術的な実験とか学習を兼ねているので多少オーバースペックになるのはいい お金はなるべくかけたくない 移行前のスタック フロントエンドはNuxt.js、Netlify バックエンドはRailsでgRPC、envoyを噛ませてフロントエンドからはgRPC-Webで呼んでる VPS上にバックエンドのアプリケーションとDB(postgres)を動かしてる バックエンドは普通のRailsアプリにしてHerokuにするのが一番楽でお金もかからないんだけど、gRPC-Webを試してみたくて、そうするとproxyが必要にな
はじめに2013年にスタートアップに参加したことをきっかけに、今までいくつかのデジタルプロダクトのUIデザインに携わってきました。2020年にTakramに参加してからは、さらに多様な事業のプロダクトに関わらせていただいています。この約10年間のあいだに世の中のUIデザインのノウハウは確立されてきており、既存のコンポーネントなどを組み合わせれば、きれいなUIが誰でも簡単に作れる時代になりました。そんな中で個人的に大切にしてきた価値観として、「ユーザーの気持ちを考えて、その気持ちに寄り添った情緒的なUIをデザインする」ということがあります。今回、この記事を書いているのは、その意味や意図を言語化して再利用可能なものにしたいと思ったことがきっかけです。考えながら書いているため、何度かのシリーズになるかもしれません。また、このテーマについて様々な方と対話ができたらいいなとも思っていますので、興味を
特に何かしらの出典はありません. プログラムの複雑さに対する大局的で直感的な指標として, 表面積とグラフの構造というのを個人的に意識しているという話. いわゆる code smell をどう嗅ぎつけているか. 表面積 プログラムは最も単純には 1 つの入力チャンネル (引数) と 1 つの出力チャンネル (戻り値) でモデル化できます. 要するに関数ということですが, 関数型プログラミングに限らず大抵は似たような考え方ができます. graph LR yield[ ] -- 引数 --> program[プログラム] -- 戻り値 --> return[ ] 一方で現実世界で価値のあるプログラムとなるためには引数と戻り値だけでは不十分で, 実際にはその他の入出力チャンネルも必要になってきます. 例えば, 可変な変数の読み書き 環境変数の読み取り ユーザー入力の読み取り 画面への出力 ファイル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く