ダッシュボタンで出退勤管理

こんばんは。

 

最近応用情報の勉強しているのですが、メリハリがなくなってきたため何か作ろうと思いました。

 

そこで、昔に流行ったダッシュボタンで何か作ろうと思いました。(個人的見解です笑)

 

前々からダッシュボタンで何か作りたいと思ってたんですよね。

 

そこで、タイトルにもあるとおり「出退勤」ボタンを作ろうと思いました。

 

なぜ、出退勤ボタンかというと、自分がこの学生生活中にいったいどれだけの時間を研究室に捧げたかを記録したいと思ったからです笑

 

さてアーキテクチャなんですけど、お風呂に入りながら思いつきで考えました。

 

f:id:k12si:20190329030715p:plain

GSSはGoogle Spread Sheetです。

API GatewayとLambdaはAWSです。(無料で使えるのかな?🤔)

S3とかDBとか使ってwebアプリケーションとしてグラフで可視化とかしてみたいけど、とりあえず(難しそうやし😂)GSSで作成していこう。

 

それではやっていきたいと思います。

 

今回は、とりあえずダッシュボタンでSlackに送信するといった挙動の確認を行いました。

 

以下のサイトを参考に作成しました。

Amazon Dash ButtonをただのIoTボタンとして使う - Qiita

 

またコードは以下のものを利用させていただきました。

GitHub - maddox/dasher: 🔘 A simple way to bridge your Amazon Dash buttons to HTTP services

なんか「このレポジトリはもう開発してないぜー!」的なことを言ってますが、とりあえずこれを元に作成していきたいと思います。

 

注意点としては、このリポジトリをクローンした後、npm iを忘れずに行うくらいです。

 

続いてSlackのWebhookを作成します。

 

結果は以下です。

f:id:k12si:20190329031825p:plain

 

とりあえず、無事にダッシュボタンで送信できました。

このSlack通知に関しては以前やったことがあったので比較的すんなりといけました。

 

というわけで、こんな感じで少しずつ作成していこうと思います。

 

それでは今日はこの辺で👋

応用情報技術者試験が難しい。。

1日サボってしまたのですが、頑張って学んだことをアプトプットしていこうと思います!

 

今日はH30年の秋の午後試験を解いたのですが、、個人的にめっちゃ難しかったです。

ちなみに、問題は以下に掲載されています。 

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2018h30_2/2018h30a_ap_pm_qs.pdf

 

今の所、情報セキュリティ、プログラミング、データベース、ネットワークの4つを解いたのですが、

 

全体で4割取れていないくらいです。笑

 

特にプログラミングとデータベースが個人的にとても難しかったです。

 

最新の問題なので現状解説をしているサイトが乏しく、今回はこういった問題出たっていうことを自分で忘れないための備忘録として記述します。

 

プログラミング(ウェーブレット木)

初めて耳にしました。

ウェーブレット木は、2分木探索手法の一つです。文字列内の文字の出現頻度を集計する場合などに用いられます。

例を用いて説明していきます。

まず、「CTCGAGAGTA」という4種類の文字列があったとします。

この文字列中に「C」の文字はいくつあるかをカウントしていきます。

の前に、まずウェーブレット木の生成方法について理解しておきます。

ウェーブレット木の生成
  1. 文字の種類の数だけのbit長サイズを用意
  2. 各文字をビット列符号化
  3. 符号化した各文字のbit列に対して、ビット位置のビットをそれぞれ取り出す(ビット位置は「深さ+1」番目)
  4. 取り出したビットの列を元の文字列順に並べたものが、ノードのキー値
  5. 4で生成したキー値のうち、ビットの値が0と1の場合で分けて、そのビットを生成した対応文字を順番に並べて、新たな文字列を生成
  6. 3から繰り返して文字列の種類が1種類になると終了

具体的に以下に図で解説しておきます。

f:id:k12si:20190328032243p:plain

 

 それでは、ようやく「C」が文字列中にいくつ存在するのか調べる方法を紹介します。

ズバリ、対象文字列の符号化のbit列を順に「0」か「1」判断しノードを辿っていき、最終的に「葉」に辿り着いた時、その文字の出現回数がわかります。

