やりたいこと Docker ホスト (Linux サーバ) の上で X11 アプリケーションのコンテナを動かす 手元のノート PC (MacBook) から Docker ホストに接続して、コンテナとして動いている X11 アプリケーションのウィンドウを手元のノート PC のディスプレイに表示する 「なんでそんなことやってんだ」と思うかもしれないが、やりたくなったもんはしょうがない。 Docker ホストに X11 Forwarding しながら SSH 接続する このあたりはググればいくらでも情報が出てくるのでサラッと。 Docker ホスト側の sshd_config で X11Forwarding yes を設定する Docker ホストに SSH 接続する際に -X オプションを付けるなどして X11 Forwarding を有効にする X11 アプリケーションの Docker イ

状況 消失したリポジトリを復元し、新しいホスティング先へ git-push したい。 Git リポジトリが消失し、ローカルにはソースファイルすらない 残っているファイルは Capistrano のデプロイ先にあるもののみ 本番環境の接続設定が ssh config の Host my-app で用意されている Capistrano を使って my-app の /path/to/app ディレクトリへデプロイされている 本番環境の様子 my-app の /path/to/app が Capistrano でデプロイする環境であることを確認する [ec2-user@my-app ~]$ ls -l /path/to/app total 24 lrwxrwxrwx 1 ec2-user ec2-user 50 Feb 1 2017 current -> /path/to/app/releases

最近、AWS の CLI を使う Bash スクリプトを書いていると、何かと jq(1) コマンドで JSON をイジりまわすことが多くなってきたので、jq(1) による JSON 操作 with Bash スクリプトのまとめ。 Bash でやらずに Python あたりででも書けばいいじゃないかって？ そりゃそうなんですが、CLI の aws コマンドだと色々なことをアドホックに試すのが楽だし、その延長として Bash スクリプトを書き始めたら何やら大きなスクリプトになってきてしまって複雑なデータ構造を処理するのが大変になってきた、ってよくあるじゃないですか（私にゃよくある）。そんな時、ブロック指向の構造化テキストフォーマットである JSON であれば、基本的に文字列しか格納できない Bash の変数内へデータをシリアライズして格納することで、構造化データを保持できるので助かるわけです。

https://megurorb.connpass.com/event/55107/ Meguro.rb #2 でのLT資料です。 だれこれ Pocke Actcat inc. / Engineer Twitter: @p_ck_ GitHub: @pocke 本題: Ruby はむずかしい お前は自分で書いた Ruby コードの構造を理解しているのか？ 例題1) 何を出力するでしょうか

Git v2.13.0（2017/05/10リリース）でgit configにConditional includes（条件付きインクルード）という機能が実装され、特定のリポジトリに対して一括でgit configを適用できるようになりました。 会社用と個人用でプロファイルを使い分けたり、たまに使う設定をまとめて適用する場合などに役立ちそうです。 設定方法 includeIfセクションを使います。git configコマンドか、~/.gitconfigを直接編集して追記します。

Macのデイスク容量がカツカツのまま運用しておりついに/Libray 以下の整理まで手をつけだした時に /Library/Caches/Homebrew にインストールパッケージのアーカイブやらで数GB消費していることに気付いた。 これらは再ダウンロードできるものなので消して問題なさそう。

タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ

[Android]SupportLibrary v23から追加されたPreferenceFragmentCompatを使ってみるAndroidSupportLibraryPreferenceFragment SupportLibrary v23でPreferenceFragmentが追加された 最近のGoogleのSupportLibraryへの対応はとても親切で、今まで、API 11未満では使えなかったPreferenceFragmentがとうとう！SupportLibraryで対応されました！ 今まではこんなもので代用していましたよね。お世話になりました。 https://github.com/Machinarius/PreferenceFragment-Compat と言っても今更API 11未満に対応する必要はほとんどないわけで、どちらかというと、バージョン依存の激しいSDKではな

この資料はなに？ Makeの良さを伝えるものです CとかC++の持ち物じゃない 普段使うコマンドのショートカットみたいな 2016年でもMakefileは便利 頑張らないでScala 〜VOYAGE GROUPにおけるアドネットワーク開発の戦略〜 // Speaker Deck Makeってなに？Makefile??? make(メイク)は、プログラムのビルド作業を自動化するツール。コンパイル、リンク、インストール等のルールを記述したテキストファイル (makefile) に従って、これらの作業を自動的に行う。 出典：https://ja.wikipedia.org/wiki/Make つまり、自動化のためのツール。 make が生成するのはふつう C のプログラムだが、べつに C のプログラムに限らず、Makefile に書く生成コマンドの書きように よっては、TeX のファイルだろうが

Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。 $ cd $GOPATH

