  |
はてなキーワード: リポジトリとは
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カ所のやはり免許更新の講習時に行った調査でも「運転への自信」への調査結果は類似した結果になったことが書かれている（運転への自信は危機回避の自信とは質問項目がことなっており結果の値も異なることに注意。高齢者ほど高い傾向自体は類似だが）。
誰かもっと詳しく検証してほしい（しかし、高齢者の運転という問題そのものに関心があるなら、前述の教授の著書はまず買って全部読め、氏の論文も、などと思わなくもないがそれはそれとして）
はてなにどのくらいの文系研究者がいるのだろうか。文系というコトバはあまり良くないが、真意は伝わると思う。
筆者は、歴史（特に考古学）を専門とする大学院生だ。査読誌が少ないという学問的な背景もあってか、考古学に限らず歴史学全体でオンラインジャーナルやリポジトリの整備が遅れている。
奈文研の全国遺跡報告総覧という優れた取り組みや、第四紀研究などいくつかの雑誌ではオンライン・ジャーナルが整備されており、全く進んでいない訳ではない。
その他、文系の研究者に限らず、研究者の文献の電子化（自炊）についての意見があったら教えてほしい。
本を裁断しようかどうか、非常に迷っている。
https://anond.hatelabo.jp/20170911110731
昨年、はてブでバズりまくったエントリにまんまと乗せられた実務経験なしのプログラミング初心者が
N予備校プログラミングコースのプログラミング入門 Webアプリコース（有料のプログラミングコースで一番最初にやるコース）を修了したので知見をまとめておきます。
そんな感じです。以下、理由。
入門コースの実践編となる３章からは各講義の最後に課題が出されて、
N予備校のGitHubリポジトリにプルリクエストを出すことで課題の提出に変えて、
学習を進めていくのですが、
https://github.com/progedu/intro-curriculum-3001
https://github.com/progedu/intro-curriculum-4023
ちゃんと内容を理解できている人の割合はさらに低いと思われます。
なぜそんなに脱落していくかというと、まあ難易度だったり色々あるとは思うのですが
～をするにはこういうプログラムを書けばいい！ということは教えてくれるのですが、
なぜ、こういうプログラムを書けば～ができるのかということについての説明が少ないです。
感覚としては、途中の式と解答だけが書いてある数学の参考書を読み進めているような感じで、学習者には途中の式の意味を自力で読み解く能力が求められます。
その過程でドキュメントをあたったり、自ら調べて解決する能力が必要です。
またアロー関数式だったり、三項演算子や論理演算子を用いた代入などの省略記法を多用する割にソースコード中にほとんどコメントを書かないことも初学者には難しいかなと感じました。
体系的な学習にも不向きです。
あとオブジェクト指向の説明をせずに、JavaScriptのオブジェクトを扱っていたり、
データベースの学習をする前に、MVCパターンを扱っていたり、ちぐはぐさを感じるところも多かったです。
ということで（他にもいろいろあるのですが）、未経験者が独学で進めていくのは厳しいんじゃないかな～というのが入門コースを終えての結論です。
たとえば保護者の方が専門のエンジニアで分からないことがすぐに聞けるような環境にあればよい教材になるかもしれません。
ただ中級者へのステップアップを目指している初心者がきっかけをつかむには良い教材になりえるとも感じました。
私自身、GitHub、Linux(Ubuntu)、Node.js、Expressフレームワークなど、自主的にはなかなか食指が動かなかった分野の知識を得ることができたと思います。
難易度は高いですが、中級者向けのまとまった教材というのはネット上にもあまりないと思いますので、ある程度経験のあるプログラマが知識を深めるために利用するのはありだと思います。
ただ社会人が学習を進めるにはまとまった時間の確保というのがネックになるとは思います。
N予備校の入門コースの想定学習時間は180時間だったと思いますが、私はこのコースを修了するのに400時間前後かかったと思います。
（今年の１月初頭からほぼ毎日午後を勉強時間に充てて、ようやく昨日入門コースを修了しました）
コースを終わらせることだけを目標にするならもっと短くできるとは思いますが、ある程度知識をつけて今後にいかすことを目標にするとなると、想定学習時間内でコースを終わらせるのは難しい気がします。
色々書きましたが、それでも月1,000円というのは破格の価格設定だと思いますので、気になっている方は挑戦してみてもよいのではないでしょうか。
などがおすすめです。 「「分かりそう」で～」のサイトには本当にお世話になりました。m(_ _)m
ただ特にプログラミング経験の浅い方に伝えたいのですが、N予備校の入門コースが理解できなかった、挫折したからといって、プログラミングができないということはまったくないです。
私自身、SEやプログラマとしての実務経験はありませんが、趣味でも仕事でもガンガンプログラムを活用しています。
ぜひ挫けずにプログラミングの学習を続けていただきたいなと思っています。
あとネット上にはN予備校のプログラミングコースのレビューも散見されますが、無料コースしかやってないんじゃないかなーというものが多いのでお気をつけください。
基本的に無料コースと有料コースは別物と考えたほうがよいと思います。
参考になれば幸いです。
ところで、N予備校のニコニコ動画再現コースが2017年度中公開予定になってるんですけど、本当に公開されるんですよね・・・？（※）
きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。
そうずっと教えられてきたし努力してきた。
業界2位のミドルウェアが、、1990年代にタイムスリップしたかのような継承拒否した継承構造で書かれていた。
世界的なOSSで3桁や4桁のスターがついているリポジトリのコードは、コピペの嵐。巨大なマージコミットやＦワード入りのコミットメッセージ。
有名なスタートアップのCTOのコードは、メタプログラミング黒魔術の塊だった。
リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。
でも、それはコピペまみれで、巨大のコミットの汚いコードだからできる。
同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。
優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコードを要求する。
他人にきれいなコードを要求するのは、他人のコードを読む時間を短くするためなのだろう。
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
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 のようなものがあればなぁ・・・ブラウザは使う側の問題で古いのまでサポート必要だが、サーバサイドは新しいの入れればいいだけなので需要がなくて作られないのだろうなぁ
最新と言われるES6, ES7にしたって、他の言語からしたらありえないほどに機能が少ない
こんなクソみたいな言語を書いていたら、エンジニアとしての腕が鈍るのではないかと思うほどにクソい
いまは仕事でJSを書いているのだけれど、Rubyだったら、Pythonだったら、KotlinだったらSwiftだったらと思わない日ない
驚くのは、こんなクソみたいな言語なのに、好きな人が多いってこと
ReactNativeだとかflowだとかTypeScriptだとかbabelでtranspileなんじゃとかいう記事をみない日がない
それだけ好きモンが多いんだろう
JSというブラウザによって取り残された言語へのキャッチアップに多くの時間を割いてしまったがために、
心理的な負荷がかかって俺はJSが好きなんだこれしかないんだとなってしまっている人が多いんじゃないかとかわいそうに思う
（JSマンで他の言語かける人って、他の言語と比べて極端に少ないように思う）
クソみたいな言語のくせにnodeのリポジトリはお家騒動みたいなんでしょっちゅう盛り上がってるし
俺はJavaが好きだけどJavaがクソみたいな言語だってことは認めている
お前らも、そう思えよ
アホか
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
学習してから３日目ぐらいだけど連続３日でやったとは言っていない。
他のプログラミング言語と違ってチュートリアルの内容が足りないってこともなさそうだし、Golangのチュートリアルだけは繰り返しやったほうが良さそう。
今からGolangを学ぶならGoogleのリポジトリにあるパッケージ管理にdepを使うほうが安心する。
まだ公式ツールじゃないけど将来なるかもしれないしならないかもしれない。
Googleのことだからgxuiみたいに更新されなくなる危険もあるよな・・・・
でもプロジェクトを新規作成するときにrails new helloに相当するコマンドがないので不便。
スケルトン生成ツールが別途必要だけどフォルダ作るだけだからbatファイル用意するだけで良さそう。
あとGOPATHの設定もか。今のところは手動でやってるけどそのうちbatファイルにしたい。
でもやりたいことができないのがつらい。
cursesぐらいは標準で出来て欲しいよ。
だから他の言語ではいらないのにGolangではそんなことでもライブラリを探してきてインストールしないといけない。
Goglandだとそのままでも十分だけどVimの場合はvim-goを入れるのが良い。
勉強会に参加するときは軽量ノートを持っていくので動作が軽いVimがいい。
でもryzen搭載ノートが来たらIDEに乗り換えるかもしれない。
cliってライブラリもあるみたいだけど標準機能のflagだけで十分便利。
今の所もあんまりコマンドラインツールに興味ないので難しいことはしない。
やりたいことをぐぐってコピペしてる程度なのでdeferとかgo funcとかグローバル変数とか基礎的な部分はまだ知らない。
インストールが楽だけどWindows作ったらMacでも動くかは謎。
MacのハードウェアにしかMacのOSインストールできないライセンスだからWindows PCにMacインストールできないからapple嫌い。
gitとか
一番最初のルート部分を別にしてコミットしておいて、別ブランチに変えたら普通気づかれない。
エクスプローラや検索ツールでファイル名検索しても出てこない。
わざわざリポジトリのログまで探すことはないだろうけどたまたま見たときにわかることがないように、大きなリポジトリをクローンしてきてそこにいれるとかありかも。
Chromium みたいな大規模ならログ一覧をざっとスクロールしてもまずみつからないはず
ブランチ消して reflog だけに残すという手もありかも。
さらにファイルを resources.zip にまとめておいて「圧縮した」みたいなコメントだと一覧の中から目に止まらない気がする。
見られたくない人にパソコン使わせたときに、ピンポイントでリポジトリをみつけて reflog の中から見られたくないもののコミットを見つけてパス付き zipを 解凍するとかまずないでしょ。
そもそも便利なのかちゃんと考えてる？
「日々Dockerfileをメンテして開発環境がこんなに楽になります！」
「Dockerなので本番とも開発者同士でも同じになります！」
馬鹿じゃねーのかｗ？
Dockerfileメンテなんて手順書メンテとかシェルスクリプトメンテしてんのと大して変わらねーよｗ
そのDockerfileから作ったものが本番と同一だなんて保証はねーって気づけボケが
それと「同じDockerfileから作ったものだから環境差異はありません」なんて寝言まだ言ってるの？
yumもaptもリポジトリがセキュリティアップデートやらで変化する以上
いつも同じ結果になるわけじゃねーだろが、（バージョンロックする方法はあるけどめんどいだろ）
本番でもコンテナを使ってますってやつら以外無理してDocker使う必要ないんじゃねーか？
お前らが欲しいのは軽いVMであって細切れのコンテナじゃねーだろ？
initを潰して,supervisor入れてプロセス管理して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか？
流行りのコンテナぽくしたいならLXDやらsystemd-nspawnの方がよっぽど筋がいい
というわけでよく考えなおせ
続き書いた
