すーてっく

技術的なことや日常などを軽く書いていきます。

Magic Trackpad2を買ってみた

2019/08/31 f:id:su-uu:20190901183150j:plain

購入のキッカケ

 ずっと前からノートPCについてるタッチパッドがとても好きで、デスクトップPCでも使いたいなーと思っていた。 でも、単品のタッチパッドが存在してる事をしらなかった。 一時期は、iPad ProにMobile Mouseのアプリを入れてそれっぽいこともした。 しかし、結構ラグが多かったり、うまく動いてくれなかったりすることが多く満足のいく結果にはならなかった。

 そんな中で、エンジニアの先輩がMagic Trackpadを使ってるのを見て、タッチパッドが存在していることを知った。
知ってしまったら買うしかない…

WIndowsでの利用

残念ながらメインのデスクトップPCもノートPCもApple製品のMacではない… しかし

  • 今後Macを購入予定である。
  • Apple製品のデザインが好き
  • WIndowsでも利用できるようにするソフトウェアが存在している。

の理由からAppleのMagic Trackpad2にした。

Mac製品を買うまでは、Windowsで利用していく予定。

使用感

他のタッチパッドデバイバスと比べたわけではないので悪しからず。

どこでもクリックできる

タッチパッドって右下、左下だけクリックできるのが普通だと思う。 しかしMagic Trackpad2は、4か所に感圧センサーがあり、表面のどこでもクリックできる。 ドラッグ操作したかったら、親指で左下を押しながら、人差し指で移動する操作になる。 物によっては、押し込み動作が重くこの動作が結構負担になる。 それが解決する。

そうMagic Trackpad2ならね。

ドラッグしたい点でクリックし、押したままドラッグできる。 クリックも軽いから、押したまま移動するのも負担にはならない。 もちろん、別途親指で押すこともできる。

押し込みが軽い

多くのタッチパッドを使ってきたわけでは無いが、ノートPCについてるタッチパッドは、クリックが重い印象がある。 1~2時間の使用なら気にならないが、6~8時間となると指がつかれる。 表面のどこでもクリックできるのと重なって、押す場所によって押しこみが重くなることがない。 (下部押し込みだと中心付近は重くなるよね)

滑りがよい

たまに、タッチパッドのくせに滑りが悪い製品があるがそんなことは無かった。 分厚いガラスを触っている感覚。

軽い

電池ではなく、バッテリー駆動なので電池の重さがない。 マウスとかなんでも電池が入るだけでかなり重くなる印象。 あまり移動しない利用方法なら意味は無いかもしれない。 自分は、持ち運ぶ予定なので利点。

広い

ノートPCのタッチパッドと比べると広い。 (当然といえば当然だが) 細かくちょくちょく移動せずに、一度に大きく移動できる。

総評

買って良かった。 後日、ソフトと組み合わせた使い方を紹介しようと思う。

GitHubからAzure Pipelinesで自動デプロイ

概要

最近GitHub Actionsがリリースされるとの情報が。自分もβに申し込んだけどまだ使えない… しかし、今CL/CDツールが必要になり、しょうがなくAzure Pipelinesを利用することにした。 今回は、その手順を書いていく。

ちなみにGitHub Actionsは2019/11/13リリース予定とのこと。

前提

  • すべての開発作業はGitHub上で行う。
  • テストは行わず、リリース作業のみ。
  • リリースは、FTP経由でサーバーにアップロードする。
  • リリース用ブランチに更新が入った場合に動作する。

注意点

自分の環境だと、ファイル名にマルチバイト文字を使用するとアップロード先にて文字化けが発生した。 普段からファイル名にマルチバイト文字は使用しないので、原因究明はしなかった。

GitHubリポジトリの設定

GitHubリポジトリの作成

今回はリポジトリ名は「AutoAzurePipelinesDeploy」にする。

f:id:su-uu:20190813183205p:plain
レポジトリ作成
入力したら「 Create repository」

テストファイル追加

テスト用に「index.html」を作成しておく。 f:id:su-uu:20190813183807p:plain ついでに「Releases」ブランチを作っておく。

