「markdown」を含む日記 RSS

はてなキーワード: markdownとは

2017-10-16

Markdownは使いにくい

Markdownはただのマークアップ言語

HTMLに「画像を挿入」できないのと同じ


で、まあ、Markdownはその出自上「テキストファイルで見たときにそれなりの構造を反映した見た目であること」を重視してる

Markdown文書さらHTMLPDFに変換することをあまり目的としていないのだ

からそもそもグラフィカルな編集サポート機能画面があるならその編集画面内での記述方法Markdownである必要はないというかむしろ害悪なんだよね

画面の内側でXMLなりHTMLなりバイナリで保持してから変換してユーザーリアルタイムに見せればいい

いまのMarkdownは使いどころ間違った使い方をされてることが多いのだ、君は被害者といえる

あとマイクロソフト関係ないぞ!

Markdownは使いにくい

最近Markdown流行っている。

GithubMarkdownだし、ブログMarkdownで書くし、QiitaMarkdownだし、

どこもかしこMarkdownだらけ。

で、最近情報共有ツールとしてMarkdownを勧められたんだが、これが本当に使いにくい

まず、画像画像の挿入がクソめんどくさい。

エンジニアなら、画面キャプチャ使った手順とか作ることもあると思うけど、

キャプって文中への挿入がクソめんどくさい。

わざわざファイル作ってリンク貼らなきゃだめなわけ。

あのさ、クリップボードキャプってペタペタ貼り付けられないわけ?

しかMdファイル画像ファイルが分割されるから、1つのファイルマニュアル送ります的な感じで展開できない。

PDF化すれば良いって?校正できないだろ。

じゃあZipで送るわってアホかよ。

ワードの方がマシだよ。

次に、表機能がクソ。マジでクソ。

エンジニアなら、機能比較表とか作ると思うけど、Markdownは表を作るのがめんどくさすぎる。

そもそも罫線書かないと表を作れないのもウンコだけど、

なにより改行とか、表中の文字装飾がHTMLタグじゃないと使えないのがゴミ

brタグ無限に続きそうな横長のテキスト見ただけで辟易する。

なんなんこれ?考えたやつ馬鹿だろ。

無駄に長いクソアフィブログより、簡潔に機能比較された表の方がひと目で分かるし便利だろ。

機能もっと書きやすしろや。なにがオープンだよ。

エクセルの方がマシだよ。

よって、Markdownはクソ

