  |
はてなキーワード: マークアップとは
経済学って偉そうに需要と供給で価格が決まるんだとか語るけど、それは現実からズレてるんだよな
価格を決める側は需要なんて観測できないから、原価率または利益率から価格を決めたり、競合他社の値段を市場調査して決める
供給の方はまあ、自分達側なんだからある程度わかるだろうが（どこが限界かやってみないと分からなそう）
それなのに需要と供給がわかれば、適正な価格がわかるって何を言ってんだ？って思うんだよな
普通に考えて、コストプラス法、マークアップ法etcとかそういう先に挙げたような方法で価格を決めて、実際に売ってみて、在庫がどうなるかを観測する事で初めて需要がわかる
それなのに需要と供給で価格が決まるんだとかいう経済学は後出しでほら需要と供給で価格が決まってると数字を見てるだけなんだよな
現場がどうなってるのか考えない
そんな考え方を元に経済政策をしようとしたらどうなるか
賃上げでお金配って、消費を増やせば、需要が増えるんだから、景気が良くなるとか言うんだろうな
そうとは限らないでしょ
そうなると原価率や利益率を元に算出してた価格を変えようとなるわけだ
するとモノの値段が上がるわけで、上がったモノの値段を見て、それを買っていた購買層はどう思うかやってみないことにはわからないわけだ
給料増えたならモノの値段が上がっても買うはずと言うかもしれないが、そもそも給料上がったやつとそのモノを買っていた購買層は一致するのか？
また、上がった給料が手に入るのとモノの値段が上がるのはどっちが先か？
とかも違うわけで
需要が増えたら売れるはずと思ったのに、売れないなんて事が起こり得るわけだ
売れないならモノの値段を下げればいい？
えーっとそのモノの値段は経費から算出されててそうなると利益を下げないといけないわけなんですが？
利益率に余裕があればいいよ、まだ
余裕がなければどうなる？
売れないけど下げることもできないとなる
そうなるとどうする？
そして、失業者が出る
こんな事になりかねないわけだ
ちなみに、経済学を擁護するとポストケインズの賃金利潤の対抗関係のようにマークアップの事を語ってる異端派の経済学というのも存在する
でも、こういう両論語ってる経済学者ってあんまりメディアとかで見ない気がする
事後的に数字だけを見るんじゃなくて、時間とか因果とかの順番や現場でどうやってるかなど複合的な事を考えて語れよって思い
こうすればこうなりますとか単純化したり、○すれば×になります（実際は×したら○になる）とか誤解される事を言い切るのをやめろ
事後的なデータを見ることや単純化することで見えてくる事もおそらくあるんだろうけど、聞いてる側はその前提条件に気づいてないから騙してるようなもんなんだよな
てか、語ってる方も本当に気づいてるのか怪しいが‥
俺の語ってる経路もまだ前提条件が抜けてたわ
YouTuberを始めるにあたって昨日今日と環境構築をしている。
動画のジャンルは内緒として、ひたすら効率良く動画を作ることを志向してる。理想は新規のMarkdownファイルがGitHubのmainブランチにマージされたら自動でYouTubeの自分のチャンネルに動画が投稿される、みたいな状態。
まあそこまでやるのは調べるの大変だし事故とかbanが怖いしまずYouTuberとして大成しないことにはって話なので、どっかで妥協すると思う。てかCI/CD周りちゃんと仕事でやっとけばよかったな。
テキスト読み上げで商用利用するなら今はVOICEVOXが良いのかなと感じた。
ただ、作成した音声に合わせた字幕ファイルを作るのがひたすら面倒くさい。絶対自動出力できそうなのに。
VOICEVOXから直で出してくれたら楽だったんだけど、リップシンク用のファイル出力しか対応してなかった（どっかでやってる人がいるかもしれない）。
VOICEVOX公式のGitHubでissue上げることも考えたけど、俺自身がまだ動画一つも上げてないし、字幕ファイルの需要がどれほどのものかも分からないので、とりあえず変換用のスクリプトを自分で書いてみた。
VOICEVOXのプロジェクトファイルであるvvprojファイルの中身はバイナリではなくただのJSONなので、エディタやエンジンのソースコードを弄らなくても、比較的簡単に字幕ファイルに変換できる。なお今回俺はDenoを使った。
こういうシェルスクリプトみたいな小さい仕事やるのにDenoはまじで楽。
あとは動画作るときに需要ありそうだなと感じたら、SubViewer以外のマークアップに対応させてissue上げるなり俺のrepoに置いとくなりしようかな。
エンジンの実態はhttpサーバーらしいので、上手くやれば意外と労力かけずに理想に近い自動化が実現できるかもしれない。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
■メモ
いやいや「だから」って言われても、その前提条件が意味不明なんだよ。
上記の通り、もともと国債には政府の財源調達なんて意味はなく、インターバンク市場の金利下支えの機能しかない。
その一つが、現在実際に各国で採用されている(超過)準備に対する付利制度です。
しかしながら、もっといいのは最初から中央銀行がインターバンク市場金利を上下することをやめることです。
つまり「恒常的ゼロ金利政策」といって、金利政策自体をやめる。
これは効かない、というより、どのような効果があるのかわからない、という意味です。
教科書に書かれているような、製造業が金利低下によって設備投資を増やし、金利上昇によって設備投資を減らす、という効果は、実際にほぼ全く期待できないことが実証研究で（もう1970年代ぐらいには）はっきりしていました。
■俺の理解
国債には政府の財源調達なんて昨日はなく、インターバンク市場の金利下支えの機能しかない。
そのため中央銀行は「恒常的ゼロ金利政策」を取り、金利政策自体をやめるべきである。
＞https://www.boj.or.jp/announcements/education/oshiete/seisaku/b28.htm/
＞一般に、金融政策による、（実質）金利の低下・上昇が経済活動に与える影響は、以下のように考えられています。
＞金利が下がると、金融機関は、低い金利で資金を調達できるので、企業や個人への貸出においても、金利を引き下げることができるようになります。また、金融市場は互いに連動していますから、金融機関の貸出金利だけでなく、企業が社債発行などの形で市場から直接資金調達をする際の金利も低下します。
＞そうすると、企業は、運転資金（従業員への給料の支払いや仕入れなどに必要なお金）や設備資金（工場や店舗建設など設備投資に必要なお金）を調達し易くなります。また、個人も、例えば住宅の購入のための資金を借り易くなります。
＞こうして、経済活動がより活発となり、それが景気を上向かせる方向に作用します。また、これに伴って、物価に押し上げ圧力が働きます。
上記のように、教科書に書かれている効果は、実際にほぼ全く期待できないことが実証研究で（もう1970年代ぐらいには）はっきりしている。
■メモ
「金利政策に意味がないのが1970年代には実証研究で分かっている」ってうさん臭いな。それもしかして「製造業の設備投資」だけで見てるない？
金融政策は金利かマネーストック（マネーサプライ）その結果としての為替レートを操作の目標とするが、金利の操作を止めるべきとな？金融政策はマネーストック（マネーサプライ）の操作だけでやるとな？大胆！
また現代の製造業では原価計算に基づく目標マークアップを実現できるように価格設定がなされる。
■俺の理解
現代の製造業ではマークアップ法、仕入れ原価にある一定の利益率または利益額を加えて価格を設定する、を使用して価格決定を行っている。
そのため金利を上昇させるとかえって物価の上昇を促すことになる。
しかし不動産では工事着工件数を増やすなどの効果があり得るとしています。
■メモ
金利を上昇させるとかえって物価の上昇を促すことになるってほんま？アベノミクスでゼロ金利になったけどなんか値下がりした？
そして現在のように年金など金利所得層が増えた状態では金利引き上げの効果はむしろ年金受給層などの支出を増やす傾向にある。
そもそもMMTの枠組みからすれば、政府による金利支払いは民間の純所得を増やすはずであり、これは民間支出の増加につながるはずです。
ところがその一方で金利引き上げによって金融資産価格が上昇すれば、それは資産階級の支出を大いに刺激する。
さらにこうした動きがコモディティーにまで波及すれば、今度はこれが原油や金属などの素材関連のコスト引き上げにつながり、インフレを刺激する面も持つ。
こうしたことを勘案したとき、MMTにとって金利政策というものが景気にどのような効果をもたらすのか不可知となります。
何より、こうした金利操作それ自体が金融市場の不確実性を高め、投機活動の機会を提供し活発化させ、金融不安定化をもたらす。
だから中央銀行はこうした金融投機活動を抑制し、銀行による不適切な融資活動を監視し、金融市場を安定させることに注力するべきで、金融政策など放棄するべきだ、という立場です。
■俺の理解
金融政策で政策金利の引き上げを行うと、金融市場の不確実性を高め投機活動の機会を提供し活発化させ金融不安定化をもたらす。
そのため中央銀行は金融投機活動の抑制、銀行による不適切な融資活動の監視を行い金融市場を安定させることに注力するべきで、金利政策は放棄するべき。
■メモ
金利政策によって不確実性が高まる可能性があるかないかで言うとあるが答えだが、それは金利の上下以外でもマネーサプライの増減によっても生じるのでは？
なお、MMTは現在のような国債制度の廃止を主張する一方で、場合によってはインフレを抑制するための「戦時公債型国債」の発行を提案しています。
これは現在の国債とは異なり、民間銀行の預金により売買され、特別な事情がない限り、一定期間、売却や譲渡ができず、担保にも使えないという国債です。
■メモ
そんなもん誰が買うんだ？
デザイナ会社のweb部隊でディレクション・マークアップ・JS書いてる三十路前の女
30代後半～50歳手前のおっさんばっか。
入社当時は、10人ほどいた部隊はこの4年で6人辞めた。私も辞めたい。
社内でそれなりに評価は貰えてると思う。
同年代平均よりも貰ってるだろうし、出身地方の月給15万とか見るとこの道進んでよかったなぁと思う。
だけれど、仕事が楽しくない。
ディレクションが増え、実務でコーディングする時間が徐々に減ってきて..あれなんでここ会社居るんだっけ？と思うこともしばしば。
IT技術の勉強でもするかと奮起するが、何を勉強していいかいつも悩む。
情報系専門学校卒で、資格だけはとにかく持ってる。知識でっかちの豆もやし。
実際に手を動かすと、全く何も出来ない。
なにがしたいかわかんねぇ。
ノリと勢いでweb業界にいる私に、次何を学べばいいかおしえてちょ☆
保持資格
・Oracle bronze
基本情報午後のCASL勉強してた10年ぐらい前と応用情報受かって、ネットワークスペシャリスト受かるぞと燃えてた頃が、1番楽しかったな。
トレースは技法なので基本的に写真などからのトレースはノーカウントにしたい。同業者の創作物からトレースはちょっとオイオイってなる。
重要な立場のもの、たとえば主人公だとかが「これまんまアレですよね？」ってなるとさすがに痛いんだけど、本筋でやられない限りはオマージュとかパロディとかリスペクトとかインスパイアと受け止めてる。
歌詞とメインメロディ以外は不問にしないと音楽が成り立たない。ドラムの4つ打ち、エイトビートなどの基本パターン、ギターやベースのリフなどをパクリじゃあああって言い始めたら音楽を作ることのハードルがやばいくらい高くなってしまう。っていうか俺はリミックスとかバージョン違いとかセルフカバーとかセルフじゃないカバーとか大好きなので歌詞とメロ以外は…ってなる。
足りなかったねん(´・ω・`)
一部の界隈の話なので説明しておくと、合成音声界隈は合成エンジンが更新されようとしている。
例えば、今日予約開始されたA.I.Voiceというソフト(https://aivoice.thebase.in/)なのだが、
エンジンは機械学習を使って新しくなろうとしているのだが、UIが過去数年前とそのままなのだ。
技術的にはTTS(Text to Speech)という分野であり、GoogleやAmazonもAppleもやっている。
合成音声マークアップ言語というのもあるが、こちらは何年も更新されていない。
ブレイクスルーが必要としているのは、演技をしたような声を出す場合だ。
音声界隈の論文では、喜び、怒り、悲しみの3種類を分類するのが伝統的になっているが、これが数値化できてない。
日本では「萌え声」というのもあるが、こちらも数値化できていない。
現状のUIは音素ごとに音の高さと長さを調整しているが、日常的に発音していても意識していないので、違和感があっても調整できない。
カラーリングで、開発環境でコードが見やすくなる。マークアップ言語には、markdown, html, wikiなどがあげられると思う。
また、xml, jsonなどのデータもマークアップ言語と言ってよいだろう。
（pythonを使えば否が応でもスペース４つを空けることになるだろう。（あるいはtab一つ分））
まずは、ブラインドタッチでマークアップ言語を書き、一文字でも違うとコンピューターは、こちらの意図通りには動いてくれないという悲しみにひたらないかぎり、
全角スペース、半角スペースを目grep出来るようにならないと、プログミングは上達しないことをここに宣言したい☆
今年の初めから、弊社の公式サイトはアクセシビリティへの配慮をすることにした。しかし、アクセシビリティをきちんとやりきるまでのハードルは結構あるため、まずはできるところからやろうということで、「音声読み上げソフトに配慮した記述」をすることになった。
たとえば「7/28(火)」はNG、「7月28日（火曜日）」ならばOK。
「7/28」だと「7がつ28にち」なのか「28ぶんの7」なのか、あるいは「7わる28」という可能性もある？ このように読み方が前後の文脈からの類推になってしまうからだそうだ。レイアウトを視覚的に捉えれば、ここにあるのは日付だなというのが判然とするけれど、非視覚的にはわかりにくいことがままある。しかし、そもそも「7月28日」と書いてあれば、視覚的にも非視覚的にも、それが日付なことが一目瞭然であるというわけだ。
「(火)」も「か」ではなく「ひ」と読みあげてしまうおそれがあるため、「(火曜日)」と書けば間違いないということらしい。
ただ、日付の直後の「ひ」なら火曜日のことだという類推に期待できるんじゃないだろうかという疑問はある。もっとも「(日)」でも「ひ」と読み上げてしまうソフトがあるかもしれないし、「(火曜日)」と省略なく書かれると迷惑だということもないから、丁寧に書いてあるという感想をもってもらえればいいかなと思った。
ほかの例では「※詳細はこちら」という書き方はNGで、「注記：詳細はキャンペーン詳細サイト（外部サイトへ移動します）（別ウィンドウで表示します）をご覧ください。」と書けばOK。
どうも記号を読み上げない音声読み上げソフトがあるらしいのだ。「※」を読み飛ばされてしまうことの対処として「注記：」と書く。「：」も読み飛ばされてしまうんだけど、この「：」はむしろ視覚的な閲覧者に対して、「注記」と注記本文との境目を明白にするために入れることになった。読みあげ的には「ちゅうきしょうさいはきゃんぺえんしょうさいさいとがいぶさいとへいどうしますべつうぃんどうでひょうじしますをごらんください」となる。丸括弧で括っている部分は、それぞれ外部サイトアイコンと別ウィンドウアイコンで表現して、alt属性に丸括弧内の文章を書くことにしている。少しHTMLが長くなるけど、まあこのほうが確かに分かりやすいのかな。
ちなみに音声読み上げソフトには、リンクリストという機能があって、ページ内のリンク部分だけを列挙したりできるそうだ。そうした場合に、複数の「こちら」が並んでしまうことを避けるために、「キャンペーン詳細」などと、できるだけユニークな言葉をリンクにしようという配慮でもあるのだそうだ。
個人的には、そもそも元の文章からして「※」という記号は不要なんじゃないかなという気持ちはあって、「注記」といわなくても、本文そのものに続いて、「詳細はキャンペーン詳細サイト（……以下略）」という文章で問題ないのではと思うのと、「詳細サイト」という言い方が、制作会社の用語な気がしていて、ふつうの人にとっては単純に「キャンペーンサイト」でいいんじゃないかなあみたいな、細かい感想は持っている。
あと「～」が使えなくなった。これ、「～」を「から」と読み上げてくれない場合に対応するために、「５～８ポイント」を「５から８ポイント」と書きましょうというのが、今弊社でやっているルールなのだが、画一的に「～」を禁止されてしまったので、「アマゾン ～最後の秘境～」とかの商品名（固有名詞）まで「アマゾン から最後の秘境から」になってしまっては困るということで、「アマゾン 最後の秘境」と、商品名としては正しくない文字列への書き換えが発生してしまっている。こうなってしまうと、そもそも正しい商品名を伝えるという観点から考えると本末転倒だし、商品名や番組名を改変しちゃって権利者から怒られるというケースさえもある。画一的に問答無用で「～」を「から」に置き換えるのは不適切なことがあるから、ある程度の判断を作業に挟む必要が生じる。しかし記号を読み上げないのなら、商品名に「～」が含まれていたって問題ないのだから、「～」を含んで良い箇所、良くない箇所というのを明白にすれば対処できそうだ。
つまり結局のところ、弊社で今実施しているアクセシビリティへの配慮は、コンテンツの校正ルールの範囲にとどまっている。したがって、校正ルールを整備をすることで、もともとアクセシビリティに配慮したコンテンツが生成されることになるし、HTML実装者は支給されたコンテンツをそのままマークアップすればいいということで、フローももう少しすっきりするんじゃないかなと思った。
音声読み上げブラウザでも、通常のブラウザでも、どちらでも間違いのない読みやすい日本語という落とし所をこれからも模索していきたいし、そうすることで、社会的要請からアクセシビリティに配慮しているっていうことじゃなくて、弊社が主体的にアクセシビリティに配慮しているという状況に持っていけたらいいなと思う。
私自身も、いつ音声読み上げブラウザのお世話になるかわからないのだから、音声読み上げブラウザの特性を把握しておくのはメリットだと思っている。日常ではなかなかできないので、仕事を通じて知見をためておけるのは、制作会社ならではだなと思って、ちょっと誇らしい気持ちになりました。
