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

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

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ベンチャー企業に中途入社した

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

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

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

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

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

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

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

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-09-04

デジタル難易度

ビデオカム

DV

難易度

厳密にはデジタル化?だが元からデジタルデータなので楽チン

今はIEEE1394ポート付きPCデッキの入手の方が難しいかもしれない

容量も数本程度ならオリジナルデータそのままでHDDが大容量化してる今なら余裕

寧ろ変にエンコードすると日付情報が消えるのでとりあえずオリジナルデータはとっておいた方が良い

状態が悪いLPモードテープに当たったときLPモードで撮った過去自分を恨む事になる

8ミリビデオ

難易度☆☆

デッキの入手がVHSよりは難しい

デッキテープによっては日付が記録されていなかったり読めなかったりすると何時撮ったかからなくなるので整理が大変

エアチェックセル

VHS

難易度

画質さえ目をつぶれば中古デッキの入手性が楽

ただ相性が悪くトラッキングが一向に合わないテープとかに当たると面倒に

とは言え取りあえずPCに取り込んでVISS信号(要は頭出し)を元に分割していけばよいので意外に楽

録画が止まる?その時はPC経由でフリーウェアを・・・

コンパクトカセットテープ

難易度☆☆☆

ノイズリダクションの有無・種類、テープポジション等取り込み時に必要パラメーターが多い

元がCD等の物の音楽場合、曲分割は無音時で分割する機能を使おうとするとテープ毎に状態が異なり閾値の調整が難しいため、大量に取り込む場合自動分割は諦めて手動分割していった方が楽

カセットテープ本体インデックスカードスキャナで取り込んでおくと分割時や高音質化のフィルター処理の手かがりなるのでお勧め

そして元が音楽場合Google Play Musicで音質のロンダリングする事が可能

http://pc.watch.impress.co.jp/docs/column/yajiuma-mini-review/729550.html

この場合分割時に曲始めに無音時間を少なくすることに気をつければノイズだらけでも割とマッチングする

ただそこまでする価値が有るかというと手間と時間が掛かるので微妙(曲毎のタグ付けも地味に面倒)

LD

難易度☆☆

意外に機材の入手性は悪くない

但しリモコンは少し難易度高めだが、スマートフォン赤外線リモコン機能が有る場合アプリを漁れば有名メーカー製だとプリセットに有ったりする。

フィルムの紙焼き写真

難易度

意外に解像度は低く基本的モアレも出ないのでスキャナーで取り込む場合300dpi程度でも割と平気

裏面も取り込んでおくと順番が分かるので整理が楽になるかも?

ポスターや巨大なアルバムLDレコードジャケット

難易度☆~☆☆☆☆

手持ちのスキャナに収まらなくてもA3程度までならコンビニで取り込んでしまった方が手間がかからない

もしそれ以上のサイズや持って行くのが恥ずかしい物・大量にある場合複数回取り込んで合成する方法を取るわけですがこれがメンドクサい

少々のズレを容認すれば今時のパノラマ合成ソフトで綺麗に仕上がりますが、ズレを容認出来ない場合試行錯誤を繰り返すことになります

A3+といった巨大なスキャナ一部の人に人気なのが納得の面倒さです。

冊子

難易度

いわゆる自炊

ノウハウネット上に大量に転がってるので楽

ドキュメントスキャナといった機材も中古が割と安く転がっているので手持ちの機材で変に粘らず買ってしまうのも手(消耗品が高かったりしますが・・・)

面白いドキュメント番組

僕の好きなドキュメンタリとして

NNNドキュメント」、「ザ・ノンフィクション」という2大ドキュメンタリがある。

普段知らない世界を知ることができるし

内容もさることながら、ドキュメンタリの制作側の情熱みたいなのも感じられて好きだ。

こういう番組こそNHK放送してあげるべきじゃないんですかね。

2017-08-28

https://anond.hatelabo.jp/20170826184330

