江戸とカレンダー

いよいよ大晦日ですね!
眠い目をこすりながら深夜0時の除夜の鐘を待っております。

さて、江戸時代の大晦日はどうだったのでしょうか。日没が1日の終わり(翌日の始まり)であった江戸時代、大晦日の日没があけおめのタイミングでした。大晦日の夜にはお雑煮を食べ、今と同じように年越し蕎麦で〆ていたようです。
なお、江戸時代は旧暦なので、年末年始は現代のカレンダーでいうとだいたい1月末〜2月中旬です。

また、江戸時代は1ヶ月の日数を30日(大の月)または29日(小の月)としていました。
ただ、この30日と29日の繰り返しでは次第に季節とずれてきてしまいます。
そのため、数年に一度は閏月を設けて1年を13ヶ月としていました。
例えば、今から300年前の1721年(享保6年)は以下でした。
30日(大の月):2月、4月、5月、7月、8月、10月、12月
29日(小の月):1月、3月、6月、閏7月、9月、11月

ということで...
毎年、月の大小や閏月の有無がどうなるか知る必要があったのですが、どのような方法で確認していたのでしょうか。
平和で創造性豊かな江戸時代です。

大小暦クイズ | 日本の暦

このようなクイズ形式の大小暦が流行しました。年が明けると、今の年賀状のように、自作の大小暦カレンダーを贈り合っていたようです。

何もひねりはありませんが、僕も一つご紹介。

f:id:KenjiU:20201231223758p:plain

EDO-OCRを実行すると、現代の小の月(30日)として
2月、4月、6月、9月、11月
が見えてくるはずです?

ちなみに、現代のカレンダーが使われるようになった明治6年以降は、「西向く士(サムライ)」(二四六九士)の語呂合わせで、小の月(30日)を覚えていたようです。

それでは、良いお年を!

DX事業について

f:id:brix:20201224161232j:plain

今年もそろそろ終わりですね、こんにちはブリスウェルの加藤です。

ブリスウェルは本業はソフトウェア開発なのですが、大きな開発を伴わないプロジェクトを担当する部門を持っています。

エンジニアの人材紹介・派遣・常駐型PJT管理のようなサービスのポーションが大きいので、「人材事業部(HR事業部)」としていました。

この部門は、

  • 顧客対応・渉外・営業
  • プロジェクト管理(PMO)
  • 会社のPR(渉外部門であることを活かして)

などに加えて、

  • 業務/ITコンサル
  • SaaS導入支援
  • Web/ECの制作・制作管理
  • ソフトウェアPJTのプロトタイピング制作
  • ソフトウェアPJTの検証

となどを行っています。

書いてみても、やはり開発以外は何でも、行っているのだなと。 ※ ただしもちろん、IT・ソフトウェア・DXに関することであればですが。

昨今、世の中に「デジタル・トランスフォーメーション」が十分すぎる程に浸透してきたのもあり、実態に合わせて、当事業全体の名称を「DX事業」、当部門の名称を「DX事業部」と変更することにしました。

2019年ころまではクライアントとのMTGで「DX」と言ってもまだ浸透していないことが多く、ソフトウェア・ファースト、ソフトウェア・ドリブンだとか、インターネットを経営に取り込むだとか説明が必要で、貴重な時間を費やしたものです。

まるでTV CMのネタのように、デラックスですか?というご質問を受けたことも1回だけあった記憶があります。 せっかくのボケを頂いたのに、うまく突っ込めたか、記憶が定かではありません。

結果的に、弊社はまさにDXをやっているにも関わらず、社内ではあまり使って来なかったワードです。

今後も、ソフトウェア開発部門には営業専任担当者がおらず、DX部門内に持っていることには変わりないので、変わらず外向きの仕事をしていくと思います。

営業部門にも全社にも若いメンバーが多いので、この時期に毎年バズる古典と、今年の新曲とを貼っておきます。

amba.to

bit.ly

※ 画像 https://pixabay.com/ja/photos/%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%9E%E3%82%B9-%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%9E%E3%82%B9-%E3%83%84%E3%83%AA%E3%83%BC-1869902/

CakePHPのアソシエーション:長所と短所(MySQLで検証)

どうもこんにちは。BriswellのTuanと申します。
前回、PHPメモリに関して色々話しました。

実は、開発時にPHPを使ってゼロからプロジェクトを立ち上げた経験のある方いると思いますが、その経験がなかなか快適ではないと思います。
ソース構造、データマッピング、リクエストハンドリングなどを管理必要があるため、ビジネスロジックを実装するの工数よりかなり多くの工数だと思います。
そのため、主に有効性と汎用性のためにフレームワークを使用します。
Web開発にはさまざまなMVCフレームワークがありますが、CakePHPはおそらく使いやすいと思います。
ただし、CakePHPには他のフレームワークと同じ長所と短所があるため、今回はCakePHPアソシエーションの長所と短所を共有したいと思います。

CakePHPのアソシエーションとは?
CakePHPサイトから下記の定義になります:

アプリケーション中で、異なるオブジェクト同士の関連を定義することは よくあることです。
例えば、記事は多くのコメントを持っていて著者に属しています。 著者は多くの記事とコメントを持っています。
CakePHP はこうしたアソシエーションの管理を 簡単にします。CakePHP には4つのアソシエーションがあります。
hasOne 、 hasMany 、 belongsTo 、そして belongsToMany です。

https://book.cakephp.org/3/ja/orm/associations.html

(サンプルとして、CakePHPサイトからのチュートリアルのデータベースを使います)

今回の話はアソシエーションの長所と短所ですので、実際の使い方を言及しないと思います。興味がある方、上記のリンク直接参照してください。

1ー長所:

①使い方が簡単:
一回テーブルクラスにアソシエーション定義してから、いつでも、どこでも適用できます。

②ソースが分かりやすい(自然言語ちょっと近くと思います)。

<?php
class ArticlesTable extends Table
{
    public function initialize(array $config)
    {
        $this->hasMany('Comments');     // アソシエーション定義
    }
}

(1-1)

<?php
$query = $articles->find('all')->contain(['Comments']);
foreach ($query as $article) {
    echo $article->comments[0]->text;
}

(1-2)

③一括全部必要な情報簡単に取得できます。

上記のソース(1-1, 1-2)を見てから、Articles テーブルの検索操作で、もし Comment のレコードが存在すればそれも取得ことができます。

2ー短所:

①オーバーヘッド
1-2のソースは簡単ですが、実施する時にCakePHPが下記のような SQL を作成して、実行します。

SELECT * FROM articles;
SELECT * FROM comments WHERE article_id IN (1, 2, 3, 4, 5);          // サンプルデータは5つレコードだけ

(2-1)

普通のクエリーと比べて

SELECT * FROM articles LEFT JOIN comments ON comments.article_id = articles.id;

(2-2)

(2-1)に何の問題発生する可能性がありますか?(答えを見ないで1分考えてください。)

問題は「IN (1, 2, 3, 4, 5)」の分です。なぜでしょうか?

サンプルデータは5つレコードだけですが、何十万件の場合はクエリー文は何バイトになりますか? 後、「articles.id」今数型ですが、例えば、idが文字列(10桁)の場合はクエリー文もっと長いでしょうか?

その場合はMySQLのクエリーパケットサイズ(max_allowed_packet)を超える可能性があります。

ただ、CakePHPの作者もそう言うことをもう考えてくれたので、「サブクエリーのストラテジー」と言うオプション追加しました。

SELECT * FROM articles;
SELECT * FROM comments WHERE article_id IN (SELECT id FROM articles);

(2-3)

こ言う書き方は安心ですよね。 しかし、下記の短所になります

