Category archives: ナオ

Visual Studio Community

20141203n ナオです。 さて、Microsoft社製の統合開発環境であるVisual Studioの無償版、Communityエディションが提供されるようになりましたね。これまでもExpressエディションというのがやはり無償で提供されてきたのですが、パッケージ自体が開発言語や開発対象ごとに分かれていたり、拡張機能が使えなかったりと有償版に比べて不便なところがありました。Communityエディションは有償のProfessionalエディションに相当ということで、パッケージが共通になり、拡張機能も使えます。企業の利用には会社規模や利用人数などに制限がありますが、個人開発者は特に制限がありません。 Professionalエディションは数万円するなど個人で買うにはなかなか高額だったため、これは趣味でプログラムを組む人間にはありがたい存在です。学生時代にDreamSparkで入手した2012のProfessionalを持ってはいますが、それと違って商用利用も可能なので、有料アプリを作ってストアに公開することも出来るようになります。こうなるともはや個人開発者はVisual Studioを有償で購入する理由がほぼ無いわけで、このあたり、どうやらMicrosoftは本気で収益構造の転換を図るつもりのようです。 .NET Coreのクロスプラットフォーム化もそれの一環でしょう。.NET自体、もともとコンセプトとしてはクロスプラットフォーム対応だったのですが、ここにきてようやくそれが本格的に実現されるようで、開発言語たるC#の使える幅が広がるとなれば期待したいところ。

Knockout.js

20141024n ナオです。 さて、今回は技術的なお話を。 JavaScript、といえばGmailやGoogle Mapsの登場以降、モダンなWebアプリケーションを提供する上でもはや欠かせないものとなりました。ただ、確かに欠かせないものではあるものの、何かと不便なことも多々あります。とりわけHTMLのDOM操作は標準のAPIでは面倒なものです。かつてと比べれば大分マシにはなりましたが、ブラウザ間での差異という問題もあります。 今ではそれらを解消ないし軽減するため様々なライブラリが提供されています。jQueryはその最たる例で、DOM操作のライブラリとしてはすっかり定番となりました。 ……とはいえ、機能が複雑化していく昨今のWebアプリケーションにおいて、直接DOMを操作するというのは、画面の表示状態と実際に保持するデータとの整合性を保つ上で大変です。画面は書き換えたけど保持するデータは変わっていないだとか、反対に保持するデータは変更したけど画面に反映させてないだとかが発生することになります。 そこで、データ(model)を自動的に画面表示(view)へ反映させる、あるいはその逆を行ってくれる、より高レベルなフレームワークが登場することになります。今回はそのうちのKnockout.jsについてです。 このフレームワークはMicrosoftの従業員が開発したそうで、.NETのバインディングに似たものとなっています。JavaScript上のデータとHTMLを関連づけることで、一方の変更をもう一方へ自動で反映させることが出来るようになります。Webアプリケーションを作る上で最も気を遣う部分がグッと楽に書けるようになるのです。 同種のフレームワークで人気のものにGoogleが開発するAngularJSというものがありますが、Knockout.jsはそれと比べて機能が絞られており、覚えることが少なく非常に簡単です。HTML側の記述もdata-bind属性のみを使用し、HTML5としてvalidであるという(標準志向派にとっての)利点もあります。 チュートリアルも優れていると評判で、ページ上でさっと書いてすぐ試せる親切仕様になっています。 Webアプリケーションを作るときに是非とも。

現代のひみつ道具

20140826n こんにちは、ナオです。 さて、最近ドラえもんの3DCG映画が公開され話題となっています。ドラえもんといえば22世紀のひみつ道具が登場するわけですが、21世紀の現在でもそれに近しいようなものが実現していたりします。 そのものずばりなものが実現している例ではかべかけテレビですね。部分的な実現を含めればそれ以外にもちらほらと実現例が見られます。さすがにどこでもドアやタイムマシンは厳しいですが……。 そんなひみつ道具の中に、オコノミボックスというものがあります。四角いものであれば何にでもなれる道具で、テレビやレコードプレイヤー(レコードというあたりがかなり時代を感じますね)、カメラなどとして使用されています。まるでスマートフォンではないか、とちょっと前にTwitterでも話題になりましたね。……作中では更に洗濯機やストーブ、懐炉などとしても使用されていて、そこまで行くとスマートフォンでは実現できませんが(懐炉なら端末の発熱で出来る?)、35年前に万能のひみつ道具として描かれたそれに近いものが今や私達の手元にあると思うと、なかなか感慨深いものがあります。 そうして考えてみると現代人は意外とSFの世界に生きているのかも。

新PCを買いました

ナオです。 最近新しくPCを買いました。実に快適です。——いささかオーバースペック気味ではありますけれど。 お下がりで貰ったWindows 98マシンを使用していた頃から引き継がれているデータなどもずっと引き継がれ続けてきていて、ドキュメントフォルダ内に更新日時が2005年のファイルがあったりと、新しいマシンなのにところどころ懐かしさもある状態になっています。 ところで今回Windows 8.1マシンからWindows 8.1マシンへ移行するという事態になったため、Microsoftアカウントによる設定の同期が行われました。デスクトップの壁紙やらスタート画面のタイル配置やらが同期されたようです。同期される情報はOSとモダンアプリ関係のものとなるため、昔ながらのデスクトップアプリについては基本的に同期されません。デスクトップアプリは本体の配置場所も設定の保存先もフリーダムな存在であるため、当たり前と言えば当たり前なのですが……。 何はともあれ、快適な環境でプログラミングもはかどります。

縦書きWindows 8.1

20131111i こんにちは、ナオです。 さて、この間Windows 8.1が発売され、私のPCもアップグレードして数週間が経ちました。8ユーザはWindows Storeから手軽に無料でアップグレードできるとはいえ、OSのアップグレードには変わりがないためディスプレイドライバを入れ直すなど幾つかの手間は掛かりましたが、ともあれ無事に使えています。 Windows 8.1は8の完成版というような言い方もされているようで、8を利用しているユーザであれば特別な事情が無い限りアップグレードした方がいいのではないかと個人的には思うのですが、その理由の一つとして、フォントに関わる重大な改善が8.1に施された点が挙げられます。 というのも実はWindows 8では和文の表示に関して結構致命的な問題があったのです。それは縦書き表示にした場合に、三点リーダ(…)やダッシュ記号(―)の向きがおかしいというもので、縦書きでも横書きの時と同じ向きで表示される、つまり90度回転した表示になってしまっていました。いずれの記号も小説などではよく使われるものですので、とりわけそういうものを書く人にとっては大問題だったのです。これが8.1で無事に解消されました。Windows 8を利用している物書きはアップグレード待ったなしといったところでしょうか。UIの変更より何よりこれがために8を避けていたユーザも少なからずいるようですし、個人的にもこれはどうかと思っていた不具合だったので解消されたのは喜ばしいことです。 ところでWindows 8といえばスタート画面の大変更についていろいろ言われることが多いですが、8.1でも基本的なところは変わりません。タイルサイズの種類が増える、「すべてのアプリ」への切り替えが簡単になるなど細かい変更はありますが、タイルという基本はそのままです。しかし旧来のスタートメニューは細かいマウス操作が要求され、押し間違いもしばしばだったことを考えると、スタート画面がスタートメニューより使いづらいとは特に思わないのですがいかがでしょう。……もっとも、自身のPC環境がデュアルディスプレイであり、元々マウスカーソルの移動量が多かったことからそれを特に苦とは思っていないせいもあるかもしれませんが。

アプリのアイコン