とりあえずいったん放置。

Azure Pipelinesの設定

GitHubからGitHub Appsで直接Piplelinesを利用する方法もあるが、今回は利用せず、別にする。 理由としては、Azure ReposをGitHubのミラーリポジトリとして利用したかったから。 その説明は今回は省略する。

プロジェクトの作成

Microsoftアカウントでログインして右上からプロジェクトを作成する。 人によって違うので注意する。 f:id:su-uu:20190813183322p:plain

プロジェクト名は「AutoAzurePipelinesDeploy」。 他の設定は特にいじっていないが、「Version control」は「Git」を選択した。 今回の内容には直接関係しない。 f:id:su-uu:20190813183511p:plain

Pipelinesの作成

「Pipelines > Releases」を選択し、「New pipeline」をクリック。 f:id:su-uu:20190813184109p:plain

Select a templateは、Empty jobを選択。 f:id:su-uu:20190813184234p:plain

新しくpipelinesを作成できたら、「Add an artifact」から「Source type」をGitHubにする。 f:id:su-uu:20190813184513p:plain

serviceの「New」から接続先を設定する。 今回は、GitHub personal access tokenを利用する。

GitHub personal access tokenの生成

GitHubに戻り、「setting > Developer settings > Personal access tokens」から新規作成する。

コピーしておく。再表示できないので、注意すること。 f:id:su-uu:20190813185900p:plain

Pipelinesの設定

「Authorize with a GitHub personal access token」から先ほどのtokenを入力する。

f:id:su-uu:20190813190008p:plain

正しく入力できたら、GitHubリポジトリが選択できるようになるので各自にあった設定を行う。 今回は、

  • Souce:AutoAzurePipelinesDeploy
  • branch:releases
  • version:Lastest

他は、デフォルト値。 f:id:su-uu:20190813190154p:plain

トリガーの設定

artifactの右上の雷マークをクリックして、トリガーの設定をする。 f:id:su-uu:20190813192552p:plain

今回は、「releases」ブランチをトリガーに設定する。 f:id:su-uu:20190813192754p:plain

taskの設定

Copy files

タブメニューから「Tasks」を選択。 「Ajent job」に「Copy files」を追加する。 f:id:su-uu:20190813193024p:plain

「Copy files」の設定は以下のようにした。

  • Source:先ほどのGitHubリポジトリの設定値と同じ。右のメニューから選択すると楽。
  • Contents:どのファイルを選択するかの設定。とりあえずの設定。各自お好みで。
**
!**\.git\**
!**\.idea\**
!README.md
 !.gitignore
  • Target:
$(Build.ArtifactStagingDirectory)\deploy

f:id:su-uu:20190813193110p:plain

FTP upload

次にFTPアップロードの設定を行う。 「DTP upload」のTaskを追加する。 f:id:su-uu:20190813194842p:plain

FTPの設定は以下の通りにした。 ここは個人差がかなりでるので各自自分にあった設定を。

自分は、 Advancedの

  • Delete remote directory
  • Overwrite
  • Preserve file paths

の三つのチェックを入れた。

f:id:su-uu:20190813195432p:plain

テストリリース

ここまでできたら。pipelineの保存を行い、実際に実行してみる。

右上の「Create release」から実行する。 特に設定変更はしない。 f:id:su-uu:20190813200220p:plain

実行

実行中... f:id:su-uu:20190813200302p:plain

正常に終了したら「Succeeded」と表示される。 もしエラーが発生した場合は、詳細なログを見ることができるので、そこから原因を探す。 f:id:su-uu:20190813200435p:plain

実際にWebページを開いてみる。 正常に表示されている。 f:id:su-uu:20190813200635p:plain

更新

ファイルを書き換えて

f:id:su-uu:20190813200746p:plain

Mergeして

f:id:su-uu:20190813200828p:plain

実行される

今回は2回目なので「Release-2」となっている。 f:id:su-uu:20190813200910p:plain

確認