②パフォーマンス
(2-1)はメモリ問題発生しなくても、下記のパフォーマンス発生します。

  • クエリー文長くて、インターネットの帯域幅がかかるので通信時間がかかります。
  • クエリーパフォーマンスだと「IN」オペレーターの検索は遅くて、Indexを使えない、Whereでデータを絞り込みますので一番遅いです。

(2-3)は(2-1)よりパフォーマンスが良いですが、Indexも使えないですのでデータ容量が大きくなったら実行時間どんどん長くなります。

3ーまとめて:

処理によって、どちら適用方がいいか考えください。

  • 簡単画面・パフォーマンスあまり影響しない場合はアソシエーションを使う方が楽です。

  • 複雑処理・件数容量が多くの場合はアソシエーションを使うのは遠慮してください。

  • テーブルのカラム数が多くの場合もアソシエーションを使う時にちゃんと、「fields」オプションで、対象のカラムだけ取得してください。 そうしないと、全カラム取得して、また帯域幅がかかりますので。

アイカタ、印刷業向け機能の紹介

f:id:bw_naoya:20201221160722p:plain
こんにちは、naoyaです。
気づけば今年も残す所あと僅かですね。
もう一年が終わるのかという気分で、年々体感時間が短くなっていくことを実感しています。

さて、今回は弊社が開発した「アイカタ」について、印刷業向けの機能紹介をさせていただきます。

イカタとは

受発注管理システムとしての機能を備えたクラウドERPパッケージです。
柔軟なカスタマイズ性により中小企業様やスモールスタート向けの業務システムとなっています。

マスタ系

顧客や外注先などの取引先や社内の情報を始めとして、印刷/製本などの各工程に利用する機械や資材の管理も可能です。

案件/見積管理

校正や受注状況の管理や、見積書の作成をすることが出来ます。
見積書は案件ごとにまとめて管理され、いつでも出力を行えます。

見積画面


仕様

デザイン/プリプレス/資材(用紙)/刷版/印刷/製本作業/納品手配 の各種工程に必要な仕様の情報を1画面で管理できます。
仕様で設定した日程情報を現場でリアルタイムに閲覧可能なスケジュール画面や、アプリも開発中です。

f:id:bw_naoya:20201221153421p:plain
開発中のアプリ画面のイメージ図


仕入/在庫管理

マスタに登録した商品や資材の入出庫を記録し、在庫の管理が出来ます。
また、shopifyで作成したECサイトと連携して注文や在庫情報を連動させる機能を開発中です。

売上/支払

案件毎に売上の作成や請求書の出力、外注先単位で集計した支払の作成を行うことが出来ます。
会計freeeと連携することで発注/売上などの会計情報をfreeeに登録することが可能です。(12/21現在、freeeアプリストアへの申請中のためまもなく正式に利用開始となります。)

最後に

下記ページからお問い合わせ頂くことで実際の機能をお試しいただくことが可能です。
お気軽にお問い合わせください。

「業務のアイカタであり続けたい」
印刷業向け総合管理システム

ai-cata.com

仕事に実際的にPostManの使い方を調べる

f:id:phamhongson063:20201214111935p:plain

どうもこんにちは。ブリスウェルのSonです。
皆様お元気ですか。冬がきました。天気がだんだん寒くなったので、気をつけてください。
この記事は2回目です。私の日本語能力はへたなので、どこか正しくない単語とか使い方がある場合は教えていただけませんか。

最近Azure Active Derectory(A A D)に関係る調べることがありますので、AAD Graph APIを実行ためにPostManを利用しました。基本的に使えるPostmanですが、他の機能の使い方があまり理解していなかったの調査したのブログについて紹介いたします。
順番に紹介方がわからないのですが、簡単のようにそれぞれ問題を分けます。

目次
・問題1:新プロジェクトの構築にしたいですが、一番簡単なやり方はなんでしょうか。
・問題2:認証A P Iを実行するごとで認証トークン値をコピーし、他のA P Iに手で入力したくなくて、どうやってやりましょうか。
・問題3:ローカルとテストの環境で同じA P Iを実行し、テストし、設定と使い方はなんでしょうか。
・問題4:チームやA P I利用者とテストを共有したいですが、共有方法はなんでしょうか。

