質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.35%
Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

Q&A

解決済

2回答

4106閲覧

Pythonでの定刻実行の達成方法をおさらいしたい、24時に定刻処理をスケジュールしなおすと、処理がWる

saya24

総合スコア247

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

0グッド

1クリップ

投稿2020/06/22 16:45

編集2020/06/23 01:14

TkInterのUIで、実行したい定刻処理をデータベースに登録する機能を作りました。また同UIから、それらの起動も達成しようと考えています。

予め登録の定刻処理をデータベースから抽出し配列に格納、ループで配列から出力される定刻処理で、schedule.every().~を組み立てる、
ループ最後では shedule.run.pendingを秒単位に行う別関数(start)を呼び出すことで、定刻起動を果たすことに成功しました。
同UIから先に登録したscheduleを、別操作で停止することが必要とも考え、UIの操作を維持するために上記をスレッドに払い出す手立てをとりました。
この結果同UIから別関数(stop)を呼び、秒間隔のshedule.run.pendingを停止させることに成功、起動と停止が思うように達成できていました。

【問題点】
定刻実行の設定に曜日指定があること、及び当該アプリを24時を廻って利用し続けている利用者のことを考慮する必要があると気が付きました。
対策として、24:00にscheduleをクリアし リスケを行うようなことが必要という解釈をしました。

time_count関数に24:00を廻ったら...という条件を追加、stop関数同様にスレッドをクリアする措置を投じようと思いましたが、
「 self.thread.join() 」の部分で、cannot join current thread というエラーが現れてしまう事象を招いています。
この行が問題ならば...と深く考えず当該行を除去してみたところ...24:00以降 定刻処理がWって起動してしまう事態を招いてしまいました。
UIからの操作でスレッドのクリアが対応できるのなら 定刻の自動でもできるはず、と浅はかな考えをしてしまいました。

そもそも scheduleを クリアして 入れ直すみたいな 措置は スレッドをクリアする手立てとは なんら関係を持たないのでしょうか????
初めてのPython、初めてのマルチスレッドで 一体どうしたものか? と頭を悩ましています。

どなたかご見解を頂けましたら幸いです。

Python

1 def time_count(self): 2 while not self.stop_flag: 3 schedule.run_pending() 4 time.sleep(1) 5 6 dt_now = datetime.datetime.now() 7 if dt_now.strftime("%X") == "00:00:00": 8 # 終了 9 if self.thread: 10 self.stop_flag = True 11 self.thread.join() #★☆★cannot join current thread が現れる、除去すると定刻処理がWる 12 self.thread = None 13 14 # リスケ 15 time.sleep(5) 16 self.on() 17 18 else: 19 print(dt_now.strftime("%X")) 20 21 22 def start(self): 23 # スレッドが無いなら生成してstart()する 24 if not self.thread: 25 self.thread = threading.Thread(target=self.time_count) 26 self.stop_flag = False 27 self.thread.start() 28 29 30 31 def stop(self): 32 # スレッドがある場合停止してjoin()する 33 if self.thread: 34 self.stop_flag = True 35 self.thread.join() 36 self.thread = None

20200623 10:11追記

breakいれたあとのtime_count関数「リスケ後定刻処理が2重になってしまう」

Python

1 def time_count(self): 2 while not self.stop_flag: 3 schedule.run_pending() 4 time.sleep(1) 5 6 reschedule = False 7 dt_now = datetime.datetime.now() 8 if dt_now.strftime("%X") == "09:57:00": 9 # 終了 10 reschedule = True 11 break 12 13 else: 14 print(dt_now.strftime("%X")) 15 16 #リスケ 17 if reschedule: 18 rechedule = False 19 time.sleep(5) 20 self.thread = None 21 self.on()

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yymmt

2020/06/22 21:37 編集

