「Json」を含む日記

■anond:20220120010619

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ？分かってるのか？

Permalink | 記事への反応(0) | 01:10

ツイートシェア

■anond:20220120001906

俺もわからないｗ

素のPHPみたいな方がHTMLとしてプレビュー、編集できるし、

ツールはみんなHTML形式には対応しているけど、非HTML形式のテンプレートには対応してないわけで、

JSONみたいに書けるんだぜ、とか、Pythonみたいにインデントするだけだぜ、みたいなのは、

プログラミング言語マニアの自己満足っぽい気がする

言語は思考を規定する、とか、流れるように書ける、とか、どうでもいいというか、

寧ろ、ツール群が揃ってるとか、つまらないほど使えて当たり前の方が開発は安定する

と、さっきまでNim書いてたフラストレーションもあって思いました

Permalink | 記事への反応(0) | 00:28

ツイートシェア

■涼宮ハルヒとパッケージ管理

消失の最後の方で、たしかキョンが長門の恋心？が理解できてるのかよく分からんが、

長門がいない世界になったとしても、ハルヒに長門を存在するように考えさせるみたいなことを言ってた気がするが、

当たり前だが、あの世界はハルヒが神みたいな前提で成り立ってるわけだが、

キョンや長門だけでなく、すべての人、というか物質の存在はハルヒによって成り立っているといっても過言ではない

つまり、package.jsonだかgo.modだかcomposer.jsonだか使ってる言語にもよるわけだが、

すべての依存関係に涼宮ハルヒと書かれてるようなわけであり、

つまり、すべてのソフトウェアが依存しているそのモジュールが改変されれば、

すべてのソフトウェアが影響するのと同じであり、

したがって、攻撃者は涼宮ハルヒに細工すれば、世界を思うがままに改変できるということである

つまり、涼宮ハルヒを洗脳するとか、思考を誘導するとか、

なんらかの方法で自分の意のままに考えさせることができるようになれば、

攻撃者は世界を思うがままに改変できて、それはそれで楽しそうに思えるのだった

俺がキョンならそれを試みると思うのだ

はぁ…

現実逃避終わり…

Permalink | 記事への反応(0) | 18:10

ツイートシェア

■anond:20211211003902

CSVでくれっていうコメントがあるけど、俺の感想はそれに近い

社内でしか公開しないエンジニアしか見ないプロトタイプみたいなものの場合、そもそもプロトタイプの目的はデザインの完璧さを求めることではないのでjsonでもcsvでもいいからAPIの生情報を見せろということはある

なのでどういうデザインがいいかっていうのはかなり文脈依存の問題かもしれない

Permalink | 記事への反応(0) | 00:56

ツイートシェア

■「オブジェクト指向はすでに粒度が時代にあっていない」を読んで

元記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分のバックグラウンドは以下:

• 1990年代 C でデバイスドライバとかの低レイヤーから職業プログラマーを始めた
• 途中から C++ になって、オブジェクト指向を学んだ
• Java で GUI のクラサバアプリケーションとか、Servlet とかのウェブアプリケーションを作り始めた
• 大規模エンタープライズな業務システムの開発経験あり
• Java RMI や Microsoft DCOM は少しだけ使ったことがある
• 静的型付け言語がめんどくさくなって途中から Perl, PHP, Ruby, JS(Node.js) に移行、現在に至る
• フロントエンドも並行してやっていてこの2,3年は TypeScript オンリー
• 関数型言語に関しては、Haskell, Elixir, Closure, F# あたりは嗜み程度に書いたことがある

その他の前提:

• オブジェクト指向プログラミングは難しいと感じている
• 関数型プログラミングはもっと難しいと感じている
• かといって手続き型で書くのはいまさら厳しいと感じている
• 結果的に、オブジェクト指向をベースにしつつ、純粋関数と不変変数をできるだけ使った形がいまのところベストだと感じている

本文およびブコメを読んで思ったこと

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。

元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントはちょっと論点がずれてると思いました。

はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。

ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。

個人的にわからなかったのは以下の部分です。

「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。

https://gist.github.com/posaunehm/4087971

Permalink | 記事への反応(1) | 21:43

