「ドキュメント」を含む日記 RSS

はてなキーワード: ドキュメントとは

2017-11-19

anond:20171119201432

それが土人ジャップ

初日ドキュメント渡されて、古かったので現状と差分出して報告したら

ドキュメント改訂版がこない

ドキュメントは別のとこで作ってて、指摘はすぐ反映されたみたいだが・・・

情けねえ

死ね

以降ずっとそれ

必要情報が展開されず、後戻りまくりんぐ

死ね

2017-11-17

PC自作まれパソコン先生だけどマイドキュメント普通に使ってたわ

っていってもテキストファイルくらいだからカスみたいな容量だが

anond:20171117155530

いや、Linuxでも/homeは別パーティションにしておくだろ…


ドライブ分けとくってのはLinuxでいうパーティションに相当する

Windowsにはディレクトリのほかにフォルダっていう概念がある

フォルダの指し示す先は変更することができる

ドキュメント旧称マイドキュメント)はC\Users\Masuda\Documents以外にすることができる

「フツーのパソコン大先生はCドライブに保存なんてしねえよ」ってのはそういうこと

Windowsドキュメントファイルを保存すると

素人みたいな扱いされる。

昔、初心者向けのPC解説で「ワードファイルはマイドキュメントに保存します」みたいのが2chで「マイドキュメントに保存とかwww」ってバカにされてたし、

PCショップで「ドライブ2つ積むより容量の大きいドライブ一個のほうがいい」みたいなことを言ったら店員に「データはDドライブに保存するのが普通ですね」とかちょっと小馬鹿にしたように言われたし。

職場でも、ファイルは全部ドキュメントの下に保存してたらファイルが数Gあって、システム管理系のツールを動かしたら容量でかすぎて固まって、管理者から普通ドキュメントなんかに保存しませんよ」とか言われたことがあった。

でもunix系だと、ユーザーファイルを、/home以外に保存するのってありえないよな。

ファイルディレクトリ権限を気にしないで、ルート直下ディレクトリ掘ってるお前らのほうが素人だろって言いたいわ。

 

自分PCショップ定員のおすすめどおりCにSSDで、Dに大容量HDDを入れて運用するようにしたけど、設定をいじってユーザーディレクトリをDにうつしてもやっぱ使いにくいし、やっぱもうちょっと金だして大容量のSSD買ってドライブ一つにしとけばよかったって大後悔だわ。

2017-11-14

今時のフロントエンドエンジニアってセンス無いよね

PWAとかでアプリからブラウザに行く、とかほざいてるけど、そんなことねぇよ。

大体さ、ブラウザPC時代に栄えたのって、検索がたくさんされたからだよね。

その検索スマホ時代になって全然されなくなった。

その時点でこれはダメだと見切りをつけれない奴は生き残れないと思う。

アプリエンジニアなり、サーバーやるなり、やる事変えるべきでしょ。

ReactとかAngularとか色々あるけど、ドキュメント表示するものOSっぽいことさせんのにも無理あるよねー。

SPAなんて、全然検索にひっかからないしね。SPA辞めたら検索流入増えましたって話しか聞かない。

CSSマージンとパディングの違いがどうのこうのって、失せろよカス(笑)って感じしかしない。

2017-11-11

rubyドキュメントあいかわらず糞と思うとき

動くコード乗せろよと言いたい

一番始めにみる要約のところなんかコピペで動かん。

たとえばHASHの下記のページ

https://docs.ruby-lang.org/ja/2.4.0/class/Hash.html

{s: b , ... }    
{"a+": b , ... }

「...」ってなんだよ略しすぎ。

bって変数いかエラー起こす

そんで、下記なんか修正すると動く

p r = {s: 'b'   , h: 'c'  }
p r = {"a+": 1  , "b+": 2 }

2017-11-10

プログラミング言語自体への興味はものすごく強い方だが

もう色々捨てて残りの人生erlangとrustでいいやと思ったけど

アプリエクステンションていうのかああいうのでpython,luaも要るしな

javascriptも書かんといけないことは多い

ドキュメントはRが絡んでくるし

あんま減ってねえというかむしろrustが増えてるくらいの感じだった・・・

2017-11-08

仕事楽しい瞬間は短いけど

誰よ:IT企業 SE 2年目

なんかのタスク振られた時に最初はわけわかんなくて、しんどくなってやる気が失せる。

でも色々調べてわかってくる瞬間が楽しい

それでドキュメントとか書くんだけど、それをまとめるのがクソめんどくさくてやる気が失せる。

でもある程度埋まってきたらノリに乗って書ける、その瞬間が楽しい

まぁとにかく、苦しい時間が長くて仕事辞めたいと思う回数の方が多いのだが、何だかんだ楽しい瞬間があるからやっててよかったぁってなる。

でも早く家には帰りたい。

[]11月7日

○朝食:なし

○昼食:助六寿司

○夕食:ご飯、納豆(二つ)、卵、秋野菜サラダ減塩野菜たっぷり味噌汁フリーズドライ

○間食:スライスチーズ

調子

はややー。

シンドイ。

仕事は行ったけど、座ってただけって感じで、特に何をしたわけでもない気がする。

(そんなことないかメール送ったり、ほかの人のドキュメント読んで軽くレビューしたりしたか

どうも、ここ最近調子が悪いみたいで、本調子じゃない。

どこかで「ゆうきゅー!」でも使って、気分を上向きにしたいなあ。

Xbox360

○エブリパーティ

シングルモードの、おはなしすごろくを進めています

ゲーム部分は小手先テクニックはあるものの、基本的にスゴロクの運ゲーで、特に語るところはないため、シングルモードお話を中心に感想を書いていこうと思います

今日はまず第一話「みやこ町スーパーGO

あっさり、一発クリア

神力子市に引っ越してきた主人公が、街を救う救世主に選ばれ市民たちの悩みを解決していく、という全体のストーリー説明される。

この話では、足が痛くて行列に並べないおじいさんの代わりに並んでメロンを買いにいくが、おじいさんはお金を払わずメロンをもらっていく。

うーん、オチ不快すぎる。

さくらももこキャラデザ不愉快な感じのキャラクタと相まって、もちろんコメディというか冗談なんだけども、それをすんなり受け入れない程度には不快気持ちだった。

続けて第二話「ゴルフ練習場GO」もプレイ

大苦戦し、8回目でようやくクリア、2時間半ぐらいこのステージプレイしてた。

これは、ゴルフ練習場クラブを届けるお話

練習場の場所がわからない主人公妖精さんの言われるがままについていくが道に迷ってしまい、

クラブを届けるも遅いという理由叱咤された。

なにゲームに熱くなってんだよと怒られそうだが、無性に腹立たしいし不愉快な気分になった。

お話としてのタメなのはわかるし、そもそも別にそうやって真面目にお話を読むゲームじゃないんだろうけど、なんか不快だ。

ゲームとしても、基本的には運ゲーをなん度も繰り返すだけで工夫のしようが非常に少ない(ないとは思わないが少ない)し、キャラクタも可愛かったり格好良かったりする感じじゃないありのままな感じで見ていてフィクションじみた面白さがなくてしんどいし、お話もただただ不愉快な思いをさせられるだけで面白みがない。

攻略を見ると、どうも14話ぐらいあるストーリーを三周すると完全クリアらしい。

さすがに、このゲームを三周もする気にはなれないので、一周で終わるつもりですがそれでもあと、12話ほどあるのか。

うーーーーーーん……

まあぶっちゃけ、手番の待ち時間によそ事すればいいので、地道に続けるか。

3DS

ポケとる

色々イベントが始まったけど、日替わり系を済ませたのち、サファリから本格的に攻略

今日だけで、ラクライライボルトダルマッカオドシシピカチュウウィンク)、ライチュウウィンク)を捕獲

残るは、ヒヒダルマ1匹。

早めに終わりそうでいい感じ。

2017-11-07

人生を分けるもの

あるドキュメント番組を見た。大きなリアカーを引いてダンボールを回収する仕事(1キロ5円の利益)をしている老人に話しかけるスタッフ。その老人によるとバブルの頃は兜町証券会社経営しており先物に手を出して大借金を背負ったという。今は故郷に帰って墓参りができたらもう何もいらないそうだ。

同じくバブル崩壊で大損したもの株主優待で食いつなぎ資産を3億まで増やした人物がいる。そのキャラクター面白さでテレビ雑誌に取り上げられ若い女性にも人気の桐谷広人さんだ。

この2人の人生を分けたものは何だろうか。リアカーを引いていた老人も証券会社経営していたぐらいだから業界に知人もいただろう。細かい事情はわからないがその人脈を使って再起をはかることもできたのではないか

私も自営の仕事をし綱渡りのような人生を送っている。大失敗をしてとことん追い詰められたとき、桐谷さんのように人生をやり直すことができるだろうか。明日は我が身だ。

2017-11-06

設計書はプログラムを完全には記述できない

記述できるのだったらドキュメントから駆動する言語が出来上がってるはずだ

設計書は骨子であって肉や皮膚にはならない

皮膚レベルまで骨を巡らすようなものを作るな

業務設計実装設計はそれぞれ別の専門だ

業務設計実装設計が従うのではない

2017-11-04

マクロ聖域

アプリや糞プログラムや糞コードや糞ドキュメントや糞エクセルがこんなにも世の中に溢れているのに、

マクロだけはなぜか「糞マクロからなんじゃないか」という予断がないのがウケる

http://b.hatena.ne.jp/entry/s/togetter.com/li/1167602

きみの作ったマクロは糞だよ素人さん、自覚を持ちなさい

Google検索結果が本当に使いにくくなってきた

悪いのはクソアフィサイトを作るやつらと質の低いWebメディア会社、クソSEO会社なんだけど…

もう一度、あのサイト見たいなあと思っても、昔ながらのHTML素組みの個人ページレベルだと全然引っかからない。

自然言語処理で共起語やドキュメントベクトルが似てるサイト検索結果に出してるのかも知れんが、検索キーワードを含んでないページが引っかかり過ぎる。毎回ダブルクォート入れて検索してるけど、それでもまともな検索結果が得られることがあまりない。

2010年2014年ぐらいのロジックに戻してほしい…。

Google検索エンジントップブランドから失墜するのも余裕でありえる状況になってきた。チャンスだ。

2017-11-03

転職先がGitHubSlack情報共有ツール使ってることは最低限確認しとけ

ベンチャー(という名の零細企業)から、そこそこの規模の企業転職して数ヶ月たった。給与面はめっちゃよくなったし、仕事も一緒に働く人間にもそんなに不満はない。

でも今時GitHubSlack情報共有ツール(Qiita Teamでもesaでもconfluenceでもいいけど)が使えないことにはめっちゃストレス感じてるし、使えない環境に来たことに対しては本当に後悔しかない。

タイトルに書いたようなツールが使えないということは、すご~く乱暴にまとめると要は以下のような状況の場合が多いのではないだろうか。

GitHub使えない = GitLabなどで代替している場合が多いが、要は会社としてエンジニアに対してそれほど投資積極的じゃない

チャットSlackじゃない = エンジニアよりもその他の職種パワーバランスのが強い。メール文化が残ってる。

情報共有ツールがない = 知見をドキュメントに残すという文化がない。後から入った人間が辛いし、本当に一部の人間の頭にしか仕様が残っていない。オープン文化でない。

ソースコード管理GitHubじゃない(Gitではある)、チャットSlackじゃないということは事前に知ってはいものの、何年も当たり前に使っていたツールが使えないのは想像以上にストレスだったし、数ヶ月たった今でもモヤモヤしている。

使いたいという要望は出しているものの、反応は芳しくない。

今これらのツール使って仕事してる人は、同じツールが次の職場でも当たり前に使えることは確認しておいたほうがよい。

これらのツール使ってるからいい会社とは言えないだろうけど、最低限よい会社下地はあるってことは言える。

逆に使ってない職場は、採用について相当なハンデを背負ってると思ってくれ。正直、こうなることが分かっていたら今の職場には転職しなかったよ…

2017-10-21

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

2017-10-11

宇宙飛行士

ドキュメント 宇宙飛行士選抜試験を読んだ。といっても大分前だけど。

子供の頃宇宙飛行士に憧れていたけど、

大人になってその試験内容と求められる資質の高さに愕然

自然科学系の大学卒業以上であること

自然科学系の研究・開発の仕事に携わった経験が3年以上あること

長期間宇宙滞在身体的・精神的に適応できること

英語で充分コミュニケーションがはかれること(英検1級程度の英話力)

自然科学系の研究・開発の仕事に携わる仕事って一体?

と思っているレベル人間なのです。


でも、次回国際宇宙ステーション搭乗宇宙飛行士候補者の応募がかかったら

送ってみようっと。

2017-10-06

「ペーパーレス」という言葉は失敗だったな

電子化」でよかったわ。

ペーパーレスという言葉を使うもんだから、紙をつかうか使わないか対立軸だと思って「でも、紙のほうがこういうときに便利だよ」とか「紙を無くすのは現実的でない」みたいなことを言う人がいる。

ドキュメント原本電子データ運用してれば、出力デバイスPCでもタブレットでも紙でもなんでもいいんだけど。

2017-10-05

ロゼッタどころか国内翻訳会社はどこも先がきついよ

突然かつ急激な産業革命パラダイムシフト翻訳屋のロゼッタ機械翻訳の飛躍的な向上に白旗宣言

http://kabumatome.doorblog.jp/archives/65903378.html

本当かどうかは知らないけど、正直さもありなんというのが元業界の人の感想

翻訳環境は「人の翻訳翻訳プラットフォーム(翻訳作業用のソフトウェア)→機械翻訳サポート機械翻訳の後編集(ポストエディット)→ニューラルネット翻訳」という風に進歩してて、どんどんの人の手がかからなくなっている。

それを発注側も受注側もわかってて、どんどん納期価格が下落しているのがここ数年の話。

在籍していた会社はまだマシというレベルの単価で、他社の話だとこれもう専業でやっていけねえよなというレベルの単価だった。

まり「安く、早く、大量に処理する」がトレンドであり、翻訳者からすると翻訳会社ソフトウェア会社の都合で単価や作業環境を年々いじくられ振り回させるのが常態化していてうんざりしている人も多い。

ちなみにほとんどの翻訳会社登録しているフリーランス翻訳者発注しているので、立場の弱い個人翻訳者翻訳会社の都合に合わせるか、条件のいいところを探すしかない。

発注企業翻訳会社ソフトウェア開発会社、それぞれがそれぞれの思惑で動いてきた結果、商売として成り立たなくなっているのが現状。

海外はというと、世界中ブランチ持ってる大手企業がせめぎあってて日本翻訳会社なんて下請けひとつしかない。

日本は数多いローカライズ先のひとつという感じで、そんなに重要視されてない。

あとそもそもの話、翻訳という仕事翻訳元になる文書(説明書とか契約書とか、仕事に関するすべてのドキュメント)がないと成り立たないので、日本企業海外進出しないと仕事が増えない。

「この文書翻訳しませんか」という営業は成り立たない。

オリンピック需要が!なんて話もあったけど目立った案件はなかったように思う。

ただ翻訳において絶対最後必要になるのは「誤訳判断できる背景と文脈がわかる人のチェック」なので、どんなに精度があがってもプロ翻訳チェッカーという仕事はなくならないと思う。

しかしそうなると外注するより社内で機械翻訳した後にチェックできる社員がいればよく、むしろそっちの方が安心感があるので市場さらに縮小するというのが個人的見立て

みんながキーボード打てるようになって、タイピスト仕事がなくなっていくのに近い感じかな。

業界の傾向だと思うんだけど、語学好きな人が多いせいか勉強好きな真面目で感じがいい人も多いので、そういう人たちがしんどい思いしないようにとは願ってる。

2017-09-30

C言語最初に学ぶべきではないが最初に学ぶことのメリット

私は今とある大学の4年生です.

本格的にプログラミングを始めとしてコンピュータ科学を学び始めたのは大学入学してからです.

今では幸運なことにインターン都内ベンチャー企業golangpython, scalaを用いた大規模なシステム構築に携わっています.

給料日本大学生にしては破格といえるのではないでしょうか. それも大学で真面目に勉強したお陰であると胸を張って言えます.

大学の方の卒業研究では組み込み系のセキュリティに関して研究しています. 正直テーマ選びに失敗したなと思っているので大学院にいったらシステムプログラミング系の方にシフトしようと思っています.

無駄話が過ぎました. 表題に関して話しましょう.

私が大学の授業で初めて習ったプログラミング言語C言語でした. 理由教授に聞くと, 並行して座学で教えるコンピュータ科学系の専門授業全般と結びつけやすいからだそうです.

最近TwitterQiita, StackOverflowなどでは「初学者最初に学ぶべきプログラミング言語はなに?」という質問に対して, JavaScriptPythonから入るのがベストだと言う人を沢山見かけます.

