読者です 読者をやめる 読者になる 読者になる

ツテなしフリーランス日誌

ツテが全く無いまま会社を辞め、我が道を行くフリーランスエンジニアのブログです



Vimでクリップボードにコピー&ペースト

vim

Vimでファイルを編集している時のコピー方法としては、
vまたはVで選択範囲して、yでコピー。

ペーストはpです。

しかし、GUIで他の場所からマウスで選択して、クリップボードにコピーし、 vimにペーストをした時にペースト出来ないことがあります。
  

確実にVimの内容をクリップボードにコピーし、 またクリップボードの内容を確実にVimにペーストする方法を書きます。

Vimのテキストをクリップボードにコピー

選択範囲をクリップボードにコピー

  1. vもしくはVを使用し、コピーする範囲を選択します。
  2. 選択した状態で、:w !pbcopyと入力しEnterを押して下さい。
      

これでクリップボードにコピーされました。

ファイル全体をクリップボードにコピー

  1. :%w !pbcopyと入力し、Enterを押して下さい。
      

これでファイル全体がクリップボードにコピーされました。

  

Vimクリップボードの内容をペーストする

  1. カーソルを使い、他のエディタもしくはWebなどから普通にコピーします。
  2. Vimで対象のファイルを開きます。
  3. ペーストしたいところまでいき、:r !pbpasteと入力します。

もしくは

  1. vVを入力し、ビジュアルモードにします。
  2. :!pbpasteを入力し、Enterを押して下さい。
      

他のサイトにも色々なやり方が書いてありますが、vimでヤンクして、他でクリップボードにコピーしてなどを繰り返しているとコピペが出来ないことがありました。
  

今回紹介した方法はいつでもコピペができるので、困ったときは試してみてください。

追記

もう一つのコピー&ペーストの方法があります。

  1. GUIで他の場所からマウスで選択して、クリップボードにコピー
  2. Vim上で :a! を入力し、enter
  3. Vim上で、command + c(Macの場合)
  4. ペースト内容が表示されるので、キーボードのescを押し、テキストを反映

こちらのやり方のほうが、単純かつ簡単でよいかもしれません。 最近はこちらの方法でコピペを私はしています。   

ダメになるソファを1年使ってダメになったのか

雑貨
楽な体勢でプログラミングがしたい!
 
会社では仕事モードなので、ピシっと背筋を伸ばして作業がしたいんですが、
 
 
 
自宅ではできるだけリラックスしてコードが書きたい!
 
 
 
ということで、自分の体勢を自由に変えられかつ、いつでも寝れる体勢にもっていけるであろう
 
 
 
「人をダメにするソファ」を1年間使って、プログラミングしてみました!
 
 

最初の1週間目

 
家にものが届いた時はテンションが上りましたが、
 
 
 
意外とでかい。。。
 
 
 
イメージ図で見ると色んな体勢で気持ちよさそうに座っているので、
 
いざトライ!
 
 
 
 
うん???
 
 
なんか、沈むけどあんまりシックリこない。。。
 
向きを変えて座ってみるけど、
 
うーん、微妙に体になじまない。。。
 
 
多分、まだいい具合に柔らかくなってないんでしょうね。
 
 

1ヶ月経過

 
 
大分体に馴染み、いい感じで座れてました!
 
座ってる時に疲れは感じず、腰も痛くならず、
 
 
 
というか良い体制で寝れる!
 
でかい枕としても使える!!
 
 
これはいい。。。
 
 
コーディングもMacBookでしてるので、膝に乗せてそのまま出来る。
 
これはいい。。。
 
 

半年経過

 
 
ぺしゃんこになるのかなと思いきや、この時が一番フィットしてました。
 
体にちょうど馴染み、自分の理想かつ快適なポジショニングが取れる。
 
なんと素晴らしい。
 
そして、、、
 
 
コタツとの組み合わせが最高!!!
 
 
もう出れないですね。コタツの中で眠る率が倍以上に増えました。。
 
コーディングしながらふと寝てるときも度々。
 
冬にこのコンボはダメになる気持ちがわかります。
 
 

1年経過

 
座るとあれ?
 
 
なんか硬いものが触れる。。
 
これは床の硬さだな。。
 
 
 
真ん中寄りに座れば大丈夫なんですが、
 
端によると床の硬さが分かってしまいます。
 
 
 
寄りかかる分には良いクッションなんですが、
 
座るものとしてはもうだめなのかなー。
 
 

