SRP - 単一責任の原則

モジュールはたった1つのアクターに対して責務を負うべき

モジュール ... 複数の関数やデータをまとめた、凝集性のあるもの
ソースファイルやクラス、DBテーブルなど？

アクター ....... システムの変更を望むものたち
「商品を探すユーザ」や、「売上を集計したい経営者」など？

責務 .............. アクターを定義する機能たち
商品DBや検索機能など？

どういうこと？

これだけだとイメージしづらいが、色々な解釈ができそう

  • 1モジュールは1アクターの機能をもつ
  • 1モジュールに複数アクターの機能を共存させない
  • アクターが異なるコードは分割すべき
  • あるアクターに対する変更は、対応したコードのみ影響を受ける
  • 逆に、あるアクターに対する変更は、別のアクターに影響しない

アクター単位でコードを分割することで疎結合にする、というイメージ

注意

モジュールはたったひとつのことをすべき、という意味ではない

1つの関数は1つのことをすべき、という原則はある
が、巨大な関数のリファクタなど、表面的で下位レベルの話

SRP とは異なる原則である

SRP はたった1つの関数だけでなく、より上位のまとまりとしての分割単位をアクターにする、イメージ

とはいえ、実際にアクターはどこまで細分化するんだろう...
1つだと思ったアクターが後に分離したり、共通化したくなったりするケースは多くありそう 🤔

設計に活かすなら

新規設計では

アクターを定義して、それぞれの責務（機能）をみつける

定義をコードの分割に落とし込む

リファクタでは

いくつか SRP を満たしているか疑うタイミングがありそう

  • あるクラスに対して頻繁に変更が行われている時は、複数アクターがいないか？
  • あるアクターによる変更で複数のモジュールが影響を受ける

そのクラスを用いる複数のアクターがいる場合、アクターごとに機能を分割する

または、該当アクターに対応するモジュールが存在しないかもしれない

おまけ

SRP の違反例は長くなるので、またどこかで.....

単一責任の原則はクラスや関数（モジュールレベル）の原則だが、より上位のコンポーネントレベルやアーキテクチャレベルで異なる呼ばれ方をするみたい

まとめ

レベルに関わらず、分離の単位はアクターである

読書録：クリーンアーキテクチャ

コードを書く時、課題に感じることが幾つかある
ぱっと出てくることを挙げると...

  • 後から分かりやすい・変更しやすいコードにしたい

    • 自信あるコードにしたい

  • どこから書いてくか迷う

    • 先の道筋を考えてコードを書こうとする
    • そんなことできるのか？
    • 道筋・どう分割するか、先に考えると書き進めづらい
    • とりあえず書き進めたほうが早い

  • どのクラスにどの責務を持たせるか分からない

    • 1つのクラス・メソッドに複数の役割をもたせてしまうことがある
    • 正しくコードを分割できている自信がない
    • ↑を防ぎたいからこそ、道筋を考えようとしてしまう

「後から分かりやすい・変更しやすいコードにしたい」というのが根本にある

コードを書く際「これはしない」「こうすべき」をまとめておくと、スムーズに実装できそう🤔
チェック形式でなくとも、頭に入れておきたい

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

まずはクリーンアーキテクチャを読んで探ってみる
途中からになるけど、 SOLID原則についてまとめる

SOLID原則

About

https://ja.wikipedia.org/wiki/SOLID

ソフトウェア設計の5つの原則の接頭語
自身仕事をしていても、設計やレビューの引き合いに出てくることがある

変更に強く、理解しやすく、再利用性の高い中間ソフトウェアを設計するためのもの

中間 というのは、ソフトウェア設計を何段階かに分けたうちの中間で、この書籍では以下の段階がある
コード - モジュール - （コンポーネント） - アーキテクチャ

SOLID原則はモジュール段階の原則

Principles

これからそれぞれ書いていくよ

  1. SRP (Single Responsibillity Principle) 単一責任の原則
  2. OCP (Open-Closed Principle) 開放閉鎖原則
  3. LSP (Liskov Substituation Principle) リスコフの置換原則
  4. ISP (Interface Segregation Principle) インタフェース分離の原則
  5. DIP (Dependency Inversion Principle) 依存性逆転の原則

まとめ

おまけ

wikipedia によるとソフトウェア設計の原則にはGRASPというのもあって、実践UML にまとまってるらしい

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

  • 作者:クレーグ・ラーマン
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2007/11/12
  • メディア: 単行本（ソフトカバー）

Visual Studio Code でも TeX がしたい

TeX 日記 Visual Studio Code VSCode

