Extras Dynamically Composing Expression Predicates Suppose you want to write a LINQ to SQL or Entity Framework query that implements a keyword-style search. In other words, a query that returns rows whose description contains some or all of a given set of keywords. We can proceed as follows: IQueryable<Product> SearchProducts (params string[] keywords) { IQueryable<Product> query = dataContext.Pro
最近、会社でシェルの操作方法について教えているのだが、 pgrep / pkill / skill / pidof といった 便利なプロセス操作系コマンドを知らない人が実に多い。 プロセスを殺すというのは、よくある作業なので 今回はコレについて書いてみる。 たとえば、これらのコマンドを知らない人が、 指定した名前のプロセスを kill する手順はだいたい 以下のようなものになることだろう。 $ ps aux | grep プロセス名 | grep -v 'grep' # コマンドの出力結果から pid を目で確認 12345 ... .. hoge .. .. $ kill 12345 この作業は非常に面倒で退屈だ。 もし殺さなければならないプロセスがたくさんあったときは どうするのだろうか。 おまけに、grep コマンド自身が候補に含まれてしまう事があるのだが、 grep -v grep
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. This came to my mind after I learned the following from th
突然ではありますが、とっておきの yield return の使い道を紹介しようぢゃないか。・・・って別にそんなたいそうなものじゃないけどね。 まず、IEnumerator ってのは次のような状態遷移モデルで捉えることが出来るわけだ。 逆に考えると、状態遷移でモデル化できる設計は、IEnumerator を利用して実装できるんじゃないか、というのが着想。つまり、yield return を利用して状態遷移モデルを実装しよう、ということ。 何のメリットがあるかって? 僕が思うに、状態遷移モデルは結構実装が面倒だ。面倒というか、コードがぐちゃぐちゃになりやすい。ところが yield return を上手く使えばあら不思議、状態遷移がすっきりと記述できてしまうのだ。 具体例を挙げてみる。 何か作図ツールのようなものを開発するとしよう。CADとかパワーポイントとかVisioとかを想像すればよい。さ
よほどのC#初心者でも無い限り、delegateの便利さを理解していて無名delegateを活用するコードを多用していることと思う。しかしdelegateでcontinuationが実現できることは知らない人が多い。 まずcontinuationとは何なのか、何故それが必要なのかを簡単に説明しておく。ここで言うcontinuationとはSchemeで言うcontinuation(継続)である。 簡単に言えば関数の実行を一時的に中断しておいて、次回にその関数が呼び出されたときにその続きを実行する機能である。「ああ、C#ならyieldで出来るよね」と思った人、それ正解。 どこでこの機能が必要なのか。例えば次のプログラム。 ウィンドウ内にダイアログを(DirectXやら何やらを用いて)自前で描画したい。ダイアログは「はい」「いいえ」ボタンがあり、そこがクリックされたときにハンドラが呼び出される
Parsing OData Paths, $select and $expand using the ODataUriParser UPDATE: This post was updated on May 29th 2013 to reflect changes to simplify the SelectExpandClause... Author: Alex D James Date: 05/10/2013 OData in WebAPI – RC release Next week we will release an official RC of the Microsoft ASP.NET WebAPI OData assembly. This marks... Author: Alex D James Date: 12/07/2012 Parsing $filter and $o
LINQ to Entitiesをやってて思うこと。 どんなSQLが発行されてるのか見たい!せめてSELECT文だけでも…。 というときのやりかたです。(LINQ to SQLだとLogプロパティにConsole.Outとか代入するだけで見れました。ただ、この方法だと全部出ちゃう。) LINQ to EneitiesのクエリはObjectQueryになるので、そいつのToTraceStringメソッドを呼び出してやると、SQLが取れるみたいです。 “みたい”というのはToTraceStringメソッドが「データ ソースに対して実行するコマンドを返します。」という説明文がMSDNに書いてあって、恐らくこの場合DBがデータソースだからSQLだろうという事です。 ということで、以下のようなメソッドを作っておくと吉。 [Conditional("DEBUG")] private static vo
開発中にSQLのチューニングを行っていると、処理時間の改善結果をミリ秒単位で計測したい場合があると思います。しかし、Management Studio でSQLを実行した際に画面右下に表示される実行時間は秒単位であるため、ミリ秒単位の計測には向いていません。そこで、簡単にSQLの実行時間を計測できるサンプルを紹介します。 DECLARE @StartTime datetime -- 処理開始時刻保存用変数 SET @StartTime = GETDATE() -- 処理開始時刻設定 /* ↓↓↓ 以下に処理時間を計測したいSQL文を書く(下記は500,000回ループを回すサンプル) */ DECLARE @Counter integer SET @Counter = 0 WHILE (@Counter < 500000) BEGIN SET @Counter = @Counter + 1
システム開発SQL Serverに別の端末(クライアント)から接続できずに何日も苦労しました。このエントリはその戦いの記録です。 接続のコード例(C#) System.Data.SqlClient.SqlConnection hConnection = new System.Data.SqlClient.SqlConnection(接続文字列); hConnection.Open(); ※接続できない場合、Openで例外が発生します。 エラー例と対処方法Case SQL Server が存在しないか、アクセスが拒否されました。 接続文字列の「Data Source」または「server」が間違っていると思われます。もしくはクライアントネットワークユーティリティのサーバ別名と一致しているか確認して下さい。 Case ユーザー 'ユーザ名' はログインできませんでした。 ここでのユーザ名は次の
./with Imagination A JavaScript, CSS, XHTML web log focusing on usability and accessibility by Dustin Diaz Wednesday, September 21st, 2005 I’ve never been one too keen Grey’s css min-height hack, mainly because of the bulky workaround in your html. Sure hacks can cause bulkier CSS, but I’m ok with that. The problem with Grey’s is that it’s not only a ‘CSS‘ hack (which I’m totally fine with), but
Achieving Rounded Corners in Internet Explorer for jQuery UI with DD_roundies jQuery UI is built upon a powerful CSS Framework, including round corners that utilize CSS3’s border-radius property. Unfortunately, CSS3 border-radius is only supported by Safari and Firefox, leaving browsers such as Internet Explorer to gracefully degrade to square corners. In many cases this is an acceptable fallback,
Once upon a time, all we needed to worry about was reducing Bytes and Requests and playing around with load order to make things faster. Nowadays, we are increasingly impacting one more major component in performance – CPU utilization. Using jQuery and other frameworks that make selecting nodes and DOM manipulation easy can have adverse affects if you’re not careful and follow some simple practice
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く