20130913i こんにちは。ナオです。 さて、PCにしろスマートフォンにしろ、何かしらアプリを起動しようとするとき、そこにはアプリのアイコンが表示される場合がほとんどだと思います。いわばアイコンはそのアプリを代表する顔のようなものなのです。 アイコンは結構重要です。他のアプリと区別出来る見た目でなければ、どれを選べば目的のアプリが起動してくれるのかわからなくなってしまいます。Windows 8やWindows Phoneでは白いアイコンが基本になり、より標識的なデザインが求められる傾向にあるので上手く作るのはさらに難しくなります。 白一色で良いのに難しい、というのは奇妙な感じもします。確かに、影や光沢といったエフェクトを使いこなすのは大変ですが、しかしそうでなくともある程度使えるならば、手軽にリッチな雰囲気をもたらしてくれる調味料なのです。 ……それが使えないフラットデザインの、それも白一色となればまさに「素材の味」がそのまま出てしまうわけで、つまり誤魔化しが効かないのです。趣味でアプリを作るときはアイコンまで自分で描きますが、このあたりはよく悩むところです。

新しい言語

20130906i こんにちは、ナオです。 最近、ちょっと趣味で運営しているサイトのシステムを作り直そうかなと思っていまして、はたして何の言語で書こうかなと。 以前長らく借りていたレンタルサーバはPerlとPHPにしか対応していなかったのでPHPを使って組んでいたのですが、今のサーバではRubyやPythonも使えるようなのでどうしようかな、と……。こんなことを言い出すとはてさてどこからともなくそれぞれの言語について熱く語って勧めてくる人達が出てきたりするのがこの界隈なのですが、それは置いておくとして、せっかくなので今まで触れたこともないPythonをやってみようかなという気持ちもあります。ソースコードのブロック構造を見た目に解りやすくするために行うインデントを、見た目だけではなくむしろそれを表す構文としても意味を持たせてしまおうというようなユニークなスタイルなどがあり、使う機会が無かっただけでもともと興味はある言語ですね。 もっとも、まだほんの少しWikipediaなりその他サイトでの説明を見てみただけで開発環境の準備さえしていないのですけど……。作り直そうと思いつつそれとは別のものを作るのにJavaを書いたり、それにともなって何故かCを書いていたりして時間が無くなってしまったりしています。このあたりはやっぱりどうしても学生時間より使える時間が短いわけなので、やりたいことをたくさん抱えているとなかなか手が回らなくて何ともはや致し方のないところではあるのですが……。とはいえサイトシステムの作り直しも大分後回しにしてしまっているのでそろそろ手をつけようと思います。

int・Integer・null

20130830i こんにちは、ナオです。 さて、ずっとJavaの話が続いているわけですが、今回もまたJavaです。2つの数値が等しいか確認するコードについて、仕事でちょっと驚いたことがありまして……。 プログラムの話になりますが、Javaにおいて2つの数値が等しいかどうかは、例えばaとbについてであれば「a == b」のように「==」を用いて表します。ところがこれでは上手くいかないパターンというのもありまして、それぞれの数値が数値そのままではなく、ラッパークラスと呼ばれるものによって覆われたオブジェクトとなっている場合には、「a.equals(b)」と書かないといけなくなります。ラッパークラスで覆うことによって出来るようになることもあるのですが、そういう点には注意する必要があります。と、ここはJavaの基本的なところなのですが本題ではないのでこのあたりで割愛します。 今回驚いたのはそんなラッパークラスで覆われた数値(参照型、整数ならInteger)と、覆われていない普通の数値(プリミティブ型、整数ならint)とが等しいか確認するコードについてです。Javaにおいてこれは「==」で比較できます。この場合にはIntegerの方が自動的にintへと変換されて、その上で両者が等しいか判定されるのです。この点に関しては何ら問題のない、むしろ便利な機能なのですが……Integer側がnull(何もない値。≠0)であると問題が発生します。 どうやらIntegerからintへと変換する処理は内部的に「a.intValue()」といった形式で行われるようなのですが、aがnullであるかどうかにかかわらずこの処理が行われるため、もしもnullだった場合にはここで「ぬるぽ」としても有名な「NullPointerException」が発生します。これが発生する原因というのは判りきったもので、null値であるもののメソッドを実行しようとしたりフィールドを参照しようとしたことによるものです。そのためエラー発生行を確認すれば「foo.bar()」や「hoge.hoge」といった判りやすい記述があるわけなのですが、Integerとintを「==」で比較して発生した場合、これが見当たりません。私が戸惑ったのはそのためでした。一体どこにNullPointerExceptionの発生する要素があるのやら、と。 「==」で比較する場合にもNullPointerExceptionの発生するパターンがあるのだなぁと一つ学んだ出来事でした。もっとも、あまり遭遇することはなさそうですが……。