この記事はCPS Lab Advent Calenderの16日目の記事です。めちゃくちゃ遅れました...。

15日目の記事は7セグもどきで電子サイコロ - Qiitaです。17日目の記事は個人開発者ならIDは統一しておくと良い - まっきーの研鑽記です。

はじめに

皆さん論文を書く季節がやってきましたね。
まだ実装が終わってないのですが、やる気が出なかったのでとりあえず論文を書く環境を整えてみました。

TeX を書くだけなら cloudLaTeX や Overleaf が便利なのですが、git管理したくてローカルに環境を構築しました。

Overleaf は有償版だと GitHub 連携ができます。

何をするのか

Visual Studio Code で快適な TeX 環境を構築していきましょう。

f:id:takorras:20181224221552g:plain

補完が効いて、保存するたびにプレビューもリロードされます。

また、今回はコンパイルに latexmk を使用します。
面倒なコンパイル手順を .latexmkrc ファイルに残せる事、先輩の論文リポジトリにも .latexmkrc が残っていたので選択しました。

軽量・高速で日本語も書ける LuaLaTeX を使う記事もありますが、梗概のスタイルを上手く読み込めなかったりして、今回はベーシックに latexmk (platex + pbibtex + dvipdfmx)を使います。

1. インストール

まずは必要なパッケージをインストールします。

自分は以下を参考に、brew で GUI なし版をインストールしました。
TeX Live/Mac - TeX Wiki

2. LaTeX Workshop のインストール

VSCodeの拡張機能である、LaTeX Workshop をインストールします。

f:id:takorras:20181224223930p:plain

3. LaTeX Workshop の設定

次にコンパイルの手順を設定していきます。

cmd + , を押すと VSCode の設定が開くので、右上のボタンで json に切り替え、User Settings (右側)を編集します。 f:id:takorras:20181224230841p:plain f:id:takorras:20181224230914p:plain

LaTeX Workshop の設定には、大きく tools と recipes があります。
tools 1つ1つに様々なコマンドを登録して、 recipes 設定でそれらを組み合わせていきます。

実際に実行されるのは recipes の項目なので、tools にいくつか変換処理を登録しておけば、まとめて実行できるということです。

ですが、私は latexmk を使ってコンパイルするので、設定は以下のみになります。
皆さんもコピペして latexmk を使いましょう（適当）

{
  // ... その他の設定項目
  "latex-workshop.latex.recipes": [
    {
      "name": "latexmk",
      "tools": ["latexmk"]
    }
  ],
  "latex-workshop.latex.tools": [
    {
      "name": "latexmk",
      "command": "latexmk",
      "args": ["--synctex=1", "--interaction=nonstopmode", "%DOC%"]
    }
  ],
  "latex-workshop.view.pdf.viewer": "tab"
}

nonstopmode を指定することで、コンパイルエラーが出ても止まらずに実行してくれます。

その他詳しい設定については公式ドキュメントを参照してください。

4. latexmk の設定

※ 前項でlatexmk を使用しない場合は飛ばして下さい。

以下の記事を参考にしました。

konn-san.com

latexmk を使うと、コンパイル手順を .latexmkrc というファイルに記述する事ができます。

先程の設定とやりたい事は同じですが、プロジェクトごとに .latexmkrc ファイルを保存できるので、後々コンパイル手順が分からない！事態を避けられます。

実際、自分も先輩の論文をコンパイルする際にこれが残っていてとても助かりました。

上記事や先輩のリポジトリを見ながらコピペで作成した .latexmkrc です。これをプロジェクト直下に配置します。

#!/usr/bin/perl
$latex = 'platex -kanji=utf8 -guess-input-enc -interaction=nonstopmode %O %S';
$bibtex = 'pbibtex -kanji=utf8 %O %B';
$dvipdf = 'dvipdfmx -p a4 -f ms.map -z 0 %O %S';
$pdf_mode = 3;
$pdf_previewer = 'open -a Preview';

正直よくわかってないですが、これで梗概がコンパイルできました。😇

5. コンパイル

設定したら、TeX ファイルを開いてコンパイルしてみましょう。

左側のコマンドパレット、または cmd + shift + p を押して Build with Recipes を選択し、作成したrecipesを実行します。（私であれば latexmk）

f:id:takorras:20181224232545p:plain

無事コンパイルできれば、 View LaTeX PDF から View in VSCode tab を押すとプレビューが表示できます。

f:id:takorras:20181224232427p:plain

できた！🎉

ホットリロードはもちろん、補完が効くのも良いし、構文チェックを行うオプションもあります。

