手抜きレシピ - ほうれん草のおから利休和え

すりゴマがなくて煎りゴマしかなかったので困っていたが、おからパウダーで代用したら思ったより美味しかったのでレシピを残しておこうと思う。

レシピ

材料

  • ほうれん草   1把(200g強程度)
  • 利休地
    • おからパウダー 20g
    • 出汁      80mL
    • 煎りゴマ    小さじ1(あれば)
    • 三温糖     大さじ1
    • 醤油      小さじ1

手順

  1. ほうれん草の根本を包丁で細かく割ってから洗い、ラップをしてレンジでチン
  2. おからパウダーに4倍量の出汁を吸わせたものに、三温糖、醤油、あれば煎りゴマを混ぜる
  3. (1) の加熱が終わったら、水気を絞って指 3〜4 本幅程度の長さにカット
  4. (2) と (3) を混ぜる

利休和えと白和えの間のような味がし、説明は少し難しい。
しかし、想像以上に美味しいので一度試してもらいたい。

おからパウダーがなければ、生おからを乾煎りしてサラサラにすれば同じように使える。

手抜きレシピ - 蒸し鶏

最近蒸し鶏にハマっている。
ありがたいことに鮮度の良い鶏肉を手に入れる方法が確立できたので、しっとりと柔らかく毎日食べても飽きない蒸し鶏を作り続けている。

レシピ

材料

  • 鶏胸肉 何枚でも
  • 砂糖  小さじ1/鶏肉1枚
  • 塩胡椒 鶏肉の皮目にまんべんなく振れる程度
  • 日本酒 大さじ1/鶏肉1枚(あれば)

手順

  1. 炊飯器の釜に皮目を上に鶏胸肉を入れる
  2. 皮目にまんべんなく塩胡椒を振る
  3. 砂糖を鶏胸肉1枚辺り小さじ1入れる
  4. あれば日本酒(not 料理酒)を鶏胸肉1枚辺り大さじ1入れる
  5. 沸かした湯を鶏肉が完全に浸かる程度入れる
  6. 炊飯器にセットして保温で2時間程度放置
  7. 湯からザルに上げて肉を冷まし、冷めたら切り分ける

醤油でも山葵でも塩でも焼肉のタレでも、好きなものを付けて食べる。
しっとりして、旨味もたっぷりなので美味しく頂ける。
シンプルな味わいなので、恐らく白米のように毎日食べても飽きない。

残った茹で汁は鶏がらスープのように使えるので、鍋にあけて沸かしてアクを取り、野菜を入れて煮てあげると美味しいです。

開発環境を見直したよ(Lubuntu 18.04 LTS から Kubuntu 20.04 LTS へ)

開発環境見直し

2020 年になったので、大凡バグも取れているだろうと期待して Ubuntu シリーズの 20.04 LTS に環境更新することを決定。
今までは Lubuntu 18.04 LTS を使っていまいしたが、今回より Kubuntu 20.04 LTS に移行することにしました。

なぜ Lubuntu を捨てるのか

Lubuntu 20.04 LTS は、きっと良い OS だと思います。
ですが、どうしても新しいデスクトップ環境に慣れませんでした。

LXDE から LXQt へ

私が Lubuntu を開発環境に選んだのは、LXDE が軽量だったからです。
選定当初 Lubuntu 16.04 が他のディストリビューションよりも遥かに軽く、他のリッチなディストリビューションよりもその一点が非常に素晴らしかったです。

Lubuntu 18.10 より、Lubuntu は LXDE から LXQt にデスクトップ環境が移行しました。
次の LTS が出る頃にはプロダクトレベルが向上してそれなりのものになるだろうと考えていたのですが、Lubuntu 20.04 LTS がリリースされた今でも LXQt はかなりつらい状況です。
当然、LXDE とは違うソフトウエアだから差異があるというのは分かるのですが、実際に実運用に放り込もうとすると LXDE より遥かに不自由でかなり厳しい状況でした。

また、LXDE が軽量だったから Lubuntu を選んでいたというアドバンテージが LXQt により失われました。
全体的にモサッとしている割には、そこまで行けているわけではないというのに耐えられませんでした。

また、Lubuntu 18.04 LTS から Lubuntu 20.04 LTS への更新は LXQt の関係もあってコマンドによる更新が推奨されず(システムが破綻するそうです)、新規インストールからの再構築を強いられます。
既存環境の放棄を強いられるのであれば、いっそのことディストリビューションを変更してしまっても良いのではないかという考えに至りました。

ディストリビューション選定

