makotanの勉強日記

勉強したこととか設定系のメモとかそういうのを集めたもの

Elixirで部分適用

どうしてもやってみたくなったので・・・

 def a3(a1,a2,a3) do
        a1 <> a2 <> a3
    end


    def portion(f,v1) when is_function(f) do
        {f, [v1]}
    end

    def portion({f,arg},v) do
        Logger.debug "ca #{inspect f} #{inspect arg} #{inspect v}"
        {f , [v | arg]}
    end

    def portion({f , args}) do
        Logger.debug "endc #{inspect f} #{inspect args}"
        apply(f, Enum.reverse( args ))
    end

    test "" do
        f1 = portion(&a3/3,"1")
        f2 = portion(f1,"2")
        f3 = portion(f2,"3")
        assert  portion(f3) == "123"
    end

結局関数使わないと今のところ出来なかった・・・
他に良い方法あるのかなぁ〜

Elixirでログ出力してみた

module内にLoggerをrequireしてあとは普通のLogger

require Logger 

Logger.debug "debug string #{inspect hoge}"

マニュアル見てるとfnを渡せるので後から評価したい場合はfn渡せば良いような気がする
configにゴニョゴニョ書けば普通のLoggerっぽくフォーマットも変えれる

ソフトウェアを作ると言う事

ソフトウェアで実現したい事があって、そのソフトウェアを作る
その場合に気をつける事などをふと気になったのでメモ

実現したい事 と それに必要な事の組み合わせ

ソフトウェアで実現したい事だけを作ってもそれは実際には使えないソフトウェアになりやすい
音楽を聴きたいと思ったときには、音楽を再生する機械を調達して、音源を調達して、電源を調達する必要がある
これと同じ事でソフトウェアで実現したい事もそのためにやるべきいろんな事がある
結果的に通常は実現したい事よりも必要な事にお金がかかる

実現の難易度が異なる

ソフトウェアで実現する事・したい事の実現方法によっては難易度が全く異なる
全ての機能が全く同じ難易度で実現できない
たとえば、ただ入力された内容をWebに表示するだけの画面と、入力された内容をPDFに出力するのでは実現方法を含めて全く異なる
そのためにソフトウェアの機能は常にどの程度の難易度で実現できるのかが重要なポイントになる
通常のアプリケーションに良くある難易度変化のポイントは以下の通り
* データと状態の複雑さ
* 出力対象(PDF/メール/Excelなど)
* データ量
* リアルタイム性

要件からのコストダウンの方法

最初に考える事は、実現したい事そのものの削減
削減した代わりにある程度の手作業が入るなどの不自由があったとしても削減出来るなら削減した方がコストダウンに繋がる
削減するポイントは必要な情報種類の削減を中心にすればそれだけコストダウンしやすくなる
次に、手作業を何処まで許容するか
人間が実行すればコンピュータより安く/早くすむ事も多いのでエンジニアと相談して手作業を許容するポイントを探す

Eilxirでhello world

ただhello wordを出すだけの変哲の無いあれを1.0.4で作ってみる
最初はinstallとプロジェクトの作成

 brew install elixir
 cd <project parent directory>
 mix new eli_test

eli_testのlibにmainのファイルを作るというか、既にあるはずなので書き換える

defmodule EliTest do
    def main do
        IO.puts "hello world"
    end
end

iexを動かしてコマンドを叩く

iex -S mix
(ここからmixの中)
r EliTest
EliTest.main

はまりポイントが色々あったのでとりあえず出来たところまでのメモ
はまったのは、main()って書いて怒られるとかw
mixの中でコンパイルして実行の方法とか(ふつーに考えればこの手順だよなとw)

便利だったのでこっちもメモ
上でEliTestって書いてるのは数文字打ってからTABで補完が効く
というか、mixは意外とTABで補完が効く

Homebrewを使ってPostgreSQLを動かすまで

2015年5月18日現時点の情報なので、バージョン他によっては違いが出るかも知れないのでそこだけは注意!
前提条件としてbrewbrew cask(pgadmin3入れるとき)がセットアップ済みなこと

brew install postgresql
brew cask install pgadmin3

これでpostgresqlは動作可能になるけど、初期DBが既に作成されてて、それがen_USなのが気に入らないのでそれを変更する

                                List of databases
   Name    |  Owner  | Encoding |   Collate   |    Ctype    |  Access privileges
-----------+---------+----------+-------------+-------------+---------------------
 postgres  | makotan | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | makotan | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/makotan         +
           |         |          |             |             | makotan=CTc/makotan
 template1 | makotan | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/makotan         +
           |         |          |             |             | makotan=CTc/makotan
(3 rows)

まずは既に存在しているDBを移動する(削除してもOK)

cd /usr/local/var
mv postgres postgres_init

次に、新規にDBを作る

initdb /usr/local/var/postgres -E utf8 --locale=ja_JP.UTF-8

後の作業の事もあるので ~/.zshrcに1行追加して

export PGDATA=/usr/local/var/postgres

変更を反映

source ~/.zshrc

サーバを起動してみたり、落としてみる