以前、適当なソースコードを貼り付けたのを後悔しつつあります。本格的なアプリケーションをお考えでしたら以下の要件を明確にして追記をお願いできますでしょうか。 1. 定刻に起動した処理はどのくらいの時間継続し終了するか(あるいは終了しないのか) 2. Windowsがスリープ状態でも時刻になったらWindowsを起こしてでも実行したいかどうか 3. インストールのサポートは開発者自ら行えるかどうか(アプリだけ渡す/インストーラを作るかも含めて) [追記] 本格的でなければ特に追記しなくて良いです。まずは今のソースコードの問題点だけ回答しました。
saya24

2020/06/22 22:15

ご親切にこちら目線になってのご見解をありがとうございます。 決して販売目的とか決算数字・命に関わるものではございません。 1: 多くても2分程度でしょうか? 2: 利用者の身になればYesですが、それによって、今回の開発が大規模になるなら諦められる要件です。 3: InstallShieldを利用してexe化したものを配布しようと考えています。以前使ったことがあること、出来栄えがはえるから、というくだらない理由です。 すみません、本文ではないですがご質問への回答となります。 初めてのPythonコーディングですが、少し凝りすぎました。
yymmt

2020/06/23 04:28

> 決して販売目的とか決算数字・命に関わるものではございません。 安心しました。それならば色々と無茶ができそうですね。
teamikl

2020/06/23 05:04

質問文からは、曜日指定のタスクを毎日0:00に組みなおすように取れるのですが、 `schedule.every().wednesday.at("13:15").do(job)` のように、 予め曜日指定でスケジュールを入れておけばよいのでは?
saya24

2020/06/23 05:18

このアプリは基本毎日出社時に立ち上げて帰宅時に電源遮断するパソコンで利用する目的でいます。 電源あげっぱなしを基本運用・推奨するような使い方はしたくないので、実行中以外の日付のスケジュールまでをキューに入れる(?)ようなことは やめておこう、と思ったのです。 ただ....そうは言っても....電源が遮断されず日を跨いでパソコン(アプリがあげっぱなし)な状態は亡きにしも あらずと考え、24時にリスケする処理を盛り込んでおこうと思ったのです。 当日以外のタスクスケジュールをパソコンに入れることに ちょっと気が引けた....というだけのことです。すみません
teamikl

2020/06/23 06:20

なるほど。scheduleモジュールに特定曜日に実行の機能があるのに、 再実装?と疑問に思ったので。そういった事情であれば納得です。
guest

回答2

0

スケジュールはメソッドからの推測ですが、schedule を利用ですか?


if dt_now.strftime("%X") == "00:00:00":

は、稀に期待通りに動かないケースがあります。

time.sleepで保証されるのは1秒以上の間隔で、
必ず1秒後直ぐに処理が再開されるという保証はありません。
また、時間のかかるタスクが直前にあると "00:00:00" に実行されないことも有ります。

取り零しが出る可能性があり、再現性の低いバグの原因となり得るので、
やるとしたら、スケジューラ自体に停止処理のタスクを任せた方が良いです。
(リスケジュールのタスクを定時処理にする、等)


そもそも scheduleを クリアして 入れ直すみたいな 措置は スレッドをクリアする手立てとは なんら関係を持たないのでしょうか????

どのようにスレッドとスケジューラを使われているのかによります。
質問に提示されたコードでは関係を持つようにはなってません。

スレッドの起動時にスケジューラーのクラスが初期化されるような実装であれば、
スレッドの再起動がスケジューラの再起動となりますが、
現状の実装は、スケジューラーの初期化は何処か(ソース中にないが、メインスレッド)で
time_count()はスケジューラ内のタスク処理のみです。


if self.thread:

複数のスレッドから書き込みが発生する場合、
マルチスレッドでは以下のような順序でコードが実行される可能性も考えて
「ロック」が必要になります。

if self.thread: # メインスレッド self.thread = None # サブスレッド self.thread.join() # メインスレッド: エラー

thread.join() は、スレッドを生成したスレッド(この場合メインスレッド)
でスレッドの処理が正常終了するのを待つために使うもので、
スレッド内での join は不要です。
スレッド内での self.thread = None もやめた方が良いでしょう。
(複数のスレッドからの書込&参照になる為、ロックが必要になる)

