 
|
はてなキーワード: ネストとは
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
tari-G 頭が痛い 彼や武田はどうみても私を含めここでブクマしている人より現実には遙かに多くの人を被曝から救っている。それを無視する訳にはいかない。 2011/11/10
凄くいいこと言ってるじゃん。
そのtari-gってこれまで見かける限りではろくなこと言わないと思ってたけど
そういう、全く別角度の発想というか、謙虚に自分を考え直してみるってことが出来る面もあるんだね。
意外な美点を見せられた感じがする。
そのブコメ欄にもギッシリ居るけど
毎度紅潮しきった顔でハフハフ鼻息ふきながら
「僕が一番この馬鹿を上手く侮辱できるんだ」大会してる奴等もさあ
tari-gの恥垢もらって煎じて飲んだら今より少しは上等な人間になれるのにね。
「攻撃してもいい人間」を攻撃する嗜虐心で年がら年中脳勃起してるインターネットのゴミ啜りなわけだけど
「いや、あくまで社会の為に（ゴニョゴニョ）」
「ちがう、我々は警鐘やカウンターを発する意味で（モゴモゴ）」
なんて、
まるで「社会正義のための公共事業やってました」みたいな言い訳をする。
そんなんじゃないのはお仲間以外のだーれが見たってバレバレなのにさあ。
要は
クラスの中でニブい奴をみんなで馬鹿にして喜ぶクソガキ小学生の愉悦、
これをいい歳になってもずーっと追い求めてるどうしようない低能のハレンチ集団だよね。
歳食って成長したのは「侮辱して楽しんでも大丈夫そうな奴」を探す、コレクトネストいう名の空気読みの小知恵だけ。
「ニセ科学を潰すのは意義のあること（ｷﾘｯ）」とかもさー
当該ニセ科学への要点批判だけを冷静に・毅然と・強烈にやればいいんだよね？
でも毎回必ずってほど
ハフハフハフハフ！って感じの、嗜虐心で血行が良くなった鼻息荒いクズの特盛りになってるよね？
また古来ネットに繰り返し現れるこの手の集団は
こんな風に自分ら自身が叱られたりすれば
血相変えて叱った人間への人格攻撃して目を背けるってのも相場が決まってる。
tari-gのをしゃぶっとけばまだ薬効があるよ。
レスが遅れてすいません。
ううむ。理系と文系の対立みたいな残念な方向に流れてきてしまいました。仕掛けたのは私のほうかもしれませんが。
京都弁？なのは一向にかまいませんが、大元の記事よりもレトリックが雑になってきているようです。
最初はそれなりにいい線いっていたのに、ここにきてもう投げやりというか、反論のための反論というか、急速に劣化ウランしてます。
オウム真理教の信者は人間。燃料棒はモノです。人間相手なら断罪するのは慎重さが必要だと思いますが、燃料棒相手にそこまで遠慮する必要はないでしょう。あそこで遠慮したことで、「メルトダウン隠蔽説」の発生という大損をしたわけです。これは表現の細部の問題で、後でいいますが、こういうのが信頼を作りだすにあたって重要なんです。
（本論と直接関係ありませんがオウム事件のくだり「化学薬品が大量に見つかった時点でもうほぼ真っ黒」という発言は気になりますね。そうやって河野さん一家も冤罪で酷い目に遭いました。人間相手にはくれぐれも慎重に頼みますよ。モノ相手はバッサリやっちゃってください。）
反原発派が物理的限界を超えて放射能が拡散する可能性を語ったせいで「だまされた」ことを批判されていましたが、今度は、逆に、物理的限界を超えて炉心の水位が保持されなかったことについては、裏付けが取れるまで断定しないことを良とする。せっかく「物理的限界」についてのあなたのロジックをもとに議論を展開しているのにスルッとかわされてしましました。なんともやりきれません。
「あいつらの中に悪い奴おるんちゃうか、だからあいつら悪い奴や」とは言っていません。「推進派が嘘をつきましたか？否。」と言いきるのは極端ということです。この点はあまり突っ込みたくなかったので、控えめに「かもしれない」で終わらせたつもりですが、もっとハッキリ言わせていただくならば、九電が今回やったことっていうのも、ウソじゃないんですか。流通していないから大丈夫って、今になってセシウム基準値オーバーの牛だって流通したことが出てきたじゃないですか。あれもウソじゃないんですか。と言いたい。それが意図的かどうかとか、実害があるないかないかは関係ないんですよ。あの船場吉兆だって、あんなの食っても到底死にませんよ。でも信頼失ったらオワコンになるんです。信頼というのはそういうもんです。推進派は、そこがまるでわかっていないんです。かわいそうなくらい。だから原発を自動車と比較したり、死者の数を出して、どうだ安全だろといったりするんです。ずっとこの調子なんですから。そんな議論で到底信頼は得られませんよ。
誤解のないように言っておきますが、わたしは原子力だけを特別扱いしているわけではありません。たとえば、メキシコ湾を汚染した油田だってああいう事故起こすのは許されません。自動車だって、免許は持っていますが、自分は下手くそなので（制御できる自信がないので）運転はしません。
広瀬隆の著作が「だまされようがありません」というのは、（あなたレベルなら）だまされようがないということです。
まあ、一読をお勧めしますね。賛否はともかく、それなりに楽しめると思いますから。私にしても全部同意するほど無批判な読み方はしていません。
「原子炉時限爆弾」の冒頭で出てくるのは、1960年、政府が原発事故の影響を試算したの極秘文書で、これが日本列島をすっぽり覆う被害予想になっているんですが、これなんか、あなたをミスリードしたナイーブ系反原発派をミスリードしたのは実は政府そのものというネスト構造だったのではないかと思えてきますよ。原発の「安全神話」もその崩壊も、推進派と反対派の弁証法じゃあないでしょうか。
まあ、私が極端な「理系」コンプレックス濃厚なのはご覧の通りですが、私にこんなにもコンプレックスを与えている、あなたを含む「理系」エリートは凄くあってくれなくては困るわけで、それが凄くないもんだから、もうプンプンですよ。上から目線などとんでもない。どんなにパニクっても、おが屑突っ込むみたいな無意味なことを弁護するのはやめてほしい気持ちでいっぱいです。あと、文系の連中ごときに手足縛られて、安全対策ができないっていうのなら、団結して職場放棄しろといいたい。「理系」には、モノを握っているという、そういう力が有るはずです。そういうのが「理系」の良心でしょう。原子力を制御できても、文系のアホ連中は制御できないって情けない話じゃないですか。
その2極の間の無数の中間。
結局、ナッシュ均衡で決まるんじゃないでしょうか。
私は原発賛成派でも反対派でもありません。というかこの二分法は意味がないと思ってます。まともな人なら賛成派であれ反対派であれ
「原子力を置換できるよりよい方法（省エネ含め）があれば脱原子力を進める、そうでなければ現状維持のままよりよい方法（原子力の改良・改善を含む）を探す」
この立場に共感。
賛成/反対の二分法はわかりやすいけど、実際的じゃないと思う。
もう我々には悠長に代案考えてる時間なんてありませんよ。明日にも第二の事故が起きるかもしれないんですよ。もしそう思えないなら、認識が甘いと思います。東電だって、明日事故は起きないだろう、来月もきっと来年だって起きないだろうと思い続けていたから、今のようになっています。自覚してください。あなたの感覚は事を起こした東電や政府や御用学者と大差ないんですよ。彼らも自分らの感覚が常識的だと思いながら、原発の運用を続けていたわけです。彼らは事故を起こしたくて起こした極悪人でも、社会人として著しく失格なウッカリ者でもありません。あなたのような標準的な人間なんです。そして現状は、それではいけないことを示しているんです。
http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/
良いPHPerだって？そんなものは丸めてゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。
つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。
それじゃ、始めよう。
?>なんて使っちゃいけない。そう俺たちはBAD PHPer。
無駄なホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めてゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。
require_once("config.php");
未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。
ダメだ、早く何とかしないと。
大抵このconfig.phpの中身はこうなっている。見て絶望だ。
$hoge_path = ''; if (!LOCAL) { define('FOO_FLAG', 1); if (HONBAN) { define('HOGE_FLAG', 1); } else if (TEST) { define('HOGE_FLAG', 2); } } else { $hoge_path = '/local'; define('FOO_FLAG', 2); define('HOGE_FLAG', 3); } define('HOGE_URL', $hoge_path.'/hoge/');
こういうのが延々と続くわけだ。もういやだ。もう見たくない。
本番環境とテスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。
なまじPHPな設定ファイルのせいで、処理をついつい書いてしまう。そしてどんどん複雑になってしまう。
やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである。
そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。
# 本番環境設定ファイル foo_flag: 1 hoge_flag: 1 hoge_url: '/hoge/'
# テスト環境設定ファイル foo_flag: 1 hoge_flag: 2 hoge_url: '/hoge/'
# ローカル環境設定ファイル foo_flag: 2 hoge_flag: 3 hoge_url: '/local/hoge/'
// ここで後の処理のためにhogeメソッドを呼び出しておく $q->foo(); // $a['foo']はここに来る時点で真のはず // 2010-03-10 判定がおかしいので修正 // 2010-06-21 やっぱり値が入ってる方が正しい if ( !isset($hoge[0]) ) { }
コメントは保守されない。そう、それは真実。こんなコメントを発見したら即効削除しよう。コメントは基本信じるな。
俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。
わかる。いいたい事はとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。
タブを画面上で認識しにくいエディタが世の中には存在する（何とは言わないが）
そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。
この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。
私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。
われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。
御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。
そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。
$iNumber = 'aaa';
になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。
変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。
$foo = null; $foo = $q->foo();
こんな初期化に意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう
$foo = null; if ( $hoge ) { $foo = 1; } else if ( $bar ) { $foo = 2; }
このときの初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; return $bReturn; }(中略)
もし、何かしらの理由で、あなたの書いたif文が間違っていたら？
この書き方をしていれば、間違った値に対して、常にfalseが返る。
私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータが入力されるまでは、動かないコードを書くべきだ。
trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; else if ($i == 1) $bReturn = false; else throw new Exception("bad status! $i"); return $bReturn; }
中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね！
連想配列のキーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。
更に後世のプログラマが処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にしたい場合はconstantを使うと良い。
// 定数のFOOを使うよということが明確になる print $a[constant('FOO')];
もし、文字列を変数の値と一緒に出力するとき、PHPではコンマの代わりにprintfを使うことが使える。
printf( “Hello, my name is %s“, $sName);
以下の代わりに上記のコードを使う。
echo “Hello, my name is “, $sName;
出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。
三項演算子はとても有効だ。しかし優先順位に難があるせいで、三項演算子をネストしようとすると以下のようなコードになってしまう
$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));
括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めてゴミ箱にでも捨てちまえ。
if ( $flag ) { }
仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。
もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。
インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい。
わけがわからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。
文句なしだ。これは文句がない。
他にも色々あるので覚えておこう
$a %= 1; $a &= 1; $a |= 1; $a ^= 1; $a <<= 1; $a >>= 1;
てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。
なのでdivを使って以下のようにしとくと便利だろう。
function p($var) {
echo "<div align='left' style='background-color:white;color:black;'><pre>";
print_r($var);
echo "</pre></div>";
}
君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ！
大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがわからなくなってるパターンが多い。
貴様みたいなもんに、定数は制御できん。いいか設定ファイルはYAML等のデータで持つようにし、その連想配列のデータ構造を一つ持ってるだけで定数の変わりになる。
このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めてゴミ箱へ捨ててしまうといい。
認識を改めろ。俺たちはより良いPHPerにならないために努力している。
class Request { private $parameters; private $method; function __construct () { $this->method = $_SERVER['REQUEST_METHOD']; if ( strtoupper($this->method) === 'POST' ) { $this->parameters = $_POST; } else { $this->parameters = $_GET; } } function param ($key) { return isset($this->parameters[$key]) ? $this->parameters[$key] : null; } }
これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ！
例が良くない。こんなのは引数が20個ある関数から、setを20回呼ぶオブジェクトに変わっただけではないか。
そもそもこの20個の引数とはなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし、20個も引数取る時点で設計が間違えている。
何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。
そんなことで悩んでる暇があったら設計を見直せ。
スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。
ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。
どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。
・・・と、いうのはやめなさい。
一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。
まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。
確かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ！
あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。
気を抜いて。そう気を抜いて。所詮あなたのコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。
結合度を減らすというのは非常に難しい。何度も何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。
まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。
そしてその後に、一部分使いまわしたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。
何事も経験が必要である！経験を積まないプログラマは丸めてゴミ箱に捨ててしまえ。
さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だって、addとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか。
function add_result_output ($iVar, $iVar2) { $r = add($iVar, $iVar2); echo result($r); }
もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう！
このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。
あくまでも「より良いPHPerにならないための20Tips」なのだ。
君はこの記事を鵜呑みにしてはならない。PHPをPHPと見抜けないPHPerはPHPを使うのは難しい。
もし、あなたがPHPプログラマなら、公式のPHPドキュメントはあなたのケツの穴を拭くための紙になるだろう。
私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。
あなたは、PHPで用意された既製関数で多くのことが実現できることに、（俺の仕事を減らすなと）驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな！
この記事に書かれている内容は、丸めてゴミ箱に捨てた方が良いレベルです。
そもそもCとかC++の初心者で？のことを良く理解していないレベルに読みにくいよ
だいいち、そのレベルなら ifで書けばいいだろうと。
そもそも
while( (*p++ = *c++) != '\0' );
c = param [ a>=0?a:0 ];
みたいな、使い方 をして 他の演算の引数に3項演算子を使ってるならわかるが
単なる代入だけで、しかも複文でネストすんならifで書けや！
ネストするってことは条件があるていど複雑ってことで、あとで、デバッグ用のif入れたりprintf入れたり改造する可能性があるってことを考慮してくれ。
変に？をネストさせて、『他人が間違えて』間違った改造いれたりしたら、どうするつもりなんだと？
間違った奴が悪い？複雑なネストして、間違いやすいコードを残した奴も悪いよ。
簡単にいえばたった、5行のスパゲティ。
それがやりたいなら、ボタン１個で勝手にネストしてくれる開発環境のエディタ使ってくれ。
viしかつかえない？いや、今時、windows側でnfsなりsmbなりで、マウントしてwindowsのツールでエディットせいや。もしくは、マクロぐらいくめや。
いや、うん。プログラマ自体はさ、たかだか数Kか、十数Kしかみないから、それでいいんだろうけど。
それを組み合わせて、数百Kとかのソースコードをメンテナンスする身になってくれ。
世の中には、アプリ全部を端から端まで、みているアーキテクトという人間もいるんだよ。
え？アーキテクトはコードは見ない？いやいや、ご冗談を。メインリポジトリ配下は全部見なきゃアーキテクトなんてやってられないよ。
もちろんマクロにではあるけど。何かあったらミクロに見ることもあるわけで、そんときに検索していてif 0とかだと、イラッと来る。しかも広域。
セクショニング・コンテンツ要素やセクショニング・ルート要素のアウトラインは、一つ以上の潜在的にネストしたセクションから構成されます。セクションとは、本来の DOM ツリーのいくつかのノードに相当するコンテナのことです。略（アウトラインの中のセクションとは、section 要素に相当するものもあるかもしれませんが、section 要素のことではありません。これらは、ただ単に概念上のセクションでしかありません。）
http://www.html5.jp/tag/elements/headings-and-sections.html#outline
セクショニング・コンテンツ
アウトライン - 一つ以上のセクションから構成される
セクション - セクショニング・コンテンツでもよい
セクション - セクショニング・コンテンツでなくてもよい
ネストが一段浅いが「おみあし」なんてのもあるね。御御足。
http://anond.hatelabo.jp/20080129103249
http://anond.hatelabo.jp/20080129104430
うそん。まじで？
ツリー浅いといいけど、深くなるとネスト見にくくない？
えっと、あとで見にくいツリーを提示するから、見やすいって話をもう少し教えてくれ。
「ワード・エクセルできます！」を書いた者です。続き。
はてブで「3が分からない」という声を多くいただきました。MIZさんの指摘どおり、順にAlt+Enter、表示形式、条件付き書式、四捨五入の考え方、並べ替え（またはフィルタ）が分かるかどうかを試すという意図で書きました。が、どうやら条件付き書式は必須と言うよりアドバンストな機能のようなので、取り消します。
私の仕事に「エクセルで作った表にそれぞれ数値を入れてもらって、集まったシートを集計する」というのがあって、「黄色い所に数字を入れてください。間違っていたら赤くなるので、赤くならないようにしてから提出してください」と説明して、必要な部分以外ロックしたファイルを配布する、という風に条件付き書式を活用しています。もらったファイルは一つにまとめて串刺し集計。
1から100までの連番を1分で作る
Alt+Enter並に重要ですね。昔はA1に0、A2に「=A1+1」と書いて、A2を下に向かってコピーしたりしていました。
重要ですね。表示形式の点でかぶるので、2を削除してこれにしましょう。
legnum シート名をセルに表示すんのって→しか無いの？RIGHT(CELL("filename",A1),LEN(CELL("filename",A1))-FIND("]",CELL("filename",A1)))
私もそれしか思いつきません。というか、見て単純に「すごいな」と思いました。
ifとvlookup重要。特にvlookup。値によって16くらいに条件分岐させる必要があったとき、ifのネストは7段階(だっけ?)までしか使えないからと、ifでまず上位8つと下位8つに切って、中をさらに4つずつに分けて……とやっていたのが、vlookupで一発になりました。
面白いのは、全部間違っていないところ。一応、与えられた条件をクリアーしてしまう。
また、こういった人たちの二大特徴「TIOOWTDI」と「紙至上主義」を上手くつかんでいると思う。
TIOOWTDIというのは自分の造語だけど、There Is Only One Way To Do It。一つやり方を覚えたら、それがどんなに非効率的でも、別の方法を探そうとしたりしない。「だって、それでできるんだから別にいいじゃん」
紙至上主義というのは、エクセルに対する捉え方。紙にきれいな書類を印刷するためであり、印刷がきれいだったら中身はどうだろうと構わない、という考え方。中身をエクセルで計算させようが、手計算しようが、結果が一緒だから構わない。データの再利用はあんまり考えない。この間「データに注釈が必要だったらそばに書いておいて」といったら、オートシェイブで四角形を書いて、その中にテキストを入れてきた人がいた。あとで並べ替えたり、一部だけ切り出したりするのに。
で、こういった人たちに、どうしたら効率的なやり方を覚えてもらえるかというのは、昔から考えているんだけど、結局、彼らは現在のところ「新しい方法を覚える手間＞作業の手間」と考えているからそうなるのであって、ムリヤリ教えてもしょうがないな、と考えるようになった。http://anond.hatelabo.jp/20071203024102の方法は、その人がエクセル上達したいと思っているからできるんであって「いいじゃん、これでおんなじことはできるんだから」という人には手の打ちようがない。誰かが「文面が一緒で、宛名だけ違う書類を何枚も書かないといけないよ、打ち直すのが大変だ」とぼやいていたらそこで差し込み印刷を教える。そういう方法で本人に便利さを実感してもらわないと、どうせ忘れちゃうよ。
ただ、相手がおじさんとかだと「こないだの便利な方法、あれやってよ」と毎回頼まれるという事態に陥るという最悪の可能性もあったりするけど。
最後に。
拗音・促音を半角カナで表現していた人がいた。
そもそも手打ち職人って、うどんかそばじゃないんですから……。
7、8年前ならいざしらず、いまどきtableつかわないと思った通りのレイアウトができない方がおかしいと思うんですが、世の中ではちがうのでしょうか……。
10年前は複雑なtableのネスト構造や、スペーサーの使い方で自由自在にデザインしてみせますよ！というのをウリに、HTMLを手打ちしてました。
2000年ごろには、逆にtableやspacer.gifを排除するために、HTMLを手打ちしていました。
なんでそんなめんどくさいことしてるの？Dreamweaverとか使えないの？といわれ続けていく歳月。
でも、SEOブームなんてのがきたときは「いままでそんなこともしてなかったの？」って感じでスルーできたよ。
最初っから構造を意識して書いてるんだから、インチキSEO業者なんて入り込むスキマもないよね。
んで、動的コンテンツを作るときにも、エンジニアさんと連携しやすい。
問題は、DreamweaverでしかWebが作れない自称Webデザイナーと共同作業しにくいこと。
それでもさいきんはツールのほうが賢くなってくれたので、大分マシになったよ。
さすがに、ポチポチとタグばかり打ってる年齢でもないので、もっと他の部分で自分のリソースを使う割合が増えたけど、美学というか信念というか、そういうものを継承してくれるような若手がなかなか居ないので、あいかわらずエディタは手放せないのです。
まあ、ライティングも編集もオーサリングも同時にできちゃうから、便利っちゃ便利だけどね。
海は死にますか、山はどうですか。
*{ margin : 0 }はもう古い！？ | Emotional Web
はてなブックマーク - *{ margin : 0 }はもう古い！？ | Emotional Web
はてなが酷い。
base.cssとかcommon.cssとかを書いて読み込ませるのは、何のためだったか考えてみよう。古い新しいの問題じゃないと気づくだろうか。少なくとも、レンダリング時間なんて完全に後付けだと洞察できるはずだ（あなたたちはjs大好きだよね）。
さて、真っ新なとこからCSS書いてくとき、どんなデザインにしろほぼ毎回指定する要素が出てくる。a img{border:none;}とかhtml,body{margin:0; padding:0;}とかだ。それなら始めにa img{border:none;}とかを羅列したファイルを用意しておけば、余計な手間が省けるじゃないか。たぶん根本の動機はこんなとこだろう。
それがいつの間にかデフォルトで適用されるスタイルをキャンセルするっていう方向へ迷走し、*{margin:0; padding:0;}なんて表現が生まれた。この指定は言うまでもなく有害で、著名なのはフォームのボタンが縮こまったり、liのネストが判別できないなどの副作用が生まれる。あまりにもすべてがキャンセルされるため、わざわざひとつずつ要素のスタイルを定義しなければならなくなって、ファイルサイズは増え可読性は下がり、冒頭で言うようにレンダリングにも時間が掛かるようになる。FireBugがない時代、この要素のスタイルはどのファイルのどの部分で指定されてるのか調べるのは本当に大変だった。*.cssをgrepしたとしても、単にul li{}とか書かれてるのがカスケーディングしてたらお手上げ。
これらのデメリットを認識したとき、はて*{margin:0; padding:0;}のメリットはなんだろうと考える。あ、特にないよね。じゃあやめよ。←いまここ
こんなのは実際にCSSを書いてたら気づくことだ。海外とか時代とか関係ない。元記事の趣旨は「*{margin:0;}は古い」じゃなくて「どんなCSSが効率的か Part2」だ。レンダリング重いから*{margin:0;}やめようなんてコピペ脳丸出しじゃ、いつまで経っても効率的なCSSなんぞ書けんよ。
＊原理主義者が「（例えば数十年後にリリースされた）UAがどんなスタイルを適用するかわからないので、最初にリセットするのは永続性完全性の観点から意味がある」と言うけども、未知のUA（というかデフォルトスタイル）まで考えてCSSを書くのはあまりに大変だ。それに、そんなことになれば、たぶん、compat.user.cssみたいなのが流行るはず。デフォルトスタイルに頼った表現がしょせん実装依存なのは認めるけど、ちょっと非現実的すぎるので、考慮から外させてもらう。俺はいま実務の話をしたいんだ。
で、元記事では、じゃあどんなCSSがいいのかって点がついで程度にしか触れられていないので、俺なりに考えてみた。
これは外せない。aの中のimgにborder付けたいってほうがイレギュラーなので、わざわざa.logo img{border:1px solid #333;}なんて書き直すのも苦にならない。例外には手作業でもって対応すべき。
ほとんどの場合、隙間を空けたいよりも隙間を空けたくない。キャンパスはフルに使いたい。
印刷時にはそうでもないので、@media print {body{padding:1cm;}}なんてのがあってもいいけど、それはまた別の話。あとそういうのは印刷するユーザー側で指定すべきだとも思う。理想論だけど。
lang="ja"な文章において斜体は不要。どうせあなたはemとかaddressとかにfont-style:normal;付けるんだから。
preやcodeがsans-serifだとイラっと来ますよね。
やられるとイラっとくるもの。個人的。
俺はページをメイリオやヒラギノやM+ FONTやVLゴシックで見たいんだよ！ お前の趣味を押しつけんな！ あと最後に一般名（sans-serifとか）くらい書け！
でもpre.2ch-ascii-art{font-family: "MS Pゴシック";}なんてのはやさしさが溢れていてとても好ましいと思う。部分的にfont-family指定するのは別にいいけど、全体のデフォルトフォントをいじられるのは不愉快でしかない。
まあ仕方ないのはわかる。解決法も知らない。けどホイールでスクロールしてるとき興味のないサンプルコードで引っかかるのはとてもムカつくんだ。俺は君のサイトが崩れてるかどうかより、いつも通りのスクロールに関心がある。
pre以外にグラフィック目的でoverflow:auto;を指定するのは論外。
「CSSは個々人のスタイルを反映してるということでしかないんじゃないの」
「そうですね」