Freelance Orgsin Official Site

ごゆっくりしていって下さい

今まで使っていた全ディスプレイをEIZOに変えたらパフォーマンス上がった気がする

今まで

ディスプレイサイズ21〜27インチの2〜3万円のものを使用していた.

正直,画素数も低いし,細かい部分で粗い画像が気になっていた.さらに,どうしてもケーブル類が増えすぎて机がごちゃついていた.

今回

FlexScan EV2785 | EIZO を2枚購入.4Kモデル.

http://www.eizo.co.jp/products/lcd/ev2785/

現在の構成.MacBook ProにEIZO2枚,iPad,iPhone,Androidで開発をしている.ディスプレイをすべてEIZOに変えた.

MacBook Proはデスクトップが壊れたときのメインPC.EIZO2枚は27インチ.iPad,iPhone,Androidはローカルで立ち上げたサーバにアクセスしたり,ネイティブのテストをしている.スマフォやタブレットとMacBook ProはWifiでつながっている.

感想

正直,これに変えただけで開発時のストレスはかなり減少した.

というのも,働き方は完全にリモートワークではあるものの,けっこう外出してレンタルオフィスやコワーキングスペースやカフェなどで仕事をしに行くことも多いので,その際にMacBook Proの電源がケーブル2本抜くだけで済むのだ.

今までは,まず電源ケーブルを抜いて,ディスプレイのUSB Type-Cケーブル互換をMacから抜いて,USB Type-Cケーブル互換をディスプレイ側も抜いて,PCケースにしまう手間があったがそれがまず解消された.さらに目に優しいため,長時間プログラミングすることが可能になった.さらにフレームレスは少しの差ではあるが,その差が開発時には非常にでかい.結局Terminalを縮小して使っていたが,そのピントを0.25ぐらいは上げてもよいぐらい.これがどれだけ大きなメリットかは開発していたらわかると思う.でかいディスプレイ,要は30インチ以上を買う必要がないということは机の省スペース化にもつながる.机はイケアの3万ぐらいのけっこうでかめのやつ.

利点

  • 各ディスプレイに付きケーブルが1つ
  • 充電もディスプレイから取れる

EIZO EV2785はMacBook ProのようなUSB Type-Cと相性がよく,各ディスプレイに付きケーブルが1つで済んでしまう.さらにMacBook Proの充電器もディスプレイから取れるため必要ない.

対象のPC

MacノートPCだけでなくWindowsノートPCにも対応しているので素晴らしい.

http://www.eizo.co.jp/support/compati/others/usb-type-c/EV2785_USB-Type-C-compatibility.pdf

4K解像度

綺麗.

省スペース

前はiiyamaのモニターを使っていたが,同様の27インチなのにより広く机を使える

フレームレス

画面いっぱいまで広がる液晶は,もはや背景と一体化しているレベル

他にも

  • ノングレア,ブルーライトカット,ちらつきなしのため目に優しい
  • 複数のPCを一つのディスプレイに表示可能
  • 5年間保証
  • 自動で彩度変更

欠点

しいてあげるなら,ソフトがMacに対応していないこと.こういうところはWindowsに軍配が上がる.

www.eizo.co.jp

Active Admin で Active Storage S3 保存の画像を表示させる

環境

  • Ruby 2.5.1
  • Rails 5.2

S3 の画像を表示と書いたが,他のストレージでも特に違いはないと思われる.イメージしやすいようにS3と表記した.

Gem

github.com

railsguides.jp

paperclipからの移行はこちらにメモった

www.orgsin.com

Active Admin

初期設定

# Gemfile
gem 'activeadmin'
# bash
rails g active_admin:install
rake db:migrate
# rails console などでAdminUserを作っておく
AdminUser.create(
  email: 'hogehoge@example.com', password: 'password'
)

http://localhost:3000/admin/dashboard にアクセスしてログイン.

特定のモデルをAdminに紐付ける

今回はTwitterサービスを開発していたので,既に存在するツイート用のモデルと紐付けた.

rails g active_admin:resource Tweet
# 例:ツイートのモデル
  create_table "tweets", force: :cascade do |t|
    t.string "tweet_id", null: false
    t.string "screen_name", null: false
    t.integer "followers_count", default: 0, null: false
    t.integer "friends_count", default: 0, null: false
    t.text "posted_text", default: "", null: false
    t.text "hashtags", default: "", null: false
    t.datetime "posted_at", null: false
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["screen_name"], name: "index_tweets_on_screen_name"
    t.index ["tweet_id"], name: "index_tweets_on_tweet_id", unique: true
  end

