git の master ブランチは取り込み専用で、ブランチの作成はほどほどに2018年08月02日 17時26分23秒

git は分散管理の履歴管理システム。それゆえ、使い方や信条などもどうしても多岐に渡ってしまう。両極端な master ブランチ強行派や、変更毎のブランチ作成必須派。master ブランチは触らないが、ほどほどブランチ作成派。単独での利用であれば、一人で好きな様にやって良いが、複数での開発になると、それぞれの流派の得手不得手が出て来る。

まずは、絶対に避けたいのが master を直接変更すること。pull リクエストなどを使いコードリビュー等を行う場合には大概不便な使い方。自分の master ブランチからの pull リクエストが、即座に受け入れられない場合は git pull --rebase の merge の原因になる。他の誰かの変更が、自分の変更よりも先に受け入れられてしまうと、自分のレポジトリでは既にコミットされている変更の前に他人の変更が加わることになる。その為、手元に沢山の merge を溜めることなり、git log に役に経たない情報が増える元になる。

それに比べると一つの変更毎にブランチを作成するのはそんなに悪くない。ブランチを作成して pull リクエストをするので、master には全てが綺麗に git pull --rebase で戻って来る。ただ、何百も変更を行い、ブランチの数も多くなってくると、名前の重複に困ったり、最近作業したブランチ名を忘れてしまったりといった弊害はある。ブランチはもちろん消すことはできるのだが、あれこれ二度手間になる部分も。

結局のところ、最近はほどほどの数のブランチを使い回すやり方に収束してきた。大きめの変更の時は、専用のブランチを作ったりはする。小さな細かい修正などは、幾つかのブランチを git pull --rebase で更新しつつ、使い回している。例えば、簡単な古いコードの削除などは cleanup ブランチでチョコチョコと行う。

pull リクエストの squash merge 等を行うと、また違った問題と解決策が必要になってくる。ただ、個人的には squash merge はあまり好まない。

gettimeofday と gethrtime の精度2018年08月03日 10時37分17秒

gettimeofday はミリ秒の精度。gethrtime は Solaris のシステムコールになるが、ナノ秒の精度。clock_gettime はどの Unix にもあるようで、構造体としてはナノ秒の精度を扱えるようにはなっている。

FreeBSD の FUSE の高速化2018年08月06日 17時27分28秒

数日前に FreeBSD の FUSE の高速化の変更が、current にコミットされた。

変更としては、バッファを大きくしただけだが、実メモリを基にした FUSE ファイルシステムで、 4.5 倍の高速化が出来たそうだ。

ntfs3-g などはディスクの転送量に比べるとファイルシステムスループットが遅い。この変更が、効いているか気になるところだ。

データベースに興味を持った2018年08月07日 12時18分51秒

あれこれと、コンピュータに入っているファイルをちょこちょこといじっていた。その中に五年以上前に、実験で C++で書き始めたデータベースのプログラムを見つけた。ほとんど実装は進んでおらず、飽きてしまった様だ。

少し見ていると、確かに面白そう。C++ には shared_ptr があるし、vector や map もある。かなりの部分は C++ の STL 等を用いて実装できそうだ。

個人的にはデータベースは時折使うくらいで、あまり深い知識はない。むしろ、仕事で使うデータベースは社内用の専用の実装なので、他のものには疎い。周りに手軽に使えるものから調べていく必要がある。

SQLite から調べ始める。

FreeBSD tcp のセキュリティ勧告2018年08月08日 12時03分22秒

FreeBSD-SA-18:08.tcp が出ている。TCP のセグメントを再構築するアルゴリズムに不備があり、処理を行わなければいけない量に比例して、処理時間が延びてしまう。そのため、分割されてしまった TCP が増えると、処理時間が掛かるようになる。意図的に分割されたセグメントを送られると、処理能力が劣化する。

対象は、公開されている全てのバージョン。十一系の 11.1-RELEASE と 11.2-RELEASE、十系の 10.4-RELEASE。回避策はあるが、パフォーマンスに影響がでるので、注意が必要らしい。

