【技術サロン】C#のコードルールについて(2016/12/7) – 株式会社ロジカルビート
あくまで非ゲームプログラマないち C#er として、ということでひとつ。
続きを読むupgrade.all-in.xyz
thebridge.jp
もちろん、全員がマルチタスクでさくさく処理できるようになることは望ましいのですが、 組織が大きくなればなるほどコミュニケーションの設計を最適化すべきですね。
これはまったくその通りだと思っていて、もうちょっと気軽に無視[できる|される]空気が欲しいなぁと思う。
例えばHulickさんが書いてるような「返事がもらえないと支障が出るようなことがらをチャットで伝えようとする」こと自体が問題で、そういうのはメールとかJIRAとかRedmineに逃がしてやるのが正解だと思うんですね。Slackがメールを置き換えるという発想自体が間違いなのではと。というか、世の中の一般的なチャットツールに「通知OFF」の機能がついてるのは、まさにそのためなわけで。この人も書いてるとおり、コミュニケーションがとれるってことが常にすばらしいわけじゃないんですよね。
チャットツールが2個も3個も起動してるような状況はそりゃよくないと思うけど、チャットとメーラーとプロジェクト管理ツールが起動しているような状況は、それ自体は別に悪くないと思うんですよ。ただそれが常に良い状況だとは限らないので、それらが如何に共存すべきかを考えるのが、生産性に貢献せんとする僕らのタスクではないかと思うのです。コミュニケーションチャネルを減らすってのはその結果採用されうる戦略のひとつであって、コミュニケーションの棲み分けができない状況でSlackをやめても、Slackを始める前の状態に戻るだけであんまいいことなさそうなんだよなー……。
ただコミュニケーション最適化ってとても時間がかかるものだと思っていて、なので現場スタッフの自分としては、二度手間になってしまうとしてもまずは、「それJIRAに積んどいてください」「じゃあそっち行くんで口頭で相談させてください」「電話で話してもいいですか?」って言うところから始めるようにしてる。もうちょい責任(というか権力)のある立場だったらまた違うやりかたがあるんだろうなぁとは思いつつ。
DLLにするとUnity上でリビルドがかからないから速くていいとか、実際どうなん?みたいなところ。
続きを読む最近はどうだかよく知らないけど、一昔前にウェブ界隈でフォントのサブセット化なるものが流行ってたらしい。ウェブフォント、つまりHTMLと一緒にフォントを提供して、コンテンツ制作者が意図する通りの文字列描画を行うというものがあるんだけど、特に日本語フォントは、配信するにはデータサイズが大きすぎる。だから、コンテンツ内で使われる文字だけを取り出して配信すればいいんじゃないか、というもの。
ただとても残念なことに、海外系のウェブフォントサービスで日本語を本気でサポートしてるものは稀で、自前でサブセット化するにしても、某有名ツールではカーニング情報が剥がれてしまう*1とか、ちょっと頑張ってぐぐった程度ではいいかんじの解説付きサンプルも見つからない。
なんでそんな状況になるのかをちょっとだけ調べてみた。
以下、TTFの仕様が大きすぎてまともな実装にはなってないけど、テスト用に書いたスクリプト。
https://github.com/hal1932/test/blob/master/testSubset.py
*1:だからといって使えないというわけではなく、あくまで求めるデザインの精度次第。
実際のところ宗教論争に近いんだけど、個人的には、TAがインハウスで扱うようなDBならSQLだけで十分だというスタンス*1*2ではある。とはいえイマドキそんなことも言ってられないし、書くだけ書いてみる。
とりあえず、「O/R マッパー」と毎回書くのはだるいので、「ORM」と略すことにする。
*1:というか、クエリアダプタの挙動をきちんと把握して内部的にどんなSQLが生成されるかを理解した上で O/R マッパーを使うのはとても素晴らしいことだと思うけど、大抵の場合、TAがそこまでやるのは無駄だろうという判断。
*2:あと、大規模で複雑なDBでは O/R マッパーがあると実際すごく便利なんだけど、そんなDBをTAが主導的に扱うことはほぼないだろうという判断。
テーブル内のデータの操作方法、とりあえずこれだけ覚えておけば、最初のうちはあまり困らないと思う。
最初に書いたとおりMySQLを前提に進めてみる。とりあえず試すなら MySQL Installer でセットアップするのが一番楽。Server Only でインストールして、クライアントは HeidiSQL を。