↑の例だと, app/admin/tweets.rb という場所にファイルが作られるのでそのファイルに表示させたいものを変更していく.

  show do |t|
    if t.image.attached?

      # ここで画像を表示させている
      attributes_table do
        row :image do |i|
          image_tag url_for(i.image)
        end
      end

      # 実際にどのデータが入っているか見たかったのでAttachmentとBlobも表示させているが本来必要ない
      panel 'image details' do
        column_rel = ->(v) { column v.to_sym }
        table_for t.image_attachment do
          ActiveStorageAttachment.column_names.map &column_rel
        end
        table_for t.image_attachment.blob do
          ActiveStorageBlob.column_names.map &column_rel
        end
      end
    end
  end

記法がよくわからなかった

github.com

このGemで表示させているので,このドキュメントを見るのが早かった.

パーシャルで共通化したものを表示させることもできる

paperclip から active storage へ移行する

経緯

paperclipは超有名なものだが,Rails5.2からはActiveStorageを推奨される.ちょうど5.2に上げたのでこの際マイグレーションしてしまおうという話.

非推奨記事

ちょうどのタイミングではてブに上がってた.

robots.thoughtbot.com

ActiveStorage

かなりわかりやすいのでガイドも貼っておく.

railsguides.jp

マイグレーション

Apply the ActiveStorage database migrations.
Configure storage.
Copy the database data over.
Copy the files over.
Update your tests.
Update your views.
Update your controllers.
Update your models.

github.com

基本的には,この手順通りで良いがそのままやってもうまくいかないので注意点を書いておく.移行タスクがまたあった時に最短でできるので.

前提

移行が完了するまでpaperclip関連のカラムを消してはいけない.


So, assuming you want to leave the files in the exact same place, this is your migration. Otherwise, see the next section first and modify the migration to taste.

マイグレーションタスクをそのままコピっても動かないのでその部分をメモしておく

postgresなのかmariadbなのかsqliteなのか

最後にinsertされたレコードを取得するための関数が変わる.

class ConvertToActiveStorage < ActiveRecord::Migration[5.2]
  def up
    # postgres
    get_blob_id = 'LASTVAL()'
    # mariadb
    # get_blob_id = 'LAST_INSERT_ID()'
    # sqlite
    # get_blob_id = 'LAST_INSERT_ROWID()'
paperclipで利用していたモデルのデータを取得しているだけ

attachされずnilのレコードがある場合はここでnilチェックをした方が良いかもしれない.デフォルトURLの設定によっては,エラーになるかもしれない. とは言え,普通はinsertのタイミングでレコードが作られるような場面が多いと思われるのでさほど重要ではない.

        model.find_each.each do |instance|
          next if instance.try(:image_file_name).nil?

          attachments.each do |attachment|            
〜〜〜〜〜
単純にローカルかリモートかで使い分ける
  def checksum(attachment)
    # ローカルはこっち
    url = attachment.path
    Digest::MD5.base64digest(File.read(url))

    # S3とかはこっち
    # url = attachment.url
    # Digest::MD5.base64digest(Net::HTTP.get(URI(url)))
  end

画像の指す場所はpaperclip と activestorageで違うので注意した方がよい.
# ローカル
ActiveStorageAttachment.find_each do |attachment|
  name = attachment.name

  source = attachment.record.send(name).path
  dest_dir = File.join(
    "storage",
    attachment.blob.key.first(2),
    attachment.blob.key.first(4).last(2))
  dest = File.join(dest_dir, attachment.blob.key)

  FileUtils.mkdir_p(dest_dir)
  puts "Moving #{source} to #{dest}"
  FileUtils.cp(source, dest)
end
# S3
  ActiveStorageAttachment.find_each do |attachment|
    source = attachment.record.send(name).try(:path)
    next if source.nil?

    dest = attachment.blob.key

    bucket = 'hogehoge' # 自分のバケット
    region = 'ap-northeast-1' # リージョン

    client = Aws::S3::Client.new(region: region, access_key_id: ENV.fetch('AWS_ACCESS_KEY_ID'), secret_access_key: ENV.fetch('AWS_SECRET_ACCESS_KEY'))
    puts "Moving #{bucket}#{source} to #{dest}"
    client.copy_object(bucket: bucket, copy_source: "#{bucket}#{source}", key: dest)
  end
もしpaperclipのデータをDBから消しちゃった場合

事前にS3からpaperclipのハッシュキーを取得しておかないといけない.以下は適当に書いているが,キーと拡張子だけ取得しておくなどして↑のタスクのsourceと入れ替える処理にするなどして対応するとか.

