kozawa のたまに気になること

リンクの少ないでもぶろぐ・・・にせぶろぐ?
スポンサーサイト

一定期間更新がないため広告を表示しています

| - | | - | - |
Nagoya.php vol.9

Nagoya.php vol.9 - Nagoya.php | Doorkeeper へ行ってきました。

ソフトウェアの世界にいますが、仕事でPHP書いたのはつい最近少しやったのが初めてだったぐらいなのでお勉強に。

前日お酒付きの打ち合わせが遅かったので、持参するノートの開発環境のインストールをしてなくて、当日wifiで IDEからMAMPから全部インストールとかいう体たらくで、開始時点でまだ設定が終わっていなかった…orz。

ろくなコードはかけてないのでとても公表したくないレベルなんですが、(時間ぎりぎりになってやっと汚いコードが動いた ので次の課題に進めず、しかも一部間違っていました。他の言語ならもうちょっとましに作ったのに…orz
出来のいいコードを当日公開したベテランの方々hidenorigoto/Nagoya.Dk9 77web/Nagoya.php.Vol9や、後日公開した方kenjis/Nagoya.php.vol.9-DouKakuなど、みなさんさすがです。 読むだけでも参考になりました。

LTもなかなか良かったです。

体力的限界その他の都合で懇親できなかったのが残念です。

まぁ、懇親って得意じゃないんですが(汗

| 言語 | 10:21 | comments(1) | trackbacks(0) |
文書水増しアプリが欲しい
 きっと既に誰かが言ってて探せば構想はきっとあるし、断片的には既にそんなソフトはありそうな気がするけど、単に自分が調べてないだけです。

とはいっても、ニーズ自体はきっとあると思われるものの、ニッチすぎて開発費用を売り上げで元が取れる気がしない点がとても痛いです。

第1のニーズ。「なるべく意味を変えない言い換え候補をなるべく出してくれて、候補は数多く出せる能力があり、候補を出す際に文字数の増減量がちゃんとわかること」。だである→ですます的なものは勿論、類語辞典的なものから、漢字を仮名に開いて字数を稼ぐとか送り仮名のバリエーションで字数が違うとか、カタカナ表記の表記ゆれによる字数の違いとか、通常類語辞典ではカバーされてなさそうな「かもしれない」が「かもしれないがはっきりしない」に無意味に文字を増やす言い換えなどもサジェストしてくれる(厳密には意味が違うけどそこは脇におく)。

第2のニーズ。もちろん、ここで元の文章の文体を見てなるべくなら文体の変わらない変更を優先して出してくれるような機能も必須(前述のものでは漢字を仮名に開いたり送り仮名の揺れを利用する場合、どういうのを選ぶのかは本来は文体に左右されるというか、どういうルールで全体を統一するか等、まぁともかく地の文とあまりに浮いた字数稼ぎはあまりよくないということで…)。

第3のニーズ。全体を指定文字数にぴったり合わせるサジェスト。これは文字数を増やす方も減らす方も。ここで、単なる総字数指定以外にも、原稿用紙的な縦横文字数の枠で、改行や段落字下げ等を意識して行数を意識した文字数合わせも欲しい(ページをぴったりに納める系のテクニック)。変則的な紙面レイアウトにあるような写真や図の回り込みも対応しているとなおよい…。

などと要らんことを考えております。アホですね、私。
| 言語 | 06:23 | comments(0) | trackbacks(0) |
愛国的アルファベット呼称

本記事はネタです。

世間でアルファベットと呼ばれることの多い英字等。ここは議論の簡略化のために英字「ABCDEFGHIJKLMNOPQRSTUVWXYZ」の26文字に限る。この制限は趣旨には影響がない。この英字の各文字の日本での呼称は英語の影響を受けた「えーびーしーでぃーいーえふぎー」などとなっている。これを愛国的に「あーべーせーでーえーふーげー」などと変更するべきではなかろうかという提案である。この愛国的、の最大の基準は「日本語のローマ字表記上の各文字と発音の関連がわかりやすくすること」である。なのでこの点においては子音に使われる文字Bがべーであるのかびーであるのかはあまり問題ではない。この変更を行うのには大きなメリットがある。それは「えーびーしー」のという読み方を覚えても単語を読んだりする時に役にたつ度合いが少ないことにある。わざわざ英語のバイアスのかかった「えーびーし」と覚えたところでAを英語で「えー」と読む事ももちろんあるのだが、fanなら「あ」の方がずっと近いし、あまりにも「えー」より遠い場合が多すぎる。他の文字も子音に主に使われる文字も例外が多すぎる。そして、勿論なにより日本語のローマ字表記上の読みとはもっと異なる。こんな不便極まりない話しがあろうか。しかし、これがドイツ語スペイン語イタリア語フランス語等になると、その言語におけるアルファベット個別の読み方と発音の対応関係はずっとよく、例外が減る。実のところドイツ語スペイン語イタリア語フランス語であればどれを選んでも英語的読みよりは日本式ローマ字読みとの対応がずっといい、がドイツ語を選ぶとCのツェーは読みにくいしJのヨットは日本語にJを使うとじぇーなどの方が都合がいい。他を選んでも大なり小なりイマイチの文字がある。なので、これらの間をとって日本っぽくすればよい。そうすると、英語以外であるドイツ語スペイン語イタリア語フランス語などの言語を覚える時にも余計な英語読みの呪縛から多少なりとも離れて学習し易くなるというメリットまである。

「あーびーせーでーえーふーげーへーいーじぇーけーえるむーぬーおーぺーくーらーすーてーうーう゛ぃーわーえっくすーやーぜー」などなど。LとRをどっちも日本語ではら業だからどっちもらーと読んではさすがに都合が悪いのでラ行っぽさの強いRを優先してらーにしてLは違う呼び名にした。ほとんど日本語で使わないXはほとんどどうでもよい。強いて言えば日本語ローマ字変換IME等では使われることがあるのでその読みのどれかから選んでもよかったのだがXに関してはどれを選んでも無理筋っぽかったので諦めた。など。

繰り返すがジョークである。幾ばくかの本音を上記に織り交ぜてはあるが、詭弁の山であり、「仮にラテン文字の日本での名称を敢えて問題提起する時に重要な論点が網羅」されているわけでもなければ、「名称変更のメリットがデメリットを上回ると私自身が考えている」わけでもなく、「変更を訴える意図」自体が書いている本人にまったくないのであしからず。このネタの再利用の際には本人の意図しない(詭弁のつもりがない、等の)単なるデタラメが混じっている危険も大いにありうることに注意すること。

| 言語 | 00:49 | comments(0) | trackbacks(0) |
Making Software エビデンスが変えるソフトウェア開発

『Making Software ―エビデンスが変えるソフトウェア開発』Andy Oram, Greg Wilson, 久野 禎子, 久野 靖 いい本なのでまぁお勧めですが、FLOSSやFirefox関係者にも面白そうなネタもあったりしたので、そこを敢えてご紹介。

本書自体良書で、ソフトウェアの生産性や品質等に関して業界なり世間では色々な手法が言われ良いの悪いのと言われるわけですが、その議論らしきものの少なくないものが経験則だけで語られていたり、データを持ち出していても、母数が少ない、条件が均一でない等分析として不十分だったりするわけで、本書は第1章で測定と分析全般に関わる話をし、第2章で個別のテーマでできるだけ分析らしい分析を試みた論を集めるという形を取っている。業界人なら全員読んでおけぐらいの気分ですが。

O'Reilly Japan - Making Softwareに目次がありますが、その中で、

第局凜愁侫肇ΕД工学における個別の話題

11章 コンウェイの法則の系(クリスチャン・バード)
の中に、
・マイクロソフト内部の組織上の複雑さ
・オープンソースソフトウェアのバザールにおけるチャペル
と、マイクロソフトの事例とFLOSS界隈の事例を引き合いに出してます(どっちがよいのかとかそういう話ではありません)。

15章 品質戦争:オープンソース対有償ソフト(ディオミディス・スピネリス)
もろにFLOSSネタです。OSのコードの話が中心です。

21章 モジュール化はどれくらい効果的か?(ニール・トーマス、ゲイル・マーフィー)
ここの分析にFirefox等のプロダクトを分析してます。

24章 バグレポート収集の技芸(ラーフル・プリムラージ、トーマス・ジマーマン)
バグレポートのあり方についてFirefox等のプロダクト開発者にアンケートを取った結果などを分析してます。

辺りがまぁFLOSSをもろに取り上げています。FLOSSの質を見るのにもいい論ではないでしょうかという感じで、是非読まれてほしいものだと思います。

| 言語 | 01:45 | comments(0) | trackbacks(0) |
読みやすいソースコード?

読みやすいソースコードとはって一部にやたら好きな人がいて、まぁでも宗教論争にもなり得て、色々あれですね。

個人的には「ロジックと書式において書き方の思想が一貫しているコード」が汎用的に読みやすいのルールになりますね。
プログラミング言語によっても読みやすさは変わってくるとか色々条件がありますが、ある一連のコードの中で前述のが一貫しているコードは慣れないスタイルは最初とまどっても慣れれば読めるようになったりします(まぁ例外はありますが細かいことをいうときりがない…)。

CとかJavaとかの例で以下ずっと話をしますが、書式の一貫性って、まぁわかりやすいところで言えば

if ( )
{
if ( ) {
が何の法則もなく無秩序に混じっていると読みにくいですよねって話です。インデントしかり。1行何文字を超えたら改行するのかetc。
※それはもちろん、例えば、1行の文字数の最大を考えるのにはディスプレイサイズとか解像度とか、場合によっては印刷した時に1行に入る文字数を考慮するのはありだと思います。コードの上の方と下の方途で改行位置が無秩序に違うと読みにくいかと思います。

読む方がルールを読み取りやすければ読み取りやすい程、読み手にとって読みやすいです。ただ、これは読み手の力量や習熟度によっても違うことなのでどれが正解というのと一概に決めるのがいいとは言いませんが、でも例えば同じ関数の中でとかっていう一定の範囲においてその範囲の中の全体の中での一貫性を考えずに書いたコードよりは考えた方が読みやすさは上がるという一般的法則はあるとは言ってよいかと思います。それが「どの程度か」「考える時間を投じるだけ価値があるか」という話になるとケースバイケースで、まじめに測定しようと思うとそれこそ大がかりな実験が必要になって、まぁそういう実験はそれはそれで興味深いですが、(測定という意味における)素人目に勝手に断言しても何もおいしくないなぁと思ってます。

ロジックにおいて一貫している、の例
コード例 A-1

int calc(int input)
{
    if (input == 1) {
        return 253;
    }

    if (input == 2) {
        return 24;
    }

    if (input == 3) {
        return 783;
    }

}

コード例 A-2
int calc(int input)
{
    int returnValue;
    if (input == 1) {
        returnValue = 253;
    }

    if (input == 2) {
        returnValue = 24;
    }

    if (input == 3) {
        returnValue = 783;
    }
    
    return returnValue;
}
とではどっちが読みやすいでしょうか。switchにしろとかって話はもあるでしょうそもそもどっちも突っ込みどころがあるのですが、ここでは二択で考えてください。まぁ私はA-1が好みですが、この例ではぶっちゃげどっちでもいいです。ちなみに私がA-1が好みな理由は「(1)変数が少ない(2)全部を読めばわかるけれど上から読んでいて二つ目のif文に着た時にはまだ一つ目のif文の結果trueの場合もfalseの場合も覚えていなければいけないけど、returnしていればそれは忘れていい」みたいなものです。まぁ反論もあるかと思いますがそれは今回書こうとしている内容と関係がないからいいです。

問題は、
コード例 A-3

int calc(int input)
{
    int returnValue;
    if (input == 1) {
        return 253;
    }

    if (input == 2) {
        returnValue = 24;
    }

    if (input == 3) {
        returnValue = 783;
    }
    
    return returnValue;
}
こういうのです。私はこれはやめてほしい。A-1かA-2にしてほしい。私がいう「ロジックの一貫性」は例えばこういうのです。もちろん、こんな簡単なのはぶっちゃげどうにでもなって、もっと複雑な例になるとA-1かA-2かどっちかに簡単には寄せられない場合もあるので、仕方がない場合はあろうかと思いますが、A-3よりはA-1やA-2を選ぶ。これがロジックの一貫性の考え方です。もちろんこういう一貫性を考える条件は色々あるわけで、複数のifの中に共通ロジックがあったときの共通化とか考えると、結果的にA-1、A-2式に無理に倒すよりA-3式の方が読みやすいこともあるかもしれませんが、考えた結果であることが重要だと思ってます。もちろん、結果的に大差がないことはあります。大差がないことに考える時間を費やすことにたいした意味がないことももちろんあります。それでも、考えないよりは考えた方が保守性があがる、という一般則はあろうかと思っています。

各種コーディング規約や読みやすさに言及した書籍やブログとかの内容を色々読んで考える練習をするのは糧になるかもしれません。

| 言語 | 20:03 | comments(0) | trackbacks(0) |
Firefox3 Meter レビュープラス
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< April 2017 >>
+ NEW ENTRIES
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE