思いついた順に
黄色→若葉→ピンク→紫→茶色→赤→...とレベルが別れてて、今だと紫中位くらいまでしか登れないので、今年前半で茶色、年末くらいには簡単な赤が登れるようにしたい。
12月にふと思いついてやってみたプランクが、最初は20秒が限界だったのに2分くらいは維持できるようになったのでそれを続けつつ、腹筋が割れるくらいにはしておきたい。
今まではRuby→C++→Goはやってきたので、今年は積ん読状態になってる実践Rustを進めたりツールを作ってみたりしてRustに慣れる。
なんとなく使ってるdockerの下のlxcだったり、束ねて使うk8sだったりを理解してどういうシチュエーションで使うのかをわかるようにする。
前年に引き続き、リアルタイム通信サーバ・クライアントの開発をやってた。
3月の途中で新卒から4年間働いていた会社を退職して、有給消化期間にギリシャに旅行に行った。
クレタ島 というところにほとんどいたが、まだ寒かったのであまり人もいなくて快適だった。
今の会社に転職した。
直前2年くらいC++で開発をやってたのが、久しぶりにRailsでの開発になったので、少し懐かしい感じがあった。
いろいろ好き勝手やってた気がする。
ちょっと大きめの機能開発をやった。
すでに5年以上メンテナンスされているシステムのロジックと折り合いをつけながら開発するのが結構大変だった。
Railsでの開発からはちょっと離れて、Goでのサーバ開発をやり始めた。
社会人になってからRails、C++、RailsときてたのでGoは初めてだったが、最初は書きやすいC言語みたいな雰囲気を感じてた(なんでこの言語がWeb系でよく扱われるようになったのかが分かってない)が、Ruby(というかRails)よりも表現力がちょっと乏しくどうしても記述量が増えちゃう感じが否めないと思った。
が、一方で事前にコンパイルすることで実行前に一定のミスに気づくことができたり、実行時間が速いというメリットも感じることができたので、来年も引き続き使って試したい。
イロイロと、試したい・やってみたいと感じたことは見つかってきたので、来年は実際に行動に移してアウトプットするところまでする。
2年ぶりに業務でRubyを書きはじめたので、改めてruby-style-guideを読んだら知らなかったことがイロイロあったのでメモ。
2019/02/28当時の日本語版: 2bac495を読みました。
# 悪い例 class FooError < StandardError end # 悪くない例 class FooError < StandardError; end # 良い例 FooError = Class.new(StandardError)
「悪くない例」を書きがちだったので。
arr = [1, 2, 3] # 悪い例 for elem in arr do puts elem end # elemはループの外からも参照できることに注意しましょう elem # => 3 # 良い例 arr.each { |elem| puts elem } # elemはeachブロックの外からは参照できません elem # => NameError: undefined local variable or method `elem'
なんとなく、「Rubyでfor文は使わないものだ」という認識はあったし、実際for文は使ったことがなかったけど、なんで使わないのか、避けるべき理由は何なのかを意識していませんでした。
↑の例に書いてあるようにfor文内でつかった変数が、外に漏れ出てくるのはなんかのきっかけでハマりそうだし、やっぱりfor文は避けるべきなんだなと思いました。
String#% メソッドよりも sprintf や format を使いましょう。# 悪い例 '%d %d' % [20, 10] # => '20 10' # 良い例 sprintf('%d %d', 20, 10) # => '20 10' # 良い例 sprintf('%<first>d %<second>d', first: 20, second: 10) # => '20 10' format('%d %d', 20, 10) # => '20 10' # 良い例 format('%<first>d %<second>d', first: 20, second: 10) # => '20 10'
単純に String#% の存在を知らなかったです。 (推奨されてないし、あえてこれから使おうとは思わないですが)
%{name} よりも %<name>s を使いましょう。 %<name>s は値の型に関する情報をエンコードするためです。# 悪い例 format('Hello, %{name}', name: 'John') # 良い例 format('Hello, %<name>s', name: 'John')
どっちの記法も知りませんでした。
Array#* メソッドよりも Array#join を使いましょう。# 悪い例 %w[one two three] * ', ' # => 'one, two, three' # 良い例 %w[one two three].join(', ') # => 'one, two, three'
Array#* を知りませんでした。(使わないけど)
size の代わりに count を用いてはいけません。 Array 以外の Enumerable オブジェクトでは、 count を使うと要素数の計算のためにコレクション全体を走査してしまいます。# 悪い例 some_hash.count # 良い例 some_hash.size
これも知りませんでした。
標準ライブラリはこのルールに従うかもですが、ActiveRecord とか外部ライブラリだとまたルールが異なってきそうなので、結局のところdocumentなりソースなりをちゃんと読むべきな気がしました。
Struct.new の使用を考えましょう、 それは、単純なアクセサ、コンストラクタや比較演算子を定義してくれます。# 良い例 class Person attr_accessor :first_name, :last_name def initialize(first_name, last_name) @first_name = first_name @last_name = last_name end end # より良い例 Person = Struct.new(:first_name, :last_name) do end
Struct.new にブロックを渡せることを、知りませんでした。
こういうふうに使えそうですね。
Person = Struct.new(:first_name, :last_name) do def full_name "#{first_name} #{last_name}" end end p = Person.new('Hoge', 'Fuga') p.full_name #=> "Hoge Fuga"
ただ、メソッドを用意する必要があるような場合は Classを使うような気もするので、使いどころが多いかは分からないです。
fail より raise を使いましょう。# 悪い例 fail SomeException, 'message' # 良い例 raise SomeException, 'message'
「自分が例外を射出するときは fail 、 rescue などで補足した例外を再射出するときは raise」のような使い分けがあった気がしましたが、今は全部 raise で良いようでした。
# 悪い例 - Powerpack の String#strip_margin を使用しています。 code = <<-RUBY.strip_margin('|') |def test | some_method | other_method |end RUBY # こちらも悪い例 code = <<-RUBY def test some_method other_method end RUBY # 良い例 code = <<~RUBY def test some_method other_method end RUBY
<<~ で書くヒアドキュメントを知りませんでした。
# 悪い例 /(first|second)/ # 良い例 /(?:first|second)/
これも単純に知らなかったシリーズ
まだまだ知らないことが多く、たまに読み返すと学びがあって良いなと思いました(小並感)
タイトルのとおりです。
(普通にkqueueで良いんじゃないのと思いはしたものの、)Linuxのepollシステムコールを使ってソケット処理を書こうとするとどうなるのかを試してみたかったのですが、手元にあったマシンがmacOSだったので、ちょうど最近業務でも使い始めたがまだ慣れていないdocker-composeで開発環境を用意してみようとやってみました。
軽い気持ちでやり始めたものの、なんだかんだで結構ハマったのでメモを残します。
やろうと思えば、docker-composeの操作もすべてCLion上で完結できるようですが、なんかうまくいかないことがあったので、docker-compose startとかはコンソール上でやって、デバッグの部分だけCLionでやってます。
(一応公式ヘルプに使い方 Docker - ヘルプ | CLion が書いてありましたが)
また、以下のソースはリポジトリ GitHub - rkmathi/dockerfiles に置いてます。
動作環境は
な感じです。
とりあえず、CLionなのでまずは CMakeLists.txt を用意しました。
cmake_minimum_required(VERSION 3.0) set(CMAKE_VERBOSE_MAKEFILE OFF) set(out_dir ${CMAKE_BINARY_DIR}/out) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${out_dir}) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${out_dir}) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${out_dir}) project(work) enable_language(CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CXX_EXTENSIONS OFF) ADD_COMPILE_OPTIONS(-Werror -Wall -Wextra) add_executable(work main.cc)
main.cc も最初なので適当です。
#include <iostream> int main() { std::cout << "main.cc" << std::endl; return 0; }
Dockerfile は、イロイロなところを見ながら次のようにしました。
流石にプロダクション環境で使うことは全く想定していないので、rootユーザにパスワードログインしちゃいます。
FROM ubuntu:18.04 # Configure working directory ADD . /work WORKDIR /work # Install packages RUN apt-get update && \ apt-get upgrade -y && \ apt-get install -y build-essential cmake gcc g++ gdb gdbserver openssh-server rsync # Enable ssh for root user # see also: https://docs.docker.com/engine/examples/running_ssh_service/ RUN mkdir /var/run/sshd && \ echo 'root:root' | chpasswd && \ sed -i 's/#\?PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config && \ sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd ENV NOTVISIBLE "in users profile" RUN echo "export VISIBLE=now" >> /etc/profile # Expose port for ssh & gdbserver EXPOSE 22 7777 # Run sshd CMD ["/usr/sbin/sshd", "-D"]
docker-compose.yml は、こんな感じです。
本当は version: '3'の部分はマイナーバージョンまで指定したほうが良いのかもしれないですがまだ良くわかってないので一旦適当になってます。
version: '3' services: ubuntu-gdbserver: build: . security_opt: # For gdb debugging - seccomp:unconfined - apparmor:unconfined ports: - "7776:22" # For ssh - "7777:7777" # For gdbserver volumes: - .:/work
$ docker-compose build ubuntu-gdbserver
$ docker-compose start ubuntu-gdbserver
この後、 ssh root@localhost -p 7776 を試してSSHできることを確認した。 (パスワードは↑のままセットアップしたなら root )
Nameは何でも良いが、Nameの隣の入力欄は Remote Host にする。
ここもNameは何でも良い
おわり