最近バーチャルユーチュ－バーが人気ですよね。自分もこの流れに乗って何か作りたいと思い、開発をしました。 モーションキャプチャー等を使って見た目を変えるのは かなり普及しているっぽいので、自分は声を変えられるようにしようと開発しました。 やったこと キズナアイさんとねこますさんの、それぞれの声を入れ替えられるようにしました。これによって、ねこますさんのしゃべった内容を、キズナアイさんの声でしゃべらせることができます。(逆も) 機械学習手法の一つであるCycleGANを用いて、変換するためのネットワークを学習しました。 パラレルデータ(話者Aと話者Bが、同時に同じ内容を話した音声)が必要ありません 。YouTubeから拾った音声でも変換ができます。 当然ですが、一度学習すれば、利用時には何度でも繰り返し利用できます。 期待できる効果 見た目だけでなく、声まで美少女になれます。やったね。 他にも

GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English

自分用にメモしておく コマンド実行 CMD1; CMD2, CMD1 && CMD2 ;はCMD1の結果に関わらずCMD2も実行される &&はCMD1の結果が正常な場合のみCMD2が実行される CMD1 || CMD2 - 失敗時に後続コマンドを実行する CMD || printf "%b" "MSG"でエラーメッセージを表示する エラーメッセージ表示後exit 1したい場合 = CMD || { printf "%b" "FAILED.\n" ; exit 1 } CMD || printf "%b" "FAILED.\n" ; exit 1と波括弧無しで書くと期待通り動作しない（CMDが成功時もexit 1してしまう） CMD & - バックグラウンド実行 CMD &で[1] 4592のようにジョブ番号とプロセスIDが表示される killしたければkill %ジョブ番号 か kill

一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ

Windows10のPC(TOSHIBA R632/H)にUbuntu16.04のデュアルブートさせようとしたら妙なことになった話。LinuxデュアルブートUEFIWindows10Ubuntu16.04LTS 先輩方の記事を見て自分の試行錯誤もまとめておこうと思った。 自分の機種も大学で推奨されていたPCである。 (実はそれ以外のPCを買うならデュアルブート可能な機種にしてくださいと言われたのに 推奨PCがデュアルブートできなかったというオチがついてしまったことは黙っておく。 結果VMware Playerを使用して講義を行っていた。) 実は発見したのは数年前でWindows8の段階でも同じ結果を得ており、こんなところに書き込んだことがある。 というか記事の内容はかつてWindows8とUbuntu14.04で起きたことをまとめたものである。 しかしWindows10とUbuntu MA

はじめに 気がつけば今年も四分の一が終わり、少しずつ春の足音が聞こえてきましたね。 この時期は環境が大きく変わる人も多く、特に新社会人になるみんなは「楽しみ」だったり「不安」だったりとそわそわしているに違いありません。 僕も14卒のエンジニアとして今の会社に入社したのですが、この時期は不安でいっぱいでした。 この記事はなんなの？ 学生時代、組み込み系を専攻していた僕が、WEBの会社に新卒入社して生き抜くために 「学生時代から社会人になって変えたこと」 を綴っています。 入社当時の僕のスキルセット 「C言語の基本的な構文がわかる」 「Javaを少し触った事がある」 本当にこのレベルでした。 学生時代は組み込み系を専攻していたこともあり授業が「回路設計」「ハードウェア設計」中心だったのでWEB系のスキルは殆ど無かったのです。 「こんなスキルセットで本当にやっていけるのだろうか…？」「仕事につい

追記: 2017/06/06 その後の成果 その後の私達の努力の結果、下記記事のコードよりさらに高速化されています。近日sgemmのコードを公開する予定です。 また以下の記事ではraspiのgpuを活用する事で画像認識等が速くなるはずだという事を言いましたが、その後以下のような成果が出ています。ConvolutionやActivation等もGPU上で実行するようにしています。 Object recognition camera with GoogLeNet, a 1000-class image classification model, running locally on #RaspberryPi 3 pic.twitter.com/WP99ePpfrM — 中村晃一 (@9_ties) 2017年4月29日 Raspberry Pi Zero version pic.twitter

MSYS の後継（？）とも言える MSYS2 では開発環境を 32bit と 64bit で併設できるらしい。 MSYS2 installer msys2 : MSYS2 GitHuB ページ Alexpux/MSYS2-packages : MSYS2 パッケージのリポジトリ Alexpux/MINGW-packages : MinGW 32/64 bit パッケージのリポジトリ MSYS2 / Wiki / MSYS2 installation : インストールガイド 追記 最近来られた方，古い記事でごめんなさい。 この記事については私のブログでフォローしています。 こちらの記事で分かりにくければ向こうも参考にしてください。 MSYS2 による gcc 開発環境の構築 ― MSYS2 のインストールから初期化処理まで — しっぽのさきっちょ | text.Baldanders.info

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag