「リポジトリ」を含む日記 RSS

はてなキーワード: リポジトリとは

2019-01-18

俺流C言語の書き方

2019-01-12

GitHubプライベートリポジトリをただにしたけど、たとえユーザー側の利であっても、怖いと感じた。

大企業簡単プランを変更する事ができるのは、逆に業績が悪くなったらもの簡単にバッサリと切り捨てられることも意味している。

2018-12-18

[][][] phpMyAdminの手動インストール

WebサーバーPHPを5.4から7.2に上げました。

phpMyAdminも入れ替えました。

 

環境CentOSNginxPHP7.2 + MySQL

yumコマンドphpMyAdminをインストールしたら、エラーメッセージが出て、インストールできませんでした。

リポジトリで用意されているパッケージが古いのか?何度かやり直しても、yumインストールできませんでした。

 

手抜きを諦めて、手動でインストールすることにしました。

phpMyAdmin インストール コンパイル Nginx」等のキーワードGoogle検索すると、やり方を解説している記事がたくさんヒットしました。

参考

 

手順

  1. WebサーバーSSHリモートログインする。
  2. phpMyAdminの最新版wgetダウンロードする。
  3. ZIPファイルを展開して、フォルダ名を「phpmyadmin」にリネームする。
  4. /usr/share/phpmyadmin にコピーする。
  5. phpMyAdmin用に、Nginx設定ファイルを追加する。
  6. PHP7のセッションフォルダ確認しておく。
    1. PHP関係設定ファイルphp.ini」や、PHP-FPM設定ファイルwww.conf」の中を確認しておく。
    2. session.save_path = "/var/lib/php/session" という記述有効にする。(コメントアウトされていたら、アンコメントしておく)
  7. Nginx設定ファイルテストして、問題なければ再起動する。
    1. $ service nginx configtest
    2. $ service nginx restart
  8. WebブラウザーでphpMyAdminにアクセスしてみる。
  9. phpMyAdminが無事に開いたら、インストール成功!!!

 

まとめ

phpMyAdminは手動でインストールしても、すごく簡単でした。

将来的にバージョンアップすることも考えると、「/usr/share/phpmyadmin」へ直にコピーするのではなく、他の場所コピーして、「/usr/share/phpmyadmin」はシンボリックリンクにしておけばいいかも。

(今回は面倒なので直接コピーしました。)

2018-10-30

【試した環境2】 Ubuntu 17.10 64bit



1. 作者が用意したスクリプト 01downloads の apt install 部分で修正必要なようです。

 emacs24 はリポジトリになかったので,代わりに emacs25 を入れました

 gcc-4.9, g++-4.9, cpp-4.9 はリポジトリにありません。

2. CASINO の makeエラーが出る

 エラーを見るとFortranで止まっていたので,入ってないのかな?と思って調べたら(Synaptic パッケージインストーラにてgfortran検索した),入っていませんでした。おそらく,gcc4.9が入らなかったからだと思います

 gfortran, gfortran-doc, gfortran-multilibをとりあえず入れてみたら動きました。(ついでにgfortran7類も入ったようです)

2018-10-14

anond:20181014212127

ほとんどの理由プラグインやらとの依存関係や。

んでCentOSバージョンでもまた内容が変わって、

Yumインストするリポジトリも違って、って

ひとつひとつ潰していくのがもうとにかくめんどくさい。

そりゃConoHaとかでもRedmine最初から入ったVPS提供するわ。

何度もやりたくない。

2018-09-22

公的文書git管理したところで

リポジトリ作り直されて,文書作成日とリポジトリ作成日の順序おかし問題が頻発するだけだな

2018-09-10

弘法は筆を選ばずの格好良さに憧れて迷走

大坂なおみの優勝で、ラケット市販の物というので、かっこいいなって思った。

この弘法は筆を選ばず的なかっこよさについつい憧れてしま

エースパイロットでもカラーリングだけ違うけど量産機乗ってるみたいなキャラがいい。

昔、BackTrackというペネトレーション特化型のLinuxディストリビューションがあったでしょ

それはKali linuxが後継になったんだ。

ペネトレーションテスト向けOSってニッチな奴だけど

ワナビーは憧れてた人が多かったんよ

なんか中二心をくすぐる雑誌とかで紹介されたりしてさ。

で、痛い話なんだけど

kali linuxに取って代わったあとも

BackTrackっていう名前はかっこいい名前のまま憧れててさ

そのワナビーコミュニティの中では、時代kaliみたいな雰囲気になってたんだけど(皆ちゃんと使いこなせてないけど)

「俺は使いやすいからあえて古いBackTrack使ってっから」って言ったりしてさ

完全のあれよね。古いシステムだけど技でそれを補う的なストーリー演出してたよね。

実際はリポジトリも閉じちゃってバージョンアップできないし、カーネルバージョンも何年も前のやつで止まってるのよね

でもそんな実際的不具合は使いこなせてないからわかんないわけよ。

ぶっちゃけOpenSSLとか古いまんまだから、当時の新し目の暗号スイート使えないしさ。他にもブラウザも古いしさ。

自分脆弱性満載のままで使ってるわけよね。

ペネトレーションテストするOSペネトレイタブルな状態ってすごい恥ずかしいよね。

まあ、当時はそんなのもわかるはずもなく、間違ったかっこいい演出しちゃたけど、あれは笑われてたなと思うよ。

はじかしぃ

冒頭の大坂なおみとは全然関係ない話になっちゃったけど、昔話思い出しので、吐き出しといたよ

2018-07-24

高齢者ほど運転に自信があるグラフについて少しだけ調べてみた話

https://twitter.com/spirited112367/status/808706652174065664

ネットで出回っているこのグラフ。おそらく同じものが何度も色々なテレビ番組採用されている。これは立正大の所正文教のもの

ご本人も複数テレビ番組に出演したり取材に答えたりしたものがあるようだ(例:http://www.ris.ac.jp/whatsnew/2014/20140707_1.html http://www.ris.ac.jp/whatsnew/2014/20150129_02.htmlなど)。

さて、このグラフ、いつどのようにして集めたものなのだろうか。ご本人に問い合わせるのが正攻法なのだと思うけれど。

超高齢社会自動車交通[PDF形式] http://www.kokusen.go.jp/wko/pdf/wko-201611_04.pdf にも同グラフをご自身使用されており、そこには出典として「所正文(2001)「高齢ドライバー運転適性プロジェクト報告書茨城県交通安全協会」とある

これを実際に読めれば一番いいと思うところ、茨城県交通安全協会に問い合わせると何かわかるかもしれないのだけど、ヒントは

https://kokushikan.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=9295&item_no=1&page_id=13&block_id=21 国士舘大学 学術情報リポジトリ わが国における高齢者の交通事故の増大とその対策に関する一考察 にあった。

引用

筆者はI県警察本部の協力を得て、高齢者講習を含めた運転免許更新時講習の際に、筆者が思案した質問テストを2,354名の一般市民ドライバー実施した。質問テストの内容、および回答様式は、前節の研究(1)に準じている。被験者の年齢属性は、75歳以上656名、50歳以上74歳以下716名、50歳未満962名である

引用ここまで

I県は他の資料と突き合わせる限り、茨城県のものと考えて差し支えなかろう。2000年頃に茨城県で、運転免許更新対象者の中で何かしら抽出された対象者実施された調査と考えられる。

この時点で、この調査が「免許更新を辞退した人」は含まれないことが明らかになる。高齢免許更新しない人は運転に自信のない人の割合集団全体から見て高めである可能性は普通に考えられる。それを緻密に推し量るデータを私は知らないが、関連として参考にできそうな数値が先ほどのpdfにある。

高齢者の運転免許保有率の変化の表だ。1991年1999年について、65-74歳と75歳以上の保有率が示されていて、おおざっぱに言えば、高齢者の運転免許保有率はこの二つの年の間で見るからに上がっている。(この推移も最新のデータを引いてくると参考になりそうなのだけどまだやっていない。誰かやって)。

高齢ドライバーの自信の高さ」について、「大なり小なり自信のない人の方が免許更新しない事に依るバイアスが働いている可能性があるのでは」とは思うのだけれども、それがどの程度なのかはまるで調べられなかった。一方で、前述の論文では高齢者が自信を持つ傾向にあるのは心理学研究で知られているなどとして傾向の存在は前提として分析している。その他、https://matome.response.jp/articles/818?utm_source=twitter&utm_medium=social でも高齢者の自信が高い傾向は出ているようだ(詳細はグラフ参照のこと。アンケート信憑性関係する分析はまったく私は行っていない)。それよりはまだ分析に使えそうなデータは「高齢ドライバー・激増時代:交通社会から日本を変えていこう(2007)所正文」にあった。2005-2006年に全国から計7カ所のやはり免許更新の講習時に行った調査でも「運転への自信」への調査結果は類似した結果になったことが書かれている(運転への自信は危機回避の自信とは質問項目がことなっており結果の値も異なることに注意。高齢者ほど高い傾向自体類似だが)。

誰かもっと詳しく検証してほしい(しかし、高齢者の運転という問題のものに関心があるなら、前述の教授の著書はまず買って全部読め、氏の論文も、などと思わなくもないがそれはそれとして)

2018-06-05

anond:20180605113805

いきなり共有リポジトリコミットされちゃうの怖くない…?

1日で終わるような作業ばかりならローカルコミットできなくてもいいけど

2018-05-16

Githubの公開

ソフトウェアエンジニア転職する時、「Githubコードを見せてください」って促されるけどさ、

周りに使ってもらうライブラリだったらいいと思うのよ。ただ個人で開発してる自動取引とか、公開したくないソースコードプライベートGithubに上げてる場合はどうなるの?

プライベートリポジトリ無料で利用できて、かつreadOnlyの設定ができるバージョン管理システムってないの?

2018-05-15

ライブラリソースリポジトリに含めるか否かの規則

npm, bundler, CocoaPods など、言語によってライブラリ管理ツールは多数ある。

しかし取得したライブラリソースリポジトリに含めるか含めないか公式見解はまたそれぞれ違う。

そしてそれぞれもっともらしいことを言うのだが、それらは詭弁であって、結局この規則に基づいているだけに過ぎない。

2018-05-12

文系研究者の文献の電子化自炊)についての質問

はてなにどのくらいの文系研究者がいるのだろうか。文系というコトバはあまり良くないが、真意は伝わると思う。

筆者は、歴史特に考古学)を専門とする大学院生だ。査読誌が少ないという学問的な背景もあってか、考古学に限らず歴史学全体でオンラインジャーナルリポジトリの整備が遅れている。

奈文研の全国遺跡報告総覧という優れた取り組みや、第四紀研究などいくつかの雑誌ではオンラインジャーナルが整備されており、全く進んでいない訳ではない。

歴史学に限らず、文系研究者に聞きたい。

文献を電子化自炊)したいと思ったことはありますか?

電子化した理由、しなかった理由はありますか?

その他、文系研究者に限らず、研究者の文献の電子化自炊)についての意見があったら教えてほしい。

本を裁断しようかどうか、非常に迷っている。

2018-04-01

anond:20180317205336

無駄コミュニケーションを省ける

リポジトリは何で管理してるんですか?」「ローカルに立てたSVNですね」「なるほど、帰ります

みたいな

2018-03-22

N予備校プログラミング入門コースを修了した

https://anond.hatelabo.jp/20170911110731

昨年、はてブでバズりまくったエントリにまんまと乗せられた実務経験なしのプログラミング初心者

N予備校プログラミングコースプログラミング入門 Webアプリコース(有料のプログラミングコースで一番最初にやるコース)を修了したので知見をまとめておきます

とりあえず結論

そんな感じです。以下、理由

経験者の独学はほぼ無理。

客観的データをあげると、

入門コース実践編となる3章からは各講義最後課題が出されて、

N予備校GitHubリポジトリにプルリクエストを出すことで課題の提出に変えて、

学習を進めていくのですが、

3章最初課題の提出数は現在424件あるのですが、

https://github.com/progedu/intro-curriculum-3001

入門コースラストの4章最後課題の提出数は現在24件です。

https://github.com/progedu/intro-curriculum-4023

ちょうど動画ベースの講座がこないだ終わったところなので、

単純に計算すると脱落率約95%となっています

課題は解答をコピペして提出することも可能なので、

ちゃんと内容を理解できている人の割合さらに低いと思われます

なんで?

なぜそんなに脱落していくかというと、まあ難易度だったり色々あるとは思うのですが

基本的には説明不足ということだと考えています

~をするにはこういうプログラムを書けばいい!ということは教えてくれるのですが、

なぜ、こういうプログラムを書けば~ができるのかということについての説明が少ないです。

感覚としては、途中の式と解答だけが書いてある数学参考書を読み進めているような感じで、学習者には途中の式の意味自力で読み解く能力が求められます

その過程ドキュメントをあたったり、自ら調べて解決する能力必要です。

またアロー関数式だったり、三項演算子論理演算子を用いた代入などの省略記法を多用する割にソースコード中にほとんどコメントを書かないことも初学者には難しいかなと感じました。

体系的な学習にも不向きです。

あとオブジェクト指向説明をせずに、JavaScriptオブジェクトを扱っていたり、

データベース学習をする前に、MVCパターンを扱っていたり、ちぐはぐさを感じるところも多かったです。

ということで(他にもいろいろあるのですが)、未経験者が独学で進めていくのは厳しいんじゃないかな~というのが入門コースを終えての結論です。

たとえば保護者の方が専門のエンジニアで分からないことがすぐに聞けるような環境にあればよい教材になるかもしれません。

初心者が中級者へステップアップするきっかけになる可能性はある。

ただ中級者へのステップアップを目指している初心者きっかけをつかむには良い教材になりえるとも感じました。

私自身、GitHubLinux(Ubuntu)、Node.jsExpressフレームワークなど、自主的にはなかなか食指が動かなかった分野の知識を得ることができたと思います

難易度は高いですが、中級者向けのまとまった教材というのはネット上にもあまりないと思いますので、ある程度経験のあるプログラマ知識を深めるために利用するのはありだと思います

それでも体系的な知識が得られるかというと微妙ですが…。

ちゃん勉強しようとするとかなり時間必要

ただ社会人学習を進めるにはまとまった時間の確保というのがネックになるとは思います

N予備校の入門コースの想定学習時間は180時間だったと思いますが、私はこのコースを修了するのに400時間前後かかったと思います

(今年の1月初頭からほぼ毎日午後を勉強時間に充てて、ようやく昨日入門コースを修了しました)

コースを終わらせることだけを目標にするならもっと短くできるとは思いますが、ある程度知識をつけて今後にいかすことを目標にするとなると、想定学習時間内でコースを終わらせるのは難しい気がします。

これから学習してみようと思っている方へ

色々書きましたが、それでも月1,000円というのは破格の価格設定だと思いますので、気になっている方は挑戦してみてもよいのではないでしょうか。

おすすめ学習方法としては

などがおすすめです。 「「分かりそう」で~」のサイトには本当にお世話になりました。m(_ _)m

ただ特にプログラミング経験の浅い方に伝えたいのですが、N予備校の入門コース理解できなかった、挫折たからといって、プログラミングができないということはまったくないです。

私自身、SEプログラマとしての実務経験はありませんが、趣味でも仕事でもガンガンプログラム活用しています

それでもN予備校の入門コースの内容は相当難しかったです。

ぜひ挫けずにプログラミング学習を続けていただきたいなと思っています

あとネット上にはN予備校プログラミングコースレビュー散見されますが、無料コースしかやってないんじゃないかなーというものが多いのでお気をつけください。

基本的無料コースと有料コースは別物と考えたほうがよいと思います

参考になれば幸いです。

ところで、N予備校ニコニコ動画再現コース2017年度中公開予定になってるんですけど、本当に公開されるんですよね・・・?(※)

3/31 追記 ※ギリギリでしたがちゃんと公開されたようです。退会してから気づいたので内容はわかりません。

2018-02-23

anond:20180223133023

例えばpublicなgithubリポジトリでそんな言葉残すやついる?

クソクソ言うのはリーナスとかの影響じゃないのか

anond:20150419125822

「気が狂った設計」「クソコード

ここら辺のワード会社によっては普通にパワハラに当たると思うけどなあ

だってファジーな上に悪口もの

自分経験から言うと、そう言うコメントを残すリーダーは大体下から突き上げで降ろされてた。

辛いと感じたり違和感を感じるのはまともな価値観を持っている証拠だと思うよ。

例えばpublicなgithubリポジトリでそんな言葉残すやついる?

会社からって言っていいわけじゃない。

2018-02-18

Github Educationって期限切れても新しいプライベートリポジトリが作れないだけで既存のやつはそのまま使えるのか・・・太っ腹すぎる

2017-12-31

きれいなコードを書くのはやめた

きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。

そうずっと教えられてきたし努力してきた。

でも、もうきれいなコードを書くのはやめることにした。


業界2位のミドルウェアが、、1990年代タイムスリップたかのような継承拒否した継承構造で書かれていた。

世界的なOSSで3桁や4桁のスターがついているリポジトリコードは、コピペの嵐。巨大なマージコミットやFワード入りのコミットメッセージ

有名なスタートアップCTOコードは、メタプログラミング黒魔術の塊だった。

リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。

でも、それはコピペまみれで、巨大のコミットの汚いコードからできる。

自分バグのないきれいなコードを書くように心がけている。

同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。


優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコード要求する。

ダブルスタンダードだ。

他人きれいなコード要求するのは、他人コードを読む時間を短くするためなのだろう。


優秀なプログラマになるために、私もきれいなコードをかくのはやめにすることにした。

2017-12-20

勉強中のノート作りが目的になっている人

ググればwebに書いているし、理解たことはブログにまとめればいいし、検証コードgitリポジトリにいれればいいのにどうして紙にまとめようとするんだろう。

紙にまとめたとしてもおそらく理解はできていなさそう。丸暗記しているように見える。

