John Lam on Software: IronRuby at OSCON
JohnはOSCONで3つの収穫があったことを書いていて、一つはIronRubyのBinary Releaseが果たせたこと、二つ目はironruby-contributeとしてGitHubを使ったオープンソース開発のプロジェクトが立ち上がったこと。三つ目がRubySpecがプロジェクトとして立ち上がったことで、待ち望んだRuby言語の言語スペックが入手できそうなことだそうです。
バイナリ入手：RubyForge: IronRuby: Project Info
（とりあえず起動はした！）
どうも、MSの場合、3文字言葉の氾濫が、それまでとちょっと違ったことを始める合図のようだ。というか、現在のC#って、C++より遥かに複雑なんじゃないかとか。（ジェネリクス使ったほとんど実装の多重継承のような技もあるようだし）
Boostはって言うのは置いておいて、言語仕様で比べれば仕様書のページ数はともかく包含するパラダイムを考えると複雑になっているし、次の4.0では確実により複雑になると思われます。
複雑になっていっているのは、解っているひとにはラピッドにものが作れるようにと言う方向性とかRuby良いなぁ入れちゃえみたいな(商売的なものを含めて)ノリだと思うのですが、現状C#3.0で追加されたフィーチャーがどの程度実際現場で機能しているかを考えると結構複雑です。まぁついていけてない人多数なのは現状確かです。
マルチパラダイム開発は現状必要だと思いますが、それに対応できる人材が特にこの国だと少ないのかもしれませんね。またもう一つ問題だと思うのは、そうしたときのオルタナティブとしてVBがあったはずなのに、VBがオルタナティブとしてあまりうまく機能していないんじゃないかと思われるところです。
まぁ、なんかこれから開発の主力はmini CLRでDLRでIron*で開発！とかになって、めでたくC#は現状の(V)C++ポジションになるかもしれませんけどね。
まぁ取っつきにくい言語にはなってきたと思います。
オートメーション業界も例外じゃないんだからね。ってことで。
Digital Bond » DNS Vulnerability and Process Control
ネットにつないでないから大丈夫ではありません。このような脆弱性は内部犯行でも多用されます。できないところもあると思いますが、できるだけ適応しましょう。
マイクロソフト セキュリティ情報 MS08-037 - 重要 : DNS の脆弱性により、なりすましが行われる (953230)
やっとつながった。。
もうすでにプログラマです。。
主張が足りませんか。
Lips仏のありがたいお言葉をいただく。
どうせC# 4.0はよりLisp臭が強くなるのは目に見えているので、いっそLispに転んでしまった方が幸せなのかもしれません。
MySQLを発祥とするマイクロカーネルなRDBMが出たんだそうです。
mixi Engineers’ Blog » Introducing the Drizzle Project
なんか記事読んでの感想は、このRDBMSみて興奮したり、感動したりする人たちってSQL ServerやOracleを使っている人たち（僕らたち）とはまた別の文化圏の属してる人たちなんだなぁってことです。ものすごく何となくですけど。楽しそうだけど、僕はそこまでがんばれませんｗ
今PCの世界で最新のエンタープライズでどうこうという話を古株のメインフレームエンジニアに聞いてみるときっとこう帰ってきます。
ここ10年ぐらいPCの世界でハイエンドなソリューションとして語られてきた、クラスタリング、仮想化といったテクノロジの源はメインフレームにあり、もう30年前から今PCで最新ソリューションと思われていることと同じようなことが、メインフレームでは実現されていました。（思えばクラスタリングはDECのミニコンがIBMメインフレームのマルチシステムに勝つための渾身の1作だったわけです）
メインフレームというか、IBMのZサーバーシリーズの仮想化技術と今のPCベースの仮想技術の対比ができていておもしろい記事です。今の仮想技術をみるときに何がよく何が悪いかという判断基準の一つにできると思います。
最近あまり間隔をあけずにGoogleが自社の成果物をオープンソースとして公開しているが、見ていると一定の戦略があるように思う。
その戦略とは、Google App Engine(GAE)で、そのユーザーが自分たちのアプリケーションを構築する当たって必要で、Googleにとって都合の良いものはオープンソースとして公開するということだ。
Goggleが何もオープンソースフレンドリな会社なのではなくて、GAEにとってフロントエンドな部分に関しては、それらをオープンソース化し、ユーザーにとって使いやすくすることで、それを使ってくれ、強いては自分たちの負荷が軽くなることを狙っているように思う。Protcol Bufferにしても、彼らのバックエンドのストレージエンジンとの親和性を考えれば、GAEにユーザーがXMLやフラットファイルで自分たちが作るアプリケーションのデータの保存をされるよりはProtocol Bufferで保存してくれた方がストレージをスケールできるので、GAEの運用管理は楽になる。pymoxにしても、テスト環境を提供することでユーザーが事前テストをしっかりやってバグをつぶしてくれれば、システムに余計な負荷もかからず運用側はかなり楽になる。
また、このようにGoogleエコシステムのエッジの部分はオープンソース化されても、Googleにとっての競争力の源泉であるコアの部分、カスタマイズされた分散処理環境だとか、分散ストレージエンジンそのものだとか、広告用のエンジンといったものは、当然のように公開されない。そう言う点でGoogleは慎重にオープンソースコミュニティに悪い印象を与えないようにしながら、大事なものは隠し持っている。
まぁ。ボランティアではないので、公開する方にもそれなりの思惑はあるよってこと。IBMのLinuxやEclipseへの支援やコミットにしても、当然思惑はあるわけで、Googleだけがなにもオープンソースやそのコミュニティに対して特別な態度をとっている訳じゃない。
ただ一技術者としてある日突然はしごを外されないためには、それがなぜ公開されたのかちょっと考えてみた方が良いよと言うこと。特にこういう大きな企業がそれを始めた場合にはね。
404 Blog Not Found:フローチャートがダメな3つの理由
文系頭で非マッチョな僕にはフローチャートもUMLも必要です。ごめんなさい。ごめんなさい。
オートメーションの世界では文字言語ではなくヴィジュアル言語が勝ち組です。ごめんなさい。ごめんなさい。
_ ∩
( ﾟ∀ﾟ)彡 IDL！IDL！
⊂彡
だよね？
【ハウツー】XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」 (1) 構造化データをバイト列に変換するための新技術 | エンタープライズ | マイコミジャーナル
＃どうせ古い人間でございます。
..一般的なCコンパイラという一般的な言葉が一般的にさし示すものは一般的に考えるに、一般的にみられるWindows（一般的に32ビットまたは一般的に64ビットのどちらのバージョンであるかを一般的に問わず）を一般的に搭載した..
「一般的」は常にはカギ括弧付きで、暗黙的にそれを口にした瞬間に口にしたものは暗黙的に対象のフィルタリングを行っている。そして私とあなたの「一般」は同じ集合かという駆け引きが始まる。
それはさておき、ここでは一般的の定義ではなく、リンク先の文章は筒井康隆の乱調文学大事典の一説みたいで愉快だったということが書きたかったのだ。
最近のコメント
工藤＠静岡 on Windowsがそんなにタコなら本気で使われないってば: 工業用などの組込み目
工藤＠静岡 on Xbox 360 新機能詳細：HDDインストール、LIVE Party、新ダッシュボード - Engadget Japanese: あとは40型以上の1
工藤＠静岡 on NHK、はじまったな: 海外に！？ この前の
工藤＠静岡 on 日本の新聞とは自ら第四の権力と言ってしまう集団だ。: 紙媒体なんて、とっく
管理人 on NHK、はじまったな: 僕は今回のことに関し
hori on NHK、はじまったな: なんで海外ではタダで
工藤＠静岡 on Silverlight SuberanighTalk: 強引に都内出張を設定
管理人 on イー・モバイル D03HW を買う: やっぱこんなもんみた
工藤＠静岡 on イー・モバイル D03HW を買う: あの辺りで、その数値