はてなキーワード: ideとは
英語だとexpandだし展開っていう言い方もあるけど日本で解凍っていうことが多いよな。
むしろ水分が含まれたら解凍後のほうがだいたい体積は減るのでは
（追記）
よなあ。圧縮→アチチだからむしろ解凍してるよな。まあデータはエチチかもしれないけど。
でもそうすると逆によ、逆にだけどさあ、旧ツイッターの場合はどんだけ「凍結」しても「解除」なのが今度は謎だよな。「キューツイッター解凍されたー！」って言ってる人みたことないわ。
（追記）
expandって言わない件、ちょっとAIの野郎にきいてみたわ
| 日本語表現 | 意味・用途 | 英語表現 |
| 圧縮 | データを小さくまとめる | compression |
| 解凍 | 圧縮されたデータを元に戻す | decompression |
| 展開 | 解凍とほぼ同義。特にGUIでよく使われる | extraction / unpacking |
| アーカイブ化 | 複数ファイルを一つにまとめる | archiving |
| 復元 | 元の状態に戻す（バックアップなど） | restore / recovery |
| パック | 圧縮と似ているが、ゲームやソフトで使われることも | packing |
| アンパック | 展開と同義。特定のツールで使われることが多い | unpacking |
そんでexpandは圧縮のソフトでもたまに用いられるけどふつうはもっとUIよりの表現らしい
| 英語表現 | 日本語訳 | 用途・ニュアンス |
| expand a folder | フォルダーを展開する | UI操作で中身を表示する（Windowsなど） |
| expand a section | セクションを展開する | 折りたたまれた情報を表示する（WebやPDFなど） |
| expand a compressed file | 圧縮ファイルを展開する | やや技術的。`extract`や`unzip`の方が一般的 |
| expand memory | メモリを拡張する | 容量や機能を広げる意味での「拡張」 |
| expand code snippet | コードスニペットを展開する | 折りたたまれたコードを表示する（IDEなど） |
inflateは専門よりらしい
| 用語 | 日本語訳 | 用途・ニュアンス |
| inflate | 展開・復元する | zlibやgzipなどのライブラリで、圧縮されたデータを元に戻す処理。 |
| deflate | 圧縮する | inflateの対義語。DEFLATEアルゴリズムとしても知られる。 |
（追記）
文書ファイルをアーカイブ化することを昔は「凍結」と呼んでたんだよ
で、アーカイブ化したファイルを変更するために一旦元に戻す行為を、対義語として「解凍」と呼ぶようになって、そちらがそのまま生き残ったが、圧縮するのが当たり前になってからは「凍結」は「圧縮」に置き換わっていった
・英語圏ではアーカイブ化のタームに「凍結・解凍」の概念は用いないらしい（AIさんより）
・それとは別の流れで、unix系osではfreeze/meltというコマンドがあり、これはアーカイブ化ではなく圧縮・解凍（展開）の機能だったらしい。このコマンドは1980年代中盤に登場し、80年代後半から90年代初頭に人気があったらしい（これは確かっぽい）
ただし、freeze のマニュアルには「所有者やパーミッション、タイムスタンプを保持できるのでアーカイブ用途にも使える」といった記述があり、このあたりから「凍結＝保存・保管」というニュアンスで広く捉えられた可能性はあります。
とはいえ、当時も複数ファイルをまとめる作業は tar や cpio の役割で、「凍結」という言葉がアーカイブ全般の俗称だったわけではありません。
・LHAの「凍結・解凍」の由来はアーカイブ化の文脈で用いられていた語の流用か、それともfreeze/meltを意識して採用したのか？（疑問１）
・アーカイブ化の文脈で日本で凍結・解凍の語が使われだしたのはアーカイブの特性からまったく新たに発想されたのか（疑問２）
・そこに（圧縮解凍機能だが）freeze/meltコマンドの影響もあったりしたのか？、その逆もあったのかも？（疑問３）
さらっと調べただけだがなんか深そう！
（追記）
「でもさあ、お前が圧縮してるのって全部オカズばっかだろ？オカズは解凍するから合ってるんだよ」
って返しを思いついたわ。ここにこっそり記すものとする。
俺が社会人始めたのは2000年代初頭くらいなんだけど、その頃ってhtml読み書きできるくらいの人でもめっちゃ尊敬されてた。
つうか、JTCは採用側の人間が無知すぎてhtmlがプログラミング言語かなんかかと思ってたんじゃないかな。
そんとき勤めてた会社の副社長兼IT部門のトップは、全社員にPCとメールアドレスを導入した人だそうで、その実績を買われてそのポジションにいるって言ってた。
コンピュータサイエンスの造詣はほぼなかった。
年功序列だったし。
ホームページ作成代行くらいでIT会社を名乗ってたし、実際そんなんで東証一部上場企業もあったし。
それでいて不思議だったのが、IT全然関係ない部署にも野生のプログラマーみたいなのがけっこうゴロゴロしてた。
仕事サボって遊んでるように見られてたな。
IDEとかなくて、簡素なエディタだけ、人によっちゃメモ帳だけでカタカタやってた。
なんだったんだあの頃は。
俺はSEだ。
とある処理がどうしても動かない。
何かがおかしい。
コンソールにログ出してみる。条件をprintfで確認してみる。
どこを見ても間違ってない。
念のためキャッシュもクリア。IDEも再起動。念押しでOSも再起動。
でもやっぱり動かない。
1時間粘った。
ここまでやって動かないなら、自分の盲点じゃなくて別の要因じゃないか？って疑う頃だ。
これ俺だけじゃ無理かもって思って、隣の席の同僚に声をかけた。
「ちょっと見てくれない？」
「OK、どんな感じ？」
「この処理がね、絶対通らないんだよ。条件も間違ってないし、ログ見ると…」
その瞬間だ。
――通った。
あっさり正常動作。
…は？
え？え？
さっきまで1時間ずっと止まってたよな？何度試してもダメだったよな？
同僚も「普通に動いてるけど？」みたいな顔。
もう一回試す。やっぱり問題ナシ。
「へー、でも今は大丈夫そうだね」
取り残された俺。
1時間の粘りはなんだったんだ。
あの粘りに費やした集中力、あの調査ログ、全て無駄だったのか。
……うん、動くんなら問題ナシ！
2025-2026
・🇺🇸AI Agentの普及が加速するが、期待ほど万能ではない現実が判明（失望が起きる）
・🇺🇸企業のAI導入率が70%を超えるが、多くは限定的な用途に留まる
・🇺🇸マルチモーダルAI（音声・映像・テキスト統合）が本格化し、人との自然な対話が普通に
2026-2027
・🇺🇸オフィスワーカーの5人に1人が業務内容の大幅変更を経験
・🇺🇸予約代行AI
2027-2029
・🇺🇸教育システムがAI前提に大幅変更、従来の暗記型学習が淘汰
・🇺🇸事務仕事の完全AI化が達成される起業が現れる（日本では+2年）
・🇯🇵人口減少とAI導入が同時進行し、労働市場の構造が根本変化
2028-2029
2029-2030
・「AI使えない人」と「AI使いこなす人」の格差が社会問題化
・人間同士の直接コミュニケーション能力が希少価値に
by ChatGPT,Gemini,Claude
私はエンジニアを仕事としておらず, 学部も情報系ではなく理学部である.
今日で会ったWebエンジニアが今の時代１からコードを書く必要がないですよ. Cursor使って指示してやったほうが生産性が高いですよと言われた.
確かにコードを速く書くことができて生産性が上がるかもしれない. だからといって自分でコードを書くのをやめるのはどうなんだろうってもやもやしてしまった.
一歩生産性を落として多くの人が使える形にするのも大切なのではないだろうか. モダンな環境で高速で作ってしまえばそれは確かに楽だ. だが一般の人はWebアプリにアクセスするよりマクロつけたExcelやパワポを使って仕事する方がはるかに楽だ.
業務を効率化できるからといって個人でモダンにサーバーを作ってしまえば属人化して維持するのも大変だ.
エンジニアの生き方としても上手くいかないことをひたすら時間を投資して考えるのも大切なのではないかと思う. 私はArch Linuxで分からないスタックしたを繰り返してみるのも楽しかった. このようなことは非生産的かもしれないが経験としてかなり強く生きてくる有意義な経験だと思う.
今日macの.profileの記述内容について質問されたとき彼にvimかなんか入ってると聞いたが何も知らなかった. 彼はVScodeかcursorしか触ったことがなくIDEとかエディターといった言葉を知らなかった. 彼はすごくモダンだが学習すべきなのかを軽く見ていると感じた. それか私の考え方が古いのだろうか.
最近流行りのAIで何とかしますとか言ってくるコンサルは生産性の向上何とかかんとかとよく言ってくる. だが生産性では変えられない安定性や経験をも大事にしてほしいと私は思う.
あらゆる技術ツールの存在意義は「人間の課題を解決すること」にある。
どれほど理論的に優れていても、使われなければ社会的影響はゼロであり、開発・保守・学習のコストに対するリターンも生まれない。
ツールは道具であり、「賢い者だけが扱える道具」は、実際の現場ではほとんど役に立たない。
例えるなら、戦場において「取り扱い説明書を10回読まないと撃てない銃」は、正確でも美しくても役立たない。
瞬時に理解され、即応可能であることが、実用の第一条件である。
ここで言う「馬鹿にもわかる」とは、知識レベルが高くないユーザーでも直感的に使える・理解できるという意味である。
これはユーザビリティ、学習曲線の緩やかさ、エラー時の挙動の親切さなどに現れる。
この観点からすると、「馬鹿にもわかる」設計は、実は賢い設計である。
人間の認知限界や行動パターンを理解し、誤操作を予防し、意図を汲み取って補完できるシステムは、万人にとって有益であり、結果として普及しやすく、フィードバックループによってさらに改善される。
Haskellは、理論的には極めて美しい言語であり、型システムの厳密さ、関数型の純粋性、抽象化の高さなど、形式的な正しさにおいて群を抜いている。
つまり、Haskellは「形式的正しさを最優先した結果、人間の直感と乖離し、現実世界との接続性が弱まった」道具である。
実際のソフトウェア開発現場では、エンジニアの入れ替わり、ドキュメントの不備、締切、バグ対応など、理想とは程遠い要素が日常的に存在する。
したがって、ツールは「賢い人が完璧に使いこなせば強力」ではなく、「凡人が雑に使っても一定の成果が出る」ことが求められる。
この点で、PythonやBashは「馬鹿にもわかる」ことを最優先し、結果として世界中で圧倒的に使われている。これは単なる偶然ではなく、設計哲学の勝利である。
道具は使われて初めて価値を持つ。そして「馬鹿にもわかる」ことは、使われるための最重要条件である。
Haskellのように理論的に優れていても、「現場に届かない美しさ」は、ツールとしての有用性を損なう。
"現状"とはつまり2025年5月時点の話であり、動向が非常に変わりやすいIT業界の風土を考えると将来的にどのようになるかは予測が非常に難しい。
しかし、数年でこの"現状"が変化するとは考えにくく、今現在の学生が10年以内に社会人となったとき今現在の"現状"を基礎に情報技術を学んでいる可能性が高く、このエントリでは"現状"を周知する為に書かれた。
集計した時期や団体で数値の変動はあるが、日本国内で現状のICT教育でのOSシェアはChromeOSがおおむね30〜40%というシェアを獲得しており、IT大国と知られているアメリカでは日本と同様に集計した時期や団体で数値の変動はあるがおおむね50〜60%というシェアであり、ICT教育のOSとしてChromeOSがデファクトスタンダードとなっている。
これは、テックファンがよく語るように「ChromeOS端末が安価で導入できる」という意見が理由として挙げられがちで、実際に導入コストを抑えられるメリットというのは大きいものの、逆に言うとそれ以外の理由があまり語られることが少ない。
流石にこの意見は、IT業界のプロの現場で多用されるMicrosoftやAppleを抱えるIT先進国である米国がただ安価であるからという理由だけでGoogleのChromeOSを採用するにしてはあまりにも弱すぎる理由ではないだろうか？
そこで「何故ChromeOSを教育現場は採用するのか？」を紐解きたい。
長々と引っ張るのも億劫になってしまうので結論から言えば「Google ClassroomとGoogle Family Linkの出来が非常に良い」からである。
Google ClassroomとはまさにICT教育向けにGoogleから提供されているグループウェアで、生徒へ対して課題の作成と配布、進捗、採点、評価の管理が可能で、それらにはGoogleドキュメントやGoogleスプレッドシート、Googleスライド、Googleカレンダーが利用でき、教師生徒間オンラインコミュニケーションとしてGmailやGoogle Chatを用いることができる。
つまり教育現場からするとChromeOS端末を導入したらGoogle謹製のオールインワンICT教育グループウェアが瞬時に入手可能であり、更に言えば現状では既にデファクトスタンダード化しており膨大な導入事例によって困りごとの解決が非常に容易であることがあまりにも大きなメリットとなっている。
なにせICT教育端末の2台におおよそ1台はChromeOS端末であり、例えばSNSなどで流れてくる「ChromeOSでこんな酷い目に遭った」は導入数が多いが故にであり、逆にiPadOSを支持する人でも「Apple Classroom」というアプリが存在することを知らない場合が多い。何故知らないのか？と言えば導入数が少なく話題にまったく挙がってこないからである。
なお、Apple ClassroomとGoogle Classroomを比較するとGoogle Classroomの方が高機能である。AppleもICT教育OSシェアを上げようとApple Classroomの改善に努めてはいるもののGoogle Classroomへ追いつくまでには至っていない。
Google謹製のペアレンタルコントロールアプリで、子供のGoogleアカウントに紐づけられたChromeOSおよびAndroidOS、それらがインストールされる端末などを管理できるサービス。
端末自体の使用時間上限を定めたり、端末の使用時間上限を定めずアプリ毎の使用時間上限を定められ、つまりゲームやYoutubeやTiktok、Webブラウザアプリなどは1日1時間に制限しつつ、学習アプリは使用時間無制限にでき、そのほかWebフィルタリングやYoutubeフィルタリング、アプリインストール、課金管理も可能で、しかも就寝時間や登校時間には使わせないようにできるなど親にとっては至れり尽くせり子供にとっては非常にお節介なサービスである。
ペアレンタルコントロールの自由度も実はAppleの方が乏しく、Apple製端末を子供に与えている親は親自身が設定したペアレンタルコントロールに親自身が巻き込まれたりして四苦八苦するシーンがある(実体験)が、Google Family LinkのあるChromeOSおよびAndroidOSはApple製端末ほど困ることが少ない。
Google ClassroomとGoogle Family LinkだけではIT大国であるアメリカが何故ChromeOSをICT教育OSとしてデファクトスタンダードとしてしまったのか？の納得感としては薄い。
最終的な決め手は「一般的な使い方ではセキュアなサンドボックス上でタブレットOSやスマホOSのように容易に利用でき、高度なプログラミングを学ぼうとするときプロとほぼ同じ環境を利用できる」ことにあるだろう。
もちろんiPadOSには「Swift Playgrounds」があり高度なプログラミングを体験できるが、ChromeOSやAndroidOSではPlaygroundsどころかLXC/LXD仮想環境上に構築されたLinuxディストリビューションのDebianを扱える。
いやそもそもDebianを導入しなくてもGoogle Play Storeには小学生向けプログラミング環境のScratchからインスパイアされたポケットコード、非常に本格的なゲームプログラミングIDEのGDevelop、UnityやUnreal Engineに次いで業界3位のシェアを持ちプロ現場でも採用される2D/3DゲームプログラミングIDEのGodot Engineなどがある。
そして当たり前のようにGoogleはChrome OS向けAndroid Studioを用意しており、ChromeOSさえあればAndroidOSアプリをGoogle謹製のプログラミング環境で開発することができる(実際のところAndoridOSはAndroidOSだけでアプリをコンパイル＆ビルドできるが割愛)。
これMacとiPhoneやiPadしか触ってこなかった人間からするとどういうことかと言えばChromeOSにはAppleで言うところのXcodeがあることを意味し、何ならDebian上でWeb版みたいに機能制限されていないフル機能のMicrosoft Visual Studio Codeが利用でき、理解できる人は驚いただろうが前述の通りGodot Engineがあるわけだ。RubyやPythonだって動くし、Bashもfishもzshも選び放題、Vim vs. Emacs論争へも参戦できる。
しかも昨今、WindowsのWSL2でLinuxディストリビューションが導入できるようになってしまった影響で、一部の情報技術者の間では「開発環境は仮想上のLinux、サービス動いてるサーバーもLinux、じゃあWindowsとかmacOSとか使わずに最初から無理せずLinuxディストリビューションを端末へインストールして開発したら良いんじゃねーの？」という動きが活発化しており、そこへ表面上は日常利用でスマホやタブレットOSのように扱えて開発はしっかりLinuxディストリビューションであるChromeOSが「あれ？意外とChromeOS良いんじゃね？」という評価が始まっているのだ。
それでも「ICT教育は性能やランニングコスト的にiPadが優れてるんだ！」というAppleファンの熱い想いは否定しない。
しかし、しかしだ、当の多くのプログラマがiPadでプログラミングしてないんだ！！！開発するときにiPadのセキュアすぎるサンドボックスがマジで邪魔だと思っちゃってるんだ！！！！！
前述までの話を聞いて「iPadとChromeOS、仕事でどちらかしか使えません。どっちを選びますか？」と言われたらLXC/LXD仮想環境のあるChromeOSじゃん！！！IT大国のアメリカ様もそりゃChromeOS選ぶよ！！！！！だってプロの現場で使われてるんだもんLinuxがッッッ！！！！！！！
「どっちかしか選べないて？じゃあ俺は普通にMacbookにするわ」だって？えっそれ10年後ChromeOS(Linuxディストリビューション)でICT教育受けてきた新社会人に言えんの？サバンナで生きていけないよ？2人に1人は「学生のときChromeOSでしたぁ」って悪気なくピュアな瞳で言ってくる時代が直ぐそこだよ？
Windowsですら無いんだぞ？隔世の感どころの騒ぎじゃねーぞ？「当時ChromeOSでヴァンパイアサバイバーズやってましたね」とか新社会人が言うんだぞ？iPadかChromeOSかって言われてんのにMacbookって返すのはギャグの段階に触れさえしてねぇよ？まぁMacbookはタッチスクリーンディスプレイじゃないから触れられないんだけどさ。
Apple信者が声を大にして言わなきゃいけないことは「Appleさん、iPadもうちょっと何とかならないっすか？」だろ！！！！！
正論言ってんじゃねーよ！！！今更Appleのエコシステムから抜け出せねぇんだよ！！！！！ちょっと気になってGoogle側の事を調べてみたらめちゃくちゃ進んでんじゃねーか！！！！！！！
えっなにマジで？今のAndroidOSは純正でDebian動くの？？？アプリストアにGodotあるってどういうこと？？？？？
AI のお陰でここ最近のソフトウェア開発が大きく様変わりを見せてきたので、なんとなく今後10年くらいを予想してメモとして残しておこうと思う
AI の導入が上手くいった企業や OSS では、70% くらいのコードが AI 生成に切り替わる
大手 SIer が関わっているような、丁寧なドキュメントが残されている案件では、大規模リプレースの成功率が安定してくる
規模が大きくない Web サイトとかは、90 %くらいが AI 生成になる
WordPress とかだと、100 % AI 生成でデザインとかが出来る場合も
OSS も定型文のようなコードは AI 生成が大半になるが、結局チューニング等の職人芸は、100 % 人の作業のまま
世間の論調として、AI によるコーディングはクオリティが低い云々で AI 利用の考え方が揺り戻しに入る(IDE とかがガンガン AI 生成で補完してくるから、実際のところは 80 % ~ 90 % 位が AI 生成)
AI を利用することが当たり前になってくるので、業界への就職の難易度が 2020年代と比較して跳ね上がる
仕事を奪われたくない人達から、AI 生成を否定する声が活発になる
プレイングマネージャーのようなポジションの人が増える
2020年代後半頃に AI 生成で作られたサービスやサイトのリプレースが活発になる
AI 生成だから何をしているのか分からないものが多くて、リプレースに苦労する企業が増えてくる
世の中の大半のコードは、90 % くらいが AI 生成になる
結局 OSS は職人芸の部分が残るので、スーパープログラマーだけがコードを書き続ける
最近のIDEであればmapだろうと変数の中身を全部確認できるので文に分解しておこうという動機は以前と比べると激減した
業務システムずっとやっているが、静的型信者が言うような型違いを代入してしまうバグや、関数型信者が言うような変数再代入によるバグってあんまり頻繁に出会った記憶がないんだよな。
ちなみに動的型言語も静的型言語も両方実プロジェクトで経験ある（その中間的なキャストだらけのC言語とかも）。
関数型言語は実務では経験なくて、JSやTSに宣言的な書き方が増えてきたのを見てきた程度。
それよりも昔はメモリリークに悩まされたし、昔も今もロジックの間違いやレアな業務の考慮漏れがバグのほとんどという実感がある。
で、それらを防ぐために、シンプルでロジックを追いやすくIDEのデバッガで確認しやすいコーディングスタイルが推奨されるようになる。
そうなると式よりも文が扱いやすく、mapよりもforだし、三項演算子よりもif文だし、メソッドチェーンのようなのもあまり使わなくなる。
静的型の人は、レアな業務が考慮漏れされないように代数データ型として業務を定義しろって言うだろうけど、それはもう全部型ワールドで設計し直すことになるので導入コストが高すぎる。
現状の言語でちょこっと今風の設計を取り入れたらバグが減りますよ、みたいな感じでは全然ない。