2011年6月5日日曜日

JSlider でクリックした位置にノブを動かせるようにする

1. JSlider でクリックした位置にノブを動かす場合の課題

Java Swing で JSlider(スライドバーみたいなもの)を使う場合、そのままではバーの特定場所をクリックしても、近くのメモリ上にスライダーは動きますがメモリの間の細かいところには動きません
このスライダーを使うのが数回程度なら、別にクリックで細かく動かせるようにしなくてもいいのではと思いますが、これで操作を行うような場面が何回もある場合、クリックで細かい指定ができないと不便なのですよね。

「JSlider」、「クリック」等、日本語で検索すると、以下の比較的有名なサイトの解決方法が上位に出てきて、このクリック時の問題をうまく解決することができます(非常に参考になります)。
 JSliderでクリックした位置にノブをスライド
  http://terai.xrea.jp/Swing/JumpToClickedPositionSlider.html

ですが、コードを見るとわかるように、「new MetalSliderUI()」となっており、Nimbus 等の Metal でない look and feel を使っている場合、うまく動きません。個人的に Nimbus を使いたい場面もあり、問題でした。


2. 簡単に出来る解決方法(挙動がヘンだけど…)

どういう look and feel でもこの問題を解決できる方法はないかと探してみましたが、日本語で検索した場合、上位に以下のような示唆しか見つかりませんでした。

 スライダーの値をマウスのクリックで設定する方法
  http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=17944&forum=12
  「現時点では簡単な実現方法がないため、
   とりあえずクリックされた座標から値を計算するようにしたいと思います。 」

これをなげやりに実装すると、以下のようになります。固定値の 8 などは location を計算するための補正です(もっと丁寧な方法があると思います)。

 slider.addMouseListener(new MouseListener(){

  @Override
  public void mouseClicked(MouseEvent mouseEvent) {
   Point point = slider.getMousePosition(); 

   int width = slider.getBounds().width - 8*2; 
   int location = (int)(((double)point.x-8.0)/(double)width*slider.getMaximum()); 

   slider.getModel().setValue(location);
  }

  @Override 
  public void mouseEntered(MouseEvent arg0) {  } 

  @Override 
  public void mouseExited(MouseEvent arg0) {  } 

  @Override 
  public void mousePressed(MouseEvent arg0) {  } 

  @Override 
  public void mouseReleased(MouseEvent arg0) {  }
 });

しかし、やってみると分かりますが、この実装にするとクリック後の動きがかなりでこぼこします(1 どキリのいいメモリに動いてから、上記の location の位置に動くため)。


3. 実用的な解決方法

英語で調べてみると、Metal UI でない場合のもう少しスマートな解決方法がありました。

 JSlider question: Position after leftclick
  http://stackoverflow.com/questions/518471/jslider-question-position-after-leftclick

上のほうのコードの方法は、1 で紹介したのと類似で Metal 用ですが、下の「This question is kind of old, but I just ran across this problem myself. This is my solution:」以下のコードは、それ以外の look and feel でも動きます。

引用:

 JSlider slider = new JSlider(/* your options here if desired */) {
 {
  MouseListener[] listeners = getMouseListeners();

  for (MouseListener l : listeners)
   removeMouseListener(l); // remove UI-installed TrackListener …(i)

  final BasicSliderUI ui = (BasicSliderUI) getUI(); // …(ii)
  BasicSliderUI.TrackListener tl = ui.new TrackListener() {

   // this is where we jump to absolute value of click
   @Override
   public void mouseClicked(MouseEvent e) {
    Point p = e.getPoint();
    int value = ui.valueForXPosition(p.x);

    setValue(value);
   }

   // disable check that will invoke scrollDueToClickInTrack
   @Override
   public boolean shouldScroll(int dir) {
    return false;
   }
  };
  addMouseListener(tl);
 }
 };

