開発ソフトの記事一覧

2020/06/01

【小説家になろう更新アラート】Windowsフォームアプリを作ってみる

条件をいろいろ考えてみたが、ひとまず自分が必要な機能を充足させるために作ってみる。

機能

  • 60分から1日(24時間)の範囲で、ブックマークしている小説の更新情報を取得して知らせる。
  • ブックマークから小説情報を取得
  • APIを使って小説情報を取得
  • メールでまとめて更新情報を送付
  • 最新話にジャンプとブックマークの次の話にジャンプを作る
  • 18禁サイトの小説も対象にする

必須機能はこの位だと思う。

あとは実際に使ってみて機能を決める。

今回のプログラムは最初からフリー版と有料版を作るつもりで居る。

ネット連動機能を作って見ようと思っている。Windowsフォームアプリでは、パソコンを起動していないとメールが送付されない。

サイトで定期的に小説家になろうのAPIをを叩いて更新情報をメールする部分を作成しようと思っている。

無料の場合には、Windowsフォームで管理出来る小説数を制限しようと思っている。

無料版では、50作品の管理にとどめて、枠を買っていくイメージにしようと思っている。

2020/05/21

【考察】ユーザ数の限界値

【開発開始】小説家になろう。更新通知プログラム

【考察】小説家になろうAPI

実際に作成するにあたって、いくつか欲しい機能がある。メールでの通知だ。

最初は、Twitterでの通知を考えたが、昨今のTwitterの動きを見ていると、BOT的な動きに見られてしまう可能性がある通知を行うのは控えた方がよいと考えた。DMもTwitterAPIから送れなくなっている。Twitterをくだらない出会いやSPAMツールにした奴らへの対応だろうが、本当につまらなくなってしまった。

Android端末と連動して通知を出す方法もあるが、世間ではまだiOSが搭載されているスマホを使っている人もいる。ChromeやMicrosoft Edgeとかに通知する方法も考えたが、あまり複雑なことができそうにない。サーバの負荷が上がってしまう可能性がある。

それらの条件を考えると、メールで通知するのが一番現実的に思えてくる。

個人的に使うだけなら、タスクバーにアイコンを常駐させて通知してもいいし、それこそポップアップを表示してもいい。

今考えているのは、サーバ経由での通知の方法だ。

手元のWindowsプログラムで、サーバに自分が読んでいる小説を登録して、小説の更新頻度から適当に割り振った小説家になろうAPIをコールする頻度を決めて、サーバからまとめてコールする。

そこから、1時間毎程度の頻度で更新された小説の情報を取得して登録ユーザにメールする。

使っている一番安心できそうなサーバがXserveなので、メールの限界を調べる。

各プラン共通で、下記の通りメール送信数の目安を設けております。

1,500通/時間
15,000通/日

上記の目安量を著しく超えている場合は、メール機能の利用制限を行う場合があります。

制限に引っかかりそうなのは、後者の15,000通/日なので、ユーザ数の上限を考えると、1時間に一度か一日1回程度のメール送信を考える。メールの本文に、更新された小説の情報が並べばいいと思っている。

そうなると、15000/24 = 625 が最大許容ユーザ数になる。実際には、余裕を持たせるので、半分に設定したとして、300ユーザを上限にする。

サイトのアクセス状況から、300名のユーザが確保できるとは思えないので、十分な数字だと判断する。

300名のユーザが、小説家になろうのブックマークの限界の半分を使っているとすると2,000件の登録を平均になる。多い気がするが、2,000の登録を300ユーザが行うと、600,000件のデータになる。有名作品などのダブりがあるだろうが、そのあたりは考慮しないとしても、60万の小説データを毎日取得するのは現実的ではない。小説家になろうAPIの制限を考える必要がありそうだ。

2020/05/20

【考察】小説家になろうAPI

Windowsプログラムで作成する場合には、制限はそれほど考えなくてよさそうだ。

IPアドレスごとに利用制限を行います。
1日の利用上限は80,000または転送量上限400MByteです。
利用制限は初回アクセスから24時間が適用範囲です。
初回のアクセスから24時間後に回数と転送量を記録していたカウンタと
初回アクセス時刻をリセットします。

http://dev.syosetu.com/man/api/

遅延に関しては、もうあきらめるしかないが、制限は考える必要はなさそうだ。

取得するデータも最小限に抑えればいい。

なろうAPIを見ていると、なんとなく問題点が見えてくる。

話数別の更新日時が取得できない。そのために、メールなどでの告知ができないのだろう。あと、APIには”章”の考え方もない事から、機能として後付けされたのだろう。

フラグが大量に存在しているが、本来このフラグは種別分けされて処理されるべき物だろう。APIだからこうしているという考えもできるが、不自然な感じがしてしまう。フラグは、楽だからこうしていると思えばいいのだが、問題はポイントの取り扱い部分だ。APIの仕様を見てもいまいちはっきりとしたい。

日間ポイント
(ランキング集計時点から過去24時間以内で新たに登録されたブックマークや評価が対象)

週間ポイント
(ランキング集計時点から過去7日以内で新たに登録されたブックマークや評価が対象)

