「OSS」を含む日記 RSS

はてなキーワード: OSSとは

2018-01-20

anond:20180120205252

OSSテレワーク諦めれば腐るほどある

テレワーク諦めれば、有名企業は大体そうだ

テレワークできるとこは相当少ない

 

フリーアプリエンジニアより。

ITエンジニアとしての転職活動

当方スマホアプリ開発者。

現在こんな条件で転職活動中。

オフィス勤務の場合
地雷要素
その他

何かない?

2018-01-17

RDBデータ暗号化(TDE)

MySQL 8.0でデータ暗号化サポートしているらしい。

面倒くさいけど、重たい腰を上げて、まずは実験してみるか。

みんな無料RDBを使う場合データ暗号化はどうやってるの?

 

MySQL以外のRDBMSでは

商用のOracleなどでは、かなり前から使えるようになっています

無償で使えるOSSでは、PostgreSQL9.3~・要NEC提供モジュール)が列単位MariaDB10.1.3~)がテーブル単位でのTDEをサポートしています

また、Amazon RDSでは、MySQLを含め、様々なRDBMSサポートしています

2018-01-12

あなた仮想通貨買ってはいけない

有名人が儲かると言ってたから買いましたか

買うべきではありません。短期利益を回収する投機にはまだチャンスがあるかもしれませんが、資産が二倍三倍になったり億の収入を得るのはもはや難しいでしょう。投機はまっとうな投資にとっては毒です。あなた仮想コインを買うべきではありません。

仮想通貨取引しようと思っていますか?購入しようと思っていますか?

取引と購入の違いがよくわかっていないならまだ買うべきではありません。また調べようとも思っていなら、買うべきではありません

仮想通貨投資投機いくら使おうと思っていますか?

通常投資は余剰金でやりましょうとすすめられます。全生活費を突っ込むつもりでしたか? あなた仮想通貨を買うべきではありません。

十万くらいならなくなってもいいというつもりで買うつもりでしたか? 確かに上手く行けば二倍か三倍くらいにはなるのが今の仮想通貨世界です。ただし暴騰した通貨は暴騰したスピードの二倍から十倍、もしくはそれ以上のスピード暴落します。十万円が五万円や一万円になったときに悔しいとか損をしたと思ったりしませんか? 数円~数十円の価格変動に一喜一憂しない自信がありますか? 二倍か三倍になるのを見越して「なくなってもいい」と言っていませんか? もしどうしても仮想通貨を買いたいなら、投資してもいいと思った金額の十分の一程度から始めたほうがよいと思います

今、人気がある通貨を買おうと思っていますか?

ビットコインは変えないけどイーサリウムなら、リップルなら、トロンなら、リスクなら…と思っていますか? それらの仮想通貨の違いが何かわかっていますか? そして通貨を発行するコミュニティ理念共感しますか? ホワイトペーパーはよみましたかプロジェクトが後悔しているWebページを読みましたか? どうしてその通貨を買うのか、今値段が上がっているから以外の理由を人に説明できますか? できないなら買うべきではありません。

ブロックチェーンが実現する非中央集権化の概念について理解していますか?

理解できないならまだ買うべきではありません。

仮想通貨トークンを発行しているコミュニティに貢献できますか?

コーディングができる必要は必ずしもないと思いますが、翻訳宣伝ものによってはリソース提供などでコミュニティに貢献することが可能です。やってもいいと思いますか? できないけれども、コミュニティから配当を期待して長期保有を考えていますか? それとも単に通貨価値十倍になるのを待っているだけですか? もちろん投資である以上、利益を期待するのは当然です。ですが投資なら投資先のことはちゃんと調べますよね。ただ待っているだけで仮想通貨トークン価値が挙がっていくことはありません。そのコミュニティ健全で、ユーザが増え、規模が大きくなって初めて価値が高くなりますあなたはそれに貢献できますか?もしくはちゃんとしたコミュニティであるかどうかの見極めができますか?

VCから資金調達してどうにかIPOするか大企業に身売りをするしかなかった、そしてそれがものすごく大変だったスタートアップや、マネタイズが難しかったせいで停止してしまOSSを救うかもしれないという意味仮想通貨市場特にICO興隆は非常に期待が持てますしかしだからといってどんなコミュニティにも平等にチャンスがやってくるわけではありません。いままでVC投資家がやっていたことを、一般庶民の私達がやるというのが仮想通貨への投資です。あなたはそれができますか? できないなら買うべきではありません。

2017-12-31

きれいなコードを書くのはやめた

きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。

そうずっと教えられてきたし努力してきた。

でも、もうきれいなコードを書くのはやめることにした。


業界2位のミドルウェアが、、1990年代タイムスリップたかのような継承拒否した継承構造で書かれていた。

世界的なOSSで3桁や4桁のスターがついているリポジトリコードは、コピペの嵐。巨大なマージコミットやFワード入りのコミットメッセージ

有名なスタートアップCTOコードは、メタプログラミング黒魔術の塊だった。

リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。

でも、それはコピペまみれで、巨大のコミットの汚いコードからできる。

自分バグのないきれいなコードを書くように心がけている。

同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。


優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコード要求する。

ダブルスタンダードだ。

他人きれいなコード要求するのは、他人コードを読む時間を短くするためなのだろう。


優秀なプログラマになるために、私もきれいなコードをかくのはやめにすることにした。

