 
|
はてなキーワード: バッドノウハウとは
プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070502200124
phpのいやなところ / perlのいやなところ http://anond.hatelabo.jp/20070522174725
LL編プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070503000905
1年くらい前にKENTWEBでCGIを覚えた私はどれくらい時代にとり残されているんだろう http://anond.hatelabo.jp/20070427114039
PHPで自称ギークとかアホか。 http://anond.hatelabo.jp/20080527201030
文系の大学出身の人が気軽にプログラマになることはお勧めしません。 http://anond.hatelabo.jp/20080830010043
[Perl][PHP][Python][Ruby] 無題 http://anond.hatelabo.jp/20080731154801
プログラミング始めてみた(笑) http://anond.hatelabo.jp/20080201185253
日本が誇るスゴ腕geekの紹介 http://anond.hatelabo.jp/20090102145542
PHPの比較の素晴らしさ加減は正常 http://anond.hatelabo.jp/20090617130518
言語による分野の住み分けがすでにできてるんだよ http://anond.hatelabo.jp/20110220120714
なぜJavaの求人が多いのか考えよう。 http://anond.hatelabo.jp/20110220101806
LL言語が後退局面に差し掛かっている件 http://anond.hatelabo.jp/20110210084023
これからweb開発に携わりたいと考えている人にお勧めの言語 http://beta.anond.hatelabo.jp/20110220013933
※はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ http://anond.hatelabo.jp/20100827202157
pタグやdivタグのclass要素を指定できるのでHTMLでそのまま記述する。
いつくかはてなダイアリーでの使用可能なはてな記法は無効になっており、例えばキーワードリンク無効記法が使えないためフォントカラーが キーワードリンクの黒に潰されちゃうかんじ。
以下サンプル。アルファベットはクラス名(自動アンカーついていててコピペしにくい。ソースみたほうがいいかも)。
a.keywordcloud10 を空白で刻むことによってうざいかんじになる。荒し用。
いやあ、まあ、崇高かどうかはあれだけど。
const char *hello = "hello world"; puts(hello + 1);
これで "Hello world" でなく "ello world" が表示されたとしたら、その理由が理解できるだろうか。
俺は理解できる。それがそこらの一般人との違いで、その能力を仕事でも使うから、その分の金が欲しい。なぜ、何の技能もない一般人と同じ給与水準なのかと。
俺が一番興味あるのはそこ。簡単でそ。
あと、仕事に「やりがい」なんぞを求めるのは昭和までだよねー。仕事は生存のためのツールの一つにすぎない。なんとかして仕事から解放されるべきだが、しかし現状では仕方の無い「バッドノウハウ」だ。
webプログラミングは、作ろうと思えば簡単なものが低いスキルでもすぐにできてしまう
でも実際に仕事でやる場合には覚えなきゃいけないノウハウが多い
なので、自分で勉強するよりも、知ってる人に教えてもらってやっていった方がいい
とくにPHPはヤバイ
バッドノウハウ多いし、プロジェクトによって作り方が全然違うと思う
Javaをやるんだったら、基本情報なんかの資格のための勉強としてやればいい
そうしたら就職しろ
基礎さえできちゃえば、言語による違いなんて方言みたいなもんだから
会社に入ってから覚えることの方が多いだろうし、スキルの上がるスピードも違うよ
だって仕事中は本当にそれだけに集中するし、やりたくないことをやらなきゃいけないし、
バッドノウハウってのはかっこつけた単語じゃなくて、奥が深い症候群を戒めた語だよ。
自分が知ってる「業界の雰囲気」ってのが偏ったものだと知覚した方がいい。
それが相応しい職務でもないのに「C++が使われることが多い」なら、そのプロダクトの仕切りをした人間は適切な道具を選べてないことになる。
プログラムをあくまで道具だと言うなら、道具の選択が出来るようになった方がいい。
あと周りがバカばっかりに見えるなら、そうじゃない場所を見に行った方がいいぞ。スポイルされてもいいこと無いし。勉強会とかに顔出してみ。
バッドノウハウ…！
これですよ。こういうのがマジウザい。
何がバッドノウハウだよただ仕様が終わってるだけじゃねーかカスが！って思う。
ああいうクソ仕様素晴らしい仕様をいかに使いこなすかがプロ！みたいな業界の雰囲気にヘドが出るぜ。
PHPは使ったこと無いけど、元増田のエントリ見ればどれだけクソか素晴らしいかは想像に難くない。
まー実際問題C++が使われることが多いからさ。業務系とかは違うのかもしれないけど（かといって組み込みとかやってるわけでもないけど）。
C++は時々意味不明な挙動をすること以外はまだマシだけど、Cとかもうできることなら二度と書きたくないね。
オブジェクト指向じゃない時点で書く気がしないってのもある。
まー俺にとってはプログラムなんてあくまで道具に過ぎないんですよ。
うっひょおおおおおおおおおプログラミングマジ楽しいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗっうううううううえわえｗｗｗｗｗｗｗっわあああふぁｓふぁ
みたいな人たちには勝てる気がしないしその気持ちも全く理解できないから同じ土俵に上がるつもりはない。
プログラミングスキルの上に構築される専門性（間違ってもプロマネ力とかコンサル力とかのことではない）で食っていけるようになるべく頑張っている。
C/C++はCPU依存性を減らしたアセンブラで、面倒くささを耐える代わりに速度を稼ぐという特殊用途言語なんだから、「プログラミングは面倒だ」の例としては局所的すぎるなー。大量のバッドノウハウを楽しんで乗りこなすマニアどもが、ゲームや組み込みや検索エンジンあたりの開発に使うプロ向けの道具で、間違っても「プログラミングの細かいところが嫌い」なんていうライトなプログラマが使うようなものじゃない。
もっとチャラい言語使いなよ。RubyとかActionScriptとか。よりによってPHP/C/C++とか選択がマゾヒスティック過ぎ。仕事だか学生の課題だかで無理矢理使わされてるの?
関数ポインタがバッドノウハウ的であるような根拠があれば納得できるんだけど。
オブジェクト指向だってバッドノウハウじゃない？ツリーの途中で指摘されてなかった？ 昨日からお前vtable言いたいだけちゃうんかと。
概念的にも実装にしても関数渡しで済むところをそんな間接的にクラス定義して継承して実装して…なんてのはどうみても間接的でコードの可読性を損なう。現状C++ではそれがイディオムとなっているけれど、ああいうのこそバッドノウハウだ。
じゃぁ、何がグッドノウハウかというとC++の継承、メンバ関数、Virtual関数
C++の継承やVirtual関数は中身はvtableでvtableって何のこと？っていうと
アセンブラがCALL命令
C++ではそれをうまくオブジェクト指向の継承という概念に持ち込んでいる。
ほとんど使われていないけど、いちおう、クラスのメンバ関数の関数ポインタという概念や
スタティック（メンバ）関数の中に素の関数ポインタは残ってはいる
だから、今でも関数ポインタを使うのは 本当に１部の残された領域と
高速化のために継承じゃ追いつかない所をハンドメイドで書くぐらいだと思う。
インタプリタのメンバ関数呼び出しとVtableによるメンバ関数呼び出しは
見かけは同じように見えても、（実行速度とか含め）全く別物だからという注釈は書いておこうかなと。
うーん。
K&Rでも「5.11関数へのポインタ」で触れられてるのはqsortの話だし、そこで「関数へのポインタを定義できるよ」とはある。個人的にこれは意図していないけど載ってることだとは思ってた。だからこの使い方が当初から意図されているかどうかと言うと、現場側のフィードバックだと思うんだけどなあ。
でも、もしも僕の言うようにバッドノウハウだったとしても、仕様に取り込まれた時点で意図されてることになるのかなあ。現時点でバッドノウハウだったっていうのは言い過ぎか。
この辺のデバッグのしづらさとかこんらんっぷりで良い思い出が無いから言いすぎてたかも。ごめんなさい。
んー。この辺の関数へのポインタを定義できることの応用のどこからがバッドノウハウで、どこまでが普通の使い方ってのは切り分け出来ないし、切り分けてもそれほど意味は無いか。
例示された 5つ が 動的コード操作のことを指しているのなら、そりゃバッドノウハウかもね。
これだけ世界に普及しているC言語のプログラミングスタイルを云々できるかどうだかは知らないけど、設計次第では普通にあり得るよね？
というか qsortって標準ライブラリだし 始めから意図されて作られていると思うよ。
高階な概念はそこらにある。
例えばあまりに定型的なツリーの操作を10個書くときに、 ツリーのトラバース1つ＋関数ポインタ10個を使うのは 普通のテクニックだと思う。
qsortと同じだよ。
まあでも…どうなんだろう。「クロージャがない言語のくせにムリヤリ関数を使おうとしたときのバッドノウハウ」とは言えなくもない。
関数ポインタで、例示された５つを実現するのはバッドノウハウじゃないの？
「関数ポインタを使ってプログラミングしましょう」というプログラミングスタイルは、正統派ではないと思う、んだけれども。
帰省中で手元にはK&Rしかないけど、関数ポインタを使って何かを成そうってのは載ってないよ。関数ポインタがあること、それを使うとどんなことが出来そうかは判るけれども。
なんちゃら抽象が一般的かどうかと、C言語はなんちゃら抽象を使えるかどうかと、C言語はなんちゃら抽象を使うことが前提となる言語である、というのはそれぞれ違う命題だと思うけれども。なんちゃら抽象をC言語で実現しようとすると関数ポインタで素直に表現できるということと、それがバッドノウハウかどうかも独立の命題だと思うよ。（美しい設計、どういう設計の言語仕様が良いかというのは、さらにまた別の問題では）
そういうのはバッドノウハウとは言わないの？
関数ポインタをバッドノウハウとは言わないでしょ。C言語自体がバッドノウハウの結果だと言うなら、当たりだけど:)
手続き関数という抽象はまことに一般的な存在で（数学では汎関数というのもある）、それをC言語で直接的に表現したのが関数ポインタ。 関数的なものを オブジェクト指向言語でオブジェクトとして実装するほうがバッドノウハウだと思う。 少なくとも私は JavaのComparableインタフェースよりも C言語の heapsort/mergesort/qsort の関数引数 int (*compar)(const void *, const void *) のほうがシンプルで どちらかといえば本質をよりよく表していると思う。 なぜ関数的なものを表現するのに オブジェクトとかinterfaceとか継承とか「余計な概念」を導入する？それこそバッドノウハウでしょ。 まあでもC言語にはクロージャが無いから、関数的なものも扱いづらいことこの上ないが、Cにクロージャが無いこと自体はバッドノウハウとは言わないでしょー。
逆も然りで、オブジェクトを表現するために 関数を使ってれば そればバッドノウハウだけど、オブジェクトは関数ほど一般的な概念ではないと思う（オブジェクトなんか無くても別にいい、かも？）。
そういうのはバッドノウハウとは言わないの？（「本来想定されていない使い方をするために、工夫してできるようにしちゃうノウハウ」を指してバッドノウハウと言うんだと思ってたから違うのかもしれないけど:-P）よく使うから正統派の使い方ってことにはならんと思うけど。
たとえば、「getとかstrcatとかstrcpyは危険だから今はstrncat,strncpyを使うようになった」ってのとは違うんでない？
変則的なノウハウが現場で多用されてたし便利に使われていたけれども問題があるし代替手段ができたから今は違う方法を使ってるってのと、そもそも想定してた使い方だけどうっかり使うと危険だから今は違う方法を使ってるってのは、違わないかい？
（その辺がぐちゃぐちゃしてて仕様に取り込まれたりしてるのがCの魅力と言えなくも無いけど）
関数ポインタはバッドノウハウどころか、手続き的な抽象を使いたいところで多用しますぜ。超重要。 そして関数型プログラミング言語の存在意義みたいなもん。
C++やオブジェクト指向言語だと 継承と仮想関数を使うけど、同じようなケースで C言語では関数ポインタを使うんすよ。
先にもかいたけど、ソートの比較関数とか、スレッドの開始とか、コールバックとか。
で、変数ポインタと関数ポインタの曖昧性(?) の件は、 私は重箱の隅をつつき過ぎたが…
要するに、 (例えば) x86の機械語に対応するデータを生成して、その先頭アドレスを関数ポインタにぶち込んで実行するという手法。
1. は、もう使われてない。 2. みたいな利点はある。3.4.みたいな例があるために現在では扱いづらいかも? 5. みたいな使い方がしたければ…悪い事は言わない、evalがあるRubyPythonLispSchemeあたりを使っとけ。 って感じっす
# またトラバ先を間違えた。
最初期の増田っす。
そもそも関数ポインタって、最近流行の言葉(笑)で言えばバッドノウハウだから、別に細かいこと良いんじゃないの？
関数呼び出しってのも「式」にしちゃうとコンパイラ書くの楽で、式だから値が必要で、値を返すには「値を返す関数へのポインタ」である必要があるという。
その辺のメモリ・アドレス・アドレスを保持する変数（ポインタ）を理解するのは、今後のプログラミングライフをよりよいものにするんではないかという。
いろんな理由があって「そりゃやっぱ普通に考えてよくないよなあ」っていろんな人がいろんな理由でいろんな解決策をもりもり出した結果よく判らないことに（まだ）なってるわけだし。
大概でいえば、それが有効である事は多いでしょう。
ですが、それだけでは足りないこともあるし、何を読むかが重要だし、「プログラミング初心者」の種類にもよる、という但し書きも必要だと思います。
そうすると、プログラミング初心者はサンプルコードがしっかり載ったリファレンスを片手に何か一つの言語で作られたオープンソースのソースコードを読んで学習するのがいいのかな？
というのも、単語（関数、ステートメント、ライブラリ、etc.）を文脈で覚えるには、文脈を理解しなければならないが、文脈を理解するためには知識が必要だから。そして、知識を得るには単語を知らないと難しい。
何も知らない状態ならば、まずは単文複文、変数、ステートメント、構造化プログラミングetc. と、言語で使用される概念を理解しなければならない。それが基礎から応用へ向かうにつれ、単語量が増え、記憶すべき事柄が増える。そしてついには、バッドノウハウ、歴史的理由、処理系依存などが出てくる。それらは必要とされるから存在する。その、必要とされる理由、必要とされる文脈を理解することが、それを応用するために必要なことだ。応用力、それは記憶と理解のバランスだ。
リファレンスとサンプルコードと実働コードを用いる手法の目的は、リファレンスで意味を、サンプルコードで小さな文脈での使用例を、実際の使用例でさらに大きな/多様な文脈での実例を、それぞれ得ていくことにある。それには、それぞれの文脈が理解できるという前提があり、今の知識・語彙で理解できるソースコードを選択しなければならない、ということである。しかし、どのようなソースコードを読めば一番効率が良いか、という問題は非常に難しい。また、実在するコードを読むもう一つの理由が、モチベーションの維持にある。しかし、これがまた難しい。難解な方が燃える人もいれば、簡易なほうが良い人もいる。また、コーディングルールや手法の違いを学ぶために、数をこなすことも有用だろう。しかし、そのためのモチベーションを維持するのは大変である。
なんにせよ、そういった、自分にあったお手本となるソースコードなど、初心者には選べるはずはなく、そういう意味で初心者にはお勧めできないかもしれない。いや、もしかすると、どこかの増田が「初心者が読むべき10のコード」とか書いてくれるかもしれないが、個人的には運命の出会いかとも思う。普段愛用しているツールに機能追加したくなって、ソースコードを読んで行くうちに覚えたとか。
と、いう謳い文句にそそのかされてRubyとRuby on Railsをインストールして、説明通りにセットしてみた。動きゃしねぇ。調べてみると、バージョンが変わっているのでデフォルトのDBが違うらしい。あと、環境プログラムのGEMも微妙に動きが変で、今は「ワンクリックで動く便利なインストーラー」があるのだとか。試してみる。なぜか「gemが古い」と言い出す。指示通りアップデート。
で、もう一度紹介されていたサンプルを組んでみるが、scaffoldという呪文を、メソッド実行時に受け付けてくれずloadErrorが出る。検索して、コマンドラインからscaffoldを生成してみたが、今度はエラーを吐いた後、サーバーすら立ち上がらなくなった。
Ruby使えねぇ。などとは言わない。「簡単に使えるというのはマーケティング上の嘘で、トラブルを回避するためのバッドノウハウをたくさん勉強しなければならないらしい」という、至極あたりまえな、うすうす予想していた結果。
Perfume の FIRST TOUR -GAME- が無事に終了した。
http://natalie.mu/news/show/id/7465
ツアーの余韻を iTunes/iPod で楽しむためのプレイリストを考えてみたのでまとめてみる。
iTunes 7.3 for Windows + iPod 4G（どちらも古い！）で試したものなので、
最新版の iTunes + iPod では動作が違うかもしれない。
もうすでに同じようなことを考えている人がたくさんいそうだし、
もっといい方法や簡単な方法もあるかもしれないので、その場合は指摘していただきたい。
自分が観た公演のプレイリストを作るのは簡単だが、できればルーレットのドキドキ感も再現したい。
「iTunes/iPod にはスマートプレイリストがあるから簡単にできるんじゃないか？」と思ったのだが、
試してみると以下の理由で意外と簡単には出来なかった…。
そんな中、なんとか試行錯誤して出来たのが以下の方法である。
今のところ、2 種類の方法を考えた。どちらも現時点では期待通り動作する。
普通のプレイリスト。以下のように上述セットリストの「固定部1」を含むようにする。
以下の条件で作成する。
iTunes だけで聴くのであれば、普通のプレイリストで構わないのだが、
なぜか手持ちの iPod ではうまく動かなかったので、回避策としてスマートプレイリストにした。
なお、あらかじめ wonder2 が含まれる複数の CD （エレクトロワールドと Complete Best）を
インポートしておく必要がある。
このプレイリストが実際に選択して再生するプレイリストとなる。
以下の条件で作成。
これだけでは「GAME TOUR」を選択しても、曲順はでたらめになってしまう。
したがって、一曲ずつコメント属性にソートのための文字列を入れる。
全楽曲のコメント属性にソート順を入力したら、「GAME TOUR」を選択して、
「表示」メニューの「表示オプション」で「コメント」を表示するように設定、
楽曲一覧の「コメント」列をクリックしてコメント属性でソートされるようにする。
これで「GAME TOUR」を再生するたびにルーレット曲が変わるはず。
ただし、スマートプレイリスト「GAME02」の条件で指定したように、
昨日再生した曲は再生されないけれどもそれはまあご愛嬌ということで…。
実現方法その 1（コメント属性を使う方法）の（将来的な）問題点は
ツアーごとにソートに使う属性が足りなくなってしまうことである。
だから、ツアーごとに楽曲そのものをコピーしてしまえば解決する。
エクスプローラや Finder で「Album GAME TOUR」のようなフォルダを作成して、
ツアーの楽曲ファイルを全てそこにコピーし、iTunes からライブラリに追加。
そうすると、すでに存在するアルバムの楽曲とだぶって登録されてしまうので、
先ほど追加した楽曲を選択して、アルバム名を「Album GAME TOUR」に変更する。
さらにこの時点でセットリストの曲順をトラック番号属性に設定しておく。
※ルーレット候補曲はもちろん全て同じ「18」に設定しておく。
あとはアルバム「Album GAME TOUR」から曲をえらんで、実現方法その 1と同じ要領でプレイリストを作成。
ただし、スマートプレイリスト「GAME TOUR」のソート順はコメント属性ではなくトラック番号にしておく。
どちらの方法でも GAME ツアー再現気分は味わえるのだが、
どちらにしても問題点があり、いささかバッドノウハウ的である。
今のところコメント属性を何も使っていないのであれば前者の方がお手軽だろう。
今後もルーレットをやるかどうかは分からないし。
ここまで来るともっと再現度を高めたくなるかもしれない。
その場合はこんなのはいかがだろう？
開演前に流れていた曲を入れて、わざと焦らされるのもいいかもしれない。
私の場合：何曲も入れると待ちきれないので、一曲だけ入れてある。
ライブにしかないもの、iTunes/iPod で一番足りないのは、もちろん「MC」。
こればっかりはどうしようもないのだけれど、どうしてもがんばるなら…。
これは試してないので誰か試したら感想を聞かせていただきたい。
セットリストや客入れの楽曲は Perfume スレとまとめサイトを参考にさせていただきました。
説明下手で読みにくいエントリですが、打たれ弱いので dis らないでください…。
間違いや要追記事項は指摘していただけたら更新いたします。
何言ってんだよ。理系は科学的思考を重視し物事の本質をよく捉え、プログラマは論理的思考を重視する。彼らの判断は文系や非プログラマのそれに比べて論理的で正しい。アルファなんちゃらって人達が言ってるんだから間違いないじゃないか。
真面目な話、プログラマの世界で本質的に新しいものを開拓出来ている人は少なくて、20年前や30年前の研究成果を再実装している人が大半だ。俺もそう。
みんなだいすきダンコーガイだって、ギークと呼ばれる人々の中では「卓越したプログラミング能力を持つ人」ではない。Perlコミュニティで十分な人脈があり、英語が十分に使えて、エンコーディングの仕様に関する必要十分な知識があり、必要十分程度のプログラミング能力があり、上記条件を比較的黎明期に満たしていた。そのような人物はもちろん少なくてだからダンコーガイはそれなりに代え難い人物であることは否定の余地はないのだが。
プログラマの世界は世間で思われているよりはずっと権威主義的で属人的。モノよりも人を見る。20年や30年でできた伝統はそんなに変えない。本質同じでインターフェースが微妙に変わっただけのものをみんなでワイワイ弄ったりする。普通にミーハーな生き物だ。信じられないような変態的な頭脳の持ち主もいるにはいるが、変態は評価されにくいので表舞台にはそうそう出てこない。成功してから後付けで評価されるものだ。方向性が違うだけでプログラマだって普通に人間的特性は備えまくっている。
一旦「人だけ見て判断して貰える」立場になれば強いので、何だかんだでその方向性で有利になるように動くことも多い。本題に関係なく適用できるメタ論理や、相手の言い分を読まないか誤読して相手を自分に有利な形で再定義してからDISるとか、そういう「プログラマがよくやるダメダメな議論」もプログラマ社会的には重要だったりもする。細かい手法についてはここでは述べないが、論理は正しい必要はなく、バカから正しく見えて発言力が強くなれば良い、ということが重要になってしまうような普通の人間社会だ。
Webは便利だが、技術的に見ると大して革新的ではない。泥縄もいいところ。
インターネット自体、仕様が決まった当時の先見の明に感服する部分も多いのだが、どう見ても老害という仕様も山ほどある。おかげでクソみたいなバッドノウハウが次から次へと生まれてくる。
たぶん、かなりのプログラマは、何だかんだであまり革新的でもないことを自覚していて、それどころかクソみたいな伝統とバッドノウハウに辟易させられている。バッドノウハウをありがたく貯め込んで「奥が深い」とか言ってる無邪気な奴も多くはあろうが。この辺も他の社会と変わらない。
というわけで元増田よ。プログラマは普通の人間だし、Webだって今となっては革新的でも何でもない。そんなに捻くれなくていいよ。
これは革新的!!知らないで許されるのは小学生まで!!時代は変わりました!!時代は変わりました!!使わないとお前らは死にます!!みたいに言ってる連中は、それがビジネスだからほっとけ。その周辺に群がっているのはただのミーハーだからほっとけ。