なんとなく思いつきで、その日の作業を全てTracに入れて、終わるごとにチケットをクローズしていけば、その日の作業ログが取れるなぁと思ったので、やってみました。 見た目はこんな感じ。 当日というのをもっと目立たせようかと思ったんですが、 AS modified をつけないとchangetimeは出力されないので、 AS __style__ と両立させることができませんでした。 レポート名: 完了したチケット レポートについての説明 完了したチケットを降順で表示 レポートのSQL: SELECT p.value AS __color__, (CASE status WHEN 'closed' THEN 'Closed' ELSE 'Doing' END) AS __group__, id AS ticket, summary, component, t.type AS type, priori

ビジネスに役立つ AI をお届けします 来栖川電算は AI 技術の研究開発から応用まで幅広いサービスを提供する名古屋工業大学発ベンチャー(2003 年設立)です。未踏ソフトウェア創造事業の採択者やソフトウェア分野の様々なコンテストの入賞者が在籍しています。最先端の AI 技術だけでなく、膨大な高品質データを生み出す技術、ハードウェアの限界性能を引き出す実装技術、高品質なソフトウェアを実現する設計技術にも定評があります。 手軽に使える様々な認識エンジン 来栖川電算の認識エンジンを活用すれば、センサーデータに埋め込まれた意味を手軽に抽出できます。種類ごとに用意された認識エンジンは教師データや設定を変えるだけで様々なタスクへ応用できます。Linux・Android・iOS 用のライブラリ、WebAPI、コマンドラインツールなどプログラマフレンドリーな SDK を提供しています。トレーニングやコン

会社で使っているTracのバックアップをするスクリプトをPowerShellで作ってみた。 readonly TRAC_HOME "D:\trac-0.1.1" readonly BACKUP_HOME "F:\Trac-Backup" readonly SVN_REPO (Join-Path $TRAC_HOME "svn_repo\projects") readonly SVN_ADMIN (Join-Path $TRAC_HOME "subversion\bin\svnadmin.exe") readonly TRAC_ADMIN (Join-Path $TRAC_HOME "admin\trac\trac-admin.bat") #############################################################################