月間ポイント
(ランキング集計時点から過去30日以内で新たに登録されたブックマークや評価が対象)

四半期ポイント
(ランキング集計時点から過去90日以内で新たに登録されたブックマークや評価が対象)

年間ポイント
(ランキング集計時点から過去365日以内で新たに登録されたブックマークや評価が対象)

この部分だ。

”ランキング集計時点”の指定がないのだ。どこかに、保存してあれば、24時間毎にデータを取得すれば履歴として使える。1時間毎にデータを取得すれば、時間ごとの集計が可能になる。しかし、この書き方だと、曖昧過ぎる。ランキング集計時点がシステムで決められているのなら、APIで取得できる数値は参考値になってしまう。参考値なら参考値で説明を追記してほしい。

あと説明が不親切。

novelupdated_at 小説の更新日時
general_lastup 最終掲載日
YYYY-MM-DD HH:MM:SSの形式

の違いに関して

novelupdated_at 小説の更新時刻
最後に小説データが更新された時刻です。
general_lastup 小説最終掲載日です。小説を公開した時点で反映されます。
上のgeneral_firstupと違い連載小説の場合、次話投稿時にも反映されます。ただし編集の場合は反映されません。

と説明されています。

特に、二つ目はひどいです。

”小説を公開した時点で繁栄されます”と”次話投稿時にも反映されます”となっています。ただし以降の書き方に関しては意味不明です。

データを取得して調べるしかないので、APIの調査は実際にプログラムを組んでみて調べるしかないと結論づけます。

はぁ・・・。

そもそも、更新通知をメールで投げてくれれば問題は解決するのに・・・SPAMにでも指定されたから止めたのか?

それとも単純に、メールで告知して小説を読まれると、広告が表示されなくてクリックされないから、作らなかったのか?

ユーザビリティが他の投稿サイトに追い越されて行ってしまっているように感じてしまう。

広告

2020/05/18

【開発開始】小説家になろう。更新通知プログラム

小説家になろうのAPIを使って一定時間毎にチェックを行って、更新情報を通知する。

Windowsプログラムにしようか、Webプログラムにしようか迷っているのだけど、サーバの負荷とか考えると、Windowsプログラムなんだよな。

更新情報だけ、サーバにあげてもいいけど・・・さて、どうしようか考えている。

一番いいのは、小説家になろうのサイトで更新情報を通知してくれる方法だけど、期待できないのだよな。

2020/04/30

プラグイン機能の全面見直し中

起動時の遅さ改善の為に、プラグインの全面見直し中です。

インポートに機能やエクスポート機能に関しては、起動時に読み込まないで、起動後に非同期的に読み込むように修正。

見た目の速度をあげる工夫を入れています。

機能に関しても見直しを行って、エクスポート形式を調整します。

作ることができればだけど、ePub形式とPDF形式とWORD形式を取り入れようと思っています。Text形式はすこし工夫した形にします。

インポートで、小説家になろうからのインポートを考えています。他のサイトも考えたのですが、一番”原始的”なサイトが小説家になろうだとおもうので、読み込むべき小説のあらすじ部分に特定の文字列を入れ込んでもらって、読み込む形式にしようと思っています。

旧版のプラグインとの互換で悩んでいます。

さてどうしたものか・・・。

2020/04/29

StoryEditorのVS2019化が終了

意外と手間取った。

コンバートは発生しなかったのだが、TFSを使っていたソース管理をGitに移行するのに手間取った。環境を構築して、ソース管理へのコミットに時間がかかってしまった。

コンパイルが通ったので、機能確認を行っています。

問題が無ければ、近日中にアップ予定です。

問題が無ければ・・・。

広告

2020/03/28

【StoryEditor】次期バージョン

StoryEditor 次期バージョンの開発を行っています。

次期バージョンの機能を確定させました。

  • WordPress連動(PlugInで対応)
  • カスタマイズ項目追加(ノードクリップボードでの選択項目を選択式にする)
  • っぽい名前に日本語追加(予定-データを作るだけ)
  • Twitter投稿機能(PlugInで対応)
  • VS2019で作成(※メンテナンスのため)

断念した機能(継続開発)

  • 簡易関連図作成ツール
  • 有料版の開発&提供
  • MDI化(複数の小説を同時に書く機能)
  • 高速化
  • 閲覧専用ツール(Android/Windows版)
  • PDF出力(PlugIn)
  • 原稿用紙出力(PlugIn対応:Word 必須)

2020/01/23

【ソフト紹介】クリップボード履歴管理 – oxypetalum –

クリップボード履歴管理 – oxypetalum –

よくあるクリップボードの履歴監視です。最大200テキストまで履歴として残ります。

文章を書いている時に、クリップボードの履歴管理が欲しくなって急遽作りました。

履歴管理しているので、クリップボードに一時保存させることもできますし。

履歴を遡れるので、数個前のクリップボードの内容を複写することができます。

 

2019/05/27

【ソフト紹介】 Freesia

デスクトップ上に常駐して作業を妨げない。デスクトップガジェットです

カレンダー/今日の日付/今の時間を好きな場所にある程度好きなサイズで表示する事ができます。

 