メインスレッドで thread.join() する場合、GUI を併用する場合だと
スレッドの処理が終わるまで待つ間、GUI のイベントループも止まり
UIがフリーズするので注意してください。通常は、プログラム終了時、
GUIが終わった後に正常なリソースの解放を待つ等の用途に使います。

リスケジュールで必要なのは、スケジュールの変更であって
スレッド自身の初期化は直接関係ありません。
設計次第では、スレッドは起動したまま schedule を差し替える事もできます。

self.on() が何かわかりませんが、掲載のコード中には
スケジュールのクリア等は見られないので、原因があるとすれば他の部分です。


24:00にscheduleをクリア

は onメソッド内で行ってるのですか?

  • onメソッド
  • startメソッド呼び出しの部分
  • scheduleの初期化

辺りが不明ですが、scheduleを初期化せずに使いまわしている場合に、
問題の様な現象が起こることが考えられます。

scheduleの中身を表示し確認してみてはどうでしょう

追記: 確認用のコード

python

1for job in schedule.jobs[:]: 2 print(job)

投稿2020/06/23 04:45

編集2020/06/23 23:48
teamikl

総合スコア8760

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

saya24

2020/06/23 05:53

teamiklさん、いつもお世話になっております。理解できていることから順次回答させて頂きます。 1.ご察しのとおり利用のモジュールはSCHEDULEです。 >リスケジュールのタスクを定時処理にする 全く思いつきませんでした。ユーザが入力する目的以外のスケジュールを内部で登録してしまう手立て、確かにありですね、今の作りに適用できるか少し考えさせてください。 >スケジューラーの初期化は何処か 本当にスケジュールをクリアする手立てが、今先ほどyymmtさんから紹介を受けた記事をみるまで 存在さえ把握していなかったのです。つまりは スケジュールのクラスを初期化する部分は 現在のところ一切ありません! >複数のスレッドから書き込みが発生する場合、 後ほど ゆっくり確認させて頂きます。この辺り よくわかっていないんで 落ち着いて読みたいです。 (もうすぐ会議で席外しいます)
saya24

2020/06/23 08:00

>scheduleを初期化せずに使いまわしている場合に、 問題の様な現象が起こることが考えられます。 私もそう思います。本当scheduleについて対応したことといえば、スレッドで秒間隔でrun.pendingしているだけ、もしくはrun.pendingしないようループを抜けることしか実装していませんでしたから。 もうちょっとしたらscheduleのクリアについて 手をつけます。 やはりメインスレッド・サブスレッドの話は 難しいですねぇ~ 本当まだ理解に苦しんでいます。 TkInterのUIをメインスレッドと解釈すべきなのでしょうかね~、もう少し考えてみますね。 確実に言えること: onという関数(メソッド)の役割・内容は 登録されている定刻実行の種類をデータベースから配列としてえて、順次shedule.every().~を 要素の数だけ生成、最後に 秒間隔でscheduleを監視するための(schedule.run.pending)関数をスレッドでスタートさせる ってことです。
teamikl

2020/06/23 11:05

スレッドはそのままにして、>リスケジュールのタスクを定時処理にする で曜日指定のタスクを更新するだけで済みそうですね。 "00:00:00" == と秒単位の時間比較は、 例えば 23:59 に2分かかる処理があった場合に、 定時処理の時間が過ぎてしまうので、ここは修正対象です。 他は(複数のスレッドから同じ変数にアクセスする時のロック等)、 スレッドを終了・再起動しない場合は不要になる部分なので、 無視しても大丈夫です。
saya24

2020/06/24 05:54

24時のはなし: なるほど、こういう時のために 払い出したスレッドを待つ という概念が必要なのですね!
saya24

2020/06/24 12:47 編集

今更ながら…上記で記載頂いたスレッドに用意されたメソッドの説明、ようやく分かってきました。 と、いうのは TkInterのUIからも、スケジュールを停止する制御を設けており(24時のリスケ以外)、こちらのスレッド(払い出したつもりはないが)からthread.joinを行った場合にはエラーにならない… かたや「自らのスレッド」つまりはschedule.run.pendingを行なっている同関数内で24時を察知してthread.joinを行おうとしたら エラーになった為なんです。 このスレッドの違いを指していたのか〜、とようやく実感できました。オブジェクト指向の意識の欠如ということでしょうか。 さて、 20:05のご提案、24時にリスケするだけなら、スレッド払出しのschedule.run.pendingは行い続けてよいのでは???に対してですが、これは 一つ一つの登録scheduleの単位に schedule.run.pendingが行われる作り・仕様の場合!!ということでしょうか? 当方、秒間隔のschedule.run.pendingを行う関数を スレッドで払い出している点は 既に存知上げておられることと思いますが 配列に蓄えた全ての定刻処理をscheduleに登録した後に、一度だけスレッドでrun.pendingの関数を開始する作りになっているのが現況です。Pythonのscheduleモジュールの使い方が そういう例ばかりで 当方もその方式を採用しています。 ご提案は 停止・リスケ含めて、各々の定刻処理=scheduleを、TkInterのUIから、個々の子スレッドとして払出す場合のご提案ですかね? その仕様であれば、24時に実行中の子スレッドを、停止・リスケ様のschedule=別スレッドが待てる筈!ということを申されているような気がするのですが 合っていますでしょうか? 合っているとなると、登録のscheduleの単位にschedule.run.pendingを実装することができるのだろうか??という迷いが生じております。 一つ一つの登録scheduleをオブジェクト化して、個体化・識別できるのでしょうか? < https://qiita.com/Kai-Suzuki/items/0c5c0e5cbdb4075fe482>この記事からではそういった事ができるように発想ができないのですが。 引き続きご見解を頂けましたら幸いです。
saya24

2020/06/25 02:35

TkInterのUIからの操作で 登録済スケジュールを停止する上で thread.join が行える理由は schedule.run.pendingを行っているスレッドは UIのスレッドとは異なるためですよね?? ご提案頂きました 定刻でリスケのためスケジュールを停止する手立てでも 申し上げられているように、実行中の自身スレッド(schedule.run.pending)を待つ必要があると思いました。「23:59 に2分かかる処理があった場合に」のくだりですね。 停止のための関数が双方で共通の場合、どちらの経路からのスレッドか見極めて、thread.join をする・しない を判断する、必要があると思いました。というか...thread.joinをできるかできないかですね。 でも、スケジュール経由・定刻で停止する場合であっても、待つ必要がありますよね~??? 上で長々と記載してしまいましたが schedule.run.pendingを 各々のスケジュールごとに発生させないと 別スレッドにならない、そうしないと リスケ用の停止スケジュールを実行させるとき、直前に実行したスケジュール・スレッドの完了を待つことができないのでは?? と思いました。 妙なことを申し上げておりますでしょうか?? 分かりが悪くすみません
saya24

2020/06/25 02:54

停止する目的のスケジュールは 別のスレッドで schedule.run.pending を行えば 良いのかな
teamikl

2020/06/25 08:15

ちょっと疑問点を全部把握しきれてないので、要点のみ改めて書きます。 後々見直して追記するのでご了承を。 まず、schedule を別スレッドで動かす点は大丈夫です。 > ご提案は 停止・リスケ含めて、各々の定刻処理=scheduleを、TkInterのUIから、個々の子スレッドとして払出す場合のご提案ですかね? 提案は"00:00:00" == と秒数が一致するかどうかで判断してる点の改善です。 ここが、例えば 23:59 に 2分かかるジョブがあると次のジョブ実行が 00:01 になる可能性があり、リスケジュールが実行されない可能性があります。 解決策として提案したのは、スケジューラー自身にこれをジョブとして実行される方法です。 schedule.every().day.at("00:00").do(job) <- 毎日0時にリスケジュールを実行 スケジューラのジョブの再構築ができれば、スレッドの再起動は不要になるので、 ロック~等と説明していた箇所は省けます。 (スレッドを中断・終了する場合の注意点の説明だったので)
saya24

2020/06/25 09:36

