タグ

developmentに関するikasam_aのブックマーク (10)

  • livedoor Techブログ : 社内のスマフォ開発用ライブラリの管理方法を公開しちゃいます!

    こんにちは!こんにちは! 最近JavaやObjective-Cで開発をしていて、やっぱりPerlって使いやすい言語なんだなぁと改めて感じている栗原です。 #と言いつつもJavaもObjective-Cも好きだったりします。 今回は「スマフォのライブラリなどの管理をどげんかせんといかん」とCTOに言われたために考えた、弊社のスマフォ開発チームが行なっているAndroidiPhoneそれぞれの社内用ライブラリやスニペットの管理方法についてご紹介したいと思います。 ソースの管理方法 まずソースの管理についてですが、現在弊社のスマートフォン系のアプリはGitを使って管理しています。 通常のアプリも含めて「android」と「iphone」というプロジェクトを作成し、その中でそれぞれのプラットフォーム毎にリポジトリを作成しています。 以下のようなイメージですね。 git://example.com

  • Facebookはどのようにコードを出荷しているか

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Facebookはどのようにコードを出荷しているか
  • RailsDevCon2010で話してきました

    RailsDevCon2010、お疲れ様でした。主催かつ発表のお声をくれた@ysakakiさん、スタッフの方々、スピーカー、発表を聞いてくれたみなさま、どうもありがとうございました。 今回、「Railsプロジェクトを成功させるために現場ができること」というタイトルで話したけどびっくりするぐらいRailsに関係のない話。オマケ程度にちょこっと。以下、資料です。 テーマとしては、@ysakakiさんから声をかけて頂いた時に、[Railsの現場でまだまだバージョン管理すらしてないところあるよね。そういう基的なところを改めて赤松さんの方から話して欲しい」と言うことだったので、個人的に基的な所と言うと「TDD」と「バージョン管理」(できれば継続インテグレーションもいれたい)だったので、その変も踏まえて技術的負債というトピックを扱った。 具体的な話をしても、スクリーン上じゃコード読みづらいし、わか

  • ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
  • いつテストを終わらせるか? - プログラマの思索

    信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。 【元ネタ】 Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ!スーパーエンジニア どこでテストをやめるのか? 日電気株式会社 川村真弥さん オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用 成長曲線(ゴンペルツ曲線とロジスティック曲線) つれづれなる技術屋日記: バグカーブ 対数曲線や二次曲線での近似のお勧め テスト消化曲線とバグ発生曲線の7パターン診断 - @IT MONOist プログラムバグの成長曲線とプログラム品質の判定 テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索 信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。 つまり、テストの止め時は、信頼度成

    いつテストを終わらせるか? - プログラマの思索
  • 現代のAgile開発が抱える課題 - プログラマの思索

    チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S

    現代のAgile開発が抱える課題 - プログラマの思索
  • リファクタリングと作業: 柴田 芳樹 (Yoshiki Shibata)

    テスト駆動開発はテストがパスするように実装して、テストがパスすればリファクタリングを行います。つまり、「Red Green Refactor」がマントラ(mantra)です。 書籍『Refactoring』が出版された当時(1999年)は、まだEclipseはまだ登場していなくて、リファクタリングを行うとうのは、「クリエイティブな活動」と「作業」の組み合わせでした。 どのようなリファクタリングを行うかを考えるのがクリエイティブな活動であり、人が行えるものです。たとえば、簡単なメソッド名の変更において、変更後の名前を考えるのがクリエイティブな活動です。その活動は、コンピュータは行ってくれません。そして、新たな名前に変更するというのが作業です。 Eclipseが登場する以前は、この作業を手作業で行わないとリファクタリングは終わりませんでした。しかし、幸いにこのような作業は、今日ではEclips

    リファクタリングと作業: 柴田 芳樹 (Yoshiki Shibata)
    ikasam_a
    ikasam_a 2010/07/10
    確かに。でも設計書修正プロセスが面倒なことへの解はあるのかな。
  • いきちがいのぷろぐらむあ - FrontPage -    

    2016-11-19[土] C++TemplateのつもりでC#Generics使ってハマる(初歩) 人様のソース改修でロクに知らないC#をここ1,2ヶ月さわってた。 といってもそのソースもC#慣れしたわけでないC系ユーザーが書いたような感じで ある意味助かったのだけれど、コピペ膨れなソースだったので、処理をまとめようと C++Template 的に Generics を使おうとして...ちょっとハマった。 C++だと #include <stdio.h> class Foo { public: void Run() { printf("Foo!"); } }; template<class T> class FooMgr { public: void Run() { T().Run(); } }; class Bar : public Foo { public: void Run() {

  • blog.katsuma.tv

    クックパッドさん主催のRuby on Railsセミナーに参加してきました。Rails仕事では利用していないのですが、CakePHPなんかはRailsと似たところがあるし、スケーリングの話なんかは参考になるところもあるかな、と思い参加。CTOの橋健太さんのトークのみ、という内容だったのですがRailsに留まらない「クックパッドとしてのものづくりに対する考え方」は非常に興味深い内容がふんだんでした。以下、そのメモです。(誤字とかRails系の用語は間違っているものもあるかも、、) クックパッド 毎日の料理を楽しみにすることで心からの笑顔を増やす これだけやる! 世界で一番!生活に役立つサイト作り 月刊ユーザ524万人 四国の人口よりおおい! 20,30代女性中心 20代は4人に1人が見てる!  Railsサイト中世界8位(ユーザ数) 月刊PV2.8億 PV的にはRailsサイトで世界3位

  • プログラマの思索: 構成管理は誰のためのものなのか?

    気になる記事を見つけた。その感想を書く。 【元ネタ】 構成管理は誰のためのもの? 意外と知らない構成管理の正体~第1回 ファイルバージョンの管理だけで十分ですか? 【1】最近のSW構成管理は、単なるバージョン管理、ビルド管理だけでなく、変更理由を追跡できる変更管理の観点を含む時が多い。 その分、構成管理の難易度が上がっているように思う。 単にSubversionやCVSでソースのみをバージョン管理できているだけでは、構成管理できているとは言えない。 そこで、気の利いたチームは、Rational製品のような重厚なプロセス付きの構成管理を導入する時があるだろう。 管理者は構成管理をしたがる。リリース作業がスムーズになるとか、デグレが減るなどの利点があるからだ。 しかし、逆に生産性が落ちる時が多い。 「意外と知らない構成管理の正体~第1回 ファイルバージョンの管理だけで十分ですか?」のように、構

    プログラマの思索: 構成管理は誰のためのものなのか?
  • 1