タグ

2014年12月30日のブックマーク (5件)

  • 家庭内KPTの話

    家庭を支える技術 Advent Calendar 2014 20日目の記事です。 19日目は ikkou さんの「我が家の家庭を支える技術あるいは大好きという気持ちを伝えること」でした。 はじめに我が家では2週間に1度、KPTを使った振り返りを行っています。 先日、同じ年頃の子供を持つエンジニアの人と飲んでいて、 家族でKPTしてるって話をしたら「検討したことはあるけどやってる奴ははじめて」というような反応で、そういえば家族でKPTしてるって話を聞いた事なかったので、書いてみようと思います。 KPTとはあえて書く必要もないかと思うけど、知らない人のためにKPTとは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと(Keep)、問題だったので次はやめたいこと(Problem)、次にやってみたいこと(Try)の3つの軸で整理

    家庭内KPTの話
    ama-ch
    ama-ch 2014/12/30
  • CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog

    はてなCTOのid:stanakaです。 はてなアドベントカレンダー2014も最終日となりました。 今年のアドベントカレンダーは、スマートフォンアプリ開発からシステム系論文の話まで幅広いテーマが集りました。 読んでいて優秀なエンジニアがいるなぁ、としみじみ思います。 ちなみにアドベントカレンダーは25日までじゃないのか、という話がありそうですが、来は24日までだそうです*1。 CTOとは何か論 最終日の今日は「CTOの役割と組織における技術的ポートフォリオの組み方」について考えているところを書いてみます。 最近、なぜかCTO論が盛んで、あちこちでよく耳にするようになってきています。 rebuild.fmでのnaoyaさんのマネージメント話や、WEB+DB Pressの舘野さんの連載などでもCTOやエンジニアのキャリアについての話が盛り上がっています。 つい先日でたWEB+DB Press

    CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog
  • requireの仕組み - ぶれすとつーる

    こんばんは この記事は Node.js Advent Calender 2014の23日目の記事です。 Node.js Advent Calendar 2014 - Qiita 普段node書くとき、何気なく使ってるrequireだけど、どんな風にモジュールが読み込まれてるのかコアコードの中を追ってみる。 https://github.com/joyent/node/blob/v0.11.14/lib/module.js#L362 Module.prototype.require = function(path) { assert(util.isString(path), 'path must be a string'); assert(path, 'missing path'); return Module._load(path, this); }; こいつが各moduleが読み込まれた

    requireの仕組み - ぶれすとつーる
  • io.jsについて知っていること - from scratch

    今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod

    io.jsについて知っていること - from scratch
  • Flux react現状確認会

    2. 前提となる適用先 • 管理画面的なWebアプリケーションのリニューアル …だったもの(仮) • REST APIを前提としたSingle Page Applicationもどき (※すべてが1ページではないけど) • 機能・画面が多い • 複雑化することがほぼ確実 3. Viewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること(含セキュリティリスク回避) (生DOM・jQueryはあり得ない) • 業界におけるパラダイムが過渡期のため、 巨大フレームワークに乗っかりたくは無い (交換可能な部品の組み合わせでプレーンに) • 困ってもなんとか出来るための緊急ハッチも必要

    Flux react現状確認会
    ama-ch
    ama-ch 2014/12/30
    すばらしい