もし上手くコンパイルされない場合は、VSCode をリロードしてみたり、Clean auxiliality files から余計なファイルを削除して再度試してみて下さい。

おわりに

ということで、LaTeX Workshop を使って論文の環境を作ってみました。
まだまだ TeX についても知らない事が多いので、また気づいた事があったら追記していきます。

それでは皆さん快適なTeXライフを！😇

ノリと勢いで旅行に行ってみる

ポエム 旅行 日記

この記事はミクシィ19新卒 Advent Calendar 2018の15日目の記事です。14日目の記事は 15日目の記事は

ネタがなくて技術記事じゃないです。余裕ができたら記事埋めます..!
先日奄美大島に行ってきたので、旅行の話をしようと思います。

はなすこと

タイトルの通りです。
卒論生にとって旅行する時期じゃないのですが、実際行くと刺激も多くリフレッシュできました。

ですが、ぜひ皆さんは余裕のある時期に旅行しましょう！

旅行が決まるまで

朝起きたら「奄美大島行こう？」とメッセージが来たのが始まりです。

皆さん格安航空を利用したことはあるでしょうか？

今年の夏頃、バニラエアが航空券のセールをしてるのを発見しました。最近だと12月の頭にもあったみたいです。

dsk.ne.jp

奄美大島であれば1,980円〜と書いてありますが、あくまで最安値で、日にちと時間によって値段が違います。
平日は安くても土日祝はこれより割高だったりしてて、学生のうちは平日行くと良さそう。

あとはプラスで保険のお金があり、月-木の往復で1万円しない程度でした！
機内は決して広くないですが、2時間程度なので寝たり映画観ればすぐです。

北海道や沖縄は競争率高めなので、事前にチェックしておくと良さそうです。

宿とホテル

お金がないので、寝泊まりができるゲストハウスを選びました。自身初めてのゲストハウスです。

1日1,500円ほどで、ベッド・風呂・洗濯機などがある、一般のお家っぽい感じでした。研究室での寝泊まりを体験していたので、自分には満足な環境です😇

あとゲストハウスならではですが、オーナーとお酒を飲んだり、他の宿泊客の方から色々な体験談も聞けたりしました。

そんなこんなで、値段以上に良かったです。

観光

名所など事前に調べてはいたのですが、実際に計画立てていたわけではなく、着いてから予約してました。
宿の人にオススメの飲み屋を聞いたり、天気が良いからシュノーケリング行くか！という感じ。

自分はもともと慎重派？ですが、気張らずに仲間と気分で巡るのはめちゃくちゃ楽しめました。

とりあえずの近くの海岸もこんな綺麗で、東京人には感動でした。

f:id:takorras:20181216012741p:plain:w440
Pixel3に変えてきてよかった

まとめ

旅行というと移動費や宿など色々考えがちですが、勢いで予約してみて、その場の気分に任せるのもめちゃくちゃ楽しいです。

論文が終わったら他の場所にも行きたいですね。

JavaScript だけで BLE に入門する

Web Bluetooth API BLE React nodejs web

この記事はCPS Lab Advent Calenderの2日目の記事です。1日目の記事はM5Stackをメトロノームにするです。3日目の記事は

@kotako_rs です。
書くネタが全くなかったので、研究で気になっていたBLEについて調べて実装してみました！

やってみたこと

ChromeからBLEデバイスに接続し、そのデバイスの電池残量をWebページに表示してみます。
今回はRaspberry Pi 3とMacを接続しています。

f:id:takorras:20181202200833g:plain

ハードウェアの知識はほとんどないですが、JavaScriptのみ書いて実現することができます！すごい

BLEについて

通常のBluetoothより省コストで通信を行うことができる技術です。 既存のBluetooth同様2.4GHzの電波を用いていますが、通信速度・通信範囲・データサイズ等がとても小さいものです。（実際には10kbps、10m、33bytesくらい？らしい？）

下の記事が個人的に分かりやすくて参考になりました。他にも良い記事があったら教えて下さい。

jellyware.jp

  • Bluetooth がコンパクトになった
  • GAP、 GATTという共通仕様を用いる
  • サーバー・クライアントみたいにセントラル・ペリフェラルという存在がある
  • Characteristic がBLEのデータを持つ単位で、Service がそれらをまとめる
  • Advertise, Scan, Connect, Disconnect という通信の流れ
  • 単方向通信もあるみたい

というくらいの、フワッとした理解です...。正直まだ全然理解できていません。

bleno

BLEペリフェラルを実装するための、nodejsライブラリです。
電池残量を取得するサンプルをRaspberry Pi で動かして、後ほどブラウザから見つけてもらいます。

github.com