Lubuntu 20.04 LTS 以外に候補に上がったのは、Xfce を採用した Xubuntu 20.04 LTS と KDE を採用した Kubuntu 20.04 LTS でした。

実際にそれぞれインストールして触ったところ、 feel が私に合ったのは Kubuntu 20.04 LTS でした。
今まで KDE は重量級だと思って避けていたのですが、KDE Plasma 5 になっていたからなのか、想像以上に軽量な環境でした。

KDE Plasma 5

Kubuntu 20.04 LTS に採用されているデスクトップ環境です。
LXQt よりもメモリを使用するのですが、もっさり感がかなり低減されており、想像以上に軽く感じます。

動作環境に関しても Lubuntu と比べてもかなり作り込まれてリッチな環境になっているため、このメモリコストを払っても十分許せるレベルになっています。

Hello Kubuntu 20.04 LTS

そういう経緯から、Kubuntu 20.04 LTS で環境を再構築しました。
KDE 環境でもまだ幾らか不満があったりしますが、その辺りはもう少し KDE について詳しくなるか慣れていくことで緩和されていくのではないかと思います。

ただ、ちゃんとしたクイック起動がない点についてだけは未だに不満を抱えています。
これ、なれるとかなり便利なんですよねー

ではでは

ブログデザインを見直してみた

PC から見た時のデザインをいじってみた。
手抜きデザインだけどパッと見は整ったんじゃないかなと思う。

とは言え、カスタム CSS にも限度があるね。
元の構造が想定していた構造と異なったので、私のへっぽこ CSS スキルではこんな所で妥協しておいたほうが良さそう。

なんか書こうと思って久しぶりに開いたら、結局デザインをいじって満足してしまった辺り、日記が続かない三日坊主どころかスタートに立てない0日坊主であった。

golangで商業サービスを書いて世の中に送り出した話

やあやあ。

今回は Go Advent Calendar 2015 その2 の12日目の投稿だよ。

今年のgolangは人気で、その1~その3まであるみたい。

 

11日目の投稿はこちらの方達がされています

 

全体的に技術的にレベルが高い記事が多い中、私は違う視点からAdvent Calendarを書いてみたいと思います。

 

なんで商業サービスにgolangを採用したの?

アーキの設計権限も、言語の採用権限も、全て私にありました。

私がサービスで最も重要なのは、挙動の「速さ」であると考えています。

速いは正義。速さこそ全て。速さとは力である。

それと同時に、ある程度の書きやすさも必要です。作るのは私です。書きづらい言語は避けたい所です。

後は、予算は節約する必要があるので、クラウドで借りれる安いヘボサーバを並列で並べて何とかしたいという大人の事情。ほどほど~良いサーバを数台借りるより、遥かに安上がりなんですよね。

今回私が書くのはサーバサイドのアプリケーション。APIサーバと分類されるものです。

そこでいくつかの言語が候補に挙がりました。

え? C++以外名前が伏せられているじゃないかって? まあ、その辺は想像にお任せします。

 

関数的表現が可能なJVM言語

初心者にしては比較的動くサンプルコードが書けたと思いました。

ただ、どうしても以下の問題を私には解決できませんでした。

  • 安定稼働させるには思ったよりもメモリを必要とした
  • 思ったほど速度が出なかった

安定はしていたのですが、如何せんリソース食う割に速度が出ずに頭を抱えました。きっともっとうまく書ける人も居るんでしょうが、私にはこの程度しか使いこなせませんでした。

後、関数的に書くと私以外の人の学習コストが高すぎるので、エンジニアの並列化がやりづらいという別の問題も。

 

コンパイル不要なメージャーどころのスクリプト系言語

最近最新版が出て速度がかなり改善された言語ですが、私はコンパイル駆動がしたかったので、お引き取り頂きました。

 

そのスクリプト言語と同じような記法で書けてコンパイルできる言語

上記言語が高速化する前に一時期話題になった噂の言語。

ですが、今後もその言語に縛られる事は幸せなのかどうかで悩んで、一旦保留にしました。

 

C++

私はC/C++系の出身なので速度的にはかなり有利な事が分かっていましたが、それと同時にこの言語でネットワーク周りをやると死んでしまいそうになる事も知っていたので、却下しました。

 

そして選ばれたのはgolangでした

golangは満足な速度が出ます。そして、コンパイラがそれなりに優秀です。

ネットワーク周りや暗号処理周りが標準パッケージに含まれており、それらの出来も結構良いです。ここで、ネットワークが必要となるプログラミングにも十分耐えられることが分かりますね。

