2022年1月21日金曜日

【Android USB oscilloscope】(4) gradleからしてわかんない

余っているAndroidスマホをオシロにしよう!

いやもうAndroid Studioの使い方がわからない.ビルドっつうたらmakeでしょという世界に棲息しているヒラサカとしては、Gradleってなんなのそれでめでたく死亡.

なので本を買いました.kindleで.

この本は言語解説書ではなくて、Android Studioの使用法が書かれています.2019年初版なのでこの世界では古い本ですが遜色なく使えそう.

gradleについて書かれた9章を読んだのだけど、読んでもわかりません.「gradle scriptに以下のcodeを追加します」みたいな調子で書かれていて、どうしてそのcodeなのかは解説されていません.よってちんぷんかんぷん.   (こちらのgradle解説はいいかも)
想像するに、javaを使い慣れた人には理解可能なcodeらしいです.つまり、javaを使えるようになるのが先決であると思われます.迂遠だ.かったるい.

ソフト素人のわたしの知識ベースはUNIXなんです.ソニーのNEWSとかSUNのsolarisを1992年から使い始めました.その流れでCやC++やmakeをUNIXの知識ベースで使えています.Linuxも同じようなもんです.

ところがjavaは何かが違う.何が違うのかは分からない.

3へ            5へ

えいめん

37 件のコメント:

  1. android studio使いにくいですよね。これを使ってから他の統合環境使うとホッとします。たぶんクセが強すぎるのだと思います。
    これだけのシェアがあるハードのメインの開発環境だからバランスの取れたトヨタ的な批判を受けにくい思考で構築されているはずと思い込んでしまうのですが、あまり人の言うことを聞かない人物が取りまとめているような気がします。
    また、Unix/Linux界とくらべて、力のある利他的なグループの存在が少ない気もします。なので、部品が揃っていないというか、何かやろうとしたら昔のBASICの様に自分でゴリゴリ処理を書いていかないと実装できない感じがします。

    返信削除
    返信
    1. ¥3000も出して買った本がまるで役に立ちません.
      わざわざ本を買うまでもなく操作できる事にページが割かれていて(wigetの配置方法とか)、そのくせmanifestやgradleの解説が少ししか無い.お金損しました.

      android studioへの目下の不満は、関数にマウスを合わせると関数定義を表示してくれない.検索機能が貧弱.だから学習が進まない.
      VScodeとかの親切さ今時はフツーなんじゃないのか?

      削除
    2. >あまり人の言うことを聞かない人物
      Googleなんて、始まりからして、典型的な、
      ・投資家が、オタクの技術で「金儲け」するために作った会社
      なので、そこには、
      ・ユーザーの視点
      なんて、微塵も感じられません。Androidが流行ってるのも、
      単に、他のOSに比べて、
      ・ライセンス料が、タダ同然(これは、単にマーケティング的な理由と思われる)
      だったからであって、決して「他より優れていたから」という理由ではありません。
      なので、それを挽回すべく、「頻繁なバージョンアップ」を、繰り返しています。
      (とりあえず「ユーザを取り込んで」から、後で何とかするという作戦。
      Androidなんて、「単なるブランド名」であって、中身は、バージョンによって全く別物です。)
      (マイクロソフトのOSも、似たような感じだが、それよりもっと酷い。)

      >自分でゴリゴリ処理
      結局「何かマトモなこと」をやろうとするとそうなるのですが、そうすると今度は、
      「バージョンが上がると、使えなくなる」
      に、ハマり出します・・・ なんだかなぁ。

      Androidが、スマホ以外に使われないのは、こういうところに理由があるように思います。
      Windowsとかは、文句を言われながらも、案外「組み込み系」で、使われてたりします。
      (某デジタルオシロの中身が、Windows OS であったのは、有名な話。Androidのデジタルオシロって、聞いたことないなぁ。自分が知らないだけかもしれないが。)

      削除
    3. >Androidが、スマホ以外に使われない
      Androidのスマホなんて、Googleの作った Reference model を、
      「ちょこっと手直し」
      しただけですからね・・・ 簡単お手軽に、スマホの出来上がり! な、ワケです。

      削除
    4. >関数にマウスを合わせると関数定義を表示してくれ

      訂正:abstructしか表示されない.abstructがサラリとしている.

      削除
    5. >某デジタルオシロの中身が、Windows OS

      たしかHPでアーキテクチャがそんなだったよな気がします.
      VXIバスに挿すカードを作るかんじ.
      あとはPC上でlabviewみたいなのでアプリを作るかんじ.

      削除
    6. 話はズレますが、なんでmanifestにintent filterを記述するのか謎だったんですが、当該アプリがOSからintentを受け取るためにmanufestに書いておく必要があるんだとか.そんなプログラム書かないから知識だけでおしまーい.

      削除
    7. android studioの関数abstruct読むよりもいちいち関数名をググる方が判るということが分かりました.

      削除
    8. androidで何か作ろうとしたら公式ドキュメントはほとんど役に立たなかったです。visual studioやunityはなんだかんだ言ってもドキュメントがしっかりしています。ネット検索でその場の解決した後、公式ドキュメントで体系的に知識を定着させるみたいな答え合わせに使えました。
      androidstudioはそれができないので、実装できた後もなんか知識がフワフワします。なので、最適解が分からず自分の知見を人に教えづらい感じです。

      削除
    9. あーそんなかんじ.
      android studioの公式web pageなんかつかえない.

      削除
    10. 確かに3,000円くらいの本を買わないと開発環境の構築ができないですよね。
      あとandroidで厄介なのは、アプリがライフサイクルやレスポンシブなどのスマホ系の機能ががっちり組み込まれていることです。
      起動してずっと電源入れっぱなしとか、単一のハードウェアに組み込み場合には逆に注意事項だらけになります。これら関係の概念や用語の把握もまあまあ面倒ですし。

      削除
    11. ふむーかったるいなぁ

      削除
    12. findViewById()はJAVAでは御馴染みでしょうけど、kotlinには不要だそうです.
      どうもsample programが納得いかなかったわけだわ.こんなのばっかし.

      削除
    13. ずっとやっている人には進歩なんでしょうけど、参照や定義が暗黙になっていくのが新参者には辛いです。
      元を辿っていけないというか、与えられた通りのものしか使えないみたいな歯痒さが。

      削除
    14. そうゆうのを シンタックスシュガー と呼ぶそうですね.ここ数日で賢くなったんだぜ.うほほー

      削除
    15. おおっ!
      進んでますね〜。

      削除
  2. >わたしの知識ベースはUNIX
    UNIX(というか、Linux)も、最近のモノは、
    「Windows 3.1 が Wondows 10 に変わったくらい」
    の、変化があります。長らく、
    ・「CやC++やmake」を知ってれば、何とかなった時代が続いたのですが、
    Linuxカーネルバージョン3以上が当たり前になった辺り(10年くらい前? 2010年あたり?)から、
    ・makeよりも、cmake や、その他の管理ツールが台頭
    ・ディストリビューションは、ほぼ Ubuntu 一択になった
    ・常駐ソフトの形式が、デーモン志向からサービス志向になった
    などなど、劇的に変わってきています。

    ※全体的には、「バッチ処理的(makeとか)なもの」から「オブジェクト指向的なもの」
    へ、変化してるような気がします。確かに「大規模ソフトの開発」には、これらが有効なのですが、「基本的なオブジェクト定義」を知らないと使いこなせないので、以前よりも、ハードルが上がった気がします。
    昔は、処理内容はとりあえず「上から読めば」わかったのですが、今は、いちいち「オブジェクト定義」を、参照しないとわからない(しかも、それがどこにあるのかが、非常に分かりにくい)ので、大変です。

    返信削除
    返信
    1. 私も、最初に Raspberry Pi を触りだしたときに、同じ問題に直面しました。
      (自分も、「make 知ってれば、何とかなる時代」の人だったので。
      長らく Solaris 使ってたし。しかし今や、 Solaris すらも Ubuntu に駆逐されてるし・・・ なんだかなぁ。)

      削除
    2. cmakeよくわからないわたしです.

      ソフト屋さんは日進月歩で大変だなぁ.
      ハードは進歩遅いです.conceptが変わってしまうよな場面はあまり無いんで.

      削除
    3. >ハードは進歩遅いです
      いや、そんなことはないと思いますよ。自分は未だに「ランダムロジック」の人なので、
      ・MIL記号のロジック回路
      は、読めますが、
      ・CPLDの中身(VHDL とか Verilog)
      は、読めません。
      ※回路記述言語は、Algol が Origin なので、元々「オブジェクト指向」と言えなくもない感じ。

      >cmakeよくわからない
      cmake は、makeの「プリプロセッサ」(のようなもの)です。最終的には、
      「巨大な makefile」が、生成されます。(人間が読んでも、ほとんどわからない・・・)
      なので、最終的に実行するのは、あくまで make ですが。

      削除
    4. 最近の、「超LSI」のマニュアルとか見ても、
      ・どこに何が書いてあるのかわからない
      ものが多いです。まぁ、そうは言っても「ハードウエア」なので、必ずどこかに
      「実体」があるのでいいですが。
      ※ソフトのオブジェクト指向は「バーチャルな定義(概念だけの定義)」とかあったりして、まず、それを理解しないといけないことがあって、大変ですが。

      削除
    5. ハードはトランジスタとフィルタとopampとverilogとFPGAがわかってりゃまぁなんとか.あと時間領域と周波数領域を脳内座標変換できる想像力.

      ガチのLSI設計屋はメソドロジ系で勉強がかったるそうに見えますが.

      ソフト屋さんはがんばれー

      削除
    6. >時間領域と周波数領域を脳内座標変換できる想像力
      フーリエ変換とかラプラス変換とかZ変換とか・・・
      ※さすがに、脳内変換は無理だなぁ・・・計算はできても、なんで、
      ・この式が、こういう変換になるのか?
      というのを、直感的にわかるのは難しいです。ちょっと係数の値が違うだけで、フィルタの形(周波数特性)とか、ガラッと変わるし。

      削除
    7. 極とゼロ点みたいな.
      Z変換って数学的にあまり美しくない気がするわたしです.

      削除
    8. >直感的にわかる
      「直感的にわかる」のは、
      ・LPFは、要するに「平均値をとってる」「積分してる」
      ・HPFは、要するに「変化分をとってる」「微分してる」
      くらいのもので、これが、BPF、BEF(Band Eliminate Filter)になると、もはや
      「ワケワカメ」
      ですね。ちゃんと計算しないと、どんな特性になるかわからない。

      削除
    9. まぁそんなもんでいいんじゃないかと思います.位相もクルクル回りますー

      そういやpower系はあまり知らないんですよね.コアの磁気飽和がうんちゃらー

      削除
    10. 磁気回路の損失をちゃんとシミュレーションしてくれる方法が知りたいです。いつも飽和させていれば,最大のBHカーブの面積で考えればいいのかもしれませんが,それ以外の状態のときはマイナーループで損失が発生しているはず。LTspiceにはその機能があるんですけど,理屈が理解できず,これも断念しましたー。

      削除
    11. わたしもLTspiceつかいです.しかしそんな非線形計算っぽい機能があるんですね.なんかエライなぁLTspice.

      まぁいまではLTじゃなくてADですからADspiceとでも呼ぼうかみたいな.

      ちなみに、スピーカーのnetworkにはゴツいferrite coreが使われますが、数10W級の大音響を出すとあれってコアが飽和しかねない領域のように感じてるわたしです.アンプの歪率どころじゃなくない?みたいな.

      空芯コイルなら大丈夫でしょうけど.高価ですけど.

      削除
    12. モータは飽和させてまでドライブするのが普通みたいですが,スピーカのネットワークはどうなんでしょうね。そもそもスピーカ自体が,動電型スピーカって,アクチュエータの中では線形性がよさそうですが,それでもアンプが標榜する90dBTHDとかのひずみ率は無理でしょうね。DCオフセット電流を変化させながら小信号特性を測れば非線形性はわかりそうな気がします。誰か測ってないかな。あ,すいません。オシロスコープの話でしたね。オシロスコープ入力で活躍するギルバートセルの気持ちがいまだに理解できない私です。なさけないです。

      削除
    13. >モータは飽和させてまでドライブ

      ほほぅ、なかなか攻めますね.オーバーロードは漢のロマンです.

      >ギルバートセル

      うあぁぁ懐かしいっっ、motoloraの乗算器IC使ってたのは80年代後半でした.
      あんな回路で線形性をどうやって実現してるのかは知らないんですが.

      スピーカーはもううんざりするほどの非線形デバイスだと思います.

      削除
    14. >ギルバートセルの気持ち
      このページをどうぞ。

      ギルバート型乗算回路の出力波形はどれ?
      https://cc.cqpub.co.jp/system/contents/1483/

      ※さすがはCQ出版社です!

      削除
    15. Dかと思っちゃった.はずしたぁぁ

      削除
    16. >Dかと思っちゃった
      Dは「全波整流回路」の出力ですね。
      (ちょっと回路をいじると、この出力にも出来そうですが。)

      削除
    17. そういやそうですね.血迷ったぁぁ

      削除
    18. 皆さん優秀でうらやましいです。

      ハードでご飯を食べるのは厳しい時代になりました。
      昔はCPU、ROM、RAM、シリアル、I/O、ビデオ、サウンドなどを組み合わせて各社の
      風味をかもし出していました。

      TVについては、各メーカ毎に出力調整があって、多くのICを組み合わせてメーカ毎の
      味わいをいかにだすかで競い合っていました。

      今はSOCや1チップマイコンにの台頭で部品点数は著しく減りました。(設計する部分が減っています)TVはデジタル化してしまったので、アナログ部品の出番はありません。

      市場に出ている家電は昔のように一度ばらしたらもう元にはもどらないようになっています。
      (接着される物が多いです。ネジ止めはコストアップですから)

      ハード屋はもうすぐ伝統工芸のような世界になってしまうのかもしれませんね。

      今年から組み込み系linuxの仕事を始めました。
      組み込み系はyoctoなるものを使うみたいです。
      レシピ?それって美味しいの?

      削除
    19. 日本の若者に回路屋になるのをオススメできないですわたしは.ソフト屋になった方がいいんじゃないかと思います.ソフトは勉強が大変ですが.

      仮に今、回路屋になったとしてもロクに技術を身に着けられないと思うんですよね.なんでもかんでもシステムLSIの中に入っちゃってるので.30年前はトランジスタで何でも動かしてたので回路の学習には適していました.

      しかし今では伝統工芸です.

      >接着される物が多い

      その代表格はiPhone.LCDパネル外すのにヒートガンが必要という.最初にバラした時は面食らいました.なんじゃこりゃって.接着にしなけりゃ薄型化できないのかな?

      組み込みLinuxいいですね.わたしもそんな仕事したい気はするけどわたしにsoftを発注したがる奴はいないと思います.ヨクト、初耳でした.

      削除