面接時「プログラミング得意です」入社時「何も分かりません」←これ多すぎ
■ このスレッドは過去ログ倉庫に格納されています
面接だから話盛るのは分かるけど
全く出来ないのに嘘八百で入られると流石に扱いきれない すまんな
ECサイト作った程度でプログラミング出来る言って入社したが1年くらい迷惑かけっぱなしだったわ
正直プログラミング力は客観視出来んと思った 最初クラスとか意味不明だったけど
実践繰り返すと、はいはいこのパターンはクラス使えば楽ねって勝手になる
努力はネットで検索する努力これだけ
他はいらない >>94
もちろん上で出ている銀行業務とか君の言う物理計算とか
許容されない例はいくらでも有るだろうけど
>>82へのレスだからね
全く使えないわけじゃないことを示したんだよ >>96
>>1の者は「四則演算」と指定してて
四則演算の中に割り算は含まれてる できる!ってなにを持って信用するのかが重要であって
何も考えずに採用するとかこの先大変 同級生で一番最初にHelloWorld出せました! こんな程度でマウント言われても困るわ
小学生でも出来る、何せ俺がやってるくらいだからな >>103
うん
何らかのアウトプットとして割合とかを出すことはあるが
その数値を再利用することは稀だし有効桁もfloatで十分なレベル >>99
ぶっちゃけあんまり気にしなくていいよ
製造やるなら設計書しっかり読める方がよっぽど重要 >>108
それは業務によって様々でしょう
業務の内容によってどこまでが有効桁数か変わる
有効桁数というものを理解するためにはやはり
型であるとかビットであるとかコンピュータの基本的な仕組みも理解してないといけない >>100
ECサイト作れるならポテンシャル自体はありそうだけどなぁ 20年位前までソフトハウスで働いていたけど女性を顔でとる会社で入社して3年経っても試験の検証しかしたことないってのがいっぱいいたな
なんでこの仕事選んだの?ってのだらけだった
そして社内でくっついたり離れたりを繰り返してギスギスしとった >>110
お前が勝手にそういう妄想してるだけっていつになったら気づくんだ 面接で好きなデザインパターンは?って聞けばプログラミングへの理解度は大体想像つく >>115
>>1はどんな業務やってるのか言ってないし
どういう四則演算が必要なのかなんてわからんだろ 面接時「人と接するのが好きです」入社時「人権宣言?なんですかそれ」 何次面接の想定かわからんが、技術者採用するのに面接に社内の技術部門が立ち合わないなんてことあるか? >>120
インキャほど人に聞くって事が出来ないから
自分で色々調べて理解するから
インキャはプログラマー向いてるジレンマ >>118
グローバル変数のノリでシングルトン量産するやつだな!帰れ! プログラミング向いてる人って趣味でUnity使ってゲームを作ってたり既に書き込まれてるけど画像クローラーを自作したりしてる人になるのか? 人事自体が仕事できないやつの集まりだからな
他の業務で結果出せて金を稼げるんなら人事で遊ばせておかないよ
面接は現場のやつも同席させた方がいいわ >>117
その後画像がどうの言ってるからそういう分野じゃないのは確か Javaのソースコード読める程度の知識しか無いのに既存の簡単な改修なら可能って書いてるけどセーフ? 普通プログラミングで何ができる?って言いかたしねえ?
車運転できます!だけで大型貨物運転させようと思わんだろ 何処から出来るって言っていいのかマジで分からない
出来ない人よりは出来るって言いたい プログラミング向いてる人って言うより絶望的に向いてない人がいるイメージ
あとシンプルに実際やってみたら思ってたのと違ったパターン
そういう意味で未経験でも一度はプログラミング触ってやってけそうか確認しておくのがお互いの為だと思う >>133
プログラム完全に理解した
と表現すれば伝わる VBA使えるのはプログラミングできるって言って良いのか? >>134
プログラミングって例えば何かゲームを作るとか? >>132
画像処理で有効数字気にするような演算しないが 出来ると言っていいか悩んでる人は
騙す意図がないならしっかり話せばいいだろ
自分が書いたプログラム作ったプログラムはこういうものだ
ここはライブラリ使ったので1からは作れないだろう
こういうことは概念としては勉強したが
使い所が分からない上手く使えている気がしない
とか
自分が何が出来て何が出来ないか
客観的に語れたら俺的には評価高いわ >>138
有効桁数を気にしなくても画像サイズをピッタリにしたい時とか
少数の計算できないと正確な結果にならないこともあるだろ 俺「チャットボット作りました!(嘘だよ!Googleが後悔してるAPI丸パクリだよ!)」 >>141
ぴったりにする必要あるか?
そもそも画像サイズは整数だろ >>137
ゲームでも良いしツールでもいい
ゲームつってもゲーム開発志望とかでなければシューティングとかアクションみたいなオリジナルゲームじゃなくてオセロとかテトリスみたいなルールがシンプルで見た目とか拘らないミニゲームでいい
基礎と雰囲気掴む為のもんだから難しくなくて良い >>143
整数でピッタリ合わすには正確な少数計算が必要なこともあるだろ >>145
四捨五入するだけだが
そもそも少数が出た時点でぴったりにならないんだから気にする必要がないって言ってる >>144
ありがとう
IT業界が気になってたけど自分に適正があるのかどうか調べるにはどうすれば良いのか分からなかったから助かる >>146
四捨五入しても少数の扱いが雑だと1ズレることもあるだろ >>150
例えば256対256のサイズで納品しないといけないファイルを
256対257で納品しちゃったとか起きたら大変なことだろ Java Silverの資格は馬鹿にならない
デバッグ能力がないと合格できない
PaizaAランクも馬鹿にはできない
ビジネスロジックが組めないと合格できない
この辺持ってるビギナー人材は宝の宝庫だけど人事は重視しないよなあ >>151
なんで納品サイズ決まってんのにずれるんだよ
最後にトリミングするだろうよ ID:nuhtnd0o0は机上の空論だけで話してて仕事したことないって感じするな >>153
まぁ1例だけどトリミングもプログラムだろ
画像処理だからトリミングも込みの仕事かもしれないし >>151
少なくともサイズに関しては拡大率縮小率での指定ならそのくらいの差は許容範囲
目的とするサイズが最初から決まっているならサイズの計算で有効桁数がどうこうなんて話にはそもそもならない >>151
サイズが指定されてる画像を何で縮尺率で割ってサイズ出そうとしてるの?
サイズ決まってるなら計算するまでもなく、そのサイズなのでは? >>157
許容範囲も何も指定したプログラム組めなかったら問題やろ >>158
だからファイルのサイズが正しくない可能性がある >>159
画像処理において画像サイズ変えることはいくらでもあるだろ
バカなのかw 画像ファイルを指定したサイズに変えるっていうのは例えば動画サイトのサムネイルを作るときに必要だよね こいつ実数と浮動小数の区別ついてなさそう
浮動小数は計算結果が正しいかどうか以前にそもそも正確に表現出来ない値があるんだよ? >>161
だから最後トリミングで整形するんだから関係ないじゃん >>162
いや、だから納品する画像サイズが指定されてるなら、そのサイズにしかならないんだから計算する必要ないだろ
画像サイズを元の○%って指定なら、1ピクセル単位のズレなんか許容範囲だって話をみんなしてると思うんだが >>165
「指定したサイズ通りのファイルを出力する
プログラムを作ってください」って業務かもしれないだろ 浮動小数で金融の話持ち出してくるのも謎
そういうのは仮に小数点以下を表現する必要があったとしても固定小数点を使うからそもそも問題にしてる誤差なんて出ない >>167
計算で画像生成するプログラムを作る業務かもしれないだろ >>171
そういうプログラムを作れと言われたら作るしかないだろw
アタマボケてるなほんと >>173
?
指定したサイズを出力しろって言われてるんだから
ズレたらトリミングする必要があるだろ
そもそもどんなデータが投げられるかもわからんし最初からトリミング前提かもしらんし >>174
「指定したサイズのファイルを出力しろ」
と言われたら
「指定したサイズ通りのファイルを出力するプログラム」
を作る以外ないじゃん
馬鹿なのかw >>170
いや、だから仮に指定されてる画像ファイルが256✕256なら計算するまでもなく256✕256にしかならないんだから、257✕257になるかもしれないなんて心配する必要があるの?って訊いてるんだけど
他の人が何度も言ってるように微妙なズレはトリミングでサイズ256✕256にすりゃいいだけの話だし
それともトリミングの意味が分かってないのか?もしや(´・ω・`) まず実務ではプログラムが目的じゃなくて業務の達成が目的なのよね プログラミング関係は話盛るのが定番だから仕方ない
このスレでも既に盛られてるし >>176
例えば「800×426のサイズのファイルを色々処理して
256×256のサイズで出力しろ」と言われたら
少数の計算がしっかりしてないと変な出力に
なるかもしれないだろ >>179
途中でどんな処理挟んでも最終的に指定サイズでトリミングするんだから途中経過でどんだけ誤差出ようが最後に帳尻合うだろ
バカなのか? >>180
プログラミングできるけどとかプロの現場でとかほざくからだよ >>181
処理によってはピクセルごとに正確な情報入れたいかも分からないだろ
その時に少数の計算の正確性が関わる 画像処理関わったことないのだが
てきとーにやったら1pixel増えちゃったから
最後もう一回変換処理かけるべ
で許されんの? はーいいなぁ
うちなんか
「入力が大変です」
ぼく「同じ内容なんだからコピペですぐできるでしょ」
「そうなんだ!しらなかった!」
「そのマニュアル作ってくれ!!」
こーんなレベルだよもうマニュアルなんてアホらしくて作ってられんわ >>183
そもそも画像サイズを変更するような加工してる時点で正確な情報は残せないんだわ
仮にそういう要求されたら相手に無理だと納得させろよ。それが仕事だろ >>186
それ決めるのお前じゃないだろw
そういう依頼を受けたらそのプログラム作んなきゃいけない >>188
要件定義したことないのか?
依頼通りに作るアホはプロの世界にはいないぞ >>189
画像処理の会社なんだったら「こういう画像処理の
プログラムを作ってください」と依頼を受けるわけでしょ
その業務内容はよく知らないけど少数の計算を
いい加減に扱っていい分野とは思わないな >>190
その依頼に対して具体的にどういう仕様にするのか要件を詰めるだろ?
その段階で実現が無理だったりコストに見合わない要求あれば相手を説得して要件変えたりするだろうが
まさかろくに要件定義もせずに二つ返事で作り始めんのかお前 正確性が失われるは良いけど
そのメカニズム説明するのに
1Pixex増えちゃうから最後辻褄合わせの制御してます
ってお客さんに説明すんの?
そりゃ嫌だわ……
画像処理界隈では許されるのかもしれんが
俺の常識では無いわ >>191
仕様を実際にプログラムする時により正確な少数計算関係あるだろ >>193
そもそも画像処理にそこまで正確な計算いらないって話に対してお前は必要って主張してるんだろ?
1ピクセル単位の画像のズレが許されない業界なんて聞いたことないんだが、そんな特殊すぎる環境持ってきて何の主張を通したいんだお前
そんな超絶激レアな依頼されたらその時は対応すれば?
でも一般的には画像処理でそんな計算いらないからな
いい加減分かれ ちょっと実際に考えてみたんだけど
プログラミングで1/3を1×3したら1ちょうどに
ならないじゃないですか
この誤差は四捨五入をしたら緩衝できるというのは
だいたいそうだろうとは思うけど
コードによってはこの誤差が致命傷になることはない?
俺はちょっと具体的には思い浮かばないけどこれはあるんじゃないかなという予想を持ってる
どう思います? >>194
例えばゲームエンジンのUnityでは256と257は大違いなんですよ
257のサイズだと512と見なされる 画像処理とかゲームとかだと小数点の切り捨ては大した問題にならんと思う
問題になるのはお金の計算、特に金利回りじゃね?
でも、そういうのって会社ごとにルールが決まってて末端の作業員はそれに忠実に従ってプログラム書けばいいだけだと思う
金融はまともにやったことないけどJavaのビッグデシマル型でないとダメとかCOBOLでやれとかあるんでしょ? >>197
だからトリミングするだろって何度も言わせんなよw
ここで言ってるズレは画像サイズのズレではなく、指定サイズ通りに縮尺した結果で1ピクセル単位で表示がずれる可能性の話をしてる
というかゲームの開発では各サイズ毎に画像作って組み込む事がほとんどだから、プログラムで画像リサイズなんて普通しない ■ このスレッドは過去ログ倉庫に格納されています