フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ディレクションが出来るエンジニアがいれば、ディレクターは必要ない - はてな村定点観測所
2014-05-14 ディレクションが出来るエンジニアがいれば、ディレクターは必要ない 最近、フルスタックエンジニアって言葉がバズワードになっている。設計・インフラ・ミドルウェア・モバイル・デザインなど幅広い技術領域に渡って活躍するエンジニアのことを指す。いわゆる万能のエンジニアだ。 自分の経験からすると、フルスタックエンジニアな人もいたけど、技術領域だけに留まらずディレクション能力なども兼ね備えるエンジニアもいた。ディレクターが日常業務として行うチームの調整作業・進捗管理・企画・数値解析なども行うことが出来るエンジニアだ。エンジニア全体からするとまだ少数派ではあるけれど、エンジニアの持つ課題解決能力や開発側から見た企画提案などを行える人はけっこういる。 そして、そういう人がいる環境ではディレクターは不要なんじゃないかと思う。もちろん、ディレクションが出来るエンジニアがディレクションをや
クソゲーを作る組織とそうでない組織 2012 05-12
1. クソゲーを作る組織と そうでない組織 株式会社 Aiming ジェネラルマネージャ / テクニカルディレクター 2012年5月12日 於 ゲームを作る勉強会 小林 俊仁 ( @toshi_k ) 2. About: 小林 俊仁 http://about.me/toshi_k オンラインゲームを作って早10年 基本はゲームも分かる web っ子 @toshi_k Community Engine でオンラインゲーム作って (2001~2003)、中国で子会社作っ てモバゲータウンの中国版（加加城）とか Play Online China とか作って (2003~2007)、子会社を閉じて日本に帰ってきて、その後オンゲの技術ディレク ターとかプロマネとかやってた 最近は、 ONE-UP → Aiming で組織横断的に開発プロセスの改善とかスクラム マスターとか
例え話だけで解決に向かうのか? - 技術的負債論 - MassKaneko.Out
はじめに 以下のエントリがHOTになっています。公開4日後の現在で949はてブです。 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog 私は企業で Software Engineer in Test としてソフトウェアの保守性に責任を持つポジションに就いている身ですのでこのテーマに関心があるのはよいことだとは思います。技術的負債そのものについてのエントリは過去にも沢山あるようですが、mizchi さんのエントリは誤解を恐れないシンプルで断定的な書き方ですので多くの人に刺さったのでしょう。 ただ、技術的負債(technical debt)というメタファーが万人に誤解無く伝わるのかは疑問です。時間を借りているのかはピンと来ませんし、財務的負債と異なり返済の義務はありません。また、エンドユーザーに提供する価値よりも負債にフォーカスし
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
Gitの仕組み - homebrewをフォークするためのGit&GitHub入門 中編 - A Way of Code
前回：Gitのセットアップ 前回、GitHubを使うためのセットアップをしていきました。 今回はGitとGitHubを学んでいきます。 （さらに次回はhomebrewをforkしていきます） 注意: Gitを知らない人がいきなりGitHubを触ったときのメモなので、間違っているところがあるかもしれません。 CVSやSubversion等のバージョン管理ツールの知識がある前提で書いています。 あくまでメモなので説明が至らないところが多々あります。ざっと読み流して、Gitを実際に触ってから読み返したほうが分かりやすいと思います。 目次 1. Gitの構成 1.1 リポジトリ 1.1.1 blobオブジェクト 1.1.2 treeオブジェクト 1.1.3 commitオブジェクト 1.1.4 tagオブジェクト 1.2 ステージングエリア 1.3 作業ツリー 2. リモートリポジトリとローカルリ
「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている！」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
スループットとは - IT用語辞典
概要 スループット（throughput）とは、機器や通信路などの性能を表す特性の一つで、単位時間あたりに処理できる量のこと。ITの分野では、コンピュータシステムが単位時間に実行できる処理の件数や、通信回線の単位時間あたりの実効伝送量などを意味することが多い。 処理の場合 コンピュータの性能について言う場合は、単位時間あたりに与えられた処理を完遂できる回数を表す。CPUやメモリ、ストレージなど装置の構成や性能、処理内容などが複雑に影響しあって決まるため、単一で単純な指標はない。分野や用途に応じて業界団体などが用意した試験用のソフトウェア（ベンチマークプログラム）を実行し、処理件数を計測して相対的な値として表すことが多い。 通信の場合 通信回線や装置のデータ入出力の性能について言う場合は、伝送路を通じて単位時間あたりに送受信できるデータ量を表す。単位として、1秒あたりに伝送できるビット数であ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
戦略(Strategy)、作戦(Operation)、戦術(Tactics)、そして兵站(Logistics) - UEI/ARC shi3zの日記.