ツイートシェア

■anond:20210827165042

「博士！解析結果が出ました！」

出力された紙テープには長々とJSONが…

Permalink | 記事への反応(0) | 18:06

ツイートシェア

■anond:20210826012139

なんでJSONに色付けする仕事でそんなに偉そうにできるんですか

Permalink | 記事への反応(1) | 01:30

ツイートシェア

■anond:20210817123214

確かに。JSON か YAML といったシンプルな方が、楽だし、そこは許して。

Permalink | 記事への反応(1) | 12:36

ツイートシェア

■anond:20210727170728

確かに保守性は最悪だししっかりサーバーとクライアント両方にデータが何かをコメントで書かないと使えない

でも全部intとかboolなら変換は簡単で10個もデータあれば150文字ぐらいは節約できて、そういうデータが10個もあれば1000文字か…みたいな感じでJSONに抵抗があった

仕事でもいるのか〜

世間一般で使われてる方法の方が100%正しいんだろうけど

Permalink | 記事への反応(0) | 18:09

ツイートシェア

■anond:20210727170141

クソザコの感想だとJSON形式より対応文字列の変更(あるいはデータベースの構造そのものの変更)に弱そうとは感じる(保守性が悪い？)

でも仕事でも似たような組み方してた人がいるのを見たことあるからOKなのかもしれん

Permalink | 記事への反応(1) | 17:07

ツイートシェア

■anond:20210727170141

よくわからんがPostgreSQLにJSONで何でもかんでも詰め込んだりしたなぁ

個人でやってるからだけど…

Permalink | 記事への反応(0) | 17:03

ツイートシェア

■データベースに配列で保存するのって公式にダメなんだな

JSONで保存するよりkey分節約できるじゃんと思ったんだけど

1999年以降はDBに配列ぶちこむのは想定してないらしい

配列というよりフラグを1,1,0とかに変換するメソッド造っておいてそれ文字で投げる行為

やっぱりその程度の節約よりわかりやすさなの？

個人でずっとやってきたからわからないんだが

Permalink | 記事への反応(4) | 17:01

ツイートシェア

■https://anond.hatelabo.jp/20210719192035

もう対抗馬さんは出てこなくなっちゃったのかね。

さみしいので俺が書いとくわ。

2021/07/20(火) の予測値 1,084 (95%予測区間 902 ～ 1,258)
2021/07/21(水) の予測値 1,350 (95%予測区間 1,177 ～ 1,534)
2021/07/22(木) の予測値 1,611 (95%予測区間 1,437 ～ 1,782)
2021/07/23(金) の予測値 1,555 (95%予測区間 1,384 ～ 1,757)
2021/07/24(土) の予測値 1,612 (95%予測区間 1,436 ～ 1,796)
2021/07/25(日) の予測値 1,273 (95%予測区間 1,088 ～ 1,452)

2021/07/26(月) の予測値 966 (95%予測区間 783 ～ 1,145)
2021/07/27(火) の予測値 1,332 (95%予測区間 1,134 ～ 1,519)
2021/07/28(水) の予測値 1,649 (95%予測区間 1,429 ～ 1,854)
2021/07/29(木) の予測値 1,957 (95%予測区間 1,722 ～ 2,205)
2021/07/30(金) の予測値 1,879 (95%予測区間 1,617 ～ 2,128)
2021/07/31(土) の予測値 1,938 (95%予測区間 1,675 ～ 2,220)
2021/08/01(日) の予測値 1,523 (95%予測区間 1,290 ～ 1,771)

2021/08/02(月) の予測値 1,151 (95%予測区間 949 ～ 1,378)
2021/08/03(火) の予測値 1,579 (95%予測区間 1,296 ～ 1,852)
2021/08/04(水) の予測値 1,948 (95%予測区間 1,615 ～ 2,267)
2021/08/05(木) の予測値 2,302 (95%予測区間 1,959 ～ 2,715)
2021/08/06(金) の予測値 2,203 (95%予測区間 1,768 ～ 2,611)
2021/08/07(土) の予測値 2,264 (95%予測区間 1,851 ～ 2,739)
2021/08/08(日) の予測値 1,773 (95%予測区間 1,391 ～ 2,155)

2021/08/09(月) の予測値 1,336 (95%予測区間 1,035 ～ 1,668)
2021/08/10(火) の予測値 1,827 (95%予測区間 1,425 ～ 2,258)
2021/08/11(水) の予測値 2,247 (95%予測区間 1,728 ～ 2,794)
2021/08/12(木) の予測値 2,648 (95%予測区間 2,054 ～ 3,296)
2021/08/13(金) の予測値 2,526 (95%予測区間 1,876 ～ 3,184)
2021/08/14(土) の予測値 2,590 (95%予測区間 1,918 ～ 3,317)
2021/08/15(日) の予測値 2,023 (95%予測区間 1,482 ～ 2,618)

2021/08/16(月) の予測値 1,520 (95%予測区間 1,060 ～ 1,983)
2021/08/17(火) の予測値 2,075 (95%予測区間 1,440 ～ 2,719)
2021/08/18(水) の予測値 2,545 (95%予測区間 1,766 ～ 3,377)
2021/08/19(木) の予測値 2,994 (95%予測区間 2,065 ～ 4,002)
2021/08/20(金) の予測値 2,850 (95%予測区間 1,946 ～ 3,818)
2021/08/21(土) の予測値 2,916 (95%予測区間 2,006 ～ 3,900)
2021/08/22(日) の予測値 2,273 (95%予測区間 1,443 ～ 3,069)

ついでにソースも公開しとくわ。Google Colaboratory に貼ればそのまま動く。

見ての通り、単に過去の感染者数を Facebook Prophet に放り込んだだけの単純なモノ。人流も変異株もワクチンも全く考慮ナシ。

適当に改良よろ。

!pip install -q fbprophet
from fbprophet import Prophet
import pandas as pd
!wget --no-check-certificate --output-document=covid19_tokyo.json 'https://raw.githubusercontent.com/tokyo-metropolitan-gov/covid19/development/data/data.json'
data = pd.read_json('covid19_tokyo.json')
date_data = []
posi_data = []
for i in range(len(data['patients_summary']['data'])):
    date_data.append(data['patients_summary']['data'][i]['日付'])
    posi_data.append(data['patients_summary']['data'][i]['小計'])
data=pd.DataFrame({'ds': date_data, 'y': posi_data})
data['ds'] = data['ds'].astype('datetime64')
model = Prophet(interval_width=0.95, changepoint_range=1.0, changepoint_prior_scale=0.5, seasonality_prior_scale=10.0, seasonality_mode='multiplicative',  n_changepoints=50)
model.fit(data)
future = model.make_future_dataframe(periods=35, freq='D')
forecast = model.predict(future)
model.plot(forecast);

Permalink | 記事への反応(2) | 22:22

ツイートシェア

■anond:20210708205945

最近のテック系の生態系を知らずに、ほとばしる若さに嫉妬して学生をぶちのめして申し訳なかったと思うようにはヒートダウンしてきた「年収270万円だった医大生」です。こんばんは！

激おこしたのは、申し訳ない。

すごく反省している。ただ、優雅に自分が学生時代に学んだ知識をもって、社会人にその勢いを保持したままで定年まで行ける可能性は高くないと私は思うのだ。おそらくは名門大で、勢いのある会社なら引く手あまたそうな貴方は自分にとっては眩しかったのだ。

フロントエンドは給料が安いという思い込みをしてました。

本当に認識不足だった。もともと Android/iPhone や jQuery で JSON の操作をしていて、PHP/Rails/Spring でバックエンド界隈から MySQL/PostgreSQLを触り、人員不足で AWS をも触って QA および SRE をしていたエンジニアだったのだけど、ブロントエンドが DB に遠いという理由で簿給だと思っていたのは、各派遣会社の給料をみる分だと間違いだと理解した。知識がアップデートされてないのはオレ自身だったようだ。申し訳ない。

Firebase や mBaaS は不味くない？