この記事は Go (その2) Advent Calendar 2016 21日目の記事です。 開発時のタスクランナーがわりにMakefileをよく使います。 make build したらビルドするとか make fmt したら go fmt するとか、 make server したらサーバを起動するとかです。 中には make build target=linux のようにオプションも渡したくなったりします。 しかしMakefileのタスクとその使い方をすぐに忘れてしまってMakefileの中を確認するということがよくあるので、 ドキュメントを表示してくれるようなコマンドをGoで書いてみました。 以下のように記述されたMakefileがあったとします。 .PHONY: command command: @## param1=value1 param2=value2 @# @# docume

$ cat foo.sh #!/bin/sh elems[0]=0 elems[1]=1 for x in ${elems[*]}; do echo $x done $ ./checkbashisms foo.sh possible bashism in foo.sh line 3 (bash arrays, H[0]): elems[0]=0 possible bashism in foo.sh line 4 (bash arrays, H[0]): elems[1]=1 possible bashism in foo.sh line 5 (bash arrays, ${name[0|*|@]}): for x in ${elems[*]}; do

先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何？ Work In Progress Pull Request の略です。 Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン

はじめに 昨今のAndroid開発ではActivityやFragmentのマッチョ化を防止するために、CleanArchitectureやMVP、MVVMなどのレイヤードアーキテクチャを採用している人が多いと思います。 Realmは素晴らしいツールで大好きなのですが、ドキュメントのベストプラクティスに従おうとするとガッツリと画面のライフサイクルに依存しているため、設計に与える影響は大きいなぁと感じていました。 これからActivity/FragmentがRealmオブジェクトを保持することなく使うための一例を紹介したいと思います。 全ての人にオススメできるTipsではないかもしれませんが、参考にしていただけたら幸いです。 3行まとめ カスタムApplicationクラスでUIスレッド用のRealmオブジェクトを保持する DB層のDaoパターンなどで①のRealmオブジェクトを渡す(Dagg

$ my-company usage: my-company <command> [<args>] commands: hosts サーバのホスト名一覧を表示 git-log-remote [<hosts>] デプロイされていない差分コミットがあれば表示 env-diff [<hosts>] 環境変数の設定漏れを表示 check-update [<hosts>] yum パッケージの更新を表示 self-upgrade my-company コマンドを更新 update [<hosts>] yum パッケージを更新 よくある風景 Chat bot は環境構築が面倒（言語・ツール等の巨大な依存があったり・・・） 運用ツールのコマンドをコピペ中心に運用している 運用で使うコマンドを管理する話です 各自インストールして使う汎用コマンドの話をします 汎用コマンドの構成 各自 git clone し

こんにちは、ほそ道です。 今回はDOMネタです。 イベントのキャプチャとバブリングについて覚書をまとめて参ります。 また今回はv8での検証であり、レガシーなIEは対象外です。 レガシーなIEはイベント設定メソッド自体が違いますのでご注意くださいませ。 目次はこちら 入れ子なDOMのイベント発生順序制御 DOMが入れ子構造になっていてそれぞれにイベント(例えばClickイベント)が設定されていた場合 「このように動いてほしい」という期待はケースバイケースであると思います。 期待通りの処理になるようカッチリ制御しちゃいましょう。 addEventListenerの第三引数「useCapture」 例えば下記の様なHTMLがあったとします。 body内にdivが入れ子になっておりそれぞれにClickイベントが登録されています。 <html> <head lang="en"> <meta char

git current-branch, git fetch-pulls, git pull-dry-run など git alias ネタGit

こんばんは、@todokrです。この記事は絵文字 / Emoji Advent Calendar 2016の22日目の記事です エモジニアンと絵文字追加運動 絵文字愛好家のみなさま方におかれましては、「いつかは自分もUnicodeに絵文字追加のプロポーザルを…」という思いをごく自然とお持ちのことと思います。 世間を見渡せば「ハンバーガーやホットドッグの絵文字はあるのになんでタコスはないんだ！」とブチ切れたタコベルがタコス絵文字収録キャンペーンを始めてしまったり、「我々には餃子の絵文字が必要である」プロジェクトがChange.orgに誕生したりなどなど、敬虔なエモジニアンらによる急進的な絵文字追加運動は枚挙にいとまがないようです。 Change.orgの餃子追加プロジェクトの方では「署名の理由」欄に「私は餃子です」と書き残す謎のサンフランシスコ人がいたりなど、異様なテンションの高さが感じられ

先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃんとやらないと、コンパイルが通らないからです。

この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