GitHub - kentaro/puppet-bookYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ソフトウェア開発の超概算見積もり | Moonmile Solutions Blog
（誰も待っていないと思うけど）お待ちかねの「３分間見積もりクッキング」の時間です。 結局のところ「概算見積もり」というのは、QCD（機能、コスト、納期）の枠を決めることで、その範囲内で、 ・人員を確保する。 ・機能を配分する。 ・社員を育てる。 ・できるだけ、利益を出す。 を行います。 なので、以上を踏まえたときに、大まかな見積もりは以下の点のみ決めます。 発注会社サイド ・全体の開発予算（コスト） ・開発期間（納期） 機能が抜けているのは、作らなければいけない機能よりも、予算や期間が優先されることが多いためです。 特に発注会社の場合は、 ・開発予算から利用するアプリケーションの減価償却 ・利用開始時期から、開発期間 が決まるために、ある意味で「機能」のほうが調節可能な場合が多いのです。 # 現に、予算が少ない場合は、機能削減で凌ぎますし、 # 予算が多い場合は「機能を盛り込み」ます。 #
社内で『チームが機能するとはどういうことか』の読書会をやっています - hapicky’s snapshots
これは feedforce Advent Calendar 2016 の19日目です。ひとつ前は mizukmb の わたしのGit/GitHubの使い方 でした。冒頭の写真、HKKBにカタカナのテプラが貼ってあるだけで「これは偽物なのかな？」と思わせる雰囲気が私は好きです。 さて私は、社内で書籍 チームが機能するとはどういうことか の読書会を社長や取締役から現場のエンジニアまで、様々な役職/職種の人で集まって開催していることについてお伝えしたいと思います。ちなみに本の内容についてはほとんど触れませんのでご了承ください。 経緯など 読書会を開催する前の状況は以下のような感じでした。 個人として本は持っているが内容はつまみ食いした程度 心理的安全性や「許可より謝罪」は理解している 新人エンジニアがSlackで「すみません」とか前置きしようものなら、先輩が「謝らなくていいんだよ」とフォローして
LinuxのARPとL2スイッチのお話 - masayoshiの日記
この記事は、はてなエンジニアアドベントカレンダー2016の12月19日の記事です。 developer.hatenastaff.com 昨日はid:taketo957くんの 10ms以下のレスポンスタイムを支える継続的負荷テスト - taketo957の日記 でした！ Webオペレーションエンジニアのid:masayoshiです。 2016年に入社後、基盤チームとして仮想化、ネットワーク周りを中心に見ています。 さて、この記事ではLinuxのARPの挙動とその挙動から起こった問題を紹介しようと思います。 長々と記事を読みたくない人向けに結論をまとめるとLinuxのARPはTCP通信で使われ続ける限りキャッシュが飛ばないという挙動になるので、複数のL2スイッチにまたがったセグメントや非対称ルーティングをしている場合は気をつけましょうという話が書かれています。 今回紹介する事例自体は別に新規性
mod_pagespeedの概要と導入について | 株式会社サイバーエージェント
業務経歴： 元Web/iOSの受託開発を行うエンジニア。プログラマーからSE/PMを経てマーケティング支援業務も行う。サイバーエージェントでは開発チームのマネジメント兼自身でもサーバ側のコードを書いている。 1.概要 スマートフォンサイトにおける表示スピード向上は、より高度な内容を実現する昨今のサービスにおいて喫緊の課題となっている。その中で2012年にGoogle Incが正式版として公開したmod_pagespeedは、インストールのみでウェブサイトの最適化を行うことができ注目を集めている。しかし、その動作原理上マシンリソースを余分に消費してしまう。本レポートでは、mod_pagespeedの各最適化アプローチを検証し大規模環境での適用について検証する。 3.序論 本レポートの動機となった背景および、レポートの題材となるmod_pagespeedの概要について示す。 3.1 背景 スマ
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
