などにすごく時間がかかる、ということがあります。 いろいろ調べて、ある程度は改善できたので、メモ。 preloadindex 設定 こちらを元に

Goodbye... Jenkins... Jenkinsを卒業してお手軽CI! iOSもAndroidもCircle CIでアプリのCIを回そうiPhoneAndroidXcodeiOSSwift by @mixiappwchr アプリ開発において、重要なのだけれども面倒なものの一つとしてCI環境の整備があります。 サーバーサイドについては、すでにtravis CI,Circle CI,wreckerなどのクラウドのCIサービスを用いて継続的にインテクグレッてると思いますが、アプリに関しては各サービスがアプリのCIに対応してなかったりするため、未だに、ローカルにmac miniなどおいてJenkinsさんとお付き合いしてる人も多いでしょう。 しかし、やはりローカルのJenkinsを使う場合だと サーバーサイドのCIはクラウドで済ませてるのに、これだけローカルだとリモートからのメンテが面倒

ここ最近、沢山シェルスクリプトを書くようになりました。 元々あまりシェルスクリプトを書いたこと無かったので、色々と勉強しつつ書いてるのですが、 他のプログラミング言語とはちょっと違って独特なクセというか、発見の度におぉー！ってなることが沢山あって楽しいです。 そんなわけで、最近学んだり参考にした中で特に感動したシェルの上手い書き方をまとめてみます。 きっとまだ知らないこととかもっと上手くやる方法なんかが沢山見つかりそうなので、 もっといいやり方あるよ！って方はコメントください 何もしない : (コロン)コマンド シェルを書いていた時に非常に欲しかったコマンドがこれ！何もしない！ : というコマンド(？)を利用すると、**何もせずに終了ステータス0(つまり正常終了)**を返します。 これが様々な事に使える万能コマンドで、これによって面倒なエラー処理を簡潔にできたり、 入力や出力のリダイレクト

シーン 1 Yamaha ルータのログを採取した時、1行のログが長い場合には途中（80バイト）で改行文字が勝手に挿入されてしまいます。 2013/03/22 18:21:27: Power-on boot 2013/03/22 18:21:27: RTX1200 Rev.10.01.38 (Mon Jan 23 07:14:38 2012) starts 2013/03/22 18:21:27: main: RTX1200 ver=c0 serial=D261xxxxx MAC-Address=00:a0:d e:xx:xx:xx MAC-Address=00:a0:de:xx:xx:xx MAC-Address=00:a0:de:xx:xx:xx 2013/03/22 18:21:34: LAN2: link up (1000BASE-T Full Duplex) 2013/03/22

まだTestFlight使ってたの？急げ！終了目前のTestFlightから,今すぐにiOSもDeployGateに移行しよう！移行パターンも紹介するよ。iPhoneAndroidXcodeiOS by @mixiappwchr 旧TestFlightがいよいよ2/26に終了のお知らせです。買収されて以来この日が来ることは目に見えておりましたが、買収先のApple版TestFlightにそのまま移行か？というとそうでもありません。 Apple版TestFlightでの問題 iOS8 のデバイスonly これは結構でかい問題です。まだまだiOS7くらいからのサポートは多いはずです。 iTunesConnectの使い勝手が悪い。 TestFlight以外の使い勝手も元から悪いですが、設定方法がいまいちわかりづらい。。。 内部テスターの場合iTunes Connectでの権限管理がちと怖い 内部

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Javaの開発と言っても、各種ミドルウェアやフレームワーク、ライブラリ、ツールなどが豊富にあり選択に悩むことは少なくないと思います。 そこで関連技術のインデックスになればと作成しました。 あくまで知っている範囲で記述しているので、コメントしてもらえれば随時追加します！ すべてを書くと膨大な量になるため、現状採用が減ってきているものや、そもそもあまり採用されていないもの、後継があったり、類似のものと比較した場合に明らかに劣っているものは省いています。 ちなみにライブラリには高機能なものも多いので、分類は参考程度にご覧下さい。 サーバ系 A

