General AI Challenge で爆死しそうになりながらBizSparkの登録コードを提供してもらった話
全国65,535人くらいの黒髪貧乳ツインテール美少女のみなさんこんにちは!
もぐもぐ。
要点
- General AI Challengeの参加者はBizSpark登録コードがもらえる(かも)
- BizSparkアカウントがつくれるとAzureだけでなく、Microsoftの各種ソフトウェアが使える特典も!
- 登録コードの発行には一週間くらいかかるかもなので、機械学習の論文を読みながらゆっくり待つべし
- BizSparkの申請に失敗したら、Microsoftアカウントの再発行が必要
- Twitterで悲しみにくれてたら助けてくれるGoodAIのサポートお姉さまはネ申
ことの顛末
General AI Challengeに参加しようと思ったところ、ありがたみのある文字列が!
To train and test your agents, you will be given free access to Microsoft Azure cloud space, provided by our technological partner Microsoft Czech Republic and Slovakia. To get started using Azure Cloud, get in touch with Tomas Prokop at b-toprok@microsoft.com and attach a copy of your registration confirmation e-mail.
Tomasさんにメールを送るとMicrosoft Azure を使わせていただけるらしい。 さっそくメールして、オナシャスと頼み込んだが……
You will need to register as a startup in our BizSpark program. Please send me your startup name and I will generate an enrollment code for you.
なるほどー。BizSpark Programに登録する必要があるのかー。
BizSpark programに登録してからenrollment code を登録すりゃいいのかな?(ポチー -> REJECT!
ここでBizSparkがスタートアップ支援のためのサービスだと気づく!!!
あ……(察し)
会社名とか勤務先のヤツ書いちゃったじゃねーか!!! アバババ…(あほ)
re-applyしたい人はhelpみてねーと書いてあるが、どこにも書いてない!!! ツラい!!!!
申し込みのページを何回表示してもm9(^Д^)プギャーしか表示されず…。
そしてBizsparkの日本問い合わせ窓口に連絡するも、気が動転してFwd形式の件名でメールを送るという痛恨のミス。(あとで気づいたが、gmailの転送機能を使うと件名が省略されるので、ちゃんとメニューから選択する必要がある)
ミスに気付いてTomasさんにstartup nameを適当に決めて送るも、とき既に遅し。
BizsparkからもGoodAIからも両者返事がないまま2日が過ぎ、機械学習にチャレンジするどころではない状態に。 うわーどうしよー。どーしよー!!!
@idkqh7 let me know if there is an issue with BizPark I can help with. Feel free to send me details at olga.afanasjeva@goodai.com
— olga afanasjeva (@AfanasjevaOlga) 2017年2月21日
オルガさん神か。Oh! My Godness!!!
事情を説明して念じながら送ったところ(I don’t know what to do. Please help me! なメール)、BizsparkからもGoodAIからもサポートの返信が!!!
神か。神なのか。Oh… My Godness…
Bizsparkのサポートさんによると、
- BizSparkの申請に失敗したらMicrosoftアカウントの再発行が必要に
- enrollment codeの登録はちゃんと最初にしてねー!(ドキュメント添付)
超感謝🙏
少し遅れて、GoodAIからもenrollment codeが送られてきた。
Thank you so much. 🙏
まとめ
- General AI Challengeの参加者はBizSparkアカウントがもらえる(はず)ので、startup nameについて聞かれたら、自分で適当に決めて送ろう
- enrollment codeが来るまで、慌てず騒がず一週間ぐらいは待とう
- もし間違えてBizSparkに登録してリジェクトされた場合は、新しいMicrosoftアカウントを用意しよう
- 貰えなくてもテンパらない。慌てず騒がず、Twitterに書き込んで(チラッ しよう
- ちゃんと申し込みページの規約をみよう
関係者の皆様お騒がせしました。
私のミスで登録不能になってしまったにも関わらず、ご丁寧な対応をしていただき誠にありがとうございます。
余談:お姉さまが人工知能じゃないかと最後まで疑っていた。
Visual Studio Code で Vue の開発環境を整える
全国65,535人くらいの凄腕ハッカーフレンズの皆さんこんにちは!
たーのしー!
概要
Visual Studio Code での Vue の開発環境を整える。今回は特にQuasar Frameworkにおいて、lintやコード補完が動くことを目標とする。
- ファイル保存時に自動でコードフォーマット&lintのfix
- よく使うものはコード補完
必要なもの
vscode上のextension
- HTML Snippets …HTML5のコード補完
- ESLint … jsのlint
- language-stylus … stylusのvscodeサポート
- vetur … vueのvscodeサポート
- VueHelper … vueのコード補完
stylintについて
正直いい感じのプラグインはないが、必要な人は下記を使用
- doiuse
vscodeの設定
settings.jsの設定を抜粋
/* Html, JavaScript, Vue */ "files.associations": { "*.vue": "vue" }, // vueにcssのemmet追加 "emmet.syntaxProfiles": { "vue": "css" }, // vueだけで追加したい設定 "[vue]": { "editor.formatOnSave": true }, "eslint.enable": true, // 適応するファイルタイプを決定 "eslint.validate": [ "javascript", "javascriptreact", { "language": "vue", "autoFix": true } ], // プロジェクト配下のeslintrc.jsを読み込み "eslint.options": { "configFile": ".eslintrc.js" }, // 保存時に自動フォーマット "eslint.autoFixOnSave": true,
補足情報
files.associationsいらないと思うが、この設定がないとvue内のstyleタグが崩壊する。 また、files.associationsで設定しない場合は、eslint.validateでのlanguage指定をhtmlにする必要がある。 VueHelperの補完が起動後すぐ働かない場合があるが、その場合は空のTypeScriptファイル(.ts)を作成してコード補完してみることで動作確認ができる。
.eslintrc.jsの設定
module.exports = { root: true, parser: 'vue-eslint-parser', parserOptions: { sourceType: 'module' }, env: { browser: true }, globals: { 'cordova': true, 'Velocity': true, 'DEV': true, 'PROD': true, '__THEME': true }, // https://github.com/feross/standard/blob/master/RULES.md#javascript-standard-style extends: 'standard', // add your custom rules here 'rules': { // allow paren-less arrow functions 'arrow-parens': 0, 'one-var': 0, // allow debugger during development 'no-debugger': process.env.NODE_ENV === 'production' ? 2 : 0, 'brace-style': [2, 'stroustrup', { 'allowSingleLine': true }] } }
補足情報
parserにvue-eslint-parser
を指定すること。pluginsの項目にhtml
が存在する場合は削除すること!
まとめ
- vscodeならvetur使おう
- vueにeslintが直接使えないことはeslintの制限なので、パーサに
vue-eslint-parser
指定しよう - Quasar Frameworkまじで凄いので、とりあえずドキュメント読んで!
Unicorn + Usercorn
全国65,535人くらいのダウナー系猫耳フード付き美少女ハッカーの皆さんこんにちは!
性欲を持て余す。
検証環境
OSX Yosemite (iOSでも動かしたいならMacを開発環境にしておくと良い)
Unicornとは
本当にUltimateだからヤバイ
Unicornのビルドとインストール
git clone https://github.com/unicorn-engine/unicorn brew install pkg-config glib cd unicorn ./make.sh sudo ./make.sh install
ついでにテストしてみる。(Fedoraとかだとライブラリのパスの問題でテスト通らない)
brew install cmocka
make test
go言語のバインディング動かしてみる
brew install go go get -u github.com/unicorn-engine/unicorn/bindings/go
package main import ( "fmt" uc "github.com/unicorn-engine/unicorn/bindings/go/unicorn" ) func main() { mu, _ := uc.NewUnicorn(uc.ARCH_X86, uc.MODE_32) // mov eax, 1234 code := []byte{184, 210, 4, 0, 0} mu.MemMap(0x1000, 0x1000) mu.MemWrite(0x1000, code) if err := mu.Start(0x1000, 0x1000+uint64(len(code))); err != nil { panic(err) } eax, _ := mu.RegRead(uc.X86_REG_EAX) fmt.Printf("EAX is now: %d\n", eax) }
go buildして動くか確認。
Usercornのビルド
git clone https://github.com/lunixbochs/usercorn cd usercorn brew install capstone go get github.com/bnagy/gapstone go get github.com/lunixbochs/fvbommel-util go get github.com/lunixbochs/ghostrace/ghost go get github.com/mgutz/ansi make
go get github.com/lunixbochs/ghostrace すると '''zsh ../../../go/src/github.com/lunixbochs/ghostrace/cli.go:25: undefined: ghost.NewTracer ''' みたいなエラー出るので、ghostrace/ghost指定してます。
Usercorn動かしてみる
./usercorn bins/x86_64.darwin.macho
正常な場合の出力結果。
hello with printf: world args (1): 0 @0x809bc3 = "_=[実行パス]" test: hi strcmp: -1, 1, 0 file test 1: success file test 2: success success
まとめ
COOOOOOOOOOOOOOOLLLLLL!!!!!!
Elasticsearch ELK Stack 始めようとしてみた
全国65,535人くらいの猫耳系プログラマ美少女こんにちは!
あざとく生きてください。
Logstashとは?
ログを集めるすごいやつ
Elasticsearchとは?
検索できるすごいやつ
Kibanaとは?
見た目がかっこいいやつ
やってみる
ここ参考にvagrantでぽちぽち。
git clone https://github.com/comperiosearch/vagrant-elk-box.git cd vagrant-elk-box vagrant up vagrant provision vagrant ssh
とりあえずkibana起動まで確認。データ入れてごにょごにょやってみるのはまた今度。
最近のWeb技術動向についてまとめる
はじめに
世はWeb戦国時代! ……分からなすぎてツライ。
結論
目的にあったフレームワークを使うべし。 SPAのフレームワークとして、Railsはオススメしない。
【5月31日追記】
ただ、ActiveRecord使いたい人はRails使ったほうが良い(WebAPIサーバとして)
キーワード
- SPA
- Ruby on Rails
- Meteor
- AngularJS
- React.js
Web戦国時代におけるそもそも論
【開発言語による派閥】
- ECMAScript(JavaScript)で統一 = Node衆
- Python/Rubyの有名フレームワーク使用 = LL衆
- 神、故に仕様は移り気 = PHP衆
- Java, Scala, Go, ... まだまだいっぱいあるんやで(ニッコリ =ニッコリ衆
老害とマイノリティには辛い世界だぜヒャッハー
今回は、Node衆とLL衆(特にRails)を対象にする。
Q.そもそもJavaScriptでモダンな開発とか無理じゃない?
A.ECMAScript 6で、classとimportがとうとう追加。ワンチャンアルッショ
【JavaScript Webフレームワークについて】
「できること増えたしNode.jsあるし、もうJavaScriptだけでいいよね」 → AngularJS
PhantomJSなどでサーバサイトから静的なページを返せない限りSEO的にはツライ。 ただ、開発言語をフロントエンドで統一できるようになった。
【Webページのはやり】
SPA(Single Page Application)
1ページで完結したWebアプリケーション。
「ああ、でっかいFlashが1個乗ってるだけのサイトあったなぁ……」
↑見た目はまさしくこれ。JavaScriptで同じ歴史を繰り返している。 なお、「SEO的にどうよ?」っていうだいぶ昔に見た議論が繰り返されている模様。
【SPAを実現するために】
jQueryでDOM書き換えまくりとか死ぬ
「VirtualDOM(差分更新)でなんとかしよう!!!」 → React.js
救世主登場。SPA時代突入。当然、SPAは静的ページではないのでSEO的にツライ。 更に「最初のアクセスはサーバサイドレンダリング、そのあとのページ遷移はSPA」みたいなものまで現れている。
俗にいう、Isomorphicみたいな感じのヤツですねホント。
「なんか見たことあるぞ」という人、そうですMeteorですね。時代がやっと2012年に戻った。ファッ!?!?!?!?!
※引用の引用でMetor(Isomorphicな開発環境)が求められる背景を抜粋
- 普通のWebでは状態が画面遷移でリセットされてしまうことが辛い
- バリデーションをフロントエンド・バックエンドの両方で実装しなければならない
- フロントエンドだけのスキルでは不十分。バックエンドの実装が特に面倒くさい。
- フロントエンド・バックエンドを別々に勉強するのではなく、同時に作っていくイメージで開発したい
【開発手法について】
どんなに頑張っても、サーバサイドから分離できないビジネスロジックがある。そんなものを無理にIsomorphicにすべきじゃないよね。
「じゃあ、サーバでよく使う機能をAPI化すればフロントエンドの変更にも対応できるし、バックエンド資源も再利用できて嬉しいよね!!!」
フロントエンドとバックエンドを分けて開発しよう!!
何年戻る気だ。
フロントエンドとバックエンド
というわけで話は現代へ。
最近よく見るSPAの構成で
- フロントエンド : AngularJS
- バックエンド : Ruby on Rails
という構成がある。「そこまでしてRails使いたいか」と思ったのは俺だけではなかった。
結論から言えば「イケてる機能使わないとか損でしょ」という感じだが、SPAの構成として勧めるべきかといわれると悩む。MVCフレームワークとは何だったのか。
「なんでもできるフレームワーク」は「何していいか分かんない」
正直、バックエンド用途として使う分には重厚長大すぎる感じがする。喩えるならば、豚も鳥も魚もブチ込んだラーメンのスープ。
つまり、Go言語の時代が来たということだ。
最近のWeb技術動向まとめ
基本的には、テストのしやすさが一番大事。「フレームワークinフレームワーク」の構成は個人的に微妙。
【SPAを作りたい!】
- 基本はJavaScriptで完結すべし
- 複雑なビジネスロジックはAPI化してサーバサイドで実装
【SPAでLLなフレームワーク使いたい!】
- フレームワークである以上、想定されてない用途には不向き
- AngularJSと混合した状態でのテストは難しそう?
- bowerもgruntも使えるがメリットはあるのか。使ったほうが管理しやすいか。
- turbolink(ajax)はSPAに必要ない(DOMを書き換えるので)
- asset pipelineも代用品はある。
- SPAじゃない方がSEO的に良いと開き直る
- javaScriptを無効にしても開けるページが正義だと信じる
Javascriptが嫌い? それならDart(なぜか途切れている)
コメントへの補足と回答【5月31日追記】
本記事でいう、「フレームワークinフレームワーク」とは、コメントにあるRailsのビューとAngularのテンプレートが一体になっているヤツです。 正直、これは非常に管理コストが高いと思います。茨の道へGo!
「バックエンドにRailsを使うべきか?」という件ですが、個人的にもActiveRecordはかなり有用だと思っていて、無理やり他のものを使うくらいなら、RailsでさっさとWebAPIの実装をすべきです。
他にも開発実績、慣れやノウハウがあるという点も多くの個人や会社にとって事実ですし、経験者であればJSONを返すものくらいちゃちゃっと作れます。 しかし、「これRails使う必要ないでしょ」と思う実装もかなり散見します。(具体的にいうとヤバそうですが……)
ほとんどコメントされた方と同意見なので、わざわざ繰り返すことでもないんですが「なんでもできるから、とりあえず使っておけ」という風潮を非常に危惧しています。 例として上げた「SPAじゃない方がSEO的に良いと開き直る」というのは本質的な問題で、フレームワークとしてのRailsについて考えたとき、
「SPAじゃないけど、Railsで完結」 vs 「SPAなので、Railsで完結しない」
となると、前者の方が圧倒的に作りやすいです。後者においてもRailsを使う利点は当然残りますが、前者に比べると「ぐぬぬ」感を味わうことが多いです。
「そもそもバックエンドでRails使うなら、SPA以外の選択肢も検討すべし」
というのが、Railsというフレームワークにおける最適解なのではないのかと個人的に思っています。
追記のまとめ
- 「バックエンドにRailsは有用だと思うか?」→有用だと思う
- 「バックエンドにRailsはオススメできるか?」→使っても良いが、ActiveRecord使わないならオススメしない。まずはSPAを辞めることを検討。
他がうんこ
Railsの完成度が非常に高いので、このような回答になってしまいましたが……「エンジニアの仕事も超できる部下に営業ばかりをやらせる上司」みたいなやり方は「確かにそれもありっちゃありだけどさー」みたいな感じです。
フレームワークを選ぶときは「やりたいこと」「できること」「実現する方法」「適切な分担」についてしっかり考えましょうという話でした。おしり。
【Go言語】スーパークラスのget()からサブクラスのメソッドをオーバーライドして使うときの話【Golang】
結論
interfaceを使いましょう!!!
サブクラスのget()を呼び出したとき、出力はどうなるか? (Python)
Pythonで以下のような継承をしたと仮定する。
スーパークラスのget()からサブクラスのメソッドをオーバーライドして呼び出している。
[Class]ー[get]ー[Class: make_string] | | [SubClass]ー[SubClass: make_string]
このとき、SubClassのgetをよびだすと
[SubClass]ー[get]ー[SubClass: make_string]
と呼び出される。
当然、実行結果も以下のようになる。
Hi, Super! Hello, Sub!
サブクラスのget()を呼び出したとき、出力はどうなるか? (Go)
※Goにクラスはないが、structだとかFactory関数だとかそんな感じのヤツを便宜上クラスと呼ぶことにする。
実行結果は以下のようになる。
Hi, Super! Hi, Sub!
SubClassのgetをよびだしても
[SubClass]ー[get]ー[Class: make_string]
となり同じ結果にならないことが分かる。
さきほどの図を見ながら、呼び出しの関係をもう一度考えてみよう。
【Pythonの場合】
[Class]ー[get]ー[Class make_string] → make_stringがSubClassでオーバーライド → get()の中身を変更 → get[SubClass: make_string] ↑ ↑ [SubClass]ー[SubClass: make_string] → スーパークラスのget()を呼び出す → get()オーバーライド成功
【Goの場合】
[Class]ー[get]ー[Class make_string] → get()の中身はコンパイル時に確定 → get()の中身を変更できない → get[Class: make_string] ↑ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ↑ [SubClass]ー[SubClass: make_string] → スーパークラスのgetを呼び出す → get()オーバーライド失敗(そもそもオーバーライドしてない)
つまり、Pythonの場合は暗黙的にオーバーライドされるが、Goの場合は明示的にしかオーバーライドされない。
インタプリタ方式は実行時に依存関係を解析できるので、動的に書き換えていくような実行に強い。 しかし、コンパイル方式では依存関係を実行前に解決する必要があるため、このような書き方を推奨することができない。 (Goだけでなく、コンパイル方式ではよくある話)
解決法: Interfaceを使う。
要は、呼び出してみるまで「メソッドの中身が分からない」という設計は、コンパイル方式のやり方ではイケてないということだ。 メソッドの中身が分からないのであれば、メソッドの中身を明示してあげれば良い。
そこで、呼び出し元を実装クラスに一元化し「◯◯のクラス使うよー」と言う仕組みを考える。
[ImplClass]ー[get]ー[Interface: make_string] [Class]ー[make_string] | | [SubClass]ー[make_string]
get()を呼び出すときはImplClassから呼び出し、ImplClassでどのクラスからmake_stringを呼びだすか決める。 このような仕組みであれば、ImplClassに向かって「SubClass使うよー」といってあげれば
[ImplClass: SubClass]ー[get]ー[Interface: make_string]ー[SubClass: make_string]
という経路をたどるので、コンパイル方式でも実行前に依存関係が自明となる。
実行結果は以下のようになる。
Hi, Super! Hello, Sub!
逆説的に言うと、「引数にクラスを指定することで、呼び出すメソッドの内容が書き換わるメソッド」を自作するときには、たぶんこんな感じになるはず……。
楽しいGo生活を!
結論:interfaceを使いましょう!!(大事なことなのでry)
おまけ: Factory関数使わない版
補足
Strategyパターン?
見返したらまさしくそうなってた。
client-specified self patternとかどうよ?
よく分かってない可能性もあるが、ごちゃごちゃするのであまり使いたくない(分かりやすい方でやればOK)
ここでいうImple構造体をSuper構造体で参照(継承っぽく)しても大丈夫?
やめたほうが良いと思う。あくまでImple構造体は呼び出しのためのワンクッション。
[ImplClass]ー[get]ー[Interface: make_string] ↑ ImplClassが直接依存関係にないのがミソ ↓ [Class]ー[make_string] | | [SubClass]ー[make_string]
参考文献
Write in Goの歌詞を和訳(超意訳)してみた。
Write in Go (Fall 2014) - YouTube
The schedule’s tight on the cluster tonight
So I parallelized my code
今夜クラスタの予定はタイト ならコード並列化
All those threads and continuations
My head’s going to explode
全てのスレッドと継続 頭…爆発しそう
And all that boilerplate
That FactoryBuilderAdapterDelegateImpl
元凶はボイラープレート FactoryBuilderAdapterDelegateImpl
Seems unjustified
Give me something simple
このままじゃダメなんだと
Don’t write in Scheme
Don’t write in C
No more pointers
that I forgot to free()
ポインタ free()はどこに
Java’s verbose
Python’s too slow
It’s time you know
アレどう?
Write in Go!
Write in Go!
Go言語! Go言語!
No inheritance anymore
継承なんてないの
Write in Go!
Write in Go!
Go言語! Go言語!
There’s no do or while,
just for
do while はforで
I don’t care what your linters say
I’ve got tools for that
lintは怖くない ツールある
The code never bothered me anyway
コードで悩まないわ
It’s funny how some features
Make every change seem small
全て小さく 嘘みたいね
And the errors that once slowed me
Don’t get me down at all
だってもうエラーじゃ へこたれないわ
It’s time to see what Go can do
’Cause it seems too good to be true
どこまでやれるか Go言語試したいの
No long compile times for me
I’m free!
コンパイル待たないよ 私
Write in Go!
Write in Go!
Go言語! Go言語!
Kiss your pointer math goodbye
さよならポインタ演算
Write in Go!
Write in Go!
Go言語! Go言語!
Time to give GC a try
I don’t care if my structures stay
On the heap or stack
ヒープやスタックに 興味はないわ
//TODO(Scalability) ミュージックの間奏
My program spawns its goroutines
without a sound
goroutines プログラムを包み込み
Control is spiraling through
buffered channels all around
buffered channels を想い描いて
I don’t remember why I ever once subclassed
サブクラス化の理由が浮かばないように
I’m never going back
戻れはしない
My tests all build and pass
テスト パスしたの
Write in Go!
Write in Go!
Go言語! Go言語!
You won’t use Eclipse anymore
もうEclipseやめよう
Write in Go!
Write in Go!
Go言語! Go言語!
Who cares what Boost is for?
ブーストは黒魔術
I don’t care what the tech leads say
I’ll rewrite it all!
上からの書き直せ指示で残業やめよう
Writing code never bothered me, anyway
コーディング悩まないわ