#クローリング型求人サイト | Explore Tumblr Posts and Blogs

petapeta · 4 years

Quote

発表１：「Librahack事件と図書館」新　出（図書館問題研究会・静岡県立中央図書館） →　当日資料(PDF) 　職場ではシステム担当ではなく，特にシステムに詳しいわけではない。所属する図書館問題研究会が本件について声明を出していることや，図書館現場からこの事件への発言者が少ないこともあり，このテーマで何度か話をしている。１．事件の概要岡崎市立中央図書館では，2010年3月中旬から図書館WEBサイトにつながりにくい状態が発生し，システムを管理する三菱電機インフォメーションシステムズ（以下MDIS）に調査を依頼し各種の方策をとったが解決しなかった。岡崎署に相談，4月15日に被害届を提出。またこれに前後して図書館ウェブサイトへのアクセスログおよび利用者4名の個人情報を警察に提出した。　2010年5月25日，「岡崎市立中央図書館のホームページに集中的にアクセスして閲覧しにくくした」として，中川圭右氏が偽計業務妨害の疑いで連行・逮捕され，新聞等に実名報道された。２１日間の勾留の後，6月14日起訴猶予処分で釈放。6月19日に自身のブログ「Librahack」（http://librahack.jp/）に事件の経緯を公開した。　ブログによると，中川氏が実行したプログラムは図書館の新着図書ページにアクセスし，ISBNや予約数を取得，新着日付を付与するもの。毎秒１回程度のシリアルアクセスを毎日1時間実行するものだった。これは図書館の新着図書ページが数カ月分を受入日付なしに表示するものであるため，図書館のヘビーユーザーである中川氏には不便であったためである。　この事件は，IT関係者の間では報道当初から疑問視されていた。1秒1回のシリアルアクセスは常識的なものであり，これでサーバが落ちることは考えられないからである。 8月21日　朝日新聞が「図書館HP閲覧不能，サイバー攻撃の容疑者逮捕，だが…」の見出しで図書館システムの不具合が原因と報道。この報道により，より広い層の関心が集まった。 9月1日　図書館が公式見解をWEBサイトに発表。 9月8日　図書館問題研究会が事件への見解を発表。 9月28日　MDISがえびの市など他の自治体に納入している同型の図書館システムを通じて，岡崎市立図書館の個人情報（督促情報など）が流出していることが判明。 11月26日　岡崎市，MDISとの契約を解除，1年6カ月の指名停止。 11月30日　MDISが謝罪会見。 12月　　　中川氏が市民団体を通じて，被害届の取り下げを市長・求める書面を提出。という経過をたどっている。詳細はサイト「Librahack：容疑者からみた岡崎図書館事件」（http://librahack.jp/），「岡崎市立中央図書館事件等　議論と検証のまとめ」（http://www26.atwiki.jp/librahack/）にくわしい。　なおLibrahack氏こと中川さんに関しては，逮捕そのものが不当であり，実名で報告することで氏の名誉回復を行う趣旨で，あえて実名での報告を行っている。２．どうすればよかったのか　この事件の対応では，ベンダー・警察・図書館がそれぞれミスをした。　図書館はどうすればよかったのか？通常の対応としては，まずプロバイダを経由してアクセス元に負荷が大きいことを伝えてもらう。ついで専門機関（JPCERT，IPAなど）に相談し，それでもだめな時に警察，が一般的。今回，こうした手順が踏まれなかった。最近，IPAが「サービス妨害攻撃の対策等調査」報告書を公開しており，参考になる。３．事件の背景１）ネット上と図書館業界に大きな温度差　ネット上やIT業界では，朝日新聞報道以前からこの事件に関する議論があり，有志による情報収集・真相究明活動が行われていた。7月16日にはパネルディスカッション「岡崎市立中央図書館へのアクセスはDoS攻撃だったか？」（技術屋と法律屋の座談会）が行われている。その背景には，クローリングは一般化しており，プログラムを書ける人には日常的な行為であること，そのことで逮捕・勾留されるようでは怖くてたまらない，やりたいことができなくなるという委縮効果への危機感がある。２）図書館員のICT知識レベルはこれでよいのか　図書館の問題として，ITにくわしくないのは「仕方ない」のか。基礎的なICT知識が欠如している現状を，仕方がないといってすませてしまっていていいのか。　三菱総研の報告書「図書館システムに係る現状調査」（2010.8）によると，専任のシステム担当者を置いている図書館は6％，担当者をおかない館は41％，8割近くの館が外部のIT専門家の支援を受けていない。自治体のITセクションとの関係も希薄である。業界として，こうした事態をどうしていけばいいのか。このままでいいのかという問題がある。３）システムベンダー・外部機関・捜査機関との関係　「IT版ストックホルム症候群」という表現がある。第三者的，客観的評価ができずにベンダーに依存し，いうことを鵜呑みにしたことが今回の事件の一因である。高木浩光氏（産総研）は今回の事件での図書館員の対応に，他人のいうことに耳を傾けず，組織内で決めたことに固執する印象を受けたという。技術は日進月歩で，これを身につければ終わりというものはない。必要な知識はどんどん変わっていく。その都度，外部の専門家の話にきちんと耳を傾ける姿勢を持つことが重要である。　「警察がきちんと検討してくれれば逮捕に至らなかったのに…」という意見もあるが，警察が無謬という前提で行動すべきではない。事件性の判断をアウトソーシングしてはいけない。被害届を出せば相手が逮捕されるかもしれないという認識を図書館はもっていなかった。４）WEBサービス利用への意識　今回，アクセスしてきた相手に直接コンタクトをとらずにいきなり警察に頼ったのはなぜか？リアルの利用者なら必ず直接コンタクトしたはず。それが，WEBサービス利用者に対してはこうした対応をしてしまった。図書館にとってメインのサービスはリアル利用者であり，WEBサービスは単に来館利用の延長としてしかとらえていないのではないか。　今後，電子書籍など，来館しなくても完結するサービスが増えていく。WEB利用者は顔が見えない，意図が読めない，市民かどうかもわからない。加えて自分に知識がないと，非和解的対応をしがち。事前に断ってアクセスを，という意見があるが，WEBサイトを開いた以上，インターネットは誰が来ても文句を言えない空間。プログラムを使った予約は「悪」，より便利にアクセスすることは「ずるい」と見る考え方もある。ほとんどの「普通」の来館利用者が満足しているから問題はないのだろうか。WEBサービスの拡大に伴い，WEBサービス利用者もリアルの利用者と対等な利用者であるというふうに図書館員の意識を変えていく必要がある。５）図書館の自由の問題として　狭義の自由の問題としては，利用者情報の提出がある。アクセスログと一緒に，「大量」アクセス元であった「さくらインターネット」ドメインのメールアドレスを持つ利用者４名の個人情報を県警の捜査関係事項照会に応じて提出している。図書館自身が被害届を出したという事情もあり，事件解決のために必要といわれればどこまで拒めるのかは難しい問題があるが，結果的に無関係だった4名の利用者個人情報の提出は正当化できるだろうか。　アクセスログについては，利用事実か否かについての共通認識はまだない。図書館サイトの利用が利用なら，アクセスログは利用事実であり，まず共通認識を作る必要がある。　より重大な問題は，ごく当然の利用（知的自由の行使）によって，利用者が図書館自身に告発され身体の自由を奪われたこと。図書館自身の対応によって利用者に迷惑をかけたことに反省が見られない。あたかも事故のような認識である。真摯に反省し，中川さんの名誉回復をはかるべきではないか。　図書館が利用者の情報アクセスを保証する必要をうたったアメリカ「図書館の自由宣言」解説文「電子情報，サービス，ネットワークへのアクセス」と比較して，日本の「図書館の自由宣言」は「資料と施設を提供する」としており意識が固定的。WEBアクセスを「図書館利用」の概念に含める合意を形成し，図書館の自由を拡張的に考えていく必要がある。４．改善のための方策　WEBアクセスを図書館利用概念に含め，図書館業界で合意形成していくこと。図書館員への基礎的な知識の研修実施。専門機関（JPCERT，IPA）への照会など危機管理・対応手法の啓発，JLAなどによる相談窓口の開設。自治体情報システム部門との連携。システム仕様書作成ノウハウの共有。そして利用者や外部からの声に耳を傾けることなどがある。　

「岡崎市立図書館Librahack事件から見えてきたもの」：第277回研究例会報告

9 notes · View notes

tak4hir0 · 4 years

Link

このエントリーは、GMOアドマーケティング Advent Calendar 2018の【12/12】の記事です。 GMOアドマーケティングとしては初のAdvent Calendar参戦です。こんにちは。GMOアドマーケティングのN.Sです。この度Webアプリケーションの脆弱性診断について研修を受けたので、内容について共有します。 OWASP ZAPという自動診断ツールを使って、診断から対策までの流れをざっと説明します。環境Mac：10.12.6(Sierra) OWASP ZAP：2.7.0 Burp Suite：1.7.36 インストールOWASP ZAP：https://github.com/zaproxy/zaproxy/wiki/Downloads Burp Suite：https://portswigger.net/burp/communitydownload 対象サイト今回は脆弱性診断レッスン用のサイト「WebGoat」をローカル環境に構築して利用します。環境構築WebGoatはDockerでイメージ化されているので、誰でもdocker pullすることができます。 $ docker pull webgoat/webgoat-8.0 $ docker run -itd -p 127.0.0.1:10080:8080 webgoat/webgoat-8.0 これで「http://localhost:10080/WebGoat」にアクセスし、ログイン画面に入れればOKです。（入れない場合は、ポートフォワーディングが8080に向いてないか、アドレスに「/WebGoat」を付けてないことが多いです。）診断環境ができたら、早速診断していきましょう。診断にはOWASP ZAPというWebアプリケーション自動診断用のツールを使います。（Mac/Windows共に対応）引用元：https://github.com/zaproxy 開くと以下のような画面が開きます。 ▼診断の流れです１．静的スキャン・対象Webサイトのクロール・静的スキャン２．動的スキャン・診断用にパラメータを付加してレスポンスを自動診断３．スキャン結果の精査・１，２の結果が正しいのか手動で確認４．脆弱性対応１．静的スキャン対象Webサイトをクロールし、いくつURIがあるのかなど確認できます。この静的スキャンだけでも少し脆弱性は分析してくれるのですが、どちらかというと後ほど行う動的スキャンの事前準備の意味合いが強いです。まずOWASP ZAPで「クイックスタート」→「Launch Browser」押下でOWASP ZAPをプロキシとして設定されたブラウザを立ち上げます。これによって、CookieをOWASP ZAPで保持してくれるため、ブラウザと自動診断の状態を連携させることができます。サインアップしてサイト内を巡回してみます。サイドバーとコンテンツエリアの画面構成になってます。 ※ここでサイドバーのボタンを全てクリックしておいてください。 OWASP ZAPのサイト一覧がどんどん増えてくのが分かると思います。これを「手動クロール」といいます。 OWASP ZAPのクロール機能である程度ページは網羅してくれるのですが、#（ハッシュタグ）や?（クエリパラメータ）で指定するページは自動クロールしてくれません。そのため、手動でポチポチOWASP ZAPに認識させていく必要があるのです。。手動クロールできたら、次は「スパイダー機能」で自動クロールさせましょう。下側のタブで「スパイダー」タブを選択→「新規スパイダー」押下開始位置に「http://localhost:10080/WebGoat」を指定し、「スキャン開始」します。自動クロール後、画面がログアウトされていますね。。汗どうやらログアウトボタンを踏んでそれっきりになっているようです。これではクロールもままなりません。認証を突破する方法はいくつか存在するのですが、ここではForm-based認証を紹介します。「既定のコンテキスト」→「認証」にてログイン時の認証方法を設定しておきます。一番下の欄に「\Q/WebGoat/login\E」とありますが、これはログアウト状態を判定するため、ログアウト時のレスポンス内容を一部で良いので登録しています。（「\Q」と「\E」で囲む必要があります。）続いて突破用のユーザを作ります。「既定のコンテキスト」→「ユーザ」でログインできるユーザを登録します。再度スパイダーで自動クロールします。今度は「ユーザー」に今ほど登録したユーザを設定します。これでログアウトされずに自動クロールできました。検出URI数も結構増え、私の環境だと475件となりました。ほぼ全てのURIを検出できたと思うので、次は動的スキャンを行います。２．動的スキャン動的スキャンでは、先程と同じコンテキストを使い、実際に攻撃コードを仕掛けていきます。その前に、動的スキャンは静的スキャンと何が違うのか簡単に説明します。静的スキャンは各ページを単にクロールしており、攻撃コードは送っていませんでした。動的スキャンはパラメータを付与・変更し、あらゆるパターンの攻撃コードをシステムに送り込みます。例えばログイン画面で以下のようなパラメータがあったとします。 Username=user01 Password=ZAP　←間違っている上記内容では本来ログインできませんが、以下のようなパラメータに変更してログインできるか検査しています。 Password=ZAP OR 1=1 — また、動的スキャンを行う前に以下のことをお願いします。・プロテクトモードに設定コンテキストで指定したURL内にのみ攻撃するモードです。「コンテキスト」→「コンテキストに含める」にて「http://localhost:10080/WebGoat.*」と登録してください。・実際に攻撃するため、データのバックアップを取るなど、万が一に備えておきましょう。・何万件というリクエストを投げるので、インフラ担当や場合によってはクラウド事業者に一言伝えておきましょう。（BANされる恐れがあります。）・IPS（侵入防止システム）をオフにしておきましょう。 IPSでリクエストが遮断され、アプリケーションの診断ができなくなるのを防ぐため。それでは自動スキャンをかけます。下タブの「自動スキャン」→「新規スキャン」押下。（コンテキストやユーザはスパイダーと同じ設定にします。）自動スキャンを開始しますが、結構時間がかかります。 WebGoatだと２〜３時間ほどかかりました。（ちなみにスキャン結果はセッションファイル化できるので、講習などではセッションファイルを渡しちゃうことも多いです。）２時間後・・・ 71171件のリクエストを投げてくれ、スキャン結果がずらずらと出ています。３．スキャン結果の精査下のアラートタブを見ると、SQLインジェクションなどクリティカルな脆弱性が検知されています。とはいえ、OWASP ZAPは結構誤検知も多いため、本当に脆弱性が存在するのか手動で精査する必要があります。今回はXSSを精査してみます。（IPアドレスが先程までと変わっているのは気にしないでください(^_^;)）対象のページはこんな感じのユーザIDを入力して、関連情報を出力するページのようです。さて、このページで脆弱性を検知した際の攻撃コードを送ってみるのですが、その際にBurp Suiteというプロキシツールを使います。 ▼Burp Suiteインストールサイト https://portswigger.net/burp/communitydownload まずはプロキシの設定です。「Proxy」→「Options」でProxyListenerを設定します。新規ブラウザを立ち上げ、上記で設定したプロキシを通るよう設定します。「設定」→「接続設定」で手動プロキシを設定します。 ▼FireFoxの例プロキシを設定したブラウザで攻撃時のリクエストを投げます。するとBurp Suiteがリクエストをインターセプトしてくれるので、パラメータを攻撃コードに変えてみます。 WebGoat画面で攻撃コードが実行されたことが確認できました。この流れで各アラートに対して精査を行っていきます。（これがかなり時間がかかります。）４．脆弱性対応見つかったXSSに対して対応しましょう。」、「&」等）に置換・URL を出力するときは、「http://」や「https://」で始まる URL のみを許可する。 javascript:から始まるものは除外する・要素の内容を動的に生成しない。・スタイルシートを任意のサイトから取り込めるようにしない。・Cookie 情報の漏えい対策として、発行する Cookie に HttpOnly 属性を加え、 TRACE メソッドを無効化する。などなど対応策を考えるにあたり、よく参考にされるの��、以下の資料です。 OWASPの公式サイト https://www.owasp.org/index.php/Main_Page IPAが発行している「安全なウェブサイトの作り方」 https://www.ipa.go.jp/files/000017316.pdf まとめ標準的なWebアプリケーションのスキャン実施〜対策までをざっくりご説明しました。はじめてOWASP ZAPを使う際、適当にURLを入れてスキャンするだけでもある程度結果が出るので満足しがちなのですが、実はあまりページをカバーできてないというケースが多いようです。そのため、最初のクローリングでしっかりページを網羅させておくことが診断漏れを防ぐためのミソです。また、脆弱性診断は継続することが重要なのでCIに組み込んでおくと良いのですが、その辺の話もいずれブログにしたいところです。ここまで読んで頂き、ありがとうございました！明日は、【PHPとGo言語のURLパーサについて】についてのお話です。お楽しみに。クリスマスまで続くGMOアドマーケティング Advent Calendar 2018 ぜひ今後も投稿をウォッチしてください！ ■エンジニアによるTechblog公開中！ https://techblog.gmo-ap.jp/ ■Wantedlyページ　～ブログや求人を公開中！～ https://www.wantedly.com/projects/199431 ■エンジニア採用ページ　～福利厚生や各種制度のご案内はこちら～ https://www.gmo-ap.jp/engineer/ ■エンジニア学生インターン募集中！　～有償型インターンで開発現場を体験しよう～ https://hrmos.co/pages/gmo-ap/jobs/0000027

