AzureのWebアプリでハマった事
Could not load file or assembly 'System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
こんな感じでアセンブリがねぇよって言われる。 web.configに
<dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly>
を追加する。oldVersionのハイフン以降とnewVersionは自分で現在参照しているアセンブリのバージョンを見て書き換えて。
Format of the initialization string does not conform to specification starting at index 0
こんな感じでよくわからん事を言われる。パブリッシュ時の「Code First Migrationsを実行する」のチェックを外そう。
閑話
なーんか、CodeFirstって……どうも肌に合わない。DB直接設計した方がどれ程早いのか、ってケースも多々ある。 まあ、慣れなんだろうなぁ。慣れたらきっと、楽ちんになる。と思う。
ただ、その「慣れたら」って部分に最近問題を感じつつある。DBの設計なんて最初しかしないし、変更は出来るだけ出ない様に配慮するから、慣れる機会があんまりないんだよ……。
なんというか、フレームワークって使いこなせば楽ちんなんだろうけれど。問題が発生した時の原因究明が酷く面倒な事があるし、慣れるまでに時間がかかるとフレームワークを使う意味が無かったりするし。 何でもかんでもフレームワークな昨今、ちょっぴりやりづらい。
さらに閑話
こういうトラブルの解決法って、日本のサイトにはあんまり無い。 いや、全く無いわけじゃないんだけど、ちょっと細かい事になると大体がStackOverflowで外人が回答してる。 うーん、なんでだろ。
出しちゃいけない情報
Stack Overflowで、DBへの接続パスを晒してる人がいた。
AWSでもこんな話が多い様だ。
割と笑い事でなく、日本のブログでもやっちゃった系体験談をどこかで見た。怖い怖い。
「オレはそんな間抜けな事しねぇし」
と思う人も多いかも知れないけど、そういう人程ミスるんじゃないかな、これ。 僕的にはGitHubにそういった機密情報を含んだアプリを公開する事自体考えられない。 機密情報だけ除外するとか、手動設定も考えられない。どこでミスるかわかんないから。
ていうか、なんでそういうものをわざわざGitHubに？ 特に個人なんかは、ローカルに普通にGitリポジトリ作ればいいと思うんだけど……。公開したいものは、ちゃんと「公開するんだ」という意識を持って別途まとめるべき。
ASP.NET MVCのテンプレートについて
プロジェクトの新規作成時、ASP.NET MVCのテンプレートが見つからない場合がある。
僕はそういうもんなのかなと勘違いをして、色々無駄足を踏んでしまった。くそう。
Visual Studio 2013のWebプロジェクト作成時にMVC 5テンプレートが選択できない場合の対処法www.lancork.net
これだけ、たったこれだけだ。 2013じゃなくて2015でも同じ。
くそう。マジで時間無駄にした……。
UnityとVisual Studioの開発における相違点
Unityを勉強していて、色々と疑問が出て来た。Visual Studioで普通のアプリをC#で開発してきた人にとっては、戸惑う部分がてんこ盛り。ものすごいプログラマなら大丈夫なのかも知れないが、僕程度のプログラマでは迷った挙げ句に一端妥協してしまう事が多い。うーん。 サンプルコードとか、開発中に気付いた事を書いてみる。
何故かvarが全然使われていない
いや、本当に理由がわからない。初心者にいきなりvar使わせるのはどうかと思うので、そういった入門とかならまあいいんだろうけれど。色々と文章や情報を調べてみても、varが本当に滅多に使われていない。理由が不明。
LINQが使われていない
これはまあ、わかりにくいからだと思われる。というか、色々な所でそんな感じの事が書いてある。良くも悪くも、UnityでC#を扱っている人は生粋のC#使いではないケースが多い様だ。あと、LINQのサポート自体もなんかバグだらけな様だし。一応、サポートするライブラリは出てはいるけれど……。
やたらとメンバ変数を活用する
プロパティにしといた方が良かったんじゃあ……。プロパティじゃあ自由度高すぎてアレだったんだろうか？ しかし、publicなメンバ変数が大量に並んですごく不安な気持ちにさせられる。というか、WindowsアプリをC#で作る時にpublicなメンバ変数なんぞ、そもそもあり得ない。何か特殊な理由がない限り、普通は全部プロパティにする。
そして、使用頻度が高くなるので命名規則が変わる。C#ではprivateなメンバ変数は「_hogehoge」みたいな最初にアンダーバーを付けるネーミングが多かった様に思う(僕だけじゃないよね？)が、そうする意味が薄れる。
名前空間をあまり使わない
使うケースももちろんあるのだろうけれど、サンプルコードとか見ると名前空間を全然使ってない。Windowsでは名前空間を使わない事の方が珍しいぐらいだが……。 しかし、Unityも開発を進めていくと、やはり名前空間による整理整頓は必須だった。なんでサンプルでこれに触れないのか、デフォルトで無しになってるのか、そこら辺の理由はわからない。
スクリプトがシーンに従属していない
UnityのシーンをVisual Studioで対応づけるのであれば、フォームになると思う。 Visual StudioではフォームはそれそのものがC#によるクラスであって、デザイナはあくまでコードの出力装置に過ぎなかった。 しかし、Unityでのシーンは完全に在り方が違う。 シーン=クラスではないし、シーンファイルはコードですらなく、バイナリだ。いじれない。 そもそも、シーンそれ自体に従属するスクリプトがないのだ。 そして、シーンがクラスでは無いという事はどういう事かというと、シーンの中に散りばめたコンポーネントがそれぞれ独立している感じなのだ。
こんな感じ。 シーンはコンポーネントを束ねる場でしかなく、コンポーネントを内包している感じではない。いや、実際は内包しているのだけども。Windows Forms程強固な関係に思えないのだ。 シーン内の何かを探したければ、一々「Find("コンポーネント名")」しなければいけない。 コンポーネントと実際のコードの紐付けを、一々手動でしなきゃいけない。 ややこしい。 下手をしたら、素人の人よりもVisual Studio経験者の方が慣れるのに時間かかるんじゃなかろうか。
うーん、なんかこう、上手く言葉に表せない。まあ、また思いついたら書こう。
……ふと書いてる途中でコンポーネントじゃなくてオブジェクトだな、と思ったけど面倒だから書き直さない。
堤抄子のマンガ
マンガ図書館Z、プレミアム登録してしまった……。
まあ、クラリオンの子供たちがPDFでゲット出来たので満足。プレミアついてて、Amazonで買ったら5000円近くするので。
しかし、もっと早く気付いていたら堤抄子のサインがもらえる機会があったのか……。あああ……もっと早く気付けば良かった。
あ、でも今読み直したらサイン色紙本物じゃなくてPDFか。じゃあまあいいや。
