modest violet

modest violet

開発者としてのあれこれや、日々の雑記など

your future hasn't written yet. no one's has.
by Emmett Lathrop "Doc" Brown

新しいiPhone SEはホームボタンの"終わりの始まり"

いよいよ待ちに待ったiPhone SEが発売されました。

www.apple.com

慣れ親しんだデザインに最新のiPhone11並の機能。そして低価格となると、「待っていたよ!」という声も多いことでしょう。
ですが、個人的には「ホームボタン式iPhoneの終わりが始まった」と受け取りました。

iPhone SEとは

第1世代となるiPhone SEは、iPhone6以降の丸みを帯びたデザインや大きくなったディスプレイではなく、iPhone5をベースとした4インチで小さく角張ったデザインでした。
年々大きくなるデバイスに対して、小さい方を好む方々は大勢おられます。ナンバリングを更新する際に消えゆくiPhone5系のデザインを残したのが、第一世代となるiPhone SEでした。
ですので、今回の第2世代iPhone SEを見て落胆された型も多いと思っています。

終わりの始まり

Appleは過去の製品をみても、ある日突然今までのデザインをガラッと変更し、一新する傾向が強いです。
例えばiMacも初代と今では全く別物です。iPod nanoも長くなったり小さくなったり、長方形だったり正方形になったり・・・とその時その時で別の形状になっていました。
そして最終的には消えていきます。
iPhone SEとはすなわち、過去の形状に一定期間の猶予を与えると捉えています。すなわち、ホームボタン式のiPhoneはこれでおしまい!と暗に言っている訳です。

返り咲きはあるのか

このまま消えゆくかと思っていたmacbook Airが奇跡の復活を遂げた辺りをみると、可能性が全くない訳ではないと思います。
ただ、iPhoneはどんどんカメラ機能が強化され全面のノッチが小さくなっていくと予想されています。
初代から絶えずあったホームボタンのデザインが完全に消えてしまうのは寂しいので、iPhone SEはなんとか残ってくれれば・・・と切に願います。

命名規則が必要な理由

f:id:shin21sk:20200401223905p:plain

多種多様なプログラムが存在しますが、命名規則気にしていますか?
ベテランプログラマーと駆け出しプログラマーのコードを比べると顕著に違いが見受けられます。
この記事は命名規則の具体例は他の記事を参考にして頂くとして、何故必要なのか?ということにスポットをあてています。

命名規則の必要性

命名規則は大事というのが分かるけれど、どう書けばいいのか分からない!という駆け出しプログラマーさんは多いと思います。
まず始めに述べると、命名規則に正解はありません。
少し乱暴かもしれませんが、ベテランでも命名規則は悩みます。というか悩まなければいけないのです。 えっ?でもベテランさんはサクサクっと名前を付けているように見えるけど??という意見も多いと思います。それは、単にベテランさんには命名規則のパターンが染みついているからです。全く新しい概念のクラスとか出てきたとき、どういう名前がいいのかベテランさんも考えます。

何故、命名規則が必要なのか。
それは人がプログラムを作るからです。コンパイラアセンブリ命名規則なんて関係ありません。人がコードを読むために命名規則が必要なのです。
そして、可読性を良くする為に「こういう風に書きましょう」という規則を設けているに過ぎないのです。
ですので命名規則なく適当な名前でもプログラムは動きます。ですが、それは独りよがりの汚いコードです。それは数ヶ月、数年後に自分でも読めないコードに陥る可能性が非常に高いです。

未来の自分でもキチンと読めて、他の人にも読みやすいコードを、美しいコードと呼びます。
そんな美しいコードを意識する最初の一歩が、命名規則です。

悩みすぎは厳禁

命名規則が大事!という事により、何十分も悩み続ける人をたまに見かけます。はっきり言ってそれは無駄です。
クラスやメソッドの名前を付けるときに、数分かかっても悩む場合はそのクラスまたはメソッドの動きを把握できていないか、用途を理解出来ていないと判断できます。
そういう場合は、仮の名前を定めてTODOを残し、動きや用途を理解出来た段階でリファクタリングしましょう。

意外に、自分が書いたコードを説明できないという駆け出しプログラマーさんは多いです。
命名もしかりで、「何故この名前にしたの?」と尋ねてもはっきりした答えがない場合が多いです。
適切な名前を付けるには、対象となるコードを理解する。または、関連する動きの中での役割を理解する事が大事です。

大体3分悩んでもぴったりくる名前がつけられなかった場合は、後回しにするべきでしょう。

終わりに

たかが命名規則、されど命名規則。 転ばぬ先の命名規則
他人に言われなくても自然と命名規則を気にしたコーディングスタイルを身につけることができれば、開発者として一段高みに登ったといえるでしょう。

Office365の割引を利用してお安く買う方法

Microsoft Office 365とは、買い切り型ではなく月額使用料を払って常に最新のWord、Excelといったツールが使用できるサブスクリプション型のOfficeの事です。
最新というのは、買い切り型のOfficeにはない機能も随時追加され、非常に利便性の高い製品になっています。それ故の誤動作がある場合も見受けられますが・・・。

www.microsoft.com

普通にOffice365を購入すると、

  • \12,984 (年間契約)
  • \1,284 (月契約)

年間契約がお得になっています。

安く購入するには12月が狙い目!

2018年の12月にOffice365の3,000円キャッシュバックキャンペーンが行われ、2年目となる2019年も同様にキャンペーンが行われました。

www.microsoft.com

Amazonのセールと併用可能!

2019年を参考にすると、 \12,019 ⇒ \11,581 ⇒ 10%OFF ⇒ \10,423

ここから3,000円キャッシュバックとなるので、実質\7,423でOffice365の1年分ライセンスが購入できます。

月額にすると、わずか\600程度となります。

定価で月契約した際の半額以下となります。

Amazonのキャンペーン、およびMicrosoftのキャンペーンは期間限定ですので、お急ぎください!

【Elasticsearch】スナップショットの共有ストレージはNFSサービスを使う備忘録

Elasticsearchネタというか備忘録は続きます。

以下の書籍通りにスナップショット(バックアップ)を試みましたが、要らないコトをして無駄な時間を費やしました。反省。

失敗したコト

書籍の中では、NFSサービスを使用して共有ストレージに保存しましょうと紹介されていました。
使用しているVirtual BOXの仮想環境がオフライン(非インターネット接続)であった為、aptが面倒という理由でNFSサービスを使わない方向で行こう!と暴走。
結果、ドツボにはまる。

具体的に何をしたのかというと、V-BOXの共有ストレージ機能を使用して各ノードサーバーにマウント。
各サーバーからはキチンと読み書き出来たので大丈夫と思いきや、REST APIからスナップショットの指示を出すとrepository_verification_exceptionエラーが出た。

その際のエラーはこんな感じ。

{
    "error": {
        "root_cause": [
            {
                "type": "repository_verification_exception",
                "reason": "[mv_backup] [[Sup7NQqXQVaT1maJ49ajpg, 'RemoteTransportException[[node72][192.168.1.72:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node72}{Sup7NQqXQVaT1maJ49ajpg}{AOI8z2v7QzeohCBSFoZHRA}{192.168.1.72}{192.168.1.72:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];'], [mHR3zxDqQCqDvGNBxUF2tw, 'RemoteTransportException[[node73][192.168.1.73:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node73}{mHR3zxDqQCqDvGNBxUF2tw}{BwILk21wR4GlJaWDy-DHFg}{192.168.1.73}{192.168.1.73:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];'], [XEgaW0CvQt-02VEczOmHoA, 'RemoteTransportException[[node71][192.168.1.71:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node71}{XEgaW0CvQt-02VEczOmHoA}{WMgwMgp_QLae61ux_xPqtA}{192.168.1.71}{192.168.1.71:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];']]"
            }
        ],
        "type": "repository_verification_exception",
        "reason": "[mv_backup] [[Sup7NQqXQVaT1maJ49ajpg, 'RemoteTransportException[[node72][192.168.1.72:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node72}{Sup7NQqXQVaT1maJ49ajpg}{AOI8z2v7QzeohCBSFoZHRA}{192.168.1.72}{192.168.1.72:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];'], [mHR3zxDqQCqDvGNBxUF2tw, 'RemoteTransportException[[node73][192.168.1.73:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node73}{mHR3zxDqQCqDvGNBxUF2tw}{BwILk21wR4GlJaWDy-DHFg}{192.168.1.73}{192.168.1.73:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];'], [XEgaW0CvQt-02VEczOmHoA, 'RemoteTransportException[[node71][192.168.1.71:9300][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[mv_backup] a file written by master to the store [/home/sgpl/elasticsearch_backup] cannot be accessed on the node [{node71}{XEgaW0CvQt-02VEczOmHoA}{WMgwMgp_QLae61ux_xPqtA}{192.168.1.71}{192.168.1.71:9300}{ml.enabled=true}]. This might indicate that the store [/home/sgpl/elasticsearch_backup] is not shared between this node and the master node or that permissions on the store don't allow reading files written by the master node];']]"
    },
    "status": 500
}