better Cでもあるので、構造体が使用可能です。「ある」と「ない」とでは全く違います。更に、ポインタ概念も存在します。にも拘らず、メモリの開放は言語にGCが積まれているので、C/C++に存在しがちなメモリの開放に関わる諸問題が起きづらいです。

なかなか魅力的ですね。

また、言語の機能そのものも非常にシンプルで、ちょっと勉強したら書き始める事が出来ます。

 

golangでプロダクトを書くにあたり

最初に行ったのは以下の整備です

  • ビルドスクリプトを作成
  • リリースモードとデバッグモードのビルド分けを実現
  • 自動デプロイの仕組みの構築
  • RDBとの接続回り
  • イベント駆動するサーバ機能とルーティング
  • 外部パッケージのバージョン制御

これだけはしないといけません。しかし、これだけやれば後は書くだけです。

 

ビルド~デプロイ系

ビルドスクリプトを叩けば、勝手にプロダクトがビルドされるようにしておきました。

デプロイはJenkins氏に丸投げします。勝手にgitからリポジトリを落としてきて、勝手にビルドして、勝手に成果物を目的の場所に配信する仕組みを作るだけです。

また、外部パッケージは毎回最新を取得してビルドするようにしました。

私は台数が変動し、IPも固定に出来ない複数台のヘボサーバへ自動に配信したかったので、動的分散デプロイシステムを書いています。

 

RDB周り

gplangには重厚なORMは不向きです。直接SQLを書くことの方が多いでしょう。

 

ルーティング系

良いパッケージを見つけたので、そちらを利用させていただきました。

 

外部パッケージのバージョン制御

恐らく、ここがgolangの弱点。

golangは外部パッケージをコマンド一本で取得して利用できる強みがありますが、この機能は対象リポジトリから常に最新のものを取得してくるという性格を持っています。

golangの設計思想として、外部パッケージは公開した後に破壊的アップデートをしてはならないとなっているようで、利用しているパッケージが下手なアップデートをしてくると死にます。

ただ、私は常に最新のコードを使いたかったので、クリティカルなパッケージのみ、自動取得した後に特定バージョンにチェックアウトしてコードを利用するというサブコマンドを書きました。

プロダクトごとに設定ファイルを持ち、デプロイ時にその設定ファイルに従って特定のバージョンに変更してからビルドをするというような動き方を実現しています。

 

golangでプロダクトを書いていて困ったこと

先ず、循環参照が出来ない点。golangにはC++のようなヘッダファイルが存在しないので、構造体を定義してパッケージ間で投げ合う時に困る事があります。この時は、ヘッダ用のパッケージを定義し、その配下に本体コードのパッケージを定義する事で回避が出来ました。

次に、型変換を容易にする標準機能が思ったより貧相であること。私は、型変換用のパッケージを別途設計して、全てそれを使いまわすようにしました。実に便利です。

