iOSアプリ個人開発で使ってるツールとかノウハウを公開してみる - Qiita
開発言語 開発当初はObjective-Cで書いていましたが、やはりSwiftの方がStruct/EnumなどSwiftyに書けるのが便利で、徐々にSwiftへ移行しています。 Swift / Objective-C（古い機能はObjective-Cで書いてあるので移行中） HTML/CSS（アプリサポート用サイトのコーディング） Python（画像のリサイズなどで自動化スクリプトをつくるとき） Ruby（fastlaneのアクション作成） Bash（Info.plistの設定変更やxcodebuildの自動化バッチをつくるとき） 利用しているWebサービス 定番のサイトも多いですが、カテゴリ分けして整理してみました。 リファレンス系 以下に書いてあるサイト以外にも個人の技術ブログなどにもとてもお世話になっています。 Qiita（情報収集/アウトプット） Developers.IO（情報収
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
業務アプリケーションにおけるモダンWeb開発の現状ーHTML5開発って簡単なの？
CSS Nite in OSAKA, Vol. 36（2013/9/10）、CSS Nite in Ginza, Vol.71（2013/9/19）にて開催された「次世代のWebデザインへの2つのヒント」のスライド。両セッションのスライドをマージしてまとめています。 スライドの末尾で紹介していますが、2013/11/7に拙著『マルチデバイス時代のWebデザインガイドブック』が発売となりました。興味ある方は書店にて手に取ってみてください。 サポートサイト : http://2843.jp/books/nabebon/ Facebookページ : http://facebook.com/nabebon/ Amazon : http://www.amazon.co.jp/dp/4883378942/
Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
『チーム開発実践入門』という本を書きました - ikeike443のブログ
2年くらい前に技術評論社さんから「チーム開発に役立つツールや方法論をまとめた本を書かないか」とお声がけいただきました。 それから構想1年（ぼんやりしてた）、執筆に1年かけて（週末がなくなった）、ようやく4月16日に発売できそうなところまで来ました。 今印刷所でゴインゴイン刷っていると思います。 技術評論社さんのページを見てもらうと、表紙画像もアップされてますね。 http://gihyo.jp/book/2014/978-4-7741-6428-1 Amazonさんにもページができていますが、まだ表画像はアップされてません。 チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus) 作者: 池田尚史,藤倉和明,井上史彰出版社/メーカー: 技術評論社発売日: 2014/04/16メディア: 単行本（ソフトカバー）この商品を含むブログを見る 目次もま
【書評】なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術 - GoTheDistance
日本実業出版社の今野様より献本御礼。 なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術 作者: 細川義洋出版社/メーカー: 日本実業出版社発売日: 2013/09/27メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る 東京地方裁判所でIT事件担当の調停委員を努めておられる細川氏が、ご自身の経験をまとめてシステム開発のモメるポイントを整理し「人の振り見て我が振り直せ」を啓蒙する位置づけの図書になっております。 こう書いてしまうと非常に堅苦しいですが、モメるポイントをわかりやすく伝えるために「IT事例に詳しい美人弁護士に相談する」というカジュアルな設定になっています。塔子さんがその弁護士役で、厳しい指摘がコンビネーションブローのように続いており、爽快感がありました。 一部、本書の会話内容をご紹介します 彩音 「もう設計も終わる時期なのに、ま
超高速開発 体験談 - 職業プログラマの休日出勤
数日前に日本で話題になっていた「超高速開発」について記事を残したいと思います。ニュース記事 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 － Publickey の はてなブックマーク に寄せられたコメントを見る限り「食わず嫌い」な方が非常に多いように見受けられたので、これは体験談の需要は高そうだなと思い、書き始めた次第です。 ネタ記事を書いた直後に真面目な記事を書くのは、少し気が引けるものではありますが…。 私は2006年初頭から2012年初頭まで、インフォテリア社製の開発ツール「Asteria」を使用していました。この製品には冒頭で紹介した記事からもリンクが張られていますが、超高速開発を実現するためのツールの一つです。もちろん、私がAsteriaを使用していた頃は「超高速開発」などという言葉は見たことも聞
「超高速開発コミュニティ」は何を目指すのか - ジャスミンソフト日記
超高速開発ツール（または手法）の普及活動を行う「超高速開発コミュニティ」がいよいよ立ち上がりました。 http://www.x-rad.jp/ 記者会見の様子がさまざまなメディアに掲載されています。記事には触れられていませんが会場では記者との間に活発な議論があり、大いに盛り上がりました。厳しい質問を経て、次のような記事でまとめられています。記者の皆様、ありがとうございました。 「超高速開発コミュニティ」を設立――日本が19位で黙っているわけにはいかない http://www.atmarkit.co.jp/ait/articles/1308/06/news121.html 開発ツールベンダー13社が集結し、「超高速開発コミュニティ」を設立 http://itpro.nikkeibp.co.jp/article/NEWS/20130806/496983/ 業務システムの開発ツール・ベンダー13
テストコードがないコードだけが技術的負債じゃないよ - methaneのブログ
私は「レガシーコード改善ガイド」を読んだことがないのですが、世間的に「テストコードがないコードが技術的負債」という認識が広まっているようです。 レガシーコード改善ガイドを批判するつもりは全くありませんが、たんにその本の中で使われている「レガシーコード」の定義に一致する物だけが技術的負債だという考えには反対します。 技術的負債とは、将来必要とされるメンテナンスコストの期待値だと思います。全てのコードは、メンテナンスを放棄するまでは技術的負債です。一方、メンテナンスコストを差し引いた上でそのコードが将来生み出す利益の期待値が、そのコードの資産価値だと思います。テストコードがないコードでも、利益を出すなら正の資産になります。 もちろん、資産価値をより大きくするために、技術的負債を減らすことは良いことです。技術的負債を下げる＝メンテナンスコストを下げることで、テストはその有力な手段の一つです。他に
JavaでさくさくWebアプリ開発 - しんさんの出張所 はてなブログ編
かなり久々の技術エントリ。 運用はお堅い重いサーバーを使ったとしても開発は軽いほうがいい。当たり前ですね。 というわけでさくさく開発する方法を書いてみる。DIコンテナはCDIやGuice、Springなど好きなものでよいが、今回は省く。軽いこともあって開発中はGuiceを使うことをお勧めしたい。注入は@Injectを使うため、開発中と運用中でコードが変わるってのは少ないはずだ。 まずはJAX-RS まず、アクションベースのWebアプリはJAX-RSを使うこと。これが基本。サーブレットAPIを使わずに開発することについては今までも書いてきた。サーブレットAPIを触らないことにより開発効率とテストのしやすさを両立できる。 こんな感じ。 @Path("/") public class Hoge { @GET @Path("add/{a}/{b}") public Response add(@Pa
Android開発の落とし穴 - FLYING
昨日のエントリーに引き続き，バッドノウハウ的なものを箇条書きでまとめておく。思い付いた順に追加していく予定。 Activity関連 永続化はonPauseで行う*1。詳しくはActivityのライフサイクル図を参照のこと。 onPauseと対になっている処理は，onResumeで行うこと。onStart/onStopはあんまり使わない，気がする。 DialogはAlertDialog.Builderを使って実装するのが楽。ただし，裏で何らかの処理を行なっている間，ユーザーに操作をさせないために表示するダイアログ（いわゆるProgressDialog）は使わないようにする。DialogではなくActivityを新しく作って表示させることで，いくつかのトラブルを回避できる*2 *3。 重いタスクはUIスレッドで処理しない。AsyncTaskなどを使ってワーカースレッドで実行する。ただし，ワーカ
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
愛せないコードを書くには人生はあまりにも短い
愛せないコードを書くには人生はあまりにも短い Dec 16, 2012 @ DevLOVE 2012 Read less
【営業さん必見！】iOS/Androidアプリ開発で事前に合意しておくべき7つのポイント | DevelopersIO
※1.X系は開発対象になることがほとんどないため、表から除外しています。 3.ネットワーク オフライン、3G、wi-fi、LTEとスマートフォンではネットワークの種類がいくつかあります。何もここまでと思う方もいらっしゃると思いますが、3Gとwi-fiで動きが異なるということも実際あったので、開発対象のアプリがどのネットワークを対象としているのかは明確にしておく必要があります。 4．テスト範囲 端末とOSのバージョンを組み合わせただけで相当数のパターンができます。全ての端末、全てのOSのバージョン、全てのネットワークの組み合わせでのテストは現実的には不可能ですので、開発でのテストの範囲を決めておきましょう。またテスト範囲には、弊社諏訪が書いた記事「Androidの結合テスト」で書いていましたが、どこまでテストを深くやるのかも決めておくべきです。 5．リリース 開発までで終わりなのか？ストアの
変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報共有から始めるチーム開発とキャリア戦略
設計から実装まで、今すぐ始める高速化
ふつうの受託開発チームのつくりかた
