したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | |

コンソールの2chブラウザを作るスレッド

8(-_-)さん:2017/03/18(土) 18:54:54 ID:???0
2ch運営の収入源は
・2chに表示される広告収入(現在専用ブラウザにも広告表示をさせてる)
・浪人システムによる収入(専用ブラウザの広告非表示やその他色々特典)
・メロンポイント購入による収入(BEユーザ対象)

こんな感じか
API導入は収入源確保の策なんじゃないだろうか
(scのコピー止まってないしsc対策にはなってないぽいし)

9(-_-)さん:2017/03/18(土) 18:58:25 ID:???0
https://developer.2ch.net/

ここのページにはスクレイピング型の専用ブラウザの公開を禁止してる
個人で開発して公開しないのなら問題はなさそうだけど
「公開」の定義次第だよね

10(-_-)さん:2017/03/18(土) 19:01:44 ID:???0
> •ウェブスクレイピングを用いた専用ブラウザの開発、公開は禁止されます。

これは開発も禁止してるのか

11(-_-)さん:2017/03/18(土) 19:18:00 ID:???0
『公開』に関しては2chの収益を阻害しかねないから業務妨害(刑事?)?(でも世の中にアドブロックとか広告表示ブロックのプラグインとか出回ってるしどうなんだろう?)

『開発』に関しては民事?公開してない限り特定はできないし
法律で明確に禁止されてるのはウイルス作成罪(刑事)?
2chの不特定多数に公開されてるデータにアクセスするわけだからスクレイピングは不正アクセス禁止法の対象にはならないし(許可ないAPI利用なら不正アクセスだが)
そもそも不正アクセス禁止法は開発そのものを禁止してるわけじゃないし(実際に不正アクセスするあるいは誰かが不正アクセスできるようしたらアウトって法律だし)

スクレイピングの問題としてはあとは著作権法の問題があるが開発を禁止するものの類じゃない
http://qiita.com/nezuq/items/3cc9772118ad112c18dc
http://qiita.com/nezuq/items/c5e827e1827e7cb29011

あとはクローリング・スクレイピングのアクセス頻度が多いと業務妨害(刑事)になるがこれは頻度少なければよいだけ
(1秒に1回アクセスは前例が出来てしまったためアウト https://media.accel-brain.com/librahack/ )

12(-_-)さん:2017/03/18(土) 19:24:19 ID:???0
不正アクセス行為の禁止等に関する法律 - Wikipedia
https://ja.wikipedia.org/wiki/%E4%B8%8D%E6%AD%A3%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E8%A1%8C%E7%82%BA%E3%81%AE%E7%A6%81%E6%AD%A2%E7%AD%89%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E6%B3%95%E5%BE%8B#ACCS.E8.A3.81.E5.88.A4

ACCS裁判ってやつ糞すぎなんだけど何これ・・・スクレイピングがアウトになる前例ケースやん・・・

13(-_-)さん:2017/03/19(日) 05:11:07 ID:???0
PC版2chはShiftJISだから
https://godoc.org/golang.org/x/text/encoding/japanese
このパッケージがいるね

(スマホ版2chはUTF8、APIのほうは知らない)

14(-_-)さん:2017/03/19(日) 05:21:52 ID:???0
https://godoc.org/golang.org/x/net/html/charset
これのDetermineEncodingでダウンロードしたhtmlファイルのエンコーディングを特定できるみたいだね

15(-_-)さん:2017/03/19(日) 05:22:45 ID:???0
https://godoc.org/golang.org/x/net/html
このパッケージは
HTML5限定っぽさそうだけどHTMLタグをパースできる

16(-_-)さん:2017/03/19(日) 05:32:17 ID:???0
https://golang.org/pkg/net/http/

ネット接続はデフォルトのパッケージにあるnet/http使えばよさそうだね

17ひきぷろ ◆SVQfrniSJY:2017/03/19(日) 06:46:50 ID:???0
おお、リスク分析をきちんとする感じ良いね!
書いてくれてる内容を読んだら、たしかに2chのAPI導入は、収入源確保のための発想だと思った。

法律の話はあんまり分からないけど、判例主義って考え方もあるし、
過去にどんな判決が出たのかを調べたら、同様のケースは予想できそうだよね。

役立ちそうなライブラリも、しっかり調べてくれてて、
進めていったら面白そうな感じはするね。

18ひきねこ ◆ez9QVuDvy2:2017/03/20(月) 06:28:01 ID:???0
おっ?(*´∀`)ブラウザ作るの?

19(-_-)さん:2017/03/20(月) 22:15:33 ID:???0
termboxの2chブラウザな

20(-_-)さん:2017/03/21(火) 00:08:15 ID:???0
板情報を保持する型の設計

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
}

21(-_-)さん:2017/03/21(火) 00:12:47 ID:???0
>>20
スレッドの一覧も情報として持たせたほうがいいのか

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
}

22(-_-)さん:2017/03/21(火) 00:16:28 ID:???0
スレッド情報を保持する型の設計

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
}

23(-_-)さん:2017/03/21(火) 00:22:00 ID:???0
>>21-22
最終取得日時もあったほうがいいのかも、アクセス頻度制御のために

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
LastUpdate time.Time // 最終取得日時
}

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
LastUpdate time.Time // 最終取得日
}

24(-_-)さん:2017/03/21(火) 00:25:35 ID:???0
レス情報を保持する型

type Response struct {
Name string // レスの名前欄(トリップやワッチョイどうしよう)
Mail string // レスのメール欄 (普通はsageとかageとか)
Date time.Time // レスの書き込み時刻
ID string // レスのID
Host string // IPアドレスやHost名が出る板とかあるし
Body string // レスの本文
}

25(-_-)さん:2017/03/21(火) 00:34:24 ID:???0
仕様変更に柔軟にするには型内部のデータを公開するよりアクセサメソッドを定義したほうがよいのかな

26(-_-)さん:2017/03/21(火) 00:38:41 ID:???0
>>23
これのままだとスレ保持数とレス保持数は取得済みの数値しか管理できないから取得可能な数値も保持すべきか

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
LastUpdate time.Time // 最終取得日時
LatestCount int // 最新のスレッド数(len(ThreadList)との差分が取得可能な数)
}

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
LastUpdate time.Time // 最終取得日
LatestCount int // 最新のレス数 ( len(Res)との差分が取得可能なレス数)
}

27(-_-)さん:2017/03/21(火) 00:46:39 ID:???0
スレ一覧はage/sageで順番が変わるし保持の仕方変えたほうがいいか

type ThreadID int64

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []ThreadID // スレッド一覧(ID)、nilのときは一覧を未取得
ThreadTable map[ThreadID]Thread // 各スレッドの情報はThreadIDに紐付けたマップで保持
LastUpdate time.Time // 最終取得日時
LatestCount int // 最新のスレッド数(len(ThreadList)との差分が取得可能な数)
}

28(-_-)さん:2017/03/21(火) 00:58:12 ID:???0
スレがスレ一覧から除外されてるかの判定もいるか、過去ログ化判定?

例えば板情報にスレ一覧の取得回数を保持しておき
スレ一覧に存在したスレ情報にそのスレ一覧の取得回数を書き込んでおき
板情報のスレ一覧取得回数と一致する数値を持つスレだけを生存スレで他を過去化って判定するのとか

29(-_-)さん:2017/03/21(火) 01:01:28 ID:???0
板情報のThreadList []ThreadID は
取得したスレ一覧というより表示順(レス数順とか勢い順とか)を保持したほうが良さそうかな

30(-_-)さん:2017/03/21(火) 01:11:43 ID:???0
毎回ダウンロードして全データを常にメモリってわけでなく当然パソコン内にダウンロードしたデータを保存するわけで
スレッド一覧やレスを未取得なのか未ロードなのかの区別が必要か
ブラウザ起動のたびに保存してる全データをロードするのは普通しないだろうから
取得済みのレス数とかも保持したほうがよさそう

31(-_-)さん:2017/03/21(火) 01:13:36 ID:???0
よくよく考えたら板情報のほうの LatestCount は必要ないな板ごとのスレ保持数が板の仕様変更で変わることはあるだろうけど滅多に変わらないから固定値になっちゃうし不要か

32(-_-)さん:2017/03/21(火) 01:21:59 ID:???0
ひとまずこんなとこか

type ThreadID int64

type Board struct {
Name string // 板名 ヒッキー とか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []ThreadID // スレッドの表示順
ThreadTable map[ThreadID]Thread // 各スレッドの情報はThreadIDに紐付けたマップで保持
LastUpdate time.Time // 最終取得日時
UpdateCount int // スレ一覧を確認した(取得した)回数
}

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得か未ロード
DownloadedResCount int // ダウンロード済みのレス数
LastUpdate time.Time // 最終取得日
LatestCount int // 最新のレス数 ( len(Res)との差分が取得可能なレス数)
LivingCheckValue // スレ一覧更新のときにこのスレがあった場合にBoardのUpdateCountがコピーされる、過去ログ判定用
}


type Response struct {
Name string // レスの名前欄(トリップやワッチョイどうしよう)
Mail string // レスのメール欄 (普通はsageとかageとか)
Date time.Time // レスの書き込み時刻
ID string // レスのID
Host string // IPアドレスやHost名が出る板とかあるし
Body string // レスの本文
}

33(-_-)さん:2017/03/21(火) 01:25:17 ID:???0
コピーコストを考えると生データ保持じゃなく参照保持のほうがいいか
Board.ThreadTableはmap[ThreadID]*Threadに
Thread.Resは[]*Responseに

34(-_-)さん:2017/03/21(火) 01:28:01 ID:???0
そういやgoのstringは生データなのか参照なのかどっちなんだろうと思って調べたらread-only sliceになってるからコピーコストはかからないようだね

Strings, bytes, runes and characters in Go - The Go Blog
https://blog.golang.org/strings

35ひきねこ ◆ez9QVuDvy2:2017/03/21(火) 02:35:54 ID:???0
Let's Go(/´∀`)/

36(-_-)さん:2017/03/21(火) 03:34:15 ID:???0
>>32
板URLはスレッド一覧の http://hanabi.2ch.net/hikky/subback.html のほうがいいかも

37(-_-)さん:2017/03/21(火) 03:59:27 ID:???0
Go言語は型名・変数名・関数名・メソッド名の頭文字を大文字にするとpublicになって他のパッケージからアクセスできて
頭文字を小文字にすると同一パッケージからのみアクセスできるんだったっけ

ディレクトリ単位をパッケージとするから
同一ディレクトリ内のgoファイルは全部同一のパッケージとみなされる

メソッドは型を定義したのと同じパッケージでしか定義できなかった気がするので

型の内部データを他パッケージから参照できなくするのが安全で
アクセサメソッドを定義してやるのがよくて
また、そのパッケージで定義された型の内部データを参照しないものは別パッケージ(親子関係パッケージか兄弟関係パッケージ)に追い出したほうがたぶんスッキリする

38(-_-)さん:2017/03/21(火) 04:07:53 ID:???0
例えば>>32のBoardは
他のコードからURLとか書き換えられちゃ困るから他パッケージからは秘匿してゲッターのアクセサメソッドを用意するのが適切

type Board strcut {

url string

}

func (b *Board)URL() string { return b.url }

こんな感じ?

39(-_-)さん:2017/03/21(火) 05:05:34 ID:???0

スレのhtmlからレスを抽出して返す
func TakeResponse(r io.Reader) []Response

40ひきねこ ◆ez9QVuDvy2:2017/03/21(火) 05:46:01 ID:???0
書いてる人はGo言語長いですか?Go言語どう?

41(-_-)さん:2017/03/21(火) 05:56:23 ID:???0
Go言語は1週間も触ってないです

42(-_-)さん:2017/03/21(火) 05:58:08 ID:???0
Goを触った日数はトータルで1週間分もないという意味

43(-_-)さん:2017/03/21(火) 06:01:19 ID:???0
Go言語を初めて触った日自体はかなり昔ではあるけど(ハローワールドのコードをWeb上で実行できるやつでコピペして実行しただけだけど)

44ひきねこ ◆ez9QVuDvy2:2017/03/21(火) 06:03:17 ID:???0
なんかCっぽいよね
かなり好み分かれそう

45(-_-)さん:2017/03/21(火) 06:32:09 ID:???0
制約が強すぎてCっぽいという印象はあまりない

46ひきねこ ◆ez9QVuDvy2:2017/03/21(火) 06:58:35 ID:???0
たしかに制約は不自由でなんで?と思う時がある

47ひきぷろ ◆SVQfrniSJY:2017/03/21(火) 08:56:10 ID:???0
projecthikky @ ウィキ - ヒッキー共同開発に関するページ/2chブラウザ
https://www54.atwiki.jp/projecthikky/pages/104.html

書いてくれた分、ちょっとだけまとめてみた

48(-_-)さん:2017/03/21(火) 18:10:56 ID:???0
>>47
乙です

49ひきねこ ◆ez9QVuDvy2:2017/03/21(火) 23:51:52 ID:???0
>>47
おつ

50(-_-)さん:2017/03/22(水) 23:45:23 ID:???0
htmlをダウンロード

データを抽出(データとはスレ一覧やレスなど)

データを保存

データを表示

51(-_-)さん:2017/03/22(水) 23:49:55 ID:???0
ダウンロードは
UIロックの待機状態がいいか
別スレッドにしてUIをロックせずユーザが作業できる状態にしたほうがいいか

52(-_-)さん:2017/03/22(水) 23:55:26 ID:???0
短い間隔でのアクセスはできないので、仮にダウンロードは10秒に1回に留めるとして

ダウンロードのたびに待機状態だと前回のダウンロードから10秒経ってない場合にその分の待ち時間が加わる長い待機

別スレッドにする場合は機構が複雑になる
おそらくダウンロードのリクエストおよびコールバック用関数をキューに繋ぎ10秒ごとに処理していく形
UIに反映させる機構が難しそう

53(-_-)さん:2017/03/23(木) 00:09:01 ID:???0
ダウンロード別スレッドの場合、

UIで表示してるためのデータ、と、ダウンロードした新しいデータ、これらのデータを統合するタイミングをどうするのか

同期を取るためにロックが必要となるはず

UI処理中(ユーザの入力中やデータ表示出力処理中)にロックがかかるのはよくない

54(-_-)さん:2017/03/23(木) 00:20:12 ID:???0
データ表示(画面表示)処理

ユーザからの入力待ち

ユーザの入力の発生と入力の終了

入力に応じた処理

その結果を反映したデータ表示(画面表示)

55(-_-)さん:2017/03/23(木) 00:22:43 ID:???0
ダウンロード別スレッドの場合
ダウンロードしたデータを処理して反映させるときの同期処理(ロック)をするために>>54のどこかで割り込み処理をする必要がでてくる

56(-_-)さん:2017/03/23(木) 00:26:38 ID:???0
入力待ちが無限ループなのかイベント駆動なのかで色々と変わってきそう

termboxは無限ループで入力の有無を判定するのかな?

57(-_-)さん:2017/03/23(木) 00:31:56 ID:???0
イベント駆動の場合はコールバック関数内でのブロックは一般には御法度だったっけか

58(-_-)さん:2017/03/23(木) 00:33:49 ID:???0
マルチスレッドはマジで難易度高すぎ、しかしGo言語の軽量スレッドという特徴を使わないで、何秒もUIが固まるなんてアプリは使いたいとは思わないかもしれない

59(-_-)さん:2017/03/23(木) 00:37:15 ID:???0
マルチスレッドとはすなわちバックグラウンド処理でありユーザビリティのためにあるようなもの

60(-_-)さん:2017/03/23(木) 00:44:41 ID:???0
http://jbbs.shitaraba.net/bbs/read.cgi/computer/44607/1488300885/23-25
を見た感じだとデータ追加がキャパシティを超えない場合は元のデータに書き足されるが

newThread.Res = append(oldThread.Res, newResponseData)

とすることで、表示処理中はoldThread.Resのスライスを参照してるため追加データが増えてもスライスの範囲外で見えない
そしてバックグラウンド処理で取得した新しいレスのnewThread.Resは追加分の範囲までのスライスを持つ
スライスというのはスレッド安全性を高める設計なのか

61(-_-)さん:2017/03/23(木) 00:48:39 ID:???0
ロックは oldThread = newThread という上書きのタイミングのときだけでよく
Thread型自体が直接保有する値は現在設計では大したことないのでコピーもすぐ終わる
oldThread等をThread型じゃなく*Thread型(ポインタ)の参照にすれば参照のコピーだけで終わるからもっと早くすぐ終わるな

62(-_-)さん:2017/03/23(木) 00:55:20 ID:???0
そういえばチャネルとスイッチ構文を使った無限ループっぽいサンプルコードがあった気がしたなGo言語
それをうまく使えばロックの代わりにもなるのかな
チャネルはキューなわけだし

63(-_-)さん:2017/03/23(木) 00:57:49 ID:???0
単純にチャネル待ちのを入れちゃうと
data := <-ch
チャネルが空だとロックがかかってしまうから
スイッチ構文のだと回避できるのだったかな

64ひきぷろ ◆SVQfrniSJY:2017/03/23(木) 08:19:06 ID:???0
ダウンロードの処理についてのお話だけど、IOはプログラミング一般のお話としては

・ブロッキングIO
・ノンブロッキングIO

っていう種類分けができる。

Go言語の実装がどうなってるのか分からないけど、
JavaScriptの場合は、おおよそIOの処理がノンブロッキングIOになってることが多いみたいで、
ノンブロッキングIOだと、UIスレッド1本でIOを処理できる。

CPUの状態がブロッキングにならないから、コード的にいうと次の処理がウエイトなしで実行される。
古典的な方法では、処理の終了通知は、コールバック関数を引数で渡して通知してもらう構造になる。
(JavaScriptの場合はsetTimeout関数とか、そういう処理のイメージ)

ブロッキングIOを使う場合は、

・IOの処理を別スレッドで実行する
・UIと同じスレッドで実行して、UIのレスポンスを待ち状態にする

の、いずれかの状態になる。

IOの処理を別スレッドで実行する場合は、

・スレッド終了時に通知する
・スレッドの処理の途中で(終了を待たずに)、通知するタイミングを何度か設ける

っていう風に分類できると思う。
通知の処理は、デザインパターンでいうと、オブザーバーパターンで実装すると分かりやすそう。

別スレッドからUIスレッドに通知する時に、スレッドをまたいだことで発生する問題は、C#でいうと、
別スレッドから呼び出された関数を、UIスレッドで呼びなおす
っていう処理が実行できる。

上に書いたようなことを考慮すれば、ロック機構なしでうまく実装できると思う。
マルチスレッドプログラミングの経験はそんなにないけど、
ロックを使ったコードがあると、その周辺は容易に変更できないコードになるような気がする。

65(-_-)さん:2017/03/23(木) 09:21:14 ID:???0
ありがとう
知らない知識ばかりなのでちょっと調べてみる

66(-_-)さん:2017/03/24(金) 17:27:00 ID:???0
閲覧に関するの基本的な機能は大雑把に

◆画面出力系
板一覧の表示
板(スレ一覧)の表示
スレ(レス)の表示

◆通信系
板一覧のダウンロード
スレ一覧のダウンロード
スレ(新着レス)のダウンロード

◆データ処理
板一覧のhtmlから板名とURLの抽出
スレ一覧のhtmlからスレ名とレス数とURLとスレの順番の抽出
スレのhtmlからレス(レス番号、名前、メ欄、日付、ID、本文)の抽出

◆保存系
板一覧から抽出したデータをファイルに保存
スレ一覧から抽出したデータをファイルに保存
スレから抽出したデータをファイルに保存

◆読込系
保存したファイルから板一覧データの読み出し
保存したファイルからスレ一覧データの読み出し
保存したファイルからスレデータの読み出し

◆ユーザ入力系
板一覧の表示要求
板一覧の更新要求
板(スレ一覧)の表示要求(板の選択)
板(スレ一覧)の取得要求
板(スレ一覧)の更新要求
スレの表示要求(スレの選択)
スレ(全レス)の取得要求
スレ(新着レス)の取得要求(スレの更新要求)

67(-_-)さん:2017/03/24(金) 17:31:02 ID:???0
レスの書き込みはクッキー操作やフォームの解析も必要になるから難易度あがりそう

68(-_-)さん:2017/03/24(金) 17:33:07 ID:???0
レスの書き込みはゴミ箱にJava製のがあるけどこれはまだ使えるのかな?

http://ux.getuploader.com/hikkyp/download/2/write2ch.zip

69(-_-)さん:2017/03/24(金) 18:40:57 ID:???0
>>68
まだ使えた、これのコード参考にすれば何とかなるのかな

http://i.imgur.com/inRK2UM.png
http://tamae.2ch.net/test/read.cgi/dame/1439747269/260

70(-_-)さん:2017/03/25(土) 23:14:13 ID:???0
暫定的に定義


◆画面出力系
板一覧の表示 ... func ShowBoardList()
板(スレ一覧)の表示 ... func ShowThreadList(Board)
スレ(レス)の表示 ... func ShowResponse(Thread)

◆通信系
板一覧のダウンロード ... func DownloadBoardList()
スレ一覧のダウンロード ... func DownloadTheadList(Board)
スレ(新着レス)のダウンロード ... func DownloadResponse(Thread)

◆データ処理
板一覧のhtmlから板名とURLの抽出 ... func TakeBoardList(io.Reader) []Board
スレ一覧のhtmlからスレ名とレス数とURLとスレの順番の抽出 ... func TakeThreadList(io.Reader) []Thread
スレ一覧の抽出で抽出したデータと現在のデータの統合(マージ)... func MergeTreadList(Board,[]Thread) Board
スレのhtmlからレス(レス番号、名前、メ欄、日付、ID、本文)の抽出 ... func TakeResponse(io.Reader) []Response
レスの抽出で抽出したデータと現在のデータの統合(マージ)... func MergeResponse(Thread,[]Response) Thread

◆保存系
板一覧から抽出したデータをファイルに保存 ... func SaveBoardList([]Board)
スレ一覧から抽出したデータをファイルに保存 ... func SaveThreadList(Board)
スレから抽出したデータをファイルに保存 ... func SaveResponse(Thread)

◆読込系
保存したファイルから板一覧データの読み出し ... func LoadBoardList() []Board
保存したファイルからスレ一覧データの読み出し ... func LoadTheadList(Board) Board
保存したファイルからスレデータの読み出し ... func LoadResponse(Thread) Thread

◆ユーザ入力系
板一覧の表示要求 ... func InvokeShowBoardList()
板一覧の更新要求 ... func InvokeUpdateBoardList()
板(スレ一覧)の表示要求(板の選択)... func InvokeShowThreadList(Board)
板(スレ一覧)の取得要求 ... func InvokeGetThreadList(Board)
板(スレ一覧)の更新要求 ... func InvokeUpdateThreadList(Board)
スレの表示要求(スレの選択)... func InvokeShowResponse(Thread)
スレ(全レス)の取得要求 ... func InvokeGetAllResponse(Thread)
スレ(新着レス)の取得要求(スレの更新要求)... InvokeGetNewerResponse(Thread)
ブラウザの終了 ... func InvokeExit()

71(-_-)さん:2017/03/25(土) 23:17:44 ID:???0
>>70
あくまで暫定
データをどう保持するか、とか、全体の処理の流れが十分に決まってないから
決まっていくたびに再定義したほうがよさそう

72(-_-)さん:2017/03/26(日) 04:13:15 ID:???0
ま、ここまでのほとんどのが暫定ではあるけど

73(-_-)さん:2017/03/26(日) 04:18:50 ID:???0
スライスのappendで自動拡張されるときで新しいメモリが確保されたときシャローコピーが発生するわけで
[]Threadや[]Responseのシャローコピーが発生するのは高コストだから
[]*Threadや[]*Responseに書き換える必要があるのかもな

74(-_-)さん:2017/03/26(日) 04:21:37 ID:???0
>>70は関数で定義してしまっているけどメソッドという形での定義でもよさそうだな
func SaveThreadList(Board) は func (*Board)Save() とか
func MergeTreadList(Board,[]Thread) Boardは func (*Board)Merge([]*Tread) Board とか

75(-_-)さん:2017/03/26(日) 04:25:13 ID:???0
一応説明捕捉するとMerge系のはBoardやThreadをイミュータブルな型としてみなして更新データを返却するというイメージね
ミュータブルで直接更新でもいいのかもしれないけど

76ひきぷろ ◆SVQfrniSJY:2017/03/27(月) 17:08:31 ID:???0
projecthikky @ ウィキ - ヒッキー共同開発に関するページ/2chブラウザ
https://www54.atwiki.jp/projecthikky/pages/104.html

ちょっとだけ追記してみた

77(-_-)さん:2017/03/27(月) 22:40:13 ID:???0
>>76
乙です

78(-_-)さん:2017/03/28(火) 16:31:13 ID:???0
アプリ起動

前回終了時の状態の読込(保存してあるデータの読込)

画面に表示

ユーザからの入力待ち

ユーザの入力

処理

79(-_-)さん:2017/03/29(水) 23:06:01 ID:???0
[アプリ起動]

[前処理]

[画面表示] ←┐ループ
↓       │
[入力待ち]   │
↓       │
[要求された処理]┘

80(-_-)さん:2017/03/30(木) 07:02:35 ID:???0
[前処理]は
初回起動時は板一覧の取得とか
次回以降は保存されてる板一覧とかの読み込みとか

81(-_-)さん:2017/03/30(木) 19:23:59 ID:???0
マルチスレッドにするなら
{{メインスレッド}}
[アプリ起動]

[前処理]

[各スレッド起動]

[画面表示スレッドに表示リクエスト]

[入力待ち]←───┐
↓          │
[要求に応じた処理]┘(アプリ終了以外の処理)
↓(アプリ終了の要求なら)
[後処理]

[アプリ終了]


{{画面表示スレッド}}
[リクエスト待ち]←┐
↓          │
[画面表示]────┘


{{ダウンロードスレッド}}
[リクエスト待ち]←──────────────────┐ 無限ループ
↓                             │
[指定ファイルをダウンロード]               │
↓                             │
[1つのダウンロードが終わったことを表示するよう      │
 画面表示スレッドにリクエスト]              │
↓                             │
[ファイルを処理する関数を実行する新規スレッドを立てる]┘


{{各ファイルを処理する関数のスレッド}}
[ファイルからデータ抽出]

[現在のデータと新規のデータを統合(マージ)]

[ファイルへの保存]

[更新したデータを表示可能だと画面表示スレッドにリクエスト]

[このスレッドの終了]

82(-_-)さん:2017/03/30(木) 19:28:42 ID:???0
[前処理]は>>80と同じ

[後処理]は
起動中のスレッドの終了とか
アプリの状態の保存とか

[要求に応じた処理]は
・板一覧の表示を要求
・板を選択してスレ一覧を表示の要求(ダウンロードやファイルからの読み込み)
・開いてるスレ一覧の更新の要求
・スレを選択してレスを表示の要求(ダウンロードやファイルからの読み込み)
・開いてるスレの更新の要求(新着レスのダウンロード)
そして
・アプリの終了

83(-_-)さん:2017/04/01(土) 03:51:12 ID:???0
2chのスレのhtmlのフォーマット変わった?
前はdl,dt,ddあたりのタグでレスが列挙されてた気がしたけど
今見たらdivでレスが括られてた

84(-_-)さん:2017/04/01(土) 03:57:49 ID:???0
古い2chまんまの仕様だと言われる2ch.scはdl,dt,ddの構成
http://ikura.2ch.sc/test/read.cgi/hikky/1489179773/l50

同じく2ch型を謳うしたらばもdl,dt,ddの構成(ただし文字コードがEUC-JP)
http://jbbs.shitaraba.net/bbs/read.cgi/computer/44607/1489736608/l50

しかし肝心の2ch.netがdivになってる(しかも改行とかが詰められて圧縮されてる)
http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/l50

85(-_-)さん:2017/04/01(土) 03:59:29 ID:???0
まぁもともとscへのコピー対策でクローリング対策やスクレイピング対策をされてるだろうから
html文書の構成がちょくちょく変わる可能性あるね(APIじゃないと厳しいところあるのかも)

86(-_-)さん:2017/04/04(火) 17:45:17 ID:???0
> ダウンロードについては、HTTPのIf-Modified-Sinceヘッダをうまく扱えれば
> 本文のダウンロード処理を減らすことができそう

これって静的コンテンツ以外でも使えたんだっけ?
スレってサーバ側のスクリプト(read.cgi)で動的生成だろうから
read.cgiがそのヘッダをどう取り扱っているか調べないといけないね

87(-_-)さん:2017/04/04(火) 17:48:23 ID:???0
以前のdat形式は静的コンテンツだったからそのヘッダを使うことが推奨されていたのだけれど

88(-_-)さん:2017/04/04(火) 21:36:23 ID:???0
板一覧とスレ一覧は静的か
過疎板でなけりゃスレ一覧は更新頻度高いから確認する意味なさそうだけど

89ひきぷろ ◆SVQfrniSJY:2017/04/05(水) 02:00:46 ID:???0
もう調べ終わった後かもしれないけど、
動的生成のページは、If-Modified-Since対応をあえて書いてる場合しか
HTTPステータスで304とか返してくれなさそうだよね。

転送容量を減らすという機能でいうと、
2chはURLのスレIDの後に "/100-" とか書くと、途中のレスから読める機能があったよね。

90(-_-)さん:2017/08/18(金) 19:09:04 ID:RqcRcy1I0
itestのAPIを使ったらどう?
認証ないから不正アクセスじゃないし、スクレイピングでもない

91(-_-)さん:2017/10/02(月) 14:31:15 ID:xWRj2EwM0
2chは5chに変わったそうですよ

92(-_-)さん:2020/01/14(火) 19:42:45 ID:QlE6dbBA0
少し挙動が怪しいですがこうなりました

https://ux.getuploader.com/hikkyp/download/41


新着レスの表示


名前: E-mail(省略可)

※書き込む際の注意事項はこちら

※画像アップローダーはこちら

(画像を表示できるのは「画像リンクのサムネイル表示」がオンの掲示板に限ります)

掲示板管理者へ連絡 無料レンタル掲示板