AtCoder 勉強記録 ~茶色コーダーを目指して~ [ABC 159-D]
今回の問題
AtCoder Beginner Contest 159 D - Banned K
atcoder.jp
私の解答
https://atcoder.jp/contests/abc159/submissions/12682578
import collections n = int(input()) a = list(map(int,input().split())) new_a = collections.Counter(a) // 出現回数の分布取得 total = 0 for key, val in new_a.items(): if val > 1: total += (val * (val - 1) // 2) // すべてのボールがある状態の取り出す方法の数 for i in a: ans = total ans -= new_a[i]-1 // 出現回数を1つ減らした取り出し方法数をtotalから引く print(ans)
解説
普通にループで毎回取り出し方法の数を数えるとTLEになってしまう。
考え方としては、最初にすべてのボールがある状態の取り出す方法の数を計算しておいて、
そこからそれぞれ出現回数を1つ減らした取り出し方法数を引けばよい。
計算量の想定ができないから無駄な実装をしてしまいました。もう少し慣れが必要そう。
ちなみに下記がTLEになった実装です。
import collections import itertools n = int(input()) a = list(map(int,input().split())) for i in range(n): ans = 0 pop = a.pop(i) new_a = collections.Counter(a) # print(new_a) for key,val in new_a.items(): # print(val) if val > 1: ans += (val * (val - 1) // 2) a.insert(i, pop) print(ans)
AtCoder 勉強記録 ~茶色コーダーを目指して~ [ABC 157-C]
今回の問題
AtCoder Beginner Contest 157 C - Guess The Number
atcoder.jp
私の解答
https://atcoder.jp/contests/abc156/submissions/12558699
n = int(input()) x = list(map(int,input().split())) ans = 10**10 for i in range(100): wa = 0 for j in x: wa += ((j-i)**2) ans = min(ans, wa) print(ans)
解説
1<=N<=100 という条件から、1から100までの整数をループで全部チェックして、その中から最小値を出しました。
このレベルの問題ならあまり悩まずに答えられるようになったのは成長だと思います。
AtCoder 勉強記録 ~茶色コーダーを目指して~ [ABC 157-C]
初めに
こんにちは。
去年からAtCoderで競技プログラミングを始めており、これまでは毎週のコンテストに参加するだけだったのですが、最近、茶色コーダーを目指したいと思い、力を入れて過去問を解いていきます。言語はpython3です。
基本的にはABCのC問題を中心に解いていこうと思っています。
今のレートは196です。(2020/5/1 現在)。目指せ今年中に茶色コーダー!!
今回の問題
AtCoder Beginner Contest 157 C - Guess The Number
atcoder.jp
私の解答
https://atcoder.jp/contests/abc157/submissions/12546787
n, m = map(int, input().split()) sc = [list(map(int, input().split())) for _ in range(m)] for i in range(1000): //0~1000までの整数をチェックする ans = str(i) //チェックしやすいように文字列に変換 if len(ans) != n: continue for s, c in sc: if int(ans[s-1]) != c: //条件に合わなかったら次の整数のチェックへ break else: print(ans) exit() print(-1)
解説
まず、考え方のポイントですが、答えは最大3桁の整数なので、それらすべての整数をループで回して条件に合うか調べます。
競プロになれてないと、そもそもそこに気が付かずにいろいろ考えちゃって沼にはまってしまうと思います。私もそうでした。。そこら辺の勘所は慣れが必要だと思います。
また、チェック時に整数を文字列に変換しておくと、チェックしやすいです。
◆入力が下記の場合
3 3 1 7 3 2 1 7
- n=3なので、100から999までをチェック
- 左から1桁目が7、3桁目が2、1桁目が7に合致したら出力
◆入力が下記の場合
3 2 2 1 2 3
- 左から2桁目が、1かつ3の整数はありえないので-1を出力
「心理的安全性」基礎知識
はじめに
最近チームに後輩が増えてきて、後輩が働きやすく、成長できる環境を作ることを意識して仕事をするようになりました。その際に「心理的安全性」の基礎知識について調べたことをまとめました。
私は、計3名との週次の1on1面談を、2020/4/30 現在までに約1年半ほど続けているので、今後、1on1のやり方の記事も書こうと思っています。
「心理的安全性」とは?
Googleがチームの生産性を上げるために最も重要な要素として発表
- メンバー1人ひとりが安心して、自分が自分らしくそのチームで働ける
- このチームでリスクをとったとしても、対人関係上の亀裂や破壊が起こらないであろう、とチームに共有された信念
「リスクをとりながら一人ひとりが学び合い、成長し合う、そしてそれがメンバーそれぞれの喜びであり幸せであり、チーム全体の成長につながる」
「心理的安全性」の誤解
- みんなで仲良くやること
- 安心安全な労働環境をつくること
- チームのメンバーが傷つくことがないことが保証されている状態
これらと全く同等ではない。
「メンバーそれぞれが、リスクがあっても学びたい、成長したいと思っている。そして、実際に行動している。ということが前提」
「心理的安全性」が低いとどうなる?
4つの不安
生産性の高いチームは「心理的安全性」が高い
リーダーの在り方
-
リーダーのマインド
- 行動基準は「全体最適」
-
言い訳をせずに、言動に一貫性を
-
怒らない、愚痴らない、妬まない を率先する
-
明るく楽観的、原則ご機嫌であること
-
自分軸を整える
-
自分を丸ごと「自己受容」する
-
自分の強みで人の役に立ち、弱みは見せて周りに助けを求める
-
自分のありたい姿(ビジョン)と価値観を認識する
-
自己認識のために周りからのフィードバックを真摯に受け止める
-
チームのミッションステートメントをつくる
リーダーのマインド
◆行動基準は「全体最適」
リーダーは、自分や自分のチームのため、自分の上司など特定の人のためだけではなく、なるべく会社全体のためになる決定をする。
◆言い訳をせずに、言動に一貫性を
小さなことも言い訳せずに、間違いは認めて謝る。そして問題解決に取り掛かる。
リーダーが率先してこれを実践すると、メンバーも言い訳をせずに、ミスを早期に認め、チーム全体が問題解決志向になる。
◆怒らない、愚痴らない、妬まない を率先する
怒りや恐怖など、自分の感情を発散することで人をコントロールしようとしてはいけない。
感情が動くということは、そこに必ず「満たされないニーズ」がある。
そのニーズにフォーカスすることが大切。
◆明るく楽観的、原則ご機嫌であること
リーダーだからといって、高い社交性が必要なわけではない。
ただし、少なくとも楽観的な姿勢を示すことが大切。
リーダーこそ、健康に気を使い、しっかりと睡眠や栄養を取り、
ご機嫌状態をキープする。
自分軸を整える
◆自分を丸ごと「自己受容」する
「あるべき自分」ではなく、「ありのままの自分」を好きになって、
自分を丸ごと受容する
◆自分の強みで人の役に立ち、弱みは見せて周りに助けを求める
なるべく自分が苦労せずに楽にできること、そして好きでたまらなくて、言われなくてもついやってしまうことで人から感謝されることをする。そして少しずつ自分の仕事の中で自分の強みを生かした仕事の割合を増やしていけるように、自分から仕事内容を提案していく。
リーダーが「弱みを見せる」
勇気がいることだが、チームに与える影響力は大きい。
リーダーがいち早くその勇気を見せると、メンバーも勇気を出して弱みを見せやすくなる
◆自分のありたい姿(ビジョン)と価値観を認識する
自分がどうありたいか、心底感じられるものが本当の自分の在りたい姿=ビジョン。
自分のビジョンとチームのビジョンの重なり部分を探す。
自分が学び成長することがチームに貢献することになる。
自分のビジョンが明確になってくると、メンバーのビジョンを見つける支援ができる。
◆自己認識のために周りからのフィードバックを真摯に受け止める
本来、人は自分のことは見えていない。だから、他者からのフィードバックが必要。
他者からのフィードバックを真摯に受け止め、感謝をして、自己認識を高め続ける努力が不可欠。
チームのミッションステートメントをつくる
ミッションステートメント=チームが共有するべき価値観、行動指針
実際にメンバーの発した言葉で作ることが大切。納得感が生まれ、チームの軸になる。
メンバーとのコミュニケーション
-
基本
-
まずは信頼、信頼は存在承認から
-
個人の強みにフォーカスして、人は成長できることを信じること
-
リーダー自ら弱みをさらけ出し、メンバーに助けてもらう
-
一人ひとりの価値観や思いを尊重し、成長を応援しあう
-
強みを引き出し、つながりをつくる会話
-
管理ではなく、自律を支援する
-
自律することは幸せである
基本
◆まずは信頼、信頼は存在承認から
チームのメンバーそれぞれを、ありのままで素晴らしい、存在するだけで素晴らしいと、認めてあげる。
自分のことを変えようとコントロールしてくる人、自分が変わらないと認めてくれない人を、人は敏感に感じ取り、自ら進んで心を開くことはありません。
◆個人の強みにフォーカスして、人は成長できることを信じること
人間の能力は人それぞれ。
メンバー個人の強みにフォーカスして、それぞれの強みの方向への伸びしろを予測しながら、適材適所をはかる。
◆リーダー自ら弱みをさらけ出し、メンバーに助けてもらう
メンバー同士が弱みを見せあい、頼って感謝しあう。感謝されれば、得意で自然にできることで貢献したいという気持ちはどんどん高くなります。お互いが補完し合う文化があるチームの生産性は必ず上がる。
◆一人ひとりの価値観や思いを尊重し、成長を応援しあう
人生は仕事だけではない。
仕事以外のやりたいことや夢についてもリーダーが自ら話し、メンバーそれぞれの話も聞いてみる。そして、できるだけ望みを叶えてあげようとすると、信頼関係が高まる。
◆強みを引き出し、つながりをつくる会話
・どんな時に相手とのつながりが強まるか
⇒相手の悪いニュースに反応した時よりも、よいニュースに反応したとき
・「最近あったいいことを教えて!」
・「すごいね!もっと聞かせて!あなたのどんな行動がいい結果につながったの?」
⇒良いニュース
・相手の強みに着目
・ポジティブな感情
・視野、思考、行動を広げ、成長を促す
・やればできるという「自己効力感」を養う
⇒自分のマイナス部分、つまり弱みを見せる会話も少しずつしていくようにする
管理ではなく、自律を支援する
◆自律することは幸せである
チームメンバーが自律的に考え行動するチームは間違いなく生産性が高い。
だからといって、厳しくハッパをかけたり、部下を管理、統制しようとしたりすると部下はますますやる気が起きず、疲弊していく。
「コントロールされて幸せな人はいない」
自分で決めたい」という感覚は生まれながらに誰もが持っているもの。
「自律性」は「関係性」から始まる。
「関係性」「自己効力感」「自己決定」の欲求を満たしてあげれば、自律性は自然に育まれます。
-
制限されたくないという気持ちに共感し、その気持ちを認める(共感)
-
なぜそのことが大切なのか、合理的な理由を説明する(説明)
-
圧力を最小限にした言い方や質問の仕方で伝え、選択の余地を与える(自己決定)
・人は自分で決めたことであれば、納得感を持って行動することができる
最後に
以上が、「心理的安全」の基礎知識です。ただ知識を持ってるだけでなく、実際に実践することが一番大切です。普段からチームメンバーの幸せと成長を願って仕事をすると自然と改善点が見えてくるはずです。
JavaScript学習記録 基礎編 第1回
初めに
最近業務でプログラミングをがっつり書くことが減ってきているのと、今後フロントエンドの開発にも携わってみたいという気持ちからJavaScriptの勉強を始めました。
まずは基本的な構文から、徐々に応用編に入っていって、最終的にはReactによるアプリ作成まで学んでみたいと思っています。
※私はJavaやPythonといった言語を業務で使用した経験があるので、プログラミング言語共通の概念などは省いています。
どんな言語?
ブラウザで動かせる言語
近年のWebサイトのほとんどに使われている
なぜ必要?
HTMLとCSSだけではできない動きのある、より使いやすいWebサイトやWebサービスを作るために必要
従来のWeb | 現代のWeb |
---|---|
HTMLとCSS | HTMLとCSS+JavaScript |
レスポンスとしてHTMLファイルを返す | レスポンスとしてJSONを返す |
ページ遷移の度にレンダリングされる | ページ遷移時に最小限のレンダリング |
JavaScriptの仕事
大きく2つ
- JSONデータのやり取り
- DOM操作
DOMとは?
Document Object Model (DOM)
「ドキュメントを物として扱うモデル」
プログラムからHTMLやXMLを自由に操作するための仕組み
※ここは別記事でさらに深堀してみたいと思います。
変数
関数
※ここは別記事でさらに深堀してみたいと思います。
基本的な書き方
function 関数名(引数1,引数2,…) { 処理 return 返り値; }
関数式
const sample = function 関数名(引数1,引数2,…) { 処理 return 返り値; }
匿名関数
関数式の時に関数名は付けなくてもよい
const sample = function(引数1,引数2,…) { 処理 return 返り値; }
アロー関数
「function」不要で => を書く書き方
const sample = (引数1,引数2,…) => { 処理 return 返り値; }
ロジカルライティングとテクニカルライティングの基礎知識
- 初めに
- 基礎知識
- 分かりやすい文章が書けるとどうなる?
- 分かりにくい文章とは?
- ロジカルライティング
- 「読み手」を意識する
- 「目的」を明確に設定し、読んだ人の行動を想定する
- 書き出す前にロジックを組み立てる
- ロジックを組み立てるメリット
- テクニカルライティング
- テクニカルライティングのメリット
- 分かりやすく、簡潔な文章を書くテクニック
- 一文一義で書く
- 文を長くしない。「~(だ)が」、「~ので」で分を繋げない
- 一文を短く。50文字以内に収める
- 5W2Hを盛り込み、曖昧な文章にしない
- メールの件名、文章のタイトルから目的が伝わるように書く
- 「話し言葉」と「書き言葉」を使い分ける
- 接続詞の使用は最小限に抑えて、効果的に使う
- 読み手に伝わる文章を書くテクニック
- 最も重要な内容を先に書く
- 否定表現に気を付ける
- 受動態と能動態を使い分ける
- 具体的に情報を盛り込んで書く
- 「など」を多用しない
- レビューを受けて、分かりやすさを高める
- 最後に
初めに
普段業務をしていて、些細な連絡から、障害報告など毎日何かしらの文章をみなさん書いているはずです。その文章って本当に読み手に完璧に伝わっていますか?うまく伝わってなかったことで無駄なコミュニケーションコストがかかったことが必ず一度はあると思います。文章力は一生役立つ基本的なスキルです。
私も最近業務で重要な報告を偉い人に書いたり、後輩に文章作成のサポートをする機会が増えてきたので、今一度「伝わりやすい文章」とは何かを学んでみました。
下記の本を参考にさせていただき、私なりに重要だと思うところをまとめました。
AWS 認定ソリューションアーキテクト アソシエイト 資格の取得体験記
始めに
2019年にAWS 認定ソリューションアーキテクト アソシエイトを取得したので、資格についてや勉強方法などの体験記を書こうと思います。
当時は勉強効率が悪くて受験3回目でやっと合格しました。当時の失敗談も含めてこれから取得したいと思っている方に少しでも参考になれば幸いです。
私はAWSを使った業務経験があるので、実際にサービスを触りながらの試験勉強はしていないので、特に未経験者など、実際にサービスを触りながら勉強したいという方にはあまり参考にならないかもしれません。
※試験の概要などは2019年の受験当時の情報なので、古くなっている可能性があります。
AWS 認定ソリューションアーキテクト アソシエイトとは?
概要
※公式ページからの引用
AWS 認定ソリューションアーキテクト – アソシエイトの試験はソリューションアーキテクト担当者向けです。この試験に合格すると、AWS のテクノロジーを使用して安全で堅牢なアプリケーションを構築およびデプロイするための知識を効果的に証明できます。
受験者の次の能力を検証します:
まとめると
「AWSのテクノロジーを使用して、要件に基づき適切なクラウドシステム設計ができる」能力を証明してくれる資格です
受験対象者に求められるもの
※公式ページからの引用
- AWS 上で可用性、優れたコスト効率、耐障害性を備え、スケーラブルな分散システムを設計した 1 年間の実務経験
- AWS のコンピューティング、ネットワーキング、ストレージ、データベースサービスの実践的な使用経験
- AWS のデプロイおよび管理サービスに関する実践経験
- AWS ベースのアプリケーションに関する技術的要件を特定、定義する能力
- 提示された技術的要件を満たす AWS のサービスを特定する能力
- AWS プラットフォームで安全性と信頼性の高いアプリケーションを構築するために推奨されるベストプラクティスに関する知識
- AWS クラウドでのソリューション構築における基本的なアーキテクチャの原則に関する理解
- AWS のグローバルインフラストラクチャに関する理解
- AWS に関連するネットワーク技術の理解
- AWS で利用できるセキュリティ関連の機能およびツールと従来型サービスとの連携に関する理解
まとめると
AWSに関する広い知識と経験が必要
(実務経験無くても合格できる)
試験の概要
※公式ページからの引用
- 複数の選択肢と複数の答えがある問題
- 試験時間: 130 分間
- 試験は英語、日本語、韓国語、中国語 (簡体字) で受験できます。
- 模擬試験受験料: 2,000 円(日本語版 / 税別)
- 本試験受験料: 15,000 円(日本語版 / 税別)
受験料が高いと感じますが、ベンダー資格なのでこのくらいでしょう。
問題数は65問で合格点は720点(100点~1000点満点)です。
模擬試験も本試験も、問題の見直しができないのと、答えも教えてくれないので注意が必要です。
合格までの道のり
ここからが本題です。
これまでのAWS経験
新卒~3年目まで
- 業務で少し触っていたものの、EC2やS3などの基本的なサービスの基本的な機能しか触っていなかった
・ベストプラクティスも浸透しておらず、みんな手さぐり状態
・全世界にまたがる大きなサービスだったので、パフォーマンスやコストの面 での考え方はいろいろ経験できた
3年目~5年目まで
-
徐々に触れるサービスを増やしていき、ある程度のサービスの概要は把握できるようになった
・ベストプラクティスに則った可用性や伸縮性を持ったシステム構築
・新しいサービスとか機能をどんどん試せる環境だった
触ったことのあるサービス
EC2/Lambda/ELB/S3/DynamoDB/ElastiCache/RDS/VPC/CloudFront/Route 53/CodePipeline/CloudWatch/CloudFormation/IAM/CloudSearch/API Gateway/SNS/Elastic Beanstalk
試験を受けた動機
- 何かしら資格を取りたいと思ったから
・情報系の資格(応用情報とか)はモチベーションが上がらない。。。
・いままで触ってきたAWSなら頑張れるかも!他の人と差別化できそう! -
「AWSについてはある程度は知っています!」自信を持って言いたいから
-
なにかしら将来に役立つと思ったから
合格までの経緯
- 2019年2月ごろから本格的に勉強スタート
- 2019年2月後半に一回目の受験
⇒結果は645点で不合格(合格ラインは720点) - 2019年4月後半に2回目の受験
⇒結果は698点で不合格 - 2019年5月前半に3回目の受験
結果は788点で合格
勉強時間⇒約3か月間、一日平均30分くらいのトータル45時間くらい
かかったお金⇒受験料(15000)×3+参考書など(約5000)=約5万円
AWSを実際に触りながらの勉強はしていない
高額なオンラインセミナーは受けていない
勉強方法
勉強方法~1回目の受験まで~
- 書籍を繰り返し読む
-
AWS公式の模擬試験を受ける
・自宅からオンラインで
・問題とか回答は教えてもらえず、点数だけ教えてもらえる
・問題をキャプチャしておいて、後で見直す
・本番よりは少し簡単
勉強方法~2回目の受験まで~
- 知識が足りないと思ったサービスを中心に勉強
・Black beltというオンラインセミナーのスライド資料
・Udemyの「これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(初心者向け20時間完全コース)」を受講
⇒セールの時に買うのがお勧め(通常12000円が1400円くらいになる)
勉強方法~3回目の受験まで~
-
合格に必要な知識はある程度付いたと判断したので、新たな書籍などは読まずに、いままでの復習と模擬試験をひたすら繰り返す
勉強のポイント
個人的にしっかり理解しておいた方がよいと思うサービス
- Compute
EC2/EC2 Auto Scaling/Lambda/ELB
- Storage
EBS/S3 -
Databases
DynamoDB/RDS -
Networking & Content Delivery
VPC/Route 53
最後に
私は勉強効率が悪くて時間がかかってしまいましたが、個人的にはサンプル問題を繰り返しやりつつBlack beltの資料を読み込むのが近道だと思いました。
また、必ずしもAWSコンソールを触りながら勉強する必要はありません。
有料のセミナーとかは受けなくてもなんとかなります。AWSの業務経験がある人は特に。
後は、ネットには情報があまりないので、自分にあった勉強方法を見つけるのが重要だと思います。