Ruby1 - プログラミング言語Rubyの概要
概要
- Rubyはオブジェクト指向のスクリプト言語
- 開発者は日本人の「まつもとゆきひろ」さん
- 有名なWebアプリケーションフレームワークとして、Ruby on Railsがある
- プログラマが楽しくプログラミングをできるようにという設計思想で作られている言語である
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
関連記事
アプリケーションの寿命について
当記事は こちら に転載しました。
コードを自動生成するか否か
メッセージIDのenumなどを作る際に、定義書から自動生成する場合がある。
こういったボイラープレートは自動生成で逃げるのが良いかもしれないのだが、その自動生成ツールなり、スクリプトなりが後からきちんと運用されなくなったりする場合を考えると、なかなか難しいところである。
また、例えば、定義一覧のような設計書から定義内容を自動生成するような場合、たとえば区分が一つ増えたときに、どういったプログラムコードに変換するのかといったようは、単純に設計書の修正だけでなく、最終的に生成されるプログラムコードのことも考えて、拡張してゆかなければならなくなる。
こういったことが、前述のように、運用されなくなる要因の一つでもあるように思う。
やはり、プログラムコードというのは職人の仕上げる飴細工のように繊細なものなのだと思う。
引き継ぎ者不在のシステム
私が前に携わっていたシステムで、専任して保守してい方が、会社を退職されるらしい。
体力のある会社であれが後任をすぐに立てられるんだろうけど、そこそこの規模の会社さんだとそうも行かないらしい。
私にも、元開発者だったということで、またお仕事の話がくるかも知れない。
偏りはあるかもしれないが、システム開発会社のような会社の週報が、紙ベースであったりと、色々と世の中まだまだだなぁと思うところはありますが、この引き継ぎ者不在のシステムの未来はどうなるんだろうか。
No Project Small Library Principle
ある日、業務コードを眺めてていたら、ふとXMLをダウンロードさせるWEBプログラムのソースに出くわした。
それだけだったら何も目新しいことはないだろう、十分に使い古されたフォーマットであるし、何も目にとまることなど無いはずであった。しかし、何かがおかしい。
そのコードは、JDK標準クラスのみで書かれていたのだ。このライブラリやらフレームワークやらが溢れた時代に、まさか素のJDKだけ書かれた大規模なプログラムに出会うのは、私としてはとても珍しいことであった。
DOMを駆使して、最後はインデント処理まで施して出力しているのである。ライブラリが無かった時代ならそうであろうが、よりによって今どきそれ?と最初は思ったのであった。
しかも今回のプロジェクトではJava8を使っているし、古い環境だったというわけではない。開発者も昔からの古参Javaプログラマというわけではなく、それなりに若い世代である。
さて、彼らはどうしてこんなコードを書いたのか。
そのあと私は、だいぶ迷った挙句、そのソースの多様性を認めることにした。それはまさに、以下の原則に辿り着いたからである。
プロジェクト向けの小さなライブラリを書いてはいけない。 いつの日か、そのライブラリは運用チームでは 手に負えなくなり、メンテナンスされなくなる。 最後には放棄されるだろう。
どういうことか。
ここで言っているライブラリとは、世に出回っている汎用的なもの*1ではなく、各プロジェクト向けに存在する、そのプロジェクト向けの小さなライブラリのことである。
自作したそのプロジェクト独自のライブラリを極力使わないことで、より一般的な記述のみへと落とし込むことができる。プログラマの中には、こういった小さなプロジェクトライブラリを作ることを生業としている種の人物もいるであろうが、残念ながら長い目で見るとプロジェクトのためになっているとは言えない。
そのプロジェクト固有のビジネスロジックを含んだライブラリは、いつか管理しきれなくなるものだ。いつまでも書いた人物がプロジェクトに残ることは稀である。ビジネスロジックはライブラリに埋め込むのではなく、機能ごとの処理層に埋め込むべきである。
小さなライブラリを書く代わりに、我々に必要なのはマニュアルであり、チュートリアルであり、QAだ。Javaの基礎知識を持ったメンバーが新たにプロジェクトに参画した際、素早くコードを追加し、メンテナンスし、テストできるようにさせるには、これらのドキュメントが必要だ。
この原則に従う限りに於いては、長期的にメンテナンスしやすいコードを書くことが期待できるのではないだろうか。
最後に、一応書いておくが、全てのライブラリを書いたり、利用したりするなと言っているわけでは無い。十分に知られた*2ライブラリであれば、緻密に汎用化されているし、またドキュメントも充実しているだろう。その最たる例はJDKではないだろうか。
技術は繋がっている
どうも、ふもです。
最近は新しいプロジェクトのアプリケーションアーキテクトなどという大層な役割を与えてもらい、日々奮闘している毎日です。
長らく新しめな技術から遠ざかっていたため、Java8やらSpring4などの環境がやっと使えるようになりました。
日々、調べながら、フレームワークとして採用する部品を作り続けている毎日ですが、そんな中で一つ思ったことがあります。それがタイトルでも書いた、技術は繋がっているんだなぁということです。
たとえばSpringとかなどですと、最近はアノテーションを多用するスタイルになっていたり、JavaConfigで定義がかけたりと、だいぶ進化しているようです。
しかし、いきなりこの姿になったわけでは勿論ないわけで、色々な機能を調べてると、私の空白の数年間の間に、様々なことがあったのだなぁと追体験ができてたのしくなります。
様々な技術が出ては消えて行くなかで、それを常に楽しめる姿勢で、今後も技術者を続けていこうと思いました。
コードはそのプロジェクトメンバー達のスキル上限までにしかならない
コードの完結さやスマートさは、結局はプロジェクトメンバーに左右されるという意味。
より洗練されたコードを目指すのであれば、プロジェクトに携わるメンバーへの教育や布教活動が欠かせない。
コードのスマートさは、将来に渡って長い間コードを維持し続ける際に必須の条権となってくるため、妥協してはならない項目の一つである。