こういう人は、脳の使う癖がそのようになっているから、外部からどう言ったって変わらないと思う。

実務ができなかったら意味がないのに。

自分のことだけを考えようと思う。

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2017-10-24

なんで未だに 5.4 なんだよ!

PHP のはなし

ウチでは centos を使うことになってる

今だと centos7 だが、これのデフォルトPHPが 5.4 だ

5.5, 5.6, 7.0, 7.1 とでていて、 7.2 がもうすぐとか言われてるのに、 5.4 だ

5.4 が出たのは 2012 年で公式サポートは 2015 年に終わっている

そんな古いもので、使える機能ももちろん古いのだけだ

新しい機能を使おうとしたらエラーになる

もちろんライブラリフレームワークですら対応してないのが多くて古いものしか使えない

さらには、古いバージョンではバグ脆弱性が見つかってもそもそも PHPバージョン自体サポート切れなので放置される

PHP7 や 5.6 対応バージョンにすれば直っているが 5.4 で動くものだと直されない

centos に 7 系を入れることはできなくはないし、難しくはない

だが、デフォルトバージョンを使うことになっている

聞くところによると、保守OSサポートが切れる頃まではすることになっているものが多く、外部リポジトリや自前ビルドになるとサポートが辛いらしい

今 7.1 にしても、その外部リポジトリはウチの保守期限より早くサポートをやめるのでその後の脆弱性などのパッチ自分でどうにかしないといけなくなる

デフォルトのものなら緊急性があれば 5.4 であろうと OSサポートしているためパッチ対応されるらしい

外部リポジトリサポート終わったらバージョン上げればいいじゃない、って思うけどけっこう動かなくなる部分があるらしい(経験談によると)

プロジェクトが大きくなるとチェックと修正がすごく大変なんだろう、そのためのテストじゃないの?って言いたいけど

自社サービスじゃないしクライアントから人件費取るのが難しいとかあるんだろうな、たぶん

そんなこんなで 5.4 を使うらしい

ライブラリ面で苦があるから、自社製ライブラリも多い

OSSライブラリで何が使えてどれを使ってはいけないか、みたいのはコア部分の開発メンバーには知見が溜まってるらしいが、私はそんな将来に役立たないものより 7 系とか新しいもの知識が欲しい


せめて JavaScript の Babel のようなものがあればなぁ・・・ブラウザは使う側の問題で古いのまでサポート必要だが、サーバサイドは新しいの入れればいいだけなので需要がなくて作られないのだろうなぁ

2017-09-24

anond:20170924204251

(またしょうもない教材のステマに利用されて伸びそうなやつだ)

俺は学生の頃からプログラマとして活動してたけど

自頭の良いハイスペックな連中に自尊心が傷つけられる事があり辛みを感じてるよ。

なるべく早く、一つでも二つでも己のプロジェクトオープンソース世界に置いて

リポジトリメンテしてもらうまでの場所を作りなさい。

そういう居場所を作る気概もなく、技術を追いかけるのが苦痛だってんなら

上流を目指して人間を統率する力を日々磨くしかない。

2017-09-21

Javascript 好きなやつって頭おかしくね

なんであんなプアな言語仕様で頑張ろうと思えるのか

最新と言われるES6, ES7にしたって、他の言語からしたらありえないほどに機能が少ない

こんなクソみたいな言語を書いていたら、エンジニアとしての腕が鈍るのではないかと思うほどにクソい

いまは仕事JSを書いているのだけれど、Rubyだったら、Pythonだったら、KotlinだったらSwiftだったらと思わない日ない

驚くのは、こんなクソみたいな言語なのに、好きな人が多いってこと

ReactNativeだとかflowだとかTypeScriptだとかbabelでtranspileなんじゃとかい記事をみない日がない

それだけ好きモンが多いんだろう

JSというブラウザによって取り残された言語へのキャッチアップに多くの時間を割いてしまったがために、

心理的な負荷がかかって俺はJSが好きなんだこれしかないんだとなってしまっている人が多いんじゃないかとかわいそうに思う

JSマンで他の言語かける人って、他の言語と比べて極端に少ないように思う)

クソみたいな言語のくせにnodeのリポジトリお家騒動みたいなんでしょっちゅう盛り上がってるし

JSなんてなくなりゃあいいと思う

あと、好きなやつらはしょうもない言語だってことを認めろ

俺はJavaが好きだけどJavaがクソみたいな言語だってことは認めている

だが、バカな息子をそれでも愛そうの精神で頑張っている

お前らも、そう思えよ

何がES6ならモダンな感じでかけてチョベリグですねだよ

アホか

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