tmytのらくがき

個人の日記レベルです

オカムラのSylphyを買いました

ちょっと前に会社を辞めてフリーランスって感じでお仕事をしていたのですが、最近ラップトップじゃなく椅子で作業することが増えてきました。 で、ずっとコーナンの1000円ぐらいのパイプ椅子を使ってたけど、いい加減つらくなったので新しい椅子を買いました。

オカムラのSylphyというやつです。

www.okamura.co.jp

Sylphyの中でも買ったのは、エクストラハイバック、背メッシュ、稼働肘、黒、アルミ足という設定のものです。ようするに、背もたれがメッシュで、高くて、ヘッドレストがついてるやつ。色は赤。赤かっこいい。ちなみに品番はC68ABR-FMP9 です。

椅子探しの旅

椅子ほしい!って言ったら、みんなにバロンがいいよ、アーロンにしなよ、とか言われたのでとりあえず大阪南港のIDC大塚家具へ。

今回椅子を選んだポイントは

  • ヘッドレストがある
  • 座面はクッションがいい
  • 背もたれはメッシュがいい

です。

いろいろ椅子が置いてあるゾーンがあるので座った結果オカムラのSylphyの背もたれがめっちゃ好きだったのでその日はそれだけ覚えて家に帰りました。

後日、グランフロント大阪 21Fのオカムラショールームへ。 ここ、さすがショールームというだけあって、オカムラの椅子とか机とかそういうのが山ほど展示してあるんです。その中で今回はSylphyを探しに来てたのでした。

ショールームでエクストラハイバック、背メッシュを試してみて、背もたれのフィット感がたまらないな、ということを再確認して、その日は帰りました*1

なんでSylphy買ったの

Sylphyを選んだ理由は

  • ヘッドレストがある
  • 背メッシュ/座クッションが選べる
  • すいつくようなフィット感の背もたれが最高
  • 前傾リクライニングができる

です。

特に背中のフィット感が最高だったのが一番の決め手でした。

このSylphyはレバーで背もたれのカーブが変更できます。

f:id:tmyt:20181116103533p:plain

僕はこれを狭いカーブにして使っています。ちょうど背中のふちが椅子のカーブの端っこかなー、ちょっと椅子のほうが広いかなーみたいな感じにフィットするのがめちゃくちゃ好みでした。

まさにこれ。これが好みだと、バロンとかアーロンじゃなくてこっちが好き!!ってなるので近くにショールームあるならぜひ一度試してほしい。

あと、そんなに高くない*2のもうれしいですね。

買った場所

Kagg.jpで買いました。会員になると意味が分からないくらい安くなります。本当に意味が分からない。

www.kagg.jp

発注から1~3週間で出荷。と書いてましたが、実際には配達まで1週間でした。

  • 2018/11/08 15:55:注文
  • 2018/11/08 17:20:納期確認中メール
  • 2018/11/12 11:50:納品日連絡
  • 2018/11/16 10:00:納品

こんな感じでした。配達は、メーカーから直接配達されてきます。玄関先で梱包の段ボールから椅子を取り出して、玄関先納品でした。クソでかい段ボール*3はおじさんがそのまま持って帰ってゆきました。

まとめ

  • Sylphyめっちゃいいからおすすめ
  • Kagg.jpの値段設定が意味不明

*1:ショールームは販売やってない

*2:十分高い。税込み10万切ってるのは神。

*3:たぶん70x70x120くらいあった

Twitterの一部API廃止に伴う影響について

Twitterでは一部お伝えしましたが、2018年8月16日にTwitter社が以下に挙げる一部APIが廃止します。

  • UserStream
  • 旧DM

このAPI廃止に伴い以下のそれぞれの機能が利用できなくなります。

  • Azurea
    • UserStream
    • DM*1
    • イベント通知
  • Aristea
    • UserStream
    • 通知カラム
    • イベント通知
    • Push通知

UserStreamが廃止されることにより、リアルタイムにタイムラインが流れることはなくなります。 Twitter社はこのAPIの後継としてAccount Activity API(AAAPI)を提供することになっていますが、このAPIはUserStreamの完全な置き換えになるとはいえません。

  • タイムラインが流れてこない
  • 受信にサーバーが必要
  • 1アカウント当たり約2500円/月の費用が発生する

これらより、Aristeaその他ではAAAPIをサポートすることはしません。いままでありがとうございました。

なお、RESTでのタイムライン読み書きは継続して利用可能ですが、2018年9月に予定されているTwitter社のAPIアップデートでアプリ利用者全体で3時間当たり300回しか書き込めなくなるため、サードパーティーの時代は幕を閉じるものとなりそうです。

*1:後日新DM API対応へのアップデートを配信するかも

Essential Phone PH-1を買いました

去る2018年7月16日(太平洋夏時間)にアメリカのAmazon.comでPH-1が249USDだったのでせっかくだから買ってみました。

Amazon.com向けのHalo Grayっていうやつ。フロント全面ガラスはやっぱりいいものだ…

とりあえずPを焼く

探せばすぐに出てくるけどPの焼き方

  1. https://www.essential.com/developer/developer-preview からOTAパッケージをダウンロードする
  2. USBデバッグを有効にする
  3. adb reboot recoverty
  4. ”!”が出たら、下のどちらかの操作をする*1
    • 音量下を押しながら電源を押して、さらに音量上
    • 電源を押しながら音量上
  5. Apply update from ADBを選択
  6. adb sideload <<ZIPのパス>>

そのほか

  • ガラスは素敵
  • さらっとした裏面も素敵
  • モノクロカメラはちょっと楽しい
    • アプリから使う方法は謎

*1:僕は2個目だったけど、白を買った友人は上の操作だったらしい。

Windows Phone 8.1向けのAristeaについて

Aristeaは新規ダウンロードを停止していますが既存ユーザのみなさま向けにちまちまバージョンアップを続けています。

5月半ばごろに、Windows向けリリースはWindows 10 15063以降のみのサポートに変更しました。 ですが、Windows 10 MobileおよびWindows Phone 8.1向けは歴史的経緯によりWindows Phone 8.1以降を継続していました。

いままでサポートが続いていたWindows 8.1向けリリースですが、次の次のリリースをもってサポートOSを次のように変更する予定をしています。

平たく言うと、Windows 10 Mobile (ビルド15063)未満がサポート対象外となって、アップデートが配信されなくなります。 15063が配信されてない端末の皆様には残念なお知らせですが、さすがにそろそろ古い環境と整合性を取りつつ最新の機能の取り込みが苦しくなってきた*1のでお許しください…

14393サポートないと困るよ!という声がたくさんあれば考え直すかもしれません…

*1:のとUWP移行が整ってきた

InlineUIContainerで追加したImageがOverflowしたときに非表示にする

UWPのRichTextBlockとInlineUIContainer周りでなんだか微妙な気持ちになりました。せっかくなのでエントリしておきます。

TL;DR

  • RichTextBlockに追加したUIElementはOverflowしても非表示にならない
  • InlineUIContainerからGetCharacterRectで矩形を取得して表示判定をする
  • SizeChangedとかで表示非表示コードをいい感じに実行する

いい感じに動いてほしいコード

UWPのRichTextBlockはInlineUIContainerクラスを経由すると任意のUIElementを子要素として持つことができます。 たとえば、RichTextBlockの中に画像をインライン表示したい。とかがよくある要件かと思います。

これを簡単に実現するとこんな風なXAMLになります。

<RichTextBlock x:Name="Text" TextTrimming="CharacterEllipsis" TextWrapping="NoWrap" IsTextSelectionEnabled="False">
    <Paragraph>
        <Run Text="aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa"></Run>
        <Run Text="aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa"></Run>
        <InlineUIContainer>
            <Border Background="Blue">
                <Image Source="Assets/Square150x150Logo.png"
                       Height="{Binding ElementName=Text, Path=FontSize}"
                       Stretch="Uniform" MinWidth="5"/>
            </Border>
        </InlineUIContainer>
    </Paragraph>
</RichTextBlock>

なんかうじゃうじゃ書いてますが、実行するとこういう画面が表示されます。

f:id:tmyt:20180702013821p:plain

期待する結果は表示しきれなくなって文字列が"..."で省略された時にこの画像部分が非表示になってほしいのですが、 何もしないとこうなります。

f:id:tmyt:20180702013850p:plain

釈然としませんが、SizeChangedあたりであふれたかどうか判定をしたうえで、Opacity = 0にするようなコードを書くと期待した結果になります。

うまく動かすコード

このコードをSizeChangedあたりで実行すると、なんかいい感じになります。

foreach (var inline in ((Paragraph)Text.Blocks[0]).Inlines)
{
    if(!(inline is InlineUIContainer container)) continue;
    var uiElement = (FrameworkElement)container.Child;
    var elementStart = container.ElementStart;
    var elementEnd = container.ElementEnd;
    var rect1 = elementStart.GetCharacterRect(elementStart.LogicalDirection);
    var rect2 = elementEnd.GetCharacterRect(elementEnd.LogicalDirection);
    uiElement.Opacity = rect1.Left == rect2.Left ? 0 : 1;
}

ただし、このコードはいくつかの決め打ち要素が含まれています。

  • TextというRichTextBlockがある
  • RichTextBlockのBlocksは1個だけ、しかもそれはParagraph
  • Paragraphの中にネストしたParagraphは存在しない

RichTextBlockが決め打ちなのは各自使いやすくしていただくとして、 Blocksの中身が2個以上だったり、Paragraphじゃない場合があったり、 Windows Runtime環境下では、Blockの派生クラスとして実装されているのはParagraphのみでした。 Paragraph直下以外でInlineUIContainerを含む場合の対応が必要な場合は 各自カスタムして使ってください。

これを実装して、実行するとこんな結果になります。

f:id:tmyt:20180702013934p:plain

UIElementが非表示になっていい感じの結果です。見えないだけで水色っぽいところに配置されています。

ちょっとだけ解説

TextPointer.GetCharacterRectは隣接するテキスト境界のバウンディングボックスを返すような関数らしいです*1。 これを呼び出したとき、コード中のrect1.Leftrect2.Leftは内包するUIElementがあふれていない場合異なる値を返します*2

しかし、あふれている場合に呼び出すとrect1.Leftrect2.Leftは同じ値になります。以降どの文字を調べても同じ値が出てきます。 どうやらこの値は、RichTextBlock.ActualWidth - "...の幅"くらいの値になってるようです*3

という挙動から、2つのRectのLeftプロパティが同値の場合はOpacity = 0とすることで、UIElementを非表示にしています。 ここで、Visibility = Hiddenにすると、2つのLeftプロパティが同値になってしまい再度表示する場合の判定ができなくなります。 また、UIElementのActualWidthが0になると同様に判定に失敗します。今回はMinWidth = 5とし、最低5px確保することでActualWidthが0になることを回避しました。

気が向いたらBehaviorにするかもしれません。

*1:https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.documents.textpointer.getcharacterrect#Windows_UI_Xaml_Documents_TextPointer_GetCharacterRect_Windows_UI_Xaml_Documents_LogicalDirection_

*2:だいたい rect1.Left + UIElement.ActualWidth == rect2.Left になります。厳密にはちょっと違う

*3:内部的には"..."の手前に全部幅0で表示してますよ。という感じなのかもしれない