マイクロソフト最高ヽ(=´▽`=)ノ

2017-07-13

ホワイト企業に勤めてるんだが、もう俺は限界かもしれない

大企業名前だけならたぶんほとんどの人が知ってる。毎日定時に帰れて、週休二日で、有給もフル消化できて、給料福利厚生も申し分無くて、寂しい時は社内イベント勉強会に出てワイワイできて、仕事もそこそこ面白い。だけどもうダメかもしんない。

俺はエンジニアだ。うちは IT 企業だ。俺はエンジニアとして働くつもりで入社した。面接でもそう言ったし、先輩にも上司にも主張した。衝突も多かったけれど、概ね希望は通ったと思う。今の仕事面白い。でも、それでも、もうダメかもしんない。こうしてお酒を飲みながら不満を垂らしちゃうほどに。

服装

スーツ強制である意味がわからない。あんな窮屈な服をわざわざ好んで着るほど俺はマゾじゃない。

営業マンオフィス街に勤めるビジネスマンだってんならまだわかるけど、違う。田舎に構える拠点だ。俺たちはエンジニアだ。仕事しやすい格好であるべきだ。だからといってさすがに裸は非常識だが、ジーパンくらいはいいじゃないか。

たまにお客さんやお偉いさんが来る時もあるけど、そんなの応接室で応対する奴だけ正装すればいい。なんで俺たちにまで押し付けるのか。本当に意味がわからない。マゾという性癖を押し付けたいの?

Webフィルタリング

ネットニュースは見れるくせに、Twitter は見れない。技術用語で検索して情報収集できることを知らないのかよ。

Stackoverflow や Quora や Qiita も見れない(知恵袋は見れる)。GitHubBitbucket も、そしてはてなさえもだ。え?IT企業だよね?何の冗談だよ。全然笑えないぞ。

情報漏えい対策です」だって?だったら POST だけ禁止すればいいじゃん。一部のサイトはそうしてるじゃん。情シスなのに GET と POST の違いもわからないの?

とにかく不便で不便で仕方がない。管理職は「自分のスマホで見ろ」「制限解除した専用タブレットで見ろ」とかほざいてるんだけど、なんでいちいち PC から離れてそっち見なきゃいけないの?コピペしたい時とかどうすんの?効率って言葉知りませんか?何なの?マゾなの?

ウォーターフォール

ウォーターウォールが常にダメとは言わない。ただウォーターフォールは昔のやり方であって、少ない人材スピードも求められる現代ではだいたい役不足だ。にもかかわらず、馬鹿の一つ覚えみたいにウォーターフォールで開発しようとする。

テストコード書いて効率化して暇を持て余して改善に勤しむ俺よりも、いっしょうけんめい(笑)ワード使ってコード日本語にひたすら翻訳するという詳細設計書執筆に勤しんでる奴の方が評価されてるという現実。第一ウォーターフォールに従うなら先にコードができてるのもおかしいじゃねーかよ。

開発審査

ウォーターフォール続き。開発審査といってこれを通過しないと先の肯定に進めない関所みたいな審査があるんだけど、これがまた冗談みたいに面白い(笑えない)。何十年も(何年も、ではない)前につくられた基準で、かつ無理矢理定量的解決しようとした体系をしていて、結果、

「30ページの仕様書ならレビューはx時間しているはずだ」

「x時間に至ってない?それはおかしい。x時間になるまでレビューしろ」

「x時間超えてる?それはおかしい。なんで超えたのは理由を説明しろ」

なんてことが起きている。何なの?ソフトウェア開発がそんなに単純にいくと思ってるの?そんなはずない。みんなわかってる。だけど逆らうこともなく、おかしいとも思わず、ただただ過剰な仕事を投入したり、数字いじりと作文に勤しんだりする。一体何と戦ってるんだよ。

パワポ民族

ちょっとした資料でもパワポが強要される。テキストで書くと渋い顔をするし、他部署や他拠点、部長より上向けの資料となると絶対に OK が出ない。

独自フォーマットじゃねえよ。Markdown 知らないの?別に Markdown 覚えろって話じゃない。ちゃんと見易いテキストで書いてるだろ。分量的にも、話題的にもこれで十分だろ。なのにわざわざパワポなの?何がしたいの?パワポ萌えなの?勝手にやってろよ。俺たちまで巻き込むな。

PC

PCとディスプレイは会社側が用意したものしか使えない。Windows 強制メモリとかCPUは家電量販店で売ってるレベル。いやそっちの方がまだ高性能かも。おいおい、総務とかじゃないんだぜ?エンジニアですぜ?開発マシンだよ?こんな貧弱なマシンでどうしろって言うの?

キーボとマウスディスプレイ枚数が自由なのがせめてもの救い。といってもディスプレイは会社支給品なので一人あたりどう頑張ってもトリプルだけど。

サーバー

サーバー仮想マシン動かしてそっちで開発しようとか、むしろ開発用のハイスペックマシン手に入れようとか画策するんだけど、無理。調達できない。壁が二つ。

上司の壁。「何贅沢言ってんの?」 贅沢じゃねえよ。それ営業マンに向かって「車?何贅沢言ってんの?(原付あるだろうが)」て言ってるようなもんだぞ。

会社の壁。やたら承認やらエクセル申請書やら冗長で数日じゃ終わらない。ちょっと記入ミスってたらやり直し。融通の利かないお役所仕事そもそもお金が無いからそんな調達できないんだってさ。無いことはないだろ。利益出してんだろうが。その金はどこ行ってるの?お偉いさんがガハハとかっさってんの?

結局、今部署にある分でやりくりしなきゃいけない。だいぶ昔から使ってるやつだから古いし、キャパも限界。使わないマシンを落とさないと他が使えなくて、そのためにみんなに使用状況聞いて回るとかしている始末。おかしいだろうがよ。

え?クラウド?「クラウド企業秘密置くなんて何事だ!」だってさ。だったら紙で仕事してろよハゲ

常駐ソフト

必ずインストールして常駐させるソフトが結構ある。特にセキュリティ系。中には Windows Update みたく動作に支障を及ぼすものもある。お前自身がウイルスじゃねえかよと言いたくなるレベル

あと全体的に実装が稚拙なようでメモリも CPU もやたら食う。ソース見せてもらえないから何とも言えないけど、初心者ゴリ押しで書いたみたいな臭いがする。これで何百、何千の人間の、いったいどれだけの時間を無駄にしているんだろう。

インフラ

インフラがとにかく弱い。メンテナンス日常茶飯事だし、入社年度とか拠点とかでアクセスしていい時間帯を分けるようアナウンスするし、24時間稼働じゃないし、稼働するにしても昼休憩とか夜間とか制限かけるし。自社のインフラさえままならない企業にいったい何ができるというのか。

本当に力入れた方がいいと思う。どれだけ損失してると思ってんだよ。お偉いさんのイベントで主張してみたりもしたけど、俺が浮いただけだった。こういうことに関して鈍感なのがデフォなのだ

IE

社内システムはほとんど IE しかサポートしてない。バージョンまで固定する始末。UI もレガシーだし、UX も全然考慮されてなくて、フォームを何十個もずらずら並べたみたいなページが普通に登場する。

バージョン管理

SVN である。これでもまだマシだ。いや SVN も相当にオワコンだけど(Git 信者が何を知ってるって?いやいや Git 知らないだけでしょ。gitignore が無い時点でどれだけレガシーなのかがわかりませんか)。

ひどいと VSS とかい化石だったりする。VSSて何ですか?だよね、知らないよね。調べてみるといいよ。面白すぎて笑えない。

残業体質

今上に立っている人たちが残業何十時間何百時間当たり前の世界バリバリ頑張ってきた人たちだから、そういう価値観蔓延している。残業40時間くらい何とも思わない人種である。いや40でも十分多いから。

物理的に仕事が多いならわかる。本質的に難しいことしてるならわかる。残業しなきゃままならないシチュは存在する。でもそんなの見たところ一握りだよ。大半はただだらけてて怠けてて非効率的無知なだけ。

いや、無頓着というべきかもしれない。たとえばつい先日こんなことがあった。レビューで(俺はレビューア。他にもたくさん)、レビューイがブラウザからファイルダウンロードした時にブラウザなのかダウンロード先なのかどこかおかして、ブラウザフリーズしたのね。イラっとするじゃん?と思ったら、したのは俺だけだった。数十秒くらいは続いたのに、俺以外はみんな平気な顔してた。平然と待ってた。そういうことに無頓着なんだ。プログラマの三大美徳を備えろとまでは言わないけど、そこまで無頓着なのは社会人として、エンジニアビジネスマンとして、どうかと思う。

俺は巻き込まれたくないからうまく立ち回っていて、帰ろうと思えば毎日定時で帰れるが。この体質はほんとどうにかした方がいいと思う。

全角

数字とスペースを全角で打つのはやめろ。それが許されるの小説だけだ。

コード規約「タブ4文字

インデントはタブを挿入すること ← 俺はスペース派だが、まあわかる。規約ならしゃーない。

タブはスペース4文字であること ← え?

いや何文字かはこっちが決めることだろ。何自由奪ってんだよ。

「従わなければいいじゃん」 俺もそう思ったよ。でもね、みんなね、レイアウト整えるのにタブ文字を入れやがんだよ。わかるかい、タブ4文字にしなきゃレイアウトが崩れるってことだよ。おかしくない?レイアウトはスペースで揃えよ。タブが許されるのは行頭のインデント部分だけだよ。

この件について戦ってみたことがあるけど、誰一人として賛同は得られなかった。俺は自分勝手な人間との烙印を押されただけだった。エンジニアとして主張すればそうなっちゃうのがうちなのだ

この件については宗教論争的なこともあるから最悪引き上がる覚悟もあった(それにぶっちゃけ手元のエディタツールで変えればいいことだし)。でもどいつもこいつも真面目に考えることなく、俺を一蹴した。俺が嫌いだから?何大人げないことしてんの?小学生かよ。意見を見ろよ、中身を見ろよ。

REST API

こんなことがあった。

オンプレで立ち上げてるサービスに対して REST API勝手に使ったら怒られた。曰くシステムがダウンしたらどうなるんだと。業務停止するだろうがと。

言ってることは正しいけど、だったらエントリポイントを閉塞しておけよ。あるいは注意で REST API 使うなと書いておけよ。REST APIデフォサポートしていて、何の注意や閉塞もなく解放されているなら、それは自由に使っていいってことだろ?(もちろんだからといってリクエストバーストさせていいわけじゃないが)。悪いのはそんなことも知らなかった無知管理者だ。責任転嫁するな。

ちなみに閉塞案と注意追加案と提案してみたが無視されている。もちろんそれらを行う権限は俺にはない。

口頭至上主義

チャットの意義は Pull 型コミュニケーションができることだ。受け取った側の都合で返信できることだ。送る側も、そのことを前提とした上で、期限に余裕のあることを送るのだ。

このことを知らない人があまりに多い。とにかく彼らは口頭を好む。え?あんたら、忙しいよね?むしろ俺は配慮してあげてるつもりなんだけど。口頭で割り込まれることでどれだけ集中を阻害されているかがわからないんだろうか。

まあ俺はいいけど。集中削がれて非生産的になって遅れるのはあんたらだから。俺には関係無い。もちろんそのせいで俺にまで影響が及ぶのだとしたら、そこは全力で反抗する。そういえば以前、この件で上司上司に対してチャットでみんなに意見を尋ねてみたら、問題行動として垢BAN食らったっけなあ。その部署からは異動しました。

C言語手続き

C言語手続きプログラミングマンがあまりに多い。OOPを使っただけで、Ruby スクリ実装しただけ異分子扱いされて「そういう最新技術を誰もが知っているわけじゃない」「自分が知っているからといって無闇に適用するにはやめろ」とか言われる始末。最新技術って。ジョークだったんだろうか。あの時は思い切り笑った。その先輩とは今でも疎遠だ。すれ違っても挨拶してくれない。

まあこれは部署や部門の問題だと思うけど。たとえば OSS で食べてる部隊ではそんなことはない。

自社製品うんちく

昇進するための要件として資格取得がある。公的資格だけじゃダメで、社内独自の資格必要なんだけど、この資格たち、試験でどうでもいい自社製品うんちくばかり問うてくるものであるはてなを例にするなら、創業メンバー全員(一人かもしんない。知らん)のフルネームを答えよとか、創業日を答えよなど。

それ、覚えて意味ある?何がしたいの?愛社精神擦り付けたいの?そんなことしても逆に離れていくだけだと思うけど。違うかな。じゃあ何のためだろ。全く見当もつかない。それくらいに不可解だ。

ソフトウェア使用前の承認

ソフトウェアを新しく使用のにいちいち承認必要かいうふざけた制度があった。ソフト使うのって、エンジニアにとっては日常茶飯事じゃん。いちいち承認してたら進まないだろ。

それでもルールなら仕方ない。俺は何十という承認依頼を送った(ちなみに部長以上のお偉いさんが承認者になるという慣習がある)。反応が悪いし、仕事が進まないので口頭でも催促した。一蹴された時は「ならもっと上の人に掛け合います、XXさんが相手にしてくれなかったので来ましたって」的なことを言ったりもした。

結局、俺の部署では「なるべく新しいソフトウェアは使わないこと」「どうしても使いたい場合自己責任で導入すること」「もちろんウイルスチェックはちゃんとしてね」「実績のあるソフトだけ使ってね」みたいな緩いルールが新設されることでケリがついた。

今でも多くの部署承認制のままだろう。みんなどうしてるんだろ。それで仕事になるの?

足を引っ張る人達

うちは IT 企業なのに、リテラシーに明るくない人がいる。たとえば Wiki の書き方も知らないような人がいる。そういう人が部下を仕切っていたり、社員を支えるスタッフ業務に携わっていたりする。

エンジニアとしてより良いやり方を提案しても、導入しても「難しそう」と一蹴されるばかり。そもそも、ここまで上述してきたことに対してピンと来ることさえない。

厄介なのは、会社そのものがそういう人達に足並みを揃えようとするところだ。だからエンジニアにとっては物足りない、窮屈で、非効率的で、むしろ邪魔しかならないようなシステムや仕組みや施策ばかりが降ってくる。元を辿れば煩わしいセキュリティソフト群や承認フローの多さも、一部のバカが何かしでかしたせいだ。

一部の人間が足を引っ張っている。大企業であるということ、図体が大きいということは、そういうことなんだと思う。そうするしかないのだろうか?個人的には、エンジニアとそれ以外に二分して、前者には前者のインフラなり体制なり整えればいいと思うんだけども。

自転車でたとえてみる

うちの会社の連中は、彼らはエンジニアではない。思えば余暇技術的な話をすることが一切無い。彼らにとって技術手段しかないのだろう。エンジニアとしての矜持というものは存在しないのだ。

たとえるならママチャリに乗っている人達みたいなものだ。ロードバイクに乗る人からすればママチャリ手段としてありえない。ロードの方が何倍も早いし、移動範囲も広がる。けれどママチャリ乗りはロードには乗らない。そんな世界があることをそもそも知らないし、知っているにしても努力してそこまで至ろうとは思っていない。今のままで十分だと思っている。

同じなのだ。彼らもまた今のままでいいと思っている。エンジニアリングのエの字もわかっていない。無論、ただのママチャリ乗りならそれでもいいんだけど、俺たちは IT を生業とする会社だ。ロードレースでメシ食べてるようなものなんだよ。なのにママチャリのままなんだ。どう考えたっておかしい。それで勝てるわけないだろ。この先どうすんの。今はたまたま誰も走ってない道を走ってるだけだ。そういう道も着実に少なくなってきているし、ママチャリで頑張って登ろうとするゴリ押しマン要員も減ってきている。

色々書いたけど

他にも挙げればいくらでも出てきそうだけど、疲れたんでこの辺で。

俺も偉そうなこと書けるほどのエンジニアではないし、ちゃんと読みやすいよううまく書けたか自信ないけど、それでも書かずにはいられなかった。

2017-05-15

http://anond.hatelabo.jp/20170515130428

いざ何か(たいていはHTML)に変換するときオリジナルだと面倒なので適当マークダウン言語を使うといい
最初おすすめはそのものずばりMarkdown

http://www.markdown.jp/what-is-markdown/

できあがった文書があるのならMarkdown表示アプリで小綺麗に表示させれば見栄えもいい(HTMLWebブラウザ関係に同じ)
多くのモダンエディタ組み込みMarkdownの書式をサポートしているから書きやすかろう


そういうの抜きでいいなら中黒「・」かな
日本語変換中のキーボードから一発なのがいい

2017-03-12

から情報学部学科で学ぶあなたへ

購入すべき物

macでもwindowsでもいい、core i3以上、メモリが8G以上が乗った持ち運べる物。これは絶対に買うべき。atomceleronが乗った廉価機は避ける。どうしてもお金が無いなら5年以内の中古でも良い。

これは講義資料などの閲覧用。なくても良いが、あると非常に便利。逆にプリンターは大抵の大学にあるのでいらない。情報系の教科書web上に無償で公開されている物が多いので、それらを活用して学ぶべし。MOOC活用するのもよい。

以下は学ぶべき

大学カリキュラムにあっても、先行して学んで損はない。

コンピュータのしくみと合わせて学ぶ。

英語情報の方が早くて正確である場合が多い。

どうせいつか覚えるので、早めに使えるようになっておいて損なし。

  • OSにまつわる内容

基本。

使えると色々自動化できて便利。個人的にはpython(3)がオススメ

必須では無いと思うが変換ツールと合わせて使うと便利。レポートにも使える。

どちらかお好みで。大抵のエディタIDEで使えるため汎用性がある。筆者はemacs派。

サークル課外活動

ひとりで手を動かして継続的に学べるのであればそれでいいが、そうで無い人間の方が多いのでは無いかと思う。筆者もそうだ。そういった人間他者と共に学ぶのがよい。

大学情報系や電気電子系のサークルがある場合はひととおりみておくといい。真面目に活動していて、ソフトウェアなりロボットなり成果物があるようなら入って良いと思われる。唯のオタクの溜まり場になっているようならまあ入らない方がいい。

サークル以外にも、都市部に住むのであれば技術主体としたコミュニティが多くある。SNSや同期、先輩のツテを使って興味のあるものに参加してみるとよい。

プログラマーバイトなども良い経験になる。しかブラック職場もあると聞くのでよく選ぶべし。

といっても、課外活動に惚けて大学の授業を疎かにするのは愚の骨頂。大学の授業で学ぶのは全ての基礎なので、これを知らずにどんな最新技術に触れようと意味が無い。

競技プログラミング

これは情報学部で学ぶならやらない理由が無い。プログラミング力を鍛えるには最適である

AIZU ONLINE JUDGEやAtCoderゲーム感覚で楽しむとよい。

まとめ

思いつきで書いたので書き漏らしはあると思う。あとよく言われる教授質問に行ったりして活用しろ〜などは情報系でも同じ事が言えると思う。

情報系の学生として最もやってはいけないことは、読んだだけ、聞いただけで理解した気になってしまう事だと思う。授業で聞いた事全てとは言わないが、せっかく場所を問わず実験ができる学問なので、興味を持った内容だけでも良いのでコーディングして動かしてみて欲しい。

2017-03-09

Vimで〇〇してみた系記事がうざい

そもそもVimでやる必要のないプラグインばかり

Markdownプレビュー系のプラグインなんてVim関係ないやつがほとんど

ただのコマンドにしとけって思うよ

そうすりゃVim外でも使えるから

大体テキスト整形とかその手の処理はコマンドの方が絶対いいだろ

糞分かりにくいVimScriptなんかで書いて喜んでる方がどうかしてる

選択して :!command で渡しておしまいだろうが

(例えばテキスト選択して!cat -n で行番号つけるとかな)

普通コマンドにしといてくれた方が100倍生産的だわ

何でもかんでもVimしか使えない機能作って悦に浸ってるんじゃねーよ

2017-03-08

バカMarkdownTODOリスト作るぞ!と思ったけどやめた話

最近Markdownを使ってやることをリスト化すれば捗る!って内容の増田を見た。あれすごいよね。

そこでやるべきことを把握しきれず失敗するマンの俺もMarkdownを使おう!と思った。

ちょうど今日やるべきことがいくつもできたし、いい機会だな!とも思った。

で、Markdown勉強し始めて3分で気付いた。

……別にEmacsorg-modeでいいじゃん、これ。

日常的にjunkファイルに好き放題.orgなメモを書き散らしてんじゃん。

はてな記法見出しや箇条書きに微妙互換性あるから増田に書くことorg-modeで下書きしてんじゃん。

それどころか忘れそうな用事org-modeでC-c c tで登録したりC-c aで表示したりやってんじゃん。

それつまり目の前のこと以外だったらもうTODO管理してるってことじゃん。

しかorg-modeでやるべきことリスト化してから気付いたけど、あそこでイチからMarkdown記法勉強してたら、結局やるべきこと手につかなくて、全部台無しになってたじゃん。

超ド級バカだわ俺。

2017-03-06

発達障害であることを認めたら人生が捗った話

自分はおそらく発達障害だ。

実際に診断していないので本当にそうなのかは言い切れないが超高確率ADHDだ、もしかしたらASDも併せて患っているかもしれない。

そんな私だが今年の頭から自分ガイジだと思って生活するようになってから仕事私生活もそこそこ上手くいくようになったので紹介しようと思う。

仕事死ぬほど捗った

自分ガイジだ、自分はうまく整理ができないと常に考えるようになったので、どれだけ時間がかかっても段取りをつけるようになった。

段取りをつけられないかガイジなのでは?って思うかもしれないが、定常発達者のように息をするようにできないだけで超ゆっくり考えて仕事をクソほど分解していけば段取りはつけられることを学んだ。

抱えている仕事がおおいー!うわー!頭がとっ散らかってるー!!ってなったら今認識しているタスクmarkdownで片っ端から書いていき、書けることがなくなってから仕事に取り掛かるようにした。

要はゆっくり整理してあとはガイ特有の過集中でどうにかするぞいって感じで仕事を回したら早くなったしミスも減ったし品質もすごくあがった。

精神的にも未発達なガイジなので、できるようになったらそれだけで嬉しいしもっとやろうとなるのでもっと良くしよう!みたいな良いサイクルになってきたと思っている。

痩せた

デブガイジだったので、まずは見た目だけでもよくなろうと思い去年末からダイエットを始めた。

3/6現在で約11kg落としている。

今まで通り無策にやっても失敗することは目に見えていたので、ガイ特有の気に入った食べ物は飽きるまで無限に食う習性を使って痩せる仕組みを作った。

朝食 おにぎりサラダチキン

昼食 適当な大盛り → 適当な小盛り

夕食 適当な飯 → 雑に作れる鍋

特に鍋がデカい、カット野菜と肉をぶっこむだけなのでスーパーマンでも作れるし、シャワー浴び終わったら鍋が出来上がってるからマジで楽。

鍋だけで6kgぐらい落ちたと思う、ハマったものを飽きること無く無限に食えるクソガイジで本当によかった。

無為にダラダラすることが減った

PCデスクに座ってしまうとそこから動きたくなくなってしまガイジなので、自分ガイジだ動けないぞやめろ座るな家事しろ運動しろって思い込むようにしたら私生活が超捗った。

今までなら平日の夜に同時にはできなかったであろう

すべてができるようになった。

これも仕事と同じく、帰りの電車のなかで一挙一動を洗い出してゆっくり見積もっていき、家についたらそのレールに乗るだけであと終わり!みたいな仕組みにしたら家事筋トレがあっという間に終わっていた。

勉強時間24時までと決めて、その後は酒飲みながら読書するようにしたらもう捗って仕方がない。

人に優しくなった

ガイである自分がそれでも人並みに生きていけているということは、今まで関わった人や環境があってことだと思うので、そんな私でも生かせてくれてありがとうと思うようになった。

そしたらお部下や店員さんにも笑顔で接することができるようになったし、思っていることを素直に伝えることができるようになったと思う。

他者言動の腹なんてどうせガイジの僕にはわからないので、言葉通りに受け取って素直に言葉通りに返したら少しはまともに会話ができるようになったのかもしれない。

これはまだなんともいえない、最近始めたばかりだから

総括

自分は定常発達者と同じようにできると思わないようにしただけでここまで捗るとは思わなかった。

出来ないんだ! → ならどうしようかと考えるようになったし、何より精神的な安堵を得られたと思っている。

足るを知ることで、はじめの一歩を踏み出せたのかなと思いました。

2017-01-29

Excel方眼紙はクソ!Markdownが至高!」みたいな無能

一般的仕様書とか図形、UML使いまくりなんだけどそれはどうしろと?

Excel方眼紙叩いてるのって社会経験のないクソ大学生ばっかなんだろうな

Excel方眼紙より表現力の豊かな媒体は今のところ絶対存在しない

2016-11-19

はてな社よ、増田ダイアリーを再び偉大にせよ

はてなプロダクトの中ではてな匿名ダイアリーが最も、人に読まれていて、国会で取り上げられるほど知名度があり、手軽に自分意見を表明できるというのになぜここに注力しないのか。

などなどを実行することを要求する。めざせ日本Mediumだよ

2016-11-08

ggcリポジトリの騒ぎは誰がいけなかったのか

http://d.hatena.ne.jp/shouh/20161107/1478521182

ggcについて

ggc とは Github Girls Collection の略で、女性 GitHub アカウントMarkdown でまとめたリポジトリでした。実装としては、Followings(自分フォローしたユーザ)の中から、あらかじめリストに書いておいた女性アカウント名のみを抽出して、アバター情報などを取得し、リスト化するというものでした。GitHub APIPython で叩いていました。

リポジトリ炎上している中見ましたが、女性を❤️の数でランク付けしているように見えました。(リポジトリが消えてしまっているので曖昧表現です…)

私はパット見でセクシャルハラスメントに当たるのではと感じました。

しかし、 http://d.hatena.ne.jp/shouh/20161107/1478521182記事ではpublicに晒されているデータを扱ったのになにが問題あるのかと書かれているように感じました。

このあたり

ここで思ったのは、ストーキングとは何だろう、ということです。私としては Google 検索やその他リンクなどから簡単に辿れる範囲女性エンジニア情報を集め、それをまとめて公開していただけで、ストーキングのつもりは毛頭ありませんでした。ストーキングって何なんでしょうね?

データを集めそれを公開しているだけならその理論も通じたのかもしれないと思いました。

ただ、データを集め、それを加工(自分目線ランク付け)を行い、その順に並べて、publicにそれを公開していたのはセクシャルハラスメントに当たるように感じます

じゃあこの人がいけないんですかね、もしかしたら、そういうことを考えることが出来ない環境で育ってきたのが悪いのかもしれないとか個人的には思いましたとさ。

またリポジトリgithubのstaffにより削除されたようですが、セクシャルハラスメントではないかというgithub issueが立っていたらしいので、

githubが幕を下ろさず、issueでのやり取りを見ていたらもう少し先が見えていたのかもしれないなぁと思いました。

ggcみたいなことやっちまう無能ソシオパスはどう生きればいいんだろうな

http://d.hatena.ne.jp/shouh/20161107/1478521182

他者のことをなんとも思ってなくて、ゆえにハラスメントが何たるかも理解できず、そのうえ無能なので実行しても自分が満足することすらなく、ただ不快に思う人間いくらか発生させただけで終わった。

自分の無様さを認識したくなくて「釣り」って言ってごまかそうとしてさらに失敗している。非難を浴びたんじゃなく悪目立ちしたんだと自分に言い聞かせようとしている。スケベ心で反省なんて書いてみる筋の悪さもどうしようもない。

公開されていたスクリプトが何か高度なことをしていたわけでもなく、ただ公開情報を取ってきて雑にmarkdownにしてただけで、光るものがあったとすれば赤裸々に書かれたリストゲス文言くらい。

人格的にも技術的にも行動も思想も言い分もすべてが劣悪で、擁護できるポイントが何もない。

こういう人はどうやって生きていけばいいんだろうな。本人はどうなったら幸せなんだろうな。

2016-11-06

http://anond.hatelabo.jp/20161105032504

かなり時代錯誤を感じる。ネタであって欲しい。もしかしてITリテラシー低すぎ?というか、好きなソフトウェアは何なんだよ。ノーカンプラ???

高い

"Excel" なら安い。アプリの数百円からデスクトップ版の1.5万程度。ていうか、¥14,526で売ってる。

https://www.amazon.co.jp/dp/B015SMNVAK/

重い

Excelが重いとかどれだけ糞スペ。

Windowsしか動かない

Mac, iOS, Android, ブラウザでOK。

よくバグる

それはExcelに限った話ではない。ソフトウェアである以上多少のバグはしゃーない。つかリソースが糞なせいじゃねーの?滅多に落ちないが。

検索性が悪い

イミフ普通に検索出来るだろ。

共有PCとかだと高確率で使えない(Excelが導入されてないから)

ブラウザでOK。

Markdown表現できるレベル資料とかもはや何のためにExcel使ってるのかわからない

それはExcelのせいじゃなくて使う人間馬鹿なんだろ。

タブ表示が面倒臭い

ショートカットご存知無い?馬鹿?ページスクロールも面倒臭そうだな。見なくていいよ。

バージョン管理システム管理した場合Diffが見にくい

それはそのバージョン管理システムが糞なんだろ。Diffを見るだけならWinMerge+xdocdiff普通にやすいが。馬鹿なの?

セル結合死ね

嫌ならマクロで一括解除&復元でもしろマクロからでも普通に扱えるし、イミフ。罫線も死んじゃうの?

Excel製ワイヤフレームとか手書きの方が多分まだ保守やす

知らんがな。使い方の問題だろ。ExcelじゃなくてWordならいいのか?馬鹿

お節介な補完がうざい

嫌ならOFFにしろよ。馬鹿

方眼紙死ね

Excel方眼より良いものがあれば使わないだろ。普及度、使い勝手トータルでExcel方眼より良いものがあればぜひ教えろ。

学生相手Office持ってる前提でいろいろ求める風潮

しろ、今の大学Office使わないところあるの?マジ?普通総合大学ならITの授業あるだろ??レポートOffice使うだろ???

それとも持ってるけど使えない脳足りん系?F欄なのかな。

つか、Excelの話じゃないのか?

AシートとBシートで別々の人が全く関係ない作業しててもマージするとコンフリクト起こる

形式(.xlsx)はXMLZIPで固めただけだから分解して好きにしろ

2016-11-05

http://anond.hatelabo.jp/20161105032504

Excelが嫌いな理由

多分あと2,3倍くらいある

2016-10-18

貧乏学生への学習アドバイス

http://anond.hatelabo.jp/20161017031727

老婆心ながら,おそらくSIer関係を目指しているだろう情報系?学生へのアドバイス

金銭

間違っても学生課に直接頼ってはいけない.悪手.

どの大学でも学生課は糞対応なので,カウンセラー通して学生課に学費免除なり,奨学金なり,対応を仰げ.

進路面

このままいくと研究室ゼミ配属で積みそうなにおいするから中退・途中就職大学頼らない就職)の選択肢も考えておけ.

技術

大学頼らないで就職どうするかが大変だが,とりあえず,

大学の授業だと理論多くて,

実務の話が少ないのも事実なのでおすすめは,

今はネット勉強できる時代から

- http://dotinstall.com/ title: dotinstall]

- http://gacco.org/ title: gacco]

- https://schoo.jp/ title: schoo]

- 各大学OCW

あたりがおすすめ.探せばもっとあるで.

SIer関係ないと思われるが,Web系への選択肢も拡がるしな.騙されたとおもってやっておけ.

最近だと技術文書Markdown で書く場合も多いし知っておいて損ないで.

ドットインストールにも授業がある.

基本情報持ってるなら知ってると思うが,

慣れておくといいで.ついでに言語C++でもいいが,SIerならJava8勉強しておけ.

多分授業だけだと,実際のコード使わないと思うので,自分インストールして使ってみるとええで.

実務なら絶対データベース使うんで,

MySQLインストールして使えるようにしておけ.基本コマンドだけええで.

後々データベース資格シルバーゴールド)にもつながるしな.

基本情報持ってるならある程度知ってると思うが,低レイヤIP/TCP, UDPソケット通信をCでもJavaでも書けるようにしておくとええで.

これも後々,ネットワーク関係資格もつながる.

開発の話あるしね

まず,add, commit , pushだけでええで.

ドットインストールにもある.

今までやったこと忘れるのもったいないし,他人に見せる意味でも技術ブログやっておけ.毎日更新かいらんで.

Linuxインストールしたレベルで,やったことならなんでもええで.

授業ノート電子化してもええで.

技術者就職面接で,(関係ない)バイトしてました,サークルやってましたじゃあん意味いからな.

履歴書ブログURL書いておくんやで.

技術面(余裕があるなら)

SIerに限らず技術関係の人たちの情報拾える.

SIerネタにされがちだが..

BS放送大学の授業タダで見れるので,

録画して好きな時間観て見ておけ.

情報系の授業もある.

コード書くようになったら騙されたと思って読んどけ.

自分の中の名著にしておけ.

優先度は低い.研究者になるなら重要なんだが..

技術文書を書くとき必要から読んどけ.

進路面

大学を頼らない方向で,地方住みでないなら,

Code IQかPaizaおすすめ

スカウト来たら,入らないにしても会ってみるとええで.

バイト大事なのはわかるが,大学目的は,知識選択肢拡げるというのもあるので,頑張って生きるんやで.

じゃあの

2016-09-19

なぜ手書きにこだわる?

自分不器用なせいかグラフ手書きが致命的に遅かったので、2年前期の実験危機感を感じた自分は2年の夏休み中にpythonを覚え、今まで苦労していたグラフプロットなどをパソコン上で全部自動化しようと考えた。日本語情報が少ないため(あっても多少古かったりすることが多かった)、情報をかき集めるのに相当苦労したが、夏休みが終わるころにはjupyter notebook(名前通りノートブックのような実行環境セルごとにコードを実行するという形をとっている)上で統計処理をしたりそのデータを基にグラフプロットするのはある程度できるようになっていた。

早速2年後期の実験pythonを試してみたが、その威力は凄まじく、今まで時間のかかっていた作業が劇的に効率化した。pythonモジュールであるpandas,numpyを使えばデータ列を文字式のように扱えるので(例えば実験データをdataとして、そのデータをすべてcos関数に代入したかったらnumpy.cos(data)と書けばよい、Excelと似たようなものだがこちらは変数として扱っているので使いまわしが容易である)、Excelでちまちま関数セル入力して列全体に引き伸ばすという操作もしなくていい。グラフコマンドで出力するので当然だが今まで苦労していた手書きプロット作業はなくなった。GUIありきのExcelと違ってコードひとつグラフの罫線の調整などもかなり簡単にできる。高級言語だけあってコードは組みやすく、実験中に即興プログラムを組むことも割りとできる。しかコードさえ組んでしまえばあとは実行するだけで計算グラフの描画を一気にやってくれるので、実験結果確認が極めて素早く行えるようになった。しかもjupyter notebookはmarkdown形式文章を埋め込めてメモ書きも残せるし、mathjaxに対応しているのでlatex形式の数式も途中に挟むことが出来る。最高の環境だと思った。しかし良いことばかりではなかった。

パソコンで全部やろうとする自分を見た一部のTAはなぜか自分グラフ手書きしろ要求してきた。自分反論した。「グラフならパソコンですでに出力できているのになぜわざわざ手書きにする必要があるのか?」これに対するTAの答えはだいたい「平等性を保つため」、「他のみんなは手書きでやっている」、「理解を深めるため」、「他学科手書き必須から」というような感じである自分にとっては、これらすべてが理解できなかった。そもそも手書きにすることによって実験に対する理解がどう深まるというのか?自分はむしろ手書きを徹底的に排除することによって、煩雑作業をする時間を考える時間に充てた。そのおかげで実験に対する理解は以前と比べ物にならないくらいに深まった。手書きじゃなければ理解が深まらない理由はない。そもそもパソコンのほうが厳密にコードを組まなければならない分だけ理解力要求されるはずである。「理解を深めるため」といっている本人だって結局その言葉意味もわからず言っているにすぎない。

平等性」に関しては全く別のTAから複数回言われた。「パソコンを使って効率化しようとするのはずるい」と言いたいのか、このTAは?pythonだって1ヶ月間死に物狂いで情報をかき集めて覚えたのに、それのどこがずるいというのだろう。平等性を掲げて効率化を否定し、全員に同じ作業強要させ、「成績」をちらつかせて脅すのはずるくないのか?みんな一緒に抑圧されましょうということか?これを言われたときに感じた何とも言えない吐き気のようなものは今でもうっすらとだが覚えている。正直なところ、プログラミングが出来るというだけでむしろ褒められると思ったのだ。パソコンが使いこなせるほうが印象はいいに決まってると思っていたのも、結局は自分勘違いだった。

pythonを使い始めてからの2年後期、3年前期を通して4,5回ぐらいTA(全員別の人)に「手書きしろ」と言われたが、言われるたびに反論するのもいい加減に疲れてきた。なぜ手書きにする必要があるのか、自分は聞かれるたびにこう聞き返した。まともな答えを返したTAは一人もいなかった。大学先生担当する実験PCは駄目なんて言われたことは一度もなかったし、どうもTA勝手に「手書きしろ」と言っているだけらしい。「他学科パソコン禁止から」とかいう非論理的ルール鵜呑みにしてそれを適用しようとする姿勢にも無性に腹が立った。

TAがいうには手書きコピペ防止の意味もあるらしい。本当に手書きにしたらコピペが減るのか?パソコンにしたらコピペが増えるというが、それは果たして本当に「増えた」のだろうか?確かにコピペするのは手書きと違って簡単だが、コピペするやつは手書きだろうがパソコンだろうがコピペする。そもそも自分の頭で文章を書く能力がないかコピペするのであって、パソコン制限たかコピペがなくなるという理屈おかしい。そんなにコピペが嫌だったらむしろ最初からコピペをチェックしやす電子データに限ってしまえばいいと思う。パソコン有りにしてコピペが増えたというのは、手書きレポートでは見逃していた分のコピペがばれて、それで数が増えたように見えたという可能性もある。むしろパソコンからこそコピペを見破れるのではないだろうか?

自分は、手書き不正の温床ぐらいに思っている。手書き場合見かけ上はコピペしたことがばれにくいし、グラフもそれっぽく適当に書いても適当プロットしたことはほぼばれないし、そもそもアナログデータ機械検閲にかけにくいためどの程度コピペなのかを判定する労力だって膨大過ぎる(別のTAに話を聞いたところ、採点する側から言わせるとコピペしたこと自体結構分かるものらしい)。手書き強制するということは、すなわち不正ごまかす余地を与えているに過ぎない。本気でコピペをなくそうとするならば、いっそのことすべて電子化してしまったほうがよいとすら思う。

pythonを使い始めてから1年経ち、「手書きにしてください」と言われるたびに反論していったが、元々自己主張の弱い引っ込み思案なタイプのために、自己主張してちゃんと言い返すというのは精神的な負担が大きかった。「パソコンではなぜ駄目なのか」を強く主張するたび、ものすごく疲れがたまってしまい、実験がない日でも「なぜこんな当たり前のことをわざわざ言わなければならないんだろう」と思い返してしまうせいでどんどんやる気を無くしていった。

なぜ大学の一部にはパソコンを使わせたがらない空気があるのだろう。この人たちは、手書きが苦手な自分にとっての最後の砦すら壊すつもりなのだろうか。なぜ手書きにこだわるのだろうか。

2016-09-14

色々試したがMarkdownは使いものにならないとわかった

markdownエディタが増えてきたのでメモ代わりになるかと使っているけど、いざそれを目的の形に変換しようとするとゴミだらけになってしま

結局、HTMLTeXを素で書いていたほうがはるかに楽だった

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-21

http://anond.hatelabo.jp/20160521163144

React.js界隈の人に聞きたい

http://anond.hatelabo.jp/20160521163144

最近某所で、React使うとjQuery不要だ的なタイトル記事を書いちゃた気がするので一応反応しときます。長文ごめんね。

えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQuery不要」「jQueryは要らないこともある」と長く書いた方が正確です(本文ではちゃんとReactが万能ではない説明をしてる)。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。

そもそも世の中にそんなにSPAがあるのか

世の中の絶対数は知りませんが、自分脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、<input type="hidden">とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。

というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAから使いづらい」という主張はよく分かりません。GitHubTwitterサイトSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは(Reactではないけど)SPAで、ブラウザMarkdownレンダリングしていますhttp://webpack.github.io/docs/ )。サーバサイドで動くスクリプトタスクゼロ個人的にはこういう使い方で十分嬉しいです。

何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります自分中の閾値としてはJSコードが数百行超えるならもうReact使う。

JSXを使うことに抵抗ないんですか?

んー、要するに「別物であるDartCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか? 正直その主張を聞いたのは初めてです。歴史的JSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。

JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしていますJSXは「関数呼び出しのシンタックスシュガーJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います仮想DOM思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています

はい所詮JSXシンタックスシュガーなので、使いたくないなら使わず本来関数スタイル仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。

それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレート仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います

5年後のビジョンがありますか?

Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。

Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています個人の感想です)。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2~3年待てばよいと思います

保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います

2016-05-07

無理だと分かっているけど増田に追加してほしい機能

Markdownで書けるようにすること。(可能ならgithub flavored markdownで)

普段はてなブログで書いててMarkdown使用する機会も多いので、記法を覚えるコストを極力少なくしたい。

はいっても、増田って多分レガシー構成してるし、そもそも増田実験プロジェクトのままだし、はてな上場しちゃったから「増田機能を追加」とかい地雷をわざわざ踏みに行かないだろうなって思って諦めてる。

http://anond.hatelabo.jp/20160507163959

読みなおしてみたら、元の記事には英語とか海外とかぜんぜん書いてないね

markdown海外発祥で「日本の」ってわざわざ書いてあるから海外メールとの比較してるって脳内で補完してたわ。

たぶん「markdown海外メールと同じような書き方だから広まった」でいいと思うけど。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん