「スクリプティング」を含む日記 RSS

はてなキーワード: スクリプティングとは

2023-02-18

anond:20230218132709

それ別にコマンドライン関係ないでしょ。

どちらかと言えばコマンドではなくスクリプティング技術だし。

(実際ある程度込み入った内容になるとスクリプト言語で書くほうが効率いい)

あとバッチファイルってことはWindows上で動かしてるんだろうから尚更コマンド無関係

2022-12-13

Unityビジュアルスクリプティング無料アセットだけで作った有料ゲームが初めてsteamで売れた。無料版遊んでくれた人が買ってくれた。嬉しい。某コミュニティ質問するたびに「ビジュアルスクリプティングじゃまともなゲームは出来ないかゲーム作りはコーディング勉強してから出直してこい」と繰り返し言ってきた奴よ。俺のコーディング無しゲームお金を払ってくれた人たちがいたぞ!

2020-03-16

anond:20200315225230






















ほぼ毎日使っている一部を挙げたけれども、出勤準備の時間が近付いてきたのでココまで。
気分が向けば追記するかも知れない。

2019-01-16

anond:20190116205839

これからビジュアルスクリプティングが主流になる業界とかも増えていって、「コードを書くだけのプログラマー」はどんどん減っていく気がしている。

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2011-10-18

Steve Yegge の Googleプラットフォームに関するぶっちゃけ話を訳した(後編)

中編からの続き

そんでもって、 Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、 Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォーム提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。 msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千もの API コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。

Amazon自分ものにしている。 AmazonAWSaws.amazon.com )は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。

Apple も、明確に、自分ものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ?。彼らは実に見事なドッグフードを作る。彼らの APIコールは Microsoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。

Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする(って言うのかどうか知らないけど)のも嫌いだ。そもそもGoogle+ぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Google成功して欲しいと思ったらね。で、僕は成功して欲しい!。まあ要は Facebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。(訳注この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え!。"アドバイス" thx !)

MicrosoftAmazon 、それに Facebook (たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…)の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね?大きな差だろう?。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。

どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。

僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 Maps API は一体どこにあるっていうんだ?。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにある API は全くけちな代物だ。まさに本当の意味ドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部 API に比べれば、まるで不格好な別物だよ。

Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティプラットフォーム部隊が、無敵で予算も自信もたっぷりプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。

ゼロから構築したプログラマブルプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps や Docs なんかが思い浮かぶ。 Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大な Microsoft Office プログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、 T-Rex の対決みたいなものさ。 Docs チームだって、このスクリプティング機能が無ければ Office太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Apps スクリプトが Spreadsheet だけで動作して、 API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。

皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの(つまり、 wall やら friends やらなんやらというデフォルト機能)が、 Facebook プラットフォームキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う

みんなは、外の人たちが Google傲慢だって言い続けているの、知っているよね?。僕は Googler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた(遠い記憶をさかのぼってよ)、 Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから傲慢傲慢だと言っているんだろう。

でも、もし僕らが、僕らは全ての人に対して完璧プロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧プロダクトなんて、無いんだ。

デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要ポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこい Chrome チームってのははっきりと傲慢から、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。

これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。

Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォーム必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…?。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。

Microsoftプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。

でも、 Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。 Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。

たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったら Google を倒せる?。 Google に足りないものはなんだ?」

僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざまし文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分ものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか

プラットフォームの黄金律「自分ドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」(訳注"アドバイス" thx !)。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。 MS Officeプラットフォーム化した人たちに尋ねてみればいい。あるいは Amazonプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドア秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。

僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。

この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに6年かかっていると言える。僕が紳士的ではなくて申し訳ないと思う。プロダクトやチーム、個人を僕が誤解していたら申し訳ないと思う。もし僕らがたくさんのプラットフォームを実は作っていて、僕や、僕が話した人たちみんなが偶然知らないだけだったとしたら、申し訳ないと思う。

でも、僕らは今すぐに始めないとならない。

2008-02-29

http://anond.hatelabo.jp/20080229121938

横はいり。

クライアントマシンwin人間からすると、

なんでEmacsがそこまであれなのかわからんのだけど・・・