どうもシリアルパッケージクリエイター見習いです。 呪文のようなカラーコード（#000000, #FFFFFFの違いすら曖昧）を覚えることができないので、ファイルを見返してカラーコードを確認することがあります。しかし、そんなこともいちいちやっていると面倒なので、簡単にファイル中のカラーコードを把握したい、というもの。 color_picker: そんな関数 より正確にカラーコードを取得するよう、なおかつコードの可読性を高めるために@hoxo_mさんがコメントしてくれました。感謝。 # 関数の定義 color_picker <- function(file, show = TRUE, ...) { col <- readLines(file, warn = FALSE) %>% stringr::str_match_all("[\"\'](#[0-9a-fA-F]{6})[\"\']") %>

【2015/07/16 追記】優れた dotfiles を設計する - TELLME.TOKYO この記事では書かなかった全体のロジックについて書きました Dotfiles Driven Development dotfiles とは Unix 系 OS で俗に言う設定ファイルのことです。.vimrc や .zshrc など、設定ファイルの多くは隠しファイルとしてファイル名の頭にドットがつくことからそう呼ばれています。 ほとんどのエンジニアは CLI 環境での開発は避けては通れないものに思います。CLI 環境は「黒い画面」として敬遠されがちで、CLI になると格段に作業効率がダウンする人も少なく無いです。その作業を効率化するキーとなるのは、設定ファイルの習熟度にあると思います。GUI 開発環境と比べてこちらはテキストベースでカスタマイズできるため、究極まで自分好みに合わせることが可能です。

この記事では、Android開発を始める方や、初めたての方向けにどのようなサイトを見たり、本を読んだらいいかをレベル別や用途別で解説します。 本の紹介などはすでに多く存在しますが、使いどころというのは本によって大きく違います。この記事ではその使いどころに意識してソースを紹介できればと思います。 また、Androidプログラミング初心者とプログラミング初心者は区別しません（合わせて"プログラミング初心者"と記述）。Androidのアプリ開発はベースとなっているJava言語が直感的に理解しやすいこともあり、他のプログラミング言語を習得していなくてもある一定のレベルまでは上達します。本当にAndroidアプリ開発に興味を持ってきた段階でJava言語の勉強を本格的に行うようにし、まずはAndroidをアプリを作成するというところにフォーカスしてやっていきましょう。 Androidプログラミングを始

概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後

何も考えずに書き始めたけど10の方法って書いちゃった。 いくつになるかはわかりません。 一般的なプロジェクト運用でもある程度同じ方法論でイケると思います。 なお、筆者であるvvakameはDefinitelyTypedのメンテナをしています。 そのため、これから先の文章について、TypeScriptやJavaScript関係固有の事象が含まれていると思います。 書かれている内容について、contributeする側、される側、両側へのアドバイスを書きます。 ちなみに、わかめ的にはTOMOYO Linuxに学ぶ説得術とかはすごい参考になりました。 こまけぇことはいいんだよ！まずはやろう！ 貴方が世界に存在するためにはまず誰かに存在を知ってもらわなければいけません。 pull requestを出そう！無理だったらIssueを書こう！ まずはそこからだ！！ pull requestのmergeを拒

Docker Advent Calendar 2014 12/25 の記事、本気で使う Docker です。 ということで、実際に弊社で Docker を使った運用を開始した際にはまったところや、悩んだ所、どういう風に使っているのかについてぱらぱらっと書こうと思います。 "本気" なぜ Docker を使うのか、というと、僕の中では以下のような理由があります。 すべてのアプリケーションを(インフラ的に)同じ方法でデプロイ、管理したい 特定のサーバー / インスタンスの状況に依存することなく、アプリケーションの依存とインフラ都合の依存を別管理したい Docker なんかかっこいいっぽいし使ってみたい 上記のような都合から、どうやって作っていくかを考えていきます。基本的には1番目と2番目の理由が重要です。 Docker コンテナのいいところ とある Rails アプリケーションをデプロイするた

お疲れさまです、trebyです。 もうだいぶ日付が変わりそうな勢いですが、Git Advent Calendar 2014の23日目を担当させていただきます。 Gitを業務で使い始めて早2年、だいぶ慣れてきた感じがありますが、それをアウトプットする機会があるかといえばなかなかありません。せいぜいたまに同僚に聞かれるくらいでなんかもったいない感じがあります。 そこで今日は私個人がgitを使って仕事をする上でどういうフローしているかなーということを改めて文字にアウトプットしてみたいと思います。ご参考にしていただくなり、ツッコミしていただくなりしていただけますと幸いです。 なお、本投稿において想定するツールはGit、ホスティングサービスはGitHubですが、多分その他のサービスでもいけるのではないかと思います。 開発準備 「新しくチームに配属された！」等のシチュエーションを想定しています。 開発

