こんにちは!としです!
気づいたらAWS 大阪リージョンが公開されていました。
東京リージョンが登場したのがちょうど10年前...
同じ誕生日に出してくるとはなんだか感動的。
今回は江戸言葉です。
「するってえと何かい!」
このような勢いがある「べらんめえ口調」の言葉です。落語や時代劇で良く使われるので、聞き覚えがある人も多いのではないでしょうか。100万都市の江戸には、武士、職人、商人など様々な身分の多くの人が行き交っていました。テンポよくユーモアもある言葉使いがコミュニケーションの潤滑油にもなっていたようです。
「味噌汁で顔洗って出直してこいってんだ!」
相手があまりにふざけている時に使うフレーズですが、つい笑ってしまいますね。現代に生きる私たちも粋な江戸の会話術、参考になるのではないでしょうか。
さて、江戸ブログではなく、テックブログなので...
現代の言葉を江戸言葉に変換するツールを作ってみましょう。
PythonでGUIを構築できるライブラリ「tkinter」を使用します。
import tkinter from tkinter import messagebox #辞書を定義 edo_dict = { 'ありがとうございます':'ありがとうございやす', 'ください':'くれっ', 'すごい':'すげぇ', 'そうですか':'そうかよ', 'たいした':'てぇした', 'ですか':'かよ', 'ですね':'だぁね', 'ですよ':'だぜ', 'とても':'えれぇ', 'ない':'ねぇ', 'はい':'おぅ'} #ボタンをクリック時に実行 def button_click(): input_value = input_text.get("1.0",'end') #テキストボックスの文字の最初から最後まで読み取る dict_list = [] #変換リスト for i, one_dic in enumerate(edo_dict.items()): #辞書を読み込む input_value = input_value.replace(one_dic[0], '{'+str(i)+'}') #入力値に変換対象があれば変換されるようにセット dict_list.append(one_dic[1]) #変換リストに追加 input_value = input_value.format(*dict_list) #変換実施 messagebox.showinfo("クリックイベント",input_value) #画面に変換結果を表示 #ウインドウの作成 root = tkinter.Tk() root.title("江戸言葉変換ツール") root.geometry("360x450") #テキストボックスの作成 input_text = tkinter.Text(width=40) input_text.place(x=10, y=50) #ラベルの作成 input_label = tkinter.Label(text="粋でいなせな言葉に変換しやす") input_label.place(x=10, y=20) #ボタンの作成 button = tkinter.Button(text="江戸言葉に変換",command=button_click) button.place(x=10, y=390) #アプリの待機 root.mainloop()
コードを実行し、何か言葉を入力します。
変換ボタンをクリックすると、粋でいなせな江戸言葉に変換されます。
とーんときたね!
厳しい寒さが続いておりますが、時折見せる青空や日差しの心地良さに、ふと春を感じる瞬間も多くなってきましたね!
江戸時代は、地球はミニ氷河期の時代でもあり、江戸は今と比べて積雪量が多く隅田川も凍ることがあるぐらいとても寒かったそうです。
さて今回は、Pythonのフレームワーク「Flask」による画像処理APIを紹介します。「Pythonによる機械学習をサービスとして導入したい」といった方々のご参考になれば幸いです。
名称:(江戸)画像合成API
メソッド: POST
エンドポイント: /image_mix/
2つの画像をBase64でエンコードされた形式で受け取り、Flask側でデコードして画像を復元します。その復元した画像を合成し、その合成画像をBase64にエンコードして返却します。
[ { id : 1 image : iVBORw0KGgoAAAANSUhEUgAABk...(base64でエンコードされた画像) }, { id : 2 image : iVBORw0KGgoAAAANSUhEUgAAAK...(base64でエンコードされた画像) } ]
from flask import Flask, jsonify, request import cv2 import numpy as np import base64 from PIL import Image app = Flask(__name__) @app.route("/image_mix/", methods=["POST"]) def post(): layer1_flg = False layer2_flg = False for json in request.json: # リクエストのjsonのidをセット id = json['id'] # リクエストのjsonのimageをデコード img_stream = base64.b64decode(json['image']) # 配列に変換 img_array = np.asarray(bytearray(img_stream), dtype=np.uint8) # 画像として読み込む img_trans = cv2.imdecode(img_array, cv2.IMREAD_UNCHANGED) # 画像を書き込む if id == "1": # 背景画像 cv2.imwrite(id+'_result.png', img_trans) layer1 = Image.open(id+'_result.png') layer1_flg = True elif id == "2": # 貼り付ける画像 cv2.imwrite(id+'_result.png', img_trans) layer2 = Image.open(id+'_result.png') layer2_flg = True else: pass # 背景画像(layer1)と貼り付ける画像(layer2)が存在する場合 if layer1_flg and layer2_flg: # layer1と同じサイズの画像を透過(A=0)で作成 c = Image.new('RGBA', layer1.size, (255, 255,255, 0)) # layer2を指定した座標位置にペースト c.paste(layer2, (780,570), layer2) # 重ね合わせる result = Image.alpha_composite(layer1, c) # 画像を書き込む result.save('mix_result.png') # 画像をBase64文字列にエンコードする with open('mix_result.png', "rb") as f: img_base64 = base64.b64encode(f.read()).decode('utf-8') # レスポンスのjsonにセット return jsonify({'result' : img_base64}) # 対象画像が存在しない場合 else: return jsonify({'result' : "対象の画像なし"}) if __name__ == '__main__': app.run()
きれいにお侍くんが合成されました!(キラッ)
あけましておめでとうございます。
駆け出し社員のkobaです。
とうとう年が明けてしまいましたね。。。
またまた私事になってしまいますが、
去年の11月から2ヶ月半OYO LIFEを使って都内に引っ越していました。
※前回のブログ記事に物件予約〜支払〜賃貸契約の詳細書いてます。
よろしければご覧ください。
今回はOYO LIFEを使って
賃貸契約締結後の入居〜退去するまでの流れ・感想を記載したいと思います。
賃貸契約締結して入居まであと5日となっていました。
入居日があと3日....2日に迫ってきましたが
入居方法がわからない....(どこかに説明の記載等あったかもしれませんが)
メールで問い合わせすると
入居日前日に入居案内のメールでお知らせするとのことでした。
そして入居日前日に入居案内メール届きました。
指定の時間に行けば部屋の鍵が空いているとのこと
これで入居に関して不安がなくなりました!
ちょっと迷いましたが、なんとか辿り着きました。
指定時間ちょっと過ぎてしまいましたが、
入居案内のメールの部屋番号の部屋に無事入居できました!
鍵も部屋の指定の場所に置いてありました
(入居案内のメールの添付PDFファイルに記載してありました)
家具付きの物件を選んでいましたが、
掃除機やアイロン&アイロン台等の生活日用品も備え付けてありました。
服とタオルだけ持っていけば生活できる状態でした笑
入居して感じたのは賃貸物件ではありますが、
ホテルのように生活用品の提供や生活補助してくれると感じました
退去2日前にOYO LIFEから退去の案内メールがきました。
指定時間前に退去してエントランスで鍵を返せばいいとのことでした。
(退去立ち会いしなくていいのは楽ですね)
当初は長いように感じた2ヶ月半.....あっという間に退去日です
とても離れがたく新年早々悲しい気持ちになりました笑
都内に住むのが恐怖心を抱いていた私には
OYO LIFEを使って都内の物件を借りて住むことは
ハードルが低くなり簡単かつ楽でした。
よかったらみなさまもOYO LIFE始めてみてはどうでしょうか?
いよいよ大晦日ですね!
眠い目をこすりながら深夜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月
ということで...
毎年、月の大小や閏月の有無がどうなるか知る必要があったのですが、どのような方法で確認していたのでしょうか。
平和で創造性豊かな江戸時代です。
このようなクイズ形式の大小暦が流行しました。年が明けると、今の年賀状のように、自作の大小暦カレンダーを贈り合っていたようです。
何もひねりはありませんが、僕も一つご紹介。
EDO-OCRを実行すると、現代の小の月(30日)として
2月、4月、6月、9月、11月
が見えてくるはずです?
ちなみに、現代のカレンダーが使われるようになった明治6年以降は、「西向く士(サムライ)」(二四六九士)の語呂合わせで、小の月(30日)を覚えていたようです。
それでは、良いお年を!
今年もそろそろ終わりですね、こんにちはブリスウェルの加藤です。
ブリスウェルは本業はソフトウェア開発なのですが、大きな開発を伴わないプロジェクトを担当する部門を持っています。
エンジニアの人材紹介・派遣・常駐型PJT管理のようなサービスのポーションが大きいので、「人材事業部(HR事業部)」としていました。
この部門は、
などに加えて、
となどを行っています。
書いてみても、やはり開発以外は何でも、行っているのだなと。 ※ ただしもちろん、IT・ソフトウェア・DXに関することであればですが。
昨今、世の中に「デジタル・トランスフォーメーション」が十分すぎる程に浸透してきたのもあり、実態に合わせて、当事業全体の名称を「DX事業」、当部門の名称を「DX事業部」と変更することにしました。
2019年ころまではクライアントとのMTGで「DX」と言ってもまだ浸透していないことが多く、ソフトウェア・ファースト、ソフトウェア・ドリブンだとか、インターネットを経営に取り込むだとか説明が必要で、貴重な時間を費やしたものです。
まるでTV CMのネタのように、デラックスですか?というご質問を受けたことも1回だけあった記憶があります。 せっかくのボケを頂いたのに、うまく突っ込めたか、記憶が定かではありません。
結果的に、弊社はまさにDXをやっているにも関わらず、社内ではあまり使って来なかったワードです。
今後も、ソフトウェア開発部門には営業専任担当者がおらず、DX部門内に持っていることには変わりないので、変わらず外向きの仕事をしていくと思います。
営業部門にも全社にも若いメンバーが多いので、この時期に毎年バズる古典と、今年の新曲とを貼っておきます。
どうもこんにちは。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サイトからのチュートリアルのデータベースを使います)
今回の話はアソシエーションの長所と短所ですので、実際の使い方を言及しないと思います。興味がある方、上記のリンク直接参照してください。
①使い方が簡単:
一回テーブルクラスにアソシエーション定義してから、いつでも、どこでも適用できます。
②ソースが分かりやすい(自然言語ちょっと近くと思います)。
<?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 のレコードが存在すればそれも取得ことができます。
①オーバーヘッド
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)はメモリ問題発生しなくても、下記のパフォーマンス発生します。
(2-3)は(2-1)よりパフォーマンスが良いですが、Indexも使えないですのでデータ容量が大きくなったら実行時間どんどん長くなります。
処理によって、どちら適用方がいいか考えください。
簡単画面・パフォーマンスあまり影響しない場合はアソシエーションを使う方が楽です。
複雑処理・件数容量が多くの場合はアソシエーションを使うのは遠慮してください。
テーブルのカラム数が多くの場合もアソシエーションを使う時にちゃんと、「fields」オプションで、対象のカラムだけ取得してください。 そうしないと、全カラム取得して、また帯域幅がかかりますので。
こんにちは、naoyaです。
気づけば今年も残す所あと僅かですね。
もう一年が終わるのかという気分で、年々体感時間が短くなっていくことを実感しています。
さて、今回は弊社が開発した「アイカタ」について、印刷業向けの機能紹介をさせていただきます。
受発注管理システムとしての機能を備えたクラウドERPパッケージです。
柔軟なカスタマイズ性により中小企業様やスモールスタート向けの業務システムとなっています。
顧客や外注先などの取引先や社内の情報を始めとして、印刷/製本などの各工程に利用する機械や資材の管理も可能です。
校正や受注状況の管理や、見積書の作成をすることが出来ます。
見積書は案件ごとにまとめて管理され、いつでも出力を行えます。
デザイン/プリプレス/資材(用紙)/刷版/印刷/製本作業/納品手配 の各種工程に必要な仕様の情報を1画面で管理できます。
仕様で設定した日程情報を現場でリアルタイムに閲覧可能なスケジュール画面や、アプリも開発中です。
マスタに登録した商品や資材の入出庫を記録し、在庫の管理が出来ます。
また、shopifyで作成したECサイトと連携して注文や在庫情報を連動させる機能を開発中です。
案件毎に売上の作成や請求書の出力、外注先単位で集計した支払の作成を行うことが出来ます。
会計freeeと連携することで発注/売上などの会計情報をfreeeに登録することが可能です。(12/21現在、freeeアプリストアへの申請中のためまもなく正式に利用開始となります。)
下記ページからお問い合わせ頂くことで実際の機能をお試しいただくことが可能です。
お気軽にお問い合わせください。
「業務のアイカタであり続けたい」
印刷業向け総合管理システム
どうもこんにちは。ブリスウェルの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:以下図のような構築にしたいですが、一番簡単なやり方はなんでしょうか。
プロジェクトAを作成するには、左ペインでCollectionsを選び、「+ New Collection」をクリックするだけ。
ダイアログが表示されるので「Project A Dev」という名前を記入してCreateを押下
次は「groups」というフォルダを作成してみよう。
またダイアログが表示されるので「groups」というフォルダを記入してCreate。
同じやり方法で「users」のフォルダーの作成を行なってから、2つのフォルダーが定義されました。
今回の記事では説明するためにローカルに環境しました。
・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が作成されました。
問題2:認証A P Iを実行するごとで認証トークン値をコピーし、他のA P Iに手で入力したくなくて、どうやってやりましょうか。
Auth APIは以下の形式のレスポンスを返却します。
access_tokenは認証トークンで、「Search Group」A P Iとかではこの認証トークンをリクエストヘッダに含めることが要求されます。トークンはAuth A P Iを叩くごとに変わる可能性があるため、それを織り込んだテストを検討する必要があります。
認証トークンを設定する
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}}」と記入
→設定方法は終了でした。
A P Iを実行するごとに認証トークンを{{access_token}}に置き換えます。
access_token変数を、全てのリクエストから呼び出せるトークンとして設定
これから「Search Groups」A P Iとかで、また情報を「access_token」に入力必要ありません。よかった!
問題3:ローカルとテストの環境で同じAPIを実行し、テストし、設定と使い方はなんでしょうか。
環境から定義します。右上の赤枠のイコンボタンをクリックします。
環境管理ダイアログが表示するので「Add」を押下
それぞれ環境名、環境変数と変数値を入力します
基本的に2つの環境情報をセットしました。したら、認証A P Iのtestsタブで内容をちょっと修正してください
目的は認証A P Iを実行する時は選んだ環境で「access_token」の値を置き換えます。U R Lは上記画像のような値を変更してください。他のA P IでURLにも変更必要あります。
「domain_url」と「access_token」を環境変数に設定すると。それぞれ{{domain_url}}、{{access_token}}として参照ができます。
ローカル環境とかテスト環境とかでテストする時に右上ドロップダウンに該当環境を選べます。。
いろいろ便利に使えそうです。
・問題4:チームやA P I利用者とテストを共有したいですが、共有方法はなんでしょうか。
Collectionをエクスポートするには「Export」をクリクします。するとエクスポート形式を選択するポップアップが開きます。 環境変数をエクスポートするには赤枠のイコンをクリクします。変数ファイルはダウンロード出来ます。
Collectionと環境変数をインポートするには以下図の赤枠をクリックします。
最後に 簡単に接続するだけでなく、環境変数などを使うことでめちゃめちゃ便利に使えるPostManをぜひ活用していきましょう!
こんにちは、加藤です。
さて急に本題です。 「プロセスを共有するところがお金を稼ぐメインとなる」という概念の「プロセス・エコノミー」を説明するけんすうさんのブログがありました。
この記事はC向けのエンタメ・コンテンツについての考察なのですが、われわれのようなBtoBのビジネスサービス企業のビヘイビアにも全く同じ事が起こっています。
例としてブリスウェルで行っているPJTのうち、「コンサルティング」や「ラボ型開発(チームをまるごと提供してソフトウェア開発すること)」あるいは「AIのプロジェクト」は、そのアウトプット(成果)も勿論ですが、プロセス(過程)やナレッジ(知見)の共有自体に大きなバリューがあります。
コンサルティング業界においては、随分と昔から社内の評価基準において成果主義の側面をことさら強調されてきたものですが、今は社外との関係性においては成果に至るまでのトライアルの過程を共有することが重要であると強調されるようになってきています。
※ 成果を出すのはあたりまえという前提を話し出すとキリがないので、今回はスルーします。
ソフトウェア開発やAIに至っても、ソフトウェアが動くことやAIが価値を出すことが最重要であることは変わりないのですが、構想・設計・開発・検証などのプロセス自体をステークホルダーと共有することが大きなウェイトを占めるようになりました。
企画の視点、PJTの進め方、期待値のコントロール、開発手法など最終成果物以外のプロセスにお金を払って頂いていると言っても過言ではないのです。
プロセスを共有していくことで、ステークホルダーを巻き込んでいくことに繋がり、ひいてはアウトプットの品質向上に繋がります。
(これだとアウトプットエコノミーのままなので、切り離して考えるとすると、もとい)プロセスを共有していくことで、ステークホルダーを巻き込んでいくことに繋がり、更に能動的にプロセスを楽しんで貰えるようになったりします。
似たようなアウトプットを出す複数社からブリスウェルを選んで頂いている場合、もしかしたらQCDでもなく、担当者の人柄でもなく、プロセスの楽しさで選んで頂いているのかもしれません。
※ くどいですが、クライアント企業に対してのサービス提供に関して、「プロセスを共有すれば、ステークホルダーを巻き込んでいれば、アウトプットの価値は程々で良い」とは言っていません。われわれは最終成果に大きくコミットしている企業であることは強調しておきます。
ソフトウェア開発で業績向上(成果)を求めていらっしゃる企業の方、試行錯誤過程(プロセス)も一緒に七転八倒して頂ける企業の方、どちらもご連絡をお待ちしております。