プログラマの雑談部屋 ★31
■ このスレッドは過去ログ倉庫に格納されています
>>664
そう、そういうのが実は重要でね。
そういうのの積み重ねで設計やデバッグの勘を養うんだ。
仕事だと他人のダメソースをコピペして
エビデンスの画像貼ってるばっかりだもんねぇ。 他人の10倍できても給料が10倍になるわけではないのがかなしいところ さすがに管理する側になったら技術的には衰えてくだけだろ、仕事外の時間のみで維持出来るとは思えない
コピペのみでこなせる仕事なら維持出来るのかも知れんが、維持出来るレベルも低いってだけでは そうだな。
でも残業とか少なくなるから、仕事が楽にはなる。 管理する側にいつまでも甘んじるとも思えんしね、できる奴は。
自分ならもっと楽にできるようなことを、部下がモタモタしてて
そのせいで自分が上司や顧客から怒られる役回りなんて・・・ うちのプロパーはとんでもねえ駄目人間だが
狂った実装能力と明るいムードメーカーだから許されてる
客が最近〇〇さん遅刻しないで来れて偉いですねって褒めてたときは俺の頭がおかしくなったかと思ったわ ブラック企業を叩いているけど、大企業やらホワイト企業がブラックな部分をアウトソースして
今の状態になっているのを気づいていないのか、知らないふりしている邪悪なのかそういう人は
少なくないよな。
まあワタミみたいに大本がどうしようもない経営者だったりするのもあるんだけど、どちらかと
いえばそういうののほうが例外っぽい。 >>672
まあいいんじゃね?
そうやって下請けに丸投げして、下請けがやらかしたことで
マスコミ沙汰になるのも大企業の責任だからな。
大企業の名前は記事になっても下請け企業の名前は出てこんだろ。 >>672
ブラックな部分をアウトソースできてたらまつりちゃんは死なないんだよ
ホワイトは看板と給料だけで
ほかはすべてブラックなんだ >>674
適応できなかった遅れた企業ってことだろ 詳しいことはわからんけど、営業マンはむやみに外注にはできないもんねぇ。 >>671
そういう人徳が欲しい
俺なんか明るいわけでも優秀なわけでもないから
粗が見えるたびに否定されていく >>677はおそらく
承認欲求を見透かされてつけこまれているんだ
たぶん諦観してやさぐれたら周囲の対応かわる >>680
そんなことしたらお前もういらねえで終わりかな
他にフレッシュな出来る人材なんてたくさんいるし 頭もいいし、業務知識もあるし、コーディングも恐ろしく早いが
なので重宝してなんでもかんでも仕事を頼んだのはいいが
コードがむちゃくちゃで
その人が病気で退職した後に地獄になったチームあったな 小さい会社は、出来る奴が入るとそいつに頼るしかないからねぇ。 小さい会社はスターエンジニアが会社の柱になっちまうからな
そいつが抜けると会社が傾く
因みに人売りじゃなくて開発な
すぐ人売りの話する奴が出てくるからな >>684
>>685
エンジニアなんて一人いくらで売るだけだから腕前は関係ない 設計書は作成者自身が責任持てってのは分かるけど
技術仕様的なところが分かってない人が適当にレビューして通して
後からあれ違うこれ違うこれだと実装出来ないって話になると
レビュアーぶっ飛ばしたくなるね
まさに誰が責任とるかって話だが結局自分になるってアホらしい 個人に依存したくなかったら
人売りになりましょうという話ですね >>659
技術あるなしじゃ全く違うよ
取れる選択肢の数が違う PMといっても、金勘定に長けた人、スケジュール管理に長けた人、技術に長けた人、語学に長けた人、言い訳に長けた人と様々。
地雷はスケジュール系と言い訳系だな。
下請けに鞭打つ奴隷管理者によくいるタイプ。
プロパーの開発部隊だと技術系の人が多い。
同格の相手に鞭打てないからね。 >地雷はスケジュール系と言い訳系だな。
>下請けに鞭打つ奴隷管理者によくいるタイプ。
それ優秀やん!
下請けをビシビシ叩いて理不尽を言いくるめて堂々としとる
理想のPMやねんで >>688
実装する前に設計するバカが悪いんじゃないの?
パンチカードでプログラミングしてた時代の名残でしかない設計書文化を現代でもありがたがって真似する必要はない >>694
そりゃあ最初から開発環境が提供されてすぐ弄れるなら
ちょっと試しながらって出来るが環境もなかったしなぁ
ずっと前からある設計書を真似ながら作れって恐ろしい 設計書は詳細になるほど間違えやすくなる
要点だけ押さえて具体的な部分はあえて書かないのがコツ
要するに設計段階でも抽象化しろってことだ 自社開発の話は他所でやれ
ここは派遣の搾取を糾弾するスレだ >>697
搾取されているとわかって、何故その状況にいるんだ
立ち上がれ そういや俺が作った設計書で代わりに実装してくれてる奴が
設計間違ってて裏で俺の事を悪く言ってたらしい
手戻りさせたのは申し訳ないけど言われる筋合いないし、そもそもやってあげてるなんて姿勢ならやってくれなくてもいいわ >>697
>>698
コピペ投下してるのお前?
まず働いてるのか、いや働けるのか?
35歳スレ見てると人として就労無理だろ
社会適応出来ないのはお前自らの自業自得だよ >>699
そいつが悪く言ってるってどうやってわかった? 35歳は認知が狂ってるからな
あいつが働ける世界なんてないよ >>701
まあ狭いところだから隠語でも言葉伏せてても
誰の事言ってるのかすぐ分かっちゃうわけで >>703
そいつ新人ならおまえのことを悪く言ってるわけではなくてその会社のフォーマットとか設計書の書き方が嫌なのかもよ >>699
無責任な奴だなキミは
障害票を起票して
デバッグして
設計書と照らし合わせて設計書の通りか確認して
関連機能のテスト仕様書を修正してレビューして
コードを修正してレビューして
関連機能のテストをやり直して
エビデンス作り直してレビューしtr
報告書にまとめて
定例ミーティングで素人の爺さん達に今節丁寧に報告する
これが全部が製造チームとテストチームの予算と工数で賄われるって理解してる?
設計書適当に納めてハイ終わりじゃねえんだよ 設計書バグってたらラッキーじゃん
そこから先のテストは省略で納品してokなんだぜ ウチの会社とくにテストもせずに実装者が動き確認するぐらいで
現場に出しちゃうんだけど異端なのかな >>690
紙はかさばるし引っ越しの時に困るから電子書籍も検討したけど
5か所位にしおりを挟んで参照したりするからやっぱり紙のほうが便利。
10年前に買った本の新しいバージョン対応の本など買い直したりしてる。
ちょっとしか変わってないからもったいないような気がするけどググる時間が節約できる。
技術書は永久保存版ではなく使い捨ての紙で印刷されたマニュアルだと割り切っている。 >>696
分業じゃないならそれでもいいんだが、分業だからそんなぬるいことも言ってられないというのもある。
社内分業ならそういうあいまいさで生じるコストはうやむやにしても問題ないが、社外だとそのコストを
うやむやにすると色々よろしくないことになる。 >>713
それじゃ分業の意味ない
曖昧さがなくなるまで設計する膨大な工数でプログラムを書けてしまう プログラム仕様書ってコードの一行一行書いてあるやつってそれ作ってる暇あるならプログラミングしたほうが早いんじゃねって思わないか 今までで最高に狂ってるなと思った設計書はこんな形式
変数宣言
(tab)変数名(tab)合計
(tab)初期値(tab)0
変数宣言
(tab)変数名(tab)i
(tab)初期値(tab)0
ループ
(tab)種類(tab)for
(tab)変数名(tab)i
(tab)初期値(tab)1
(tab)終了値(tab)10
(tab)増加値(tab)1
(tab)処理内容
(tab)(tab)代入
(tab)(tab)(tab)左辺(tab)合計
(tab)(tab)(tab)右辺(tab)i
リターン
(tab)戻り値(tab)合計 >>717
まさかと思うけど、その(tab)って、そこにTABコード入力しろって指示なの?w おれがハルヒ見てる間にずいぶん盛り上がってたようだな。 >>690
新しく買うものは電子書籍にしてる
古いのはそのまま >>690
結局、電子書籍のほうが読む回数増える
出先で急に必要になったときの便利さ半端ない 技術書見るなら10インチ以上ぐらいのタブレットないとキツイよね 今度新しく出たiPad欲しいな
AppleID取るところから始めないといけないけど kindleペーパーホワイトいいぞ
雑に扱っても丈夫だし読みやすい
充電も滅多にいらない
カバンに常備するならこれだわ kindlは画面2倍にしてくれたら3個は買うけどな >>728
あれって固定サイズの参考書もまともに読めるの? >>729
電子書籍リーダーって3個も買うもんなの? >>732
それならiPad proでいいだろw
kindleが有利な面って持ち運びのメリットだ >>730
本をそのまま電子化したようなのは無理
素直にiPad proかパソコンで読んだほうがいい おい、おれだいだい前のを利用てコピペしながらのプログラミングが多いんだが、実際にゼロから
作れとか生産性を問われるとちょっと自信がないんだが、生産性を高くしていく方法ってあるんだろうか、
時間外に自分であたかもゼロから作ってプログラミングの勘を養っているんだがそんなの当たり前の
ような気もするし、なんかないのかねえ、最悪はマネジメントで食っていこうとも考えてるよ。 技術書は紙で読みたい。
PCだタブレットで読んでも
なぜか頭に入らない。 >>735
10.5は触ったことがないが
12は不満なし
9はちょっとだけ狭いんだよ
>>737
ああ、わかる
がっつり勉強するような場合は紙で買う >>737
仲間。紙じゃないと読めない。
ソースコードも印刷しちゃう。 ソースコード印刷は効率いいよな
若い子が検索機能でぴょんぴょん飛びながら編集してるの見ると宇宙人に見える ソースを印刷したら死ぬほど怒られたことあるな。
コピー代がもったいないって。大昔だけど。 おまえらC++使いの老人だろ
JavaやC#でソースコード印刷したことがないわ ああ、JavaやC#はすぐ修正して元のソースなんて意味ないし、
そもそも美しいソースとは無関係だし、
印刷しても紙がもったいない。
JavaやC#のようなウンコは電子版でそのままよめ。
紙で出したら拭いてしまうぞ? >>740
特に740よ、それは異常だって、検索機能でぴょんぴょん飛んでやるのは常識だろ、
汎用機しか使ったことないんとちゃうか。 同じようなシステムで使うutility系の関数とか丸々コピペが当たり前
見積もりの工数を全部ゼロベースから試算されてるならいくらでもゼロから作ってやるけど
今じゃ見積もる奴も知恵ついちゃってコピペなしじゃ到底間に合わない工数しかない
コピペ工数で新人にゼロからページング処理とか作らせたら3倍の時間かかって糞コードが出来上がる
俺はif文すら打ち込むのめんどくさいからコピペする
カチャカチャやってる奴が馬鹿にしか見えない C++は楽しかったな
今はPythonやPHPが多い
VB.NETも意外と多い
JavaやC#はあまり縁がないね
趣味もAIのフレームワークさわったりAWSの新機能試したりでコーディング減ったな・・・
せいぜいシェルスクリプトぐらいだ
趣味はプログラミングと公言してたのにいつの間にか離れてたな
ソース印刷ってフォントで効率変わるよな >>744
ソースの流れを読まないのか?
イベントや割り込みが発生した箇所からの流れを読まないと不安で仕方ない >>748
全部読むかよ、既存ソースの変更はな必要な箇所のみ見るの、全体の動きを追ってたら
想定以上の工数がかかってしまうわ。 >>748
イベントや割り込みって何?、OSのプログラムのこと? >>750
イベントが発生してイベントハンドラがキャッチして関数が動き出す
そのスタートする地点のことを言ってるつもりだよ
HTTPリクエストやCRONのキックの場合もあるね
まぁ、元のレスが何が言いたかったかというと、処理の流れを全部把握したいってこと Kindleは書籍管理の根本から作り直してくれないと
全く使いたい気持ちにならない
現実は本棚を持ち歩けなくて数冊入れて読み終わったら消す使い方になる 本来はそういうのが設計書に書いてあるべきものだけど、
ごちゃごちゃ余計な事書いてあって、わからん >>752
セミナーでアップルペンシルでカリカリ書いてるやつ増えてるよなw
スタバでマック以来のどや顔アイテムだと思うわ >>753
同じくそれが嫌なので自炊に走ってる感あるわ >>756
最後はそれが一番だと思う
自分で管理して使いやすいアプリで読むのがいい >>751
それ関数の切り口が悪いんじゃないか?
処理のレイヤーとか命名法則とか役割決めて組んでたら
それぞれの関数の中身が気になることってあんまりない気がするが >>753
これほんと謎
Amazonの技術者なら鼻クソほじりながら1時間くらいで作れそうだけどなぜやらないのかね
ソーティングとグルーピングを強化するだけでも十分なのに >>759
最初に書籍データにMP3みたいな管理タグ情報を入れとくべきだったと思う
そうすれば分類も簡単に出来たろうに 何か部分的に聞くのにソース印刷とかはわかるけど
ソースを自分で読むのに印刷ってちょっとヤバいね
オブジェクト指向とは無縁の化石言語でも使ってんのかな >>759
まさにそうさせたいんじゃないか
ユーザーに保存可能な情報を一切もたせない世界にしたがってる Amazonのmp3サービスのサポートにメタ情報編集機能くれつったら暫くして実装されたことがあった
Kindleでもできない理由は無いと思うんだがこっちはなぜかやってくれない もっとよくなるシステムって世の中にいろいろあるよな ■ このスレッドは過去ログ倉庫に格納されています