Wihndowsで、Pythonの環境構築をしましょう。
ということで今回おすすめするのが、Canopyです。
Page 5 of 11
Pythonのコーディングスタイル
Pythonで一般的なコーディングスタイルがあるそうです。
http://pep8-ja.readthedocs.org/ja/latest/
PEP8というそうです。その中でも重要そうなものを簡単に紹介したいと思います。
- インデントは半角スペース4つ、タブは使わない!
- 79文字以下で文字を折り返す
- プログラムのまとまりが分かるように適せん空行を入れる
- 文字コードはUTF-8を使う
- 「”」を使うか「’」を使うかは統一する。(個人的には「’」で統一した方がいいかも)
- 関数の説明には「docstring」という形式を用いる。(後述)
- 演算子の前後、コンマの後ろにはスペースを入れる。括弧の内側にはスペースを入れない。
- 命名規則について
- モジュール名:全て小文字の短い名前
- クラス名:CapWords 方式(単語の頭文字を大文字にしてつなげる)
- 関数名:小文字のみ、必要に応じて単語をアンダースコアで区切る
- メソッド、インスタンス名:小文字のみ、必要に応じて単語をアンダースコアで区切る
- 定数:全て大文字、必要に応じて単語をアンダースコアで区切ります
- メソッドの第一引数:常に「self」
という感じです。
=docstringとは=
Python的お作法に則って書かれた関数につける説明。
3重クオート「”””」を用いて記述する。以下、例。
[python]
def konoyarou(n):
"""引き数の入力された数値の分だけ「このやろう!」
を連結した文字列を返す。
param int : Number of repetitions 繰り返す回数
return str : Concatenated string 連結された文字列
"""
return ‘このやろう’ * n
[/python]
ここに詳しい説明があるので興味のある方はどうぞ。
=docstringの説明終わり=
ということで、これらを守ってPythonをコーディングしましょう!
就職先の選択に迷ったら(Web系エンジニアの話)
現在どこの企業に就職しようかなど迷っているわけですが、そんな悩みを先輩のエンジニアに相談したところなかなかありがたいアドバイスをいただきました。
以下要約。
選択肢に迷ったときどれを選ぶか
選択肢に迷ったら「多くの人が選ばない方」を選んだ方がいい。
例えば君が大企業のA社とベンチャーのB社で迷っていたとする。
100人に聞いたら90人以上は「A社がいい」と言った場合、B社の方を選択した方がいい。というのも、普通の人ならA社とB社が同等の選択肢にならないところを、君は両者とも同等の選択肢としてみることができている点で、すでに才能を持っていると言えるからからだ。
今回の例に限って言えば、君の「リスクの許容範囲が広い」ということになるかと思うが、リスクをとれればリターンも大きくなる可能性がある。
選択するときの一つの指標にしてみたらいいかもね。
ふむふむφ(・ェ・o)~メモメモ
という訳で、今後の人生で役立てようかと思います。
またWeb系エンジニアのキャリア的な話も面白かったので、ここに書き残しとこうと思います。
Web系エンジニアのキャリア的な話
Web系エンジニアは2~3年ほど真面目にやっていれば、他の企業からそこそこいい給料で引き抜きがかかるそうです。
ということで、そのエンジニアが所属している会社もそこそこの給料になってくるそうです。
つまり最初の数年間はバリバリとコーディングを行って「自身の技術力を高める」ことに専念した方が良いみたいですね。
ある程度Webサイトとかが作れるようになっていれば、収入に関しては心配することないみたいです。
会社選びにおいてきちんと技術力身に着ける自信があるなら「”年収”は重要な評価軸ではない」ということもアドバイスしていただきました。
おしまい
とてもためになります。
この場をかりて感謝します。
データ分析に重要なこと
最近、研究がなかなかうまくいかず大変です。
この前指導教員に言われたことが、他のことにも役に立ちそうだったので記事書いとこうと思います。
今は論文を書いているのですが、データの分析結果がなかなかまとまらないので以下のようなことを言われました。
分析を行っていると様々なデータが出てくるが、それらを全部用いて結論や結果を記述するのは労力がいるし、そんなことは到底できるものではない。様々データを出すことによって、新しいことが見える場合もあるけれど、自分の言いたいことに対して適切なデータのみを厳選して使用して論文を書かないと、相手にも伝わらず、自分の言いたいことも言えない。
たしかに…。
自分は「出せるデータは全部出す」という教義のもとに今までデータサイエンス的なものをやっていたのですが、論文書いたり発表したりということになってくると本当に慎重に使用データはチョイスしなければなと思いました。
まとめると、研究等でデータを用いる場合は以下の2点に注意することが必要かなという感じです。
- 目的をしっかり固めて、結論までの道筋をきちんと用意する
- 必要なデータな厳選して、無駄なデータは出さない
Enjoy! データ分析!
英語ができないと…
先日こんな記事を書きました。
[Ruby]配列のデフォルト値を0にする | INFORMATICS FINDER
この記事では、Rubyのデフォルト値を0で初期化するためにはどうすれば良いか
ということを書いていました。
まあ、Fixum#to_iを使ったらいいのではないかということで〆めています。
しかし先ほどこんなものを見つけました。
Can I create an array in Ruby with default values? | Stack Overflow
ちなみに、リンク先はプログラマー用のQ&Aサイトで
「Rubyで配列を作成する際にデフォルト値を設定するにはどうすれば良いか?」
という質問内容です。様々な解答が寄せられています。
わぉ。すでに議論されていたとは…。
しかも4年前…。
to_iメソッドで「0」に初期化できる!すごいこと思いついた!と思ったのですが、とうの昔に既出でした。
まあ、rubyは車輪の再発明も推奨している文化ではあるのですが、4年も遅れた情報を嬉々としてブログに掲載してしまうのはお恥ずかしいあまりです。
英語圏にも目を向けなくてはならないということを痛感しました。
[Ruby]配列のデフォルト値を0にする
どうもこんにちは,Rubyを使っていてハッシュみたいにある要素にアクセスしたときに値が存在しない場合のデフォルト値を設定できれば嬉しいなと思っていたのですが,どうもそういう機能がないようなので,0に初期化する方法を見つけました。
要は無限の要素に対して0で初期化したいわけです。
a = Array.new(,0)
5.times{|i| a[i] += 1}
p a => [1, 1, 1, 1, 1]
みたいなことがしたいわけです。
※もちろんこんな書き方はありません。
ぱっと考え付くのは,if文などを使って条件わけをすることですが,
そんなの全然スマートじゃない!
というわけで・・・
考えてみました。
今回注目したのは,
「nilに対して#to_iを行うと0になる」
という性質です。
これを使って,書くと
a = Array.new()
5.times{|i| a[i] = a[i].to_i + 1}
p a => [1, 1, 1, 1, 1]
みたいにワンラインで書くことができます。
※これはちゃんと動きます。
なので,if文とかで2行以上やりたくないときは使ってみてください。
まあ,2回目以降は数値に対して#to_iメソッドを使ってるのでエレガントではないですね・・・。
2015/9/19(土)追記
後で知ったのですが、Integer#to_iメソッドはselfを返すらしいので
この書き方はあながち間違ってないかもしいれないですね~。
→http://docs.ruby-lang.org/ja/2.1.0/class/Integer.html#I_TO_I
カメとウサギ
今朝のことです。
私は普段自転車で大学に通っているのですが、ボーっと自転車をこいでいたら後ろから来た会社員らしき人に自転車で追い抜かれました。
そして(あ、追い抜かれたなぁ~)などと思いながら、自転車をこいでいました。
そしてふと気付くと、先ほどの会社員がはるか前方にいるではありませんか。
そんなに多くの時間がたったわけでもないのに、二人の差は短時間の間にものすごく開いていました。
そんな体験を通して、これは世の中の色々なことに当てはまるなと考えました。
例えば、勉強などもそうではないでしょうか。
いくら毎日ちょっとずつ進めたからといっても、もともとの学習スピードが速い人と比べてしまうとその差はあっという間にものすごいものになります。
だから諦めととかいう話ではないです。
今回(自転車の差がついてしまったこと)の敗因はどこにあるのでしょうか。
それは、自分の周りを意識しなかったことにあるといえます。
ボーっとすごしていると、気付いたときには”誰か”と”自分”との距離はものすごいものになってしまうでしょう。
常に自分がどの程度遅れているか、どの程度サボっているか、といったことを相対的な目線で見ておくとこが大事だと言えるのではないでしょうか。
「日々視線を上げて、できるだけ広い視野で物事を見ておく必要があるだろう」
そんなことを考えた朝でした。