  |
はてなキーワード: ネストとは
今日プロジェクトの打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQLの魔女と呼ばれていた。
今から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSEの仕事内容、特にWebのアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。
初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。
与えられた課題を終えるごとに、コードを提出するのだが、見たよ〜出来てると思う、頑張ったね〜と言われた後で、そのプロジェクトを下敷きに発展課題に足を進めたら、でっかいバグがあったり。
万事その調子で、今やってる課題放り出して、プロジェクトオイラーの問題でも解いてた方がよっぽど楽しいなぁと若干サボりたいと思い始めた頃、炎上プロジェクトへ先輩と二人テスターとして出向するよう、上司から命じられた。炎上プロジェクトのリーダーから手待ち要員いない？と声がお上に届き、降りて来た結果先輩と自分がいたわけだ。
前の事業部ではずっと同じ客先にいたわけで、頭では分かっていても鼻先三寸で飛ばされることには不安がつきまとった。
「これから行く先はどうなんでしょうね？」
先輩へ問うと、
「基盤にいたんでしょ。メインフレームが扱えるなら大丈夫だよ〜」
豆腐すらぷるぷる震えそうな声が返ってきた。
この時の私は、まだ事業部を転属して間もなかったし、プライドばかり高くて奢ってたように思う。事業部を変える→入社して以来の経験値がまた0に、と失うことに対する不満ばかりで、それが拗れて数少ない基盤系経験アプリ開発者、そんな肩書きばかりを強調する変人に成り果てていた。自己紹介で、どうも、基盤から参りましたと、そこだけは大きい声が、今思い出したけどマジで恥ずかしい。
だから、だろう。このゆるふわな先輩とドナドナされることに密かに感じていた屈辱には、出向いた先で押された駄目テスターという烙印によって罰があたることになった。
その理由は、私がSQLを全く使えなかったことにある。テスターとして行うことになったのは表示画面の統合テストで、UIの検索結果とデータベースに直接SQLを打ち込んで得たレスポンスを目で確認していく作業だった。UIは、境界値さえ気をつけて、仕様通りに実施すれば何とかなる。しかし、SQLで再現が出来ない。この仕様はどうやったらコマンドに落とし込めるんだよ。頭を抱える中で思い出したことがあった。
教育過程でJavaサーブレットを学んだが、その一つにJDBCも勿論習った。そこで私は何をしたか？mysqlに繋げればそれでいいやと、エグゼキュートで実行する際に渡す魔法の文字列……つまりSQLの中身は、すべてコピペで済ませていたのだ。社内教育資料を内部作成するにあたり参考にしたと思われるネットから……構文チェック効かないし、ここは手を抜いてもいいだろう、これが要領の良さというものさ……アホーアホー私のアホー。
三日目の午後二時、進捗を確認しに来たPMにすべてを告白すると、ちょっと来てとPMが連れ出したのがあの先輩の席だった。
「申し訳ないけど今やってるテストは止めて、これから定時いっぱい最低限テストが出来るように彼にSQLを教えてやってくれ。」
良いのですか？と顔をあげるとPMは何を勘違いしたのか、やにわに私の肩を叩くと、
「彼女はSQLの魔女と呼ばれている。半日でお前も即戦力だよ。」
と去っていった。顔を先輩へ戻すと、あのPMさんは嘘つきだから信じないほうがいいよといつものふわふわした声でにっこり。
宜しくお願いします。ノートパソコンを横に私は型通りの挨拶。四時間後、私は傲慢さを、尻の毛まで抜かれることになる。
私はSQLの深さを知った。SQLのQとは何だ？Queryであります、サー!!今も時々夢問答を繰り返す。そう、全ては問い合わせ次第なのだ。今思えば、あの時やったことはT2テストを使ったSQL文の作成と添削、しかもSELECTによる条件抽出のみだったが、そこに全てが詰まっていた。
DISTINCTとORDER BYの共存で詰まってわけがわからなくなったコードは、もっとシンプルにいけるよと副問い合わせに書き換えられて。ネストとワイルドカードを多用してスパゲティになったコードを、先輩はLEFT JOINとWHEREとORで全てをすませた。
なんということでしょう。マニキュアが塗ってある長い爪からは想像もつかない早さで直されていく構文に脳内で途中から匠の曲が流れ始めたのを覚えている。本当に、なんということでしょう。先輩はSQLの魔女だった。
翌日、先輩の教えはしっかり自分に身に付いていた。すらすら書けるSQL、サクサク進むT2テスト。条件設定に悩んで、エクセルに吐き出してからリストとコピペで逐一加工してた時間が馬鹿みたいだった。先輩のところへ、帰りしなに昨日のお礼と作業進捗に激震が走ったことを伝えると別にお礼なんていいよーといつものふわふわした顔で微笑んでくれた。
それから先、配属先が決まるまでの条件付きでテスターとして入っていたはずだったが、T2試験が終わり、T3試験が始まってもなぜか私はそのプロジェクトにいたままだった。DB担当者として。もともと基盤だったわけだし、バッチファイル処理でスクリプトがそこそこ書けたというのもあるけど、SQLが書けたというのはすごく大きい。昼休み、いつのまにか私はプロジェクトオイラーの問題に代わって、名著「SQLパズル」を解くのを日課としていた。
先輩は仲良くなる暇もなく、その後すぐにプロジェクトを移り、メーリングリストで寿退社を知った。炎上したプロジェクトは、なぜか横展開を経て今に至り、私は相変わらずここにいる。だが、あの時SQLの魔女がかけた呪いは今もしっかり私に根付いている。
そもそも、よくよくLinkedListクラスのインターフェースを眺めてみると、これは連結リストのノードを表現するクラスではなく、連結リストそのものを表現するクラスのようですね。こんなものをいくらネストしたところで多次元配列の構造しか作ることができないのは自明でした。現段階では、元記事の文章は不適切であると言わざるを得ません。
ところで、Lispの真似事をC/C++でさせたいのであれば、タプルを定義するのが先だと思いますが、いずれにしても教育カリキュラムや人材の選別過程でこのようなコードを組ませる方針は私はあまり感心しません。あれは一種のハックであって、木構造のアルゴリズムをコードで表現する際に必須の、本質的な概念ではないからです。仮に知らなくとも、それは「その人が育ってきた文化が違う」だけの話です。例えばB木を実装するにもRadix Treeの実装にしても知らないままで全く困らないでしょう。
ほかにも、計算量の評価に触れていないなど、気がかりな点はありますが、元増田氏からのコメントもないようですので、ひとまずこのへんで。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
http://d.hatena.ne.jp/RepsolFireBlade/20130220/1361332690
それだけ、PHPって流行っている言語で、この問題も注目されているってことなのね。まあ、言語としてPerlよりはマシだと思うね。ってか私Perl嫌いかも？しかしPHPにも型がないところが嫌いなんだけど。
世が世ならこの破壊力は大きかった。
C系の構文を採用する言語の中でPHPだけが左結合などという非常識な仕様を採用している。そもそもCを真似して作ったのに、ここだけ「間違えて」実装しちゃったとしか思えない。で、それを後から「仕様だ！」って言い張っているんだろうなぁ。大人げないねぇ。素直にバグだって認めれば良いのに。実装のバグじゃなくて仕様のバグね。言語仕様として「三項演算は左結合です。」って言ってしまえば、その実装は正しい。私が言っているのは、仕様のバグ。つまり、仕様です、そう決まってます、と言っていること自体が間違っている。どう考えたっておかしいでしょ？
普通、色々書けば書くほど説得力は増すのだけど、書けば書くほど説得力が抜けていく。
あっちこっちで、ネタにされていた中に「今さら言語仕様変えるなんて、後方互換性はどうなる？」なんてのがあったけど、そんな非常識なプログラミングは存在しないだろうから問題ないと思う。その前に、後方互換性って今や死語じゃない？
いずれにしても、昔のプログラムを救うことを考えるより、今後も続々と増えるであろう「C系の言語から入ってくる人」を救うことを考えるべきだね。
それじゃ、とりあえず読みやすいソースコードを残して頂けると大変助かります。
このおっさんがすべき事は、このおっさんがどんなネストを書いてしまったのか、そのPseudo Codeを晒すこと、ただそれだけ。
「泥の様に１０年」でしたっけ？w
とか思いながらどっぷり寝込んだ。１月ぶりによく寝たせいか、すっきりしているけど頭が痛い。（変な話だ）
３９度近い高熱で動けなくなって、ようやく休みが貰えた。
考えが甘すぎたと思う。というか社会に期待し過ぎていたのかもしれない。
入社して１年半。糞大学も糞なりにトップで卒業した。プログラミングは楽しかった。勉強は勉強という感じがしない。
実戦で通用しないのはわかっていた。だからこそ学べることに期待した。
地方にとどまったのが間違えだったのかもしれない。
とんでもなくネストの深いループや分岐(クラス使えや。せめてメソッドに分けろや)
ソース内にある変更履歴（え、バージョン管理使ってますよね？）
意味不明な継承関係の社内ライブラリ（そもそもクラスをまともに使っていないし論外）
業務アプリを作るのだ。厳密さが求められ、仕様変更が常にあると聞いていた（そして実際常にあった）この世界であり得ない状態だった。
そしてこれが評価されている(どうも一番優秀な人が書いたコードらしい)
何より驚いたのは、彼らの無勉強さだった。
常に２件が燃え上がっている状況になっても、彼らはまだ気づかない。
驚いたのは、技術の重要性を認識していたのが営業部長だということだ。（本当に出来る人だし、見える人には見えるという事なのかもしれない）
「プライベートで学んで転職を」と思ったが、そもそも睡眠時間を確保するのもやっとなのに、そんな事できる訳もなかった。
もうこの世界は降りた方がいいのかもしれない。
独学でも好きなプログラムは作れる。残業代も出ないのだから、時給800円のフリーターの方が収益が良いくらいなのだ。
社長のご立派な会議の議題はiphone5が発売になることだった。
自社の強みを生かしながらスマートフォンアプリにも対応していくのが我が社のやり方だそうだ。
この業界は上位5%以外は不要だ。残りの95%は職を失うが、どうせ過半数は１０年持たない。
泥の様に働く方も、働かせる方も、もう１０年も持たないと、本当にそう思う。
数百行、果ては数千行もある関数やメソッドが何故生まれるのか、どうしても理解できない。それ仕様の通りに動かそうと思ったら、テストもデバッグもライフワークになるよね？それとも未完成でも納品するってこと？もしかしたら「勝手に関数/メソッド作るな」司令が出てるのかもしれないけど、だったら「できません」と断ったほうが絶対楽だと思うぞ。あ、楽といえばこういうコードのレビューは楽だよ、「長すぎて読めない、書き直し」で終わるから。
条件分岐やループを何重にもネストしたコード。スクロールさせるとうねって見える。それさ、正常系の処理だとして一番最後の行の直前はどこ通るの？即答できないなら書き直せ。即答できても「こういう複雑なコードを書けるのがプロ」とか誇らしげな表情しちゃう人はただの勘違いバカだから、その姿勢改めるまで可愛がられるかサクッと見捨てられるかでしょう。
ANDやORが入り組みまくった条件式だけどさ、お前一体何がしたいの？それ多分お前しか理解できないから、システムがEOLになるまで面倒見てあげてね。
「1からnまでの総和」とか、公式がありそうなものをロクに調べもせず、n回ループする方法しか思いつきませんでした的に書いたコード。そんなバカ丸出しの実装で恥ずかしくないの？バカはプログラマに向いてません。それは前述の勘違いバカもそうだけど、頭を捻るセンスが無いのも致命的。
閏年を始めとする日付の計算アルゴリズムとか、標準提供されていそうなものまで手で実装したコード。お前それ辛くないか？てかマニュアルやヘルプはちゃんと読もう、な？
なんで同じコードをコピペするの？共通ルーチン作らなくてもgrepで直して回れば修正漏れも起きないって魂胆？同じ処理が出てくるたびに読んでてうんざりしてくる人も少なからずいることを理解して仕事してください。頼むよ。
DBのテーブルから全レコード取得して、必要なデータか判定して処理するコード。WHERE句って知ってる？データが数億件とかあってもそれでいいと思ってる？
その処理は本当にコードで書かないとダメなの？書かないで済みそうなことまで何故書くの？書かなきゃいけないとして、どうやって短く書くか工夫しないの？コードが増えただけバグも増えることを、もっと深刻に受け止めて欲しい。
最後にコードじゃないけど、巨大なディスプレイに高解像度で極小フォントという環境で開発ってどうなのよ。そこまでしてコード全部表示しないと書けないんだ？今まさに書いている部分なんて、変数もアルゴリズムも自分の頭の中にあるんだから画面に表示する必要なくね？確かに開発用のディスプレイは大きいものが複数あったほうがいいけど、それらはそういう使い方をするためにあるものじゃないと思うぞ。
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
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
レスが遅れてすいません。
ううむ。理系と文系の対立みたいな残念な方向に流れてきてしまいました。仕掛けたのは私のほうかもしれませんが。
京都弁？なのは一向にかまいませんが、大元の記事よりもレトリックが雑になってきているようです。
最初はそれなりにいい線いっていたのに、ここにきてもう投げやりというか、反論のための反論というか、急速に劣化ウランしてます。
オウム真理教の信者は人間。燃料棒はモノです。人間相手なら断罪するのは慎重さが必要だと思いますが、燃料棒相手にそこまで遠慮する必要はないでしょう。あそこで遠慮したことで、「メルトダウン隠蔽説」の発生という大損をしたわけです。これは表現の細部の問題で、後でいいますが、こういうのが信頼を作りだすにあたって重要なんです。
（本論と直接関係ありませんがオウム事件のくだり「化学薬品が大量に見つかった時点でもうほぼ真っ黒」という発言は気になりますね。そうやって河野さん一家も冤罪で酷い目に遭いました。人間相手にはくれぐれも慎重に頼みますよ。モノ相手はバッサリやっちゃってください。）
反原発派が物理的限界を超えて放射能が拡散する可能性を語ったせいで「だまされた」ことを批判されていましたが、今度は、逆に、物理的限界を超えて炉心の水位が保持されなかったことについては、裏付けが取れるまで断定しないことを良とする。せっかく「物理的限界」についてのあなたのロジックをもとに議論を展開しているのにスルッとかわされてしましました。なんともやりきれません。
「あいつらの中に悪い奴おるんちゃうか、だからあいつら悪い奴や」とは言っていません。「推進派が嘘をつきましたか？否。」と言いきるのは極端ということです。この点はあまり突っ込みたくなかったので、控えめに「かもしれない」で終わらせたつもりですが、もっとハッキリ言わせていただくならば、九電が今回やったことっていうのも、ウソじゃないんですか。流通していないから大丈夫って、今になってセシウム基準値オーバーの牛だって流通したことが出てきたじゃないですか。あれもウソじゃないんですか。と言いたい。それが意図的かどうかとか、実害があるないかないかは関係ないんですよ。あの船場吉兆だって、あんなの食っても到底死にませんよ。でも信頼失ったらオワコンになるんです。信頼というのはそういうもんです。推進派は、そこがまるでわかっていないんです。かわいそうなくらい。だから原発を自動車と比較したり、死者の数を出して、どうだ安全だろといったりするんです。ずっとこの調子なんですから。そんな議論で到底信頼は得られませんよ。
誤解のないように言っておきますが、わたしは原子力だけを特別扱いしているわけではありません。たとえば、メキシコ湾を汚染した油田だってああいう事故起こすのは許されません。自動車だって、免許は持っていますが、自分は下手くそなので（制御できる自信がないので）運転はしません。
広瀬隆の著作が「だまされようがありません」というのは、（あなたレベルなら）だまされようがないということです。
まあ、一読をお勧めしますね。賛否はともかく、それなりに楽しめると思いますから。私にしても全部同意するほど無批判な読み方はしていません。
「原子炉時限爆弾」の冒頭で出てくるのは、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は個々人のスタイルを反映してるということでしかないんじゃないの」
「そうですね」