ダウンロード
Magazine
開発
アカウント
ダウンロード
Magazine
開発
ログイン
アカウント/パスワードを忘れた
アカウント作成
言語
ヘルプ
言語
ヘルプ
×
ログイン
ログイン名
パスワード
×
アカウント/パスワードを忘れた
日本語の翻訳状況
カテゴリ:
ソフトウェア
人物
PersonalForge
Magazine
Wiki
検索
OSDN
>
ソフトウェアを探す
>
コミュニケーション
>
チャット
>
インターネットリレーチャット(IRC)
>
keitairc
>
フォーラム
>
開発者
>
やはりkeitaircは前時代的な件について
keitairc
Fork
概要
プロジェクト概要
開発ダッシュボード
Webページ
開発メンバー
画像ギャラリー
公開フィード一覧
活動
統計情報
活動履歴
ダウンロード
リリース一覧
統計
ソースコード
コードリポジトリリスト
Git
keitairc
チケット
チケット一覧
マイルストーン一覧
チケットの種類一覧
コンポーネント一覧
よく使われるチケット一覧のリスト/RSS
新規チケット登録
文書
FrontPageの表示
ページ一覧
最近の更新
コミュニケーション
フォーラム
フォーラム一覧
開発者 (13)
ヘルプ (10)
公開討議 (0)
メーリングリスト
MLの一覧
keitairc-commit
keitairc-dev
ニュース
フォーラム:
開発者
(スレッド #25286)
話題(スレッド)一覧に戻る
RSS
やはりkeitaircは前時代的な件について (2010-02-01 14:29 by
noblejasper
#48238)
返信
チケットに引用
色々ソースを読んでいて思ったのですが、
やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。
3.0ぐらいを目標でいいと思うのですが、
Plack::Server::Standalone(
http://perl-users.jp/articles/advent-calendar/2009/hacker/23.html)
などで動かして、
POEではなくAnyEventなどでIRCとつなぐのがいいのではないかと。
モバイル対応に関しては文句なし!って感じなのでもったいないかと思ってます。
メッセージ #48238 への返信
×
題名
本文
メッセージ #48238 への返信 > 色々ソースを読んでいて思ったのですが、 > やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。 > > 3.0ぐらいを目標でいいと思うのですが、 > Plack::Server::Standalone(http://perl-users.jp/articles/advent-calendar/2009/hacker/23.html)などで動かして、 > POEではなくAnyEventなどでIRCとつなぐのがいいのではないかと。 > > モバイル対応に関しては文句なし!って感じなのでもったいないかと思ってます。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-02-01 14:30 by
noblejasper
#48240)
返信
チケットに引用
SVNかGitに移行すればbranch切ってnoblejasperが書きはじめますー
#48238
への返信
メッセージ #48240 への返信
×
題名
本文
メッセージ #48240 への返信 > SVNかGitに移行すればbranch切ってnoblejasperが書きはじめますー
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-02-03 19:39 by
morimoto
#48298)
返信
チケットに引用
> やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。
メンテナンスされていない、利用していると問題がでてきそうなmoduleがどれなのか教えていただけますか?
その具体的な問題がどの程度差し迫ったものかを知りたいです。
ちなみにあと1〜2年のスパンでしか考えてないです。
現在使っているモジュール群がいずれ古くダメになっていくもので、
かつ他のより新しいモジュールを採り入れることが将来への有効な投資になりそうで、
かつモジュールやアーキテクチャが異なるブランチを同時に保守していく手間が充分割に合うのなら、
よい提案なのだと思います。
いま現在は、おそらく私の勉強不足のため、あまりピンときません。
また「前時代的」であることは優劣とは関係ありませんし、
たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。
個人的には、stableなDebian GNU/Linuxにおいてapt-getでインストールできないモジュール、
cpanで手で入れるようなモジュールにプログラムを依存させるつもりは全くありません。
#48238
への返信
メッセージ #48298 への返信
×
題名
本文
メッセージ #48298 への返信 > > やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。 > > メンテナンスされていない、利用していると問題がでてきそうなmoduleがどれなのか教えていただけますか? > その具体的な問題がどの程度差し迫ったものかを知りたいです。 > ちなみにあと1〜2年のスパンでしか考えてないです。 > > 現在使っているモジュール群がいずれ古くダメになっていくもので、 > かつ他のより新しいモジュールを採り入れることが将来への有効な投資になりそうで、 > かつモジュールやアーキテクチャが異なるブランチを同時に保守していく手間が充分割に合うのなら、 > よい提案なのだと思います。 > > いま現在は、おそらく私の勉強不足のため、あまりピンときません。 > また「前時代的」であることは優劣とは関係ありませんし、 > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。 > > 個人的には、stableなDebian GNU/Linuxにおいてapt-getでインストールできないモジュール、 > cpanで手で入れるようなモジュールにプログラムを依存させるつもりは全くありません。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-02-04 09:49 by
noblejasper
#48316)
返信
チケットに引用
[メッセージ#48298 へのフォロー]
> > やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。
>
> メンテナンスされていない、利用していると問題がでてきそうなmoduleがどれなのか教えていただけますか?
> その具体的な問題がどの程度差し迫ったものかを知りたいです。
> ちなみにあと1〜2年のスパンでしか考えてないです。
最近のPerl事情を聞いているとPOE->AnyEventって流れが主流になりつつあります。
またサーバとしての機能もカスタム面から考えるとPSGIを汲み取った方がいいのかな。と思います。
> 現在使っているモジュール群がいずれ古くダメになっていくもので、
> かつ他のより新しいモジュールを採り入れることが将来への有効な投資になりそうで、
> かつモジュールやアーキテクチャが異なるブランチを同時に保守していく手間が充分割に合うのなら、
> よい提案なのだと思います。
上述したようなものを異なるブランチで作るのは大変賛成ですが、
やはり人間的なコストがかかりますね。
> いま現在は、おそらく私の勉強不足のため、あまりピンときません。
> また「前時代的」であることは優劣とは関係ありませんし、
> たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。
すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。
> 個人的には、stableなDebian GNU/Linuxにおいてapt-getでインストールできないモジュール、
> cpanで手で入れるようなモジュールにプログラムを依存させるつもりは全くありません。
ふむ。
apt-get出来るモジュールだけで作るというのであれば今回の話は完全になかった事になるかと思います。
思いつく解決法としてはlocal::libなどを使用し、moduleを同梱するという可能性がありますが、
まだAnyEventにせよPlackにせよ完全に安定したとは全くもって言えません。
とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていくのがいいのかなぁ。と思いました。
#48298
への返信
メッセージ #48316 への返信
×
題名
本文
メッセージ #48316 への返信 > [メッセージ#48298 へのフォロー] > > > > やはり前時代的なModule(現在はメンテされてない)などが多いのが気になります。 > > > > メンテナンスされていない、利用していると問題がでてきそうなmoduleがどれなのか教えていただけますか? > > その具体的な問題がどの程度差し迫ったものかを知りたいです。 > > ちなみにあと1〜2年のスパンでしか考えてないです。 > 最近のPerl事情を聞いているとPOE->AnyEventって流れが主流になりつつあります。 > またサーバとしての機能もカスタム面から考えるとPSGIを汲み取った方がいいのかな。と思います。 > > > 現在使っているモジュール群がいずれ古くダメになっていくもので、 > > かつ他のより新しいモジュールを採り入れることが将来への有効な投資になりそうで、 > > かつモジュールやアーキテクチャが異なるブランチを同時に保守していく手間が充分割に合うのなら、 > > よい提案なのだと思います。 > 上述したようなものを異なるブランチで作るのは大変賛成ですが、 > やはり人間的なコストがかかりますね。 > > > いま現在は、おそらく私の勉強不足のため、あまりピンときません。 > > また「前時代的」であることは優劣とは関係ありませんし、 > > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。 > すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。 > > > 個人的には、stableなDebian GNU/Linuxにおいてapt-getでインストールできないモジュール、 > > cpanで手で入れるようなモジュールにプログラムを依存させるつもりは全くありません。 > ふむ。 > apt-get出来るモジュールだけで作るというのであれば今回の話は完全になかった事になるかと思います。 > > 思いつく解決法としてはlocal::libなどを使用し、moduleを同梱するという可能性がありますが、 > まだAnyEventにせよPlackにせよ完全に安定したとは全くもって言えません。 > > とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていくのがいいのかなぁ。と思いました。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-02-04 09:51 by
noblejasper
#48317)
返信
チケットに引用
追記:
最近出てきたような新しいモジュールを使ってブランチを作ってみる。
とかは試作してみてもいいのかなーとかも思いました。
#48316
への返信
メッセージ #48317 への返信
×
題名
本文
メッセージ #48317 への返信 > 追記: > 最近出てきたような新しいモジュールを使ってブランチを作ってみる。 > > とかは試作してみてもいいのかなーとかも思いました。
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-03-10 19:44 by
morimoto
#49338)
返信
チケットに引用
[メッセージ#48316 へのフォロー]
> > いま現在は、おそらく私の勉強不足のため、あまりピンときません。
> > また「前時代的」であることは優劣とは関係ありませんし、
> > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。
> すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。
ハックするのもいいけど、実際に使いたいという気持ちのほうが70%ぐらいかな、
少なくとも僕は。
あと、あくまでも現時点での話ですよ。
10年前だったら、Perl 4で書かれたplumでまあ実用上問題ないやと思っていた
わけですし、逆に2年後とかに、なんでkeitaircをPlackベースに書き直さない
んだよこのタコ! とか私自身が言っている可能性だってありますw
> とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていく
> のがいいのかなぁ。と思いました。
別ブランチで先進的な取り組みをしていくのは良いことだと思います。
ただ、今の状況で、単に前 (別ブランチだから、斜め前かな?) にだけ
アクセルを踏んでも、やりっぱなしで失速する予感がします。
* cvsじゃなくて、もうちょい現代的なversion control管理に改善する
* test suiteを整備する
** いちおう *.t の場所はありますけど、まったくもって不完全です
** irc serverとやりとりするソフトウェアのテストをどう書くべきか?
RDBにアクセスするソフトウェアをテストするためにFixtureがあるように、
irc serverとのインタラクションをエミュレートするFixture的なものが
あるといいかもしれませんね。
このへんに取り組むのは、まだ他に誰もあまりやってないかもしれないし、
hack valueもあると思います。
また、これを使うのはkentaircエンドユーザではなく、keitairc開発者だけで
すから、多少先進的なperl moduleを使うのも時にはありでしょう。
まずはこのへんに取り組んでみるのはいかがでしょう?
#48316
への返信
メッセージ #49338 への返信
×
題名
本文
メッセージ #49338 への返信 > [メッセージ#48316 へのフォロー] > > > > いま現在は、おそらく私の勉強不足のため、あまりピンときません。 > > > また「前時代的」であることは優劣とは関係ありませんし、 > > > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。 > > すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。 > > ハックするのもいいけど、実際に使いたいという気持ちのほうが70%ぐらいかな、 > 少なくとも僕は。 > > あと、あくまでも現時点での話ですよ。 > 10年前だったら、Perl 4で書かれたplumでまあ実用上問題ないやと思っていた > わけですし、逆に2年後とかに、なんでkeitaircをPlackベースに書き直さない > んだよこのタコ! とか私自身が言っている可能性だってありますw > > > とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていく > > のがいいのかなぁ。と思いました。 > > 別ブランチで先進的な取り組みをしていくのは良いことだと思います。 > > ただ、今の状況で、単に前 (別ブランチだから、斜め前かな?) にだけ > アクセルを踏んでも、やりっぱなしで失速する予感がします。 > > * cvsじゃなくて、もうちょい現代的なversion control管理に改善する > * test suiteを整備する > ** いちおう *.t の場所はありますけど、まったくもって不完全です > ** irc serverとやりとりするソフトウェアのテストをどう書くべきか? > > RDBにアクセスするソフトウェアをテストするためにFixtureがあるように、 > irc serverとのインタラクションをエミュレートするFixture的なものが > あるといいかもしれませんね。 > > このへんに取り組むのは、まだ他に誰もあまりやってないかもしれないし、 > hack valueもあると思います。 > > また、これを使うのはkentaircエンドユーザではなく、keitairc開発者だけで > すから、多少先進的なperl moduleを使うのも時にはありでしょう。 > > まずはこのへんに取り組んでみるのはいかがでしょう?
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-03-11 00:03 by
noblejasper
#49356)
返信
チケットに引用
[メッセージ#49338 へのフォロー]
> [メッセージ#48316 へのフォロー]
>
> > > いま現在は、おそらく私の勉強不足のため、あまりピンときません。
> > > また「前時代的」であることは優劣とは関係ありませんし、
> > > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。
> > すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。
>
> ハックするのもいいけど、実際に使いたいという気持ちのほうが70%ぐらいかな、
> 少なくとも僕は。
>
> あと、あくまでも現時点での話ですよ。
> 10年前だったら、Perl 4で書かれたplumでまあ実用上問題ないやと思っていた
> わけですし、逆に2年後とかに、なんでkeitaircをPlackベースに書き直さない
> んだよこのタコ! とか私自身が言っている可能性だってありますw
>
> > とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていく
> > のがいいのかなぁ。と思いました。
>
> 別ブランチで先進的な取り組みをしていくのは良いことだと思います。
それは確かにそうですね。。。汗
僕も「まだ早すぎるかも」とか思ってます。
でもプロジェクト自体が「あれって古いよねー」って扱いになるのがちょっと淋しい気がするので、
別ブランチうんぬんは「ありかも」って思います。
> ただ、今の状況で、単に前 (別ブランチだから、斜め前かな?) にだけ
> アクセルを踏んでも、やりっぱなしで失速する予感がします。
それは危険ですね。。。かなりあり得ますし。
> * cvsじゃなくて、もうちょい現代的なversion control管理に改善する
> * test suiteを整備する
> ** いちおう *.t の場所はありますけど、まったくもって不完全です
> ** irc serverとやりとりするソフトウェアのテストをどう書くべきか?
>
> RDBにアクセスするソフトウェアをテストするためにFixtureがあるように、
> irc serverとのインタラクションをエミュレートするFixture的なものが
> あるといいかもしれませんね。
>
> このへんに取り組むのは、まだ他に誰もあまりやってないかもしれないし、
> hack valueもあると思います。
>
> また、これを使うのはkentaircエンドユーザではなく、keitairc開発者だけで
> すから、多少先進的なperl moduleを使うのも時にはありでしょう。
>
> まずはこのへんに取り組んでみるのはいかがでしょう?
はい。そうですね。
とりあえず現状で一番気になるのは
> * cvsじゃなくて、もうちょい現代的なversion control管理に改善する
ですかね。
個人的にはgitよりSVNの方がいいかなーと思ってます(完全に個人の好き嫌いです)。
SVNに移行しようと思って、とりあえず
rsync -av rsync://keitairc.cvs.sourceforge.net/cvsroot/keitairc/* .
とかしてみたらエラーが出て既に挫けそうですが・・・笑
#49338
への返信
メッセージ #49356 への返信
×
題名
本文
メッセージ #49356 への返信 > [メッセージ#49338 へのフォロー] > > > [メッセージ#48316 へのフォロー] > > > > > > いま現在は、おそらく私の勉強不足のため、あまりピンときません。 > > > > また「前時代的」であることは優劣とは関係ありませんし、 > > > > たとえばmobircという選択肢もあるいま、保守的であることはむしろ美点だと思っています。 > > > すみません。そういう価値観(保守的)なプロジェクトであるという事をあまり認識していませんでした。 > > > > ハックするのもいいけど、実際に使いたいという気持ちのほうが70%ぐらいかな、 > > 少なくとも僕は。 > > > > あと、あくまでも現時点での話ですよ。 > > 10年前だったら、Perl 4で書かれたplumでまあ実用上問題ないやと思っていた > > わけですし、逆に2年後とかに、なんでkeitaircをPlackベースに書き直さない > > んだよこのタコ! とか私自身が言っている可能性だってありますw > > > > > とりあえず今件に関してはmrmtさんのおっしゃる通り現状のまま進めていく > > > のがいいのかなぁ。と思いました。 > > > > 別ブランチで先進的な取り組みをしていくのは良いことだと思います。 > それは確かにそうですね。。。汗 > 僕も「まだ早すぎるかも」とか思ってます。 > でもプロジェクト自体が「あれって古いよねー」って扱いになるのがちょっと淋しい気がするので、 > 別ブランチうんぬんは「ありかも」って思います。 > > > > ただ、今の状況で、単に前 (別ブランチだから、斜め前かな?) にだけ > > アクセルを踏んでも、やりっぱなしで失速する予感がします。 > それは危険ですね。。。かなりあり得ますし。 > > > > * cvsじゃなくて、もうちょい現代的なversion control管理に改善する > > * test suiteを整備する > > ** いちおう *.t の場所はありますけど、まったくもって不完全です > > ** irc serverとやりとりするソフトウェアのテストをどう書くべきか? > > > > RDBにアクセスするソフトウェアをテストするためにFixtureがあるように、 > > irc serverとのインタラクションをエミュレートするFixture的なものが > > あるといいかもしれませんね。 > > > > このへんに取り組むのは、まだ他に誰もあまりやってないかもしれないし、 > > hack valueもあると思います。 > > > > また、これを使うのはkentaircエンドユーザではなく、keitairc開発者だけで > > すから、多少先進的なperl moduleを使うのも時にはありでしょう。 > > > > まずはこのへんに取り組んでみるのはいかがでしょう? > はい。そうですね。 > とりあえず現状で一番気になるのは > > * cvsじゃなくて、もうちょい現代的なversion control管理に改善する > ですかね。 > 個人的にはgitよりSVNの方がいいかなーと思ってます(完全に個人の好き嫌いです)。 > > SVNに移行しようと思って、とりあえず > rsync -av rsync://keitairc.cvs.sourceforge.net/cvsroot/keitairc/* . > とかしてみたらエラーが出て既に挫けそうですが・・・笑
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-03-11 00:29 by
noblejasper
#49357)
返信
チケットに引用
とりあえず
http://sourceforge.jp/docs/%E3%82%B3%E3%83%BC%E3%83%89%E7%AE%A1%E7%90%86%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E7%A7%BB%E8%A1%8C
ここで申請すればsfの人が移行してくれるんですね(汗
#49356
への返信
メッセージ #49357 への返信
×
題名
本文
メッセージ #49357 への返信 > とりあえず > http://sourceforge.jp/docs/%E3%82%B3%E3%83%BC%E3%83%89%E7%AE%A1%E7%90%86%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E7%A7%BB%E8%A1%8C > > ここで申請すればsfの人が移行してくれるんですね(汗
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル
RE: やはりkeitaircは前時代的な件について (2010-03-15 16:02 by
morimoto
#49485)
返信
チケットに引用
> でもプロジェクト自体が「あれって古いよねー」って扱いになるのがちょっと淋しい気がするので、
セキュリティホールを放置したりするのは良くないことで、素早く積極的に直すべき理由がありますし、そうすべきですが、設計やモジュールが古いこと自体はなんら問題ないでしょう。
なので「ちょっと寂しい」というのは私にはわかりません。つきつめると感覚論の雑談にしかならない気がします。
古いから、こういうデメリットがある、なのでこうしたい。ということなら判ります。
(という話のくりかえしになってきている気もします)
#49356
への返信
メッセージ #49485 への返信
×
題名
本文
メッセージ #49485 への返信 > > でもプロジェクト自体が「あれって古いよねー」って扱いになるのがちょっと淋しい気がするので、 > > セキュリティホールを放置したりするのは良くないことで、素早く積極的に直すべき理由がありますし、そうすべきですが、設計やモジュールが古いこと自体はなんら問題ないでしょう。 > なので「ちょっと寂しい」というのは私にはわかりません。つきつめると感覚論の雑談にしかならない気がします。 > 古いから、こういうデメリットがある、なのでこうしたい。ということなら判ります。 > (という話のくりかえしになってきている気もします)
Wiki文法は使えません
ログインしていません。投稿を区別するために投稿者のニックネームをつけてください(ニックネームの一意性は保証されません。全く別の人も同じ名前を利用することが可能ですので本人であることの特定には利用できません。本人であることを保証したい場合にはログインして投稿を行なってください)。
ログインする
ニックネーム
プレビュー
投稿
キャンセル