  |
はてなキーワード: シンタックスとは
掛算の順序と学習指導要領の話おもしろかったです。
「りんごが5つ載った皿が4枚ある場合にりんごがいくつになるか」という問題を立式するときは、
という話だと思いました。
4✕5は4[個/枚] * 5[枚]に変換されるので、正解にならない。
✕は乗算の演算子と思ってしがいがちだけど、被乗数と乗数の順序を考慮するときは、その順序を含めた乗算のシンタックスシュガーになっている。
なんか、このシンタックスシュガーいけてないなと思うのは、計算するときは交換法則適用していいよと言われているところと、乗法を習うこの単元以外では立式の際もシンタックスシュガーではなく乗算の演算子として取り扱われているところ。
でも、いけてないシンタックスシュガーは世に溢れているので、まあいいや。
被乗数と乗数の関係を考えていて思い出したのが、消費税が導入されたとき、大学生協の書籍代はどうなるのかという話。
乗算は交換法則が成り立つから1000*0.9*1.03でも1000*1.03*0.9でも良いです。
✕も計算のときは交換法則を適用して良いから1000✕0.9✕1.03でも1000✕1.03✕0.9でも良いです。
でも✕で立式するときはどうなるのか。
1000[円/冊]✕1[冊]✕0.9✕1.03と1000[円/冊]✕1[冊]✕1.03✕0.9のどちらが正しいのか。
0.9と1.03は単位がないから乗数、被乗数の順序を考慮しなくて良いのかな。
僕が小学生の頃は乗数、被乗数は「かける数」「かけられる数」と言われてました。
「この式の４は『かける数』でしょうか『かけられる数』でしょうか」みたいなテストの問題があったけど、「この話は、ここでしか出てこないので、気にしなくて良いです」と先生が言って、採点対象外になってました。
生産性になぜ差異が生じる かの原因の 1 つは，おそらく文章を書くという作業があ る種のスキルであることに起因していると考えられる． すなわち，生まれつきの技能や特別な才能ではなく，地 道に練習をすればある程度までは論文を執筆するスキル は身に付けられるものであり「文章を書くという作業を 習慣化する（生活の中に組み込む）」ことこそが最も重 要なのではないかと思う．
自分自身を振り返ると，授業 や学内業務，社会活動をはじめ様々な日常業務がある中 で，いつも忙しいというのを言い訳にして「もう少しま とまった時間があれば，もっと論文が書けるのに」とい つも考えており，その改善策を考える上で，私の周りに いる生産性の高い研究者に教えを乞うことが有効だと考 えた．
そのため，論文執筆の生産性が高いと考えられる 研究者を対象に，執筆作業の効率化およびそれを習慣化 するための具体的な工夫等について聞き取り調査から明 らかにすることを試みた．対象者は，論文の生産性がかなり高い研究者 3 名（男性 2 名, 女性 1 名）であった．調査内容は， 1 ）論文執筆作業を習 慣化するための具体的な工夫， 2 ）論文執筆作業を効率 化するための具体的な工夫，の 2 点である．
論文執筆作業を習慣化するための工夫として，「タイ ムマネジメント」の一環として，論文執筆の日は出張に 行く日と同じという感覚を持つことが挙げられた．具体 的には，実際は自分の研究室にいるが，出張で終日不在 にしている体裁で論文執筆作業のみを行うというやり方 であった．特に，手帳に論文執筆の日であることを明記 し，他の予定を入れない，メールの確認頻度を減らす， 急用でないとメールは開かない，集中度が高いときは電 話にもでないという工夫をしていた．
また，早朝の時間 を論文執筆作業に充てるという意見もあった．学生指導 を含めた業務時間を自他共に分かるようにし，指導学生 には業務時間になってから相談して欲しい旨を伝える工 夫を行っていた．
さらに，無駄な時間や作業を減らすた め，非常勤講師や超過コマを持たない，むやみに学会発 表をしないといった意見もあった．
一方，いつまでに書 き上げるかのタイムスケジュールを（数カ月単位で）徹 底的に組み締切を作る，最低でも一文を書いてから帰宅 する等の「目標設定」を上手に行っていた．また，構想 から論文化までを一括管理し，何をどこまで書いたかを 常に把握しておく（可視化する）といった「セルフ・モ ニタリング」，できる限り大学に行く（まずは **やる場所** に行く），ふと良い流れや改善点，文章が浮かぶため， 常にメモができる状態にしておく等の「環境整備」に関 する工夫がみられた．
論文執筆作業を効率化するための工夫としては，作業 過程を 5 段階に分類するという意見があった．具体的に は，
①先行研究の動向を把握する段階（雑誌の最新号目 次のメール配信サービスの活用），
②データを分析し， 結果を確定させる段階（シンタックスを自分で書き, 分 析手続きの記録を残す），
③論文構成を考え，まとめる 段階（「日本語で」「段落ごとに」執筆する内容や主な引 用文献を, 箇条書きに簡潔にまとめる），
④文章を執筆す る段階（数日程度, 執筆のみを行う時間を作り, 細部は気 にせず一気呵成に書き通す），
⑤文章をブラッシュアッ プさせる段階（冷静に見直すため少し日数を置き, 全体 の一貫性など細かな修正を行い, 仕上げる）であった．
また，書く→修正→書く→修正ではなく，執筆自体が止 まらないようとりあえず全体を書いてから修正する，上 手に気分転換を図る（同時に複数の論文を書き, 1 つが 行き詰まったら他の論文を進める）といった意見も挙げ られた
論文執筆作業を習慣化するとい うことは，自分が重要性を感じているその他の時間との 価値交換を行う場面が多々あるため，なぜ自分は論文を 書くのかということを改めて突き詰める必要があるよう に感じた
数学の必然性は実は人間の言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね～
なぜ数学と言語能力が関係するんだ？と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね～
・“Colorless green ideas sleep furiously.”（「無色の緑の考えが猛烈に眠る。」）
・“Furiously sleep ideas green colorless”（「猛烈に」「眠る」「アイデア」「緑色」「無色」）
前者は文法的には正しいが意味が無い文で、後者は文法的に正しくないから意味がない文、ということはわかっていただけるかと思います。
しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。
ということは、経験こそが認識の基礎、基底であると考える人にとっては、二種の文の違いを説明することができないのですよね～。
なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから、経験的基底において違いのない(意味のなさ、指示対象が存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね～
現代の言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学の必然性がどこから来るのかという問題について、
文の経験的理解よりも前に、文の文法的分析が先に行われる(そして数学的必然性は、文法分析に基づく理解そのものから正当化可能である)ことを示すことによって、
前経験的(アプリオリ)に論理や数学の必然性の正当化が可能であることを証明してきたんですね～
例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味の解釈に失敗するから無意味なのであって、その逆ではないのですね～
そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね～
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね～
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね～
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね～
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね～
もー超ウケるんだけど。
聞いてくれる？
GPT-4ちゃんの超絶賢い素早い翻訳でお客さんとのやり取りが滑らかに捗りまくりまくりすてぃーで、
私のビジネスが加速するのはいいんだけどPayPalが止まるという笑っちゃうでしょ？
ウケるわ。
と言うのもあんまり年に何回か以下のPayPalでの入金がないから
ここのところ立て続けに問い合わせなど多くってその分のお支払いの入金も立て続けにあるわけね。
いまそう言うお金の管理のサービスってちょっと変な動きがあると警告が来るじゃない。
最近急激に受取金額が通常と比べて著しく増加しているのでって理由で警告が出たの。
まあ実際に真っ当なやり取りでの受け取りだからそれは内容問題ないんだけどさ。
21日間そこから日本円に移せない保留期間になっちゃったってだけの話しなんだけどね。
もう笑うわー
それなんて言う「風が吹けば桶屋が儲かる」バタフライエフェクト方式か！つって
加速したら止まるってジワるわー。
なのでもう1回言うね！
GPT-4ちゃんでビジネスが加速したらPayPalが止まる！
あーウケるわ。
抱腹絶倒とはこのことね。
まあ実際そこまではないけど気持ちはそんな感じかしら。
でもさ、
まあここでも256回ぐらい同じことを何回も言ってるけど
よく言うニュースでやってるなんか難しいプログラムがどうのこうの難しい分析がどうのこうのって
そんな凝ったテクニカルなことをやっているわけではなく
ただただGPT-4ちゃんとお話ししながら翻訳してもらってるつーだけの話しなのよ。
大まかな内容を私が箇条書きで書いて、
むしろ私が書き忘れたことや言い忘れたことの細かいことを付け加えてやり直してもらうことが多いので、
もはや英語に限らずなのがまったくもって私もそれが本当に正しいのか分からないけど、
これあってんの？って直接GPT-4ちゃんにたずねるとそれもちゃんと答えてくれるから
対話型もなにも自分が思ったことを書いて渡せばいいだけの使い方なのよ。
「さっきのにこの内容の旨付け加えてもう一回お願い！」とかで言う指示の仕方でフレンドリーだし、
多少こっちがタイプミスだったり誤変換だったりゴホンと言えば龍角散だったりしても
そこも推測して踏まえて何事もなかったかのように、
本意を理解してくれてるみたいなのよね。
でさ、
私が素でタイプミスしたところをワザとゴメン意味これ分かった？ってGPT-4ちゃんに訊くと、
文章の前後文脈でおおよその理解は出来るから大丈夫でーす！だって！
人でもいるじゃない、
もー一字一句間違えたら鬼の首取ったどーってそれなんて黄金伝説？って言うぐらいな尾根ギアしますな人いるじゃない。
同じ事繰り返しお願いしても嫌な顔しないし。
同じ事繰り返しお願いしても喜んでくれるのはGPT-4ちゃんと居酒屋で生ビール頼む時よね！「喜んで～！」みたいなの。
なーんで持ってんの？
なーんで持ってんの？
飲み足りないから持ってるの！
飲～んで飲～んで飲～んで！
飲～んで飲～んで飲～んで！
ってもう大学のうちのサークルは歓迎会とかでコールとかないから！って言いそうなぐらいよ。
まあそんなこんなで
GPT-4ちゃんでビジネスが加速したらPayPalが止まったってお話でした。
今日も締めは機関車トーマスのお話の終わりのような感じで締めくくるわ。
うふふ。
朝だんだん早くなってきて目覚めるんだけど、
今日はなんか肌寒くて目が覚めた感じの起床30分前で、
でもさなんでモーフって毛布って変換出来ないのかしら？変なの！
一瞬また忘れて思い出してやろうとしていたルイボスティーウォーラーも
これからの時期また復活させたいところだわ。
困るわよね。
すいすいすいようび～
今日も頑張りましょう！
chatgptで
「sqlite3でtwitterみたいなサイトのテーブル設計をして。
上記のTwitterのようなサイトで特定のユーザーのタイムラインを表示するクエリの例を教えて」
って聞くと、こういうの表示されるけど、こんなの絶対パッと思いつかんやろ!!
特にJOIN2回使うのが全然分からん。なんならJOIN1回の部分も分からん
っていうか、hatena君、sqlのシンタックスハイライトするとインターナルサーバーエラー返してくるんだが...
class Foo def bar'baz' # return baz end end
sqlだけっぽい......
CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL, email TEXT NOT NULL UNIQUE, password TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tweets ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, body TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users (id) ); CREATE TABLE follows ( follower_id INTEGER NOT NULL, followed_id INTEGER NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (follower_id, followed_id), FOREIGN KEY (follower_id) REFERENCES users (id), FOREIGN KEY (followed_id) REFERENCES users (id) ); SELECT tweets.id, tweets.body, tweets.created_at, users.username FROM tweets JOIN follows ON tweets.user_id = follows.followed_id JOIN users ON tweets.user_id = users.id WHERE follows.follower_id = [特定のユーザーID] ORDER BY tweets.created_at DESC;
RubyやRailsでどう書くかを知っているか知っていないかだけでそれがプログラミング能力だと勘違いしてる人が多い。全員というわけではないが……
「このライブラリでこう書ける」とか「こういう書き方がある」とか「こっちに書くとここがこうなる」とか、そういった規約覚えゲー的なところに目を取られて、どれだけRuby on Rails関連の規約をたくさん覚えているかでプログラミングスキルが高いか低いかを考えてる人が多い。もちろんそうした覚えゲーもある種プログラミング能力の一部なのだが、一方でライブラリを単に入れただけでは実現不可能なパフォーマンスを考えたコードを書くときやアーキテクチャ設計の段階では、何年も経験しているはずなのに役立たずになる。
ググるのが面倒なシンタックスシュガーや、ライブラリを導入した人しか辿り着けないconfigなど、規約（笑）とかいう発見非可逆なルールによって、それを導入した人だけが知っていて既得権益を得られるような構造になっている。そのために、ある機能を新しく利用したときに、それを知らない人にRails知識マウントを取れるようになっている。この気持ち悪さは、例えるなら、刑法を全部読んでからじゃないと街を歩くだけで逮捕されて、しかも何の罪で逮捕されているのか教えてもらえないようなものだ。
それで、全員というわけではないが、そういったRailsしか書けないおじさんは別言語で書くときに平気で今までプログラミングしたことないかのようなレベルの最悪のクソコードを生み出してくる。そもそも他言語が書けないおじさんも多い。
なぜなら、Rails知識こそがプログラミングスキルだと考えていて、Rails知識すごいワールドでしか生きてないからだ。覚えゲーをやっていただけで、スキルとしてはポケモンの名前を覚えただけにすぎない。社内スキルのようなものだ。
自分としてはRubyやRailsが直ちに滅びるとは思っていないが、Railsをメインで使ってる会社からしても、こうしたRailsしか書けないおじさんは今後不要になってくると思う。
ベトナム語は格変化とか名詞の性がないので日本人には覚えやすい言語だとどこかで読んだ気がするけど、実際に勉強してみると自分にはものすごく難しい。
なんで難しいのか考えてみると、まず声調のせいだと思う。
中国語と違ってベトナム語は綴り字のうちに声調の記号が入ってるので、まだわかりやすいといえばわかりやすいのかもしれない、けど、やっぱり全然慣れない。特に文末で高い声調のまま終わるタイプの話し方は日本語にほとんどないと思うので、本当に慣れなくて苦手。
あと、ベトナム語は似たような発音の単語が多すぎて区別できない。
ベトナム語っぽい音としてニャーとか、ニュアとか、ブアとか、ズンとか、ザーとか、ダオとか、同じような音が違う発音記号付きで次々と出てきて全部意味が違うので、覚えようとしても無理だ。
ベトナム語って、実はロマンス語系の言語に結構似てるようなシンタックスだなと思うことが割にあるんだけど、繋合動詞も格変化もないからやはり違うわけで、謎すぎる。
他の東南アジアの言語か中国語をちゃんとやっている人がベトナム語を勉強すると、わかりやすかったりするのだろうか。少なくとも自分にはさっぱりわからない。
さんざんベトナム語への愚痴を書いたけど、できるようになりたいと思っているので、何か上手い学習法があれば試してみたい。
追記：
Cảm ơn chị
（噛むウンチ）
どもども。
わたしは「なにか作ってみろ」系の言説にはまったく同意しません。
わたし自身、会社に3ヶ月間みっちり導入教育をしてもらい（COBOL85とPL/I。時代がわかる……）、基本的なアルゴリズム（コントロールブレーク、マッチング、マスタ－トランザクション、ソート、マージ、etc.いよいよ時代がわかる……）の演習を（給料をもらいながら）やって、その後もプログラムとつかず離れずでフラフラと生きてきました。
こういう経験は新卒カードがあるから有効なもので、では1から始めるとしたら……、というときに、プログラミングスクール（専門学校）というのは悪くない選択肢ではないかと思います。が、行ったことないので正直わかりません。
実際自分が1から始めるという立場になったら、まったくオロオロして元増田さんのように世のなか（の気にいらないヤツら）に呪詛を吐いて満足するだけだったと思います（当然ながらそれをいくらやってもプログラミングは上達しません）。
話をプログラミングだけに限っていえば、一番大事なのはやりかたじゃなくて動機だろうと思います。
「なにか作ってみよう」というのは、なにか作ってみようと思ってない人にはまったく心に響かないでしょう。
動機ドリブンで「なにか作ってみた」人といえば思いだすのは、MikuMikuDanceの樋口優さん（ミクを簡単に踊らせたい！）とhinadanの若宮正子さん（高齢者にも遊べるゲームが欲しい！）でしょうか。
ただかれらはわたしから見れば（モチベーションを維持しそれを行動に移す）天才で、あんまり参考にならないのも確かです。
あと、元増田さんの動機は「プログラミングを生業にしたい」ということなので、野良プログラマでは履歴書上でのアピール力が弱いかも、と思います。
ビジネスで使われるアルゴリズムにはそれなりのルールがあります。安全な（バグの出にくい）コードの書きかた、「車輪の再発明」はぜず、枯れた（将棋で言えば定跡のような）アルゴリズムを使う、ほかの人に使ってもらえるための工夫（可読性の向上など）、etc.です。
「なにか作ってみよう」を繰りかえしても、そういった作法的なものが身につくかどうか、それは才能に関わってくる問題だと思います。才能だのみの手法を推奨するのは無責任だと思いますね。
また、たとえば「例をコピーして解析する」というのもある意味有効なプログラミング学習法ですが、「下手に習うと下手が伝染る」ともいいます。どれがお手本として優れているか、それを見る目はある程度ビジネス用途のプログラムに関わっていないと持てないというジレンマがあります。
野生のプログラマで就職に有効なくらいの力を見せるとしたら、なにかのコミッター（なにする人かよく知りませんが）とかになって「××ならこの人」となったり、プログラミングコンテストで上位の成績を残したりしなければいけないのかもしれません。
どうしたものでしょうね。ブクマカのみなさんの反応を見ると、専門学校でもあまり就職に有利にならない（ホントか？専門学校の意味あるのか？）という話ですが、目的が就職ならば、一番の近道のような気がします。
そこらへんからは、元増田さんがなにをしたいか、あるいは聞いてみたいだけだったのかによります。仕事には適性とやる気が大事です。あとは年齢と必要性かな。進路はオーダーメイド以外にはありえないので、提示された案を自分で選んでそれに賭けるしかないのかな、と思います。
さて、この文章は実はこの一文に反応してのものです。（↑のは前書き）
GWあたりからトシも考えずにRubyの再入門をしていまして、手始めに「首相動静」の整形ツールを作ってみました。
初心者で（Rubyに関しては仕事で使ったことないので）なにか作ってみよう、というとこの程度ですね。
これで就職に有利になるかというと、あんまりそうは思えないなあ。Excelのマクロが組めるとかのほうがどこかの事務所に潜りこめそうですよ（でもそれも最近はインフレ気味かもしれませんね）。
朝日新聞の首相動静は詳細ですが、改行が入っておらず、大変読みにくいものです。こんな感じです。
【午前】９時３１分、自民党本部。３３分、同党役員会。１０時２分、官邸。５分、閣議。２１分、宇宙開発戦略本部。３４分、柴山昌彦文部科学相。３８分、岩屋毅防衛相。４１分、山下貴司法相。１１時３分、安全保障と防衛力に関する懇談会。
【午後】０時１１分、政府・与党連絡会議。４４分、山口那津男公明党代表。１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。２時２０分、行政改革推進会議。５２分、兼原信克官房副長官補、秋葉剛男外務事務次官。３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。４時７分、太田氏出る。可部哲生理財局長加わる。１５分、全員出る。２５分、黒川弘務法務事務次官。３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。４１分、谷内、宮川両氏出る。５時３分、北村氏出る。１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。２０分、官邸。６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。２７分、アクフォアド大統領と会談。７時１２分、署名式、共同記者発表。３２分、公邸。首相主催の夕食会。８時４３分、アクフォアド大統領を見送り。９時、ヨルダンのアブドラ国王と電話協議。
ただ、これはフォーマットがはっきりしており、
と、例を見るかぎりキッチリとしたルールに則っているようです。
なので、「これだったら整形できるかも」と思い、再び学びはじめたRubyで整形ツールを作ってみることにしました。
【午前】
１０時０２分、官邸。
１０時０５分、閣議。
１０時２１分、宇宙開発戦略本部。
【午後】
０１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。
０２時２０分、行政改革推進会議。
０３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。
０４時１５分、全員出る。
０４時３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。
０４時４１分、谷内、宮川両氏出る。
０５時１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。
０５時２０分、官邸。
０６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。
０６時１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。
あと、午後の時刻を24時間制にしたいな、とも思いますが、それは今後の課題（つぎに首相動静が話題になったとき）とします。全角数字の計算ってどうやるんだろう？
たぶんRubyistにいろいろ突っこまれると思うけど、こんな感じです。
プログラマは玉石混淆ですが、これは石のほうの例だと思っていただければさいわいです。
※ はてな記法にはシンタックスハイライトあるけど、増田だとInternal Server Errorになるのではずしました。見にくくてスマソ。
# encoding: utf-8 # 漢字コンバータのライブラリを取りこむ（Stringに漢字変換メソッドを付けてくれる。神） require 'kconv' # 正規表現パターン # 時刻をｈ時ｍ分形式からｈｈ時ｍｍ分形式にする # 否定後読みを使用する # 時は行頭にある OneDigitHour = /^((?<![０-１])[０-９]時)/ # 分は時のあとにある。このパターンとマッチすると、\1が時、\2が分になる。 OneDigitMinute = /^([０-９]{1,2}時)(?<![１-５])([０-９]分)/ # 分のない、時だけの行のパターン。否定先読みを使用 HourWithoutMinute = /^([０-９]{1,2}時)(?![０-５]?[０-９]分)/ # 行頭のｈ時ｍ分をｈｈ時ｍｍ分にするサブ処理（これは関数といっていいの？） def convTopHourMinute2TwoDigits(oneLine) # 時を変換 oneLine.sub!(OneDigitHour, "０\\1") # 分を変換 oneLine.sub!(OneDigitMinute, "\\1０\\2") # 分がない場合"００分"を追加 oneLine.sub!(HourWithoutMinute, "\\1００分") # 戻り値 oneLine end # 入力ファイルの名前 InputFilename = "首相動静2018年12月11日.txt" # 出力ファイルの名前 OutputFilename = "首相動静2018年12月11日_編集済.txt" # 入力ファイルをオープン inFile = File.open(InputFilename, "r") # 出力ファイルをオープン outFile = File.open(OutputFilename, "w") # 時刻パターンはシンプルに、ｈ時、ｍ分、ｈ時ｍ分、という3パターンを結合する # 1つのパターンで全部カバーするよりこちらのほうが見やすい。というか、脳の容量の問題で1文に書ききれなかった jikokuPattern = /[０-９]{1,2}時[０-９]{1,2}分、|[０-９]{1,2}時、|[０-９]{1,2}分、/ # 午前/午後 ampm = /(【午前】|【午後】)/ # 午前/午後、あるいは時刻の前で改行するためのパターン kaigyouSign = Regexp.union(ampm, jikokuPattern) # ファイル一括読み込み # 昔は1行ずつ読みこんでました。メインメモリが3MByteとかだったので contents = inFile.read.toutf8 # 入力終了。閉じておきます inFile.close # スコープの関係から、ここでローカル変数に代入 # ※ Rubyのスコープと暗黙の型には泣かされました。これに慣れるのがRubyのコツかしら # 明示的な型宣言はあったほうがいいと思うなあ。エラー出力の理由がわからなかったりするので。 hour = "" # デバッグ行はコメント化しています # 時刻パターンチェックのため、コンテンツを出力してみる # p jikokuPattern.match(contents) # エントリを改行サインで行に分ける contents.gsub!(kaigyouSign, "\n\\&amp;") # "\\&amp;"はマッチした文字列そのもの。2重のエスケープ"\\"が必要 # 改行チェックのため出力 # p contents # 入力を行で分割して各行ごとに処理 contents.split("\n") do |oneLine| # 午前/午後を示す開きカッコ"【"があるか if (oneLine =~ /^【/) then # そのまま出力 outFile.write(oneLine + "\n") # p "午前午後：" + oneLine next # 空白行は無視（スキップする） elsif (oneLine =~ /^[\s ]*$/) then # 出力しない # p " 空白行：<skip>" next # 行頭に「時」があるか elsif (oneLine =~ /^[０-９]{1,2}時/) then # あったら時間表示を抜きだしておく hour = oneLine.match(/^([０-９]{1,2}時)/)[0] # p " 時：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") next else # 「時」がなければつけて出力 oneLine = hour + oneLine # p "普通の行：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") end end
手でやったほうが早いね。
以上
グループSNEがプログラムのSyntax Errorが元ネタであることはWikipediaにもあるくらいに知られていて、
大昔のラジオのなんだったか、たぶん麗しの我が家亭かなんかだと思うのだが、グループSNEの人が出てて、由来を聞かれたときに
「コンピュータの文法間違いのシンタックスエラーが元、どうしてSNになったのかはたぶん英語ができなかったかなんかだと思うんですが(笑)」
みたいなことを言ってた記憶がある
…SNになったのは、Syntax ErrorをSN Errorと略すBASICがいくつかあるので、その略し方が元だと思うんだ
むしろ聞いてた当時はSN Errorはえすえぬえらーで、Syntax Errorの略だと知らなかったくらいなのでよく覚えてる
覚えていても仕方ないので忘れることにしよう
udemyでいくつかのコースを取ったのだが、気になったことが、日本と英語のコンテンツの差が気になった。
レベルや内容はほぼ同じなのだが、日本の方は結構編集が粗い。英語が10なら日本は7か8くらい。
シンタックスミスや、スペルミスを普通に流して、ローディングなどの時間のかかるところをスキップしない。普通に流す。
すげぇ細かいところだけど、こういうのは受講者としては混乱の元になる。
自分も講師みたいなことをするんだが、分からんことを知るために参加しているのに、さらに謎なことをしていると「何してるんだ?」と置いていかれている感じになり、受講者の集中力が切れる。
高校時代の数学とか教師が間違えたりしてうーんと唸ってるときクラスの雰囲気が変になったりしなかっただろうか？
ネイティブな言語で聞いているから何となく分かるんだが、これを英語でやられたら多分理解度はグッと下がる。
多分、フリーランスの人が頑張って作ったんだろうが、惜しいなと思った
