 
|
はてなキーワード: hogeとは
増田でこんなこと聞いていいのかわからないけど、誰かわかる人教えて欲しい。
seasarの公式サイトにある、s2jdbcのチュートリアルを試してみたんだけど、entityの生成でいきなり躓いてしまった。
$ ant -f s2jdbc-gen-build.xml gen-entity Buildfile: /Users/hoge/dev/s2jdbc-tutorial/s2jdbc-gen-build.xml gen-entity: [gen-entity] Java Result: 1 BUILD FAILED /Users/hoge/dev/s2jdbc-tutorial/s2jdbc-gen-build.xml:46: Exception in thread "main" java.lang.NoClassDefFoundError: Caused by: java.lang.ClassNotFoundException: at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
動かしている環境は
- java version "1.6.0_29"
- Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
- Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
s2jdbc-gen-build.xml:46 っていうのが、classpathに関する記述の箇所なので、動かすのに必要なjarが読み込まれていないからなんだろうなぁ、って思ってるんだけど。
同じ現象で躓いて、うまく解決できた人がいたら、教えて欲しい。
38 <target name="gen-entity"> 39 <gen-entity 40 rootpackagename="${rootpackagename}" 41 entitypackagename="${entitypackagename}" 42 javafiledestdir="${javafiledestdir}" 43 javafileencoding="${javafileencoding}" 44 env="${env}" 45 jdbcmanagername="${jdbcmanagername}" 46 classpathref="classpath"> 47 <jvmarg value="${vmarg.encoding}"/>
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
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
こんにちは、技術恋愛戦略学を専攻しているユビキタス嬢です。私は学歴もスキルもありませんし偽装請負ですが、情報系の恋愛に関してはプロフェッショナル。今回は、モテる情報系女子力を磨くための4つの心得を皆さんにお教えしたいと思います。
1. あえて2～3世代前の開発言語のスキルを履歴書に書いて行く
あえて2～3世代前の言語を使うようにしましょう。そして会社のマッチング面談で好みの人事がいたら話しかけ、わざとらしくラップトップを出していじってみましょう。そして「あ～ん！ このC○B○L本当にマジでチョームカつくんですけどぉぉお～！」と言って、人事に「どうしたの？」と言わせましょう。言わせたらもう大成功。「オブジェクト志向開発とか詳しくなくてぇ～！ ずっとコレ使ってるんですけどぉ～！ 使いにくいんですぅ～！ぷんぷくり～ん（怒）」と言いましょう。だいたいの人事は新しい開発案件に流したがる習性があるので、古かったとしても1世代前の案件を担当しているはずです。
そこで男が「新しいスキルがほしくないの？」と言ってくるはず（言ってこない空気が読めない人事はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！ 最近C# 5.0が人気なんでしょー!? あれってどうなんですかぁ？ 新しいスキル学びたいんですけどわかんなぁぁああい!! 私かわいそーなコ★」と返します。すると男は「C# 4.0でしょ？ 5.0はまだ仕様も決まってないよ。本当に良くわからないみたいだね。どんなスキルが欲しいの？」という話になって、次の営業日にふたりで案件選びのデートに行けるというわけです。あなたの女子力が高ければ、人事が優良案件を紹介してくれるかも!?
「var」とか「temp」などを表現する「hoge」をコードに入れると、コードレビュワーの男性SEは「なんかこの子カワイイなぁ」や「指導してあげたいかも」と思ってくれます。コード管理ツール上では現実世界よりもイメージが増幅されて相手に伝わるので 「hoge」を多用することによって、男性はあなたを可憐で女の子らしいと勘違いしてくれるのです。そういうキャラクターにするとほぼ絶対に同僚プログラマに嫌われますが気にしないようにしましょう。
3. とりあえず営業には「えー！ なにそれ!? 知りたい知りたーい♪」と言っておく
ミーティングなどで営業がSE・プログラマに話すことといえば予算話や納期の話ばかり。よって、プログラマにとってどうにもならない話ばかりです。でもそこで適当に「へぇー検収間に合うんですかぁ～？」とか「よくわかんないですけど予算超過しそうですねぇ」と返してしまうと、さすがの営業も「このプログラマダメだな」と気がついてしまいます。ダメプログラマだとバレたら終わりです。そこは無意味にテンションをあげて、「えー！ なにその業務要件!? 知りたい知りたーい♪」と言っておくのが正解。たとえ理解できない仕様でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に営業は弱いのです。
いろいろと話を聞いたあと、「〇〇は〇〇扱いで、〇〇が〇〇になるバグは見なかったことにするんですね！ 忘れたぞぉ！ メモ廃棄！コメント削除！」と該当コードをコメントアウトすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン！ キュンキュンキュン！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「私のバグ発生履歴マスタからレコードを物理デリートしているのでありますっ☆」と言えば女子力アップ！ そこでまたマネージャーは「この子おもしろくて使えるかも!?」と思ってくれます。私は学歴もスキルもありません偽装請負ですが、こういうテクニックを使えば知識がない私のようなバカ女のほうがモテたりするのです。マネージャーは自己保身に走りたいですからね。
客先担当者の男とレストランに入ったら、真っ先にATMなどの銀行系SIerを使ったシステムを探して「あーん！ 私これ使えないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「どうして？ キャッシュカード持ってないの？」と聞かれるので、「カード持ってるし使いたいけど使えないんですっ＞＜」と返答しましょう。ここでまた100パーセント「カードがあるのにどうして使えないの？」と聞かれるので、うつむいて3～5秒ほど間をおいてからボソッとこう言います。「……だって、……だって、ATM使ったらエンジニアが死んじゃうじゃないですかぁっ！ 孫請けプログラマかわいそうですぅ！ まだ有給とってないのにぃぃ～（悲）。労災すら降りないんですよ……」と身を震わせて言うのです。
その瞬間、あなたの女子力がアップします。きっと男は「なんて優しい労働基準監督官のようなコなんだろう！ 絶対にゲットしてやるぞ！ コイツはうちの担当SEだ！」と心のなかで誓い、あなたに惚れ込むはずです。意中の会社を担当することになったら、そんなことは忘れて好きなだけATMを使って大丈夫です。「使えないんじゃなかったっけ？」と言われたら「大丈夫になった」とか「もみ消した」、「そんなこと都市伝説です」と言っておけばOKです。
横だけど、元エントリに反応した側ははてな記法が使いづらいかに興味はなくて、増田とダイアリーの仕様の違いに興味があるってだけでしょ
確かにそこは本題ではないけど、書かれた内容のどこに反応するかは自由だべ
もちろんさらに元増田が「そこに反応してほしいんじゃねーヨ」みたいに返すのも自由なんだけど、キレ気味なのは相当みっともないよ
はてな記法がわかりにくいなら別に使わなくてもいいよ
箇条書きはがんばって＞＜ul＞＜li＞hoge＜li＞fuga＜/ul＞＜とか書いたらいいよ
p要素は内容にブロック要素を含めてはいけないから、ブロック要素のタグを書くときはpタグが自動挿入されないよう＞〜＜で囲むのが大事だよ
まあはてな記法は別に難しくないと思っているから、これでわかりづらいってだいぶアレですねと思うのも確かではある
===それはそれとして===
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.Y.HEAD』という曲の歌い出しですけど、最近この部分がぐるぐるぐるぐると頭を回るものだよ。
ええ、わかってますよ。仕事相手の悪口を公的な場で言うなんて、問題があるって言うんでしょう。まあ、それもそうなんだけど、たいしたプログラムも書けないくせにプログラマー名乗ってる奴らに本当に腹が立つからせいぜい堂々と書きますよ。
「忙しくってコードの質が下がってる」っていうような事情もあるでしょうが、まともに納品が出来ないなら仕事なら受けるべきでないわけだし、ビジネスの世界は「結果責任」を負うものですから、「事情」なんてのは知ったこっちゃないね！
……っていうふうにね、「仕事」というのは基本的に「事情」を無視するものなんですね。だから基本的にはあんまり僕は「仕事」が好きじゃない。とはいえ、今いっしょに働いている人たちはかなり「事情」というものを意識していて、おかげでそれほど辛くはないんだけれども。ただ「ほかのプログラマー」みたいな、外部の人たちは、事情を共有することができないので、「あー！ クズみたいなコード送ってきやがって！」ということにしかならない。「事情」を共有できるような、近しい距離の人たちとのみ、仕事をしていたいものですよ。
で、そのコードがどういうふうにダメなのかというと、主に2つの側面がある。
【１】文法が正しくない、プログラムが読みづらい
【１】はもう、そのまんま。文法がおかしいとか、同じ様な処理をコピペで5回かいてるとか、１メソッドが長すぎる上に変数が"hoge"とかでわかりにくく、意味を取るのに困難があるとか。「こんなプログラムに金を払わなければならないのか……」と思うとめまいがする。何せ、それを「まともなプログラム」にレビューするのは僕なのだ。で、その作業に対してお金は一銭も入ってこないのだ。
不具合・先祖返りなんかは誰にでもあるミスだし、それを点検するために僕がチェックしているわけなので、そのあたりはいい。しかし文法の狂っているプログラムを修正するというのは、時には全体を書き換えなくてはならなくて、非常に労力である。それに、受け取ったコードは「ほかのプログラマー」さんの「成果物」であるので、あまり手を加えすぎるわけにもいかない。それが「仕様書」をもとにしたコードの場合、あまり修正するとクライアントに「自分はこんなこと言っていない」と思われてしまう可能性もある。だいいち、こんな作業にあんまり時間をかけたら、ほかのもっと大切な作業をする時間がなくなってしまうのだ。こういった様々な事情を考え合わせ、うまいことバランス取りながら、修正の妥協点を探していくわけだが、これはとてつもない頭脳労働である。疲れる。
【２】は例えば、「バリデートチェック」のためのコードなのに、「intは2バイト」ということばっかり書いて来るとか。「intは2バイトはわかったけど、いつからバリデートチェックになるのだろう」と思って読み進めても、最後までintは2バイトしかチェックしていない。依頼主であるからSIerは、そんなプログラムに金を払いたがるだろうか？
もっと具体的な例。ゲーム会社が、「我が社のキャラクタ版権を利用して、凄く売れるSNSゲームを作ってくれ」と依頼してきたとする。プログラマーが打ち合わせに行くと、企画者は「動的フラッシュも使って、１００万ユーザーが遊べる。。。」という話を延々とする。プログラマーは「了解しました」と言って安請負する。そのプログラムはメイン処理だけで１０００行というもので、memcachedの「mem」の字もないし、「オブジェクト指向」といった概念も勿論ない。これでは仮にSNSゲームがリリースされたとしても、１００人さえも遊べない。
このくらいならマシなほうで、ひどいのになるとフリーランス会社から紹介されたプログラマーで、「SQLはselect文くらいしかやった事がない」とか平気で送りこんでくる。たった一人で。
また、意味のないコメントも多い。ループ処理に、「イントのiに３を代入する」と書いて、何の意味があるのだ？ せめて「処理速度改善の為にIntegerは使わずにプリミティブのintを使う！」というふうに書くのが本来だと思う、まぁ嘘なんだけど。だって、そんなコメントみて、「なるほど」って誰が思いますかね？
コメントには必ず「目的」というものがあって、次にソースを読む人は処理の概要を知りたいのだから、「プログラム」をそのまんまコメントにしてもダメなんですよ。そういう単純で、最も重要なことが意識できないで、どうして堂々と「プログラマー」なんて名乗れるのか知らん、と思うぜ。
一番、腹が立つのは「偽SE」ですね。「プログラムはだれでもできるでしょ、重要なのは業務知識でしょ！」みたいなのが偽SE。こういうのを本当に思っているのがいる。業務の画面遷移さえ理解してないSEがだよ。
上の例はさすがに大げさでも、「僕は、プログラムが好きでソフト開発者になりました」とか言ってまともにプログラムが書けない奴は、頻繁にいる。自分でサーバ建てろよ。自分で簡単なサービスつくる事もできないなら、向いてないから辞めてしまえ。
「オレはサーバエンジニアじゃないからコマンド打てない」みたいなね。
世も末だ！
ここに挙げたのは「最低限」のことで、「より読みやすく」「より自然に」「より美しく」というところを、自分の能力の限界まで突き詰めてこそ、プロってもんじゃないんかね。もちろん時間や諸々の事情と相談してのこととはいえ、「26歳の若造が吐き気を催すような拙いプログラム」を送ってくる、30代40代のプロプログラマーってのはいかがなもんでしょう？
身の程を知れというか。
なんでプログラム書けない人がプログラマーなんかやってんだろ？
んで、なんでそういう人に「仕事」があるんだろうか？
身の程を知れよ。
自分の欲望ばっかり考えやがってね。
いじめだったら被害者に共感し、差別だったら加害者扱いされることに恐怖する。
その捻じれの可笑しさに気付かないものかね？
hogeだったら被害者に共感し、hugaだったら加害者扱いに恐怖する。
↓
これがねじれになるんかいな。
むしろ当たり前のことじゃない？
ねじれが生じてるのはそこじゃないだろ。
なぜ被害者に共感したいという気持ちが、加害者になることと両立するのか。
「この無神経野郎め、お前は加害者だ」って言って絡んでいるのは誰なのか。
どうしてこの二つの問題を切り離して考えられないのか。
そのことが本当に理解できない
蛸壺屋の平沢唯が私は愛することの大切さを歌ってますが、
普段はおなかが減っただけで人に怒りを持ったりしますけどね、
みたいなセリフを言ってて納得したことあるけれど、
人間ってそういうもんだと思う。
少なくとも差別はいけないものだってことがみんながわかってれば
誰も差別なんてしないはずだ、なんて理屈よりはずっと腑に落ちる。
なんでも一貫してなきゃおかしいと思うのはどうなんだろう。
内面の感情にまで一貫性を持てとか介入してくるのはバカとしか言いようがない。
どう思ってもいいから、差別スンナよ、だけでいいんじゃないの？
考え方から変えようとする人間って自分が正しいって言いたいだけと茶うんか？
そもそも論だが、差別しないのが人間だというのはただの理想だし、差別するのが人間の自然だともいえない。
あんまり「人間ってこういうものだ」という部分を無視して「こうあるべきだ」だけ語る人はなんだかなぁ。
ましてそれを一貫した態度で求めるとか、もう人間ってものをないがしろにしすぎでしょう。
そういう理論に人間をハメる取り組みのがしたいなら会員制のクラブを作ってその中でやればいいのに。
まぁ啓蒙思想の限界なんてそれこそ我らがルター先生がエラスムスに優越した時からわかってることじゃないか。
世の中を動かす力は理性なんきゃじゃないっての。
そういう理性が多少なりとも力を持つってことは、そんだけ暇を持て余してるってことだ。
アンカータグ内部文字列(＜a href="hoge"＞piyo＜/a＞のpiyo)にはてなキーワードが含まれる場合に、
キーワードリンクが生成されてしまうために、はてな匿名ダイアリーにおけるhttp記法が期待通りに働かないことがある。
この不具合を応急処置的に修正するためにユーザスクリプトを作成した。
(直接インストール https://gist.github.com/raw/552772/569787ce0c50a34ff611605b493236eca6d85131/anond_httpnotation_modification.user.js)
有効にすると日記を書く画面に「確認する(http修正)」「この内容を登録する(http修正)」という2つのボタンが現れる。
アンカータグ内部文字列における各々の文字と文字の間にleft-to-right markが1つずつ挟まれるようにすることでキーワードリンクを抑制する。
[http★://www.flickr.com/search/?l=commderiv&mt=photos&adv=1&w=all&q=japan+people&m=text]
と入力して(★は削除)http修正ボタンを押すと、記事中では
と表示されるようになる。
[http★://anond.hatelabo.jp/20100827093416:title=1日で1,000人にフォローされる地味な作業]
と入力して(★は削除)http修正ボタンを押すと、記事中では
1日で1,000人にフォローされる地味な作業
と表示されるようになる。
http://anond.hatelabo.jp/20070328234724
http://anond.hatelabo.jp/20090616173906
Inspired by これ→ http://d.hatena.ne.jp/DocSeri/20100807/1281152204 ね。
ホメオが根拠無いだとかナンセンスだとか、科学の力で否定するのができるとかできないとかは、まぁどうでもいい。
オレ自身は信じちゃいないが、上のリンク先にあるような話を真に受けて信じちゃってるオツムの不自由な人々が日本だけでも数十万とか、グローバルに世界展開したら、たぶん数億人レベルで存在するに違いない。そこにカネモウケの匂いがするから、とりあえずビジネスにしてみようぜ、みたいな。
なんたって、そのレメディとやらは、物質的に有効成分が一分子も入ってなくても、なにやら記憶というかパターンというか波動というか、得体は知れないけどなんらかの「情報」が転写されてれば「効果がある」そうじゃないか！
しかも、その情報はネットの回線を経由して転送できることが証明されてるそうだし。
すなわち、音楽ビジネスと同じなのだよ。ビニールやポリカーボネートの円盤を買ってこなくても、ネット配信で入手すればOKだし、ちょっと法的にアレなことに目をつむれば、タダで共有することも可能ってわけだ。
イマドキ流行のクラウドでバーチャルなウェブのサービスで、モバイルでユビキタスに対応するフリーミアムなビジネスモデルを構築すれば、受けること間違い無し！
では、どうやってマネタイズするか。
ニコニコ動画と同様に「プレミアム会員」には毎月500円くらい払ってもらう。すると、あなたの生年月日や血液型や星座や十干十二支や生理周期や姓名の画数や手の平のシワの具合や鼻や耳やヘソの形や、あるいは生まれたときの水星と冥王星の角度とかまでモロモロの要素を計算して盛り込んだ「あなただけにピッタリのオーダーメードなレメディ(の情報)」を生成してダウンロードできるようになるのさ。
だれか、はまちちゃんだか、えがいひとだか、どこぞのおもしろ法人だか、スーパーハカーなひとがやってくんねーかなー？彼らなら、とりあえず無料部分までなら２〜３日もありゃ構築できるんじゃねーのか。
そんでもって、そういうWebサービスを始めちゃったら、元祖本家のホメオな人たちがどういう文句を付けてくるのか、楽しみで仕方がないなぁ．．．
音楽だったら著作権法違反がどーたら〜で取り締まれるけどさ、レメディの情報ってヤツらが主張する「客観的な(?)物質の波動だかなんだかをそのまま写したもの」だと思うんで、著作物には当たらないよなー。マトモな科学的根拠も無いわけなので特許権も登録できないだろうし、商標登録になってるようなら、そこだけ少し配慮しとけば、法的にはアレなことって無さそうに思えるんだけど。
ヤツらが「そんな画像で情報が転写できるなんてインチキだ。根拠がない！」とか言ってきても、そこはもうhogeでfugaでpiyoな方法はオレらが開発した独自の計算式で量子力学に基づく超弦理論の波動関数で明らかに証明できてるから間違いないってあくまで言い張ればいいし。
鍵かけてスクリーンネーム変えて逃げたつもりの子の新スクリーンネームを知るには。
まぁ、気づく人はすぐ気づくはずだけど。
俺は最初に書く
( → () → (define hoge '3) とか
読みかたは
かっこ でふぁいん ほげ くおーと3 こっか
Rコンソールに一行ずつコマンドを入力してもいいけど、実際に使うにはテキストファイルにコマンドを書いて（ソースコード）一気に実行させる方が楽。
source('hogehoge.R')
hogehoge.Rというのがソースコードを書いたファイル（ソースファイル）の名前。
CRANという、CPANのパクリがある。膨大な数のライブラリがあるので、好きなものをインストールするには、
install.packages('hoge',dependencies=TRUE)
とするのが楽。
＞ あ<-1 ＞ あ [1] 1
a<-1 b=2 1-＞a
どれでもいい。但し推奨されてるのは一番上。Rの人は「束縛」という言葉を使いたがる傾向があるけど、どっちでもいいと思う。
余談だけど、関数の引数の中で代入できる、しかもその値をそのあとの引数で使える。これ実は便利。
＞ sum(a<-1,a) [1] 2
＞ a [1] 1 ＞ str(a) num 1 ＞ summary(a) Min. 1st Qu. Median Mean 3rd Qu. Max. 1 1 1 1 1 1
最後のsummaryはRっぽい。strっていうのはstringではなくstructの略（だと思ってる）。Rの変数はいくらでも複雑な構造になり得るけど、そのときにぱっと見がわかるように構造を出力してくれる。
Rの基本はベクトル。
ベクトルの作り方はいくらでもあるけど、例示するのが早いでしょう。
＞ x<-1:3
＞ y<-c(TRUE, FALSE, TRUE)
＞ z<-c("a","b","c")
＞ x
[1] 1 2 3
＞ y
[1] TRUE FALSE TRUE
＞ z
[1] "a" "b" "c"
他にもいっぱいあるし、関数の返値がベクトルってこともよくある。
＞ runif(3) [1] 0.2200965 0.6391403 0.1089252
一様乱数を三個作った。
＞ x<-letters[1:5] ＞ x [1] "a" "b" "c" "d" "e" ＞ x[2] [1] "b" ＞ x[4:5] [1] "d" "e" ＞ x[c(1,3,5)] [1] "a" "c" "e"
こんな感じで、[]の中に添え字でアクセス。1-indexなので注意。2,3番目の例では添え字にもベクトルを使って、複数の要素に一気にアクセスしてる。
＞ x[3]<-"z" ＞ x [1] "a" "b" "z" "d" "e"
でOK。
要望があれば続くかも。
はてブとか見てて、おっ、と思わせるコメントにスターがたくさんつけられてるのは、まだ理解できるけどな。
一方で、極論しか語ってないような奴のコメントにやたらとスターが付いてる場合があって、マウスカーソル当ててみるとそいつのIDだったり、クリックすると退会してる会員のIDらしくてスターページ(http://s.hatena.ne.jp/[hoge]/)に行き着けなかったりする。まあおそらく、当のブックマーカーのダミーIDなんだろう。頭隠して尻隠さず。自作自演にすらなってない。お笑いぐさにもなりゃしねえ。
だけどこういうのって、スパムとして運営に通報したほうがいいのか？よくわかんねえ。
とりあえずあらかじめ質問を考えておいて、それだけを相手にぶつけてるように見える。
相手の答えから流動的に質問を変えることは出来ない？
増田の例を使うなら
今の増田は
先輩「りんごは赤くて甘いものだよ」
増田「えっ」
先輩「えっ」
先輩「みかんは黄色くてすっぱいんだよ」
増田「えっ」
先輩「えっ」
て感じだけど、
先輩「りんごは赤くて甘いものだよ」
先輩「みかんは黄色くてすっぱいんだよ」
増田「なるほど。りんごは『赤』く『甘』い。みかんは『黄色』く『酸』っぱい。他にこの二つについて違い（関連性）はありますか？」
…という感じで。
できればノートに簡単な図を書きながら会話を進めていくとモアベター。
ツリー型だろうが配列型だろうがデータには変わりないんだから考え方を変えればいいんじゃない？
C:\hatena\hoge\anonymous.txtを見て
ととるか、
ととるかは増田のお好みで。
C++ の std::list にデフォルトコンストラクタが無いclassを使おうと思って気づいたのだけれど、コピーコンストラクタとか代入演算子を定義してやらないと駄目なのかな。
いやまぁ、それで動くんだからいいじゃんという話とか、ポインタにして自分で new すればいいじゃんというのもあるのだけれど、
class hoge { public: hoge(int dummy); hoge(const hoge &other); private: char buffer[1000]; }; std::list<hoge> hogeList; </pre>とか定義してる時に、
hogeList.push_back(hoge(0));って書いた時、auto変数の領域かなにかに領域が確保されて、hoge(int dummy) が呼び出されて何かの初期化が一回入って、その後、hogeListが確保した領域に、コピーコンストラクタでその値が上書きされるということになって、ぶっちゃけ最初のhoge(int dummy)呼び出しは無駄なんじゃないかなーというか、なにやらでかいバッファを持ってる奴とかだったら、それが全部copyされると考えるとなんか無駄だなーとか細かいことが気になった。
で、これでコピーコンストラクタを呼び出されないようにする方法っていって自分が考え付いたのは、
std::list<hoge *> hogePointerList; </pre>として、自前で new するってのなのだけれど、まぁアレですよ。できれば自前で new とかしないですむ「俺楽チン」なステキ手法はないものか、と愚痴ってみただけです。ハイ。
つか、それくらいやりかたありそうなもんだけど、無いのかなほんとに。そういうもん？
一応試してみたcodeはこんなん。
#include <stdio.h> #include <list> class hoge { public: hoge(int dummy); hoge(const hoge &other); private: char buffer[1000]; }; hoge::hoge(int dummy){ printf("hoge initialized. this: %p\n", this); } hoge::hoge(const hoge &other){ printf("hoge copyed. this: %p\n", this); } int main(int argc, char *argv[]){ std::list<hoge> hogeList; hogeList.push_back(hoge(0)); return 0; } </pre>結果はこんなん。
hoge initialized. this: 0x22c8c0 hoge copyed. this: 0x6c0210で、蛇足的に、
hogeList.push_back(0);みたいな書き方をしてみたら、
hoge initialized. this: 0x22c8c0 hoge copyed. this: 0x6c0210となった。あぁ、これは
hogeList.push_back(hoge(0));に読み替えてくれたんだね。賢いなぁC++は。
ということで、hoge(int dummy) の方に explicit をつけてみたら、muchするfunctionが無いよとcompile errorした。まぁそうだよねぇ。