2017-12-16

オライリーで本書いたっていう印籠

ところてんさんがこの前書いてた話思い出したけど、たしかにちびると思うわ

 

Google社員の〜

・有名OSSコミッターの〜

オライリーで本出した〜

大学教授の〜

社長の〜

 

オライリー最強すぎる

平伏する

 

こういうのいろんな業界にありそうだな

それは平伏するしか無いみたいなやつ

武道館単独ライブした〜みたいな

M1で優勝した〜みたいな

2017-12-10

俺も音声アシスタンス作りたい

音声認識OSSってどんなもんなんだろ

Googleが出してるかどうか次第か

 

音声は琴葉茜ちゃんでやりたい

2017-12-07

今の20代の男女は結婚とかマジで無理ゲー

20代年収400万は最低限っていうけど、政府統計見てもそんなの20%いるかいないかまで日本経済衰退してるからもっとハードル下げた方がいいよ

20代で400万~1000万くらい稼げてる人らって、残業代かせいでるからね、そんだけ命と時間削ってるから出会いなんてほっとんどないし、恋愛したくても時間すら取れないって人達ばかりだからなおさらレアキャラになるんだよ

例を挙げれば20代後半に来年差し掛かる俺が年収400万ちょっとで、月労働時間160時間くらいだけど、不安定覚悟で高時給技能派遣フリーランスやらないと、これくらいの時間生産性をねん出できないからね、俺とか35歳以降は本気で資産処分してナマポを考えてるくらい、ノーフューチャーからね、当たり前だけど俺みたいに20代で半分フリーランスとか、いい意味だろうが悪い意味だろうがマトモな人間じゃないから、結婚はまずできないし、そんなのとしない方がいいよ、ホント

でも日本はそういう社会になってしまってるから、嘆いたってしょうがないよ、主語がでかいバレバレ大嘘で見栄はる増田とかやたら多いけど、働いてたらわかるけどあんなの90%くらい嘘ってわかるから

普通に考えてもごらんよ、結婚できるギリギリラインが、その年齢層で30%くらいしかいないんだよ?年々自分若さという価値が失われて行くと考えて

22歳から30歳までの8年間で、週1~2回の男探しをして、30%以内を引き当てる確率って、もう1%下回るんじゃないかな、しか第二次世界大戦SOEOSS女性諜報員並に考えて動いても、これくらいになる無理ゲ―で婚活させられてるんだよ、今の女の子たちって

30や40代に広げれば…って考えてるけど、まさにこの世代勝ち組かつ独身探すなんて、家の庭掘ってダイアモンド鉱脈探すレベルってくらいいないからね

ポリコレだのなんだのというつもりはないけれども、幾らなんでもこりゃ日本女性可哀想すぎでしょ、男も女も若い人間はマトモな方法で生きようとしたら誰も幸せにならねーじゃん、政府20代以下は自由が欲しけりゃ国民半グレになれって言ってるようなもんじゃ

共働き世帯年収上げたってマタハラ保育園落ちたのオンパレード、男も、変な上司人間に当たれば即キャリアバキバキ廃人じゃん

若者いじめて何がしたいんだろうね、この国

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2017-11-28

OSS最初の数時間がすべて、みたいな

OSSを書くとき最初の数時間がすべて、みたいな感覚がある。

ファイル構成を決めてMakefike書いて、自動ビルドを設定して、えとせとら、えとせとら、みたいな。

最初のめんどくささが途方もなく高いので、それを乗り越えると、割と惰性でなんとかなる。

(次の壁はテストだけど。。。)

年をとるごとに、最初のめんどくささが超えにくくなってるような感覚がある。

ちょっと久々に勢いでOSS書いたので、そんなことを思った。

2017-10-24

なんで未だに 5.4 なんだよ!

PHP のはなし

ウチでは centos を使うことになってる

今だと centos7 だが、これのデフォルトPHPが 5.4 だ

5.5, 5.6, 7.0, 7.1 とでていて、 7.2 がもうすぐとか言われてるのに、 5.4 だ

5.4 が出たのは 2012 年で公式サポートは 2015 年に終わっている

そんな古いもので、使える機能ももちろん古いのだけだ

新しい機能を使おうとしたらエラーになる

もちろんライブラリフレームワークですら対応してないのが多くて古いものしか使えない

さらには、古いバージョンではバグ脆弱性が見つかってもそもそも PHPバージョン自体サポート切れなので放置される

PHP7 や 5.6 対応バージョンにすれば直っているが 5.4 で動くものだと直されない

centos に 7 系を入れることはできなくはないし、難しくはない

だが、デフォルトバージョンを使うことになっている

聞くところによると、保守OSサポートが切れる頃まではすることになっているものが多く、外部リポジトリや自前ビルドになるとサポートが辛いらしい

今 7.1 にしても、その外部リポジトリはウチの保守期限より早くサポートをやめるのでその後の脆弱性などのパッチ自分でどうにかしないといけなくなる

デフォルトのものなら緊急性があれば 5.4 であろうと OSサポートしているためパッチ対応されるらしい

外部リポジトリサポート終わったらバージョン上げればいいじゃない、って思うけどけっこう動かなくなる部分があるらしい(経験談によると)

プロジェクトが大きくなるとチェックと修正がすごく大変なんだろう、そのためのテストじゃないの?って言いたいけど

