Javaでプログラムを書いていたころ、プロパティは以下のように書いていた。ゲッター、セッターだ。
private string name; public string SetName(string _name) { name = _name; } public string GetName() { return name; }
けど、C#ではこんな書き方ができる。
public string Name { get; set; } = 6;
この一行で、変数Nameの初期値は6で設定し、呼び出しもできる。ただ、外部から値をセットできると色々まずいので、読み取り専用プロパティの書き方がある。
// アクセスレベルがprivate public string GevenName { get; private set; } // getアクセサーのみ public string Name => FamilyName + " " + GivenName;
よし、プロパティ完璧に理解した。
よくif文使いがちだが、if文は簡単だし、分かりやすい反面、たしかに行数は多くなる。
var list = new List<int> { 1, 2, 3, 4, 5, }; var key = 2; int num; if (list.Contains(key)) { num = 1; else num = 2;
リストに2が含まれていたら変数numに1を、リストに2が含まれていなければ変数numに2を代入するコードを書くだけで、7行も必要になる。
けど、条件演算子を支えばもっと楽に書けるよというものである。
var nums = new List<int> { 1, 2, 3, 4, 5 }; var key = 2; var num = nums.Contains(key) ? 1 : 2;
条件演算子を使えば、3行で書けた。けど、慣れないとこの条件演算子の書式がかなりややこしい。。上の式でいうと、trueなら1、falseなら2を返している。
続いて、null合体演算子だ。
ヌルポを防ぐコードだと、一般的にはこう書くと思う。
var message = GetMessage(); if (message == null) message = "Default";
そう、if文で変数messageがnullかどうか、チェックしている。これも、null合体演算子を使えば楽に書ける。
var message = GetMessage() ?? "Default";
上のコードだと、GetMessage()がnullなら、??以降に書かれた戻り値を変数messageに代入する。
nullかどうか判断するコードで、null条件演算子というのもある。
これは、プロパティを持つオブジェクトのnullチェックで効力を発揮する。
return sale?.Product;
sale変数がnullの場合はnullを戻り値として返すが、sale変数がnullではない場合、sale.Productプロパティを返すというもの。
どれも、たしかに簡単に書けるけど、いざ書こうとすると多分if文で書いちゃうんだろうな。。条件演算子とnull合体演算子、完璧に理解した。
C#の特徴でもあるLINQ to Objects。自分の中では、C#でSQLの構文が使えるイメージでいる。それは、LINQに用意されているメソッドが、「Where」、「Select」などクエリ演算子と呼ぶからだ。
var list = new List<string> { "Tyokyo", "New Delhi", "Bangkok", "London", "Paris", "Berlin", "Canberra", "Honkong" }; // 文字列の長さが5以上の要素を抽出 IEnumerable<string> query = list.Where(s => s.Length <= 5);
このコードを見ると、List
List<string> names = list.FindAll(s => s.Length <= 5);
どちらも簡単な書式だし、ラムダ式を使っているし、わざわざLINGを使うメリットって何なのかというと、ここで使ったWhereメソッドはIEnuberable
// 配列でも使用できる var array = new string[] { "Tyokyo", "New Delhi", "Bangkok", "London", "Paris", "Berlin", "Canberra", "Honkong" }; IEnumerable<string> query = array.Where(s => s.Length <= 5);
反対に、FindAllクラスはList
var list = new string[] { "Tyokyo", "New Delhi", "Bangkok", "London", "Paris", "Berlin", "Canberra", "Honkong" }; // コンパイルエラーになる var names = list.FindAll(s => s.Length <= 5);
型によって、メソッドを変えるのが面倒なので、LINQを使った方が便利。また、Whereメソッドの戻り値がIEnumerable型なので、こんな書き方もできる。
var array = new string[] { "Tyokyo", "New Delhi", "Bangkok", "London", "Paris", "Berlin", "Canberra", "Honkong" }; // 元々はArray型だったものを、List型にキャストしている List<string> query = (List<string>)array.Where(s => s.Length <= 5);
インタフェースでやりとりできると、色々便利だ。
LINQのメリットはこれだけじゃないと思うけど、自分の中の理解としてはこんな感じ。
ということで、LINQ to Objects完璧に理解した。
何度も勉強しているが、すぐに忘れて使えなくなるのがラムダ式。ということで、何度も何度も勉強し直しています。
正直に言うと、「ラムダ式とは何ですか？」と聞かれてもうまく説明できる自身がない。自分の中の理解としては、ラムダ式はPredicateデリゲート型に変換できるため、Predicateデリゲート型を引数にもつ匿名メソッドに使用できる。
よって、引数に様々な条件を簡単な記述で渡せれるというのが、自分の中でのラムダ式というイメージ。
// Predicateデリゲート型変数matchに、ラムダ式を代入 Predicate<string> match = (string s) => { if (s[0] == 'A') return true; else return false; }; // 上で定義したPredicateデリゲート型変数matchを、Exixtsメソッドに代入 Console.WriteLine(list.Exists(match));
これが、Predicateデリゲート型を引数に持つメソッドに、ラムダ式を使った変数を渡しているコードだ。
けど、これじゃあ書き方が助長なので、簡素化したものがこちら。
Console.WriteLine(list.Exists(s => s[0] == 'A'));
さっきのコードと同じ結果が得られるから、こっちの書き方の方が簡単。けど、慣れないとこのコードが読めない。
自分は、=>の右側に条件を記載するものとして覚えた。=>の左側は、List
こんなざっくり理解でも、一応ラムダ式使えているのでOKとする。ラムダ式、完璧に理解した。
何事も飽きっぽい性分なのだが、例に漏れずブログ更新も飽きてしまっていた。「100記事書けばアクセスが増える」、「200記事書けばアクセスが増える」、「300記事書けばアクセスが増える」とネットの情報につられて、一時期は毎日更新してたどり着いた結論が
「どんなに書いてもアクセスが増えない！！」
だった。というのも、アクセスが増えるような高クオリティーの記事を300記事書いて初めてアクセスが増えるのであって、何も考えずにただ書いただけの300記事ではアクセスが増えるわけではない。元々その事実に気づいてはいたが、結果をつきつけられて一気にブログを更新する気力がなくなってしまった。
そもそもブログを始めた動機は、「ブログを書けば月に５万円ほど小遣いを稼げそう」というもので、ブログ更新そのものに目的を置いていないため、ブログ更新のその先が何もないとやる気を失ってしまうのは当然だ。ここで自分の意見を書いておくと、「ブログで収益を出すのは死ぬほど大変」ということ。当たり前だが、ブログで収益を得るためには「面白い記事」という結果が求められる。しかも、コンスタンスに。
こう考えると、失敗しても給料が毎月いただけるサラリーマンという職業は、素晴らしいと実感する。
と、約500文字かけてブログを放置するに至った経緯をまとめたのが、この記事で言いたいのは、そんな放置していたブログが急にアクセスが増えてきているというタイトルそのまんまのこと。
これまで、月平均500アクセスから700アクセス程度だったのだが、月に2000アクセスまで伸びてきた。最近、ブログ更新していないのに！
人間、結果が出るとやる気が出るというもの。もちろん、収益に繋がるほどのアクセスではないが、変化が目に見えることが嬉しい。
ということで、今この記事を更新するに至ったわけだが、やはり大事なのはクオリティーが低くても300記事を更新したという事実。となると、このまま10年くらいブログを更新し続けて、記事が3000記事くらいになればアクセスも月に20000アクセスぐらいになるのでは？と考える。（もちろん、そう単純ではないのだが。。。）そこで大事になってくるのが、継続力だ。
冒頭で飽きっぽいと自己分析をしているぐらいだから、継続力が圧倒的に足りていないのは重々承知している。だからこそ、継続させるための工夫をこらす必要がある。
そこで、ブログを続けることで得られるメリットを考えてみた。
考えついたのが、この4点。分析をすると、「1、2は自分に利益があるメリット」、「3、4は自分の承認欲求が満たされるメリット」だと考える。
1は達成する難易度が高い、2は結果がわかりづらい（文章力があがったことを実感じづらい）が、3、4ははてなブログのアクセス数や、スター機能で結果が分かりやすいし、今もアクセスが増えたり、スターもたまにいただいているので難易度としてもそこまで高くない。
とすると、ブログを継続する意味はあると考える。自分の場合は、「やらなくてはならないこと」と頭で認識してしまうと一気にやる気が削がれる。
だからこそ、これらメリットを十分に意識しつつ、さらには「ブログを書くのが楽しい」という、行為そのものを目的化させないと何事も続かないと思う。（そうなるまでが、大変だが。。）
ということで、これからもゆるーくブログ更新していきます。
突然ですが、急にF1にハマりだした。
これまで車関係に全く興味がなく、何なら周りにF1好きがかなりいたのにも関わらずだ。
きっかけとしては、Netflix制作のF1のドキュメンタリー。これはね、俺みたいな素人にもF1の魅力が伝わるように作られてるからホントおすすめです。
で、F1の2020シーズンを楽しみに待っていたら、まさかの新型コロナウィルスにより第1戦目のオランダグランプリが延期。。で、2戦目以降も延期の連続で、4月になってもシーズン開始の目処が立っていないとか。
見たいのに見れないとなると、さらに興味は湧いてきたんで、こんな本を買った。
全くの素人には内容ちょい難しめやけど、これまた面白い。レーサーではなく、エンジニア視点からF1の面白さが語られてるところが、たまりません。
と、F1の興味が高まりまくったところで、F1のゲームを購入。もともとレースゲームはかなり不得意というか、ほぼやったことなく飽きる可能性があるので、ソフトは中古でF1 2017にした。F1 2019でもよかったんやけどね。
さっそくゲームを始めたんやけど、このゲームはチュートリアルが無いのに、操作方法がよくわからん。というか、F1マシンの細かな設定が色々できるんやろうけど、専門用語が多すぎて、何をどうしていいかわからん。
これは、ゲームで練習しつつ、F1のことも勉強してかなあかん。。ということで、勉強した内容はこのブログに書き留めていく。
あと、自分がどれだけ上手くなっているか確かめるためにも、レースの様子をYouTubeにアップしていくことにした。
#1【F1_2017】レースゲーム初心者がワールドチャンピオンを目指す
順調にうまくなっていったら、ハンコンも購入しようかな。
// 配列の生成 var chars = new char[] { 'P', 'r', 'o', 'g', 'r', 'a', 'm', }; // 文字配列から文字列の生成 var str = new string(chars);
C#では、数値を文字列に変換する方法が、「ToStringメソッド」と「String.Formatメソッド」の2通りある。しかし、ToStringメソッドには色々制限があるため、基本的にはString.Formatメソッドを使うのがよい。
int number = 12345; // 文字列変換 Console.WriteLine(string.Format("{0}", number));
この場合も、string.Formatメソッドを使う。
string familyName = "yamada"; string lastName = "taro"; Console.WriteLine("FamilyaName={0}; LastName={1}", familyName, lastName);
