  |
はてなキーワード: Gitとは
I want to display mathematical formulas in SSG, so I have installed the KaTeX plugin.
In the case of SSG (honkit) that I use, I want to convert the part to a mathematical formula into
Enclose it in $ (dollar mark) and write the contents in so-called TeX.
In fact, the github site also supports math rendering.
I think it's pretty familiar.
I wanted to mention Excel's built-in functions. What are Excel functions?
I use the dollar mark when I want to keep the cell fixed even if it gets copied and pasted.
I want the dollars to remain dollars inside the code block.
For example on the markdown source side
```markdown
=\$A\$2
````
I thought I could escape it by adding a backslash, so that's what I did.
In the case of the SSG that I use, when converted to html,
````
\{% math_inline %}A\{% endmath_inline %}2
````
As for the hosting method, I also store the html files in a GIT repository and host them on the `vercel.app` site. Regarding markdown → html, I do it in the local environment instead of using GitHub Actions.
I confirmed that if I use full-width instead of half-width for the dollar, it would not be recognized, so I confirmed that it would work.
But this isn't a fundamental solution, is it?
Also, open the html file and use the batch replacement function to replace `{% math_inline %}` and `{% endmath_inline %}` with dollars. It seems that you need some wisdom to selectively replace only the fence code blocks at once.
https://github.com/zimmem/honkit-plugin-katex
Markdown's fence code block is a guy who repeats backticks three times.
In some cases, the only option is to ask the author to ignore the dollar sign conversion.
The author of the plugin seems to have stopped development a long time ago.
It seems like they won't be able to respond.
Also, in the case of inline math, it says to surround it with two dollars each, and in the case of block math, it says to surround it with two dollars + a new line, which is different from the normal syntax. I'm curious.
However, it will work even if you write it in the md source using normal syntax.
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
他に遭遇したケースは、環境のアップグレードによってphpが特定の関数を廃止したというケースだ。
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
gitを利用してローカルファイルを取得し、Node.jsで静的サイトを生成し、serveを通じてブラウザに表示する予定でした。ブラウザはAndroidタブレット用のChromiumです。sudoを使わずにNode.jsをインストールすることに懸念がありましたが、sudoがなければNode.jsをインストールできない場合、それは大きな問題になります。しかし、よく考えてみると、外部ホスティングサービスを使用すれば、ブラウザから直接アクセスして十分に機能することがわかりました。例えば、Vercel.appにホスティングして、Androidタブレットのブラウザ（Chromiumなど）からアクセスするのが良い解決策だと思います。
PowerShellでGitコマンドを実行できるようになりました。この進歩は、技術の進化に対する感慨深い思いを抱かせますね。
Windows環境でGitをインストールし、WSLの使用を最小限に抑えることは、開発効率を高める一つの方法です。しかし、Linuxベースのメールユーザーエージェントに慣れている場合、同等のWindowsアプリを見つけることは挑戦的かもしれません。K-9 Mailのようなアプリケーションは、そのオープンソースの性質と高度な機能性で人気がありますが、Windows用の類似アプリは少ないのが現状です。ただし、Androidエミュレータを使用してPC上でK-9 Mailを動作させる方法があります。また、Windows 11のメールクライアントに関する詳細なレビューとおすすめのアプリケーションリストがあり、これらはK-9 Mailの代替として検討できるかもしれません。
べつにおどろくことでもなんでもないけど、honkitできた！
Node.jsがらみのツールらしい。これってのもはじめての経験だ。Node.jsとはjsの開発環境のこと？なんじゃ？IDE？
ディレクトリーに適当にマークダウンファイルやjsonファイルをおいておけば、HP作成してくれた。htmlタグをベタ打ちするのも、いやだった。だからよかった。
さいきん、ベタ打ちすることないし、といっていちいちpandocとかで変換するのもめんどうだし・・・よかった。
いまのところ、git repoでもなんでもないフォルダーにマークダウンファイルなどをおいて、honkitでウェブファイル作成してから
そいつをエイヤーっとgit repoに動かして、git push でリモートにもっていって、さらにgithub pagesでHPにしているけど・・これって
