「Atom」を含む日記

■サーバマシン起動が無駄に仰々しいこと。。ばかみたい

重厚長大イコール高性能かよ？バブル期の考えのまんまだな。

起動にちんたら7〜8分もかけてさ、この起動時間は、新モデルになるにつれてどんどん長くなっている。

Xeon積んでるのに、へんなインストール支援ツールやら、RAID構成ツールやらは、二万円程度で売られていそうなAtom機と遜色ない遅さ。

Windowsデスクトップからの管理ツールはWEBベースに成り果てて、無駄にhttps接続だったりして、証明書エラー。エラーのポップアップも多発するし却ってセキュリティ上気持ち悪い。

もしかしてここのメーカーだけなのかな。。いままでなんとなくメーカーを統一してきたけど、替えどきなのか。

Permalink | 記事への反応(0) | 23:57

ツイートシェア

■anond:20180130150104

可能ならメモリも8GBにしたい…

それ無しでもSSDだけで、新しいのATOM機より快適だと。

Permalink | 記事への反応(0) | 15:03

ツイートシェア

■どうすべきか

実家の放置されてる　Core2Duo、メモリ4G、HDD500G　のノートにWindows10をインストールして使うか、

ビックで売ってる、Atom、メモリ4G、フラッシュメモリ64Gで約2万のノートを買うか。

実家に帰った時にネットサーフィンしたり動画を見る程度だから、どっちでもいいっていえばいいけど。

Windows10は海外のサイトで千五百円で売ってるからそんなに金はかからない。

Permalink | 記事への反応(2) | 14:56

ツイートシェア

■大学の図書館にまともな本が無い

司書の話がバズってるので便乗して書き込み。

とりあえず、ここで伝えたい事はブコメやトラバで「皆さんのおすすめの本を教えてください」ということです。

↓以下駄文

大学の情報系の学部にいるんだけど、設備が酷い。

学内に無線が通ってないどころか、作業スペースも1GB もないからUSBを持ち歩かなきゃいけない。

というのはまあ慣れるんだが、図書館に本を借りて勉強しようとしても、情報系まともな本が置いていない。

大学の利点といえば、高い本をただで何冊も読めることだと思っていたのに、なんだCS5のフォトショやイラレ、2010年頃のMOS教本ばかりが並んでいる。

挙句の果てにはiPhoneの使い方などの本ばかり。高校のほうがもっとマシな本が置いてあった。

ということで最近、友達と結託して図書館に何冊か技術書などを買ってもらえるように届け出を出している。

最近届け出を出して入った本は、リーダブルコード・入門 Python 3・みんなのPython・Gitが、おもしろいほどわかる基本の使い方33・Atom実践入門など色々ある。(友達が凄い出してたけど、僕はあまり把握しない)

僕の周りはとりあえずPythonで適当な数学の計算とか、あわよくばアプリ開発などをしてみようと思って活動しているからPythonの本の届け出が多い。

だけど、他の知り合いや他ゼミの子の話を聞くと、プログラミングをしたいけど何から始めたら良いかわからないと言う子が多かった。

だから、何をしたいか決めて、言語も決めて(気に入らなかったら変えても良い)とりあえず何か初めてみようと言う提案をした。

僕自身Pythonの次はRubyもやってみたいと思ってるから、もっと他の本も欲しい。

こういう活動をしていたら、情報系の学部生はあまり図書館に届け出をしないらしく、だから本が足りないと司書の方に教えてもらい、何か必要な本があればドンドン教えて欲しいと言っていただけた。

