Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0-beta.4 概要 Conventional Commitsの仕様は、コミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します、この規則に従うことで自動化ツールの導入を簡単にします。 この規約はSemVerと組み合わせることで、コミットメッセージへ機能、修正、重大な変更を入れることで、さらに詳細な説明を可能にします。 コミットメッセージは次のような形にする必要があります 原文： <type>[optional scope]: <description> [optional body] [optional footer] 訳： <型>[任意 範囲]: <説明> [任意 本文] [任
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
実戦での Scala 〜6つの事例から知る Scala の勘所〜で発表してきました - たけぞう瀕死ブログ
2月21日（土）にスマートニュースさんの新オフィスで開催された「実戦での Scala 〜6つの事例から知る Scala の勘所〜」で発表してきました。togetterでのまとめはこちら。 ビズリーチの新サービスをScalaで作ってみた 〜マイクロサービスの裏側 #jissenscala from takezoe スマートニュースの村石さんが「Scalaで快適に開発するためにはいいマシンを使う」と仰られてましたが、3年前のScala Conferenceで全く同じことを言った記憶があります。Javaのコンパイルも昔は死ぬほど遅かったですが、当時とはCPUの進化の方向が違うのでScalaに関しては今後も当分はコンパイル遅い問題は続いていくでしょう。 普及という観点では、昨年くらいからWeb界隈を中心にいろんな会社でScalaが使われるようになってきました。最初にScalaを実戦投入しは
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem（個人批判をしない建設的な障害の振返りミーティング）というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
研究のプログラミングにおける悲劇を無くすためのGitとテスト - Kesinの知見置き場
大学の研究に役に立った物シリーズ第3弾です 今回は研究のためのプログラミングのノウハウについてです。 特に、研究におけるプログラミングでの悲劇を防ぐために自分が実践していた方法を紹介をしたいと思います。大学や研究室によっては、このような研究のプログラミングのノウハウの伝承が行われているところもあると思いますが、何かの参考になれば幸いです。 大学の研究で役に立ったものシリーズの記事 サービス編 勉強編 研究のためのプログラミングとは まずは、研究のためのプログラミングに求められる特徴をざっと説明したいと思います。自分の経験からですが、こんなところではないでしょうか。 実験結果が出ないと何も議論できないので、とりあえず速く実装することが求められる コードのモジュール化、速度の最適化は後回しになりがち 計算量が多いタスクでは、24時間実行しても実験が終わらないことがあり得る バグによって実験の結
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
python自習テキスト [kirinwiki]
このコンテンツを更新しなくなって久しく、さらにレンタルサーバーのPHPもずっと古いバージョンを使うわけにいかず、従来のdocuwikiを使うのをやめました。全ての内容を静的なHTMLにするのが割と手間なため、手抜きとして、ここの表紙以外をPDFに直してしまいました。これで保存します。python2用なので利用価値もすでに少ないですけどね。 っていうか、実際は動物さんイラスト集サイト。pythonの話はオマケ。 スクリプトが書けると、多分どっかで何かの役に立ちます。決まりきった仕事をチマチマと手作業でやるような場面で、スクリプトを上手に書けると劇的に楽になったりすることもあります。筆者自身がそういう経験を持っているので、他にも同じようなことができる人が現れてほしい。こういった動機で、習得用のテキストをポチポチと書き続けています。 興味はある(or 必要に迫られている)んだけど、本当に何も知ら
プログラミング初心者に本当に必要なのは情報ではなく師匠という存在だと思う : 941::Tech
34歳、今日からプログラミングを始めます : 941::Tech って書いたら、色々と教えていただいて誠にありがとうございます。 なんでPerl？って聞かれたら、そりゃYAPC::Asiaの主催をやっているのは大いに関係あるけれどもわりと言語にこだわりはないので、だったら関わりがある言語選ぶのが人情ってもんです。おかげさまで今年のチケットはすでに売り切れております。どうもどうも。 プログラミングについて、やはり皆さん色々と言いたいことはお有りなようでMentionいただかなくても色々とご意見あるようです。人が何かを学ぶ時というのは環境というのはとても大事だと思いますけれども「インターネット普及しまくり、環境恵まれすぎ」な自分がプログラミングを学ぶうえで最初の壁は「情報の取捨選択」かなぁと感じてる。プログラミングというものに対して色々な姿勢や意見があるし、これが正解ということもないからそりゃ
統計的にインデントするやつ - hitode909の日記
古来より，ソースコードのインデントは人力で行われていた．エディタごとかつプログラム言語ごとにがんばってインデントのプログラムが書かれている．EmacsにRuby用のインデントのプログラムとかPerl用のインデントのプログラムがあって，Vimにも似たようなのがRuby用とかPerl用とかちまちま用意されてる．Emacsのruby-mode.elだと，カーソルがかっこの中にいたらこれをするとかで，職人っぽい． 人間がこういうのを書かなくても，周りのソースコードを解析したら，普通はこういう場面ではインデントする，というのを機械的にできるだろうと思った． 以下のPerlのコードはべつにインデントしたくないと思う． print 1; print 2; 以下のPerlのコード見たら，2行目でインデントして，3行目で戻したくなると思う． if ($i % 15 == 0) { print "FizzBu
from old Java to modern Java
16. from old Java to modern Java ∼ 職業プログラマに聞いて欲しいJava再入門 Acroquest Technology株式会社 JJUG / 関西Javaエンジニアの会 谷本 心 ( @cero_t ) 19. private List m_list = null; private int process_file(String str_file_name) { String str_line; List list_lines = new ArrayList(); int i_result = read_file(str_file_name, list_lines); if (i_result == 0) { List list_record = new ArrayList(); for (int i = 0; i < list_lines.size(); i+
Vimを最強のPython開発環境にする2 - Λlisue's blog
本気でPythonをやりたいならあわせて読みたい「え？君せっかく Python のバージョン管理に pyenv 使ってるのに Vim の補完はシステムライブラリ参照してるの？」 2013-06-23 21:30 おしりに追記しました 2013-06-24 10:00 設定等微修正しました 2013-06-24 15:20 quickrunの設定を修正しました 2013-07-03 14:30 間違い等を修正しました 様々な開発環境を試してきましたが、結局Vimに落ち着いてしまっているAlisueです、どうも。 Vimを最強のPython IDEにするを書いてからかれこれ二年ほどが経ちます。 二年もあると新しいVimプラグインが増えるなどし、先の記事内容では最強ではなくなってしまいました。なのでこの辺でもう一度現在の最強をまとめてみたいと思います。 基本方針 プラグイン関係はすべてNeoBu
LIVE 2013: Workshop on Live Programming
First International Workshop on Live Programming, in conjunction with ICSE 2013, May 19. Read more ⇒ About Bringing together people who are interested in live programming. View about ⇒ Venue The workshop is held in San Francisco on May 19. Register now ⇒ CfP We solicit papers and live demos, authors may choose between open access and paywalled submissions. Important dates are, Paper due Feb 7, and
「壊れてねぇなら直すな」という発想はRailsにはないのかも - QA@IT公式ブログ
QA@ITはRuby on Railsで構築・運用しています。で、そろそろRailsの新メジャーバージョン、Rails4のリリースが近づいているようです（と、聞くようになってずいぶん経ちますが）。いろいろと新機能がありますが、GitHubを見ていて1つ驚いたことがあります。Ruby on Railsの生みの親のDHH（David Heinemeier Hanssonさん）が、メジャーバージョンアップとなるRails4に向けて行ったこのコミットに唐突感があったのです。よく使われるAPIの名前を、こんなに簡単に変えちゃうんだという軽い驚きです。 「壊れてねぇなら直すな」（If it ain’t broken, don’t fix it.）という有名な言葉があります。米国のジミー・カーター大統領時代の行政管理予算庁長官だったトーマス・バートラム・ランス氏の1977年の発言が人口に膾炙したもののよ
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
プログラミングはそれ自体が目的であっていい - mizchi log
これ読んで思ったこと。 プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
git-gutter.el - naoyaのはてなダイアリー
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