つまり、以下のような感じです。

 

f:id:k12si:20190328035131p:plain

このとき、「C」bitサイズ分の回数だけノードで判定を行います。これは、生成方法「1」の文字列の種類分のbitサイズに相当します。

 

種類のbitサイズは以下のように考えていきます。

例)4種類 => bit列に直すには2進数に変換 => 2の何乗 => log24 => 2bit

 

したがって、文字の種類がσの時、1文字あたり「log2σ」箇所のノードで判定を行います。

 

また、文字列の長さをNとおいた時、

 

ウェーブレット木が保持するキー値のビット列の長さの総数は、最後の「葉」以外はどの深さの段階でもN個のキー値が存在するため

「Nlog2σ」となる。

 

最後の方の設問がわからなかった。

 

文字列をNとおいた時の計算量 =>「O(N × log2σ)」

わかる方がいればコメントしていただけると幸いです。

 

コードは以下です。

TIL/h30a_ap_pm3.rb at master · k12si/TIL · GitHub

 

ネットワーク

f:id:k12si:20190328035548p:plain

端末からロードバランサ(LB)経由でWebサーバ1,2,3のいずれかに接続する時、パケットの送信元アドレスはLB(172.16.10.5)に置き換えられると解答ではなっている。

!?!?。ど忘れしたのだが、TCP/IPってMacアドレスを次のホップ先に書き換えていくものではなかったっけ??🤔

IPアドレスも書き換えたっけ??となった。

送信元IPアドレスをLBに変更するのであれば、Webサーバからのレスポンスも一度LB経由になってしまうのだろうか?無駄な気が・・・。

というか、そもそもレスポンスって送信元IPアドレスを宛先IPアドレスに書き換えて送るものなのでは?これではリクエスト元の端末に届けられない気がする。

 

あまり自信がないので、*1調べてわかり次第、この記事を編集するつもりだが、コメントで教えていただければ幸いです。🙇‍♂️

 

ここにはIPアドレスは書き換えないという記述がある🤔)

 

データベースに関しては、ただただ知識不足だったので、本記事では特に取り上げません😇勉強しよう。。。

 

というわけで、今日はこの辺で。👋

 

 

*1:調査した結果、LBやProxy経由時に送信元IPはLBやProxyのI/FのIPアドレスに書き換えられることがあるらしい。「あるらしい」と述べたのは、そもそもLBの仕組み自体に送信元IPアドレスを書き換えるという動作はない。また、書き換えた際、正真の送信元IPアドレスXFFとういうHTTPヘッダフィールド内に記録させることがデファクトスタンダードらしい。これによりレスポンス送信時、宛先には正真のIPアドレスを設定可能である。しかし、そもそもなぜ送信元IPアドレスを書き換える必要があるのかがわからない😢

SMTPってどんなプロトコル?

はい、どうも。

 

今回はメールプロトコルでおなじみのSMTPについて調べたことを記述していきます。

 

一般的なSMTPでのメールの仕組み自体は、多くのサイトで解説しているのでそれらのサイトを参照していただけたらと思います。

 

今回僕が行ったことは、SMTPプロトコルのメール送信をGmailで確かめてみました。

 

どういうことか。以下の図を見ていただきたいです。

  f:id:k12si:20190325222830p:plain

 

まず、自分のPC => GmailSMTPサーバ へとopensslを用いてTLS接続を行います。

 

opensslとはSSL/TLS機能を実装したオープンソースライブラリです。今回はtelnetのように、遠隔のサーバにクライアントとしてログインする用途で用います。

 

SMTPサーバ内にSSL/TLSクライアントとして接続した後、SMTPサーバ内で、メール送信を試みます。

 

では、早速方法について紹介します。

 

方法

  1. Googleのアプリケーションパスワードを発行
  2. $ openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof  
  3. SMTPプロトコルのやり取りに準じてサーバにメール送信を依頼

順番に説明していきます。

 

まず、Googleのアプリパスワードを発行します。

これは、Googleアカウントへのアクセス権をアプリやデバイスに付与する16桁のパスワードです。

目的としては、GmailSMTPサーバにTLS接続をする際、アカウントの認証が行われます。その際、アプリケーションパスワードで認証を行うために必要となります。