ありがとうございます。 >解決策として提案したのは、スケジューラー自身にこれをジョブとして実行される方法です。 Yes、Yes、これはよく分かりました。いいアイデアだと思います。 で確認したかった内容は、提案の定刻処理もTkのUIから子スレッドで払い出したら、子スレッド同士でThread.joinを使えないのでは?? 別スレッドにする手立ては?を知りたかったです。 ま....書いている自分でも 確認したい内容がどんどん変わってしまい ご迷惑をおかけしている状況を十分に認識しているので、別案件を掲載させて頂きました。そちらの内容のほうが 回答しやすいかもしれません ご確認いただければ幸いです。
teamikl

2020/06/25 10:00

要点はそこだけだったので、残りの点は後で確認してみますね。 一点だけ明らかなのは >子スレッド同士でThread.joinを使えないのでは??  thread.join はそのスレッドを生成したスレッドから スレッドの終了を待つ為に呼び出すので、 スレッド内で thread.join することはありません。 スレッド内で自分自身の終了を待つことになるので永遠に終了できません。 (ここがもし必要だと感じているなら、恐らく設計の間違いです) 自分の提案では、リスケージュールでの スレッドの再起動が必要なくなるので、そもそもスレッド内での thread.join ~辺りのコードは不要になるはずです。 (この辺が文章では判り辛いと思うので、コードで提示できればと思います。取り急ぎ返信のみ)
saya24

2020/06/25 12:08

私、何かの認識を根本的に間違っているのでしょうね。あきらめずにお付き合いを頂き本当にどう感謝したらよいものか。本当にありがとうございます。 早速ですが 「スレッドの再起動が必要なくなるので、そもそもスレッド内でのthread.join〜辺りのコードは不要になるはずです。」 これも納得できているのですが、 「例えば23:59に2分かかるジョブがあると次のジョブ実行が00:01になる可能性があり、リスケジュールが実行されない可能性があります。」を記載いただいた事に由来して、分からない事があるのです。 『動作したら動作したで、実行中のジョブの終了を待つ必要があるのでは?待たずにスケジュールクリアする事に不安』という点を気にして疑問点・解決策の必要性を感じているのです。この考えを持つこと自体がひょっとして間違っているのかもしれませんね。 この面で thread.joinは 使えませんよね?? 互いは子のスレッド同士になるので、という意識があって やりとりを継続させて頂いてます。 この面に意識をはたらかせると、そう考えてしまったのですが、そもそも意識不要なのか・やはり何らかの解決策を取るべきなのか、取るべきとした場合は妥当な案はどういったものか、を教えて頂きたいのです。 きっと私の考えに何か間違いがあるとおもうのですが…正して頂けませんか?
teamikl

2020/06/25 12:55 編集

>『動作したら動作したで、実行中のジョブの終了を待つ必要があるのでは?待たずにスケジュールクリアする事に不安』 何処で(どのスレッドから)待つかという視点が必要です。 ジョブは順番に実行されるので、 ジョブ内で更にスレッドを使ったりしてない限りは、 必ず前のジョブが終わってから次のジョブが実行されます。 もし「別スレッドからスケジュールクリアする場合」は、その通り ロックを使うなどしてまた実行中・実行予定のジョブは待つ必要があります。 ですが、同スレッド内から「リスケジュール自体をジョブとして登録」 では、同スレッド内で順番に呼び出されるので追加で待つ必要はありません。 呼び出された時点で前のジョブは完了してます。 また、関連として注意が必要な点 run_pending()の説明にも書かれているのですが、 例えば毎秒実行するジョブがあったとしても、 1分間に必ず60回実行される保証はありません。 (別途、各ジョブが遅延なくすぐ終わる様にする対策が必要です) 他に問題点としては、0時にリスケージュールを予定するとして 00:01時にリスケジュールが発生した場合(秒数比較と違い、取り零されることはありません、実際の実行時間は遅れても必ず実行されます) 0時丁度に実行予定の他のジョブは、実行されるジョブに含まれるのかという懸念はありますね。 scheduleライブラリに詳しくないので実際どうなってるのか解りませんが、この辺は確認が必要です。
saya24

2020/06/25 13:09

ジョブは順番に実行される、必ず前のジョブが終わってから次のジョブが実行される、追加で待つ必要はない この前提が分からずに話をしていたがため、貴重なお時間を頂いてしまったようですね。誠に申し訳ございませんでした。 いづれにしても、スレッドについて今回正しく理解できていたみたいで、最終的には話が噛み合っていたことを実感でき 喜びを感じています。すみません。本件本当のクローズです、ありがとうございました。
guest

0

ベストアンサー

疑問点について1つずつお答えします。

「 self.thread.join() 」の部分で、cannot join current thread というエラーが現れてしまう事象を招いています。

エラーメッセージにもあるように、スレッドのjoin()ができるのは親スレッドのみです。join()は子スレッドの終了を待つための関数です。

この行が問題ならば...と深く考えず当該行を除去してみたところ...24:00以降 定刻処理がWって起動してしまう事態を招いてしまいました。

スレッドとして起動する関数time_count()が無限ループになっていますので、この無限ループを終了させることが必要です。該当のjoinの部分をbreakもしくはreturnとすれば良いと思います。例外を投げても良いです。

そもそも scheduleを クリアして 入れ直すみたいな 措置は スレッドをクリアする手立てとは なんら関係を持たないのでしょうか????

基本無関係だと思います。

投稿2020/06/22 21:35

yymmt

総合スコア1615

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

saya24

2020/06/22 22:18 編集

会社で試してみますね、楽しみだなぁ。 実は親父スレッドと子スレッドという言葉すら分かっていないです。 タイムカウントの一つしか、スレッドを払い出した記憶がないのですが。
saya24

2020/06/23 01:11

停止時刻になって breakでループを抜けた後、その要因で停止した場合はリスケする必要があるので、threadをクリアして、再度一連をやりなおすよう(スケジュールの登録と、スケジュールを秒単位で監視してスレッドとしてスタートさせる)をやったのですが 相変わらず 停止時刻後 定刻処理がWってしまいます。画面に現れている時分秒のprint文は1行単位なのですが、やはり停止前に登録されたschedule・スレッドが活きてしまっているようです。 scheduleをクリアするようなメソッドはないのでしょうか?何が問題で前のスレッドをクリアしても、2重で定刻処理が起動してしまうのでしょうか.... 本文に 改修後(breakを挿入したのち)のtime_count関数を追記します。
saya24

2020/06/23 05:00

ありがとございます。やはりスケジュールをクリアすることができるのですね。 この記事を最初から見つけられればと 今さらながら思っています。世の中スケジュールを登録するばかりの記事が目立ち...ちょっと読んでみます。
saya24

2020/06/24 07:36

ご紹介頂きました記事の、schedule.every().day.do(greet, 'Andrea').tag('daily-tasks', 'friend') のタグの内の第二引数って どういう意味でしょうかねぇ ほんと世の中 shceduleを登録する記事ばかりで キャンセルの仕方を取り扱った記事が見つけられなくて
yymmt

2020/06/24 09:40

tag(*tags)と書かれていて説明には「一つ以上のユニークな識別子をジョブにタグ付けする」となっています。ソースコードを見るとsetによる集合で、clearメソッドでジョブを削除する際に指定します。上記の例だとclear(tag=['daily-tasks'])を指定してもclear(tag=['friend'])を指定してもこのジョブは削除することができます。
saya24

2020/06/24 10:28

ご親切な説明をありがとうございます。登録するスケジュールを特定するための印は幾つもつけられる、ということですね。分かりました。 別案件のサンプルソースも修正を頂いたようで。まだまだお二方の話しが次元の違う話に聞こえます。今の段階では、正直申し上げて何のことやら、という状態ですが、将来確実に有効な情報になるに違いありません。重ねてお礼を申し上げます。
saya24

2020/06/25 04:52

当方が掲載したタイトルの要因、スケジュールのクリアの必要性・クリアの手立をご提案頂けましたので こちらはこちらで クローズと致します。ありがとうございました。 先ほど、別案件で、払い出された個々のスケジュール処理(同一スレッド)側で どう互いに完了を知ることができるか を掲載させて頂きました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.35%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問