読者です 読者をやめる 読者になる 読者になる

ガツンと。

文章書くのって難しい

ActiveReportsのXaml, Wpfについて体系的にわかり始めた

Xaml, WPFについて体系的に解説してくれているサイトがなかなか見当たらなかった。
※ちょいちょいヒットするのだが、どのサイトも読み進めていくと、自分に最低限の知識ベースができていないからなのか途中で理解に詰まってしまった。
 
書籍もこれといったものがない。(というか基本的な知識もないため、本も選べなかった。)
 
いままで見た中で、このスライドが一番くわしく、基本的な部分から順序良く解説してくれていた。
 
今日はこれに沿って、以下を学べた。
Xamlでのオブジェクト生成について
Xamlでのオブジェクトプロパティ指定について
Xamlコレクション構文
Xamlコンテンツ構文
・TypeConverter
WPFのコントロール

ActiveReportsセクションレポートのページレイアウトについて勉強した

参考)https://codezine.jp/article/detail/7434?p=3


◆group header, detail, group footerのkeepTogetherプロパティをTrueにするとページをまたいで表示しない。
※らしいけど、ページをまたいだ。。なぜだ?
→解決:keepTogetherは指定したgroup headerのみがページをまたがない。
指定のgroup全体の改ページを制御する場合はgropuKeepTogetherを指定する。

◆canGrow, canShrinkプロパティ
textBoxなどに存在するプロパティで、文字数が多かったり少なかったりしたときに、それに合わせてサイズの拡大縮小を行うかどうかを指定する

◆NewPageプロパティ
指定のセクションで改ページを行うかどうかを指定する
pageセクション以外に存在するプロパティ

◆RepeatStyleプロパティ
改行したときにグループヘッダの内容をもう一度表示させるかどうか。

◆UnderlayNext
グループヘッダをdetailと同じ行に表示するかどうか

◆RepeatToFill
detailに存在するプロパティ
表示するデータがなくなっても、ページ末まで空で行を表示する。
「手書き用の行を表示させたい」などの需要に対応
※ただし、groupHeader等を複数指定していると使えないという制限が存在する。

◆ShrinkToFit
textBoxなどに存在する。
文字数が枠内に収まらなかったとき、フォントサイズを調整して枠内に収める。

◆ColumnCount、ColumnDirection、ColumnLayout、NewColumn
カラムレイアウト設定用プロパティ。
detail.ColumnCountの数値でカラム数を決定。
ColumnDirectionはカラムのデータの展開方向

C# コレクションについて調査

 
ArrayListクラス
なんでも入れられるコレクションクラス。
配列と違い、要素数は動的に変化する。
入れられる型も統一しなくてもよく、逆に言うと何が入っているかわからない。
phpでいう配列(連想配列でない)のイメージ
 
◆Listクラス
System.Collections.Generic名前空間に所属している。
ArrayListクラスはなんでも入れられたが、
Listクラスは宣言時に入れる物の型を指定し、その型のデータしか入れられない。
 
◆HashTableクラス
キーとともにデータを追加でき、キーでデータを指定できる。
ArrayListと同じく、キーにもデータにもどんな型のデータでも指定できる。
 
◆Dictionaryクラス
HashTableのジェネリック版。
キーと値に型を指定できる。
 
◆Queue, Stackクラス
キューとスタックを実装できる。
これもジェネリッククラスで、入れるデータ型を指定する。
これらもICollectionインターフェースを実装しているので、foreachでデータを取り出せる。

今日やったこと。
 
 
◆基本的なクエリのおさらい。※MySQLとの違いを比較。
SQL Server 2016の教科書」の6章、7章。
キーワード的には以下
・SELECT
・ORDER BY
・WHERE
・GROUP BY
・INNER JOIN, OUTER JOIN
・CASE
・TOP
・OFFSET, FETCH
 
TOPとOFFSET, FETCHが独特だった。
 
「上位10件」や「10件ごとにページング取得したデータの3ページ目」のようなクエリをMySQLなら、
LIMIT 10 OFFSET 3
のように書くが、SQL Serverの場合は、
OFFSET 3 ROWS FETCH 10 ROWS ONLY
のような書き方になる。
ただし「上位10件(ページングなし)」の場合は
SELECT TOP(10) * FORM テーブル名
のような書き方になるっぽい。
 
◆ActiveReportsの帳票の組み方。
ここを参考に。
 
帳票を日付、注文番号ごとにグループ化して一覧表示し、
各グループごとに価格の小計を表示させる方法を学んだ。
textBoxのプロパティへの設定でいろいろできる。
 
◆I review how to use Query of SQL Server. Compare that with MySql.
section 6 and 7 of「SQL Server 2016の教科書」
keyword is ...
・SELECT
・ORDER BY
・WHERE
・GROUP BY
・INNER JOIN, OUTER JOIN
・CASE
・TOP
・OFFSET, FETCH
 
When you want to get record of top 10, You write that in MySql case
'LIMIT 10 OFFSET 3'
but, You have to write that In SQL Server case
'OFFSET 3 ROWS FETCH 10 ROWS ONLY'
 
◆I study How to use of ActiveReports

I study English talking and Windows Programming

I study English talking and Windows Programming, Today.
Neither is difficult.
 
When can i speak English very well? When will that day come?
 
Where is a good document about WPF, XAML?
I couldn't find it.

PHPカンファレンス関西 2016 聞いた内容を短くまとめた

「要約出来るようになれ」と上司から言われているので、
今回参加したPHPカンファレンス関西2016で僕が聞かせてもらったカンファレンスの内容をなるべく短くまとめてみた。

 

[基調講演] Composerを速くするために必要だったもの
中野 拓 さん

スライド:

Composerを速くするために必要だったもの /composer-keynote // Speaker Deck

Composerの動作が遅かったので、早くするためのプラグインを自分で作ったら、
githubで凄いスターをもらえた。(日本のphperで一番)

GitHub - hirak/prestissimo: composer parallel install plugin

便利なツールや評価されているツールはスーパープログラマーが作っていると思っていたが、実はそうではなく、問題に立ち向かう姿勢を持ったプログラマーが作っているのではないか?
このプラグインはごく一般的なプログラマーが出来ることで出来ている。

今自分が出来る範囲でも、影響あるツールは作れるはず。

 

 

大量のデータで困ってませんか?
高橋 邦彦 さん

google cloud platformのBig Queryというサービスについての話。

データ量が多すぎてRDBSで集計しようとすると
結果が帰ってくるまでに数時間とかかかってしまうような場合、
BIg Queryを使うことでスグに結果を得ることが出来る。

「集計したい時にだけRDBSのデータをデータをBig Queryに上げて、集計処理し、データを削除する」
というような使い方をすればお金もあまりかからない。

ただし、集計処理の指示の方法によっては扱うデータ量が無駄に大きくなり、無駄にお金がかかってしまうので、扱うデータ量が小さくなるように工夫するようにする。

 

 

 

ビューのソースコードコンフリクトから解放される、PHPerのための次世代Webアプリケーション開発への道。
岸田 健一郎 さん

スライド:

ビューのソースコードコンフリクトから解放されるPHPerのための次世代Webアプリケーション開発への道 / PHP Conference Kansai 2016 // Speaker Deck

SPAでサイトを作る場合、Polymerを使うと綺麗に開発できておすすめですよという話。

 

 

 

PHPerに知ってほしいDB設計の話 7F メインホール
曽根 壮大 さん

スライド:

PHPerに知ってほしいRDBの事 その3 // Speaker Deck

検索とINDEXについて
  • indexの使われ方、実行計画を理解すれば、遅いクエリはなぜ遅いか理解できる。mysql workbenchの実行計画はみやすい。
  • JOINは掛け算で、走査するレコードがJOINするたびに倍々に膨れ上がるので、遅いならばJOIN前に範囲を絞ったほうがよい
  • PostgreSQLは複数indexを使えたり、JOINのアルゴリズムも複数あったり、相関サブクエリも早かったりとmysqlよりも優れている点が多い
スキーマレスについて

json型のカラムを定義することができる。(mysql5.7以上、postgreSQLは昔から)
TEXT型にjsonを入れるのと違い、json中の値で検索できたり、indexをはったりできる。ただし、ユニーク制約や、外部キー制約はできない。

仕様変更などで扱うデータ項目が変わる度にDB構造を変更するのは大変だが、json型なら簡単に対応できる。
あらたな選択肢として持っておく。

※ただし、ORMを使うのには向いていない。

少子化は解消するべき問題なのか?

 http://anond.hatelabo.jp/20160605143345

こういう事は自分もよく考えてた。
やはり同じようなことを考えている人はいるんだな。
 
いざ作ろうという時に、将来が不安になってしまう時点でだいぶ問題な気はする。
少子化を本当に解消したいなら、補助でも印象操作でも何でも出来るのに(実際他のことならやっているのに)、やらないのは、政府は少子化は解消するべき問題だと捉えていないんじゃないかなと思う。