根拠は、NoSQL はスキーマ無しなのは途中までは良いけど、後で負債になる感じがするので。あと、Firebase は Google が中途でやめるとなったときが怖いぞ。JS なら express というフレームワークあるし、Kotlin もサーバーがあるから、古典的なサーバークライエントモデルで良いのじゃないかな？Next なら SSR あるし。

サイバーエージェントにくくった理由

自分のような新卒採用を逃した身分では、サイバーエージェントのような B to C 領域でトップティアにある会社に紹介してもらえるというのは「蜘蛛の糸」のような貴重なチャンスに思えたのだよ。そりゃ、ある程度は経験積めばスカウトが来るかもしれないけどさ、自分は年食っていたから「サイバーエージェントで働けるという可能性」に全力をかけたよ。その結果が、場末の未認可SES って、しかも反社だったなんて、すごくショックだったよ。クソな「自称数学者の人工知能論を聞いて土日が終わり、平日はブラック客先常駐」な日々はうんざりだ。

Permalink | 記事への反応(0) | 00:33

ツイートシェア

■anond:20210714091139

よく分からんな

要は、Enumでソース内で書くか

JSON で外に保持するかのどちらかって

話でいいのか？

Permalink | 記事への反応(0) | 10:44

ツイートシェア

■anond:20210713142310

文字列の配列ってことか？

とすると、json のキーは

番号なのか？

Permalink | 記事への反応(0) | 01:13

ツイートシェア

■anond:20210712154918

「これをやればモンハンを作れる」などというものは存在しない

ほとんどの職業プログラマは、モンハンを作れない

ハローワールド（文字列表示）の延長でHTMLやJSONを生成してブラウザに表示したりSQLをこねくり回したりするだけ

Permalink | 記事への反応(1) | 15:52

ツイートシェア

■

Excelの1セルにJSON形式で全部入れてもらったほうが助かる

Permalink | 記事への反応(0) | 15:24

ツイートシェア

■anond:20210310030108

星の数かぞえ。どう解釈すれば良いのか求む考察

ブクマの人とスターの人があんまり重複していないってのは今まで語られてこなかった知見じゃないかな

人気コメントの選択アルゴリズムがそろそろ変わるらしいので変わったらまた見てみたい

例1

長かった10代の終わり、エヴァが想い出になった日。(『シン・エヴァンゲリオン劇場版』感想 ※ネタバレ注意)｜祥太｜note

https://b.hatena.ne.jp/entry/s/note.com/shota_/n/n851f4b3faec1

2021年3月10日19時頃

このエントリの場合スター屋よりブクマ家のほうが多い

このエントリの場合、全ブクマにまんべんなくはてなスターを付けているスター屋はいなさそう

ブクマせずにスターのみ付けていったユーザーは114ユーザー、今まであまり論じられているところを見たことがない層だが結構多い。非公開でブクマしてる可能性はあるけど。

例2

なぜ日本企業だけ「テレワークによって生産性が落ちる」のか？ その根本的な理由（加谷 珪一） | 現代ビジネス | 講談社（1/4）

https://b.hatena.ne.jp/entry/s/gendai.ismedia.jp/articles/-/80990

2021年3月10日20時20分頃

ブコメ率37%

ブクマせずはてなスターのみ付けたユーザーが289とこちらは結構な比率。

こちらには新しいブコメまでまんべんなく目を通してはてなスターを付けるスター屋さんがいる。10人ほどか、初期ブコメが除外(力尽きた?)されているスター屋さんも含めると更に多い。

セルフスターを付けた方は時間的にあとからブクマした方で人気コメ戦線に絡んでくるようなスター数ではなかった。

例3

主婦が運転中に心肺停止、すれ違いざまに車内見た男性が停車させ心臓マッサージ（読売新聞オンライン） - Yahoo!ニュース

https://b.hatena.ne.jp/entry/s/news.yahoo.co.jp/articles/9b16ce8fb661f4a0f65ee609df31ed2d3105aa81

2021年3月10日20時55分頃

美談。スター工作を行う動機が無さそうなので選んでみた。

ブコメ率45%はわりと高いほうなのかも。

全ブコメにまんべんなくはてなスターを付けたユーザーはいない。前半1/4くらいまでのブコメにまんべんなくはてなスターしたってユーザーは1人いた。

