_%25E3%2582%25A8%25E3%2583%25B3%25E3%2583%2588%25E3%2583%25AA%25E3%2583%25BC)
就活日記 (0) エントリー - laiso
（知り合い向けの日記です） 就活の件休暇中に雪かきしながら自分自身と向き合い「ほんとうに自分がやりたいことは何か？」「インターネット社会で今私にできることは？」と自問自答した結果「庭から一億円出てきて欲しい」という結論に辿りついてしまったので全然なんも行動してない 2014-01-06 20:00:30 via ハンゲームスマートフォン 2014年こそは就活をはじめたい！ とのことでもそもそと行動をしはじめました。 そもそもなんではじめられなかったかというと、根っからのダウナー系なので履歴書とか意気込みとかを書くのがだるかったのです。 いやしかし。そんな私たちの為にWantedlyがあります。 Wantedlyは最近急成長しているソーシャルリクルーティングサービスで社長がストールが似合うことで有名です (参考: http://blog.kushii.net/archives/1874257
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
Codebrag·Subversion/Git対応のコードレビューシステム MOONGIFT
コードレビューしてますか？ チームのコード品質を向上し、ひいてはシステム品質の向上を目指すためにはコードレビューが欠かせません。工業製品のように一定の品質を担保する技術がない以上、チーム全体でコード品質をあげていくのが最もいい方法ではないでしょうか。 単純に書いたコードを見せるだけでなく、Web上で確認、コメントできるようにすればより優れたコードレビューができるようになると思います。そこで使ってみたいのがCodebragです。 ログインします。 ログイン後。左にレビュー待ち一覧が並んでいます。 項目を選択すると差分が表示されます。 コード中にコメントできます。この辺りはGitHub風ですね。 ハートマークでいいねもできます。 Codebragの特徴としてはGIt/Subversionをサポートしているということがあります。バージョン管理システムの問題なので、GitHubやBitBucket
『上を目指すプログラマーのためのiPhoneアプリ開発テクニック iOS 7編』書評 - その後のその後
加藤さんをはじめとする豪華執筆陣による名シリーズの最新刊です。 上を目指すプログラマーのためのiPhoneアプリ開発テクニック iOS 7編posted with amazlet at 13.12.20加藤 寛人 西方 夏子 藤川 宏之 鈴木 晃 高丘 知央 インプレスジャパン 売り上げランキング: 1,885 Amazon.co.jpで詳細を見る このシリーズは毎回買っていて、iOS5プログラミングブックに関しては紙の書籍を持っていたにも関わらず、そのあと達人出版会で電子版が販売されているのを発見してさらに買い直した、というぐらいお世話になっています。 今回はありがたいことに @hkato193さんより献本いただきましたので、気合い入れてレビュー記事を書きたいと思います。 ちなみに本日より発売です。一部大型書店などでは昨日から並んでいるようです。 （隣に並んでいる達人のナントカという本も
高速にドッグフードを食べる方法 - hitode909の日記
はてなエンジニアブロガー祭りで「高速にドッグフードを食べる方法」という題で発表してきた． 箸でドッグフード食べるパフォーマンスの話ではなくて，もとはマイクロソフト用語である，Eat your own dog food，自社製品を使ってより良くしよう，みたいなほうの話．はてなブログ開発しながら毎日使うとか，思い付きで作ってるわけではなくて，事実や根拠にもとづいて作ってるとか，安全に作るための仕組みとか，そういう話． 普段の勉強会では僕は主に3分くらいのLTをしていて，20分も話したことなかった．資料ぜんぜんできなくて，Keynote見るだけで疲弊してた．急に長くていい話できるはずないと思って，LT5連発という形にして，ドッグフードにまつわる話を5個するという形にしたところ，なんとかなった． 東京では情報が氾濫してるから，京都でこんなのやってますとか言っても，東京では常識みたいな冷たい反応をさ
よく分かる！iOS アプリのリリース手順のまとめ | DevelopersIO
2014/04/16 コンプライアンスの「Content Rights」と「Advertising Identifier」についての解説を追加しました。 はじめに iOS 7 がリリースされ、さまざまな新しい機能が使えるようになりました。iOS 7 SDK を使ったアプリをリリースしたい！と思っているかたも多いのではないでしょうか。しかし iOS アプリのリリース作業は手順が複雑そうで取っ付きづらい印象を持たれているかたが多いと思います。筆者もそうでした。 ということで、最新 (2013年10月21日現在) の iOS アプリのリリース手順についてできる限り分かりやすくまとめてみました。リリース時の参考にしていただければと思います。 概要 まずはじめに全体像を確認しておきましょう。iOS アプリのリリースは下図のようなフローで行います。 リリース用の Provisioning Profil
設計レビューに私情を持ち込んでいませんか？
設計・開発・運用業務に役立つ書籍をピックアップして紹介する新連載「情シスの本棚」。第1回は、システム開発の現場で働く多くの人が思い当たるであろう、設計レビューの問題点と方法論を解説した書籍を紹介する。 「システム構築プロジェクトでは、さまざまな会議が開かれます。そのなかでも、参加する際にとりわけ気が重いのは、ドキュメントの問題指摘を行うレビュー会議ではないでしょうか。長々と続くにつれてレビューアーがイライラし、ドキュメント作成者がつるし上げられたり、レビューアー同士で言い争いになったりする――。そんな状態だから、長い時間をかけた割に重大な問題を指摘しきれずに終わるケースが少なくありません」。「頑張るだけのレビューには限界があります」。「必要なのは、レビューのやり方を見直すことです」――。 本書、「間違いだらけの設計レビュー」は、レビュー方法論の第一人者である名古屋大学 大学院 情報科学研究
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
ゲーム開発の企画から開発までを解説した本「遊んで作るスマホゲームプログラミング for Android」 - 強火で進め
「遊んで作るスマホゲームプログラミング for Android」というProcessingを使ったゲーム制作の解説本を献本頂きました。 タイトルには「for Andrdoid」と付いていますが使用している開発環境がProcessingなのでPCやブラウザ向けに制作する事も可能です。書籍内でもPC環境向けやブラウザ向けのビルド方法の解説などもされています。 2Dゲームはもちろん、3DやKinectを使ったゲームなども解説して有ります。 現役のゲーム開発者さんが書かれている本という事も有り、バンダイナムコゲームスの中の人が書かれたUnity本みたいにプロの方ならではのテクニックやコラムが書かれていたので良かったです。 例えばキャラクターがマウスカーソルに追随するというサンプルでも以下の様に現在のキャラクター(リンゴ)の位置を90%、マウスカーソルの位置を10%合成するというコードに成っています
iPhoneアプリ申請やAppleの審査に関するメモ - Qiita
iPhoneアプリの申請作業を行う上で知っておいた方が良いことをまとめておきます。 一部個人の見解も混ざってます 申請ルールなどは予告なしに変更になることがよくあるので、本記事の内容は古い場合があります アプリ申請前 アプリはどこから申請するの？ App Store Connectというサイトから申請できます。ブラウザはSafariでアクセスすることをおすすめします。 ※2018/6/5 、「iTunes Connect」は 「App Store Connect」 に名称が変更されました。 誰でも申請できるの？ Apple Developer Programに登録する必要があります。（年間参加費 ¥11,800） また、アプリのアップロード時にはXcodeが必要なので、Macは必須になります。 アプリの申請時には何が必要なの？ 次の情報が必要になるので事前に準備しておきましょう。 アプリ名
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Review Board - It's a bright day for code review!
It's a bright day for code review! Still on pull requests? See why organizations upgrade to Review Board: Code review, document review, and image review, all in one place Your code and data stays private, secure, and in your control (Review Board won't mine your data for AI training or other purposes) Works with what you use today (such as Git, Mercurial, Perforce, ClearCase, Cliosoft SOS, or Azur
Crucible: Git、SVN などでのコード レビュー | Atlassian
SVN、Git、Mercurial、CVS、Perforce のいずれのシステムにおいても、コードをレビューし、変更について議論を交わし、知識を共有し、欠陥を特定します。
r-labs - Code Review - Redmine
Redmine Code Review プラグイン ダウンロード 正式公開版 開発版 インストール 注意 使い方 レビューを書く 差分にレビューを書く 新規追加ファイルにレビューを書く レビューを読む Redmine Code Review プラグイン¶ English page is here. Redmineのリポジトリブラウザにレビューを書き込むことができます。 任意のリビジョンにレビューを書けます。 任意のリビジョン間の差分にレビューを書けます。 チケットに添付したパッチファイルにレビューを書けます。 レビューの実態はチケットです。 レビューに返信することができます。 レビューが追加されたらメールで通知することができます。 レビューの状態(オープン中、クローズ済み)管理ができます。 ダウンロード¶ 正式公開版¶ http://code.google.com/p/r-labs/dow
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
automated tests - What is the most mature BDD Framework for .NET? - Stack Overflow
Codebrag - your daily code review tool
もっとコードレビューを楽しく！を目指した『CodeBrag』 | 100SHIKI
gerrit - Google Code