何がいけなかったのか

書籍通りにやらなかったというのが一番な訳ですが、どうも各サーバー上からはアクセスできても、実際のマスターノードが他のノードにアクセスする際、ローカルのパスだと駄目という海外の記述もあり。。。
素直にNFSサービスを入れることに。

Ubuntuでのスナップショット構築

NFSサーバー側ノード

※マウント先のドライブを/dev/sdb1で設定済みとし、/mnt/repoとしてマウント済み

  1. 権限変更
    RESTful APIが読み書きする為に必要

    sudo chown -R elasticsearch:elasticsearch /mnt/repo

  2. NFS server install

    sudo apt install nfs-kernel-server

  3. exports設定

    sudo nano /etc/exports

    # (公開したいディレクトリ) (どのマシンに公開するか) (公開モード)

    /mnt/repo *(rw,async,no_root_squash)

  4. sudo exportfs -av

    exporting *:/mnt/es_repo

NFSクライアント側ノード

  1. NFS client install

    sudo apt install nfs-common

  2. mount用folder
    【需要】マウント先の名前は揃える

    sudo mkdir /mnt/repo

  3. 権限変更

    sudo chown -R elasticsearch:elasticsearch /mnt/repo

  4. 自動マウント

    sudo nano /etc/fstab {NFSサーバーIP}:/mnt/es_repo /mnt/repo nfs rw 0 0

共通設定

  1. elasticsearch.ymlにRepositoryのPath追記

    path.repo: ["/mnt/repo"]

急がば回れとはよく言ったものですね・・・。

【Elasticsearch】クラスターにノードを追加する際 NotMasterException が発生する

Elasticsearch で クラスターにノードを追加する際、マスターノードが見つからないエラーが出たので、回避策の備忘録です。

現象

Elasticsearchでクラスターに複数ノードを追加する。

各ノード候補の /etc/elasticsearch/elasticsearch.yml に設定を追加する。 ノード候補となるElasticsearchは仮想環境で、同一のノードからクローン後に各ノード名を変更している。 ノード名を変更した後、クラスター名を合わせるだけで自動的にノードが追加される。

www.elastic.co

・・・ハズが、「マスターノードが見つからない」という症状が発生し、大いにハマる。

master_not_discovered_exception (NotMasterException)がスローされる。

{
    "error": {
        "root_cause": [
            {
                "type" : "master_not_discovered_exception",
                "reason" : null
            }
        ],
        "type" : "master_not_discovered_exception",
        "reason" : null
    },
    "status" : 503
}

原因

同じ仮想からクローンした為、Node-idが同じままになっており、うまくマスターノードを探せない状態に陥っていた様子。 elasticsearch.ymlでnode nameを指定しただけでは、node idなるものまでは変わらないようだ。

stackoverflow.com

解決策

古いノード情報を削除する。

cd / var / lib / elasticsearch 
sudo rm -rf nodes / 
sudo systemctl start elasticsearch

全てのノードを再起動後、エラーが出ないことを確認。