はてなキーワード: IDEとは
IDEってCLIで開発しているときには考えられないくらい、色々便利な機能が付いてるじゃん。
そういう機能がないと、エラーに出くわしても何にもできませんみたいな人にならないか?というのが気になる。
CLIのほうが覚えることが少ないのはその通りで、IDEの使い方とか余計なこと考えずにプログラムの中身に集中できるのは、初心者には重要だよね。
俺「〇〇して」
俺「〇〇するときって最初どうすんだっけ、えーと……これして」
CLI「ほい」
俺「で、次はえーと……あれして」
CLI「むりやで」
俺「え? あー、最初が間違ってる、そうじゃなうくてこうして」
CLI「ほい」
俺「で、次は、こう……であってるよな……、えっとお……」
俺「これをこれこれこうした後でそれしてあれして最後にこれでまとめて」
俺「まずねー、これをね……」
IDE「これ?」
俺「うんそう、それ。それをこうしてくれる?」
IDE「……こう?」
俺「そうそうそう、ありがとう。合ってる。次はねー、これを……」
IDE「これ?」
俺「そう、それをこうして……」
IDEを使う上で覚えることは決して少なくないし、CLIだったら実行するためのコマンドとエラーメッセージの読み方だけに絞れる。
そしたら「自分のプログラムがなぜ動かないか」という本質的な問題に直面しやすいだろ。
たった1文字書き誤っても動かない、だから書く時は注意の仕方にコツがいる(≒単純なコピペであってもすぐ動くとは限らない)とか、実地に学べるじゃん。
一方で、スペルミスとかもいちいち丁寧に教えてくれる、IDEの親切な機能に最初からおんぶにだっこみたいなプログラミングがいいとは思えない。
あと、こっちはIDEの便利さは否定しないどころか、効率的に開発するなら必須だと思っているけど、最初からセットで覚えるものじゃないと言っているだけなんだが。
なんで最初からIDEでプログラミングを覚えるべきなのかが理解できない。
これもう言いがかりやん
CLIだとCLIしか使えないプログラマーが出ても問題ないってこと?
IDEしか使えない問題点ってそれほどないし事前にわかってれば回避可能じゃね?
さらにIDEを使いこなすことばかりに注意が行って、データ構造とアルゴリズムへの意識が甘いプログラマとかも生まれそうだよね。
macだとカーソル移動させる時にctrl+aで行の先頭、ctrl+eで行の末尾とかできるけど、Windowsだとそういう無いの?
検索したらカーソル動かすのは矢印キー、行の先頭へ移動させるのはHome、行末へはEndとか出てくるけどWindowsでプログラミングしてる人はそれでカーソル移動してるの?
ctrl+f,b,p,nとかでカーソル移動させるのに慣れすぎてて、ホームポジションから手を離す以外にカーソル移動させる方法しかないのが信じられなくて増田に書いてみた。
AutoHotkey(?)でキーコンフィグできるみたいだけどそういうの導入してるのかな。
capsとctrl入れ替えるのにCtrl2Capとかわざわざソフトインストールしないといけないってマジ?
ctrl+dでdeleteしたいよー。
何か暗黙的にWindowsでプログラミングする時にはこういうツール導入して、こういうキーボードショートカットに変更するよみたいなことがあれば教えて欲しい。
そういうは特に無くて慣れの問題なら、Windowsのキーボードショートカットはそういうものだとして受け入れることにするよ。
ちなみにIDEはとりあえずVisual Studio使い始めた。
プログラムのインデントで未だにスペースでインデントしてるのか理解できん
タブ文字を使えよ
タブキーでタブサイズ分のスペースが入力されるからって、それはわざわざタブ文字の動きをエミュレートしてるだけ
間違ってバックスペース押したせいでインデントがずれてたけど気づかなかったとかそんな余計な問題が発生するだけだろ
タブ文字にしたらそんなことは発生しないし、エディタ問わずタブ文字単位でカーソル移動もできる
スペースインデントは2文字か4文字かで対立したことがないか?
ネストが深くなるとインデント幅は浅めにしたいが、浅いと離れたところのインデントレベルが同一かを瞬時に判断できない
インデントの文字数が8文字もあればその点では迷うことはないが横スクロールが発生して見づらくなりやすい
タブ文字は幅が可変なものだから大抵のエディタでは簡単にインデントの幅を調整できる
スペースでもできなくはないが対応してるのは一部のIDEくらいだ
それに実体としてのスペース数が変わってしまうから複数人で扱うファイルの場合はバージョン管理や自動フォーマット等の環境が整ってなければ手間が増えるだけだ
最近はウェブだとアクセシビリティだとか言って普通に画面を作る分にはなくていい属性を色々追加しろよみたいな雰囲気がある
そんなアクセシビリティとか考えるならまずタブ文字にすべきだろう
令和にもなってWordやExcelでスペースで位置調整するのと同じような馬鹿なことをしないでもらいたい
ITエンジニアなんてのはそういうのはやめるべきっていう側だと思うんだが
---
ちなみに念のため、これは行頭における話
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか?(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
https://anond.hatelabo.jp/20220214164030
まず真っ先に出てくるのがスマートグラス
Googleがしっかり投資してインチキムービー作ってまで頑張ったけど無理でした
EPSONが頑張って出してくれてるしHololensとか工場系で使われてる(らしい)けど
5Gには2種類あって5GHz帯周辺を使うSub6と、30GHzとかのミリ波帯を使うmmWaveがある
このミリ波帯は高速通信可能なことが知られていてWiFiにも規格がある(IEEE 802.11ad)
ところが指向性が強いし遮蔽されると通信できないとかで全然使い物にならない
ビームサーチ技術とか使うと指向性は大丈夫になるんだけど、遮蔽はどうしようもないのでほとんど採用されず
5Gで10Gbps越え!とか言ってるのはmmWave使った場合なので騙されないように
IEEE802.11adの話が出たので、IEEE802.11aiの話。
これが何者かっていうと、WiFiの接続時間を無茶苦茶短縮できる技術。
WiFiって繋がるまでに結構時間がかかる(といっても数秒)んだが、それを0.1秒ぐらいにしてくれる。
そうすると隣のWiFiに移動しても途切れずに通信できたりするのがメリットなんだけど
あんまりそういうシチュエーションが無い、というか家庭とオフィス以外でWiFiがそもそも使い物にならないからね
こんな感じで802.11系を調べると来なかった技術の宝庫です
SDカードのデータ通信速度が遅くて特にカメラ業界はイライラしてて
読み取り端子を二段構えにしたUHS-IIという規格を作成
一部の高級志向カメラには搭載されたし下位互換性もあるから流行るかな?って思ったが
その手のカメラはXQDとかCFExpressに流れてしまった
まぁ細々と生きてはいる?のかな?
そもそもSDカードの抜き差しがめんどくさいんじゃ!ということで無線通信可能なカメラとかが出現。
TransferJet対応のSDカードとかも出てきて盛り上がるか?と思ったが、流行らず
そもそも高級志向カメラの人達は撮り終わったら家に帰ってゆっくり現像なので、無線でやるメリットがほとんど無いんだよね
と思ったあなたは間違えてないが、実はETC2.0の構想としてはその辺の駐車場でも使えるようにする予定だった
駐車場でETCが使えたらこの上なく便利で仕方がないサービスのような気がするのだが導入が進んでないのはやっぱりコストが高いのかな?
まぁ、承認も何もなしにいきなり「駐車料金は3000円でした」とか言われても困るけど、結局は払うんだから導入してほしい
でもそうなると駐車券処理とか面倒になりそうだからやっぱ無理なのかな
ちなみに駐車場の最近の流行は「ノーガード戦法」のようで、ゲートも何も無く、車両をカメラで撮って、酷い違反があれば後から追いかける、らしいです
だって、導入するイニシャル・ランニングのコストよりバイト雇った方が圧倒的に安いんだもの・・・