私自身こういった意見には賛成です.

JavaScriptブラウザというものが有る限り20年は消えなさそうですし, Python機械学習を始め, Webシステムでも使え, 非常にクレバー言語です.

javaオススメだと思います. 30億?ものデバイスで動く言語ですしドキュメント豊富です. 色々な分野にも応用が効くでしょう.

さて, そんな中でC言語という悪い評判しか聞かない, でもやたら色々なところで使われているらしい言語最初に学ぶメリットとは一体なんなのでしょう.

一つ, 私が思いついたのはコンピュータと仲良くなれる.

というのもC言語アセンブリ機械語に比べれば, 人間にわかやすく, かつコンピュータ側にも近いという顔をもちます.

真面目にプログラミングしようとするとどうしてもそのコンピュータの仕組み(主にメモリ) について学ぶ必要が出てきます. これらの知識現代の開発に置いて役立つ分野比較的限られると思います.

しかし, それらは思わぬバグ特定意図していない動作改善に役立つことがあるかもしれません(実際に私もいくつか出会いました)

二つ目は他の言語を学ぶ時のハードルが非常に低くなる. これはどの言語を学んでも同じだとは思います.

そして, 他の言語の高級な機能に思わず涙ぐみながら感謝すること間違いなしでしょう(javaのsplitとか他の言語にもあるHashとか)

ただ, 私はC言語構造体やポインタのお陰でオブジェクト指向プログラム言語を低レイヤ実装的な面と概念的な面ですんなりと理解することができました.

そしてよく挫折ポイントとなるポインタ(ダジャレじゃないですよ?). これもメモリの住所だと考えればそれほど難しくはないのです.

メモリ管理を適切に設計した時あなたプログラムボルト並みに早く走ってくれるかもしれません.

他の言語では味わえないやりがいがあるのもこの言語の魅力でしょう.

書いているとこれぐらいしか思いつきませんでした.

それでもコンソールに初めて Hello World! が出力された時の感動はやはり忘れられません.

昨今, 高機能言語が沢山ありますが, あなたプログラミング生活ささやかアクセントとしてC言語を学び直してみてはいかがでしょうか?

きっと今使っている言語普段言わない感謝言葉を述べること間違いなしです.

それではこんな駄文に付き合っていただきありがとうございました.

一刻も早く世界からC言語が消えることを祈っています.

2017-09-27

Facebookレイバンスパムイベント招待に負けない方法

もしあなたFacebookアカウントが乗っ取られた場合


今回はログインしないと行えないことがされているため、ケース2から漏洩だと予想できます。ただ確実にかどうか検証できてないので1の対応もしてほしい。

ケース1.【アプリ認証からアカウントが使われてしまった場合

https://mobareco.jp/a5458/

このページにある「アプリ連携確認・解除」をすると、今回のようにFacebook認証が通ったアプリあなたアカウントを使ってイベント招待できなくなります

そのアプリを作ったり運用してたりしている人の中に乗っ取り野郎がいる or あなたアカウント情報乗っ取り野郎に売ったからこうなってる。

補足:アプリ認証イベント招待できるの?

FacebookAPIドキュメント読み込む力割けないかちょっとわかんないです。

ぱっと見できなさそうに書いてあるけど、FacebookAPI抜け道をつくと「とれるよ」って言われてない情報が取れたりするなーって思ったことがあった気がするのでどうなんだろ。できんのかな?そのあたり強い人コメントください。

https://developers.facebook.com/docs/facebook-login/permissions/?locale=ja_JP

ケース2. 【パスワード漏洩によりアカウントが使われてしまった場合

http://crearc-design.com/2016/05/11/facebook-ray-ban/

ここに書かれている手順で


をすると新しいパスワードしかログインできなくなります

なので他の端末からログインしているであろう乗っ取り野郎パスワードを知らないのでログインできなくなります

これで乗っ取り野郎あなたアカウントからイベント招待できない体になった。

もしこのケース2のパスワード漏洩が原因である場合

このようなことが考えられるので、良さげなパスワードを考えよう。

好きなもの頭文字ランダムに並べるのが私はかなりオススメ

おすすめパスワード例: 「fOpc_fF1mi5000m 」(ふっくらおっぱいぷるぷる可愛い_ふっくら太もも1かい揉みたい、いや、5000かい揉みたい)

