【VisualStudio】デザインとコードのバインド
年忘れに一記事。
現在開発に携わっているシステムはサーバー側をJava(eclipse)、クライアント側をC#(Visual Studio)で開発している。
新規にチェックボックスを設置し、その入力値をもとに検索をかける、という追加開発中にエラーが。
「DataSource のプロパティまたは列 ●● にバインドできません」
ほう。
内容としては、エラーメッセージが示すとおり、用意した変数（クライアントからサーバーへ渡すために用意したもの）と画面項目（チェックボックス）が紐づいていないために画面描画ができません、というもの。
この画面を開こうとする時点でエクセプションをはいてしまう。
所属するチームでは、データテーブルを管理するプロジェクトと、画面項目の管理を行うプロジェクトを別に管理している。
行った修正は
①データテーブル管理プロジェクトのxsdの該当データテーブルへの項目追加
②画面項目管理プロジェクトのdesigner.csに表示位置や初期値を設定
の大きく二点。
大きな改修でもなく、すでにあるコードをコピペしつつ必要な箇所のみ独自に修正していくだけだったので大きな問題なぞ起こらないと思っていたらこれである。
対処方法は以下。
画面項目管理プロジェクトのデザインを開いて追加した要素をクリック。
選択するとこのようなラインで囲まれるはず。
この状態でプロパティを確認。
この(DataBindings)という項目がデータテーブルと画面デザインの紐づけを管理している。
今回追加したのはチェックボックスだったので「Checked」という項目に、紐づけるべきデータテーブルとその項目名が表示されるのだが…
ぱっと見紐づけがされているのだが、「Checked」に右にあるセルをクリックし、プルダウンを開くと
この「バインド先のBindingSourceを選択してください」の部分に「バインドされていません」というメッセージが表示される…
はあ？
じゃあプルダウン開かなくても、紐付け「(なし)」って表示しておいてよう！
てっきり紐づけされてると思ってたやんけ！
ここでデータソースを選択して、対象の項目をクリックすると紐づけ完了。簡単。
あとはクリーン→ビルドで、自動生成でほかのファイルのプロパティも変更してくれる。
初めてのVisual Studio、初めてのC#ということもあり苦戦したのだが、終わってみればどうということはない。
むしろ超簡単。
きっと一生忘れない。
この経験を通して、すこしC#、VSも理解できてきたように感じる。
にしても、VSのパフォーマンスが悪くてまあしょっちゅうPCが固まるのだがなんとかならないかなー
eclipseと同時に起動してるとビジー状態になり、ビルドが全然進まない。全然進まない。ヘイトが溜まっていく一方だ…
これは年明けの課題としましょう。
それでは。
AWSを知らないエンジニアが基礎から学ぶために使用したサイトや記事など
自分で勉強する前の知識とか使ったことのあるサービスとか
・AWSはプロジェクトで使ってるけどインフラエンジニアがすべて見てくれているのでどんなサービスがあるかよくわからない
・EC2っていうのがインスタンス（いわゆるサーバー）管理、プロジェクトの画像などのリソースを管理していたのがS3（ストレージ）、RDSがデータベースのマスターとスレーブを管理しているというくらいの認識
・オートスケーリングというインスタンス数の管理をしてくれる仕組みがあるのは知っている
・RedisやSQSを使用するためのコードは書いたことがあるけど設定の仕方はわからない
・ClowdWatchとかCloudFrontとか聞いたことがあるけど、それで何をしているのかは知らない
後輩くんが「パイセンー、AWSを勉強するときにどういうサイト参考にしました？」と言うので自分のためにもまとめてみた。
参考にした記事やスライドなど
・知識について
インフラに関しては苦手意識が強かったですが、そんな初心者にも最低限知っておくべき知識が書いてあって端的なのでわかりやすいし読みやすい。
なんとなくAWSってどんなものかがわかる。
AWSの中の人が書いたスライド。たくさん情報があるけど資料が読みやすいおかげで、AWSの知識を概要だけ仕入れた人間でも理解を深めることができる。
サービスの仕組みについての図解が細かく、使用料金についても記述がある。
Hiroshi Takayama presentations | SlideShare
中の人は優しいので他にもAWSに関するスライドをアップしてくださっている。読んでおくとよいかもしれない。
全サービスをなんとなく理解するにはよいかも。
・実際にAWSを動かしてみる
ユーザー登録はそんなに難しくないから自分でやってね！カード情報が必要だよ！
この方には足を向けて寝られない。↑の概要も含めると全6回に渡って、AWSとはなんぞや？というところから冗長化まで操作・解説してくださっている。
ユーザー作ったけど何からやったらいいんだよー、というときはこれを順にやっていくことをおすすめする。徐々に身についてきて成長を実感できる。
すごい。
ちなみに、全6回の内容は以下の通り。
①概要
②VPC
③EC2
④ELB
⑤RDS
⑥AMI
このアルファベットと数字の3文字ばっかり並んでてなにがなんやら、でも徐々にわかってくる。
これもやっておこう。
・身についてきたら、運用担当者になったら読むとよいかも
Amazon Web Services Japan presentations channel
SlideShareのAWSJapanの公式アカウントに膨大な量のスライドがあるので、目的に合わせて読んでみると良いかも。
・困ったら
公式のドキュメントを読む。
ユーザーの記事は古くなるが公式のドキュメントは常に最新。コンソールのUIやなんらかの機能を作成する際の手順だって数年前と現在では変わっている。ようわからんなーと思ったら記事やブログを参考にしつつ公式の該当ページを読もう。
例：
・そのほか
教訓のほかにこういうのもやってみたよー、という欄があるので、そこを参考に次に度のサービスを動かしてみるかの参考にさせてもらった。
請求アラートの設定は上記や下記の記事を参考にした。お金は大事。
やってみて楽しかったこと。
S3に画像をアップロードしたらLambdaを通じてSlackに通知を送る - 備忘録
以上。
まだまだ知識は浅いので今後もお勉強は続く。
Javaフレームワークリンクまとめ
Spring Framework(すぷりんぐふれーむわーく)ー2002～
・アプリケーションフレームワーク
・テストしやすい→Spring MVC Testというテストプログラム
・独立性→拡張しやすい、外部のフレームワークも取り入れやすい
・保守性が高い
・再利用性が高い
・新しい機能を積極的に取り入れる
Spring Framework | TECHSCORE(テックスコア)
・動かしてみる
Struts(すとらっつ)ー2000～
・アプリケーションフレームワーク
・シンプル
・国際化対応が容易
・自由度が高い
・DBにアクセスする仕組みがない
・脆弱性がある
・動かしてみる
Strutsを使うWebアプリケーション構築術（1）：フレームワーク・プログラミングの準備 (1/2) - ＠IT
Wicket(うぃけっと)ー2005～
・アプリケーションフレームワーク
・Apacheが開発
・JavaとHTMLだけでの開発を目指す
・Ajaxが使用しやすい
・動かしてみる
Wicketでオブジェクト指向を楽しみながらWebアプリケーションを作る - 技術ブログ | 株式会社クラウディア
Play Framework(ぷれいふれーむわーく)ー2007～
・アプリケーションフレームワーク
・非同期で行われていることが前提
・軽量
・生産性が高い
・Java、Scalaで動く→謳っているもののだいぶScala推し
・独自のテンプレートエンジン→Groovy
Play Frameworkについてざっくり説明する | anopara
Dropwizard(どろっぷうぃざーど)ー2014～
・デプロイ時にjarにパッケージングするので楽
・学習コストが低め
・ドキュメントが少ない
・動かしてみる
Spark Framework(すぱーくふれーむわーく)ー2013～
(2017/05/18
コメントよりSparkとApache Sparkが混在しているとご指摘を受けましたのでApache Sparkの関連リンクを削除しました)
・マイクロフレームワーク
・RubyのアプリケーションフレームワークであるSinatra(しなとら)と似ている
・動かしてみる
Junit(じぇーゆにっと)
・テストフレームワーク→eclipseに標準で入っていることもある
・バグ修正が早くなることでプロジェクト全体の作業効率をあげるのが目的
・動かしてみる
PHPフレームワークリンクまとめ
CakePHP(けーくぴーえいちぴー)ー2005～
・機能性が高い
・利用者が多い
・無料
・ユーザーが多い→学習しやすい
・日本で人気
・Ruby on Railsの影響を受ける
・動かしてみる
Zend Framework(ぜんどふれーむわーく)ー2007～
・PHPを開発したZend Technologiesが開発
・シンプル
・柔軟→拡張しやすい
・高速
・技術パートナーにMicrosoft、IBM、Google→信頼感
・動かしてみる
Symfony(しんふぉにー)ー2007～
・互換性がある
・Mojavi(もはび、もじゃび)から派生
・Ruby on Railsの影響を受ける
・動かしてみる
Laravel(ららべる)ー2011～
・低速
・Symfonyを利用している
・開発者は.NETの中の人（個人プロジェクト）
・柔軟→拡張しやすい
・テストしやすい
・速度重視版Laravelもある→Lumen(るーめん)
・海外で人気
・動かしてみる
CodeIgniter(こーどいぐないたー)ー2006～
・高速
・規約が緩い
・シンプル
・導入しやすい
・学習コストが低い
Codeigniterをはじめる時にまず読んで欲しい記事10選 – rdlabo.inc｜リレーションデザイン研究所
PHP初心者の私がCodeIgniterを勉強して感じた4つのメリット、2つのデメリット | 株式会社アルベ | Arubeh Inc.
Phalcon(ふぁるこん)ー2013～
・高速→CodeIgniterの1.5倍から2倍
・省メモリ
・柔軟
・規約が緩い
・専用のテンプレートエンジンを内蔵→Volt(ぼると)
・途中から導入する場合に再起動が必要
・C言語で開発
FuelPHP(ひゅーえるぴーえいちぴー)ー2011～
・高速
・規約が緩い
・CodeIgniter関係者が開発
・学習コストが低い
http://www.buildinsider.net/web/bookphplib100/096
Flight(ふらいと)ー2013～
・独立性が高い
・計量
・Twitterが開発
・MVCではなくVC
・テストしやすい
・動かしてみる
Silex(さいれっくす)ー2011～
・Symfony開発者が開発
・シンプル
・動かしてみる
BEAR(べあ)ー2011～
・日本製
・動かしてみる
Kohana(こはな)ー2007～
・CodeIgniterから派生
・軽量
・高速
・動かしてみる
Ethna(えすな)ー2011～
・フォームが特徴
・日本人が開発
Ice Framework(あいすふれーむわーく)ー2014～
・高速
SQSを動かしてみる
以前のプロジェクトでSQSで非同期でDB更新を行う処理を入れていたためになじみがあったので動かしてみる。
①AWSコンソールの「Simple Queue Service」からキューの作成
設定はこんな感じ。
②メッセージを設定。
「メッセージの送信」を選択してメッセージを作る。
（適当に）メッセージを作るよ。送信できていることがわかればいいのでゆるくいくよ！
送信！
③キューを送る。
「キューの表示/削除」を選択してメッセージを送ってみる。
ポーリングスタート！
75秒遅延にしたので、すぐポーリングしてもメッセージは来ない。
100％になっても空っぽのままになる。
もう一回ポーリングスタート！
きたー！
時間もちゃんと75秒以上差がありますね。
動作確認は終了！
aws-shellから設定する方法もあるみたいですが、コマンド叩くの嫌いマンなのでひとまずこのまま……（インストールだけした）
停止させていたEC2インスタンスを起動させる
この頃、AWSのいろいろサービスを試してみようと勉強を進めているわけですが、無料範囲内で行うことを第一にしているので、請求が来るリスクを減らしておこうとインスタンスを停止させていました。
（操作学習もかねてボリューム、スナップショットはとっておきました）
今度はこのサービスを試してみようかな、と思いターミナルで入ろうとしてみたら入れない。 そうだインスタンス止めてたやー、とうっかりをかましました。
ではAWSコンソールのEC2から「インスタンス」を選択し、インスタンスの起動じゃ。
確認用のモーダルが出るので「開始する」を押下。 すると
インスタンス開始のエラー Invalid value ‘インスタンス名’ for instanceId. Instance does not have a volume attached at root (/dev/xvda)
とエラーメッセージが。
そうだ、ボリュームも課金を減らそうとデタッチしたのでした。
「ボリューム」を選択して、取得していたボリュームをインスタンスにアタッチ。
モーダルが出てくるので対象のインスタンスを選択。
インスタンスを選択するとデバイスが自動的に入力されるが、このデバイスがエラーメッセージに表示されているものと異なる場合はエラーメッセージ側に書き換えておく。
書き換えたらアタッチ。
無事成功するとステータスが「in-use」になります。
S3に画像をアップロードしたらLambdaを通じてSlackに通知を送る
こちらのページで示されている手順をトレース。
AWSは触り始めて日が浅く、基礎的な環境構築や動かし方を先人たちの記事を見ながら確認している段階。
実運用しているわけではないので、Slackに通知を送れるだけで楽しい。
自分が作ったものが動いたー！という実感がもてる。
以前参加していたプロジェクトで利用していたサービスをひとまず触ってみて、どのように設定を行うのか確認している段階。
S3は画像や音楽ファイルの管理などに使用していたため聞きなじみのあるサービス。何をするためのサービスかを調べなくても知っていたのでとっつきやすかった。
S3→Lambda→Slackとつなぎ、ログをCloudWatchで確認する。
①S3にバケットを作ってファイルをアップロード
好きなものをアップロードしよう
②Lambdaの設定
「Lambda関数の作成」から
「s3」などでフィルタをかけて「s3-get-object」を選択。
もろもろの設定はページTOPで紹介したリンク先を参照してください。
③SlackのWebhookURLを取得（Slackのアカウントが必要）
https://my.slack.com/services/new/incoming-webhook/
ここからwebhookのURLを取得する。通知するチャンネルを用意しておこう。
「テストだし、プライベートチャンネルを立てて挙動が確認できたらチャンネル削除しよう」と思ってプライベートチャンネルを立てたが、プライベートチャンネルは削除できないから気を付けるんだ！
（アーカイブ化はできるが、チャンネル削除はパブリックチャンネルのみ対応）
LambdaでこのwebhookURLを設定する。
ちなみに、最初は自分にダイレクトメッセージで送ろうと「@my-account」と自分のアカウントを設定したが、この場合は@slackbotに送られて自分のアカウントにダイレクトメッセージでは送られなかった。
何か設定方法があったなら知りたい。
以上の設定ができたら動作確認してみる。楽しい。
④CloudWatchでログを確認
Lambdaで設定したJSでログを吐き出すようにしてあるのでCloudWatchへ。
メニューから「CloudWatch」を選択して「ログ」へ遷移。
「ロググループ」から該当するグループを選択してログを確認。アップロードするたびにここにログが吐き出される。