ブクマせずはてなスターだけの人はここでも多い。

例4

稲田氏、「森友訴訟」に出廷記録　大阪地裁が作成、答弁矛盾 - 共同通信 47NEWS

https://b.hatena.ne.jp/entry/s/this.kiji.is/214065793666072577

2021年3月15日18時30分頃

以前から同じ傾向だったかを見るため4年前、2017年の記事。

この頃からブクマカとスター屋は別々のユーザーだったようだ。

セルフスターを5個付けているユーザーが1人だけいた。

例5

何も言わずに女性が自分のことをどう思っているか簡単に調べる方法 − はてな匿名ダイアリー

https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20150312110948

2021年3月15日18時30分頃

更にさかのぼって6年前、2015年の記事。

この頃もブクマカとスター屋は別れていた。

下衆な増田にツッコミを入れる会場になっているが、スター工作は発生し無さそうなジャンル。

例6

ネットがある種の人々から奪ったもの − はてな匿名ダイアリー

https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20130313174126

2021年3月16日1時頃

2013年。人気コメントができて2年経過後。今と似たような感じにすでになっている。

例7

声優の三石琴乃さん「業界の状況はかなり厳しい、ギャラの安い若手ばかりが使われて、大御所が呼ばれないんです 」｜やらおん！

https://b.hatena.ne.jp/entry/yaraon.blog109.fc2.com/blog-entry-1884.html

2011年。人気コメントができて1ヶ月半経過。数こそ少ないものの今の雰囲気とにている気がする。当時のブクマやスターは消えたのもあるだろうからどれだけ当時の様子が残っているのかわからないけれど。

スターのみ付けて満足できる人は当初から居たのは確かなようだ。そういう人はブクマは一切しない人なのだろうか、それともその記事はブクマに値しないと思ってスルーしただけなのだろうか。

人気コメント欄ができる前の2011年1月2月ごろのエントリを見るとスターが付いているコメントはかなり少ない。

カラースターはJSONの深いところに別途格納されていてカウント外だった。あっても2個くらいだったので影響はほとんど無い。

セルフスターを付けたユーザーを追記。

例1の公開ブックマークしスターも付けたユーザーが1人少なかったので訂正。

Permalink | 記事への反応(1) | 20:01

ツイートシェア

■Rustまったくわからん

普段、おまえは何の努力もしてないのではないか？

凡人以下ながら新しいネタとか技術とか数学やアルゴリズムは引き出しを増やすように心がけてるんだけどね

食い扶持になる可能性もあるし

しかし、未だにRustがうまく使えないというか、学習コストが高すぎる気がするんだがどうしたもんかな…

国が公開してるとあるExcelファイルを読み込んで、それを望まれるCSVやJSONに加工する、

という仕様は同じにして色々な言語で書いて比較しようと思っているのだけど、

PHPやNode.js、Python、Goは自分には問題なく書けてる

多分、C++やCも、流石に何か便利なものにvcpkgやconanとか使って依存するだろうけど書けると思う

しかし、Rustは難しいなあ

Excelファイルをパースするサンプルコードも難しいというか、長くね？と思ってしまうんだけど

これに慣れる日は来るんだろうか…

Goは学習コストが低いと思うから、とりあえず動作するコードを書くのは問題ないんだよなあ

C#とかDとかNimとかErlangとかKotlinとかDartとかもやろうかなあ

でも、少なくとも後ろ2つはほとんどJavaみたいなもんだろうか

考えてみれば、自分はHaskellが駄目なので、Rust駄目は関係があるんだろうか

Lispは方言みたいなのが多すぎてよくわからん

Permalink | 記事への反応(0) | 14:54

ツイートシェア

■「Microsoft Power Fx」がExcelに搭載されると勘違いする人が意外と多い

ITリテラシーありと自認してる人達にも多いのが意外だった。

Excelの関数をベースにしただけで、搭載されるのはPowerAppsやPowerAutomateが含まれる「Power Platform」であってExcelなどのOfficeソフトは関係ない。

Excelには(プレビューだから現時点ではWeb版限定とはいえ)もうOfficeScriptsという名のTypeScriptが既に載っていて、Excelファイルと切り離されて管理される仕組みになっている。

