サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
HomebrewとAnsibleでMacの開発環境構築を自動化する | mawatari.jp
3月20日に13″ rMBP early 2015が手元に届いたので、以下の様なツイートをしながらPlaybookを作っていました。 GUIアプリも含めて全部Homebrewで管理してみようかな。 — まわたりなおと (@mawatarin) 2015, 3月 20 んー？Brewfileで管理できないのか？ http://t.co/g8eBr2tInk — まわたりなおと (@mawatarin) 2015, 3月 20 うん。Brewfileの代替はこれがよさそうだな。今夜やってみよう。 http://t.co/mxXRd3IGK2 — まわたりなおと (@mawatarin) 2015, 3月 20 例のごとく、そのとき取り組んだことを整理した上で公開しようとしていたわけですが、その日の夕方、@t_wadaさんによって、Mac の開発環境構築を自動化する (2015 年初旬編)という
EmacsでAPIをたたく。restclient.el - @peccul is peccu
restclient.elというものがありまして、 テキストファイルにAPI呼び出しを列挙しておくと、C-c C-cなどで実行できます。 github.com JSONかXMLならレスポンスをpretty-printしてくれます。 postリクエストの例。バッファにこんな風に書きます。(GitHubの例より) POST https://jira.atlassian.com/rest/api/2/search Content-Type: application/json { "jql": "project = HSP", "startAt": 0, "maxResults": 15, "fields": [ "summary", "status", "assignee" ] } POST https://... の部分でC-c C-cすると別のウィンドウにレスポンスが表示されます。 このテキ
自宅サーバーをRaspberry Pi 2 にした
古いタワー型PCで動いていた自宅サーバーを Raspberry Pi 2 に置き換えました。 GPIOを使ってどうこうとかそういう面白そうなことはやってません。 Raspberry Pi 2 を単なる省電力小型Linuxマシンとして使っているだけです。 このエントリは通常のタワー型PCサーバーではやることが無かった類の作業の記録です。 自宅サーバーなんてイマドキ外部のサービスに頼れば殆ど不要なのですが、データ量がTB単位になるような深い業を背負った人間のファイルサーバーはちょっと困ります。そこに一ヶ月の電気代が50円未満なんて言われる小型PCがあれば惹かれていくのは人の性というものです。 用途 NASが主な用途です。sambaです。 HDDは2台接続して、それぞれメインとバックアップにします。 RAIDではありません。個人用途では常時クローンされることよりも誤操作時の復元容易性の方を重視し
iOS アプリの継続ビルドを CircleCI に変更した
今まで Travis CI で設定していた iOS アプリのビルドを CircleCI に変更しました。 ngs/onairlog-ios on CircleCI ngs/onairlog-ios on GitHub 現在、iOS ビルドの機能は Experimental Settings として提供されています。 https://circleci.com/mobile TOC 前準備 依存ライブラリのインストール 鍵と証明書の読み込み プロビジョニングファイルのダウンロード 環境変数のエクスポート テスト実行 デプロイ AdHoc ビルド DeployGate へデプロイ Release ビルド作成 iTunes Connect へデプロイ (WIP) その他 Xcode 6.2 所感 TODOs 参考にしたページ 環境変数 件のアプリのソースコードは、GitHub 上の公開リポジトリで
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
