DebianへCouchDBをインストールしてみた。

最初は
https://cwiki.apache.org/confluence/display/COUCHDB/Debian

こちらを参考にインストールしてみるも、最後のInstall CouchDB 2.0+の段階でこける。

erlang関連のバージョンの問題で、いくつかインストールができない模様だった。

その後色々と調べてみると、公式に普通にインストール方法が記載されていた。

http://docs.couchdb.org/en/2.1.0/install/index.html


http://localhost:5984/_utils/
上記アドレスへアクセスしたが、ログインIDが分からず少し困る。
が、local.dにadminユーザーの設定があり、adminで良いと分かる。
administratorだけ試して諦めたのが敗因か・・・

CouchDBを使ってみる

目標はPythonから使用するところだが、一旦は使いかたをまとめてみる。

DB追加
curl -X PUT http://[ID]:[PASS]@localhost:5984/dbname

Documentの追加
curl -X PUT http://[ID]:[PASS]@localhost:5984/dbname/id -d 'json_data'

同一IDのDocumentを追加しようとすると、
{"error":"conflict","reason":"Document update conflict."}
と言う結果が返却される。

Documentの取得
curl -X GET http://[ID]:[PASS]@localhost:5984/dbname/id

Documentの更新/削除
追加時に発行されるrev値を使用して行う模様。

Qiitaにチートシートがあったので、そちらを参考にする。
https://qiita.com/usagi/items/ffe7b2cde9f2f8b1b7f4


とりあえず、SQLを書かないDBってのはちょっと新鮮だな・・・

タイトル変更

普段の考えが技術的なものだけでなく多岐にわたってきたのでタイトル変更
カテゴリも見直して、再運用
さすがにメモなどに色々と書いているけど、頭の中を整理するにも書き残す事にする
部下ができたときや、独立したときなんかにも役に立つかもしれないので

システム開発における文書化の重要性について

まず、現在実践しているフローは

  1. 営業がクライアントにてヒアリングを行なう
  2. 帰社後、開発サイドへヒアリング内容をおろす
  3. 開発を行なう
  4. クライアントが営業と確認する

なお、すべてにおいて文書はなく口頭で行なっているものとする
言語化すると、すごく頭が痛くなる状態だがこんな状況である。
開発サイドで降りてきた情報はもちろんある程度の管理はしているが
後だしでもれていたものが出てきたりしている



そして、この状況の問題点としては

  1. 情報のまとまった資料がないため、話が堂々巡りする
  2. 記憶を元に情報が構築されるため、相違が出やすく仕様変更を受け入れざるをえなくなる
  3. すべての情報が営業に集中するため、捕獲できないと確認ができずスケジュールが遅延する
  4. 後だしの要求を飲まないといけないため、見積と結果の差異が非常に大きくなる


業務における口頭伝達は、確かに早い手段ではあるが
システム開発においては、決まりきった業務なんてほとんどないため
このような状況を作ると各自の理解力や想像力に頼る結果となり
ミスや繰り返し、手戻りを引き起こす原因となる
ただし、決まりきったことを行なう上でならば口頭伝達がベターかと思うが
そういう状況は運用などでルール化されたもので行なうことになるだろう

理想的なのは

  1. ヒアリング
  2. 開発
  3. 検収

各項目間での合意が文書によってなされる事であり
また、書かれている内容も理解のゆらぎがないものでなければならない



こんな事がまかり通るのは、単に信頼関係が強いからってだけだと思う
ただ、こういう相手を選ぶ仕事の仕方をしていては事業や会社の拡大なんて
夢物語であろう



今回はシステム開発を例にあげたが、企画をするときもほとんど一緒だなこりゃ・・・
企画書のない企画は、単なる夢物語
今度からそういう対応しよう・・・

OPOS for .NET

調べていくうちに
C/C++ CLI でもできそうな気がしてきた

別のアンマネージドなDLLから呼び出されるのであれば

C#見たいなマネージドなDLLを作ってしまうと
結果的にCLIでラップすることになりそう。

C#やるにしても、CLIやるにしても
どちらも勉強からだから大差はないかな?

ただ、サンプルはC#のみだけども…orz

EPSON APD + TM-T88IIIにおける印刷高速化

細かい仕様などはマニュアルに書いてなかったため試行錯誤した結果

・文字の印刷
これは、どれだけ増えても早い
なので、文字だけを印字する場合は考慮する必要はない


・線の描画
MFCとか使ったことないので、WindowsAPI使用だけども
MoveToExとLineToで線を引くと一気に遅くなる
回避方法は文字でラインを引くことになる
Shift-JISの文字セットがデバイスフォントで使用できるため
それなりに表現はできる
文字コード表とにらめっこする羽目にはなったけども・・・

また、サンプルプログラムも線を文字で書いていたため
画像描画形式になると、印字速度が一気に遅くなると思われる


・画像
線の描画でも言及したけども
画像の部分は印字が遅くなる
回避するにはAPDのユーティリティでプリンター登録し
controlフォントで印刷することになる


・回転印刷
[ただいま試行錯誤中]
FontのEscapementだとかで設定して、回転させて印刷しても
画像描画と同様の結果となる

用紙設定そのものを変更しないとだめかも・・・。
ただ、ドライバ設定で回転を指定すると
自動的に画像で印刷設定にかわるので
果たしていけるのだろうか・・・?

TM-T88IIIとの格闘。。。

先ほどの記事での格闘結果は
APDで回転印刷をする場合の高速化はほぼ不可能な気がしたので
別のドライバーを使用することにした。

OPOS for .NET
サンプルにも回転印刷などがあるため、期待が持てる