はてなキーワード: テキストエディタとは
テキストエディタが秀丸推奨。というかエディタに金を出してくれない。
OSSのエディタが増えてきたにも関わらず、意識低いので秀丸メインが多い。
前述の通りようやくSVNが導入されたけれども、Githubの提案は「英語で使いづらい」という理由で却下。
総務だろうと何だろうと全社員がrootで見ようと思えば見られる状態。
性善説に頼りすぎだろ。
ReactやAngularJSといったモダンなものは難しいという理由で俎上にすら乗らない。
既に開発が打ち切られたjQueryプラグインなんかを当たり前のように使う。
当然開発が打ち切られてるもんだから最新版のjQueryでは動かない。
結果、特定プラグインを動かすためだけに複数バージョンのjQueryを読み込ませたりする。
にも関わらず「何で遅いのか」と問題になったりする。
コード見ろよ。
Slackやチャットワークはおろか、Skypeなども使われていない。
受信するメールの量が多いため当然取りこぼしも増える。
当たり前のようにIE8対応が仕様書の必須要件に含まれている。
最新ブラウザ以外の対応に別料金でも取ればむしろ工数と金になるものを、無知なので最低要件に含めてしまう。
何度言っても理解しない。
もちろん、別にこれがダメってわけじゃない。いやダメなのもあるけど。
「これ使えてるだけまし」って人もいるかもしれない。
ただ、数え役満っていうのかな、技術力の低さがインクリメントされていって、現状の「技術に明るくない我が社」を作ってるように思う。
自分が少しずつ会社を変えていけばいいのはわかるけど、決定権持ってる人間が技術に明るくないと、枯れた技術がいよいよ朽ち果てる寸前まで現状をよしとする。
それが、うちの会社。
気がついたら「まともな技術持った人」が全員辞めていた。
この前、テキストエディタで日記を書いて保存する、というのを覚えた。
で、さっき。帰宅するなり「おれ、すごいことを思いついた!」と駆けまわってしまった。
ということは、日記を中に書かないで、別人の名前を書けば、自分の意見にどんなトラバでも、いくらでも書ける。
ということだ。
実際はすぐ釣り乙自作自演乙と返ってくるのだが、よく気がついたものだと感心した。
その辺のことを、増田界隈に書いていたら、
「やっぱりねー。そんなはずないとは思ったんだけど『もしかしたら』と思ったんだー」と少し残念になった。
でもさ、このアイデアといい、薄々「そんなはずない」って気がつくことといい、すごいよね?
この前、テキストエディタで日記を書いて保存する、というのを教えた。
で、さっき。帰宅するなり息子が「お父さん、すごいことを思いついた!」と駆け寄ってきた。
息子が言うには、
ということだ。
実際はファイル情報としてファイルシステムに保存されるので、容量は消費しているのであるが、よく気がついたものだと感心した。
「やっぱりねー。そんなはずないとは思ったんだけど『もしかしたら』と思ったんだー」と少し残念そうだった。
でもさ、このアイデアといい、薄々「そんなはずない」って気がつくことといい、すごいよね?
別に本がなければ勉強できないわけじゃないよ。増田は考えるのが苦手なタイプと見た。
現に、文章が読みづらく、頭にとっさに思い浮かんだことを数珠繋ぎで書いているもんな。
悪く言ってるわけじゃない。そういうタイプは知識を蓄えるよりも、実際に手を動かしたほうが身につく。
paiza.ioってサイトがある。そこで自分の学びたい言語を選択したら問題が色々あるから、それを解いていけば結構そのモヤモヤは解消されるとおもう。
そんな頻繁にすることじゃないから、新卒で入社したら先輩にある程度確認してもらって構築できるから。
恐らく一番簡単な言語だから。Webサイト開発に使う言語なので、就職先のバリエーションも広い。
なんか時々Javaとか言ってるけど、それ学校で教えてるだけであって、お前が将来したい仕事とリンクしているわけじゃないだろ?
俺は業界未経験でWeb業界に入ったけど、この業界は大概の場合、デスマーチとは無縁だから(ないとは言っていない)、SIerとかソフトハウスとかそういう地獄よりはまだ生ぬるいぞ。
ソフトだってeclipseがどうのって言ってるけどそんなの要らない。terapadとかsakuraeditorみたいなただのテキストエディタでいい。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
俺も就活うまくいってない時期があったんだが
その時のESはテキストエディタにまとめた文章をpdfにして提出していた。
面接にこぎつけても下調べなんてろくにやらなかったし
今思えばおいおいという感じだけど、
当時からすれば至って真面目なんだよね
それなのになんでろくに研究もしないままだったのに
同期はするすると内定もらってるんだ?俺と何が違うんだ?
と思い初めてそいつを観察するようになって目が覚めたんだけど。
非モテも「何でそうなるんだ?」っていう突っ込みどころ多いかもしれない。
片意地はりたくなる気持ちはわかるんだよ、
でもこれじゃどうしようもないなって言いたくなるようなところは
大体持ってるんだよね、非モテって奴は。
http://anond.hatelabo.jp/20160110131135
だからあくまで「俺から見て」という話になりますけども、イケダハヤトという人のブログからはおもしろみを感じることができなかった。役に立つかというと、それもあまりそうは思えない。
おもしろくない、役に立たないという結論を出しているが、イケダ氏がどうおもしろくないのか、
なぜ役に立たないのか、その根拠が書かれていない。
あれつくづく俺と対極にいる人なんだなあと思いました。
文章への情熱や原初的な感動が感じられないイケダハヤトは、自分とは対極の人だと断じているコンビニ店長。
だが、なぜイケダハヤトにはそれらが感じられないと判断できるのか、その根拠が書かれていない。
さて、彼は三度のメシよりなにが好きなんでしょう。俺にはそれがわかりません。その答えがおそらく彼があのような手法をとる理由であり、そしてどうやら俺は、わからないながらもなんとなくその理由があまり好きではないのです。
「わからない」を「つまらない」「嫌い」等に結び付けてしまう人をたまに見るが、
わからないのに判断を下しているおかしさに気付かないのだろうか。
すでに多くの人がやっているイケダハヤト叩きに手を出したあげく、鋭いことを何も言えず、
自身の陳腐な文章哲学を並べただけのコンビニ店長。独自性が無く、結論を根拠立てて説明するという
作法すら知らない人が、文章への情熱を自負している様は滑稽でしかない。
大学の知見や論文レポートの下地があるイケダハヤトは、自説を根拠立てて説明する文章を普通に書いているし、
顔や実名を明かしているぶん、コンビニ店長よりも文章に対する責任や覚悟があるのではないか。
なんにせよ、他人の情熱を否定するような傲慢を冒すなら、相応の論を出せないと恥ずかしい。
・発音やリズムに気を配って、読み心地のいい文章を作る(語句の反復もその一例)。
・漢字をひらいたり、常用外の漢字を使ったりして、ビジュアル的なニュアンスを出す。
これらは比較的ポピュラーな文章術であり、例えば大ベストセラー作家の村上春樹もやっている。
だから、こうしたテクニックを駆使しただけでは評価に値しない。
小説なら、どのような形でテーマを見せるか。評論なら、どれだけ鋭いことを言えるか。
文章術なら、まだ知られていない面白い文章術を編み出せるかどうか。
コンビニ店長が今回書いた増田は評論に該当するが、鋭いことを何も言えていないので価値が無い。
「俺はアマチュアリズムの信奉者でした」と書くだけでも自覚や熱意を表現できるわけだが、
わざわざ「かなり自覚的な」という句を入れて野暮ったくしている。言葉のセンスが無い。
アマチュアリズムというとかっこよく聞こえるんですが、要は「無料なんだからなに書いたっていいだろ」っていうことです。あるいは「なに書いてもいい自由を俺から奪うな」「つーか金とるにあたって発生する責任とかとる気ねえから」ということでもあります。
考えてみると、俺は常におすそわけの原理で動いていた気がします。たとえばカレー作った。なんかおいしくできた。じゃあ隣にも分けてあげよう。やっべー俺の作ったカレー超うめえっすよ。でも隣の人がカレー好きじゃなかったらおすそわけしない。インターネットのすばらしさは、俺にとっては「俺の作ったカレーここにあり!」「俺は超うまいと思うからカレー好きな人は食え!」「でも俺の好みで作ったから好みにあわない人ごめんね」「そのかわり無料」っていうところです。
かといって日本全国のカレー好きの人に俺のすばらしいカレーを届けるための努力をするほどではないのです。だから別に有名になる必要はなかった。それに俺には「今日はカレーを作ろう」「いや、気分的に今日はうどん」という自由がありました。その自由を捨てる気はなかったのです。カレー職人になりカレーで金をとるためには、三度のメシよりカレーが好きであり、魂がカレーでできている必要があります。それでいえば俺は「料理が好き」なだけであり、だれかがおいしいといってくれればそれで満足だったのです。もっといえば「おいしいといってくれる可能性がある」だけで満足だった。
それでも俺は、なにも書かれていないテキストエディタを前にしたときの「さあ、いまから俺はなにを書いてもいい。そしてだれかがそれを読んでくれるかもしれないんだ。こんな素晴らしいことがあるだろうか」という原初的な感動を捨てたくはないです。
こういうのは、ネットで文章を書いている人の多くが日常感覚的に思うことだ。
それをさもマイナーな価値観のように語っているところに、コンビニ店長の井の中の蛙ぶりが見てとれる。
大卒の人や、それなりに本を読む人の語彙や理解力を想像する力がコンビニ店長には無い。
だから「かなり自覚的な」等の過剰な説明をしたり、誰もが知っていることを念入りに語ったりする。
言わずもがなの言葉ばかりで埋められた文章は、文字量のわりに読み応えに乏しい。
私はコンビニ店長の文章を面白いと思わない。コンビニ店長の文章には知的刺激が無い。
誰もが知っていること(共感性)をまわりくどい言葉(歯ごたえ)で書いていて、
その共感性+歯ごたえが、コンビニ店長の人気の理由ではないかと推測している。
粋な文芸の世界を知らない人や、文章を批評的に読む習慣の無い人が、コンビニ店長に釣られてしまう。
長いです。
ついさっき、イケダハヤトって人について書いた記事を読んでたんすけどね。
あれつくづく俺と対極にいる人なんだなあと思いました。
個人的な感情としては「そこまでしなきゃマネタイズできないとか向いてないからやめたほうがいいよ」としか思わないんですけども、同時にだれもが文章一本で金とれるわけでもない、ということもよく知っています。
俺はかなり自覚的なアマチュアリズムの信奉者でした。書籍化とかまあそういう話もそこそこあったんですけども、一度の例外を除きすべて断ってます。まあ商業に乗っかることのめんどくささってのがいちばんでかいんですが、それ以上に俺には「自分の文章を換金する」気がかなり強固な意志としてなかった。ブログでもそれを鮮明にしていたはずです。
アマチュアリズムというとかっこよく聞こえるんですが、要は「無料なんだからなに書いたっていいだろ」っていうことです。あるいは「なに書いてもいい自由を俺から奪うな」「つーか金とるにあたって発生する責任とかとる気ねえから」ということでもあります。
仕事柄「商品と価格」ということにかなり鋭敏です。流通に乗っかってる以上は、どんなもんでも商品だろってことです。まあ、需要がありゃどんなもんでも換金できるのが資本主義ってもんでもあるんでしょうけど、だからといって送り手がそのことに無自覚でいいってことはないよね、という。
俺が売ってるものは食い物がメインです。食い物は、払った金のぶんだけはなんらかの満足を客に与えなきゃいけない。そうでないと売れない。食い物の第一の機能は「食ったら腹埋まる」ということですが、ほかにも甘くておいしいだとか、レアだとかまあいろいろあります。ごく大雑把にいうと、普及価格の食い物に関しては「おいしい」と「腹埋まる」がメインの機能で、ほかのものは付加価値だと思ってます。
しかし実際に売れる商品ってのは付加価値で売れるんですよな。パッケージがいい、CMが大量投下されてる、見た目より重い、いままでに見たことがない、など。まあリピート以外の要因では、食ったことがない状態から買うんだからあたりまえの話ではありますが。
で、イケダハヤトっていう人は、この付加価値の部分を極大化させた人だと思うのです。あらかじめ言っておきますが、いいとか悪いとかの話はしてないです。そもそも俺はブログってものを「文章をのっけるためのメディア」としか考えてません。俺にとってそうだからそうだ、というだけの話で、この段階で、そうは把握していない人を批判する資格と能力がありません。
ただ、人目に触れるなんらかのメディアである以上、その本分は「おもしろい」か「役に立つ」だと思ってます。おもしろいってのはなんでもいいです。単純に笑えてもいいし、罵倒芸でもいいし、人の生の一断面があらわれてるようなものでもいいし。そして、それ以外の部分はすべて付加価値です。
おもしろさというものが単純に言語化できる性質ものではない以上、付加価値のほうも明確には定義できない。だからあくまで「俺から見て」という話になりますけども、イケダハヤトという人のブログからはおもしろみを感じることができなかった。役に立つかというと、それもあまりそうは思えない。ではなにが得られるのだろうと考えたときに、ある種の人々を「その気にさせる」「逆から見ることでわかったような気にさせる」機能がメインじゃないかな、と思えました。
付加価値は金になります。しかし付加価値だけでは長持ちしない。それをなんとかしてきたところに異能があったんじゃないかと思えます。まあ実際にだれかの人生に影響を与えたんだとしたら、それはもう「付加」とは呼べないのかもしれません。
個人的にはイケダハヤトという人のスタンスは嫌いです。ただ、嫌いである以上に理解ができない。これはあくまで俺の理解能力の限界なんだと(遠回しな皮肉でなく)思うんですが、たとえマネタイズという強力なモチベーションがあるにせよ、ああいう炎上上等な手法で得られるものはいったいなんなのか。それが金だというなら仕事なんだからいやなことでも我慢するっていうことなんでしょうか。
考えてみると、俺は常におすそわけの原理で動いていた気がします。たとえばカレー作った。なんかおいしくできた。じゃあ隣にも分けてあげよう。やっべー俺の作ったカレー超うめえっすよ。でも隣の人がカレー好きじゃなかったらおすそわけしない。インターネットのすばらしさは、俺にとっては「俺の作ったカレーここにあり!」「俺は超うまいと思うからカレー好きな人は食え!」「でも俺の好みで作ったから好みにあわない人ごめんね」「そのかわり無料」っていうところです。
かといって日本全国のカレー好きの人に俺のすばらしいカレーを届けるための努力をするほどではないのです。だから別に有名になる必要はなかった。それに俺には「今日はカレーを作ろう」「いや、気分的に今日はうどん」という自由がありました。その自由を捨てる気はなかったのです。カレー職人になりカレーで金をとるためには、三度のメシよりカレーが好きであり、魂がカレーでできている必要があります。それでいえば俺は「料理が好き」なだけであり、だれかがおいしいといってくれればそれで満足だったのです。もっといえば「おいしいといってくれる可能性がある」だけで満足だった。
さて、彼は三度のメシよりなにが好きなんでしょう。俺にはそれがわかりません。その答えがおそらく彼があのような手法をとる理由であり、そしてどうやら俺は、わからないながらもなんとなくその理由があまり好きではないのです。
これを、文章だけでのし上がってきた人間のマッチョイズムといえばそれはそうでしょうし、インターネット懐古主義だというのならそれもそうでしょう。それでも俺は、なにも書かれていないテキストエディタを前にしたときの「さあ、いまから俺はなにを書いてもいい。そしてだれかがそれを読んでくれるかもしれないんだ。こんな素晴らしいことがあるだろうか」という原初的な感動を捨てたくはないです。同時に、この感動はおそらくSNSの時代以前の人間のものだということも承知のうえで、なおそう思います。まあ、かたちを変えた「飽食の時代なんだから文句言うな論」にしか聞こえないでしょうけど。それでも俺は「読まれる」というだけですばらしいことだとしか思えないのです。
※追記
あー、逆に「読まれる」という自体がさほど困難ではない状況以降の人にとっての「原初的な感動」がなんであるかは聞いてみたいかもしれない。自分にとっての感動が真実である以上、その先の状況にいる人たちの感動ってのは理屈でしか想像できないものなのです。まあ物心ついたころにはインフラとしてネットが存在していたならそんなもののありようはないのかもしれませんけど。
(Qiitaのほうに2019年版があるので今はそちらを…。こちらは2015年版な感じです。)
Vimの外でもVim風の操作ができたりするのは彼らのおかげだ。
デフォルト、オプション、プラグイン、アドオン、様々な手段で提供されている。
Vimを使っている人でも使うかどうかは人それぞれだし、
どの程度Vimを再現できているのかも実装によってまちまちなのだが、
なんだかんだで有名どころのテキストエディタや統合開発環境では何らかの形で提供されることが多くなったように思う。
(一覧に無いものは私が知らないか忘れているだけなので、実際にはまだあると思う)
統合開発環境 | 名称 |
---|---|
Visual Studio | VsVim |
Xcode | XVim |
Eclipse | Vrapper |
NetBeans | jVi |
IntelliJ IDEA | IdeaVim |
MonoDevelop | Vi Mode |
Qt Creator | FakeVim |
テキストエディタ | 名称 |
Emacs | VIP |
Emacs | Viper |
Emacs | Evil |
Atom | Vim mode |
Atom | vim-mode-plus |
Sublime Text | Vintage |
Sublime Text | Vintageous |
Brackets | vimderbar |
Visual Studio Code | Vim |
Light Table | Vim |
ブラウザ | 名称 |
---|---|
Firefox | Vimperator |
Firefox | VimFx |
Firefox | Vimium |
Chrome | Vimium |
Chrome | Vrome |
Chrome | Vichrome |
Chrome | cVim |
Opera | VimOperate |
Opera | wasavi |
Safari | sVim |
Safari | vimari |
いくつかのコマンドでも。
コマンド | 分類 |
---|---|
bash | シェル |
zsh | シェル |
ksh | シェル |
tcsh | シェル |
yash | シェル |
tig | gitインターフェース |
less | ページャー |
cgdb | デバッガ |
LuaKit | Webブラウザ |
名称 | 操作 |
---|---|
jkで前後の項目に移動 | |
TweetDeck | jkで前後の項目に移動 |
jkで前後の項目に移動 | |
Google+ | jkで前後の項目に移動 |
Tumblr | jkで前後の項目に移動 |
GitHub | jkで前後の項目に移動 |
jkで前後の項目に移動 | |
Pixiv(複数投稿) | jkで前後の絵に移動 |
ニコニコ静画(漫画) | jkでスクロール |
ニコニコ静画(電子書籍) | hjklで前後のページに移動(wasdでも可) |
はてなブックマーク | jkで前後の項目に移動 |
ゲームも。
名称 | 操作 |
---|---|
nethack | hjklで上下左右に移動(yubnで斜め移動) |
> viのhjklは先行する何かの影響で実装された記憶があるので、操作が共通だからというだけで「viを忍ばせる」というのは言い過ぎではないかという気がする
> まして「vimを忍ばせる」というのは、ちょっとその、まあなんというか…
確かにVimではなくviの模倣だったりして無理があった…。hjklの大元を辿るとどこに辿り着くんだろう(ビル・ジョイの使っていたキーボードとは別?)
http://www.cocacola.jp/win2015/music/
対象期間内にコカ・コーラ、コカコーラゼロ、コカコーラライフのボトルに印刷されているQRコードか、URLにスマホからアクセスすると、冬をテーマにした有名楽曲12曲がストリーミングで聴けるというもの.
スマホで下記URLをクリックしていくと、プレイリストに曲が追加されます。
Departure /globe
ずっと/SPICY CHOCOLATE
これ、ネットでボトルの写真あげてる奴らがいっぱいいて、そのURLをスマホで打ったら、普通に楽曲フルできける。
あと2曲あるけど、見つからんかった。
しかも、見てるのはUser-Agentだけみたいなので、ChromeのデバッグモードとかでiPhoneのUAにしてアクセスすれば、PCでもOK。
さらに、今時、楽曲ファイルはAmazon CloudFrontに生でおいてあるので、配信期間終了しても聴きたい人は、ダウロードして保存可能。
例えば、
の場合、
https://d1bj9pw755lis4.cloudfront.net/hls/ko_winter/music/h6H.m3u8
(他の曲の場合には、h6Hのところを書き換えればOK)
m3u8拡張子でM3U。
テキストエディタとかで開くと、楽曲が10秒毎に分割していることがわかる。
https://d1bj9pw755lis4.cloudfront.net/hls/ko_winter/music/h6H00000.ts
https://d1bj9pw755lis4.cloudfront.net/hls/ko_winter/music/h6H00001.ts
https://d1bj9pw755lis4.cloudfront.net/hls/ko_winter/music/h6H00002.ts
と順番に保存していってm3u8ファイルと一緒のフォルダに保存して、
https://www.videolan.org/vlc/index.ja.html
mp3とかに変換して、スマホに入れてもよし。128Kbpsだけどね。
この記事はメンヘラ&発達障害 Advent Calendar (http://www.adventar.org/calendars/1197) の2日目です(遅刻)。
12月に入り、Advent Calendar(アドベントカレンダー)という企画がネット上の各所で行われています。
これは、12月1日から24日(または25日)の間に、あるテーマに従った好きな記事を書いてリンクを貼ることで、1日ずつ数珠つなぎにそのテーマの記事を読めるというものです。(ちなみに本来は、キリスト教圏における、クリスマスまでの日をカウントする紙のカレンダーです。)
この記事では、ブログを持っていない人が、身分を明かさずに(匿名)で、Advent Calendar(今回はAdventar)の記事を書く方法を紹介します。
(ほぼ匿名に出来ますが、自分のGoogle/Facebook/Twitterアカウントを利用する都合上、アイコンは外せないようなので、その点をご了承ください。)
現在、私は メンヘラ&発達障害 Advent Calendar 2015 - Adventar というのをやっているのですが、しばらくして下記のことに気づきました。
このせいで、「Advent Calendarに参加出来ないけど記事は書いてみたい」という人がいたら、もったいないなと思ってこの方法を紹介することにしました。
これから、Adventarに載っているAdvent Calendarに参加する場合を考えます。
Adventarのトップ画面の「ログイン」を押すと、下記のような選択肢が出ます。
非プログラマの方であれば、Google/Twitter/Facebookのいずれかのアカウントをお持ちの方が多いと思うので、好きなものを選び、指示に従って登録します。(「Authorize App」みたいな指示が出たら、それを押します。)
ここでは仮に、メンヘラ&発達障害 Advent Calendar 2015 - Adventarに登録する場合を考えます。
カレンダーが表示されていると思うので、希望する日付の「登録」ボタンを押します。
まだ記事が書けてない段階で日にちだけ押さえる場合は、上の欄に「自分が書きたいテーマ」(適当でOKです)を記入し、「保存」を押すと登録されます。
このままだと、自分の登録したアカウント名がそのまま表示された状態です。
なお、画像は変更できないようなので、残念ですが諦めましょう。
実際に、書きたい内容について書いていきます。
まず記事を作る前に、あらかじめテキストエディタやWordなどで下書きすることを強くおすすめします。
このとき、「改行の際に空行1行を空ける」ことに気を付けてください。
下書きができたら、いよいよ記事を書いていきます。ここでは「はてな匿名ダイアリー」(通称:増田)というサービスを利用します。
上記のリンクにアクセスします。ここで「はてなID」というものが要求されるので、持っていない人は「新規登録」する必要があります。
なお、はてなIDは下記のサービスなどで使用されているので、これらを過去に使った事のある人は同じIDを使えます。
その後、はてな匿名ダイアリー で改めて「ログイン」をクリックし、はてなIDとパスワードを入力します。
ログインに成功すると、「○○(あなたのID)の日記」という表示が出ると思います。
上部の1行欄にはタイトルを、下部の広い欄には記事の内容(文章)書きます。
最後に、「確認する」を押して実際の見栄えを確認し、良さそうなら「この内容を登録する」を押すと、登録できます。
記事が表示されると思うので、リンク(http://〜)をコピーします。
再度 メンヘラ&発達障害 Advent Calendar 2015 - Adventar に戻り、
自分が登録した日付をクリックし、先ほどコピーした記事のリンクをペーストします。
以下、余談です。
はてな匿名ダイアリーは、「外部の人からはユーザーを特定できない」仕組みになっています。
しかし、記事にははてなIDは個人に紐付けられています。なぜはてなIDが必要なのでしょうか?
記事を公開した後になって、書かれた記事を修正したり削除したくなる場合があります。
その際に、はてなIDと紐付けておくことで、記事の修正や削除ができるのです。
匿名という性質上、この匿名ダイアリーは犯罪等に利用されやすい問題があります。
はてな内部ではそのユーザーを特定できるようになっており、運営さんによって削除や情報開示できるようになっています。
本来、はてな匿名ダイアリーでは身分を明かすようなことはする必要がないのですが、
http://pha.hateblo.jp/entry/2015/12/03/225533 を見てふと。
当方文筆業。外で書き物するときとか、家の中でもデスクトップじゃ作業する気になれないとき用に動作の軽いラップトップが欲しいと思っていた。
値段がお安くて動作も軽いという噂のChromebookを検討したんだけど、基本的にブラウザ上で完結させないといけないと聞いて二の足を踏んだ。
ちょうどその時、古いノートPCをChromebookとして復活させてくれるアプリ『CloudReady』という記事がはてブに上がってたので試してみる気になったんだけど「Chrome OS入れるぐらいならLinux入れるわハゲ」というコメントがあって、そっちの方がいいのかとやってみた。
当方が持ってた古いノートPCは、2007年ごろに買った糞Vista搭載のレッツノート(CF-Y5)。当時の型落ち機だったので、買った当初からVistaは若干重く、とにかく嫌な記憶しか残ってない。CPUは2コアの1.6GHz、メモリは512+1024MBぐらい。クリーンインストールもしたんだけどやっぱり重く、ブラウジングですらコマ落ちする有様。これにLinuxの軽量ディストリビューションをいくつか入れてみて、けっきょくLinuxBean+Firefoxの組み合わせに落ち着いた。
あれ……、これだけか。
など。Windowsのように使おうとすると確実にLinuxの洗礼に見舞われると思う。ただそれを乗り越えてでも使いたいほど軽くなったので、頑張ることができた(デメリットというより単にLinuxに慣れろって話かもしれない)。
まとめると、糞VistaノートにLinuxを入れて手に入れたものは、「軽快さ」であり、Chromebookじゃなくて良かったなと思えるのは「Windowsアプリが動く」ことだ。Linuxに慣れてないことによって面倒だと感じることはあるが、用途を決めればそれに合致する環境を手に入れるチャンスではあると思う。
このエントリが、Chromebookを検討しつつ糞Vistaノートを死蔵させてるひとに対し、ひとつの選択肢を提示できたなら嬉しく思う。
昔mixiが流行ってしばらくした時にmixi疲れなる言葉が流行った。
今、増田に疲れ始めている。
もちろん他人のネタ投稿も気になるので、ざっと読まなくてはいけない。
この悩んでいる時がまた楽しみでもある。
そして業務が開始するも増田のネタがうまくまとまっていない間は、
なるべくコードを書いているふりをするために
「この行に間違いがあったのか……。したりしたり。」
などと意味もなく呟いてみる。
そしてお昼ごはん。
飲食店の混雑が嫌いなので11時50分にはきっちり会社を出る。
なるべく早く食べて、ドトールでタバコを吸いながら増田をチェックする。
午後になるとMTGが入っている日が多く、それだけで数時間が過ぎていく。
この時間帯は不作時間帯であまりおもしろいネタが無いことを経験的に知っているが、
そうこうしているうちに退社時間になっていることが多い。
晩ごはんは外食はしない。お金はあるが増田のチェックがおざなりになるからだ。
近所のスーパー玉出でかってきた安い鶏肉を食べながら、増田をチェックする。
適当に「釣り針太すぎ。」などと半分本気になった投稿に突っ込んでみたりする。
あれは本当なのだろうか?と突っ込んでみてから気になったりする。
マックでも良いけど、惰性で窓。
どこ行っても書くから、軽量(1kg未満)・小型(11.6インチ)なやつ。
タブレットや2 in 1みたいな、キーボードと本体をBluetoothで接続するのはダメ。
UTF-8のプレーンテキストが望ましい。Shift_JISは亜種あって困る。
どうしてもリッチなドキュメントが必要な時はOffice Online、Google Document使う。
縦書で出力する時はVerticalEditor使ってる。
ローカルは64GBのSSD。扱うファイルがほとんどプレーンテキストだからこの容量で済む。
物理メディア(USBメモリ、外付けHDD)より、大手各社が運用するサーバーの方が相対的に信頼性高い。
ローカル、クラウドの2箇所に同じデータがあるようにしている。
本当は3箇所(ローカルとクラウド2つ)に保存しておくと安全だけど面倒だからやってない。