#techblog.gmo-ap.jp

0 notes

tak4hir0 · 5 years

Link

背景実求人をクロールし、どの言語がどれだけ求人を保有しているか実数を取得し、年収別の求人数から総合ランキングを作成してみました。個人の恣意的な価値観を反映しないよう、エンジニアとしての個人的な主観は可能な限り省いています。(解説のところで少し主観が入っているのでお気をつけください) 調査方法 Web上にある求人サービスから実求人をクローリングし、言語の頻出数から人気言語のランキングを調査しました。クローリングとは何かクローラーとは、ザックリ言うと、web上でデータを集めてくれるロボットです。webにある色々なサイトを飛び周り、こちらの命令（求めているもの）に該当するページで、データを集めてくれます。集まったデータは、各項目ごとに分別され、それぞれ値が抽出されます。抽出されたものは、何かうまいことやってデータベースに格納するなどします。初心者でも分かる説明水泳��をかぶったロボットがプールの中をクロールで泳ぎまくり、「おとな20人」「こども12人」「おとこ20人」「おんな11人」「せいべつふめい1人」みたいな感じで情報、データを集めてくれる便利で良い奴です。対象データ調査した実求人総数は10万件ぐらい。プログラミング言語はWikipediaの一覧から取得し、求人数が100件に満たないものは除外しました。 ref https://ja.wikipedia.org/wiki/プログラミング言語一覧では早速見てみましょう。年収別ランキング（絶対数順）全体的にJava,PHP,JavaScriptが上位に位置しています。特にJavaの案件がダントツに多いことが分かりますね。この３つの言語は幅広いスキル層に求人を提供しています。専門学校、プログラミングスクールなどを卒業したての駆け出しエンジニアから、バリバリ開発が出来る高レベル層のエンジニアまで幅広い種類の案件がたくさんあります。傾向上位はJava、C、PHP, C#, JavaScriptです。市場規模を考えると業務系はWeb系の8倍弱なのでJava,C,C#が上位に来るのは当然です。PHP,JavaScriptが健闘しています。第2章我が国における IT 関連産業及び IT 人材の動向 https://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_report_2.pdf C言語はJavaに比べ高年収求人が比較的少ない事が分かります。逆にRuby,PythonはC言語と比較するとそれぞれ案件数に比べて高年収求人は比較的多い事分かります。C, C#などは低年収求人が比較的多いようです。組み込み寄りの言語は人あまりが発生しているのかもしれません。高年収求人はTypeScript, Kotlin, Scalaが高年収求人に偏っています。TypeScriptはJavaScriptの、KotlinとScalaはJavaの後方互換言語で、これから言語学習を始める方はJavaかJavaScriptをやっておけば、高年収の道は確保されていると見て良さそうです。年収別ランキング（相対数順）単純な求人数だけの比較をしてしまうとどうしても母数の多い言語が有利になってしまうため「言語別の高年収求人の割合」を出して並び替えました。「人気がありかつ人手不足の求人ほど給料が高年収の求人割合が多い」と考えるなら、こちらのほうが人気度の実態を表していると考えられます。傾向 400万円台までは組み込み系かWeb系、500万円台,600万円台からモダンな言語が増えていきます。700万円台ではProcessingの人気が際立っています。Processingは主に電子アートとビジュアルデザインのための言語です。その他、高年収求人には最近出て来たモダンな言語が割合多く見られます。 2019年総合ランキング決定版絶対評価、相対評価だと結局どの言語が良いのか分からないので、絶対数と相対数から弊社独自の重み付けにより総合ランキングを算出しました。ランキングの仕組みは期待値を出しているだけで単純すぎて恥ずかしいので割愛しますが、要は「高年収求人の割合が多い言語」ほど上位に来る仕組みだと思ってください。(期待値のようなものです。というか期待値です。) 10位：Kotlin Androidアプリ開発で採用する企業が年々と増えており、Android需要に後押しされた格好です。Androidアプリ開発自体はJavaでもできるため、Kotlinでの開発は選択的でiOS開発におけるSwiftほどのインパクトはなかったと見るべきでしょう。 KotlinはJavaよりもスマートに完結に書けることを目指していて、Javaとの互換性もあり、人気が高まっている言語です。最近は「サーバサイドでもkotlinで実装しよう」という動きが目立ち始めています。国内のサーバーサイド Kotlin 公開採用事例まとめ https://qiita.com/ptiringo/items/dd734ab8064f94139294 9位：Scala 国内ではあまり目立っていませんが「高単価求人の多さ」が援護射撃になり上位にランクイン。開発資産としてJavaライブラリが使用可能で(Kotlinも同じ)、生産性を高めるモダンな書き方も可能です。やや古い話ですが、2009年にはTwitterがバックエンドをRubyからScalaに移行しました。 Twitter、Ruby on RailsからScalaへ https://it.srad.jp/story/09/04/10/0421223/ 8位：JavaScript SPAの需要拡大に伴いTypeScriptと共に上位に浮上しました。Adobe AcrobatがJavaScriptのマクロ機能を積んでいるなど、サードパーティ製ツールもJavaScript解析エンジンを積んでいる例が散見されます。また昨今ではJavaScriptの言語的特性(NonBlocking I/Oと相性が良い)からサーバサイドでもJavaScript(NodeJS)を使う動きが見られています。 githubでは注目度断トツの1位。世界的にも現在、もっとも注目を浴びている言語の１つとして過言ではないでしょう。 https://githut.info/ 7位：Python Pythonはシンプルで少ないコードで書けるので、C言語などと比較し扱いやすい人気言語です。近年よく耳にするAI/機械学習/統計解析に必要なライブラリを揃えている事で上位にランクイン。AI需要もありこれからもPython需要は高まっていくかもしれません。既にAI分野のディファクトスタンダードのような扱いで、Jupyter Notebook(https://jupyter.org/ )など使えば比較的簡単に環境が手に入ります。これから学ぼうという方にも良いかもしれません。 6位：Ruby 日本で開発されたプログラミング言語で、初めて国際電気標準会議（IEC）で国際規格に認証されたことでも有名です。『Y combinator』出身の時価総額上位10社のうち6社が採用している言語で、世界のテクノロジーを支えていると言って過言ではないでしょう。Webアプリケーション開発と非常に相性がよく、日本では下火になったと言われて久しいですが、求人ベースだと人気は健在。国内のスタートアップが積極的に採用している言語の１つです。 ref https://news.ycombinator.com/item?id=21138422 5位：TypeScript TypeScriptはマイクロソフトによって開発されたプログラミング言語。JavaScriptに「型」の概念を持ち込みました。ここから『ReactJS』『VueJS』が生まれたと言って過言ではないでしょう。スパゲティになりがちなフロントエンド開発にオブジェクト指向の概念を持ち込み、優れた保守性を持ったSPAアプリケーション開発を実現します。 4位：Apex SalseForceのプログラミング言語です。ApexはJavaに似ており、Java言語ユーザには親しみのある記述方法を提供しています。Salesforceは開発者に高いインセンティブを支払うことで有名であり、中小ベンダーにとって採用の敷居が低い人気言語となっています。実は現在、人材市場ではApex開発者の争奪戦が繰り広げられており、歴3年もあればヘッドハントは当たり前。開発者からすると東京で1000万、大阪でも800万も狙える非常に魅力的なプログラミング言語となっています。 3位：PowerShell PowerShellは2006年に生まれた言語でMicrosoft発のプログラミング言語です。WindowsやMicrosoft製品のシステム管理を行うためのシェル言語を提供しており、オブジェクト指向で開発ができることでも有名です。Bashで書くかPowerShellで書くかで悩んだ開発者も多いでしょう。現在はオープンソース化されています。 Apexと同様、この２つの言語は使用用途が偏っているため求人数が多くないのですが、その分開発経験者が少なく、高単価になったと考えられます。わざわざこれから始めようという言語ではないかもしれませんが、既に業務で経験されていたり触る機会のある方にはGood Newsかもしれませんね。 2位：Swift Swiftは、モダンな記述で開発がしたい開発者とiOSアプリの開発需要のダブルアタックで上昇したプログラミング言語です。Swift自体は初心者にも優しく、駆け出しの方にもオススメですが、ある程度ターミナルの知識を求められるので、知識が全くないと環境構築の段階で沼にハマってしまうかもしれません。そして言うまでもないかもしれませんが、Swiftでの開発には「MacBook」が必要です。 1位：Golang GolangはGoogleによって設計されたプログラミング言語です。動作は軽量でソフトウェアを効率的にシンプルに構築できるとされていてオススメです。Goのツール、コンパイラ、ソースコードは全てオープンソースです。実装はオブジェクト指向にも関数型にも適応しており、優れたメモリ管理アルゴリズムが非常に軽快で高いパフォーマンスを発揮します。ある程度の言語経験者には非常に人気の高いプログラミング言語ではあります。一方で低年収求人には少なく、初心者向きではないので注意が必要です。まとめプログラミング言語別総合ランキングはGolangが一位を獲得しました。今までGolangには興味あるけどなんとなく遠ざけてきた開発者の方は一度Tryしてみる価値はあるかもしれません。しかし入門者が始めるには敷居が高く、これからプログラミング言語を始める人はJava/Ruby/JavaScriptあたりが良いかもしれません。全体的に��ダンな言語や用途が限定的ではあるが需要の高い言語が上位に来ており、既に得意になっている言語の延長で取り組めば効率よく年収アップが狙えるかと思います。プロモーション『リッターズ』のTwitterアカウントでは世界中の「先端Techビジネス」や技術要素の格付け情報を流しています。気になる方は是非フォローしてみてください。リッターズ https://twitter.com/ritters2u 『渋谷コード塾』では求人市場の調査結果から最新の技術トレンドを調査取得し、それらを習得するための半年間のコースを提供しています。直近ではReactNativeによるネイティブアプリ開発とRuby/Python/NodeJS/Golangによるサーバサイド開発を半年でマスターする「アプリxAPI開発コース」を提供しています。「精神と時の部屋」で半年間で3年分の成果を出しましょう。HPはまだ用意していないため、興味ある方は直接私のTwitterアカウントにご連絡ください。 Twitter https://twitter.com/shiraponsu フォローやお仕事のお問い合わせもお待ちしています。ここまで読んでいただきありがとうございました。

#Qiita

0 notes