電池残量のようにどういった形式のデータを扱うか、というのがGATTプロファイルで、battery-serviceが公式が提供しているGATTプロファイルの1つです。独自に定義することもできます。

以下のサンプルコードをRaspberry Pi 3 に保存して、
bleno/examples/battery-service at master · noble/bleno · GitHub

自分の環境がはそのままだと動かなかったので、依存関係に手を入れます。
Bluetooth-hci-socket という依存ライブラリが古いので、他の方が修正してくれたものに向き先を変えてあげます。参考issue

// package.json
... 
  },
  "resolution": {
    "bleno/bluetooth-hci-socket": "https://github.com/jrobeson/node-bluetooth-hci-socket/#fix-builds-for-node-10"
  }
}

BLEの仕様がなんとなく分かると、コードもなんとなく読めると思います。

Web Bluetooth API

ブラウザでBluetoothを利用するためのAPIです。
現在策定中ですが、試験機能としてChrome で利用できます。chromium ベースだからか Opera でも利用できるんですね。

Can I use... Support tables for HTML5, CSS3, etc f:id:takorras:20181202215942p:plain

利用したい場合は、試験機能を有効にするために chrome://flags/#enable-experimental-web-platform-features を有効にする必要があります。

f:id:takorras:20181202221759p:plain:w500

Web Bluetoothには

The first version of this specification allows web pages, running on a UA in the Central role, to connect to GATT Servers over either a BR/EDR or LE connection.

と書いてあり、GATTプロファイルを用いてBluetoothデバイスと通信するためのものという事が分かります。
セントラルとして動作します（Web Bluetooth APIを用いてデバイスを見つけて接続する）

またセキュリティから、localhost か https のページでしか使用することはできません。試験機能がoffかhttpかBluetooth機能がない場合は navigator.bluetooth でnullが返されるので、そこでチェックしておきます。

同様にデバイスへの接続も勝手にする事はできず、ユーザーが選択する必要があります。
PCは上記gifのように、Android Chromeでは以下のようなモーダルが出てきました。

f:id:takorras:20181202221707p:plain:w300

以下チュートリアルを確認しながら、先程作成したRaspberry Piを探して接続するコードを書いていきます。
developers.google.com

デバイスを検索するモーダルを出して接続し、電池残量を取得するまでが以下になります。
パッと見やる気が失せますが、これだけです！

  connect() {
    // Web Bluetooth APIが使用できるか
    if (!navigator.bluetooth) return;
   
    // battery_serviceを持つデバイスを検索して、データを取得するまで
    navigator.bluetooth
      .requestDevice({ filters: [{ services: ["battery_service"] }] }) 
      .then(device => device.gatt.connect())
      .then(server => server.getPrimaryService("battery_service"))
      .then(service => service.getCharacteristic("battery_level"))
      .then(characteristic => characteristic.readValue())
      .catch(e => console.log(e));
  }

以下、create-react-app したものを修正してこのコードを入れたものです。
Raspberry Piのサンプルを準備して実行すると出てきました！👀

f:id:takorras:20181202200833g:plain:w500

github.com

まとめ

間違っているところなどあればご指摘お願いします！

だらだらと書いてしまいましたが、JavaScript だけ書いてBluetoothデバイスとそれを利用するアプリを作る事ができました！
身の回りのBLEデバイスや研究室にあるマイコンを使って、なんだか面白いモノが作れるんじゃないかなとワクワクしますね👨‍💻（思いついてないですが）

ハード開発に縁の薄い自分でも、 JavaScript のみで開発ができると手が出しやすく嬉しいです。

では、研究は全く進んでいませんが、奄美大島に行ってきます。

東京アメッシュを使って研究室を雨から守る

slack hubot 開発 nodejs

東京の街を雨から守るサービス

東京都下水道局の東京アメッシュというサービスを知っているでしょうか？

最新のレーダーシステム？によって、現在の東京周辺の降雨情報をみることができます🌂
東京アメッシュ・東京アメッシュのご紹介

研究室のslackbot (hubot)からアメッシュを確認できるようにして、研究室も雨から守ろうと思います

降雨情報

東京アメッシュでは、地図と透過の降雨（メッシュ）画像があり、これらを重ねて表示しています

記事は結構あるので割愛しますが、気になった事があればアクセスしてcmd + opt + iを押すと確認できます

つくってみる

以下をすれば実現できそうです

  • hubot からキーワードなど受け取る
  • 東京アメッシュから最新のメッシュ画像を取得する
  • メッシュ画像と地図画像を重ねて合成する
  • hubot から画像を送る

hubot でキーワードを受け取る

amesh という単語に無差別に反応🤖

module.exports = robot => {
    robot.hear(/amesh/, msg => {
        // アメッシュする
    };
);

メッシュ画像を取得する

地図はあらかじめ保持しておくとして、 メッシュは5分で更新され、http://tokyo-ame.jwa.or.jp/mesh/100/${YYYYMMDDHHmm}.gif から取得できます

const momentTz = require('moment-timezone');

const ameshFilename = () => {
    const now = momentTz().tz('Asia/Tokyo').format('YYYYMMDDHHmm');
    return now - (now % 5);
};

// http://tokyo-ame.jwa.or.jp/mesh/100/${ameshFilename()}.gif からメッシュ画像を取得

画像を重ね合わせる

sharpというライブラリを使用しました
Jimpやgm といったライブラリもあるのですが、Jimpはパフォーマンスが気になったこと、gmはサーバーにImageMagickなどのインストールが必要なことなどから、sharpを選びました
GitHubのスター数も多いです⭐️

東京周辺の大きなアメッシュ画像ができあがるので、表示したい地域に合わせて切り出すと良い感じです

const sharp = require('sharp');

sharp('map').overlayWith('mesh').toFile('amesh'); 
sharp('amesh').extract({left: 0, top: 0, width: 800, height: 480});

github.com

slack bot からの画像アップロード

ファイルのアップロードなどのAPIは hubot-slack ではなく、別に切り出されていました🔪

github.com

ドキュメントのこのあたりにアップロード方法が書いてあります👀 slackapi.github.io

デプロイ

以上もろもろを組み合わせたコードを追加すると...

できた！😄 f:id:takorras:20181014201513p:plain

雨やばいじゃん...

git challengeに参加した

開発 git

はじめに

先日git challengeに参加してきました！

が、結果はボロボロでした…😔

ここでは戒めとしてなぜボロボロだったのかと、イベントで得た学びについてまとめます
あと、前もって言っておきますが今回の内容と実際の問題は関係ありません:bow:

git challengeは

各課題をgit 使ってクリアし、ポイントを稼いでいくCTFのような競技です

ミクシィが主催している学生向けイベントで、詳しくは以下をあたりにまとめてあると思います👉 matome.naver.jp

反省している

問題の難度は複数あるのですが、自分が解けたのは中盤くらいまででした。
中盤くらいまでは実務でも起こり得る状況が多く、基礎コマンドが上手に使えるだけでかなりポイントが稼げると思います

そんな中でポイントが稼げなかったのは、基礎となるコマンドを使いこなせていなかったからです

例えばgitを使っていてコンフリクトが起きたときは、変更箇所をどちらか片方選びますよね。
複数箇所でコンフリクトが発生した状況では、diffやshowでどちらがどちらの変更なのか確認しながら修正していくと思います

が、自分はそれが手際よくできませんでした。😞
コンフリクトなどに限りませんが、基本コマンドをもっと上手く手際よく使えていれば、もっと余裕を持って進められたでしょう...😞

実務や趣味開発においても、基本を上手く使えることが大事だと感じました

反省しつつも

これまで触れなかったコマンドや知識に触れる事ができたのはすごく良かったです！

まず git fsck はgitリポジトリの修復をしてくれるコマンドです
Git - メインテナンスとデータリカバリ

reset --hard など「やらかした！ｗ」という時でも、諦めないで！✋と手を差し伸べることができるようになります
コマンドがある事を知っておくだけで気分は楽になるはずです

また、 git worktree も有用なコマンドの1つです
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！

ブランチ切り替えせずに別ブランチを確認できるので、ちょこっとした確認やプルリクのレビューがしたい時などに便利です。使っています。

ところで

git を作った人は誰だか皆さんは知っていますか？

というような、LTタイムもありました。

gitのファーストコミットを見るのは面白かったです

最初「1コミットでかすぎん？ｗ」と思いましたが、このコミットがあるまでgitが存在していなかったので、それはそうでした😇
gitが当たり前のツールとして浸透している事を感じます

リーナスは2週間でgitを作ったらしく驚きですが、まだ48歳という年齢にも驚きます（歴史上の偉人くらいの感覚だった）
検索トップに例の画像が出てくるので、3重の驚きです:linus: f:id:takorras:20180923023556p:plain

まとめ

基本を大事に〜みたいな事は先程書きましたが、場数と経験も大きなポイントだと感じました！
いろいろと試したり失敗したりしていきましょう😇

個人的な反省点ばかりですが、イベントはとても良いものでした。
運営の方々には本当に感謝です、お疲れ様でした🎉