弱い技術者は実はおやじ予備軍というエントリを見て感じた事を書きます。言っても、このエントリの書いてある本筋には大賛成です。枝葉末節についてです。弱い技術者は実はおやじ予備軍より実は、チャンジャーに見えるRailsユーザもおやじ予備軍の危険性があります。「JavaからRubyへ」でこのような意見があります。Javaの世界はフレームワークが乱立していて適切な組み合わせを選ぶのが大変だからRailsで統一されているRubyがいいんだと。これには、全然賛成できません。悩みたくないからスーパーなデファクトを望むのは、危険だと思うんですよね。ライバルがいないとどうしても進歩の速度が鈍ります。Rails一党独裁よりも、いくつかのフレームワークが競い合うほうが健全なのではないかと思います。いうフレームワークが紹介されていました。こちらの記事が詳しいです。ユーザも一党独裁問題に対しては、バランスを取り始めています。ユーザにも波及してくことでしょう。系には手厳しいですね。弱い技術者は実はおやじ予備軍より典型的なおやじ予備軍は、自分で考えるよりも権威のある人にこれだって言ってもらうのを好みます。身に覚えはありませんか。これって頭の固いおやじがスーツなやつらに付け込まれているのと同じです。厨は・・・」なんて書き方をされると絶大な効果があります。ユーザの実態をよく調べてほしいところです。ソフトウェアの階層構造ソフトウェア技術者がどっかの段階で覚えなきゃいけないことを読んで思ったのは、広場っぽいカラーが出てていいなぁと思いました(笑)。私の結論は以前書いたとおり、自分の目指すところに合わせてポートフォリオを組んでくださいということですが、この考え方を使ってソフト(Kodougu)を組んだばかりなので、いまさらですが再考します。ソフトウェア技術者がどっかの段階で覚えなきゃいけないことよりソフトウェアにはメタな構造があって、さらに根源のところでは自己記述っぽい形でぐるぐる回ってるというイメージを持つ事じゃないかなーと思う。これはソフトウェアの本質そのものなので、知っておいて損は無いはず。注目してもいいと思います。シンプルで本質的です。流行るのかも考えてみるとよさそうですね。マシン語だって、高級言語からアセンブリ言語、そしてその命令がスーパーパイプラインでどのように処理されているかというような階層を知れば、意外とそういう理解を得ることも可能なんじゃないかなという気がします。それに、知れば知るほど、深く掘れば掘るほどシンプルで要素分解できるというほどわかりやすい世界でないことがわかります。神のお告げで命令の実行順を決めているなんて言われたもんです。(μOP、分岐予測あたり。氏はこの手のことくらいは熟知していると思います。確かにこの手の知識は必須じゃないのですが、その割にこの手の知識を知っている人には技術的に「骨のある人が多い」のも事実なんですよね。メタ階層的な話に戻ります。Infrastructure)をいくつか改造して実装しています。メタモデルはデータで表現されています。適切な例かわかりませんが、クラスとオブジェクトの関係が、メタメタモデルとメタモデルの間に表現されています。メタモデルのデータをもとにコードを生成して、クラスとオブジェクトの関係をメタモデルとモデルの間に構築しています。モデリング言語を設計することができるのです。この種のアプリの一般的なコード量は十万行から百万行程度になりますから、ずいぶんスリムです。この手の設計思想のメリットは、初期の開発コストはそこそこ高いですが、ソフトウェアの規模が小さいため、保守コストが小さいことでしょう。デメリットは、このメタ階層が処理できない問題にあたると、どうしようもなくなるか、途方もないコストがかかる恐れがあることでしょう。いう意味では、もっとももメタな部分の設計/実装センスが問われてしまうので、リスクを取ってでもやりたいという強いモチベーションが必要です。(ここでいうセンスは別に先天的なものを意味しているつもりはありません。音楽やスポーツに要求される”才能”とは違う気がします。)それがアーキテクチャ設計の宿命だといえばそれまでなので、エンジニアとして生き残っていきたいのなら、この種の能力は必須かもしれません。お、スラドでも話題になっているようです。スラド、割りとガチでテクニカルに議論している気がします。半年ぶりくらいの参加でした。個のセッションを行うという形式になっています。参加者は、興味のあるセッションに参加します。使えないからもっと良い仕様を考えよう)」に参加しました。詳しくない私にとっては何を聴いても勉強になります。ネストして掛けたいということでした。つけたいということでした。現在の仕様は納得感がありますが、こういう検索を楽に行う機能があったらいいというのは私も賛成です。)ストアドプロシージャで解決するという話は、もっと簡単な方がいいなぁと思いました。なんか誰かが作りそうですけど。改善案についてでした。不満点かもしれません。