No Programming, No Life

プログラミング関連の話題や雑記

Ruby2 - Rubyの基礎文法

概要

ここではRubyの基礎文法についてまとめていきたいと思います。

文字列

文字列はシングルクォーテーション ' もしくはダブルクォーテーション " で囲む。

puts 'Hello!'
puts "Hello!"

文字列の連結

文字列を連結するには + を使う。

puts 'あいう' + 'えお' # => あいうえお

コメント

コメントにはシャープ # を使う。その行#の後ろ部分がコメントになる。 行の先頭に # を置けば、まるまるコメント行になる。

# ここはコメント
puts 'Hello!' # これもコメント

数値と様々な計算

Rubyで数値を扱うには、単に数値を書くだけ。 足し算は +、引き算は -、掛け算は *、割り算は /、余りは % が使える。

puts 2 + 3 # => 5
puts 7 - 4 # => 3
puts 13 * 9 # => 117
puts 32 / 8 # => 4
puts 18 % 5 # => 3

条件分岐

条件分岐は別記事にしました。

Ruby3 - Rubyの基礎文法 - 条件分岐 - No Programming, No Life

関連記事

Rubyのチュートリアルっぽい記事の一覧 - No Programming, No Life

Ruby1 - プログラミング言語Rubyの概要

概要

REPL

irb コマンドにて。

実行例

$ irb
irb(main):001:0> a = 10
=> 10
irb(main):002:0> b = 20
=> 20
irb(main):003:0> c = a + b
=> 30
irb(main):004:0> p c
30
=> 30
irb(main):005:0> 

ドキュメント

ri コマンドにて。

例)

ri Array

参考サイト

https://dotinstall.com/lessons/basic_ruby_v3/37101

関連記事

Rubyのチュートリアルっぽい記事の一覧 - No Programming, No Life

コードを自動生成するか否か

メッセージIDのenumなどを作る際に、定義書から自動生成する場合がある。

こういったボイラープレートは自動生成で逃げるのが良いかもしれないのだが、その自動生成ツールなり、スクリプトなりが後からきちんと運用されなくなったりする場合を考えると、なかなか難しいところである。

また、例えば、定義一覧のような設計書から定義内容を自動生成するような場合、たとえば区分が一つ増えたときに、どういったプログラムコードに変換するのかといったようは、単純に設計書の修正だけでなく、最終的に生成されるプログラムコードのことも考えて、拡張してゆかなければならなくなる。
こういったことが、前述のように、運用されなくなる要因の一つでもあるように思う。

やはり、プログラムコードというのは職人の仕上げる飴細工のように繊細なものなのだと思う。

引き継ぎ者不在のシステム

私が前に携わっていたシステムで、専任して保守してい方が、会社を退職されるらしい。

体力のある会社であれが後任をすぐに立てられるんだろうけど、そこそこの規模の会社さんだとそうも行かないらしい。
私にも、元開発者だったということで、またお仕事の話がくるかも知れない。

偏りはあるかもしれないが、システム開発会社のような会社の週報が、紙ベースであったりと、色々と世の中まだまだだなぁと思うところはありますが、この引き継ぎ者不在のシステムの未来はどうなるんだろうか。

No Project Small Library Principle

ある日、業務コードを眺めてていたら、ふとXMLをダウンロードさせるWEBプログラムのソースに出くわした。
それだけだったら何も目新しいことはないだろう、十分に使い古されたフォーマットであるし、何も目にとまることなど無いはずであった。しかし、何かがおかしい。

そのコードは、JDK標準クラスのみで書かれていたのだ。このライブラリやらフレームワークやらが溢れた時代に、まさか素のJDKだけ書かれた大規模なプログラムに出会うのは、私としてはとても珍しいことであった。
DOMを駆使して、最後はインデント処理まで施して出力しているのである。ライブラリが無かった時代ならそうであろうが、よりによって今どきそれ?と最初は思ったのであった。
しかも今回のプロジェクトではJava8を使っているし、古い環境だったというわけではない。開発者も昔からの古参Javaプログラマというわけではなく、それなりに若い世代である。
さて、彼らはどうしてこんなコードを書いたのか。

そのあと私は、だいぶ迷った挙句、そのソースの多様性を認めることにした。それはまさに、以下の原則に辿り着いたからである。

プロジェクト向けの小さなライブラリを書いてはいけない。
いつの日か、そのライブラリは運用チームでは
手に負えなくなり、メンテナンスされなくなる。
最後には放棄されるだろう。

どういうことか。
ここで言っているライブラリとは、世に出回っている汎用的なもの*1ではなく、各プロジェクト向けに存在する、そのプロジェクト向けの小さなライブラリのことである。

自作したそのプロジェクト独自のライブラリを極力使わないことで、より一般的な記述のみへと落とし込むことができる。プログラマの中には、こういった小さなプロジェクトライブラリを作ることを生業としている種の人物もいるであろうが、残念ながら長い目で見るとプロジェクトのためになっているとは言えない。
そのプロジェクト固有のビジネスロジックを含んだライブラリは、いつか管理しきれなくなるものだ。いつまでも書いた人物がプロジェクトに残ることは稀である。ビジネスロジックはライブラリに埋め込むのではなく、機能ごとの処理層に埋め込むべきである。

小さなライブラリを書く代わりに、我々に必要なのはマニュアルであり、チュートリアルであり、QAだ。Javaの基礎知識を持ったメンバーが新たにプロジェクトに参画した際、素早くコードを追加し、メンテナンスし、テストできるようにさせるには、これらのドキュメントが必要だ。

この原則に従う限りに於いては、長期的にメンテナンスしやすいコードを書くことが期待できるのではないだろうか。

最後に、一応書いておくが、全てのライブラリを書いたり、利用したりするなと言っているわけでは無い。十分に知られた*2ライブラリであれば、緻密に汎用化されているし、またドキュメントも充実しているだろう。その最たる例はJDKではないだろうか。

*1:Javaならjarにて提供されるもの

*2:この業界では、よく「枯れた」と表現する

技術は繋がっている

どうも、ふもです。

最近は新しいプロジェクトのアプリケーションアーキテクトなどという大層な役割を与えてもらい、日々奮闘している毎日です。

長らく新しめな技術から遠ざかっていたため、Java8やらSpring4などの環境がやっと使えるようになりました。
日々、調べながら、フレームワークとして採用する部品を作り続けている毎日ですが、そんな中で一つ思ったことがあります。それがタイトルでも書いた、技術は繋がっているんだなぁということです。

たとえばSpringとかなどですと、最近はアノテーションを多用するスタイルになっていたり、JavaConfigで定義がかけたりと、だいぶ進化しているようです。
しかし、いきなりこの姿になったわけでは勿論ないわけで、色々な機能を調べてると、私の空白の数年間の間に、様々なことがあったのだなぁと追体験ができてたのしくなります。

様々な技術が出ては消えて行くなかで、それを常に楽しめる姿勢で、今後も技術者を続けていこうと思いました。