  |
はてなキーワード: ソースコードとは
何ていうのかな
コードを他人に見せる前提で書くというサービス精神が足りていないんだと思うんだよ
エンジニアってBtoCやBtoBサービスに関わってること多いけど、大概サービスのことには疎いじゃん？
アイディアの一つも出せない人が多い
分かりやすく工夫してあげようなんていうような思考や才能から程遠いところに居るからだと思うんだよ
ソースコードを見やすく保つにも、そういったサービス精神が何より重要になる
でもそういうのってコミュニケーション能力に近いスキルだから、エンジニアの性質として、疎くて当たり前といえば当たり前なんだよね
エンジニアは読み手に回るときは分かりづらい、読みづらいと言うけれど
ただ、これは逆のことも言えて
読みやすいコードを書ける人って、読み手の事を汲んであげられるような人だから、エンジニア以外の仕事でも出世するタイプだと思うんだよね
そしてこういうスキルは、ある程度訓練もできる
まずは今書いているコードを、きっと自分以外の誰かが読むと思って
サービス精神をもってして読みやすく保つことが大事なのではないか？
ちなみに、ブログを書いてみるというのも良い訓練になると思う
そいう叩き方をしていた人も居たけれど、一番は実行速度なんだよ。
クソ重いコードにサーバのリソースを占有されたら、誰だって迷惑だと思うだろ。
そこでFacebook社が開発したのが、HipHop Virtual Machine(HHVM)
こいつは、事前にPHPを中間コードに変換してから実行するので、.NETやJava並みに速く動く。
HHVMが公開されたのが2011年で、実用的に使われだしたのは2012年のアップデート以降かな。
2016年にはPHP7がリリースされて、これはHHVM並みの速さでPHPが動くようになった。
PHP自体の改良が進むことで、PHPも他言語並みの速さで動くってことになったのであまり叩かれなくなった。
Laravelみたいなフレームワークも世界的に使われだして、ソースコードの書き方も他言語と大差なくなってきたのもあるとは思う。
仮にも一部上場企業のプログラマやってるんだけど、属人化が凄まじいんだよね
仕様を決めないくせに文句ばっかり言ってくる上司に嫌気が指したから退職を切り出そうと思うんだけど、さてどの程度の引き止めが来るんだろうか
取り敢えず役職持ちなのに入社2年目の社員より基本給が低いってイカれてるよね
自分がいなくなっても一時的に機能不全になるだけで会社はちゃんと回るだろうけど、
31歳、WEB博物館の学芸員。大学の専攻はソフトウェア考古学。
行ったことのない人のために説明しておくと、WEB博物館はWEB150年周年を記念して設立された博物館で、WEBの歴史を振り返るとともに
各時代のサイトのデザインやインタラクションを体験できる日本唯一の博物館。古くは平面ディスプレイでのWEBページから、主流の空間型3次元MRの流れを体験できることが売りなんだけど、
まだ2010年~2020年代の展示が用意できていない。暫定的に、展示パネルでスクリーンショットを展示している。
この展示の担当者は俺。正直な所、ちゃんとした展示が開始できる見込みは立っていない。というのも、ソースコードはあるけれど、当時の技術背景がはっきりしないため、サイトを動かすことが全くできないためだ。
今時、平面ディスプレイなんて骨董品屋に行かないとお目にかかれないが、なぜか自宅の地下に眠っていた。
りんごのマークが描かれた物理キーボード搭載の、所謂ノートパソコンってやつ。金属ボディでかつ核シェルターに入ってたので、核戦争の時のEMPにやられずにかろうじて残っていたみたい。これを高校生の時に見つけて以来、徐々に二次元派になっていった。レトロPCマニアという区分の人間だ。
当時のソフトウェアを発掘、解析していくうちに、古い技術のソースコードを集めるのが趣味となり、大学ではソフトウェア考古学を専攻した。
大学時代にやってたことは、未処理地区に入ってストレージを発掘、残っている当時のソフトウェアを解析、当時のものを修復・復元などだ。
ここでは研究員がそれぞれの時代のWEB技術で作られた製作物を復元するプロジェクトに携わっていた。
で、俺の担当が暗黒の時代と言われた2010年~2020年代だった。
ソースコードは、骨董家から譲ってもらった。当時のサーバーやクラウドサービスは核戦争でほぼデータ消失しており、100年以上前のソースコードなんて絶望的だったが、ある企業が当時の中国のハッカー集団に抜かれたソースコードを保存していたストレージがたまたま現存していた。
開発に使われたJavaScriptという言語は、AIの解析によってバージョンが判明し、なんとか仕様が分かった。大学で近代プログラミング言語史の授業を取っておいてよかった。
とにかく、この時代はフロントエンドの開発環境の移り変わりが激しく、それぞれのパッケージが使われていた期間がとても短く、バージョンも多様に渡ることから、正解のパッケージが現存していない。
この時代は、まだIT教育がほとんどされていなかった時代でもあり、ソフトウェアエンジニアはほとんど独学で技術を身につけるのが普通で、そのためソフトウェアに対する価値観が多様であった。どんどん新しいパッケージが開発、公開され、そのため開発環境の移り変わりはとても激しく、特にフロントエンドは1~2年でガラリと変わっていたようだ。
すると、1~2年しか使われなかったパッケージなんて入っているピンポイントな生存ストレージなんか見つかるはずもなく、全然開発環境の復元が進まない。
別バージョンのパッケージが見つかることもたまにはあるので、それで代用を試みるけど、エラー文が多すぎてほとんど使えない。
当時の人は、やたら保守性にこだわっていたみたいだけど、こんなバージョン地獄でうまくやっていたのだろうか。
好きなことを仕事にしたいと思い、Web開発の職種を希望し、これまでに複数社受けました。
就職活動を初めた頃は、技術力が足りないが、明るくて人当たりが良いため、営業なら採用できる。などと内定を頂いていましたが、エンジニア枠では無かったためお断りしていました。
それが悔しく、自分なりにプログラミングの勉強を続けました。ソースコードのアウトプットも増やし、本も今まで以上に読みました。
それからは、就職活動で技術力の低さを指摘されることは無くなりました。それだけではなく、Githubのソースコードだけで、技術試験パスもありました。
プログラミングを学べば、エンジニアになれると思っていました。
僕はエンジニアになりたいのに、なれません。この業界は人手不足だと言われてますが、僕はいらない。
どうすればエンジニアになれるのかわかりません。
2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。
そうしたらとんでもないことになっていた。
結論から言えばあからさまに怪しいデベロッパーが二次配布のソースコードを使って
itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8
www.gatobros.com/
play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween
www.pipletas.com/syobon/syobon.html
デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。
で、サポートURLのページをよく見るとOpenSource扱いになっていた
Original Source. Ported by @jezng using Emscripten.
sourceforge.net/projects/opensyobon/
Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeにアップロードしたようだ。
sourceforge.net/u/twoscomplement/profile/
で、SourceForgeのプロジェクト開設日が下記のとおりになっているが
Registered 2010-05-16
原作者のサイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの。
wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html
このSourceForgeのプロジェクト、再配布人が下記のライセンスで公開している。
www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると
としている。
SourceForgeに公開されているプロジェクトがGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。
が、まずこれ色々と問題がある
プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。
dxlib.o.oo7.jp/dxlicense.html より引用する。
<<ＤＸライブラリのライブラリファイルやソースコードの再配布について>>
ＤＸライブラリのライブラリファイル( 拡張子が lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず
クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz
なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか？
（配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。）
なお、実行ファイル形式で配布されている物の英語のReadMeには原作者のクレジットなし。
どうやらゲームファイルとソースコードが転載されたようだが、少々違和感がある。
Internet Archive内にあるソースコードとSourceForge内のソースコードが違う。
tiku氏のそのまま配布するなを遵守したのだろうか？ （配布されているソースコードには日本語が混じっているので非常に怪しいけど）
ただ、言えることはしょぼんのアクションがスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。
ここまで書いておいてなんなんだけど飽きた。
共働きなんだ、うちは。
嫁の勤務している会社は経営的にだいぶ厳しい状況で、結構前から転職を勧めていたんだけど、どうにも腰が重く
ズルズルしてたら、本格的に経営が危ういとこまできてるよう。なんでもバックオフィス系の人間が続々辞めてると。
いまや家計を共にする訳なので、転職はうまく行って欲しいと思ってる。
で、「履歴書レビューすっか、みせてみ？」って言ったら、なぜか全力拒否、「恥ずかしいからイヤ」とか。
もうね、(ﾟДﾟ)ﾊｧ?って感じ。
「企画書でも要件定義でもソースコードでも履歴書でも職務経歴書でも、レビュー重ねれば品質あがるでしょうに、転職成功の確率を上げる方法だよ？」
と言っても全く聞かない。俺、一応管理職だし面談経験それなりにあるから、対策や対案は出せると思うのね。
kickstarterのAndroidアプリのソースコードが公開されている。
https://github.com/kickstarter/android-oss
特色すべきは、まだGooglePlayStoreに公開前だということ。
主に雑誌からのコピペ作業で月５００万PVのサイトを個人で運営している人。個人が運営するメディアではたぶん日本でもトップクラスのPVでためになる話でも聞けるのかと思ったらびっくりするぐらい何も得るものがなかった。
もともとその業界はWEBではブルーオーシャンで雑誌の情報をそのままコピペしてアクセスを集めるのが黙認されてる状態。２ちゃんねるは規制がはいっているが規制がはいっていない２ちゃんねるまとめさいとのようなもの。
アフィリエイターはプログラマーでもライターでもないので期待して会いに行ったわけではないのだがそれにしてもインターネット上の月５００万PVのイメージを持っていったものだから少々がっかりした。どんなソースコードがSEOに良いのか聞いたりしたのだがテンプレートを借りてやっているのでよくわからないと言われた。
ネット上では人格者のように見える。切って貼って良い人格を演じているだけの実像はまるで大学２年生のように無垢で無能だがただたまたま開設したサイトが当たってしまった幸運な青年だった。聞いてみると大学の時から当該サイトで荒稼ぎしているので就職したことがないらしい。
だからどうだという話でもないのだが廃れることが確定している業界で不幸にもブルーオーシャンで泳いでいる無能な青年がすこし心配になった。
某検索エンジン大手は、検索エンジンの結果をアドセンスのクライアントのために操作することはない。
正確に言うとヒルズの奴らはやりたくてもマウンテンビューのやつらが邪悪になるなと言って許さないし、システム的にもわざわざやることが難しい。
それでも数字をあげたいヒルズの営業部隊は、日本語特有の文化として、まとめサイトみたいなのが必要だと訴えてみたり、
日本語に関わる開発はヒルズでも一部主導権を持ってるので、そのようなサイトを優遇していくことでクライアントの広告収入が結果的に増えることに気がついた。
他のやり方としては、HTML5に準拠したソースコードのページを優遇することで、老朽化した個人サイトを突き落として大手を優遇することに成功した。
その大手はつまり最新のアドセンス改定についてけるような開発体制がある会社ということ。
まあ、その結果どうなったかは皆さまご存知だろう。
もう１つ言うと、ヒルズの日本法人はマウンテンビューと組織が完全に別なわけではなく本社と人の行き来はかなりある。
その点はヤフーとか他の外資とは異なる。それでも日本法人のやつらはKPI求めるタイプの人間ばかりになってしまって本社ほど心に余裕がない人が多い。
それに日本法人は今回炎上した会社と恐ろしいほど社風が似ている上にコンプライアンス守る気もあまりないが、
某社と違って自分たちが圧倒的なブランドでグレーゾーンを押し切っても逃げ切れることをよく理解してる。
それにいざ、取引先が炎上しても自分たちは安全な場所に居続けることが出来ることも自覚してる。
今回も一連の事件を受けて我々は検索アルゴリズムの改良提案をしましたとか日本法人のブログでさらっと書いて第三者風にして逃げる方針。
だそうです。
私が入社する前に職場の先輩がリーダーとなって作ったプロダクトがあって、
それが結構外部からの評価も高いのだが、原因不明のバグが存在していた。
それは私が入社した当初から、先輩が直したいと言っていたものなのだがそれは比較的コードの量もおおく
原因を突き止めるのにだいぶ苦労していたようであった。
そこで、昨日だ。
私はちょうど自分の仕事が一段落したのでそのソースコードを勉強がてら眺めていた。
すると何やら臭いところがあったので、クローンしてきて詳しく調べてみた。
そして、バグの発生している箇所を見つけたので先輩に確認してくださいと言った。
発見した。
わかった。
直し方を教えた。
先輩は長いこと悩まされていたバグが解決して喜んでいるようだった。
そして最後に俺にこう聞いた。
「どうしてバグを探そうと思った？」
悲しい
昔のソフトウェア開発だとコンパイルをできる大型計算機ってのはとっても高価で一台しか無かったそうな
おまけにコンパイルするためには平気で1日とか2日とかかかっていたそうな
ソフトウェアにバグが混入しておるとその分の稼動が全て無駄になってしまうので
ソフトウェア開発者はコンパイルをする前に入念なチェックをしていたそうな
入念なチェックをフェーズに分けて行うための仕組みとしてウォーターフォール型というものが考案され
抽象的なソフトウェア仕様からコンパイルに書ける前のコードになるまで
段階に分けてソフトウェアにバグが無いかチェックしていたそうな
詳細設計書というのはその名残で、コンパイルをかけるときにバグがあってはならんから事前に設計するようにしたんじゃ
ところで結局ウォーターフォール型では各工程で不都合が生じたときに前の工程に戻ることが難しく
本当の意味でのソフトウェアの品質や工期が伸びてしまうのが大きな問題で
それを解決できないか試行錯誤しておるうちにハードウェアが進化して開発者みんながパソコンを持てるようになり
ソースコードを書きながらコンパイルできるようになったもんじゃからこの方法は海外では廃れてしまったのじゃ
一方日本ではウォーターフォール型というものが古来より日本の社会システムにある天下り制度とマッチしてしまったこともあり
ウォーターフォール型が大変好まれて今も使われているというわけじゃ
これが日本の大企業からろくなソフトウェアが生まれない理由なんじゃと思うのぅ
「詳細設計書」の書き方も会社によるだろうけど、ソースコードと「粒度が同じ」っつーんだから、それこそif文for文と対応するようなドキュメントを否定してるんだろう
Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。
詳細設計のことだ。
ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。
てか、そんな物を読むくらいなら、現物のソース読めよって話だ。
だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。
何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。
「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。
それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。
でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。
負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。
なんでそんなに「日本語訳」が欲しいの？
もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。
そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。
それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。
とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。
ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。
ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。
そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。
ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。
Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。
いまは別の会社に勤めているが、以前の会社があまりにも残念だった。
ちょっと気持ちが落ち着いてきたのと、落ち着いてきたものの誰かに知っておいてもらいたいので記すこととする。
例によって特定を恐れ、ある程度はぼかすものとする（が、事実である）
昨年の夏頃から転職活動を始め、自分なりに納得した上で初冬に転職した、理由はUターンである。
小生は都内でシステム開発の職に就いていたが、転職先も地方のシステム開発である。
Uターンということもあり、年収や仕事内容が下がることは覚悟の上だった。
仕事の内容が下がるとは、やはり都内でイケイケな技術を使って、イケイケなサービスを作っていた側からすると、劣るということである。
断りを入れると、すべてが転職活動の失敗に紐づくし、それは自分の責任の以上で以下ではない。
が、考えていた以上の煮え湯を飲まされることとなる
一例を出すとする。
まず前提
そこでは、とあるシステムのパッケージ開発とその納品作業（カスタマイズ含む）を行っていた。
納品作業には顧客との動作確認や他システムとの連携テストが含まれる。
うすうすおかしいなっと思うことがあったが、連携テストの際に辞めることを決意する決定打があった。
コレである。
なんかよく分からない叱責の中で、この言葉がでてきたのである。
耳を疑った。
多分人生で初めて、耳を疑った。
いままで信頼してきた自分の耳を疑った。
そもそもこの会社では到底SVNとは思えないSVNの使い方をしていた。
なんせソースコードの改修箇所は、Excelで管理されているのだから。
ちなみに想像つくと思うが、ソースコードに改修番号みたいなコメントがあって、その改修番号でExcelと紐付いているという。
そんなこんなでソースコードにはどこぞの納品先でカスタマイズされた分岐やらループやらが散在して、なんのことかよくわからなくなっている。
まぁやり方はそれぞれだから百歩譲って許そう。
しかし許せないのは、あたかもそれが正解かのように叱責され、でてきたあの言葉である。
これを言ってきた連中は新卒で入ってずっといるor長いこと会社にいるっといったメンツである。
毒されている、というか技術者としての向上心もない、もはや彼らはこの会社でしか生きられないだろう。
「ごめんね、ここでのSVNの使い方はこうなんだ、いま改善しようとしているところだから、とりあえずは我慢してね」
とか言いようがあるだろう。
それもなく、運用ルールを説明もせずに間違っていたら怒るという。
（彼らは説明したと言っているが、間違いなくいっていない。こんなルールを聞かせれて覚えていない訳がない、彼らのなかで常識となっているから言ったと思いこんでいるのだろう。）
ボカしているのでうまく伝わらないと思うが、これがことの顛末である。
もちろん他にも首を傾げるところはある、けしてコレだけではない。
書いてて思ってが本当に内容をボカす必要があったのだろうか。
なぜなら彼らは、はてブも知らなければ当然ながら増田も知らないだろう。
故にこの増田がはてブのトップにきたとしても、みることはないだろう。
もうちょっとだけ、なんだかなーっと思ったことを言わせてほしい。
例によって彼らもソシャゲをする一端のサラリーマンなわけだが、Ingressを知らないことには驚いた。
別にIngressを知らないからレベルが低いと言ってるわけではないが、それぐらい知っておこうよっていうことが多々ある。
どうやったら防げたのだろうか。
（それはない、人のやる気さえを奪う負であったから、ここにいたらマイナスでしかない）
やっといろいろ考えられるようになってきたので、今回まとめてみることにした。
賛同してくれる人がいたら嬉しいです。
最後に
だけどそんな高尚な話じゃない。
10年以上前の職場で、たまたまスプレッドシート上に示されたなんかの値を整列させないと上手くいかない事があって、マクロを組まざるを得なくなり、ちょこちょこっと勉強してみてソートアルゴリズムなるものがあることを知った。
それ以来プログラムなんか書いた事はなかったのだけど、またしても書かざるを得なくなった。
「その振込み用データって名前のあいうえお順にならない？」って頼まれて「簡単に出来るよー」と安請負したからだ。
最初はエクセル上で普通に整列させれば良いと思ってたんだが、表形式上のデータの取扱いに難点があり、エクセルの操作だけでは出来ない、あるいはかなりややっこしい事が判明した。
そこで、昔取った杵柄、マクロ書いてやろうかと。
クイックソート使わなくともバブルでも全然問題なかったんだけど、何故かクイックソートに拘った。
しかし、そのクイックソートのアルゴリズムが思い出せない・・・
こんなことここに書いたらバカにされるのは分かりきってて書いてるんだけどね。
ググれば済む話なんだけど、歳食って頑固になってきたからか、意地でも思い出そうとノートに数字書いて並べたりして考えて。
・・・よくよく思い出すと、10年前の当時、そもそもクイックソートのアルゴリズムをそんなに知らずにただただソースコードを拝借しただけだった事を思い出した。
でも、なんとなく、なんか左右に入れ替え続ける図みたいなのがあったなぁってのと、再帰アルゴリズムってーのを使うというところを思い出して、１時間くらい掛けて独自にクイックソートをするコードを書き終えた。
テストして、勘違いなどのバグを直し、整列に問題ない事を確認。
我ながらやるじゃん！・・・と思ったのも束の間、付随するほかのデータを同じ順に並べなおさないといけないことに気付く。
てことは、元の配列の添字を別の配列に入れて、ソートするときに一緒に入れ替えて元の順序を保存するようにすれば良い？・・・と思ってやってみたがこれが上手くいかない。
結局、ほんの些細な勘違いをしてたことに気付くまでに２時間も掛かり、頼まれてから計3時間後、「簡単に出来るよー」と豪語してしまった相手を呆れさせてしまった。しかもその間他の仕事放ったらかし。
突然、宣伝インタビュー記事(https://thinkit.co.jp/article/10488)という燃料を投下してきたので、http://anond.hatelabo.jp/20160616172213に引き続きこき下ろす。
これは上記記事とあまり関係ないのだが、ホームページなどで特に目立っているので、あえて書くことにする。
メジャーなブラウザであるIE、Edge、Firefox、Chrome、Safariは国産ではない。そのせいなのか知らないが、やたらと「国産」を強調している。
しかし、国産であることのメリットはあまりない。あるとすれば、要望・バグ報告などのサポートが(製作者にとって)やりやすい、要望が通りやすいぐらいである。ただ、国産でなくても、サポート体制がしっかり整っているところは少なくなく、国産の優位性はさほどない。
エンジンは国産ではなく、ただのChromium派生ブラウザである。セキュリティ問題報告に対して報奨金制度を出して安全にすると言いたいのだろうが、国産だから安全というわけでもない。国産ブラウザは全体的に多機能・重量級な傾向にあり、それを嫌う人には全くメリットにはならない。
たったこれだけのメリットのためだけに、なぜ国産と強調することにこだわるのだろうか。
これは認識が甘い、と言わざるを得ない。というか、無理だろうと言いたい。
「ユーザーの声で進化するブラウザ」を謳うのであればサポート体制の強化が必要である。
しかし、いくらサポート体制を万全にしても、地理的に離れていることもあり文化が異なる。国が変われば求められていることも変わるが、もし特定の国を優先するならば、世界中のユーザーの声を聞くことは不可能である。無理に行うと妥協点を探すことになり、下手をすれば誰も求めていない機能が出来上がる恐れがある。ローカライズすると妥協点を探すことが多くなり、日本国内だけを相手にしていた時より困難になりそうだ。
その上、ユーザー要望で機能を揃えただけではただの器用貧乏である。ブラウザの将来性が感じられない。それでは海外では受けないのではないだろうか。
意味不明。これはつまり、将来的にはアドウェアになる、ということを遠回しに言いたいのか？(たぶん違う)
例示した「セキュリティ上問題になる危険なリンクは自動で排除する」は非常に危険。これが実現すると、一企業が恣意的に操作できるので、よほどD社への信頼がない限り不可能ではないだろうか。「中国系の外資系元社員が作ったブラウザ？」と勘ぐられているのでは道のりは長いだろう。
「特定業界の法人向けに専用ブラウザを開発していくプランもあります」というビジネスの展望があるそうだ。私企業なので、こうした利潤追求は当然である。しかし、この文脈だけだと、コンシューマー向けには具体的な話がない。似たようなスタンスであるVivaldiのような期待はしてくれるな、ということか。
マネタイズが難しく、市場的にも先細りな将来しか見えてこない(MSがやめたくてしょうがない)デスクトップアプリよりも、マネタイズのやりやすいスマホ向けに力を入れるほうがよいはずなのに、可能性を自ら捨てている。
アプリストアのリジェクトが不安だからやめたって、規約が厳しいiOSならともかく、ゆるゆるなAndroid向けをやらないのは意味不明。これでは「うちには全然技術がないから無理」と言っているようなもの。あるいは、できる人を入れる余裕がないということだろう。
先に断っておくが、元になっているChromiumは修正BSDライセンスなので、そのライセンスの条件を守っていればChromium派生ブラウザのソースコードを公開する義務はない。Google Chromeがその例である。
と回答したが、本音を言いたくなくて言い訳しているように聞こえてしまう。ブラウザを開発できる人数で公開するかどうかを判断したの？これでは開発者が多いほど外部の貢献者にバグを修正してもらえる可能性が高くなるので、バグ修正にかかる開発コストを0でやってくれることが期待できるという本音が透けているのだが。そういう本音が事実かどうかはわからないが、ほかに考えられることは、外部の貢献者が増えることで発生するであろうD社内部で決めた方針のブレを防ぎたいからとか、パクられるのが嫌とかの理由で晒したくないからとか、特に理由はないけどとりあえず言い訳しといたとか。
やはり、ブラウザの将来そのものについて具体的なことは何も書かれていなかった。ユーザーの要望に依存した受動的な開発体制だから何も出ないのではないか。こんなことで国内のシェアを増やすことができると思っているのだろうか。
Vivaldiでいいじゃん、Cent Browserでいいじゃんという人に対しては全然効果がないだろう。むしろ、墓穴を掘ったような感じである。