簡単に説明すると、JSlider を拡張して、 (i) JSlider 中にあるクリックを受け取るリスナ (MouseListener) を一旦 remove して、(ii) クリックで細かく動く listener に新たに設定し直している、ということですね。
これなら実際に動かしてみても、キレイに動きます。

ある程度使う場面が考えられるような機能なので、簡単な設定でこのような挙動で実装できるようになっているといいなと思うのですが、Java 7 でも機能追加されないかな?

基本的に目的の達成を目指して実施してきた過程で副産物的に得られた知見で、英語で調べられれば誰でも解決できる話なのですが、多少他の人の役に立つかなと思い少しまとめてみました。

2011年3月7日月曜日

Office suite のクラウド連携 vs クラウドストレージ

最近 google docs のインターフェイスが新しくなって使いやすくなりましたが、今回さらに google docs をバックエンドとしてデスクトップの microsoft office を連携させていくようです(グーグル、「Cloud Connect」を公開--Officeファイルを「Google Docs」と同期)。この流れだと、Open Office (Oracle) と Libre Office でもプラグインの形式で対応してくるかもしれない。
Google は microsoft のように既存のデスクトップアプリケーションを販売することにこだわらなくていいので、他の office suite もブラウザでの使用もきっちり対応できて、ほんの少しだけ有利かも。

でも、Microsoft Office が同じような機能をやっていたときから疑問に思っていたのですが、こういう office suite のクラウド連携と、DropBox などのクラウドストレージサービスを使って連携するのと、どっちがいいんでしょう? 機能を統合している前者がいいのか機能ごとにわかれていて連続して使用する後者がいいのか。個人の使い勝手という観点や、ビジネスの構造(垂直統合と水平分業の意味で)がありますが、それぞれの視点で考えられると思います。

個人の使い勝手という観点からいうと、office suite に対応していないファイルも取り扱えるので、後者の方が気分的には楽かなとも思います。一方、前者のほうがアップの手軽さで、後者では同期時に不可が大きくなるため、単純な使い勝手だと前者の方がいいという人もいるような気がします。
結局どっちがと決定づけるのは難しいかなと思いますが、主流としてはどちらになっていくのか、気になります。

ビジネスの構造の視点では、前述の個人の使い勝手とも関連してきますが、水平分業を進めることで規模のメリットや 1 つの機能の追求、メンテナンス性の向上などの利点があったり、他方統合しているほうが all in one で売りやすいというメリットも見えてきます。

結局分野や情勢、ブロックバスターとなる商品のスタイルなどによってこの、統合型と水平分業連携方のどちらがいいのかは変わってきて、永遠の議論対象なのかもしれません(例:統合型の Mac と水平型の windows、ビジネスモデルとしての垂直統合的な日本の携帯電話(やapple?)と欧米の水平型市場)。

2011年3月4日金曜日

ネットの実名と匿名と、密結合と粗結合 (twitter の"次"が facebook?)

1. 密結合と粗結合が作り出す複数のネットワークの構成

人のつながり方の密結合と粗結合について、これまでにいろいろと書いているけれど(人のつながりにおける密結合と粗結合)、そのつながり(結合)によって構築されるネットワークについて考えてみた。
特に今いろいろと話題(問題)になっている facebook と実名性でのネットワークと、それに対応する匿名空間について考えたいと思います。

人のつながり方の密結合と粗結合については、まえの記事で書いたけれど(人のつながりにおける密結合と粗結合)、その粗密に関係する要素の「背景情報の共有度」は結構重要なことで、特に (1) 実名か (2) ハンドルネームか (3) 匿名か、という部分は各種エンジンで簡単に検索して名寄せできるネット上では重要になりますし、この 3 つのどれがネットワークを主に構成しているかでネットワークの性質が異なってくるように思います。
 具体的には、(1) 実名の場合には密で現実に(いい意味でも悪い意味でも)裏打ちされたネットワーク、(2) ハンドルネームではやや緩いけれど、継続性を持ったネットワーク、(3) 匿名だと粗結合で自由度が高いけれど、継続性がない関係性になって、現在のコミュニティの性質をよく繁栄しているのではないでしょうか。

