投稿者「sasaki」のアーカイブ

[vim] syntastic + rubocop で保存時には実行しないようにする

概要

題の通りの備忘録。[Ruby] RuboCopをインストールしてvimで実用化するまで | qs Developersのオマケ。

問題点

[Ruby] RuboCopをインストールしてvimで実用化するまで | qs Developers にて、syntasticでrubocopを使うように設定することが出来たが、rubocopは案外処理に時間がかかってしまうので、保存のたびに発火されると困る。(非同期で動かせる方法があるなら良いけど…)

解決策

vimrcのsyntasticの設定周りを以下のように変更

NeoBundle 'scrooloose/syntastic.git'
set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*
let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1
let g:syntastic_check_on_open = 0
let g:syntastic_check_on_wq = 0
let g:syntastic_mode_map = { 'mode': 'passive', 'passive_filetypes': ['ruby'] }
let g:syntastic_ruby_checkers=['rubocop']

上記のようにすると、ファイルを開いたときや保存した時に自動で解析が走らないようになる。

手動で解析を実行するには、:SyntasticCheck コマンドを叩く必要があるが、これはこれで面倒くさい。

なので以下のようなキーバインドを定義する。

nnoremap <C-C> :w<CR>:SyntasticCheck<CR>

これでノーマルモードでCtrl+Cキーをタイプすることで、バッファの保存と解析の実行をまとめて行うことができる。

普段の保存は従来どおり:wで、解析付きで保存したい場合はCtrl+Cと使い分けることで、保存のたびに一瞬重くなるのを避けることができる。

[Swift4] OauthでzaimAPIのアクセスキーを取得する

概要

Swift4と、OauthSwiftを用いて、iOSでZaimAPIを利用するためのアクションキーを取得する手順の備忘録。本記事ではzaimを例にしているが、基本的にはTwitter APIやGithub APIなんだでも同じ手順で出来る。

前提

OSX 10.126
iOS 11.2.6
xcode 9.2
swift 4.0.3
OAuthSwift 1.2.0
  • xcodeがインストールされている
  • zaimのアカウント登録済み

Zaimにアプリケーショを登録する

zaimログイン後、以下にアクセスしてアプリケーションの登録を行う。
https://dev.zaim.net/home/clients/add

  • 名称: アプリの名前とか入れる
  • サービス種類: iOSで利用するので「クライアントアプリ」を選択
  • 概要: 説明を書く
  • サービスのURL: 開発段階では何でも良い
  • アクセスレベル: どこまでできるか
  • アイコン画像: 無くても良い

登録するとコンシューマIDとコンシューマシークレットが手に入るので控えておく。

プロジェクトを作成

  • single page applicationで作成
  • 言語はswiftを選択

Project設定→inffo→URL Typesより、ディープリンクの設定を行う。

ディープリンクは、そのアプリがインストールされた端末のsafariで、特定のURLを開いた際にそのアプリを開くようにする設定。これを設定しておくことで、Zaimなどの各種OAuthサービスからコールバックでアクセスキーを受け取る際に、ブラウザから直接アプリを立ち上げることができる。

URL Schemesの部分に適当にプロジェクト名を入れたりする。これがディープリンク用のURLになるだけなので何でも良い。

OAuthSwiftのインストール

本記事では、OAuthによるアクセスキーの取得に、Swift用OAuthライブラリのOAuthSwiftを利用する。

OAuthSwiftのインストールにはCocoaPodsを用いる。CocoaPods自体のインストール方法と基本的な使い方については、iOSライブラリ管理ツール「CocoaPods」の使用方法 – Qiitaなどを参照。

Podfileを以下のようにして

platform :ios, '10.0'
use_frameworks!

target 'ProjectName' do
  pod 'OAuthSwift'
end

インストール

$ pod install

以下のようなPodfile.lockが生成されればOK

PODS:
  - OAuthSwift (1.2.0)

DEPENDENCIES:
  - OAuthSwift

SPEC CHECKSUMS:
  OAuthSwift: 7fd6855b8e4d58eb5a30d156ea9bed7a8aecd1ca

PODFILE CHECKSUM: 5eac377106539aabc31c87229422b0d43b9c0acb

COCOAPODS: 1.4.0

画面の作成

適当に画面を作る。ここは好きなように作ってよい。

とりあえず今回は右上の「同期」ボタンをタップすると、ViewControllerにタップイベントを走るようにした。

実装

AppDelegate.swift

以下のメソッドを追加する。Zaimからコールバックが飛んできた時にゴニョゴニョする部分。

func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
  OAuthSwift.handle(url: url)
  return true
}

ViewController.swift

import UIKit
import OAuthSwift

class ViewController: UIViewController {

  var oauthswift: OAuthSwift? = nil
  
  @IBAction func onTappedSyncButton(_ sender: UIButton) {
    let oauthswift = OAuth1Swift(
      consumerKey:    "0f8hogehogehogehogehogehogec0b6",
      consumerSecret: "695fugafugafugfugafugafugaaf3f",
      requestTokenUrl: "https://api.zaim.net/v2/auth/request",
      authorizeUrl:    "https://auth.zaim.net/users/auth",
      accessTokenUrl:  "https://api.zaim.net/v2/auth/access"
    )
    
    self.oauthswift = oauthswift
    let _ = oauthswift.authorize(
      withCallbackURL: URL(string: "zaimanalyst://oauth-callback")!,
      success: { credential, response, parameters in
        print(credential.oauthToken)
        print(credential.oauthTokenSecret)
    },
      failure: { error in
        print(error.description)
    }
    )
  }
  
}

動作確認

アプリを立ち上げてボタンをタップすると、以下のような認証画面に移るので、許可する。

認証が完了して、コールバック経由でアクセスキーが取得できる。

参考

3年目プログラマが参考にしたQiita記事まとめ⑯

概要

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ16本目

Qiitaまとめシリーズ

一つ上のチームメンバーのそだてかた

コーチングは将来役立つものだろうし覚えておくとして、エンジニアのレベルの評価方法は参考になった。紙に書いた適当なスキルシートとか、面談通して口頭でエンジニアのレベルを測れるはずがない。やっぱりエンジニアに求められるのは何よりアウトプット。あとはGithub見るとか?

Macでより単純作業をスピーディにするために工夫していること

Macのフリーソフトは、単純作業を少しだけ強化するためのモノが多い印象。元々使ってたツールやテクニックも多かったけど、意外と「これ良さそうだぞ」というのもチラホラあったので、時間を見つけてじっくり強化したい。シェアウェアは即戦力級のツールが多いからお金を払う選択も重要だけどね。

先人達から学ぶRailsのテーブル設計

調べたのはスゴイけど、結果は概ね予想通りといった印象。やっぱり1テーブルのカラム数は6,7に抑えたいね。使用頻度の低い(Nullになりやすい)列は、別にテーブル切ったり、KeyValueなテーブル作ったりで対応したほうが良いと思う。ただRailsだとSTIも多くなってくるから、必然的に列数も増えてくるだろうしこの集計がどのぐらい正確かは怪しい。

エンジニアでも知っておきたい実装時のデザインのこと

確かにこの辺り何も考えずに実装して、予期せぬデータが来た時にレイアウトがボロボロになる現象はよくある。もう少しデザインを精査して実装しないと、技術的負債と抱えることになるので気をつけよう。特に挿入されるデータが想定の範囲外だった場合の振る舞いについては意識しないと。

EcmaScriptの個人的に気になる新機能提案

こういうのもチェックする人はエンジニアとして上のレベルに居ると思う。記事内だとパイプライン演算子は是非とも欲しいね。JavaScriptでも関数型な実装をもっと強化したい。

こんな私でも Vim が好きと言いたい

「びっくりするほどシンプル」と自称してるけど、それでも初心者には敷居が高く見える。自分は最初半年ほどはvimrcを一切弄らずにvimを使ってきたからかな。

シェルスクリプトを何万倍も遅くしないためには —— ループせずフィルタしよう

シェルスクリプトのコマンドは1コマンド1プロセスだから、ループ内でコマンド実行せずに、複数行入力に対してパイプで1コマンドに投げようという話。そもそもそんな入り組んだロジック書くならスクリプト言語を素直に使ったほうが良いのでは。(シェル芸人は除く)

勘違いして定時前に帰ってしまったので再発防止策を考えてみた

稀によくある。
記事中に登場したTampermonkey、便利そうだ。任意のユーザスクリプトを特定のURLで実行してくれるブラウザ拡張機能。当然Chromeのもあるので、何か思いついたけど拡張作るほどじゃないって時には捗るかな。チャットワークやBacklogで使えるネタを考えよう。

昭和以降の全横綱データをスクレイプしてサバイバル分析にかけたら、突っ張り横綱は短命なのがわかった。

面白い。プログラミングせずにデータ可視化ツールだけでここまで見れるんだね。

ReactにするかVue.jsにするか、jQueryだけ触っていたエンジニアがサンプル作って比較してみた

良比較。ReactとVue両方共、趣味/実務両方で使ったけど、個人的には総合的にやっぱりVueかなぁ。記事では大規模になったらReactって結論出してるけど、多分ReactならRedux、VueならVuexを使えばそんなに変わらないと思う。トレンドはReactが安定して高くて、Vueは最近急上昇中という感じ。好みの問題になってくるけどやっぱりVueかな。

[Ruby] モジュール(module) 入門

概要

Rubyのモジュール(module)を何となく使ってきたので、基礎を振り返りつつ、ざっくばらんにコード例を掲載する。詳しい説明は省略するので必要に応じて各自で調べるものとする。

前提

以下環境で動作確認済み

debian 9.3
ruby 2.4.1

moduleとは

Rubyにおけるモジュールは、Moduleクラスのインスタンスでうんたらであるが、ここではクラスと同じように変数やメソッドを持ってる名前空間ぐらいの認識から始める。

module MyModule
end

みたいに定義できる。

モジュールはクラスと違い

  • インスタンスを生成できない
  • 継承ができない

などの特徴がある。インスタンス作れない、継承できないでどうやって使うのよという疑問は後々。

moduleを入れ子にする

module Constant
  module User
    module Status
      INVALID = 0
      VALID   = 1
    end
  end
end

p Constant::User::Status::VALID # 1

のように、moduleを入れ子にすることで、名前空間の階層化ができる。これによって階層的な定数の管理とかがしやすくなる。

モジュールに特異メソッドを実装する

module MyModule
  def self.say_hello
    p 'Hello'
  end
end

MyModule::say_hello # Hello

のように、クラスのクラスメソッドみたいな書き方でメソッドを定義すると、モジュールの特異メソッドとして利用できるようになる。クラスに属さない汎用的なロジックとか定義すると捗る。

特異メソッドはmodule_functionメソッドで定義することも出来る。こっちのほうが一般的かも。

module MyModule
  def say_hello
    p 'Hello'
  end
  module_function :say_hello
end

MyModule::say_hello # Hello

モジュールをクラスにmixinする

モジュールはインスタンスを生成できないけど、クラスにインクルードする(mixinする)ことはできる。

module MyModule
  def say_hello
    p "Hello"
  end
end

class MyClass
  include MyModule
end

MyClass.new.say_hello # Hello

クラスにモジュールをincludeすると、モジュールのメソッドがあたかもクラスのインスタンスメソッドであるかのように利用できる。

Rubyはクラスの多重継承を行うことができないが、includeは複数のモジュールに対して行えるので、一つのクラスに複数の機能を取り込むような使い方ができる。

module FooModule
  def say_foo
    p 'Foo!!'
  end
end

module BarModule
  def say_bar
    p 'Bar!!'
  end
end

class MyClass
  include FooModule
  include BarModule
end

obj = MyClass.new
obj.say_foo # Foo!!
obj.say_bar # Bar!!

逆に、一つのモジュールを複数のクラスでincludeすることもできるので、ある共通の機能を複数のクラスに持たせることができる。

module Printable
  def print_info
    p "this class is #{self.class}"
  end
end

class User
  include Printable
end

class Post
  include Printable
end

User.new.print_info # this class is User
Post.new.print_info # this class is Post

クラスをモジュールでextendする

includeでは、モジュールのメソッドをクラスのインスタンスメソッドにすることができた。

今度はextendを使うことで、モジュールのメソッドをクラスのクラスメソッドにすることができる。

