せ肥大化した巨大なフレームワークで使い勝手悪いんだろ。実際使ってみると、思った通り肥大化した巨大なフレームワークで、ローカルPCでGrassfishを起動するのも大変な有様だった。HTMLやAjaxの面倒臭い部分を完全に隠ぺいしていて、ページの部分更新なんかがとても簡単に書けるのだけど、吐き出されたHTMLは難解で意味不明だった。componentもXML名前空間の書き方に「こういうディレクトリ構成の時はこういうネームスペースにすること」みたいな規則が覚えにくくてどうも違和感を感じる。XHTMLに独自タグを組み合わせて画面設計するという手法自体は間違ってない気がする。componentも前述のような違和感があるものの、再利用可能な画面部品を製作できるという点が優れていると思う。わからないけど、最近のWebフレームワークであればみんなできて当然な機能である気がする。Expressフレームワークに触れたとき、これは楽ち~んだな。Scoket.ioを使えばWebSocketでリアルタイムに更新するようなページを数行で実装できてしまう。サーバもクライアントもJavaScriptだし、ライブラリ/フレームワークによるサポートも強力なので、サーバ/クライアントの違いを意識することすらあまりないと言っても過言ではない。動的型付け言語というのが、メリットでありデメリットでもあると思う。動的型付け言語は、大規模なアプリケーションを作るのには不適である。開発が大規模になり、メンバが増え、影響するシステム要素、コード、モジュールが増えると動的型付け言語ですべてのプログラムを実装するのはどんどん難しくなる。それは、コンパイル時の型チェック、IDEによるコード補完などの機能を使うことが不可能だからである。いうのは動的型付け言語である限りはどうしようもない。JavaScriptに触れて日が浅かったある日、私は他人が作ったJavaScriptライブラリ中にある関数から値をもらい、データを加工して表示するコードを書いていた。やってもプログラムが動作しない。与える引数がおかしいのかと試行錯誤していたが、そしてようやく、私が要求していた関数getResponseData()は実際には存在せず、正しい関数の名前はgetReponseData()だったとわかった。「他人が作ったJavascriptライブラリ」に含まれる関数名にはスペルミスがあったのだ。これだけのことを調べるのにとても苦労した私はがっくりとうなだれた。静的型付け言語であれば、書いた瞬間にIDEが警告を出してコンパイルする以前に誤りであるとわかるケースである。少なくとも巨大なソフトウェア作成では、動的型付言語は使い物にならない。一万行程度が限界である。これらのスクリプト言語は、この程度の「さっと書いて、使った後は捨ててしまう」といった用途にのみ向いている。これを超える、複数の人間で作成するような複雑なシステムでは動的言語は明らかに不適当である。クリプトメディア技術メモ上記のようなことを書いているページがあったが、全面的に同意する。この意見はきっと多くの人にとって支持されるであろうと思うのだがどうだろうか。ちなみに、勘違いしてほしくないのは「静的型付言語は動的型付言語よりも優れている」と言いたいのではない。得意とするシーンが異なるだけである。「さっと書いて、使った後は捨ててしまう」といった用途に静的型付言語のみを適用することの困難さよりも、巨大なシステムを作るのに動的型付言語のみを使う困難さのほうが圧倒的に大きいとまでは言えると思う。以上のようなことを思いつくままにぱらぱらと書いてみた。これらを踏まえて考えると、次世代のWeb開発環境には以下のような特性を持った言語/フレームワークが存在することが望ましいと考える。・マルチパラダイム言語を利用できること・クライアントサイドでも静的型付け言語を選択できること・高度なO/Rマッパ、もしくはオブジェクト指向DBが利用できること・環境の構築とデプロイが簡単であること・コードを一切書かずに開発できる環境があること以下、一点ずつ述べる。マルチパラダイム言語を利用できること先に述べたように、システムを実装する(=現実世界の問題をうまく計算機を扱う)ためには、オブジェクト指向設計を行うことですべてが解決するわけではなく、もう少し別の要素を加える必要がある。オブジェクト指向、関数型プログラミング、静的型付けと動的型付けの選択が可能であること、などが同時に利用できる言語が望ましいと思う。4.0以降)であると思う。クライアントサイドでも静的型付け言語を選択できること先に述べたとおり、大規模なシステム開発では静的型付け言語を利用できることが望ましい。最近ではクライアントサイドのパフォーマンスの向上がめざましい。スマートフォンのCPUの進化、JavaScriptエンジンの強化などがそれにあたる。したがって、クライアントサイド、つまり、ブラウザが担当する処理もそれなりに増えてきたし、これからも増えていくことが当然予想される。その際に障壁となるのは、やはりJavaScriptしか選べない、つまり動的型付言語でしか開発できないという点ではないだろうか。jQueryを使って非同期に検索結果を取ってきて表示させる、程度であれば全く問題ないし、むしろ動的型付言語であるほうが簡潔に書けるだろう。複雑なことをやらそうとすると、静的型付言語がほしくなってくる。altjsと呼ばれる言語がいくつか提案されていて、そのなかのいくつかに静的型付言語と動的型付言語が選択できるような機能を持った言語(DartやTypeScript)がある。それはやはりそのような開発側からの要求があったからこそであろう。高度なO/Rマッパ、もしくはオブジェクト指向DBが利用できること私がソフトウェアの勉強を始めてから今に至るまで、ずっと疑問であったのがSQL文の存在である。SQL文は構造化されていない構文であり、お世辞にもわかり易いとは言えない記述方法である。複雑なクエリを書こうとするとどんどんSQL文が長くなっていく。そもそも80年代に定義されたフォーマットを、なぜ2010年代になっても後生大事に使っているのか全く理解できない。代替手段が用意されているならばまだわかるが、主要なRDBMSはまずSQL問い合わせを代替する方法がない。SQLで問い合わせをするという手続きがまず本質的でなくて本来は不要な作業であるはずだ。我々がやりたかったことは、指定した条件にマッチするタプルの集合を取ってくる操作であるが、それを実現するためにSQLという言語はあまりにも不適であるとおもう。覚えるのが大変だし、覚えた後もSQLやRDBMSのチューニングなどといってさらに知識を要求させられる。我々がやりたかったことはデータベース屋の勉強ではなくして、単にデータがほしかっただけである。プログラミング言語に加えてSQLを覚えなくてはならないのか。RDBMS自体もこれが本当に使いやすいのか疑問である。「リレーショナルモデル」を標ぼうしておきながら、その実装方法があまりにもユーザー任せでチープだと思うのは私だけだろうか。1対多リレーションを表現するためには「片方の表から片方の表の主キーを外部参照する」という方法を用いるが、1対多のリレーションを表現したいだけなのにこんなテクニックじみた操作をしなければならないこと自体がおかしいと思う。多対多のリレーションなんかもっとひどくて、わざわざ中間テーブルを一つ作成しなければならないのである。リレーショナルモデルを標ぼうするくらいなら、そんな単純作業はシステム側で自動的に処理してユーザーから隠ぺいしろよ、と思う。TABLE_B.ID」などとしょーもない、分かりきった文字列を書かなくてはならないのである。バカが外部結合と内部結合の違いも判らず、問い合わせの最中に何万というタプルが発生してしまうような爆発的なSQLを書いてパフォーマンス上の問題が発生したりするのである。いうか、そもそもこのIDというのも腹立つ表現であって、「それぞれのレコードで重複しない値をID列として用意しておく」みたいな決まりきったパターンの意味が分からない。世界中で何億回と繰り返し作られたID列を見てなぜシステム側がそれをサポートするということをしないのだろうか。私は初めてOracleを触ったとき、ID列を作るに当たりどうやって重複しない値を取ればいいんだっ、と思い、調べたところ「シーケンスを使え」などと書いてあって心底あきれた。んなもん実装する手間で、なんで自動的にIDを取って入れてあげる機能を実装できるだろっ。それ以外にも、たとえば複合主キーを定義した時はデフォルトだと索引を作ってくれなくてフルスキャンになるので複合インデックスを作らなきゃいけないとか、そういう点にもうんざりする。んなもん、複合主キーを作った段階で複合インデックスを自動で作っとけよ。それらすべてを使う側が許容し、やっとこさDBを使う段になり、プログラム中のなかのオブジェクトを永続化したいな、と思うと、「リレーショナルモデルとオブジェクトモデルの間にはインピーダンスミスマッチがあるからねー」なんつって、いちいちデータ保存するためだけにO/Rマッパとか特殊なフレームワークを導入して使い方を覚えないといかん、もしくは、お世辞にも使いやすいとは言えないデータベースドライバの使い方とお作法を覚えないといかんのである。私に言わせれば、データベース屋は実応用をわきまえず、椅子にふんぞり返って「僕らの考えた高尚なソフトは、君らにはちょっと難しいかもしれないね」と言っているに等しいと思う。memcachedやNoSQL関連の技術が登場して世の中を騒がせたことを思い出してほしい。単純で高速なキーバリューストアの仕組みなんて、もっと以前からRDBMS内にオマケで実装してあってしかるべきだと思う。DB屋はもっと謙虚な心を持つべきなんじゃないだろうか。Oracleのクライアントなんかがその性格をもっともよく表した代表例であると思う。環境変数にORACLE_HOMEを追加しなきゃ動かないとか、OSの流儀をわきまえず、WindowsであればCドライブの直下にアプリケーション本体を格納させるだとか、いたるところに勝手にログファイルを吐き出したり、実行プログラムのパスにカッコが入ると実行できなかったり、もう窓から放り投げたくなってくる。ヒートアップして長くなってしまったが、言いたいことはただ一つ。プログラム側から扱いやすいデータベースシステムがあるべき、というただ一点である。オブジェクト指向データベースであったり、問い合わせと永続化の処理を抽象化した高度な機能を持つO/Rマッパがこれに当たる。POCOは求めるものにかなり近い。以下のように直観的でわかり易いクエリを書ける。p.Salary).Max();EFで唯一残念なのがパフォーマンスの問題だ。Frameworkを使用して複雑なクエリを投げたり、リレーションがいくつか連なったデータを挿入したり更新したりするときに速度が出なくて結局ネイティブSQLを叩いたりする。複雑な処理をしているのでしょうがないとは思うが、今後の改良に期待する。理想を追い求めるのであれば、O/Rマッパーではなく、オブジェクト指向DBを採用すべきだと思う。オブジェクト指向DBはプロプラなものがほとんどだ。私が知る限り、オープンソースなものはdb4Objectsのみである。合わせ技が効率的すぎる上記にdb4ObjectsとScalaを組み合わせたサンプルコードが乗っているが、こういう風に書けるのが理想的な状態ではないだろうか。}.foreach(println);環境の構築とデプロイが簡単であること作業環境の構築にかかるコストというのは結構大きい。Windowsを使用すると、いまだにJavaとEclipseとTomcatをネットから落としてきて・・・から始まる。一人や二人で開発しているのであれば許容できるコストかもしれないが、プロジェクトが大規模になるにつれて構築コストも管理コストも大きくなってくる。Linuxを使用するとこれはずっと改善される。パッケージ管理システムで特定のコマンドをたたきさえすれば開発環境の準備は整う。これも完全な方法ではなく、パッケージで提供されるのが古いバージョンであることが多いため、最新バージョンを利用するためには自分でコードをgitやSVNで取得してコンパイルしたりしかるべきファイルをしかるべき場所に置くなどの作業をする必要がある。一般的な会社においては個人がLinuxを使用するということにハードルがある。業務上の多くの場面でMS製品、特にOffice製品が動かないと仕事にならない。すると個人に与えられるPCというのはまずwindowsになる。その上さらに2台目のPCを与えるというのはコストの面でなかなか難しい。仮想化も手軽な方法ではあるが、そもそも仮想マシンを動かすのにある程度のマシンパワーが必要になる。その様なPC(サーバー)を買い与えてくれる職場であれば、そもそも2台目のPCを買い与えているような気もする。ここに全く別の解がある。RubyのRubyGem、PythonのPypi、Node.jsのnpmなどは独自のパッケージ管理システムを備えており、依存性の解決や最新バージョンの取得も容易であるのに加え、パッケージをプロジェクトのディレクトリにインストールすることも可能であるので環境を汚さない。環境を汚さず、プロジェクトの管理ディレクトリ内ですべて完結するということはすなわちデプロイも簡単であるということにつながる。デプロイが簡単であることは必須条件ではないが、簡単であることに越したことはない。コードを一切書かずに開発できる環境があることこれまで一切触れてこなかった概念であるが、日本ではこういった要求が強くなる可能性が高いと私は考えている。日本の大規模なソフト開発会社、特にSIerはちょっと特殊である。ソフトウェアの知識がない、もしくは、80年90年台に主流だった古い知識しか持っていないという人間がプロジェクトマネジメントを行い、かつ、詳細設計のレベルにまで口を挟んでくることである。上記には、何とも非常識な企業内ルールが大企業の中でまかり通ってしまっている怖い例がたくさん列挙されているが、残念ながらプログラマだったら誰しも一度は経験するのではないだろうか。私の会社でも、「コード中の変更はコメントアウトしてリビジョン番号と変更者氏名を併記すること」「オープンソースソフトウェアを使ってはいけない(ただしLinuxはオープンソースソフトと見なさない)」などという謎ルールに遭遇したことがある。「DBが全部Varchar」はよく遭遇する。半ば当たり前ともいえる。これが「世の中にはすげー職場があるもんだな。」で済めば良いんだけど、それで済まないような気がしてならない。いうのは、ここにもう一つ問題があって、ソフト業界にいる人が皆ソフトに興味を持ち、モチベーションを高く保っているとは限らないということ。自分から新しい技術を勉強して、それをどうにか業務に生かそうとする向上心の高い人は実はあんまりいない。私の経験上で言えばまず間違いなく数%のオーダーである。モチベーションの高くないプログラマが非常識なルールで縛られる環境で働くとそれが当たり前のように身に沁みついてしまう。結果としてプログラマーは出来るプログラマーとダメなプログラマーに二分される。いまやちっちゃなベンチャーでもHadoopを使ってデータマイニングする時代である。いう世界でダメプログラマーの食い扶持というのはどんどん少なくなってくる。企業としては生産性を高めるためにダメなプログラマーを切って優秀なプログラマーを募集したいというのが当然の流れだけど、そもそも優秀なプログラマーの絶対生息数が少ないうえに「仕事ができないから」という理由で正社員の首を切ることを良しとしない社会構造になっている。したがって、どうやってそういうダメプログラマーに仕事をさせるかというと、もう、コードを打たせないということに尽きるのではなかろうか。コードを一切書かなくてもWebシステムが開発できる環境が必要になってくるのではなかろうか。・・・と、このように書くと、いかにも侮蔑的なような印象となってくるが、そうでもない。コードを書かないということはバグが入り込む余地がずっと減るという点で、ソフトウェア開発に携わるすべての人間に恩恵があるのである。優秀なプログラマであっても、単純な画面や機能で構成されるシステムの開発をするときは、コードを書かなくても済む手段を使いたいと思うだろう。そのほうが工数を削減できるから。「GUIでプログラムを作れる」、これはMicrosoftが最も得意とする分野だと思う。今でいうと、LightSwitchなんかがこれに相当すると思う。・マルチパラダイム言語を利用できること・クライアントサイドでも静的型付け言語を選択できること・高度なO/Rマッパ、もしくはオブジェクト指向DBが利用できること・環境の構築とデプロイが簡単であること・コードを一切書かずに開発できる環境があることこれらを兼ねそろえた(組み合わされた)開発環境が今後主流になってくるのでは、と思う。ちなみに、記事全体を通じて親Microsoft寄りなニュアンスになっている気がするが、別にそういう意図はない。懐かしの1FD-SambaとBusyBoxanopara作者:withpop昼はサラリーマン。頑張れば何でも出来る。...最近の人気記事2019年の振り返り「エンジニアになってリモートワーク🌟✨」みたいなやつプログラミングスクールについて思うこと【質問#168】35歳システム経験2年。