自社サービスじゃないしクライアントから人件費取るのが難しいとかあるんだろうな、たぶん

そんなこんなで 5.4 を使うらしい

ライブラリ面で苦があるから、自社製ライブラリも多い

OSSライブラリで何が使えてどれを使ってはいけないか、みたいのはコア部分の開発メンバーには知見が溜まってるらしいが、私はそんな将来に役立たないものより 7 系とか新しいもの知識が欲しい


せめて JavaScript の Babel のようなものがあればなぁ・・・ブラウザは使う側の問題で古いのまでサポート必要だが、サーバサイドは新しいの入れればいいだけなので需要がなくて作られないのだろうなぁ

2017-10-21

むやみに抽象化?するのやめてほしい

え、半日で変更差分が 3 行と 5 行と 20行程度しかないんだけど・・・ じゃないんだよ!

あれこれ調べて試して最終的にそれだけの変更ですんだんだよ!!


引き継ぎもなく会社辞めた人が作ってたシステムコードを渡されてこの修正依頼対応してね、とか言われても作りが意味不明

有名ドコのフレームワークライブラリならともかく、見るからにその人自作らしいもので作られてる

愚直にイベントに対して、あれやってこれやってそれする、って書いてたり、変な上書きはせず UI コンポーネントプロパティ変えればそのまま反映されるようなら簡単に直せそうだったのに、

複雑に継承を重ねたコントロールクラスちょっと見た目変えるだけでも一苦労

値を変えても反映されずに親クラスで変な制御ついてたりするし、現状のものフィットさせすぎてちょっと操作性変えるだけでも大規模に変更が必要そうに見えるし、どこから手を付ければいいのかって状態だし

どこで値が変えられてるとかが追うのだけで時間が過ぎていく

どこがどういう仕組になってるとか、こういう変更ではここを変えればいいとかいう手引きがあればまだましだが、そういうのは全くない

余計なことせず単純にコントロール並べて、単純にデータ取得や保存する作りで作られていたなら1日もあればで終わったであろう簡単修正依頼が1日で1割程度しか終わらない

作った本人はこの方が楽だったんだろうが、他の人が使えないもの作るのはやめてほしい

というか、ファイル名が連番でどのファイルがどの画面に対応してるからすら開いてみないとわからないレベルだったのだが作った本人はこれで苦労しなかったのだろうか・・・

仕様書対応表があったのかもしれないが今あるのはこのコードだけだ


最後まで面倒見れないなら、世間一般の作りに合わせるとか有名どころのライブラリ情報があるものを利用してほしい

退職のつもりなくても、病気とか怪我で代わりの人に任せるとかはあるだろうから出来る限り、独自の作りはやめてほしい

有名どころのOSS並に丁寧なドキュメントFAQとか作れるなら別にいいけど

2017-09-16

例のIssueの話について

これな。今日Twitterでバズってたやつ。

> OSSオーナーからTwitterで是非issueを上げてくれと言われたから頑張ってissueを上げたのに、エアリプで「OSSなのに英語でissueを上げない日本人、本当に空気読めない」と言われ、著名人がそれに「それな」とメンションしてて、もう2度とやらねーと心に誓った。

https://twitter.com/stb_nissie/status/908494673102041088

からない人に説明すると、GitHub(通称ギフハブ)にはIssue(イシュー)という機能があって、なんかバグってたら問い合わせ出来る機能があるんだ。

でも大半のIssueが英語でやり取りされている。勇気をだしてIssueを日本語で立てたけど、あとで作者にエアリプで陰口を言われてすげームカついたって話だ。

でもこれだけ見ても背景がよくわからない。Issueを上げてくれ、っていうやり取りが日本語なのか英語なのかもわからないし、エアリプで陰口言われたのも日本語なのか英語なのかも分からいからだ。これは裏を取る必要がある。

ちょっと調べてみたけど、おそらく発端はこれだろう。

https://twitter.com/takezoen/status/636551825160695808

> IE以外のブラウザではどうでしょうか?また、可能であればスタックトレースGitHubのIssueに上げていただけると助かります

もとのツイート主とGitBucketの作者とのやり取りだ。ちなみにGitBucketとはギフハブクローンで、コンプライアンス的にギフハブが使えないかサーバーを自前で用意して自社でギフハブを使えるようにするものだ。ちなみにギフハブ本家でもそういうクローンは用意しているが高くて稟議が通らないので仕方なくOSS(≒無料)のクローンを使っている会社は多い。

で、作者とのやり取りを経て出されたIssueがこれだ。

https://github.com/gitbucket/gitbucket/issues/908

タイトル英語なのはともかく、本文は日本語である自分経験則からすると、こういうIssueは速攻でクローズされるか放置されるが、それは後述するとして、例のエアリプはおそらくこれだろう。

https://twitter.com/takezoen/status/648914153785044992

> GitBucketに日本語でIssueを投げてくる方が後を絶たない。ドキュメントも周囲のIssueも全部英語なのに日本人空気を読むとか嘘なのではないかという気がする。どうすればいいのだろうか…。

そのとおりではある。ドキュメントを見て、Issueを英語で書かなきゃいけないと思わなかったのだろうか。

新しくIssueを立てるときは必ず「New Issue」というボタンを押さなければならないが、そのときに他のIssueを参考にしなかったのだろうか。

例のツイート主のギフハブを見ても、このIssueがおそらく初めてのIssueと思われる。

