パスワードを忘れた? アカウント作成

m_nukazawaさんのトモダチの日記みんなの日記も見てね。 今週も投票をしましたか?

13349095 journal
日記

m_nukazawaの日記: vecterion進捗

日記 by m_nukazawa

https://github.com/MichinariNukazawa/vecterion_vge
XXにスナップ、を雑に実装中。
何が雑かというと、角度にスナップ機能で、第二象限以降のスナップ角度がツールおよび機能毎に違っており、実装依存な感じになってる。
グリッドにスナップ、はとりあえず機能している。

他の機能。
LayerViewをテキストベースから独自描画に移行。(GTKのTreeViewは扱いが辛そうだったので使用しない)
ドキュメント内のCtrl+x,c,v。
グループ化と、Elementによる抜き。

BasicShapeも前のバージョンには載っていなかった気がする。

ともかく、角度にスナップが実装されたら、次のリリースを出す予定。

13324744 journal
日記

m_nukazawaの日記: ゆるぼ:C言語でネストした構造体の初期値定義がしたい 7

日記 by m_nukazawa

C言語の構造体には、C++のようなコンストラクタがありません。
コンストラクタは、構造体オブジェクトの初期値を定義し、初期化を保障する機能を持っています。
C言語で構造体の初期化を保証するのは諦めるとして、初期値を定義しておきたい。
なので現在は、ヘッダファイル上にグローバルでstatic constな初期値オブジェクトを作り、構造体オブジェクト作成時に代入することで、初期値を定義しています。
(サンプルコード参照)

しかし、static constな構造体は、ネストに対応していないようです。
(エラーになってからよくよく考えてみれば、納得できなくもありませんが。)

つまり、下記サンプルコードのようなことがしたい。

``` et_snap_context.h
  12 ¬
  13 typedef struct{¬
  14 >-------bool is_snap_for_grid;¬
  15 }EtSnapContext;¬
  16 ¬
  17 static const EtSnapContext EtSnapContext_Default = {¬
  18 >-------.is_snap_for_grid = false,¬
  19 };¬
  20 ¬
```

``` et_document_preference.h
  12 ¬
  13 #include "et_snap_context.h"¬
  14 ¬
  15 typedef struct{¬
  16 >-------EtSnapContext snap_context;¬
  17 }EtDocumentPreference;¬
  18 ¬
  19 static const EtDocumentPreference EtDocumentPreference_Default = {¬
  20 >-------.snap_context = EtSnapContext_Default,¬
  21 };¬
```

いま思いついている他の手法は以下。
・初期値定義にマクロを使う方法は、改行に'\'、ブラケットを正しく書くのが難しい等、読み書きがつらい
・初期化関数をヘッダに持つ方法は、gccの未使用関数の警告オプションに引っかかってしまう
・ヘッダに初期化関数または初期値オブジェクトの宣言だけ書き、定義は.cファイルに書く方法は、ヘッダとソースに構造体の情報が分かれるので、一覧性が低く、構造体と初期値の定義という目的に対して大げさ。
・``` = {0}; ```で代入される値をすべての構造体の初期値として定義する。
  (メッセージフォーマットならともかく、)is_exist_*とis_not_exist_*が入り交じる構造体メンバ定義は正気の沙汰ではない。

// スタックオーバーフローに投げようかとも思ったのですが、とりあえずの整理も兼ねて日記に。

良い案、あるいはわたしの思い違い等がありましたら、ご指摘頂ければ幸いです。

13306883 journal
日記

m_nukazawaの日記: バベルの塔 6

日記 by m_nukazawa

いちおう業界人として、(まあ実際の仕事では幸か不幸かお目にかかる機会がないのですが、それもあって)一度くらい現物を目にしておいたほうがいいかなあと思ったので、後学のために観てきました。

以下、感想ほか。
・細かい。絵の物理サイズに対して解像度というか描き込み量が合ってない。2〜3倍サイズで見せてほしい。
・絵師様、神話モチーフを主題にしつつ作中にリアリティ要素を散りばめる、という作風らしく、レンガ運びのディティールとか、周辺の作業者の日常描写とか描き入れてるそうで。そういう作品、わたしも好きなので、作風は好みに合っていたかも知れない。
・おみやげ屋さんでもグッズを売っていたのですが、作者殿、神話モチーフの他には、異形や一つ目を描く方だったようで。そちらの趣味はわたしにはわからないですが、異形デザインは良かったです。(閑話休題)

展示は「行列に並んで目の前を通り過ぎるか、ちょっと離れた行列の後ろから見てください」形式。絵だから何時間も見る人が出そうなので仕方ないけれど。前述の初見殺しな作画、展示形式もあってなかなか目視で確認できないのですが、展示側もわかっているようで、反対側に2倍サイズのレプリカが展示されていました。またプロジェクタで大写しする部屋も用意されていました。とても親切。

(職場へ)ポスターを買って帰ろうか悩みました。結局、職場へはおみやげのみ購入。明日持っていきます。

総じて、人間の脳にこの規模のプロジェクトの全体像が入るものなのだなあ、すごいなさすがプロだな、と。
自分も、誇らないまでも恥じない仕事をできるようになれればいいなと、思いを新たにした次第。

13306120 journal
日記

m_nukazawaの日記: SourceForge.netさんからおメール着いた 7

日記 by m_nukazawa

(スラドの日記に書いておけば、他に同じメールが来ている人達から参考情報がもらえるかもと期待してます。)
MLのユーザを整理したいのかな。reconfirmしてくれとのことらしい。

一覧には、確かに登録しているMLが並んでいる。
とりあえず発信元は SourceForge.net だそうで。元スラッシュドット・ジャパン時代もSourceForge時代も短かったわたしのような若輩者にはメールアドレスでは判断がつかない。URLは本物っぽいけれど。

以下、メール転記。
====
Hi,

Thanks for being a SourceForge user. Our records indicate that you are subscribed to the following project mailing lists:

        fontforge-users
        inkscape-devel
        inkscape-wiki
        liferea-devel

We are contacting you to confirm you are still interested in receiving emails from these SourceForge project lists. If you do not confirm your subscriptions by June 29th, you will be unsubscribed from the above mailing lists.

Please click here to confirm your subscriptions:

https://sourceforge.net/mailman/reconfirm?confirm=d32f9986-c22f-41b4-a5fe-13a8f38b2ad5&email=michinari.nukazawa%40gmail.com

Thanks,
The SourceForge Team
A Slashdot Media Company

====

スラッシュドットも遠くになりにけり、と感慨にふけるのでした。(今でも見に行けるのでは)

13296996 journal
日記

m_nukazawaの日記: amazonでmp3を初購入

日記 by m_nukazawa

いくつもの意味でいまさらな購買行動な気がするけれど、感動のあまりTwitterに購入報告を共有してしまいました。
https://twitter.com/MNukazawa/status/869927566450212868

God Save The Girls のフルが聴いてみたかったので、CDを買おうと決心。最初にGoogle検索をかけたのだけれど、なぜかAmazonの初回限定盤DVD付きしかヒットしない。
(というかまだ初回限定版が買えるというのはまああれですが。)
で、一応アーティストストア(?)に通常版があったのだけれど、ほとんど初回版と変わらないし、でもDVDは持っていても見ないしなぁ、と悩む下に「mp3」のリンクがあり、価格も250円(ダウンロード販売として一般的な値段かどうかはともかく、CDで全曲買うよりは安い)だったので、ものは試し、何事も経験と思い購入。
で、ダウンロード用のクライアントはどうしよう(母艦がLinuxだからスマホにプレイヤ入れるしかないかな)、と心配していたら、普通に「ダウンロード」のリンクがあってmp3ファイルが落とせました。

まあ、技術的にはできるだろうけれど、そうなってはいないだろうなと思い込んでいたわけですが、杞憂に終わったという。
まあそれだけですが、体感するとすごく楽で、インパクトがありました。

ついでといってはなんですが曲の感想。フルも良かったです。(人間、過去のマイナスの記憶は印象に残りやすいもので、フルで聴くとがっかりな曲もあるので聴くまで少し怖かった)
そもそも、God Save The Girls はタイトルがずるい(褒めてる)(ツイッタにも同じこと書いてる)

13265992 journal
日記

m_nukazawaの日記: Edge of exceptional exception(草稿) 1

日記 by m_nukazawa

きっかけは、会社で昼休み中に見つけたTogetterのこのまとめ。曰く、bashシェルスクリプトを書く際、何も考えずに`set -e`を頼るのはよくないのではないか、という。

挙げられている理由は大きく2つ。
ひとつ目は、エラーこそが欲しい結果である場合。あるいはvariant型の偉大な力によって、出力がエラーに変換されてしまう等の場合があること。途中解で意図的にエラーを使うことが難しく、シェルスクリプトに書ける処理が制約を受けてしまう。
もうひとつは、`set -e`には思いもよらない挙動が多く、シェルスクリプト関数の中などでプログラマの思う通りにエラーを捕捉してくれない場合があるのだという。もしその通りであるのなら、確かにエラー処理として頼るには心もとないかもしれない。
まとめ中では、`set -e`を使ってまとめてエラーを処理しようとせず、コマンドまたはパイプ終端ごとにひとつずつ、確実にエラー処理を書くことを推奨していた。

一通りTogetterを読み終わり、得た情報を元に、いま使っているシェルスクリプトを精査すべきか少し考えてみた。
まず、仕事のプロジェクト。こちらは問題無さそうだった。
次に、趣味のプロジェクト群。vecterionでは、テストの一部やビルドシステムの外苑にbashシェルスクリプトが組み付けられている。またRuneAMN等のFont系のプロジェクトではbashシェルスクリプトがビルドシステムのグルーとして重要な役割を果たしている。vecterionのテストスクリプトはTDDよろしくエラーが出るのを確認しながら書いた。Fontのビルドシステムは、最終的にフォントが出力されれば良いのであって、多くの場合、結果を見れば問題があることは一目瞭然にわかる。
`set -e`は強力なエラー処理方法だ。エラー処理がスクリプト先頭のtrapにまとまるので、コードが読みやすくなる。コマンド行毎に終了コードのチェックを入れたら、シェルスクリプトの可読性が下がってしまう。
結論として、わたしは`set -e`を使い続けることにした。確かに危険はあるのだろうが、今のところ問題は起こっていない。たぶんコントロール可能な範囲だろう。bashシェルスクリプトで関数なんて書かないし(そうでもないかな...ちょっと心配)。
プログラマがエッジケースの存在を知ってさえいれば、問題にハマって時間をいたずらに費やしてしまう心配はない。次からは気をつけよう、というか、今度、予想と違うことが起こった時には`set -e`を疑って、Web上の情報を探しなおせば良い。具体的な問題と回避方法は、実例から失敗を学んだほうが覚えも良いだろう。
こうして『`set -e`不要論』は昼休みのネットサーフィンの収穫として、ちょっとしたAssertionとまあまあの満足感を与えてくれた。その時はそれで終わった。

帰宅後、ターミナルを叩いて謹製のMakefileが自作フォントを吐き出す様子を眺めていた。Makefileがotfフォントファイルを生成する様は若干倒錯的だ。わたしは小さな幸福感に浸っていた。
そのとき、ふと昼に見た『`set -e`費用論』を思い出した。例外的な状況では、`set -e`が意図通りに働かない場合があること。いや、例外的というほど特別な状況ではなくて、普通のシェルスクリプトを書いていて起こりうるシチュエーションなのではないか。学習効率は置いておいて、いちど、ケース集に目を通すべきだろうか。
そのとき脳内でWarningが上がった。エラー発生箇所、つまり直前の思考の文字出力へ意識がジャンプする。

例外的?
`set -e`は例外に似ている。

exceptionのイメージが脳裏に去来する。言語構文に定義された例外。C++は気が乗らない。エラー処理のベストプラクティス。握り潰し。OSによるエラーダイアログ。
`set -e`も例外も、戻り値のチェックからコードとプログラマを開放してくれる。エラー処理を正常系と書き分けることで、正常系の流れが読み取りやすいコードになる。可読性が高くなればコードの保守性も高まる。コード内のすべてのエラーを自動的に捕捉することで、プログラマのミスによるエラー処理漏れを起こさなくする。
完璧なコードを書けない私たち。不完全な人間のためのすばらしいソリューション。ただしそれは、人間に完璧なエラー処理のコーディングを要求する。
十分に理解のあるプログラマが扱うならば、例外は安全で有用なものであり、`set -e`は理想通りにすべてのエラーを捕捉してくれる。例外をハンドリングしきれずに握り潰してしまうプログラマと、`set -e`のエッジケースをすべて把握しておくことのできないプログラマの側に問題がある。だが、その考えは問題を言語から追い出しただけで、問題を解決したわけではない。でもエラー処理を書かなくて良いのは楽で良いよね。
例外を諦め、簡潔だった正常系が長大な異常系への対処コードに無残に切り刻まれて埋もれることを受け入れて、関数を呼び出す度に戻り値をチェックするコードを丁寧に書くべきだ。
『今度は例外なしでやりましょうよ』。自分が先週、言ったばかりのセリフを思い出す。

自分はどちらを支持しているのだ?

例外をことさらに嫌悪しておきながら、他方で似た機能である`set -e`を擁護している自分に気づく。少なからず心がざわついた。

両者には違いもある。例外はtry{}catch{}構文で、エラー処理は後に来る。例外は回復できる。通常処理に復帰するためにあるとも言える。
`set -e`は先に来る。わたしはtrapを一緒に使ってエラーの発生行を示し、そして通常処理に戻らず終了する。事実上のクラッシュ。
```
    3 set -ue¬
    4 ¬
    5 trap 'echo "$0(${LINENO}) ${BASH_COMMAND}"' ERR¬
```
『エラーが起こったら、直ちにけたたましく警告を出し、そして速やかにクラッシュするべし』というのはUnix思想のプラクティスだったか。
エラーに陥ると、通常処理への復帰は難しい。復帰したつもりになって、床に落ちたアイスクリームを塗り広げる掃除ロボットのようなことになっては目も当てられない。
`set -e`はクラッシュを起こすための仕組みであり、例外はエラーから回復するための構文だ。前者はシンプルで、後者は複雑になりやすい。複雑な例外処理はエラーにバグの上塗りをするリスクが高く、見た目にも汚いコードになる傾向が強い。小学校で雑巾が嫌われるのを見るようだ。床拭きにはクイックルワイパーを使って、掃除が終わったらゴミ箱に捨ててしまえばいい。
あのJoel社長がむかし書いていたような気がする。『やっつけのスクリプトを例外を使って書くのはすばらしい。そしてそのコードが翌朝クラッシュしていたら、その時はやれやれと言いながら人間が対処する。それで何の問題もない』

それはその日、同僚と話していた話を思い出させる。サーバのサンプルコードには、実用性に一歩足りないところがあるという話だ。サーバアプリケーションが立ち上がり、クライアントとソケットを生成する。クライアントが処理を終え、サーバとのソケットを切断し、サーバはクライアントへのサービスで使用したすべての資源をクローズする。そしてサンプルコードは終了する。
そして、現実のサーバプログラムはサンプルコードのようには終わらない。人生は続いていく。サーバは次のクライアントを、その次のクライアントを、次の次のクライアントを待ち受けるために、自分を最初の状態にResetできなければならない。すべての資源を綺麗にクローズして初期状態に戻り、無限にループしていなければならない。だが正しいクローズは正常系でも難しい。ファイルディスクリプタのクローズ、シェアードメモリの参照カウントのデクリメント、読みかけのシリアルの破棄、fflash(3)、mallocしたメモリのfree、立てたままのpthreadの停止と削除、閉じっぱなしのMutexの開放に、アプリケーション内部の状態遷移の初期化。サンプルコードは、それらをすべてほったらかしたままExitすることで、後始末をOSに移譲する。
サンプルコードとしては正しい。サーバとしての役割を終えるところまでを一旦説明する説明の順番も、わかりやすくてありがたい。だが実用コードへ向けてもう一歩、難しいところの解説が必要なはずなのに、サンプルコードは優しげな顔をしたまま、これがすべてで十分と言わんばかりに、一番難しくて大切なところを説明してくれないで終わっている。

正常終了して正常処理に復帰するのは、かように難しい。いわんや、異常状態から正常処理へ復帰することの困難さよ。

思えば例外は、C++とJavaの目玉機能だった。エラー処理を簡略化する、銀の弾丸。少なくとも、わたしが例外を知ったのはC++には例外が有るという紹介からだ。
Javaは銀行のバッチシステムに採用された。それは、決してクラッシュしてはいけないシステムだった。大量の量産型Javaプログラマは例外を憎むことを知らなかったが、産業プログラミング業界にとっては新しいアイデアだった例外を彼らに教えるときに、例外の正しいハンドリング方法を教え損ねた。結果、無垢な量産型Javaプログラマたちは、あらゆるJavaの例外を単に『握り潰した』。
結果としてJavaの例外は、`set -e`したやっつけのbashスクリプトに劣る安全性を、銀行のバッチシステムにもたらした。少しは出来るシステムエンジニアが、再現性の低いデータ破壊を起こすJavaアプリケーションをデバッグしていて、まったく関係ないはずの箇所の関数呼び出しの奥底で、Javaプログラマがゼロ除算例外を握り潰しているのを発見した時の感情は、察するに余り有る。
C++はシステムプログラミング言語だった。`set -e`と異なり、あらゆるエッジケースで動作する回復可能な例外を実現するために、C++の例外はシステムプログラミングにはとてもではないが採用できない重装備なギミックになった。
組み込みエンジニアはC++の例外と、ついでにC++に対して期待を寄せることをやめた。無言で静かに首を横に振り、穏やかなC言語の世界に戻っていった。

結果的に、例外はその真価を発揮できない用途で、使い方が周知される前に普及してしまった。神速の重装騎兵に馬を降りて城塞拠点を守らせるようなミスマッチが、例外というアイデアから力を奪った。関数の戻り値を処理することのできない無知なプログラマが書いたゴミコードの責任を、例外は押し付けられた。
この状況下で、プログラマが例外を愛することは難しい。業界が、例外への強く深刻な嫌悪を生み出した。

例外というアイデアが過去の汚名を払拭し、古くて新しいアイデアとして再び脚光を浴びる日がきっとくる。それは、私たちが思うほど遠い未来ではないのだろう。だが、その日は明日にはまだ来ない。

まだエラー処理とそうでない何かを混同している気がするけれど、まあ間違っていれば指摘があるだろうから、これくらいで。

結論。
`set -e`不要論から始まった一連の連想のおかげで、例外に対する不要な嫌悪感に気づき、それを払拭することができた。例外は実は良いものだった。ただし、ただちにクラッシュするために使い、ただちにクラッシュできる用途に用いるならば。
さもなければ、例外は福音よりも多くの災厄を産み出すだろうから。

====
今年も夏がやって来ます。そろそろproject daisy bellに新しいメニューを増やしたいという機運もあり、ポエム、はじめました。
皆様のお口に合いますよう。ご愛顧頂ければ幸いです。

13263381 journal
日記

m_nukazawaの日記: RuneAMN PixelArticデザイン中

日記 by m_nukazawa

間隔pixelを指定する引数を書き換えては画像出力を確認する繰り返しは、確かにデザイン作業なのだけれど、一般に想像されるデザインの工程とは違う気がする。

というわけで、ドット絵風なルーン文字フォント、RuneAMN_PixelArticを製造しています。
進捗等はtwitterに上げているであるとか、最近話題だったので作ったmastdon/pawooに上げたりしています。

pawooのほうは少し期待したのですが、力量不足によるものか、肝心のターゲットであるレトロゲームファンやドット絵風のデザインをしている方に反応がもらえなくて悲しい。
それはともかく。

ざっくりデザインしてみて思ったのは、ピクセル風デザインをモノクロ2値で作るとき、簡単な要素でそれらしく見えるよう、ピクセルを示す四角の間隔をあけるデザインにしているのですが、この間隔の幅が難しい。
画面に比較的大きく表示する場合、間隔を開けすぎるとルーン文字らしく見えなくなってしまう。その一方で、幅を狭めすぎると、SNSなどで縮小画像で表示された際に、間隔が潰れて、単なるルーン文字になってしまい、肝心のドット絵風デザインにならない。
ある意味、とてもわかりやすいトレードオフ。

今はもう、諦めて両方のサイズを用意すれば? という意見に傾きつつあります。もし良いアイデアがありましたら、教えてください。

// サイズ可変なフォントにすれば、というのはちょっとパスの方向で...根本的には2~N種類のサイズのフォントを個別に用意するのと変わらないですし。

13261578 journal
日記

m_nukazawaの日記: AndroidSDK触るだけ 3

日記 by m_nukazawa

いまさら周回遅れながらAndroidSDK。ネットワークからのダウンロードに失敗することが多く、デフォルト設定ではネットワーク接続できず、同じことを何度か再施行すると上手く行く。

AndroidSDK、落ちるわけではないし、マルチプラットフォームなのはすごいけれど、皆さんよくこれで開発しているなあと関心する次第。
Install Android Studio 2.3.1 to Ubuntu16.04LTS

// コレ以外のgoogleプロダクトでもいろいろあった結果、「google、もしかしてネットワーク周り弱い会社なのか?」 という感覚が芽生えつつあり、困惑している。

13258314 journal
日記

m_nukazawaの日記: 募集:Androidとgoogle音声入力で長文を書きたい 5

日記 by m_nukazawa

どなたか良いアプリケーションをご存知でしたら教えてください。
要望としては、
- 改行できる
- 句読点"。"等が入れられる
- google音声入力を使っている(独自の音声入力エンジンとか使っていない...精度が良いならまあ可)

といったところです。

通勤中とか移動中に、ブログとか、メモより長い文章の下書きをしたいのです。

自分でAndroidアプリケーションで作ったほうが早いでしょうか?
// 簡単そうなので作ろうかと思っている、が、簡単すぎるので絶対に既にあると考えている。

13249202 journal
日記

m_nukazawaの日記: cudaと再会 4

日記 by m_nukazawa

機械学習、やれるようになっておいてよ、という要望もあって、でもしばらくぼうっとしていたらzi2ziが出てきたので、おっとり刀で駆けつけた次第。

とりあえず1050Tiを購入。
前回外付けGPUを個人的に買ったのも、もう昔のこと(オンボードグラフィック派)。

cuda、インストールが楽になってる。
昔はドライバとドライバツールキットか何かとcudaの3つを別々にインストールしなければならなかったし、その時はXを切らなければならず、インストールの順番を間違えるとやり直しだった。

今はUbuntu向けにパッケージがある。

サンプルコード群は足りないライブラリがあるそうでビルドが途中で落ちたけれど、deviceQueryと対面してインストール成功を確認。

zi2ziと数式フォントの組み合わせは、twitterにお試し結果を上げてみたら、興味を持った方が本格的に回し始めてくださったので、さてどうしようかなといったところ。
https://twitter.com/mimighost008/status/854751340433596416

とりあえず、いまさらTensorFlowのチュートリアルを読む。

typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...