 
|
はてなキーワード: モジュールとは
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
一度虐殺器官を読んだ人（＝自分）が内容を思い出すためのもの。
第一部
１
死者の国の夢と、そこに現れる死んだ母さん。
２
僕は「濡れ仕事屋（ウェットワークス）」として、二〇一〇年代後半に頻発する内戦をおさめるため、「レイヤーワン」を殺してきた。レイヤーワン――罪の多寡とは無関係に、それを殺すことでもっとも効率的に争いを終結させられる標的。
仕事で殺してきた数多くの（時に罪のない）標的のことは少しも心に留まらないのに、プライベートでの、母に対する医療行為の打ち切りを決断したことで、僕は気を病んでいる。
３
仕事で、二人の標的AとBを殺すように命じられ、異国に入る。標的Bについての情報は、上司から与えられているはずなのだが、それが上司の意図により隠されている。
４
標的Aはその国で虐殺行為を率いていた為に、ぼくの手により暗殺される。
ぼくは標的Aに、なぜそのようなことをしたのかをきくが、彼はしきりに「わからない」と繰り返す。
標的Bはすでにそこにはいなかった。
第二部
１
彼はしばしば「地獄は頭の中にある」と言っていた。
ぼくの父も、かつて自殺したのだった。
標的B――ジョン・ポールを追って、僕らは殺しを繰り返してきた。彼は内戦から内戦へ渡り歩いているようだった。
だが、ぼくらが暮らすアメリカは、「ドミノ・ピザやペイムービーのリピートの平和」か支配し、戦火とは無縁だったのだ。
２
ペンタゴンに召集される。
そこで「ジョン・ポールは軍とは無縁の文人、学者でいる」、「しかし、彼が関わった国は決まって内戦が起こる」と聞かされる。
彼は今度、ヨーロッパに入ったらしい。
ぼくの新たな任務は、チェコで彼を追跡すること。
３
死者の国の夢――「死体は物質にすぎない、生きた人間も」と母さん。
幼少時、僕は家の中で母さんの視線を感じ続けて育った。その視線から逃れるために、「濡れ仕事屋」を始めたのだった。
４
ジョン・ポールと関係を持つらしい女、ルツィアと接触する。チェコ語の講師をしている彼女の生徒として。
ルツィアに、「言語は進化によって獲得された『器官』である」という話を聞かされる。
５
チェコ・プラハで行方をくらませた人間（ジョン・ポールもそうかもしれない）のIDの追跡可能性はゼロらしい。
9･11のテロとの戦い以後、認証を繰り返さなければ買い物も交通機関を利用することもでしないのに。
ルツィア曰く、「ジョン・ポールはもともとMITの学者だったが、いつからかDARPAの研究（ぼくが使う武装、SOPMODを作ったのもDARPA）をするようになった」
６
ルツィアの部屋からの帰り、若者におそわれるが返り討ちにする。おそらくは、ジョン・ポールの協力者。
IDトレースによれば、かつてジョン・ポールとルツィアが密会していたとき、彼の妻子はサラエボで核に吹き飛ばされた。
第三部
１
死者の国の夢――夢の中のプラハでは、例の虐殺が発生していた。
その夢でも、母さんが現れる。
「母さんは意識はなかったけど、内蔵は動いていた。そして、ぼくが医療行為の中断を認証した。
……母さんが死んだのは、ぼくが認証でイエスと言ったときだったんだろうか？」
「あなたは、任務での殺しでは「それは政策が決めたことだ、自分が決めたことじゃない」と、責任の重みから逃れられた。
でも、医療の中断の責任からは逃れられない。あなた自身の決断だから。
……そう思っている。もしくは、中断をする前から私は死んでいたと信じたがっている。
けれど、本当は、私だけじゃなく、あなたがころしてきたすべての人々が、あなたの決断によって死んだ。
私を殺した罪を背負い込めば、あらゆることが帳消しになると思っているの？」
２
夢の虐殺後の静けさとは裏腹に、プラハのあるクラブには、生き生きとした騒々しさが満ちている。
そのクラブでは、IDを認証せずに支払いできる紙幣（みなくなって久しい！）を使うことができる。
「プライヴァシー（認証されない）自由と、テロの自由からの恐怖はトレードオフ。自由の選択の問題」
３
ジョン・ポールの妻子がサラエボで核の熱で蒸発したとき、彼女はジョン・ポールと不倫し、セックスを楽しんでいたという罪の告白。
罪悪感の対象が死んでしまうということは、いつか償うことができるという希望を剥奪されること。
死者は誰も許すことはできない。
４
「濡れ仕事」で数々の骸を見、中央アジアからワシントンに帰ってくると、母さんは事故で死んでいた。が、彼女の心臓は再び動き出した。――危険な軍隊へ行ってしまったぼくへの復讐として、ぼくに生き死にを決断させたかったから？
決断の材料を探す為に、母さんのいえ――ぼくの生家でもある――に行く。
かつてそこでも母さんの視線を絶え間なく感じながら、ぼくは育った。
見つめられることの安堵は、（認証され続けることの安堵は、）息苦しさの表面にすぎない。
結局、母さんの残したログは見ずに（ロックがかかっていて、他人が見ることはそもそもできなかった）、ぼくは母さんの「死」を決断する。
――母さんの視線の「気圧」から逃れたくて、ぼくは母さんを「殺した」んじゃないのか。
５
僕の告白に対してルツィアは、
「人間は生得的に善ね利他行動を行える。あなたの、お母さんを「殺した」決断も、本能による利他の行動。だから、あなたは許されるべき」
ルツィアとの帰り道、気を失う。
ジョン・ポールによる電撃を食らって。
６
とらえられた僕は、ジョン・ポールと会話をする機会を得る。
虐殺の言語は、僕の装備を作ったDARPAが協力した研究により生まれ、僕の殺す対象を選ぶのと同じシステムを利用してる。
７
ルーシャスは、〈計数されざる者〉という、ポールの協力者集団の一人だったのだ。
〈計数されざる者〉は認証を嫌う。プライバシーと平和はトレードオフの関係にあるはずなのに、実際は、認証をすればするほどテロが増加している。
それは、世界の人々が、自分のことにしか興味がないから。ドミノ・ピザとビデオクリップの平和に浸っているから。すぐに手にできるはずの現実に手を伸ばそうとしない奴らばかりだから。
ジョンとルツィアは去る。
僕はルーシャスに殺されかかる。その寸前のところで、ウィリアムズに助けられる。
第四部
１
旧印パ国境地区。そこにいるらしいジョンをとらえるように命じられる。
２
痛いと「感じる」ことはなくても、痛いと「知覚する」ことはできる。人をためらうことなく殺せても、その殺意を自分のことのようには感じない――僕は「濡れ仕事」をこなせるように、DARPAによって、そのように調整されている。
――「殺される」前の母さんと同じ、希薄な意識だ。僕が「濡れ仕事」をするために必要な、意識の希薄さ。
この殺意は、本当に僕のものなのか、僕が「殺す」前、母さんが本当に「死んで」いたのか、僕にはわからない。
３
４
ジョンを文化顧問として雇った、ヒンドゥー原理主義国、ヒンドゥーインディア。
その少年・少女の兵を、「他人の殺意」で殺しながら、ジョンのもとにたどり着き、彼をとらえる。
５
ジョンは、
「私が行っている「虐殺の言語」と、きみが施されている「「他人の殺意」による殺人」は同じだ。どちらも、良心を抑制する」と。
ぼくは、
「あんたには内通者がいるな。政府部内に。僕らの面子か、もっと上のほうだ」
ぼくらアメリカと同等の技術を持った敵によって、列車が襲われる。ジョンは僕たちによる拘束から逃れる。
僕たちも敵も、痛みを「知覚」するが、感じない。体の部分が吹き飛ばされても、戦闘は続く。お互い、「ハンバーガーになるまで弾と火薬をたたき込むしかない」。
リーランドはミンチになりながら、死の間際まで、冷静で希薄な意識で戦い続けた。
第五部
１
インドでミンチになったリーランドは、商品と違ってメタヒストリーを持たないから、つなぎ併せて一つにして、棺に納めるだけでも一苦労だった。
それでも、ミンチにさえならなければ、認証によるメタヒストリーを僕らは持つ。母さんもそうだった。
母さんのメタヒストリーがプロテクトされていなければ、僕は母さんを「殺す」か否かの決断を、認証の蓄積によるライフログを手がかりに探すことができた。
リーランドがミンチになった戦いがきっかけで、ジョンとの内通者が発覚する。
２
発覚した情報を手がかりに、ヴィクトリア湖へとジョンを追う。そこは、誰も追おうとしない人工筋肉のメタヒストリーの行き着く先。
〈ヴィクトリア湖沿岸産業者同盟〉は、人工筋肉の利権を得るために、独立しようとしている。
３
ジョンがいるはずのゲストハウスにルツィアを見つける。
ルツィアを探してゲストハウスに入ると、ジョンが待ちかまえていた。
４（物語のコア）
ジョンは、
「虐殺も利他も、進化によって得たモジュールという点で同じ。むしろ両立すらできる。生存のための大量虐殺というのもありうる。たとえば、食料を多部族から奪って自部族の仲間を生きながらえさせるためだったり」
ルツィアは、
「あなたは、サラエボの奥さんや子供を失って絶望しているから虐殺の言語をばらまいているのね？」
ジョンは、
「いや、愛する人々を守るためだ」
――そうだ。ジョンがいたどの国も虐殺に見回れていたはずなのに、彼の過ごしたアメリカとチェコでは、それが起きていない！
５（物語のコア）
ジョンは、
「人々はみたいものしか見ない。だから、いくら認証しても、テロはなくならない。
ならば、テロで爆発するはずの憎しみがこちら、アメリカやチェコといった先進国に向く前に、彼ら同士で憎しみあってもらおう。――そのために、虐殺の言語をふりまいた」
ジョンは、ぼくらの世界へのテロを未然に防ぐため、虐殺の旅を重ねた。
ルツィアは僕に、ジョンを殺さずに逮捕するように言う。僕らの世界の平和は、ジョンによる無数の死者の上に成り立っているのだと、みんなが知るべきだと。
と、ルツィアがヘッドショットを決められて死ぬ。
ウィリアムズによって。
「なぜ殺した」と僕。
「妻と子のためだ。彼女らは、この世界が虐殺の上に成り立っていることを知らなくていい。
ドミノ・ピザを認証で受け取る世界、くそったれの平和な世界を、俺は彼女らのために守る」
ウィリアムズはジョンを殺したがっているが、僕はルツィアの最後の言葉の通りに、ジョンを生きてアメリカにつれていき、証言の場に立たせたい。
ジョンとともに、逃げる。
「おまえを逃がせばまた、虐殺の言語を振りまくのだろう？」と僕。
「いや、死んだルツィアの望んだ通り、世界に真実を知らせよう」
タンザニア兵と合流しようとするが、それはタンザニア兵になりすました、僕の「濡れ仕事」の仲間だった。
彼がジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
……僕は、プロテクトがあるためにライフログを見られなかったのではない。ただ、漠然とした恐怖があって、ライフログの閲覧を申請しなかっただけだ。
僕は幼いころ、常に母さんに監視（ID）されているような気でいたが、母さんのログを読んでみると、必要最低限にしか、僕の存在が記述されていない。
母さんの記録の中に生きていたのは、圧倒的に父、自殺したはずの父だった。
僕は、ジョンからもらった手帳を元に、虐殺の言語を語る。虐殺の言語でもって、ルツィアの願い通り、真実を世に知らせるのだ。
そして、世界にとって危険な、アメリカという火種を、虐殺に突き落とす。
僕はこの決断を背負う。ジョンがアメリカ以外の命を背負おうと決めたように。
☆改変版
ジョンは、
「いや、私は米国内の後ろ盾を失った。深層構造の原理を知られれば、たかが言葉だ。応用されるのも時間の問題だろう。マスコミや政府公報で、いくらでも虐殺の言語を打ち消せるさ。
だが、私は〈計数されざる者〉という新たなバックアップを得られた。認証に対して憎悪を抱く、世界的な組織だ。この力を使えば、私たちのすむ「こちら側」を静寂に保つことができる」
「なにをするつもりだ？」
僕の「濡れ仕事」の仲間が、僕がジョンの答えを聞く前にジョンを射殺し、僕の任務は（アメリカからすれば）成功裡に終わる。
〈エピローグ〉
僕はジョンに、「真実」が書かれたテキストファイルを渡されていた。
それを世界に知らしめ、僕たちが虐殺の上にたっていることをみんなが理解することがルツィアの願いなら、僕はそうするべきなのだろう。
公聴会で、ぼくはジョンの件で見聞きしたものを語る機会を得る。
ジョンから渡された「真実」をオルタナに浮かべて話そうとする。
すると、僕が見ずにいた、母さんのライフログをオルタナに突きつけられる。――これが、〈計数されざる者〉、ジョンが最後に得た力か。
幼少の僕は、母さんに監視（ID）され続けていたと思っていた。しかし、母さんのライフログには、あまりにも父ばかりがいる。彼の死語ですら。
それを皮切りに、次々に、アメリカの全議員、いや、オルタナをつけているすべての人々の視界に突きつけられる、真実のログ。世界からアメリカに憎悪の数々が向けられているという真実。〈計数されざる者〉のルーシャスは言っていた。プライバシーの提供と、テロとのトレードオフの不均衡は、みたいものばかりを見ることによって起こると。認証の中に閉じこもり、ドミノ・ピザとビデオクリップの平和の外を知ろうとしないことで起こると。
ふと、アメリカはもう死んでいるのだと思った。母さんに視線を返せない、父さんのように。憎悪を浴び続け、しかしそれを無視しているアメリカは、死んだ父さんと同じだ。
……だが、アメリカに憎悪を向ける小国とて、自分の窮状をしらしめようと騒ぐばかりで、他の小国を知ろうとすらしていないのだ。僕が母さんのログを見ようとしなかったように。
ジョンが行った、〈計数されざる者〉の力の改変。それは、小国の内部で争いを起こす虐殺の言語よりも規模が大きなものだった。互いに無視しあっていたずの、小国と小国の視線をぶつけ合わせる。そして、小国同士で戦争を起こすことで、「こちら側」の平和を保とうとするものだった。
ジョンの考えと僕の考えは違う。
母さんが僕を見ないのは、父さんというすでに存在しない項があるからだ。アメリカからの存在しない視線を小国が期待するように。
存在しないものを、存在しないと意識させること。僕にはそれができる。ジョンから得た「真実」の欠片、虐殺の言語と、僕のマザータン、アメリカで語られる英語によった。
横だけど。
【プログラムの何らかの「凄さ」を】って問いに「人気だ！」って答えるのもどうかと思うよ。
それって別段スキルなくても、サービスプロバイダのＡＰＩを切り貼りしただけでも、稼げるからね。
今だと、モジュール化され過ぎてて、指標を出しにくいよね。
これは、「（他のライブラリが必要な）特殊なモジュール使ってますか？」「環境依存の設定ありますか？」とかを包括した質問かもしれない。
（コンパイラオプションで関数を使う／使わないって切り替えする奴とかで、おまじないとして大量の定義が必要な仕事場はあった）
使ってる検査ライブラリが、ドライバのライブラリを静的リンクしてた時、「なんか（インストールとか）必要なの？」って聞いたこともあるよ。
「この○○ってライブラリが参照してる××ってなに？」じゃなくてね。
まぁ、言語仕様は知ってるけど、開発環境の仕様は知らないって人、多いよ。
んで、そういう事についての感性が低い人は、確かにいる。
Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。
JS も馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数もオブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.js や jQuery やの中身とか読んで理解できるくらいになるには。
Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンな Perl は OO だよ。CPAN にあがってるまともなモジュールは殆ど OO スタイルだし、もっとモダンなスタイルの環境でもいける。モダン Perl や Moose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。
JS や Perl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者は最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。
JS と Perl はレガシースタイルが残ってる例としてあげたけど、LL でも Python や Ruby はもともと OO スタイルしかない。だから、自分でやってることを理解してないと過去のうんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python は初心者向けだと思う。知り合いが何でも良いからプログラミングやってみたいと言い出したら GAE で Python 弄らせる。
ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。
プログラミングスキルは、本質的には言語に依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語が LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JS や Perl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、～だから～を学ばなくていい、なんてのは上達したいなら殆どない気がする。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
「素性の良い言語」に求められる性質は色々あるけど、一つは、モジュール同士を疎結合に保つための機能が備わっていることが挙げられる。つまり、「理解していない人」がエンバグしても、その影響範囲を最小限に留められるということ。これが、機能追加やデバッグ時にどれだけありがたい性質であるかは、多くのプログラマに同意してもらえると思う。
大規模なコードになるほど、一人の開発者から見てブラックボックスになる部分が増えるのは避けられないこ。Javaの言語機能を適切に使えば、手に負えないバグを埋め込むことを回避しやすくなる。
http://anond.hatelabo.jp/20110417194312
ただ、個人的には代替エネルギーと原子力が相互排他的であると考えるのはおかしいと思います。早い話、太陽光発電は昼間にしか発電できない以上、出力調整ができない原子力よりも、ピーク時に稼働される火力・水力を代替する方がよほど技術的にも本筋です。
代替エネルギー＝太陽光ではないし、風力・地熱・高温岩帯・潮汐など夜間も発電可能な代替エネルギーのほうが多いです。また、エンド寄りで充放電してピークシフトする技術も研究されています。
原発に対するリスク評価・費用便益比評価は、3.11以前と現在ではまるで変わってしまいました。そのことは原子力研究者たち自身も反省の弁を述べ、他国の原子力施策が相次いで大きな転換を迎えつつあることにも表れています。そうした現状を無視して「原子力は出力調整ができないから現状維持、火力・水力は代替エネルギーに置換」と主張するのは、技術的にもSTS的にも的外れなソリューションです。
また、 id:koseki は、代替エネルギーと原子力が技術的あるいは運用的に「相互排他」だと指摘しているわけではありません。原子力発電は、エマージェンシーの際には被災地での直接人命救助に割けるリソースを廻してでも最優先で事態悪化を食い止めなければならないほどのリスクがあること、そのリスクのモジュール化による低減が困難なほど大規模な系にならざるを得ず、現に全体の統御をしあぐねていること、（そして私から見れば、現時点での想定賠償金だけで日本最大級の「優良企業」が消し飛びかねないほどの潜在的コストを孕んでいたこと）…などの現実を前に、「長期的観点での原子力からの脱却・転換が必要」だと認識したうえで、それを置き換える存在として代替エネルギーの話をしているだけです。
地元の同意がなければ立地できないというのがまず一点。あとそういうことを言い出せば病院や工場を街中に建てるのも許されないということになってしまいます。何事も程度問題でしょう。
今となっては、原子力発電には「想定外の事態が起きたときには、周辺地域の住民がその土地での生活を永遠に放棄しなければならないほどの危険性もある」というリスクが内在したことがわかっているわけですが、当時の福島原発周囲の地域住民は、そうしたリスクを含めた適正なアセスメント情報を開示されたうえで受け入れに同意してはいないでしょう。不完全な情報提供に基づく判断について自己責任を負えというのは、特にこうしたビッグサイエンスが絡む（≒専門家集団と一般市民のあいだにおける情報やリテラシーの非対称性が著しい）問題においては、あまりに一方的な話です。
また、地元での調整の結果、病院や工場の街中への建設が許されないというケースは当然ありましょう。ただし病院や工場の費用と便益は（法令による環境アセスメントがなされている限り）基本的にローカルスケールに収まるものです。しかし、原発はそうではない。現状でも国家〜超国家規模のコストを生み出している。4号機の使用済燃料プールが水素爆発により「注水」されるという偶然がなければ、さらに大きな被害を生んでいたことでしょう。
程度問題の「程度」がまさに問題なのです。
なんちゃってIT「エンジニア」の id:koseki です。ITだけが技術だと思いこんではいませんけども。
「安全を金で売り渡す」というのは多かれ少なかれ誰でもやっていることです。
問題は、「安全を金で売り渡す」というその安全が、他人のものだということです。人の命を賭け金にして自分の儲けのために博打を打つ、という行為を、正当化できるとは思えません。ギャンブル依存症のような経済学者や評論家が言う「リスク」という言葉から抜け落ちているのは、この不正義の感覚だと思います。
「エンジニア」がリスクを数字で見積もることももちろん必要でしょうけれども、それは議論の全体ではない、という点を、まず指摘したいです。
「死者ゼロ」という表現は正確ではないと思います。震災1週間後には、次のようなニュースが出ていました。
【東日本大震災】福島原発の避難所死亡、２１人に 病院の入院患者ら - MSN産経ニュース
http://sankei.jp.msn.com/affairs/news/110318/dst11031807500008-n1.htm
福島第１原発（福島県大熊町、双葉町）の事故をめぐる避難指示を受け、大熊町の「双葉病院」から避難した入院患者ら高齢者の死者数が、同県いわき市など３カ所の避難所で計２１人に上っていたことが１７日、分かった。
入院患者衰弱死の現場「想像以上」 原発事故で避難も…医師語る 社会 福井のニュース ：福井新聞
http://www.fukuishimbun.co.jp/localnews/society/27092.html
白い防護服に身を包んでバスに乗り込むと、思わず息をのんだ。マットレスと掛け布団にくるまれた高齢の男女が座席にあふれ、衰弱しきっているのかほとんど動かない。排せつ物で汚れた布団。通路にも何人かが横たわり、女性が「足が、足が」と、か細い声でうめいていた。
福島・双葉病院「患者置き去り」報道の悪意。医師・看護師は患者を見捨てたりしていなかった（追記あり） - 絵文録ことのは - BLOGOS（ブロゴス） - livedoor ニュース
http://news.livedoor.com/article/detail/5424517/
以上の流れをもう少し簡単にまとめると、「自衛隊が来るが、寝たきりや車いすの患者が搬送できず、一旦戻る」→「2度目の救援が来ない」→「一緒に残って いた警察の指示で職員が川内村に避難」→「自衛隊と一緒に病院に戻ろうとする」→「避難地域なので一緒に行けない」→「自衛隊だけが救援に」→「2・3回 目の搬送の際、病院関係者は誰も現場に居なかった」→「職員が患者置き去りで逃げたと報道」という流れになる。
この方々は、原発事故のせいで避難しなければ、助かった可能性が高いと思います。原発事故による二次的な被害を含めれば、「死者ゼロ」とは言えません。
個人的にはBPの原油流出事故の方が死者も出ているし汚染もひどい事故のような印象がありますが、まさに「比較」や検証を客観的に行うことが大事というのは大いに同意します。
大気汚染についてはわかりませんが。自分の「印象」では、福島の方が重大な事故だと感じます。
事故被害の一次的な死者数は、リスクを見積もる上で確かに重要なパラメータだと思いますが、それが全てであるかのように言うのは、ある種の誤魔化しだと思います。
たとえば、一歩間違うと大変な数の人命が失われた可能性があるが、幸い誰も死ななかった、というタイプの事故があると思います。そういったリスクを、数少ない事故例をサンプルとして、死者数から見積もれるかどうかが、疑問です。年に何十回、何百回と原発事故が起きていれば、だいたいこのくらい死ぬのだな、とわかるかもしれませんが、、。
それから、津波のがれきの下に生きている人がいるかもしれないにも関わらず、ハイパーレスキュー隊が原発へと向かったということがあります。
asahi.com（朝日新聞社）：東京消防庁ハイパーレスキュー隊など１３９人が福島入り - 社会
http://www.asahi.com/national/update/0318/TKY201103180121.html
原発のリスクが本当にそれほど大きくないなら、一旦原発は放置して、救える命を救う方が良いと思います。福島原発の事故処理が、これほどリソースを消費しているのはなぜなんでしょうか。原発の潜在的なリスクが巨大だからだと、自分は理解しているのですが。
現代ではどんどんシステムが大規模化しているわけで、そうなればなるほど原子力に限らず事故が起こった場合の被害は増大するわけですから。
システムが大規模化した場合、モジュール化してリスクを分割・分散することが必要です。小さなシステムの集合体として大きなシステムを構築すべきだと考えます。原発のリスクは大きく、全体を制御しきれていません。代替エネルギーによって、大きなリスクを解体し、正確に制御できるようになることを期待します。
東京電力には大変に優秀な、非なんちゃって「エンジニア」の方が大勢いらっしゃると思います。彼らの知見を、当面運用し続けなければならない原発の安全性向上と、脱原発のプラン作成、代替エネルギーの技術開発に最大限生かしていただきたい。墓守のような原発維持の仕事よりも、新しいエネルギーを生み出す仕事の方が、技術者としては面白いのでは、と想像しています。現実問題として、どちらも大切な仕事だと思いますが。
自分は今回の事故後、代替エネルギー技術の進歩を推し進めるために、政府は脱原発の方針を明確に打ち出すべきだと考えるようになりました。あまり数字には具体的な根拠がありませんが、
今後30年で全54基稼働停止
http://www.jpea.gr.jp/pdf/009.pdf
太陽電池モジュール 期待寿命20年以上 パワーコンディショナ 期待寿命10年以上
太陽電池の主要な材料は結晶シリコン(ケイ素)だっけ。採掘するだけなら日本国内で十分な需要をまかなえるだろうけど、あれって確か精製自体に結構な電力を食うという話だったはず。だから電気が安い国で作らざるを得ない。火力にしても太陽光にしても、外国に依存せざるを得ない点は同じだね。原子力発電の場合、日本はNPT加盟国なのでウラン産出国から自動的に輸入されるっぽい。というか、NPT批准しないと核燃料回してもらえないっぽいな。
そんなこんなで仮に日本全国の家屋に遍くソーラーパネルを設置したとしても、毎年相応の割合で発生する故障や破損の交換は必要になるし、一気呵成に普及させれば寿命による交換時期も毎回集中してしまうはず。
覚書。
Internet Explorer8(64bit版ではない)にてGyaO!、Yahoo!ニュース、DMM等の動画サイトを閲覧するとブラウザがクラッシュする。
Internet Explorer は動作を停止しました
強制終了されるページはMicrosoft Silverlightプラグインを使用したもの。
障害が発生しているアプリケーション名: iexplore.exe、バージョン: 8.0.7600.16700、タイム スタンプ: 0x4cd23213
障害が発生しているモジュール名: getflash.dll、バージョン: 1.0.0.1、タイム スタンプ: 0x4506208e
例外コード: 0xc0000005
障害オフセット: 0x00008c40
障害が発生しているアプリケーションの開始時刻: 0x01cbbb667d383d68
障害が発生しているアプリケーション パス: C:\Program Files (x86)\Internet Explorer\iexplore.exe
FlashGet1.73をインストールしていたのだが、こいつとSilverlightの相性がわるいのか。
私はwebデザイナーをやっている。制作会社に在籍していて、独身の女で、今年で4年目になる。
webデザイナーはちょっと頑張ればできる仕事だと思われている気がする。
ずっともやもやしていたので、そのことについてちょっと書いてまとめてみたい。
私の会社は人の募集をわりとずっとしていて、ちょくちょく選考をしている…みたい。私はたまに書類選考や面接を担当するぐらいなので、全部は分からないけど。
（しかも私は「お前の勉強にもなるから」という感じで担当させてもらってるような感じなので、特にスキルレスな人に当たってるのかもしれない。）
そうやっている中で、応募してくる人のレベルと、こちらの望んでいるレベルのギャップが大きいということにすごく戸惑っている。
未経験+職業訓練+ポートフォリオはありません、これが結構いる。
ポートフォリオったってあなた、職業訓練に行ったのならそこで課題とかあるでしょう。せめてそれ持ってきたら？ないなら作ったら？イチから作れないならレンタルブログのカスタマイズでもいいから、ないよりはましだよ、ていうか頼むよ。
（今ふと思ったけど、営業とか事務ってそういうの全くない中で選考すんだよなー…すごいな…）
作品です、と持ってくる人も、ポートフォリオの作り方にも一工夫しようとか思わないのだろうか。印刷してファイリングしてくるならフォントも意識しなよ。
こんなアイデア、スキルを持っているということをアピールしたい、どうやったら印象に残るだろうと思う人に、彼らが勝てるわけがない。
他のwebデザイナーの年収や忙しさ、勤務環境を知りたくて、質問サイトなんかを色々見ていた時期がある。それこそ知恵袋から、個人のブログ、2ちゃんまで色々見た。
知恵袋みたいなところでは、検索をかけてみたら「webデザイナーになりたいです」という質問がヒットするわするわ。うんざりした。
あんまり出てくるから「webデザイナーってそんな簡単じゃないんだけど…」という気持ちのやり場に困った。
1枚画像を作るのがwebデザイナー、と思う人もいると思うけど、今の職場での私の仕事では、一番長いスパンで関わるものの流れはこんな感じ。
お客さんとの打ち合わせに同行→営業と打ち合わせ→レイアウトを起こす（漫画でいうとネーム）→営業と打ち合わせ→トップページのデザインを起こす。→営業と打ち合わせ。私はflashができないので、flashが入る場合は別の担当に入ってもらってその人も交えて。→お客さんからOKが出たらトップページのコーディング。→トップページのSEO対策をしつつ各ページのコーディングをしつつ、ページごとに必要な写真加工とパーツ制作。メールフォームなんかの簡単なプログラムもここで入れることが多い。→ブラウザチェックと営業の確認。ブラウザはIE（6/7/8）、火狐（win/mac）、Safari（win/mac）、chrome（win/mac）。微調整を行う。→お客さんのOKが出たら納品。納品前に確認事項があったりCMSの使い方のレクチャーみたいなのが必要ならお客さんに教えてから。
大規模なサイトなら画像面のデザインが２人、コーディングが３人、flashが１人…みたいなこともあるので、リーダーになったら各人への指示なんかもある。SEO対策を担当する場合なら納品後も関係は続く。報告書まとめたり提案出したりといった。
どう、大変でしょ、みたいになってしまった気がする。ごめんなさい。
で、どの行程を担当しても、全行程を理解していなければかなり全体効率が落ちるし、他の担当や営業、お客さんにまで迷惑がかかることがある。コーディングのことを全く考えてないサイトデザインでコーディングが圧迫されたり、SEOのことを分かっていないコーディングのために後から修正したり。半端にカスタマイズしてプログラムが暴走したりしたこともある（さすがにこれはひやっとした）。
一つの職業であることは変わらないのに、デザインというセンス要素が過剰に注目されてしまっている。皆そこに憧れている気がする。webデザイナー、なんて名前がきらびやかすぎるのかもしれない。地道な地道なパーツデザインやコーディング、市場分析が仕事に占める割合は高いのだから、単調な部分も多いのに。
センスが生きる場所のサイトデザインだって１回では終わらない、ずっとアイデアを出し続けることが求められるから、ある種の単調さは生まれる。時には１案件に何案もデザインを出すことすらある。どうしょうもないセンスだと思うお客さんの希望に沿ったデザインを出すこともある。
話はちょっと変わって、私が関わった営業の中にはデザイナーをすごく見下している人がいたけど（ちょろく見ているというか）、なりたい、と思う人でさえそうなのだから、なりたいと思わない人には余計簡単そうに見えるのだろうか。
営業は本当に大変だと思う。
サイト制作経験のない営業もいて、そういう人は本当に苦労しているし、逆にデザイナー上がりの営業は「自分だったらこうする」という主張が出るからそこで苦労がある。「ホームページってそこまで興味ないんだよね」と言いながらわがままな注文や後出しの要望が多いお客さんもいるし、お客さんのホームに行って戦うのは彼らだ。
だからがっちり支えたいと基本的には思っているけど、楽な仕事なんだからいいよな、と言われると腹が立つし、それぐらいちょちょっとやってよー、適当でいいからと不必要なデザイン案の数を求められると踏みにじられているように感じる。
単発でそういうことがあっても、人間そういうことはあるから抑えるけど（営業てめえこんな手間かかるものをこんなに安く取ってくんじゃねえよ、分かってないやつは死ね！と思うことはあるし）、基本姿勢が「デザイナーは営業の言う通りやってたらいい」の無知な営業に対する怒りは地道にたまる。
かなり時間をかけてここまで書いた。考えながら書いたので、きれいに自分の中で結論が出た。
俗なことだけど「こっちのことも認めてくれ」に尽きるな。
webデザイナーじゃなくても同じだなあ。
営業は営業でこっちに対して言いたいことがあるだろうし、その言いたいことはデザイナーが想像もつかないことだったりするのだろう。
ただ、互いに互いのやっていることを逐一知らせあうような時間はとてもないし、実際にその職につかないと分からないことこそが軋轢の原因にもなる。
もっと寛容にならないといけないな、私。
さて…。
吐き出しになってしまったので、webデザイナーの面白いところも書くことにしよう。
いいデザインができて評価されるともちろんそりゃ嬉しいんだけど、それは分かりやすいので省略しよう。
私は表を作ったり説明文をコーディングしたり、Q&Aを作ったり、「サービスの流れ」みたいなページを作るのがとても好きだ。フッターにあるテキストリンクや、パンくずリストを作るのも好き。問い合わせフォームや、WPなんかのモジュールのカスタマイズも好き。あとキャンペーンバナーとかボタンも楽しい。
そういう部分は、分かりにくいとお客さん（サイトを訪問した人）を逃がしてしまうからやりがいがある。
逆によくできていれば、サイト全体のイメージをかちっと上げてくれるし、メンテもしやすい→サイトが継続しやすい。ってこれはこっちの都合だけど。
分かりにくいサービスや、説明しておくことが多い商品のことをお客さんにきっちり聞いて、まとめあげるのは快感に近い。
そういうものって「あって当たり前」みたいなとこがあるから、気を配って作っても気づかれないことが多いのだけれど、でもやっぱりサイトを見る人を左右するのはそういうちょっとした部分の累積だと思う（なので営業が「こういう表はお客さんに好印象でいい」「このお買い物の流れ、他のお客さんにもお勧めした」なんて言ってくれたりしたらすごく嬉しい）。
内容が本当にきちんと練られているサイト、ユーザビリティがきちんとできているサイトってまだまだない（あるようでない）。新しく次々に出てくる技術はいっぱいあるけど、そういうのも大事だけど、でも内容がちゃんと伝わってなかったら無意味だ。サイトに書いてあるこれってどういうことですか？どうやって買い物したらいいんですか？とかいう電話かかってきたりしたらサイト作る方がデメリットがある。
デザインのこととか、最新の何か（今ならhtml5とか）を使ったりすることばかりに集中していたらいけない。それこそ「webデザインのことしか分からない人間がうるさい」ということになる。営業的な考え方も必要だし、一般のお客さん的な考え方も必要。
全行程に対する理解の度合いでできる仕事が変わるっていうのは、本当にどこにいても同じなんだと思う。
支離滅裂になってきたので、終わる。
今年は社会人として一区切り付く年となりそうなので、これまでに
仕事をしてきて思った事などをまとめたいと思います。備忘録です。
客先だけでなく、社内、グループ内を含め時間は必ず守るようにしましょう。
レビューの日にち、時間、資料の提出期限、飲み会の参加表明の記入などなど、
周りに与えるインパクトに大小はありますが、時間を守るのは絶対です。
もし、遅れる場合は必ず連絡しましょう。遅れてからでは遅いです。
連絡するタイミングも重要です。直前の連絡は遅れた事と同じです。
ただし、遅れる事を連絡するタイミングは、早すぎるのも良くありません。
できる努力をしていないと思われるからです。連絡のタイミングは見極める
必要があります。
作業を依頼する時は必ず期限を切りましょう。
なぜその期限に完了する必要があるか説明できないと、人は動きません。
また、逆に期限を設定されない作業が降ってきた場合は、期限を設定しましょう。
そして、なぜその期限までに完了させないといけないのか聞きましょう。
自分は誰に管理されているのか、エスカレーションは誰にすればいいのか、
必ず明確にしましょう。
また、自分が人の上に立つ場合は、管理下の要員以外は原則動かせません。
管理下以外の要員を動かす場合は、その人の管理者と調整する必要があります。
作業の基本は Plan→Do→Check→Action です。
このPが曖昧だと火を噴きます。計画は絶対に手を抜いてはいきません。
1．出来るだけ細かく作業項目を洗い出します。
例）xx機能の詳細設計書の作成、xx機能のyy処理の試験実施、
2．どのくらいの量があるか洗い出します。
xx機能 -
yy処理の項目数：100項目
この時、上の例でyy処理、zz処理の中でも必要な時間が変わる場合は、
重み付けをします。
例）
xx機能 -
yy処理の項目数：100項目実施の時間＝5分×20項目＋10分×80項目＝900分
zz処理の項目数：200項目＝10分×150項目＋15分×50項目＝2250分
合計：3150分＝52.5時間＝8人日(1日を7時間とする、小数点以下は切り上げ)
※1日7時間の根拠：1時間はログの整理や事後作業の時間とする
また、上で作った見積もりは、PDCAのCheckでも使われます。
具体的には、結果の報告です。
見積もりと乖離があった場合の説明に用いたり、見積もり通りに進捗した場合の
振り返りに用いたりします。
リスクとしては、障害の発生、バグ検出による改修からリリースまでの作業、
上乗せしておきます。
末端にいて、客先を意識しにくい場合は、自分がいる立場の一つ上に立って
担当者の場合は管理者の、管理者の場合は更に上の管理者の立場で物事を
考えます。
例えば、報告資料のフォーマットから、エクセルの文字の大きさや網掛け等の
書式といった、細かいところまで、人に見てもらう資料は気を使わないと
いけないところがたくさんあるはずです。
。。。うん、当たり前の事書いてますね。でもなかなかやってくれないし、
★今日はここまで。
完全に一致を作るための勉強法
コメントもたくさん頂いてまして、それにお答えするのに「ブログでもつくろうかいな」とのぼせましたが、そんなテーマで続くわけもないので、やはりアノニマスダイアリーにしました。
【製作期間について】
まず、皆さん仕事しながらたった4ヶ月で！と褒めて頂いてますが、たったじゃないですよ。4ヶ月って。
仕事が終わって、毎日2～3時間。土日関係無くやると、多分300時間くらいになります。
専門学校の2年間の授業時間がこのくらいだったりするんじゃないですかね。結構長いです。
【モチベーションの維持について】
モチベーションを保つのがすごいというのも褒めてもらいましたが、私は一回やり始めると、意外に長く続きます。
コツがあるんです。
毎年、日々の単純作業が続かない新入社員が入ってきますが、そんな新人に言います。
「息をするように続けるんだよ。」
毎日やるんです。土日関係無く。毎日。
前回の日記で「勉強した」と何度も使ってしまった為、誤解をされている方が多くいらっしゃいます。
正確には、「調べ」ました。
職業柄「調べる」という事が多い為、WEBサービスを作るという事に関してはそれが訳に立ちました。
追記でも書いているのですが今回のシステムはほとんどが、先人達が作った既存のシステムがベースになっています。
ぱくりと言われてしまえばそれまでなんですけど、丸ごとはやってないですよ。というか、丸ごと合うモノがなくて、いろんな所からソースコードを拝借させてもらいました。
なので、中身はぐちゃぐちゃです。けど、検索システムはそれでも200行くらいしかありません。クローラーは80行くらいでしょうか。
【HTMLについて】
というか、それすら途中で挫折してAdobe社のDreamWeaverというソフトを使いました。
適当に書けばソースは綺麗にしてくれるし、CSSの体裁はプロパティを設定しながら見た目のまま調整すれば良いし、一番助かったのはテンプレート機能でした。
最初は全部のHTMLファイルをコピーしながら作っていたのですが、ヘルプを見るとテンプレートとライブラリという機能があるのをしってライブラリがいまいち分らなかったのでテンプレートを使いました。
■Dreamweaver便利
■テンプレート便利
【Javascriptとの出会い】
最初に本やで立ち読みした本に、「プログラムをやってみよう」ということでJavascriptの事が書いてありました。
なので、自然とプログラムの最初のさわりがコレになっただけなんですね。
でも、アラートを出したりとかばっかりで、面白くありませんでした。
インターネット黎明期からのネットユーザーなのですが、「最近よく見るページが移動しないのにページの中身が切り替わるやつかっこいいよな」と思って「ページ遷移しない 読み込み」で検索をすると、Ajaxという文字を見つけ、「ajax 入門」で検索してトップに出たサイトでAjaxの概要だけ調べて、「ajax 簡単」でprototype.jsとjQueryの文字を見つけて「ああ、jQueryってよく見るな」というのがjQueryとの出会いでした。
「最近よく見るページが移動しないのにページの中身が切り替わるやつ」は、非同期通信という名前でした。
jQueryを使うと、下記のように1行コピペするだけで外部のHTMLを読み込む事ができました。
--------------------------------------------------------------------------
var http = $.get("abc.html",null, function(data) {$("#main").html(data);});
--------------------------------------------------------------------------
すごい簡単。最初は意味は分りませんでしたが、目的の事ができればそれで良いので次に進みました。
■jQueryすごい
■非同期通信かっこいい
【Perlとの出会い】
jQueryがちょこっと書くとダイナミックに色々変わってくれるので、日々いろんなプラグインを探して遊んでいました。
でも、作りたかったのは検索システムだったのを思い出し、また近くの大きな本屋に。
検索するパソコンで”プログラム 検索”で探しだした棚に行くと、「CGI/Perl」の本棚でした。
大量にありすぎてどれをかって良いか分らなかったので、いくつか立ち読みして家に帰り、「CGI/Perl 入門」で検索すると
このページにたどり着きました。
Windowsだった為、ActivePerlを入れていくつかプログラムをやりましたが、これがまた面白くないんですね。
すごい地味で。このPerlをさわった最初の1日は正直かなり苦痛でした。
その後、”AV女優の検索システムって不動産の検索システムに似てるな”って思って「CGI/Perl 不動産検索 無料」で検索したら、http://www.yumemaboroshi.net/ってサイトが引っかかって、ここのおかげでかなり進みました。
先人が作った大量のプログラムがダウンロード出来るサイトなんですね。
【PHPとの出会い】
いくつもダウンロードしては、サンプルと中身を見てを繰り返してたら、Perl/CGI以外にPHPがたくさんありました。
どう違うのかと思い検索したら、PHPはすごい叩かれてて、Perlがえらいみたいに書いてあったのですが、叩かれてる理由がいまいち理解できませんでした。
結果PHPを使う事になったのですが、その大きな理由は、DreamweaverでPHPが開ける。なおかつHTMLファイルをそのまま使うテンプレート機能のプラグインがあったという事でした。
PHPでテンプレートを使うには、Smartyというプラグインを使えば良いということが分って、「Smarty 入門」で調べて、いくつかのタグを覚えました。
実際にSmartyで使ったタグは、{$変数}と{if}{/if}と{foreach}{/foreach}の3つだけだと思います。
色々高機能らしいのですが、まあ目的は達成できたのでいいか。と。
PHPの検索プログラムは、HTMLファイルでボタンを押すと、テキストファイルに書いてある内容を、表示してくれる簡単なものを作って、そこに肉付けしました。
（最終的にテキストファイルがSQLサーバーになりましたが。）
■PHPはDreamweaverと相性がいい
■Smartyでやると見た目が壊れない
【Rubyとの出会い】
簡単にPHPで動くプログラムが出来たので、実際に女優のデータを登録しようと思い、DMMに行きました。
DMMのサイトを見ていると、いったい何人いるんだってくらいAV女優が登録されています。
数人集めてみて「こりゃぁ。無理だな。」と途方にくれて1日を過ごしました（笑）
次の日、「ホームページ 自動 巡回 プログラム」とかで検索して、ボットとクローラーという存在を知りました。
自動巡回で拾ってくるのは、どちらかというとクローラーと呼ばれるそうで、「クローラー 作り方」で調べたホームページに、Perl+LWPモジュールで似たことができるということで、とりあえずペタペタとソースを貼ってうごかしてみたら、まあなんと簡単に取れました。
しかし、取ってきた後に気がついたのが、HTMLファイルをそのまま取ってきても結局手動でコピペの必要があり、あんまり意味がない。と。
で、もう少し調べると、「WWW::Mechanize」を使うといいよって書いてあって、Mechanizeで調べたサイトをみるとrubyを使ったサイトが出てきました。
rubyのサンプルがすっごい短くてわかりやすかったので、Perlは苦痛だったのでRubyにしようと、このときRubyを始めました。
■Rubyきれい
■Mechanize簡単
【デザインは・・・】
はてなブックマークのコメントで、DoCoMoのサイトが元ネタと書いてありましたが、ハズレです。
デザイナーの友人が居て世間話でどうやって作るの？って聞いたら、「まあ、パｋ、じゃない。参考にするよ。他社のを。」っていうもんでどうやって見つけるか聞いたら、あるんですね、綺麗なデザイン集めたサイトが。http://www.ikesai.com/ここでたくさん見ました。
それから、スライダーのインターフェースは、「selectToUISlider」jQueryのプラグインそのまま使ってます。
■世の中のデザイン全てぱｋ（略
■selectToUISliderかっこいい
という感じで、ほんとにちょっとずつ進みました。
楽しかったですね。Perl以外は。なんであんなに読みづらいんでしょう。
と、またもや長くなりすぎたのでこの辺で。
DMMのクリックが10万クリックほどあり、その結果、購入された金額が、なんと！
報酬額が245円。
----------------------
今回のサーバーダウンは結構深刻でなかなか復旧が出来ていません。。。
申し訳ないです。
----------------------
http://twitter.com/#!/kanzen21_com
----------------------
自分はポールグレアムじゃないけど、プログラミングをする事と絵を描く事は同じようなものだと考えているんだよね。
まぁ、個人的な主観だし感覚的に共通点があったとしても僕だけにしか通じない部分もあると思うからそんなに真剣に受け取らないでねｗ