( ´・ω・)ﾉ こんにちは 👋

抱負 (仕事) チーム開発の気持ちを持って開発する (プライベート) インプット/アウトプットを常に行う 旅行に行く 筋トレを行う 英語学習 インプット/アウトプットを常に行う 自己学習をしているが、あまりアウトプットができてなかったので、 今年はインプット/アウトプットを常に行う年にする やることとしては以下の通り。 最低月一でアウトプットする(Zenn, blog, OSS, etc…) 旅行に行く 今年は旅行の頻度を増やしていきたい。 国内旅行は勿論だが、海外旅行にもいきたいと思う 筋トレを行う 物だけ揃えて、行っていなかったので初めていきたい w 英語学習 学生時代に英語学習を怠けていたので、久しぶりに TOEIC を受けたら 絶望的な点数を出してしまった。 また、昨年は Duolingo を使って学習していたのでまた復活しつつ、 TOEIC 対策などしていく。 チーム開発の気持ちを持って開発する 昨年の反省点だったので、今年は改善していく。 課題点はコミュニケーションだと思うので、もう少し活発になるように 自ら意見を述べつつ活性化できるようにする。

新年の目標は 1 月 1 日に書きます。 結論 転職した 炊飯器を買った 転職した 以前ブログでも書きましたが、転職しました。 転職先は内緒ですが、当初希望していた Go エンジニアになっていました。 本当はフルスタックに色々やりたいのですが、 とりえずバックエンドを伸ばしていきたいなと思っていたので結果 OK だったと思います。 入社前とのギャップとしては、時々精神的にキツイと感じることですね。 前職は、結構ぬるま湯のような職場だったのでそれが原因なところもありますが、 現職ではそこのギャップに悩まされることもありました。 また、チーム開発というより個人開発に近い開発スタイルだったこともありますね。 チーム開発感が少なく、ちょっと相談しづらい環境を感じています。 来年はもう少し意見を述べつつ、チーム開発感を出しながら開発したいですね。 あとは、Flutter にも興味がちょっとでてきたいので開発してみたいです。 炊飯器買いました そのままです。ちなみに買った炊飯器はこちら

コードレビューを行う際に自分が注意している点をまとめてみました。 余談ですが、最近リーダブルコードの本買いました。（どこかでブログに書くかも) レビュ-の際の注意点 以下の観点に注意しながらレビューしています。 タイポ 共通化できるもしくは、共通化されているメソッドを使っているか 命名規則 言葉遣い コメント タイポ 当たり前といえば当たり前かもしれません。 また、メソッド名やエラーメッセージのタイポも丁寧に指摘します。 とはいっても、xxxが間違ってます！といった命令口調ではなく xxx -> yyy と思いますーといったように修正後は こんな感じになりますよと相手に優しく伝えるようにしています。 共通化できるもしくは、共通化されているメソッドを使っているか これも、タイポと同じくらい注視しています。 例えば、チーム内で共通化されたメソッドがあればそれを使うように促したり、 共通化できそうなところは、参考コードを添えてレビューするようにしています。 命名規則 例えばブログサイトを構築していたとして、以下のような関数があったとします。 確かにブログを作成するための関数として create を選んでいると思うのですが、 これでは他の方が見たときに、何を作成するための関数なのか分かりずらいです。 func create(){ xxxx } 長すぎず、短すぎず、汎用的すぎない命名になるので難しいところではあると思います。(自分もよく指摘される) 相手に分かりやすく伝えるような命名になっているか確認するようにしています。 なかなか決められない時は、codicなどのサービス使って作成するときもあります。 言葉遣い 以下の二つのコメントがあったとします。 <A> ここはxxxのように修正したほうがいいです。 <B> [IMO] ここはxxxのように修正したほうがいいと思いました！ ~~参考コード~~ どちらの方が相手に良い印象を与えられそうでしょうか？ Aの方が命令口調でサバサバしていて、Bはトゲがない感じがしますね。 また、Bは参考コードまで載せているので相手の方はどのように 修正すればいいのか分かりやすくなっていると思います。 このように、ただただ間違いを指摘するのではなく 参考コードや相手を不快にさせないコメントの書き方をするだけで 良いレビューになるのではと思います。 また、Bのコメントのように[IMO]と添えてあげるだけで どのような考えなのか可視化できると思います。 特に自分は、[IMO]と[Q]を使います。 IMO…自分ならこのようにするかなーなど Q…実装で不明点などを聞く時（仕様がよくわからないなど) コメント 意味のあるコメントと意味のないコメントを精査しながらチェックしています。 人によっては、コメントではなくコードを読めという人もいるかと思いますが、 私はコメントなら大歓迎なタイプです。 意味のないコメントでは以下のようなコメントが挙げられます。 // アカウントが存在する場合 if account { xxx } パッと見たときに何をしているか判断できるものはコメントが不要かなと思います。 また、以下のような形で書く場合は修正を促しています。 // ブログ作成 func createBlog() { } あくまでGoの場合ですが、 // method名 コメント内容で書くのが一般的かなと思います。...

問題 回答 正解は①です。（このままだと） 解説とおまけ 前回はTupleかと思いきやstrだったやつでしたが、今回はちゃんとTupleです(笑) パッと見、aか1120を返してくれそうですが実はTypeErrorになります。 理由は型の違いです。 Tuple1にある、1はint、aはstrになります。 そのためTypeErrorになります。 ただ、これを型を変えることで以下のように比較することができます。 正解はどちらと思いますか？ tuple1 = (1, 'a') print(max(str(1120, 'a'))

インスタとかでプログラミング系を見てると海外の方が、 こんな感じの問題をあげられていることありますよね。 今回はこの問題を解説付きでサクッと解いてみようと思います。 (当分この投稿するかも・・・) 問題 答え 正解は、Aになります 解説 まず一行目から見ていきましょう。 Tuple = ('Python')*3 こちらは、変数Tupleに Python の文字列を代入しています。 ただ、('Python')*3となっていますね🤔 *は算術演算子となります。 そのため、文字列と文字列を任意の回数繰り返すだけとなります。 ちなみに、変数名はTupleですが、実際の型はstrです。 Tuple = ('Python')*3 print(type(Tuple))　#=> <class 'str'> これは、Tupleにする場合要素で区切る必要があります。 Tuple = ("Python", ) print(type(Tuple)) #=> <class 'tuple'> 変数名に騙されると、一瞬Tupleかなと思ってしまいますが、 コードをちゃんと読むと、全く異なるものが作成されますね。