https://github.com/SatoshiNishimoto

「なんか問題発見した!」→「世紀の大発見や!」→「Issue投げたろ!」の流れで興奮しながらIssueを立てた可能性はある。初めてのIssueならまさにそうだろう。

しかしたら作者は日本人だったから「つい」日本語でIssueを立ててしまったのかもしれないし、他のIssueも日本語で書かれているか自分日本語でIssueを立てたのかもしれない。

本当のところはわからないが、Issueを立てるときは、一晩寝かせてからIssueを立てるべきだったし、一回失敗したからってめげてはいけない。まあ勇気をだしてがんばったのに全力で全否定されるのは非常につらいものはあるが、そういうときキャバクラにでも行って慰めてもらいなよ。

閑話休題。Issueを立てるときに注意しないといけないのは、まずガイドラインを見ること。次にオープンされたままのIssueがどのくらい残っているかだ。

Issueを立てるときにはたいていガイドラインがある。READMEちゃんと読め。そこにIssueやプルリクを投げるときルールマナーが書かれている。中には日本語OKだったり中国語OKだったりするOSSもあるが、そんなのはほんの一部で、たいてい英語だ。そのルールに外れたIssueやプルリクは大抵無視されるかクローズされる。ルール英語で書かれているということは、Issueやプルリクも英語で書かなければならないということだ。というか、作者にアットツイート出来る勇気があるなら「こんなIssueを投げようと思うのですが、日本語OKですか?」くらいは聞いてもよかったんじゃないか

次にオープンされたままのIssueがどのくらい残っているかだが、ガイドラインほど重要じゃないにしても、結構見て置かなければならない要素だ。オープンされたままのIssueが3桁以上残ってたら、それはIssueさばきが回っていない証拠だ。もしくはググったりドキュメントを読めば事足りるようなどうでもいい内容のIssueが盛りだくさんな可能性もある。最初のうちは書き逃げでも構わないが、凡百のIssueのなかで自分のIssueを読んでもらえる努力しろ

あとこの人、自分のこと意識が低い人間だと思っているけど、有名人に何度もクソリプかましているし、勉強会にもちょくちょく顔を出しているっぽくて、そういうことする人間意識が低いとは言わないと思うんだよ。意識の高い低いを都合で使い分けるのは辞めたほうがいいと思っている。

はいえ、OSSに定期的にフィードバックを投げられる人間はほんのひとにぎりで、一生に一回Issueを立てられるかどうかというプログラマーほとんどだと思う。OSSの作者からしたらそんなの関係いかもしれないけど、Issueを投げるほうからしたら一生に一度の大舞台だ。そこらへんをよく考えてOSS活動に取り組む必要はあるんじゃないかなとは思う。ま、人生に失敗はつきものだ。気長に生きてこうよ。

2017-09-04

CEDEC任天堂セッション求人動向について

全くゲーム業界関係者ではないものの、プログラマの端くれとして関心があったためタイムシフト配信ゼルダの伝説の8本のセッション全部見た(また、他のセッションも色々視聴した)

内容については(増田SNSかは微妙だが)SNSへの投稿禁止、また専門家ではないので言及しない。

興味のある人は是非タイムシフトパスを購入してその目で確認しよう!と言いたいところだが、CEDEC最終日(9/1)の19時が購入期限で今から視聴は不可能である(様々な事情があるだろうし、残念ながら致し方ない)

専門外のため用語や実際の作業として理解できない部分もあったものの、8つのセッション全てプレゼンとしてとても丁寧に整理されており、他業種の私にも参考になる・刺激を受ける部分が多くあった。

内容以外で特筆すべきは、プレゼン資料統一性もだが、十二分なトレーニングを積んだと思われる16人の発表者であろう。

8つのセッション(1セッション1時間なので8時間)で16人発表したわけだが、話す速度、スライドをめくるタイミング含めて完全にコントロールされており、全てほぼ時間ぴったりに発表を終えている。

また、言い間違いや詰まる箇所は合計8時間の中で数えるほどしかなく、資料を見っぱなしということもない。

こういったセッションカンファレンスで必ずしもこのようなクオリティで発表すべきとは全く思わないが、任天堂完璧主義ともいうべき姿勢が見えて尊敬の念と同時に、少し空恐ろしいものを感じた。

セッションの中では、過去カンファレンス論文などを参考にしたなどの言及もたびたびあり、オープンにされた知見への「お返し」という面もあるのかなぁ、オープンソース的な流れを感じる良い話だぁなどと暢気に考えていた。

しかし、そこでとある情報を知った。

次回の転職ドラフト任天堂が参加するらしいのだ。

また、先日のOSC2017京都にも任天堂は協賛しており、求人広告を出している。

OSC2017京都の件については、私は求人広告は注目しておらず、任天堂が昨今のマクロソフトアップル同様、秘密主義からOSSへ歩み寄り始めているのかと思っており、CEDEC任天堂関係者が登壇する、というのもその流れで観察していた。

(ちなみに今年のHTML5カンファレンスへも任天堂スポンサーとして協賛しており、同様に求人広告を出すのではないかと予想している)

ただ、これほど立て続けにこれまで関わりの薄かった他業界への求人アピールが続くと今回のCEDECの講演内容について別の側面から見たくなってくるものだ。

