概念モデリングは奥が深すぎる

さて、

仕事で設計の話題がでて、

頭を悩まされた一日でした。

社内製品の次なるリリースに向けて

機能の拡張に着手し始めました。

作りたいものはイメージ化できているのですが、

既存のシステムに取り入れている概念とは別の新しい概念を作らねばならなくなりました。

まぁ作らねばならないと決めるまで相当時間かかったんですけどね。

既存の概念をうまく使って実装できないか、既存の概念にうまく内包できないかなどなど考えたりしてました。

結果的には話は纏まりつつある状況なのですが、

他の方々はどうやっているんでしょう？

色んな人の概念モデリングが気になります。

単純にクラスとなり得るものを洗い出して、

それから設計を進めていくだけでは難しい時がいつか必ず訪れると思うんですよ。

それこそ、論理的にかつスマートに物事が運ぶようにするため、

自分で新しい概念を作り出す、とか。

そこってオブジェクト指向とかよりももっと上のフェーズですよね？

そういった超上流工程は経験貯めるしかないな〜と思うこの頃。

そもそも新しい概念が思いつかない。

とは言ってもすぐ思いつくものではないですよね。わかっているんですが。

思考に思考を重ねて、これが必要になったからそういう概念を作ろうって感じかな？

それは仮設検証の話になるんでしょうか？

…

うーむ、まだまだ経験も知識も足りない…。

Linuxのしくみを読み始めました。

さて、

先日よりlinuxのしくみを読み始めました。

下記の本ですね。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

最近自分が何に興味あるかなと考えたところ、今は

「仕組み」

に興味がある、という結論に至りまして最近読み始めました。

職場で最近はメモリ管理など、

低レイヤを意識することが増えたのが恐らく原因ですね。

とは言ってもGoも勉強していきたいのでうまくやっていく必要がありますが。。。

…

読んでいて、「お？なるほど！確かに」というところがあったので、

メモがてらブログに記載しておきます。

第４章のプロセススケジューラの話なんですが、

実験で１コア（論理CPU（CPUとして認識されているもの、ここではコア））

で、１プロセス・２プロセス・４プロセスを実行して、

CPU内部ではどのようにプロセスが実行されているかの実験です。

詳しくは本の中身を呼んで頂ければいいのですが、

簡単に結論だけ書くと、

・ある瞬間に論理CPU上で実行されているプロセスは１つのみ

・動かし方は、複数プロセスを順番に１つずつ動かして、

　１周したら最初のプロセスに戻り動かす（ラウンドロビン方式）

・各プロセスはほぼ等しい時間間隔（タイムスライス）で動いている

・全プロセス終了時間はプロセス数に比例して増加（２つなら２倍、４つなら４倍）

という感じでした（手元のUbuntuでも実行して確認済み）

また、このプロセスが切り替わる仕組みを

「コンテキストスイッチ」と呼ぶ。

…

知っていたことではありましたが、手元で動かして確認したことがなかったので

新鮮な感じで学べました。

また下記の内容が一番「なるほど！」と思ったことなのですが、

コンテキストスイッチはいかなるコードの実行中であっても、

タイムスライスが切れると容赦なく発生する。

なので、hogehoge関数の次にhugahuga関数があったとしても

hugahuga関数の前に別プロセスが動くかもしれないので、 

必ずしもその順番で実行されるわけではない。

ということでしたね。

なので、

処理に思った以上に時間がかかっている場合は

・処理自体に問題がある

・コンテキストスイッチが発生して他のプロセスが動いた可能性がある（NEW)

という可能性がある、という観点を新しく身につけることができました。。。

これまでの見方とは別の観点がある。

これを発見できただけでもこの本買った価値ありました！

しかもまだまだ本の最初の方なので、学ぶことはもっとありそうです…。

是非皆様もお買い求めください。

続きを読むぞー！

技術の進歩に自分の知識が追随できない

さて、

ようやく仕事の山場を越えて、自分の時間が戻りつつあります。

仕事が忙しい時期って自分の生活リズムが狂いますよね。

仕事をしている以上、時間が仕事に依存している証拠ですね。

かといって、疎結合できるものでもないし。

もう少し余裕を持ちたい！

…

今日はある記事を見て、タイトルの様な事を思ったので

とりあえずブログに書こうかと。

記事というのがこちらですね。

www.publickey1.jp

( -_-)・・・

はええよ！進歩が！

最近！コンテナ技術を勉強し始めて！

k8s触ったばっかだってのに！

もうこれかよ！

…

ま、まぁ

既存のk8sのスリムダウン版ですから、

新しく学びなおすってことではないのでいいんですけどね。

記事には中身の仕様が少し書いてありますね。

軽量化のためにやれることやったって感じですね。

…

ここでタイトルの話に戻りますが、

他のエンジニアの方々は最新の技術についていけているのでしょうか？

よく私は思っちゃいますね。

あれもこれもまなびたいことがあるときって

どんな順番にすればいいんでしょうね。

私の場合は普通に正社員で仕事をしているので

勉強時間は当然限られます。

そうなるとどれか一つの分野にしか暫くの間集中できないわけですよ！

そんなときにどんどんとポンポン新しい技術が出てくると、

もうそれはイタチごっこですよ。。。

と、思ってはいても

やることはひとつだけなんですけどね。

…

今日は本屋で1冊、

いつか買おうと思っていた本を買いました。

また読み終わったら紹介します。

ではでは。

学ぶ事って本当に多い

さて、

今日は書くネタを思いつかなかった日なので、なんか書きます。

…

よく先輩から注意されるのは、

メソッドやクラス、モジュールの命名です。

別に英語が不得意とか英語に苦手意識があるとか、そういうわけではありません。

あれですよ、あれ。

その時、すっと、単語が出てこないんですよ。

別に歳じゃないですよ？私まだまだ若者と言える年齢ですし。

あり合わせの言葉を駆使して作成してしまう事が多いです。

そしてレビューを受けて、

「こういう単語があるよ」

と気付かされます。

恐らく経験によるところが大きいと思うんです。

まぁ引き出しの多さですよ。

最近へ〜ってなったのは

dataは複数形

単数系はdatum

でしたね。

こういうのって言われなきゃわからんですよ！

datasとか書いてましたもん！

コードの設計や書き方をレビューされるのもいいですが、

命名も勉強になるな〜と思います。

ガベージコレクションの実装って考えること多い

さて、

最近遅く帰ることが多くなりました。

まぁ忙しい時期なので仕方ありませんが。

ブログは腐らず続けていきたいので、頑張って更新します。

今日はガベージコレクション、GCについて簡単に書きます。

仕事で、あるシステムを作成していて、そこでGCのようなアルゴリズムを書いたので、ふと書こうかなと思いました。

…

ガベージコレクションとは？

ja.m.wikipedia.org

 wiki参照！以上！

  =====○)д｀);.･;゛；ﾌﾞｯ 

   =====○)д｀);.･;゛；ﾌﾞｯ 

    =====○)д｀);.･;゛；ﾌﾞｯ 

…

とりあえずでwiki見てみましたが、完成度高すぎてビックリしましたね（当たり前か）

アルゴリズムの種類、言語毎の実装アルゴリズムなどなど…

とりあえず話は戻って、

ガベージコレクションとは！

不要になって使わなくなったメモリ領域を開放する仕組みのこと

ですね。

最初にガベージコレクションを実装したのはlispだとかなんだとか。

ガベージコレクションは常にオブジェクトを見張っているため、

それなりに時間がかかる重い処理です。

C言語なんかはガベージコレクションを実装していない（ライブラリで追加可能）ので、そんじょそこらの言語よりは高速となっています。

それ故、組み込み系のシステムではC言語がよく使われていますね。

…

それではガベージコレクションって

どんなアルゴリズムで動いているのか？

代表的な例を記載しておきます。

リファレンスカウント

※時間制限ではなくカウント制ですし、爆発はしません。

予め、オブジェクトが参照される回数を記憶しておき、

その回数がゼロになったときにゼロになったオブジェクトを開放する方式

仕事で作成したGCもどきもこの方式を採用しています。

わりと単純なアルゴリズムですよね。

マークアンドスイープ

どこからも参照されていないオブジェクトを開放する方式

これは確か下記の本でも取り扱われていたアルゴリズムだったと思います、

これも単純かつ有名ですね。

プログラムはなぜ動くのか　第２版　知っておきたいプログラムの基礎知識

 ※この本わかりやすくておすすめです。プログラムが動く仕組みを知るって大事ですよね。

コピーGC

メモリ領域を二つ用意し、片方にオブジェクトをプールし、片方に使っているオブジェクトをコピーしてから、プールしてある領域を解放する方式 

これは実は知らなかったです。

２つの領域のうち、アプリが使えるのは片方のみで、

その使える片方にオブジェクトが溜まると、コピーGCの処理が走ります。

 そうすると、使っていないもう片方の領域に、

使用中のオブジェクトをコピーして、使っていた領域を解放します。

そして、コピー元とコピー先の領域を入れ替えて

再びオブジェクトがいっぱいになれば、同じことが起きる。

こんな感じのアルゴリズムらしいですね。

オブジェクトを順々にコピーしていくため、

メモリの断片化が起きないのがメリットらしいです。

