２０階建てで一階あたり２０室あるホテルで以下のルールで部屋番号を設定すると、最大になるのは何号室？
１．部屋連番。例：１階の最初の部屋は１号室
２．4と9のついた数字を飛ばす。
解答：
10あたりの飛ばさない数は
12356780
となり、8個となる。
100までに飛ばさない数は上記の8個*10となるが、40番台と90番台は飛ばすので、
8*8=64個
となる。
400を64で割ると、400/64=6あまり16
つまり、6回100の位が変化する。
そして、400番台は全て飛ばすので、６回変化するという事で700番台となる。
そして先ほどのあまりの16までに、登場する抜け番は
10あたりの飛ばさない数は前述の通り8個なので
16/8で2あまり無しとなり、
720番が最大となる。
よって最大の部屋番号は720号室となる。
前にも少し書いたような気がするんだけど、iPhoneでWebブラウジングをするのに慣れてしまうと、PCでブラウジングする時に、本文以外の部分が目障りになってくる。
どういうことかというと、
iPhoneのWebブラウザはダブルタップでそのdivの領域の横幅が画面いっぱいになるようにズームしてくれる。
そのため、本文だけを表示して読み進める事ができる。
実際、ダブルタップでズームしないと細かくて読めないからなんだけど、副作用として本文以外が表示されないので、意識を他のものに削がれる事なく読み進める事ができる。
その半面、PCでブラウズしようとすると、ズームする必要がないし、iPhoneみたいにいい感じなズームが実装されているわけではないから、どうしても本文以外の部分も一緒に表示する事になる。
今まではあまり気にしてなかったんだけど、最近、この「本文以外の部分」がちょっと目障りに感じるようになってきた。
ということ。
とはいえ、PCのブラウザにいい感じなズームが実装されても使わないと思うけど。
フォームに貼り付けたコントロールのValidatingイベントハンドラ内で
if(!this.CauseValidation && this.ActiveControl == 元のコントロール) { return; } if (!this.ActiveControl.CausesValidation) { return; }
とする。
×ボタンで閉じる時は、元のコントロールがアクティブなままなので、ActiveControlが元のコントロールだったら抜ける。
本来、ActiveControlのCauseValidationがfalseの時は、Validatingイベントが発生しないはずなので、Validatingイベント内で、ActiveControlのCauseValidationがfalseである事を確認したらreturnで抜ける。
カスタムコントロールの実装時には、OnValidatingをオーバライドして、base.OnVvalidating()を呼ぶまえに
System.Windows.Forms.Control 親コントロール = this.Parent; while (親コントロール != null) { if (親コントロール is System.Windows.Forms.Form) { if (親コントロール.CausesValidation) { break; } if ((親コントロール as System.Windows.Forms.Form).ActiveControl == this) { return; } if (!(親コントロール as System.Windows.Forms.Form).ActiveControl.CausesValidation) { return; } } 親コントロール= 親コントロール.Parent; }
とする。
基本的には、フォームに貼り付けた場合と同じで、追加された実装はFormコントロールを見つけるまで親を遡る事。
JailBreakを行うということは、規約に違反した行為です。
つまり、ユーザがSoftBank及びAppleに対して契約違反を侵したという事になります。
しかし、契約違反はこれだけではありません。
もし、SoftBank及びAppleがJailBreakユーザに対して何のアクションも取らなかった場合、SoftBank及びAppleは正規利用ユーザに対して契約違反を侵しているという事になります。
SoftBank及びAppleは規約によって、正規利用ユーザのみが3G回線を利用できるという環境を約束している事になるからです。
つまり、規約で縛るという事は、正規ユーザに対しても、「規約で縛られた以外のユーザ」が存在しないことを約束しているという事なのです。
JailBreakユーザ→契約違反→SoftBank及びApple
SoftBank及びApple→契約違反→正規利用ユーザ
というわけで、SoftBank及びAppleのJailBreakユーザに対する今後の姿勢を興味深く見守ろうと思います。
まぁ何もしない気がするけれど。
私としては、別に、JailBreakユーザがいてもいなくても、どっちでも良いし、「勝手にやってれば」という感じです。
まぁ、規約を守れないのによく契約するもんだと、その神経に感心してはいますが。
たまにAppStoreで販売しているソフトウェアを不正利用する方法を公開しているブログがあったりすると、正直腹立たしいですね。
あとは、テザリングは正式に認められるまではするべきでは無いと思います。
プロジェクトの過程でコーディング規約を決める。その後はシステムが運用に辿り着くまで変更しない。
このような環境が多数派だと思う。
しかし現実はミスマッチとか想定外な事が少なからずあり、コーディング規約を逸脱した例外的なものが許容される事がある。その割にコーディング規約に明文化されることはなく、あくまで例外という名の運用でカバーという奴だ。もしくは、無理矢理コーディング規約に則るために、最適ではないコーディングになっていることもある。
確かに一度決めたことを変更するのは勇気がいる。もしこはそもそも、変更しようという概念自体が無いかもしれない。
だが、ルールは適用するためにあるのではなく、円滑なプロジェクト運営や保守を行うためにある。だから、コーディング規約に、こんな文章の追加をお勧めする。
「このコーディング規約は変更可能である。このコーディング規約に定義された内容を逸脱する必要がある場合、このプロジェクトにミスマッチな場合は責任者に相談しコーディング規約が変更されるのを待ってからコーディングを行うこと。また、レビューによって指摘された内容がコーディング規約に定義されていない時は速やかに規約に追記する。」
