  |
はてなキーワード: コンテナとは
自炊しているが、食品の消費期限とかを気にして生きるとか、一週間レシピを決めて計画的に消費するとかが無理なので最近はなんでも冷凍するようにしている。
安いスーパーで買って冷凍する。一度に使う最小単位（うちでは100g）ごとにラップして、購入日と品名（豚バラ、鶏むね等）を書いたジップロック袋Ｌでまとめておく。
袋への品名記載は当初していなかったが、自分の目は死んでおりしょっちゅう冷凍豚バラと冷凍鶏モモを取り違えるので記載するようになった。
20時とか21時に帰宅してこれは何だったかな……。と考える手間も省けるし、解凍して豚でなく鶏だ！と気づくこともなくなるので良かった。（3敗）
同じく安いスーパーで買ってラップして保存。魚なら切り身単位で売っているものを購入できるので楽。
エビの場合背ワタを取ってから冷凍するのでちょっと面倒くさい。
この連中は加工食品のくせに意外と足が早く、期限内で使い切るのも割と難しいので冷凍する。
冷凍庫の中で常備しておくと煮物のボリュームが足りない時に足せたりするので便利。
ちなみに油抜きしてから冷凍したほうが持つらしい。今この記事を書くために調べた。次からそうする。
油揚げ系より日持ちするが、使い切れないことが多い。気づいたら賞味期限後一週間とかなってることがあるので、その日使う分以外は冷凍庫行にする。
スープ・みそ汁・ポトフなど冷凍したまま調理開始できるレシピに突っ込むと楽。
ひとかけごとにラップし、袋に入れて冷凍。当初は野菜室で保存していたが、毎回使い切る前にカピカピに乾燥させていたので今は購入即冷凍している。（n敗）
通常は週初めに作り、冷蔵で３～５日で消費している。たまに急な外食が入ったり、そもそも作りすぎたりしてたまに余るので、保存容器に入れて冷凍する。
何もしたくなくて限界なとき、解凍してそのまま食卓に並べるので楽。
下味を付けた揚げる前の唐揚げ・とんかつ、焼く前のグラタンなんかも凍らせることができる。作るときは大目に作り、冷蔵庫に入れとくと便利。
豆を挽いた状態だと冷暗所では一週間、冷蔵庫でも２～３週間で酸化するが、冷凍庫なら一か月持つらしい。
専門店で購入して持ち帰ったらジップロックに移して空気を抜いて、すぐ冷凍している。
一か月冷凍保存したものを飲んだが、バカ舌なので正直「うまい」ということしかわからない。俺は雰囲気でコーヒーを飲んでいる。
定期的にはてブでは「めんつゆは家庭料理の味方！ 手抜き扱いするヤツはクソ！」という記事が盛り上がり、そのたびにはいはいそうですねと見ているが誰も保存方法の話をしてくれない。
開封後のめんつゆの目安は、ストレートなら三日、三倍濃縮で三週間。分量にもよるが毎日めんつゆ料理を作らないと無くならないと思う。
仕方ないので自分で色々試した。結論から言うとフタつきコンテナ型の保存容器に流し込んで冷凍庫におけばよい。
めんつゆ・白だしは内容物のせいで、家庭用冷蔵庫では凍りきらずシャーベット状になる。冷凍しておけば開封後も保存期間を気遣う必要はなくなる。
スプーンですくえるぐらい柔らかいサクサクの状態なので、使うときは料理用のサジですくって使用する。
白みそ、赤みそも別容器に移す必要はないが同様に冷凍保存できる。めんつゆ以上に凍らないので同じ感覚で使用できる。
同じ調味料でも水分の多いもの（レモン汁等）は凍りきってしまう場合がある。100均で製氷機を買って凍らせる前にキューブ状にしたほうが良かった（１敗）
水分が多い野菜（キャベツ・レタス・玉ねぎ）や、それらを使った総菜は凍らせると質感がわかるぐらい落ちるので避けた方がよい。
また試してないけど調味料でもゴマ系は劣化するので冷蔵・冷凍しない方がいいらしいぞ。
ここに出てないネタとか指摘があったら教えて
ブコメとトラバに知見が集まっててまさに集合知って感じなのでここまで読んだ人はみんな見てみてね。
シュレッドチーズ小分けと油抜きした油揚げを刻むやつはなんで思いつかなかったのかってぐらいいいアイデアなのですぐやります。
あとトラバ読んでて気づいたことだが、同じめんつゆでもストレートなら製氷機に入れてキューブ上で凍らせられるんじゃないかという気がする。
自分も当初は製氷皿に入れてみたのだが、試したやつが三倍濃縮だったので、シャーベット状、より正確にいうと半液状になって固まらなかった。
それで上記の結論（コンテナに入れて保存すればよい）となったが、ストレートめんつゆや自家製めんつゆ保存の場合は製氷皿で一度凍らせた方がいいのかもしれない。
会社入ってからプログラミングはじめたが、普通に部署のエースみたいな感じになった。
配属から５年。
安定した会社ではあるが、自分の思い描いていたIT企業ではなかった。
（というか就職のときはIT企業の中身すらよくわかっていなかったのが正直なところだが……）
自分がやってきた仕事は、システムの設計・開発・テスト・実施の一連のことはやった。
よくある協力会社のマネジメントというのではなく、全部自分の手でやった。
いわゆるSEとしての仕事は一通りできるようになったかな〜という感じ。
WEB業界なり、外資系IT企業の日本法人なりが転職先の候補なのだが、
担当してるシステムがメインフレーム系なので、今の会社で培った技術というのが、ほぼ外で応用できない。
よくSEからWEB系転職する際に、プライベートで勉強してつくったものをアピールして、
自分の技術をアピール、というのが鉄板なので、ちょっとした手土産を作って持っていこうとは思う。
結局Git使って、コンテナ基盤の上でCIして、アジャイルに開発してますみたいな世界線で、
自分がどれだけやれるかが自分自身も不安だし、正直やってみないとわからない。
それではさっそく、一番簡単な手続型プログラミング言語の使い方を学んでみよう。
「構造化プログラミング」でGoogle画像検索すると、分かりやすそうな図があった。
買物を例に挙げて、「順次」「反復」「分岐」の３つの動作を使ってみよう。
このように構造化プログラミングは、人間の動作と同じだ。やることをズラズラ書いていけばいいだけだ。
「最低限これだけはないとダメ」という項目を箇条書きにしておこう。
買物プログラムなら、
などが必要だろう。
単純なプログラムだと処理が少ないので混乱しないが、複雑なプログラムだと処理が多くて混乱するだろう。
あらかじめ、処理を図に書き出しておくと混乱せずに済む。その図が「フローチャート図」だ。（フローチャート図の書き方は自分で分かりやすい説明を検索してみてくれ。説明省略）
実務では納品時の成果物としてフローチャート図の提出を求めらていなければ、面倒なので作る必要はない。自分のための図なら、ノートにチャチャっと落書き程度に流れ図を描けば十分だろう。
フローチャート図を基にして、実際のコードを書く前に、人間の言葉で「疑似コード」を書いてみよう。
擬似コード（pseudocode）とは、アルゴリズムなどを、架空の非常に高水準なプログラミング言語（擬似言語）で記述したものである。
例
番号と注文で取引をする
else
エラーを表示する
end if
個人的に最良だと思う方法は、プロジェクトの各パートにおいてなにが求められるのかを具体的に書き出すことです。
このとき、まだコードを書かずに言葉だけで記述するのがカギです。
pseudocodeなら構文を気にすることなく、プロジェクトの動作だけに思考を集中できます。
カウントダウン時計の場合なら、書き出した内容は次のようになるでしょう。
要するに「擬似コード」とは、人間に意味が分かる言葉でコードっぽいものをあらかじめ書いておき、後でそれを具体的なプログラムコードに書き換えていく方法だ。
いちいち面倒だけど、最初慣れないうちは、こうすれば間違えにくいだろう。
擬似コードと似た方法として「文芸的プログラミング」という方法もある。
面倒なので実務では使わないが、このような補助的手段もある、と紹介しておく。
Javaと関係する点で考えると、Javaには「アノテーション」（注釈）という機能がある。
プログラムに「注釈」となる記述をちょこっと書いておくと、プログラムの動作について細かな指示が出せる機能だ。（学習が進んでから、後で「Java アノテーション」を検索して学んでみよう）
次回は、子ども向けプログラミング教材「Scratch」を使って、実際に構造化プログラミングの３つの動作を練習してみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐） ←★今ここ★
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
：
昨今流行りの機械学習でプロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。
グループ全体の規模はそこそこ大きいが、将来単なるアッセンブリー屋になることが目に見えている事もあり（今後20年以内には喰われてしまうという憶測もあり）ネットワーク、Linux、コンテナ、プログラミングが出来る自分が社内の機械学習、引いてはITインフラの民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。
まずは既存DHCPサーバ、名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題でデスクトップPCとサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題を解決することにした。
上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代のオンプレクラウド（個人的にはエッジクラスタがゆるく繋がるアメーバクラウド？のような呼称があっている気がするが）を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。
とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品や保守サービスが受けられる事から上記2つを選択した。
PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど（言いたかっただけ）、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイが重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア（とちょっとしたAPIサーバ）をGo言語で作成した。
次に世の中のパブリッククラウドやOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記のAPIサーバと連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題を解決することにした。
まぁなんだかんだ大企業なのでお金で解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。
脱線したが、上記以外にも検証やバックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+goで簡単なフロントエンドサーバを構築し、一人情シスの様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。
ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。
特にオンプレクラウドは部外者が中々見えてこないものがあり、なんならその見えないものを限界まで吸収できるように、かつ現実的に実現可能なギリギリのラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。
覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。
世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか？
ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力感はいかんともしがたい。
