Category: software topics

アジャイル開発手法には複数の手法あるいはプラクティスと呼ばれるものがありますが、その中で「スクラム」はもっともよく使われている手法として知られており、マイクロソフトやIBMをはじめ多くの企業がソフトウェア開発の現場で採用している。

そのスクラムを実践するための「スクラムガイド（Scrum Guide in Japanese）」が、スクラムの普及促進のための団体「Scrum Alliance」から公開

スクラム入門
正しくは、様々なプロセスや技術を取り込むことのできるフレームワークである。スクラムの役割は、複雑なプロダクト開発が可能なフレームワークを提供することで、開発プラクティスの効果を相対的に浮き彫りにし、改善することである。

スクラムの内容
スクラムフレームワークは、スクラムチームとその役割、タイムボックス、成果物、およびルールで構成される。
スクラムチームは、柔軟性と生産性の最適化を目指すものである。チームは、自己組織化しており、クロスファンクショナルであり、反復的に作業をする。
（略）
スクラムがタイムボックスを採用しているのは、規則的なリズムをつけるためである。タイムボックスには、リリース計画ミーティング、スプリント計画ミーティング、スプリント、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブが含まれる。
（略）
ルールは、スクラムのタイムボックス、役割、および成果物を結びつけるものである。

—–
スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。この方法論は、製品開発における伝統的な、シーケンシャルなアプローチとは大きく異なる。この方法論は、チームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。

スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。
—–

開発途中での仕様変更を認めるということでしょうか。こういう資格があること自体知らんかった。

まず、nginx
[vagrant@localhost local]$ nginx -v
nginx version: nginx/1.14.0

あれ、入ってますね。
起動してみます。
[vagrant@localhost local]$ sudo service nginx start
nginx を起動中: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[失敗]
あ、ポート80はapacheが使ってるからか。

比較
Apacheは、プロセス駆動アーキテクチャでマルチプロセス。これは、各リクエストをプロセスに割り当てて処理を行う。リクエストが大量に来た際、プロセスが同時に起動するのでオーバーヘッドが非常に大きくなるというデメリットがある。

nginxは、イベント駆動アーキテクチャ、シングルスレッドモデル。 シングルスレッドでループ処理をまわし、キューに溜まったイベントを処理していく処理方式（イベントループ方式）（node.jsなどでも採用）。プロセス数はCPUコア数と基本的には同じに設定。

＝＞リクエストが多い場合は、単純にマルチプロセルの方が速そうだが。
＞nginxの方が、処理が軽く、大量のリクエストを処理するのに向いている。
なに？なぜだ？

>nginxは、CPUリソースがたくさん必要な処理には向いていない。処理時間が長くなる処理を実行した際、そこでプロセスがブロックされてしまい処理能力が落ちてしまう。
これはシングルだから、納得できますね。

>NGINXは大量処理、スピード重視を徹底的に追求
同時アクセスはnginxの方が良いと書かれている。
う～ん、イマイチ納得いかない。

コマンドを変えてみるが、
[vagrant@localhost local]$ sudo nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()

あかん

>>MATLAB（マトラボ）は、アメリカ合衆国のMathWorks社が開発している数値解析ソフトウェアであり、その中で使うプログラミング言語の名称

なるほど、機械学習に強いエンジニアだと、matlab使ってる人多いなー、という印象。
とりあえず、python行きましょうかね。

[vagrant@localhost ~]$ python -V
Python 2.7.14

[vagrant@localhost ~]$ python
Python 2.7.14 (default, Mar 12 2018, 22:03:33)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 + 2
5
>>> exit()

Blue tooth 案外使いやすいかも。

M336はカチカチ音がうるさいので、気になりますが。

そういえば、次のiphoneは$700らしいですね。まー　xよりiphone 8 64gbの方が売れてますからね～

例えば、電話のXX-YYYY-ZZZZのうち、YYYY(市内局番)によって、読み込むディレクトリを変えたいとする。
その場合、ファイルをインクルードする際に、フォルダを指定すればよい。

以下のように、6832と6833のフォルダを作る。

$_SERVER[‘PATH_INFO’]でパスを読み込んで、市内局番のフォルダから、加入者番号のファイルを読み込めばよい。

$path = explode('/', $_SERVER['PATH_INFO']);

require "function.php";
$number = format_phone_number($path[1]);

$num1 =  strstr($number, '-', true);
$num = preg_replace("/".$num1."-/","", $number, 1);
$num2 =  strstr($num, '-', true);
$num3 = str_replace("".$num2."-","", $num);

include("".$num2."/".$num3.".php");

0368320900

0368330900

例えば、市内局番が2264件、それぞれ加入者番号が9999件あったとすれば、2264個のフォルダ(ディレクトリ)をつくり、そこから加入者番号のファイルを読み込めばいいので、フォルダを分散させて、フレームワークのルーティングのようにインクルードすれば、理論上、2000万ファイルを作ることは可能ということになる。

まず気象庁
———–
地震の発生日時 震央地名 緯度 経度 深さ Ｍ 最大震度
1 2018/03/12 19:21:26.0 沖縄本島近海 27°15.0′N 128°25.6′E 48km Ｍ4.6 ３

USGS
———-
Magnitude
uncertainty
4.9 mb
± 0.1
Location
uncertainty
27.131°N 128.447°E
± 7.0 km
Depth
uncertainty
52.5 km
± 7.1
Origin Time 2018-03-12 10:21:26.840 UTC
Number of Stations –
Number of Phases 48
Minimum Distance 37.0 km (0.33°)
Travel Time Residual 1.18 s
Azimuthal Gap 74°
FE Region RYUKYU ISLANDS, JAPAN (238)

時間はほぼ一緒ですが、マグニチュード、緯度経度、depth、全て値が微妙に異なります。

マグニチュード：地震が発するエネルギーの大きさを対数で表した指標値
地震のエネルギーを1000の平方根を底とした対数で表した数値で、マグニチュードが 1 増えると地震のエネルギーは約31.6倍になり、マグニチュードが 2 増えると地震のエネルギーは1000倍になる

マグニチュード測定方法：地震計
USGS:GPSや地震計を一定間隔で配備して、ネットワーク化、地下深くまでドリルで穴を開けて分析

気象庁とUSGSでは、どちらのデータが精度が高いのか疑問に思ったのですが、
下記資料をざっと流し読みすると、やってる事にあまり違いがないように感じます。
http://www.spaceref.co.jp/homepage/colum/images/US_earthquake_observation.pdf

ということで、今回は、USGSのデータを使って、地震情報をつくっていきたいと思います。

EPELリポジトリとは、Centos標準のリポジトリでは提供されていないパッケージをyumコマンドでインストールすることを可能にするリポジトリのこと。EPELはエンタープライズ向けリポジトリ。

EPELリポジトリをインストール
yum install epel-release

続いて、php7.1をインストール
yum install –enablerepo=remi,remi-php71 php php-devel php-mbstring php-pdo php-gd php-xml php-mcrypt

base64でエンコードする。
メール本体のように、8ビットクリーンではないトランスポート層でもバイナリデータが生き残るように設計されている。

<?php

$str = "高リスク仮想通貨株にガートマン氏も賭け";
echo base64_encode($str);
?>

結果：
6auY44Oq44K544Kv5Luu5oOz6YCa6LKo5qCq44Gr44Ks44O844OI44Oe44Oz5rCP44KC6LOt44GR

URIまたはURLで使用できる文字をRFC3986で定義している。
This document obsoletes [RFC2396], which merged “Uniform Resource Locators” [RFC1738] and “Relative Uniform Resource Locators” [RFC1808] in order to define a single, generic syntax for all URIs.
RFC3986が分散したURIの定義を全て統合することを狙っている。

予約文字は不可、!、♯などの非予約文字は自由に使用可。

例えば、チルダをurlencodeすると、%7Eに変換されるが、rawurlencodeなら、チルダとなる。

<?php

$str = "~";
echo urlencode($str). "<br>";
echo rawurlencode($str);

Physical World
– sensing, actuation
Communication Network
Cyber System

IoT, Clud, M2M, WSN, Big Data

Interoperability attributes composability, scalability, heterogeneity
Predictability attributes accuracy, compositonality

Security objective: Availability
Network topology: static
Patching: infrequent updates