Technical Note TN2435: Embedding Frameworks In An App
What is a framework?A framework is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package. Apps using frameworks need to embed the framework in the app's bundle. Adding A Framework TargetApps wishing to utilize frameworks to share code across different parts of their application, such
The Collaborative API Development Platform
New Release - Insomnia 8.0 is finally here with Scratch Pad, Real-Time Collaboration, Enterprise SSO, AI-Generated Testing Design, debug, and test APIs locally or in the cloudChoose Local, Cloud, or Git storage to build better APIs collaboratively with a dev-friendly UI, built-in automation, and an extensible plugin ecosystem. Get Started for Free
The Future of API Design: The Orchestration Layer
Celebrate King's Day with TNW 🎟 Use code GEZELLIG40 on your Business, Investor and Startup passes today! This offer ends on April 29 → Daniel Jacobson (Twitter | LinkedIn), is currently director of engineering for the Netflix API. Prior to Netflix, Daniel ran application development for NPR where, among other things, he created the NPR API. He is also the co-author of APIs: A Strategy Guide. The
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
チーム開発レトロスペクティブ
大学の講義の関係で、4月から12月まで7人のチームで開発を行いました。自分の役割はチームリーダーでした。これはある種残念なことかもしれませんが、いろいろやりたいことができる立場であったので、やってみたいことを出来る範囲で盛り込んでいきました。この記事では、このチーム開発における制約条件を述べた後に、その制約下でできそうだと考えたことをまとめます。そして実際に行ったことについて、その意図と実際の運用結果、反省点をまとめます。最後に適当に雑感など述べます。 制約条件 このチーム開発を行うプロジェクトでは次のような制約条件がありました: 開発期間は5月から11月まで 給与は出ない チーム人数は6人から7人 開発するアプリケーションは「大学生の学びを楽しくするアプリケーション」 Android上で動作するアプリケーションであること これらの制約条件のうち最もきついのは最初の開発期間です。一見開発期
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
俺式4.0 :: 方向キーとボタンが無い時代のゲームづくりについて
Created: 2012-12-30 Modified: 2012-12-30 Written by Tatsuya Koyama 0. 最近の僕は何を考えるか この文書は平行世界における 21 歳の僕へ向けたメッセージだ。 この記事では 就職して３年も経つと、人生について色々考えるようになる。 このまま行って最終的に僕は何が作れるのかなーとか、 これから先何年も満員電車で往復する朝晩でいいのかなー、とかね。 まあでも実際は、どうなるか予測のつかない未来のことを考えるのより、 今現在つくりたいゲームのことを考えることの方が僕は好きだ。 そう、どうなるかなんて予測がつかないんだ。 僕はウェブの勉強をしようと思って敢えてゲーム会社を選ばず今の会社に就職したのに、 結局今はゲームをつくっている。 今はまだ、自分がゲームをやるのと作るのを好きだと信じて疑っていないけど、 これから先、ゲームより魅
日本語 : Plugin tutorial
Created by Unknown User (sogabe), last modified by Unknown User (kohsuke) on Apr 30, 2012 オリジナル: Plugin Tutorial このドキュメントでは hello-worldプラグイン とともにプラグイン開発の始め方を示しています。 プラグインは何ができるの？ Jenkins では拡張ポイントを定義しています。それはビルドシステムのある側面をモデル化したインターフェースもしくは抽象クラスです。これらのインターフェースでは実装する必要があるものを定めており、Jenkins ではプラグインがこの実装にコントリビュートすることを許可しています。拡張ポイントについてもっと知りたい場合はこのドキュメントを見てください。 このドキュメントでは、ビルダー を実装してhelloと出力します。（ビルトインのビルダ
増14．“テストファースト”と言われて：自転車とプログラミングと：エンジニアライフ
●今回の発端 筆者は直接は言われたことはありませんが、別の所で仕事をしている人などは、「テストファースト」でプログラムを作るのが良いと言われたことがあるそうです（その人は「緑の文字」と言われただけで嫌そうな顔をしていました）。Webの記事などでも見かけます。 もちろん、人間の価値観で軽重の無いプログラムの成果を、人間の価値観に引き込む唯一といっていい方法がテストです。テストは必要です。 しかしながら、“仕事で分担して作業しているプログラマに直接”“「テストファースト」をしろ”と、言われると、まるで「労せず実務上の権限をごっそり奪取しよう」としているように聞こえます。多分、周りの人が手をこまねいていると本当に奪取されるかもしれません。 なぜ、良いことのはずが、こんなにひどいことになるのか？ その辺りを描写したいと思います。 ●背景説明 学生のプロジェクトなどで、 自分一人でやっている デザイ
最近の git の使い方について - tomykaira makes love with codes
先日の #shibuyarb の懇親会ですこし話したら、わりと食い付いてもらえたので、 knowledge worth spreading だと感じた。git の設定を中心に共有する。 ワークフロー @kyon_mm さんの Continuous Commit の熱心な信奉者である。 Continuous commit とは continuous integration, continuous delivery とおなじように、開発中のコミットを自動化する試みである。 continuous commit という言葉はなくても、おなじようなことを自分でやっているひとは多そうだ。 continuous commit は大量のコミットログを残すので、これを整理する作業はけっこう負荷が大きくなる。 最近はこのあたりを改善している。似たようなワークフローを採っている人には役にたつと思う。 コミットを
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
基礎研究と応用研究とをつなぐ橋。薬作り職人のブログ
「〇〇の仕組み解明、××の治療に応用期待」なんてタイトルのマスコミの報道をよく見かけます。このブログでも、ときどきそのような話題について取り上げたりしています。 このような報道は、これまで星の数ほど行われてきました。しかし、「××の治療」に応用できたものが果たしてどれだけあるのか、ということを考えてみると、パッと思い浮かぶものはなかなかありません。もちろん、さらなる基礎的な研究は続いているのでしょう。ただ、そこから先、新薬という結果が出せたのか、そこまでいかないまでも、その発見を元にした薬をつくろうという動きがあるのか、といわれると、多くのものはそこまでいかないのではないかと思います。 治療薬の研究を開始して、それを薬を作り出すのには、10年（もしくはそれ以上）の期間がかかります。新しい発見を元にした薬の開発が製薬会社で行われているとすれば、何らかの形で進捗がわかるものです。例えば、特許と
Minimum viable product - Wikipedia
This article is about the product development strategy. For the pilot episode of Silicon Valley, see Minimum Viable Product. A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.[1][2] A focus on releasing an MVP means that developers potentially avoid lengthy and (possibly) u
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Remove unused CSS - CSS Optimizer
github を用いた開発フローテンプレート
Amazon.co.jp: アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント: 平鍋健児, 野中郁次郎: 本
