やること: チケット
https://dev.mikutter.hachune.net/
https://dev.mikutter.hachune.net/favicon.ico?1619448608
2022-06-04T05:14:52Z
やること
Redmine
mikutter for Android - 環境対応 #1586 (新規): SDK Level 32対応
https://dev.mikutter.hachune.net/issues/1586
2022-06-04T05:14:52Z
Shibafu Midorino
<p>現在のdevelopのリビジョンではtargetSdkVersion 29となっており、これは2022年6月現在のPlay storeの提出要件を満たしていないため、SDKの更新を行いたいです。</p>
<p>2022/10/31まではLevel 30で提出できますが、今30で止める理由は無いと思うのでなるべく最新ということで。</p>
mikutter - 提案 #1581 (分類待ち): Color Model
https://dev.mikutter.hachune.net/issues/1581
2022-01-16T03:51:58Z
toshi_a 初音
toshi.alternative@gmail.com
<p>mikutter上で色を表現するデータオブジェクトを標準提供する。</p>
<a name="やりたいこと"></a>
<h1 >やりたいこと<a href="#やりたいこと" class="wiki-anchor">¶</a></h1>
現在、色情報を利用する場面は以下のとおりだが、色の表現方法が異なる:
<table>
<tr>
<th>名前</th>
<th>形式</th>
<th>値の範囲</th>
</tr>
<tr>
<td> UserConfig </td>
<td> RGB </td>
<td> 0..0xffff </td>
</tr>
<tr>
<td> Cairo::Color::RGB </td>
<td> RGBA </td>
<td> 0..1 (Float) </td>
</tr>
<tr>
<td> Gtk::Color </td>
<td> RGB </td>
<td> 0..0xffff </td>
</tr>
<tr>
<td> Gdk::RGBA </td>
<td> RGBA </td>
<td> 0..1 (Float) </td>
</tr>
<tr>
<td> CSS </td>
<td> RGB </td>
<td> 0..0xff </td>
</tr>
</table>
<p>現状だと、色をどこで利用するかによって適切に変換しなければならない。<br />異なるクラスなのは仕方ないにしても、UserConfigからCairoに変換するために、各要素を0xffffで割るみたいな処理を毎回実装しなければならない。</p>
<p>レンダリングを行う層以外ではそういった詳細には立ち入りたくないし、現にGtk3移行のときに変換処理がバグっていたことがあった。</p>
<p>mikutterプラグインの共通の色の表現があると、こういった問題を解決できる。</p>
<a name="インターフェイス"></a>
<h1 >インターフェイス<a href="#インターフェイス" class="wiki-anchor">¶</a></h1>
<p>RGBAの要素のみを要求する。<br />精度は、各要素を8bitで返すインターフェイスと、0-1のFloatやRationalで返すインターフェイスが考えられる。<br />アルファブレンド値自体は、無いと困るケースがあるので、このデータオブジェクトで表現に対応する。</p>
<p>ディスプレイは1677万色の表現能力しか持っておらず、24bit (0-255)で十分表現できる。したがって、現在採用しているほとんどの表現形式が過剰である。<br />また、これは人間の識別精度を十分超えているらしく、mikutterのユーザは今のところ地球人のみであると考えているので、これ以上の精度は不要である。</p>
<p>以上のことから、各8bitでも十分である。</p>
<p>一方で、0-1で表現すると、計算が楽で、何をやっているのかわかりやすいというメリットがある。<br /><pre><code class="c++ syntaxhl"><span class="kt">uint16_t</span> <span class="nf">conv</span><span class="p">(</span><span class="kt">uint8_t</span> <span class="n">c</span><span class="p">)</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">c</span> <span class="o">*</span> <span class="mh">0x101</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">uint16_t</span> <span class="nf">conv</span><span class="p">(</span><span class="kt">float</span> <span class="n">c</span><span class="p">)</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">c</span> <span class="o">*</span> <span class="mh">0xffff</span><span class="p">;</span>
<span class="p">}</span>
</code></pre><br />ん〜どうしよっかな〜</p>
<a name="永続化について"></a>
<h1 >永続化について<a href="#永続化について" class="wiki-anchor">¶</a></h1>
<p>UserConfigは古いバージョンとの互換性のために現在の形式を維持しなければならない。</p>
<a name="表現"></a>
<h1 >表現<a href="#表現" class="wiki-anchor">¶</a></h1>
<p>各データクラスは、異なる方法でデータを保持するが、同じインターフェイスを持っている。</p>
<p>TrueColor (32bit color)<br /><pre><code class="ruby syntaxhl"><span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">Color</span><span class="p">.</span><span class="nf">parse</span><span class="p">(</span><span class="s1">'#FF0000'</span><span class="p">)</span> <span class="c1"># red</span>
</code></pre></p>
<p>ContinuouslyColor<br /><pre><code class="ruby syntaxhl"><span class="no">ContinuouslyColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mf">1.0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
<span class="no">ContinuouslyColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mf">1.0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">)</span> <span class="c1"># red</span>
</code></pre><br />同じインターフェイスを実装しColor Modelの要件を満たす独自の実装をプラグインが行うことによって、mikutterの色の表現方法を拡張できるように注意する。</p>
<a name="操作"></a>
<h1 >操作<a href="#操作" class="wiki-anchor">¶</a></h1>
<p>spellを使った場合、結果は必ずPromiseを受け取ることになる。色の操作はリアルタイム性が求められることが多く、spellは不適切である。<br />よくありそうな操作についてはColor Pluginで用意する。</p>
<a name="UserConfigの読み込み書き出し"></a>
<h2 >UserConfigの読み込み、書き出し<a href="#UserConfigの読み込み書き出し" class="wiki-anchor">¶</a></h2>
<p>RGBAの各要素は同じ方法で取得できるため、UserConfigに書き出せるはず。<br />現実的には、今の所UserConfigはあらゆるModelを永続化するような機能はもっていないため、別のところに変換ルーチンを実装しなければならない。<br /><pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">Plugin</span><span class="o">::</span><span class="no">Color</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="mi">255</span><span class="p">,</span> <span class="mi">255</span><span class="p">,</span> <span class="mi">255</span><span class="p">)</span>
<span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="o">=</span> <span class="n">c</span> <span class="c1"># 理想</span>
<span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="o">=</span> <span class="no">Color</span><span class="p">.</span><span class="nf">export_to_user_config</span><span class="p">(</span><span class="n">c</span><span class="p">)</span> <span class="c1"># 現実</span>
</code></pre><br />一方、読み込みはColor Modelだったらどんなものに復元しても良いため、もう少し直接的になりそう。<br /><pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">UserConfig</span><span class="p">[</span><span class="ss">:color</span><span class="p">]</span> <span class="c1"># 理想</span>
<span class="no">Plugin</span><span class="o">::</span><span class="no">UserConfigColor</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="ss">:color</span><span class="p">)</span> <span class="c1"># こういうのがあってもよい?</span>
</code></pre></p>
<a name="印字変換"></a>
<h2 >印字、変換<a href="#印字変換" class="wiki-anchor">¶</a></h2>
<p>例えばHTML形式で印字したいなど。すべてのColor Modelに実装を要求すると印字形式が拡張できないが、インターフェイスが統一されているのでどうとでもなる。<br /><pre><code class="ruby syntaxhl"><span class="k">def</span> <span class="nf">html_color</span><span class="p">(</span><span class="n">color</span><span class="p">)</span>
<span class="s1">'#%02f%02f%02f'</span><span class="p">.</span><span class="nf">format</span><span class="p">(</span><span class="n">color</span><span class="p">.</span><span class="nf">r</span><span class="p">,</span> <span class="n">color</span><span class="p">.</span><span class="nf">g</span><span class="p">,</span> <span class="n">color</span><span class="p">.</span><span class="nf">b</span><span class="p">)</span>
<span class="k">end</span>
</code></pre><br />Cairo::Colorに変換するといった処理は、gtk3プラグインなどが各々提供する。<br /><pre><code class="ruby syntaxhl"><span class="no">Plugin</span><span class="o">::</span><span class="no">Gtk3</span><span class="p">.</span><span class="nf">cairo_color</span><span class="p">(</span><span class="n">c</span><span class="p">)</span>
</code></pre></p>
<a name="比較"></a>
<h2 >比較<a href="#比較" class="wiki-anchor">¶</a></h2>
<p>==で比較する場合、RGBA各要素を0-255で表現した値が等しければ等しいとする。<br />Color Modelインターフェイスの精度以上で比較する意味がないからである。</p>
<p>同様に、eql?とhashもすべてのColorModelが同じ計算式で値を算出しなければならない。</p>
<p>大小比較は、多分ソートすることがないので別にいいや</p>
<a name="標準色"></a>
<h2 >標準色<a href="#標準色" class="wiki-anchor">¶</a></h2>
<pre><code class="ruby syntaxhl"><span class="n">c</span> <span class="o">=</span> <span class="no">Plugin</span><span class="o">::</span><span class="no">Color</span><span class="o">::</span><span class="no">RED</span>
</code></pre>
<p>16色とか256色とか用意する。</p>
<a name="備考"></a>
<h1 >備考<a href="#備考" class="wiki-anchor">¶</a></h1>
<p><a href="https://github.com/red-data-tools/red-colors" class="external">red-colros gem</a> は採用しない。<br />目的に対してできることが多すぎるため。<br />あと、色に対する複雑な演算をしたいわけじゃないので、その程度の理由で直接依存を増やしたくない。</p>
<p>Diva::Modelのatomic typeとして追加することも考えたが、wellknownではあるけどatomicではないかな</p>
mikutter - 提案 #1579 (まだダメ): gettext 3.4.2へのアップデート
https://dev.mikutter.hachune.net/issues/1579
2022-01-11T08:18:47Z
あひる 家鴨
mikutter - ワークフローに関する質問 #1324 (新規): 「バグ」チケット添付のパッチのレビュータイミング
https://dev.mikutter.hachune.net/issues/1324
2019-03-10T15:45:34Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>mikutter Redmine のワークフローの「<a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E3%83%90%E3%82%B0%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">バグチケットの進め方</a>」を見ると以下のように書かれています。</p>
<blockquote>
<p>"しばしば、バグ報告にいきなり修正パッチがついている場合がある。この場合、ステータスは「パッチ適用待ち」にする。" <br />"この遷移は、報告された問題の存在さえ確認できていれば、パッチの良し悪しに関わらず行って良い。パッチ自体の品質については、あとで判断する。"</p>
</blockquote>
<p>しかし「パッチ適用待ち」の状態の説明では以下の記載になっています。</p>
<blockquote>
<p>"このステータスの時にやるべきことは、単にそのパッチをコミットすることである。"</p>
</blockquote>
<p>「パッチ適用待ち」の項が「<a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E6%8F%90%E6%A1%88%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">提案チケットの進め方</a>」のワークフローそのままになってしまっているようにも見えますが、<br />「バグ」のチケットの「パッチの品質の判断」はどこで行われるべきでしょうか。</p>
mikutter - 最適化 #1315 (新規): filterの戻り値を加工しない場合、配列よりもアロケートのコストが軽いオブジェクトで代用する
https://dev.mikutter.hachune.net/issues/1315
2019-02-09T17:41:29Z
toshi_a 初音
toshi.alternative@gmail.com
<a name="動機"></a>
<h1 >動機<a href="#動機" class="wiki-anchor">¶</a></h1>
<p>メモリプロファイルを取ったところ、以下のようなコードで作成される配列が大量にあった。フィルタを過剰に呼び出さない工夫も必要だが、大抵のフィルタは値を加工しないので、値を加工しなかったことを示すキーワードを代わりに返すことで、ほとんどのフィルタ呼び出しで配列の作成を1回削減できる。</p>
<a name="対応"></a>
<h1 >対応<a href="#対応" class="wiki-anchor">¶</a></h1>
<p>値を加工しなかったことを示す値には以下の候補がある:</p>
<p>- <code>nil</code> : やりやすいが見慣れていないと何のことかわからない<br />- <strong>何らかのSymbolや定数:</strong> オブジェクトを作成しない。意図が明確になる。<br />- <strong>何らかのメソッド:</strong> 今もフィルタを強制的にキャンセルするために <code>Filter.cancel</code> とか書いてるので、 <code>Filter.pass</code> とか書いたら帯域脱出した上でパスできると良いかも。<br />- <strong>filter_xxxの引数に加工しないという宣言を与える:</strong> 戻り値が偶然衝突することはないが融通は効かない</p>
mikutter - ワークフローに関する質問 #1278 (新規): 「提案」のパッチをレビューするタイミング
https://dev.mikutter.hachune.net/issues/1278
2018-07-15T06:40:18Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p>「提案」チケットにおいて、提案された機能自体はOKの場合、<br />添付されているパッチの実装をどのタイミングでレビューするか、<br />という課題。</p>
<ul>
<li>とりあえず無条件に「パッチ適用待ち」にしてブランチに入れてしまって、<br />そのブランチ上で動作だけではなくコードもレビューするのか</li>
<li>パッチの中身をレビューしてOK判断してから「パッチ適用待ち」にするのか</li>
</ul>
mikutter - ワークフローに関する質問 #1276 (新規): コミッタの方によるパッチ投稿
https://dev.mikutter.hachune.net/issues/1276
2018-07-14T13:56:13Z
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp
<p><a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-1">#1269#note-1</a> での議論。<br />コミッタからパッチ付きの提案チケットが投稿された場合、<br />誰がどう判断してステータスを進めるべきか。</p>
<blockquote>
<ul>
<li>コミッター+モデレータのメンバーのうち少なくとも 2人がOKと言ったら進める?</li>
<li>slack や mastodon とかでとしぁさんと会話して「いいよ」だったら進めるとか?</li>
<li>最終的に「パッチ適用待ち」にするときにコミッタの判断が入るなら最初は緩くてもいい?</li>
</ul>
</blockquote>
<p><a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-2">#1269#note-2</a> のコメントは以下<br />cob odo さんは書きました:</p>
<blockquote>
<p><a class="wiki-page" href="https://dev.mikutter.hachune.net/projects/mikutter/wiki/%E6%8F%90%E6%A1%88%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E9%80%B2%E3%82%81%E6%96%B9">提案チケットの進め方</a>によれば、</p>
<blockquote>
<p>ステータス「分類待ち」の場合<br />この場合、モデレータがその提案が妥当なものなのか判断し返信する。<br />妥当でないならばその理由を説明し、ステータスを「却下」に変更する。<br />モデレータがそれを取り込むべきと判断すれば、以下の条件に従って次に進める。</p>
</blockquote>
<p>ということなので、</p>
<blockquote>
<p>このあたりのGOの判断を誰がどうするか</p>
</blockquote>
<p>は、「独断で(もちろん理由は挙げるとして)GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。<br />そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。</p>
<p>「提案」フローについては、単に「こういう機能がほしい」という提案が(非コミッタ・非プログラマ)から出た場合、モデレータがGOの判断をしてもまだパッチは無いので「パッチ適用待ち」にはできなそうだなとは思いました。</p>
</blockquote>
<p>それに対する返信 <a class="issue tracker-12 status-5 priority-4 priority-default closed" title="提案: mobile.twitter.comで始まるtweetのperma_linkの引用に対応する (終了)" href="https://dev.mikutter.hachune.net/issues/1269#note-3">#1269#note-3</a><br />Izumi Tsutsui さんは書きました:</p>
<blockquote>
<p>cob odo さんは書きました:</p>
<blockquote><blockquote>
<p>このあたりのGOの判断を誰がどうするか</p>
</blockquote>
<p>は、「独断で(もちろん理由は挙げるとして)GO/NO-GOを判断できる権限がモデレータに与えられている」と解釈するのかなーと思いました。<br />そうは言っても判断が微妙な提案はあると思いますし、迷ったら適宜相談という形でいいのではないかと個人的には思います。</p>
</blockquote>
<p>仕様としては歓迎するが、実装(コード)はわからん、という場合は迷うんですよね……。(非プログラマのつぶやき)</p>
<p>公開API変更のような互換性で禍根を残すようなものは別として、「やってみてイマイチだったら元に戻せばいい」という程度の変更なら<br />あまり気にせず「コミッタorモデレータのうちひとりがOKと判断すれば進める」というゆるいルールでよいような気はします。</p>
</blockquote>
mikutter - ワークフローに関する質問 #1275 (新規): テストだよ
https://dev.mikutter.hachune.net/issues/1275
2018-07-14T12:46:46Z
toshi_a 初音
toshi.alternative@gmail.com
<p>うーんこの</p>
mikutter - 最適化 #1244 (新規): Score対応の漏れ
https://dev.mikutter.hachune.net/issues/1244
2018-05-14T05:06:43Z
cob odo
cobodo@gmail.com
<code>Message#entity</code>をまだ参照している本体同梱プラグインの一覧
<ul>
<li>bitlyプラグイン</li>
<li>tcoプラグイン</li>
<li>commandプラグイン(:open_link, :copy_link)</li>
<li>gtkプラグイン(filter_gui_timeline_selected_text)</li>
<li>quoted_messageプラグイン</li>
<li>twitterプラグイン(quoting_ids)</li>
</ul>
<p>また、smartthreadプラグインがまだ<code>MessageMixin#quoting_message</code>を参照しているようです。これを修正すれば<code>Plugin::Twitter::Message#quoting_ids</code>は無視できると思います(サードパーティプラグインが使用している可能性はありますが……)。</p>
mikutter - 環境対応 #1178 (新規): GLib-GObject-WARNING **: invalid cast from 'GtkAdjustment' to 'GtkWid...
https://dev.mikutter.hachune.net/issues/1178
2018-02-20T05:08:46Z
cob odo
cobodo@gmail.com
<p>コンソールを開いたら出ました。環境はWSL(Fall Creators Update)、Ruby 2.5.0です。</p>
<p>ディレクトリ名だけ加工したログを貼ります。</p>
<pre>
GLib-GObject-WARNING **: invalid cast from 'GtkAdjustment' to 'GtkWidget'
from ~/repos/mikutter/core/plugin/console/console.rb:78:in `gen_scrollbars'
from ~/repos/mikutter/core/plugin/console/console.rb:18:in `block (2 levels) in <top (required)>'
from ~/repos/mikutter/core/plugin/shortcutkey/shortcutkey.rb:18:in `block (3 levels) in <top (required)>'
from ~/repos/mikutter/core/plugin/shortcutkey/shortcutkey.rb:12:in `each'
from ~/repos/mikutter/core/plugin/shortcutkey/shortcutkey.rb:12:in `block (2 levels) in <top (required)>'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/filter.rb:28:in `filtering'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:59:in `block (2 levels) in filtering'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:58:in `each'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:58:in `reduce'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:58:in `block in filtering'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:57:in `catch'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/event.rb:57:in `filtering'
from ~/repos/mikutter/vendor/gems/ruby/2.5.0/gems/pluggaloid-1.1.1/lib/pluggaloid/plugin.rb:63:in `filtering'
from ~/repos/mikutter/core/plugin/gui/dsl.rb:31:in `keypress'
from ~/repos/mikutter/core/plugin/gtk/gtk.rb:558:in `block in create_pane'
from ~/repos/mikutter/core/mui/gtk_extension.rb:35:in `block in safety_signal_connect'
from ~/repos/mikutter/core/plugin/gtk/mainloop.rb:10:in `main'
from ~/repos/mikutter/core/plugin/gtk/mainloop.rb:10:in `mainloop'
from ./mikutter.rb:68:in `boot!'
from ./mikutter.rb:104:in `<main>'
</pre>
mikutter - 最適化 #1170 (新規): form dslのoptionの引数の順序の統一
https://dev.mikutter.hachune.net/issues/1170
2018-02-11T01:56:38Z
あひる 家鴨
<p><code>Gtk::FormDSL::Select</code> の持つ <code>option</code> の引数が <code>value, label</code> の順序になっている。<br />formの持つ他のウィジェットの引数は <code>label, value</code> になっているため、統一したい</p>
考えている実装方法としては以下の通り
<ol>
<li><code>option(value, label = nil)</code> から <code>option(label = nil, value)</code> に変更する</li>
<li>互換性の維持のために第一引数に symbol が与えられている場合は、何かしらの警告を出しつつメソッド内で順序を入れ替えて、変更前のものが動くようにする</li>
</ol>
mikutter - 最適化 #1158 (新規): ret_nthユーティリティの利用をやめる
https://dev.mikutter.hachune.net/issues/1158
2018-01-23T02:30:11Z
toshi_a 初音
toshi.alternative@gmail.com
<p><a class="source" href="https://dev.mikutter.hachune.net/projects/mikutter/repository/main/entry/core/utils.rb#L45">source:core/utils.rb#L45</a> には、ret_nthという、n番目の引数を返すProcを返すメソッドがある。<br />標準プラグインでは0番目を指定することで恒等関数のような用途にしか使われていない。</p>
<p>恒等関数であれば、Ruby 2.2からは <code>Object#itself</code> が標準で用意されている。mikutter 3.6ではRuby 2.3以降をサポートするとしているので、 <code>Object#itself</code> を使い、ret_nthの利用を避ける。もしret_nthの利用を全てやめることができたら、ret_nthをdeprecateにすることも検討する。</p>
mikutter - 最適化 #1072 (新規): Twitterモデルのフィールド定義を増やす
https://dev.mikutter.hachune.net/issues/1072
2017-10-10T11:30:29Z
あひる 家鴨
<p>TwitterモデルのJSONエクスポートとインポートをしたいが現状のTwitterのDiva::Modelではフィールドの定義が不十分である。<br />例えばEntityなどはエクスポートする上で欠かせないフィールドだと思う。<br />どのフィールドを用意するかを含めてここで議論したい。</p>
mikutter - 最適化 #931 (新規): 一部のオブジェクトが不要なデータを抱えている
https://dev.mikutter.hachune.net/issues/931
2016-11-13T16:02:05Z
Osamu Koga
osak.63@gmail.com
<p>例えば<code>User</code>オブジェクトは、api_call_support.rb内でTwitterの渡してきたUserオブジェクトをそのままparseして格納していますが、ここにはユーザの最新ツイートなど、mikutter的には不要なものが含まれています。<br /><pre>
>>> User.findbyidname('osa_k').to_hash[:status][:text]
"mikutter分からんけど何が分からないのかも分からない……"
</pre><br />これが直接的に問題となる箇所はないですが、多くのUserオブジェクトが生成される環境(フォロー数が多い、RTが大量に流れてくる等)ではメモリを無駄に圧迫する可能性があります。</p>
mikutter - 最適化 #800 (新規): ユーザの鍵アイコンが毎回ストレージからロードされている
https://dev.mikutter.hachune.net/issues/800
2015-12-21T19:09:19Z
toshi_a 初音
toshi.alternative@gmail.com
<p>これ多分Pixbuf使いまわして問題なかったはずだし、そもそも使い回されてると思っていた。ブランチ変えて画像なくなったら読み込みエラーの画像になってしまうので、毎回ロードしているのでは?</p>