いろんなサーバーにsshしてちょろっと設定を確認したりするときってあると思います。 ただその時にllがつかえなかったり、vimのタブが空白4つがいいのに8文字分の広さのtab文字だったりして、ちょっとずつストレスが溜まっていきます。 やっぱりserverfaultでもおなじ苦労をしている人がいました。 vim - How to bring .vimrc around when I SSH? - Server Fault http://serverfault.com/questions/33423/how-to-bring-vimrc-around-when-i-ssh ただここにあるようにdotfilesとして保存して先でcloneするのもとても面倒くさい。第一各サーバーへ変更を入れないといけないし。SSHの秘密鍵みたいに携えていきたい。 そこで探していたらsshrcというツールを見つけて

クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例

本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関

参考URL http://hotolab.net/blog/mac_localize/ - /System/Library/CoreServices/SystemFolderLocalizations/Japanese.lproj/ の中にある、SystemFolderLocalizations.stringsを編集します。 ただ、SystemFolderLocalizations.stringsは、plistというバイナリ形式で保存されているため、一旦xml形式に変換してからでないと編集ができないようです。 変換するには、ターミナルでplutilのコマンドを使います。 このコマンドは、Xcode を入れていると使えるコマンドになるようです。

これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情

zshは標準の機能を使うだけでも便利だけど、それでも足りないときはいろいろなプラグインを追加して拡張できる。でも、プラグイン一覧はどこかにまとまっているわけではない。特に、zsh本体に標準で含まれているプラグインはman zshcontribを見ればわかるけど、それ以外のユーザが独自に作ったプラグインはGoogle検索とかで地道に探すしかない。 そこで、zshで使用できる標準で含まれていないプラグインをまとめて紹介する。これを参考にして、zshをもっと便利にしてください! ディレクトリ移動 名前 概要 参考記事

Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので

より快適なVim × Ruby環境を目指して構築したvim環境について。 0からでも構築できるように整理した。 やること 最初にRuby、Vim、その他必要なパッケージをガシガシインストールする。 その後、設定した下記機能について実際の操作例を見ていく。 自動コード補完ができるようにする（Rsense/neocomplete） Vim上で静的解析ができるようにする（Rubocop/syntastic） Vimからリファレンスを閲覧できるようにする（vim-ref/vim-ref-ri） メソッド定義元へのジャンプができるようにする（ctags/vim-tags） 構文終わりのキーワードを自動入力できるようにする（vim-endwise） OSはLinux（CentOS6.5）を想定。検証環境は以下のとおり。 $ uname -a Linux vagrant-centos65.vagrant

ブラウザを更新したりするときの癖で、間違えてiTerm2に対して「Command+R」ショートカットを実行してしまう場合がある。 このショートカットには「Reset」という機能が割り当てられていて、シェルの現在の入力位置がウインドウの一番上の行にくるよう自動的にスクロールしてくれる。 ただこの機能、Vimを起動している時は非常に迷惑。 そこで、Command+RでResetが実行されないようにする方法をメモ。 iTerm2のメニューから「iTerm→Preferences…」を選ぶ 「Keys」タブを選択 左側「Global Shortcut Keys」の一番下にある「+」ボタンを入力 「Keyboard Shortcut」にフォーカスが当たっている状態で「Command+R」入力 Actionを「Ignore」に設定し「OK」 これで、Command+Rを入力してもResetが実行されな

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

この記事は Go Advent Calendar 2014、16日目の記事です。 はじめに Matz さんが streem という、ストリーム指向言語の開発を始めるらしいです。 まだ文法の設計段階ではあるけど、それなのにかなりの量の pull-req がバンバンと来てて凄いなーと思いつつも「この pull-req 量だと僕には出番無いなー」と思ったので、README.md に書かれているサンプルだけを頼りに streem を golang で実装してみました。 先日はネタで streem のマネをして yacc 定義部分だけ公開していましたが、本日ネタが無い中にTLがヒートアップして焦りに焦って勢いで実装してみました。いやはや異様な追い込みを感じます。。。 まずは streem を知る streem は README.md に書かれている通り並列実行を行いつつストリームを処理する言語です。