CEDECセッションからという面はあるのだろうが、8つのセッションの多くはこれまでの任天堂の「アイデア」「枯れた技術の水平思考」的なイメージから離れたモダン効率化・自動化を中心としたセッションであった。

実際、セッション内容をまとめた記事を見たと思われる人々から任天堂イメージが変わった、という感想も多く見受けられる。

既存イメージ合致するのはフィールドレベルデザインセッションの一部ぐらいだろうか)

セッションで繰り返し述べられたのは、自動化効率化によって「最後まで何度も調整できた」「クリエイティブ作業に集中できた」ということである

その「クリエイティブな繰り返しの調整」こそ任天堂の元来のイメージに相当する部分であると思われるので、任天堂の開発手法が大きく変わったというのも事実ではあろうが、外部に見せる側面を変えたという印象が強い。

まり既存イメージを強調するセッション行おうと思えば出来たにも関わらずそうしなかったように思えるのだ。

とにかく、メディア記事確認してもわかるが、今回のセッションではブレスオブザワイルド特有面白さの根幹に関わる部分はほとんど出てこない(例えば以前から話題になった2Dマップでの検証化学エンジンに関する内容)

企業秘密から一般化できるようなノウハウではないから?

それもあるだろう。ただここで一つ仮設を立てたい。

8つのセッションは開発の様々な知見からある効果を狙って特定テーマに基づいて選定されているのではないだろうか。

そして、そのテーマはおそらく「ゲーム制作支援する技術(者)」である

先ほど述べた通り、発表内容・資料プレゼンタークオリティ一定以上に統一されて非常に高い。ほぼ間違いなく、開発チーム・制作部署以外の部門も深く関与しており、そのテーマの選定にも関わっていると考えるのが自然だ。

ゲーム自体に関わる部分への知見ではなく、他業界にも理解やすく応用できる内容を意図的に選定しているのではないか

セッションを視聴した人、またメディア記事を読んだ人でこういう感想を持った人も多くいただろう。

「他業種だけど参考になる」

ゲーム以外のソフトウェア開発にも応用できる部分もありそう」

「こういう開発支援ツール作るの楽しそうだな」

「分野は違うけど、自分のやっている(やりたい)仕事と似ている」

自分技術ならもっと自動化効率化できるのに」

「こういう形なら任天堂で働くのも自分でもできるかも」

転職先としてゲーム業界選択肢にしよう」

秘密主義任天堂はある日突然、知見の共有に目覚め、OSS理念共感し始めたのではなく(部分的にはそうなのかもしれないが)、他業界の(優秀な)エンジニアに自社の存在アピールしようとしているのではないだろうか。

自社の技術開陳し、それを一種求人広告とするというのは他のカンファレンスでもよくあることではあるが、今回のCEDECセッションもその面が強いのではないだろうか。

IT企業ベンチャー企業経営者は「参考になる!」とか言ってfacebookTwitter記事能天気シェアしている場合ではない。

平均年収840万の(日本本社とする)世界企業が本格的に君たちとの人材獲得競争に参戦したのである

昨今のコンシューマゲーム業界に対するサイゲームスの立場に近いものを感じた。

ちなみに私はフレックスなし、制服作業着)着用の時点で中途採用への応募は断念した。

今回の内容では余りに任天堂が腹黒いかのような印象を与えてしまうので、補足としてCEDECに関してはセッションへの登壇こそ初めてのものの、任天堂は長年スポンサーとして協賛しており、過去数回基調講演への登壇は行っていると書き添えておく。

また、多かれ少なかれ企業というはこの手のカンファレンスへはある程度作為を持って参加するのが当然のため、私自身は任天堂に他意はない。

ぼくが北朝鮮将軍様だったら

玄関前まで米軍がせまって来て,絶体絶命になった時に,

どうやったら一番アメリカダメージを与えられるかって考えると,

核兵器の作り方をものすごくわかりやすく整理して,

githubに上げちゃうという方法を思いついた.

ソウル砲弾を打ち込むよりも,

東京グアムハワイミサイルを打ち込みよりも

はるか世界を変えるインパクトがあると思う.

ネットに放流した情報は回収不可能だし,

OSSによって改良され続けるのは止められない.

世界秩序は根本からくつがえる可能性がある

2017-08-29

NDAに縛られるフリーランスとは将来を今の金銭に換えることだ

「**社で**の仕事をしています

フリーランスで**の仕事をしています

「**の会社をやってます

勉強会飲み会合コン。あらゆる所で繰り広げられる会話。

あなたはこれを言えるだろうか。

私は言えなかった。厳しいNDA、社名の無い名刺職種くらいしか伝えられない人に相手は興味を持たない。自分だってそうだ。

仕事は人脈か自己PRからしかまれない。自己PRという言い方がfitしなければ広告と言っても構わない。

OSSコミッターや技術blog,書籍を書くようなエンジニアならいいだろう。

だが、業務ビジネスコミットして仕事をするフリーランスNDAに縛られてしまえば、時間とそれまでの経験金銭に換える事にしかならない。

「今何をやってるんですか?」という質問に答えられない仕事をするべきではなかったのだ。

2017-08-18

エロサイトアンテナサイト作ってみた

こんにちは

こちらに投稿するのは3回目ですかね。

過去に書いた記事

二次元系のエロサイトを作ったからいろいろ書いてみる 編集

https://anond.hatelabo.jp/20160225062051

自動更新エロサイトを作ったから自慢させて 編集

https://anond.hatelabo.jp/20150519124614

エロサイトばかり作ってます

懲りずにエロサイトアンテナサイトシステム含む)を作ったので投稿してみました。

作ったサイト

エロ萌えアンテナ
https://eromoe-antenna.link/

こりずにエロサイトです。

しかも今回はアンテナサイトという・・・

サイトを作ったきっかけとか

アンテナサイトは以前から作ってみたいとは思っていたのですが、何しろ情報が少ない。

既存無料システムなどは使い勝手が悪かったり、そもそも(私が思う)アンテナサイトの体をなしていなかったりと、不満がありました。

なら「私が思う」アンテナサイトを作ってみようと思った次第です。

また、1度作ればシステムを流用でき、昔はやった2chアンテナサイトなども簡単に作れるという打算もありました。

(今は下火ですがそれでも収益を上げることはできるので)

※このシステムは実は数年前に完成させたのですがバグだらけで一度頓挫したのを、1から作り直したものなのです。

使った技術

PHP

CSS

JavaScript

MySQL

これだけです。

かれた技術だけで作りました

仕様など

正直「アンテナサイト仕様」という情報はあまりネット上にも書籍などにも落ちていません。

なので私が思う仕様実装しました。