はじめましょう!!!


問題1:以下図のような構築にしたいですが、一番簡単なやり方はなんでしょうか。

f:id:phamhongson063:20201214112615p:plain

プロジェクトAを作成するには、左ペインでCollectionsを選び、「+ New Collection」をクリックするだけ。

f:id:phamhongson063:20201214112838p:plain

ダイアログが表示されるので「Project A Dev」という名前を記入してCreateを押下

f:id:phamhongson063:20201214113003p:plain

次は「groups」というフォルダを作成してみよう。

f:id:phamhongson063:20201214113103p:plain

またダイアログが表示されるので「groups」というフォルダを記入してCreate。

f:id:phamhongson063:20201214113148p:plain

同じやり方法で「users」のフォルダーの作成を行なってから、2つのフォルダーが定義されました。

f:id:phamhongson063:20201214113237p:plain

今回の記事では説明するためにローカルに環境しました。
http://127.0.0.1:8081

ソースコードGitHub.comにあげました。ソースコードは下記U R Lになります。
https://github.com/bw-sonph/postman-demo-project

プロジェクトのルーターの内容

// get: api/auth
Route::post('auth', [ AuthController::class, 'auth' ]);

Route::group(['prefix' => 'users', 'middleware' => ['api.authentication']], function() {
    Route::get('', [ UserController::class, 'search' ]);
    Route::post('', [ UserController::class, 'create' ]);
    Route::get('{uid}', [ UserController::class, 'searchUid' ]);
    Route::patch('{uid}', [ UserController::class, 'update' ]);
});

Route::group(['prefix' => 'groups', 'middleware' => ['api.authentication']], function() {
    Route::get('', [ GroupController::class, 'search' ]);
    Route::get('{uid}', [ GroupController::class, 'searchUid' ]);
    Route::patch('{uid}', [ GroupController::class, 'disable' ]);
});

上記ルーターについてはPostmanで特に説明は要らないと思います。作成してから、8つのA P Iが作成されました。

f:id:phamhongson063:20201214113635p:plain

問題2:認証A P Iを実行するごとで認証トークン値をコピーし、他のA P Iに手で入力したくなくて、どうやってやりましょうか。 f:id:phamhongson063:20201214113950p:plain

Auth APIは以下の形式のレスポンスを返却します。

f:id:phamhongson063:20201214114030p:plain

access_tokenは認証トークンで、「Search Group」A P Iとかではこの認証トークンをリクエストヘッダに含めることが要求されます。トークンはAuth A P Iを叩くごとに変わる可能性があるため、それを織り込んだテストを検討する必要があります。
認証トークンを設定する
f:id:phamhongson063:20201214114158p:plain

try {
    pm.environment.set('access_token', '')

    if ( pm.response.code === 200 ) {
        pm.environment.set('access_token', pm.response.json().access_token)
    }
} catch {}

このテストコードではステータスコード200が返却されているかと、プロジェクトのaccess_token変数に値をセットすることが可能です。
で「Search Groups」A P IのタブとかでAuthorizationタブが表示されるので
・TYPEを「Bearer Token」に選択
・Token欄に「{{access_token}}」と記入

f:id:phamhongson063:20201214114310p:plain →設定方法は終了でした。
A P Iを実行するごとに認証トークンを{{access_token}}に置き換えます。
access_token変数を、全てのリクエストから呼び出せるトークンとして設定

f:id:phamhongson063:20201214114415p:plain これから「Search Groups」A P Iとかで、また情報を「access_token」に入力必要ありません。よかった!

問題3:ローカルとテストの環境で同じAPIを実行し、テストし、設定と使い方はなんでしょうか。

f:id:phamhongson063:20201214114548p:plain

環境から定義します。右上の赤枠のイコンボタンをクリックします。

f:id:phamhongson063:20201214114618p:plain

環境管理ダイアログが表示するので「Add」を押下

