graphics.hatenablog.com

技術系テクニカルアーティストのあれこれ

Slackとかにおもうこと。

upgrade.all-in.xyz
thebridge.jp

もちろん、全員がマルチタスクでさくさく処理できるようになることは望ましいのですが、
組織が大きくなればなるほどコミュニケーションの設計を最適化すべきですね。

これはまったくその通りだと思っていて、もうちょっと気軽に無視[できる|される]空気が欲しいなぁと思う。

例えばHulickさんが書いてるような「返事がもらえないと支障が出るようなことがらをチャットで伝えようとする」こと自体が問題で、そういうのはメールとかJIRAとかRedmineに逃がしてやるのが正解だと思うんですね。Slackがメールを置き換えるという発想自体が間違いなのではと。というか、世の中の一般的なチャットツールに「通知OFF」の機能がついてるのは、まさにそのためなわけで。この人も書いてるとおり、コミュニケーションがとれるってことが常にすばらしいわけじゃないんですよね。

チャットツールが2個も3個も起動してるような状況はそりゃよくないと思うけど、チャットとメーラーとプロジェクト管理ツールが起動しているような状況は、それ自体は別に悪くないと思うんですよ。ただそれが常に良い状況だとは限らないので、それらが如何に共存すべきかを考えるのが、生産性に貢献せんとする僕らのタスクではないかと思うのです。コミュニケーションチャネルを減らすってのはその結果採用されうる戦略のひとつであって、コミュニケーションの棲み分けができない状況でSlackをやめても、Slackを始める前の状態に戻るだけであんまいいことなさそうなんだよなー……。

ただコミュニケーション最適化ってとても時間がかかるものだと思っていて、なので現場スタッフの自分としては、二度手間になってしまうとしてもまずは、「それJIRAに積んどいてください」「じゃあそっち行くんで口頭で相談させてください」「電話で話してもいいですか?」って言うところから始めるようにしてる。もうちょい責任(というか権力)のある立場だったらまた違うやりかたがあるんだろうなぁとは思いつつ。

TrueTypeFontで遊んでみた。

最近はどうだかよく知らないけど、一昔前にウェブ界隈でフォントのサブセット化なるものが流行ってたらしい。ウェブフォント、つまりHTMLと一緒にフォントを提供して、コンテンツ制作者が意図する通りの文字列描画を行うというものがあるんだけど、特に日本語フォントは、配信するにはデータサイズが大きすぎる。だから、コンテンツ内で使われる文字だけを取り出して配信すればいいんじゃないか、というもの。

ただとても残念なことに、海外系のウェブフォントサービスで日本語を本気でサポートしてるものは稀で、自前でサブセット化するにしても、某有名ツールではカーニング情報が剥がれてしまう*1とか、ちょっと頑張ってぐぐった程度ではいいかんじの解説付きサンプルも見つからない。

なんでそんな状況になるのかをちょっとだけ調べてみた。

以下、TTFの仕様が大きすぎてまともな実装にはなってないけど、テスト用に書いたスクリプト
https://github.com/hal1932/test/blob/master/testSubset.py

  • 目的
  • 準備
  • データ定義
    • TTFに含まれる情報
    • TTFフォーマット
    • 文字コードとグリフの対応付け
  • 実演
    • グリフ検索に使うコード体系を扱う 'cmap' サブテーブルを特定する
    • 「フォントに含まれるグリフ→文字コード」の辞書をつくる
    • 不要な文字に相当するグリフ情報を潰す
    • 結果の確認
  • 結論

*1:だからといって使えないというわけではなく、あくまで求めるデザインの精度次第。

続きを読む

テクニカルアーティストのためのデータベース入門 (9) パフォーマンス最適化

最初のリリースまではデバッグ大変だからちっちゃいデータセットで試しながら進めてて、とあるタイミングで本番規模のデータを流し込んだら最初のロードに数秒とかかかっちゃったりして。そういうときに、可能な限り悩まずに状況を改善したい。

  • 共通
    • サーバを札束でひっぱたく
  • select
    • クエリの並列化
    • クエリの数を減らす
    • キャッシュに載せる
    • joinしない
    • インデックスを貼る
  • それ以外

graphics.hatenablog.com

続きを読む

テクニカルアーティストのためのデータベース入門 (8) O/Rマッパー

実際のところ宗教論争に近いんだけど、個人的には、TAがインハウスで扱うようなDBならSQLだけで十分だというスタンス*1*2ではある。とはいえイマドキそんなことも言ってられないし、書くだけ書いてみる。

とりあえず、「O/R マッパー」と毎回書くのはだるいので、「ORM」と略すことにする。

  • 必要とされる背景
  • 主な機能
  • メリットとデメリット

graphics.hatenablog.com

*1:というか、クエリアダプタの挙動をきちんと把握して内部的にどんなSQLが生成されるかを理解した上で O/R マッパーを使うのはとても素晴らしいことだと思うけど、大抵の場合、TAがそこまでやるのは無駄だろうという判断。

*2:あと、大規模で複雑なDBでは O/R マッパーがあると実際すごく便利なんだけど、そんなDBをTAが主導的に扱うことはほぼないだろうという判断。

続きを読む

テクニカルアーティストのためのデータベース入門 (7) SQLのはじめの一歩

テーブル内のデータの操作方法、とりあえずこれだけ覚えておけば、最初のうちはあまり困らないと思う。

https://zeroturnaround.com/wp-content/uploads/2016/06/RebelLabs-SQL-cheat-sheet.png

最初に書いたとおりMySQLを前提に進めてみる。とりあえず試すなら MySQL Installer でセットアップするのが一番楽。Server Only でインストールして、クライアントは HeidiSQL を。

  • テーブルの作成と削除
  • データの追加
    • 1つずつ追加する(インサート)
    • まとめて追加する(バルクインサート)
  • データの検索
    • 1つのテーブルから検索
    • 複数のテーブルから検索
  • データの更新
  • データの削除
    • 条件を指定して削除する
    • 全部まとめて削除する

graphics.hatenablog.com

続きを読む