INF-015_そこのコンテナ、うまく積めてるね! ~Windows アプリケーション コンテナの展開と運用~decode2016
INF-015_そこのコンテナ、うまく積めてるね! ~Windows アプリケーション コンテナの展開と運用~decode2016
以前に2回に渡ってiOSの開発でスタティックライブラリィの扱いについて書いた。 [Objective-C][Xcode][iOS]Xcode 4.3でスタティックリンクライブラリィを扱う (その1) [Objective-C][Xcode][iOS]Xcode 4.3でスタティックリンクライブラリィを扱う (その2) この時はスクリーンショットを入れながらだったので、ごちゃごちゃと長くなったが、超要約すると以下の手順でスタティックライブラリを扱うことができるはずだ。 ライブラリ側 1.公開するヘッダファイルの"Target Membership"を全て"public"に設定する(デフォルトは"project") 2.ビルドセッティング"Installation Directory"の値を環境変数"$(BUILT_PRODUCTS_DIR)"に設定する 3.ビルドセッティング"Public
タイトルは釣りぽよ〜 今日ここで書くのはわりかし最近知ったことだったりするのが多いんですが、せっかくなので書いておこうかなぁと思った次第です。Linuxって書いてるけど、普通にMacでも使えるハズです。 知ってる人にとってはアタリマエのことですけどね……。 ファイルサイズの桁でかすぎてがわからん ls とか duあたりで使える話ですね。 ファイルサイズが大きすぎてパッと見わからないよっていうことってあるじゃないですか。ありますよね。いやある。 そんな時は -h オプションを使いましょう。 $ ls -l /var/log/nginx/access.log -rw-r--r-- 1 root root 1897381 8月 26 02:50 2012 /var/log/nginx/access.log $ ls -lh /var/log/nginx/access.log -rw-r--r--
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
IT業界のイベントなどで行われるパネルディスカッションを成功させるためのノウハウについて、準備編はどのような事前準備をすべきかについて説明してきました。本番編では、本番でモデレータが果たすべき役割などについて紹介しましょう。 (本記事は「パネルディスカッションを成功させるためにモデレータがしなければならないこと(準備編)」の続きです) マイク、スクリーン、机と椅子 パネルディスカッションを成功させるためには、ステージ上にセットしてもらうマイクやスクリーンなどの設備の面でもしっかりした準備が必要です。必ずこうしなければならない、というルールはありませんが、あったほうがよい、というものは確実にあります。 最も重要なのはマイクです。人数分のマイクが用意され、できればスタンドにセットされているか、ピンマイクがセットされているのが理想的です。 パネルディスカッションでは、パネリスト同士の議論こそもっ
ステージの上に専門家が並び、与えられたテーマに沿って本音をぶつけ合う。IT業界ではこうした形態のパネルディスカッションが、ベンダー主催の大きなイベントからコミュニティによる勉強会まで、さまざまな場所で行われています。 筆者(新野)は、10年以上前からパネルディスカッションのモデレータの依頼を数多く受けてきました。おそらく、IT業界においてモデレータをもっとも多くこなしてきたひとりだと思います。 大きなイベントでは、例えば2009年、2010年にIBMのイベント「IBM Rational Software Conference 2009」や「Innovate 2010」で、アジャイル開発をテーマにしたパネルディスカッションのモデレータを担当し、来場者アンケートの評価で2年連続して基調講演を含めて全数十セッション中最高の評価を得たことがありました。コミュニティ主催のイベントでも、昨年の「クラウ
環境構築を自動化すれば数分でサーバ構築して投入できますよ?@HIROCASTERでございませう。 vagrantで開発環境(仮想マシン)を自動構築しようの記事で、仮想マシンにchefやpuppetを自動的に実行させて開発環境を自動で構築する手順を紹介しました。 環境構築を自動化する内容をchefであれば、レシピと呼ばれるものを、puppetであればマニフェストと呼ばれるものを記述しなければなりません。 今回はパッケージ(NTP)を導入して、NTPの設定ファイルを自動的に配備して、サービスを立ち上げるという環境構築の自動化をchef-soloを使って、紹介したいと思います。基本的に他のソフトになっても手順は同じです。参考にしてください。 chefとchef-soloの違いchefはクライアントとサーバの形を取っており、chefを実行するためにはサーバにレシピや付随する数多くのデータがなければ
gitプロジェクトのガイドラインを参考にまとめました。この作法は英語で書くことが前提となっています。 1. コミットメッセージの1行目は短い説明文(50文字以内) モジュールについての修正の場合、モジュール名: ではじめる 説明文は小文字ではじめる 説明文のピリオド(句点)を省く 2. 2行目は空行にする そうすることで、例えばコミットした内容を E-Mail に変更するツールにて、 Subjectに最初の行を使用し、残りの行を本文にすることができる。 3. 本文には意味ある内容を含める 問題点: 修正した問題点について説明する 妥当性: 行った修正について、「なぜその方法がより良いのか」を説明する 代替案: もし、他の修正方法を検討したのなら、それらについて説明する 4. 変更は命令形で表現する まるであなたがコードベースに変更を命令じているかのように書く。 [bad] "This pa
githubで複数アカウントを使い分ける方法を紹介します。gitそのものではなくsshの使い方になってしまいますが。 前置き みなさんgithubは使ってますか? 趣味のオープンソース活動だけでなく、最近はお仕事でgithubを利用する人も多くなってきたことでしょう。 そうなると困るのが情報漏えい対策です。githubではお金を払えばprivateなレポジトリや組織を作ることができ、それらを活用することでNDAの下にあるプロジェクトも安心して取り扱えます。というわけで私もプライベートに使ってるアカウントをそのまま仕事に使おうと考え評価していたのですが、ある問題点が浮上しました。githubから飛んでくる通知 メールです。あれをプライベートと仕事で同じメールアカウントに飛ばしてしまうと、オペミスなど万が一の事故が起こらないとは言えないのです。特に粗忽な私はメールのオペミスしやすいですからね。
「うわっ…私のバージョン管理、ダメ過ぎ…?」を解決するGitの使い方“超”入門:かんばん!~もし女子高生がRedmineでスクラム開発をしたら(5)(1/3 ページ) 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 これまでのお話 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 ひょんなきっかけから電子目安箱(カウンセラー)を開発することになった「ぷりん」と「まいん」の姉妹。第1回の『高校生になって初めてスクラムを始めました~「ストーリー」で何を作るかまとめよう』、第2回の『スプリントと“かんばん”でチームのビートを刻め!! ~ス
こんにちは!元気にiOS開発でテストを書いていますか???まだ書いていない人は、さっさと書きましょうね!!!今回はObjective-Cでテスト書く上でのモックオブジェクトとかのお話です。 OCMockというライブラリ使うのでCocoaPodsはインストールしましょう! 先にOCMockについて少しだけ 実際にOCMock使ってどうこうはちょっと先の話になってしまいますが、簡単にOCMockの説明だけしておきます。 Mulle kybernetiK -- OCMock Objective-Cのモック系のライブラリにはほかにもOCMockitoやExpectaなどがありますが、個人的にはOCMockが好きです。 有名なBDDフレームワークのCedarなんかでも、OCMock使うといいよ〜と言ってるので、そういう意味でもおすすめですね。 で、OCMockは何するの〜という話なのですが
GitHubの特に重要な機能である「Pull Request」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。 GitHubのメンバーが行った講演などでもPull Requestの重要性は何度も言及されてきています(図1)。修正したコードの取り込みを依頼するだけならすぐにでも使えそうなPull Requestですが、記事では次の3つのコツを挙げています。 Pull Requestはなるべく早く起こす Pull Requestは機能についての意見交換をする良いきっかけになる。コードの修正が終わっていなくてもなるべく早くPull Requestをすることで、最後にまとめてフィードバックをするのではなく発展的なコメントができる Pull Requestはブランチからブランチで GitHubでは誰もgithub/githubのForkを持っていない。同じリポジ
Mojito(モヒート)は、Javascriptで記述されたWebアプリケーション用のフレームワークです。米Yahoo!がオープンソースとして公開しました(2012/4/1)。 Javascriptを使う機会が増えてきた昨今、非常に興味深いフレームワークです。MojitoはMVC構造を採用しており、コードのきり分けを明確にしています。また、1つのソースで複数のデバイスへ対応させるなど、挑戦的な試みも行っています。 今回は、Mojitoを使ってHello worldアプリを作成してみます。 OSはLinux系(ここではMac OS X使用)、Node.jsが入っていることを前提とします。インストールには、npmコアマンド(Node.jsのパッケージ管理ツール)を使います。
プレゼンテーションに関するイベントで「人前で発表をするときに気をつけたい8つのことがら」という発表をしてきました。その概要をメモしておきます。 ここで挙げたのはこの8つ。 準備 自己紹介 スライド 時間 話し方 コミュニケーション ツール しめくくり ではそれぞれの中身を。 1. 準備 最悪の事態に備える 行った先で、すべてが期待どおりに動くことはまずないと思ってます。「ネットが繋がると思うな」「自分のPCが使えると思うな」「Mac (Windows) があると思うな」ぐらいでちょうどいい。 現地ではうまくネットに接続できないかもしれないから、ファイルは事前にダウンロードしておく、ウェブサイトの画面はスクリーンショットを撮っておく、デモはローカル環境で動くものを用意する。 接続がうまくいかなかったり急に動かなくなったりで自分が持って行ったパソコンが使えないかもしれないから、スライドのファイ
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Apacheのデバッグの方法は多く紹介されていて、例えばgdbを使ってみましょうと紹介されている記事も多いです。しかし、操作の仕方が多岐に渡っていて、なんとなく敷居が高く感じて使わないという人も多いかもしれません。 例えば、Apache周りのエンジニアが一番気になるのは、Segmentation faultだと思います。そこで、今回は自分がSegmentation faultの原因を特定する時の一番手っ取り早い、gdbを使った方法を紹介しようと思います。gdbを使っていない人にとって、gdbって少し敷居が高いんじゃないかなぁ、と思っている人も多いかもしれませんが、今回の方法であればだれでも気軽にできると思います。 まずはバグを作る 今回は、自
Androidエミュレータの起動は非常に遅いのです。要はARM仮想マシンなので、実行性能が物理CPUに比べると5~10倍くらい遅いのはどうしようもありませんが、起動を速くすることは簡単にできます。 スナップショット機能を使う Android開発でエミュレータの起動の遅さが悩みの種という人も多いのではないかと思います。エミュレータの起動待ちで始めたCityVilleについハマり、起動時間の実質5倍以上の時間を無駄にしたという人も多いんじゃないかなーと思います。 AVDのバージョン9.0以降、仮想マシンのスナップショットの保存と復元がサポートされました。この機能を使うとびっくりするくらい起動が速くなります。 [マシンスペック]
Mac OS XではFrameworkを作成することが出来ます。 そもそもMac OS XにおけるFrameworkとは何かというと、簡単にいえば「ヘッダやリソースなどをひとまとめにし、複数のバージョンを保持することが出来るライブラリ」といったところです。 システム内において複数のアプリケーションが共有して利用できる機能をライブラリ化しておくことで、各アプリケーションがその処理を個別に実装することなく、単にそのライブラリをロードして利用するだけでよくなるというのが大きな利点でしょう。 そのため、iOSのようにシステムに自作ライブラリを追加できないOSではあまり意味が無いように思われるのですが、このFrameworkという仕組みを利用すると、ヘッダファイルやリソースを一気にまとめることが出来るので、結果的にライブラリの管理がしやすくなりますし、Xcodeプロジェクトへのインポートもこのフレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く