C#プログラマからみたPython 変数の基本編
変数宣言の方法
Pythonの変数は代入を行うことで宣言する。
// C# int hoge = 10;
と
#Python hoge = 10
は変数を宣言するという意味では同じ。
JavaScriptの「Var」や、Perlのように「$Var」というような予約語はない。あくまで代入を行った場合に変数宣言とみなされる。
代入で変数宣言ってことは…
代入するたびに別物が生成されるかっていうとそうでもなくて。（不変型の変数とかそういう話はここでは置いておく…。）
代入しようとしているスコープ内に、代入先の変数が存在すれば宣言とはみなされない。
のだけど、スコープの考え方もC#とかとは結構違う。
例えば以下のコードの場合…
# 変数を宣言する a = 1 b = 2 def hoge(): # 関数内からは親のスコープの変数bを見ることが出来ないため、 # 以下のbは変数を新規に宣言している。 # ここで宣言した変数はローカルスコープとなるので、上位の変数bには影響を与えない b = 10 # この場合はbが既に（先頭あたりで）宣言済みのため、変数bの値が200に変わる b = 200
C#だと、このような場合は親の変数bの値が変更されるし、宣言しようにも親のスコープで宣言されている変数名と同様の変数名を下位のスコープで利用できないので、マジでかって感じなのだが、Pythonの言語仕様上そうなので納得せざるをえない('A`)
型について
上のコードを見て、「型の宣言が無くね('A`)?」って思った人がいるかもしれないけど、Pythonはいわゆる動的言語なので、実行時に型が決まる。
C#やJavaなどの静的言語ではコンパイル時に常に型が決まるのに対し、Pythonでは実行時にならないと型が決まらない。JavaScriptなんかと同じ。
余談だけど、C#の…
var hoge = 10;
はあくまで型推論で、動的に型が決まっているわけではないので注意。
変数名について
Python3からは日本語を利用することが可能。
とは言えPython2まではアルファベットと数字のみだったので、日本語変数名の文化がないはず。よって、基本的には英数字のみで変数名を決める。
なお、変数名を数字から始めることは出来ない。これはC#と同じ。
アルファベットの大文字と小文字は区別される。これもC#と同じ。
まとめ
Pythonのインデントにハマる…
はじまり
みんなのPythonのサンプルコード写経中。
インデントの位置を間違えたので、Macの冷却ファンが大変なことに…(´・ω・`)
なお、このサンプルはみんなのPython第３版、チャプター07（P234）、ジェネレーター関数の定義のサンプルコードです。
間違い
def get_primes(x = 2): while True: for i in range(2,x): if x % i == 0: break else: yield x x += 1 i = get_primes() for c in range(10): print(next(i))
！！注意！！
これは実行すると帰ってきません。
正しい
def get_primes(x = 2): while True: for i in range(2,x): if x % i == 0: break #ここのインデント位置が違う！ else: yield x x += 1 i = get_primes() for c in range(10): print(next(i))
forの中の「else」文のインデント位置だけが違うのだけど、
頭のなかには「else」と言ったら「if」という風にこびりついているので、
このように間違えた次第…。
よーく読むと、「if」に「else」をくっつけてしまうと、
無限ループしてしまうので、間違いなことは明白なのだけど。
MacでREALFORCE91UBK-Sを利用する
会社でRealforceを使っていましたが、諸事情により自宅に持ち帰ることになりましたので、
自宅のMacで利用することにしました。
以下の手順はその際に行ったメモになります
Seilというアプリをインストールします
以下のリンク先からパッケージをダウンロードし、インストールします。
https://pqrs.org/osx/karabiner/seil.html.ja
Seilの設定画面を起動します
ミッションコントロールなどから起動すると、設定画面が開きます。
なお、アプリケーション自体は常時起動している状態です。
リーン開発の現場 書評
優れたプロセスは設計によって生み出されるものではない、進化の結果として現れる。
ソレを体現した本と言えます。
この本には、筆者がぶち当たった壁に対して実践したプラクティスが詰まっています。
なので、ターゲットとして
アジャイル、リーンの基本的な部分は既に分かっている方を対象としており、
理論ベースではなく、わりと実践ベースで語られていることが多いです。
こんな人にオススメ
アジャイル、リーン開発の基本的な方法は分かった、
でも実際のところどうなの？
アジャイルをやってみた。
でも思ったほどの効果が出ない。
こういう悩みを抱えている人には、
この本は一定の回答を出してくれると思います。
刺さった文
管理するバグの数を制限することでクライアントとの間に信頼関係を築ける。
数ヶ月修正するわけでもなく、ただ登録しておくよりかは、短いバグ一覧だが確実に修正されるほうが良い。
修正される見込みがない場合、いつかは修正されるはずというような誤った期待を抱かせないように、はじめから修正する気はないと伝えている。
9.4 バグを可視化する
コレは個人的には盲点でした。
ダラダラと書いてあるだけのバグ票よりかは、確かに確実に修正されるものだけを記載したほうがお互いに良いと思います。
ただし、「直さなければいけないものは直す」のが前提ですけれど。
「ものごとがそうなっているのは、そうなったからだ」
ー ジェラルド・ワインバーグ
「あなたがこれまでにやってきたことをやっているだけならば、これまでに得たものしか得られないだろう」バグの根本原因を分析してみると、バグは本当の問題ではないことに気がつくはずだ。
バグは症状に過ぎない。
プロダクトのバグはプロセスのバグから生み出される症状だ。
9.5 繰り返し発生するバグを防ぐ
バグが発生した時に、バグを（結果的にでも）埋め込んだプログラマを責めるのではなく、
チーム全体の責任と考えるのならば自ずとこうなるのだと思います。
プロセス改善ワークショップには、僕達の仕事のやり方を明確にして改善する狙いがある。
プロセス改善のための意思決定は、変化を起こすことを意味している。
10.2 プロセス改善ワークショップ
振り返りのこと。
何回も振り返りをやっていると忘れがちだけど、振り返りの目的はつまりそういうこと。
完璧な解決策を探そうとしてもムダだ。
その代わりに小さく少しづつ出来る改善点を探して改善を実験だと考えてみよう。
優れたプロセスは設計によって生み出されるものではない、進化の結果として現れる。
16.2 実験しよう
小さく初めて振り返りつつ繰り返す。
リーン・スタートアップにも書いてありましたね。
失敗への恐怖が改善の最大の敵だ。
本当の失敗はひとつしかない、それは失敗から何も学ばないという失敗だ。
16.3 失敗を抱擁しよう
失敗から何も学ばない人や組織って多すぎると思うの。
大抵の人は変化を好む。でも、他の誰かに変えられることは好まない。
あなたからの提案を拒むようだったら、それは問題が何か明確にできていないのだろう。
もしくは、間違った問題を解決しようとしているのかもしれない。変化の提案を自分ではやらない作戦がある。
提案する代わりに、考え認識した問題を可視化する。問題の影響を受ける人を巻き込み、
解決策を提案してもらう。自分自身が出したアイデアなら変化を受け入れやすいはずだ。
16.6 関係者を巻き込もう
提案してナンボだと思っていたのでコレは盲点。
確かに誰かが提案した内容を飲み込むよりも、
自分で提案したものの方が、
問題を把握している文変化も受け入れやすい。
これはおいおい実践してみたいと思います。
ASP.NET MVC実践プログラミング―.NET Frameworkによる標準Web開発技法 書評
ASP.NET MVCを勉強し始めて、最初に気がつくことが、
MVC関連の技術書（和書）の少なさと、
体系立って説明されたWebがないことだと思われます。
そこで登場するのが、
この本なのですが、いかんせんMVC１を対象としているため、
現在では使えなくなっている部分が多いです。
例えば、
この本ではレンダリングエンジンがaspxを使用しているが、
最近ではRazorエンジンを使用することが多い。
Ajaxについても、
昔は「MicrosoftAjax.js」、「MicrosoftMvcAjax.js」などで提供されていたようだが、
MVC4となってからは、knockoutやjQueryに取って代わられている。
最新のフレームワークのバージョンがMVC4、MVC5が殆ど公開待ちというような状況で、
この本一冊読んで、MVCのアプリケーションが作れるかというと、
（フレームワークを使いこなしたプログラミングをする）という観点では、
かなり厳しいかなというのが正直なところです。
とは言え、
基本的なフレームワークのアーキテクチャ部分については、
それほど（現時点で）大きな変更もまだないので、
参考に出来る部分は多いと思います。
私の場合は、Webフォームからの移行組なので、
ルーティングの部分がイマイチ理解できなかったのですが、
この本を読んだことで一定の理解を得ることが出来ました。
ASP.NET MVCを最初に勉強する和書、
かつ、割りと時間のある方にならオススメできる本。
ただし、この１冊だけではダメで、最近のフレームワークを使用するなら、
ネットなり他の書籍なりで補完してやる必要があります。
時間がない方は洋書ならば、
オライリーなどMVC関連の書籍が多く出ているため、
そちらを読んだほうが時間を短縮できるはず。（読めるなら）
アーキサイト メカニカルテンキーレスキーボード茶軸 インプレッション
半年ほどアーキサイトのメカニカルテンキーレスキーボードを使用したのでインプレです。
ちなみに私の職業はプログラマーなので、
コードやドキュメントなど、
文章を打つことのみに使用しています。
ゲームなどでは使用していません。
また、今回のアーキサイトのキーボードが、
初めて買った別売りのキーボードとなりますので、
他の「東プレ」や「FILCO」などとの比較は出来ません。
よって、以下の内容はDELLのPCについてくる付属品のキーボードとの比較になります。
打ち心地
DELLとの比較ですが、非常に打ちやすいです。
打鍵の際に、分かりやすく軽く打てるので、
DELLのキーボードと比べて疲れにくいという効果もあります。
また、キーボード自体の高さも計算されて作られているようで、
確かにパームレストなしでも打ちやすいです。
DELLを使用していた際には、
パームレストを使用していましたが、
こちらのキーボードを使用してからはパームレストは使っていません。
打鍵音
メカニカルの宿命だとは思いますが、
DELLとくらべて音は大きいです。
私は軽いキータッチを好みますので、
最初は青軸を買おうかと思いましたが、
店舗で試打した際に、
あまりの大きさに青軸を止め、
茶軸に変更した経緯があります。
しかし、茶軸とはいえやはりDELLキーボードよりはうるさいです。
そう、初日に職場に持って行き使用した際に、
周りから「何だ何だ？」と見られるぐらいには…。
何故テンキーレスか？
テンキーレスの場合、キーボード本体の横幅が狭くなり、
キーボード → マウス と手を移動する際の移動距離が短くなります。
また、私の日常の使い方として、テンキーはほとんど使用しません。
テンキーをあまり使用しない人でしたら、
テンキーレスのメリットがデメリットを上回ると思います。
ギミック
CapslockやScrollLockのライトが非常に明るく、
点灯していれば画面を見ている時でも気がつくことが出来ます。
誤ってCapsLockを入れてしまった時などに早く気がつく事ができます。
また、PCの電源を入れた時にこのランプ2つが点灯します。
特に意味はない（通電確認？）とは思いますが、
単純にカッコイイです。
耐久性
まだ半年程度しか使用していませんが、
特に不具合無く使用できています。
デメリット
あまりデメリットはないですが、あえてあげるならば。
エンターキーから「キュッ」というような音がたまにします。
エンターキーの上あたりを押した時になるようです。
ただし、音がするというだけで、入力自体に支障はありません。
※先日キーボードの分解清掃を行ったところ、
上記の音も収まりました。もしかしたら何かゴミが挟まっていたのかもしれません。
また、白で印字された文字が非常に汚れやすいです。
数日も使えば、よく使う箇所の文字の印字が汚れてきます。
加え、汚れてしまうとなかなか落ちません。
（私は諦めました）
神経質な方はカバーを掛けるなどしたほうが良いかもしれません。
テンキーレスキーボードということもあり、
BackSpaceキーと、Insertキーの間がかなり狭いです。
慣れの問題もあるとは思いますが、
BackSpaceキーを押したつもりが、
Insertキーを押してしまうことがたまにあります。
まとめ
値段の割には質の高いキーボードだと思います。
更に高級なキーボードを知っている方からすれば、
多少の物足りなさを感じるかもしれませんが、
エントリーモデルとして考えた場合、
コレ以上のメカニカルキーボードはないような気がします。
メカニカルキーボードってどうなんだろうなーと思っている方には、
最初の１台としてオススメできます。
付属品のキーボードとは世界が変わりますよ？
コードコンプリート書評
2013年の今から見ると、内容が流石に古くなってしまっている。
本書のテーマとして、
「ソフトウェアコンストラクション」と「品質の良いコード」という２つのテーマが掲げられているが、「品質の良いコード」部分はともかく、「ソフトウェアコンストラクション」面では、
大規模なウォーターフォール、豊富なドキュメント、擬似コードを書いてからコードを書くなど、
最近のアジャイルな開発手法とは咬み合わない部分も出てきている。
よって、今あなたが働いている職場が、
ゴリゴリのアジャイルや、
時代の最先端を走っているWeb系の会社であるような場合は、
「ソフトウェアコンストラクション」に書かれていることは、
古典を習っている意味に等しいのかもしれない。
また、
あなたのプロジェクトが、
３人月を３人で１月とか、
小さいプロジェクトに従事している場合も同じように古典となる可能性が高い。
（アジャイルなプラクティスを導入したほうが良い）
ただし、
あなたが働いている職場が、
いわゆるSIerに代表されるような所で、
プロジェクトの進め方といえばウォーターフォールで、
200人月のプロジェクトを10人で20ヶ月で進めている。
ようなやり方をしている職場ならば、
リーダブルコードの「ソフトウェアコンストラクション」の章は、
役に立つ部分が多いはず。
また、「品質の良いコード」部分についても、
最近出た「リーダブルコード」と内容が重複している部分が多いので、
リーダブルコードを読んだ後だと、「おっ。これは…！」と思う部分が少ない。
※当たり前だけど「コードコンプリート」が被っているのではなく、
「リーダブルコード」が被っている。
リーダブルコードは読みやすいコードを書くための本で、
コードコンプリートは品質の良いコードを書くための本なので、
「防御的プログラミング」など、リーダブルコードでは網羅されていない部分も、
あるにはあるのだけれど、
コードコンプリートという技術書に興味を持ち、
こんなマイナーなブログの記事まで見て頂いてるあなたのような、
割りと勉強していると思われる人から見ると、
「それって当然だよね」という感じで、あまり新しい発見がないかな、
と言ったところ。
まとめ
新卒のルーキーや、２〜３年目ぐらいまでの方は必読。
４〜年目ぐらいの方だとリーダブルコードを読んでいるならば、
あまり得るものはないかもしれない。
しかも上下巻合わせて１万円以上、1000p超なので、
バキバキのウォーターフォールでやっている人でも無ければ、
少し厳しいかなと言ったところ。
読むか読まないかであれば、読んだほうが良いに決まっているんだけどね。
