Remember The Time

Google Apps を採用し、仕事上も Gmail を使うということも多くなってきた（個人的な印象では、企業の採用率は Office 365 と半々くらいのイメージ）。Gmail を仕事で使う場合、注意しなければならないことがいくつかあると感じた。 スレッド表示を止める メールを仕事で使うと、返信を繰り返すケースがよくあるのだが、Gmail の初期設定ではスレッド表示になっており、一つの話題がまとまってすっきりする反面、相手からの新着メールを読み漏らすリスクがかなり高まると感じた。 スレッド表示の解除 設定（歯車のアイコン）ボタンをクリック。 [ 全般 ] タブの、スレッド表示を「スレッド OFF」にする。 一番下の [ 設定を保存 ] ボタンを押下して保存 。 受信トレイとすべてのメール Gmail では、メールはいったん受信トレイに入る。そして、表示させる必要がないメールは「アーカイブ」すると、受信トレイから消える。 アーカイブしたメールは、すべてのメールに移動される。 個人的には、 受信トレイのメールがすべてアーカイブされたらその日の業務は終了 、というメール術を実践している。 メール誤配信防止 Chrome 限定なのだが、 Gmail Address Checker という拡張機能がある。これはウェブ上の Gmail から、メール送信時に送信先とタイトルのチェックを促す。 アプリ感覚で使う タスクバーにショートカットアイコンを作成すると、単独のアプリのように Gmail を使える。 Chrome 設定 -> その他のツール -> アプリケーションのショートカットを作成 Internet Explorer アドレスバーのアイコンをそのままタスクバーにドラッグしてショートカットを作成 設定 -> スタートメニューにサイトを追加

ログ出力等で、実行中のクラス名やメソッド名の取得をしたい場合は以下の通り。クラス名は this で簡単に取得でき、メソッド名は Reflection で参照する。 C# // クラス名 string className = this.ToString(); // メソッド名 string MethodName = System.Reflection.MethodBase.GetCurrentMethod().Name; VB.NET ' クラス名 Dim className = Me.ToString ' メソッド名 Dim MethodName = System.Reflection.MethodBase.GetCurrentMethod().Name

iOS も iPad で使っていたのだが、携帯も iPhone に変更したので独断と偏見をメモ。 比較対象 Android 2.2, Android 4.0 (GALAXY S II LTE SC-03D) iOS 6 (iPad 3), iOS 7(iPad 3), iOS 8 (iPad 3, iPhone 6 Plus) iPhone に向いている人 スペックは気にせず、iPhone がいいと思った人。 シンプルな操作性が好きな人や初心者。 アクセサリー（カバーとか）にこだわりたい人。 モノに愛着を持つ人。 しかし、電話としての機能と日本語入力に関しては、現時点では iPhone は圧倒的に Android に負けている（英語しかタイプしない人は関係ない）。あと、落とすとすぐ壊れるのは iPhone。 Android に向いている人 いろいろな端末から選びたい人。 スペックや機能を重視する人（おサイフ携帯やワンセグなど）。 設定のカスタマイズが好きな人。 iPhone が嫌いな人w アクセサリーやサードパーティ製品の対応度合いは圧倒的に Android の負け（厳密には別に Android が負けているわけではないが……）。 以下、それぞれ思ったこと。 ハードウェア Android は端末によってボタンの位置が違いすぎるのが気になる。多数のメーカーが端末を出しているのでしかたがないのだが。 iPhone はそれとは逆。 また、ハードウェアにもよるのかもしれないが、タッチの感度に関しては iPhone の方が優れていると思う。文字入力時のタッチに関しては Android はよく入力ミスがあったが、iPhone に変えてからあまりないからだ。 操作性 常にワンボタンで戻るを繰り返す iPhone に比べ、Android は戻るボタンやホームボタンが下に配置されているため、操作性は Android の方が好ましいと感じる。 そして、特に日本語入力（キーボード）に関しては iPhone は大きく劣っている。英語圏では気にならないのだろうが、日本語入力環境では矢印キーがないのは致命的（画面を横にすると出てくるが）。 アプリ ほぼ差はないが、やはり iPhone にしかないアプリが存在する。...

