Node-v0.12の新機能について
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 ↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtd
Boxen使ってて許されるのは2013年だけだった - Qiita
Boxen使わなくても許されるのは2012年までだよね を書いたのも今は昔、1年間の運用の末にこの度Boxenを卒業しました。なぜBoxenをやめたのか、やめて今はどうしているのか、といった話を書きます。 Boxenのつらいところ ここで述べるBoxenの問題点の大部分は筆者のBoxenおよびPuppetに対する理解の低さが根底にあります。間違った使い方をしている可能性は十分にあり、適切に使っていればこのような問題は発生しないのかも知れません。しかしながら、深い理解がなければまともに使えないというのもどうかと思いますのでつらつらと並び立てたいと思います。 挙動を把握するのが難しい BoxenはPuppetの上で動作します。Puppetを便利に使うためのフレームワークみたいな位置づけだと思っています。 Rubyに詳しくなくても、RailsのDSLを組み合わせるととりあえず動くものを作れるよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