上の例はおっぱいと太ももが好きなので大文字になっている。英大文字、英小文字数字ランダムに入っていると良いよ。

この文章を知っていてもパスワードとは思わないので。

個人的には1Passwordって神アプリを使うのが一番いいと思う。


ところで今回の事象とは

アカウント乗っ取り野郎あなたアカウント乗っ取り、相当の人数に対してスパムイベントに「イベント招待」をしたと思われます

イベントの削除はイベント削除権限がない限り行えないので、招待者は削除できません。

また、現在Facebook送信済みの招待を取り消すことができない仕様になっています

対応できることといえば、その招待を無効にしてもらうようにFacebook運営にお願いしてみることです。

そうするとFacebook運営の人が、送信済みの招待を削除してくれるので被害が広がらなくて済むようになります

が、対応までに時間がかかる or やばい影響が出てるわけでなければ対応されないかもねって感じです。

その間に招待された友人が「興味あり」や「興味なし」を選択し、イベントFacebookアカウントが紐づいてしまい「このアカウントリテラシーが低いか乗っ取りにいこう」と悪質な影響を受ける可能性があります

自分の友人などへの被害の広がりを防ぐためには。

「昨日私のFacebookアカウントが乗っ取られてしまい、悪質なイベント招待が友人に送られたそうです。現在パスワード変更したので再度送られることはありませんが、招待を無効にすることができません。なのでRay.Banの悪質イベントの招待が行ってしまった方は、"イベントには参加する、しない" などのリアクションをせずに ”Facebookイベントを報告する” をして、 "Facebookイベントを報告する" → "スパムまたは詐欺 "にしていただけるとたすかります。ご迷惑おかけして申し訳ありません。」


みたいな文章投稿しておけば、「おかしいな?」と思った方は被害を受けずにすみます

投稿するかどうかはあなた次第なのですが、低リテラシーであることを恥ずかしがって隠していると将来的に誰も教えてくれなくなっちゃますので言っておくが吉でしょう。

恥ずかしがらずに被害を受けたということを公表すれば、二次被害が広がらずにすみます

私の気持ちに関して

あなたが乗っ取られたっていうことはあなた情報だけではなくあなたの友人の情報漏洩したということになります

「わからなかった」「知らなかった」と思うだろうけど、悪いことに使われてそうだと思いながら放置していたらそれは過失だから

訴えられたら負けてしまます

これから先の未来技術の先にあるから、わからないのはしかたないけどわかろうともしないのはいかがなものかと。

やっぱ将来はインターネットのない島根野生動物を狩って暮らしたいよね。

2017-09-26

プログラマだけど、SIのお客さんとこの役割分担で不可解に思うことしばしば。

設計ドキュメント作成)と実装を分けるパターンは割と見る。納得いかないながらも目にすることは多い。

しかし今のとこはさらにわからない。設計作成実装及びテストを行う実作業者、とレビュアーの2役の役割分担。客とのコミュニケーションレビュアー側の人間がやってる。口聞いて話まとめて口頭で伝える人 と 物作る人という分け方なのだろうか。

自分は昔の教科書的な上流〜下流ガッチリ階層分け現場はあまり経験がなく、プログラマ要件聞いて物作るところまでやるような現場が多かった。なのでこういう役割分担ってどうも馴染みがなく。

世間的にはこういう分担が一般的なんでしょうか。

2017-09-19

anond:20170919014227

なんかちょうど「米国Rubyの人気が減りつつあるらしい、マニュアルサンプルコードが不足してるからサンプルコードをみんなで書こう」みたいな記事見て

「えっそれ今言う…?君らソースコードドキュメントだって10年くらい言ってたやん…?」っていう気持ちになった

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-12

ITベンチャー企業に中途入社した

自社ウェブサービスの基礎部分は外部に委託して作っていたらしいがめちゃくちゃひどかった

言語知らないけど流行ってるので書いてみました」

フレームワーク知らないけど流行ってるので使ってみました」

インフラ知らないけど新機能なので使ってみました」

こんな感じのオンパレードだった

もちろんドキュメントもないし、連絡ももう取れない

こんなんでも、スタートアップを共にやったった、とかで自分の給金よりも大きなお金が動いたのだと思うと泣きなくなる

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