天気予報みて21時には晴れるのかと思ったら、台風の中心が通過するのかコレ…
天気予報みて21時には晴れるのかと思ったら、台風の中心が通過するのかコレ…
@Tina04VV mk2じゃない方なのかな。まああると思うよ
@Tina04VV タイトルにカメラ名のついたムック本をAmazonでぐぐって、中古のでいいから入手するといい。取説よりは機能ごとの作例画像が多くて分かりやすいし、レンズの紹介もある
@Tina04VV 単焦点の入門としてはとても良いレンズだと思うよ。ボケ表現を試してみるにはとてもよい。
しかしティナさんどっちかというとボケあまり興味ないよね…。
@Tina04VV 例えば今の画像だと、撮影前に白い紙を使ってWBを合わせるとか、Avモードでもっと絞ってピント範囲を広げて、MFでメカと少女の両方に合うピント位置を探すとかある。一つ一つは取説や入門書、入門記事にかいてること
@Tina04VV そんなことはない。F値の小さい明るいレンズほどじゃじゃ馬なので、安めの単焦点は入門にとても良い。合わなくても被害が軽微ですむ
@Cutls 編集して投稿する直前に削除はしてるので、デバッガでそこを見ればみれなくはない
このアカウントは、notestockで公開設定になっていません。
https://github.com/tateisu/FADownloader/releases/tag/v1.5.0 を公開したよ。なお動作確認はあまりしてない模様。不具合報告がきたら対応しよう… #fadownloader
ボトムタブが重要なんだったら、ユーザがボトムタブを構築できるようにした方が快適だよね。
使用頻度の低い項目はやはりメニューボタンの向こうに追いやるしかないよね。
ボトムナビゲーションとハンバーガーメニューは全く独立した話で、画面下部が重要なんだったらハンバーガーメニューを下に置けばいいよね。
…全部STのUIじゃん…変える必要ないわ
横棒が並んでるのはメニューの意匠であって、決してハンバーガーの意匠ではないよなあ…。という結論になった
@ButterflyOfFire maybe it was fixed. thank you
currently there is an inconsistency between the weblate branch and my branch. Please wait for a while until correct it.
試してみたけど微妙。ごめん、戻す @ButterflyOfFire
STの場合はハンバーガーよりも"+"の方が適切なのかもなあ…
何が困るって、Godoxのフラッシュのコントローラにシグマ用のがないんだよ。ペンタックス用すらあるのに！のに！
暖房を最弱にしても部屋が31度になるの贅沢感ある。
このアカウントは、notestockで公開設定になっていません。
ライカLマウントのアライアンスは、ストロボの互換性はない。ライカのフラッシュはニコン互換、パナソニックのフラッシュはフォーサーズ互換、シグマのフラッシュはSA-TTLでシグマ専用。なんてこった。
@Tina04VV あとは https://s.kakaku.com/review/J0000013583/ もセンサー大きくて良いかなあ。
まあ中古は買うときにモノが出てないと変えないから、その時になってから考えた方がいいかも。
@Tina04VV バッテリーもたない。プレビューの遅延が大きい。AFも遅い。グリップ感も悪い。撮影後に転送を待たないとピントチェックできない。
@Tina04VV 特に用途が限定されてないなら、ソニーRX100の少し古いモデルはどうかなあ。 https://s.kakaku.com/item/K0000653427/ ただマクロは少し弱いね。 予算あるならもちろん新しいのもいい。LX100IIも悪くない。
@Tina04VV まあその、レンズスタイルカメラは後継が出なかった理由が色々あるんだよ…。今のスマホアプリでのサポートも厳しいのでオススメできない。
ていうか今時はスマホのカメラも画質よいので、コンデジはセンサー大きいか高倍率か防水かで、タッチ操作できてWi-fiでスマホに転送できるのが受けてる…。
@Tina04VV 対応してるスマホアプリが変わってるんだけど、そのアプリとそのカメラで出来ることが割と制限されてるよ
「SIGMA fp」は10月25日発売 ボディは税込22万円 https://www.itmedia.co.jp/news/articles/1910/10/news127.html やっぱり EOS RPほどのコスパはないか…
フルサイズミラーレスはレンズが全然エントリー向けではないので、まずそこを崩してほしいと思ってる
Z50は4k60pには踏み込まなかったか…。フジより後ろにいる感じ
別アカ操作の大半はブーストボタン列の長押しでも使えるから、アクション数はあまり増えてない筈なんだけどね
STでコンテキストメニューを折りたたんだの、最初から開いてるようにするオプション欲しい人いるかな？ #SubwayTooter
自宅鯖以外でも、オンラインストレージを別業者に切り替えてアップロードし直す時とかに怒られたりするよ。DropboxとかAmazon DriveとかGoogle Driveとかに1TB超を上げるのを年に数回やる。
プロバイダからの怒られ、下りではあまり発生しないしnuro光とかは規約に制限がないので怒られないよ。iijmioとかはかなり厳しい。
初期のmstdn.jp が一週間で自宅鯖からさくらに移動した理由はたぶん転送量だと思ってる。
自宅鯖の一番のリスクは転送量が多くてプロバイダに怒られることです。本当に困る
たとえばCrypkoやWaifuLabsみたいなGPUぶん回すサービスだと、画像生成部分はクラウドには置かれないですね
クラウドと同じスペックのサーバ、市場に出てるパーツの下限が高すぎるので自作ではもはや作りにくいよ。DDR4 RAMだと8GBx2が最低ラインでしょ。おさがりのPCで始められるのが利点なので、比べるもんじゃない
先に進むとキャラの差異が微妙になって判別が難しくなる
WLClient http://juggler.jp/WLClient/ の最新版ではアプリから作った画像もリンクできるようにしてるので、もし使ってる人がいたら試してみてね
#WaifuLabs で メールアドレスとリンクした画像を使えるゲーム https://play.google.com/store/apps/details?id=com.Sizigi.Concentration が日本でも使えるようになったらしいよ
Androidは作りが悪いからより多くのRAMが必要と言う人がいるんだけど、ローエンド端末への対応をしっかりやってるのはむしろAndroidの方だよねってオチ
@blank71 プロセスが個別に用意される訳ではありません。プロセスの下にActivity(画面)やService(UIなしで動く何か)などのコンポーネントがいくつかあります。コンポーネントのどれかが「フォアグラウンド状態」ならプロセスも「フォアグラウンド状態」です。例えば音楽プレイヤーは再生中はサービスをフォアグラウンド状態にするので、プロセスもフォアグラウンド状態です。
画面スタック(Activityのリスト)はプロセスが死んでも管理情報だけはOS側が維持してます。
状態の保存を行えるタイミングはいくつか用意されてます。
@rinsuki まあ当時はRAM1GBでしたからねー。4GBになれば少しはマシになったでしょうけど、りんすきさんの言い分に合わせるならそれはOSの改善とは言わないですね。
@blank71 Windows OSなどでタスクマネージャに出るアレがプロセス。 Androidではバックグラウンドに回ったタスクは管理情報は存在してるけど、プロセスは殺されることがあるのです。そしてタスクが再び必要になったときにプロセスは新しく作られて、状態を復元して何事もなかったかのようにふるまうというのが理想的な流れです。
@rinsuki バックグラウンドに落ちたアプリが殺されることをクラッシュとは、私は言ってませんね。 むしろバックグラウンドアプリが殺されないことでフォアグラウンドアプリのメモリが不足してクラッシュするのです。iOS9.xで大量に見ましたね。
@rinsuki ローエンドはAndroidの方が多いんで、Androidの方がしっかりやってますね。一方でiOSはハイエンドなのにRAMはケチってて、バックグラウンドプロセスの制御も雑ってことになるんだけど。
開発者オプションで「バックグラウンドプロセスの上限」を「使用しない」にする。
STを起動してTLが読み込まれるのを見る。
投稿画面を開いて何かテキストを入力。
ホーム画面に戻ってgmailか何か別のアプリを開く。
タスク切り替えでSTの投稿画面に戻る。入力したテキストが復元されてる。
戻るボタンでメイン画面に戻る。STはTLをディスクに保存しないので、再度TLの読み込みが行われる。
@blank71 いや、プロセスが殺されただけでタスク一覧には残ってて、タスク切り替えで戻ってきたなら、画面ごと復元されてユーザは何も意識せずに編集を再開できるはずだよ。開発者オプションで「バックグラウンドプロセスの上限」を変更すると体験できる。ほかのアプリでも真面目に作られてるならそうなる。しかしゲームアプリは保存するべき情報が多すぎるので保存せず、オープニングの権利者表示から見直すことになる場合が多い。
@rinsuki 仮想メモリに頼れないモバイルOSでメモリ確保の失敗を防止するには、OSが空きメモリの確保を周到に行う、つまりバックグラウンドプロセスをいかに適切なタイミングで殺すかという問題になる。常に一定量の空きを確保するようOSが動いてる
@rinsuki メモリ確保への失敗で落ちるのは大半のアプリで防げないのです
「バックグラウンドになった際にプロセスが殺されても大丈夫なように」を言い換えると「殺されるか殺されないかはわからないけどバックグラウンドになる際に状態の保存が必要」なので、デスクトップ用OSよりタスク切り替え時の負荷は高いのだ
通話着信への応答性が求められるモバイルOSでは、バックグラウンドになった際にプロセスが殺されても大丈夫なように設計する必要がある。これはデスクトップ用OSとの大きな違い
iOSはAndroidよりアプリがクラッシュしやすい？InstagramやFBなど https://iphone-mania.jp/news-145071/
あとアプリのクラッシュ率でいうとAndroidの方が圧倒的に低い。iOSはメジャーアップデートのたびにアプリのクラッシュ祭りやってる
iOSユーザの言う「Androidよりクオリティが高いアプリ」って訊いてみるとニッチなやつばかりだ
はてなブログに投稿しました
ハクキンカイロを買っていた - ejo090の日記 http://ejo090.hatenadiary.jp/entry/2019/10/10/151929
@deltelta 割と長期間繋がらないんですよ。負荷になるので他の繋がらないサーバと一緒のタイミングで整理してる
の投稿
kedama@foresdon.jp
このアカウントは、notestockで公開設定になっていません。
@mal The behavior is not intended, but if one is selected from the previous visible range, I don't think it's abnormal.
タブレットモードでのデフォルトアカウントは前からあったが、投稿画面を開く時だけ使われてた
「アプリ設定/タブレットモード/簡易投稿でも可能ならアカウント選択を省略する」を追加。
投稿画面を開く
- (1)デフォルトアカウントが指定されてればそれで投稿画面を開く
- (2)画面内のカラムに疑似アカウントがあればアカウント選択
- (3)画面内のカラムが同じアカウントならそれで投稿画面を開く
- (4)アカウント選択
簡易投稿
- (1)「簡易投稿でも可能ならアカウント選択を省略する」が無効ならアカウント選択
- (2)デフォルトアカウントが指定されてればそれで投稿する
- (3)画面内のカラムに疑似アカウントがあればアカウント選択
- (4)画面内のカラムが同じアカウントならそれで投稿する
- (5)アカウント選択
簡易投稿の方がチェックが多いのは、投稿画面を開くのと違って後からアカウントを切り替える機会がないからです
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
tootctl domain purge、つながらないサーバに接続しようとして延々またされるの理不尽な気がする
(LTL) pleroma.nakayoshi.tk そろそろpurge していいかい…？
https://gist.github.com/tateisu/f8f942478019ebf87d56166adbbb00a8 Mastodon の sidekiq のリトライを読む単純なスクリプト。配送エラーのメッセージのホスト名部分を集計します。 tootctl domain purge するかどうかの判断に使えなくもないかも。
「短いサイトの説明」の表示例
- /about
- アカウントの公開ページのサイドバー
- /about の<meta>タグ
試してみたらmetaタグの方はタグが除去された状態になった。aタグやimgタグはなかったことになる。
3.0.1で「サイトの説明」がほぼ使われなくなります。公開ページとそのMETAタグで「短いサイトの説明」だけが使われます。 なおHTMLタグは使えるので「サイトの説明」に指定してた内容を「短いサイトの説明」に丸ごとコピペしても大丈夫です。いや公開ページのサイドバーやMETAタグ内部に長文HTMLが出てくるのはどうなのと思わなくもないです。
未リリースどころかタグも打たれてないけど3.0.1なう。
@kazumi_7 行の最後に必要なんじゃなくて、実際には前の文と新しい文の間に必要なんだから仕方ないね。 tmp=a; a=b; b=tmp; とか1行に書く時もある
サイト設定で無効にできるのだから、急ぐ必要は全くないと思います
サイトの死活検知とかみると分かるけど、自動検出って一回イベント上げた後にその状態が収まるまで異常状態を覚えておいて状態変化時に通知する形か、状態を覚えないかわりに何度も通知するか、強制的に状態を解決しちゃうかなのです。実装コスト的に最後のになっちゃうのはよく分かる。3.0.1なるべくすぐに出したいだろうし
HTMLはもはやコンテンツ記述言語ではなくて、UI記述言語だからね。しょうがないね。
属性指定が内容とマッチしないサイト(Githubとか)が既に大量にあるので、ブラウザやサーチエンジンがHTMLのlang属性の正しい取り扱いを要求することは今後もないだろうと思う。
HTTPのAccept-Language が色んなサイトで役に立ってることはわかるけど、HTMLのlang属性が役に立たないという話とはまた別だね。あの属性のブラウザ上での振る舞いが、デフォルトでは「フォント」「引用要素の引用符」だけなので、どっちも内容の言語じゃなくて読み手の言語に合わせた方が読みやすい…となる。
HTMLのlang属性は内容の言語を表すために用意されたが、その挙動を見ると書き手よりも読み手の言語に合わせた方が(特にCJK圏では)良い結果になる。またGoogleの検索エンジンはlang属性を利用しておらず、SEO上の優位性は全くない。大半のサイトで正しく設定されていないからだそうだ。
…どうしてこうなった…
物欲を解消したい時に、同じのいくつも買うよりは別の機種を買う選択肢があった方がいいじゃないの
STの絵文字ピッカー、カスタム絵文字のタブを選んで、次に右端のタブを選んで、またカスタム絵文字のタブを選ぶと落ちるらしい。露骨なテスト不足や…。 3.8.4を出した直後だけど3.8.5を出しました
このアカウントは、notestockで公開設定になっていません。
https://github.com/tootsuite/mastodon/commit/c8bcf5cbfdc4b076eae0d9091e688436aa7f2508 マストドンの次のバージョンではハッシュタグがデフォルトで承認済みになる管理者設定が増えるらしい
クラッシュレポート対応しないといけないのがまだいくつか残ってるな…
https://github.com/tootsuite/mastodon/pull/12119 は「サイトの説明」に(YouTube埋め込みを含むような )長いHTMLを書かれるのがイヤだから「短いサイトの説明」だけにするというPRだけど、「短いサイトの説明」にもHTMLを使えてしまうので、それならサイト管理者は今まで「サイトの説明」に書いてたことを「短いサイトの説明」にコピペするだけになるんじゃないかなあ。結果としてサイドバーやmetaタグの説明文にまで長いHTMLが書かれることになる。
サイト設定の「短い説明」も普通にHTMLタグが使えるらしい。入力欄の説明には特に書いてないけど。
さくらのストレージもそうだったけど、障害が始まると長いのはなんでだろうね
このアカウントは、notestockで公開設定になっていません。
絵文字カテゴリ対応のiOSアプリ、 
tootoiseも仲間に入れて！
カスタム絵文字のカテゴリ別表示ができるマストドンアプリはまだiOSにはないんだっけか
アプリ的には古いサーバも動作対象なので、両方記載する方向かなあ
HTC Desire(Android 2.0～)を相当雑に扱ってたら4-6年くらいで焼き付きましたね
サイト設定のサイトの説明は使われなくなるらしい。短いサイトの説明だけが使われるようになる。
アプリが表示するサーバ情報も変えないとなあ
@galaxis fixed on 3.8.3. beta channel on play store, or direct download from release page on github.
@neruru 試験リリースのAPKをいれたらなおるよ
Wasabi、安いのはいいんだけど安定性は見ての通りなのでDigitalOcean Spacesの方がバランス良いよ。もちろん外部のCDNと組み合わせて課金さげる
(LTL)パソコン工房かツクモ。ドスパラは中華SSD組み込んで知らんぷりした前科があるのでオススメしない
(LTL)探すの大変だから、トゥートのURLわかったら教えて
よそさまからカスタム絵文字を持ってくる時に重複が分かりやすくなるといいなあ…
du -b でファイルサイズの合計。-bなしだとブロックサイズにアライメントしたのを合計する。
オブジェクトストレージでバイトサイズで課金される場合だと、ブロックサイズを気にする必要はない
HUAWEI MediaPad M5 Pro になんかアップデート来てるな…
の投稿
WandelStock@mastodon.art
このアカウントは、notestockで公開設定になっていません。
@Cutls フラッシュメモリは長期間通電しないとデータが失われるのです。メモリじゃなくて使い方が悪い。
なおSTの場合は「最初から赤字前提なのでコストのかからない構造にする」方針なので割となんとかなってます。
サーバ1つのためにクライアント作るとか今考えたらバカげた時代もあったものですよ。
ああ、むしろクライアント作るためにサーバたてたとかならあるよ。
STのタブレットモードでレイアウトが崩れてるらしい対応は後で…。
@toneji うちはdockerなのでこんなですね
*/5 * * * * docker exec -it mastodon1_db_backend_1 psql (認証回りは書けない) -c "update tags set usable=true,trendable=true,listable=true,reviewed_at=current_timestamp,updated_at=current_timestamp where reviewed_at is null;"
未審査(審査時刻がnull)のタグに対して、チェックボックス3つを有効にした状態に更新します。審査済みのタグには手をつけないので、既存のNGタグを変更しちゃうことはありません。
@toneji うちはdockerなのでこんなですね
*/5 * * * * docker exec -it mastodon1_db_backend_1 psql (認証回りは書けない) -c "update tags set usable=true,trendable=true,listable=true,reviewed_at=current_timestamp,updated_at=current_timestamp where reviewed_at is null;"
未審査(審査時刻がnull)のタグに対して、チェックボックス3つを有効にした状態に更新します。審査済みのタグには手をつけないので、既存のNGタグを変更しちゃうことはありません。
ハッシュタグ承認すごくめんどくさいので未審査のタグの承認をcrtontabにぶっこんだ。runじゃなくてexecだからメンテナンスの時もまあ困らないやろ…
断酒して2年が経過した。なきゃないで困らないものだ
風邪で熱が下がらなくてふらふらしてる。
部屋を28度に保ちたいんだが、ダイキンのエアコンは冷房を指定すると効きすぎるし、自動モードは勝手に調整される温度に相対+5度までしか指定できない。エアコンのグレードは低くないんだが、うまくないなー。
とりあえずissue投げた https://github.com/tootsuite/mastodon/issues/12114
ところが /about では site_short_description しか参照されてないので、短い説明をカラにするとaboutが寂しくなるのだ。
%p= @instance_presenter.site_short_description.html_safe.presence || @instance_presenter.site_description.html_safe.presence || t('about.generic_description', domain: site_hostname)
とか
description ||= strip_tags(@instance_presenter.site_short_description.presence || @instance_presenter.site_description.presence || t('about.about_mastodon_html'))
とかなので、短い説明があればそちらが優先して使われるらしい
site_description は app/views/application/_sidebar.html.haml と app/views/shared/_og.html.haml で使われてるらしい。
https://mastodon.juggler.jp/about/more のテキストは「カスタム詳細説明」です。私が知りたいのは「サーバーの説明」が表示される場所。
https://mastodon.juggler.jp/about に出るのは「短いサーバーの説明」だった。「サーバーの説明」ってどこに表示されるんだ…？
マストドン、いつからかサイト設定のサーバー説明でHTMLバリデータが入ってタグの閉じ忘れとかがエラー判定されるようになりました。「入力文字列の外側に<p>～</p>がついた状態で検証される」「Pタグは入れ子にできない」ので、段落を区切りたいときは「閉じてから開く」で行けます。pタグを全く使えない訳ではありません。
@estpls 入力部分の外側に見えない<p>～</p>で囲まれた状態でバリデートされるというのが真実です。そして<p>の入れ子は許容されません。
このアカウントは、notestockで公開設定になっていません。
@Cutls AndroidのWebブラウザでのログアウトとOAuth認証まわりが雑なまま放置されてるのが致命的だよ
https://togetter.com/li/1412832 キズナアイ、中国に売られて釣魚島だの中国台湾省だの書かれた地図を背負う。闇が深いぜ
ニコンもキヤノンもソニーも、別にクイックリターンミラーやオートフォーカスやミラーレスの先駆者だった訳ではないんだよ
先進性の話からなぜか昔話に飛ぶあたりがなあ。別ジャンル、例えばデジカメで同じようなこと言う人がいたら変だと思うのにね
OSやUIそのものがどうこうというより、Appleは通話の他デバイスとの共有や顔認識のAPI化やペンの使用体験では先に進んでるというのはある。残念ながらGoogleはハード屋というよりは広告屋なので、ハイアマ向けの体験は売っていない。
顔検出AFは2005年のニコンCOOLPIX7900、瞳検出AFは2010年のオリンパスE-PL2が最初。
ただしXMLでのUI生成が配慮してくれてる部分がなくなるので、ワナは多い。minWidthとminimumWidthを両方設定しないといけないとか、id=View.generateViewId() を指定しないと入力部品の状態保存が行われないとか。
素人にはお勧めできない
Anko Layouts はXMLではなくDSL によるUI定義を行うのでXMLや属性の識別子を解釈する手間がなく、さらに定義中に参照変数への代入を行えるのでfindViewById() によるビュー階層探索を大幅に減らせる。
以前STのタイムライン項目を移行した時は、UI部品の生成にかかる時間がXMLだと秒30回だったのをAnko Layoutsだと秒40回にできた。
ユーザから見て「新機能」でも「不具合修正」でもない変更はリリースノートに書かないことがある。
期待どおりに動けばユーザは違いに気が付かず、ただ軽くなったと思うだけだ
#SubwayTooter 3.8.1。リリースノートには書いてないけど、カラム部分のレイアウトをXMLからAnko Layoutに移行してる。2013年の端末で動作確認してたらそこが重かったのでついやってしまった。不具合報告まってるぜ！
@keizou 苦笑するしかない。ここ数年ずっとこんな感じ https://www.businessinsider.com/graphic-iphone-6-v-nexus-4-2014-9 ノッチも多眼カメラも時計も別に初めてじゃない。
@smkw https://github.com/tateisu/SubwayTooter/releases/tag/v3.8.1 にあるAPKをお試しください。
@higahako コンテテキストメニューの削除はメニュー内の「あなたのトゥート」の中に移動しました
@smkw ご指摘ありがとうございます。あー、3.7.7あたりからインスタンス情報APIを使う部分を変更した時にバグを作っちゃってましたね…。直します。
