開発効率アンチパターンCustomizing Theme and Style for Material Design : Droid Kaigi 2016
中規模iOS開発とコードレビュー
フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました matsuiです。 先週末の2014年6月13日～14日に、札幌でオープンソースカンファレンス 2014 Hokkaidoが行われました。 弊社インフィニットループもスポンサーとして、セミナーの発表を1コマと、ブースを出させていただきました。 その際に使用したスライド資料を公開しましたので、どうぞご覧下さい。 おかげさまで満席でした。来て頂いた方ありがとうございます。 講師の佐々木、なぜか白衣です（理科の先生に憧れてるらしい）。 ブースはこのような感じです。 新作ゲームである「勇者と1000の魔王」と、Android用のタイムカードアプリである「かざしてシュキーン」を展示しました。 ツイート
システム統合にSOA？ RDBMS？ bashで十分！ － ＠IT
2009/09/07 毎年夏に開催される軽量プログラミング言語（LL：Lightweight Language）をテーマにした「LLイベント」。第7回目となる「LLTV」が、2009年8月29日に東京・中野で開催された。この記事ではプログラムの一部、「大改善!!劇的ビフォーアフター」をレポートする。前編では、Rubyによるfortuneコマンドの“増築”と、Firefox拡張によるslコマンドの実装というネタ系発表をレポートした。中編ではC言語にLisp風のマクロを取り入れ、lsコマンドのソースコードを約半分に削減する匠の技をレポートした。後編となる本記事では、売り場業務が滞りがちだった販売管理システムをbashコマンドで“建て直した”という劇的ビフォーアフターの発表をレポートする。 DBを捨ててテキストファイルに変換 「100万件ぐらいの検索なら、シェルだけでも1000分の数秒でできます
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
プログラムに証明が付く日 | RANDMAX
この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ！ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
ja: NetBeans 日本語サイト
このサイトについて - About this site Here is a NetBeans, Japanese Speaking Community. All contents are available in Japanese. このサイトは NetBeans 日本語サイト です。netbeans.org 内に設けられた日本語のサイトです。日本語によるメーリングリストの運営やドキュメントの公開などを行っています。このページは、NetBeans オープンソースプロジェクトの中の ja というサブプロジェクトのトップページでもあります。日本語サイトプロジェクトへの参加方法などはプロジェクトについてを参照してください。
社内向けWebサービス開発のススメ - kotas.tech
社内向けWebサービス「ニコニコプロデュース」 例えば、コードレビューをしている時に誰かが鋭いツッコミを入れてくれた時。 例えば、社内のチャットで、ふと誰かが名言を書き込んだ時。 そんな「もっと評価されるべき」を、「評価」する手段が欲しい。 そんな思いから、社内向け Web サービス「ニコニコプロデュース」を作りました。 画面はこんな感じです。 使い方は簡単で、「だれうま」とか「GJ」とか思ったらポイントをあげる。それだけです。もらったポイントの使い道は特にありません。 こんな感じで、趣味としてちょこちょこ社内向けサービスを作ったり、簡単なツールを作ったりしているので、その魅力について語りたいと思います。 作っている間 なにせ自分で1から企画して自分で全て実装するので、作っている間はとても楽しいです。 「こういうページがあってー、こういう UI でポイントをつけれてー・・・あ、ユーザー認証
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編）
SIビジネスの本質は保険屋であり、受託開発でアジャイル開発が失敗するのは受託開発が製造業だから。11月19日に行われた楽天テクノロジーカンファレンスでの講演「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン」では、ソニックガーデン代表取締役社 倉貫義人氏によるこのような示唆に富む内容が語られました。 さらに倉貫氏は、ソニックガーデンで行っているクラウド時代の受託開発の新しいモデルについても詳しく紹介しています。 同氏の講演の内容を、配信されたUstreamの動画を基にして紹介しましょう。 プログラマを一生に仕事にできるビジネスモデルで目指す未来のビジョン ソニックガーデン代表取締役社長 倉貫義人氏。 倉貫です。今回のオファーをいただいたときに「技術者の人が元気になるような話をしてほしい」というのがあって、私自身がずっとエンジニア、プログラマやマネージャ、営業などいろいろや
プログラマになるための勉強をしている人の前で話をしてきた - きしだのHatena
イデアルITスクールというところで、１時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出
「自分が使いたいものを、ピュアな気持ちで」 家計簿アプリ「Zaim」を開発した閑歳さん
「自分が使いたいものを、ピュアな気持ちで」 家計簿アプリ「Zaim」を開発した閑歳さん（1/2 ページ） ソーシャル機能を持つ家計簿アプリ「Zaim」を個人として開発した閑歳孝子さんは、MacBook Proを駆使して通勤電車内でもコードを書く。「プログラミングは編み物に似ているので、女性に向いている」という。 TwitterやFacebookと連動するソーシャル家計簿アプリ「Zaim」（ザイム）がヒットしている。7月19日にiOS版がリリースされた直後にAppStoreのファイナンス部門で1位にランクイン、4日間で1万DLを突破した。開発したのは、気鋭のエンジニアとして注目を集める閑歳孝子さん（32）。アクセス解析ツールを手がけるユーザーローカルの社員だが、今回は個人としてサービスを立ち上げた。「ピュアな気持ちで作りました」という閑歳さんに、開発の舞台裏を聞いた。 Zaimの特徴は、「簡
Private Presentation
Private content!This content has been marked as private by the uploader.
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
誰でも即席“Androidプログラマ”に、Googleが開発ツール「App Inventor」を一般公開
言語を知らなくても簡単にAndroidアプリが作れる――。誰でもプログラマになれる“驚愕”の開発ツールが登場した。米Google社が提供する「App Inventor」だ。早速、開発のしやすさを体験してみた。 米Google社は2010年12月16日、Androidアプリを開発するためのツール「App Inventor」のベータ版を一般公開した。同年7月から登録者のみに提供していたものだ。ツールおよびWebサービス、Javaアプリの3つの組み合わせで実現している。 App Inventorの特徴は、プログラムをコーディングしなくても、Androidスマートフォンで動作するアプリが即席に作れること。パズルを組み合わせる感覚でプログラムを作成できる（図1）。Javaを知らない人でも、Androidスマートフォンを持っていれば、そのまま個人用のアプリが即製可能だ。
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
幸せなエンジニアになるための仕事術/まつもとゆきひろ＆平鍋健児 - tmtms のメモ
幸せ 平鍋: 1. 技術的な困難を達成。 2. お客様に感謝された。 最初は1だったけど最近は2。 まつもと: 理不尽な目に合わないこと。 思うようにツールが動かない→自分でつくる。 OSSは自分で手を入れられる。 平鍋: 自分一人の幸せじゃない。 プロジェクトが終わっても続く人間関係。 人のつながり。信頼。 まつもと: 通勤が3時間。理不尽→地方。 納得行かない変更が顧客から言われたくない 平鍋: エンジニアで不幸せな人へ。仕事は選べる。極端なこと言えば辞めればいい。 ワークライフ・バランス実現の戦略（例：地方に住むこと） 平鍋: 1995.子供を育てられるかを考えたときに自分の中での都会の価値がさがってきた。 田舎に帰ってから、世界のことを考えた。JUDE,アジャイルをやり始めた。 まつもと: 鳥取→つくば→島根 1997. OSSビジネスを始めようと声をかけてもらって島根へ。 理不尽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本当に怖いパフォーマンスが悪い実装 #phpcon2013