ostsという拡張子のファイルの中身がTypeScriptそのものじゃなくてTypeScriptを含んだjsonなのがいまいち使い勝手悪いけど、一つのostsに保存された処理を複数のExcelファイルに簡単に適用できるようになっている。

Pythonは....望み薄な感じだからPython期待を煽られて梯子外された感じになってるのは同情するよ。

Permalink | 記事への反応(0) | 11:32

ツイートシェア

■anond:20210228205029

追記しました

次にこの記事。

ツイフェミを観察して大まかな生態が分かってきたので記したい。

上位のコメント8件以上にスターをつけているのは57アカウント。半分以上のアカウントがスターをつけたIDを強調した。増田のデザインだとあまり強調されていないが。

やはり同じコメントに対してスターをつけているアカウントが多く、スター工作なのは間違いなさそうである。しかし完全に同じではなく少し違うアカウントもある。

トップのid:white_roseのコメントへのスター順も見てみる。

2番目のid:ivory105へのスター。

こちらの記事でも工作の疑いがあるアカウントは前半に多いが、工作用らしきid:trolleyGuysとid:zweiRは後からスターをつけている。

それぞれのIDのブックマークを確認したところ、上位コメントすべてにスターをつけたアカウントでもid:misogy_NEET、id:KoDoKu_Si、id:Aspeはブックマーク数がそれなりにあり、コメントも書いているので工作用アカウントではないのかもしれない。

上位全てにスターをつけていないコメントではid:bridgevierwとb:id:crybirdはブックマークが非常に少ないため工作用アカウントの疑いがあるが、他のアカウントは違うようである。スターをつけたタイミングから見ても、単に上位ブコメにスターをつけただけだろう。

まとめ

• 人気コメントを埋めるための工作なので10件だけにスターをつけているのだろうと思っていたが、そうではなく少し多めにスターをつけている。偽装なのかもしれないが、対象のコメントが同じなのでかえって怪しい。
• 上位コメントに多くスターをつけているというだけで工作用アカウントとは判断できない。工作された後にスターをつけたのかもしれない。
• アカウントごとにブックマークした記事の数や、書いたコメントの量などを調べればより正確な検証ができそうである。
• 政治関連の記事とフェミニズム関連の記事の両方に同じアカウントがスター工作をしている。

追記

前半のコメント

id:suihan74

ユーザーのブクマ数は https://b.hatena.ne.jp/api/internal/cambridge/user/{userId} をGETして返ってくるjsonに含まれてる

ありがとうございます。また検証する機会があれば使います。

id:zenkamono

お、当選してる。見てのとおり気にかかるニュースにブコメ書き連ねてるだけなので工作ではない。賛同の意を強く感じたときは複数スターつけてる（順位には影響ないよな）

同じ記事に同じIDが複数スターをつけていても1個だとカウントしています。

id:gooeyblob

「_」が随分多いけどこれはアカウント消された（or消した）ってこと？

id:ikura_chan

ん？ーって垢消えたってこと？

上位コメントへのスターの多いアカウントがいつスターをつけたのかを表したかったので、スターの少ないアカウントは見やすいようにIDを伏せました。説明するべきでしたね。

id:cameraojisan

続きで「上位コメントに多くスターをつけているというだけで工作用アカウントとは判断できない。」のあとに「工作された後にスターをつけたのかもしれない。」ってなってて工作が実在するというバイアス強すぎ

それは「上位コメントに多くスターをつけている」は工作用アカウントかどうかの判断基準にはならない、という意味です。

id:rshi

なんか当選してるけど、工作垢とかじゃないです…勘弁して…

すみませんでした。他のアカウントは違うようである、だけでなくIDを書くべきでした。

id:hisawooo

後ろの方についてるスターって工作後に「トプコメに並んでる米だけ見てスターをつけた人」とどう区別するの

工作後にトップコメントだけを見てスターをつけたのであれば、トップ以外のスターをつけたコメントがほぼ同じになることは無いでしょう。

偶然同じになることもあるでしょうが、多数の記事で同じになれば不自然です。