MS 系の開発をしているのであれば、ソース管理といえば現在は TFS が主流かもしれないが、VSS も未だに残っていたりする。そんな現場が Git を使いはじめると、たいてい失敗する。それは、仕組みそのものが全く違うにもかかわらず感覚で使おうとするからだ（Git そのものがダメなわけではない）。 Git は高度なことも可能だが、最低限以下を抑えれば、それほど問題にはならないはず。 Git のコミット Git のイメージ Git では、コミットは「ローカル」のリポジトリに対して行う。 他の人が修正内容を取れるようにするためには「プッシュ」を行う。 他の人のソースを取りたいときは「プル」を行う。 注意しなければならないのは、競合が発生した場合はプッシュやプルができない。ただ、ビルドエラーは起こっても大丈夫だったりするw リベースとマージ 修正内容を反映させたいときに出てくるのが、リベースという単語。よく聞きなれたマージという言葉もあり、結果そのものは同じことになるので違いは何だろうと思ってしまうのだが、実はわりと別のことだったりする。 リベース 対象となる修正内容を飲み込んで取り込む。 マージ 対象となる修正内容の差分のみ取り込む。 わかりづらい部分だが、上記の例だと、左側の青い丸がリベースを繰り返した場合。マージを行うと、赤紫の変更分が develop に取り込まれ、新しくマージコミットが作られた後、master に統合されている。 マージを繰り返すと、マージされたそれ自体がどんどん蓄積されていくので枝が広がっていきわかりづらくなっていく（逆に細かい変更を指定しながらリリース・ブランチを作りたいときなどは便利）。 リベースを繰り返すのは、TFS などに近い動きになる。 スタッシュ TFS でいうところのシェルブである。スタッシュを行うと変更点がすべて退避され、変更前の状態に戻る。 SourceTree だと、なぜか新しく追加したファイルが差分として残ってしまう…。 ルール作りが必要 Git のソース管理は、チーム内で一定のルール作りをしてから初めないと、失敗する気がする。ここで言う失敗というのはデグレも含まれるので注意が必要ではないかと思っている。 TFS などはそういう細かいこと（ブランチがグチ...

bool 型の値の中身に関わらず、true/false を一発で逆転したい場合は以下のように書く。 C# bool hoge = true; // false hoge = !hoge; これはラジオボタン等でも同様に使える。 CheckBox1.Checked = true; RadioButton1.Checked = true; // 逆転 CheckBox1.Checked = !CheckBox1.Checked; RadioButton1.Checked = !RadioButton1.Checked; 覚えておくと便利な小技。ちなみに VB.NET の場合は以下のとおり。 VB.NET CheckBox1.Checked = True RadioButton1.Checked = True ' False になる。 CheckBox1.Checked = Not (CheckBox1.Checked) RadioButton1.Checked = Not (RadioButton1.Checked) Not を使う。

メッセージ 8155、レベル 16、状態 2、行 38 'hoge' の列 1 に列名が指定されませんでした。 このエラーメッセージは、集計関数の別名を指定せずに他のテーブルと JOIN で結合を私用とした際のものである。外部結合をさせる際には AS で列名を指定しないと結合できない。 上記の例だと、hoge テーブルの列 1 に対して列名が指定されていません、ということだ。

メソッドの中には、イミディエイトウィンドウで実行できないものもある。例えば自身のメソッドをリフレクションを使って取得する、以下のようなメソッドを実行すると、System.ArgumentException 例外をスローする。 System.Reflection.MethodBase.GetCurrentMethod().Name コード内では問題なく実行できる。

ASP.NET において、runat="server" に設定した HTML 要素は、C# のコードビハインドで制御できるようになる。 しかし、あらかじめ style="display:none;" に設定されている Div 要素を表示させたい場合は、div.Visible = true; としても表示されない（div は id）。これは display:none; と Visible は異なるものであるからだ。 コード上から display を変更したい場合は、以下のように書く。 div.Attributes.Add("style", "display:block"); Attributes に Style を設定することで、他の様々な Style も適用させることができる。

ドロップダウンリストの Value に、指定した値が存在するかチェックを行う場合のメモ。 存在する場合は、ListItem 型として値が返却される。 C# if (DropDownList1.Items.FindByValue("Hoge") != null) { // あります } VB.NET If DropDownList1.Items.FindByValue("Hoge") IsNot Nothing Then ' 存在します。 End If ドロップダウンリストになかったら追加する、みたいな処理で使えるだろう。 FindByValue を FindByText にすると、Text の方でチェックを行える。

Windows 環境の GUI クライアントツールはいくつかあるが、SourceTree と SmartGit を使ってみた際の使用感のメモ。 SourceTree スタンドアローンで動作する、Atlassian 社のクライアントツール。直感的な操作で Git を使うことができる。ユーザーは多いと思う。 メリット 日本語対応（完全にローカライズされているわけではないが）。 フリー。 操作が直感的。 デメリット エラーは英語。ソースの差分が文字化けする。 除外したいファイルを設定しても無視されたりしてよくわからん。 タグやブランチ、管理するファイルが多くなってくると動作が重い。 SmartGit こちらもスタンドアロン型クライアントツール。英語版のみだが、動作の軽さと合理的な画面デザインがわかりやすい。 メリット 動作が軽い。 一画面で見渡せるつくり。ソースの差分がわかりやすい。 メニュー等は英語だが、中のコメント等に日本語が含まれていても文字化けしない。 デメリット 個人ユーザーは無償だが、業務用途では有償。 日本語でないのは、やはり抵抗がある人が多いと思う。 個人的には、完全日本語対応がされたら SmartGit が軽くて好きだが、SourceTree は直感的な見やすさがあるのでもう少し動画軽くなって欲しいところだ。 SourceTree https://www.atlassian.com/ja/software/sourcetree/overview SmartGit http://www.syntevo.com/smartgit/

コーディングに最適なフォントとして挙げられる Ricty（リクティ） だが、.ttf はライセンスの都合上により配布できないそうだ。だから、自分で生成しなければならない。 しかし、Ricty Diminished という姉妹フォントなら、.ttf 版（TrueType）がダウンロードできる。漢字の種類が若干少ないようだが、コーディング用なら実用上の問題はないと思う。 Ricty Diminished https://github.com/edihbrandon/RictyDiminished

ちょっとメンテナンスをしたいとき用のテンプレート。 USE HogDb BEGIN TRANSACTION -- なんか適当な処理 -- COMMIT TRANSACTION -- ROLLBACK TRANSACTION トランザクションを張る際、個人的なこだわりポイント。 USE で対象データベースを明示的に把握しておくこと。 Management Studio のツールチップ部分に表示されている接続先だけだと、どうしても漏れる。実行時に明示的に示すことで想定外の DB への更新を避ける。 COMMIT, ROLLBACK は必ず結果を見てから流せるように、コメントアウトしておく。間違って全部実行した際にコミットされてしまっていたら、トランザクションを張った意味がなくなってしまう。 BEGIN TRANSACTION (Transact-SQL) https://msdn.microsoft.com/ja-jp/library/ms188929.aspx

SQL Server で、UPDATE 時の更新値を CASE で分岐させたい場合。 -- CASE 文は他の書き方でも良い。 UPDATE Hoge SET Point = CASE WHEN (NowPoint - @GetPoint) >= 0 THEN NowPoint - @GetPoint ELSE 0 END WHERE Cd = @Cd 簡単な更新であればこの通りでも良いと思うのだが、大量のデータをこうやって分岐させながら更新するのは経験上パフォーマンスが悪いように思う。 テーブル設計にもよるが、条件を分け複数回の UPDATE の方が速かったりすることもあるので、書けるからといって何でもこういう書き方で実装ししてしまうのは危険だ。