すっごーい!よく年代別にまとめたね!

かつては社会課題世界問題について提言するようなことがあったのに、今は何やってんのかわからない・・・

タレントが走るのも意味不明

告白で、なんで小さな子供に「あなたの本当のママじゃない」ってテレビで言う必要があるのか全然理解できない。

センセーショナルならば何でも許されるわけでもなかろう。

NNNドキュメントを延々ゴールデンで流した方が全然いいのになー

http://www.ntv.co.jp/document/

2017-08-24

AWSハードウェア障害ないとか言ってる人はエンジニア引退して

ソシャゲがトラブったことをきっかけに、クラウドエアプ勢の大先生だちが珍説をぶち上げてる

曰く、「AWSクラウドなんだからハードウェア障害なんて起こらない」「仮にあったとしたら世界中が大騒ぎじゃん」みたいな理屈らしい

頼むからAWSドキュメント一度でも読んでから言ってくれ。

物理ホストハードウェア障害インスタンスが立ち上がらないとか普通にあるし、1個や2個物理ホストが死んだくらいでいちいちリージョンステータスすら変更しねーよ

彼らが使ってたのはEC2だろうし、そこのSLAをもう一度読んだ方がいい。そして、もし本当にITエンジニアで、AWSハードウェア障害なんてないなんて言ってる人は、頼むから引退してくれ。システム作るレベルにいないから。

2017-08-23

ITリテラシー

ITリテラシーの低い人、今時いるんだね

ていうか、理解しようとしていないように感じる

エラーメッセージが出ても読もうとしないし、対策しようともしない

OKしか押すボタンないし、押さないと進まないのにイチイチ確認してくる

パソコンを使う仕事は何であっても丸投げ

ファイルを保存しても保存した場所ファイル名も解らない

「新しいファイル」「名前未設定」みたいなファイルデスクトップドキュメントフォルダーにならんでいる

そのくせに関連付けを勝手に変更してどうにもならなくなってから

「なにもしてないのに壊れた」だから

2017-08-19

ソニーAIのやつ

なんとかダウンロードできたので試してるけど、わけわかんねーわ

日本語ドキュメントの添付サンプル実行、新規プロジェクト作成・実行やっておしまい

2017-08-13

最近windows10環境の構築

メモ代わりに

テキストエディタ

mery

一行目で保存マクロを組み込んで使っています

圧縮解凍

zip天下統一された感があるので、標準の機能OKのように思います

7zip

あえて入れるとすれば、7zipで事足りるでしょう。

画像処理

GIMP

とりあえず独特なインターフェイス操作感なので、戸惑いますが、やりたいことはできますアドビユーザー的には、概念の違いに少し戸惑う可能性があります

音声編集

SoundEngine Free

カット編集正規化、フェードインフェードアウトなどにマルチトラックを扱いたいときは、RadioLine Freeで。うざいセリフカットしたりとか、もじぴったんの歌を30分バージョン編曲したりできます

午後のこ~だ

懐かしい感じすらしますが、このあたりがシンプルでよいと思います

動画編集

AviUtl

プラグインを導入したら、うまくいきます。使い方は調べるとだいたい判明します。

webエディタ

Microsoft Expression Web4

仕事でないと使う人もいないような気がするジャンルですが、表組とかフォーム作成とかとても楽になりますメニュー表示英語なので、英語勉強をしておきましょう。

画像データ作成

Microsoft Expression Design

イラレFireworks的な何か。

オフィスソフト

LibreOffice

エクセルワードのようなもの。家で使う分にはこれくらいでいいのでは。何かの展示会でGoogle日本の人が、Googleスプレッドシート説明をするときExcelのようなもの連呼していたことが思い出されます。ちなみにGoogleドキュメントワードのようなもの表現していました。

Media player classic

動画再生用。

VLC media player

mp3再生用、簡易なタグ編集もできる。

ブラウザ

Chrome

Edgeを使いたくないとき

Firefox

スクリーンショットとか便利系の追加機能をつかいたいとき

有料編。

CorelDraw

アドビはお高いわという人向け。文字組の品質InDesignにはかなわないけど、フルバージョンが5万。年契で2万+税なので、お得。使いこなすとMSWord不要になる。カッティングプロッターとつながるのと、図面の寸法通りに印字できるので、モデラーの人には便利。ページの概念マスク機能があるので、漫画作成にも使えます自分同人誌プリントして製本したい人にはおすすめ日本語解説が少ないので、ある程度調べることが苦にならない人向け。Essentialという廉価版もあるので試してみたい人はそちらから

スマホにまかせること

メール

もうスマホでいいでしょ。

2017-08-09

引きこもりドキュメントを見た

youtubeで「引きこもり」を検索するといろんな動画が出てくるのでしばらくそれを見ていた。

私は引きこもりには4つのタイプがあると思う。

1.自分の部屋から出れない巣ごもりタイプ

2.同居している親に暴力を振るう内弁慶タイプ

3.働く意欲がなく毎日無為に過ごすニートタイプ

4.働く意欲はあるが仕事がない無職タイプ

よくメディアが取り上げるのが1と2のタイプだ。その方が刺激的で絵になるからだ。しかし、大半の引きこもりは3や4ではないだろうか。

1と2の社会復帰は難しいが3や4ならまだ希望があると思う。社会適応するための知恵をつけてやれば彼らは働き出すだろう。

2017-08-06

史上最悪の戦争ドキュメント

原爆写真CGにして動かしてたやつ

趣味悪すぎて吐き気がした

2017-08-05

「ペーパレス化」という言葉電子化を遅らせたんじゃないか

ドキュメント原本電子化されてれば、出力媒体は、PCモニターでも、タブレットでも、紙でもなんでもいいよな。

しろガンガン印刷して古くなったら即破棄とか、紙を浪費するスタイル奨励したほうが電子化が進んだと思う。

でも、電子化の意義が理解できないおっさんは、電子化した原本修正しないで、紙のほうに修正を書き込んで「こっちのほうが最新だ」とか言ったりするから無理か。

かわいそかわいそ増田

https://anond.hatelabo.jp/20170804223333

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

かわいそかわいそ増田

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

まず仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

ただ、仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

2017-08-01

俺はこんな仕事をしたかったわけじゃない

学生の頃からパソコンが好きだった

好きといっても、プログラミングソフトを作るのが好きとかハードウェアを作るのが好きとか

そんな高尚なもんではない

CPUってこんな小さいのにどんどん性能があがってるのか!とかメモリはこんなに小さいのにこんな容量を記録できるのか!とかその程度

まぁなんだ、パーツを眺めるだけで楽しいとか性能を考えるだけでわくわくするとかそんなんだった

で、情報系の大学学科を出て、卒論書くために必死内定とって、卒業後しがないクソ田舎SIerになったわけだけど

やることは貸し出しのゴミみたいなノートPC渡されて、やることはつまらないマクロ付きExcelシートのメンテナンスドキュメント作成

お金のために仕方なくやってるけど、苦痛しかない

確かにパソコンは好きだよ、でもこんなのじゃなかったんだ。

そもそも文章ドキュメントを作るのは嫌いだし、プログラミングだって苦手な方だ

というかこんなクソみたいなシートを誰が使うんだ?このドキュメントはいるのか?試験はこんなガバガバでなぜ許されるんだ?

なんで俺はこんなことしてるんだ?


学生の頃は内定貰うことに必死で何も見えてなかった。

俺がやりたかったことはこんなクソどうでもいいことじゃない。

PCショップ店員とかだったんだ。

辞めたい。

wordって編集時間出るんだな・・・

8700分ってことは・・・145時間!?

あーあせった前のドキュメントを流用してたからか

2017-07-28

ここがクソだよ日本人エンジニア

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