  |
はてなキーワード: ソースコードとは
https://anond.hatelabo.jp/20211029215655
Android初期の失敗はここに十分詳しく書かれているので、余計なおまけとしてAndroidとiPhone対立煽りで会話が噛み合わない原因について書く。
AndroidはAndroid Open Source Project、略してAOSPと呼ばれる枠組みで開発されていて、誰でもソースコードをDLして改造することができるようになっている。
メーカによって改造されたAndroidがカーナビやTVやその他のデバイスに搭載されていることは、一般の人でもなんとなく知っていると思う。
ホーム画面には謎のキャラが我が物顔で走り回ることでユーザのタップを阻害し、d〇●・d●○という専門家にしか見分けがつかないアプリがプリプリプリプリ垂れ流されている。
頻繁に鳴る通知は使いもしないアンインストールもできないプリインアプリからのもので、肝心の自分が使っているアプリからの通知はそれに押し流される。
目的も定かではないOSへの改造によってデバイスのリソースは使い切られ、ユーザが使えるのはそのおこぼれでしかない。
そんなザマだからキャリアのAndroidの操作感は悪い。日本人がAndroidを投げ捨ててiPhoneに走るのも当然である。
なぜかといえば、iPhoneという競争相手がいる中で、Androidで金を稼いで飯を食う人たちによって日夜開発されているからである。
当然ながら出来が悪ければ稼ぎは少ない。実際に金を払って使用するエンドユーザではなくどこか壁に貼られたポスターとかを見ているキャリアと違って、彼らはユーザの反応をフィードバックして改善しているのである。使う人のことを考えた使いやすいものを作っているのである。
が繰り返される原因はここにある。
品質が一定水準を超えればあとは好みの問題なのだが、Android絶対否定派は魔改造されたキャリアのAndroidしか知らず、本来のAndroidを知らないのである。
「（キャリアの）Androidはダメ、iPhoneしか選択肢はない」
というのが正しい。
元記事のキャリアをやり玉に挙げたが、3大キャリアはどれもAndroidを「キャリアのAndroid」にしている。
生活費の内訳に通信費が必ず計上されるようになったこの時代において、金を払っているユーザに独自の改造を押し付けることで、日本人をどれだけ消耗させてきたことか。
というか普通に自分で触ればわかるだろ！！？！？！使いづらいんだよ！！！！！！！素のAndroid触ってごめんなさいしろ！！！！！！！！！！！！！！！
Youtubeやアマプラのために6万以上するデバイス買うやつ頭おかしい。Fireでいいやろ。
かく言う自分もipadminiは新しいのを買ったが、目的は以下の通り。
こういうスマホでは代替しにくい用途がメインで、さらにKindleや安いAndroidでは処理が追いつかない用途で使ってて今のところ、満足してる。
アマプラやYouTube見るためなら完全にオーバースペック。
これはiPhone13でも同じ。動画や望遠レンズ活用、暗所撮影をやらないのに、pro買うやつ、養分すぎる。
え？ゲームに使う？
え？バッテリー持ちが？
今日も使われてないソースコードの文脈を読み取りながら、サーバーのバージョンアップで変更される仕様に合わせて動くように書き直す仕事をする
10年以上前に誰かはわからない人よって作られた、既に使われていない処理
これっていつまで保守し続けるんだろう
使わなくなったらさっさとコード削除して欲しいんだけど、なんで削除しないんだろう
削除しないので無駄な作業が発生してるんだけど、会社的には無駄とは思っていないのだろうか
ブルシットジョブだよなぁ
よく考えたら負債を返済すらしてないな、負債が膨らみ続けてついには、利子の返済だけで一杯一杯になってるのが現状である
密結合とか疎結合とか、基本のきだと思ってたけど、何が何に影響を与えてるのかわからないコードの編み目はさながら身体の隅々を侵し尽くすガンといった様相で、それを直すでもなく、場当たり的対処に止まる私もまた、この会社のガンなのかもしれない
悪の帝国 Oracle が Java を有償化し重税を課そうとしたその時、正義の勇者 Amazon が立ち上がり新しい Java 実装 Corretto を無償で広めて救ったのだ！
……という情弱が好きそうなデマがあるんだが、こんな陳腐なシナリオに喜んでいるようではインチキなテック系 YouTuber に食い物にされてしまうぞ☆
Oracle レジスタンスはいた。彼らは Oracle の中に潜んでいたんだ。
時は2005年に遡る。
Java を開発した 米 Sun Microsystems は赤字にあえいでいた。
2004年に Java 5 (目玉機能はジェネリクス) がリリースされてしばらくの頃だ。
この頃、ひとつのオープンソースプロジェクトが立ち上がる。名を Apache Harmony という。
開発は2005年5月に開始され、2006年10月には Apache 財団のトップレベルプロジェクトとなった。
Sun は多数の企業をまきこみ、いろんな企業に Java™ をライセンスしていた。
Java の実装は Sun が持っていたが、各社が独自に実装したり、Sun と契約してコード提供を受けたりしていた。
Java™ を名乗るためには Technology Compatibility Kit (TCK) という互換チェックをパスしなければならない。
初期の Java はオープンソースではなかった。誰もが自由にコードを参照し用いることができるものではなかったんだ。
これをオープンソース化しようという野心で始まったのが Apache Harmony プロジェクトだ。
Java の実装をいちから書き起こしオープンソースの代表的な Apache License Version 2 ライセンスで提供したのだ。
しかし、Sun は Apache2 ライセンスを良しとせず、Harmony に Technology Compatibility Kit (TCK) を受けさせなかった。
なるほど。彼らが Java をオープンソース化したレジスタンスだったわけか？
違う。話はそんなにシンプルではない。
2006年 Sun は Java をオープンソースにする意志があると発表した。
Sun は Java を リンク例外付きの GNU General Public License でオープンソース化することにした。
Harmony のライセンスは自由な改変を認めるものだった。
OpenJDK のライセンスは派生物を作ったなら、そのソースコードの公開義務がある、という点が大きな違いだった。
OpenJDK は出た当初はまだ Sun の JDK との非互換が多かった。しかしこれが現代まで続く OpenJDK の始まりだったのである。
2007年11月 GoogleがAndroidを発表した。 Android は Java 言語で開発することができる。
そのベースとなったのは Sun との火種くすぶる Apache Harmony だった。よりにもよって！
(後にGoogleが負けて賠償し、現在のAndroid は OpenJDK ベース)
その渦中、赤字に喘いでいた Sun はついに身売りを決断する。2009年のことである。
当初 IBM との交渉が報じられていたが金額で折り合わなかったようだ。
そこに颯爽とあらわれたのが Oracle である。 Oracle が Sun Microsystems を買収することになった。
しかし Oracle にはよくない噂がある。敵対買収してプロダクトを潰してしまうという黒い噂だ。
Sun の Java も Oracle に食い物にされてしまうんじゃないか、いわゆる 「悪のOracle」 のイメージはこの頃からのものだ。
しかし、 Sun はすでに Java をオープンソース化していた。 派生物もオープンソースにしなくてはならない OpenJDK で！
Oracle は Java を Sun 社ごと買ったが、 Java はすでに独り占めできるようなものではなかった。
Sun 本家の JDK を引き継いだ Oracle JDK と、OpenJDKがついに統合される。
Oracle がソースコードを OpenJDK に寄贈し、 Oracle JDK も OpenJDK ベースとなった。
ここに OpenJDK への移管は完全となり、Javaのオープン化は成就した。
それまでの OpenJDK は Oracle JDK との非互換が不安視されていたわけだが、Java11 からはその不安もなくなった。
こうして完全にオープン化された Java は、各サードパーティーからディストリビューションが出るようになった。
Java11 での Java のオープン化を経て、Javaはディストリビューション乱立時代へと突入する。
Amazon Corretto もそうした OpenJDK の派生ディストリビューションのひとつである。
OpenJDK の開発は今なお Oracle が主力となって牽引している。
Java を解放しようとしたレジスタンスは、赤字に喘いでいたSunの中にいた。
たとえ Sun が身売りをすることになろうとも、Java を邪悪な独裁者の手に渡さないように。
Sun が倒れてしまう前に Java はオープン化された。Javaの仕様策定は Java Community Process (JCP) にて行われる。
Javaの仕様策定は Oracle の独断で進めることはできない。 OpenJDK の開発も Oracle の独断ですることができない。
GNU General Public License でオープンソース化された Java は、派生物のライセンスもGPLが強制されソースコードを公開しなければならない。
そんな OpenJDK をリリースした、当時の Sun の中の人達こそがレジスタンスだったんだ。
Oracle はそんな Java を、そういう存在だと分かって Sun ごと買った。
Kinzaのパッチが当たった正式版が公開されたので、引き続きこき下ろす。
この間 https://anond.hatelabo.jp/20210828113740 を書いたが、DuckDuckGo経由で無事作者に見つかってしまったらしく、ここで指摘を入れた誤字、インストール場所、公開ソースコードのREADMEが全てではないが直ってた。ここ以外にもアンチがそれなりにいるみたいで、作者のTwitterを見る限りメンタルが削られていたようだ。(あれだけTwitterでアンチコメントがあったのを知ってたのに、中途半端な覚悟でエゴサしたからじゃないの？と言いたいが)
アンチがあんなにいるのは人気がある証拠ではないか。もっといろんな人に知ってもらうまたとないチャンスだ。
誤解しないでほしいのは、こき下ろしているのは学生の合間に作った革新的で軽量なブラウザーが自称ではなく価値あるブラウザになることも期待しているからである。ブラウザ作る奴なんてほとんどいないから。
以前利用規約での遊びがひどすぎてふざけてんのかと書いたせいかは知らないが、アップグレードはちゃんとアップロードになっている、個人の感想がなくなっているなど、おふざけはなくなった。しかし、利用規約が以前と比べて長すぎる文章になってしまっている。しかも利用規約に書くべきではない内容はそのままどころか増えているし、もう少し整理できたのでは？
以前、「Ablazeの利用規約に沿って」という文に対してAblazeの利用規約をここに載せろと言ったが、掲載されたのはその利用規約ではなくプライバシーポリシーだった。「Ablazeの利用規約」は「Albazeのプライバシーポリシー」のことなのか？「Ablazeの利用規約」はホームページにも掲載されていないので、結局の所それに何が書かれているのかわからない。何が書かれているかわからない「Ablazeの利用規約」に同意しようがないので、この利用規約に真面目に従えばAblazeの関係者と同団体に盲信する人を除いてFloorpブラウザは規約上誰も使えない代物である。どうせ誰も見ないでスルーして使っているだろうが、きっちり書くべきところがきっちりできていないのは問題である。
所々「書いとけばいいんでしょ」感が出てしまっていて、ただでさえ読まれない利用規約をさらに読む気のしないものになっている。ここまで長くなったのなら、規約本文の見直しをした上でその中にあるプライバシーポリシーを分けた方が良くないか？工夫・配慮が足りない。リリース予定日に追われて、利用規約に割く時間がなかったのだろう。
それにしても、あれだけ長くなってもChromiumのライセンス情報が未だに書かれていないのはどういうことだろうか。著作権表示と許諾表示をドキュメントに書くことが条件になっているので、「BSDライセンスに従って」という書き方ではダメ。その表記で済ませるなら、ドキュメントファイルとかURLとかを明記しないと。Kinzaのパッチのことよりも憂慮するべきことではないのか(これも結構長いのでChromiumと同じようにすればよいのでは？)。
Kinzaのパッチをそのまま当てられるようにしたことで、バージョンがDevチャネル相当の95から89に大幅ダウン。Kinzaのパッチが公開されてからわずか2週間でリリースできたのはこれが理由だろう。Kinzaの言ってるとおり古いバージョンのままでは危険で、常用は避けるべきである。
ちなみに、https://developers-jp.googleblog.com/2021/04/chrome.htmlの通り、Chrome94からメジャーバージョンアップの頻度が6週間から4週間になるらしいが、メジャーバージョンアップについて来られるのかが疑問である。メジャーバージョンアップした正式版に期待が寄せられると思ったが・・・(次節に続く)
というツイートが。あれ？このブラウザって「Kinza派生系ブラウザ」だよね？たった1年ちょっとで終わりなの？
Chromiumのメジャーバージョンアップにかかる手間のことを全く考えていなかったようだ。Kinzaが終了した理由に開発継続に対するコストの問題があるって書いてあったのに。その意味が理解できていなかったのか。2022年まではやると言っているようだが、パッチ適用時のエラー量が多すぎて挫折しているのではないか？本業が学生なんだし、本業を優先するゆえにKinzaの後釜になれないのも仕方のないことだろう。というより、ブラウザ開発は本業と両立できるほど甘くないのでは？
2022年までの理由は、受験を控えているかららしい。受験は作者の人生を左右する大事なことなのでしょうがない面もあるが、Ablazeという非営利団体(?)にはそれをカバーする人が今はいないということも言える。要するに、2022年を過ぎるとメンテナンスする人が誰もいないことになる。早くもFloorpの将来性が危うい。
Fireminによる見せかけのメモリ使用量しか見ていないのは相変わらずのようで、大変残念。あれだけこき下ろしたのに懲りないね。
以前
なんて書いたら某動画で「変なこと言ってる」と言われたが、その動画でもやっぱりWindowsタスクマネージャーの一部分しか見てなくてお前もかよ。恥ずかしい人は作者だけじゃなかったわけだ。まあ仕方ないよ。Floorp軽い！って先に体感してしまってろくに検証せずそれで終わりにしたんだから。
たしかにメモリ圧縮の効果はあるからメモリ不足気味な低スペックPCなら有効かもしれない。けどな、Fireminを他のブラウザでも有効にしたら同じ効果が得られるぞ。ChromeなんかもWindowsタスクマネージャーのメモリの所を見たら数MBになるから。実際そこまで減らないけどな。
某落書きに書いてある
は全くその通り。そう思い込む奴が出てきた一因はこの間裁判に負けたギガなんとかが記事を書いたせい。あと前に言い忘れたけど、ページアウトするってことは、ページファイルへの書き込み頻度が上がってディスクの寿命を縮めるからメモリに余裕がある人はFireminは止めとけとだけ言っておく。
FloorpにはFFmpegのH.264とAACのデコーダが入っているが、それらは特許技術で保護されている。特許の入ったコードをバイナリで配布することに関して、FFmpegは特許侵害の責任は一切持たない方針をとっているので、一部の例外を除いて特許のライセンスを管理しているMPEG LAやVia Licensingとライセンス契約を結ばなければ特許侵害になる。
非商用ならライセンス料がかからないが、個人もしくは非営利団体だからライセンス料がかからないとは限らない。広告収入を得ている場合は非商用と見なされない可能性がある。将来ライセンス管理会社からライセンス料を請求される、最悪の場合特許侵害で裁判沙汰になるので覚悟しよう。ちなみにこれがKinzaが当初はH.264とAAC(と当時はまだ特許が有効だったMP3)の再生ができなかった理由であり、独自実装となった理由である。
以前言ったことが直ったものもあるが直ってないのもいくつかあって、特にhttps://github.com/Ablaze-MIRAI/Floorp-Browserの一文
が象徴的。「大部分の」は直ったが、どうやら「一番軽量」は直す気がないらしい。その誇大広告を直す気が無いのなら、なぜ一番軽量と言い切れるのか証拠を出しましょう。まさかあのメモリカスタマイザーが同梱してるからどの派生ブラウザよりも軽いんだよ、とか言い放つ気ではないだろうな？他のブラウザにFireminを入れてもなお軽いことを示してみてね。頑張って♪
Chromium派生ブラウザを初めてインストールした時に軽いとかほざく奴がいるけど、あれ何も入ってないまっさらな状態のせいだからな。履歴とかクッキーとかキャッシュとかがたまりにたまったブラウザと比べるから軽いって錯覚するだけで、地道なChromiumのコード改造とかしない限りメモリの使い方もパフォーマンスもほとんど同じ。改造以外に差があるとしたらビルドの仕方ぐらい。比べるのはプロファイルを全部コピーして同じにしてからだ。
Floorpは他のブラウザに拡張機能をインストールする！！危険！！！
って意見を持つ必要はありません。FloorpはChromeウェブストアの審査を通過した場合のみ、その機能を採用します。Googleの厳しい審査を受けている為、安全です
というTwitterの発言。大事なことを忘れている。Chromeウェブストア経由でインストールするのはGoogleの審査があるという意味では安全だが、ストア外からのインストールが安全とは言ってない。審査の通ったファイルが変化なくFloorpに入っている保証ができるのか？Floorpを信用するならインストールすればいいと思う。ソフトウェアに署名がないから改ざんされてないかが検証できないけどな。サーバーが乗っ取られて偽ファイルをダウンロードされるような事態を想定できている？何のためにストア外の拡張機能のインストールに管理者権限が必要になったか理由わかってる？
まあ学生が作ったブラウザを信頼するかしないかの問題だな。どうなっても誰も責任は取ってくれない。
今の段階だと、Chromiumのバージョンが古くてセキュリティが怪しいFloorpをわざわざ入れるまでもないんじゃないのか？FloorpSyncというxBrowserSyncベースのブラウザ同期の機能はxBrowserSync拡張機能さえ入れればどのブラウザでも使えるし、そんなに(見せかけの)メモリ使用量削減効果を見たいならFireminを入れればよいわけだし。
FloorpSyncはxBrowserSyncから名前変えただけじゃないの？まあ日本語対応はブラウザの作者がやったらしくそのことは評価できるが、Floorp自体はまだこれといった特徴がない。特徴がないのは開発が始まったばかりで仕方のないことだが、Kinzaのパッチを適用した後どうするかが特になく、将来どうしたいのかがよくわからない。挙げ句の果てにKinza派生系は2022年までという期限が付いてるし。
まあめんどくさがりにはいいんじゃない？同期やらメモリ節約やらを勝手に入れてくれるんだから。
何で批判多いのか自覚がないのは痛い。そういう厚かましさと根拠のない自信がアンチを生んでるんじゃないのか。もうエゴサしてないらしいからこれを見ることはもうないだろうがな。これを書いた屑なアンチを乗り越えてこそ本物だから。メンタル崩壊してる暇はない。しっかりしろ。
オープンソースソフトウェアの名前を変えて、それらを寄せ集めただけのブラウザで終わるのか、このブラウザならではの特徴を持ったブラウザに成長するかは作者次第。今のところは前者で開発終了になるのが目に見えている。いろいろな人から期待されている割には軽い気持ちで作っているように見受けられ、ブラウザ開発の覚悟が足りていない。
Floorp ウェブブラウザと名乗るブラウザが最近出てきて、開発が終了したKinzaのパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人は学生(中学生？高校生？)らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。
このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。
※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである。
---------------------------------------------------------------------------------------------------------------------------------------------
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう
8.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
---------------------------------------------------------------------------------------------------------------------------------------------
利用したオープンソースソフトウェア
[※以下略]
さて、どこから突っ込もうか。
---------------------------------------------------------------------------------------------------------------------------------------------
あああああああああああああああああああああああああああああああ開発つかれた
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう？癒してください！彼女ください（）
8.Floorpは有志によって無料で提供されています。寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください
9.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
[※以下略]
利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約の最後に・彼女になることに同意しますか？って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。
Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。
というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの？
あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、
という文は誤解を生むから今すぐ止めろ。これだとBSDライセンスに違反するぜ！と宣言してるような解釈もできるから。利用規約でOSSに感謝しましょうとか言っておいてこの扱いひどくないか？
このブラウザの自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。
ブラウザをインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザのメモリ使用量が劇的に減ってるから軽い、ということらしい。
しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザのタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか？
メモリカスタマイザーの正体はFireminである。名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的に対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeのトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。
結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術的アピールができるし)。Floorpブラウザの作者はWindowsのタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である。
500ms単位でメモリ節約機能が動作するせいで、Speedometer 2.0のベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。
Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリを使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能がインストールされたという通知が表示されるようになってしまう。
Cドライブ直下にフォルダー作ってそこに入れるとか、いつの時代のソフトだよ。Program Filesに入れてやれよ。
https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp
https://twitter.com/surapunoyousei/status/1431961462734352385
作者から依頼されて書かれた記事に客観的な証明なんてどうやってするんだろうね。
まあKinzaのパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。
Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん。個人で開発してるのか寄り集まって開発してるのかもよくわからん。
中の人のTwitterで中学生と書かれていたことがあったので、高校生ではないかもしれない。高校生の表記から「学生(中学生？高校生？)」に変更した。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
ゲーム業界でプログラマーとしてやっている身から考えを書いてみる。
「私のフォロワーの方にはクリエイターやゲーム関係の方がたくさんいらっしゃると思います。皆様の意見を聞かせていただきたいです。」
https://twitter.com/gamemakerdiary/status/1413185724849954817
ゲーム会社の経理や人事でも、好きなゲームに関わっているということで満足する人もいる。
小規模なゲームをひとりで全部作りたいのか、中規模以上のゲームのどこかを担当したいのかくらいは考えておくべき。
次は専門職。シナリオ、グラフィック、作曲といった専門の教育を受けてないと手も足も出ない分野。
これも解像度を上げると、コンセプトアート、キャラデザイン、ムービー、モデリング、ライティング、UIデザイン、録音、効果音などなど無数に分類される。
ゲーム会社、特にコンシューマゲームのプログラマーとしてやっていくなら、学生時代に身につけている言語や環境よりも、「大規模なものや複雑なものを怖れず学ぶ」資質が大事だと個人的には思っている。
ゲーム開発は、ゲームエンジンやフレームワーク、ライブラリ、APIを多用する。それもネットで検索してもまったく情報がない独自のものだったりする。
そもそもゲーム機はOS自体が普通と違うし。ビルドに使用するツールチェーンもかなり複雑になっていることが多い。
簡単な例でいうと、Visual Studioよりもテキストエディタの方がシンプルで使いやすいと思うタイプは要注意だ。
複雑でも多くの人に支持されているツールは何か良いことがあるはず、と思ってVisual Studioを使いこなす気持ちを持とう。
学生時代の作品もProcessingなどではなくC++で書くべきとか言われるのもこの辺に通ずる。
あとプログラミングに自信がある人で、既存のライブラリは複雑で使いにくいからとオレオレライブラリを作ってしまう人も要注意。
実は俺もそういうタイプなので苦労した。
ゲーム開発は複雑なものをそのまま使わなくてはならない日がいつか必ず来る。
既存の複雑なものを使う能力と言うのは、つまり大量の（英語を含む）ドキュメントを読む能力、大量のソースコードを読む能力でもある。
シンプルで洗練されたコードも素晴らしいが、洗練されたコードをめちゃくちゃ時間かけて書く人よりも
多少いまいちでも手が止まらず書き続けられる能力がある人の方がまわりには多い。
そういう人は、いまいちなコードに何度も手を加えて最終的にはまともなコードにしてしまったりする。
ゲーム全般やゲーム開発に関する知識量は、プログラマーとしても最大の武器だ。
有名なタイトルがどういう特徴を持ったゲームなのか広く知るのには膨大な時間がかかる。ゲーム好きでそのあたりに詳しいだけでも強い。
Unityなどのゲームエンジンに触ったことがある、というのもスキルというより知識の武器という意味合いが強い。
入門書レベルではなく、UniRxとかのプログラムの書き方の根本からくつがえるようなライブラリ経験とか、Unreal Engineのソースコードをいじったことがあるとかレベルなら超強い。
大学のゲームサークルやインディゲーム開発のグループで経験がある人はここが強いように思う。グローバルゲームジャム参加経験者とかも。
それから、ここが一番言いたかった点なのだが、前述の専門職とまたがる知識のあるプログラマーはめちゃくちゃ重宝される。
グラフィックならシェーダーがめちゃくちゃ書けるとか、3DデータやIKを扱った経験があるとか、3Dベクトルや行列演算の数学が得意だとか。MayaやBlenderを使った経験があるだけでも強い。
サウンドならDAWや波形編集ソフトを普段から触っているとか、信号処理に詳しい人。
つまりデザイナーやモデラーや音楽家の気持ちがわかって、その人たちと専門用語で話ができるプログラマーはどこでも食っていける。
あと最近はAIに強い学生もゲーム会社は積極的に採用している。
ひとつの専門知識＋プログラミング能力を身につけるのはわりとおすすめの戦略だ。ゲーム開発の全部に詳しい必要は必ずしもない。
CEDECなどのカンファレンスに参加して、どういう知識体系があるのか知って、自分の強みを考えよう。
ゲーム開発用の自社ツール制作や、プロモーション用Webサイト制作など、ゲーム本体以外のプログラミングも多いので、
仕事の指示をうけるときも「この処理が似たようなことをやってるから、コピーしてそれをもとにやって」みたいな感じ。
ぐちゃぐちゃのコードを追いかけて、内容を理解して、それを改変するのが大変だったわ。
あるとき、その現場の古いソースコードを見つけてみてみたら、それは、きっちり書かれたきれいなコードだったわ。
最初のころは、できる人がきっちり書いてたけど、その後コピペプログラマが内容を理解もせずに「コピペして改変」を何世代も繰り返してるうちに、こういうぐちゃぐちゃのコードになったんだって歴史を見た気になった。
結論から言えば、やはりソフトウェアエンジニアが一番向いているんじゃないですか。
鼻持ちならない気位が高いわりにざっくばらんな文章を書くなぁと感じますが、
等身大の自分を見て人々がどう思うのか率直な意見が欲しくて意図的にやっているんですよね？
出来るソフトウェアエンジニアには内面がこんな調子の人は多いのではないのでしょうか。
挫折についても、単に運がわるかっただけじゃないですかね。
簡単なタスクはあっという間に終わらせてしまうし、かといって難しいタスクだとあなたが分からなかったときに上司の側が教えることが出来ない。
あなたにタスクを振る上司は、あなたより優れたソフトウェアエンジニアであって、振るタスクのことを十分に理解していないといけないし、あなたの限界をきちんと見定めていなければならない。
インターンだとどうしても日常業務から外れた、〆切りがなく失敗してもダメージのないタスクを与えることになるので、お互い不幸な結果になってしまうことはあります。あなたには悪気はなく、十分努力はしたと思いますし、会社や上司も悪気があってしたのではないでしょう。まぁそういうことはあります。
まともな会社、まともな部門、まともな上司にあたればもうちょっと丁寧に導いてくれると思いますし、日本で10人みたいな仕事はそうはありません。あなたくらいのレベルだと、おそらく仕事は自然言語で書かれているが穴だらけの仕様書と、コメントのあまりない微妙だがそこそこの規模ソースコードを渡されて、不明な点を関係者（誰に聞けばいいかは必ずしも自明ではない）に聞いて埋めながら実装する、とかになると思っていて、多分それは出来るんじゃないですか？名前の出ている会社だともうちょっと丁寧な扱いをしてもらえると思うので、エンジニアインターンをやって自身を回復させるとよいでしょう。
別言語への書き換え、任せてさっとやってくれて、セキュリティなど聞くべき所を聞いてくれる人ってそんなにほいほいいるものじゃないですよ。がんばってください、いつか一緒に働けることを楽しみにしています。
結論から言えば、やはりソフトウェアエンジニアが一番向いているんじゃないですか。
鼻持ちならない気位が高いわりにざっくばらんな文章を書くなぁと感じますが、
等身大の自分を見て人々がどう思うのか率直な意見が欲しくて意図的にやっているんですよね？
出来るソフトウェアエンジニアには内面がこんな調子の人は多いのではないのでしょうか。
挫折についても、単に運がわるかっただけじゃないですかね。
簡単なタスクはあっという間に終わらせてしまうし、かといって難しいタスクだとあなたが分からなかったときに上司の側が教えることが出来ない。
あなたにタスクを振る上司は、あなたより優れたソフトウェアエンジニアであって、振るタスクのことを十分に理解していないといけないし、あなたの限界をきちんと見定めていなければならない。
インターンだとどうしても日常業務から外れた、〆切りがなく失敗してもダメージのないタスクを与えることになるので、お互い不幸な結果になってしまうことはあります。あなたには悪気はなく、十分努力はしたと思いますし、会社や上司も悪気があってしたのではないでしょう。まぁそういうことはあります。
まともな会社、まともな部門、まともな上司にあたればもうちょっと丁寧に導いてくれると思いますし、日本で10人みたいな仕事はそうはありません。あなたくらいのレベルだと、おそらく仕事は自然言語で書かれているが穴だらけの仕様書と、コメントのあまりない微妙だがそこそこの規模ソースコードを渡されて、不明な点を関係者（誰に聞けばいいかは必ずしも自明ではない）に聞いて埋めながら実装する、とかになると思っていて、多分それは出来るんじゃないですか？名前の出ている会社だともうちょっと丁寧な扱いをしてもらえると思うので、エンジニアインターンをやって自身を回復させるとよいでしょう。
別言語への書き換え、任せてさっとやってくれて、セキュリティなど聞くべき所を聞いてくれる人ってそんなにほいほいいるものじゃないですよ。がんばってください、いつか一緒に働けることを楽しみにしています。
原文: https://icfpcontest2021.github.io/rules.html
------
本コンテストは、オープンコンテストです。ICFP2021コンテスト主催者を除き、どなたでもICFP2021プログラミングコンテストに参加できます。
出場者は、自由にチームを編成することができます。出場者は、1つのチームにのみ所属することができます。コンテスト開始後にチームを分割、合併、共同作業することはできません。
チームは、コンテスト期間中に登録を行い、認証情報を取得する必要があります。コンテスト中に2つ以上の認証情報を使用したチームは失格となります。
賞品の獲得を希望するチームは、コンテスト終了時にソースコードを提出しなければなりません。コンテストへの応募に関する詳細は、コンテストの開始時に発表されます。コンテスト期間中、チームは複数回応募することができます。初期の応募作品はコンテスト期間中にライブランキングとして評価されることがありますが、賞品の検討対象となるのは、ライトニング部門およびコンテスト全体の最後の応募作品のみです。
主催者は、参加者およびチームの提出物、その他のコンテスト関連活動、またはその欠如を監視、記録、および調査する権利を有する。記録は審査のみを目的として使用され、コンテスト関連のイベントが終了すると破棄されます。
コンテスト参加者は、コンテスト用サーバーへの攻撃を試みないようにお願いします。これは、他のチームや主催者の楽しみを奪うことになります。これらのルールに違反したり、コンテストのインフラの完全性を損なわせようとしたり、他の出場者を妨害しようとしたり、チーム間で結託したり、コンテストの精神に反する行為を行った場合、関係する出場者やチームは失格となります。
応募者は、応募前に保有していた応募ソリューション、ソースコード、カスタムツール、および関連資料（以下、「応募作品」といいます）に関するすべての知的財産権を保有しています。提出の条件として、応募者は主催者に対し、提出物の使用、複製、公開、配布、公の場での上演および公の場での展示に関する非独占的、恒久的、取消不能、全世界的、無償のライセンスを付与し、主催者が本コンテストの目的のために提出物をテストおよび評価することを許可するものとします。