chordではなくcodeですね……
CSSで喪に服す - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2016/10/15/mourning-with-css/
そういえば CSS 1行で喪に服せるという知見を持っているので、 friends.nico には是非とも通夜テーマになってほしい #適当
例えるとすればなんだろう、サービス発案能力と美しいコードを書く能力とリファクタリングやレビューをする能力は別ベクトル、とか?
このアカウントは、notestockで公開設定になっていません。
ORMで画一的にSERIALがあったほうが都合がいいケースにも言及されており、名前を id 以外にするのを検討しようね みたいなことが書いてあった記憶
安直な id SERIAL はやめようねというのがあったので、時刻カラムを直接 PRIMARY KEY にするということを考えたりした
大学でコンピューターをやっていると知った人は大抵「じゃあ(ここに広く使われているソフトウェアの名前を入れる)とか詳しい?」と訊くので「F1のエンジンの仕組みが分かる人なら皆F1を運転できるというわけではない」と答える
外すのは簡単だからとりあえずそれっぽいものに UNIQUE 付けておけという話はありますね (これは欠陥に気付いたときすぐに直すという前提)
ALTER TABLE somethings MODIFY COLUMN almost_unique TYPE UNIQUE;
するときに無視できる程度の重複があった場合どうするかという話ですね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Twitterクライアントだったものを使うと標準機能なんですよ
わかる~~~~~~~~~~ RT: @kb10uy 引用RT自体は悪い文明ではなく、それが通知になってしまうことが邪悪すぎる
このアカウントは、notestockで公開設定になっていません。
レーティング対象曲ひさしぶりに見返したら新曲枠が 15.7〜14.9 、ベスト枠が 15.7〜15.2 になってて泣いてる
こっからどうやって 15.5 行けばええねん
2年、2年、3年とかで改元している時期、規模は大きく違うが「頼むからこれで直ってくれ」と思いながら設定変更と再起動を繰り返すのに近いものを感じる
DirectWriteでも満足できない人おるんか…となったがあれ設定によってはただのハードウェア支援版ClearTypeだしな…
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
半角濁点がダイアクリティカルマークと同じカテゴリっぽいという仮定に立つと濁点だけを検索すると虚無とマッチするのでとりあえず要素の先頭がマッチするみたいなかんじなんだろうか
grapheme_strlen先生も1クラスタっつってるしUnicode 9.0以降の仕様では1文字としてカウントされるということっぽそう
Postgres は JDN の日付入力に対応しているらしいので、8byteで表せる限りのユリウス通日ということで例の範囲なんだろう
ユリウス日は別の種類の暦であり、名前が似ていて混乱しますが、ユリウス暦とは関係ありません。 ユリウス日は、フランスの学者Joseph Justus Scaliger(1540-1609)によって発明され、おそらくこの語源は彼の父であるイタリアの学者、Julius Caesar Scaliger(1484-1558)からの引用と考えられます。 ユリウス日システムでは、JD 0(よくいわゆるユリウス日と呼ばれます)から始まる日は連番です。 JD 0はユリウス暦の紀元前4713年1月1日、またはグレゴリオ暦の紀元前4714年11月24日に対応します。
https://www.postgresql.jp/document/10/html/datetime-units-history.html
ところでなぜ最遠の過去と最遠の未来がこの年数なのかがわからん
https://www.postgresql.jp/document/10/html/datatype-datetime.html
"the range for TIMESTAMP values is '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999'."
MySQL :: MySQL 8.0 Reference Manual :: 11.3.1 The DATE, DATETIME, and TIMESTAMP Types
https://dev.mysql.com/doc/refman/8.0/en/datetime.html
Postgres の TIMESTAMP は、というより日時系データ型はどれを使っても30万年ぐらい先までは安心して格納できる
解説: MySQL にも Postgres にも TIMESTAMP が存在するが、Myのそれは2038年問題が存在する一方でDATETIMEは0月0日を許容する
SQLite は VARCHAR の長さ指定は無視されて最大サイズは 1GB 、PostgreSQL だと VARCHAR には 100K 文字、TEXT には 1GB - α 入るっぽい
InnoDB については確保サイズの分が 64KiB 制限には計算されるが 8000byte 制限には計算されないのが VARCHAR 類、どちらでも数byteしか消費しないのが TEXT 類ということでいいのか?
行全体で65535byteまで、VARCHARでは長さに2byte消費するので領域としては65533、utf8 になってると65532が割り切れるので、みたいなことらしい
なんか調べていったらMySQLの仕様っぽいことがわかってきた
https://dev.mysql.com/doc/refman/5.6/ja/column-count-limit.html
なんで 65536 じゃないんだろう https://github.com/jinzhu/gorm/blob/8b07437717e71c2ff00602ae19f8353ba10aafbb/dialect_mysql.go#L91
壁ツェーン - ココアちゃんとセックスしないと出られない部屋に閉じ込められた(45日目)
https://blog.kb10uy.org/blog/sexroom-with-cocoa-day45
kb10uy「保登心愛さんとセックスしないと出られない部屋にいる」 - ShortStoryServer
https://ss.kb10uy.org/post/20
夏稀の彼氏 さんのチェックイン (3月28日 00:55) - Tissue
https://shikorism.net/checkin/1745
非公開チェックイン、「数には入れるが数しか出さない」みたいな GitHub の private contribution みたいなやつでいいとおもう