f:id:phamhongson063:20201214114650p:plain

それぞれ環境名、環境変数と変数値を入力します

f:id:phamhongson063:20201214114722p:plain

f:id:phamhongson063:20201214114737p:plain

基本的に2つの環境情報をセットしました。したら、認証A P Iのtestsタブで内容をちょっと修正してください

f:id:phamhongson063:20201214114842p:plain

目的は認証A P Iを実行する時は選んだ環境で「access_token」の値を置き換えます。U R Lは上記画像のような値を変更してください。他のA P IでURLにも変更必要あります。

f:id:phamhongson063:20201214114918p:plain

「domain_url」と「access_token」を環境変数に設定すると。それぞれ{{domain_url}}、{{access_token}}として参照ができます。
ローカル環境とかテスト環境とかでテストする時に右上ドロップダウンに該当環境を選べます。。

f:id:phamhongson063:20201214115021p:plain

いろいろ便利に使えそうです。

・問題4:チームやA P I利用者とテストを共有したいですが、共有方法はなんでしょうか。
f:id:phamhongson063:20201214115120p:plain

Collectionをエクスポートするには「Export」をクリクします。するとエクスポート形式を選択するポップアップが開きます。 環境変数をエクスポートするには赤枠のイコンをクリクします。変数ファイルはダウンロード出来ます。 f:id:phamhongson063:20201214115204p:plain

Collectionと環境変数をインポートするには以下図の赤枠をクリックします。 f:id:phamhongson063:20201214115231p:plain

最後に
簡単に接続するだけでなく、環境変数などを使うことでめちゃめちゃ便利に使えるPostManをぜひ活用していきましょう!

プロセスを共有することとアウトプットを出すこと

f:id:brix:20201202164822j:plain

こんにちは、加藤です。

プロセスエコノミー

さて急に本題です。 「プロセスを共有するところがお金を稼ぐメインとなる」という概念の「プロセス・エコノミー」を説明するけんすうさんのブログがありました。

kensuu.com

この記事はC向けのエンタメ・コンテンツについての考察なのですが、われわれのようなBtoBのビジネスサービス企業のビヘイビアにも全く同じ事が起こっています。

BtoBにおけるプロセスエコノミーとは

例としてブリスウェルで行っているPJTのうち、「コンサルティング」や「ラボ型開発(チームをまるごと提供してソフトウェア開発すること)」あるいは「AIのプロジェクト」は、そのアウトプット(成果)も勿論ですが、プロセス(過程)やナレッジ(知見)の共有自体に大きなバリューがあります。

コンサルティング業界においては、随分と昔から社内の評価基準において成果主義の側面をことさら強調されてきたものですが、今は社外との関係性においては成果に至るまでのトライアルの過程を共有することが重要であると強調されるようになってきています。

※ 成果を出すのはあたりまえという前提を話し出すとキリがないので、今回はスルーします。

ソフトウェア開発やAIに至っても、ソフトウェアが動くことやAIが価値を出すことが最重要であることは変わりないのですが、構想・設計・開発・検証などのプロセス自体をステークホルダーと共有することが大きなウェイトを占めるようになりました。

企画の視点、PJTの進め方、期待値のコントロール、開発手法など最終成果物以外のプロセスにお金を払って頂いていると言っても過言ではないのです。

BtoBでのFan化

プロセスを共有していくことで、ステークホルダーを巻き込んでいくことに繋がり、ひいてはアウトプットの品質向上に繋がります。

(これだとアウトプットエコノミーのままなので、切り離して考えるとすると、もとい)プロセスを共有していくことで、ステークホルダーを巻き込んでいくことに繋がり、更に能動的にプロセスを楽しんで貰えるようになったりします。

似たようなアウトプットを出す複数社からブリスウェルを選んで頂いている場合、もしかしたらQCDでもなく、担当者の人柄でもなく、プロセスの楽しさで選んで頂いているのかもしれません。

※ くどいですが、クライアント企業に対してのサービス提供に関して、「プロセスを共有すれば、ステークホルダーを巻き込んでいれば、アウトプットの価値は程々で良い」とは言っていません。われわれは最終成果に大きくコミットしている企業であることは強調しておきます。

ソフトウェア開発で業績向上(成果)を求めていらっしゃる企業の方、試行錯誤過程(プロセス)も一緒に七転八倒して頂ける企業の方、どちらもご連絡をお待ちしております。

www.briswell.com

pic by : 喫茶店での休憩中のテーブルの写真(画像)を無料ダウンロード - フリー素材のぱくたそ

Shopify Partner Boot Campに参加してみました①

突然ですが、はじめまして。omiyaです。
今回初めてTech Blog書いてます。
普段は人材事業や管理業務を行っているのですが、少し前から新サービス
「Shopify」を使ったECサイトの構築も担当しております。

弊社でもすでに案件はいくつか動いているのですが、よりShopifyの理解を深めるためShopify Japanが開催しているShopify Partner Boot Campに参加してきました。
(先着順だったので間に合うか心配でしたが、大丈夫でした!人気が高いですね)
こちらは12月まで続くのでまだ終了はしていないのですが、随時備忘録代わりに残していきたいと思います。


第1週 基礎知識の習得
この日は初日ということもあり、お題としてはプログラム概要とパートナーセミナー(セッション)でした。
今回はShopify Japanの方以外にもShopify Expertの企業の方も講師としていらっしゃいました。

■まずShopifyとは
ShopifyははじめはECプラットフォームを販売していた会社ではなく、スノーボード用品を販売していた会社だったそうです。
スノーボード用品を売るためにエンジニアだった代表がShopifyのECプラットフォームを開発したことがきっかけだったのですが、 そのうちスノーボード用品よりもShopifyの方が売れ始めたため、Shopifyのサービスに特化するようになりました。
2004年会社設立、サービスは2006年ローンチされました。
現在、Shopifyを利用している事業者は世界で100万社以上、175か国にも及びます。

■Shopifyにはアプリストアがあります。
アプリを使うことによって、構築がとーーーってもストア構築が簡単になるのです。
アプリ開発をしているのは37,400社とも言われるパートナーが開発しています。
アプリの数としては5300以上のアプリが存在します。

■プラン
SHOPIFY PLUS:大企業向け。月額2,000ドル。
プレミアム  :中小企業向け。月額299ドル。
スタンダード:中小企業向け。月額79ドル。
ベーシック:個人向け。月額29ドル。

事業者が支払う料金としては上記のプラン費用、決済手数料、有料アプリ料金、有料テンプレート料金のみです。
(アプリ、テンプレートは無料のものも多々あります)
パートナーは基本的にお金がかかることはありません。

また、Shopifyのすごいところはどのプランでも商品登録数は無制限!
すばらしいですね。
プラン変更してもプラットフォームの乗り換え不要なので、事業が成長してもずっと使うことができます。
プランの違いとしてはスタッフのアカウント数や決済手数料などでした。
ご興味あれば下記リンクに詳細ありますので、参考にしてみてください。

www.shopify.jp

大手向けのプランが5~6年前と最近始まったこともあり、ユーザーは個人や中小企業が多いそうです。
しかしながら事業成長と共にプラン変更するだけでそのままサイトを使えることは魅力的ですね。

■Shopifyコミュニティフォーラム
このコミュニティを使うことによって、さまざまなアドバイスを得られることができます。
参加者は事業者やパートナー等、多岐にわたります。
困ったときはここで情報収集するのもありですね。

■Shopifyパートナーの種類
・ストア構築パートナー
アプリ開発パートナー
・テーマデザインパートナー
・紹介(アフィリエイト)パートナー
マーケティングパートナー
・販売チャネルパートナー

弊社はストア構築パートナーとして活動しています。
ストア構築後、リリースすることによって、クライアントの月額利用料20%を毎月得ることができます。
この後は、弊社はストア構築パートナーとして活動していますので、ストア構築パートナーに特化して書いていきたいと思います。

■Shopifyパートナーの管理画面
上記で紹介したどのパートナーでも同じ管理画面を使うことになります。
Shopifyパートナーに登録すると、下記管理画面にログインできるようになります。
f:id:bw_omiya:20201124112102p:plain

赤い四角で囲んである【開発】から構築中のストアを見ることができます。
画像は開発ストアのみとなっていますが、コラボレーターとしてストア登録すると事業者と連携して管理画面を操作することができます。
(コラボレーターと記載されます)
新規のストアを登録する際もとても簡単です。
こちらは別の機会に紹介したいと思います。

■パートナー成功事例
まだまだ海外での事例が多い印象でした。

■Shopify Expert企業のお話
どのようなきっかけでShopifyを始めたか、実績やメリットの紹介等のお話がありました。
いくつか実際Shopifyで作成したサイトの紹介もあったのですが、全く違う作りだったので幅広いデザインや機能の構築が可能なんだなと改めて思いました。

■Q&A
今回Shopify Partner Boot Campの参加者向けにslackが開設されています。
セミナー中に質問を投げておくと、最後に回答してもらえます。
もちろんセミナー中でなくても質問可能です。


第1回目ということもあり、Shopifyとは?何ができるの?料金ってどのくらい?といった基本的なサービス概要の説明が主だったかなと思います。
第2回目以降も書いていきますので、参考にして頂けると嬉しいです。
もちろん弊社へのShopifyの相談もお待ちしております!!

江戸と数学

f:id:KenjiU:20201123001823j:plain
越後屋

江戸時代は、日本の歴史上最も数学がフィーバーした時代です。
大名から子供まで、商売、両替、測量など日常生活に活かせる技術として学んでいただけではなく、娯楽としても楽しんでいたようです。

江戸時代のベストセラーの一つに、塵劫記という数学の参考書があります。
数の単位(一、十、百 ... 那由他、不可思議、無量大数)、九九、そろばんの使い方、面積の求め方、そして数学問題などが、面白い挿絵を入れて分かりやすく書かれています。

塵劫記には、次のような盗人算という問題があります。

橋の下で盗人たちが何やら話しているのが聞こえます。どうやら、盗んだ反物を分けようとしているようです。ところが、7反ずつ分けると8反余り、8反ずつ分けると7反足りず、困っているようです。
さて、盗人と反物の数は?

現代っぽく、プログラミングで解を見つけてみましょう。

nusu = 0 # 盗人0人

while True:
    nusu += 1 # 盗人1人増やすぜよ
    tan1 = nusu * 7 + 8 # 7反ずつ分けると8反余り
    tan2 = nusu * 8 - 7 # 8反ずつ分けると7反足りず
    if tan1 == tan2: # 盗人が何人であれば合致するのか
        break

print("盗人 = " + str(nusu) + "(人)")
print("反物 = " + str(tan1) + "(反)")

出力結果
盗人 = 15(人)
反物 = 113(反)

のようにとても簡単ですね。

7x + 8 = 8x - 7

という方程式を立てても、すぐに解は出てきます。

さて、江戸時代の人たちはどのように解を出していたのでしょう。

塵劫記の解答には

盗賊は8足す7で15人。反物は15人掛ける8反に7反足りないから113反。

とだけ、記載されています。

うーむ... なるほど
盗賊全員に7反ずつ分けると8反余って、もう1反ずつ分けようとすると、あと7反足りない。ならば15反(= 8 + 7)あれば全員に1反ずつ分けれる、すなわち盗賊の数は15人ですね。
スマートなアプローチです!

最後になりますが、一つAI技術をご紹介。

トップの越後屋のイラストは、写真を漫画風の画像に変換するGAN、その名も「CartoonGAN」を利用して生成したものです。
お主も悪よのう。

AWSアクセス管理(IAM周り)

どうも、しゅんです。

今回は、IAMAWS Identity and Access Management)について触れていきたいと思います。

IAMでは、AWSユーザーの管理や認証、サービスやリソースへのアクセス制御を管理することができます。

AWSアカウント

 AWSを利用する際、初めにAWSアカウントを作成します。

アカウント作成時に入力した、「メールアドレス」と「パスワード」を用いて、自身のAWSマイページ(AWSマネジメントコンソール)へログインすることができるようになります。

 

この初回に作成するAWSアカウントのことをルートユーザーと呼び、

当ユーザーは、自身のアカウント内のすべてのAWSサービスやリソースに対するフルアクセス権限を持ちます。

→会社の中で例えると、社長(※会長がいるところもありますが)に相当

 

ルートユーザーの特権としては、以下のようなものを有しています。

AWSアカウントのメールアドレスやパスワードの変更

・IAMユーザー(ルートユーザーより下位のユーザー※詳細は後述)の課金情報に対するアクセス許可/拒否の設定

AWSサポートプランの変更

 

ここで気を付けないといけないのは、悪意のある第三者などによってルートユーザーが乗っ取られないようにすることです。

このルートユーザーは前述した通り、最強のアカウントとなりますので、乗っ取られた場合は、全権限を奪われることになります。

そこで、AWSでは多要素認証という認証方式を使用することができるため、この認証方式を取り入れた方がよさそうです。

→もちろん、完全にリスクを回避できるといったことはできないのですが、何も対策を講じていない状態から比べると、だいぶんセキュリティ面は向上できると思います

②IAMユーザー 

 AWSを操作するユーザーを、1つのAWSアカウントで5000ユーザーまで作成することができます。

AWSマイページ(AWSマネジメントコンソール)へのログイン方法は、IAMユーザーを作成した際に発行した「ユーザー名」と「パスワード」になります。

③IAMグループ

IAMユーザーをまとめたグループを、1つのAWSアカウントで300グループまで作成することができます。

IAMユーザーが所属できるグループは、最大10グループまで。

 アクセス制御ポリシー付与

 前述の「IAMユーザー」と「IAMグループ」にポリシー(権限など)を割り当て、サービスやリソースへのアクセス制御を行います。

IAMユーザーにポリシーを直接付与した場合のイメージ

f:id:artistyuiguitarelegance:20201118161922p:plain

IAMユーザーにポリシーを直接付与

この場合、ユーザー単位でポリシーを割り当てる必要があるので、ユーザー数が増えれば増えるほど、ポリシーの管理が手間になる場合があります。

IAMグループにポリシーを付与した場合のイメージ

f:id:artistyuiguitarelegance:20201118162057p:plain

IAMグループにポリシーを付与

この場合、グループにポリシーを 割り当てるため、ユーザー数が増えてもポリシーの管理が手間となりにくいです。

IAMポリシーの設定方法

IAMポリシーの設定方法としては、以下の方法があります。

JSON(コードを記載していくため、JSONの記載ルールを知っておく必要があります)

・ビジュアルエディタ(画面上からポチポチ触って設定をしていきます)

・インポート(以前作成したことのあるポリシーをインポートします)

 

※設定の内容につきましては、本記事では触れておりませんのでご了承くださいませ

最後に

以上、IAM周りについて、触れてみました。

記事中の誤り、不備などございましたら、コメントいただけますと幸いでございます。

 

それでは今回はこの辺で✋

See you next time then.

ZIPファイルを少しでも小さく圧縮させようとした話

f:id:rosone:20201113215354j:plain

はじめに

GmailでZIPファイルを添付する際、ファイルサイズ上限の25MBに引っかかってしまいました。

なんとかしてメールに添付したい!ということで少しでもファイルを小さく圧縮させる試行錯誤の末に、元サイズ26MBから24MBまで小さくすることが出来たので、そのテクニックを紹介しようと思います。

(ネタ色が強いので、本当に困っている方はファイル転送サービスやGoogle Driveの共有機能を利用することを推奨!)

続きを読む