はじめに 開発部の tasaki です。Python 3.7 のリリースが今月末に行われるということで、あらためて 2018 年現在の Python のパッケージ構成におけるベストプラクティスについて検討してみたいと思います。 対象読者 この記事は、 書き捨ての Python スクリプトなら書けるが、ちゃんとしたパッケージの作り方がよく分からない 公式リファレンスのモジュールの章を読んだが、結局具体的にどういう構成にすればよいのか分からない setuptools.setup 関数の大量の引数のどれを使えばよいのか分からない というような人を対象としています。 対象バージョン 処理系とツールチェーンのバージョンは、 Python 3.4 （2014/03/16 リリース）以降 pip 8.1.2 以降 setuptools 19.2 以降 を対象とします。 EPEL の python34,

大阪オフィスのYui(@MayForBlue)です。 S3+CloudFrontの構成で静的サイトを構築していてハマったところがあったので書き留めておきたいと思います。 CloudFrontのURLにアクセスしてもS3のURLにリダイレクトされる S3+CloudFrontの構成で静的サイトをホスティングしたのですが、CloudFrontで指定したドメインにアクセスしてもS3のオブジェクト自体のURLにリダイレクトされてしまう現象になりました。（今回はS3をオリジンサーバに設定して構築しました。） 例えば https://example.com/sample.html　（CloudFrontで指定したドメイン） にアクセスしても https://example.s3.amazonaws.com/sample.html （S3のオブジェクトURL） にリダイレクトされてしまう状態です。 色々

How to Handle your Python packaging in Lambda with Serverless plugins I use AWS Lambda for almost all of my projects these days-from Flask apps and Slack bots to cron jobs and monitoring tools. I love how cheap and easy it is to deploy something valuable. Python is my go-to language, but handling Python packages in Lambda can be tricky. Many important packages need to compile C extensions, like ps

はじめにこんにちは。DATUM STUDIOの安達です。 最近社内で日本語のテキストを用いた自然言語処理でよく質問を受けるのですが、前処理についてはそこそこ同じような内容になるため、本記事では社内共有の意味も込めて前処理に関して用いてきた＆用いれそうな手法を列挙します。 比較的同じ内容を扱った既存の記事としては以下のようなものもあり、読者の方はこれらも参考にされて要件に合わせて取捨選択してください。 自然言語処理における前処理の種類とその威力 – Hironsan自然言語処理の前処理・素性いろいろ 本記事における使用言語、環境は以下の通りです。 ・osx 10.13.6・anaconda 5.2.0・python 3.5.2Table of contents ・形態素解析段階での前処理 ・文字表現の正規化　・URLテキストの除外　・Mecab + neologd 辞書による形態素解析 ・形

pandas.DataFrameは二次元の表形式のデータ（テーブルデータ）を表す、pandasの基本的な型。 DataFrame — pandas 2.0.3 documentation pandas.DataFrame — pandas 2.0.3 documentation ここでは、はじめにpandas.DataFrameの構造と基本操作について説明し、そのあとでコンストラクタpandas.DataFrame()による作成方法およびファイルからの読み込み方法について説明する。 一次元データであるpandas.Seriesからpandas.DataFrameを生成する方法については以下の記事を参照。 関連記事: pandas.DataFrameとSeriesを相互に変換 本記事のサンプルコードのpandasのバージョンは以下の通り。バージョンによって仕様が異なる可能性があるので注意。N

■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等)　だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ

機械学習系の話題が多い昨今ですが、実際触ってみると期待した精度・結果が出ないなんてことはよくあることではないでしょうか。 機械学習特有の性質として、データ自体がモデルを変化させ、結果として業務に影響を与えたりします。 仮に、機械学習屋さんが精度が出るモデルを構築したと言っても、それを導入するときに、システム全体での品質の維持に苦労したりします。 ということで、不確実性の大きい機械学習系開発についての、設計・テスト戦略でどうやってリスクを低減していけるかが一つカギになってくると思い、方法論について勉強しましたので、そのメモです。 非常に参考にしたのはこちら。 arxiv.org テストそのもののテクニックなどは、一般的なテスト駆動開発に関する書籍を合わせてをご参考ください。 テスト駆動開発 作者:Kent Beck発売日: 2017/10/14メディア: 単行本（ソフトカバー） テスト駆動P

I have recently written about Clean Architecture and provided an implementation example by Uncle Bob himself. This time, we’ll look at the implementation from a bit different angle — i.e. is it possible to implement Clean Architecture and still take advantage of modern, reactive frameworks like Vert.x? Here it comes! What Was That Clean Architecture Again? Clean Architecture divides our code into

タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ

[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな

あらすじ 今まで OAuth は「認証とか簡単にできてすごいんだなー」程度に思っていました。 しかし仕事でOAuth（に近い仕組み）を実装することになり、雰囲気でOAuthを使うわけにはいかなくなりました。 というわけで、理解しようぜOAuth！ と意気込んで勉強を始めましたが……単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる？ 認証と認可は違う？ OpenID Connectって？ 本記事は、OAuth 2.0 初心者に向けた入門記事を目指しています。 対象読者 OAuth 2.0 の雰囲気すらつかめてない人 OAuth 2.0 の勉強を始めたい人 対象にしない読者 OAuth 2.0 の雰囲気のさらに向こうへ進みたい人 OAuth 2.0 を整理して理解したい人 おすすめ資料 雰囲気でOAuth2.0を使っているエンジニアがOAuth

みなさんローカル環境での開発時は必要に応じて「自己署名入り証明書」（通称：オレオレ証明書）を作成していると思います。 ほとんどは主にopensslなどを使って作成していたりすると思いますが、オプションが複雑で毎回ググったり、そもそもopensslのバージョンの問題などでコマンドがコケることもしばしばあるのではないでしょうか。僕だけですかね（苦笑） 日頃からサーバーサイドのことをやっているわけではないので結構ストレスを感じながらやっていましたが、今回ServiceWorkerをいろいろ検証（「Workbox + webpackでServiceWorkerのオフラインキャッシュと戯れる」、「ServiceWorkerのキャッシュ戦略を考える」を参照）するにあたって調べたところmkcertというツールを発見。使ってみてものすごく簡単だったのでオススメしたいと思います。 github インストール

In an application I am developing RESTful API and we want the client to send data as JSON. Part of this application requires the client to upload a file (usually an image) as well as information about the image. I'm having a hard time tracking down how this happens in a single request. Is it possible to Base64 the file data into a JSON string? Am I going to need to perform 2 posts to the server? S

はじめに 皆さん、OpenID Connect を使った Web 認証/認可システムを実装していて、「サードパーティのライブラリなんかに頼りたくない！」とか「署名を自分でパースして中身見てみたい！」とか「OpenSSL の RSA_verify 呼び出すだけじゃ物足りない！自分で $m = S^e \pmod{n}$ ってやって署名検証してみたい！」って思うことよくありますよね？ ここでは、暗号関連のライブラリを使用せず、OpenID Connect の JWT の署名を自力で 検証した際に調べた内容を備忘録としてまとめてみました。 普通はライブラリ任せにする署名検証の処理も自力でやってるので、「RSA 暗号の数式も知ってるし、ライブラリ使えば暗号化もできる。だけど、平文として指定した hogehoge をどうやってあの数式に当てはめてるのか気になる」という人が読むと、もしかしたら嬉しいか

はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may

TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA

概要 SpringBoot1.3からFully Executable Jarとしてビルドして Linux上のサービスとして簡単に登録できるようになった。 今までは起動シェルを作成し、サービスに登録していたのだけれど これらをすっきりさせることができそう。 設定手順 gradle準備 build.gradleに以下の記述を追加