WinScpみたいんでこっちで編集したんじゃダメなの?

Emacs使うひとはもっと編集スパンが細かいのかな??

SSHごしとかでlinuxアクセスしてもviでまにあうぐらいの設定編集レベルしかしないから、

Emacsの必要性があまりわからん。

SSH越しとかでバリバリスクリプティングするの??

それとも編集専用マシンがそもそもLinuxなの?

後者であれば納得なのだけど、前者だとするとちょっと理由がわからないです><

2007-09-29

[]Ruby on Railsにおさわりしたので評価してみる。

勉強からはじめ10日間ぐらいでひとつのRubyアプリケーションをつくった。

キャッチコピー道場 CatchCopyHacks

http://aor2007-3.drecom.jp:18012/

ドリコムの運営さんにDBキャラをLatin1からutf8に変えてもらってようやく日本語が動くようになったので一応公開。

これをつくるまでの詳細な過程は[Ruby]のタグをひいてみてほしい。

http://anond.hatelabo.jp/c/Ruby

正直WEBアプリとして完成しているとは言いがたいが…

RonRに触ってみて思ったことをいくつか書いておきます。

Railsの特性

0から作る分には正直それほど生産性は高くないと思う。

ただ、既存プロジェクトの焼き直しやプラグイン活用できるようなケースに限って言えばほぼ設定変更だけで対応できる。10分でつくる***みたいなものは既存のものをナゾルというバッチスクリプティングというような作業。(プログラミングという所作からは遠いかもしれない。)

Ruby on RailsDRY:繰り返さないことを標榜しているがあれはウソだと思う。

プラグインなどをオーバーライドさせて再帰的に繰り返していくことこそがこの言語の特性だとおもう。

過去プロジェクトなどの繰り返し。これこそがRailsの本領ではないのだろうか。

言語というよりはこれはまるでWordpressだ。

プラグイン自作してストックできる体制ができあがったら物凄く生産性をあげることができる。

Railsの難点

敷いたレールのうえを突っ走らせるのはものすごく簡単だ。

だが、レールに分岐をつくったり、既存のレールから少しでも外れたことをやろうとすると他の言語よりも苦労をする。

とくにO/Rマッピングは設計から頭を悩ませることになる。

逆にO/Rで何ができるんだという発想から辿らないと設計できなかった。

もし既存のシステムからのリプレイスであったら困難を極めるだろう。

システム会社がRonRを生産性が高いだの、国産だのとの流行で取り入れて、

リプレース案件を請け負ってデスマーチに陥る姿がありありと目にうかんだ。

find_by_sqlを連発せざるをえないシステム。少し想像するだけで怖い。

RailsMVCは賞賛にあたいすべきものであるが、もしRonRをチームで取り組んだときには担当分担は非常に頭を悩ませることになると思う。Vの部分は分業容易だが、特にCの部分は設計が担当できるレベルPGが必要になる。

また事前の仕様決定が相当重要になるだろう。

コンシューマ向けサービスのように自らの要件と仕様が近いようであれば回避できるかもしれないが、

客先都合で変更が入った場合RonRのその特性が仇になる可能性が高い。

チームに目的地まできちんとレールをひける人が居ないと間違いなく地獄に落ちる。

その目的地に案内することを客先にきちんとコミットできる人が居ないと間違いなく地獄に落ちる。

Railsの将来性

まだ1、2年ぐらいはないなという思いを強くした。

コンシューマー向けのサービスをRonRで展開することはできても、人月仕事をRonRでやるにはまだ無謀すぎる。

現状では、やれたとしても単票、マスメン系が限界だ。10人を超える案件にはまだ向かないとおもう。

言語としての難易度は他とそれほどかわらないが、方言というレベルでは収まらないので、

3、4年生レベルのイキのよさそうなところに勉強会にでてもらうとかアンテナ立てておいてもらうより無いのではないか。お金になるのはもういっぽ先だ。

Rubyは行政の方がご執心なので仕事はある程度見込めるが、果たしてそれまでに使いものになるRuby使いが量産されるか…

 
ログイン ユーザー登録
ようこそ ゲスト さん