最後に、真のマルチスレッドに対応していない外部パッケージがちらほら存在すること。sql driver周りで嵌りました。泣く泣く、スレッド数を1固定にもどしました。ヘボサーバは1コアだから悔しくなんてないんだからね(グスン

 

golangでプロダクトを書いていて気を付けたこと

先ず、各機能に「状態」を持たせないようにしました。

誰かに呼ばれるのは一期一会。どのように呼ばれようと、同じ値が同じ環境に投入されると、同じ結果が返ってくるように書いていきました。関数的表現のエッセンスを取り入れた結果です。

次に、構造体をなるべく使うようにしました。実に便利です。ポインタを投げ合うの、楽しいです。各メソッドのI/Fにも影響が出づらいので、良いです。

そして、goroutineとchannelを上手く使い、並列化できる処理は並列化しまくりました。

最後は、各処理の独立性を上げた構造を意識していきました。

これぐらいの注意点で、十分動くものが作れます。

 

最後に

goに入ってgoに従う

これですよ。goにはgoの書き方がある。それに従えば何とかなる。

え? これが言いたかっただけだろって? ハハハ

 

goと共にあらんことを。/ May the Golang be with you.

 

技術的なお話をあえて避けて、実際に使った人の視点で書いてみました。

golangでプロダクトを書きたい方、安心してください、怖くないですよ。

ちゃんと書けます。だから、怖がらずに採用しても大丈夫な言語です。

  

明日は Go Advent Calendar 2015 その2 の13日目となります。

13日目の投稿はこちらの方達です。

 

CM

こんなのやってます

kug2.connpass.com

 

ではでは!

ITエンジニアに求められる最低限の素質とは

やあやあ。

夏だから色々ぼやいてみたいと思うよ。

 

ところで、ITエンジニアに求められる最低限の素質って、何だと思いますか?

色々あると思います。よく聞くものとしては

  • コードを書く技術
  • 仕様書を書く技術
  • 算盤をはじく技術
  • 専門特化した知識
  • コミュニケーション力

この辺りですかね。

さて、本当にこれらがITエンジニアに本当に必要な最低限の素質となりえるのでしょうか?

 

コードを書く技術

IT技術者としてお飯<オマンマ>にありつくためには何かしらを作って対価にお金を貰うか、作った何かでお金を生み出す必要がありますね。

となると、コードを書く事で何かを生み出す必要があるのは間違いありません。

かと言って、世のIT技術者が皆コードを書いてお飯にありついているかというと、そうでもありません。

IT業界で悪の代名詞としてよく使われるSIerと言う世界では、コードが書けなくてもプロダクトに携わって大金を得ている人種が少なからずいます。

彼らをIT「技術者」と言うべきかどうか、そもそもそういうお金儲けのスタイルがどうかと言う話もありますが、事実として、コードを書く「技術」がなくても生きていく方法はあるようです。

必要とされるのは「コードを書く『手段』」のようですね。

ですので、一旦最低限の素質としては保留しておきましょう。

 

仕様書を書く技術

コードが書けない彼らの内、その一部は「仕様書」なるものを書いてお飯にありついているようです。この仕様書を元に、コードが書ける人に理想の実現を代行して貰おうという仕組みのようです。では、この仕様書を書く技術があれば最低限の素質を満たしていると言えるのでしょうか?

所で、みなさんはデスマーチと言う単語をご存知でしょうか。デスマーチとは、破綻したプロジェクトの中でメンバの健康や私生活を無視して、命のある限り過酷な労働を強いる状況を指します。

この地獄の所業が起こりうる要因は沢山ありますが、その内の一つとして、「方向性が確定されておらずフラフラとした質の低い仕様書で強引にプロジェクトを進める」と言うものがあります。

この低品質の仕様書が生まれる更なる原因は、仕様書を書く技術に乏しいと言う事では説明できないことがママにあります。よくある話としては

  • お客さんがコロコロと要望を変える
  • お客さん自身が望んでいるものが分かっていない
  • クリエイティブと言う単語を免罪符に行われる無慈悲な仕様変更
  • 政治的な要因で結論ありきで仕様が決まる

まあ、この辺りでしょうか。これらは仕様書を書く以前の問題ですので、仕様書を書く技術だけでは、安定してお飯にありつけないようです。

ですので、こちらも一旦保留としましょう。

 

算盤をはじく技術

コードが書けない彼らの内、「仕様書」も書かずにお飯にありついている人もいます。それは、算盤をはじいている人です。つまり、お財布を握っている人ですね。

プロジェクトの中では、誰かに働いて貰う為には、それ相応のおちんぎんを用意しないといけません。SIerの世界では、それを「人月」という単位で扱う事が多いです。

 

とある要件を受託し、そのプロダクトを納品する為に、4人で6ヵ月掛かるとしましょう。すると、このプロダクトは 4 x 6 = 24人月必要な案件であると表現されます。

仮に、1人月のランニングコストが社内で70万掛かるとしましょう。これを粗利30%と仮定して、100万/人月で契約すると、24人月で2400万円の案件となります。

 

こういうことを考えて、お金の出入りを管理する人も、ITエンジニアとしてご飯を食べているわけですね。

 

さて、先ほどの例題に戻りましょう。

この2400万の案件で現時点では粗利が30%なので720万なわけですが、良くある話としては、利益を720万ではなく1000万以上に何とかしろと言われることがママにあるわけですね。ここで算盤をはじく人は以下のようなことを考えます。

 

算盤をはじく人「今の予算はこうだ」

 4(人) x 6(ヵ月) = 24(人月)

 24(人月) x 100万 = 2400万

算盤をはじく人「で、以下を達成したい」

 2400万から1000万以上の利益 => 実働1400万でやりくりすれば良い

算盤をはじく人「予算から考え直そう……」

 実働1400万 => 1400万 / 70万 => 20人月

算盤をはじく人「20人月で回せば何とかなる!」

 5(人) x 4(ヵ月) = 20 (人月)

 4ヵ月あれば、土日全部使えば+1月分くらい時間は生まれる

 残業代はかかるが、4人月浮くからそれを更に別案件に売ればいい

算盤をはじく人「ふはははは、完璧じゃないか!」

 

まあ、この後どうなるのかはお察しですね。

このような事ばかりしていると、実際に手を動かしてくれる人はその場を去っていきます。このような焼き畑農業ばかりしていくと最後は自分にも火を放つことになるので、安定してお飯にありつけないですね。

ですので、こちらも一旦保留としましょう。

 

専門特化した知識

「我々には、今まで培ってきた知識・経験がある」

よく聞くワードです。つまり、今までの案件に特化していると言う事ですね。

さて、将来の案件もまた、過去の実績でどうにかなるのでしょうか。

いや、確かに同じような案件は続くかもしれないのでそれらに関しては太刀打ちできるでしょうが、それ以外の依頼では役に立たなさそうですね。

 

もう少し具体的な専門特化を考えてみましょう。

例えば「金融系システムに特化した知識」があったとして、それが売りだと言っている集団に「スマートフォンを使った新しい案件」が飛び込んでくるでしょうか?

多分飛び込んでこないでしょうね。

 

なら、「スマートフォンを使ったソリューションに特化した知識」があると豪語する集団があったとして、将来生まれてくるであろう全く異なる異質な要件が、彼らの元に降り注いでくるかと言うと、きっとその時には回ってこないでしょうね。

 

「我々は○○に特化しています。これ以外は認めません」という生き方はロックですし、切れ味の良い刃物になるのでしょうが、その刀だけで戦い続ける事は出来ません。

ですので、こちらも一旦保留としましょう。

 

コミュニケーション力

新卒採用市場で最も重視されているという噂の能力ですね。

この謎の力、正体は「自分の意見や気持ちを第三者に伝える力」と定義されています。

はて、面接で自己PR出来てる時点である一定水準以上の能力があるような気がしますが、これだけで本当にお飯にありつけるのでしょうか。

実に謎です。無いよりはあった方が良いですが、別に胸張って威張るような技術ではないんでしょうね。となると、こちらも一旦保留としましょう。

 

本当に必要な素質って何?

なんだろうね。

ここからは私の解釈ですが、ITエンジニアに必要な素質は以下のようなものだと思っています。

  • 怠惰
  • 短気
  • 他人に教えを乞う能力
  • 変わり続ける能力

 

怠惰

「怠惰」は原動力です。ITエンジニアは怠惰であるべきです。

楽をする為に苦労を厭わない奇人であるべきです。

その苦労の末に楽を達成し怠惰を実現した時に快楽を覚える変態であると、尚良いです。

 

短気

「短気」は柔軟性です。ITエンジニアは一つの事だけに囚われず、ダメだと思ったら別のアプローチからも攻めるべきです。

鳴かぬ鳥を鳴くまで待つのはITエンジニアではありません。代わりに鳴くか別のモノに鳴かせるくらいの気変わりの早さがあるべきです。

 

他人に教えを乞う能力

出来ないのであれば、出来る人に頭を下げて教えを乞う。

コミュニケーション力とか言ってる人が真に求めているのはきっとこっち。

「出来ない自分」と向き合って、「教えて下さい」と言える人は、きっと強い。

その本質は「貪欲」。知る為なら、「出来ない自分」と向き合う「覚悟」がそこにはある。

 

変わり続ける能力

最初に挙げた5つの技術や能力たちは、一昔前にあちこちで見た条件でした。

でも、実際にはそれでは上手くいかないことが分かっている。

巷でよく見る、「将来なくなる職業ランキング」に名を連ねる「ITエンジニア」という仕事の在り方は、変わる事を拒否し続けた将来の姿であるともいえる。

実際、部分的にITエンジニアの仕事はなくなりつつある。

その一方で、新しい領域のITエンジニアの仕事が生まれつつある。

ITと言う領域は、あらゆる領域と共に歩み、変化し続けていく。

その変化を恐れず、常に変わり続ける事が出来れば、お飯にありつけ続ける事は出来ると思う。

 

また、これらの私が考える素質は、IT業界に限定された話ではないと思っている。

きっと、何処で働くにしても、これらは必要な事だと、私は考える。

Apple「お前らはApple Watchで時計アプリ作るの禁止な」

やあやあ。

色々物議をかもすApple Watch。

そんなApple WatchにAppleからの鬼裁きが下されました。

 

App Store Review Guidelines - Apple Developer

10. User interface
 10.7 Watch Apps whose primary function is telling time will be rejected

 

どうやら、時計アプリは許さないよと仰ってますね。

ううむ。Apple Watchだぜ? 時計だぜ?

coolなUIを持ったイカレた時計アプリが出来上がる可能性だってあったのに、なんだかなあ。

 

既にいくつか時計アプリが出てたような気がしましたが、この大裁き、どう決着をするのでしょうか?

 

ではでは。