はてなキーワード: Webブラウザとは
キーボード打つのめんどいからマウスでコピペしてるのに、結局求められる。だるい。
虫眼鏡アイコンにホバーした時にマウスカーソルが👆にならなかった時の絶望感よ。
見づらい。やめろ。
読めない。強制中断させられるよりは読み込み完了までフォント真っ白でいい。
独立させてくれ。大体こういうのは閉じるボタンが追尾してこない。
閉じた後も見ていたとこまでスクロールし直さないといけない。だるい。
横からメニューが出てくるタイプの場合は大体リンクの半分以上が隠されているだろうが、そんなリンクを開きたいと思わん。
リンクを開きたくて押した訳じゃない。開くな。
開くなとは言ったが、何もするなとは言ってない。
メニュー閉じろ。わざわざ画面上部/画面外の閉じるボタン押すのだるいのよ。閉じてください。
言うまでもなく誤タップを誘う。やめろ。
うちのアプリ入れてねって広告でよくある。はてブお前のことやぞ。
画像表示前に高さが0なやつ。たまに商品画像でこれをやってくる通販サイトがある。
(上に大きく商品画像が表示されていて、下にちっちゃく商品画像一覧が表示されているやつ。一覧から別の画像を選ぶと一瞬大きい方のサイズが0になってガクつく)
スーパー見づらい。lazyload + これ + 一番下から上にスクロール でガクガク地獄を見れる。
lazyloadの利点はわかる。まあわかる。でもlazyすぎる。too lazy.
画像メインのサイトほどメリットが大きいんだろうが、画像メインのサイトほどlazyloadのせいで流し見しづらい。スクロールに表示が追いつかない事が多々ある。やめろ。
読み込み中は真っ白のままで、読み込み完了後にやっとゆっくりフェードインで表示されるやつ。なんの意味があるの?
「新しいタブで開く」等でバックグラウンドで読み込み完了させても、開くとあなたが見てくれるまで待ってましたよとばかりにフェードイン。
小さい。押しづらい。大体広告についてて、消そうとすると広告本体を誤タップする。やめろ。
LINEお前のことやぞ。(LINEは三点リーダーを縦にしたようなやつだけど)
狭い。みんながみんな縦長大画面じゃないんだよ。片方だけなら許す。両方はやめろ。
共有を知らない・使わない・アプリ入れてないユーザーもいるだろうからボタンを置く事自体は許すが、追尾はしなくていい。邪魔。とにかく邪魔。
hoge.com#aiueo みたいなの履歴に追加してくれるとこと追加してくれないやつあるよね。
追加してくれるやつはそれはそれで多用すると履歴がカオスなことになるが、追加してくれないやつはスマホ(Android)の「戻る」押すとタブが閉じられたりしてビビる。
目次に戻りたい時はスマホの「戻る」を押す癖がついてるので、例え目次に戻るボタンを用意してくれていてもスマホの方押す。でタブが閉じられる。ビビる。
履歴に追加してくれない上に、目次/トップに戻るボタンを用意してくれてないとこも稀にある。目次まで手動スクロール。だるい。
「このURLはうちのサイトじゃないよ、安全かどうかわからんけど開く?」みたいなやつ。
価格コムみたいなユーザーが好き勝手投稿できるサイトならまだわかるが、そうじゃなく運営者しか記事書けないタイプのサイトでもたまに見る。
記事書いといて安全じゃないと思うサイトのリンク載せとんのかよ。邪魔。まあ広告見せたいだけなんだろうが。
Googleお前のことやぞ。
そのアプリ内でしか見れない物だとか、特定のページを普通のブラウザより見やすくしている訳でもない限り、普通のWebブラウザアプリで見せてくれ。
ブラウザで開くと戻ってくるの面倒でしょ?って気遣いかもしれんが、大抵文字通り「ただのブラウザ」でSafari/Chrome以下の利便性。
LINEお前のことやぞ。
困る。これは困る。
人に勧めたい時、Webで調べてリンクを見つけてくるか、スクショを撮らなきゃならない。
スクショを撮るとしても大抵1枚では情報量が足りない。(商品名・ブランド名・商品画像・価格とか1枚に入り切らない)
ユニクロお前のことやぞ。
photoshopで作ったpsdのwebデザインを渡されて、フロントエンド担当がHTML/CSSコーディングしてるんだけどどうなのこれ?
そういう職場もある
客に見せるデザインカンプの方が先に必要なことも多々あるのでは
最近はFigmaのようなWebページやモバイルアプリなどのUIデザインのツールが多くある
それをそのPhotoshopのようなデザインカンプ作成に使うのはありだと思う
というか、こっちの方がデータがXMLやJSON形式だったりするので、デザインからそのままコードに落とし込みやすい
Figmaでネイティブのデスクトップアプリさえデザインして一発で落とし込む試みをGitHubで開発している人もいる
上述したとおり、デザインカンプのことですね
いきなりHTML/CSSを書くと、後から抜本的な調整が不可能になる
プログラミングも同じで、かなり書いてから、やっぱあれナシだから、みたいなのは嫌なので
それをなんか知らないけど、普段使わねーphotoshop開いてルーラー出して、
自分も馬鹿げていると思うこともあるが、そもそも社内研修やスクールでそう教えてるところもある
自分もそう教えられたときがあって、その場では嫌々ながら教えられたやり方で課題をこなしたりしてた
ここで逆らっても意味ないなあ、と思ったので
客なり講師なりを全否定するなら、そこに自分がいる意味がなくなっちゃうよなあ、とも思ったので
正直、そういう場合はちょっと揉めることが多いのだけど、仕方がないですね
仕様等の客の話を聞きながら勝手に自分の中で、あのライブラリやあのフレームワーク使えば楽勝だろう、と思っていると、
後々になってその前提としていたライブラリやフレームワークでは実現が難しい仕様を喋りだしたりすることもある
今の会社含めて2社しか経験してないので、一般的かどうかは判断できないが、前職ではHTML/CSSまでデザイナーの人が書いてたぞ
そういう職場もある
Zeplinは知らないけど、ツールにクソコードを吐かれるのはよくあるので、そこは相談するしかないのかなあ
相談するだけ無駄なケースも多いので、転職するとか、仕事自体を蹴ってしまうことも考えるべきかも
現に生きてけないで🍣
本来はこうでしょ?
(中略)
今になって思い返しても、自分のやり方の方が正しかったんじゃん、やっぱアホだろあれは、
と思うこともあるけど、世の中そんなもんなのでなんとも言い難い
決定権が自分にないと当然無理だし、フリーランスで決定権が持てても今度は仕事が小さくなるし
それは偏見
例えば、音声のスペクトル、声門とかを画像編集ソフトでプレビュー、加工することもなくはない
もっとも、それ専用のアプリ使った方がいいのは言うまでもないが
自分は普段はPhotoshopを使ってないけど、PSはJavaScriptなどでプラグインが書けるはずだし、
といっても、何でもPhotoshop同様、何でもExcelの世界で、Excelで仕様書とかあんたバカァ?とは思う
(中略)
これもやんわり、なんとかなりませんか?みたいに言うぐらいしかできない気がする
でも、意見するだけで攻撃的になる人もいるので、転職案件なのかもなあ
そもそも何でもかんでもwebページをポスターみたいに着飾るんじゃねーよ
ランディングページならともかく、よく使うwebアプリを着飾るんじゃねーよ、開発もしにくい、使いにくいしでまったく良いこと無い
それは客が要求するのもあるんで
大抵Craigslist, Hacker News くらいのデザインで十分なんだよ
フロントエンドエンジニアみたいな肩書でドヤってる人を見るとウンザリする
いっそJavaScriptなくした方がいいんじゃないかとさえ思うときがある
Webブラウザのタブごとに動作しているわけで、ブラウザが重くなる原因の1つだと思うし、
ブラウザ上でしか動作しないJavaScript書いて人生を消費したくない
でも、本当に?
「キングダム」や「かぐや様は告らせたい」「ゴールデンカムイ」などのアニメ化された人気作や、「スナックバス江」といったマニア好みの作品などが連載されている週刊ヤングジャンプ。そのヤングジャンプの電子書籍版が定期購読できるサイトがあるを皆さんご存じだろうか。
私はサイトが開設された当初から定期購読してるのだが、このサイトは色々おかしいんじゃないかと思うことがいくつかあり、今後「ヤンジャンを定期購読してみようかな」という人のためにおかしいと思う部分を列挙しておきたいと思う。
定期購読を名乗るサイトなだけに定期購読のプランがいくつかあるわけですが、その価格設定がなかなかおかしい。
1か月プラン…1,300円
3か月プラン…3,600円(1,200円/月)
6か月プラン…7,200円(1,200円/月)
12ヶ月一気に課金する方がひと月当たりの金額が高いという謎の価格設定であるが、公式サイトには「12か月一括払いで追加の特典が!」といった記載は特になく、恐らく同様のサービスを受けることになると思う。(私が12か月プランを選択してないので、詳細不明)
個人的に一番おかしいと思っているのがこの部分で、いつから契約しようが読めるバックナンバーは1年分のみなのだ。私は今サービス開始当初(2019年7月)からこのサイトで定期購読しているのだが、私が読めるバックナンバーは2019年11月7日発売号以降のもので、2019年7月~10月に契約していた部分については読むことができない。つまりこのヤングジャンプの的購読サイトは「当月分のヤングジャンプと過去1年分ヤングジャンプをweb上で読む権利」を毎月定期的に買っているというシステムなのだ。
なお、こういうシステムになっていることはサイトの非常に細かい部分まで読まないとわからない形になっていて、定期購読という名称を使った優良誤認なんじゃないかと思ったりもする。
ちなみに同サイトはwebブラウザ上で閲覧するという形式なので、週刊少年ジャンプの定期購読ようなアプリでアーカイブがいつでも読めるなんてこともない。ということで電子書籍での特典部分(フルカラー版を除けば「となりのヤングジャンプ」で読めるものが殆ど)に興味がない人でバックナンバーを手元に置いときたい人は、ちょっと値段は高くなるけど好みの電子書籍サイトで電子書籍版のヤングジャンプを購入した方が良いと思う。私も今月が更新月なのだが、更新するのかどうか月末まで悩むと思う。
https://anond.hatelabo.jp/20200829191330 の続き。
Mastodon, Fediverseに対する日本国内の認識はあまり高くない。そもそも一般人にとって注目度の高いトピックではないというのは理解しているし、だからこそメディアも取り上げないというのも理解している。これは仕方がないことだ。だからこそ、こうやって自分自身で筆を取ることをしている。
散見される意見は間違っていたり認識に齟齬があったりする。今回はそれについて説明したいと思う。
日本でMastodonが注目されるキッカケを作った mstdn.jp は2020年6月にサービス提供を終了するアナウンスを出したが、その後引き継ぎ手を募集した。Sujitechという企業が名乗りをあげて7月から運営をしている。SujitechとITジャーナリストの三上洋、ITmediaの松尾公也による mstdn.jp / mastdon.cloud のこれからの運営についてなどのインタビューの場が設けられた。ライブ放送され、そのアーカイブはここにある。
https://twitcasting.tv/mikamiyoh/movie/621664098
ITmediaからこのインタビューの記事が出ると思っていたが出ることはなかった。
Mastodonサーバーがサーバー運営者の決断により停止することはあるものの、Mastodonのプロジェクトの開発はされているし、Mastodonサーバーはたくさんある。Mastodonは単一の営利的なサービスではない。よってそもそも「Mastodonが終わる」という表現自体が間違いである。
mstdn.jp を始めとした大規模サーバーにはAlt-TwitterとしてTwitterの無法者が多く移住してきたことは事実であるが、他のサーバーのユーザーはそうとは限らない。サーバーにはサーバー運営者の取り決めたルールがある。自分に適したサーバーを選ぶべきである。もしくは自分でサーバーをたてればよい。
Ryou Ezoe(江添 亮) (@EzoeRyou@twitter.com) :
Googleがfediverseアプリを軒並みストアから検閲しているというニュースで思い出すことがある。もはや平均的な日本人にはインターネットは存在しない。スマフォアプリが全てになっている。
あるWebサービスがあると聞いて使ってみようと思い立った人間はどうするか? Webブラウザーは使わない。スマフォのアプリストアでWebサービス名を検索し、出てきたものを何の疑いもなくインストールする。そのアプリが公式であることはろくに確かめない。
結果的に、共通のプロトコルを使いゆるーくfederationで繋がりましょうというfediverseなのにもかかわらず、自社のインスタンスにログインするためだけのスマフォアプリクライアントをストアに登録しておく必要がある。中身は単なるWebブラウザーだというのに。
Apple/Googleによって提供されるスマフォのアプリストアが単一障害点になってしまっている。ストアになければ存在しないも同然だ。どうしてこんな世の中になった。
彼の主張したい点というのは理解できる。アプリはユーザーが便利に利用するための手段であるが、それが目的化してしまいストアに存在することに意味を見出しゴミのようなアプリばかりになるという懸念である。これはユーザーの意識も高めなければいけない事案である。
リプライや引用を参照すれば分かるが、彼はfederationやfediverseという語を使ってさも識者のような素振りをしているが、3つ目の投稿の内容というのは全くもって門外漢な内容である。
FediverseはActivity Pubなどのプロトコルによって形成される大きな集合体みたいなものである。各サーバーはゆるく繋がり合うがその全体的な繋がりを指す。Fediverseは構造上非中央集権でありFediverseの運営母体や総意というものは存在しない。
自社インスタンスの具体的な内容が分からないが、もし既存のソフトウェアを利用したサーバー(インスタンス)であるなら、自社向けのWebViewアプリを作る必要はない。既存のクライアントを使えばいい。「自社向け」としてアプリストアに出したいのであればほとんどのクライアントはオープンソースであるのでフォークしてカスタマイズすればいい。そもそも優秀なWebUIが存在しているのでWebViewのゴミアプリというのは発生しないはずだ。自社インスタンスがプロプラなソフトウェアであるなら、そもそも現実的ではない。プロプラならば自社インスタンス内の投稿やコンテンツを囲い込みたいが、Fediverseに参加するのであればプロプラであるインセンティブは得られないので現実的ではない。他のサーバーとの通信を遮断して自社インスタンス内のみに限定するという手法も取れるがそれはFediverseに参加しているとは言えない。
勝手な妄言は結構だが、的はずれな内容を指摘したものを受け入れずその妄言が無知な受け手によってさらに誤認識が広まることを阻止しないのはあまりにも愚かである。
今回の問題はGoogleが理不尽な要求を突きつけ圧力をかけてきたことが大きな問題である。それ単体でもGoogleの行動は批判されるに値するが、Fediverse的な思想というのも大事な視点なのだ。Fediverseは非中央集権であり、中央集権に相対するものである。各人の自由を尊重し各人が自由を勝ち取るのだ。だからFediverseのクライアントは根本的に自由でなければならないし、クライアントが特定の思想を排除するようなことはあってはならない、と私は考える。差別を扇動する要素を排除したいのは理解できるが、それはクライアント開発者の決めることではなくユーザー個人が決めることだ。そして、中央集権Googleの要求に屈してはいけないのだ。
楽しいことを考えるのが好きだ。
特に自分自身は優れた人間ではない。何らかを生産する能力がなければ行動力もない。
しかしながら自分自身が考えた世界を妄想するのが非常に好きなのだ。
如何にして従業員が快適に労働しつつ会社を維持するための収益を挙げるか?を考えている。
他の企業相手に商売するBtoBを検討したが、話題性一発で勝負できる可能性のある一般消費者を相手にするBtoCでやってみよう。
もちろん今から起業するのであればITの分野で、BtoCということであるならば想定できるのはコミュニケーション、まぁつまりSNSだ。
ただ単純にSNSで勝負しようたって既存のTwitterやFacebookに勝てるはずもないので話題性が必要。
ここで疑問が湧く。なぜ発言を投稿するタイムラインをメインへ据えたSNSにしなきゃならないのかと。
タイムラインによるコミュニケーションはオマケでも良いのでは?と。
いわゆるSNSの利点と言えば常時接続性にあるというのは多くの人が理解しているはずだから、常時接続性の悪いサービスとくっつけてしまうのはどうだろうか?
人々の話題を得つつ、まだまだ新しさを感じ、接続性の悪いサービスと言えばなにか?
そうだコレしかないだろう「VR型コミュニケーションサービス」だ。
VRChatへ代表されるように既存のVR型コミュニケーションサービスはどうしてもVRゴーグルなどを装着していないとコミュニケーションが取れないという問題があった。
皆さんが「それならもうVRじゃなくてもいいんじゃないか?」と感じるのはもっともだが、ゆったり腰をすえてコミュニケーションを取る時はVRワールドへインして、外出時などはTwitterのようなタイムラインでコミュニケーションを取り続けられるのは魅力的だと思わないか?
なんならVRゴーグルなしでもVRアバターを操作できるようにしたって良い。それはもう既にMMOやFPSで実現できているのだから技術的な問題はない。
欲を言えばVRゴーグルも専用機でなく、Google Cardboardのような形式が望ましいな。参加の敷居を著しく下げるだろう。
ARとVRの利点を融合し、スマホカメラから手指の動きを認識させVRアバターの手指腕の動作と連動させよう。VRコントローラも悪くはないが。
どうだ?自宅ではスマホを使ってVRワールドへインして、外出先ではVR仲間とタイムライン上でコミュニケーションを取る。
オープンソースで公開し、個々のサーバがまるでMinecraftのように自由なVRワールドを公開できつつ、サーバ同士がネットワークで相互接続し、法令に違反しない範囲で自治権を与えられるようにしよう。
これならばリアルの仲間内でVRワールド上でコミュニケーション取れるじゃないか。同じ趣味の者たちが集まるテーマを持ったサーバも公開できるぞ。
もうここまで来たらSNSの仕様は以前話題となったMastodonが採用するActivityPubプロトコルへ準拠し、メディアの配送形式をP2PであるWebTorrentにしようじゃないか。
個人がサーバを公開する際に問題になるのは借り受けたサーバの従量課金転送量なのだから、画像や動画はP2Pで配送してしまおう。
需要があるだろうしタイムラインのほかチャットも用意してしまおう。こちらも分散型のMatrixプロトコルへ準拠だ。
開発の中心たる我が社は特権としてマーケットサービスを運営できるようにしたら、ある程度のマネタイズも可能になるのではないだろうか?
クリエイターが3DCGモデルを公開したり、タイムライン上で使えるカスタム絵文字やスタンプ(ステッカー)を有償公開できるマーケットだ。
それと並行してVRワールド上で音楽ライブなどを開催できる環境をパッケージとして法人や団体へ売り込もう。BtoB需要もこれで確保できる。チケットはマーケットから購入する。
もしもVRワールドとしてSAOのようなMMOを公開できるとするならば、更に面白くなるんじゃないか?
分散型コミュニケーションVRシステムがゲームプラットフォームにまでなる。しかもそれはスマホで参加可能というものだ。
こんなものを立ち上げられれば、会社には面白い人材が集まるだろう。
だからこそそういう会社ではMicrosoftやApple、Googleへ強く依存しないことが求められる。
しかしITの巨人たちを脊髄反射でEvilと決めつけるのは良くない。彼らは重要なビジネスパートナーで居て貰いたいからだ。
少なくともスマホOSは2大巨頭であるiOSとAndroidOSなわけだし、GPUの多くはWindowsに最適化され、Apple Silicon化するMacは次世代に大きな影響を残すかも知れない。
重要なのは会社内部の業務環境へどのくらい自由度があるのか?という点だろう。
しかし自由度が高すぎると管理が煩雑になりセキュアな社内システムが構築しにくいという表裏一体の問題があるのも事実だ。
ならば経営者として示さなければならない社内で用いる基礎システムはPOSIXだろう。
しかしPOSIXが示されたとしてもバックオフィスの人員はまだ困るかも知れない。つまりどのようなオフィススイートが標準なのか?だ。
この点、Microsoft Officeは申し訳ないが却下で、OpenDocumentFormatも検討に入れたが、よりアクセシビリティを考えた結果Google G Suiteをオフィススイートのフロントエンドとして選択することにした。
これならばChrome Webブラウザ(またはChromium Webブラウザ)でアクセス可能なのでWindowsやMacはもとよりLinuxでも利用できる。
G Suiteを選択したことによってバックオフィス人員すべてへChrome Bookを配布することまで検討できる。
無論、アカウント管理もG Suiteで行えるし、YubiKeyなどで2段階認証も可能だろう。
・・・ふぅ
みたいなことを考えると凄く楽しいよね。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
「AWSによるクラウド入門」が2つ入っているのは?s=09というパラメータが付いているのと付いていないとので割れたせい。
7月8日、推している作家の生存確認やオンラインゲームの告知を見る程度にしか使っていなかったツイッターのタイムラインに一件のリツイートが流れてきた。
その告知を見たとき、私は「やはりな」という感想とちょっとした残念さを同時に感じていた。
なぜ「やはりな」なのか、それはサービス開始前から半分くらいの確率でコケる確信があり、サービス開始後にそれが8割に達したからだ。
====
まず、サービス開始前から感じていたことだが、LINEの使用者層とLINEノベルがメインターゲットとする層のちぐはぐさ、これが一番大きなものであったように思える。
LINEを主に使う――のはあまりにも広い層だ、抜粋は諦めよう。その中で特に頻繁に使うのは?おそらくは中学生~大学生であろう。
一方LINEノベルのターゲットは正直言ってとっちらかっている。
後述する残り3割の理由もあり、私はLINEノベルを開けないのでソースは公式ツイッター、並びに実際にLINEノベル上で連載を持っていた作家の発言程度しかないのだが、それでも商業を全面に押し出している割に内容が闇鍋すぎた。
比較的最近のベストセラーや女性向け小説、そして大量のライトノベル。
公式ツイッターはこれらを無分別に告知し、公式サイトにはどんな小説を閲覧できるかすら載っていない。
なにが入っているのか不明瞭かつ、事前情報という明かりすらない。
まさに闇鍋だ。
最低でもオリジナル連載の試し読みは公式サイトに置くべきであるし、告知ツイッターも女性向け、一般向け、ライトノベルくらいには分けるべきである。
ここまでが(最近の情報も混じってはいるが)サービス以前から分かっていたことである。
では、残りの3割にして止めを刺した要因について話そう。
先程は触れなかったがLINEノベルは小説投稿サイトでもある。
まずは落ち着いて「小説家になろう https://syosetu.com/」のトップページを開いてほしい。
次に「カクヨム https://kakuyomu.jp/」のトップページを開いてもらいたい。
最後に「google:LINEノベル」のトップページを――はてどこだろうか?
検索してもそれらしいものは存在せず、公式サイトぐらいしか目につかない。
先程も触れたが公式サイトにはどんな小説が閲覧できるか載っていない、消費者に向けて言っているのは「読みたかったらアプリ入れてね!」くらいである。
そう、情報が不透明な状況下でのアプリインストールの要求(実は今年の4月に共有機能が追加されWEBブラウザでも読めるようになったらしいが共有元が必要な様子なので論外)。これがWeb小説を読むまでにほとんど存在していなかったハードルを非常に高くしてしまった。
Web小説というのは、個人サイト時代から連綿と続く匿名に近い個人が書く、不特定多数が制限なく読む小説である。
商業サイトに掲載の場を移してからもその形式が変わることはなく、サイト会員が小説を載せ、それを不特定多数がデフォルトのWebブラウザで会員登録などせずとも際限なく読んでいる。
今も昔もWebブラウザ一つで閲覧し、小説を書く。最低でもWebブラウザのみで完結するというのが小説投稿サイトの強みである。
作者側に会員登録を求めるのは「書いたのはわたし」の証明に必須であろう。
ならば、読者側にアプリのインストールを求めるのは?「めんどくさい」や「容量制限」などなどの様々な問題が顔を出すだろう。
更に言ってしまえば小説家になろうやカクヨムでスマートフォンのブラウザ上でお手軽に読める物という概念が染み付いている事も敗因の一つだ。
商業小説も掲載している以上アプリのインストールを条件にするのは致し方ないことだろう。
投稿作品や公式連載作品をWebブラウザでも自由に見られるようにすることは技術的に可能なはずだ。
だが、それはなかった。
そこにあったのは、先人のいいところを投げ捨てた投稿サイトであった。
そして、美味しいものが入っていると言われても味がわからず、中身が見えない、誰が何を突っ込んだのかわからない暗闇の鍋に箸を入れる者は減っていった。
これがLINEノベルが失敗に終わった理由であると私は考えている。
カクヨムは小説家になろうの流れを汲み、KADOKAWAが興した小説投稿サイトである。
自社の小説や人気作品の番外編、公式連載などもあり、結構商業的な面がある。(儲かると思ってやっているのだから当然である)
利用料金は(執筆時点で)完全無料、アプリ版もあるが機能的にはちょっと便利レベルであり、スマートフォンでもブラウザ上で閲覧と執筆が完結できる。
要するに上位互換。
プログラミング未経験者から「プログラミングを勉強してみたい、でもどのプログラミング言語をやればいいのかわからない」というような悩みを聞くことがあるので、https://redmonk.com/sogrady/2020/02/28/language-rankings-1-20/ に載っている人気の言語TOP 20について、未経験者が最初に学ぶのはどの言語が良いかという観点で簡単に解説してみます。
対象読者はプログラミング未経験者なので、なるべく難しい言葉を使わないようにしたつもりです。また、正確性よりもわかりやすさを重視しているので何かしら間違っているかもしれません。ご留意ください。
Webブラウザの上で動くプログラミング言語。元々ただの文書しかなかったインターネットの世界に、グリグリ動くページを作りたいという欲求により生まれた。JavaScriptのおかげで今のWebページはグリグリ動きまくりである。
元々HTMLをちょちょっといじる為だけのものだったが、どんどん進化を続けて今は一つの超人気プログラミング言語である。今ではブラウザ上でなくても普通に動かせる(Node.jsという)ので様々な用途で使われている。
ブラウザ上で動くプログラミング言語は基本的にJavaScriptしかないので、JavaScriptはすべてのWebプログラマが学ぶ必要があると言っても過言ではない。
ちょっとしたプログラムを書いてすぐブラウザ上で動かせるので楽しい。そういう点ではプログラミング入門に適していると言えるかもしれない。
機械学習を始めとしたデータサイエンスの分野で激烈に人気のある言語。理由としてはNumPyとかTensorFlowのようなライブラリが充実しているというのが大きく、資産がたくさんあるのでこれからも使われ続けるであろう。
言語としては、誰が書いても簡潔で読みやすいコードになる傾向にあり、小さいプログラムを書くにはいい感じである。米国ではプログラミング教育にPythonがよく使われているという話も聞くし、初心者がプログラミングを始めるのにはいいのかもしれない。
将来AIやデータサイエンスをやってみたいと思うのであればPythonから始めましょう。
ランキングでは常に一位に近い順位をつける言語。Javaができた当時は色々と革新的だったらしく、組み込み業界からWebまで流行りまくっていた。今でもその名残か使っているところは多い。過去の資産やプログラマの数が多いのが一番の理由だと思う。AndroidアプリもJavaで書く(もしくはKotlin)。
実行速度が速く、また下位互換性がしっかりしているので過去に書かれたコードが新しいマシン上でも動きやすいのが長所。短所としては、歴史ある言語で下位互換性を保っているため文法が古い感じがする。タイプ量も多くなるし、学習コストはJavaScriptやPHP, Ruby, Pythonあたりに比べると高い。
正しく使えば強力な言語だが、日本のクソSEもどきは全員(自称)JavaエンジニアであることがJavaが毛嫌いされる理由の一つになっている[要出典]。いわゆるGAFAもJavaをかなりヘビーに使っているので要は玉石混交ということである。
Androidアプリを作ってみたいというならJavaからはじめるのはアリ。
Webページを作るためだけに生み出された言語。プログラマの数が非常に多い。日本で求人が一番多いのはJavaかPHPであろう。
初心者でもとっつきやすく、すぐに動くプログラムを作れるので入門に使われることも多い。学習コストの低さはトップレベルである。しかし基本的には古くてダメな言語とみなされており、PHPで作られたWebサービスは脆弱性が多いという都市伝説もある。真実は闇の中である。
近年のバージョンアップで比較的良い方向に向かっている(と個人的には思う)ので、選択肢としては意外と悪くないかもしれない。
Microsoftが生み出した言語で、.NETというプラットフォームを使ってWebサービスを、Unityというゲームエンジンを使ってゲームを作ることができる。
最近有名なのはUnityで、今やほとんどの3Dソーシャルゲーム(の一部分)はUnityで作られている。そう考えるとC#のプログラマは結構いそうだし将来もある程度安泰かもしれない。もちろん.NETも広く使われている。
ただし.NETもUnityも触らない人にとっては基本的に縁のない言語である。
なんかゲーム作ってみたいかもなーと思う人はC#から始めてもいいんじゃないでしょうか。
C言語に色々な機能を足しまくってできた巨大な迷宮のような言語。言語仕様は複雑怪奇だが実行速度は全プログラミング言語中でも最速レベルなので、パフォーマンスが重要な開発において使われる。アプリやサービスというよりは、それらを作るためのライブラリ、プラットフォームなどを作るときに使われることが多い。Web系の会社でいうとGoogleなどは主にC++を使っている。
基本的には初心者が触る必要はない。競技プログラミングを極めたいとかならC++からはじめてもいいかもしれない。
このランキングの中で唯一、日本人によって作られた言語。作者のまつもとさんは世界的有名人である。ちなみに島根県出身、在住。
プログラミングを楽しくすることがモットーらしく、確かに書き味は良い。また作者が日本人なこともあってか日本語情報が多く、情報収集という点ではとてもやりやすい。
Ruby on RailsというWebサービスを作るためのフレームワークが世界的に大ヒットしたため、必然的にRubyの知名度も上昇した。少し前まで日本のWeb系スタートアップは猫も杓子もRuby on Railsといった様相であった。今は少し落ち着いたようだが今も人気は根強く、Web系プログラミングスクール等ではだいたいRuby on Railsを教えているとかいないとか。
Webに興味があるのならRubyから始めるのが一番無難な選択肢と言える…のか?まあ悪くはないと思う。今でも需要は多い。スクールに行きたいのであれば黙ってスクールのカリキュラムに従いRailsをやりましょう。
これは他の言語とは毛色の違う言語である。というかCSSはプログラミング言語と呼んでいいのだろうか?
CSSはHTMLを装飾するためのものである。字に色をつけたり、背景を変えたり、レイアウトやサイズを変えたりするのは基本的にCSSの役割である。
すごく大雑把にいうと、HTMLで表示する内容(文章や画像)を定義し、CSSでその見た目を整え、JavaScriptで動きをつける。というのがWebサービスの”見た目”を作るやり方である。
なので、Webに興味があるのであればある程度はCSSの知識が必要である。が、これ単独で学ぶようなものではない。Webサービスを作る時についでに調べて少しずつ覚えていけば良い。
TypeScriptは比較的新しい言語で、JavaScriptをさらに拡張したものである。Microsoftによって開発されている。
プログラムにはデータの型(Type)というものがある。例えば「1」や「2」は数値型、「あいうえお」は文字列型といった具合である。大まかに言うと、この「型」に対して厳しい言語は型チェックによりバグの混入を防ぎやすいがプログラムを書くのが大変、というかコード量が多くなる。型が緩い言語はサクサクかけるし短く書けるがバグを生みやすくプログラマの力量が問われる。ランキングの中だとJavaScript, Python, PHP, Ruby, Perlあたりは緩く、Java, C++, C, Swift, Go, Kotlinあたりは厳しい。
そんな中、世で広く使われているJavaScriptの型チェックが緩すぎるのでもっとちゃんと型をつけたい、そんな要望を叶えるのがTypeScriptである。基本的にJavaScriptを理解している人間が使うべき上級者向け言語というのが現状なので、初心者が始めるには適していない。
ただしこの先主流になっていく可能性は大いにあるので、どこかのタイミングで勉強してみても損はしないと思う。
C言語は基本的にOSを作るための言語である。OSというのはWindowsとかmacOSとかLinuxといったもので、マシンを動かすための基盤となるソフトウェアである。AndroidスマホにはAndroid(という名のOS), iPhoneにはiOSが載っている。コンピュータは基本的にOSがあって初めて動かすことができ、OSが提供する機能を使ってブラウザやスマホアプリなどを動かせるのである。
というわけで、初心者が学んで実用的なものではない。ただしC言語というのは世の中の様々なものの基盤になっており、他言語の文法もC言語から拝借しているものが多い。例えばC言語をある程度勉強していればJavaやPHPなどはなんとなく雰囲気で書けてしまったりする。
そういうわけで、コンピュータサイエンスをこれからちゃんと学んでいきたいという人(大学生とか)はC言語から始めるのもいいと思う。ちなみに筆者は初めて書いた言語はCであるが、意味が理解できるまでに2年かかった。才能がないとこうなるので注意。
SwiftはAppleによって作られたAppleのための言語である。iOSアプリ(iPhoneアプリと言い換えても良い)を作るためだけに存在している。
言語自体は他と比べて新しいため文法や機能がイケてる雰囲気があるので基本的にはいいのだが、iOSアプリ以外で使っている人は多分世界で5人くらいしかいないと思う。なのでiOSアプリに興味がない人はやめておきましょう。iOSアプリを作りたいあなたは他に選択肢はない。Swiftをやりなさい。
Swiftが生まれる前はiOSアプリを書くためにObjective-Cが必要だったため、多くの人がこの言語を使っていた。が、今はSwiftがあるので、古くからあるObjective-C製アプリをメンテナンスする時以外に使う機会はない。名前すら覚える必要がないので存在を忘れてしまって構わないが、これだけ順位が高いということは多くの企業がいまだにObjective-Cで開発し続けているということであり、ニッチな需要はこれからも残るのかもしれない。
Scalaは関数型言語と呼ばれる言語の一つ。Javaの親戚みたいなものなのでJavaとの連携が容易であり、上手く使えば性能も出るしコード量も少ないしバグも少なくて最高、な感じらしい。が、その分難易度が非常に高いので初心者が手を出すものでは絶対にない。どんなに早くても他に二つは言語を覚えてから勉強しましょう。Javaを覚えてからやるのがベター。
正直ほとんど書いたことがないのでよくわからないが、ビッグデータというワードが流行りだした頃はデータ解析用途でかなり流行っていた。その後機械学習やAIブームが来て、今でも現役で使われてはいるがPythonがどんどん勢力を拡大しているので少し目立たなくなってきた、というのが個人的な印象である。まあプログラミング初心者が最初にやるようなものではないことだけは確かである。
Go言語は比較的新しいGoogle製のプログラミング言語で、Googleのように巨大なシステムでの使用を目的に作られたものである。しかし実際には様々な企業が利用しており今一番勢いのある言語と言ってもかもしれない。
他のプログラミング言語の良い点や悪い点を参考に設計されており、実行速度の速さと生産性(プログラムの書きやすさ、読みやすさ)を両立できるような言語になっている。ただし、機能を増やすのではなく本当に重要な機能だけに絞るという思想があるようで、他の言語に慣れていると機能の少なさに不便を感じるかもしれない。
学習コストが低いという点では最初に学ぶ言語として適しているかもしれないが、GoだけでWebサービス等をサクッと作れるのかというと微妙なので、アウトプットを出しにくいというのはあるかもしれない。
シェルというのはテレビなんかでハッカー的な人間がPCを開いて謎の黒い画面に白い文字を打ち込んだりするアレである。説明としては正確ではないがまあ大体そんなもんである。何が言いたいかというと初心者が最初に学ぶとかそういうものではない。しかし実際に開発の仕事をやるとシェルの知識はあったほうがいいし、シェルに多少詳しくなるとPC上でテキスト操作をしたりファイルをいじったりというのが便利にできるようになる。ただし(通常は)極める必要はない。
Shellと言っても実際にはbash, csh, tcsh, zshなど色々あるのだがそれらをひとまとめにしてShellとなっているようだ。
PowerShellは上のShellの親戚みたいなもので、ShellがMacやLinuxで動くのに対しPowerShellはWindowsで動く。そんだけである。あと正直あまり知らない。
ランキングの中ではかなり昔からある言語で、サーバーと呼ばれるマシンには大体Perlが入っている。そのくらい市民権を得た超有名言語で、C言語やC++で書くほどでもない小さなプログラムはとりあえずPerlで書く、というくらいには広く使われていた。インターネット初期はほとんどのWebサイトはPerlで書かれていたとかいないとか。PHPなどの登場はその後である。
今でも広く使われてはいるが、RubyやPythonがPerlの後継的な位置付けであるため、初心者が新しくPerlを学ぶメリットというのはあまり思い浮かばない。何か特定の目的があるのであればいいと思う。
Kotlinは簡単に言えばBetter Javaである。Javaをもうちょっといい感じに書きたいという気持ちで作られた言語で、Scalaと同じくJavaの親戚のようなものである。
ランキングの中ではSwiftと並んでかなり新しい部類。AndroidアプリをKotlinで書けるようになったことがきっかけで人気が爆発的に上昇、今ではWebの開発にも使われていたりする。
とは言えまだまだ新参者といった感じで、ドキュメントなどの情報も他の言語に比べると物足りないので初心者には厳しいかもしれない。
言語自体はとてもいい感じなので、もう少しコミュニティが成熟してくれば最初に学ぶ言語の選択肢として有力になるかもしれない。
HaskellはScalaと同じく関数型言語である。ScalaがJava的な書き方でも動くの対し、Haskellは「純粋関数型言語」と呼ばれ、ランキング中の他の言語とは一線を画した書き方になる。どう考えても初心者にはオススメしない。少なくとも他に二つは言語をマスターしてからやりましょう。
なんとなくWebに興味がありそうならJavaScriptかRubyもしくはPHP、Androidアプリに興味があればJava、iPhoneアプリに興味があればSwift、AIやデータ分析に興味があればPython、3Dゲーム開発に興味があればC#。この辺りをやりましょう。
特に目的がないのであればフィーリングで選んで大丈夫ですが、やめておくべき言語というのはあるのでその辺だけ参考にしてもらえれば。
なお筆者はただのヘボプログラマであり、大好きな記事(http://www.mwsoft.jp/column/program_top10.html) の現代版かつより初心者向けなものを書いてみたいと思ってこの記事を書きなぐった次第である。あまり真に受けないよーに。
美少女ゲーム(エロゲ)のサブスクリプション「OOParts」が2020年4月24日にサービス開始した。
Webブラウザ上で動作するため、PCだけでなくスマートフォンからもエロゲができる画期的なサービス。
4月24日~4月26日の3日間は無料でサービスが体験できるキャンペーンを実施し、多くのアクセスがあった模様で期間中はなかなか繋がりにくかったりもした。
無料期間は終了したものの、しばらくは限定価格の月額1,000円でプレイできるらしい。(通常価格は月額3,000円)
外出自粛で暇を持て余した紳士淑女にはピッタリなサービスかもしれない。
遊べるタイトルも100作品を超えており、メジャーなものから「これを持ってくるか」というマニアックなものもあるのでタイトル一覧を眺めてるだけでもエロゲーマー的には楽しいところ。
とはいえ、現状は収録ブランドに偏りがあり以前OOParts公式さんがアンケートをとった【もう一度遊びたい美少女ゲーム】の上位作品がラインナップされていないので、そちらを優先的に注力していただきサービス加入者を増やしてもらいたい。
こういった定額サービスは内容が充実しているか否かで大きく左右されるので、サービス料が月額3,000円の通常価格になった際、高いと思わせないようなラインナップとなっていることに期待。
個人的には「もう一度プレイしたい」ではなく「一度プレイしてみたかった」作品を望んでいるので、90年代作品なんかがラインナップに増えてくれると大喜びする。
https://ja.wikipedia.org/wiki/W3m
昨今のサイトを見るにはとても不便で、操作性も何もかも非効率だけども、ブラウジングがとても新鮮なものになるよ
CDが売れなくなっている昨今、EP、LPとかレコードは好調らしい。
なんかそんな記事を見た中に、
「もはや音楽を聴くことに娯楽的意味がなくなってしまい、CDセールスが衰退、アーティストが音楽のみで身を立てることが困難になっている中で、
ライブに行き生演奏を目で体で聴くことで原初的感動を受ける人や、繊細なアナログメディアで音楽を享受する”儀式的行為”により、新しい価値を見出している人がいるため」
というようなことが書いてあって、なるほどなあと思った。
効率を無視した献身的行為、ある種の狂信とも言うべき自慰的な活動こそが、拡散してしまいがちなアイデンティティを収斂するための一助になっていると考えているので、
それが音楽であれ、ピュアオーディオであれ、ルリ儀式、筋トレ、政権批判、ガチャ課金、なんにでも没頭できるものが見つかるということはとても喜ばしいと思う。(誰かに迷惑をかけなければ)
音楽ほど歴史が長くないが、Webブラウザも年々大きく変動している最中で、研究者のツールだったものが大衆向けに整備され、一般化されるコンテンツに合わせてWWWの利用も複雑化している。
SNSと高度に連携したスマホファーストの無味乾燥に大量消費されるコンテンツを見ていると、WWWを見るという行為を愛で、儀式的行為に価値を見出しても良いように思う。
「インターネットを介したコミュニケーションでは情報が多すぎる、たくさん情報を受け渡しすると疲弊する。
情報量を極限まで削ることで、原初的な伝わったことが嬉しいという気持ちを得られる。
ここからw3mで適当にWebブラウジングをするのが習慣になった。
原理主義というならLineModeBrowserとかLynxとかを選ぶべきなのだろうが、
日本発というアニミズム的発想(とドキュメントの多さ)からW3mを選んだ。
何よりも、w3mは「WWW-wo-Miru」の略だというと、上にあげた「WWWを見る」という行為に儀式的意味を持たせるためには必要な要素だと思われた。
最近だとBrow.shという画像も何とかテキストで表示してやろうという意欲的なものもあるんだけども、これは端末の解像度に依存が大きいため断念。
というか画像も必要であれば普通のブラウザ環境も使うという腥っぷり。
twitterは、twtermを使ってこれも余計なTLチェックが不要となった。
というような落書きを、適当なEC2インスタンス上のw3mから書いている。
EC2にtmux + w3m + twterm という環境をほぼ放置してあり、コマンド一発でほぼ同じ環境を無料AWSを乗り継いで利用できるようにしてある。
はてブをテキストベースで閲覧する方法を探している。それがあれば、より原初的感動を持ってクソのようなコメントを投げ合えるパラダイスが待っていることは自明である。
くそ長い話なので注意
最近、TwitterでロリキャラのR18イラストを描くアカウントへの規制が厳しくなってきたらしい。
そういったアカウントの凍結は前からあったが、最近は特に見つかり次第凍結されている印象だ。
ぶっちゃけてしまうと私はそういうイラストが好きなので、個人的には少し残念な状況ではある。
ただ、だからといって「表現の自由を守れ!」なんてTwitter社にケチをつけたいとは全く思わない。
みんな知ってる通り、日本という国はロリエロ絵に対する規制がかなり緩いが、世界的に見れば法律でNGとしている国も少なくないし、国際的な流れは完全に規制寄りだ。
そんな状況では、いくら日本人ユーザーが多いTwitter社でもロリエロ絵を看過できなくなって当然だと思う。
さて、それではそもそも、ロリエロ絵がTwitterなどのSNS上で投稿・拡散されることの問題とはなんだろう。
ロリコンが増えることも社会的にはマイナスではあるが、これについては言論・思想の自由で見逃されていい範囲だと思う。社会的にプラスな思想のみ肯定する世界になったら、それは単なるディストピアだ。
なので、間違いなく一番問題なのは「見たくない人の目に触れてしまう」ことだと思う。
すこし前に話題になった「お父さん、あれ気持ち悪い」発言だって、見たくないのに目に入ってしまうのが原因だし、他の既出の問題もたいていここが原因だろう。
これの対策は一見すると簡単で、「見たくない人が見ないところで投稿・拡散すればいい」という「自主ゾーニング」なのだけど、私の知っている限りこの試みは何度も失敗している。
これまで何度も、ロリエロ絵のイラストレーター達は「Twitterではやってられない! Pawoo(Pixivが運営するMastodonのインスタンス。Twitterに似ている)に移住しよう!」と発言しているのだが、まあ十中八九失敗している。
なぜかと言えば、Pawooはユーザーが圧倒的に少なく、絵を多くの人に見てもらえないからだ。
クリエイターにとって知名度こそ全てだ。知名度だけ高ければいいわけでもないが、知名度がなければ何もできない。そして、それはロリエロのイラストレーターも例外ではない。
というわけで、結局彼らは絵に修正を入れたりリンクを貼ったりして、だましだましTwitterで活動し続けている。
とまあ、ここまで書くと「そんなもん描くやつ勝手にくたばればいいだろ」と思う人が多数派だろう。
まあその通りなんだけれど、ちょっとだけ待ってほしい。
上で書いたとおり、ロリエロ絵の最大の問題は「見たくない人の目に入る」ことで、それさえ無ければ被害者はいなくなる。
だから、ゾーニングさえ上手くできれば(ほぼ)問題はないのだ。
ではロリエロに限らずweb上で、「見たい人にはちゃんと届くように」「見たくない人には届かないように」上手くゾーニングするにはどうすればいいんだろう。
私は「webブラウザ、検索エンジンを提供する企業が、最初にユーザーに見たくないものを選択させ」、「Twitterなどのサービス提供者が連携する機構を作り」、「投稿者がきちんとカテゴリを選択して投稿する」ことでしか解決できないと思っている。
例えば、Google Chrome(ブラウザ)のインストール時、ユーザーに「ポルノ」「暴力」など見たくないものを選択させる。
Twitterはそれに対応するカテゴリの選択肢を作り、投稿時などに選択できるようにする。
そして投稿者が「ポルノ」にチェックをつけて投稿すれば、ポルノを見たくない人には届かないといった寸法だ。
そして、これらのルールを破ったユーザー、サービス提供者には即座にペナルティを課すようにする。
大仰なやり方ではあるが、web上のゾーニングはロリエロだけでなく大きな問題なのでこれくらいやってもいいんじゃないかと思っている。
そして、この仕組みを作れるのは世界中のwebを席巻しているGoogleくらいじゃないだろうか。
…というわけで、Googleさん、そろそろ(誰も不幸にならない形で)ゾーニングに本気出してください。
お願いします。
はい。
これが言いたかっただけ。