だてブログ

ねことテクと趣味のブログ

やらかした-滅びの呪文

突然だが"滅びの呪文"というのをご存知だろうか。黒い画面で管理者権限でログインして、
rm -Rf /” と打つと
………
はい、今回はわたしも滅びの呪文を打ってしまった経緯をお話しする。私はこのようなディレクトリ構成で作業をしていた。

username
├── testA
│   ├── test2
│   ├── test3
│   │   ├── testa
│   │   ├── testb
│   │   └── ~username
│   └── test4

“test3"に私はいた。そして”~username"というフォルダが間違えて作られたものだということに気づいた私は、
rm -Rf ~username” と打ってしまった。お気付きの方もいるであろうか 。"~“はホームディレクトリを指す。それは上の図の一番上、”~username"を指す。つまり、上のコマンドを押すと……

username
└──

全て消えた。
今までの作業。
すべて。

自分にはroot権限がないため、管理者にrmしたものを復活させる邪道なプログラムを入れてもらうよう頼んだが、、ダメでした。(リスクもあるため) 原則的にrmしたものは復活できない。それを心から感じました。結局、ローカルやgithubなどに保存したものと他のユーザを参考にして、半分ほどは復活させることができました。
次からは次のファイルをcron使って定期的に打ってバックアップを取ることにします。

#!/bin/bash
chmod 777 ~/.backup 2> /dev/null
rm ~/.backup/backup.gz 2> /dev/null
shopt -s dotglob
tar cfz ~/.backup/backup.gz * 2> /dev/null
chmod 400 ~/.backup

エンジニアは一つの言語に特化すべきかどうか

こんにちわ! 今日は、面白い質問を見つけたのですが、SSL未対応でそのサイト自体に安全が保証できないため、こちらの方で引用-紹介させていただきます。また回答が28件あったため、そのなかでも上位数件を載せたいと思います。

質問 エンジニアは一つの言語に特化すべきかどうか

エンジニアは一つの言語に特化したT字型の成長をするといいと聞きました。 しかし、現場に出ると、プロダクトに合わせてPHP, javascriptなど様々な言語を使うように求められました。 エンジニアとしてのキャリア形成を考えた時に、一つの言語のみに特化させて極めるべきなのでしょうか? それとも知識は浅くても幅広く言語を習得すべきなんでしょうか?

この質問にたいして、様々な意見がありました。

