【LeetCode】Best Time to Buy and Sell Stock 解法
LeetCode - Best Time to Buy and Sell Stock
自分的な解法はfinalである。 v1は5800ms、finalは120ms。 v1はスライス多様しすぎなへっぽこコード。 finalはsolutionに書かれていたものを理解したもの。
ループを時系列に例えて、その際の最小値と最大利益を順次計算している。
ちなみにmaxProfitはsolution内の書き込みだが、よく理解していない。
class Solution: def maxProfit(self, prices: List[int]) -> int: if len(prices) <= 1: return 0 d = [prices[i]-prices[i-1] for i in range(1,len(prices))] g = [0]*len(d) g[0] = d[0] for i in range(1,len(d)): g[i] = max(d[i], g[i-1] + d[i]) return max(0,max(g)) def final(self, prices): minprice = 9999999999 # sys.maxsize maxprofit = 0 for price in prices: if price < minprice: minprice = price elif price - minprice > maxprofit: maxprofit = price - minprice return maxprofit def v1(self, prices): max_ = 0 for i in range(0,len(prices)-1): v = prices[i] p = max(prices[i+1:]) - v #max_ = max([max_, p]) max_ = max_ if max_ > p else p return max_
【LeetCode】Two Sumの解法
LeetCode - Two Sum
解法。自分の場合は最初はv1（ブルートフォース）。 その次にv2（ハッシュ）、これで速度が100倍になった。 で、コメントをみてv3,finalです。
finalの場合、target - nums[i]をifの中で 計算しているようにしているが、ifがTrueになる確率の方が低いから、 変数への代入のコストが少なくてすむのだろう。 ちなみに enumerateを使おうが使わまいが、速度差はなかった。
あとは、towSum関数に直接コードかかないと30msくらい遅くなるが、 これは備忘録として見やすいようにしているだけ。
class Solution: def twoSum(self, nums: List[int], target: int) -> List[int]: return self.final(nums, target) def v1(self, nums, target): for i, n1 in enumerate(nums): for j, n2 in enumerate(nums[i+1:]): if n1 + n2 == target: return [i, i+1+j] return None def v2(self, nums, target): map_ = {} for i,v in enumerate(nums): map_[v] = i for i, v in enumerate(nums): complement = target - v if (complement in map_) and (map_[complement] != i): return [i, map_[complement]] return None def v3(self, nums, target): map_ = {} for i, v in enumerate(nums): complement = target - v if complement in map_: return [i, map_[complement]] map_[v] = i return None def final(self, nums, target): map_ = {} for i in range(len(nums)): if target - nums[i] in map_: return (map_[target - nums[i]], i) map_[nums[i]] = i return None
【書評】Docker 書評というにはあまりにも失礼なくらいわからない
- 作者:Adrian Mouat
- 発売日: 2016/08/17
- メディア: 単行本（ソフトカバー）
業務でDockerを使うようになってきたので、ちゃんと体系的に知って起きたと思って手にとってみたが、まあむずい。
Ⅰ部 背景と基本
これこれ！こういうことをちゃんと体系的に知りたかったんだよねえ！！
Ⅱ部 Dockerのあるソフトウェアライフサイクル
お、おう。そうだな、こういうハイテクな使い方があるんだ、ふむふむ。
Ⅲ部 ツールとテクニック
・・・。
という具合である。
まあ今使うと言っても、リソースをスケールアウトしたいとか、いろんなコンテナを起動して連携したいとかいう場面はないのだ。 ただ実験環境をクリーンにして、受け渡しやコード管理を楽にしたいという理由でDockerを使っているから、とりあえずI部の内容をちゃんと把握しておけば合格だと思っている。
この書籍の出版は2016年であって、もう4年くらい経ってるわけだから、ここで紹介されている内容だってだいぶ陳腐化されている可能性はある。 書籍でのdocker バージョンは1.9（19じゃない）だし、オーケストレーションでswarmなんて使わないでしょ？しらんけど。 なのであまり変わらないであろう「背景と基本」を抑えておけば、、、あとは必要な時に学習するのがよいのではなかろうか、と自分に言い聞かせる。
まあ3,600円するけど自分にとってその価値があるかというと、微妙ではある。というか、「お前にはまだ早い」と言わんばかりの内容であった。
個人的付箋
コンテナのポートを自動割り当て
-Pという引数を使うとDockerにホスト上の空いているポートを自動的にフォワードさせることができる。
$ ID=$(docker run -d -P nginx) $ docker port $ID 80 0.0.0.0:32771 $ curl localhost:32771 <!DOCTYPE html> <html> …
コンテナ間でのデータの共有
コンテナ間でのデータの共有はdocker runで--volumes-from CONTAINERという引数をつかうことで実現できる。
$ docker run -it -h NEWCONTAINER --volumes-from container-test debian /bin/bash
これを使って複数コンテナ間でデータの共有をするためだけに作られた最小限なデータコンテナを用意するテクニックがある。
開発環境と実行環境の切替
cmd.shというファイルを作成する。
#/bin/bash set -e if [ "$ENV" = 'DEV' ]; then exec python "development.py" else exec python "product.py" fi
Dockerfileに
CMD["/cmd.sh"]
を追記して
$ docker run -e "ENV=DEV" -p 5000:5000 test-container
【書評】みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト
これはやばそうな本が出たぞ。というワクワク感で買ったものの、 amazonの評価を見るとそうでもない感じだった。
同じようなレビューが複数存在していて、なんか著者はみずほ銀行に忖度しているのかと思ってしまったが、 とりあえず読んでみることにした。
結果的にはレビューの通り、罵詈雑言が飛び交うものでもなく、現場の荒れ果てた状況が語られるわけでもなく、どちらかというと、すごいシステムを作り上げたという評価に近いものであった。
本は３部構成になっており、 １部が最近完成したMINORIというシステムについて、２部は東日本大震災直後のシステム障害について、３部は統合後の最初のシステム障害についてである。
２部、３部についてはいろいろ問題があって起こるべくして起きたと語っているものの、１部のMINORIについては、35万人月、4000億以上のコストをかけたすごいプロジェクトを成し遂げたんだ。という内容になっており、拍子抜けだった。
技術者であれば、人が増えることで一人あたりのパフォーマンスは下がることは経験的にわかるはずで、これだけの人数が携わっているならそれはもう想像しただけで恐ろしいと思うのだが、なぜかその苦難というのがあまり語られていない。過去の失敗から学び、大きな問題なく完成させたぞ、みうほは銀行の中でもリードしているのだ。みたいな。
まあ実態は違うんだろうけど、それでもまあここに語られていることが全てならば、予想していたよりもよいものができているんじゃない？と思ってしまう。
- ブラックボックスの排除
- 経営陣のIT軽視、IT理解不足の解消
- IT理解不足の場合は、ソフトウェアが障害の原因なのにハードウェアベンダーの責任を問うなど見当違いが発生する。
- SOAを採用
- APIゲートウェイの採用
- AS IS（現状のまま）の要件定義を完全排除
- Xuppterを使って、「あるべき業務フロー」をゼロベースで検討
- 超高速開発ツールを採用し、属人化を排除
- Fintechとの連携を想定し、コア部分は自前、それ以外はオープンAPIを利用
まあ、言うは易く行うは難しだと思うので、MINORIが完成したことはすごいとは思うし、障害が発生しないで星いと思うばかりである。
【書評】「新しいLinuxの教科書」大まかな風呂敷の大きさがわかるつもりになれた。
GW中にざっと読んだ本。
仕事でubuntuはよく触るけど、あくまで実践的に触る程度で、 躓いたらその都度ネットで調べるというスタイルだった。
なのである特定のコマンドはしってるけど、/varがなんだとか/etcがなんだとかは知らないし気にしていなかった。 ネットで「そこにシンボリックリンク」とあればそうするだけだ！みたいな。
まあそれだと寂しいので、ちょっと前に、独習Linuxを読んだ。
- 作者:小林 準
- 発売日: 2011/12/17
- メディア: 大型本
これはこれで良い本だった。中古で200円くらいで買った気がする。 ただ、まあ最近は「教科書」とかいうのが出てそれの評価が高いので、じゃあっと思って読んでみたけど、 まあ、わかりやすかった。
20のチャプターから構成されている。 最初にLinuxとは、から始まって、あとは具体的なコマンドの羅列、後ろの方にシェルスクリプトの実践やgitについての説明など。 程よく浅く網羅されているんだな、と感じた。とはいえ、Linuxの全体像を知らないから、これで全部かはわからないが。 これを教科書とするなら、風呂敷の大きさは大体わかった気分になれる。 実際はもっと奥深いんだろうが。
LPICなどの資格を受ける場合はこの範囲をさらに深堀りする必要があるだろうなと思うが、 とりあえずwindowsユーザーがLinuxを触るさいには、一読しておいて損はないと思った。
ただ、「教科書」というのは、実はただで入手できる。
まあ、2700円払うのがもったいないなら、こちらですませてもいいと思う。
個人的な付箋
sshを使って、リモートホスト上のファイルを直接手元にコピーする方法。
ssh osumi@serverB 'tar czf - dir1' | tar xzf -
czf -と指定することで、リモートホスト上でディレクトリdir1をtar+gzファイルとしてアーカイブし、その出力をこちらのシェル標準入力へと渡している。 手元のシェルでは、受け取ったtar+gzのデータストリームをxzf -として展開することで、リモートホスト上のdir1ディレクトリを直接手元にコピーすることができる。
GW中の勉強内容
以下の通り。
- udemy これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）
- セクション15/16完了
- AtCoder
- 165
- 166
- 読書
- さあ、才能(じぶん)に目覚めよう
- OpenSSH［実践］入門
- 新しいLinuxの教科書
- 勉強会
- CDLE勉強会 #1
家族がいるのでフルタイムで勉強はできなかったが、 朝5時に起床して３、４時間勉強に当てた。 あとは寝る前に、読書。 ドラマと映画はまあまあ見たが、udemyの講座が終わらなそうなだったので途中から我慢。
udemyの講座はすごく有益だった。これがセールで1400円弱だと言うのは本当にすごい。
今はクラウド前提だし、クラウド前提の場合awsファーストで考えないといけないし、 という講師の見解があったが、勤めている会社はそんなのまったく触れ的てないどころか、 インターネットは敵であるみたいな考えだからまあ、未来は明るくないだろう。 会社をあてにせず精進したいが、やはりawsはお金がかかる。 この講座を受けるにあたってawsに課金した金額は約1000円くらい。 実サービスとして利用したらやはりかなりお金がかかるんだろうなと考えると、 個人での利用は厳しい。
とにかく、まだ理解できない点は多々あるので、これはblackbeltや書籍を買って補う。
できなかったこと
【書評】「さあ、才能に目覚めよう」は全く色あせていない
さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0
- 作者:トム・ラス
- 発売日: 2017/04/13
- メディア: 単行本
この本は、2011年に購入した。今は2.0というのがあるが、購入したのは1.0(2.0とついてないもの）。 勝間和代の帯が若干恥ずかしいんだけど、それは置いとく。
社会人も11年目になる、この本は入社して2年目くらいに買った本で、 何かのサイトでお勧めされていたと思われるが、そのまま積読してしまった。
そして今、自分は色々社会人として悩んでいる。 このままだらだらと仕事をこなすのか、思い切って環境を変えるのか。 そもそも自分は何がしたいのだろう？microsoftの澤さんがいうように、beingを考えたとき 自分はどうしたいんだ？と答えが出せなかった。
そんな時にふとこの本を思い出した。 自分の才能ってなんだろう。と。 そしてこの本にあるストレングスファインダーをしてみたという流れである。
この本は、7章まであるが、大まかに3部構成になっている。
- 才能についての説明
- 自分の才能の活かし方
- 他人の才能の活かし方
前半中盤と、自分と向きあう内容になっており、これはこれですごく役に立つ。 まず自分の才能がなんなのか。 40分くらいのテストに回答すると、34種類の才能の中から特に特徴的な5つを発見してくれる。
自分の場合は、過去に述べた通りである。
その才能をとりあえず受け止めることにした。 直感と外れていないし、自分にとってこうありたいという内容と近いからだ。
しかし、この書籍で（期待していなかったが）嬉しかった内容は終盤の 「他人の才能の活かし方」である。 昨今withコロナで働いき方が否応なしに改革されている中で、 この本に書かれている内容は非常に重要だと思う。全く色あせていないどころか、今読むべき本なのかもしれない。
さて、他人の才能の活かし方、と書いたが、 他人というよりも部下にあたるかもしれない。 これはマネジメントに近い話である。 部下に何を期待するのか、どう接するのか、どう評価するのかなど。
自分の場合は部下というよりチームメンバーにあたるが、 年齢的に一番上というのもあって若干マネジメントのようなこともしている。
その際に漠然と思っていたことがこの本に書かれていた。 自分の中では、こういうチームができたらもっといいのになと思っていたことが、 この本でその通りのことが書かれていて、すごく嬉しかったのだ。間違ってなかったと。
例えば下記。
ここの従業員を型にはめ込むのではなく、あくまで最終的な結果に重きをおくべきだ
日本の多くの企業がそうかもしれないが、多様性は基本的に認められない。 評価の多くは減点法であり、平均的にミスしない人間が評価される。 特別目立ったスキルを持っている人間を特別なタスクの担当にさせるようなことも滅多に起こらないし、 そもそもそのようなスキル発掘の場を設けていない。本当はあの人はすごいのに・・・もったいない。という人材がたくさんいるのだ。 彼らが評価されないのは、１種類の陳腐な物差しですべての社員を評価しているからだ。 さらにそれが過程の比重が大きいからたちが悪い。例えば残業して頑張っているかどうか、上司に好かれているかどうか。等。
研修にかける時間と資金は、従業員の弱点を矯正してスキル・ギャップを埋めるだけではなく、一人ひとりの強みを発掘し、それを伸ばすために費やすべきだ
社内研修や社外研修はあるが、本当に心の底からクソだと思ってしまう。この時間を返してくれと切に願う。 そもそも何のための研修なんだろうと考えると、管理部の自己満なんだろうなとしか思えない内容だ。 これで何をしたいんだろう、ビジネスマナーや論理的思考など、すっごい薄っぺらい内容だ。 なぜエンジニアが受けるのか。この疑問に対する答えは「社会人としての常識」などであろう。 でもそんな常識を立派に持っている人間よりも、バリバリ設計やコーディングができる人間の方がプロジェクトはうまくいく。
専門知識のある従業員とここの顧客との関係が尊重される知識経済の世界では、特定の分野にしろ、顧客情報にしろ、従業員の方がマネージャーよりもくわしいなどということがいくらでも起こりうる。そういう状況でマネジャーが従業員の決定や判断を覆すおそれががあるようなら、そんな企業はすぐに力をなくすだろう。
上司は、なぜか自分を偉いと思う。部下を教育するとか、部下をしかるとか、訳のわからないことを抜かす。 そのくせ仕事は承認印を押す、定例会議に参加するがメインである。 忙しいというのは、シャローワークだろう。誰にでもできる仕事で忙殺されている人間のどこが偉いのだろう。
自分は役職はついていない。そして役職をもらうための社内政治もするつもりはない。 今の会社では役職はいらないと思っている。この会社での陳腐なものさしで自分を計測されるのが嫌で仕方がない。 ただしチームメンバーやその他従業員に対して、一緒に何かを作り上げたいという気持ちはあるし、 彼らの人生を棒に振るうような飼殺し的なキャリアパスは避けさせたい。 そのための努力はしたいと思っている。
まずは自腹でチームメンバーにこの書籍を買おうと思う。 そしてお互いの才能を確かめ合い認め合うことから始めようと思う。
