組み込み型一覧
組み込み型 + 数値型 | + 整数 | + 長整数 | + 浮動小数点 | + 複素数 + シーケンス型 | + 文字列 | + ユニコード文字列 | + リスト | + タプル + マップ型 | + 辞書(ディクショナリ) + ファイルオブジェクト
参考 http://www.python.ambitious-engineer.com/archives/128#i-3
文字コード
文字コードみたいなのって意外に重要だったりすることが多い。
文字コード
文字コードとは、コンピュータ上で文字を利用する目的で各文字に割り当てられるバイト表現。
(符号化)文字集合と(文字)符号化形式
文字集合は等しいが符号化方式だけが異なる場合と、それぞれ異なる文字集合を同じ符号化方式で扱う場合がある。
日本語の場合
日本語には JIS X 0208 というJIS企画の文字集合に対して、 ISO-2022-JP (JIS コード)・EUC-JP・Shift_JIS など複数の符号化方式が対応している。
Unicodeの場合
Unicodeは符号化文字集合。符号化形式はUTF-8やUTF-16など複数種類存在する。
Pythonの場合
私の環境(Mac上のPython3)ではデフォルトの文字コードがUTF-8になっていた。だからWindows上でコードを使い回す場合にはUTF-8の指定が必要だったのか。
Gitチェックアウトコマンド
本当に今更なんだけど。。。チェックアウトコマンドには2通りの使い方がある。
ブランチの切り替え
複数ブランチ間の切り替えに用いる。
ワーキングツリーへのファイル展開
ワーキングツリーで編集したファイルを差し戻す場合に利用する。
# コミット「6f87gs1」のtest.pyを、ワーキングツリーに展開する場合 git checkout 6f87gs1 test.py # HEADのtest.pyを、ワーキングツリーに展開する場合 git checkout HEAD test.py # ステージングエリアのtest.pyを、ワーキングツリーに展開する場合 git checkout test.py
クラス設計雑記
最近スクリプト*1に機能追加してプログラム*2を作成する機会があった。
最初はなんとなく実装しながら必要に応じてクラスを追加していったが、途中からロジックをシンプルにするために、あちこちのクラスのメンバーの修正が発生してしまい、結局最初に書いたコードの3〜4割程度を書き直すこととなった。
原因はクラスが3つ程度ならばクラス設計なしでもいけるが*3、クラスが5つ以上になるとクラス設計がないと厳しいからだと思う。思うにクラス3つの場合、クラス間の通信は3C2=3通りであるが、クラス5つの場合クラス間の通信は5C2=10通りとなる。流石に10通りもあると最適な組み合わせを実装と並行して考えるのは難しい。
清書したようなクラス図はいらなくても、チラシの裏にでもER図やクラス図をざっくりとでも書いてみることが大切なのがわかった。
ちなみに当然なんだけどER図やクラス図は言語によらないがフレームワークは言語に依存する。そもそも両者はそれぞれ担当する範囲が違う。フレームワークを利用する時点である程度クラス設計は束縛されることとなる。
動的型付け・静的型付け
- 動的型付け...変数の型をプログラムの実行前に規定しない。型宣言が不要。
- 静的型付け...変数の型をプログラムの実行前に規定する。型宣言が必要。
仕様なし開発
開発では事前に仕様を定義して、その仕様に基づいてプログラムを作成する。しかし中には様々な理由で仕様がない(あってもほとんど意味がない)まま開発する場合がある。
その場合はできた実装が仕様である。こうなると当然テストケースの作成などはできないため最低品質となり、正常系が動けばマシ程度となってしまう。
次元の呪い(球面集中化現象)
次元の呪いとは、高次元データの場合データのほとんどが原点から遠い場所に集中していること。
- 高次元空間の球は体積のほとんどが表面付近に集中。
- 高次元空間ではメロンパンのほとんどは皮。