f:id:su-uu:20190813200953p:plain

おわり

これで、ファイルアップロード作業からは開放される。 今回は、アップロードだけだが、テストだったり、もっと複雑な処理もすることが出来るので興味がある人は色々触ってみると良いかも。

Googleには入社できません

できません

最近「○○に入社しました」や、「○○に転職しました」というのが流行っている?ので、流れに乗りました。
しかし自分は、学生で入社、転職はもう少し先。 そこでエンジニアとしては、最高峰の一つであるGoogleを一つの目安として、自分がGoogle社を受けても落とされるだけという仮説を立て、今の自分に何が足りないのかを考えてみる。内容については、過去に色々な人が出した入社エントリの話から推測する。

英語

まず、圧倒的英語力不足。。
1年生のころに受けたTOEIC IPテストは350点くらいだった。絶望的だ… 加えてTOEICはListening&Readingであり、会話とは全然違う。 加えて専門用語も入ってくるとなると全然足りない。日本語でのコミュニケーションすら危ういのに英語でコミュニケーションとれるハズがない。 英語のリスニングだけでも頑張ろうと思ったけど、続かなかった。 よく英語のリファレンスを利用するが、Google翻訳や辞書を多用しながらのリーディングであり、スラスラとは読めない。

できない理由としては、まず単語力不足があげられる。単語を知らないから聞いても、見ても内容を把握することができない。単語をひたすら覚えるしかない。IT系の用語は元が英語ベースなのもあり覚えやすいところだけは感謝。

コーディング

どうやら、一般的なアルゴリズムとデータ構造の基本の問題がでるらしい。 講義にて一通りは学んだが、やはり基礎的な部分だけであり、コードに起こして利用するにはもう少し足りない。
最近競技プログラミング(AtCoder)を始めたが、C問題が解けるか解けないかレベルの弱者である。 他にもLeetCode - The World's Leading Online Programming Learning Platformというコーディング試験問題を解くことができるサービスもある。 最低でも、木構造グラフ理論、ソートやサーチも一通り理解し、コードに起こせるようになっておきたい。

直接は関係ないのかもしれないが、設計についても経験が足りない。どのような設計はよくないかなどの、失敗から学んだ経験が少ない。

経験

自分は、いわゆる実務経験はない。エンジニア関係の仕事はしてみたいと思いつつできなかった。 あくまで趣味での活動、独学となっている。 これといった研究成果もないので、大々的に発表できることは何もない。
社会から見れば、ただの学生がくだらないもの作りをしているだけである。 もう少し役に立つようなものを開発したい。

結論

圧倒的にすべてが足りない。最重要課題は"英語"。
加えて、自分はこれだけは負けないという分野を作りたい。 幅広く興味があるが故に、すべてが中途半端になっている感が否めない。 もう少し特定の技術について深掘りしていきたい。

参考

とりあえず関連記事を並べておくので興味があったらそちらもどうぞ。

ブログを書きたい

はじめに

ブログを書きたい。 ずっとそう思ってきた。 何度か挑戦したけど、途中でやめてしまう。 そしてまた、次のブログを始める…

今回は

今まで、辞めてしまう原因に
"一つの記事を書くのに時間をかけ過ぎる”
がある。今回からは、きちんと調べて書くべきことは、調べるけど基本的に

  • ”思ったこと”
  • ”考えたこと”

メインの軽い感じでやっていこうと思う。 もちろん適当な事を書いていきたい分けではない。

何を書くか

とりあえず

  • 日記のようなもの
  • コンピューター関係の話

にしていこうと思う。

当面の目標

  1. 見てもらおうと思わない
    皆に見てもらう為に書くのではない。あくまで自己満足にする。 ただの経験だ。
  2. とりあえず書く
    記事の内容は保証しない。 間違った事を書いたからと言って大きな問題になるわけでは無い。 書くときに疑問点を潰していく過程、を自分の経験にする。
  3. 自分が読み返せるようにする
    自分が読めないのに他の人が読める訳がない。 せっかく書くのだから、読みやすい物を書く。