id:B2igwzEE

運営に報告したorする予定があるのかどうか書いてほしいんだが

今のところ報告の予定はありません。疑いが強いというだけで、間違いなく工作用アカウントだと判断できるわけではないので。

自分のコメントが工作されることがあれば、嫌がらせとして報告するつもりです。

id:tetora2

もうちょっと母数が増えないと言い切ることが出来ないかな。この程度のサンプルではたまたま意見の一致とも言える。

たしかに言い切ることはできないですね。

Permalink | 記事への反応(2) | 20:56

ツイートシェア

■はてなブックマーク一行スクレイピング

実行すると、各記事を

{

　title:記事タイトル,

　url:記事URL,

　users:ブクマ数,

　tags:[タグ]

}

の形式に変換し、500ブクマ以上でフィルタし、ブクマ数降順で返す。

#一行版

curl -s https://b.hatena.ne.jp/hotentry/it | pup --charset utf-8 'div.entrylist-contents-main json{}' | jq -r '[.[] | {title: (.. | select(.class? == "entrylist-contents-title") | .children[].title), url: (.. | select(.class? == "entrylist-contents-title")) | .children[].href, users: (.. | select(.class? == "entrylist-contents-users") | .children[].children[].text | tonumber), tags: ([.. | select(.class? == "entrylist-contents-tags") | .children[]?.children[]?.text])}] | unique | map(select(.users ＞= 500)) | sort_by(.users) | reverse'

#変数版

title='title: (.. | select(.class? == "entrylist-contents-title") | .children[].title)'
users='users: (.. | select(.class? == "entrylist-contents-users") | .children[].children[].text | tonumber)'
url='url: (.. | select(.class? == "entrylist-contents-title")) | .children[].href'
tags='tags: ([.. | select(.class? == "entrylist-contents-tags") | .children[]?.children[]?.text])'
target='https://b.hatena.ne.jp/'
hotentry='hotentry/it'
curl -s $target$hotentry | ￥
pup --charset utf-8 'div.entrylist-contents-main json{}' | ￥
jq -r "[.[] | {${title}, ${url}, ${users}, ${tags}}] | unique | map(select(.users ＞= 500)) | sort_by(.users) | reverse"

Permalink | 記事への反応(0) | 20:57

ツイートシェア

■身近な自閉症傾向

自閉症スペクトラム

俺は意固地で決まり事を作るとき、厳しくしすぎて周りの人とギスったりする。何年たってもそんなで、他の要因もあり、自分は自閉症なんじゃないかとおもった。

しかし、自閉症というものはもっと深刻なもので、自分とは全く違った(自閉症のドキュメンタリはかなり内容に共感した。勝手に掃除されたくなかったりとかすごい分かる)。

さらに調べてみると、自閉症スペクトラムという、段階みたいなものがあるらしい。社会的にはそこまで困ってない(会社の人間関係が少し危ういくらい)ので、0%から100%で表すとしたら自分は10%くらいだろうか？自分の位置がはっきりすると少し気が楽になった。

身の回りの例

スペクトラムというものを考えると、あーこれも自閉症スペクトラムの左端かなぁというのがある。

罫線文化

日本だと、論文やら注文書やらの表にはフルに罫線を引かせる。海外だと横線だけだったり、軽い印象だ。

自閉症傾向の方はカッチリしたものに安心感を覚えるらしい。まぁこれは好みなんでいいんじゃないかと思う。

マイクロソフト

仕様が独特。それでもって形式がやたら過剰でカッチリしてる。

具体的に言うとXML。SOAPはよりラフなJSON形式のRESTになったし(別に書式はXMLでもいいんだっけ？JSON以外みたことない)。何でもかんでも1回XMLにしたがるよなぁ。

他にも様々あるけど、マイクロソフトのサービスを全部列挙することになるからやめとく。まぁエンジニアってそういう傾向あるから、いいんじゃないんですかね。

Permalink | 記事への反応(1) | 20:46

ツイートシェア

■anond:20201113213756

jsonにしてくれっていったらjsonでくれるのでは？

Permalink | 記事への反応(0) | 21:38

ツイートシェア