個人的な認識ですが、現実の関係やネット上の関係を含めた、人と人とのつながりの構造、ネットワークの構成を図にしてみました。



2. 密結合と粗結合が作り出すネットワークの性質

結合が密な実名層は、実社会に張り付くように存在し、結合は強固でローカルな楽しさがあります。反面、その関係から離れにくかったり、社会的な立場やその他の考え方が異なると似た趣味でもなかなかつながりを作れない、友人関係や印象等いろいろと配慮をしなければいけない、など実社会を超えたつながりを、特に動的に作るのには不都合な点が多いです。
一部の仕組みで流動性も多少あるけれど、非常にソリッドで固体的なのが特徴かなと思います。

これに対し、匿名の関係性(blog のコメントで見られる匿名コメントや捨てハンドル、2ch での匿名コメント(ID がついていたりもするけど))は、趣味や嗜好、考え方で集まりクラスタリングできるけれど、つながりの持続性が弱く離散しがちで、何かの議論や話をする場合、同じ展開を何度も繰り返してしまったりします(その点、2ch ではテンプレート等で対応している様子)。
流動性が高すぎ、発散する非常に気体的な特徴があります。

他方、ハンドルネーム層は、継続的に同じ名前や ID を使うため、関係性やつながりはゆるく担保されるが、実名や実社会の関係に基づかないため、比較的関係を作ったり切ったりするのが簡単。そのため、比較的強いつながりが残り続け、同じような趣味や嗜好、考え方を持った人が集まりやすく、つながりを保持しつつクラスタリングしやすい。相手の情報も限定的なため、フラットな関係で話をしやすい。
また、継続的にハンドルネームを使用していると人柄がある程度わかるので、実名のアカウントともやり取りをしやすい。他方、何かあっても実社会への影響は起こりにくいため、比較的匿名層ともやりとりをしやすい
全体的な柔軟性と適度な流動性、クラスターを作るところからみて、とっても液体的(水のクラスターみたい。※ クラスターの小さい水を使うといい製品ができるとか、そういう擬似科学ではないです><)。
特に twitter ですと、実名でも匿名的にも使えるし、クラスタリングもかなりすばやく効きますし、クラスタを超えた伝播も多く、かなり優秀な液体ではないでしょうか?


mixi から、twitter への(一部の?)流れは、擬似同期的な速さの楽しさのところもあったかもしれませんが、上記のネットワークの性質の面から考えると、実社会に縛られずクラスタリングされる楽しさの部分が結構大きかったのではないかなと思います。mixi も実名から匿名へ、実社会に固まっていたところから流動性を高める方向に動いている(いた?)ようにも思います(ほとんど使ったことないので分かりませんが)。
また、同じような嗜好や趣味のクラスタの楽しさと、実社会からの強い束縛を保持しつつ、関係性や継続性の担保が欲しくて、2ch 等大規模掲示板から twitter に来た(メインを移した)人も(少しは?)いるように思います。


3. ネットワークを楽しむユーザーの視点で見て、twitter の"次"が facebook なの?

このように束縛されすぎず関係性を楽しめる液体的な特性のため、twitter が使われるようになってきた気がする(仮説)のですが、twitter の次は facebook だという人もいます。

関係性が流動的で、実社会の関係を超えて広く繋がれることを楽しむようになってきたつ言ったーユーザーは、また現実社会に張りつけられ(以前よりより強く?)束縛されたコミュニティに戻りたいと思うのでしょうか?あるいは、facebook で日常のつながりをより強固で動かしがたくしたいと思うでしょうか。日常のソーシャルグラフを活かしつつ趣味でつながりたいなら facebook よりいいサービスが他にあると思いますし(鍵かけて twitter 使うのもいいと思う)。
もちろん、人の好みによりますが、上で述べたような感性の人も多いように思いますし、twitter ユーザーが全体的に facebook のほうに流れるとはどうしても思い難いです。