SQLite の利点2018年08月09日 12時06分06秒

データベースを使い始めるに当たって、まず SQLite を選んだ。この利点は何よりも使い初めやすいこと。

  • 単体の SQL のインストールが簡単。
  • インストールした後の設定も無し。
  • すぐに QSL のクエリが使える。
  • データベースの廃棄も簡単。

もちろんこの利点は使い方によって、欠点にもなる。サーバが存在しないとか、認証が無いなどとか。元々が組み込み系の単純な利用環境を前提としてる。

SQLite はパブリックドメインで公開されているオープンソースの SQL データベースで、構文なども丁寧に記述されていて、調べるのにも都合が良い。

SQLite データベース - Top

SQLite3 のデータ型2018年08月11日 12時52分12秒

SQLite は明示的に型を指定しない。実行時に必要に応じて型変換を行う様だ。また、SQLite2 と SQLite3 では違う。読み込み時には型の決定を行わず、条件式を評価する段階に型変換を行う。

3の主なデータ型は以下の通り。コンピュータの基本的な型だ。

NULL
NULL値
INTEGER
負号付きの整数
REAL
浮動小数点数
TEXT
文字列 (UTF-8、UTF-16BE、UTF-16-LE)
BLOB
エンコードされない文字列

SQLite データベース - Top

SQLite を FreeBSD にインストール2018年08月12日 11時19分12秒

SQLite に依存するオープンソースの製品は多い。恐らく、既に依存関係によってインストールされている場合が多いだろう。

pkg データベースを sqlite で探すとあれこれ各種拡張機能が沢山見付かる。

% pkg search sqlite
R-cran-RSQLite-1.0.0_2         Database Interface R driver for SQLite
R-cran-RSQLite.extfuns-0.0.1_9 SQLite extension functions for RSQLite
bogofilter-sqlite-1.2.4_3      Fast, teachable, learning spam detector
exim-sqlite-4.90.1             High performance MTA for Unix systems on the Internet
fpc-sqlite-3.0.4               Free Pascal interface to SQLite
gosqlite3-20120330_2           Go interface for SQLite3
...
その中の sqlite3 を root ユーザでインストールする。古いバージョンが欲しければ sqlite2 を入れる。
$ pkg install sqlite3

SQLite データベース - Top

坊主頭にしてみた2018年08月13日 12時47分02秒

ここ数年、後頭部に腫れが出来て、赤くなっていた。ある程度、髪の毛を短めにしたり、薬を塗ったりもしているが、長くなってくると薬が届かなくなり、効きが悪くなる。また、自転車で通勤しているので、汗などで汚れやすい。簡単にでも、水で汗を洗い流すと若干症状が良くなったので、髪を一気に切り落とすことにした。頭を簡単に洗える様にして清潔に保つのと、薬を塗りやすくする。

全部綺麗にするつもりだったのと、自分でやってみるのに興味があった。散髪用のハサミと漉きバサミはあるが、残念ながらバリカンは持っていない。そこでまずは、ハサミで切れるだけ短くした。適当にジョリジョリと自分の髪の毛を切り落とす。ハサミの刃の厚みのせいで、摘める程の長さはないが、丸めたと言う程ではない。

そこで、鬚剃りで剃ってみた。しかし、ここで難儀。長さ的には、数日間鬚剃りをサボったぐらいの長さ。髪が微妙に長くて、鬚剃り機が上手に毛をとらえてくれない長さだった。鬚剃り機を頭に走らせるのだが、バリカンの様に綺麗には刈ってくれない。毛が長すぎて、うまく捕えられない様だ。そこで、キワ剃りの方で、一度短くした。この、キワ剃りはあまり多くの毛を刈るようには出来ていないので、時間が掛かった。キワ剃りを終えた後は、鬚剃りの方でもしっかりと残った毛を剃ることが出来た。

結構、キワ剃りに時間が取られて、片付けも含めて一時間程で終った。三十分もあれば、終るだろうと楽観的に見ていたので、随分と掛かった気分だった。バリカンの刈り落し能力の高さを改めて認識した。