「OSS」を含む日記 RSS

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

2018-04-11

Vue.js日本語ドキュメントについて

バージョン1.xの頃からVue.js使用している。

ドキュメント英語で読んでいる。

しかし、英語ドキュメント意味不明のことが多々ある。

英語ドキュメント英語おかしいのだ。

そういう時は日本語ドキュメントを読む。作者とやりとりしたりして、不明点が解決している可能性があるからだ。

しかし、その日本語さら意味不明なのだ

OSSドキュメント基本的に有志がボランティアでやっていることは承知している。

でも、英語が苦手なんだったら、翻訳作業に関わってはいけない。

試しに、適当なページを見てみる

https://jp.vuejs.org/v2/guide/single-file-components.html

「多くの Vue プロジェクトでは、グローバルコンポーネントは、new Vue({ el: '#container '}) の後に各ページの body においてコンテナ要素をターゲットにすることに続いて、Vue.component を使用して定義されています。」

どういうことだろう?

原文はこうだ。

「In many Vue projects, global components will be defined using Vue.component, followed by new Vue({ el: '#container' }) to target a container element in the body of every page.」

まりグローバルコンポーネントは「new Vue({ el: '#container '}) 」の後で「Vue.component」を使って定義されることが多いと言っている。「to target a container element in the body of every page.」は意味不明だが、ここはこういう定義の仕方をする目的をさしていると思う。

次の文章もよくわからない

「これは view拡張するだけに利用された小さな中規模プロジェクトにおいてはとても有効です。 あなたフロントエンドJavaScript 全体を操作するようなもっと複雑なプロジェクトでは、これらの点において不利益になることは明白です。」

「小さな中規模プロジェクト」「あなたフロントエンド」とはなんだろう、書いた段階でおかしいと思わないのだろうか。機械翻訳をするなら、日本語ドキュメントを用意しておく意味はない。

原文はこうだ

「This can work very well for small to medium-sized projects, where JavaScript is only used to enhance certain views. In more complex projects however, or when your frontend is entirely driven by JavaScript, these disadvantages become apparent:」

JavaScript特定の表示の拡張だけに使用されるような小規模〜中規模のプロジェクトにおいて、この方法はとても有効です。しかし、もっと複雑なプロジェクトや、フロントエンド全体をJavaScript制御する場合、この方法では次のような問題があります。」

ForkしてPull Requestするのもだるい

こういうのが大量にあるから

2018-03-29

https://anond.hatelabo.jp/20180329124829

これなあ

どこも似たようなもんだとは思うんだけどさ

OSSが活発な国の人たちって、こういうのはどう対処してんだろうな

2018-03-13

なぜググらないのか

一般の人ならいちいちググらないのもわかる


だがIT系プログラマなど開発者


ググればすぐにわかるようなことをチャットに書いてる事が多い

ググって一番上のページを貼り付けるだけの作業をよくしている



新入社員ならまだ仕方ないだろう

プロジェクトリーダークラスから驚きだ

「これはもうどうしようもない部分では」などと上がってきたバグ報告を書いてたりするが知識があれば普通に対処方法はわかるもの

物によっては使うツール自体おかしい部分もある

だが有名ツールであれば大抵は Stackoverflow 等でググれば回避策が見つかる

OSS なら Github 等の issues を探しても見つかることが多い


変に知識がある分、自分知識でどうしようもないと判断したらそれは無理なものと決めつけてるようにも思う


しかすると、自分達に調べさせるためにわざと聞いているのだろうかと思ってあえてスルーしておいたことがある

そこまで考えてくれてる人では無いと思うが一応だ

その結果、自分たちのレイヤでどうにかできるものではありません、とクライアントに報告していたりすごく無理矢理で無茶苦茶方法対処していた



ググれよ!






2018-03-09

できるようにみせたいならライブラリをつくればいいんだよ

IT系の話


社内で出来るように見せて評定高くしたいならライブラリ作ればいいと思う

そしてドキュメント適当に、書いて入るけどいまいち中身が把握しづらい感じでダラダラと


