  |
はてなキーワード: javaとは
どうしてマジで未だに企業の無料講習や職業訓練はJavaなんだろうな・・・
PHP(＋JavaScript)、Pythonあたりならエントリーレベルでも仕事あるけど、
Javaとかエントリーレベルは開発保守(大抵地獄)しかないやろ
そもそもエントリーレベル到達以前に習得挫折する可能性すらあるやろ・・・
不正解でscore += 0; と書いているのは静的解析がelse節を省略すると指摘してくるから。
何もしていない、はそのとおり。
不等号がいい具合に化けてるのでそのままにしておく。
import java.util.*; public class Main { public static void main(String[] args) { // 入力のparse (中略:int numに問題の数、String list[i][] に問題のリストを格納している) // 採点 int point = 0; for (int i = 0; i < num; i++) { String question = list[i][0]; String answer = list[i][1]; if (question.equals(answer)) { // 完全一致 point += 2; } else { if (question.length() == answer.length()) { // 文字数は等しい（部分点の可能性がある） point += scoring(question, answer); } else { // 不正解 point += 0; } } } System.out.println(point); } // 長さが同じ文字列を採点する // 長さが違う文字列を受け渡したときは正しく動作しない private static int scoring(String question, String answer) { int length = question.length(); int score = 2; for (int i = 0; i < length; i++) { (中略:文字が違うたびにscoreを-1して、socreが0以下になったらそのままreturn) } return score; } }
割りとマジだよねと思う出来事をふと思い出したので書いてみる。
といっても後輩が俺の思ってもいないところでつまづいて、それに俺がカルチャーショックを受けたというだけの話。
問題の話なんだけど、とある有名サービスのJSON APIを叩いて呼び出し結果を手元のオブジェクトにマッピングするというただそれだけのコードを書くというもの。
普通に考えて一日もしないで出来ると思うような代物だけど、三日以上悩んで彼はそれでも出来なかった。
{ ..., "count": 10000000000000000000000000000000000000, ...}
という感じで多倍長整数がリテラルとして書かれているのを前提として受け取る仕様だった。
JavaScriptの通常の整数と違って、JSONの整数リテラルは仕様上大きさの制限の記載がないので、上のようなのも合法。
で、彼の使ってたプログラミング言語のオブジェクト から JSONの変換ライブラリが、多倍長整数を文字列（""）としてシリアライズするような仕様なことがわかって、彼は行き詰まった。
そこで何をやり始めたかというと、JSONの整数がそのまま1000000000000000みたいにシリアライズされるライブラリ探し始めたんだけど、それは見つからないまま。
というわけで「増田さん、詰まってるんですけど……」と言われて助け舟出すことになったはいいものの、彼のコード見るとJSONの抽象構文木クラスがそのまま使えるようだった。
なので、
String serialiaze(Ast.JsValue value) { return switch(value) { case Ast.JsNull nullValue-> "null"; case Ast.JsInt bigIntValue -> bigIntValue.toString(); case Ast.JsArray arrayValue -> arrayValue.stream().map(v -> serialize(v)).collect(Collectors.joining(", ", "[", "]")); // 他のJSONの木についても同様に処理 default -> throw new RuntimeException("cannot reach") }; }
1時間しない内にこんな感じのコード（言語はJavaじゃなかったけど、だいたいこういう感じ）を書いて無事問題解決。細かいタイポとかあるかもだけど、日記では確認してないのでそれはおいといて）。
結局、JSONの形が期待と違って、しかも既存のAPIじゃいいのがなかったのに延々API探すことしか出来なかったのが問題解決できなかった原因だけど、このくらいのは割りとちょこちょこある。
きっと、それから一週間放置しても問題解決できなかっただろうし、どうも同じチームの同僚も問題を解決できなかったようだった。
最近、APIは叩けるけど、そこでトラブルとどうにもならなくエンジニアにちょくちょく遭遇するんだけど、やっぱりもうちょっと基礎出来てないと駄目だなと思った出来事だった。
具体的には、再帰が相性が良いプログラムを書けるとか、APIに頼れないときはさっさと自作する頭の切り替えとかもろもろ。
↑を書いた元増田ですが、VBの話から派生した話で、やたらコマンドライン(以下CLI)を使った開発に否定的な人間がいて閉口した件。
そりゃ一口に開発と言っても色々なので、本当に統合開発環境(以下IDE)だけで開発するケースもあるのは、こっちも知ってるんだよ。
だから学習者の中で「何をやりたいか」が既に決まっているなら、CLIを全く触らずプログラミングを学ぶケースもアリということなのだろう。
1つ目は、そもそも「プログラムって何？」というレベルの人が「何をやりたいか」なんて決まっているわけがないので、最初から「何をやるか」を決めてかかるのはナンセンスという話。
むしろどういう開発に進んでもいいように、「等号は代入を意味する」辺りから始まって、どんなプログラミングでも基礎の基礎になる、データ構造とアルゴリズムを意識させることに集中させたい。
そのためには難易度低めで比較的潰しが効く言語を、できるだけシンプルな手順で作業できる開発環境で学べる方がいい。
そしたらPythonの実行環境とそこそこ以上の機能を持つテキストエディタを入れて、コマンドプロンプトとかPowerShellとかのCLIから"Helllo, world"が取っ掛かりだと思うわけ。
もしLinuxの環境が用意できるなら同じことをLinuxでも試してもらって、プラットフォームに依存しない開発の入り口くらいを知っておければベター。
いずれにせよ何かを実行する方法が1つではないという重要な知見は、できれば基礎のうちに知ってもらいたいことの1つだし、それはWindowsとLinuxとかCLIとIDEという対比がうってつけかなーと。
ちなみにIDEは、Pythonによる手続き型プログラミングに慣れた後のタイミングで学べばいいと思う。
そこまで行ったら変数の型や、クラスとオブジェクトとかの難しい話をGo言語で学んでおくことで、現場で使われているJava、C#、swiftへの移行もスムーズになりそうだし。
ちなみに「初心者コース」の最後、もし可能ならRustでポインタとメモリの話の触りくらいを体験してもらえると、組み込みに進む際のハードルが少しは下がるんじゃないかな。
もう1つは、いくら現場によってはIDEだけで開発する現実があっても、CLIを使った開発がどういうものかくらい、プログラマにとっては知ってて当たり前じゃねーの？という話。
もちろん「プログラマが何を知ってて当たり前なのか」は、時代の移り変わりとともにどんどん変わる。
大昔ならおそらく機械語とかが必須だっただろうけど、今なら機械語よりはHTMLを読めるほうが遥かに重要なわけで。
あと、UNIX系OSをパーティションごとに主要なディレクトリを分割してインストールしていた時代であれば、edエディタの使い方は必須だったと聞く。
(/binに入るエディタがedのみだったため、もし使えないとシステムクラッシュして/以外マウントできなくなったときに詰む)
でも今やそんなの完全に過去の話どころか、viとemacsの論争ですら多分古い方の問題になるだろう。
そういう過去の諸々も踏まえるとCLIが未来永劫、プログラマにとって常識的なナレッジだとは自分も思っていない。
でも今はまだ、プログラマを名乗るならCLIからコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
自分が業界に入った頃はVisualBasic使ってWindows用の業務アプリ作れますって人や会社が大量にいたんだけど、今はそんな需要はほとんどないわけで
その次にきたC#やJavaで業務システム作れます、PHPやRuby使ってWebサイト作れますブームも終わったし
なんで、PythonやらJavaScriptやらRubyが初心者向けと勧められちゃうんだろう。
a = 100
puts a
とか打ち込んでぱっと実行結果が見れるから、その瞬間は簡単に思えるけど、20行やら30行やら100行とかちょっと行数が増えるだけでこれらの言語ってJavaやらC#に比べたら格段にコード書くのが難しくなるよね。
初心者が数行程度のコードを書いて「Python簡単じゃん！」と騙されるのはわかるけど、人にどの言語がいいとか勧めてる人ってそこそこコードを書いてる人らだよね。
初心者はPythonから始めましょう。やりたいことはPythonでだいたいできます。世界で一番人気の言語で資産も豊富にあります。低学歴の素人がなんと言おうとPythonです。Pythonを覚えるのです。簡単なので1日あれば覚えられるでしょう。
次にSQLを勉強しましょう。SQLは3日くらいあれば中級者になれるでしょう。現代のデータベースはだいたいSQLかそれのパチモンが備わっています。SQLができると仕事の幅が広がるでしょう。
そしてJavaScriptは勉強しておきましょう。Webブラウザは全部JavaScriptが動きます。JavaScriptを勉強することでWebページで遊ぶことができるようになります。スクレイピングなどの理解も深まります。JavaScriptは便利です。
さて、ここまで来たら仕事に必要なプログラミングは身についているので次に進む必要は無いです。コンピュータの気持ちを理解するためにはC言語をかじってみるのもいいでしょう。大企業で働きたいならJavaは必須です。型に興味を持ったらOCamlやHaskellに手を出してみても良いでしょう。システムプログラミングをしたいならGoやRustも良いです。Goはバカみたいに簡単ですがRustは初心者向きではないです。
Python使ってて、そんな初学レベルでお手上げになるようだったらプログラミング向いてないよ。
Eclipseとか優れた開発環境のないJavaなんて書きたくない
Java単体では書きたいと思えない
C#もVisual StudioとかIntellisenseありきだと思える
C++は全然詳しくないので、それこそSTLがどうこうみたいなのは正直分からない。
あくまでCとの比較なんだけど、一般的に難しい方の言語と言われるRustでも、Cのソースに比べたら全然読みやすいことにびっくりした。
特にポインタ周りの記述は、＆とか*の書き方がCから少し変わっただけなのに、ぐっと読みやすくなってる件。
これならCやRustを使う上で絶対的に必要な、メモリの話も理解しやすいだろう。
なので先にRustを学んでおけば、後でCに取り掛かる際のハードルはだいぶ低くなりそう。
そうなると、今だと全くのゼロからプログラミングを学ぶなら順番としてはPython→Go→Rustになるのかな。
正直JavaやC#やSwiftは必要になってから学んでも遅くはないし、Goを知っていれば多分そこまで難しくない。
VBに至ってはExcelやAccessのマクロに手を付けなきゃいけないときが来ない限り、全く知らなくても問題ない。
↓てな具合なのでそういうプログラムが作れるだけでも社会の平均？中央値から見れば立派立派
500動け動けウゴウゴ5ちゃんねる2020/06/14(日) 12:57:52.17ID:6qfdYEVd0>>501
規制が有効なBBSでスマホからアクセスするとsmartphone_idなるjavaが存在する。
501動け動けウゴウゴ5ちゃんねる2020/06/14(日) 20:35:49.18ID:gDZ1+EG90>>505
https://www.applican.com/tutorial/p11/index.html
こういうのね
偽装もし放題なんだが
505動け動けウゴウゴ5ちゃんねる2020/06/16(火) 21:36:47.88ID:KpWEJQvH0
ましてや優れた人から教えて貰うことでもなく
ただただプログラミングを好きになってモノづくりに熱中することだ
小さい子供がプログラミングに向いているのはモノづくりが好きだからであって
これは大人でも当てはまることであって
何かのモノづくりをするという目的の元に手段としてプログラミングが選ばれ
それに熱中することでいつの間にかプログラミング能力は向上していくのだ
上司から命令されてプログラミング講座を会社の金で受講するとか
Googleを目指して学生時代にプログラミングに打ち込むだとか
そんなのは全然上手く行かないのに定年退職したジジイがラズパイ使ってロボ作りとか始めると上手く行くのはそのせいだ
GitHubが発明したPull Requestはこの楽しみを徹底的に阻害している
「ちょっとこの辺は微妙だけど他のことやりたいから適当に済ませよう」
こうした行為はモノづくりからはほど遠く必要無いものに見えてしまい
「早く動いているところを見たい」
やがて開発者はプログラミングそのものに従事して嫌いになっていくのだ
以前からプロの現場ではもっと厳しい品質管理がなされていたという人がたまにいる
PRによってアジャイルの現場に品質管理がもたらされたと主張するのだ
命名規則やコメントの書き方などルール化できるものは別にレビューなど必要無くツールで弾くことができる
バグがあるかどうかはテストで担保すべきであってレビューで見るべきではない
この手のレビュワーが好んで使う言葉として「技術的負債」というものがある
技術的負債を残さないためにもPRで品質を保つ という主張である
一方で技術進歩は止められるわけが無く10年前に必死でクラス設計したJavaのシステムは
またはレビュワーの考える言語化できない「品質」のために今日もPRはリジェクトされる
人はプログラミングを嫌いになっていくのだ
某話題の書籍を買って読みました。ひととおり読んだのですが、話題の1章を読みつつ取ったメモを、本が回収される前に置いておこうと思います。
ちなみに最初は電子書籍で読んだのですが、回収かもって話を聞いて紙も買いました。
以下にメモをそのままのっけるので、たぶん書籍と照らさないと意味不明だと思います。
・Web1は「1970年代から1980年代」というのが若干謎ではあるが、この本ではそういう定義だとおもって受け入れる余地はあるか。実際、列挙されているTCP/IP・SMTP・HTTPの最初のRFCは70～80年代
・HTTPはWebサイトの「構築」をするものではない（Webサイトのデータを取ってくるためのプロトコルである）
・TCP/IPの4層モデルとかOSI参照モデルとかを意識しているんだろうけれど、いまひとつWeb2とWeb3の対比ができていない。また、後段で「ブロックチェーンもプロトコル」と主張する割に、このLayersにも「Protocol Layer」が存在しており、いまいち言いたいことが伝わってこない
・Web2 Layersの雑さは見ての通り。「中間のレイヤー」としてなにを想定しているのかが気になるところ。「プラットフォーマーの上に載っている」という結論ありきで作られた図のように思える
・Web1の例としてHTML/CSSのWebサイトのことを提示しており、それはそれで正しいのだが、冒頭のWeb1は1980年代のプロトコル云々というところと整合しない。
・JavaやRubyはわかる C++もそりゃあたくさん使われてるわけだが、この並びで出てくるのはちょっと違和感。PHPとかは？
あとP2PはべつにWeb3独自ではない SkypeとかWinnyとか、クライアント・サーバではない仕組みは2000年代からいくらでもある
・このへんはあんま詳しくないのでよくわかんなかった そういえばログインIDにメールアドレスを使わせるようになったのってなんでなんでしょうね
・この書き方だとSNSログインすると情報収集できそうに読めるけど、SNSログインを介したからって即ログイン先の情報をプラットフォーマーが集められるわけではない
・ブラウザのとこはそうだね～っていう感じだったが、Firefoxがハブられてるのがかなしかった オープン云々のはなしをしたいならMozilla財団の果たした役割は相当に大きいと思うのだが、（この本に限らず）無視されてることが多い
・OSの部分は突っ込みどころがいっぱいあるしスクショがバズったのですでに突っ込まれている
・あくまで例示で出てきてるだけなので本質的なところではないし、よくあるまちがいではあるのだが、POPはどちらかというと「受信したメールを取ってくるため」のプロトコルと呼んだほうがいいと思う じぶんが使っているメールサーバ（というかMTA）までメールが届くのはあくまでSMTPが使われている 「プロトコルが一緒じゃないと～」という文脈で考えると、いったん向こうのMTAに到達しさえすれば、読み手がPOP3で受信しようがIMAP4で受信しようがどうでもいいわけで、例示としてあんまりうまくない
・唐突にICMPが出てきてびっくりした 重要であることはまちがいないのだが、あんまり「プロトコルの例」として出てくるとこはみないので
・後段で「Web3ではいろんなプロトコルがあるんですよ～」という話をするんだったら、ここでWeb3のプロトコルとしてBitcoinとEthereumしか出さないのはなんか話が通りにくいのではないか
俺はまだ辞めないが、去年入った新人が辞めたのでなんとなくだだらと書く。
残業は月20hくらいで手取りは28万くらい。残業次第で変わるので手取り額ってあんま当てにならんよね。高収入というほどでもなく低収入と言ったら怒られるくらいの微妙な層。
はてなに書いたらそれだけでアンチ湧くレベルのFラン理系。クソみたいな学部論文からのクソを具現化した修士論文で一応院卒。謙遜とか自虐ではなくマジで就活が嫌だったのでなんとなくで院に行き、マビノギに明け暮れてろくに研究室に顔出さずに論文出して教授からはノーコメントをもらい発表会で他大学のせんせから「この研究、何？」と言われたくらいには意識が低い。
就活やる気起きなさすぎてうだうだしてて、当時の彼女に未来が無いと振られてしゃーなしで学内専攻行ったらそれが富士通で適当行ったら通った。俺はハリボテが得意なんだ。
雑用。エクセルひたすら編集したりjava書いたりbash書いたりマクロ書いたりRHELいじったりpostgres弄ったり客とだべったりパートナーとだべったりオフショア折衝したり。
大学時代はクソだったが仕事は流石にそうもいかんのでちゃんと毎日出社して自分のこと仕事はこなしてる。お金は欲しいので。
管理職になりたくないので一生下っ端みたいな仕事してたい。マネジメントは一応資格とったけど二度とやりたくねえ。
パートナー会社、大抵は良い人だしスキルもあるんだけど、この世に俺以上のカスがいるのかと思わせられるクラスのカスがいるしそんな人間のマネジメントさせられるのももう面倒でいやだ。
「勉強！勉強！」みたいなキラキラSEではなく仕事で必要になったら「ほなクラウドの取説読むかあ……」みたいな意識低い系。
というかインターネットに住んでるITマンすごいね。仕事おわったら酒酒シコ酒ゲーム酒でしょ。それが正しい人間の生き方だよ。
みたいな昭和カンパニー的な感じはない。申請事項と申請フローはクソ多いので面倒。
うちはBtoGなんでせいぜい二億くらいの小規模案件多いから部長本部長決裁で適当に説明にして承認もらえるけど、BtoBで銀行とか企業相手にしてるところは社長決裁とかあってヤバいらしい。
よく退職エントリで見る開発PCが低スペック！！！みたいなのは意味わからん話。稟議出して購入手続きすればCPUメモリ増し増し40万くらいのマシンが社内価格で20万くらいで買えるので。FCNT別会社になったはずなんだけど、まだpc安くてよかった。win11のマシンが欲しくて今年頭に買ったので最近の話ね。
有給はフルで毎年20取ってる。みんな取ってるから俺だけ勝手に休んでる訳じゃないぞ。
社内の連絡手段はメールがlyncかteams。lyncはもうすぐ終わるらしい。lyncとteams両方生きてるせいでどっちもアプリ立ち上げとかないといけなかったのではよ終われ。
ファイル保存はネットワークドライブと皆様ご存知projectWEBだったけど、ネットワークドライブは、boxに移行し、そのboxはろくにつかわれないままonedriveとshrepointになった。
projectwebはなんだかんだで便利だった。エクスプローラー感覚でできるファイル管理とチケット管理とタスク管理できるシステムはUI古く見えても便利だったよ。
仕事は全部テレワーク。最近「でもやっぱ直接会うのって大事だよネ……！」とか上層部が言い出したので、たまには出社するようにとのことらしい。課会で「マネージャーとチームリーダーが出社したことでチーム内コミュニケーションとする」という空報告が決まった。
幹部社員崩れの老害社員は1人いる。正確にいうと仕事はできるしいうことも正論だがお小言が多くコロナ前にあった飲み会の場では「俺の若い頃は〜」という話を延々と続け、俺とはソリが合わない上に体臭がきついので俺は嫌っている。耳ほじった手でキーボード触んな。
今まで4人面倒見たけど全員離れて行った。
本人の希望ではなく会社都合で別部署になったのが2人、本人の希望で別部署行ったのが1人、そしてYouTubeに本腰入れるためと言って入社一年目で辞めたのがこれ書く契機になった1人。
別部署行った子も「わたし文系出身だからSEの仕事合いません…」っつって営業に行ったのでまあわかる。向き不向きあるしね。変数名にint OkyakusamaNunberと付けてきたのも良い思い出。せめて綴りは合っててくれ。
君と夏の終わり、将来の夢、rm -rf /*したテスト環境忘れない。
それはそうとYouTuberよ。
そんな「父さんな、YouTubeで食っていこうと思うんだ」みたいな台詞現実で聞くことになるとは思わなくて三回くらい聞き直しちゃったもんね。
いや俺もVtuber見てるからYouTuber自体に理解が無いわけでは無いのよ？
でもさあ。「チャンネル登録者1000人の大台に乗ったんです！いま踏ん張らないと！」とか言われてもさあ、1000人クラスでよく会社辞める決心ついたな……としか思わんじゃん？
仕事に不満はなかったというが立つ鳥跡を濁さなかっただけなのかはよくわからん。振り返ってみてもそんな旧態依然としたオールドカンパニー、待遇激悪、未来なしみたいな会社じゃ無いと思うんだが。
チームメンバーみんな「えっ辞めるんだ……1年経ってないのに……」っていう戸惑いの後に「YouTuber???????」っていう戸惑いあったもん。オンライン会議のマイクの向こうから伝わる、必死に言葉選んで「ゆ、ゆーちゅーばーやるために会社辞めるの？」という問いかけにちょっと怒り気味で答えた君の勇姿美しい。