詳しい説明は以下のURLで。

https://support.google.com/accounts/answer/185833?hl=ja

 

続いて、ターミナルなどでコマンドを実行します。

opensslの使い方は以下の通りです。

```

$ openssl コマンド [ コマンドオプション ] [ コマンド引数 ]

```

opensslを利用する際、コマンドというものが必須パラメータとなります。

今回指定した` s_client `はSSL/TLSクライアントとして動作するというコマンドです。

これにより、Gmailのサーバにログインすることができます。

続いて、オプションについて説明していきます。

` -connect `は接続するドメインとポート番号を指定します。

` -crlf `はターミナルから送られる改行文字をCR+LF(\r\n)に変換します。通常のターミナルのエンターキーではLF(\n)だけが送信されます。

` -ign_eof `は入力時に「end of file」がある時に、接続の切断を抑制します。「ignore_end_of_file」の略だと思われます。

s_clientでは入力に「R」もしくわ「Q」で始まる行があると、それぞれ「再接続」、「中断」と認識し切断されてしまいます。

これでは、後半で説明する「RCPT TP」という入力ができないため、このオプションを指定します。

 

さて、接続先のGmailのサーバですが、以下のサイトから調べました。

Use IMAP to check Gmail on other email clients - Gmail Help

 

ここでちょっと余談なのですが、実際のGmailSMTPサーバは` smtp.gmail.com `ではありません。

 

` nslookup `というコマンドで、DNSサーバ内のゾーンファイル中のDNSレコードを参照することができます。

 

`smtp.gmail.com`ドメイン宛てのメール配送先に関するDNSレコードはMXレコードを参照することわかります。

 

実際に以下のコマンドを実行すると、` smtp.gmail.com `のメール配送先がわかります。

```

$ nslookup -type=mx smtp.gmail.com

```

実行してみるとわかるのですが、実際は` gmail-smtp-msa.l.google.com `にSMTPメールは配送されています。(ここら辺は、正直合っているか怪しいので間違っていたらコメントお願いします。)

 

話を元に戻します。

 

SMTPサーバにSSL/TLSクライアントで接続ができたら、後はSMTP通信のやり取りです。

 

以下の手順の通りにコマンド実行していきます。

 

手順

  1. HELLO:` ehlo localhost `
  2. 認証:` AUTH LOGIN `
  3. 認証:base64エンコードしたGmailアドレス入力
  4. 認証:base64エンコードしたアプリパスワード入力
  5. メール(送信元):` MAIL FROM: <送信元アドレス> `
  6. メール(宛先):` RCPT TO:<宛先アドレス> `
  7. メール(本文):` DATA `
  8. メール(タイトル):` Subject:<メールタイトル> `
  9. メール(本文):` ********* `
  10. メール(本文終わり):` . `

こちらも順に説明していきます。

 