Java 7

20130823i こんにちは、ナオです。 最近は仕事でも趣味でもJavaをいじっているJava漬けの日々なのですが、趣味の方ではJava 7のコードに書き換える作業をしています。Java 6のサポートももうじき終わる(OpenJDKなら続く)ので、Webで公開しているものについてもそろそろ移行して良いだろうと思い、だいぶ便利になったと噂のJava 7の世界へようやく突入しました。 実際書いてみるとファイル操作周りの改善がいい感じですね。この辺りに関してはもともとがかなり貧弱で、ファイルコピー一つするのも割と面倒だったのですが、きちんとそのためのメソッドが用意されて楽に書けるようになっています。 それから、ファイルの中身を読み取ったり、あるいは書き込んだりするときも楽に書けるようになっています。特にそれら操作を終えた後のファイルを閉じる操作については、お決まりの記述でありながら冗長で面倒くさいものでした。try-with-resourcesと呼ばれる、開いたファイルを自動で閉じてくれる構文が新たに加わったことで、すっきりと簡潔に書けるようになり、利便性が格段に向上しています。もっとも、C#なんかでは同様のものが昔からあったのですが……。 ともあれ、Javaの弱かった部分が補強された感じなので、これはもう趣味の方では7が標準ですね。

バージョン管理システム

20130816i こんにちは、ナオです。 さて、私がMacBook Proを手に入れてからもう2ヶ月が経とうとしています。メインがWindows PCなのは変わらないのですが、MacBook Proの方も環境を整備していろいろと出来るようにしてあり、当然開発環境についてもそのようになっています。 バージョン管理システム、というのはとりわけ複数人で開発する場合においてソースコードの変更を管理するために使われると思いますが、これは個人で開発する場合にも有用です。新機能を作っている最中に既存の箇所でバグが見つかったりして、そちらの修正を先に済ませたい時であるとか、一度変更した部分を取りやめにしたい時などに、変更前の状態へさっと切り替えられる、戻せるというのは便利ですし、いつどこをどのように変更したのかという情報が残っているおかげで、例えば開発に時間を掛けていると初めのうちに行った変更を忘れてしまったりするのですが、そういう場合でもリリース時に漏れなく更新履歴を書き記すことが出来ます。 そんなバージョン管理システムにもいろいろと種類があって、古くはCVSであるとか、最近だとGitというものが有名ですが、それらは大きく分けると「集中型」と「分散型」の2つに分類されます。ソースコード全てとそれをいつ誰がどこをどのように変更したのかという情報を持つリポジトリが1つのサーバで集中的に管理され、開発者がそこへ直接変更をコミットする(反映させる)ものが集中型、それぞれの開発者がローカルにリポジトリのクローン(コピー)を所有して、コミットはまずそちらへ行い、それからリモートへ反映させるというものが分散型です。私がバージョン管理システムを導入した時は、1人で使うだけであるし、と集中型であるSubversionを選んだのですが、Windows PCとMacBook Proという2台のマシンを所有するようになって状況が変わってきました。 集中型のバージョン管理システムというのは、リポジトリのあるサーバに接続できない環境下ではコミットひとつさえ出来ないのです。Windows PCだけであった頃は、常時インターネット接続状態であり、そしてそもそもリポジトリ自体ローカルに作成したものなので何らの問題もなかったのですが、MacBook Proの側にとってはローカルでないわけで、こちらではどこかへ持ち出して使っている場合などリポジトリにアクセス出来ない状態が十分に起こりうるのです。 そこで、そういう時でもコミットが行えるよう分散型のバージョン管理システムへ移行することにしました。若干の設定が必要だったものの、リポジトリを移行する機能は用意されていたため特に戸惑うことなく完了し、現在それで運用しています。 ……ちなみに特に深い意味はないのですが、分散型として一番有名なGitではなくMercurialを選びました。