  |
はてなキーワード: Guiとは
雑誌のInterfaceでライセンス6ヶ月無料となっていて、一部界隈で話題になっているMATLAB。
普段MATLABを使っている身だが、Pythonのライブラリが充実している状況で、MATLABを使う意味は何か悩むことがある。
それなりに高いライセンス料を払って効果出てるのかって話になる。
本体だけでなくToolboxも使い出すと高くなる。
MATLAB言語仕様として速度が遅い(for文はJITで昔より高速になったというが遅い)だけでなく、高いワークステーションを買ったとしても普通にプログラムするとシングルプロセスで遅い。
GPUやマルチコアの性能を活かすには、それ用のコードに書き換えと、メモリーコピーの影響などもあるので実際速くなるかプロファイルで試行錯誤が必要になる。
plot周り、画像周りは気になる。
とはいえ学生からすると会社に入ってからは使わない物を学ぶより、Pythonを学びたいはずだ。
企業が使う場合に関しては、先に挙げた理由でまず業務効率になかなか結びつかない。
低レイヤー過ぎて開発コストがかかる、コストがかかる割に遅いなら別の手段で開発するはずだ。
昔からのMATLABコードを動かしている所以外、新規でMATLABを学ぶメリットはあるのか。
もう１つ気になる点は数値計算や画像処理など、色々対応してはいるが、
画像だったらHDRの表示対応などだ。今どきのディスプレイ表示に対応してない。（HDR機能はあるが古い）
CAE的な物も教科書的な物は出来るが、業務的な物は扱いにくい。
toolboxが沢山あり、かつドキュメントもそれなりの量があるので、業務でも使えそうに思ってしまうが、
実際業務を進めると詰むことになり、結局別の有名ソフトで立ち上げ直すとなりがち。
(Juliaが代わりになると一時期話題になっていたが、実際本格的に使うと色々足りてない。）
OSというと、基本的にファイルシステム、GUIないしCLIインターフェース、ネットワーク通信(はまだなくてもいいか？)、その下にあるハードウェアの制御などが機能としては一般的なものになると思うけど、少なくとも今そこまで出来ているとは考えにくいな。
この辺見る限り、スマートコントラクトについては合っていそうだけど。
https://ethereum.org/ja/developers/docs/smart-contracts/
イーサリアムのアドレスにあるということなので、これをメモリアドレスと見なしているのだと思うが、現在の定義ではOSは上でハードウェアの制御と書いたように基本的には単体の物理マシン上にインストールされるもの(仮想マシンの場合はハードウェアを下のハイパーバイザがエミュレートしたりバイパスしたりするはず)なので、分散システムであるブロックチェーンとは相性が悪いんじゃないかな。
少なくとも、イーサリアムのスマートコントラクトを自分のマシン上に持ってくるために、OSの下にネットワーク通信が出来る「何か」が存在する必要があるのでは？現在これはOSが担う機能なのだけど。
言ってることはなんとなく分からないでもないけど、少なくとも現時点で広く認知されている「OS」になるとはあまり思えないな。
Windowsの非インストーラー版のソフトって皆どこに解凍(展開)して置いて使ってるの？
インストーラー版だったら大抵は勝手にC:\Program Filesと指定されて展開されるから、ソフトを置いておく場所に迷うことはないけど、
ZIP版とかのみのソフトだと、自分で展開先(置く場所)を決めて管理しないといけないけども、そうなると「どこに置こうか」という判断に時たまふと地味に悩む。その場合どこに置くのがいいのか。
(たとえば使い捨て用途のソフトだったら用が済めばすぐ捨てるから、デスクトップ上だろうがCドライブ直下だろうがどこに展開して使おうがソフトを置く場所にこだわりはないだろうけど。)
皆は使い続けるソフトはどこに置きまとめているの？
しっくりこなくて地味に悩む。
検索用:
パワハラって具体的に何なのかわかんないけど、力関係的に逆らいにくい人にプレッシャーかけられたので多分そうなのかなと思う。
どんな感じだったかというと
2.実装していくとどうすればいいかわからない部分が出てくるので、仕様を尋ねる
3.無視される
5.後々、仕様と違うことを詰められる
という感じだった。
詰められ方は
「バグが多すぎます、ちゃんと確認やテストを行ってください」とか
「この不具合はシステムの構造上致命的です、早急に修正してください」とか
いまチャットの履歴から引っ張ってきたけど、原文はもうちょっと高圧的だと思う
普通じゃんと思うかもしれないけど
だったりするので、小さなミスでも大きなミスとして圧をかけてくるのが辛かった。「そもそもそんな仕様だったことすらこっちは知らないよ！」っていうのでも責められるし。
そしてミスはミスだからこっちが悪いので言い返せないんだよね…
未経験からエンジニアになったというか、新卒→自営の流れを汲んだ人間で初社会人だったから「世の中こんなものなのかな？」とか思ってたけど
いわく下についた人を二桁近くやめさせてきた人間らしくて外れ引いたんだなって思った
今その会社の評価星1.2とか凄まじいことになってるんだけど、
昔は良かった的なコメントがついているのでもしかしたらこの人のせいで良いエンジニアがどんどんやめていってしまったのかなとか思ったりした。
技術力も低くて尊敬できる所一つもないんだけど、こういう人に限って社内政治が得意だったりするもんだから、上の方のポジションに居るんだよね
だから指示も抽象的で「いい感じに頼む」みたいになるし、GUIで状況がわかる段階になってから「こうじゃない！」とか言い出すから困る
一つだけ良かったこととしてはありとあらゆることが適当に投げられて後よろしくされてたので、急速に技術がついたこと。
DBもよくわからなかったし、SQLも書けなかったけど、半年ぐらいでフルスタックの開発を一から任せてもらえたりしたし、実際にどうやればいいか分かれた。
---
冒頭に戻るけど、SEは
・大まかな設計
・進捗管理
など、いわゆる上流工程のこと指して使ったけど、結局こういうポストに収まる人って社内政治得意マンが多いんだろうなって思った
社内政治が得意で技術力もあるっていう人は、仮にどちらもレア度10%だとしたら掛け合わせで1%なわけで、多くは社内政治だけ得意なことが多い
つまり技術力は対してないから具体的な指示が出せなくて、曖昧なところを『いい感じ実装』する羽目になる。技術力なかったら具体的な質問に的確な回答を返せないしね。
……正直そんなSE嫌われてる論とかどうでもよくて、
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
MATLABを使っているが、どうも中途半端な存在になっている。
①言語的な競合はもちろんPythonになるが、Pythonとの差別化が出来てない。
Python側は純粋なPythonだと遅いが、今はC++のラッパーとして使うのが多くなっており、Pythonの方が速いということが起こる。
最近のMATLABはJITコンパイラによって昔ほどfor文を気にしなくても良くなっているが、それでも遅さは気になる。
GPU、分散コンピューティングにMATLABは対応しているが、使いこなすのに苦労する。
GPU使う場合だと、CUDAをそのまま使いたくなるし、GPUメモリーとのやり取りといったオーバーヘッドが加わるので、
単純にGPU使うようにしたら速くなるってことはなく、処理時間を測りながらトライアルを繰り返すことになる。
MATLAB側のエディタは機能が増えているとはいえ、Python+VSCodeとの対抗となると辛いものがある。
toolboxを追加で課金してCコードを吐き出すことはできるが、劇的に速くなるわけではない。
②toolboxは沢山あるが、使い始めると色々足りておらず、Pythonのエコシステムが欲しくなる
toolboxが多くなりすぎていることと、手を広げすぎているのかtoolboxを買って使ってみると色々足りないことがある。
買う前に調べるわけだが、色んな事ができそうだと思って購入し、実際使っていくと、嘘は言ってないが事あるごとに使いにくい所が出てくる。
GUI周りに関しては不満が多い。
③GUIが重い、使いにくい
事あるごとにGUIが重たいのが気になって仕方ない。
また使いにくいのが多い。デザインが良いというのはコンシューマ用ではないので気にしないが、重たさと使いにくさで嫌になってくる。
④plotや可視化周りが重い
エクセルが普通になっている今、エクセルで出来ないことが出来て欲しいが、そうなっていない。
https://d.potato4d.me/entry/20220405-nodejs/
が話題になっているけど、本来人類に必要なのはクロスプラットフォームな実行環境であってNodeじゃない。
TSが流行ったのはJSがクソだから。BabelしなきゃいけないのもJSにトランスパイルしなきゃいけないからであって、必要なのはJVMやCLRのような言語実行環境。
Reactが流行ったのはshadow domだけど、必要なのはDOMじゃなくてちゃんとした「アプリ」開発用のイベントモデルとレイアウトマネージャ含むGUI環境。
フロント界隈の流行廃りって本質的な改善ってよりもほかの良い技術をいかにブラウザ/Electron等JSエンジンという限られた環境に持ち込んで幸せになるかがメインに見えるので地獄に見える。
「アプリ」書くのになんでドキュメント記述用のHTMLに今ものっかってんだよと。
MavenやらGemsができて依存管理楽になったとか、RailsがでたときのようなCoC良いねとか開発の考え方を変えるフレームワーク、 rspec/Cucumberがでてテスト最高とか、c10kも怖くない非同期I/Oとか、好きな言語が使えるJVM/CLRそもサーバーならrustでもgoでも好きなものが動くとかとか本来の開発を楽にするという意味のブレークスルーってあんまりみられない気がしている。なんでフロント界隈の新技術ってあんまりわくわくしない。
逆にちゃんとしたクロスプラットフォーム実行環境がブラウザしかないということなんだけど、ブラウザなかなか進化しないし RIA は Apple 様が切り捨てるからなぁ。
ということですべてはブラウザが悪い。JavaScript 以外がちゃんと動くクロスプラットフォームのGUI環境が必要。でもプリインでモバイルでも動いてOSから独立して協調して作られていて、Webという既存の大量の資源にアクセスしやすいものは現時点で実質ブラウザ一択。つまりWASM に期待。次にHTMLであるべき文書はともかくSPAなんてもう「アプリ」なんだからHTML手書き文化もうやめてネイティブアプリ並みの GUI 作成環境も復権しよう。
するとクライアントでも好きな言語が使える。そして同じ言語がいいとサーバサイドで Node.js を使う必要もなくなりへっぽこプログラマが Node のイベントモデルを理解せずに使うこともなくなる。
そしてそれらができたときに Node というか JS/HTML の呪いから解放され人類に平和が訪れるのだ。君はその後も Node.js を使っても良いし使わなくてもいい。
未経験から3ヶ月で外資IT勤めで年収1600万みたいなのがバズってたので
ただし俺の場合、実務が未経験なだけでプログラミング歴は20年ちょっとある、いわゆる趣味グラマからの転職
同人ゲーム制作やFLOSS系の活動はずっとやっていて、学生時代はバイトで出会い系サイト作ってた
前職の都合で自動車メーカーとも繋がりがあり、そのツテで昨今の自動車へコンピューティングを強く導入するという流れがあったので誘われて転職することになった
つまり草の根(もう死語だねコレ)の情報技術者が昔馴染みを頼って転職しただけと言ってしまえばその通りなのだ
こんな転職の仕方だからプログラミングスクール出身者のレベルがどんなもんだか知らんけど、もともと俺は電気系のオタクでシーケンスに関して理解があってH8あたりからプログラミングへ手を出しているって感じがスタートなんだ
たぶんイマドキの純粋培養な情報技術者の中には電気回路まったくわからんって人も居るとは思うけど、電気関係の素養があったほうがプログラミングの習得には今でも有利なんじゃないかな？と思わなくもない
例えば俺へ対してパソコン通信やインターネットを通じてプログラミングのノウハウを教えてくれたお兄さんたちはゲームメーカーでエレメカやってるって人が居たりして、後にゲームハードやROM作り始めたなんて話もリアルタイムに聞いていた。今じゃお偉いさんになってるだろうけど
そんなんだから俺はハードもソフトもネットワークもスペシャリストほどではないけれど満遍なく知る変な素養があり直接声がかかった次第だ
イマドキ流行りのGoとかSwiftとかRustみたいなイケイケな言語ではなくC++とかJavaとかBashとかの方が得意だっていうのも評価としてはあったかも知れないけどね
あと日常的なLinuxデスクトップ使いというのも最近のLinux興隆の流れから後押しがあったかも知れん
もちろん苦手な部分もある、GUIがそれだ
GUIの設計なんて言うものはデザイナーがやるべき仕事だね。今流行りのそれっぽいのとかツールチップ使いましたみたいな古典的なスタイルを真似たGUIを作ろうと思えば作れるけど、単なるモノマネなので本職のそれとは出来が違う
というわけでプログラミングスクール出身者、どこかで俺みたいな草の根出身者に出会うこともあるだろうから、そのときはヨロシクな
MATLABの言語仕様上、処理が遅い（JITコンパイラで改善されているが）
→ わかる
GUIが基本モッサリ
→ ライセンス料高いのでなんとかして欲しい。
→ライセンス料高いのでなんとかして欲しい。
Image Processing Toolboxの画像データの値を表示するGUIが使いにくい。
→ 追加でtoolbox代金払ったのに何故ってレベル
音の再生、停止、動画の再生、停止、コマ送りなどのGUIが使いにくい
→ なんとかして欲しい。
プロットの細かい調整に時間がかかる。GUIはあるが不親切だったり、誤操作しやすい
→ なんとかして欲しい
→ 今どきディスプレイ前提のことが多いので、論文印刷用以外のプロット方法も準備して欲しい
マルチコアのCPUを使わない。Parallel Computing Toolboxはあるが効き目のある場面が限られる
