もちつけ
しゅいろ 
(@syuilo@misskey.xyz)の投稿
このアカウントは https://misskey.io/@syuilo に引っ越します
---
Author and project lead of #misskey.
Misskeyの作者。主人→@AureoleArk
好きなこと: 近所を散歩すること、写真を撮ること、眠ること
最近はお菓子を食べることも好き
#misskey #藍ちゃファンクラブ #DTM #BitwigStudio #写真 #アズレン #わーーーーーーーーーーーーーーー #web
Because I can not understand English, I may not be able to answer questions.
SELECT DISTINCT note.*
FROM note
INNER JOIN drive_file
ON drive_file.id = ANY(note."fileIds")
WHERE drive_file.type like 'image/%';SELECT DISTINCT note.*
FROM note
INNER JOIN drive_file
ON drive_file.id = ANY(note."fileIds")
WHERE drive_file.type='image/jpeg';なるほど～！
試してみます ありがとうございます
実際には投稿のfileidは配列なので少し改造が要りそう
ファイルにはそのファイルがどの投稿に添付されているかなどの情報はない
投稿にどのファイルを添付しているかという情報がある(IDの配列)
ただ別にどの投稿にどのファイルが添付されているかという情報を表すテーブルを作るのでもいい
投稿テーブルとファイルテーブルがあって、投稿には複数のファイルを添付できる ファイルにはファイルの種類を表すtypeカラムがある
ここで typeがimageのファイルがひとつでも添付された投稿をすべて取得したいとき、どんなSQLを書けばいいんだろう
Fediveserがスパムに対してどれだけ脆弱かそんなん最初からみんな分かってると思う 面倒だしそこまでスパムもいなかったからフィルタのようなものを実装してなかっただけで
@howaito516@misskey.m544.net API上では実装されてるけどUIが思いつかない
このアカウントは、notestockで公開設定になっていません。
Misskey11では削除系の処理が強化された
例えば投稿を削除したらその投稿への返信やRenoteも削除され、その投稿への返信やRenoteに対する返信やRenoteも削除され... と連鎖し、関連するすべての情報がリンクして削除される
普通時間は1970年から数えるけど、少しでも寿命を延ばすため2000年から数えるようにした
謎のIDの仕様を作った(ただ互換性の問題が...)
この仕様にそってIDを生成すると 7qxk2ttpw92z のようになる(12文字)
2089年までは大丈夫 それより未来で生成しようとするとおかしくなる
ただMisskeyが2089年時点で現役の可能性は低いので気にしない
このアカウントは、notestockで公開設定になっていません。
@mei23@misskey.m544.net その人がどんな投稿をしているかは分からない
そのユーザーの詳細なプロフィールを見ることなくフォローを決断するケースは少ないように感じる
Misskey v10
Misskey v100
Misskey v1000
Misskey v10000
あとさっき新たなコミット追加したからもしブランチ最新じゃなかったら追従しておいてください＞＜
昔のMisskeyは画面に雪降ってたよ(冬季限定)
RE: https://misskey.xyz/notes/5c9cdda2107d68002ea40108
私にも似たような癖がある 私の場合は「え、嘘でしょ？」だけど
https://twitter.com/aureoleark/status/1111227078681100289?s=21
このアカウントは、notestockで公開設定になっていません。
xyzはいつでも移民受け入れできる
でもLTLが無いことを考えるとめいめいサーバー等の方が馴染みやすいかもしれない
このアカウントは、notestockで公開設定になっていません。
フレニコ、比較的大きいインスタンスとはいえ何千人ものアクティブユーザーがいるわけではないと思うのでそこまで運営にお金がかかっていたとは思えない
だからどちらかというと経済的な問題というよりは運営自体(スパムの対処など)が大変だったから閉鎖するのだと思う
ユーザーがアップロードしたファイルを勝手にいじるようなことはしないので、サムネイルだけ作成して元のファイルはそのまま
私も毎月1000円寄付してる
RE: https://misskey.xyz/notes/5c9cb3f0107d68002ea265d5
他の人とコミュニケーション取る目的なら別に良さそうだけど、ブログとして使う場合はキツイ
何回でも言うけど分散型の最大の欠点は簡単にインスタンスが閉鎖してしまうことだな
インスタンスが閉鎖するとアカウントや投稿も消えたと同然になる 他のサーバーに残ってる可能性はあるけど...
結局そういうのを考慮すると自分でインスタンス作成しかないんだけど、一般の人にとっては手間がかかるしコストも発生する
このアカウントは、notestockで公開設定になっていません。
TypeScript: 2 syntax errors
TypeScript: 297 semantic errors
かなり減ってきた
@hina@mstdn.maud.io Misskey as a Service
このアカウントは、notestockで公開設定になっていません。
藍ちゃんとか人が操作することのないアカウントに対してトークメッセージ送る方法もある
APIではできる
クライアントのUIが思いついてないだけで
RE: https://misskey.xyz/notes/5c9b0e46107d68002e98af72
MisskeyのデータベースPostgreSQLにするわwwwwwwwwwwww
このアカウントは、notestockで公開設定になっていません。
MisskeyのモバイルUIはiPadにも最適化されている
私がiPad使いだから
Proのぬるぬる感をまこちゃんにも体験して欲しかったところだけど高いからしょうがないね
グギギギギ… っていうワイヤーが軋むような音が聞こえると思ったら髪の毛が耳に入ってた
とりあえず何かの縁だと思って Star はしておきました
RE: https://misskey.xyz/notes/5c9a3684107d68002e9497ea
JavaScriptでSnowflakeIDを生成するライブラリ無いかな〜と思って探したら、snowflakesってのが見つかって お、あるじゃんと思ったらただ雪を降らせるだけのライブラリだった
https://github.com/hcodes/snowflakes
このアカウントは、notestockで公開設定になっていません。
仮想DOMは実際のDOMではなくJS上に疑似的に構築したDOMのことだった気がする
内部的に変更を追跡するために用いられる手法だった気がする
それよりもっと前は
MySQL - (without framework) - jQuery - PHP
だった
Misskey 10: MKVN
MongoDB、Koa、Vue、Node.js
Misskey 11: PKVN
PostgreSQL、Koa、Vue、Node.js
PostgreSQLでJavaScriptのDate型を保存するのに最も適した型は何？
PostgreSQLのJSONサポートが貧弱なので、JSON型は使わずにオブジェクトをフラットに自動変換して保存することにより事なきを得た
例えば { x: { y: { foo: any, bar: any }} という型ならば
x_y_foo と x_y_bar というカラムが生成される
このアカウントは、notestockで公開設定になっていません。
キックの音程がコード進行に合わせて上下するタイプのハードコアテクノはあんまり好きじゃない アクセントで一時的に上がったり下がったりするのはいいけど、基本的にはずっと同じ音程で鳴っててほしい
大人しくTypeORMの型定義フレンドリーじゃないクエリビルダーを使うしかないようだ
ここで動いてる様子を見れます
http://sqlfiddle.com/#!17/3b217/3
RE: https://misskey.xyz/notes/5c97995b0663710027f50ec8
サブクエリ対応したぞ
IDが 2 のユーザーがフォローしているユーザーをすべて取得するクエリ
良い感じ
const sql = Q.And(q => [
q.Equal('name', 'alice'),
q.NotEqual('age', 42),
q.Or([
q.Equal('id', 1),
q.Equal('id', 2),
q.In('id', [7, 8, 9])
])
]);最終的にこんな感じに
https://pastebin.com/xH9VH2hD
@megumeru@misskey.dev ニンテンドーDSでプログラム書けるソフトみたいなのがあってそれやり始めたのがきっかけ
その後 VB --> PHP, JS --> C# --> TypeScript みたいな流れだった気がする
SQLジェネレータのプロトタイプできた
遊んでみて
https://bit.ly/2HQvUN9
良くない？
ちゃんと型定義効いてるよ
例えば q.Equal('name', 42) みたいにカラム名と型が一致していない場合は怒られるし、q.Equal('foo', 'alice') みたいにそもそも存在しないカラム名を指定しても怒られる
内部的にSQLを使うのは別にいいんだけどプログラマがSQLを書くのは辛い
繰り返すけど型定義と相性が悪いから