基本プログラムは作った人はどう動くかやどこに何があるかはすべて分かってる

他の人だと全然からなくて一から読んで、なんでこうなってるの?とか思いながらとりあえず動きを把握する


他の人が基本的な使い方をわかってサンプルをみながら書いてるうちにライブラリの作者(以下作者)は本来作業ほとんど終えている

周りに比べて何倍も早く仕事を終えているわけだ

ブラックボックス的に考えて中の動きを気にせずに使ってる人なら思い通り動かなかったりライブラリバグ出会うととても苦労する

時間も書けて対処方法を見つけるか作者に教えてもらうか


1開発者からするとOSSでいいのになんでこんな自作のわかりづらいものを使わないいけないのかと思う

OSSみたいな今の仕事以外でも使いまわせるものでもなくて社内でしか役に立たない

将来転職したら意味ないし自宅でプログラムを書こうと場合でも使えない

モチベーションがあがらない


ライブラリを作る方針は色々なやり方ができるようにしておけばいい

1つのことをするためにああやってもいいこうやってもいい

入力された値が不正ならそれっぽく修正して動かす

一見便利そうで使う側がはっきりと使い方を理解できない感じが一番だ

さらにこまめにバージョンを上げていって使用者理解できた頃にそれが無駄になるくらいに大きな内部構造を変化させる

全体を理解するんじゃなくてサンプルを参考に動く書き方をして動かなくなって初めてコード見ればいいやくらいに思わせればいい

作者がいないと効率よく進まない状態になるわけだ


また業務システムだと同じようなものが多いのでそれらを簡単に作れるようにフレームワークにしてしまうのも良い

作者自身が使う分には簡単に使えてひとりですぐに目的のものが作れてしま

ライブラリを使って他の人が2人がかりで1月というものを作者ひとりで1週間ということもできる

中を知ってる人とそうでない人の違いは大きい


最終的には普段使う機能簡単に作れるからほとんどのプロジェクトにこのフレームワークを導入される

新規に入った人は使いづらいかOSSにしたいと言っても実績あるし作者が社内にいるからと強制される

作者がいたところでわかりづらいドキュメントと長いソースを読むことになってその他開発者ストレスは大きい


私は1開発者なのでそんな苦痛を味わっている

ソースみてもうわ・・って思うようなもので読む気もしない

作者がやめたらどうなるんだろうね

2018-03-08

anond:20180307001040

概ね同意で素晴らしいサービスだよね

元増田に書かれてない点をいくつか

  • 良い点

・作者ページに単行本販売や作者ツイッターアカ等のリンクがあるのが良い!

サイトデザインが小綺麗で清潔感があってスッキリしてて良い!アダルト関連でありがちなゴチャゴチャで下品な感じはない

ブラウザURLバーとかを隠すための全画面モード等の気の利く機能実装が良い!

  • 気になる点

モザイクが濃い!せっかくのインターネット書籍でその上出版社自家製なんだからもう少し薄くて良いんじゃないの?

・未読既読周りが閲覧履歴だけしかない。雑誌ベースなんだから前回抜いたところから未読を消化したいのに前回どこまで読んだか分からなくなる

元増田にもあるけどページ遷移周りの挙動おかし

雑誌がメインなのに雑誌一覧ページにアクセスし辛いし使い辛い

・このサービスだけで色んな主要雑誌とか読めるのは良いけど囲い込みとか大丈夫

電子単行本をここで買いたい。 DRMフリーpdfダウンロード権とkomifloリーダー閲覧権を一つのセットとして買えたら最高

NG機能(作者やタグ)が欲しい

・未読既読関連の充実化

・(将来的な話になるだろうが)OSSのような形かなんらかの形でオープンにして他のアダルト漫画雑誌一般漫画雑誌も参画できるようにしてほしい

2018-03-01

anond:20180301002920

自分は公開しても差し支えないような細々したツールを載せてる

あとOSSにIssue出してもいいんでないか

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に縛られてしまえば、時間とそれまでの経験金銭に換える事にしかならない。

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

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