とやればOK。 Ubuntu14.04およびUbuntu14.10の場合 ・・・のはずだったのですが、自分の環境（Ubuntu14.04及びUbuntu14.10）では下記のようなエラーが出てビルドに失敗しました。 % rbenv install 2.2.0 Downloading ruby-2.2.0.tar.gz... -> http://dqw8nmjcqpjn7.cloudfront.net/7671e394abfb5d262fbcd3b27a71bf78737c7e9347fa21c39e58b0bb9c4840fc Installing ruby-2.2.0... BUILD FAILED (Ubuntu 14.04 using ruby-build 20140524-150-gbe7d096) Inspect or clean up the working tree at /

この記事はSwift Advent Calendar 12月23日の記事です。 アドベントカレンダーは後半ほどネタが出尽くすので不利ですね。 自分はこの2ヶ月半ほどプライベートの時間を使ってSwiftで新しくアプリを作っていたので、それについて考えていたこと、感じたことをつらつらと書き下してみたいと思います。 [2014/12/28 追記] 今朝、アプリがリリースされました！！ Rebuilt きっかけ 2014/6/3にWWDCでSwiftが発表され非常に気になっていました。 しかし、当時の自分は業務でアプリ開発から離れており、他に優先順位の高い事柄があったので積極的に勉強することを避けていました。 Xcodeベータは安定していない、Swiftの仕様もコロコロ変わる中、学習効率を重視するのであれば安定版がリリースされてから勉強したほうが良いとも思いました。 新しい技術が出てくるタイミング

概要 AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。 しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。 今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。 比較の軸 以下のように、評価軸を設けました。 サービスの機構として提供されているものは◯とします。 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など) 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。 デプロイ自動化 まずはアプリケーションのデプロイを自動化するサービスの比較を行います。 以下の4つの選択肢があります

この記事はSwift-2 Advent Calendar 2014の23日目。Swift本を紹介しようと思ったら他にも色々書いてしまった。 Swiftで関数型プログラミング 原題Functional Programming in Swift。ベストプラクティスを追い求めてるobjc.ioの人たちが書いた本。ebooks版（PDF, ePub）が安く、なんとダウンロードしたサンプルコードがPlaygroundsで実行できる。 きっかけはQuickというOSSの開発者から薦めてもらった @yimajo enumとswitchはSwiftの割といいところだと思う！でも自分もFunctional Programming for Swiftを読むまでは知らなかった and 理解できていなかった — Brian Gesiak（もどかしい） (@modocache) 2014, 11月 18 サンプル版

ちょっと趣向を変えてJavaScriptの情報をどうやって集めているかという話を書きたいと思います。 使っているもの Twitter RSS(feedly) Pocket はてブ TwitterはただフォローしてTL見ていたり検索してたまに見ているだけでリストを作ったりはしてなくて暇な時に見ている感じです。 RSSはこれから紹介するようなサイトとかこの人のブログ面白い！というものだけを登録しています。未読が100件増えると消化する気がどんどんなくなっていくので...。 PocketはTwitter、RSSで気になったものを後で読むためにとりあえず突っ込むのに使っています。 こうすることでRSSはすぐに終わるので、その後で時間があればPocketで読みます。 Pocketに溜まった記事はちょっとした合間に読んだりしていて、たまにまとめて読んだりして消化しています。 今見ると20件くらいあるの

2014年終盤、もしかしたら皆さんはObjective-Cなんて使わずにSwiftでアプリ開発をしているかもしれませんが、自分が利用しているコーディング時のガイドになるスタイルガイドを公開したいと思います。 新しくプロジェクトが始まった際など何かしらの議論のベースとなれば幸いです。 前提 あくまでスタイルガイドであってルールじゃない もしガイド通りでなくてもレビュー時に指摘するほどではない 複数ある方法を選ぶ際の参考にすればいい MUSTな項目はなくレビュー時に気づいたら気づいた誰かが直せばいい 項目それぞれに理由があるが、その理由が当てはまらなければ当然他の方法が適している 開発メンバーによってそれぞれ合う合わないがあるのは当然 プロジェクトによってガイドの内容は調整されてもいい スタイルガイドは言語仕様や開発環境の気付きになる場合が多く、それも目的としている Blocksを引数にとるメ