今まで使っていた全ディスプレイをEIZOに変えたらパフォーマンス上がった気がする
今まで
ディスプレイサイズ21〜27インチの2〜3万円のものを使用していた.
正直,画素数も低いし,細かい部分で粗い画像が気になっていた.さらに,どうしてもケーブル類が増えすぎて机がごちゃついていた.
今回
FlexScan EV2785 | EIZO を2枚購入.4Kモデル.
EIZO FlexScan 27.0インチ ディスプレイモニター (4K UHD/IPSパネル/ノングレア/ブラック/USB Type-C搭載/5年間保証&無輝点保証) EV2785-BK
- 出版社/メーカー: EIZO
- 発売日: 2018/01/30
- メディア: Personal Computers
- この商品を含むブログを見る
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に軍配が上がる.
技術系の情報収集
僕のローテーションの話だが,朝起きてスマフォで見て,仕事を開始したらまたサイトを見る.昼食中にまたスマフォで見る.夜仕事終わりがけにまた見る.
スケジュール
時間帯 | 端末 | 主なサイト |
---|---|---|
8時頃 | スマフォ | MITTR |
11時頃 | PC | はてなブックマーク,Hacker News |
13時頃 | スマフォ | |
18時頃 | PC | Hacker News |
HNはけっこう情報が変化するので朝と夜に見るようにしている.Twitterというのは,結構色んなサイトを迂回するのでTwitterでまとめているだけ.昔はいろんなサイトを追っていたけど,結局これに落ち着いてからかなり安定していると思う.
注意点としては,この見ているのはあくまでも開発とは直接関係ないものに限られる.例えば,自分が仕事で使う言語の更新情報などは当然毎日見るが,そのようなものを書き出すとキリがないので,書いてない.
2018年の目標
2018年
戌年.そして自分にとってもキリの良い年.
達成したいこと
インプット
- 英語論文(AI系)を12本以上読むこと
- http://ainow.ai/category/scholar-ai/ 手っ取り早いのはこのサイトがヨサソウ
- 読んだ内容はまとめておく
- テーマの情報を足でも収集すること
- 実際に赴く
アウトプット
- 新しい技術を実際に自分のサービスに組み込む.以下は例,論文読むとまたちゃんとしたジャンルに絞れるかも.
- 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のコカ・コーラより軽い.コンビニでちょっとペットボトル買うことって多いのだが,それより軽いっていうのは非常に安心感がある.ランチの時に持ち運んでも違和感がないぐらい軽い.
今回はApple製品だけを考えているが,持ち運びという意味ではSurface Proもあるが,これの重さはキーボードとかを付けるとMacBook Proと重さがほぼ変わらない.それならWindows限定の作業じゃない限りMacBook Proを使う.
できること
何ができるかってのを考えると,以下である.ちなみにiPhoneでもストレスなくできそうなものは省いた(メールやチャットなど)
- 書類編集
- ワード編集
- エクセル編集
- パワポ編集
- 画像編集
- 要件を考える時に図を書いたりする
- 絵を書いて頭をクリアにする
- クライアントへ説明する時にすぐ絵をかける
- アイコンやデザインをさっと少し修正する
- プログラミング
- HTML/CSS/JSや簡単なプログラムであればWebのサービスを使ったり代用できるアプリを使用すれば可能
- その他
- MacBook Proをデュアルディスプレイにできる(※別の使用法)
実装やインフラ作業をすることは難しいが,それ以外の工程であれば作業できそうだ.
また,最後のデュアルディスプレイというのは長時間作業をするときにも力を発揮できそうだと思いこれは別件で記載.重量が2kgちかくなるというのはきついが,ガッツリやるときならあり.
朝の4:30に書いてしまうほど悩んでいる
物事はそんなに効率的にならない。そういうことを考えることが最近多い。
例えば、何か特定の技術の開発を請け負ったとして、それを自宅でガリガリとコード書いていても固いアーキテクトにならざるを得ないし、運用保守を無視した提案なんてできない。本来技術を向上させるためにプログラマとして仕事をしているわけなのだが、結局そうなっていないのが現実的な話。分かりやすくプログラミングだけの話で言えば、自分が目指す綺麗な書き方、イケてる書き方をしたくても中々そうはいかない、例えばrubyでメタプロを駆使したくてもそれは難しいように。それは、自分の開発したファイルの全てがexcludeすることなしにコードチェックでwarningが出なかったとしても同じことだ。コードレビューの時間がかかるんじゃないかとか現場のレベル感を考慮してコーディングするのは避けられないし、それを無視した仕事を金の対価として納品するわけにもいかない。
結局、ソロでプログラマ名乗っててもなんらかの組織に従属した形になってしまう実態があるし、そういう働き方をしなかったとしても、引き継ぎの時に面倒なことはなるべく省きたい。
というわけで、物事はそんなに効率的にならない。技術向上や、ソロでプログラマやる!みたいな心意気は大事だが、そんな簡単な話じゃない。
また、技術をアピールしていても、上には上がいるわけで恥ずかしい思いもしたくないというダサいプライドもなかなか捨てきれない。
なぜ、最近そこまで深く考えるかというと、本質的ではない忖度というものに振り回されることが多いためだ。人の信頼は大切だし、誰がプロジェクトの事実上のボスかということも分かっているから簡単に自分のスキルシートの見栄えだけの為に技術を行使した話を提案するわけにもいかない。
ゴールはみんなそれぞれ違うと思うが、自分が何をゴールと定めるのかをしっかりと見出してプログラマやってないと今後仕事なんてできないだろう。そんなことを朝の4:30に書いてしまうほど悩んでいる。
竜は、飛ぶ時に羽を必要としない。
割と空気が澄んでいた。ただ、少し肌寒く薄着で外に出てしまったのを後悔した。嫌な予感は常につきまとっていたが、まさか竜を飼うことになろうとは思いもしなかった。
少し歩いた丘の先で僕はのんびりと休憩していた。2人ぐらい座れる古ぼけたベンチに座りながら、ただただ時間を消費することを楽しんでいた。
そんな時、空を見上げると割と小さめなゴールデンレトリバーぐらいのサイズの竜がいた。竜と言えば、トレーラーより大きいサイズをイメージしていたが、これがリアルの竜なのかということを知った。それは、まさに漆黒のドラゴンと呼べるに等しかった。よく見ると、そんな竜は傷を負っていたし、他の人間たちに攻撃されていた。気づいたら僕はその竜の方向へ走っていた。僕は竜を助けることにして、その人間たちを言葉巧みに誘導して竜と引き離した。人間は、竜のことを神聖な生き物だと思っているため、なぜ攻撃しているのかも結局わからなかったが、僕は真っ先に竜を助けることを選んだ。
その後竜は、僕にお礼を言い、僕は仲良くなることで竜の背中に乗せてもらった。竜の背中は意外と捕まりやすくて安定していた。僕は何度も君は羽を広げなくていいのかい?と聞いた。どうやら竜は羽を広げずに飛ぶことができるらしい。羽は威嚇のためだけに使う、とそう教えてくれた。
僕たちは天上の崖と呼ばれる場所まで行き、そこの小屋でその竜を飼うことにした。竜は、なぜか僕のペットになることを決めたらしい。僕が困っている時には一緒に戦いたい、そう言った。
その少し前、僕と竜は天空で他の竜と交戦し勝利を収めていた。竜の炎は熱く敵の竜の鱗を溶かしていった。
その時も竜は、僕が一緒にいてくれると元気が出ると嬉しいことを言ってくれた。
この後のことはあまりに悲劇であり、僕も思い出したくもないのでここで幕を閉じることにする。
【AWS】サーバレス導入・基礎編(お名前ドットコム・SES・S3・CloudFront・Certification Manager)
当記事について
最近サーバレスの相談をよく受けることもあって,せっかくなので自分のサイトも簡単にサーバレス構成にしようと思い立った.
実際S3の独自ドメインは基本行うとしても,それをHTTPS化したり,CDN化したりといったところまでは業務以外ではやらなかったのでちょうど良い機会だった.
この記事は,サーバレスの基礎編.これに今後LambdaやCognito,DynamoDBとのRelayを入れていく.その記事はまた今度書くことにする.
構成図
構成は,お名前ドットコムで取得したドメインをSESを利用して,Certification Managerで申請したドメインで,HTTPS通信をしてCloudFrontでCDN化したS3の静的ページを表示させるというもの.
AWSの利用サービス
- S3: S3
- CloudFront: CF
- Certification Manager: CM
- SES: SES
- Route53(今回は,お名前ドットコムのドメイン設定で代用): R
手順
- R: 任意のドメインを購入する(例として,
example.com
を買ったとする) - SES: ドメインを登録する(us-east-1)(example.com)
- R: MX(example.com),TXT(_amazonses.example.com)レコードを登録する
dig example.com mx
- SES: Active Rule Setを設定する(us-east-1)→Verification statusがVerifiedになればMXレコードが正常に設定されている
- S3: メール受信用のバケットを作成し,IAMのポリシーを設定する(グローバル)
admin@example.com
などにメールが届くことを確認する- CM: ドメインのSSLを申請する(us-east-1)→s.example.comなどを登録する
- S3: 該当の場所へメールが届くので中身にあるURLにアクセスして承諾する.これは,
https://us-west-2.certificates.amazon.com/approvals?code={CODE}&context={CONTENT}
というURLになる. - S3: 新規でバケットを作成し(Certification Managerで定義したルールと同様の名前にする),何らかの静的ページを配置する.
- CF: 該当のバケットと,SSLを指定する
- R: CloudFrontのDomainNameをCNAMEで設定する
- CF: StatusがIn ProgressからDeployedに変わったら完了.結構時間がかかった.
dig example.com cname
※説明がわかりづらいのでもっと詳細について書いたほうがいいかも.
S3
注意点としては,一般的にS3をサイトとして公開する時のように Web Site Endpointを利用するとSSL通信ができない ということ.CNAMEをこのエンドポイントで設定するだけで,独自ドメインにできるため便利なのだが,思わぬ落とし穴であった.
公式が言っているので間違いないのだが,HTTPS化したいのならば通常のREST API エンドポイントにするしかない.
Amazon S3 バケットがウェブサイトエンドポイントとして構成されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を構成することはできません。
Amazon S3 はその構成で HTTPS 接続をサポートしていないためです。
こちらでも明記されている.
REST APIエンドポイントは以下にあるので参考にしたい. docs.aws.amazon.com
Certification Manager,CloudFront
CloudFrontはus-east-1などのSSLしか受け付けていないので,SSLも同様の場所で申請する必要がある.
また, S3は元々バケットとドメインがイコール でないと表示できないという制約があるため,CloudFrontでCDN化する時もその点に注意して作成する必要がある.
例えば,cf.example.comというドメインで表示させたいなら,S3のバケットもcf.example.comという名前で作成する.
さいごに
待ちが発生する事が多いため,手順をミスると大幅な時間がかかってしまうので注意.特に先に述べたWeb Site Endpointは使わないことや,S3は元々バケットとドメインがイコールであることには注意. 今回は単純なものであるが,普通に一般的なS3のサイトにも応用できそうだったのでまとめておく.料金がいくらかかったかは,また1ヶ月後にでも追記しようと思う.