GPD PocketからOneMix3 Proに乗り換えた - Runner in the High
かつてIndiegogoでバックしたGPD Pocket初代をときたま外出のとき持ち歩いたりしていたが、とうとうOneMix3 Proに乗り換えた。 性能も使いやすさも段違いになった。 www.izumisy.work ONE-NETBOOK OneMix3 Pro ミニパソコン 日本語配列キーボード搭載 ( Intel Core i5-10210Y / 16GB RAM + 512GB PCIe SSD / Windows10 / 8.4インチ 2560*1600 10点マルチタッチパネル / 360度YOGAモード / 4096段階の筆圧に対応 / バックライト付きキーボード ) ブラック メディア: 今の世の中のUMPC全体のトレンドが7型から8型台へ移りつつあり、OneMix 3シリーズに限らずMAG1やGPD Pocket P2 Maxなどもまた8インチモデル。 これはすごく理に
「チェアdeスクっと」は名前はダサいが気軽にスタンディングデスクを導入できる最強の製品 - Runner in the High
いわゆるコロナ禍で自分も在宅ワークを余儀なくされているが、やはりなんといっても座りっぱなしで問題になるのは腰。腰がイカれてくる。 Fitbitで歩数を見ても腰が壊れるのは自明で、自分はかなり通勤経路が長めの人間だったということもありこれまでは余裕で10k歩ほどあるけていたものが、ここ最近では歩いてもせいぜい5k程度にしかならない。歩かないとどうなるかというと、それは下半身のとくにハムストリングスが十分に伸びなくなるため腰痛に悩まされる。下半身を動かさない人間はだれでもみな腰痛に苦しむことになる。 これは座っていることがほとんどの原因なので、これを解決するために自分も据え置き型のスタンディングデスクの導入を検討していた。しかし、いかんせん値段が高い上に置くと机のほとんどのスペースをとられてしまう。昇降デスクも部屋狭いので置く場所がない。 というわけで見つけたのが「チェアdeスクっと」という製
Elmのモジュール分割における区分軸の観点 - Runner in the High
Elmアプリケーションにおいてモジュールを作る際に、モジュールへ機能をどう凝集させるかに関して。 機能による区分 かつてElmにおいて一般的だった分割方針。グレーの部分がひとつのモジュールを表している。 ModelとUpdate, Viewなどをすべて別のモジュールへ分割し、Userなどのネームスペース配下に配置する形で、Railsなどのフルスタックフレームワークのディレクトリ分けと非常に近い。 機能による区分 この分割方針の大きな欠点は、モジュールを不必要な単位で分けすぎていることで結局すべてのデータをモジュールから公開しなければならなくなっている点にある。 ViewモジュールやUpdateモジュールは、実装のためにModelモジュールの内部実装を知る必要がある。その結果、公開された内部実装へ知る必要のない他のモジュールが依存する可能性がでてしまう。 Elmにおいてモジュールを作る理由と
ElmでPhantom TypeとExtensible Recordを用いて型安全な状態遷移パターンを実装する - Runner in the High
このDiscourseスレッドがかなり面白かった。 OPは「幽霊型（Phantom Type）を使うと特定の順序でしか型安全に状態遷移できないように実装できると思うんだけど、どうしたらいいかな？」と質問している。 discourse.elm-lang.org 実装してみる 回答者からのアイデアによると、Phantom TypeとExtensible Recordを組み合わせて実装することで型安全な状態遷移が作れる。 たとえば、以下のようなゲーム上での状態遷移のパターンが仕様としてあるとしよう。 これを実際に今回のパターンで表現すると、このようになる。 type Transition a = Transition type Allowed = Allowed type Game = Loading (Transition { ready : Allowed }) -- ロード中 | Read
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