client = Aws::S3::Client.new(region: 'ap-northeast-1', access_key_id: ENV.fetch('AWS_ACCESS_KEY_ID'), secret_access_key: ENV.fetch('AWS_SECRET_ACCESS_KEY'))
client.list_buckets.buckets.map(&:name) # 必要なバケットを探す
contents = client.list_objects(bucket: 'hogehoge').contents
keys = contents.map { |v| v =~ /tweets\/images\/([0-9]*)\/original\/(.+)(\.)(png|jpg|jpeg)/; {"#{$1.to_i}": "#{$2}#{$3}#{$4}"} if $1 }
keys.compact.reject(&:empty?).inject(&:merge)

一旦DBのデータ移行がうまくいったかどうかは確認した方が良い.

rails c
> a = User.first.image.attachment
> a.blob

技術系の情報収集

僕のローテーションの話だが,朝起きてスマフォで見て,仕事を開始したらまたサイトを見る.昼食中にまたスマフォで見る.夜仕事終わりがけにまた見る.

スケジュール

時間帯 端末 主なサイト
8時頃 スマフォ MITTR
11時頃 PC はてなブックマーク,Hacker News
13時頃 スマフォ Twitter
18時頃 PC Hacker News

HNはけっこう情報が変化するので朝と夜に見るようにしている.Twitterというのは,結構色んなサイトを迂回するのでTwitterでまとめているだけ.昔はいろんなサイトを追っていたけど,結局これに落ち着いてからかなり安定していると思う.

注意点としては,この見ているのはあくまでも開発とは直接関係ないものに限られる.例えば,自分が仕事で使う言語の更新情報などは当然毎日見るが,そのようなものを書き出すとキリがないので,書いてない.

【Ruby】モジュール(Module)のインクルード(Include)しないメソッドの呼び方

Moduleに存在するメソッドの分類

Moduleに定義したメソッドを任意のクラスのメソッドからインクルードをせず呼び出す方法を書いておきます(使うタイミングはあまりないですが)

結論から書くとinstance_methodをBindすることでほとんどのメソッドを呼び出せます.

と言いながら,それ以外の呼び方もあるのでタイプ毎に分けました.

Moduleの直下にそのままメソッド定義

最もポピュラーのメソッド定義ではないでしょうか.

module A
  def hoge
    'hoge'
  end
end
区分け
  1. instance_method
  2. public_instance_method
# 1
A.instance_method(:hoge).bind('').call
# 2
A.public_instance_method(:hoge).bind('').call

self使う

シングルトンでpublicなメソッドを作り出す.やり方が二通りある.

module A
  def self.hogehoge
    'hogehoge'
  end
end

module A
  class << self
    def hogehoge
      'hogehoge'
    end
  end
end
区分け
  1. singleton_method
  2. public_method
# 1
A.singleton_method(:hogehoge).call
# 2
A.public_method(:hogehoge).call
A.hogehoge

module_function

privateなインスタンスメソッドも作り出す.

module A
  module_function

  def fuga
    'fuga'
  end
end
区分け
  1. private_instance_method
  2. singleton_method
  3. public_method
# 1
A.instance_method(:fuga).bind('').call
# 2
A.singleton_method(:fuga).call
# 3
A.public_method(:fuga).call
A.fuga

Moduleにインスタンスメソッド定義

module A
  extend self

  def piyo
    'piyo'
  end
end
区分け
  1. instance_method
  2. public_instance_method
  3. public_method
  4. singleton_method
# 1
A.instance_method(:piyo).bind('').call
# 2
A.public_instance_method(:piyo).bind('').call
# 3
A.piyo

Moduleにprivateメソッド定義

module A
  private
  def foo
    'foo'
  end
end
区分け
  • private_instance_method
A.instance_method(:foo).bind('').call

Moduleにprivate特異メソッド定義

module A
  module_function

  def bar
    'bar'
  end
  private_class_method :bar
end
区分け
  • private_instance_method
  • private_method
A.instance_method(:bar).bind('').call

最後に

ミスっているところがあるかもしれません.その時は教えていただけると助かります.すぐに修正します.

2018年の目標

2018年

戌年.そして自分にとってもキリの良い年.

達成したいこと

インプット
  • 英語論文(AI系)を12本以上読むこと
  • テーマの情報を足でも収集すること
    • 実際に赴く
アウトプット
  • 新しい技術を実際に自分のサービスに組み込む.以下は例,論文読むとまたちゃんとしたジャンルに絞れるかも.
    • AI系
    • AR/VR
    • 暗号通貨
ビジネス
  • 事業を大きくすること
    • 具体的には,自分の働くウェイトをシフトさせ,サービスに稼いでもらうように
  • 請負案件を増やし,常駐案件を削減すること
    • 現在は請負2:常駐5 → 今年は請負4:常駐3へ
  • パッケージソフトウェアの種類を増やす
    • 自分が常に働いているという状態を減らすことが重要 → これができないと破滅する
  • 起業を視野に入れること
  • 投資
    • アンテナを張る → 実際にこれ以上新しい投資先が見つからなくても情勢把握は大切