だから、大学で初心者から上級者までとりあえず幅広く(出来ることなら就職してからも苦労することのないように）対応できる本を入れてもらえるように申請を出そうと思ってる。

でも、僕の知見は広いとはいえず、出したのもそのGitなどの本ぐらいであんまり貢献できてない。

はてなにはエンジニアの方などのユーザーが多い印象があるので、ご教示いただければ幸いです。

Permalink | 記事への反応(0) | 12:32

ツイートシェア

■プログラミングの勉強をしよう

Atomインストールしてパッケージ入れまくってたら飽きてきた

前はsublime textで同じことをやって飽きた

そもそも秋田県に住んでるからプログラミング覚えても使う仕事がない

Permalink | 記事への反応(1) | 18:13

ツイートシェア

■新調する自宅サーバーのスペックを考えた

今はAtom 330+ION+SST-SG05B+SSD+HDD+TVチューナーの構成。

ケース新調&SATAポート追加&OS入れ替えの必要が出てきたので、新調することにした。

• 150WのACアダプタではオーバーしそうなので、ファンレス電源を買うことにした。
• HDDはともかくとしてケースが高い。同等のものでもっと安いのがないか探す。価格.comで価格なしでもAmazonではまだ売ってるパターンがある。
• 用途は録画・リモート視聴・ファイルサーバー・Webサーバー・その他。
• エンコードはメインPCでやるのでスペックは不要。

候補から外れたもの

ケース

PC-Q28B

• HDDとSSDが合計6台しか入らず、見かけに反して収納力が低い。
  • 基本的にSSD1台+HDD2台の構成だが、余りを突っ込んだり壊れかけの使い潰しなどでオーバーする可能性はありえる。
• 全く使わない5インチベイがある。
  • 使うなら表に出るものがいいので、HDDやSSDは入れたくない。
  • GRID+ V2の存在に気付かなかったら、5インチベイ付きを候補にしていただろう。
• 1万円で買えるのは高評価。

SS-DS380B

• 8個ある3.5インチシャドウベイが全てホットスワップ。
  • USB-SATA変換アダプタの直付けができない。
  • USB-SATA変換アダプタは宙ぶらりんになって危険。かといってテープなどで貼り付けたくもない。よってSATAカードが必要。
  • 現状でWチューナー内蔵&SATAカード&拡張スロットに固定する方法がない。
    • PX-Q3PE4にPCIe以外から電源供給する方法があれば、PCIeにSATAカード、2個目の拡張スロットにTVチューナーという方法があるのだが。
    • M.2→PCIe→チューナーという方法もあるが、変換アダプタが高い上に売り切れてる。
• 電源がSFXなので、240W程度のファンレスSFX電源を探さなければならない。RM650x相当のものが見つからない。
• HDDをしっかり冷やしてくれること、防塵フィルターが外にあることは高評価。

マザーボード

J4205-ITX

• 総費用ではH270M-ITX/acと大して変わらない。その一方で性能は低い。
• PCI-Expressが2.0x1でエッジフリーですらない。SATAカードは2ポートのものがほとんどで、転送速度は片方向あたりHDD4台程度しかない。
• CPU違いのものもある。

A68N-5600

• TDPが25Wもあるのに、極小ヒートシンクを4cmファンで冷やしているだけ。負荷がかると爆音間違いなし。
  • チップセットはファンレスなのにCPUはファンありということは、ケースファン程度では冷えないことを意味する。
• 4cm用の口径変換アダプタはあるが、それを使ってまでこのマザボを使うメリットが有るかは疑問。
• マザボが安いこと、メモリは流用できることから、総費用が1万円安い。ただしメモリを8GBに増やせば5000円程度になってしまう。
• 5年前のCPUなので、ドライバ供給が止まるかもしれない。IONは数年で止まってしまった。
• CPU違いのものもある。

Permalink | 記事への反応(1) | 01:05

ツイートシェア

■https://anond.hatelabo.jp/20170706235735

GitHub Atomでいいじゃん。管理者が管理放棄してくれるなら任意コード実行可能なエディタを入れられれば個人レベルでは一番良いと思う。

Permalink | 記事への反応(0) | 02:51

ツイートシェア

■エディタのAtomの文字がなんか滲む

うまく表現できないのだが、マウスカーソルが乗ってないペインの文字がどんどん滲んでいく（エディタ部もメニュー部も）

クリックするなどして「前面」に持っていくとくっきり表示される

いくらぐぐってもこの症状が出てこないんだが、常用にしんどいのでなんとかしたい

Windows10なんだけど、だれか困ってる人いないかなー。Chromeでは起こらないんだけどなー

Permalink | 記事への反応(0) | 20:20

ツイートシェア

■Atomエディタは日本語入力確定前のカーソル移動が見えない

持ってる人はやってみよう。文節区切りを変え隊とかひらがなにゅうりょくしてｒｙときのにゅうりょくみすけしたいときとかのどうさだ。
なんでこんなことになってるのかと思ったら「AtomはChrome+JacaScript+CSSなのでブラウザ上のJavaScriptから読めないものはできん」ということらしかった。
Atomが絶妙に重いのは中身Chrome（正しくはChromimum）だからか！なるほど！畜生！
日本語利用を片隅に置いて作られたものじゃないから仕方ないのかねコレも

Permalink | 記事への反応(0) | 21:11

ツイートシェア

■http://anond.hatelabo.jp/20170407112743

プログラミング歴10年ちょい、仕事でWebシステムとかiPhoneアプリとか、色々プログラミングしてるアラサーのおっさんからだ。

増田は10代後半〜20代前半くらいかな？と思って、書く。参考にしてほしい。うっかり年上だったら何かゴメン、でも少しは参考になると思う。

こういう「どこからやったらいいんだよ…」っていう悩みは俺もちょうど中学生くらいの頃に思ってて、悩みながら薦めたんだけど、

結局の所「どの経験もムダにはならないから、とりあえず沢山やってみるといい」ってことだ。これについては後述するけど、まずは細かい疑問に答えていこうと思う。

まず、色々調べてて、結構詳しいし感心した。ただ、その詳しさは、まだスタート地点だ。

どの言語がどういうものなのか、何となく知ってるのは役に立つから、これからもアンテナを張り続けるといい。

MySQL使うべきなのかSQLite使うべきなのか、GolangにすべきかRubyにすべきかいっそJava？いやC#？

こういう悩みが出るのは勉強した証拠。しかし、この問題はレベルの高いプログラマーでも難しい。

何故かというと、作ろうと思うもの次第だし、作ってみたら意外と相性が悪いみたいな事も起きるし、

何より、根性出せばどれを使っても作れるからだ。

疑問に思っているらしい、言語を複数触れた方が良い理由は、こういう「どれを選んだら良いか」という問いに答えやすくなるからだ。

自分が理解していないものが、今作ろうとしているものにマッチするかしないか判断するには、言語や環境に対する深い理解が必要だ。

エディタは個人的にはVisualStudioやXcode、あるいはIntelliJ系をオススメする。

何も設定していなくても好ましくない書き方の時に警告が出るから、強制ギプスみたいに作用するからだ。

Twitterとかで騒いでる強いプログラマーの皆さんはvimやemacsを薦めるけれど、意外にもchokudaiさんとかはVSでC#を書く派なのを思い出して欲しい。

IDEを作っているのもプログラマーなので、IDEを使うメリットもかなりあるんだ。使った上でやっぱりvimが良ければvimに戻ると良い。

パソコンのスペックについては、確かにスペックが低すぎる。そのマシンで開発するなら、vim/emacsにせざるを得ない。 AtomやSublimeでもキツそうだ。

書いてる通りで、Core i7/RAM 4Gくらいあればとりあえず基本的人権って感じ。

性能は高ければ高いほど良いけど、予算の都合だってあるだろう。 10万用意できるなら、結構選択の幅は広がるんじゃないか。バイトなり親の説得なりお金ためるなり、頑張って調達するんだ。

さて、最初の話題に戻る。

何から勉強したら良いか分からないなら、とりあえず何かをパクれ。Twitterクローンみたいなのでも良い。フォローとテキストの書き込みだけなら作れるんじゃないか？

なんならそれを公開してもいい。

もしアイディアがないなら、それこそTwitterで誰かが「こんなのあったらいいなぁ」って言ってるもののうち、何となく頑張れば作れそうなものに手をつけてみると良い。

どの経験もムダにはならない。やってみろ。1個作ったら、もっと広い世界が見えてくる。

Permalink | 記事への反応(0) | 01:39

ツイートシェア

■

サクラエディタ←玄人

秀丸←ハゲ丸

Vim←しょうもないところにこだわる

Emacs←ガキの心を忘れないおっさん、

Atom←中途半端

SublimeText←シャレオツクソ野郎

Permalink | 記事への反応(1) | 00:15

ツイートシェア

■普段コーディングに使っているエディタでエロ画像を閲覧すると

intelliJとかVSCodeとかAtomとかって画像開くと表示してくれるじゃないですか。

たまたまDownloadsディレクトリで作業していたから、エディタに表示されるファイル一覧にいつも見ている声優のコラ画像のファイル名が見えていた。思わずクリックしたところ、いつもはコードが表示されている部分にどーーんと豊満なオッパイが表示されちゃった。

めっちゃ興奮した。みんなもやってみて。

Permalink | 記事への反応(0) | 22:34

ツイートシェア

■gitしか知らないけれど

SVNの何がダメなのかよく知らない。

知る必要もないんだろうけど。

ただ、過去の技術ってこうやって無くなっていくんだろうなって実感する。

みんな使うからgithub使ってるし、なんとなくgithub好きだからエディタはAtomを使ってる。

計算機以前の「技術」って積み重ねていくもので無駄になる知識なんて無かったんだろうけど（切削加工の知識とか設計図の読み書きとか）、

計算機ができてから「これまで大活躍だったのに１０年後には知っていても何の役にも立たない技術」っていうのが増えてきてるんだよねきっと

Permalink | 記事への反応(1) | 01:54

ツイートシェア

■春から情報系学部・学科で学ぶあなたへ

購入すべき物

• ラップトップPC

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

• 8〜10インチのタブレット

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

以下は学ぶべき

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

• C言語

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

• 英語

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

• git

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

• OSにまつわる内容

基本。

• スクリプト系言語を何か一つ

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

• markdown

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

• emacsかviのキー操作

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

サークル、課外活動

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

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

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

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

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

競技プログラミング

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

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

まとめ

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

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

Permalink | 記事への反応(0) | 04:30

ツイートシェア

■コメ率の低いはてブエントリは英語とエロか?

http://anond.hatelabo.jp/20170305115905 を増田以外のホットエントリで見ると。

2017年2月コメント率の低いホットエントリ

Python、データベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。

2017年2月コメント率の高いホットエントリ

Permalink | 記事への反応(1) | 17:20

ツイートシェア

■自分のプログラマーとしてのレベルが低くて凄く心配になってくる

Webエンジニア歴2年目。多分年齢的にはまだ若い。

RailsとLaravelくらいは触れる。

でもPlayとかはHello Worldくらいしか作ったことない

オレオレWebフレームワークくらいなら作れる。

でもRailsのソース見て内容を理解しろと言われても多分無理。

AngularとBackboneくらいは触れる、

けど最近のフロントエンド界で大量に出てくるツール群には全然ついて行けてない。

ReactとかAngular2はビルドするまでが面倒くさくて投げた。

インフラ、ネットワーク全然わからない。この前ネスペ受けたけど午前で落ちてそうだったから途中で帰った。

会社にいるインフラ系の人達が超人に見える。

静的型付け言語あんまり触ったことない。

というか動的型付け言語があんまり出てこないステートフルな分野のアプリを全然作ったことない。

言語仕様くらいはわかるけどデスクトップアプリとかは未だにストップウォッチくらいしか作れない気がする。

自分の身の回りのよく使うツールを考えてみる

OS、勿論作れない。

Git、無理

Atom、うん作れない。

Office、無理無理

Steamのクソゲーすら無理だし、もうむしろ増田くらいしか作れない気がしてきた。

例えば学生時代の友達に「一緒にゲーム作ろうぜ！」とか誘われてもあんまり役に立てない自信がある。

就職するまでエンジニアってもっとなんでもできるものだと思ってたよ。

ネットにはスーパーエンジニアがいっぱいいるからよくわからないけど、もしかするとこんなもんなエンジニアっていっぱいいるのか

凄く将来が心配だ。

Permalink | 記事への反応(4) | 12:02

ツイートシェア

■SublimeTextじゃなくてAtomを使ってる理由

日本語がSublimeより書きやすいって点に尽きる。

結局コーディングだってそんなガッツリやるようなプログラムや

静的型付け言語だったらそもそもエディタじゃなくてIDE使うし、

簡単なスクリプトとか書くだけだったら日本語書く作業と同じウィンドウで扱える

Atomでいいかなーって思った感じ。

Sublimeもプラグイン入れたらコーディング意外でも使えるレベルになるんだろうか。

Permalink | 記事への反応(0) | 21:35

ツイートシェア

■http://anond.hatelabo.jp/20161026022026

> エディタにAtom を使うと怒られるの？

怒られない、むしろ自由だから俺はVSCode使ってる。

でも社内の人間は「困ってない」って理由で使わない。

モダンな環境が広まらない。

> 「IE8は別料金！」って張り紙しておいてもダメなの？

ダメ。「前も動いてたから」っていう理由で要件変えずに仕事取ってくる。辛い。

Permalink | 記事への反応(0) | 16:08

ツイートシェア

■http://anond.hatelabo.jp/20161026022026

エディタにAtom を使うと怒られるの？

「IE8は別料金！」って張り紙しておいてもダメなの？

Permalink | 記事への反応(0) | 07:43

ツイートシェア

■http://anond.hatelabo.jp/20161007222446

え、何で分かったの？　Atomは割と好き

イマイチUIわからんところもあるけど

vimかemacsかみたいな議論してる人たちを遠巻きに見てるタイプ

Permalink | 記事への反応(0) | 22:56

ツイートシェア

■http://anond.hatelabo.jp/20161007220113

だからvimじゃなくてatom派なんだね

Permalink | 記事への反応(1) | 22:24

ツイートシェア

■ノートパソコンを買うのなら

「パソコンが今買い時　ポイントは高性能、モバイル型」

http://style.nikkei.com/article/DGXMZO07281760V10C16A9000000?channel=DF260120166490

って言う記事を読んで、割りと頷ける部分は多いんだけどやっぱり商業ライターなのでバッサリ切れてないところがある（メーカーに気を使わなきゃならんだろうし）。たしかに多角的に見るのは公平だと思うんだけど、日本は大学生のPC所有／利用率が低いなんて言うニュースもあったし、ノートPCを買わなきゃいけない人もいると思うので、私見でバッサリ感のある記事を書いてみようと思った。

その１

・CPUはわりとなんでもいい。Core i3～Core i7とかがいまの表記なんだけど、Core i5,Core i7,Core　Mなんでもいい。極端に古くなければ困らない。

・メモリは４Gほしい。ちょっと詳しい人がせめて８Gとかいいだすけど、初めて買うノーパソなら４Gで十分だ。

・ストレージの容量も、あんまり気にしないでいい。でもHDDよりはSSDにしとくべき。これは記事の通り。CPUで２世代分くらい体感早くなる。

・光学ドライブとかいらねえですよ。めったに使わないし、もし使う場合は外付け買うとか、どっかでデータ読ませてもらうとかした方がいいよ。

・A4かB5ノートにしとけ。でかくて重いノートを家でデスクトップ代わりに使うとかもったいねえ。家で広い画面で使いたければ記事にあるようにディスプレイとマウスでも買っとくほうが安くて快適。

・この条件で７万前後なら概ね性能で不満は出ないと思われる。この性能なら、ネット見たりレポート書いたりWebみたり、休日にYoutubeしたり、あるいはSkypeで喋ったりしても、ぜんぜん余裕はある。おそらく今のノートパソコンの更新ペースから行って、大学４年間使っても困らない。

その２

・CPUをCeleronというのかATOMというのにしてストレージをeMMCってのにすると、急に４万を切ったりもする。

・さすがに性能面では上に及ばず、動きがもっさりする。が、ネット見たりレポート書いたりWebみたり、休日にYoutubeしたり、あるいはSkypeで喋ったり出来ないかというと、多分全部できる。ただそれぞれがもっさりしてて作業モチベに悪影響があるくらいだ。でも、ノートパソコンを持ってないよりは遥かに良い。４万円だして、とりあえず買ったほうが良い。

・キーボードのついたPCのスキルなんてスマホやタブレットでは身につかないので、そこは別物だと割り切るべき。PCは「なんか楽しいものを見聞きできるモノ」じゃなくて「作業用の道具」なので。

その３

・１０万円以上のノートパソコンは、PCが好きな人、すくなくともPCがある程度わかる人向けだと今は思っておいて良い。狙いは「その１」の６～８万円のにしておこう。それでももっといいのが欲しい人は↓

・おしゃれな使い方がしたい人はMacbookAirでもかっとけ。

・そうじゃねえならSIM挿せるのは費用対効果がいい（おすすめ）。挿せる機種少ないけど。

・格好いいパソコン持ってても彼女は出来ねえぞ（俺調べ）。肩を並べてレポート作成デートとか都市伝説だから。

・彼女がいるっぽい雰囲気（とか、出来たときの予行演習）をつかむためには、可愛いデザインのUSBメモリでも買っておけ。５００円とかあるから。

Permalink | 記事への反応(1) | 04:52

ツイートシェア

■Windows 10 Mobile

Insider Preview 初期からBTキーボードでほぼ毎日つかってる人の感想

・IMEが糞

　モニタつないで大きな画面でOffice動いたとしてもそれを無に返すレベルでIMEが糞ほんとﾂﾗｲ

　ユーザー辞書機能も無いし長文書くのにつらみしかない

・アプリが少なすぎ

　あってもAndroidやiOS向けと比べるとしょぼいのが多い

　ニワトリ・タマゴだとは思うけどKKのやる気がなさげなので何ともはや

・端末の出来が安っぽいのが多い

　HPのは期待してる。けど、端末の出来以外の所がアレすぎるのでそれに7万出せるかと言われると結構悩む

　OSとしてはETWS対応してるのに、端末メーカーが有効にしてないので使えない物がそこそこあるのでその端末一台運用はお勧めできない。

・continuum 機能自体はまぁどうでも

　ローカルで作業する気ないから外部モニタでFullScreen表示できる何かとしか思ってない

　でかい画面でRDP動くのが重要

・入手方法が限られすぎ

　キャリア経由のがないとガジェオタ端末からの脱却はムリじゃね？

ビジネス向けだからこまけー事はいいんだよという人いるけど

多分そこでメインになるであろうcontinuumはIMEが糞過ぎてストレスマッハですよ？

ATOMがどんどん改良されてスマホサイズでx86版動けばと結構期待してたけど残念な結果になりそう…

合うかどうかは、人というかライフスタイルにだいぶ左右されると思われる

Office Applicationだけで仕事が完結してドキュメント参照の方が多い人なら悪くないかも？

Permalink | 記事への反応(0) | 08:39

ツイートシェア

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

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

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

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

はじめに

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

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

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

• swift
• atom
• electron
• rails
• tensorflow

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

• ピリオドで終わっているもの(4535件)
• 小文字で始まっているもの(2242件)
• 過去形, 現在進行形で始まっているもの(1044件)
• Merge/Revertで始まっているもの(6555件)
• 絵文字を使っているもの(2171件)
• その他バージョン番号のみ等、参考にならないと判断したもの(313件)

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

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

用例集

オプションやフラグ、メニューを追加した

• Add -enable-experimental-nested-generic-types frontend flag
• Add --main-process flag to run specs in the main process
• Add Throws flag and ThrowsLoc to AbstractFunctionDecl
• Add "event" parameter for "click" handler of MenuItem
• Add File > Exit menu on Windows

ファイルを追加した

• Add npm start script
• Add build script
• Add SkUserConfig.h with blank SkDebugf macro

メソッドや機能を追加した

• Add TypeLowering::hasFixedSize()
• Add overflow scrolling
• Add convenience API for demangling
• Add a typealias to avoid a build ordering dependency between projects
• Add a helper method mayHaveOpenedArchetypeOperands to SILInstruction

実装を別のものへ切り替えた

• 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

新しく何かに対応した/機能上の制約を取り払った

• Add support for closure contexts to readMetadataFromInstance()
• Add support for activating and deactivating package-specific keymaps
• Add support for launching HTML files directly
• Add support for allocators that require tensors with zero
• Make it possible to call `reflect` multiple times
• Make it possible to set a data type for variables that come out of constants
• Allow atom-pane to be shrunk independently of its contents' width
• Allow null TextEditorComponent::domNode during visibility check

何かを使うようにした

• Use const for util require
• Use FoldingSetNode for ProtocolType
• Use unique text editor title in window and tab titles
• Use an empty object if metadata is ~null
• Use target_link_libraries for fat executable dependencies
• Use existing flatMapToOptionalTests dataset

より好ましい実装に改良した

• Make the clone function more generic
• Make IO faster for v8 compile cache
• Make model constructor argument to addViewProvider optional
• Make Browser::Quit more robust
• Make Menu.getApplicationMenu() public
• Improve incompatible native module error message
• Improve readability of multi-line command
• Improve folds behavior when duplicating lines
• Improve deprecated message on webPreferences options

何かを出来ない/しないようにした

• 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

オブジェクトの内容や挙動を確認しやすくした

• Emit capture descriptors in their own section
• Emit field metadata for @objc classes
• Emit reflection info for protocols

Assertを追加した

• Add assert for role with app name in label
• Add assertions for no available bookmark
• Add asserts for properties

不要なコードを除去した

• Remove some dead code
• Remove some unused enum declaration
• Remove unused variable
• Remove unnecessary line feeds
• Remove trailing whitespace
• Remove debug statement
• Remove redundant mapType{Into,OutOf}Context() calls

コードを移動した

• Move function signature analysis to a Util
• Move markInvalidGenericSignature() to a method on TypeChecker
• Move diagnostic for stored properties in protocols from type checking to validation
• Move Doxygen converter into a proper MarkupASTNode visitor
• Move Module require to top

名前を修正した

• Rename environment -> environmentHelpers
• Rename watchProjectPath to watchProjectPaths
• Rename generic arguments
• s/grammarName/grammar
• fullVersion -> writeFullVersion

小さなバグやタイポを修正した, 警告を潰した

• Fix typos
• Fix a typo
• Fix a test
• Fix typo in DevTools Extensions tutorial
• Fix DownloadingState typo
• Fix includes order
• Fix mistake in tvOS availability
• Fix cpplint warnings
• Fix wrong markdown
• Add missing return
• Add missing period in comment

バグや好ましくない挙動を修正した

• Fix a memory leak in FSO
• Fix lifetime issues in ManagedBuffer.value
• Fix mangling for nested generic types
• Fix memory corruption in another circularity check
• Fix thread-unsafety in Process.Argument initialization
• Fix "Object has been destroyed" error in "page-title-updated" event
• Make Error.prepareStackTrace read-only (again)
• Make string slicing tests standalone
• Make sure showing success dialogs works correctly
• Make sure to emit closure bodies only once
• Make sure all native resources get freed on exit
• Make sure temp file will be cleaned up when base::Move fails

テスト、コメント、ドキュメントを追加した

• Add tests for pending pane items
• Add validation test for projecting existentials
• Add a basic test for opening an editor in largeFileMode if >= 2MB
• Add specs for moveSelectionLeft()
• Add failing spec for Menu.buildFromTemplate
• Add comment about map key/values
• Add TODO about blinkFeatures -> enableBlinkFeatures
• Add a design-decisions section to the CONTRIBUTING guide
• Add style.less examples
• Add docs for app.getLocale()
• Add documentation for --proxy-bypass-list

テストを削除した

• Remove a redundant test
• Remove an empty test

テスト、コメントを修正した

• Fix comment
• Fix outdated comment
• Fix failing specs on Windows
• Fix PersistentVector test for powerpc64{le}
• Update specs for deferred activation hooks
• Update successor/predecessor in validation tests
• Update some tests to use LifetimeTracked instead of hand-rolled canaries

ドキュメントを修正した

• Update README.md
• Update docs for marker callback
• Update documentation for mark*Position
• Update link to solarized-dark-syntax
• Improve documentation of `ses.cookies.set()`
• Improve readability in CSRF section of guide
• Improve spec description

表現傾向とまとめ

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

コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

Permalink | 記事への反応(4) | 09:24

ツイートシェア

■八王子の本屋は1日遅れ。

最近八王子に引っ越してきた。

そして今日（2016年7月14日）は、Atom実践入門─進化し続けるハッカブルなエディタと言う技術書が発売される日だ。

入荷されているか近くのそれなりに大きな本屋を選んで、入荷の確認電話をかけてみた。

くまざわ書店 イトーヨーカドー八王子店 15日入荷予定。

啓文堂書店高尾店 入荷していません。

ヨドバシカメラ 八王子店 15日入荷予定。

ACADEMIA くまざわ書店 入荷していません。

蔦屋書店 八王子みなみ野店 入荷していません。

丸善 多摩センター店 本日か明日入荷、まだわからない。

くまざわ書店八王子店 入荷していません。

これはニッチな技術書なので入荷しにくい本だろうなぁと思ったけど

全滅とは・・・

これはネット書店に負けますね。

ちなみにヨドバシカメラのネットでも15日発売予定。

アマゾンでポチるか・・・

Atom実践入門──進化し続けるハッカブルなエディタ | Gihyo Digital Publishing

https://gihyo.jp/dp/ebook/2016/978-4-7741-8302-2

ダウンロード販売、EPUB/PDFセットなら今すぐ手に入る。でも紙の本がいい。

twitter検索してみると・・

書泉ブックタワーコンピュータ書売り場

https://twitter.com/shosen_bt_pc/status/751344261463830528

7/7先行販売『Ａｔｏｍ実践入門』技術評論社

都心だと先行発売されているのね。

Permalink | 記事への反応(1) | 11:51

ツイートシェア