ダウンロードはここから!

広告

2018/07/15

【NEWS】富士山がIoTだらけに。登山ルートの気温・混雑度もウェブで一目瞭然

富士山がIoTだらけに。登山ルートの気温・混雑度もウェブで一目瞭然

言葉の力ってすごいな。
IoT っていうだけで、最新技術って感じがしますからね。数年前・・・下手すると、もっと前から、同様の事が、河川の氾濫予測や天気予報や渋滞情報でやっていますよね?

それとも、まったく新しい”技術”が使われているのでしょうかね?

違うといえば、VR系だと思いますが、これも、ハードウェアが追い付いてきただけの話ですよね。
それに、”視覚”だけで、ヴァーチャルリアリティっていうあたりがなんとなく・・・なんだかなぁって気持ちにさせられる。

定義の問題だとは思うけど、3つくらいの感覚が再現できて、VRだと思うのだけどな。

2018/02/13

[特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴

[特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴

アルミ建材大手の文化シヤッターが、販売管理システムの開発が頓挫した責任は委託先の日本IBMにあるとして、約27億4000万円の損害賠償を求めて日本IBMを提訴していたことが、日経コンピュータの取材で明らかになった。

ツッコミどころ満載だけど、落とし所を見つけられるような気がするのだけれどね。

火が着いてからの、PM交代には意味がない。その後で、セールスフォースの技術担当者を合流させても、テコ入れに見えて、何も考えていなかったのが解るだけの対応でしかない。
その上で、不具合1,000件の内800件は、”By Design”だと言い切れる所がすごい
そう言われれば、「まず200件直せば使えるだろうな!」と言われる未来が予測できる。
しかし、見つかったバグの後ろには、新たなバグが仕込まれている事位はわかったのだろう。だから、全部治すよりは、作り直しを提案したのだろう。

順番が逆なら良かったのでしょうね。
大型案件だから、予算計上や人員の問題も有ったのだろうけど、アジャイルで行くのなら、セールスフォースの販売管理を稼働させてから、カスタマイズで対応出来る物と出来ないものを切り分けるべきだったのでしょう。

2017/04/11

開発者の調べ物

開発系の案件だと思って話を聞きに行ったら、実は運営系の話だったって事がよくある。
それでも、話が”自分の担当ではありません”では話が終わってしまうので、最低限の知識を入れておく必要がある。

この最低限の知識という物が困り物で、経験有る物なら、”古い知識”ですがと枕詞を付ける事で、その場は切り抜ける事が出来る。問題は経験がない物だが、開発に絡む運営系の問題は概ね幾つかのパターンに分ける事が出来る。そのパターンを抑えておくことで、切り抜けられる事がおおい。

  • パフォーマンスの問題
  • セキュリティの問題
  • ライセンスの問題

に分類される。

パフォーマンスが一番多いが、その場合の対応はいくつか決まった事の確認から始める事が出来る。何か、ソリューションを使っているとしたら、そのソリューション自体の問題がないか?パフォーマンス低下はどのタイミングで発生するのか?など定型文とも言える情報収集から始める。大抵この時点で問題点は出てこない。この程度の事はもう調べているし解っている場合が多い。しかし、確認するのは、おの調べているだろう事でもこっちにしたら初めて聞く事だという事を印象づける意味合いが強い。
その上で、幾つかの仮設を建てる。
ボトルネックになりそうなネタを探す。
アプリケーション系で遅くなる場合には、スレッドの使い方が大雑把だったり、DB接続が最適化されていなかったり、ネットワークを考えていなかったりする場合が多い。客の属性では、ソリューションに頼った作りをしている場合に多い。
次にWeb系のソリューションでパフォーマンスが問題になる場合には、同じくDB接続を一番最初に疑います。特に、DB接続を何かに頼っているような場合には疑います。次に、同じフォーム内に複数の属性が必要になっているような画面が存在しないかやWebサーバのパフォーマンスチェックを行います。
次に意外と見落としがちなのが、タスク管理がされているのかですが、これはシステム全体を見ないとなんとも言えない事も多い上に、面倒ですので、実際に調べる時に最初に行う事が多いです。
次に見落としがちなのが、ファイルシステムへのアクセスによるボトルネットです。DBだけで完結している倍でも、画像ファイルや設定などがファイルになっている場合が多く、それらのファイルに対するアクセスがボトルネックになっている場合も多く見かけます。レスポンスはいいんだけど、表示が遅いなどの場合に考える箇所です。

セキュリティの問題に関しては、もうシステムごとに望まれている事が違うが、話を聞いていれば、”気にしすぎ”か”無頓着すぎ”の両極端になってくる。それらの事は経験則でいくらでも話せるが、”大丈夫だろうか”と思っている客には、”殆どの場合は大丈夫ですが、狙われたら多分対策をしても無意味です”と答えてから、最低限の事だけはしておきましょうという事が多い。

開発者として、知っておくべき知識が”調べる”事で得る事ができます。
その場合には、調べた物をそのままにしておくよりは、自分の経験と結びつけておく事を推奨します。それだけでも、次に似たような話が来た時に”経験”として話が出来るようになります。

広告