  |
はてなキーワード: classとは
まじな話をすると、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チェイン, リファクタリング)
ケナタッチ氏の書簡に対する、日本の抗議文がアップされるのをwktkしてまってます。あと前文部科学事務次官が実名で事情を話す覚悟を決められた由、敬意を表しまして、ぜひぜひ参考人招致を実現して頂きたいなと思いますね。
「国連のプライベートの権利に関する特別報告者が懸念を表明されたということですが、政府としてはどのような対応をとられますか。」
「まずですね、特別報告者という立場ですけども、これは独立した個人の立場で、人権状況の調査、報告を行う立場であって、国連の立場を反映するものではない。これは明確に申し上げておく。今回の書簡を受けてですね、政府外務省は、直接説明する機会が得られることも無く、一方的に発出したんです。この点、さらには同書簡の内容が明らかに不適切なもの、でありますので、強く抗議を行ったという、行ってます。それと同時に、テロ等準備罪処罰法案（名前違うよ）というのは、187の国と地域が締結する本条約締結するために必要な国内法整備であってですね。プライバシーの権利や表現の自由を不当に制約するできる利用がなされるということはまったく当たらないということですを強く抗議したということです。」
下のマニュアルのII methods of work B. Communication 37に、基本的には、レポートに掲載されるまでは機密扱いになるけど、特定の事情で特別報告者が、報告書より前に公開する必要があると判断すれば行うことができると書いてあります。なので、公開するのは全然問題ない。
菅さんの一方的な発出の部分ですが、どれくらい特殊な例なんだろうかと、ケナタッチ氏の場合は、ポストの歴史が浅いので記録がアーカイブされていないのですが、表現の自由に関する特別報告者のComments on legislation and Policyをつらつらと眺めてみると、
http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/LegislationAndPolicy.aspx
もうまったく普通に、書簡の最後に、この文書はこのウェブサイトで公開しますし、返信も同様に公開しますよ、というようなことが書いてあります。むしろ書いてないほうが珍しい。
アメリカの、宗教的属性で、旅行者のスクリーニングをやることをみとめる大統領令に対しての書簡や、旅行者にソーシャルメディアの情報を提出させる大統領令など、ドイツのインターネット監視の法律強化案に対するコメントでは
最後にお知らせさせていただきますが、この書簡は、特別報告者の任務のために、公に利用可能とするため、ウェブサイトに投稿いたします。
貴国政府からの返信に関しても同様に、同じウェブサイトに投稿し、また通常の表現に関する人権の議会に提出する活動報告書にも同様に掲載させていただきます。
Finally, I would like to inform that this communication will be made available to the public and posted on the website page for the mandate of the Special Rapporteur on the right to freedom of expression:
Your Government’s response will also be made available on the same website as well as in the regular periodic Communications Report to be presented to the Human Rights Council for its onsideration.
これに対して、アメリカやイギリス、ドイツなどの先進国は、形式だけにしても「忠告してくれてありがとう、これこれこういう法律だから大丈夫です。もしもっと疑問があったら答えるよ」とか「忠告には感謝しますが、現在議会で議論している最中で、議会の決定は政府とは独立しているから現段階で、どういう内容の法律になるかは答えられません。もし内容が明らかになったらすぐに情報提供させていただきます」みたいな感じの丁寧な応答がされています。
また先日書いたInvestigatory Powers Billについては、コメントはありませんが、同様にすぐにウェブサイトに投稿されています。こっちのほうが珍しいパターン。
理由を書いてある奴もたまにはあって、たとえば、中国のインターネットアクセス規制に関するコメント（これが中国から見えるのかは気になるね）では
また私は貴国政府に、この法案に関する私の見解をすぐに公に示すことをお知らせいたします。このプレスリリースは、私が、貴国政府と、この問題の疑問点を明らかにするために、コンタクトを取っていたことを示すことでしょう。
I would also like to inform your Excellency’s Government that I intend to publicly express my views on the draft legislation shortly. The press release will indicate that I have been in contact with your Excellency's Government to clarify the issues in question.
まぁ中国だと、こういう意見表明がされたことを自ら発表することなんて無いだろうしね。中国のレスポンスは「中国は法治国家だから大丈夫」見たいな感じで、西欧諸国のような修辞はないのが笑えた。
貴国政府の返答は、人権委員会の判断を仰ぐために作成する報告書にも公開されることになります。
今回の申し立ての重大性、緊急性を考慮しまして、今回の書簡の内容については、プレスリリースを行うこととすることも、貴国政府にお知らせいたします。
The response of your Excellency’s Government will be made available in a report that will be submitted to the Human Rights Council for its consideration.
Given the seriousness and urgency of the allegations, we would like to inform your Excellency's Government that we intend to issue a press release on the issues contained herein.
とこれも一方的に公開書簡を送ってるけど、このときは別に怒った反応はしてない。でもお得意の
「いかなる情報に基づいた書簡かは明らかではないが、特別報告間が得られた情報は正確ではないwhile it is not clear what information the communication based on, the information which Special Rappoteurs obtained is not accurate.」を書いてますね。
https://spdb.ohchr.org/hrdb/25th/Japan_31.01.14_%281.2013%29.pdf
まぁ正直、文章の修辞的な意味での丁寧さの欠如具合が中国の例に近い。
「最後に、立法段階が相当進んでいることに照らしまして、私の見解では、迅速な公共の関心が必要な事項であると判断いたします。ですから私は、プライバシーに関する特別報告者の任務として、貴国政府に、本書簡を公開するとともに、ウェブサイトに投稿すること、そして私の懸念についてプレスリリースをを行う準備をいたしますことをお知らせいたします。またこのことは、私たちと貴国政府が疑問点を明らかにするためにコンタクトを取っていたことを示すものであります。」
と書いているわけで、むしろ丁寧に理由まで書いているという意味では、通例に照らしてなんら失礼な文書ではないと思うわけですが、強くprotestしたということですので、文書の公開が楽しみでならないわけであります。
http://www.ohchr.org/Documents/HRBodies/SP/Manual_Operations2008.pdf
緊急提言として、通常の外交マナーにのっとらない行動もできるとか書いてあるけど、公開書簡はありふれてというか、少なくとも事後的にでも公開されるものは、迅速に公開されるので、まあUrgent Appealだから公開だっていうわけじゃなくって、コンタクトを取ってる証拠として公開するから、ちゃんと答えてよ、ということでしょうね。これによると基本的には60日以内には回答することになってるけど、トランプアメリカとか、中国とかは1年、2年回答してないのもあるし。
特別報告者としての活動による訴追等は受けない、逮捕、拘禁もされない、書いた報告書は誰にも訂正されない、等々書いてあるので、まぁ特別報告者がただのprivate（私人）ちう意味での個人だというのは相当苦しいですなぁ。
http://www.ohchr.org/Documents/Publications/FactSheet27en.pdf
The experts carrying out United Nations human rights mandates
are legally classified as “experts on mission” in the meaning of the
1946 Convention on Privileges and Immunities of the United Nations.
While they are working on their mandates, the experts enjoy functional
privileges and immunities that are specified inter alia in article VI,
section 22 of the Convention. These include:
“a) Immunity from personal arrest and detention and from seizure
of their personal baggage;
b) In respect of words spoken or written and acts done by them in
the course of the performance of their mission, immunity from
legal process of every kind. This immunity is to be accorded notwithstanding
that the persons concerned are no longer employed
on missions for the United Nations;
c) Inviolability for all papers and documents;
d) For the purpose of their communications with the United
Nations, the right to use codes and to receive papers or correspondence
by courier or in sealed bags;
e) The same facilities in respect of currency or exchange restrictions
as are accorded to representatives of foreign governments
on temporary official missions;
f) The same immunities and facilities in respect of their personal
baggage as are accorded to diplomatic envoys.”
まぁ国連の特別報告者の見解がいつもいつも正しいわけじゃないのは当然でしょうから、疑義には正面から答えればそれだけですむのになぁという話。正直、「一方的に発出してー！」って切れられても戸惑うんじゃないかしら。他国の反応を見てみると。
Hatelabo::AnonymousDiary
はてな ＞ はてラボ ＞ はてな匿名ダイアリー
ざっくり言いたい人必見！
俺氏、ライブドアニュース風ソースを公開へ
ざっくり言うと
✓ もっとみんなにもざっくり言ってほしい
✓ ソース公開したら良くね
<p class="font-l"><b>Hatelabo::<font color=#4296A5>AnonymousDiary</font></b></p>
<p class="recentitem"></p>
<p class="font-ss">はてな ＞ はてラボ ＞ はてな匿名ダイアリー</p>
<br>
<p class="font-ll"><b>タイトル</b></p>
<p class="font-ss"><font color=#2C4F99>■</font> <font color=#2CAAF0>■</font> yyyy年mm月dd日 hh時mm分</p>
<br>
<br>
<p class="box-bg-gr">ざっくり言うと</p>
<br>
<font color=#4296A5>✓</font> 内容
<br>
<font color=#4296A5>✓</font> 内容
<br>
<font color=#4296A5>✓</font> 内容
<br>
気に入ったものを繰り返し見続けることがある。
一日に5回とか。それが数週間。
子供が気に入ったアニメや絵本をずっと見続けようとするのによく似てる。
まあ、そんな音楽です。
------------
JUNGLE FUNK
https://www.youtube.com/watch?v=0_JJqdWSJuA
リヴィングカラーのリズムセクションの 2 人と Vinx のユニット jungle funk の曲 "TORN"。
ひたすら美しく切ない。
ウィンビッシュのベースはデリカシーのある美しいコード進行を多彩なパターンでメロウこなしているが、
ガっと行くトコはきっちり行ってて、甘さだけにならないのが本当にうまい。
パーカッション(壺かな？)のオーガニックなリズムが、控えめだけど強いビートを一貫して曲に与え続けている。
そして、歌とコーラスワークの美しさにおれの涙腺は何度でも崩壊するわけです。
ちなみに、エリックゲイルズがギターを弾くインストバージョンが下記。
これも良い。
ウィンビッシュが弾いてるところが見れるのがうれしい(凄すぎて何やってるかさっぱりだけど)。
John Page Classic Presents “TORN,” featuring Eric Gales, Doug Wimbish & Will Calhoun
https://www.youtube.com/watch?v=WeefVD1668w
-------------
Chantae Cann All I do Cover Live HD
https://www.youtube.com/watch?v=i5liTAUdFHQ
最近はあんまり参加してないっぽいけど、スナーキーパピーの鍵盤の人として知られるコリーヘンリーのライブ。
見どころはシャンティーカンの歌！歌！。スナーキーのプロジェクトでもよく歌ってるけど、それほど
アピールする歌い手には見えなかったんだよね。けど、こっちは本当に良い。
ちょっとチャイルドボイスで、べったり歌い上げる感じにならない乾いた感触がステキ。
バックは結構いかつい演奏してるのに、そこからさらに2歩も3歩も前に出るパワーもさすが。
それこそ何度も聴いたけど、後半のロングトーンは何度聴いてもドキドキさせられる。
下のはたぶん同じライブの別な曲。これも上とセットでずっと聴いていた。
Cory Henry Plays Gnarles Barkley's "Crazy" feat. Chantae Cann
https://www.youtube.com/watch?v=xp8UCpHk-vk
-------------
North Mississipi Allstars - Turn Up Satan
https://www.youtube.com/watch?v=p1rLGrLAXQ0
NMA のブギ。
一見何のひねりもないミドルテンポのブギのようだけど、現代的な工夫が多く盛り込まれていて退屈させない。
逆かな？。今時のポップソングに典型的なブギのリフを再利用して見せたのかもね。
いずれにしてもそうした要素を中毒性高くパッケージした NMA の手腕はさすが。
ギターソロ開けにリフに戻ってくるとこなんか立ち上がって踊りだしたくなる。
使い古された何の変哲もないギターリフが強烈な輝きを取り戻す一瞬と言って良いと思う。
ルーザーディッキンソンは本当にうまい人で、ブラッククロウズのこの曲も執拗に聴き続けた一曲。
後半のソロは何度聴いても胸に刺さる。
The Black Crowes - Oh Sweet Nuthin'
/** * 都会歩行プログラム * @author 増田 * @version 1.0 */ public class WalkingTimerTask extends TimerTask { public void run() { if (片側寄り通行の表示がある) { // 駅構内の通路や階段などを想定 表示に従って片側に寄って直進する。 } else if (曲がり角進入までの距離 ＞ 0 ＆＆ 曲がり角進入までの距離 ＜ 5メートル) { // 出会い頭の衝突時の衝撃緩和 歩行速度を下げる。 } else if (曲がり角進入までの距離 == 2メートル) { // 出会い頭の衝突防止 曲がり角から離れる方向に1歩移動する。 } else if (曲がり角曲がり中) { // 他レーンとの衝突防止 円弧を描くように歩行する。 } else if (曲がり角の曲がり終わり) { 歩行速度を通常に戻す。 } else { // TODO: 通常歩行時の減速および加速を段階的に行う処理を組み込む。 左側を歩行する。 } } }
newしてから渡せば良いと思うよ。
いちいちクラスに分ける理由は、こういう感じで、クラス内の変数にアクセスすれば、画面事の表示とかが簡単に出来る的な？
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
//画面事の名称
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("画面の名前：" + ViewName); // 画面名称が表示されるイメージ
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
View.OnClickListener ocl = new EventHoge();
ocl.ViewName = "画面その一";
button.setOnClickListener(ocl);
}
}
こんな感じにすれば、画面が二つあって、
その画面の名称を表示するようなボタンを、二つメソッドをコピペして作らなくていい的な？
サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。
だから、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか？ とかを考えてこそ勉強だと思うよ？
今回のレイだと「View.OnClickListener」っていうインターフェイスを実装したクラスを、setOnClickListenerすればいいってことさえわかれば、
匿名クラス？（っていうのかな？ ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方）とかを使わずに、
どういうふうに応用ができるか？ とか頑張れ！
頑張れ！
頑張れ！
はああああああ。
おれはビールを飲む！
うーん？
いや、なんか、通じてないな。
もうちょいサンプル詳しく書くから、サンプルのどこがわからないか言ってくれ。
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("サンプル");
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
button.setOnClickListener(new EventHoge());
}
}
こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。
元増田のサンプルだと、メインの中でインターフェースを実装したクラスの実装を書いてるから、中とか外とかがあるんじゃないのか？
自分でクラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数？の中で実装しなくてもすむじゃん。
よくわからん。
中が嫌なら外でかきゃいいじゃん。
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class Hoge : View.OnClickListener {
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("サンプル");
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// メインスレッド的なところ
final Button button = new Button(this);
button.setText("ダイアログの表示");
button.setOnClickListener(new Hoge());
こう書けば、中で書かなくて良い気がするけど、駄目なの？
なんか、インターフェースだから引数の中ってのが意味わからん。
どう関係してるの？
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
↑に「生きざまを見よ！」とあるので、見てみたら別の意味ですごかった。
いわゆる optimisation なのだろうかな。
ちなみに顔写真は↓
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話
「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる
間違っている電波だ
個人的に電波だと思うのはこういう匿名の書き込みを住井だ駱駝だ言い出すところ
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
https://www.npmjs.com/package/timeengine
IOモナドをDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからはFRPの効力がまざまざと見せつけられている。
荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数で関数に渡すのか？
グローバルな値を参照したり書き換えたりして
いやだから、定数なんだから書き換わらないんだよ、FRPのストリームはconst 定数なんだから。
オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
:echo 1 / 0 :echo 0 / 0
2147483647 -2147483648
きっしょｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
他の言語もチェックしてみるか
package main import "fmt" func main() { fmt.Println(1 / 0) fmt.Println(0 / 0) }
echo 1 / 0; echo 0 / 0;
PHP Warning: Division by zero。
print 1 / 0 print 0 / 0
ZeroDivisionError: integer division or modulo by zero
print(1 / 0) print(0 / 0)
ZeroDivisionError: division by zero
nodejsだと1/0と0/0で異なるメッセージが表示された。
console.log(1 / 0);
Infinity
console.log(0 / 0);
luajitだとnodejsで表示されたメッセージの短縮形で表示された
print(1 / 0)
print(0 / 0)
main = do print(1 / 0)
Infinity
main = do print(0 / 0)
public class Test { public static void main(String[] args) { System.out.println(1 / 0); } }
public class Test { public static void main(String[] args) { System.out.println(0 / 0); } }
Exception in thread "main" java.lang.ArithmeticException: / by zero at Test.main(Test.java:3)
#!/bin/bash echo $((1 / 0)) echo $((0 / 0))
test.bash: 行 4: 1 / 0: 0 による除算です (エラーのあるトークンは "0") test.bash: 行 5: 0 / 0: 0 による除算です (エラーのあるトークンは "0")
haskellとnodejsとluajitはエラーにならないけどまあいい。
Vimはやべえよ。
