こんにちは、記事の始めと終わりに散文を書くのが好きなタイプのエンジニアのむっそです。
暖かな日が増えてくるとTwitter監視が捗ってしまいますが、駆け出しエンジニアや知識の無さを笑ったりするようなつぶやきをときどき見たりします。5年前くらいにたたき上げ的に促成栽培された駆け出しエンジニアのむっそ的にはそういう風潮は好きくないですね。知識の無さを共有できる人は器量も教養もあって私は好きです。
駆け出しエンジニア的な人が道を外さないように不確実性を減らしていくように記事を書いたりできればなと思う所存で候うございます。
はじめに
この記事を読む方はITエンジニアの方が多いと思いますが、やはりエンジニア人生をやっていると
「バックエンド飽きたからイケてるフロントエンドエンジニアになりたい！」
「転職して新しい言語を学ばないといけない！」
っていう時、ありますよね。知らんけど
私もスタートアップに転職する前はReactもTypeScriptも書いたことも読んだこともない状態だったので、勉強しないとやべぇかもという感じでした。結果的にいまはなんとかなってる部分もありますが日々是勉強です。
ということでプログラミング言語を新しく覚えたいときに試すこと7選というテーマで書いていきます。あくまで私の主観が大いに入っているので、好きなやり方でやっていただければと思います。
1. オンライン学習サービスを使ってみる
1つ目から「オンライン学習サービスを使ってみましょう！」というと ステマですか？？ と疑われそうですが、実際わからないところがわからないという状態だったり、つくりたいアプリのテーマもなくモチベーションがほぼないというひとにはオンライン学習サービスはオススメです。
Twitter監視していると、高額なオンライン教材を買わせるサービスが炎上しまくってるときがあります。しかし燃えているものは本当にひどい教材なだけで、ちゃんとインターネットで探して、ちゃんとレビューを見て、ちゃんと講師が怪しくないかチェックして買えば、 購入コストの割に得られる知識が多くて良かった！ という例はあるものです。
たとえば私がReactもTypeScriptもわからん！ってなってたときに購入したのは下記のようなUdemyの教材です。Udemyはタイミングが良ければ1万円くらいのものが2000円とかのレベルで買えるのでセール中に買うのが良いです。
(値引率がえげつなくて引くときもあります)
この教材を買った理由はなんとなく講師の話し方だったりIT経験などを聞いて好感が持てそうだなぁというだけです。
「なんか鼻につく話し方だな。うさんくさいな」 とか違和感を感じたら買わないほうが良いですし、人間の五感みたいなものは意外と信用になるものです。多分
2. 入門書を買う
ものすごくやる気がでないときに「PCのローカル環境をセットアップして実行する」という作業自体が辛かったりします。またPC自体を持っていけない状態だけれども実際に手を動かさずになんとなく新しい言語を読みたいという場合もあったりしますね。
そんな場合は、Amazonなどのレビュー評価が高い入門書を購入すると良いですね。
個人的に良い入門書は 目次の構成がMECE(漏れなく・ダブりなく) なものが好きです。
「この本の1章と8章、同じことをちょっと言い換えただけやん」みたいなものを見るとすぐ買うのをやめます笑
たとえばRustの入門書といえば実践Rustプログラミング入門がすごくおすすめです。
基本的なことから組み込みやGUIアプリケーションのことまで網羅されていて、最強の入門書を作ってくれてありがとうという気持ちでいっぱいです。このような最強の入門書を手に入れられれば新しい言語への心理的な障壁は薄れていくと思います。
さらに重要なのはその本にGithubへのリンクがあるかということです。 ちゃんと動くサンプルプログラムを用意していたり間違ったプログラムに関するissueがGithubにあって著者が回答しているような入門書はかなりポイントが高いです。
その労力に感謝と敬意しかありません。
3. デバッグ環境を整える
この記事に書いた通り、デバッグ環境をちゃんと整えてあげることでトライアンドエラーを効率良くできるので、まずデバッグ環境を整えていくらでも失敗できるような環境を作るのが良いと思います。
ただ難点としては開発環境へのインストールや環境変数などの設定などは地道な作業になるため、あまり好きではないという人が多いと思います。環境構築ができなくて「やっぱ新しい言語を学ぶのをやめよう」となってしまうのは実にもったいないので、環境構築があまり好きではないひとは 各言語が用意しているプレイグラウンドなどで遊ぶ というのも良いと思います。
4. AtCoder過去問精選10問をやってみる
AtCoderとは「競技プログラミング」と呼ばれるコンピュータプログラムのコンテストを行うサービスです。
「人と競ってプログラミングできるレベルじゃないです」と思われると思いますが、競技自体をやらずとも問題を解くことでアルゴリズム/データ構造や計算量を意識できるようになるのでとてもオススメです。
しかもけんちょんさんという方のQiitaの記事は結構良質なものが多いので私はけんちょんさん推しです笑
基本的に処理パフォーマンスが良いC++の記事が多いですが、他の言語を使う方もいるので学びたい言語に応じて推し競プロerができると良いかと思います。
やはり新しい言語を読むだけだと実際に書いてみたときに 「あれ？？」 ってなることがあるので、AtCoderの問題を通じて実際に書いてみるのが良いのかもしれないですね。競プロ特有の特殊なマクロや標準入力の受け取り方の高速化などの話もあるのですが、最初のうちはそういうテクニックはちょっとだけパクるかスルーしてもらうと良いです。
最近Rustを学んでいるのですが、例題として下記のような問題をRustで解くとこんな感じです。
（まだRustが手に馴染んでないので良い感じの書き方を模索中です）
みなさんもいっぱい書いていっぱい失敗しましょう。
第 2 問: ABC 081 A - Placing Marbles (100 点)
【問題概要】
0 と 1 のみから成る 3 桁の番号 s が与えられます。1 が何個含まれるかを求めてください。
【数値例】
1)
s = "101"
答え: 22
'1' が 2 個含まれています。
Rustで書いた場合
use std::io::*;
use std::str::FromStr;
fn read<T: FromStr>() -> T {
let stdin = stdin();
let stdin = stdin.lock();
let token: String = stdin
.bytes()
.map(|c| c.expect("failed to read char") as char)
.skip_while(|c| c.is_whitespace())
.take_while(|c| !c.is_whitespace())
.collect();
token.parse().ok().expect("failed to parse token")
}
fn main() {
let a: String = read();
let leng : usize = a.len();
let mut ans : u32 = 0;
for i in 0..leng {
if a.chars().nth(i).unwrap() == '1' {
ans += 1
}
}
println!("{}", ans);
}
5. つよつよエンジニアを追う
さきほどけんちょんさんという方を推しているという話をしましたが、世の中にはたくさんのつよつよエンジニアがいます。
つよつよエンジニアが強すぎて嫉妬したり「自分なんて」と卑下するのであれば追わないほうが良いですが、彼らの見ている世界をTwitterやQiitaのブログなどを通じてちょっと覗ける世界になったのは良い刺激になるなぁと思います。
私も自分の学びたい言語や分野に関してつよつよなひとをフォローするようにしています。
ただ物理的に追いすぎると警察を呼ばれてしまうのでやめましょう。
またネットストーカーも公序良俗の範囲内でお願いします...
6. 言語の特性や歴史を知る
プログラミング言語は自然言語(日本語や英語)と比べて 文章の曖昧性が少なく、新しく作られたプログラミング言語は従来のプログラミング言語よりなにかしらの点で改善させようという明確な設計思想があって作られている のかなぁと私は考えています。なのでそれぞれのプログラミング言語のメリット/デメリットを比較したり歴史や設計思想を見てみることで、この新しい言語を学ぶ意義はこういうところにあるという認識や動機付けができたほうが、長期的に学習を進めるにあたって良いのではないかと考えています。
たとえば私の場合だとRustやTypeScriptの概要をざっくりWikipediaで調べたりします。Wikipediaだと全体的に難しい単語が並んでますが、Rustであれば 性能、メモリ安全性、安全な並行性を目指して設計されていてC言語、C++に代わるシステムプログラミング言語を目指してるんだなぁ というのがざっくりわかります。大事なのはチョコモナカジャンボ並みのざっくり感です。
ちょっと脱線して、プログラミング言語と自然言語の本質は異なるのかという部分については ゆる言語学ラジオ という最近私が個人的に刺さっているYouTubeチャンネルがあるので、気になる方はぜひご覧ください。
7. 公式ドキュメントを読む
結局公式ドキュメントというのが究極の原典ですね。
言語によりますが公式ドキュメントが堅い文章すぎて読みたくないという感じのものもあったりするので、やる気がなくなるようであればちょっと慣れてきた段階で公式ドキュメントを読むというので良いと思います。
（デバッグしなくてはいけないときはやはり公式ドキュメント読まざるを得ないです）
たとえばReactの公式ドキュメントは英語版の他にも日本語版もあるので、ある程度体系的に学びたい場合やクラスやメソッドの引数でどの値が取れるのかなどの詳細情報は公式ドキュメントを読んでみましょう。
あとがき
新しいことを学ぶのって面白い半面、ストレスがかかったりするのでこの記事でそういうストレスが軽減できれば幸いです。
「プログラミング言語」というとなんだか科学ぽいですが、ソフトウェアエンジニアとして仕事をしていると「世界のどの部分を切り取って言語化、コード化するか」という問題が出てきたりして、なんだか認知言語学とかそういう話とリンクするよなぁと思ったりします。アジャイル開発なんかも心理学的なアプローチも含む手法だったりしますし。
結局優れたプログラマーになるにはコンピュータサイエンス以外にも教養力(歴史、哲学、政治、心理学とか)みたいなのが必要な気がして、途方もなく道のりが長いなぁとモヤモヤしながらこの記事を終えたいと思います。
ありがとうございました。