新しいものを表示


* 会話スレッド、通知以外のレイアウト案を完成。
TODO
* 右ペインの表示内容、表示順。
* 通知画面のレイアウト。
* 会話スレッドのレイアウト。
ここまで決定しておけば、プログラムに落とし込むのは多分そんなに手間かからなそう。

9月までにUIだけは完成目標。

マストドンのざっくりした解説的なものを書きました 
合ってなかったらごめんなさい!!!

Google Photoの画像から顔を、Twitterの文章からしゃべり方や好き嫌いを学習させて、死んだ人間と話せるようになるツールをもう作れると思うんだけど、流石に企業はやらないなぁ。
個人で画像に関しては検討している人はいたけど。

東京新聞すごい!
公式ページで精神疾患患者の身体拘束について「地域で見守る態勢に本腰を入れるべき」との見解を示していた。
具体的に社員の何割を福祉事業に宛てる、との記載はなかったが、社員約2500人だから、各社員年に1日動員するだけでも拘束件数の1/4を担える!
tokyo-np.co.jp/article/261541

あと、かなり謎なのがどのアプリもドロワーを左にしているけど、右利きが多い中何故左にするんだろ?
ホームからViewPagerでリストとかに切り替える人が多いから誤操作防止かな?
単にTwitterに習ってるだけとも思うんだけど。

今回、clean architectureで組むつもりだから、アプリ作ってる時間より勉強してる時間の方が長い疑惑。
いつもならUIが一番時間かかるけど、今回はAPIとのやりとりに一番時間かかりそうだし、早めにUIまでは作っちゃいたいんだけどなぁ。

今、いろんなMastodonクライアントを触りまくって、UIのお勉強をしているところ。
Twitterとかのアプリって、内容を読んだ後にお気に入りにするなり、リツイートするなりするはずだから、文字の下にそのボタンはあるべきと自分は考えている(多くのアプリ)。
もしくは、タイムライン上での誤操作を防ぐためにタップした際にメニューが出るのも良いと思う(ZonePane)。
しかし、一部アプリ(Ivory)は上に表示するようにしていて、その設計にした理由がすごく気になる。何らかの利便性を考慮していると思うんだけど、デザインの合理性が分からないんよね。

Use caseの説明がわかりやすかった。
要はentity (= データ保管場所)からデータを出し入れする際に、そのデータと使い方(= use case)を定めるところ。
保管してある自分の投稿リストをentity (= データ保管場所)取得しても、その中で人気のだけ抽出して「使いたい」場合、アプリの動作をControllするControllerでやるべきじゃなくて、Use caseでやるべきって話と認識した。
wantedly.com/companies/progrit

デザイン部分とコード部分が完全に別れているXMLが好きだったけど、この記事読んだら確かに宣言的UIの良さがわかった。
実際に過去に作ったプログラムも宣言的UIの方が軽量で簡潔に書けそう。

techblog.zozo.com/entry/zozoto

デザイン部分とコード部分が完全に別れているXMLが好きだったけど、この記事読んだら確かに宣言的UIの良さがわかった。
実際に過去に作ったプログラムも宣言的UIの方が軽量で簡潔に書けそう。

techblog.zozo.com/entry/zozoto

七夕だから願い事考えるか、と思った。
織姫はどちらかというと技術寄りの存在だから、祈るなら技術に関することにせよ、と助言を受けた。
しかし、「どうでもよいことは流行に従い、 重大なことは道徳に従い、 "研究"のことは自分に従う」(小津安二郎 一部改)というし、ならば願うことはないか。

鯖缶さんは絶対大変だと思うし、実際のところうまくいくかわからないけど、ThreadsがAP対応して、これまでClosedだったSNSが開かれた物になるのはほんとに革命的だと思う。
AP自体がそうなんだけど、大手が対応するのすごいよね。

Mastodonの鯖缶には是非ともタイムラインに広告を出してほしい。
サステナブルなの大事よ。


* アプリ名決定
* Githubにレポジトリ作成
* 画面遷移図作成中(左ペイン暫定完成)

9月までにUIだけは完成目標。

UI検討中。
我々は最適化されてるからハンバーガーメニューを認識できるけど、猿でも分かるメニューはどうしたらいいだろうか?

古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。