タグ

developmentとprogrammingに関するyogasaのブックマーク (149)

  • リファクタリング 目的・パターン・思考 / reprotech

    Modern Angular with Lightweight Stores: New Rules and Options

    リファクタリング 目的・パターン・思考 / reprotech
  • あなたの知らない連絡先の世界

    「iOSから連絡先をサーバーに同期させたい」 用件を受け、iOSにはContact APIがあるから楽勝でしょ、と思ったあなた。 しかしながら連絡先の構造はそんなに簡単なものではありません。 ミドルネーム?Suffix?振り仮名?旧姓? そんなハマりやすい連絡先処理の説明やVCard変換など、 …

    あなたの知らない連絡先の世界
  • [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp

    第16回プログラミング言語とTDDは、どちらを先にマスターすべきか? 和田卓人 2007-12-21

    [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
  • データがどのように更新されてきたのか追跡する - クックパッド開発者ブログ

    こんにちは。技術部の吉川です。 みなさんは、異常なデータを見つけたが、どうしてそのような状態になったのか追跡できず困ったという経験はないでしょうか。 今回は、そんなときにクックパッドで利用されているAuditログについてご紹介します。 Auditログとは クックパッドでのAuditログは特定のデータレコードに対して発生したイベントをコンテキストとともに記録するものです。 一般的に監査ログ、証跡ログといったものがありますが、それらとは多少異なっています。 ここでのイベントとは、あるデータレコードが 作成された 更新・変更された 削除された といったものです。またそれ以外にもログインした、ログアウトした、セキュアな情報が閲覧された、といったイベントも含まれています。 コンテキストは以下のようなものを記録します。 いつ どこで 処理が行われたホスト 何が イベント 何を 対象データの情報 スキー

    データがどのように更新されてきたのか追跡する - クックパッド開発者ブログ
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    2. 自己紹介 • 1998年 株式会社ナムコ 入社 • 1999年 蚊取り大作戦 (ナンジャタウン) • 2000年 ディグダグ (パチスロ) • 2003年 ミスタードリラー ドリルランド (GAMECUBE) • 2003年∼2004年 ドンキーコンガシリーズ (GAMECUBE) • 2005年∼2006年 リッジレーサー6, 7 (Xbox360, PlayStation3) • 2006年∼ 社内サウンドライブラリ NUSound アーキテクト 4. リッジレーサー6 Love FOOTBALL リッジレーサー7 鉄拳5 DARK RESURRECTION 鉄拳5 DARK RESURRECTION ONLINE ビューティフル塊魂 エースコンバット6 鉄拳6 ソウルキャリバー レジェンズ スマッシュコート3 ファミリースキー ファ ミリージョッキー もじぴったん プチプチ ソ

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
  • デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)

    DevLove甲子園 東日大会でお話した内容です。 http://devlove.doorkeeper.jp/events/11792 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less

    デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)
  • テスト駆動型開発についての議論 - ワザノバ | wazanova

    http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想

  • テスト考2014 - Hidden in Plain Sight

    年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも

    テスト考2014 - Hidden in Plain Sight
  • アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io

    Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね! で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ

  • B2Cモバイル開発のいまとこれから #forcedotcomjp

    Salesforce Developer Conference Tokyo 2013 での発表資料

    B2Cモバイル開発のいまとこれから #forcedotcomjp
  • ブラックボックステストとホワイトボックステスト | DevelopersIO

    テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装(コード)を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装(コード)を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか? それともブラックボックステストでしょうか? 「JUnit実践入門」では次のように記述しました。 書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行

    ブラックボックステストとホワイトボックステスト | DevelopersIO
  • 徹底解説!Project Lambdaのすべて[JJUG CCC 2013 Fall H-2]

    JJUG CCC 2013 Fallで発表させていただいた「徹底解説!Project Lambdaのすべて」の資料です 最新のものはこちらです. http://www.slideshare.net/bitter_fox/ss-35882498

    徹底解説!Project Lambdaのすべて[JJUG CCC 2013 Fall H-2]
  • 開発時に出会いたくないパターン - Perl日記

    悩んだりうまくいかなかったり解決したり。だらだら書いた。 手作業症候群 とにかくなんでもかんでも手で確認・作業する必要があると思い込んでしまう病。 そりゃiOSアプリとかAndroidアプリとか最終的には実機確認は必須だけれども。 その前にやれることは多々あるはず。リグレとか。 あと「デプロイ職人」も不要にするべき。わかってる。 自動化できない要素を突っ込んでる方が悪いのだ。なんとかする。 masterブランチぶっこみ志向 masterブランチに直接コミットを重ねていくことにより開発速度をアップさせることができる。 ただし孤独な背水の陣を構えることになる諸刃の剣。 おとなしくtopic branchを切って作業するのが安心への近道であり王道である、 とか言ってたらみんなちゃんと切ってくれるようになった。めでたし。 チケットそっ閉じ症候群 来はリリースしたりデータを修正したりしてチケットと

    開発時に出会いたくないパターン - Perl日記
  • Java での web アプリケーション開発時の開発環境メモ #1 - 一角獣は夜に啼く

    最近 Java で web アプリケーションを開発しようと思って、アプリケーション構成やら開発環境周りやら悩んだりしていたのだけれど、ある程度良さそうな構成に落ち着きつつあるので現状をメモしておく。 アプリケーション構成 とりあえず HTTP 周りは JAX-RS に任せるのが良さそう。 JAX-RS 実装としては Jersey を選択。 JBoss RESTEasy とかも試してみたけど、JAX-RS の参照実装ということもあって Jersey は癖が少なくて使いやすいのかなーと思ったりした。 Web 上の情報も多そうな気がする。 JAX-RS 2.0 Jersey 2.4 Servlet コンテナ内で動かすことを想定 ビルドツールとしては Gradle を選択。 IDE との連携を考えると Maven の方が有利かなーとも思ったけど、実際 Eclipse と NetBeans で試した

    Java での web アプリケーション開発時の開発環境メモ #1 - 一角獣は夜に啼く
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • ドメイン駆動設計入門

    6. ドメインモデル • 業務のデータと業務の機能をコードで表現 – ビジネス層に集約する – 関係するデータと機能をクラスにまとめる • ハイブリットなアプローチ – データの視点と機能の視点 • 両方からアプローチする • 二つの視点をいったりきたりする – データと機能の結びつき強める • クラスにカプセル化 • データ保持クラスと機能クラス(データ操作クラス) に分けるのはアンチパターン

    ドメイン駆動設計入門
  • プログラマは金魚鉢で泳ぐ - ふたつの教室

    いやー、暑いっすね。こうも暑いと仕事の合間にちょっとひと泳ぎしたくなるって事でエクストリーム フィッシュボウルやってみるかーと思い、チームメンバー10人くらいで試してみました。 エクストリーム フィッシュボウルって何かというと、もともとはグループワークの手法で、数人が輪になってディスカッションしてるのを囲むように数人が観察する「フィッシュボウル」というのがあって、それをベースに考えられたものだと思います。(たぶん) で、エクストリーム フィッシュボウルではペアプロをしてる2人をみんなで観察するのですが、観察するだけじゃなくて、質問したり野次を飛ばしたり、実装するメンバーを交代したりしながら開発する手法です。あまりとかでは見かけないですが、勉強会などで時折行われていたりします。 詳しくはainameさんの説明資料をどうぞ。 extream fish bowl チートシート(Gist) ちな

    プログラマは金魚鉢で泳ぐ - ふたつの教室
    yogasa
    yogasa 2013/08/17
    エクストリーム フィッシュボウル。ペアプロをしてる2人をみんなで観察
  • スマートフォン開発研修教材の公開について - mixi engineer blog

    クラフトワークの来日公演3-D CONCERTS 1 2 3 4 5 6 7 8を観にいったら、顔が大きいのか、3Dメガネがきつくて切なかったもりもとです。 株式会社ミクシィでは、新卒入社スタッフをはじめ、これからスマートフォンアプリ開発を行っていく全スタッフを対象に、社内で「スマートフォン開発研修」を始めています。その研修資料をこのたびgithubで公開させていただきました。 mixi-inc/iOSTraining · GitHub https://github.com/mixi-inc/iOSTraining mixi-inc/AndroidTraining · GitHub https://github.com/mixi-inc/AndroidTraining これら文書は、それぞれCC BY-SA 3.0およびApache License 2.0とCC 2.5 Attributi

    スマートフォン開発研修教材の公開について - mixi engineer blog
  • Rails + Heroku で俺専用RSSリーダー作った

    Webアプリのリハビリ ということで、Official Blog: A second spring of cleaningで告知された、Google Reader閉鎖に備え、俺専用RSSリーダーをRuby on Railsで軽めに作ってみた。 read.aho.mu 目的としてはRuby + Railsの学習と、サーバーサイドのリハビリのつもりだったのだけど、簡単すぎて実作業1日分くらいで終わってしまった..(´・ω・`) 自分で登録したフィードを、自分でなんとなく流し読みして、良いと思った記事に♡を付けられるだけなのですが、それがついでにオープンになっているだけ。 色々もにょもにょ 触ってみた箇所について所感など。 前からScalaなりNodeなりでHello Worldまでは試してましたが、素直にRailsをデプロイして動くところまで手を入れたのは初。 無料で使えるアドオンを幾つか入れ

    Rails + Heroku で俺専用RSSリーダー作った
  • Joel on Software - 射撃しつつ前進

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