中々面白いなぁと思いました。

他にも世代別GCというものもあり、

これはコピーGC＋マークアンドスイープのアルゴリズムのようです。

なんとなくイメージは湧きますね！

…

アルゴリズムを知っておくと、思わぬところで役に立つので、

引き出しはたくさん持っておきたいですね。

アルゴリズムイントロダクションを完読しよう！

花粉症

さて、

そろそろ花粉症の時期ではないでしょうか？

花粉症はかかると辛いですよね。

まぁ私花粉症かかったことが無いのでわからないんですが。

  =====○)д｀);.･;゛；ﾌﾞｯ 

…

さ、さて、

会社で花粉症の話があったから記事にしたのですが、

ては花粉症ってなんでかかるんでしょうね？

職場では、博識の先輩から出たキーワードとして、

食物繊維

が出てきました。

なるほど、確かに私の食生活は野菜中心なので、

かかったことがないことに対しても説得力がある…。

実際に調べたところによると確かにそうらしいです。

纏めるとこんな感じです。

花粉症がかかる原因

→身体の免疫力が低い

免疫力を高めるには？

→適度な睡眠、腸内環境をよくする

腸内環境を良くするには？

→食物繊維をとる

らしいです。

ちなみに腸内環境をよくすると免疫力が高まる理由としては、

腸内に60%もの免疫機能が集中しているかららしいです。

www.google.com

…

エンジニア関係なく花粉症は辛い（らしい）ですよね。

本格的な花粉が来る前に対策しておくのが吉ですね。

他にも夏が暑いほど次の年の春花粉は辛くなるみたいな話もありました。

ここ数年毎年記録更新するレベルでどんどん暑くなっていますが、

花粉はどうなるんでしょうね…。

一時ファイル

さて、

業務ではpythonを使用しているのですが、

そこで今日は久々にtempfileモジュールを使う機会がありまして、

一時ファイルを扱っていました。

tempfile.TemporaryDirectory()やtempfile.TemporaryFile()などですね。

常識事ではありますが、自分の頭の中を整理するために簡単に記載したいと思います。

…

一時ファイルとは？

その名の通り、一時的なファイルです。

基本的には使用が終わると自動的に破棄されます。

（厳密にはプロセスが終わると、ですが。プロセスやスレッドもブログで纏めようかな）

一時ディレクトリなら、一時的なディレクトリで

本物のディレクトリのようにファイルを格納することができます。

こちらも一時ファイルと同じように、自動的に破棄されます。

倉庫は一時的に物を置いておく場所ですが、自動的には削除されないですね。

例えばpythonなら下記のように、

withブロックにいる間はtempfile（tempdirectory）が存続しています。

import tempfile

import os

from pathlib import Path

def main():

with tempfile.TemporaryDirectory() as td:

with open(Path(td) / 'test.text', 'w') as f:

for path in Path(td).iterdir():

print(path)

if __name__ == '__main__':

main()

pythonのwith句はわかりやすくて好きです。

C#にもusingステートメントありますが、ing付くと文字数長く感じません？

いっても「using」5文字じゃねぇか、本当に目が悪いやつだなぁ！？

 =====○)д｀);.･;゛；ﾌﾞｯ 

…

 勉強しているGoでも触ってみようと思います。

あちらは自動で削除されないみたいですね。。。。

どこに一時ファイルは作成されるのか？

これはOS毎に違っております。

windows・・・環境変数で設定してあるフォルダ

unix系統・・・/tmpディレクトリ

（windowsはフォルダ、unixはディレクトリと呼びます。個人的にはどっちでもいいんですけどね。）

windowsではTEMPあるいはTMPの環境変数で設定してあるフォルダになります。

初期設定では、

C:\ユーザ\ユーザー名\AppData\Local\Temp

となっているはずです。

勿論、環境変数内のPATHを変更すれば、

一時ファイルの出力先も変更した場所になります。

ある意味、ユーザの設定に依存している形にはなりますね。

unix系統（macやlinux）は

ルートディレクトリ直下に存在するtmpディレクトリが

一時ファイルの出力先になっております。

こちらは常に決まっているので

OSの設定に依存していますね。

個人的にはunix系統の方が好きですね。

いつも同じ場所にあるという感じで。

windowsも同じ場所にあるといえばあるのですが、

一度PATHを確認しないと確信が持てませんからね。。。

しかし、実運用上では気を付ける必要があります。

セキュリティ上の問題ですね。

常に決まった場所にあるということは、狙う場所がバレているということですから。

下記参照ください。

www.ipa.go.jp

…

簡単ではありますが、纏めてみました。

日々、基本的な知識が蓄積されているのがいい感じですね。