実社会にへばりつく facebook は、実社会の関係性を強化するために使うほうがいいですし(距離や仕事が離れた友人との関係には便利ですね。これ以上密結合を密にする方向に進むのは、?という気がします)、流動的な twitter は実社会のクラスタを含みつつ超えて、オープンでフラットな立場でつながりを楽しむのに使うのがいいんじゃないでしょうか。

次は twitter だとか、次は facebook だとか、そういうビジネス的な視点での流行を信じて動くより、そのつながり方の性質を見て、自分の頭で考え、好みを決めるのが大事だし、楽しいんじゃない?

2011年3月2日水曜日

用語:粗結合と疎結合について

以前の人と人とのつながりに関する記事(Twitter と飲みニケーション人のつながりにおける密結合と粗結合)でつかっている「粗結合(そけつごう)」 について。

以前の記事で書いた、「そけつごう」は、loose coupling の日本語訳として?、プログラミングの世界でよく用いられ、「システムの要素どうしの連関が、互いに交換可能である程度に緩いこと。」などのような意味で用いられています。この際、漢字表記は、「疎結合」と書くことが多いようです(「粗結合」とも書くようですが)。
プログラミング上での意味の、相互に依存しない関係は、確かに質的に「結合が強くなく、疎である」と考えられるので「疎結合」でもあっていると思います。ただ、この表記だと「結合の数が少ない、あまりない」ともとれてしまう気もします
個人的に前の記事で述べている "人のつながりの「密結合」と「そけつごう」"では、とくに後者に取られてしまう可能性が高いので、どちらかというと「粗結合」と書いたほうがいいかなと思っています。

人のつながりにおいては、数が少ないというより、結合の密度というか束縛度が低いという感じ。

2011年3月1日火曜日

人のつながりにおける密結合と粗結合

以前の記事で書きましたが(Twitter と飲みニケーション)、粗結合のほうが好きな傾向がある人と密結合のほうがすきな傾向がある人がいるような気がするんですよね。もちろん、場面や関係によって、結合(つながりかた、コミュニケーション)の選び方が違うと思いますが、全体的な好みもあるような気がします。

でもこの、密結合とか粗結合というのが、なんとなく感覚的で良く分からないので、少し考えてみました。
まず具体的に、どういうつながりかた(結合)が密結合で、どういうつながりかたが粗結合か考えて、リストを作ってみました。上から順に密結合から粗結合へいく気がします。

↑密結合
・飲み会やイベントでの会話
・日常会話
・電話
・ニコニコ生放送
・facebook
・携帯電話でのメール
・mixi 等
・skype(チャット、会話などいろいろあるけれど…)
・PC 等でのメール
・twitter
・はてなブックマーク
・blog
・小規模掲示板
・(旧)ニコニコ広場
・大規模掲示板 (2ch)
↓粗結合

あくまで伝達方法なので、使い方によって順位は変わってくると思います。たとえば携帯電話のメールを即時性を重要視する使い方をしていれば、電話より相互の状態が強く繋がって依存している状態になりますし、twitter や blog でも実際の顔見知りの人同士で使っていれば、電話ぐらいには密な結合になる気がします。
ただ、一般的に、下に行くほど互いの情報をあまり持っていなくても成立し、使用する際に両者がリアルタイムに時間をあわせる必要性が低くなる、より粗な結合になると思います。

密とか粗とか、凄く抽象的で感覚的なので、具体的にどのような要素で構成されている感覚なのか、考えてみたところ、
  • リアルタイム性(使用する際にどの程度相手の都合にあわせなければならないか)
  • 背景情報の共有度(相手のことをどれだけ知っているか)
  • 通信時の情報量(テキストか音声か、画像や映像か)
