  |
はてなキーワード: gitとは
テスト対象は大小さまざま。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にしているけど・・これって