pg_ctl -l /usr/local/var/postgres/server.log start
pg_ctl -D /usr/local/var/postgres stop -s -m fast

起動した後の確認結果は・・・

$psql -l

                                List of databases
   Name    |  Owner  | Encoding |   Collate   |    Ctype    |  Access privileges
-----------+---------+----------+-------------+-------------+---------------------
 postgres  | makotan | UTF8     | ja_JP.UTF-8 | ja_JP.UTF-8 |
 template0 | makotan | UTF8     | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/makotan         +
           |         |          |             |             | makotan=CTc/makotan
 template1 | makotan | UTF8     | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/makotan         +
           |         |          |             |             | makotan=CTc/makotan
(3 rows)

pgadmin3から接続するときはOwnerのユーザを使って、パスワード無しでOK

参考: Homebrewを使ったPostgreSQLのインストール(Mac OS Lion) - Qiita

スキルの蓄積を投資/投機として考える

エンジニアなので、スキルの蓄積はどうしても必要
ただし、どのスキルを身につけるのかによっては単なる投機(実質ばくち)になる事も確か
ってことでスキルを身につけて蓄積する事とそれに時間とお金を投じる事を考えてみた

変化しにくいスキルと変化しやすいスキル

スキルの中にも変化しやすい物と変化しにくい物が存在している
当たり前の事ながら全てのスキルは時代によって要らなくなったり、重要度が増したりしていく
この変化度合いを年単位で表すと技術によっては、1年持たないもの、数年で廃れるもの、10年を超えるて使われてる物が存在している事が判る
10年を超える技術をさらに理論と実装と実践の3つに分類すると、実装は比較的短期間(数年単位)で変化していくものが多い
ということは、理論部分については10年を超えてさらに先まで使い続けれる可能性が高い

アプリケーションレイヤから見るスキル

UI、開発ツールミドルウェア、OS、ネットワークまでスキルの種類は多岐にわたってる
しかもこれからも続々登場し、続々消えていく事だけは間違いない
ここでも変化に強いもの、変化に弱いものが存在する
たとえば、UIは時代によって数年単位で大きく変化していく
それに対してネットワークは長い時間安定している
ここでも変化という軸で投資的スキルと投機的スキルを選択可能になる

変化という軸で基礎的なポートフォリオを組むと

エンジニアスタートの頃は基礎的な理論部分を軸に実践のマスターに注力する
実践部分は数年単位で変化する事を前提にとりあえず使いこなせれば良い程度でOK
その間に色々な基礎部分を固めておく
変化しやすいスキルの変化の方向をしっかり見定めて時々投機的に学習する
あとは継続的に基礎部分への投資を続ける事
10年ほど続けると、相当な量の基礎固めが出来ているので実践への展開、未知のものへの対応はそれなりに出来るようになるはず

スキルのポートフォリオを組む

投資出来る時間とお金は人それぞれであくまで将来に向けて学習するという前提で
* 数年で変化していくスキルへの一点集中型の投資は普通のエンジニアは絶対に避ける
この場合の例外はそのスキルの第一人者になる事
* 変化しにくいスキルへの一点集中型の投資はお勧め
狭い範囲ながらそのスキルの専門家となればそれなりに仕事は続くので意外とお勧め
ただし、そのスキルを持っている事を周りに告知する事も大事
* 複数分散投資するときは半分以上を変化しにくいスキルに集中する 変化しやすいスキルは複数持っていても長期的に見るとあまり良い投資とは言えない
なので変化しやすいスキルもしっかり持つ事が大事
* 変化しやすいスキルは素早く身につけれる様にする
実は忘れがちながら重要なポイント
短時間で身につけられれば必要になってから一気に投資しても間に合う事が多い
しかも短時間で身につけれればロスカットも気楽に行える

おまけ

時間とお金の捻出方法が問題になりそうだけど、その辺はライフハック系で良く扱われるから
個人的にはスキルへの投資のリターンは普通の投資を遙かに凌駕するリターンがあると思ってる
もし、一点集中したいなら他の人の作った物にのっかるより自分で作った方が良い

バランスと一点集中(偏り)

バランスを取るというのは凄く大事な事。
バランス良くXXXXをする、バランスのとれたXXXなど、バランスが良い状態は良い状態の一つ
それに対して一点集中(偏り)はバランスが悪い状態になる

バランスが良い状態と一点集中の状態をどう考えるか

バランスが良い状態に保てるのは基礎体力みたいなもので、バランスを意識してそれを保てる事は非常に重要
ここを上手く出来ない状態で一点集中の状態へ行くと、最終的にバランスを保ちたいとき(保たないと駄目なとき)に保てなくなるので危険
逆に、バランスを意識して保てる人が敢えて一点集中したとしても、必要に応じてバランスを保てるので危険は少ない

バランスを保つ事を意識的に行えるようになるまでは、バランスを重視し
バランスを保てるようになった段階で一点集中すれば良い

バランスを意識して保てる状態になる事でバランスを崩すタイミングを知る事が出来る
要はバランスですよ。