A. エンジニアを雇う立場から言えば、言語はツールであり、適材適所で色々な言語を使いこなすことが出来るエンジニアの方が好ましいのは当然です。「得意な言語がある」ことは好ましいことですが、そのためにその言語に固執したり、客観的な判断が出来ないようでは困ります。私が雇ったエンジニアの中で、Javaが得意でとても優秀なエンジニアがいましたが、Javaが最適でないところにまでJavaを使おうとしたり、Java以外の言語を勉強することを拒否したので、とても苦労しました。理想的には「どんな言語でも2週間でマスターしてやる!」ぐらいの心意気のある(そして実際の実力もある)エンジニアと仕事をしたいですね。
A. 特化すべきではないと思います。 言語は流行もあります。そして、エンジニアとしての寿命はそれほど長くないです。結局プログラミングは表現が変わっても原則は変わりません。そういった共通した根本的な考え方をマスターすれば、他の言語習得にそれほど時間はかかりません。それ以上に、言語よりも原則をマスターして設計が出来るようになり、エンジニアからより上流に移っていくことが必要だと思います。ただし、組み込み系などのニッチなトコについては尖がってずっとエンジニアとしていくのもありだとは思います。
A. 多分エンジニアとしての質やレベルは、どの言語かというより、エンジニアリングとして何をすることが出来るのかによって測られるのだと思います。そういった能力を高めるには言語を一つ決め打ちして掘り進むのがいいと思います。一つの言語で到達した点に、他の言語でたどり着くのはそれほど難しくないですからね。 なので結論としては1つの言語のみ特化、会社などの実情を鑑みると、今やっている言語を本気で極めようとしたほうがいいという答えなのではないでしょうか。ちなみに、個人的には、サーバーサイドの重い処理はC++(HadoopだとJava)Webサーバー全体としてはRuby,クライアントサイドは言わずと知れたJavaScript,学術論文や機械学習分野だとPythonやR,iOS開発だとObjectiveCでやるのが一番楽な気がしているので、強要されなくても自由に出来るのであれば言語を変えます。結局言語の差なんて、文法的には方言程度の差しかないので、ライブラリの充実度など含め、そのドメインで多く使われている言語を使うのがデバッグなどを含め開発が速くなると思います。我が道を行くとGoogle先生が助けてくれないですからねwちなみに、別の話として、その分野のトップになるためにマイナー言語を学んで高速に情報発信していくという戦略はありかと思います。
A. 言語という意味では、言語に固執するなという部分もありますが、言語に紐づくコミュニティにコミットするという意味ではある程度、言語を絞ったほうが良いと言う部分もあります。僕がこのレスを読んだ人に希望するのは、他の言語をバカにしない人材になって欲しいということですね。昔ならVB、今ならPHPがそういう対象になりがちですが、その中でも、市場ではPHPは何故支持されているのか?!を適切に把握し、もしRubyPerlが好きだったとしても、普通にその言語も使えるようになって欲しいと思います。処理系の人に言うと怒られるかもしれませんが、言語というのはエンジニアリングという意味では所詮、何かを実現するための手段の一つでしかない、という事実はあります。また言語のトレンド一つで、成功したサービスの歴史あるコードがレガシー技術扱いになってしまうという業界としての問題もあります。技術者は、トレンドにこだわるよりも、あなたの本当の価値はそこじゃないというところを意識し、ビジネスやアウトプットの質や安定性にコミットして欲しいです。
A. 業務及び趣味でPythonを使っていますが、いろいろな言語をかじっては覚えたりしています。自分が思うに、一つの言語に特化するためには、むしろ他の言語を勉強する必要があると思います。著名なハッカーの人々は、例えば「一年に一つのプログラミング言語を学ぶべきである」と述べたり、あるいは半ダースの言語を覚えるべきである、という話をしています。参考までに、そういったエッセイを載せておきます。 http://www.yamdas.org/column/technique/21-daysj.html http://itpro.nikkeibp.co.jp/article/COLUMN/20070618/275142/ プログラミング言語には、さまざまなパラタイムがあります。例えば、自分がかじった範囲ですと、関数型としてHaskell、宣言型としてPrologなどが挙げられます。これらの言語は、いわゆるPHPPythonといったような手続き型以外のパラタイムを教えてくれます。そうすると、如何に自分が勉強している言語が「特殊なものの」の一つであるということに気がつかされまず。そして、またこれらは「この言語はこうするべきだ」という思い込みを打ち砕き、違うアプローチを教えてくれます。これらが実際的に、業務として、ようするに「技術を金にする」という意味で役に立つかどうか、というところは疑問ではあるでしょう。しかし、自分は上記の言語を勉強した所で、ポンコツでありながらも、「こういう考えをするとどうだろう」と考えられるようになったように感じます。それは確実に業務として生きているように感じます。また、エンジニアとしてのロードマップとして、どのように生きるのか。一つとして、Webサービスをたち上げる、といったときに、一つの言語でおさまることはほぼありえません。最近、自分でもサービスを立ち上げたのですが、Pythonの他に、SQLであったり、クライアントJavaScriptであったり、それらをつなぐShellScriptへの理解をせまられて、必死で覚えています。たぶん、多くのスペシャリストも、上のように、「母国語(メインの言語)」を覚えながら、他の言語で幅を広げるという形を取っているような気がします。もちろん、ただの器用貧乏になる可能性もありますけどね、自分のように :)
A. 高水準言語を使うエンジニアであれば、答えとしては、すべきではないです。まず、大抵の高水準言語のプログラミング言語は使った言語と同じ世代言語で、親となった言語があります。まず、その親言語の理解が必要です。例としてはC#の親言語はC++,phpの親言語はC++などとなります。次に同じ親を同じとしている他の言語の理解が必要です。(以降、類似言語と省略)これら、親言語と類似言語は、文法の違いもありますが、根幹として、設計思想の差がありますので、同様の仕組みを作る場合、記述する命令の差が出てきます。これら差がオブジェクト指向が使える高水準言語の場合、全体的な設計に大きく関与してきますので、バグ、生産性、セキュリティといった要素に大きく関わってきます。全く系統の異なる高水準言語の場合は、上記の差異がわかりづらいですが、同様の差がありますので、よく学んで下さい。

以上のように賛否両論さまざまな意見がありました。 わたしのゼミの先生もそうでしたが、多くのプログラマーはより幅広く言語を学ぶべきという人が多いとおもいます。 しかし、学生の短い時間でどれだけの言語を習得できるかと考えると、一つの言語のスペシャリストになろうとするのも悪くはないのかな?と私は思っています。 ちなみに、わたしはPython超大好きっ子なので、(ほかも必要最低限学びながら、)すくなくとも今年はPythonオライリー本全部読破しようと目論んでいる勢いで学んでいます。 好きな言語を好き放題やれるのは学生のうちだと思いますし、こだわるのもいいのかなと思っています。

Pythonを選んだわけ

こんにちはー。 今回は今勉強している"Python"というプログラミング言語を選んだわけとその他周辺ネタを触りつつ、自分へのメモ代わりに書いていこうと思います。

Pythonって?

そもそも"Python"は様々な分野で利用されている、汎用型スクリプトプログラミング言語です。
そもそもプログラミング言語テキストエディタに書けばすぐ実行できるスクリプト言語と、機械語に変換することで初めて発動するコンパイラ言語に分かれます。(難しいので詳細割愛)
わたしは比較的学ぶのが簡易なスクリプト言語、かつWeb(サーバ)で使えてそれでいて汎用的な言語を探していました。当てはまるメジャーな言語として、昔から掲示板やブログなどで利用されてきた"Perl", HTMLに組み込むことにより、Webではかなりの速さを誇る"PHP", そして日本人の作った完全オブジェクト指向かつわかりやすい日本で大人気"Ruby", そして世界ではかなりメジャーなのに、日本では流行っていない悲しい"Python"(笑) 日本ではRubyが流行っているためPythonは流行らなかったそうな。おかげで資料やQ&A探すのも一苦労。

ではなぜPythonを選んだのか。

Perl, Ruby, Pythonこの3つはよく比べられていて、あるプログラマはこの3つをプログラマの3大美徳にたとえて比較しています。

Perlハッカー小飼弾氏が語った
Python as a Foreign Language」"より

  • Laziness(怠惰)  → Perl
  • Impatience(短気) → Ruby
  • Hubris(傲慢)  → Python

『Laziness(怠惰)』は、100回同じことを繰り返すくらいだったら、10の手間でプログラムを書いて簡単にすませてしまうというもの。この分野で一番強いのが、Perlだと思います。

次が『Impatience(短気)』です。これは、要するにコンピュータが『短気』になるということ。『高速なCPUもっているのに何もしていないじゃないか』といわんばかりに、コンピュータもこき使う気性が一番マッチしているのが、現在だとRubyかなと思います。例えばRubyでは文字列とか数値ですとかが手元でガンガン拡張する流儀がある。そんなに待たずにできる。それによりRuby on Railsも出てきて、Rubyはこれでブレイクしたわけです。

『Hubris(傲慢)』とは『神罰が下るほどの過剰な自尊心』、そして『人様に対して恥ずかしくないプログラムを書き、また保守しようという気質』。これはやはりPythonでしょう」