module MyModule
  def say_hello
    p "Hello!!"
  end
end

class MyClass
  extend MyModule
end

MyClass.say_hello # Hello!!

mixin(include,extend)の継承

クラスの継承時に、親クラスのmixin(include,extend)はそのまま引き継がれる

module IncludeMyModule
  def print_class
    p "this class is #{self.class}"
  end
end

module ExtendMyModule
  def say_hello
    p "Hello!!"
  end
end

class ParentClass
  include IncludeMyModule
  extend  ExtendMyModule
end

class ChildClass < ParentClass
end

ParentClass.new.print_class # this class is ParentClass
ChildClass.new.print_class  # this class is ChildClass

ParentClass.say_hello # Hello!!
ChildClass.say_hello  # Hello!!

3年目プログラマが参考にしたQiita記事まとめ⑮

概要

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ15本目

Qiitaまとめシリーズ

PHPを使いもせずDISってる君達へ

PHPの擁護記事かと思ったらボロクソ行ってて笑えた。と同時に、PHPのドハマリしそうなポイントを抑えることができた。

なぜ仮想DOMという概念が俺達の魂を震えさせるのか

Reactを必死に勉強してた頃に目を通して意味わからなかったけど、今ならそれなりに理解できる。何でReactがここまで成り上がったか、やっぱり仮想DOMの影響が大きいんだと言うことがわかった。今はReactよりVueのほうが使ってるけど、Vueも仮想DOMなのでこの記事の内容はそのまま使うことができる。

ハッシュをソートしてハッシュで返す(Ruby)

痒いところに手が届いた。ハッシュは本来順番を持たない概念だからこういうことをやろうとするのがミスだと思うけど、今のRubyのハッシュは順序をしっかり持ってるので捗る。

フロントエンドエンジニアが暇なときにやると良いかもしれないこと

情報収集が受け見ガチなのでより能動的に情報拾いに行きたいね。少なくとも言われたから調べるとかは辞めたい。

カオスになりがちなCSSと向き合ってみた

あるある。スタイルをABC順で統一するの良いなぁ。自動化できると尚良いけど、組織レベルでやるとしたら何らかの気風が必要そう。ビルドツールでまとめて行えるのが一番いいけど。

最近Webサイトやアプリを使ってイラッとしたUI/UX

SPAはこれが難しいなぁ。しっかりエラー対応付けないと、ブラウザレベルでユーザにエラーの報告してくれないからわけわかんない感じになる。

pry-byebugでrubyをデバッグする

この記事読んでpryデビューした。ずっと素直にirb使ってきたけど、pryは素で便利。もっと早く乗り換えておけばよかった。

[Vue.js] フォームの多重送信を防止する

防止用のボタンをコンポーネントで切り出す考えは良いな。これは率先して使っていきたい。

一つ上のチームメンバーのそだてかた

コーチングは将来役立つものだろうし覚えておくとして、エンジニアのレベルの評価方法は参考になった。紙に書いた適当なスキルシートとか、面談通して口頭でエンジニアのレベルを測れるはずがない。やっぱりエンジニアに求められるのは何よりアウトプット。

テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話

テストもだけどレビューに関しても結構振れられててソッチのほうが参考になったりした。

今までのレビュー目的は「バグを減らすため」でしたが、再整理の結果、「知識共有と可読性の検査」へと変わりました。

人のコードを積極的に読まないと知識は偏るし、人に読ませるようにコードを書かないと保守性の悪いコードが生まれる。互いにもっとコードを読み合うような仕組みが合ってしかるべきなんだけど。

今回は、自動テストの狙いを「開発速度を上げること」に絞り、手動動作確認よりも自動テストの方が素早く確認できる箇所にのみ自動テストを導入することに決めました。

誤解されがちだけど、自動テストはコードの品質を高めるとかじゃなく(それもあるけど) 最終的な開発速度を上げることが目的。長期的な視点の場合、テストを書くことで工数が増えるというよりはテストを書くことで工数が減るはず。まともな設計がある前提だろうけど。

まぁ自動テストにしろコードレビューにしろ、コードは疎結合に書こうねというのは共通してる。