ここ数年プログラミングを学びたい人が増えている。そうした需要に応じて有象無象のプログラミングスクールや不適当な内容の学習サイトも増えている。中には粗悪なスクールやオンラインサロンも沢山ある。しかし未経験者にはどれがいいスクールなのか悪いスクールなのか等の審美眼はない。 この記事では未経験者がそういった情報弱者を食い物にする偽物に騙されないように滑らかに学習を進めていくための道筋について書く。 この記事の対象読者は下記。 教養としてプログラミングを学びたい未経験者 とにかくWebサービスやアプリを作りたくてプログラミングを学びたい未経験者 プログラマとして職を得たい未経験者 以下、まずは全ての対象読者向けの下準備について書き、その後それぞれの対象読者向けに道筋を書く。 目次 準備 教養としてプログラミングを学びたい人の場合 とにかくwebサービスやアプリを作りたくてプログラミングを学びたい人

2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

windowsアプリ作りたい → C#,VB.NETmacアプリつくりたい → Objectiv-CWebアプリ作りたい → PHP ＆ JavascriptiOSアプリを作りたい → Objectiv-C, swiftAndroidアプリを作りたい → Java(スマホアプリは両方のソースを共通化したいとかゲームを作りたいという需要でJavaScriptやC#,C++という選択肢も用意されている)unix系のOSでツールをつくりたい → C, Ruby, Pythonunix系のOSでミドルウエア的なものを作りたい → C, C++バリバリ動くゲームを作りたい → C++言語を作りたい → COSを作りたい → Cやりたいことが無いがなんとなくプログラムをやりたい → なにかやりたいことを見つける就職したい → PHP, Java, C#

最強ゲーム開発環境として誉れ高い、Unity3Dを使って2Dゲームを作ってみました。 第二回目も執筆しました。 Unity3Dで2D物理シミュレーションゲームを作る：プログラム編 – Mokosoft開発者ブログ Flashで動くデモも公開してみました。 ブログに貼り付けれないのでこちらから ※音が出ます こういうのが簡単に出力できてしまうのもUnityの魅力の一つです。 毎度ながらAppleの審査に時間がかかるので、記事にするのは作ってから１か月後とかになってしまいます。 Unity – Game Engine Webサイトを見ると、ライセンスは１５万もするのか、と思ってしまうのですが、無料でも十分使えます。 今回のゲームも、ライセンスは買っておらず無料（一部有料のasset）で作成しました。 Unityというのは統合開発環境ソフトとなっており、3D空間のエディット機能やアニメーションの

グーグルがChrome DevToolsの学習ビデオを公開。DOM操作からプロファイリング、メモリリークの発見まで詳しく学べる 学習内容は全部で以下の7つのレベルに分かれており、17本のビデオと、レベルごとに用意された、実際に自分で操作して解いてみる75以上の例題から構成されています。レベルをクリアするとバッジがもらえるようになっています。 Level 1: Getting Started & Basic DOM and Styles Level 2: Advanced DOM and Styles Level 3: Working With the Console Level 4: Debugging JavaScript Level 5: Improving Network Performance Level 6: Improving Performance Level 7: Memo

心底、プログラマとして生きていくのが幸せなんだなと思える人に出会ったことのある@HIROCASTERでございませう。 プログラミングが上達するベストプラクティスってあるんでしょうか？ 大学でコンピュータ教えている教授なんかは、そのあたり教えてくれるんでしょうか？ あなたの先輩は教えてくれましたか？ 昔ながらの職人がいう、見て、まねて、盗め。ですかね？ 僕の経験で、いくつか書いてみました。 毎日コードを書くとにかく毎日コードを書いている。 息を吸うように、歯磨きををするように、顔を洗うように、食事を取るように毎日コードを書いている。 テストコードも書く動くソフトウェア側のコードだけでなく、テストコードも書いている。 必然と設計も考える癖が付くわけで…。 ソフトウェア全体を仕上げるまで書く例えば、小さなメソッドだけでなく、クラス全体を。 ソフトウェアとして動作するまで全体を。 全体を仕上げるま

さまざまなGoogleのサービスを使いこなすコツをグーグルの担当者に聞くインタビュー特集。第1回は、日本Androidの会のメンバー（嶋 是一氏と中村 秀樹氏と安生 真氏（株式会社ケイブ））3人が、Androidアプリケーション開発のコツを聞くため、グーグル日本法人のオフィスを訪ね、ゲームアプリケーションを通して効率よく描画するためのノウハウについて聞いた。 その結果、T-Mobile G1（以下、G1）を用いた場合、2D描画であってもOpenGL ES（※1）を用いたAPIを利用するのが良いことが判明した。これは、驚くべき事実だ。このことは、機種に特化したチューニングを行うことで、よりデバイスの性能をフル活用したアプリケーション開発ができる可能性を示したといえる。 「Eat your own dog food」というGoogler文化 Androidについて話したのは、グーグル デベロッ

Let'sプログラミングでは初心者の方を対象にJavaやPython、PHP、Rubyなど色々なプログラミング言語の解説を行っています。 Java Java入門 これからJavaを使ったプログラミングの習得を目指している方を対象としたチュートリアルです サーブレット(Servlet) / JSP入門 サーバサイドで動作するアプリケーションの作成方法 Androidプログラミング入門 モバイル向けプラットフォーム Android で動くアプリの作成 Swingを使ってみよう GUIを使ったJavaアプリケーションの作成で使用するSwing入門です Eclipse入門 開発環境として広く使われているEclipseのインストールと活用法 Javadocの記述 ソースコードからHTML形式の仕様書を生成します Apache POIでExcelを操作 Excelファイルの作成・操作

enumは型安全な列挙定数が作れるこれですね。 public enum Sample { HOGE, FOO, BAR, } enum basics - しげるメモによるとenumってクラス本体にメソッド定義できるんですね。 public enum Sample { HOGE, FOO, BAR, ; // セミコロンで区切る public boolean isHoge() { return this == HOGE; } } この仕組みを使って「ステートパターンをenumで」 public class Lifecycle { // 初期状態はINITIALに固定 private State state = State.INITIAL; // 外側に公開する状態遷移メソッド public void start() { state = state.start(this); } public

私、餡子のためなら逆立ちだってしますよ。 こじらせている。 食べたいと思ったら食べたいのである。 ここが北カリフォルニアの片田舎であろうと、私があんみつが食べたいと思えば、あんみつは今すぐ作って食べなくてはいけないものになる。食いしん坊の思考は凄まじい。 子供が観ていたアニメで、赤ちゃんが空の…

サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな？とあれもこれもと手を出すうちに2，3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか？QAやテストやドキュメントなどはいりませんか？誰に承認をえるのですか？これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ

ソースコードの変数名、メソッド名、設計ドキュメントのサブシステム名として「こだわってつけてるなぁ」という名前は、時間をかけて作成することができた部分であり、その周辺もきちんと作りこまれている。逆に名前が安易につけられていると時間をかけられなかったことを示していて、品質に問題があるかもしれない、という仮説を考えた。 ソースコードの変数名へのこだわりというのはよく聞くが、設計時に「・・・部」というようなサブシステム名にどれくらい時間をかけてらっしゃるだろうか？名前にこだわる理由は自己満足という側面もあるだろうが、メンテナンス性に響く。また、他の開発者への誤解の可能性を少なくするだろう。 「処理部」というような名前は確かに中身を表しているが、理解容易性という点では少し疑問が残る。「処理」がシステム固有の言葉として使われていれば別だが、どのような機能であれ、何らかの処理をするからだ。ソースコードの