の 3 つが思い浮かびました(プログラミングでの意味とは少し違うかもしれませんね)。
先ほどのリストの下に行くほど、それぞれの項目の度合いが低くなり、一方、上に行くほど、結合が密になり他の関係との代替が困難になります。


具体的に個人の傾向で考えてみると、メールより電話を好む人は、いろいろな情報を知れるので、実際に会ったり飲み会で話すのが好きだったりする一方、メールでやりとりするのが好きな人は、twitter などが非同期的(擬似同期的?)で拘束が少なく好きだったりする気がします

また、職業的にも営業担当の方は密結合がウリであるところもあり、上のほうのコミュニケーションを好むように思いますし、開発やさらに研究の人はなるべく非同期的な粗結合のもので連絡して欲しいと思う気がします(Togetter-電話するならまず先にメールでアポを取るべき)。(電話の密結合的なリアルタイム性は、やっぱり迷惑を感じますよね…。)

このように密結合と粗結合を意識して、日ごろの好みで相手がどういう連絡手段がすきそうか考えると、上記の営業の人と開発の人みたいな齟齬が減って便利じゃないかなと思います。

2011年2月25日金曜日

Vala プログラミングに valide を使ってみる。

Vala の開発環境にはいろいろあるみたいだけれど、valide を使ってみた。
Windows 版の exe もあるみたいですが、とありえず ubuntu 10.10 で。

