dockerで一人から始める社内用ナレッジを作ってみたら周りが捗りまくった話 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Qiitaを開発するIncrements株式会社、 全従業員を対象にリモートワークを導入 - Qiita株式会社
Qiitaを開発するIncrements株式会社、 全従業員を対象にリモートワークを導入Increments株式会社(本社:東京都港区、代表取締役:海野 弘成)は、リモートワーク制度を導入しましたので、お知らせします。 弊社は、「Qiita」「Qiita:Team」「Kobito」などプログラマ向けのWEBサービスを開発する会社であり「ソフトウェア開発をよくすることで、世界の進化を加速させる」をビジョンに掲げています。そして、良いソフトウェア開発のためには、従業員一人ひとりが最大限のパフォーマンスを発揮できる環境が重要と考え、リモートワークを導入しました。 今後も従業員の働きやすい環境づくりのため、会社として様々なサポートをして参ります。また、リモートワークで得られた知見を多くの方に共有するため、勉強会や講演を行う予定です。 Incrementsのリモートワークの特徴 オフィス、自宅、コワ
SpringでAOP - Qiita
Seasar2でAOPは散々使ってきたが、Springではまだ使ったことなかったので、どんな感じになるのか簡易なコマンドラインアプリケーションで試してみた。今更感があるのでAOPとは？の説明はここでは省略。Spring AOPはXMLで設定を記述する方法もあるが、今回はアノテーションベース + Spring Bootで試してみた。 用語の整理 とはいえまず最初に用語の整理をしてみる。正直AOPでよく聞く用語は公式を直訳すると結構分かりづらく、あまり直観的ではないので語弊を恐れず簡潔に定義したい。 Aspect(アスペクト) 複数のクラスにまたがる関心事をモジュール化したもの(まとめたもの)。 JoinPoint(ジョインポイント) Advice(下記参照)を挿入する場所。場所といってもソースの特定の位置というわけではなく、メソッド(やコンストラクタ)の実行前、メソッド(やコンストラクタ)の
Parse.com 終了に伴う mbaas サービスの移行方法（終了直前の大幅更新！） - Qiita
（2016/12/21 時点の情報で大幅更新しました！） とうとう、Parse.com の終了まであと１ヶ月となりました。アナウンス時点から状況が色々変わっているので、現時点の情報で更新しました。 （特に、Facebook のグループ Parse.com Developers Japan の投稿を参考にさせていただきました。ありがとうございました。） Parse.com の終了 2016年1月29日（日本時間）、Parse.com のサービス終了のアナウンスがありました。それから１年後の 2017年1月28日（恐らくアメリカ東部時間）にサービスが終了します。 2017年1月28日にサービス終了。 Parse Server や SDK などをオープンソースとしてGitHub で公開。 移行方法をMigration Guide で提示。 移行するには、大きく４つの手段あります。 他の mbaa
Maven3で環境ごとのresourceを差分で管理する方法 - Qiita
Mavenでリソースファイルを環境毎に管理したい場合はよくあります。 以下はぐぐるとよく出てくる方法で、環境毎にプロファイルでresourceを定義するものです。 <profiles> <profile> <id>ローカル開発環境 <build> <resources> <resource> <directory>src/ローカル開発環境/resources </resource> </resources> </build> </profile> <profile> <id>本番環境 <build> <resources> <resource> <directory>src/本番環境/resources </resource> </resources> </build> </profile> </profiles> これでも環境毎にリソースを管理できますが、一方のリソースファイル配下のファ
Emacsで.logファイル監視(tail -f) - Qiita
これはなに？ タイトルの通りです。Emacsで.logファイルを監視することができるようになる設定です。 .logファイル開いたとき、自動的にtail -f相当の以下のような動きをするようになります。 ファイル更新に追随して自動的にバッファを更新 バッファ更新時とファイルを開いた時、自動的にバッファの末尾へカーソルを移動 設定 ~/.emacs.e/init.elの末尾に追記するか、init-loaderを利用している場合は21-auto-revert-tail-log.elといったelispファイルを作成して下記を記載します。 ;; .logファイルでは自動で auto-revert-tail-mode にする (add-to-list 'auto-mode-alist '("\\.log\\'" . auto-revert-tail-mode)) ;; ファイル更新やバッファオープン時
bashに自作のホスト名補完機能を追加してsshを楽にする - Qiita
はじめに bash-completionをインストールすることで、sshやpingなどのコマンドで、タブキーによるホスト名補完が可能になります。 これを『自作のホスト名補完に 置き換える』例は様々ありますが、『自作のホスト名補完を 追加する 』手順の例がなかなか見つからないので、私の実装例をTipsとしてまとめました。 以下は、bash-completionのversion 1.3を検証環境として記載しています。 また、私自身bash-completion設定を初めて書いたので、お作法を無視しているかもしれません。ご承知ください。 (2016/01/19追記) 本手順に従うと、補完機能はシステム共通設定として設定されます。個人設定を作成する際には別の手順を参照してください。 bash-completion導入方法 以下が参考になります。 ぶっちゃけ、yum install bash-com
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
はじめに 英語力をあげるために、コミットメッセージを英語で書こうとしても実践するのはなかなか難しいものです。 GitHubで使われている実用英語コメント集 - Qiita のような記事を読んでもコミットするときには忘れています。 そこで、git commit時に表示されるコメントに、英語でメッセージを書くためのヒントを表示してみました。 完成イメージ やり方 ~/.gitmessage.txt を作成 # fix, add, changeといった事実ではなく、このcommitで実現する要件や仕様を書きましょう。（リファクタなどは除く） # # 例文） # - Fix typo in docs # - Remove unused code # - Remove use of deprecated method # - Update Modernizr to v1.6 # - Make it
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
DigitalOceanの便利ツール作りました - Qiita
はじめに DigitalOceanの管理ツール(dioc)を作成したので、ご紹介します。(利用については自己責任でお願いします。) 操作は、Ubuntu上で、DockerとPython3.5を用います。Windowsの方は、Ubuntuを入れてDockerを使う方法を参考に、VirtualBox、Ubuntu14、Docker1をインストールしてください。 Dockerが使えれば、Dockerイメージdioc-python-3.5を用いてすぐに始められます。 用語 DigitalOcean： AWSのEC2のようなクラウドサービス。 Droplet： 仮想OSのインスタンス。 Snapshot： Dropletの状態を保存したもの。Snapshotを元にDropletを作成できます。 Image： Dropletの元になるもの。公式のものと、Snapshotで作成した私的なものから選べます
crontabで特定年月日に実行させようとして失敗 - Qiita
経緯 crontabで特定の日時に一回だけ実行したいと思うことはあると思う。普通なら 11 7 24 12 * /usr/local/bin/hoge みたいに書く訳だけれども、毎年その日が変わる場合なんかだと、フェールセーフとして、曜日を入れたくなる1。 今回は、月～金の休日明けに何か2処理を実行させたかった。 crontabの設定 ということで、2015/123に以下のような設定を追加。 05 04 24 12 thu /usr/local/bin/hoge 05 04 04 01 mon /usr/local/bin/hoge 05 04 12 01 tue /usr/local/bin/hoge 05 04 12 02 fri /usr/local/bin/hoge 05 04 22 03 tue /usr/local/bin/hoge 05 04 02 05 mon /usr/l
Emacs で M-x すらままならなくなった場合の対処 - Qiita
でもできれば強制終了してくないですよね？ M-x package-install して マイナーモードを on/off したり ごちゃごちゃイジっていると たまに抜き差しならない状況に陥ります 多分 advice が変な状態になって ミニバッファで Enter 押せないとか。 でも、できれば kill -9 とか、プロセスの強制終了はしたくないですよね？ auto-save-buffers とか使っている人は、 あんまり気にしないかもしれないですけど。 とりあえず無難に終了させたい!! 端末から
個人のスマホアプリ開発者がParseを使うべき15の理由 - Qiita
注意(2016/01/29追記) Parseサービスの終了が発表されました。 利用できるのは2017/01/28までだということです。 Facebook Shutters Its Parse Developer Platform | TechCrunch http://techcrunch.com/2016/01/28/facebook-shutters-its-parse-developer-platform/ Moving On http://blog.parse.com/announcements/moving-on/ こんなに便利なサービスが終了してしまうのは残念でなりません。。 (一応ParseサーバーとMongoDBのマイグレーションツールが公開されるということなので 自前サーバーで管理すればParseと同じようなものを動作させることは可能かもしれません。) 背景 最近個人で掲
GitLab on docker のバージョンアップをしてみた - Qiita
先日slackにて、こんな会話がありました。 先輩：「GitLabのバージョン上げたいけど、設定が面倒くさいな～」 自分：「それdockerなら簡単にできますよ」 先輩：「お～、それじゃあお願いしていいかな？」 自分：「はい、よろこんで！」 というわけで、今回は7.12.2から8.3.0へのバージョンアップになります。 ただ、新規にGitLab on dockerを行う場合も、この方法で作成できます。 環境 ホストのCentOSにVirtualBoxでUbuntuを作成し、その中にdockerを入れています。 HostOS: CentOS release 6.5 GuestOS: Ubuntu 14.04 LTS docker version: 1.9.1 GitLabバージョンアップの注意点 7.12.2のバックアップデータを直接8.3.0でリストアしようとしても、互換性の問題があるため
MySQLに割り当てるバッファサイズの計算方法 - Qiita
概要 このへんの本を読んで復習がてらに書いてく 計算式 (物理RAMの合計) ― {max_connections x (スレッドバッファによる消費) + グローバルバッファによる消費} > 0 グローバルバッファ + スレッドバッファで消費されるであろうメモリサイズが物理メモリサイズを超えないようにする 物理RAM：r3.2xlargeで61GB グローバルバッファ(サーバ全体に設定されるオプション) すべての接続とクエリに影響する mysqldが獲得できるRAMの量を計算し、バッファサイズの合計がこれを超えないようにする オプション query_cache_size innodb_additional_mem_pool_size innodb_buffer_pool_size innodb_log_buffer_size key_buffer_size 消費メモリ計算式(GB表示) S
Gradle のプラグインの作り方メモ - Qiita
ビルドスクリプトに直接定義する方法もあるそうだけど、今回はスタンドアロンで動かせるやつを勉強する。 スタンドアロンのプラグインを作る 実装する |-build.gradle `-src/main/ |-groovy/ | `-sample/gradle/plugin/ | `-MyGradlePlugin.groovy `-resources/ `-META-INF/gradle-plugins/ `-com.github.opengl-8080.hello.properties プラグインは、最終的に Java バイトコードになるなら言語は問わない（Java, Groovy, Scala など）。 ただ、 Java 8 の API とか使うと実行環境によってはエラーになるかもしれないから、あんまり最新の API は使わないようにしたほうがいいのかもしれない。 今回は Groovy で書く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MyBatis 使い方メモ - Qiita
Vagrant1.8で追加されたSnapshot機能のまとめ - Qiita
ライブラリを探す方法 メモ - Qiita
Javaの "? extends" や "? super" の使い方をC#やScala風に考える - Qiita
