@takke Android端末だとメーカーによっては通知領域にBTスピーカーのバッテリー残量でることもありますね。LGEとか
@takke Android端末だとメーカーによっては通知領域にBTスピーカーのバッテリー残量でることもありますね。LGEとか
ライブの客「オタ芸うるせぇ!!」 → 敗訴確定 http://blog.livedoor.jp/goldennews/archives/52016226.html
カメラバッグに詰め込む機材を吟味するなど。
パナ:GM1, GX7mk2, 8-18, 12-60F2.8, 42.5F1.7, 100-400
ペンタ:K-1, FAリミ3種類, DFA100
…がなんとか収まる感じ
https://mastodon.juggler.jp/media/GjHkSezLX9QHrnNjsIw
http://juggler.jp/tateisu/camera/20171021-Pana100-400-test/ パナ100-400mm の最短撮影距離付近。遠距離だとどうなるかも試してみたいが今週末は天候がアレで難しそう。なんにせよ真価を発揮させるのが難しそうなレンズだ…
カスタム絵文字に を輸入しました。けもフレのは著作権的にどうなんだろ。クレーム来たら消します
診断メーカーへの指定はこんなだった https://gist.github.com/tateisu/5fc37408a74aaa3680ace74baed4f86f
@nacika いらすとやの場合、http://www.irasutoya.com/p/faq.html のFAQを読む限りでは、Webで使うだけならOKで、素材配布目的のサイトでの配布はNGと読めます。
うちはpgbouncerいれてるけど「you don't own a lock of type ExclusiveLock 」はログには出てこないなあ… pooling mode によるんじゃない?
一週間前の最高気温が28.9で機能の最高気温が11.9ですか… 気温の変動に耐えられないのでガスファンヒーター回してる
ゼロ幅スペース(ゼロはばスペース、ZWSP: zero width space)は、コンピュータの組版に用いられる非表示文字で、文書処理システムに対して語の切れ目を示すのに用いる。
画像があればカスタム絵文字にするけど、もうこのeagleの画像をまんまつかってhawkで登録すればいいんじゃないかな。。
Lightroomという名前のアプリはアップデートで別のものを指すようになった。画像を一枚開くたびにダウンロードで待たされるのはさすがに耐えられないのでClassicの方を使うかなあ…
EF-MはなぜかAF可能なSpeed booster (focal reducer)が存在しない。コントラストAFがうまくいかないとかありそうだ
知り合いに貸してたカメラとレンズを回収してくるよ。帰りはカメラバッグを2つ背負うのか…
「疑似アカウントで会話の流れ」もリモートのトゥートのIDを調べる時にURLを正規表現で処理してて、そこも多分だめ
外部アプリからトゥートやアカウントのURLでクライアントアプリを開けるようにするIntentFilterが「URLのpathの先頭が/@」という条件なんでサブディレクトリにマストドンのタンスがあるとかいう場合は対応がむずかしい。下手に緩めると全てのURLに反応しちゃううざいアプリになるので…
公式Webだとマウスを重ねると説明が出るんだけど、タッチUIとあまりにも相性が悪いので表示スタイルはかえました
v1.7.0
- (マストドン2.0.0以降)添付メディアに説明文を指定できます。指定した説明文はTL中に表示されます。
- (マストドン2.0.0以降)アカウント追加とアクセストークン更新の際にクライアント登録を再利用する
- カラムのリロードボタンを押したらカスタム絵文字のエラーキャッシュをクリアする
- 添付メディアのアップロード完了時に投稿欄にURLを付与する位置をテキストの末尾に変更
クライアント登録の確認のために /api/v1/apps/verify_credentials を呼び出すために oAuth2 の Client Credentials を生成するのだが、今度は Client Credentials を浪費しないように注意する必要が出てきた。デベロッパーフレンドリーェ…(
添付メディアのdescription、これ使って会話されたらサードアプリだと感知できないな。何か入力されてたらテキスト表示するようにSTを変更するか
なるほど、この表示はALTテキストを入力できる ってことなのか https://mastodon.juggler.jp/media/po70nlYwuvdVrO0HGmQ https://mastodon.juggler.jp/media/fN4p0DcHHvdhMK3L1wA
APIが追加されたのはいいけど多分どのアプリもまだ対応してなくて古い挙動のままだと思う
マストドンのクライアントIDが矢鱈多くなるのはこんな理由 https://github.com/tootsuite/mastodon/issues/5104
日本製のイギリス高速鉄道、初日からやらかす
http://blog.livedoor.jp/goldennews/archives/52015966.html
http://blog.livedoor.jp/goldennews/archives/52015958.html スカイツリーの各所に使われてる神戸製鋼
バターをレンジで溶かして小麦粉とだし汁いれて、レンジで20秒まわしてかき混ぜるのを繰り返すとホワイトソースできる
deleteイベントが届いたらstatus.idかstatus.reblod.idが一致するトゥートをTLから削除してるよ
「unreblog arrives over streaming API」ってAPIイベントにそんなんあったっけ、、、?
インスタンス情報APIも5xxになるタンスが結構あって、割とどうしようもない印象しかない
@Clworld mstdn.jp はCloudFlareだしmastodon.cloud も何か挟んでる
暗幕一枚じゃ消しきれなくて、二つ折りにしてなんとか消せた感じでした。そのせいで撮影中のポーズがなんか必死なアレになって笑われてたw
そもそもカードリーダーて熱で勝手に壊れるから、よほど使用頻度が高いんでもない限り外付けを使い潰した方がええよ
忍者レフはカメラマンを隠すのに便利でしたが、展望台の室内照明の全部の写り込みを消す程の広さはないのです
ガラス用のバキュームリフターと暗幕と洗濯紐と三脚とカメラを持って展望台に向かってるけど、はたして使わせてくれるんだろうかコレは
ブランチマイニングの跡地なんて価値はたいしてないんだから好き勝手に掘れば良いのよ…
どうせ思い出すなら美しい異性のことにしようぜ。オバケも擬人化して魔改造して美しい異性にすれば大丈夫!
断酒して一か月を過ぎて、酩酊したいと思うことは特にないんだけど、ノンアルのビール風飲料をかぱかぱ飲んでる自分がいる。行動自体はあまり変わってないなー…
うちの鯖で遅いクエリは SELECT "statuses".* FROM "statuses" WHERE "statuses"."account_id" = ? ORDER BY "statuses"."id" DESC LIMIT ? が (スロークエリだけの)平均で 35,124 ms くらいなんだけど、全ローカルユーザでベンチとってみてもキャッシュが効いてたら1msくらいだったりするので割ともう仕方ないと思ってる
Web Hook スタイルの通知APIがないとサードアプリ的にはしんどいことだけが分かった
というわけで実験終了にする。アプリの通知サーバが全タンス全アカウントの通知ストリームを受信するなんてRate Limit的にムリ
通知リスナのサーバから大手サーバに接続にいくとIPアドレス単位のRate Limitにひっかかることが分かった。そりゃ無理だ
気温の推移 http://weather.time-j.net/Stations/JP/koshigaya をみたら最高気温の下がり具合がすごかった https://mastodon.juggler.jp/media/iwtfqed-aifs2AjoMys
NginxやApacheのバージョンは隠してるけどマストドンのタンスのバージョンは隠さないのは良いんだろうかとふと疑問に思った
https://mastodon.juggler.jp/media/-RnCPateq1aGrVWWGPw Androidスマホのテザリング設定、TKIPの有無が書いてなくて今回のWPA2の脆弱性に引っかかるのかどうかわからない
アップロードした添付メディアにマウスポインタのせると「視覚障碍者のための説明」って出るのは翻訳がおかしいのか原文がおかしいのか https://mastodon.juggler.jp/media/Z0JxpPFD-qUq91ot25U
muninで使われてるRRDtoolsとかは4GB rolloverを考慮した作りになってる
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1 FTLでは部分インデックスが使われなかったのでLTL専用のインデックスに書き直しました
このアカウントは、notestockで公開設定になっていません。
LTLが過疎りがちなおひとり様タンスだとLTL専用に部分インデックス作った方がいいんだろうなあ… FTLの方は別に最適化いらないだろうと思わなくもない
ほんとはLTLとFTL個別に部分インデックス作った方が速いけど、容量との兼ね合いもあるしどうなんだろ。FTLのクエリでさっきの部分インデックスが使われるのかどうか確認してない
このインデックス入れるとLTLが過疎ってる場合のAPI応答性が大幅に改善しますが、インデックスを増やすことによるコスト増加と見合うかどうかは人によると思います。
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1
というわけでLTL,FTLのクエリ負荷を軽くするインデックス。
CREATE INDEX accounts_not_silenced ON accounts using btree
(id)
WHERE not silenced;
CREATE INDEX statuses_public ON statuses using btree
(id,("statuses"."local" = TRUE OR "statuses"."uri" IS NULL))
WHERE "statuses"."visibility" = 0
AND (statuses.reblog_of_id IS NULL)
AND (statuses.reply = FALSE OR statuses.in_reply_to_account_id = statuses.account_id) ;
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1 部分インデックスを貼ると8msのクエリが1.5msになった
ああ、このケースだとaccounts.silences 見てるから結局アカウントテーブルにもアクセスが必要になるのか… cost見ると別に減ってないしなあ…
@zundan 時報か天気ボットでも入れてLTLを微妙に賑やかすと一発で解決するんでは。
あとaccounts へのjoinをin(select...) に置き換えると実行時間が44%下がります。
https://gist.github.com/tateisu/58d8e566f67a2cd3aa999c7c4b5e6ee1
このアカウントは、notestockで公開設定になっていません。