(2015/10/13追記) 今なら、他言語には無名関数やcallback関数というものがありますねとか、イベント駆動の世界を覗いてから戻ってくるとより腑に落ちるかもしれませんとか、もう少し全体観の中で説明する気がしますが、当時は本記事の様な理解が役に立ったことは事実なので、引き続き公開を続けます。 (2013/11/29追記) block_given? について Twitter上で「Kernel.#block_given?についての解説があってもよさそう」と 指摘を頂きましたので、本文下部に追記しました。 概要 Ruby on Rails Tutorialのエッセンスを自分なりに整理してみる4 Railsを触る際知っていると便利なRubyの基礎 [ブロックとかシンボルとか] http://qiita.com/kidachi_/items/46a6e49b6306655ccd64 の続き。

アナウンス Selenium 談話会 in Slack まだまだ活動続けています！！(2019/09/09追記) https://selenium-danwakai.connpass.com/ でアナウンスを出しています。 2015/春から「Selenium 談話会 in Slack」というものをはじめました Slack(チャット)を使って日々の困りごとなどを同士とリアルタイムで情報交換することができます 登録されたユーザは2015/06/25時点で35名 => 2019/09/09時点で596名 半年に１回程度でチャット上に集まってテーマを決めて話をしています Ex) 「第３回Selenium談話会 in Slack」 のまとめ 詳細、参加方法などは上記リンク先に書いています 2018/09/18時点で13回開催しています。ご興味のある方はお気軽にご参加ください https://sele

こんにちはこんにちは 私は日々大量のサーバーで作業をする必要があるので tmux が欠かせません そんな中最高便利な記事が先日公開されました Tmuxでウィンドウをインタラクティブに移動する - Qiita [キータ] しかしこの記事が全く話題になっていません おそらく理解されていないのだと思います ということで私がもう少し詳しく説明したいと思います 先程の記事と同様に ssh-configにはパターンが使えるので便利 - Qiita [キータ] tmuxで色んなホストにsshする時に便利な.ssh/config - Qiita [キータ] の合計 3 記事を組み合わせて初めて達成できる最高のソリューションを紹介します tmux のウィンドウの名前 tmux で大量のウィンドウを立ち上げて ssh しているとどのウィンドウがどこのホストにいるのか分からなくなります そこで先程紹介した 2

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ

特技はgit commit -a -m いろいろ修正です！ ダメ。ゼッタイ。 しかしこまめにコミットするのは面倒臭いですよね。でもrebaseやらrevertやらcherry-pickするにもコミットログは綺麗にしたい。そんなズボラで凝り性なあなたはgit add -pでコミットを整えるといいと思います。

概要 チームや組織、プロダクトをまたいでcookbookを使っていく場合に使えるcookbookの書き分け方を紹介します。 要はプロダクト毎にサーバに対する要求は変わりうるのでサービス毎にcookbookを分けるんだけど、会社全体として組織プロダクトをまたいで共通化しておきたい部分は共通のcookbookを使いましょうという話です。 こういう分け方をしたらよい、という話もします。 組織やプロダクトの成長とcookbook 小さな組織やチーム内でchefを導入した場合、cookbookを書くのは大抵の場合一人だと思います。 扱うサーバの種類もそんなに多くないので、apacheのインストールやphpの設定を一つのrecipeにベタ書きしても人間が管理できるボリュームに収まると思います。 というか、変に分割するよりもベタ書きのほうがrecipeの見通しがいいと思います。 ところが、組織が大きくな

Qiita Hackathon、今回のテーマは「GitHub APIを用いた開発」 ということで、「GitHubのコミットメッセージを英語の勉強に活用しよう」 という趣旨でアプリを作ってみました。 今回はAngularJSを用いてフルJavaScriptで実装しました。 使い方 http://yuch.github.com/angular/app/ を開く 参考にするレポジトリを探すためにキーワードで検索する 一覧からレポジトリをクリック コミットメッセージで使われている英単語と例文（実際のコミットメッセージ）がずらずら表示されます 知ってる単語/不要な単語は「i know」ボタンを押す 覚えたい単語は「Study」ボタンを押す ※ データはブラウザのクッキーに保存されます。 ※ 対応ブラウザ: Chrome/Firefox 感想 ネタに迷走しすぎて結局1日目の帰宅後に、作るはめになってし

あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 この記事について この記事は、新人向けの研修内容を再編集してお送りします。 この記事の内