違法コンテンツPoisoningを法律で禁止してほしい
根本的な問題はいきなりサーバ止めるNTTグループの運用がダメというやつなので、そのへんに理解のありそうなアダルトOKなVPS業者を使う方がよいのかもしれない
将来kotlinに追加されるかもしれない機能 https://drive.google.com/file/d/0BwAovUlww0CmVmNQTXd4TTdKYUU/view
お、Android StudioからAPI 28 のソースを参照できるようになった。エミュで新機能のテストするアプリくらいは書いてもいいかなという気分になった。あとはAndroidX のリリース待ちと各種UI部品ライブラリの更新待ちだなー
https://android-developers.googleblog.com/2018/07/supporting-display-cutouts-on-edge-to.html ディスプレイのカットアウト、 #subwaytooter では特に何もしてないけど何かした方がいいんだろうか。まず端末を持ってないのと、API28はソースをまだ見れないので使いたくないのとであまりやる気がない
TAIなどの暦に基づかない時刻表現をUTCなどの暦に基づく表現に変換するには、うるう秒がいつ発生したかを知る必要がある。たとえばGPSの時刻は基本的にはTAIなのだが、過去に発生したうるう秒の数も共に配信されてるので過去の時刻についてはUTCなどへの変換ができる。
読み捨てられる秒があるのが怖いようなシステムは、時刻表現にTAIや端末起動時からの経過秒数を使う。たとえばdjbのいくつかのソフトウェアはログの時刻表現にtaiを使っていた
うるう秒が未来のいつ発生するかは人間が恣意的に決めることなので、うるう秒をカウントするタイムゾーンが設定された端末ではunixtimeベースの日時計算を行うと未来の日時を正しく計算できない。例えば10年後の正午までの秒数は推測でしか計算できず、うるう秒によって何秒ずれるかは正確にはんからない。一方でエポック以後のうるう秒については全て分かっているのでより正確な計算ができる。良し悪しだ。普通のタイムゾーンで同じ事をすると、未来については暦との一致性は増すが、秒数そのものはより不正確になる。
unixtimeはうるう秒を読み捨てるというのがposix規格だけど、世の中にはそれを読み捨てない(カウントする)タイムゾーンが設定されたマシンも存在する。そんな端末で現在のエポック秒を取得すると普通の端末と異なる数字が帰ってくる。unixtimeは絶対ではないのだ
@toudouyouhei カラム設定の添付メディアとか、サイドメニューのお気に入りとか、トゥートの…メニューの中とか?
このアカウントは、notestockで公開設定になっていません。
Happy birthday, Rin!
今日9時からiMast 3.0が配信されます。iMastがApp Storeに公開されたのは2017年8月10日なので、ちょうど一周年です。
今回は、プッシュ通知を始めとした、「今までiMastにはなかったけどあると便利な機能」をいくつか実装しました。
(公開されたら)ぜひアップデートして使ってみてください!
また、iMast 3.0をきっかけとして公式アカウントを変更し、今後はこちらから情報を発信していきます。お手数ですが、リフォローよろしくお願いします。
リリースノートはこちら。 https://github.com/cinderella-project/iMast/releases/tag/3.0
ノートPCが届いたので
Windows 10 proのライセンスを psngamesで¥2,698でポチってアップグレードするなど。リモートデスクトップ税である
Android API 28 はAndroid StudioでAPIのソースを見れるようになったら対応を検討しよう。依存関係のUIライブラリがAndroidXに対応しそうにないとか色々あって辛いが…
@ChloroNoirHightower フレニコのサーバ側のマストドンのバージョンが古いからです
Pleromaが添付メディアの説明にファイル名を埋め込むの、誰も得しないアレな機能だと思う
Playコンソールでアクティブインストール数が結構減ってた。ユーザの動向というより何かPlayストア側の事情な感じだ。急激すぎる
Andoid Studio 3.1.3 で API level 28を試してみたらGradleさんが妙だったのでまだまだ様子見する。どうせPの端末が日本に来るのはまだまだ先だろう