Pythonは傲慢な言語と彼は仰っていました。どういうことなのか。
「人様に対して恥ずかしくないプログラム」というのがPythonのポリシーで、Pythonは基本的に(程度の差はあります)プログラミングのスキル次第でコードの長さが変わることはあまりないです。 わたしが少しかじってみた感じ、Pythonはコードの長さよりも読みやすさを重視している感じがありました。正規表現なども一応ありますが、見やすさが犠牲になるくらいならわかり易く冗長に書いてみるほうがいい。そういった特徴もあると思います。
Pythonは読みやすさ-「可読性」を重視している言語なのです。

その可読性の特徴にインデント下げによる見やすい表現技法があります。Pythonではwhile,for,if.def(関数), class(オブジェクト)などでは、行末に:をつけて、次の行からは8バイトインデントを開けて書かなければならないのです。それによるカッコなどは使わないため他言語よりカッコが少なくなり、インデント下げも加わり独特の見やすさを手にしたのです。(まぁでも関数やリスト、辞書などでカッコは使います。)

その可読性はそのまま保守性にもつながります。保守性は作成したずっとあとで自分もしくは他人が見ても、コードの居場所がすぐにわかり、書き直しやすいことが重要です。Pythonは見易く、オブジェクト指向などにも対応していて、コメントもかなり推奨されているので比較的保守性も高いです。

またPythonでは独自の思想をいつでもコマンド一つで見れるようになってます。(“Zen of Python”) “Zen"は日本の禅でPythonプログラマが持つべき心構えを簡潔にまとめています。

$ python

>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
醜いより美しいほうがいい。

Explicit is better than implicit.
暗示するより明示するほうがいい。

Simple is better than complex.
複雑であるよりは平易であるほうがいい。

Complex is better than complicated.
それでも、込み入っているよりは複雑であるほうがまし。

Flat is better than nested.
ネストは浅いほうがいい。

Sparse is better than dense.
密集しているよりは隙間があるほうがいい。

Readability counts.
読みやすいことは善である。

Special cases aren't special enough to break the rules.
特殊であることはルールを破る理由にならない。

Although practicality beats purity.
しかし、実用性を求めると自然さが失われることがある。

Errors should never pass silently.
エラーは隠すな、無視するな。

Unless explicitly silenced.
ただし、わざと隠されているのなら見逃せ。

In the face of ambiguity, refuse the temptation to guess.
曖昧なものに出逢ったら、その意味を適当に推測してはいけない。

There should be one -- and preferably only one --obvious way to do it.
たったひとつの冴えたやりかたがあるはずだ。

Although that way may not be obvious at first unless you're Dutch.
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。

Now is better than never.
ずっとやらないでいるよりは、今やれ。

Although never is often better than *right* now.
でも、今"すぐ"にやるよりはやらないほうがマシなことが多い。

If the implementation is hard to explain, it's a bad idea.
コードの内容を説明するのが難しいのなら、それは悪い実装である。

If the implementation is easy to explain, it may be a good idea.
コードの内容を容易に説明できるのなら、おそらくそれはよい実装である。

Namespaces are one honking great idea -- let's do more of those!
名前空間は優れたアイデアであるため、積極的に利用すべきである。

この規約は、Pythonプログラマだけでなく、全プログラマが守るべきものなんじゃないかなと私は思います。

もちろんPerlRuby,PHPにもそれぞれいいところはありますが、Pythonは初めて学ぶ言語としては比較的学び易く、またプログラマとしての暗黙の規律、常識も理解できる言語なのではないかなと思っています。速さやコードの短さも大事ですが、わたしはそれよりも可読性のほうが大事だなと思っています。まだまだ勉強中の身ですが、書いていてすごくシンプルで楽しいです。 ただまぁ日本の資料や文献、などが他と比べて少ないのが残念です。日本でもこれから伸びてくるとは思うんですけどねー。