今年必ず達成しなくてはならないこと

自分が常に働いているという状態を減らす

なぜかというと,働く==金を得るため,という方程式が成り立つからだ.我々技術者にとって,大切なことは探究心・好奇心を絶やすことなく,常に新しい技術を追い求め,検証し,アイデアに繋げ,可能性を生み出すことであるが,そんなことは言うまでもない.

ただし,上記の事を働く中で達成し続けるのは非常に困難である.それは,利益の追求がレールの先にあるかどうか中々見えないからだ.当然,ビジネスをする上で利益を出すことだけが重要ではないが,エンドユーザのためのUI/UXであれ,利便性の高い仕組みや高度な技術を提供することであれ,利益が発生しないのなら誰も金を出そうとはしない.

私は技術より,科学の方向へ指針を持ちたいという気持ちが強いらしいが,大学院の頃それをはき違えておりそのような素直に技術というより科学,という考えに至れず博士課程に進むことは断念したのだが,今なら分かる.結局技術者といいながら,科学への道を諦めきれないという葛藤を常に抱えており,それが原因だとわかった.

そのため,科学研究を続けるためには,働くだけでは難しいのだ.数多くの技術探索を続けるだけでなく,科学研究も引き続きやっていきたい.今年は,そのウェイトを増やしていくことが大切.

つまり「 自分が常に働いているという状態を減らす 」である.

本心では,働きたくないというわけではない.ただ,このまま働いてfiatに利確し続けたと思っていても,それは利確なのか損切りなのかもはや判断がつかないほどやりたいことへのフラストレーションが増大してしまう気がしている.これではストレスで精神的におかしくなってしまう可能性も高い.それを防ぐためには,2018年という年を無駄に過ごしてはならない.春.春が限界だと思っている.それを過ぎてなおそのような働き方をしているのであれば,もう決して科学という戯言を宣うべきではない.

なぜ,自分が本当にやりたいことを捨てることができるのか?そんな生き方は生き様として最悪である.誰に何と言われようと,自分の道を誤ってはいけない.

2019年に,この記事を見て,私は笑っていられるだろうか.そう思いながら記録として残しておく.

iPad Pro で ソフトウェアの開発はできるのか

目的

ソフトウェアの開発を外で手軽にしたい.長時間ならばMacBook Proを使用すれば事足りるが,毎日の通勤電車の中だったりランチの約1時間中に開発をするといった個人的な目的を達成するためにはやや重量に限界を感じる.

メイン開発端末スペック

  • MacBook Pro
    • 13インチ
    • 2.4 GHz Intel Core i7
    • 16 GB 1867 MHz LPDDR3

「Macを買うなら…」でおなじみの、秋葉館オンラインショップ
もちろん話題のiPodも本体を含め関連商品充実!

重さ

MacBook Proは,13インチでも「1.58kg」これってどれだけ重いかって言うと,例えば八百屋さんに行き.そこで焼きそばの材料買うとすると同じぐらいの重さになる.キャベツ1玉と人参,もやし,麺ね,ここらへんをスーパーの袋に入れたものを持ってると想像するとわかるけど,軽くランチに出かける時に持ち歩くような重量ではないことが分かる.

ここでiPad Proに白羽の矢が立ったわけです.10インチに関して,これの重さって言うと,500mlのコカ・コーラより軽い.コンビニでちょっとペットボトル買うことって多いのだが,それより軽いっていうのは非常に安心感がある.ランチの時に持ち運んでも違和感がないぐらい軽い.

www.apple.com

今回はApple製品だけを考えているが,持ち運びという意味ではSurface Proもあるが,これの重さはキーボードとかを付けるとMacBook Proと重さがほぼ変わらない.それならWindows限定の作業じゃない限りMacBook Proを使う.

できること

何ができるかってのを考えると,以下である.ちなみにiPhoneでもストレスなくできそうなものは省いた(メールやチャットなど)

  • 書類編集
    • ワード編集
    • エクセル編集
    • パワポ編集
  • 画像編集
    • 要件を考える時に図を書いたりする
    • 絵を書いて頭をクリアにする
    • クライアントへ説明する時にすぐ絵をかける
    • アイコンやデザインをさっと少し修正する
  • プログラミング
    • HTML/CSS/JSや簡単なプログラムであればWebのサービスを使ったり代用できるアプリを使用すれば可能
  • その他
    • MacBook Proをデュアルディスプレイにできる(※別の使用法)

実装やインフラ作業をすることは難しいが,それ以外の工程であれば作業できそうだ.

また,最後のデュアルディスプレイというのは長時間作業をするときにも力を発揮できそうだと思いこれは別件で記載.重量が2kgちかくなるというのはきついが,ガッツリやるときならあり.