Valide (https://launchpad.net/valide ) の valide-0.7.0.tar.gz をダウンロードして、README を読んでビルドしてみましたが、各種ライブラリを手動でいれていかなければいけなくて面倒なのに加えて、なぜか「No package 'vala-1.0' found」とでてしまい(vala 0.10.3 とか、0.11.5 とかならあるのだけれど)、うまく起動できませんでした。

仕方がないので、こちらの PPA をいれて、インストールしてみました(というか vala の最新版を入れるときに使っていて、ふと valide あるのを見つけました…)。
https://launchpad.net/~vala-team/+archive/ppa

無事以下のような感じで動きました。ファイルの管理がしやすい、使うライブラリ(?)をプロジェクトごとに管理できるので、--pkg gtk+-2.0 つけてコンパイルしなくていい等、多少楽できるのかな?と思います。


Valide のウインドウ。





Valide。新規プロジェクト作成時の画面。言語では Vala 以外に Genie も選べる。

2011年2月21日月曜日

Vala に関する資料のリンク集。

Vala の使いどころ
  • C#に近い文法のオブジェクト指向プログラムからC言語/GObjectのコードを生成するValaについて(概要) (http://d.hatena.ne.jp/kakurasan/20090427/ ) → linux 上での話に限定されるけれど(もとより主に linux 用ではあるけれど)、まとまっていると思います。 Mono との比較ですが、Java でも同じような話になりそう。


Vala についての情報
  • Valaについて語りませんか (http://www.pctec.2chmatome.info/?p=720 ) → スレッドを保存し、ノイズを除いたもの。体系的ではないけれど、断片的な知識や手がかり的な情報が手に入り有用かもしれません。



Vala のドキュメント、valadoc
  • Valadoc について (http://live.gnome.org/Valadoc ) → vala のソースコードのコメントからドキュメントを作成する。javadoc 的な。
  • Valadoc (http://valadoc.org/ ) → 使える既存のライブラリ (vapi ファイルが作成されているもの?) などを調べられる。valadoc で作成(?)。GTK などを使うときに便利。


Val(a) IDE
  • Valide http://www.valaide.org/ → まだ機能は少ない気がするけれど、vala の IDE、valide のホーム。windows 版もある?
  • https://launchpad.net/valide → valide の開発用 launchpad。

2011年2月20日日曜日

blogと「わた」の位置づけ。

すこし悩んだけれど、この「わた」っていうアイデンティティ(この blog や広場まとめなどなどぜんぶ含めて)を活かしていこうと思う。
他に新規にアカウントや blog つくってもいいのだけれど、このアイデンティティに愛着があります。そのまま置いておくのも残念なので。
技術系の内容を中心に、オープンな web で、困ったときに検索するとひっかかるようなコンテンツを展開することを目標にしたい。

2011年2月19日土曜日

日本のユーザーのみる facebook と twitter の違い

以前投稿した記事(Twitter と飲みニケーション)に少しだけ関係しているかもしれない。

リアルの関係を超えて、いろんな趣味や興味のあうことで緩やかに広くつながってる日本の多くの匿名ツイッタユーザーの用途には、現実の拡張でしかない facebook は合致しないし、ツイッタのいいところを兼ね備えた上位互換を想定してつかうとすごくがっかりすると思う。
Facebook ページのリニューアルは、趣味や嗜好などに関して、現実からの拡張につながりやすさを持ち込むために作られているように感じるけれど、数日スパンの事柄については不向きだと思うし、ページの乱立は facebook 側は想定していない気がする(日本のユーザーがその気になれば、日本語の wikipedia の各種趣味のページなどのように、ふくらんでいく)。そういう部分は facebook ページではとらえられないし、何より複雑でめんどうくさい(ツイッタなら、タグをつけて検索すればいい、すごくシンプル)。
一方、匿名でリアルの関係で、少なめのフォロワーでツイッターを楽しんでいる人たちには、facebook にはあうと思う。
ただ、日本の場合、各種サブカルチャーや他国に比べ異常に多いブログとの親和性、ニコニコ動画等の匿名でのコミュニティ形成などから考えると、緩やかに広くつながってる匿名ツイッタユーザーのほうが多い気がする。そういう意味で、日本のツイッタユーザーは facebook には移行しにくいし、上記のように勘違いして移行しても、また twitter に戻ってしまうような気もする。

  

2011年2月11日金曜日

Vala でプログラムを書く (Gtk を使ってみる)。

前回(Vala でプログラムを書く。) のつづき。
Vala の使い方が分かってきたので、他のライブラリを使ってみたり、GUI アプリケーションを作ってみるために、Gtk を使ったサンプルを動かしてみる。

たとえば、こちら (Vala GTK+ Examples) の一番上のサンプルコードをコピーして vala ファイル (gtk-hello.vala) を作成し、以下でコンパイル (コンパイル等については、前回:Vala でプログラムを書く。参照)。

$valac --pkg gtk+-2.0 xxx.vala


コンパイルする際には gtk 2.0 が必要になります(ない場合、「gtk/gtk.h: そのようなファイルやディレクトリはありません」等エラーが出ると思います)。
Ubuntu 10.10 環境では、Synaptic で「libgtk2.0-dev」を入れたら、コンパイルできました(libgtk2.0 自体は入っていたようです)。Synaptic 便利。


実行すると、以下のようなウインドウができます。GTK を使えば、ちいさめのアプリケーションならある程度作れそうですね。


Vala で gtk2.0 アプリケーション。hello world。ウインドウ内にはボタンがあります。



Vala で gtk2.0 アプリケーション。hello world。ボタンをクリックした場合。

  

2011年2月6日日曜日

Twitter と飲みニケーション

NHK でツイッタユーザー対象に調査したところ、飲みニケーション反対が多いという話がでていました。それは、そうだと思う。そういう結果になる気がする。むしろあたりまえな感じが。逆だったら怖い。

飲みニケーションって、コミュニケーション上、最大の密結合ですよね。飲みニケーションに続いて、結合の密度で言えば、会話、skype 等のビデオ通話、電話、facebook 上のコミュニケーション、mixi〜、電子メール っていう順番のように思います。
一 方、twitter は使い方によりますが、粗結合(疎結合?)の系統に近いです。前述に続いて twitter、blog、質問系サイト、2ch 等大規模掲示板(場所によるけれど)の順に結合が粗になっていきます。Twitter は使い方によっては blog より粗結合だと思う。

もちろん結合の粗密でどちらがいいという話ではないです。

粗結合傾向のある twitter を好んで使っている人に訊けば、強い密結合になる飲みニケーションが嫌いというのは、すごく納得です。
ただ、twitter をニュースフィードで使う割合が低く、reply でコミュニケーション用途で使うことが多い人や、実名で使っている人は、飲みニケーションが好きな割合が高いのではないかなと思います。そういう層別解析はしたら面白いでしょうね。

メタな視点だけれど、こういうコミュニケーション方法の傾向を考えずになんとなく使っている人、多いですよね。
文句とかないですが、齟齬が起こることがあるだろうな、って思います。



   

2011年2月5日土曜日

Google health をさわってみた

PHR (Personal Health Record) に興味があったので、google health を年明けから使ってみました。と、いっても、あまり情報が無いので、体重や睡眠時間を入れてみただけですが。
英語のインターフェイスですがとくにストレスなく使え、各種情報で Wii fit の体重測定時のように簡単にグラフがみられいいですね

こちらの記事(Google Health、新デザインで登場も日本向けではない)で日本向けのデザインになっていないと指摘されており、実際日本語でないため部分的に使いにくいのではと感じられますが、「単位がMKS単位系になっておらず、ポンドやフィートが採用されている」という問題は解決されているようです。
上の「Option」から「Settings」を選ぶと、単位系を「Pounds and Feet+Inches」と「Kilograms and Centimeters」から選べます。

それよりも、医療機関の情報やその他の機器のデータのインポートが日本では簡単にできないことが課題ではないでしょうか(サービスがターゲットとしているアメリカなら便利に利用できるのだろうか?)。

まだ自分の入力した情報も、他の利用者も(日本では?)少ないですが、google health data API も使ってみたいです。


  

2011年1月16日日曜日

Vala でプログラムを書く。

いろいろと影響を受けて、Java や C# に似ている、Vala (wikipedia に日本語版の記事がない。作ったほうがいいな) をちょっと勉強してみました。
Vala についてはこちら (ValaによるGNOMEアプリケーションのプログラミング) がわかりやすいと思った。

環境は ubuntu 10.10 上で。とりあえず、Vala で書き、コンパイラ (valac) でコンパイルして、文法を学ぶこと、を目標に。



(1) Synaptic で 「valac」を探し出して、インストール。

現在、valac-0.10 が管理されています。2011.01 時点で、0.11.3 が最新でそちらを使ってもいいですが、とりあえずそのまま使いました。


(2) Valac のインストールの確認

アプリケーション -> アクセサリ 等から、ターミナルを開き、

$ valac --help

を実行してみて、インストールを確認(このコマンドでヘルプが表示されます)。


(3) web 上の (他のライブラリを使っていない) サンプルプログラムをかたっぱしから見てみて、実行してみる。

こちら (「猫でも分かるC#プログラミング」はValaで使えるか) が簡単かつわかりやすく、参考になりました。特に C# や Java を学んだことがある方にはおすすめです。

xxx.vala をテキストファイルで作成し、サンプルプログラムをコピー。

$valac xxx.vala

でコンパイルして、できた xxx を

$./xxx

で実行。各種サンプルプログラムのコードの意味を考えながら、上記を繰り返す。


(4) Vala の他の文法等について勉強。

このチュートリアルが良いです (Vala Tutorial、英語です)。読みやすいです。
チュートリアル集はこちら。参考になります。


以上で、ある程度のことは Vala で出きるようになったかなと思います。Gtk 等の他のライブラリを用いた場合については、後日また。

Vala は日本語で説明しているサイトが少ないため、やや学びにくい状況かなと思います。
特に、linux などでプログラミングをしてきた人向けの情報は少しありますが、プログラミング経験が浅い人向けの情報は少ないかもしれません。
この記事が、そういう場合の役に立てればいいけれど。