ある型Aからある型Bへの変換をする処理を書く時にはよくTypeConverter型を継承して型コンバータを書いている。 型コンバータの利点は、.NET標準の機構であるというのもあるけど、変換元の型にカスタム属性で型コンバータを関連付ければ、 ↓こんな風に TypeConverter tc = TypeDescriptor.GetConverter(typeof(型)); TypeDescriptorを使っていつでも*1型コンバータにアクセスできること。変換の処理を変換元の型から切り離せるということも、プログラムの見通しをよくするのに役立つ。 そういう理由で型コンバータをよく書くわけだけど、毎回毎回TypeDescriptorを使って型コンバータを取り出して変換するのは案外めんどくさい。だからその処理をラップしたメソッドを変換元の型に ↓こんな風に [TypeConverter(typeof

Code Craftを読んでいたら防御的プログラミングについての記述があったので、自分が普段やっている防御的プログラミングについて書いてみる。 まずCode Craftで述べられている防御的プログラミングとは Code Craft P7 より 注意深く慎重を期したプログラミングのことです。防御的プログラミングでは、信頼性の高いソフトウェアを構築するために、システム内のすべてのコンポーネントを、各コンポーネントがそれ自体を最大限に保護できるような方法で設計します。暗黙の仮定をコード内で明示的に検証することによって、それらを粉砕します。これは、不正な動作を発生させるような方法でコードが呼び出された時点で、それを阻止するか、少なくともその状況を把握しようとする試みです。 とある。 防御的なプログラミングと聞いてまっさきに思い浮かべるのは、メソッドや関数呼び出しで事前条件、事後条件などのチェック（

今日、なんとなくプログラムのソースを何行ぐらい書いているのか気になったので、さくっとワンライナーで書いてみた。 (dir -recurse -include *.cs -exclude *.Designer.cs | % { gc $_| % { $_.Trim() } | ? { $_ -ne "" -and -not $_.StartsWith("//") } }).Count 検索対象はC#のソースで、デザイナファイルはあてにならないので除外。 空行とコメント行は無視する。 これでそれなりにあてになる行数が取れると思う。 ちなみに、今作ってるプログラムの行数は「26535」やった。意外と多い。

カレントディレクトリから特定のファイルを検索して、見つかったファイルをエディタで開くコマンドが欲しかったので、作ってみた。 ############################################################################### # 関数名： # Find-OpenFile (findop) # 説明： # 指定したパターンに合致するファイルをエディタで開きます。 # 引数； # $pattern : ファイル名のパターン（ワイルドカード指定可能） # $exe : ファイルを開くエディタ # $recurse : サブディレクトリも対象にするか ############################################################################### function Find-Op

アプリケーション構成ファイルには、ユーザ固有の設定を定義する場所として「appSettings」要素があるが、アプリケーションの規模が大きくなるとこの部分が膨れ上がって、管理しずらくなる。 これを解消する手段として、この設定を外部ファイル化できる。 通常は以下のように記述する。 <configuration> <appSettings> <add key="name" value="Hoge" /> </appSettings> </configuration> 「appSettings」の内容を切り出したXMLファイルを作成する。（例：Hoge.xml） <?xml version="1.0" encoding="shift-jis"?> <appSettings> <add key="name" value="Hoge" /> </appSettings> 「file」属性で、外部ファ

普段使っているNAntビルドファイルのテンプレートを晒してみる。 default.build - Download <?xml version="1.0" encoding="shift-jis" ?> <!-- PROJECT_NAMEをプロジェクトに合わせて変更してください --> <project xmlns="http://nant.sf.net/release/0.85/nant.xsd" name="PROJECT_NAME" default="build" basedir="../src/PROJECT_NAME"> <!-- プロジェクトの名前 --> <property name="project.name" value="${project::get-name()}" /> <!-- フレームワークのバージョン --> <property name="framework

さすがにid:shi3zはよく分かっていらっしゃる。わざわざプラットフォームって言葉を使う奴ほど自分の都合しか考えてないのが問題なんだよね。相手の都合を考えて必要なものを提供し、時に結果的にネットワーク効果が働いてプラットフォーム的な位置付けになることはあっても結果に過ぎない。BASICだってDOSだってWindowsだって同じじゃないかな。 プラットフォームをつくるときに、自分の都合を優先して考えてはいけない。 ただそれだけのことだと思う。 追記: 事実関係が微妙に違っていた模様。詳細はwikipedia:QDOS参照。 Thx > id:finalvent ちょうどいい例なのでDOSを取り上げてみよう。DOSって今時のOSと違ってメモリ管理もタスク管理もデバイス制御も中途半端にしかやっていなかったので、プラットフォームといえるかは微妙だけど米国では最初からIBM互換しかなかった。日本で

MagicPot のソース公開用に、 Visual Studio の .csproj, .sln 含めソース一式をコピー .suo ファイルとか bin, obj フォルダとか、公開する上で不要なファイルを削除 ZIP で圧縮 という処理を PowerShell で書いてみた。 http://ufcpp.net/study/powershell/source/ZipVsProjects.ps1 ZIP 圧縮の部分は下記サイトを参考に。 Compress Files with Windows PowerShell then package a Windows Vista Sidebar Gadget – David Aiken これを .ps1 ファイルにしたのが↓（ZipVsProjects.ps1 と同じフォルダに置く）。 http://ufcpp.net/study/powershel

ドットインストール代表のライフハックブログ

VS 2008 / .NET Fx 3.5 / C# 3.0 の日本語正式版も出たということで、C# 3.0 で導入された var（型推論）の是非をめぐって先月半ばごろに軽い論争が起こってました。正月休みに入って時間もあることだしちょっとまとめてみようかと。 私見としては 最初に私見を書いておこうかと。 まず、「C# 3.0 の var はあくまで「型推論」であって、バリアント型ではない」ということは改めて念を押しておきます。型が合ってなければコンパイル時にエラーがでるし、Visual Studio で変数にマウスカーソルを合わせれば型名が表示される。C# が型の甘い言語になったということでは断じてない。 で、var の利用ポリシーに関してなんですが、考えられるのは 匿名型利用時など、どうしても必要なときだけ使う ↑に加え、右辺が new SomeClass() のようなときだけ var