1年半経過

 
座り心地というよりも
 
すでにクッション兼まくらという感じになってきました。
 
こんな感じに少しへこたれました。
 

f:id:kurisankaku:20160421212735j:plain

 
 
 
カバーをかけてるので壊れるとか破けるとかはないんですが、
 
もうソファというより巨大クッションですね(笑)
 
 
 
でも快適にコーディングは出来てます!
 
 

結論

 
ソファとしての機能は1年経ったあたりから欠けてきました!
 
毎日座ってたので、ヘコたれるスピードが早かったのかもしれないです。
 
 
 
ただ、クッションとかまくらとかではすごく良い感じに使えてるので、
 
捨てるってことはしないですね。
 
 
 
でっかいクッション兼ソファが欲しいって方にはすごくおすすめです!
 
ソファが欲しい!って方はソファを買って下さい!(笑)
 
 
あ、1年使いましたが、私自身はこのソファのせいでダメになったとかは特に無かったです!
 
心地よいクッションが増えてよかったなーぐらいの感じですね。
 
 

Vagrantでネットワークエラーになる。git clone, pushが出来ない時

vagrant

Vagrantvagrant sshでログインして、作業をし、git pushをしようとしました。

しかし、下記のようなエラーが出ました。

ssh: Could not resolve hostname github.com: Temporary failure in name resolution
fatal: The remote end hung up unexpectedly

  

pingコマンドを試した所

$ ping www.yahoo.co.jp
ping: unknown host www.yahoo.co.jp

  

unknownと言われる始末。。。

vagrantを再起動した所、正常に動作しました。
  

多分、PCをスリープ状態にしたためにnetworkがstopしたのではないかと思います。
ただ、スリープをしても起きないこともよくあるので、どの時に起こるのかは突き止められていません。
  

networkのエラーが出た場合は、再起動もしくは/etc/init.d/network restartをして、networkを起動させて下さい。
  

Githubの複数アカウントをsshで使用する時の設定とプロジェクト毎のconfigの設定

Git

仕事とプライベートのGithubアカウントを持っている方は多いと思います。

1つのPCで仕事用のGithubとプライベート用のGithubsshで使用するには、アカウント毎に公開鍵の設定が必要です。

なので、今回は、既に公開鍵を登録してあるGithubを所有し、別のGithubアカウントでもsshを行いたい場合の設定方法について書きます。

新しい公開鍵、秘密鍵の作成

~/.sshのディレクトリを見てみましょう。既に一つ目のGithubの時に作成したid_rsaid_rsa.pubがあると思います。

$ ls ~/.ssh
id_rsa  id_rsa.pub

  

ここに新しい別名の公開鍵と秘密鍵を作成します。

$ cd ~/.ssh
$ ssh-keygen -t rsa -C "メールアドレス" -f "鍵のファイル名"

  

例えば鍵のファイル名をprivate_id_rsaとして作成します。ディレクトリを見ると

$ ls ~/.ssh
id_rsa  id_rsa.pub private_id_rsa private_id_rsa.pub

  

作成されました。

  

作成した公開鍵のGithubへの登録

作成した公開鍵を使用するGithubへ登録して下さい。

今回の例ならprivate_id_rsa.pubの中身を全てコピーして登録して下さい。コマンドでコピーする場合は、

$ pbcopy < ~/.ssh/github_private_rsa.pub

  

コピーした内容をGithubSSH keysに追加し登録して下さい。

  

~/.ssh/configにHostの指定

次にHostの指定を ~/.ssh/configに書きます。configがない場合は新しく作って下さい。

Host <ホスト名>
  User git
  Port 22
  HostName github.com
  IdentityFile <作成した秘密鍵へのパス>
  TCPKeepAlive yes
  IdentitiesOnly yes

  

今回の例の場合、このようになります。

Host github-private
  User git
  Port 22
  HostName github.com
  IdentityFile ~/.ssh/github_private_id_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes

  

記述した内容が正しいか、接続テストをします。

$ ssh -T <ホスト名>

  

今回の例の場合、

$ ssh -T github-private
Hi ◯ ◯ ◯ ! You've successfully authenticated, but GitHub does not provide shell access.

  

というようにメッセージが返ってきたら成功です。途中質問されたらyesを打ち込んで進めて下さい。

  

設定したHostでcloneする

設定したHostを使用して、cloneをします。

git@<設定したホスト名>:<Githubアカウント名>/<対象リポジトリ名>.git

  

例えば、先ほど設定したホスト名と、アカウント名がhogeで、testリポジトリcloneするとした場合、

$ git@github-private:hoge/test.git

となります。 これで、以降は通常通りpullpushなどを新しい鍵で行えるようになります。

  

プロジェクト毎のconfigの設定

最初にGitをインストールした際に、大抵

git config --global user.name "ユーザー名"
git config --global user.email "メールアドレス"

と設定したと思います。一つのアカウントを使用しているのなら問題ないのですが、

複数アカウントを使用していると、プライベートの時は別のユーザー名とメールアドレスを使いたいと思います。

その場合は、対象のリポジトリのルートに移動して、

git config --local user.name "新ユーザー名"
git config --local user.email "新メールアドレス"

  

とすると、そのリポジトリではそのconfigの設定でコミットが出来るようになります!

例えば、testリポジトリのユーザーを変えるとしたら、

$ cd ~/test
$ git config --local user.name "hoge"
$ git config --local user.email "hoge@test_test_test123.com"
$ git config -l --local
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
user.name=hoge
user.email=hoge@test_test_test123.com

  

と変わっていることが分かります。

設定を変えたい場合は、やってみて下さい。

  

開発効率をUPする Git逆引き入門

開発効率をUPする Git逆引き入門

  • 作者: 松下雅和,船ヶ山慶,平木聡,土橋林太郎,三上丈晴
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2014/04/09
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (6件) を見る

gitのリモートリポジトリの設定と変更、設定ファイルの場所

Git

GitのoriginのURLを設定するときのコマンドで、

git remote add origin <url>

と指定しますが、この<url>の部分のパスって結構間違えたりします。
なので、間違えた場合のURLの確認と修正方法について説明します。   

リモートの設定の確認

まず、今のremoteの設定状況を確認します。

git remote -v

  

先ほどの<url>git@github.com:kurisankaku/hoge.gitと設定したとします。
下記のようにリモートに設定したURLの状態が出てきます。

origin   git@github.com:kurisankaku/hoge.git (fetch)
origin  git@github.com:kurisankaku/hoge.git (push)

  

設定したURLがfugaではなく、hogeに間違っている事に、気づいたので、それを修正します。

  

リモートリポジトリのURLの変更

変更するときのコマンドは下記です。

git remote set-url origin <URL>

  

とするので、今回であれば、

$ git remote set-url origin git@github.com:kurisankaku/fuga.git

  

となります。確認すると、

$ git remote -v
origin  git@github.com:kurisankaku/fuga.git (fetch)
origin  git@github.com:kurisankaku/fuga.git (push)

  

正しく変更されていることが分かりました。

  

リモートURLが記載されているファイル

この設定が書かれているファイルがどこにあるかというと、
<プロジェクトのルート>/.git/config

に記載されています。なので、先ほどの状態であれば、

$ cat ./.git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:kurisankaku/fuga.git
    fetch = +refs/heads/*:refs/remotes/origin/*

なので、ここのurl = git@github.com:kurisankaku/fuga.gitを直接書き換えてもURLを変更することも出来ます。

  

リモートの追加と削除

あまりorigin 以外に追加することもないと思いますが、
追加する場合のコマンドは次です。

git remote add <追加する名前> <追加するURL>

  

例えば今回、staging という名前を追加する場合

$ git remote add staging git@github.com:kurisankaku/fuga2.git
$ git remote -v
origin  git@github.com:kurisankaku/fuga.git (fetch)
origin  git@github.com:kurisankaku/fuga.git (push)
staging git@github.com:kurisankaku/fuga2.git (fetch)
staging git@github.com:kurisankaku/fuga2.git (push)

  

と追加されたことが分かります。

削除する場合は、

git remote rm <削除する名前>

そして、今回は先程のstaging を削除する場合

$ git remote rm staging
$ git remote -v
origin  git@github.com:kurisankaku/fuga.git (fetch)
origin  git@github.com:kurisankaku/fuga.git (push)

と削除されました。

  

リモートの調査

特定のリモートの調査をする場合、次のコマンドでリモートが保持しているブランチが何があるかなど、詳しい内容が調べられます。

git remote show <調べたいリモート名>

  

リモートのヘルプ

リモートのコマンドのヘルプは下記で見られます。
オプションや他のコマンドもあるので、一度見てみて下さい。

git remote --help

いつも調べては忘れていたので、今回は色々調べてみました。
調べてまとめるとすっきりしますね。         

開発効率をUPする Git逆引き入門

開発効率をUPする Git逆引き入門

  • 作者: 松下雅和,船ヶ山慶,平木聡,土橋林太郎,三上丈晴
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2014/04/09
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (6件) を見る

vimrcをgithub管理して、簡単にvim環境構築

vim

vimを使用している人なら必ずカスタマイズしているdotfiles(.vimrcなど)

このdotfilesをGithub上で管理することによって、新しいPCやサーバーへ自分のvim環境を簡単に構築することが出来るようになります。
  
また、vimのplugin管理にはNeoBundleを使用しているので、NeoBundleの設定も合わせて、 書きたいと思います。  

  

  1. _vimrcの作成とシンボリックリンク
  2. NeoBundleをサブモジュールとして追加
  3. NeoBundleの設定
         

1. _vimrcの作成とシンボリックリンク

ターミナルを起動し、ホームへ移動します。そして、ディレクトリを作ります。 ここで作るディレクトリ名は何でも構いませんが、通例に従ってdotfilesとしておきます。

cd ~
mkdir dotfiles

  

次に、dotfilesに移動し、_vimrcを作成します。これは、.vimrcのシンボリックリンク元として扱うために作ります。

cd dotfiles
touch _vimrc
ln -s ~/dotfiles/_vimrc ~/.vimrc

  

これで、_vimrcを編集していけばvimの設定が変わるようになりました。

次に、このdotfilesフォルダをgithubで管理します。(先にGithubでdotfilesのリポジトリを作成しておいて下さい)

cd ~/dotfiles
git init
touch README.md
git add -A
git commit -m "first commit"
git remote add origin [作成したGithubのリポジトリのパスを指定して下さい]
git push -u origin master

  

2. NeoBundleをサブモジュールとして追加

続いて、NeoBundleを導入します。

NeoBundleをそれぞれの環境毎にcloneして来ても良いのですが、今回はgitのsubmoduleとして管理したいと思います。
これをすれば、新しい環境では、シンボリックリンクを貼ればいいだけになるので。

# submoduleへ追加
git submodule add git://github.com/Shougo/neobundle.vim ~/dotfiles/.vim/bundle/neobundle.vim
git commit -m "add neobundle submodule"
git push origin master

# submoduleを取得します。
git submodule update --init

# シンボリックリンクの作成
mkdir -p ~/.vim/bundle
ln -s ~/dotfiles/.vim/bundle/neobundle.vim ~/.vim/bundle/neobundle.vim

  

3. NeoBundleの設定

続いて、NeoBundleを使用するために_vimrcに書きを追記します。

" 一旦ファイルタイプ関連を無効化
filetype off

if has('vim_starting')
  " 初回起動時のみruntimepathにneobundleのパスを指定する
  set runtimepath+=~/.vim/bundle/neobundle.vim/
endif

call neobundle#begin(expand('~/.vim/bundle'))
NeoBundle 'Shougo/neobundle.vim'

" NeoBundleを初期化
call neobundle#begin(expand('~/.vim/bundle/'))

" インストールするプラグインをここに記述
NeoBundle 'Shougo/unite.vim'
NeoBundle 'Shougo/vimfiler'
NeoBundle 'Shougo/vimproc.vim', {
\ 'build' : {
\     'windows' : 'tools\\update-dll-mingw',
\     'cygwin' : 'make -f make_cygwin.mak',
\     'mac' : 'make -f make_mac.mak',
\     'linux' : 'make',
\     'unix' : 'gmake',
\    },
\ }

call neobundle#end()

" ファイルタイプ別のプラグイン/インデントを有効にする
filetype plugin indent on

  

vimを起動し、次のコマンドをvimで打ち込みプラグインをインストールして下さい。

:NeoBundleInstall

これで、NeoBundleを使用してプラグインの管理と利用ができるようになりました。
  

vimには様々なプラグインがあり、また自分独自の設定をすることで、より使いやすいものとなります。
私のdotfilesを載せておきますので、ご参考までに。

dotfiles
  

実際に、新しい環境でvimを設定する

作成したdotfilesを対象のホームディレクトリにcloneし、シンボリックリンクを貼ります。

git clone [リポジトリのパス]
ln -s ~/dotfiles/_vimrc ~/.vimrc
mkdir -p ~/.vim/bundle
ln -s ~/dotfiles/.vim/bundle/neobundle.vim ~/.vim/bundle/neobundle.vim

# submoduleを取得していない場合は、初期化し取得します。
git submodule update --init

  

そして、vimを開き、

:NeoBundleInstall

を実行して、環境を設定しましょう。

開発者が初めて本格的にUIデザインをしてわかった大変さ

UI

新しいアプリを一から自分で作るために、企画と設計を行っています。

私は開発者だったので、
今までの仕事では、企画が仕様を考え、制作がUI設計とデザインをし、画面遷移図がある程度出来上がった状態のところから開発をしていました。

出来上がったものに対して、開発者側の立場からUIについて言及したり、改善提案を出したりしたことはありました。
自宅で作るお遊び系のアプリならUIを作ったこともありました。



仕事で様々なアプリを開発したり、普段の生活で色んなアプリを使用をしていたこともあって、
本格的な自分のアプリを作るときにも『UIデザインなんて、ちゃちゃっとできるでしょ!』と思ってたんですが。。。




作れない!




どうしてもなんかダサいUIになってしまう。。。(泣)

というか、作れるわけが無いんですよね。
当たり前ですよ。。



なぜかって、今まで本気で一から書いたことが無いんですから!!



そして、考えました。今一番いい方法は何かないかと!
選択肢としていくつか出しました。

  • デザイナーに頼んでデザインしてもらう
  • 自分の力で空で考えて書きまくる
  • 競合分析をし、様々なパターンの組み合わせで作る


それぞれについて考察しました。

1.デザイナーに頼んでデザインしてもらう

仕様は考えてあるので、一番手っ取り早く尚且つリスクが少ない方法だと思います。


しかし!デザイナーに頼む場合はどうしてもお金が発生してしまいます!


お金を多少出せないとできませんし、デザイナーもピンきりではあるので、
イメージの共有が下手に間違ってしまうと、お金の無駄になってしまいます。。。


今回自分で一からつくりたいと思ってた私にとっては今の段階では無いかなと思いました。

ワイヤーフレームや画面遷移とアクションがしっかり決まり、デザインの話になった時に、良い方を探したいと思います。

2.自分の力で空で考えて書きまくる

うん、無いですね。これは無いです。

仕事や日常で色々なアプリに触れたからといって、それが自分で書けるわけがありません。


ソースコードを読んでるだけではプログラムは書けません。

好きな漫画を死ぬほど読んだとしても、一回も書かずに主人公が綺麗に書けるわけがありません。


ということで、自分の頭だけで考えて作るという作業は
相当な数をこなしてきた方でないと無理だということが今回の事で分かったので、
デザイナーに転向しないかぎりはこの選択肢はないなと思いました。

3.競合分析をし、様々なパターンの組み合わせで作る

私は、この考えに落ち着きました。

最初からこの考えになってたわけではありません。

UIの参考になるサイトってないかなと探しているうちに、自分のサービスと類似のものを調査するようになっていました。
そして、「これって結局競合分析ではないか!」と思ったんです。


競合分析をしていると、ただアプリを眺めているだけではなく、

  • どんな機能があり、
  • どういった動きをして、
  • どこで独自性を出してるんだろう


って考えながら見るようになります。


そうすると、各アプリのUIを見た時に、自分のアプリでなら


「このUIは、指向性が合ってるし使いやすそう!」
「このUIは方向性が違うから自分のに使ったらイケてないな。。。」


という事が分かってきました。

なので、競合アプリからのUIを参考にして、作ることにしました。



※ ここで注意するのが、そのままUIを持ってくるのは良くありません。コピペはもちろんダメです。
考えなしに持ってくると、単なるつぎはぎのアプリになってしまい、使い勝手が逆に悪くなってしまいます。
自分のサービスの軸をしっかり考えて、参考にするという考えを忘れずにしましょう。

サービスを作るときは調べることが大切

どんなデザイナーでもプログラマーでも参考資料って必要ですよね。
サービスを作る前には、必ず調査する必要があります。


当たり前のことなんですが、それが今回身にしみて分かりました。

調査をしないで作った製品は、どこかにある製品と類似してしまったり、
もしくは、作った後に同じような製品があってショックを受けたり、パクリと言われたりするかもしれません。


まずは世の中にあるものを調べて、それで企画デザインをする!


そのプロセスがどれだけ時間がかかるのかが、改めて知れた良い機会でした。
世の中のデザイナーさん達に改めて尊敬の念を抱きました。