はてなキーワード: Gitとは
分散バージョン管理システムGitの開発者でもあるトーバルズ氏は、暗号通貨をサンタクロースやイースター・バニーと同じ神話的カテゴリーに位置づけているとユーモアを交えて付け加えた。
彼のコメントは、ビットコインの曖昧な創設者であるサトシ・ナカモトではないかという間違った憶測を含む、技術コミュニティでの議論の中で生まれた。
トーバルズ氏はこのような噂を否定し、Linuxカーネルの編集で自分の名前がユーモラスにビットコインと結びつけられたことを明らかにした。トーバルズ氏は、自分はビットコインの多額の財産を所有していないと断言し、そのような主張の信憑性については否定的であるとの立場を繰り返した。
ソース: https://www.realworldtech.com/forum/?threadid=217627&curpostid=217694
生産性が全ブラウザの中で一番低いにも関わらずなぜか使用率が高いので、生活残業を稼ぎたい人に大変オススメのブラウザです。
Windowsに最初から入っているEdgeは基本的にChromeの全ての機能が使える上に、
縦タブやOfficeファイルのプレビュー、Copilot、広告ブロックなど業務を効率化させる余計な機能がついているので禁止です。
生活残業をしたい生産性の低い社会人の合言葉は「EdgeはChromeダウンローダー」!
もちろんVimキーバインドでブラウジングができる拡張機能、Surfingkeysなんて入れたら生産性が爆上がりしてしまうので、
リンクはマウスでポチポチとクリックし、ページスクロールはマウスホイールを使いましょう。
Ctrl+TやCtrl+L、Ctrl+Wなどのショートカットも覚える必要がありません。
生活残業のためにタブを開くのも閉じるのもマウスを使うべきです。
こちらもマウスと矢印キーを使うことを前提にした非常に生産性の低いエディタであるにも関わらず使用率が高く、
と言う気の狂った操作方法しかなく、後者の場合『Shiftがすっぽ抜けるとやり直し』と言う絶望的な生産性の低さで非常におすすめ。
カーソル移動と言う一番頻出する操作方法がメモ帳と変わらないので、結局多少補完が強力だろうとVSCodeの基本的な生産性はメモ帳と同じです。
素晴らしい!生活残業にピッタリ!
VimやEmacsなどのエディタはもちろん、これらのキーバインドを使えるようにする拡張機能も絶対に使うべきではありません。
VSCodeで使えるGit系の拡張機能もバカみたいにマウスをポチポチして操作する必要があるので、
ヘタするとそのままGitコマンドを打つよりも遅そうで最高です。
間違ってもtigやEmacsのMagitなどの高速Git操作インターフェースを使ってはいけません。
わざわざGUIで操作するSourcetreeを入れるのもアリですね。
ExcelでもSpreadsheetでも全てのセルにその場限りの計算式を入れましょう。
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.
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
テスト対象は大小さまざま。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にしているけど・・これって