あずにゃん
Cの次に背が高い人のやつ、文章の意味を理解せずに単語だけ拾ってそれっぽい解釈をくっつけるだけの人がかなりの割合で存在するという説の傍証なんじゃないの
@ahiru SQLと違って既存のクエリをコピペしてきて改造することが多いので対等な比較ではないけど、それでも補完が結構効くのはありがたい。あと先にデータセットを書いてからフィルタを書いてフィールドを選ぶというように、詳細度の低い方から高い方になるよう並んでるので、そこがごちゃ混ぜのSQLより読みやすい
@ahiru 一応OSSなので参考にどうぞ https://opensource.indeedeng.io/imhotep/docs/sample-queries/
クエリ言語はSQLと同程度の表現力があるけど、Imhotepというシステム自体はこのクエリをRDBとは違う独自のセマンティクスで評価するのでサンプルを触るときは注意
このアカウントは、notestockで公開設定になっていません。
結局人間は愚かとはいえパイプラインを考えられる程度には賢いので、ヘビーに使われがちなシステムではDSLを変に自然言語に寄せるよりはコンピュータとの親和性を取ったほうが良いみたいな話だと思っています
このアカウントは、notestockで公開設定になっていません。
アトリエに社会性を破壊されたため、月曜の労働再開に向けてどうやって体調を整えればいいのか分からなくなってしまった
@toshi_a 一応補足しとくとソフィーちゃんの使用済みコートが欲しいって意味じゃなくて、あれと同じコートが欲しいって意味ですよ??
適当なWebアプリを書くのに真面目にREST API書いてフロントエンド書いて……ってやってると手数ばっかりかかってどうしようもないのでもっと軽量なやり方を身に着けたいな
今ならFirebaseと和解できる気がする。AWS Amplifyもよく知らんけど似たようなことやってくれるのかな?
REST API書くとDB ModelとView Modelを作る必要が出てきて、View ModelはフロントのJSで再定義された上でRedux stateの一部になるので都合4種類のモデルと操作を書く必要があって、スケールが小さいと面倒ばかり増える
#暗号解読 第38回 クリアしました
■■は■たが■をみ■め■■■■■は■く、■もに■■じほ■■■をみ■め■■■■■■。
https://puzzlega.me/cryptogram/