まず、SMTPサーバへHELLOを送信することでSMTP通信を開始します。このときコマンドは` ehlo localhost `です。(SMTPSSL/TLSクライアントで接続しているためlocalhost

近年のSMTP通信では拡張機能による暗号化が必須になってきているらしく、` ehlo `コマンドでサーバ側が対応している認証方法が返ってきます。(ehlo/Extended HELLO

 

続いて認証フェーズです。今回の認証には` AUTH LOGIN `を利用します。

この認証方式は、ユーザ名とパスワードをBase64エンコードして送ります。

Gmailのアカウントのメールアドレスと前述で取得したアプリケーションパスワードが必要です。

 

認証ができたら、メールの送信元と宛先を指定します。

余談ですが、この時、送信元を認証したユーザ以外で送信してみました。

結果は、自動的に認証したユーザから送信したことになっていました。(なりすましとか簡単にできるのかと思ってたけどそうではないんですね笑)

 

続いてメールの本文を送るため、` DATA `コマンドを送信します。

 

本文が送り終わったら、最後にピリオドを送信します。

 

これで、認証ユーザが送信元のメールが宛先に届きました。

 

結果は以下です。

             f:id:k12si:20190326191545j:plain

 

というわけで、終わりです。

皆さんもぜひ試してみてください!

どうやったらyoutubeから抜け出せるのか?

みなさん、こんばんは。

今回はタイトルにもある通り、youtubeの無限ループから抜け出す方法について記述したいと思います。

youtubeの無限ループとは、ある動画を見終わった後、関連動画へ飛び、それが見終わると興味もないのに惰性で別の関連動画を見てしまい、それが見終わると・・・× n回 😇

気づくともう夜中3時!!∑(゚Д゚)

みたいなやつです。

自分はこの経験が日常茶飯事で、ある日iPhoneのスクリーンタイムで1週間のアプリ別平均起動時間を見てみると驚愕。「えっと、なになに、youtubeが・・・・・・・6時間と」_| ̄|○

今の若い時間をこんな無駄なことに溶かしてはいけない。しかし、お気に入りのチャンネルの最新動画はチェックしたい。しかし、関連動画が僕を無限月読の世界に閉じ込めてくる(涙)

と、なかば諦めていたのですが、無限ループにハマらず、かつ、お気に入りのチャンネルの最新動画だけを見るのに(個人的に)最適な方法を見つけたので紹介したいと思います!!

の前に、以下に要点を整理してみました。

youtubeから抜け出せない原因

  • 関連動画の提案
  • チャンネル登録が手軽(見たいチャンネル数を無駄に増やしてしまうため)

欠かせないポイント

  • お気に入りのチャンネルの最新動画はチェックしたい

僕個人としては上記の問題原因を解消でき、かつポイントを満たすことでできれば圧倒的にyoutubeに割く時間は減少すると考えました。

方法

それでは実際におすすめする方法を紹介していきます。

ズバリ、「Feedly」というアプリを利用する。たったのこれだけです。笑

Feedlyとは「RSSリーダー」です。RSSとはWebサイトなどの更新情報をまとめる技術です。つまりRSSリーダーとはWebサイトのRSS情報を取得し、一度に更新をチェックできるものです。実際に更新されて通知がきている画面を以下に載せます。

f:id:k12si:20190325004817p:plain

さて、「だからなんやねん。」「それで、無限ループは解決できてるん?」といった疑問にお答えします。

この方法の素晴らしい点は、以下の2点です。

  • Feedly上?で動画を視聴
  • お気に入りのチャンネルの登録にはURLの登録が必要

まず、1点目に関して、これによりFeedlyで上がる更新動画の視聴はできるのですが、関連動画の視聴はできないのです。

これにより関連動画による欲望の連鎖は抑制されます🙌

つまり、iPhone上からyoutubeをアンインストールし、動画の視聴媒体をFeedlyに変更することで関連動画という魔の手から逃れつつ、お気に入りのチャンネルの最新動画のみを視聴することが可能なのです(゚∀゚)

 

2点目は、お気に入りのチャンネルを抑制できるというメリットがあります。

youtubeアプリだと、チャンネル登録を1タップでできるので、気がつけば更新動画が大量に!!なんてことがあると思います。

ですがFeedlyでは、RSS取得をするにはURLをFeedlyに登録しないといけません。

つまり、お気に入りのチャンネルを増やすのに多少の手間がかかってしまうのです。

これにより、自分が本当に毎日見たい動画なのかを今一度冷静な目で選定するきっかけを与えてくれます。

 

以上の点から、youtubeの無限ループ問題は解消されること間違いなしです!(個人の見解です)

 

これで泥沼のようなyoutube生活にメリハリをつけて、貴重な時間を有効に活用できればと思います。

 

それでは👋

Pocket => Slack通知

今日は、PocketアプリとSlackを連携したbotスクリプトの作成を行った。

大まかな処理の流れは以下である。

f:id:k12si:20190324020240p:plain

Pocketに入った記事を、スクリプトがクーロン処理により時間とタグでフィルタリングした上でPocket内に溜まった記事を取得。

その記事をSlackに送信するといったbotである。

 

詳しいコードや環境などは以下を参照していただきたい。

https://github.com/k12si/TIL/tree/master/pocket

 

このシステムを作成するにあたり以下のサイトを参考にさせていただいた。

 

つまった点として、Slack送信の際、Slack.chat_postMessageの引数にas_user: trueを指定するとなぜかSlackに送信できなかった。

それとrubyで実行する際、bundle exec ruby <スクリプト>としないとrequireできない。(gemのインストール先をbundle install --path vendor/bundleとしたため)

 

さらに、Pocketのデベロッパー用APIの利用にあたっては以下のサイトを参考させていただいた。

https://syncer.jp/pocket-api-matome

 

また、Slackにおけるattachments表記(この呼び方があっているかわからないが・・・)は以下のサイトを参考にした。

https://qiita.com/daikiojm/items/759ea40c00f9b539a4c8

 

一通り作成したが、以下の2点は改善した方がいいと思っている。

  1. スクリプトのクーロン処理を1日に1回の頻度で行ってる
  2. 記事取得のフィルタリング(23:30にその日にPocketに追加された記事がSlackに送信されるようになっている)

理想としては、クーロン処理をHeroku上で最も頻度の高い10minに1回で回し、前回処理時にSlackに送信した記事は再度送信しないようなフィルタリングにしたい。

UMLの図っていくつあるの??

本日も、応用情報技術者試験の勉強をした際の調べたことを記録しようと思う。

 

問題は以下

https://www.ap-siken.com/kakomon/25_haru/q64.html

 

UML/Unified Modeling Language(統一モデリング言語)とは

簡潔にいうと、オブジェクト指向開発における設計〜実装までのモデリング手法

 

結論から言うとUMLで用いられる図の種類は9種類らしい。

 

まず、分類として「構造」にフォーカスした図か「振る舞い」にフォーカスした図かによって2つに大別される。

 

<構造>

・クラス図

コンポーネント

・配置図

・パッケージ図

(4種類)

 

<振る舞い>

ユースケース

・シーケンス図

・コラボレーション図

・ステートマシン図(UML2.0以前は「ステートチャート図」)

・アクティビティ図

(5種類)

 

これらの図がどういった用途で利用されるのか見ていく。

 

まずオブジェクト思考開発プロセスには以下のフェーズが存在する。

 

1.ビジネス分析

 ビジネスの理解、ビジネスの可視化

2.要求分析

 ユースケースモデル作成 => ユーザから見た機能を単位としたモデル

3.システム分析

 「要求」=>「設計」に落とし込むためのワンクッション(要求中の概念構造理解)

 ここのフェーズがシステムの構造把握において最も重要!!

4.システム設計

 設計モデル作成:オブジェクトという概念中心のモデル化(ロジックを考慮しない)

5.実装・テスト

 

特にどのフェーズで、どのUML図を利用するといった決まりはない。

例えば、ビジネス分析において、ビジネスの大枠を捉えるためにアクティビティ図を利用することもあれば、クラス図でオブジェクトだけを取り出し、属性などは考慮せずにビジネス理解を深めるといった方法もあるらしい。

以下のサイトが、UMLを取り入れる概念が具体例を交えてわかりやすく書かれていた。

https://www.itmedia.co.jp/im/articles/0308/19/news001.html

 

よって、重要なのは各UML図がそれぞれどういった特徴を持っているのかという点である。

個々のUML図の特徴は以下のサイトに詳しく乗っている。

http://objectclub.jp/technicaldoc/uml/umlintro2

 

なお、以下の記事を見てUML・・ ・と言うよりかはソフトウェア設計は奥が深いなと感じた。まあ何のために作っているか、誰のために作っているのかを考えると当たり前のような気もするが。

個人的には詳細なモデル図からUMLツールを用いてソースコードの自動生成ができるということに衝撃を受けた。いつかはコードを書かなくなる日が来るのだろうか。

https://cpp-learning.com/uml/

 

はてなブログで記事投稿 => Slackに通知

IFTTT作成してみた。

 

はてなブログrssは末尾に`/rss`つけるだけで取得できるみたい!

参考リンク

https://computerlife.hateblo.jp/entry/hateblo-rssfeed-url

 

作り方は以下のサイトを参考にさせてもらった。

https://www.komaroku.com/push-notification-hatebu

 

無事にbot完成

f:id:k12si:20190321202332p:plain



 

GASでもできるので、また別の機会にやってみよ。

https://mrtry.hatenablog.jp/entry/2018/07/08/163004