中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
「コツコツ努力できる人」は前向きでも、モチベーションが高いわけでもない。自動的に動いているだけ。
コツコツ積み上げることは大事。よく言われるだろう。例えばこんな具合だ。 「毎日英語の練習をしよう」 「毎日記事を書こう」 「毎日お客さんに手紙を書こう」 だが、実際にやりだすと、 「うまくなっている実感がわかない」 「アクセスが伸びない」 「時間がない」 と、１ヶ月も立たないうちに諦めてしまいがちだ。頭で理解はしているが、体は動かない。これが人間の悲しい性だ。そのため「努力は、つらいことだ」というイメージが生まれ、手っ取り早く結果を出せるワザが人気を集める。 だが、時間をかけなければ成し得ないことも数多くある。 例えば人の信用を得たりすることや、高度な技術、卓越した知性などは多くの場合、気の遠くなるほどの数の基礎を少しずつ積み上げた結果の頂点に置かれた「キャップストーン」なのである。 そして、そこで重要なのは、「積み上げる」という単調で結果を実感しにくい仕事をいかにコツコツ続けるか、という
IPADIC(IPA辞書)とはなにものか？
※私は言語処理に関する知識は無いので、あくまで「IPADICとは何ものなのか？」という点に絞ってのみ記述しています。まあ、ここまで突っ込んだのは戯れですが、一応の目的として現在から未来にわたって無料で入手できる形態素解析を使うに当たり、「メンテナンスが継続されている辞書」が入手できるかを調べたかったという意図もあります。 日本語を処理する上で形態素解析というのはわりと欠かせないものです。 Webのサービスでよく用いられている形態素解析器にはChaSenとmecabがありますが、これらのエンジンは何らかの辞書を利用して日本語を解析します。 ちなみに形態素解析器と言うのはChaSenの表現を帰りれば「形態素解析器とは、入力文を単語単位に分割し品詞を付与するツールである。」ということです。形態素解析器の開発の歴史はMeCab の開発経緯をご覧ください。 ここでChaSenにもMeCabにも、標準
「AWS is 何」を3行でまとめてみるよ - Qiita
すべてのAWSのサービスを 3行以下でまとめました。 AWSが色々ありすぎてわからん！ 3行以下で誰かまとめて！！という思いで、AWSを3行で書いてるところがなかったので自分で作りました。 掲載した金額は最小使用時のもの。無料枠や大量購入割引(Volume discount)、あと転送量でかなり変わるので、参考程度に。 以下からのカッコよすぎな見出しは AWSクラウド製品のページ からのそのままの引用です。「 広範かつ奥深いコアクラウドインフラストラクチャサービス」って僕が言ってるわけじゃない！ 広範かつ奥深いコアクラウドインフラストラクチャサービス なんのこっちゃ。 よーするに「基本サービスですよ」ってことらしい。基本サービス多すぎだろ・・・。 い。 コンピューティング AWS is 何 いくら？
クラウドサービスを活用して README にバッジをペタペタ貼る - Qiita
最近の GitHub に上げてある OSS リポジトリには、README にいろんなバッジが貼られています。リポジトリに連携しているクラウドサービスのステータスを表すものがほとんどです。 自分は README にバッジを貼りたい派です。たとえば dtan4/terraforming だとこういう感じです。 最近はバッジの種類も増えているので、整理のためにもどういうのがあるかまとめてみようと思います。 自分がよく README に貼っているバッジ 自分が書く RubyGems については、以下の6個のバッジを必ずつけるようにしています。 Travis CI 言わずと知れた CI サービス。現在の master が CI 通っている (passing) かコケている (failed) かがわかります。リポジトリのメンテナンス状況を把握するのによいです。 クリックすれば、そのリポジトリのテスト結
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さくらVPSにMeCabをインストールしてPHPから利用（CentOS6.4+PHP5.3.3/5.4.2） - 青春B■雑記blog‐青酸カリ カラメルシロップ味‐
長文日記
作中で良い関係の男女に「メールする」「電話する」というセリフを言わせる作者は40代以上である確率が非常に高い？その理由