Colabでウェブアプリを実行する
Google Colaboratry は機械学習向けの実験環境で、とても便利なんですが、そこで構築したモデルやツールのデモなどで、Colaboratry 上でウェブアプリや API を一時的に公開したいことがあります。 そんな時、今までは ngrok などの外部サービスを使って、半ば強引にポートを公開していたのですが、実はそんなことする必要がないことを知りました。 サーバーの立ち上げ まずは公開したいサーバーを立ち上げます。バックグラウンドで実行して欲しいので、 nohup と & を使ってやります。 PORT = 8000 PATH = '' # 検証用に適当なサーバーを立ち上げておく !nohup python3 -m http.server $PORT > server.log 2>&1 &
テーブルデータに対して、DenosingAutoEncoderで精度向上 - にほんごのれんしゅう
データセットの問題 Kaggle Porto Seguroでは問題となっている点があって、テストデータとトレインデータのサイズの方が大きく、トレインだけに着目してしまうと、LeaderBoardにoverfitしてしまう問題があります。 これはトレインだけで学習するために起こる問題で、テストデータ・セットを有意義に使う方法として、教師なし学習でまずは次元変換やなんやらを行うという方法が有効なようです。 ディープを用いることでいくつか有益な変換操作を行うことができて、「すべての情報は何らかのノイズを受けている」という視点に立ったときに、恣意的にAutoEncoderの入力にノイズを乗せ、それを除去するように学習するとはっきりと、物事が観測できるようになったりするという特徴を利用しています。 図1. よくある画像の例 画像の利用からテーブルデータの利用に変換する操作を行います。 このテーブルデ
データアナリストが育てるDWH
[オンライン開催] Retty ✕ Mercari Analyst Talk Night! 登壇資料 https://mercari.connpass.com/event/218848/
2015年頃のWeb開発者がやりがちだった、DockerをVMと同じように使うのは便利だけど辞めたほうが良いという話 - inductor's blog
Dockerが普及し始めて、Docker Composeによって開発環境が簡単につくれるようになった2015年頃から、DockerはVagrantの置き換えツールとして使われることが増えてきました。 Vagrantを使うことでサーバープロビジョニングのときに発生する初期構築を全てスクリプト化し、プロジェクトメンバーの開発環境構築のコストを削減することができますし、設定がGitに残るのでメンテナンスも比較的容易です。そのため、自分の認識ではVagrantの一番の特徴はVMのパッケージングにあると思っています。 一方、Dockerはアプリケーションを動かす環境を配布するための仕組みとして普及しました。どちらもベースのイメージから必要な処理を流す点は同じですが、DockerとVagrantでは開発者が利用する上では体験の面で見ても以下のような違いがあると思います。 Vagrantは仮想マシンをV
1998/03/04
ソフトウェアのレビュー 先日はバグを見つける事について話した． 今日もちょっと関連してソースコードのレビューについての話だ． プログラマであるわたしはプログラムを作る．それと同時にバグも作る．一番いいのはバグを作らない事だが，残念ながらだれしもバグは作る．どのようにしてバグを作り込むかを分析すればひょっとしたらバグを埋め込まないプログラムの作り方を発見できるかもしれないが，現時点での研究もバグに関する理解も進んでいないので当面はバグはそこにあるものだという前提で物事をすすめていかないといけないであろう．とはいうものの，バグの少ないコードを書くプログラマも世の中にはいる．できればそのコツというかノウハウを学びたいものであるが残念ながらそれはある種黒魔術のようなもので素人には手が出せない神秘である． バグを埋め込んだのならそれをできる限り早く発見してできる限り早く修正したい．ソースコード１００
SQLBoiler（とoapi-codegen）でつくるREST APIサーバ | フューチャー技術ブログ
ライブリッツの筒井です。 GoのORマッパー連載、折り返して5日目です。 SQLBoilerを使用したDBスキーマ駆動なREST APIサーバの開発ワークフローを紹介します。 なぜSQLBoilerを選ぶのか?自分たちのチームでは、REST APIサーバを開発する際にはまずデータベースのテーブル設計から始めることが多いです。その次にAPI定義の設計へ入るのですが、既にテーブル定義は出来上がっているため、なんとなくSQL文が頭に思い浮かんだ状態でAPIのRequest / Responseを考えることになります。 ゆえにORMに一番に求めるのは、「いかにストレスなく思い描いていたSQL文を実行し、Goの文脈に持ち込めるか」ということです。 この基準を元に、次のような観点からSQLBoilerを選定しています。 複雑なSELECT文でDSLに苦悩したくない前述の通り、我々の頭の中にはなんとなく
新規事業におけるWebAPI開発をよしなにリードする方法
新規事業×WebAPI開発に立ち向かう話 よしなに @shibadog39
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
