IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Erlangのプロセス間ではメッセージ通信が容易に行えますが、JInterfaceライブラリを使うと、ErlangプロセスとJavaプログラムとのあいだでもメッセージ通信ができます。予備知識である分散Erlangから説明し、JInterfaceを紹介します。ちょっと長いので、前後編に分けて、今回の前編ではErlang側の話をします。 内容: Erlangを分散モードで動かそう セキュリティソフトとマジッククッキー 分散ノード達を互いに接続する リモートメッセージングを試してみよう 今回のまとめと次回の予定 後編 参考資料: http://www.erlang.org/doc/reference_manual/distributed.html Erlang Reference Manual(http://www.erlang.org/download/erl_spec47.ps.gz)11章
Javaな世界に10年以上どっぷりと浸かってきたが,Ruby on Rails(RoR)をやっていると「良く考えられているなぁ」と感心してしまう箇所が随所に見られる。とかくScaffoldやActiveRecordに関するコーディングに目が行ってしまいがちだが,僕個人的にはテストに関する環境が最も「おぉ」と感じている。 言うなれば,「JUnit + DbUnit + Cactus」な環境が標準で整備されている,ということだ。 JUnitについては,もちろんTest::Unitがそれに相当する。Test::Unit::TestCaseクラスを継承し,”test_“で始まる名前のメソッドを定義していくというのは,xUnitの流儀とほぼ一致している。JUnitで単体テストを行ったことがある開発者は,違和感なくTest::Unitでテストケースクラスを書いていけることだろう。 Web+DBアプリケ
2007年07月03日18:25 カテゴリOpen SourceArt 気前という技術 「有害な“正論”」にふさわしい一コマ。 第3回 トラブルシューターは一匹狼有害な“正論”を盲信するな:ITpro 技術者の場合,自分の腕一本で食べているのだから,自分だけが持っている知識やスキルを,簡単に他人に伝授してはいけない。職人に上下関係はない。上司も部下も全員がライバルなのだ。教育の名のもとに安易に極意を伝授してしまったら,いずれは部下に取って代わられ,泣きを見ることを覚悟しなければならない。もし、承前の引用が事実なら、オープンソースなんてありえない。少なくとも、そこで活躍している人々はいずれは他者にとって代わられ、泣きを見ているはずだが現実はどうか。 私が知っている限りにおいてであるが、優れた技術者ほど気前がいい。ものによっては特許や著作権やNDAで「すぐに公開」というわけには行かないが、それ
Copyright (C) by the contributors. Some rights reserved, license BY-SA. Sponsored by the Wiki Symposium and the Nuveon GmbH. Auf Deutsch WikiCreole 1.0 - a common wiki markup # FOR IMMEDIATE RELEASE Heilbronn, Germany, 4th July 2007 - After a year of diligent effort, a group of nearly 50 dedicated users and developers are proud to release WikiCreole 1.0. Creole is designed to be a common wiki mark
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の1つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の1つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
ネットワーク応用通信研究所 特別研究員。島根の田舎に住みながら国際的なオープンソース・ソフトウエアの開発に挑むプログラマ。家族6人で幸せな田舎暮らしを満喫している。バグと原稿の締め切りがなければもっと幸せなのに,と思いつつ,考えてみれば,それらがないならないで,別の困ったことがあるよなあと思う今日このごろ。 皆さんは「サピア・ウォーフ仮説」をご存じでしょうか。これは言語学における古典的な仮説の一つで,「人間の思考は使用する言語とそれに付随する文化に影響を受ける」というものです。もし仮に数字を3までしか持たない言語があったとすると,その言語を使用する文化に生まれ育った人間は3以上の数を認識できない,といったことです。言語学的にはこの仮説は否定されているようですが,日常生活の中では,この仮説が本当ではないかと感じる経験がたびたびあります。 例えば,私は年に数回海外に出張して講演をする機会があり
このへんを読んでいて思ったこと。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む - 大迫正治 REPEDANT BLOG [ITmedia オルタナティブ・ブログ] HOW DO YOU LIKE SILICON VALLEY? | やはり受託からイノベーションは生まれない いやはや、まったくおっしゃるとおり。 ともかく、みんな「リスク」とか「不確実性」とか、そういう浄化されたビジネス用語をつかって説明しようとするからリアリティーがないんだ。 いまの日本のITイノベーションに足りないのは、転んで生傷をつくりまくる失敗経験だよ。 「10のチャレンジのうち9の失敗をよしとする」ということは、それ自体、相当の覚悟と思考体系の適応力が求められる難しいテーマ。ハンパに受託をやりながら、そういうマインドを維持できると思ってる人がいるとは、いかにもおめでたい。 だいたい、国際交流試合や全
RubyKaigiでも発表させてもらったのですが、Rubricks0.6リリースに向けてパフォーマンスをがんばって上げております。 以下、つらつらと。 render_componentが遅い render_componentはrequest.dupしてコントローラに投げなおすようなつくりになってて無駄が多い。 シンプルなsimple_render_componentを自作して解決。 →コントローラの処理時間がに5倍近く高速化 IEはDOM操作を行うと重い 一般的にDOM操作よりもinnerHTMLの方が速い。 SpinelzをDOM操作ではなく極力innerHTMLで操作するように改良 →IEで約3倍の高速化 毎回JSライブラリを読み直しは重い 数百kbyteのJSライブラリを読み直すのに時間がかかっている。 ほとんどのJSをログイン時に先読みし、画面更新を全てAjaxベースで実施するよう
tugboat.GTD Adobe AIR版の開発スタート tugboat.GTD Adobe AIR版の開発に私も参加します。AIRのクライアントとtugboat.GTDのサービスとは、RESTful WebServiceでつなぐことになります。このRESTful WebServiceの機能は、汎用化されてSeasar2.5にマージされることになると思います。 RESTって何って方は、こちらを参考にしてください。 http://yohei-y.blogspot.com/2005/04/rest_23.html RESTって一口に言っても、ユーザインターフェースとサービスの二つの部分に分かれるのではないかと思います。サービスというのは、WebServiceの意味で使っています。もちろん、SOAPではなく。 せっかくなので、S2RESTの仕様を考えて見ます。書くのは次のエントリで。 S2RE
Windowsで言えばInstantRails、Mac OSXで言えばLocomotiveというソフトウェアがある。どちらも、Rails開発を手軽に行うためのソフトウェアだ。 ことLinuxについて言えば、CUIでApacheやらMySQLやらを順番にセットアップする。Linuxでのセットアップはコンパイルから何から面倒なもの、というのが染み付いている。だが、それで良いのだろうか。 今回紹介するオープンソース・ソフトウェアはLinRails、LinuxにおけるRails環境一括インストーラーだ。 LinRailsはRuby-1.8.6、Rubygems-0.9.4、Rails 1.2.3、Mongrel 1.0.1、MySQL-5.0.41、ncurses-5.6、OpenSSL-0.9.8e、zlib-1.2.3が一括でインストールできるようになっている。 このラインナップを見て分かる通
Ajaxの隆盛もあって、JavaScriptが見直されている。そして、クライアントサイドのみならず、サーバサイドでもJavaScriptを使おうと言う動きすらある。 Javaが好きでサーバサイドJavaScriptに興味がある方はこちらを試してみてはどうだろう。 今回紹介するオープンソース・ソフトウェアはHelma、サーバサイドJavaScriptフレームワークだ。 Helmaは一からサーバサイドJavaScriptを作り上げている訳ではない。JavaによるJavaScript実装であるRhinoと、HTTPサーバであるJettyを組み合わせている。 JavaScriptながら、データベースへ接続する事ができる(ドライバはJavaのものを利用)。サンプルアプリケーションとしてデバッガーや、Shellライクに動作するものが付属する。 同じJavaScriptとは言っても、クライアントサイドと
今回から、Seleniumを使ってどのようにテストを行っていくか実践していきます。サンプルアプリケーションを用意し、それに対するテストをSeleniumで実施します。まずは事前準備とSeleniumの基礎知識についての説明です。これより本連載では、下記ソフトウェアを使用しているという前提で進めていきます。 カテゴリ ソフトウェア バージョン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く