Rustのメモリ操作がわからないので読んで理解してみた。 [プログラミング]
Rustをちょっとやってみたんだけど、いまいちコンパイラに怒られるばかりで気持ち良くない。Golangくらいに楽にできろとは言わないけど、もうちょっと何とかならないのかなぁと思ったりする。でも、それは必要に駆られての言語仕様なのだから、面倒でもそれに従うしかないのかな。
雑誌を買って読んでみたんだけど、なかなか悪くない。
![Software Design (ソフトウェアデザイン) 2021年9月号 [雑誌]](https://m.media-amazon.com/images/I/51yXsa8gbJL._SL160_.jpg "Software Design (ソフトウェアデザイン) 2021年9月号 [雑誌]")
Rustの本を買おうとすると分厚くて高いものを買わざるを得ない気もするし、Rustの本で他の言語との比較をやれるという事はあまりないと思う。普通、Rustの言語の本で他の言語のソースを引き合いに出す事はないだろうし、雑誌でやるという意味は結構ある。Rustで引っ掛かるところは、メモリのやりとりの部分で、他の言語と同じようなつもりで書いていると、コンパイルエラーで嫌になるのがオチだろう。
結局、メモリの動的配置をどうするのかというところにあって、自動変数からmalloc(), free()の原始的な操作、ちょっと欠点があるスマートポインタ、処理が重いけど書く方の負担が少ないガベージコレクション、の次に来る仕組みであった。
ただGCと逆行するみたいなところはあって、書く方に気をつけさせるためコンパイラで問題部分をエラーにする方針のようだ。だから書くのが面倒で、数年間書いている人でさえ、そのメモリ操作に頭を悩ませると書いてあった。それって問題があるんじゃないのと思うけど、メモリリークとか二重開放とかダングリングポインタとかを、文法と書き方で防いでいるという事なのでしょう。
生産性から言うとRustはあまりよくないと言わざるを得ない。少なくとも趣味的に気軽にプログラミングしたいという人にはお勧めできません。前にGolangとRustは競合しているとか似ているとか言われたらしいんだけど、コンパイルで実行速度が速いという点以外はほとんど共通点はないように思えます。そう言い出した人は同じくらいのタイミングで、同じようなコンパイル言語くらいの認識しかなかったのでしょう。たぶん、文法的に同じようなところは、他の言語でも大して違っていないことが多いような気がします。
一番の違いはGolangがGCを使っていて、Rustはコンパイル時点でメモリを制御しているという事です。先に述べたように、Rustではコンパイルを通すのにも一苦労だし、その点Golangでメモリ上で引っかかる点はそれほどありません（高度になってくるとあるんでしょうけど）。Golangではたぶん関数の中で作った変数を参照で返しても文句言われないんじゃなかったんじゃないかな。ただ参照じゃなくてコピーされていただけなのかもしれないけど、Rust的に考えるとそんな大胆なメモリ操作は普通通るわけがないレベルではあると思うんだよね。
気軽にプログラミングしたい人はGolangを使うべきです。色々メリットがあるし、いろいろ直感的ではあります。細かいことに気を付けなくていいというのは、やりたいことに専念できるという意味でもあるので、やりたいことを実現するのにはうってつけだと思います。あんまり言語内の細かいことを気にするよりもそれで何ができるのかを考えた方が建設的だと思いませんか？
Rustは初心者にはお勧めできません。他の言語で考えなくてもいいことが大きな部分を占めているからです。例えばC++でオブジェクト指向を使わないという事はあまりないですが、やろうと思えばC言語のやり方でプリミティブな手続き型のプログラミングもできます。だけどRustはコンパイルが通るまで言語のクセを味わう事になります（主にメモリ部分）。それは本来のプログラミングでは本来的ではない部分のところではあって、それでいてどこにでも存在する問題の一つでもあります。確かにメモリ操作に関するところは、プログラミング言語の進化の一つでもあるんだけど、どれも一長一短でこれが最高で、何にでも使えますというものはないんだよね。
先の雑誌のところに書かれていたんだけど、Golangで書いていたプログラムがGCのせいでパフォーマンスが落ちてタイミングが取れなくなるために、GCのないRustで書き直したという例がある。確かにGCの処理で遅くなるとか止まるとかあるようだけど、そこまで気にするようなものを書く機会があるのかと考えると、そこはGolangでやっていて行き詰ってしまった時に考えればいいことで、最初からパフォーマンスうんぬんでRustを選ぶことはないんじゃないかと思ったりします（デバドラとかを除く）。
やっぱり実行時のパフォーマンスも大事だけど、コーディングする時の人間のパフォーマンスも考えるべきでしょう。というか、プログラムを何度も使ったり繰り返したりするのでは、実行時間が関係することもあるのでしょうが、そこまでシビアになる時ってあるのかなと考えます。それこそ、リアルタイム性が必要な時や、バッチで処理が重たくて少しでも早く終えたい場合など、わりと特殊な場面しか考えられないんですよね。
だからGCを積んでいるから遅くてGolangは嫌だという人は偏屈としか言いようがありません。競技プログラミングで少しでも時間を短くしたいとかならまだしも、Rustでコンパイラに怒られて修正する時間を使うくらいなら、Golangで一つでも便利な機能を付けた方がいいんでしょう。
ただこの先にあるWebAssemblyを今すぐ使いたいだとか、Linuxでドライバを将来作りたいとか、そういう目的があればRustでも全然OKです。今あるC言語代替の動きで、C/C++をいまさらやるのもなという人はそれはそれで積極的にやった方がいいです。一つ言語をやってしまうと、なんだかんだで詳しくならざるを得ない時が来るので、そこまで深くいくと別のところに行くのがしんどくなってしまう事もあると思います。それを考えると新しいパラダイムの言語を使うという意味もあるでしょう。
Golangはそこそこ仕事があるようになってきたみたいですが、Rustは大々的に人を集めているという話は聞いていません。自分の知らないところではあるのかもしれませんが、一般的ではないと言えるでしょう。だから仕事で使えるようになりたい言語を選ぶのだったら、PythonやJavaをやった方が飯のタネにはなるでしょうね。職業プログラマをしていくには、そこのところはシビアなのでマイナー言語にはまってしまったら仕事も選べないという状況にもなりかねません。
それは避けたいので、ニーズがある言語をやりたいという気持ちは誰にでもあると思います。完全に趣味的か大学とかで研究しているとかなら別ですけど、メジャーかどうかはわりと分かれ道になるとは思います。一時期COBOLしかできない人がたくさん出て、結局みんな営業側に回らざるを得なくなったという事もあったわけですから、プログラミングを長い間ガチでやっていきたいのなら、一つの言語にかじりつくというのは危険かもしれません。とはいえ、最近はWebアプリの案件も多いので、多言語でフルスタックな人材が求められたりはしているんですが、それだと多言語の習得は必須になりますね。
とりあえず、メモリ操作のために何でそんなことをしているのかという事はこの雑誌でわかりました。Rust自体の文法の解説はあまりないので、リファレンスとかを見ながら理解していくことになります。ただ、そこまで難しいサンプルコードは出てこないので、読み物としてさらっと読むこともできると思います。
Rustをやったことがない人はまずはパソコンに入れてコンパイルしてみてその偏屈さに辟易してから読んでもいいと思います。いきなり読んでも理解できないことはないですが、つまずいた後に見た方が理解が進むし知識的な滋養にもなります。
とりあえず、Rustを勉強するにあたって分厚い3000円以上の本を買うより、Webの情報とSoftware Designの記事を読んで、とりあえずすんなりコーディングできるようになった方がいい気がします。分厚い本はある程度、必要になってからでも遅くない気はします。Rustに飽きて放り出してしまうかもしれませんしね。
![実践Rust入門 [言語仕様から開発手法まで]](https://m.media-amazon.com/images/I/51t+hDKJOvL._SL160_.jpg "実践Rust入門 [言語仕様から開発手法まで]")
雑誌を買って読んでみたんだけど、なかなか悪くない。
Software Design (ソフトウェアデザイン) 2021年9月号 [雑誌]
- 出版社/メーカー: 技術評論社
- 発売日: 2021/08/18
- メディア: Kindle版
Rustの本を買おうとすると分厚くて高いものを買わざるを得ない気もするし、Rustの本で他の言語との比較をやれるという事はあまりないと思う。普通、Rustの言語の本で他の言語のソースを引き合いに出す事はないだろうし、雑誌でやるという意味は結構ある。Rustで引っ掛かるところは、メモリのやりとりの部分で、他の言語と同じようなつもりで書いていると、コンパイルエラーで嫌になるのがオチだろう。
結局、メモリの動的配置をどうするのかというところにあって、自動変数からmalloc(), free()の原始的な操作、ちょっと欠点があるスマートポインタ、処理が重いけど書く方の負担が少ないガベージコレクション、の次に来る仕組みであった。
ただGCと逆行するみたいなところはあって、書く方に気をつけさせるためコンパイラで問題部分をエラーにする方針のようだ。だから書くのが面倒で、数年間書いている人でさえ、そのメモリ操作に頭を悩ませると書いてあった。それって問題があるんじゃないのと思うけど、メモリリークとか二重開放とかダングリングポインタとかを、文法と書き方で防いでいるという事なのでしょう。
生産性から言うとRustはあまりよくないと言わざるを得ない。少なくとも趣味的に気軽にプログラミングしたいという人にはお勧めできません。前にGolangとRustは競合しているとか似ているとか言われたらしいんだけど、コンパイルで実行速度が速いという点以外はほとんど共通点はないように思えます。そう言い出した人は同じくらいのタイミングで、同じようなコンパイル言語くらいの認識しかなかったのでしょう。たぶん、文法的に同じようなところは、他の言語でも大して違っていないことが多いような気がします。
一番の違いはGolangがGCを使っていて、Rustはコンパイル時点でメモリを制御しているという事です。先に述べたように、Rustではコンパイルを通すのにも一苦労だし、その点Golangでメモリ上で引っかかる点はそれほどありません（高度になってくるとあるんでしょうけど）。Golangではたぶん関数の中で作った変数を参照で返しても文句言われないんじゃなかったんじゃないかな。ただ参照じゃなくてコピーされていただけなのかもしれないけど、Rust的に考えるとそんな大胆なメモリ操作は普通通るわけがないレベルではあると思うんだよね。
気軽にプログラミングしたい人はGolangを使うべきです。色々メリットがあるし、いろいろ直感的ではあります。細かいことに気を付けなくていいというのは、やりたいことに専念できるという意味でもあるので、やりたいことを実現するのにはうってつけだと思います。あんまり言語内の細かいことを気にするよりもそれで何ができるのかを考えた方が建設的だと思いませんか？
Rustは初心者にはお勧めできません。他の言語で考えなくてもいいことが大きな部分を占めているからです。例えばC++でオブジェクト指向を使わないという事はあまりないですが、やろうと思えばC言語のやり方でプリミティブな手続き型のプログラミングもできます。だけどRustはコンパイルが通るまで言語のクセを味わう事になります（主にメモリ部分）。それは本来のプログラミングでは本来的ではない部分のところではあって、それでいてどこにでも存在する問題の一つでもあります。確かにメモリ操作に関するところは、プログラミング言語の進化の一つでもあるんだけど、どれも一長一短でこれが最高で、何にでも使えますというものはないんだよね。
先の雑誌のところに書かれていたんだけど、Golangで書いていたプログラムがGCのせいでパフォーマンスが落ちてタイミングが取れなくなるために、GCのないRustで書き直したという例がある。確かにGCの処理で遅くなるとか止まるとかあるようだけど、そこまで気にするようなものを書く機会があるのかと考えると、そこはGolangでやっていて行き詰ってしまった時に考えればいいことで、最初からパフォーマンスうんぬんでRustを選ぶことはないんじゃないかと思ったりします（デバドラとかを除く）。
やっぱり実行時のパフォーマンスも大事だけど、コーディングする時の人間のパフォーマンスも考えるべきでしょう。というか、プログラムを何度も使ったり繰り返したりするのでは、実行時間が関係することもあるのでしょうが、そこまでシビアになる時ってあるのかなと考えます。それこそ、リアルタイム性が必要な時や、バッチで処理が重たくて少しでも早く終えたい場合など、わりと特殊な場面しか考えられないんですよね。
だからGCを積んでいるから遅くてGolangは嫌だという人は偏屈としか言いようがありません。競技プログラミングで少しでも時間を短くしたいとかならまだしも、Rustでコンパイラに怒られて修正する時間を使うくらいなら、Golangで一つでも便利な機能を付けた方がいいんでしょう。
ただこの先にあるWebAssemblyを今すぐ使いたいだとか、Linuxでドライバを将来作りたいとか、そういう目的があればRustでも全然OKです。今あるC言語代替の動きで、C/C++をいまさらやるのもなという人はそれはそれで積極的にやった方がいいです。一つ言語をやってしまうと、なんだかんだで詳しくならざるを得ない時が来るので、そこまで深くいくと別のところに行くのがしんどくなってしまう事もあると思います。それを考えると新しいパラダイムの言語を使うという意味もあるでしょう。
Golangはそこそこ仕事があるようになってきたみたいですが、Rustは大々的に人を集めているという話は聞いていません。自分の知らないところではあるのかもしれませんが、一般的ではないと言えるでしょう。だから仕事で使えるようになりたい言語を選ぶのだったら、PythonやJavaをやった方が飯のタネにはなるでしょうね。職業プログラマをしていくには、そこのところはシビアなのでマイナー言語にはまってしまったら仕事も選べないという状況にもなりかねません。
それは避けたいので、ニーズがある言語をやりたいという気持ちは誰にでもあると思います。完全に趣味的か大学とかで研究しているとかなら別ですけど、メジャーかどうかはわりと分かれ道になるとは思います。一時期COBOLしかできない人がたくさん出て、結局みんな営業側に回らざるを得なくなったという事もあったわけですから、プログラミングを長い間ガチでやっていきたいのなら、一つの言語にかじりつくというのは危険かもしれません。とはいえ、最近はWebアプリの案件も多いので、多言語でフルスタックな人材が求められたりはしているんですが、それだと多言語の習得は必須になりますね。
とりあえず、メモリ操作のために何でそんなことをしているのかという事はこの雑誌でわかりました。Rust自体の文法の解説はあまりないので、リファレンスとかを見ながら理解していくことになります。ただ、そこまで難しいサンプルコードは出てこないので、読み物としてさらっと読むこともできると思います。
Rustをやったことがない人はまずはパソコンに入れてコンパイルしてみてその偏屈さに辟易してから読んでもいいと思います。いきなり読んでも理解できないことはないですが、つまずいた後に見た方が理解が進むし知識的な滋養にもなります。
とりあえず、Rustを勉強するにあたって分厚い3000円以上の本を買うより、Webの情報とSoftware Designの記事を読んで、とりあえずすんなりコーディングできるようになった方がいい気がします。分厚い本はある程度、必要になってからでも遅くない気はします。Rustに飽きて放り出してしまうかもしれませんしね。
- 作者: 増田 智明
- 出版社/メーカー: 日経BP
- 発売日: 2020/04/20
- メディア: Kindle版
- 出版社/メーカー: 技術評論社
- 発売日: 2019/04/26
- メディア: Kindle版
タグ：RUST
ちょっと昔夢見ていたプロジェクトが頭をもたげてきた。 [プログラミング]
昔に偽春奈とか流行っていた時に、どのプラットフォームでも移植が簡単なようなデスクトップマスコットを考えていた。その時は機械学習やAIがそれほどなくて、今こそ話すデスクトップマスコットをとちょっと野望が出てきてしまったのだ。
昔はどのプラットフォームでもGUIをやろうとすると、JavaのSwingぐらいしかなかったのだが、ご存じの通りあまり普及せずに終わった。Javaは企業のWebアプリを作るぐらいの状態になり下がっている。
前もちょっと考えたんだけど、Atomとかで使っているElectronがいいのではないかと思ってはいた。でも面倒くさくてやっていなかった。結局、Webの技術で書けるので、ブラウザ上でやるのとそんなに変わらないかもしれない。
https://ja.wikipedia.org/wiki/Electron_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
とにかく一度書けば、WindowsとMacとLinuxでは動くようなので、デスクトップOSでウインドウを出すには困らないみたいだ。問題はデスクトップマスコットらしく、ウインドウ上で動いているんじゃなくてキャラがそのまま乗っている感じを出したい。
https://qiita.com/nullpointer_t/items/0131109fa49185a34fa4#%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%81%AA%E3%81%97%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6%E3%82%84%E9%80%8F%E6%98%8E%E3%81%AA%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6%E3%81%AA%E3%81%A9
どうやらできるっぽい。具体的な技術としてはこちら。
https://www.electronjs.org/docs/api/frameless-window
フレームレスとかトランスペアレントって書いてあるから、考えられることはできそうな感じ。ただHTML5でゴリゴリ書いていくことになりそうなので、ちょっとしんどいかなという気はする。フレームワークを作って、イメージを張り付けて、どこかから話すデータを取ってくるという形がいいな。そうすればクローン的に他の人が作れるようになるだろうし。
基本的にUIであることに注力して、文字を出す機能と画面的なリアクションを作ればよくて、後はWebAPIでセリフ取ってきたりすればいいかな。結局HTML5でどこまでできるかというのが問題かもしれない。JavaScriptか…。
昔はどのプラットフォームでもGUIをやろうとすると、JavaのSwingぐらいしかなかったのだが、ご存じの通りあまり普及せずに終わった。Javaは企業のWebアプリを作るぐらいの状態になり下がっている。
前もちょっと考えたんだけど、Atomとかで使っているElectronがいいのではないかと思ってはいた。でも面倒くさくてやっていなかった。結局、Webの技術で書けるので、ブラウザ上でやるのとそんなに変わらないかもしれない。
https://ja.wikipedia.org/wiki/Electron_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
とにかく一度書けば、WindowsとMacとLinuxでは動くようなので、デスクトップOSでウインドウを出すには困らないみたいだ。問題はデスクトップマスコットらしく、ウインドウ上で動いているんじゃなくてキャラがそのまま乗っている感じを出したい。
https://qiita.com/nullpointer_t/items/0131109fa49185a34fa4#%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%81%AA%E3%81%97%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6%E3%82%84%E9%80%8F%E6%98%8E%E3%81%AA%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6%E3%81%AA%E3%81%A9
どうやらできるっぽい。具体的な技術としてはこちら。
https://www.electronjs.org/docs/api/frameless-window
フレームレスとかトランスペアレントって書いてあるから、考えられることはできそうな感じ。ただHTML5でゴリゴリ書いていくことになりそうなので、ちょっとしんどいかなという気はする。フレームワークを作って、イメージを張り付けて、どこかから話すデータを取ってくるという形がいいな。そうすればクローン的に他の人が作れるようになるだろうし。
基本的にUIであることに注力して、文字を出す機能と画面的なリアクションを作ればよくて、後はWebAPIでセリフ取ってきたりすればいいかな。結局HTML5でどこまでできるかというのが問題かもしれない。JavaScriptか…。
2021-06-26 06:20
コメント(0)
iOS上でHTMLパーサでスクレイピング [プログラミング]
ちょっとiPhoneで作りたいアプリがあったので調べた。
HTMLからスクレイピングをしたいと思っていた。
https://qiita.com/_tid_/items/c228b1931cd9b23d52d3
Kannaというもので使えるっぽい。CocoaPodsで楽できそうだけど
問題がありそうなのでCarthageで入れるのがいいのかも。
これでimgタグのURLを取ってきてファイル表示すればOKかも。
相対URLのは先のもので変換してね。
って書いてあったから
でいいのかもね。
おなじかもしれんけどこれもね。
https://qiita.com/yogita109/items/977e5c0e8d40795748d8
Alamofireとかあるらしいけど、標準で用意されているっていうんだから、それを使ったほうがいい気はする。でも、気楽に書きたい気もするなぁ。だが依存するライブラリは少ない方がいいに決まっている。
・URLを相対パスから絶対パスへ。
これはHTMLから相対パスをスクレイピングした時に必要だな。
・URLSessionを使ってファイルを取る。
https://qiita.com/shungo_m/items/64564fd822a7558ac7b1
最後にスクレイピングするファイルを取ってきたり、スクレイピングされたURLを取ってきたりするのに使う。これが一番最初な気もするけど、まぁいいか。
まずSwiftUIで二分割したウインドウをどう連携させるかというのが必要かな。でも、正直SwiftUIに対する情報が少なすぎるというのが厳しい。
HTMLからスクレイピングをしたいと思っていた。
https://qiita.com/_tid_/items/c228b1931cd9b23d52d3
Kannaというもので使えるっぽい。CocoaPodsで楽できそうだけど
問題がありそうなのでCarthageで入れるのがいいのかも。
これでimgタグのURLを取ってきてファイル表示すればOKかも。
相対URLのは先のもので変換してね。
// HTML内のリンク(URL)を抜き出す
for node in doc!.css("a, link") {
println(node["href"]) // href属性に設定されている文字列を出力
}
って書いてあったから
// HTML内のリンク(URL)を抜き出す
for node in doc!.css("img, link") {
println(node["href"]) // href属性に設定されている文字列を出力
}
でいいのかもね。
おなじかもしれんけどこれもね。
https://qiita.com/yogita109/items/977e5c0e8d40795748d8
Alamofireとかあるらしいけど、標準で用意されているっていうんだから、それを使ったほうがいい気はする。でも、気楽に書きたい気もするなぁ。だが依存するライブラリは少ない方がいいに決まっている。
・URLを相対パスから絶対パスへ。
URL url=new URL("http://www.abc.com/aa/bb/cc/file.html");
String relativePath="../file2.html"; //maybe is "/file3.html"
new URL(url, relativePath);
これはHTMLから相対パスをスクレイピングした時に必要だな。
・URLSessionを使ってファイルを取る。
https://qiita.com/shungo_m/items/64564fd822a7558ac7b1
let url = URL(string: "https://hogehoge.hoge")! //URLを生成 var request = URLRequest(url: url) //Requestを生成 let task = URLSession.shared.dataTask(with: request) { (data, response, error) in //非同期で通信を行う guard let data = data else { return } do { let object = try JSONSerialization.jsonObject(with: data, options: []) // DataをJsonに変換 print(object) } catch let error { print(error) } } task.resume()
最後にスクレイピングするファイルを取ってきたり、スクレイピングされたURLを取ってきたりするのに使う。これが一番最初な気もするけど、まぁいいか。
まずSwiftUIで二分割したウインドウをどう連携させるかというのが必要かな。でも、正直SwiftUIに対する情報が少なすぎるというのが厳しい。
SwiftUIでViewControllerベースのアプリを作るのを調べた [プログラミング]
SwiftUI以前のアプリはみんなViewControllerを使ったMVCっぽいものになっていたと思うけど、SwiftUIになってからは勝手が変わったようだ。とはいえ、以前のアプリのつくり方を覚えているほどたくさん作ったわけでもないし、最近はXcode自体に触れてないので、そもそもの作り方が分かっていない。
そんなわけでAppleでSwiftUIの公式チュートリアルをサラッと見たのだが、英語は難しくないがいまいちわかりづらい。まぁ公式のものってわかりやすいことはあまりないので、一次情報であるということ以上の利点はないよね。
https://developer.apple.com/tutorials/swiftui/
わけわかんなくないけど、日本語で今までの作り方を前提とした記事とかがないかなと思って探してみたんだけど、思いのほかない。SwiftUI自体の新しく加わったものについての話はあるんだけど、ViewController周りのこととかがない。というか、以前の作り方からSwiftUIに移行する方法とかがあまりないみたいだった。探し方が悪いのかもしれないけど、わりと情報が少ない。出てきてからそんなに時間が経っていないわけではないんだけれど、欲しいなぁと思うようなものがない。
それで結局、本家チュートリアルに戻った。
https://developer.apple.com/tutorials/swiftui/interfacing-with-uikit
結局ViewControllerを使っているのはこれだった。これがあるから特にほかのページで解説しているところがなかったのかもしれない。
半分ほど見たけど、以前より手数（コードの量）が多くなってないか？
SwiftUIを成立させるために、以前のViewControllerの手法が面倒になっているのだとしたら本末転倒でかなり問題なのでは？ もう少し文句も出てもよさそうなもんだけど、そういう人はSwiftUIを使わずに今までの手法を使っているのかな？
問題なのは以前のViewControllerをそのままがっちゃんこして使えそうな感じではないことだ。少し直せば使える程度ならいいけど、ちょっとその程度ではない気がしている。SwiftUIはこのまま定着するのかな？ 以前と同じくViewControllerの手法を用いている場合は面倒が増えるだけなんじゃ？
UICollectionViewを使おうとしていたんだけど、SwiftUIがらみだとほとんど記事がない。と思っていたらSwiftUIで代替方法があった。LazyVGridがそれである。
https://www.yururiwork.net/%e3%80%90swiftui%e3%80%91lazyhgrid-lazyvgrid%ef%bc%88uicollectionview%ef%bc%89-%e3%81%ae%e4%bd%bf%e3%81%84%e6%96%b9%e3%80%90ios14-xcode12%e3%80%91/
結局、SwiftUIに対応した方法がリリースされなければ、面倒なViewControllerの手法を無理やり入れないといけませんよと言うことらしい。どちらにせよ、簡単に書けそうな方法があったので一安心です。まぁ新しいものなのでバグとか普通にありそうですが、ViewControllerを学んでからそれを無理やり組み入れるよりかはマシなことでしょう。
WWDC2020でいろいろ追加されたようなので、そのうち見てみることにしましょう。ここあたりっぽい。
https://developer.apple.com/documentation/swiftui/view-layout-and-presentation
やっぱGoogle検索は古い情報が頭に来やすくて、探すのしんどい。とりあえずWebkitであってSwiftUIで実装されていないものは、以前の作り方で作ってSwiftUIで作らないというのが一般的な解法となるのかもしれない。まぁSwiftUIでできないことはWWDC2021でもかなりつぶされるとは思いますが…。
SwifUIがまともに使えるのかどうか心配になってきた。この先、フェイドアウトとかねーだろうなぁ。
https://engineering.mercari.com/blog/entry/20201216-4043b38af1/
使いやすくはなっているみたいだけど、如何せん日が浅いので情報も少ないしガチで使っている人も多いわけでもなく、使い方はこれだ的な決定打は出にくい模様。GUIでGUIを作るのっていうのは楽でいい気はしていたんだけど、スマホだと全画面だし解像度は違うしで、JavaのSwingみたいに画面をコードで書けた方がいいのかも知れぬ。
正直、今までの経緯をあんまり知らないものだから、iOS開発の泥臭いところを経験してないものでね。そういうところがわかっていれば、SwiftUIも有り難みがあるのかも知れないけど、今のところ簡単に書けるということぐらいしかわからない。それと今までやってきたことをしようとすると面倒だということぐらいしか伝わってこない。
まぁ本気でSwiftUIにしようというのはわかった。書き方も少なくなった分楽になりそうなのもわかった。あとはAppleの開発者が必要なものを揃えてくれるだけである。ある程度自分で作るにしても、フレームワーク的なものや部品から作るとなるとキツいしね。
そんなわけでAppleでSwiftUIの公式チュートリアルをサラッと見たのだが、英語は難しくないがいまいちわかりづらい。まぁ公式のものってわかりやすいことはあまりないので、一次情報であるということ以上の利点はないよね。
https://developer.apple.com/tutorials/swiftui/
わけわかんなくないけど、日本語で今までの作り方を前提とした記事とかがないかなと思って探してみたんだけど、思いのほかない。SwiftUI自体の新しく加わったものについての話はあるんだけど、ViewController周りのこととかがない。というか、以前の作り方からSwiftUIに移行する方法とかがあまりないみたいだった。探し方が悪いのかもしれないけど、わりと情報が少ない。出てきてからそんなに時間が経っていないわけではないんだけれど、欲しいなぁと思うようなものがない。
それで結局、本家チュートリアルに戻った。
https://developer.apple.com/tutorials/swiftui/interfacing-with-uikit
結局ViewControllerを使っているのはこれだった。これがあるから特にほかのページで解説しているところがなかったのかもしれない。
半分ほど見たけど、以前より手数（コードの量）が多くなってないか？
SwiftUIを成立させるために、以前のViewControllerの手法が面倒になっているのだとしたら本末転倒でかなり問題なのでは？ もう少し文句も出てもよさそうなもんだけど、そういう人はSwiftUIを使わずに今までの手法を使っているのかな？
問題なのは以前のViewControllerをそのままがっちゃんこして使えそうな感じではないことだ。少し直せば使える程度ならいいけど、ちょっとその程度ではない気がしている。SwiftUIはこのまま定着するのかな？ 以前と同じくViewControllerの手法を用いている場合は面倒が増えるだけなんじゃ？
UICollectionViewを使おうとしていたんだけど、SwiftUIがらみだとほとんど記事がない。と思っていたらSwiftUIで代替方法があった。LazyVGridがそれである。
https://www.yururiwork.net/%e3%80%90swiftui%e3%80%91lazyhgrid-lazyvgrid%ef%bc%88uicollectionview%ef%bc%89-%e3%81%ae%e4%bd%bf%e3%81%84%e6%96%b9%e3%80%90ios14-xcode12%e3%80%91/
結局、SwiftUIに対応した方法がリリースされなければ、面倒なViewControllerの手法を無理やり入れないといけませんよと言うことらしい。どちらにせよ、簡単に書けそうな方法があったので一安心です。まぁ新しいものなのでバグとか普通にありそうですが、ViewControllerを学んでからそれを無理やり組み入れるよりかはマシなことでしょう。
WWDC2020でいろいろ追加されたようなので、そのうち見てみることにしましょう。ここあたりっぽい。
https://developer.apple.com/documentation/swiftui/view-layout-and-presentation
やっぱGoogle検索は古い情報が頭に来やすくて、探すのしんどい。とりあえずWebkitであってSwiftUIで実装されていないものは、以前の作り方で作ってSwiftUIで作らないというのが一般的な解法となるのかもしれない。まぁSwiftUIでできないことはWWDC2021でもかなりつぶされるとは思いますが…。
SwifUIがまともに使えるのかどうか心配になってきた。この先、フェイドアウトとかねーだろうなぁ。
https://engineering.mercari.com/blog/entry/20201216-4043b38af1/
使いやすくはなっているみたいだけど、如何せん日が浅いので情報も少ないしガチで使っている人も多いわけでもなく、使い方はこれだ的な決定打は出にくい模様。GUIでGUIを作るのっていうのは楽でいい気はしていたんだけど、スマホだと全画面だし解像度は違うしで、JavaのSwingみたいに画面をコードで書けた方がいいのかも知れぬ。
正直、今までの経緯をあんまり知らないものだから、iOS開発の泥臭いところを経験してないものでね。そういうところがわかっていれば、SwiftUIも有り難みがあるのかも知れないけど、今のところ簡単に書けるということぐらいしかわからない。それと今までやってきたことをしようとすると面倒だということぐらいしか伝わってこない。
まぁ本気でSwiftUIにしようというのはわかった。書き方も少なくなった分楽になりそうなのもわかった。あとはAppleの開発者が必要なものを揃えてくれるだけである。ある程度自分で作るにしても、フレームワーク的なものや部品から作るとなるとキツいしね。
タグ：SWIFT
Webが使えない職場で何をしようか。 [プログラミング]
ある理由で会社のネットワークが使えなくなった。復旧の見通しはかなり先という事しかわからない。上の方からも何か白というお達しは基本的にはない。ないことはないがネットワークが使えないと調べ物ができない。
開発関係でWebが使えないと何もできない。Linuxでaptもdnfもできないし、もちろんWebにあるドキュメントも見られない。正直、何もできない。それまで使っていた環境を使って開発とかはできるけれども、新規に何かをやろうとしてもなかなか厳しい。
PHPが使える環境でWordPressの勉強でもしようかなと思ったけど、MySQLが使えないとダメなようなので、今からでは入れられない。外からrpmなりdebファイルを持ってくればいいのだが、それをするにしたって外の環境からの持ち込みをしないといけない。元々、WordPressも外からの持ち込みをしていたわけだが、結局今のソフトウェアは基本的に依存性を含んでいて、スタンドアローンで何かできる状態にはなっていない。今できることはgccでC言語くらいだが、今更C言語でやりたいことなどない。
Rustは使える。コンパイル環境を以前入れたので使える。でも、教科書もWebドキュメントもないところでお勉強は難しい。本を持ってきてやることはできても、Amazonじゃネット環境が必要だし、PDFをそのままくれるところっていうのもあんまりないだろう。Rustはちょっと今までの言語に比べてパラダイムが違う感じだから、何もお手本がない状態だときつい。Golangぐらいわかりやすかったら、ある程度はできるかもしれないけど、それだって標準ライブラリを使うためのサンプルやらがないときつい。
昔ならばドキュメントを含めて開発環境を光学ディスクから入れてお勉強できたものの、それもできないからなぁ。外に持ち出せる端末であれば、家でいろいろインストールして会社で使うことはできるんだけれども、やはりそれもできないし。パソコンを含むコンピューターがスタンドアローンでも開発できた頃が懐かしい。とはいえ、すぐにネット情報がないとやっていけなくなったわけだが、それでももう少し何かできた世の中であったと思う。
開発関係でWebが使えないと何もできない。Linuxでaptもdnfもできないし、もちろんWebにあるドキュメントも見られない。正直、何もできない。それまで使っていた環境を使って開発とかはできるけれども、新規に何かをやろうとしてもなかなか厳しい。
PHPが使える環境でWordPressの勉強でもしようかなと思ったけど、MySQLが使えないとダメなようなので、今からでは入れられない。外からrpmなりdebファイルを持ってくればいいのだが、それをするにしたって外の環境からの持ち込みをしないといけない。元々、WordPressも外からの持ち込みをしていたわけだが、結局今のソフトウェアは基本的に依存性を含んでいて、スタンドアローンで何かできる状態にはなっていない。今できることはgccでC言語くらいだが、今更C言語でやりたいことなどない。
Rustは使える。コンパイル環境を以前入れたので使える。でも、教科書もWebドキュメントもないところでお勉強は難しい。本を持ってきてやることはできても、Amazonじゃネット環境が必要だし、PDFをそのままくれるところっていうのもあんまりないだろう。Rustはちょっと今までの言語に比べてパラダイムが違う感じだから、何もお手本がない状態だときつい。Golangぐらいわかりやすかったら、ある程度はできるかもしれないけど、それだって標準ライブラリを使うためのサンプルやらがないときつい。
昔ならばドキュメントを含めて開発環境を光学ディスクから入れてお勉強できたものの、それもできないからなぁ。外に持ち出せる端末であれば、家でいろいろインストールして会社で使うことはできるんだけれども、やはりそれもできないし。パソコンを含むコンピューターがスタンドアローンでも開発できた頃が懐かしい。とはいえ、すぐにネット情報がないとやっていけなくなったわけだが、それでももう少し何かできた世の中であったと思う。
Pascalってあったなぁ。 [プログラミング]
自分がWindows95でプログラミングを始めたぐらいの時、WindowsでプログラミングするならC/C++かVBかPascalぐらいだったと思う。OSSのプログラミング言語もあったと思うけど、そこまでLinuxが身近ではなかったのと、OSS文化がそこまで盛り上がっていなかった。
今ではいろいろな言語が百花繚乱で、別にLinuxじゃなくてもWindows上で移植されたりしていて、実行するにも困らないけど、昔は開発環境をお金を出して買わないといけなかった。そう思えば今は恵まれているものだ。とはいえ、いろいろありすぎてどれ選んだらいいかわからんところもあるだろうし、例えばゲームを作ろうとしてもなかなかどのプラットフォームでやるのかとか、そこから悩まないといけないのもあるんだろう。
そうそう。VBはコンパイルされる前は遅かったらしいけど、そのうち速度が改善された。GUIのフロントエンドをVBで作って、C/C++でできたDLLとかを蹴ってとかそんな手法もあった。そんなわけでスクリプト言語が思うさま動く環境でもなかったわけで、コンパイル言語が幅を利かせていたわけだ。やっぱりネイティブバイナリを吐き出さないとねという刷り込みがその頃の状況にある。
Pascalなんて名前が出たのは、RISCの歴史の読み物に書いてあったからだ。
https://www.itmedia.co.jp/news/articles/2003/04/news068_2.html
C言語が高級言語なんて書かれているけれども、今は低レイヤーの部分でわりと低級に使われている。というか、その前はアセンブラとか機械語の世界があったんだもんなぁ…。
PascalはObject PascalとしてDelphiで生きていた。使わなかったけどあるのは知っていた。タダになっていた時もあったと思ったが、Borland C++ Compilerは使ったことがあったけど、Delphiはとんと使ったことがない。やはり新しい言語を習得するのはしんどい。それほどモチベーションがあるわけでもないので、その労力はほかに仕向けられた。
コンピューター業界は栄枯盛衰あるけれど、自分がマイナーなカテゴリーに入ってしまうのは悲しいことですね。メジャーであってもそれが形を変えてしまっていて、もはや同じものでなくなっていることもあるしね。
今ではいろいろな言語が百花繚乱で、別にLinuxじゃなくてもWindows上で移植されたりしていて、実行するにも困らないけど、昔は開発環境をお金を出して買わないといけなかった。そう思えば今は恵まれているものだ。とはいえ、いろいろありすぎてどれ選んだらいいかわからんところもあるだろうし、例えばゲームを作ろうとしてもなかなかどのプラットフォームでやるのかとか、そこから悩まないといけないのもあるんだろう。
そうそう。VBはコンパイルされる前は遅かったらしいけど、そのうち速度が改善された。GUIのフロントエンドをVBで作って、C/C++でできたDLLとかを蹴ってとかそんな手法もあった。そんなわけでスクリプト言語が思うさま動く環境でもなかったわけで、コンパイル言語が幅を利かせていたわけだ。やっぱりネイティブバイナリを吐き出さないとねという刷り込みがその頃の状況にある。
Pascalなんて名前が出たのは、RISCの歴史の読み物に書いてあったからだ。
https://www.itmedia.co.jp/news/articles/2003/04/news068_2.html
C言語が高級言語なんて書かれているけれども、今は低レイヤーの部分でわりと低級に使われている。というか、その前はアセンブラとか機械語の世界があったんだもんなぁ…。
PascalはObject PascalとしてDelphiで生きていた。使わなかったけどあるのは知っていた。タダになっていた時もあったと思ったが、Borland C++ Compilerは使ったことがあったけど、Delphiはとんと使ったことがない。やはり新しい言語を習得するのはしんどい。それほどモチベーションがあるわけでもないので、その労力はほかに仕向けられた。
コンピューター業界は栄枯盛衰あるけれど、自分がマイナーなカテゴリーに入ってしまうのは悲しいことですね。メジャーであってもそれが形を変えてしまっていて、もはや同じものでなくなっていることもあるしね。
Golang版のbusyboxを探していたら、gokrazyの方に行っちゃった。 [プログラミング]
最初はGolangでbusyboxがないかと探していたら、gokrazyの方に目がいってしまった件。
作ろうとしたこと。
・Golang版のbusybox
割と簡単に実装できそうだが、出来上がるバイナリがでかいのでモバイル用のユーザーランドとしてはダメかも。
・Rust版のbusybox
書き方がむずくてやる気にならない。というかすんなりコンパイルが通らなくてストレスが溜まりそう。Golangほどバイナリが大きくならないので、使うには問題なさそうな気はする。
実はGolang版のbusybox的なことは作られていて、gokrazyというものらしい。ファイルサイズもGoにしては小さくて実用に足る感じではある。しかし、先にやられてしまうとはなぁ。人が考えることは大体似たようなものではあるのだな。なんかラズベリーパイに使っているところを見るとなかなか見込みはあるようである。
https://qiita.com/tetsu_koba/items/aa2d245a61db98299a89
ん？よく見たらBusyboxのような部分は含まないらしい。ユーザーランドという名前に騙された。よく考えるとユーザーランドという呼び名は結構あいまいに使われている気もするな。カーネルに対するユーザーランド的な。
ユーザーランドという言葉を調べてみると、カーネル以外のすべてみたいなことが書いてあった。基本的にカーネル以外の実行環境のことを言うらしい。Linuxカーネル以外全部じゃん！ 結構いい加減な分け方なんだけど、実際そうなんだから仕方がない。
上のサイトを見ていると「libc や busybox のコマンドを含んでいない」とあるので、ログインして何かできる状態ではないようである。そもそもbusybox自体かなり限られたユーザーランドであるので、gokrazyを入れただけでは何もできないんじゃないかと思われます。
カーネルモジュールを含んでいない、ということなので、カーネルの一部ですらない。結局何やってるんでしょうね…。initとかの作業をしているみたいですが、initはカーネルの中身ではなかったんだ…。
https://www.slideshare.net/tetsu.koba/linuxinitgolang
やはりshさえも入っていなかった。これは本当に特定通信をやり取りするだけのもので、シェルに入って云々というものではなかった。ということは、立ち上げてそれ以上手を入れることができないような状態みたいですね。ラズパイのコンソールがどうなのかは知らんけど。
カーネルモジュールのロードもできないし（スタティックに組み込めという話）、デバイスの抜き差しすらできない（uvev?）。カーネルがやっていそうなところもカーネル自身が結構やっていないことも多いんかなと思ったり。こういうことをしない限りは、カーネルとの境を意識することもないわけだよね。
それと依存性とかもいろいろ関係して単体では動かないことが結構あるんやね。Golangがわりと単体で実行できるという性質を持っているけど、その他のツールが依存性をがっつり持っているので、簡単にミニマム構成にできないってことなのか。
gokrazyはGolang版busyboxではなかったのだが、goで書いたbusyboxライクなものもあるみたい。それはファイルの大きさとかどうなのかなぁ。依存性は少ないのだろうけれども。gokrazyが終わった後ぐらいには、ちょっとみてみたい気もする。というか、初めはそっちが興味があったんだけれども。
gokrazyはラズパイ依存のものみたいなので、ケースワークとしてはminimumgoの方がわかりやすいかも知れない。
https://qiita.com/tetsu_koba/items/059849c0871a7e3bd94f
ソースを見てもしんどくならない程度に短い。バイナリが小さいというのも分かろうもの。というか、Golangのネックはバイナリがデカくなるというところだと思っていたのだが、用途によってはそうでもないのですね。
gokrazyはGolang版busyboxではなかったのだが、goで書いたbusyboxライクなものもあるみたい。それはファイルの大きさとかどうなのかなぁ。依存性は少ないのだろうけれども。Goのいいところの一つはlibcなどに依存しないところなので、こういう環境の方がワンバイナリになっていていいのではないかと思ったり。まぁC言語とかでもスタティックにリンクすればいいんだろうけど、そうする人は少ないよな。
作ろうとしたこと。
・Golang版のbusybox
割と簡単に実装できそうだが、出来上がるバイナリがでかいのでモバイル用のユーザーランドとしてはダメかも。
・Rust版のbusybox
書き方がむずくてやる気にならない。というかすんなりコンパイルが通らなくてストレスが溜まりそう。Golangほどバイナリが大きくならないので、使うには問題なさそうな気はする。
実はGolang版のbusybox的なことは作られていて、gokrazyというものらしい。ファイルサイズもGoにしては小さくて実用に足る感じではある。しかし、先にやられてしまうとはなぁ。人が考えることは大体似たようなものではあるのだな。なんかラズベリーパイに使っているところを見るとなかなか見込みはあるようである。
https://qiita.com/tetsu_koba/items/aa2d245a61db98299a89
ん？よく見たらBusyboxのような部分は含まないらしい。ユーザーランドという名前に騙された。よく考えるとユーザーランドという呼び名は結構あいまいに使われている気もするな。カーネルに対するユーザーランド的な。
ユーザーランドという言葉を調べてみると、カーネル以外のすべてみたいなことが書いてあった。基本的にカーネル以外の実行環境のことを言うらしい。Linuxカーネル以外全部じゃん！ 結構いい加減な分け方なんだけど、実際そうなんだから仕方がない。
上のサイトを見ていると「libc や busybox のコマンドを含んでいない」とあるので、ログインして何かできる状態ではないようである。そもそもbusybox自体かなり限られたユーザーランドであるので、gokrazyを入れただけでは何もできないんじゃないかと思われます。
カーネルモジュールを含んでいない、ということなので、カーネルの一部ですらない。結局何やってるんでしょうね…。initとかの作業をしているみたいですが、initはカーネルの中身ではなかったんだ…。
https://www.slideshare.net/tetsu.koba/linuxinitgolang
やはりshさえも入っていなかった。これは本当に特定通信をやり取りするだけのもので、シェルに入って云々というものではなかった。ということは、立ち上げてそれ以上手を入れることができないような状態みたいですね。ラズパイのコンソールがどうなのかは知らんけど。
カーネルモジュールのロードもできないし（スタティックに組み込めという話）、デバイスの抜き差しすらできない（uvev?）。カーネルがやっていそうなところもカーネル自身が結構やっていないことも多いんかなと思ったり。こういうことをしない限りは、カーネルとの境を意識することもないわけだよね。
それと依存性とかもいろいろ関係して単体では動かないことが結構あるんやね。Golangがわりと単体で実行できるという性質を持っているけど、その他のツールが依存性をがっつり持っているので、簡単にミニマム構成にできないってことなのか。
gokrazyはGolang版busyboxではなかったのだが、goで書いたbusyboxライクなものもあるみたい。それはファイルの大きさとかどうなのかなぁ。依存性は少ないのだろうけれども。gokrazyが終わった後ぐらいには、ちょっとみてみたい気もする。というか、初めはそっちが興味があったんだけれども。
gokrazyはラズパイ依存のものみたいなので、ケースワークとしてはminimumgoの方がわかりやすいかも知れない。
https://qiita.com/tetsu_koba/items/059849c0871a7e3bd94f
ソースを見てもしんどくならない程度に短い。バイナリが小さいというのも分かろうもの。というか、Golangのネックはバイナリがデカくなるというところだと思っていたのだが、用途によってはそうでもないのですね。
gokrazyはGolang版busyboxではなかったのだが、goで書いたbusyboxライクなものもあるみたい。それはファイルの大きさとかどうなのかなぁ。依存性は少ないのだろうけれども。Goのいいところの一つはlibcなどに依存しないところなので、こういう環境の方がワンバイナリになっていていいのではないかと思ったり。まぁC言語とかでもスタティックにリンクすればいいんだろうけど、そうする人は少ないよな。
タグ：Golang
IT土方、Web開発言語を調べる。 [プログラミング]
最近、Web開発言語ってどうなっているんだろうねと仕事場で話になって、仕事を受ける側の組織じゃないから最近のトレンドってわからないよねという事になった。わりと古いという話になっているPHPが現役な現場なのですが、その先有名どころのプラットフォームでJavaを書くという事になりそうで、今更Javaに日和るらしいですｗ。
今までもJavaで作ってきたものもあったのですが、わりと評判が良くなく、OSなどの基盤のアップデートに対応する時も厳しい感じでした。今までを考えるとたぶん今でもJavaは現役なのだろうなと思っていましたが、調べてみると果たしてそうでありました。
https://www.creativevillage.ne.jp/57889
これはWeb開発言語ではなく求人数ということなので、それでもPHPも根強くはあるのですが、その半分はWordPress需要じゃないかと思ったりするわけで。なんか知らんけど、WordPress信仰は止めることができないみたいで、PHPもそれに付随して生き残るのではないかと。
とはいえ、PHPもLaravelみたいなものもできたので、そこまで古いもの扱いしなくてもいい気はします。それに枯れた技術というものはそれはそれで価値があるものではあるので、昔のひどい時期をことさらに忌避しなくてもいいような気がします。逆に言うと、そこの部分はある程度攻撃されてクリアされているわけだしね。
仕事の数からいうとJavaが一番多いけど、Javaを習得して会社に入ったけど、PHPやってますなんて人もいそうな数ですね、PHP。PHPは言語習得コストが低めなので、後からでも何とでもなりそうなのはあります。とはいえ、Javaはある程度の大きさのビジネス向けではあるので、PHPでお手軽にやるよりかはお作法が必要だけど、つぶしが効くという事で食いっぱぐれはなさそう。PHPで自分でサンデープログラマ的に活動はできるけど、Javaになっちゃうと途端に仕事感が出てきてしまうので楽しくはないな。
上のサイトでGolangが給料がいいって書いてあるけど、それって高い技術力を要求されるってことだよね。均一なJavaのコードを生産してくれというより、少々とがっている技術を見せてくれってことだろう。でも、Javaよりも習得コストは低めなので、書くのは簡単目だけどプロトコルを自らいじくるような高度な（ローレイヤーな）使い方をするようなのを求められるのかもなぁ。というか、C/C++で新しく書くぐらいだったら、どこでも動くのがわかっていて動かすのも簡単なGolangにするってことなのかもしれない。
Golangは外部ソースを使うにしても、他の言語に比べてGitで楽できるし、goコマンドがそれ前提にできている。Googleはトップ的な企業にもかかわらず、そのサービスは他のものに劣っていたりすることが多いが、Golang自体はとても素養がいいと思う。出てきた時点からブレが少ないし、使っていてしんどい思いをすることが少ない。でも、Web開発言語として使われることは少ないかもしれない。少しのコードでWebサーバを作ることができるけど、それは他の言語もわりとできたりするので特異的ではない。
Rubyが案外求人率が高かったり低かったり。就活サイトによりけりなのですが、日本人的には入りやすい言語ではありますよね。日本人技術者では英語があまりできないという事も多いので、その点では敷居が低い。そもそもの言語仕様がユーザーフレンドリーなのもありますし、Ruby on Railsはいまだによく使われているみたいですね。
Javaは最近のはあんまり知らないんだよなぁ。勉強しないといけないんだけど、アノテーションとか昔はあった覚えはなくて、最近はやたら使われている感じでしたね。まぁ見たソースはそんなに新しくないので最近じゃないんだろうけど、知っているJavaがJava2あたりなもので、新しく増えた部分はかなりあるんじゃないかなと。
訳の分からない記述が出てきたら逐一調べるか、基本文法を復習し直すか、どうするかちょっと迷っています。システムをスクラッチするなら全部さらっておいた方がいいだろうし、それを考えると結構しんどいかなと。既存のシステムはそのままで使っていくとは思うので、それをスクラッチして作り直すようなことはないにしても、システム同士をつなぐ部分に関しては作りこまないといけないので、やっぱりそこそこ知っていないといけないはずなんだよね。
Webはあんまり関係ないけど、C++の求人ってわりとあるんだね。組み込みとかわりとC++を使っている節があるけれども、この量からして組み込みだけってことはあり得ないね。一回プログラマをセミリタイアしたときには、WindowsのアプリとかでもMFCの資産とかあったけど、今だとC#とかが普通になっちゃってるんだろうなぁ。というかWindowsでしか動かない案件とかは減っていそうだが、わりとHTML5でできる範囲が広まったというのもあるんだろうな。
そう考えるとWeb系に入らなかった今までの経歴はわりとニッチなんじゃないだろうか。C/C++はつぶしが効くようでピンポイントな案件も多いから、来る仕事次第のところもあるんだろうな。なんかWeb開発言語どうでもよい感じになってしまったが、どこぞではJavaかPHPかPythonがいいらしいよ、って書いてあった。まぁ仕事の数を考えればそうなるかもしれないな。
今までもJavaで作ってきたものもあったのですが、わりと評判が良くなく、OSなどの基盤のアップデートに対応する時も厳しい感じでした。今までを考えるとたぶん今でもJavaは現役なのだろうなと思っていましたが、調べてみると果たしてそうでありました。
https://www.creativevillage.ne.jp/57889
これはWeb開発言語ではなく求人数ということなので、それでもPHPも根強くはあるのですが、その半分はWordPress需要じゃないかと思ったりするわけで。なんか知らんけど、WordPress信仰は止めることができないみたいで、PHPもそれに付随して生き残るのではないかと。
とはいえ、PHPもLaravelみたいなものもできたので、そこまで古いもの扱いしなくてもいい気はします。それに枯れた技術というものはそれはそれで価値があるものではあるので、昔のひどい時期をことさらに忌避しなくてもいいような気がします。逆に言うと、そこの部分はある程度攻撃されてクリアされているわけだしね。
仕事の数からいうとJavaが一番多いけど、Javaを習得して会社に入ったけど、PHPやってますなんて人もいそうな数ですね、PHP。PHPは言語習得コストが低めなので、後からでも何とでもなりそうなのはあります。とはいえ、Javaはある程度の大きさのビジネス向けではあるので、PHPでお手軽にやるよりかはお作法が必要だけど、つぶしが効くという事で食いっぱぐれはなさそう。PHPで自分でサンデープログラマ的に活動はできるけど、Javaになっちゃうと途端に仕事感が出てきてしまうので楽しくはないな。
上のサイトでGolangが給料がいいって書いてあるけど、それって高い技術力を要求されるってことだよね。均一なJavaのコードを生産してくれというより、少々とがっている技術を見せてくれってことだろう。でも、Javaよりも習得コストは低めなので、書くのは簡単目だけどプロトコルを自らいじくるような高度な（ローレイヤーな）使い方をするようなのを求められるのかもなぁ。というか、C/C++で新しく書くぐらいだったら、どこでも動くのがわかっていて動かすのも簡単なGolangにするってことなのかもしれない。
Golangは外部ソースを使うにしても、他の言語に比べてGitで楽できるし、goコマンドがそれ前提にできている。Googleはトップ的な企業にもかかわらず、そのサービスは他のものに劣っていたりすることが多いが、Golang自体はとても素養がいいと思う。出てきた時点からブレが少ないし、使っていてしんどい思いをすることが少ない。でも、Web開発言語として使われることは少ないかもしれない。少しのコードでWebサーバを作ることができるけど、それは他の言語もわりとできたりするので特異的ではない。
Rubyが案外求人率が高かったり低かったり。就活サイトによりけりなのですが、日本人的には入りやすい言語ではありますよね。日本人技術者では英語があまりできないという事も多いので、その点では敷居が低い。そもそもの言語仕様がユーザーフレンドリーなのもありますし、Ruby on Railsはいまだによく使われているみたいですね。
Javaは最近のはあんまり知らないんだよなぁ。勉強しないといけないんだけど、アノテーションとか昔はあった覚えはなくて、最近はやたら使われている感じでしたね。まぁ見たソースはそんなに新しくないので最近じゃないんだろうけど、知っているJavaがJava2あたりなもので、新しく増えた部分はかなりあるんじゃないかなと。
訳の分からない記述が出てきたら逐一調べるか、基本文法を復習し直すか、どうするかちょっと迷っています。システムをスクラッチするなら全部さらっておいた方がいいだろうし、それを考えると結構しんどいかなと。既存のシステムはそのままで使っていくとは思うので、それをスクラッチして作り直すようなことはないにしても、システム同士をつなぐ部分に関しては作りこまないといけないので、やっぱりそこそこ知っていないといけないはずなんだよね。
Webはあんまり関係ないけど、C++の求人ってわりとあるんだね。組み込みとかわりとC++を使っている節があるけれども、この量からして組み込みだけってことはあり得ないね。一回プログラマをセミリタイアしたときには、WindowsのアプリとかでもMFCの資産とかあったけど、今だとC#とかが普通になっちゃってるんだろうなぁ。というかWindowsでしか動かない案件とかは減っていそうだが、わりとHTML5でできる範囲が広まったというのもあるんだろうな。
そう考えるとWeb系に入らなかった今までの経歴はわりとニッチなんじゃないだろうか。C/C++はつぶしが効くようでピンポイントな案件も多いから、来る仕事次第のところもあるんだろうな。なんかWeb開発言語どうでもよい感じになってしまったが、どこぞではJavaかPHPかPythonがいいらしいよ、って書いてあった。まぁ仕事の数を考えればそうなるかもしれないな。
<input type="file">でディレクトリを丸ごと送信したい、を実装 [プログラミング]
PHPで簡単にHPをアップロードできるシステムを作ってみたいと思った。初めはエクスプローラみたいに操作できるものを考えたんだけど、思いのほかめんどそうなので、とりあえずフォルダをごっそり上げる仕組みにしたいと思った。
そんで差分ファイルだけ上げて上書きするような感じで。そうすると要らなくなったファイルも残っちゃうけど、それは別途削除の仕組みを作ってあげた方がいいような気がした。
必要なのはPHP実行環境と、ファイルかフォルダを指定できるインターフェイスのみかな。ただアップするだけなのでそんなに問題があるとは思わないんだけど、実装するには一工夫必要であった。
・ファイル一つを上げる
http://www.isl.ne.jp/pcsp/php/contents_10.html
・ディレクトリごと
<input type="file">でディレクトリを丸ごと送信したい
https://qiita.com/akase244/items/f5f7287cfe28bebe00fc
これを実際にやったのが下のGithubのファイルです。
https://github.com/miffy/php-one-file-uploader
https://github.com/miffy/php-one-file-uploader/blob/main/upload.php
readmeにいろいろ書いてあるので、そちらを読んでいただければ情報を得られるとは思いますが、こっちでも解説しておきますね。
まず使うにはPHPを実行できるディレクトリにアップロードします。そのファイルをWebブラウザから見るとディレクトリの設定するボタンがあるので、そこで自分の上げたいディレクトリを設定して、ボタンを押すだけでファイルが上がります。実験的に行っているので問題はありありなのですが、一応できるという事を示したかったので、簡潔に見られるようにはなっています。
内容を簡単に説明すると、HTMLの
でディレクトリの情報を取ることができます。Submitすると指定した中のファイルが、Webサーバのテンポラリディレクトリにアップロードされます。
でもただそれだけだと、ファイルを複数送信しただけで、違うディレクトリにある同名のファイルは上書きになるので、ローカルでのディレクトリ構成を別に上げてテンポラリからコピーするときに名前を付けて各ディレクトリごとのコピーを行います。
結局、$_FILESの中に入れ込んでくれればいいものの、その情報はローカルでwebkitRelativePathで取れるものの、意図的に送り込んでやらないとダメなのでした。なので$_POSTに入るように別途送ってあげるようにしています。実際にはfuncBtn()の部分ですね。実証コードだったので、動くサンプルをそのままコピペしてきていて変数の名前とかが適当です。
JSONで送ることも考えましたが、めんどうなのでJavaScriptでカンマで区切って、PHPでexplode()で受け取っています。基本、どちらの順番も同じだと思うので、そのまま配列の番号は合っていると思います。
しかし、php-one-file-uploaderだとファイルが一個しか上がらない感じがしてしまうな。PHPファイル一つでいっぺんにディレクトリをアップロード可能というところ言いたかったんだけど、英語的にも伝わらない気がした。
そんで差分ファイルだけ上げて上書きするような感じで。そうすると要らなくなったファイルも残っちゃうけど、それは別途削除の仕組みを作ってあげた方がいいような気がした。
必要なのはPHP実行環境と、ファイルかフォルダを指定できるインターフェイスのみかな。ただアップするだけなのでそんなに問題があるとは思わないんだけど、実装するには一工夫必要であった。
・ファイル一つを上げる
http://www.isl.ne.jp/pcsp/php/contents_10.html
・ディレクトリごと
<input type="file">でディレクトリを丸ごと送信したい
https://qiita.com/akase244/items/f5f7287cfe28bebe00fc
クライアント側で「webkitRelativePath」というファイルオブジェクトのプロパティが取得可能なので、これをPOSTデータに含めて一緒に送信し、サーバー側でゴニョゴニョしてあげると良いと思います。
これを実際にやったのが下のGithubのファイルです。
https://github.com/miffy/php-one-file-uploader
https://github.com/miffy/php-one-file-uploader/blob/main/upload.php
readmeにいろいろ書いてあるので、そちらを読んでいただければ情報を得られるとは思いますが、こっちでも解説しておきますね。
まず使うにはPHPを実行できるディレクトリにアップロードします。そのファイルをWebブラウザから見るとディレクトリの設定するボタンがあるので、そこで自分の上げたいディレクトリを設定して、ボタンを押すだけでファイルが上がります。実験的に行っているので問題はありありなのですが、一応できるという事を示したかったので、簡潔に見られるようにはなっています。
内容を簡単に説明すると、HTMLの
<input type="file" name="upfile[]" webkitdirectory>
でディレクトリの情報を取ることができます。Submitすると指定した中のファイルが、Webサーバのテンポラリディレクトリにアップロードされます。
でもただそれだけだと、ファイルを複数送信しただけで、違うディレクトリにある同名のファイルは上書きになるので、ローカルでのディレクトリ構成を別に上げてテンポラリからコピーするときに名前を付けて各ディレクトリごとのコピーを行います。
結局、$_FILESの中に入れ込んでくれればいいものの、その情報はローカルでwebkitRelativePathで取れるものの、意図的に送り込んでやらないとダメなのでした。なので$_POSTに入るように別途送ってあげるようにしています。実際にはfuncBtn()の部分ですね。実証コードだったので、動くサンプルをそのままコピペしてきていて変数の名前とかが適当です。
JSONで送ることも考えましたが、めんどうなのでJavaScriptでカンマで区切って、PHPでexplode()で受け取っています。基本、どちらの順番も同じだと思うので、そのまま配列の番号は合っていると思います。
しかし、php-one-file-uploaderだとファイルが一個しか上がらない感じがしてしまうな。PHPファイル一つでいっぺんにディレクトリをアップロード可能というところ言いたかったんだけど、英語的にも伝わらない気がした。
タグ：PHP
プログラミング言語は使われていてサポートされていれば終わりではない。 [プログラミング]
よくPHPは古いだの、jQueryは時代遅れだの言われているようですが、過去のシステムをそれで作っていたら、それを面倒見ないといけないわけで、古いだの新しいだの言っているわけにはいかないんですよね。というか、この世の案件で新規スクラッチのシステムがたくさん存在するかと言われると、既存のシステムを改築する方がよっぽど多いんじゃないかと思うんですよね。
特に他の会社に入ってSEやっているとかいう人は、そこで使われているツールやシステムの面倒を見る要員として雇われているわけだし、新しく作るっていうのはそこまでたくさんあるわけじゃない。まぁ所によるとは思うけど、たぶん大体そんな感じ。Perlは今はそんなに使われていないかもしれないけど、台湾のえらいひともPerl後継を扱っていたようだし、その言語が終わるという事はなかなかに難しいことなのかもしれない。
Rubyとかは好きだしRuby on Railsとかはよくできていると思う。だけども、使われているサイト数を考えるとPHPの比ではない。まぁ自分が見たデータはWordPressも含まれている可能性は十分にあるけれども、PHPで動いているシステムは拡張子で分かるので、よく見かけることはわかる。少なくともJavaのTomcatでの.jspや.doなどよりかはよく見かけるような気がするんですが。
まぁ他の言語と同じように拡張子の偽装はできるので、簡単にその数を測ることはできないけど、社内システムでわざわざ下のようなことをすることはあんまりないんじゃないかと思ったりはする。
https://dev.classmethod.jp/articles/rewrite_url_using_reweitevalue_in_tomcat/
PHPでもApacheの設定でうんぬんできるようなので、あれもPHPだったという事もあるかもしれません。だから使われているサイトが少ないという事に直結することもない。
https://ameblo.jp/web-designers/entry-10426619511.html
というか、外向けサーバで.phpな拡張子丸出しは、歴史的な脆弱性から言うとうれしくない気はしますね。今では脆弱性が少なくなったとはいえ、裏で何が動いているのか察せられることをよく思わない、少しばかりの慎重さを見せることがないこと自体が問題かなと思ったり。要するに付けこまれるカモとみられやすいというか…。
最終的にはセキュリティとレスポンスが維持されていれば、何の言語を使っても同じだとは思いますよね。確かに書きやすい言語とそうでない言語はあるとは思いますが、そもそもWebシステム構築に使われる言語ってそんなに多いとは思えないですしね。
自分がPHPをやるまでは、こんなに良く言われていない言語ってないなと思ったものでしたが、実際に使って調べてみると、現状はそんなに問題となることはない、と言っていいのではないでしょうか。大方のシステムは問題のある5系から7系に移行しているだろうし、言語的に問題がある部分はどんどんなくす傾向にはあるようですし。
何か必要があってPHPを自ら使い始めることは少ないかもなと思ったりはするんですが、それでも初期的な学習コストは低めだし、そこまで悪いとは言えないとは思います。言語としての厳密性という意味ではあまりよろしくない状況もありますが、そんなことを考えるよりも動くものを作ろうという気になれば、それは枝葉末節の事柄に当たるのだと気づきます。
もちろん、コンピューター言語をはじめに習うのにPHPが向いているとは思えません。お勉強の面からすると推奨されるようなものでもないかもしれません。学習コストは低いんだけど、あまりにもWeb寄りの言語であることに、他の言語に向かいづらくなってしまうかもしれないなと思ったりはします。最初からWebサイトをバリバリ作るという気持ちがない限りは、仕事でアサインされてから真剣に勉強するでも遅くない気はします。
それと最近はプログラミングスクールとかで、Webサイトのシステムを作るというお題で勉強するみたいですが、本当にまっとうな意味でプログラミングをしたいと考えているなら、Webシステムはお勧めできません。何にしても知っていなきゃいけないことが多すぎる。
フロントエンド：HTML、JavaScript
ビジネスロジック：いろいろな言語
バックエンド：SQLなど
と一人でやるなら知っておかないといけないことが山ほどあるからです。これは正直ビギナーにはやることが多すぎますし、それをスクラッチでという事になると、数個のフレームワークを使う事になるので、自分で作った部分が単なるジェネレーターが出したコードの装飾みたいになる、ことになりがちだろうからです。何かが起きた時には自分で対処しずらくなる。
初めからフルスタックエンジニアを求められるのはきついと思うので、Webは要件が多いかもしれないけど、入り口としては結構地雷なのかもしれないと思っておいた方がいいです。実際、昨今のプログラミングスクールから採用されることは少ないみたいですしね。
それでもPHPがやりたい人は止めないけど、さほど良いものではない。PHPがサポートを止められる日が来るのはそう早くはないだろうし、これからも新規には少なくても使われていくのは間違いないところです。だからPHPは安泰だというつもりはないですが、少なくともPHPだけをやっていたら安泰じゃないだろうなとは思います。
よく初心者に何の言語をやったらいいですか？という話を見たりしますが、なかなか難しいですよね。一時期、メジャーになり基本情報技術者試験の課題にもなったJavaがありますが、今ではそこまで案件が多いように思えないですしね。まぁ全体から見れば割合は多いのかもしれないですが。
とりあえず流行りで行くというのもいいのかもしれません。できれば、自分がやりたいことと合致しているものがいいのですが、そういうものがきっちりあるという人も多いとは思えないし。今だったらPythonとかやっておけばいいんじゃね？ぐらいの事しか言えません。というか、すごいマイナーな言語以外は差分となるところを除いたコアの部分はみんな同じなので、何をやってもそこそこ応用が効くだろうから、自分が信じた道を行くのもいいと思います。正直、どう転ぶのかは誰にもわからない…
特に他の会社に入ってSEやっているとかいう人は、そこで使われているツールやシステムの面倒を見る要員として雇われているわけだし、新しく作るっていうのはそこまでたくさんあるわけじゃない。まぁ所によるとは思うけど、たぶん大体そんな感じ。Perlは今はそんなに使われていないかもしれないけど、台湾のえらいひともPerl後継を扱っていたようだし、その言語が終わるという事はなかなかに難しいことなのかもしれない。
Rubyとかは好きだしRuby on Railsとかはよくできていると思う。だけども、使われているサイト数を考えるとPHPの比ではない。まぁ自分が見たデータはWordPressも含まれている可能性は十分にあるけれども、PHPで動いているシステムは拡張子で分かるので、よく見かけることはわかる。少なくともJavaのTomcatでの.jspや.doなどよりかはよく見かけるような気がするんですが。
まぁ他の言語と同じように拡張子の偽装はできるので、簡単にその数を測ることはできないけど、社内システムでわざわざ下のようなことをすることはあんまりないんじゃないかと思ったりはする。
https://dev.classmethod.jp/articles/rewrite_url_using_reweitevalue_in_tomcat/
PHPでもApacheの設定でうんぬんできるようなので、あれもPHPだったという事もあるかもしれません。だから使われているサイトが少ないという事に直結することもない。
https://ameblo.jp/web-designers/entry-10426619511.html
というか、外向けサーバで.phpな拡張子丸出しは、歴史的な脆弱性から言うとうれしくない気はしますね。今では脆弱性が少なくなったとはいえ、裏で何が動いているのか察せられることをよく思わない、少しばかりの慎重さを見せることがないこと自体が問題かなと思ったり。要するに付けこまれるカモとみられやすいというか…。
最終的にはセキュリティとレスポンスが維持されていれば、何の言語を使っても同じだとは思いますよね。確かに書きやすい言語とそうでない言語はあるとは思いますが、そもそもWebシステム構築に使われる言語ってそんなに多いとは思えないですしね。
自分がPHPをやるまでは、こんなに良く言われていない言語ってないなと思ったものでしたが、実際に使って調べてみると、現状はそんなに問題となることはない、と言っていいのではないでしょうか。大方のシステムは問題のある5系から7系に移行しているだろうし、言語的に問題がある部分はどんどんなくす傾向にはあるようですし。
何か必要があってPHPを自ら使い始めることは少ないかもなと思ったりはするんですが、それでも初期的な学習コストは低めだし、そこまで悪いとは言えないとは思います。言語としての厳密性という意味ではあまりよろしくない状況もありますが、そんなことを考えるよりも動くものを作ろうという気になれば、それは枝葉末節の事柄に当たるのだと気づきます。
もちろん、コンピューター言語をはじめに習うのにPHPが向いているとは思えません。お勉強の面からすると推奨されるようなものでもないかもしれません。学習コストは低いんだけど、あまりにもWeb寄りの言語であることに、他の言語に向かいづらくなってしまうかもしれないなと思ったりはします。最初からWebサイトをバリバリ作るという気持ちがない限りは、仕事でアサインされてから真剣に勉強するでも遅くない気はします。
それと最近はプログラミングスクールとかで、Webサイトのシステムを作るというお題で勉強するみたいですが、本当にまっとうな意味でプログラミングをしたいと考えているなら、Webシステムはお勧めできません。何にしても知っていなきゃいけないことが多すぎる。
フロントエンド：HTML、JavaScript
ビジネスロジック：いろいろな言語
バックエンド：SQLなど
と一人でやるなら知っておかないといけないことが山ほどあるからです。これは正直ビギナーにはやることが多すぎますし、それをスクラッチでという事になると、数個のフレームワークを使う事になるので、自分で作った部分が単なるジェネレーターが出したコードの装飾みたいになる、ことになりがちだろうからです。何かが起きた時には自分で対処しずらくなる。
初めからフルスタックエンジニアを求められるのはきついと思うので、Webは要件が多いかもしれないけど、入り口としては結構地雷なのかもしれないと思っておいた方がいいです。実際、昨今のプログラミングスクールから採用されることは少ないみたいですしね。
それでもPHPがやりたい人は止めないけど、さほど良いものではない。PHPがサポートを止められる日が来るのはそう早くはないだろうし、これからも新規には少なくても使われていくのは間違いないところです。だからPHPは安泰だというつもりはないですが、少なくともPHPだけをやっていたら安泰じゃないだろうなとは思います。
よく初心者に何の言語をやったらいいですか？という話を見たりしますが、なかなか難しいですよね。一時期、メジャーになり基本情報技術者試験の課題にもなったJavaがありますが、今ではそこまで案件が多いように思えないですしね。まぁ全体から見れば割合は多いのかもしれないですが。
とりあえず流行りで行くというのもいいのかもしれません。できれば、自分がやりたいことと合致しているものがいいのですが、そういうものがきっちりあるという人も多いとは思えないし。今だったらPythonとかやっておけばいいんじゃね？ぐらいの事しか言えません。というか、すごいマイナーな言語以外は差分となるところを除いたコアの部分はみんな同じなので、何をやってもそこそこ応用が効くだろうから、自分が信じた道を行くのもいいと思います。正直、どう転ぶのかは誰にもわからない…
タグ：PHP