(有名サイトをみて「こうかな?」というのを整理しました。

ですかね。

あとはDBにいろいろ情報をぶち込んだので、後々の仕様変更にも柔軟に対応できるようにしました。

今回のアンテナサイトつくりで、だいぶSQL文の勉強になりました。

DB構造とかもWPなどのCMSを参考にリレーショナル?にしたとり、いろいろカスタマイズやすしました。

IN/OUT比率に応じてアクセスを返す処理についてはかなり悩み、これはみんな情報を出さないはずだなーと思いました。

秘伝のタレ的なものですよ・・・結局「こんなかんじかなー」というのを他サイト経験を元に推測して実装しました。

都度様子を見て変更するかもです。

こだわりの点など

お気に入り機能や、検索機能については結構実は力を入れています

検索機能は実は一番時間をかけています。世の開発者様はすごいですね。

https://eromoe-antenna.link/search.php?page=2&category=3

例えばカテゴリ3の2ページ目を表示、といった複数パラメータを持つ検索条件をどうやったらMySQLで取得するか、といったことや、

それをページャーにどうやって落とし込んでやれば良いのか、といったことがわかりませんでした。

普段WPを使っているので意識してなかったのですが、こういうところも自作システムの悩みどころですね。

あとはIN/OUTでの処理をするにあたり、一通りの情報DBに保存することで、後々いろいろ応用を利かせられるように設計しました。

その他には管理画面を設けることで、サイト更新やお知らせの投稿などを、WP並にとはいいませんが簡単に行えるようにしました。

デザインについて

完全自作です。

もともとPhotoshopで作っていたものがあったのですが、数年前に作ったものだったのでそれを基に開発を進めながら調整していきました。

スマフォサイト対応もしています

エロサイトっぽく?ピンクを使ってますが、正直もう少しやりようはあったかなーって思っています

システムさえできてしまえばデザインは後から変更し放題なので後々の課題ですね。

その他

作るのに1年以上かかってしまいましたが、何とか1システム完成させることができました。

おかげでだいぶ力がついたのではないかと思っています

今まではWPサイトを作ることが多かったので、1からシステムを作り上げて完成させるといった経験は実は皆無だったので、楽しかったです。

今は沢山のOSS無料ツールがあるので、自作する必要性も減ってきているかもしれませんが、実は自分がほしい機能ってピンポイントで無かったりすることも多いのではないでしょうか?

そういったときには是非皆さんも自作ツールを作ってみてはいかがでしょうか

以上、宣伝がてら、普段お世話になっている匿名ダイアリーにいろいろ書いてみました。

意見、ご感想などあればコメントとかくれるとうれしいです。

サイト登録申請もお待ちしています

https://eromoe-antenna.link/register/

2017-08-14

web系の専門用語多すぎ問題

門外漢からするとこんな風に聞こえてる。(所々適当に書いてるし書いてる内容は嘘デタラメ

「gulpでbowerしてsassgruntビルドすれば、cssストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWS連携させてWebGLTensorflowやらchainerやらと組み合わせればブラウザDQNとかA3CとかDCGANも動かせるスクリプトリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsカスタマイズしたりタスクランナープロセスマネージメントできるからもはやjstensorflowを含めたpythonラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinマインングをサポートしていてブラウザ上でウォレットからマイニングセットアップまでできるんだってブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータ分散してサーバーに保存できるみたいなこともあるんだって。」

どうしてweb系は専門用語肥大化するんだ。

2017-08-07

転職精神を病んだ話

自分転職顛末時系列で書きたい。内容は、自分の中で溜め込んでいたもの。録音や証言確保などの対応はとっていたものの、当時は恐ろしさと鬱で動けず、その後は諦観と鬱で、少数と共有する以外は、表に出して活かす機会を作れなかった。ただ溜め込みつつも、恐怖や後悔、憎悪感情がずっと自分の中で渦巻いていて、耐え難くなっている。だからここに吐出させて欲しい。

転職

知り合いに紹介され、20代都内IT企業転職した。新卒から務めた緩い企業から転職不安も大きかったが、当時仕事スキルアップが楽しめており、期待も大きかった。

転職後、すぐ遠方の客先にフルタイム常駐することになった。なおこの出張フルタイム常駐は、数年後退職するまで続くことになる。この常駐先には複数人同僚が派遣されていた。その中で自分リーダーAの下に付き、二人一緒に業務を進めることになった。このリーダーAが後に精神を病む原因となる。

初期

リーダーAは同じく転職入社したばかりで、直属の上司からの期待を強く受けているようだった。初印象は悪くなかったものの、働いて会話を重ねるうちに、以下のような傾向が顕になっていき、怖さを感じるようになった。

なお初印象は良いが、密に・継続的に関わると評価を落とすというパターンは、自分以外でも結構あったようだ。仕事での顧客評価も、概ねこ竜頭蛇尾パターンを繰り返していたと思う。

振り返ると、この時点で危険を感じて逃げるべきだった。そうすれば精神と体が壊れ苦しむこともなかった。ただ自分には、それに気づいて逃げる能力がなかった。

攻撃が始まる

リーダーAと1、2ヶ月働いている中で、怖い傾向はより強まっていった。相手に応じた態度の切り分けも荒が目立つようになり、例えば上司に、気に入らない顧客プロパーについてナイフで刺してやるといった過激な報告を行うようになった。また長く一緒にいることで、報告や悪口に、呼吸するように嘘や誇張を織り込んでいることに気付かされた。例えば自分提案失敗を、叩きやすターゲット問題転嫁するといったことを行っていた。

そして一緒に働いている中で、自分攻撃ターゲットにされるようになった。はじめは、仕事ができない、自分フォロー無用に忙しくなっている、といった仕事の指摘からまり、お前は無能である性格が劣悪であるといった説得を頻繁に自分に行うようになっていった。後に案件仲間から、見えないように、自分悪口を頻繁に上司に展開していたという話も教えられた。

ただ当時、自分は期待される成果を出せていなかったし、転職業界を変えたばかりで、能力的にも問題があると自覚していたので、リーダーAの言葉や怒りに応え自分改善しなければならないと考えていた。また、会社ではパワハラ自慢(こんなにひどいパワハラを耐えた、自分無能パワハラで潰してきたなど)が目立ったので、この程度は転職の試練であり一人で耐えて当たり前のものと考えてしまっていた。この考えは心を壊すまで変えられなかった。

閉鎖環境攻撃エスカレートする

その後、出張状態のまま、リーダーAと二人だけで、別現場フルタイム常駐に移った。後に派遣や準委任メンバーの方が増えたものの、基本リーダーAが管理し、自分が下につく、プロパー二人組で仕事を進める形となった。本社とのやりとりはリーダーAがすべて統括したため、自分視点での会社同僚はリーダーAしか見えない世界となった。

この本社から監視がきかない体制になってしまたことで、リーダーAの攻撃露骨エスカレートするようになった。例えば次のようなことを何ヶ月も継続して行うようになった。

また指示される作業単純作業が多くなっていった。例えば以下のようなものだ。

当時高い単価で常駐していたので、単価に見合わない上記のような単純作業強要されるのがまた別の苦しみとなった。

一方で、周りに対する演出には力を入れていた。例えば、本社での会議の参加を禁じたり、本社とのやり取りを自分が見えないように済ませたりして、本社自分コミュニケーションを断絶させるように動いていた。また「殺す」と脅迫するなどまずい言動を取るときは、周りの目や耳のない状況下で行っていた。あとは従順派遣社員を見つけて、主張に箔付けに使うなどしていた。例えば悪口を裏で本社に展開する際に、その社員CCに入れて、この悪口自分だけの勘違いではないと演出する気配りを行っていた(ただこの方には、裏でやりとりされている悪口中傷や、リーダーAの内心などの情報を後にもらえるようになった)

こうした状態半年近く続いたが、その中で自分精神おかしくなっていった。仕事中に泣く、顎が痙攣して歯がカチカチ鳴る、ネガティブ独り言を言うといった、外目から異常と思われるだろう様相晒ししまっていた。ただリーダーAにとってはそれは笑い飛ばす程度の扱いだった。例えば自分精神的に参っているから慰労会をやろうとリーダーAに飲みに連れて行かれることがあったが、リーダーAが一方的侮辱言葉を投げて笑い飛ばすだけの不快な場になるしかなった。

なおこの頃からさすがにこれは異常だ・危険だと言う思いを強くして、証拠を残すようにした。例えば勤務中にずっと録音機を動かし、殺すといった脅迫を録音するようにした。客先社員から同情してくれる方も出てきた。同情してくれた方から内情ももらえるようになった。

しかし激昂し犯罪者的な言動を取るリーダーAに抵抗するのは当時とても恐ろしく、証拠を残せても、証拠を活かす行動をとれなかった。また入社後即フルタイム常駐していたので、気軽に相談できる会社同僚もいなかった。そして、自分無能であり、まずはリーダーAの言う通り改善しなければ後がないという考えを持ってしまっていた。恐ろしさから逃避しながら苦しみを軽減したいという思いで、リーダーAに従い続けた。

一応本社人間相談することもあったが、抱え込まずに相談して良い、というコメントを貰った以外は、本社側で具体的な対応はとられなかった。あとは、退職時に人事から詳細情報を聞かれる程度だった。

自分の変化

上記のような状態一年以上続くことになったが、そのあい自分は大きく変わった。基本的に、次のようなネガティブな変化ばかりだ。

お上記は、もう死ぬまで元に戻ることはないと感じている。器質的に脳が変化・死滅してしまっているようだ。苦しみを経験すると強くなるとよく聞くが、苦しみで心を壊すとむしろ大きく弱体化してもう戻らないというのを、30を超えて学んだ。

その後リーダーAが抜ける

その後の展開だが、リーダーAは、顧客大言壮語ダメ出しを多くする一方で、成果を出せず、評価が得られなくなっていたようだ。そしてその頃から特定の先輩社員に嵌められて仕事がうまくいっていないと吹聴するなど、被害者的な言動が多くなる。そして最後案件から逃げていった。

ただ元凶リーダーAが抜けてからも、苦しみがなくなることはなかった。

仕事では、リーダーAが案件から逃げた尻拭いをして、関連会社メンバの業務確保と案件維持に奔走させられた。リーダーAの代わりに本社上司関係者と関わり合うようになったが、リーダーAが散々悪口を刷り込んでいたせいか、馴染みの薄い上司とは、最初から関係がギクシャクしていた。

これを心が壊れ、精神薬・アルコールカフェイン漬けで体を無理やり動かしていた状態でこなすのは、本当に苦しかった。

退職する

その後、苦しみながら遠地に常駐し、売り上げ確保に努めていた。しか半年ほどたった所で、復帰したリーダーAが、自分の目に届く会社MLで活発に発言するようになった。自分はそれを目にする度に、過去出来事フラッシュバックして恐慌状態となってしまい、もうこの会社では過ごせられないと信じるようになった。そして、ずっと常駐で会社への帰属意識がなかったなど、他の理由複数揃っていたので、会社を辞めた。

後悔

振り返っても、失ったものが多く、後悔の数多い数年間だった。

大きな後悔としては2点。1点目は、リーダーAのようなタイプ人間とは、唯一の対策として距離をとるべきだった。2点目は、状況が異常である認識して、もっと強く本社上司に状況改善を訴えるべきだった。この対応ができなかったのは自分の未熟さによる。だから転職必要能力が足りないまま転職してしまったというのが、問題要因として大きくあると思う。

あとは、仲間を作るべきだった。退職間際で、別地域担当する案件仲間と話し込む機会があったが、そこではリーダーAの異常性を感じ取っていて、仕事から排除するように動いていたという。またリーダーAから悪口の報告を受けていた人間の中には、虚言癖を見破っていて信じないようにした人がいたと聞いた。同情してもらえて、自分の見えないところでのやり取りを情報共有してくれた関係者もいた。そういった人達と早くから関係を持っておくべきだった。

そして転職や、フルタイム常駐は、巡り合う人次第のギャンブルだというのも知った。転職した会社にも、尊敬すべき人格者結構いた。会社技術力が高く、業績好調で、外から良い評価を得られている優良企業だった。唯一、リーダーAと巡り合ったのが問題だった。

ただもう後悔しても何も変わらない状況になっている。今は壊れた心身が残り、恐怖・後悔・憎悪が入り混じった感情自分の中で渦巻き続けている。

2017-07-31

https://anond.hatelabo.jp/20170731110456

黙れ小僧!お前にweb系の不幸が癒せるのか?

コミュニケーション能力の欠落した人間が、技術力のあるエンジニア(笑)になりたいと流れ込んでくるのがweb系だ!

Googlerにもなれず、OSS committerにもなりきれぬ、哀れで醜い、情報科学の掃き溜めだ!

お前にweb系を救えるか!?

2017-07-27

独自フレームワークつくるのやめてほしい

仕事プログラム書いてるけど、社内で自作フレームワーク作ってる人が多い

だいたいプロジェクトごとに別のもの使うことになる

一般的に有名なOSSならまだいいが、独自のものからそれを使いこなしたところで対して意味がない

一応githubだったり、社内のgithub系のやつに公開はされてるが、githubのでスターなんて全くついてないようなもの

せめて30くらいはついてから使うといってもらいたい


私自身そういうの作るの好きだから、作りたい気持ちはわかる

ただ、自分以外が辛いだけなのを理解してもらいたい

自分自身よく体感してるので、他人が入ったり引き継ぎを頼む可能性があるものでは、私は自作のものを使わないようにしてるくらいだ


更に問題は、納品したものが数年は保守があるのに、自作使いたいという勢いだけで使ってるから1年もすれば互換性まったくない2.0とか別のができてて古いのを改修する人が苦労してる

知名度もない自作フレームワークなんかを保守あるプロジェクトで使うなら5年、10年程度はメンテ続けるくらいのもの作ってからにしてほしい

あとついでに、ウチは成果主義なところがあるから、慣なれない上に使いやすくもない、作者に聞かないと分からない仕様ばかりのを使わせれてれば成果もあがらない

それに対して作者は自分の好きに作ってるわけだから、どんどん成果を出せる

周りの人の苦労は増えるばかり

どうしたものかなぁ

2017-07-16

OSSUIの「Do you want to 〜 ?」とその類似表現の訳のメモ

Do you want to 〜 ?

しますか?

Do you really want to 〜 ?

本当に〜しますか?

Are you sure you want to ~ ?

します。よろしいですか?

〜してもよろしいですか?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん