スプラ2での回線落ちとコントローラの故障でイライラ

私スイッチのスプラ2にハマっております。 土日はウェブの個人開発の傍で休憩のつもりでスイッチに手が伸びてしまいます。
イライラしながらガチマッチをしているんですね。

スプラ2を知らない人のために解説しますがスプラ2には通常モードのナワバリバトル、ランクを競うガチマッチ、そしてチームでのマッチバトルリーグマッチと3種類のバトルがあります。ナワバリバトルというのは皆さんのご想像通りインクを塗った範囲が広いチームが勝利となります。ガチマッチは4種類のゲームルールがありそれぞれでCから始まってXランクまであるランキング方式で勝ち続けてXのランクを目指すバトルです。リーグマッチは私チームに所属しておらず友達いませんので基本できません。
そんなスプラ2ですが、ネットの回線落ちとスイッチのコントローラで十字キーの「↑」と「R2」キーが認識しにくい問題を抱えながらやっておりました。スイッチのコントローラって故障しやすいんですね。
で、最近家を引っ越したのですが、それと同時に家のwifiというかルータも契約を変更しました。それまでauの回線を使っていたのを工事を待つのが面倒だったこともあって引越しを機会にauからBroadWiMAXにwifiを変更しました。
これで工事をせずにネットが使えるようになったのですが、このWiMAXは接続維持が よくないらしくたまにネットに接続できない時が多いのです。
最近でこそパソコン上でやるときのネットワーク環境がよくなりましたがそれまではパソコンでもよく回線が切断され続けました。
その回線の影響がスプラ2プレイ中凄くて1回4分間のバトル中よく落ちたりするのです。任天堂さんは連続接続を前提としているらしくちょっとでもサーバーとの接続が悪いプレイヤーがいるとそのプレイヤーをサーバー落ちにしてしまいます。リアルタイムを前提にしているんでしょうね。
そういうことで私はWiMAXにしてからというものサーバー落ちで何度もスプラ2からログアウトされてしまいます。

4ゲーム連続でサーバー落ちが落ちたこともありまして、
その時は流石にしばらくゲームをしなくなったこともありました。

はい、今回は単なるグチでありました。

ウェブ開発にLaravelいいよ

Laravel + Vue.jsがベストな組み合わせかもしれない

しばらく個人のWeb開発のためにLaravelをいじっています。
私は基本的にスクリプト言語がとても嫌いなのでネットの情報は信用せずに書籍を購入します。スクリプト言語が嫌いな理由はネット上に落ちている試したいコードがことごとく動かないので信用できないからです。動かない素晴らしいコードよりも汚いけど動くコード派です。
なので、スクリプト言語を勉強するときは有料の物を購入してサンプルコードを試します。

私はLaravelよりもRails派なのです。ですが、世の中の商用コードのほとんどがPHPの製品なのでPHPができた方がいいとも思えてきました。なので友人にPHPフレームワークなら何がいい?と質問したところcakePHPではなくてLaravelをオススメされたのである。
そのため、Laravelをリサーチすることになりました。

どうやら、これからのウェブ開発のフロントエンドはVue.jsが良いとのことらしいのでトレンド的にはVue.jsが流行るらしいです。LaravelはVue.jsと相性がいいのでもしかするとRails + Vue よりも Laravel + Vue の組み合わせが流行るかもと予想しています。

LaravelはRailsのパクリ

Laravelをインストールしてちょっと触ってみたところ、Rails派の私は「なんかRailsに似てるぞ」と思えてきたんですよ。cakePHPもできるかもしれませんが、基本的にmodelやcontroller、マイグレーションがコマンドから行うところがRailsぽいです。そもそもcakePHPも全然知らず昔ちょっと触っただけの記憶なので信頼性は皆無です。  

となるとRailsもLaravelもそんなに変わらないならRailsよりもLaravelの方がよくて?
となるのです。
あとは作ってみたいアプリケーションの用途によるかなー。
WebならLaravelを触っておけばCMSECサイトを作りたい案件がきた時にWordpressやECcubeもあんまり抵抗なく書けそうな気がしますので。
それって結構重要でRails使いがいきなりCMSECサイトを作るとなるとやっぱりRailsでは荷が重いわけです。だから、Rubyだけが書けるだけではWebを網羅することができないのですね。自分はSNSサービスをつくりたいんじゃ!という方なら圧倒的にRailsだけで事足ります。

作りたいアプリについて

そんなこんな考えながらだったのですが、今日はなぜか朝の5時くらいに目がパッチリ醒めてしまったのでLaravelでTODOアプリを作ってましたとさ。

TODOのウェブアプリが出来上がったらそれをAPIにしてiOSAndroidアプリも作りたいなと思ってます。
それができたら写真投稿アプリを作ると。

今は作りたいサービスが多すぎて時間が圧倒的に足りないですね。

作りたいアプリは

  • 下書きアプリ (TODOの拡張)
  • 写真投稿アプリ
  • Twitterクライアントアプリ
  • アダルトサイト
  • 投票サイト

これぐらい作ったらWeb開発に抵抗はなくなるんじゃないかな。 下書きアプリが完成したらブログの更新の頻度を上げる予定。

技術書典に行ってきました。

技術書典

昨日10/8はエンジニアのための書籍イベント「技術書典」が開催されていたので試しに行っていきました。ええ、行きましたよ。わざわざ池袋のサンシャインシティまでトコトコ歩いていきました。5回目だからなのか技術書典5でしたが。書店ではなく「書典」なので私の日本語変換ソフトは毎回誤変換をしてくれます。定番の「書店」という誤変換から「書展」「諸点」などと変換してくれます。「書典」と入力するたびに集中力が途切れてしまいます。

技術書典

結論からいうと「技術書典」マジ最高やんけ!
ということでした。本当軽い気持ちで「面倒臭いな」とか思いながらサンシャインシティの奥まで足を運びましたが頑張ってめっちゃ正解でした。軽い気持ちでいきましたので本は2冊ぐらい購入したら帰ろうかなと思っていました。が、結果的には電子書籍を含めると5冊は購入しています。やばい、本だけで1時間の滞在で1万円も使っていますね。まあ、コスパを考えるとそれでも安かったと思えました。

というより、寧ろもっと早い時期から技術書典に足を運ぶべきだったとも思えてきました。良い技術書が多いし購入するときにその著者(?)らしき方々に質問を投げることができるからです。

技術書って一般的にも1冊3000~4000円ぐらいかかりますので、
本を購入するときにはどうしても

  • この本って初心者向けかな
  • 今仕事で必要な「〇〇」の部分をもうちょっと詳しく知りたいんだけどな。
  • ボリューム分厚そうかも
  • タイポや載ってるソースコードってちゃんと動くのかな

といった疑問を持ってしまいます。なので、購入後に購入者のニーズと著者の意図がミスマッチするとそこに悲劇が起きてしまいます。(あと、時間の浪費)

ですが、購入前に著者に販売している本の対象者だとか書いている内容に付いて事前に質問してちゃんと回答してくれるとそういった問題を事前にある程度解消できます。そして、満足して帰宅できるのです。

そんな感じだったので私は技術書典で予算よりも多く使ってしまった罪悪感を持たずに帰宅することができました(笑)。あとで計算してみるとやっぱり罪悪感をひしひしと感じてしまいました。ですが、それは購入した技術書で勉強してちゃんとその分を取り返そうと思っています。

購入した本について

ではどういう本を購入したのかというと

  • iOS、Metalの解説本
  • iOS、ARKitの解説本
  • iOS、UnitTestの解説本
  • iOS、RxSwiftの解説本
  • Laravel、初めてのWeb開発

こういった本を購入しました。
はい、iOSに偏っています。やっぱり、仕事で使うiOSの本が沢山ありました(Androidは大丈夫か?)。もっとAndroidの方も足を運んでおけばよかったと今後悔しています。多分、良書多そう。。。

Laravelの本は個人のWeb開発のために購入しました。本の表紙と売り子さんの外見のギャップはとんでもなく乖離していましたが中身はサンプルアプリの開発フローが書いてあったのでサンプルコードを書きながら勉強できるので即買いでした。(ギャップ萌えですね。)

今月中にタスク管理アプリぐらいは開発したいと思います。
APIが出来上がったらそのままiOSAndroidにも移植できますしね。
Webは今の所もバイル開発よりも難しい概念がないからいかにサンプルアプリを拡張していけるかが上達の鍵になりそう。

電子書籍版の購入について

実はここ技術書典で販売されていた本は「電子書籍」版だとウェブで購入できたりします。

販売しているのは「BOOTH」という同人誌を販売しているウェブサイトらしい。
ここで検索で「技術書典」と検索すると確かに出てきます。なので、紙の本を購入できなかった人はここで電子書籍を購入すれば良かったりします。
BOOTHですますか技術書典まで足を運ぶかはもうその人個人の好き好みで決まりますので好きな方を選ぶ感じで良いかと思います。

あとがき

このブログを書いている最中に気づきましたが、もしかして「技術」「書典」ではなく「技術書」「典」という区切りだったのかもと思えてきました。これだと私の変換ソフトはある程度の確率で正しく変換してくれますね。「書典」だとSEOを考えた場合、なんか損してそうなワードですが技術を語る方々が運営しているのだからSEOには強い方が多いはず。

とかまあ、そんなくだらないことを考えながら今日は仕事をしていました。

Swiftでのプロトコル指向のプログラミングを考えてみる

概要

Swiftのプロトコル指向プログラミングのベストプラクティスがわからなかったので、海外で販売されている本を読みながらXcodeのplaygroundで挙動を見ながら勉強していきました。

これはその備忘録です。

Introducing protocol extensions (protocol extensionの導入について)

アプリ開発でよく見るプロトコル拡張の使い方はUIColorStringといった既存の型に新しいメソッドを追加するやり方ではないでしょうか。

extension String {
    func shout(){
        print(uppercased())
    }
}
"Protocol extension is pretty cool".shout() // PROTOCOL EXTENSION IS PRETTY COOL といった感じに大文字に変換される

こんな感じですね。

それに対して下のコードはプロトコルに新しいインターフェースを定義してそれをextensionで実装していく流れになります。

protocol TeamRecord {
    var wins: Int { get }  // 勝ち数
    var losses: Int { get } // 負け数
    var winningPercentage: Double { get } // 勝率
}

extension TeamRecord {
    var gamesPlayed: Int { // 試合数
        return wins + losses
    }
}

struct BaseballRecord: TeamRecord {
    var wins: Int
    var losses: Int
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses)
    }
}

let bayStars = BaseballRecord(wins: 10, losses: 5)
print(bayStars.gamesPlayed) // 15 回
print(bayStars.winningPercentage) // 0.666666 ~

Default Implementations (デフォルト実装)

// Before extensionで拡張前

struct BasketBallRecord: TeamRecord {
    var wins: Int
    var losses: Int
    let seasonLength = 82  // デフォルト実装が持てる

    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses)
    }
}

extensionで拡張させることで

extension TeamRecord {
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses)
    }
}

// After extensionで拡張後

struct BasketBallRecord: TeamRecord {
    var wins: Int
    var losses: Int
    let seasonLength = 82 // シーズンの長さ
}

let minneapolisFunctors = BasketBallRecord(wins: 60, losses: 22)
print(minneapolisFunctors.winningPercentage) // winningPercentage が使えるようになる // 0.7317

structの中の実装は少なくなるよね、といった話し。 さらにstructインスタンスはprotocol extensionで実装したものが使えるようになっています。

struct HockeyRecord: TeamRecord {
    var wins: Int
    var losses: Int
    var ties: Int // 引き分けのプロパティ、 追加
    
    // Hockey のレコードは引き分けのプロパティを導入したので「勝率」の計算方法が変わる
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses + ties)
    }
}

let chicagoOptionals = BasketBallRecord(wins: 10, losses: 6)
let phoenixStridables = HockeyRecord(wins: 8, losses: 7, ties: 1)

print(chicagoOptionals.winningPercentage) // 10 / (10 + 6) = 0.625
print(phoenixStridables.winningPercentage) // 8 / (8 + 7 + 1) = 0.5

Understanding protocol extension dispatching

protocol WinLoss {
    var wins: Int { get }
    var losses: Int { get }
}

extension WinLoss {
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses)
    }
}

struct CricketRecord: WinLoss {
    var wins: Int
    var losses: Int
    var draws: Int
    
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses + draws)
    }
}

let miamiTuples = CricketRecord(wins: 8, losses: 7, draws: 1)
let winLoss: WinLoss = miamiTuples

print(miamiTuples.winningPercentage) // 0.5
print(winLoss.winningPercentage) // 0.53 drawsがカウントされないため

WinLossには引き分けの draws が存在しないので、winLossはprotocol-extensionの方のメソッドwinningPercentageを出力する

Type constraints

// 概念
protocol PostSeasonEligible {
    var minimumWinsForPlayoffs: Int { get }
}

// PostSeasonEligible と TeamRecord に準拠している時だけ適用される
extension TeamRecord where Self: PostSeasonEligible {
    var isPlayoffEligible: Bool {
        return wins > minimumWinsForPlayoffs
    }
}
// 具体例
protocol Tieable {
    var ties: Int { get }
}

extension TeamRecord where Self : Tieable {
    var winningPercentage: Double {
        return Double(wins) / Double(wins + losses + ties)
    }
}

struct RugbyRecord: TeamRecord, Tieable {
    var wins: Int
    var losses: Int
    var ties: Int
}

//struct HockeyRecord: TeamRecord {
//    var wins: Int
//    var losses: Int
//    var ties: Int
//
//    var winningPercentage: Double {
//        return Double(wins) / Double(wins + losses + ties)
//    }
//}

let rugbyRecord = RugbyRecord(wins: 8, losses: 7, ties: 1)
print(rugbyRecord.winningPercentage) // 0.5

Protocol-oriented benefits (プロトコル指向のメリット)

プロトコル指向のプログラミングをやるメリットとして

  1. Programming to interfaces, not implementations
  2. Traits, mixins and multiple inheritance
  3. Simplicity

のメリットを享受出来る。

Programming to interfaces, not implementations

プロトコルは実装にフォーカスするのではなくインターフェースにフォーカスする protocol にinterfaceを持たせるのでprotocolを見ればどういった機能なのかわかるので最終的にはFatClassが無くなりそうだよね。

Traits, mixins and multiple inheritance

多重継承 の問題を解決する interfaceをprotocolに持たせてextensionで実装を行い、それをstruct やclass に準拠させるのでクラスの共通実装が必要なくなる。そのため、BaseClassといった共通クラスを継承したサブクラスにする必要がないので A is B 問題を解決する糸口になる。

Simplicity

単純かつ、簡潔、簡易なものにする

あとがき

海外のプログラミング本は最初はクオリティとか本当に理解できるのかと疑ってましたが、日本で販売されているプログラミング本よりも大変わかりやすかったです。最初は英語の苦手意識がありました。ですが、それを乗り越えると英語の解説書の方が回りくどい表現がない分理解が早くなることがわかる。

delegateとかprotocolなどの専門用語を日本語に翻訳する方が難しい気もします。

英語と聞くとアレルギーを起こすエンジニアさんも多数いるとは思いますが、
海外の本は日本の受験英語みたいに難しい英文はそこまでないように思います。

だったら最初から英語の本を読みながら英語でプログラミングを理解する方がいい気がします。
ですが、これは個々人の好みの問題ではあるところだと思います。

SublimeTextからVisual Stuidio Codeに乗り換えしました

VSCodeに完全移行

Visual Studio Code

エントリのタイトル通りに今まで仕事でもプライベートでもメモがわりに使うテキストエディタをSublimeTextからVSCodeに完全乗り換えしました。確かSublimeTextは2014年ぐらいからずっと使っていたテキストエディタ。まだ現役で使うこともできるのですが、仕事の人たち、特に若手の方がVSCodeを使っていたのでこれはもう時代なんだなと思いました。私が2014年から SublimeTextを使っていた動機も同じその時の同僚が使っていたテキストエディタがそれだったからです。

VSCodeのいいところ

SublimeTextからVSCodeに乗り換えて一番感激したのがMarkdownに対応しているということ。
記憶に覚えてはいないが今はVSCodeで編集したMarkdownを右側のプレビューで見え方を確認しながらリアルタイムで編集しています。このリアルタイム感が良いです。私は性格的に文字入力をするのが大変億劫らしくてブログを更新するのが大変苦手であったが、VSCodeにしてからは見え方をリアルタイムで確認できるので文字入力のスピードが格段に上がりました。

ブログに記事を更新してから、あーこの行間で改行するのは読みにくかったんだなといつも後悔します。それがリアルタイムで見え方を確認するのでブログに記事を投稿してからの気持ちの差異が少ないので最近ではブログに投稿した後の確認をしていないぐらいです。あと、MarkdownなしだとHTMLのタグ打ちをしなければならないのですが、\

\

とタグ打ちするのが大変に好きでないことを知っているのでできれば文章を書いている最中はタグ打ちを気にしたくないんですよ。なので、私は基本Markdownで文章を編集しています。

使っているMarkdown

ちなみに私が普段使っているMarkdown

# (h1)
## (h2)
### (h3)

[リンク](url) (リンク)

`文字` (文字装飾)

```code```

これらを頻繁に使っています。

それとVSCodeが相性が良いのでとうとうVSCodeに完全移行することにしました。
最初はVSCodeの使い方が全く分からなかったのですが、使っていけば慣れるものですね。
これで文字数カウントみたいなものがあれば完璧ですね。プラグインを導入すればトータル文字数を見れるらしいとのことですがググるのがそんな得意ではないのでまた近い内かな。
あと、タブ機能も付いているから普段XcodeAndroid Studioでコードを編集する感覚に近いのも比較的大きいかもしれない。

もう時代はVSCodeなんだろうな。

注記

文字数カウントぽいプラグイン見つかりました。

(CharacterCount)https://marketplace.visualstudio.com/items?itemName=8amjp.charactercount

このプラグインをインストールして有効にすれば、ウィンドーの一番下のブルーの左側に xx Charactersといった感じで表示されてました。これでブロガーさんにとっては今何文字を入力したのかリアルタイムで意識しながら文章が書けますね。
これでまたライティング効率が上がります。

9月の総決算について書いてみる

9月の総決算

7月からブロックチェーンの勉強を本格的に始めましたのでDapps開発の経験が3ヶ月を越えました。9月末までの目標はとにかくDappsをブラウザで使えるレベルまで持っていけるようにすることでしたがなんとか達成できました。そこに至るまで新しい言語Solidityを覚えたりブラウザ連携をしなければ話にならないのでHTMLだったりCSSだったりと色々な言語を覚えました。6月を基準とするとこの3ヶ月間でのパワーアップ感は半端ないと思いました。

よく仕事しながら続けられたと自分でも感心してしまいます。
その分、プライベートの時間が少なくなりましたので10月はちょっとゆっくり過ごしたいですが、この月は自分で経営してる会社の決算日なので決算手続きに追われます。8~9月がオフィス移転・引っ越しだっただけに怒涛の4ヵ月となりそうです。

本業の方はAndroid開発が一旦落ち着きましたのでiOS開発に戻ろうか的な雰囲気があります。今回のAndroid開発でJava言語を覚えられたのは人生の中でも凄く大きいかな。

3ヵ月間で達成したこと

この3ヵ月間で自分でも達成、あるいは成長したことを上げるとするなら

  • Solidityの基礎がわかった
  • ブロックチェーンの将来の可能性が見えてきた
  • Web開発言語であるHTML, CSS, PHPの復讐ができた
  • PHPのLaravelを触れるようになった
  • Qiitaの投稿を増やした。コントリビュートが100を越えた

と中々の成長ぶりです。

9月に重い腰を上げながらPHPを触り始めましたがこの行動が正解でした。
Web開発に関してはRailsとかJavaもいいですが、結局PHPで緩く書くのがビギナーにとって近道であることが分かりました。Rubyもいいのですが、Rubyをデプロイできる安いレンタルサーバーが少なすぎて選択肢から外してしまいました。Railsはいい言語なんですけど、手っ取り早く・安く・あるいは海外で!、と言うことを考えるとRailsを使うことが出来なくなりました。

次の4半期での目標について

そのため、PHPクローラー開発などで触りながら覚えて行ってます。こいつは割と適当な書き方でも動いてくれるんで非常に便利です。(Pythonでもいいんだけど安いレンタルサーバーが少ない・・・)
ひとまずいろんなページをスクレイピングして情報を集めるところからスタート。
この10月~12月で商用レベルのTwitterクライアントを開発してリリースまで持っていくのが直近3ヵ月の目標です。友達がTwitterで集客したいとの事だったので使いやすいTwitter関連サービスを開発中です。
その開発にLaravelを使用しています。Laravel楽しいわ。

ニートが一発奮起して年収500万円のプログラマになる方法を語る

概要

20代の職歴なしフリーターくんが今の日本で一発逆転して職歴を作ることができるかどうかを検討したい。

アラサー未経験からのIT転職

この記事に感化されて考えてみることにした。

フリーターTくんのスペックについて

まず、できるかどうかは別としてターゲットとなる人物像はこんな方です。

  • 20代かアラサーまで
  • 大卒・高速どちらでも構わないが最低限の地頭を担保したいので大卒にしておく
  • 就活に失敗したか景気の影響を受けて正社員になることができなかった
  • 所持金は15万円はあるし、奨学金以外の借金はしていない
  • やる気と根性は人並み以上にはある方

これぐらいの条件で勘弁して下さい。 これぐらいであればまだ救いようがあります。

ではこのフリーターTくんは何をすればいいか。

楽天カードを作る

まず始めにクレジットカードが必要なので楽天カードを申し込んで下さい。
時代によりますが、景気のいい今のタイミングでしたらだいたいの人が審査に通ると思います。
申込み時点で「ショッピング枠」の希望項目があれば、自分の信用なら通りそうな金額で「できるだけ高めの金額」を選びましょう。
大卒なら20万円ぐらいいけそうですが、最低10万円以上が最低限ですね。
カードを申し込んだら1週間後ぐらいにカードが届くと思いますので、カード到着までの待ち時間に次の項目をやっておきましょう。

MacBookを購入しよう

クレジットカードを申し込んでからカードが届くまでに、手元の資金15万円をパソコンに投資しましょう。 Appleで新品で買えば10万円くらいで手に入ります。

MacBook Air

ただ、プログラミングスキルが全くないTくんには新品のMacBookなんて最低スペックでも勿体無いので、 倹約したいのであれば、ヤフーオークションで中古のMacBookAirを購入してきて下さい。

型落ちの古いモデルであれば頑張れば6万円、相場であれば7~8万円で入手できるはずです。
ここは最低限頑張って下さい。
カードを待っている間時間があると思うので時間をケチる必要はありません。

これで必要な道具が揃います。

アプリ開発スクールに3ヶ月間くらい通う

大抵の人はプログラミング未経験者にいきなりドットインストールをオススメしています。確かにドットインストールは優秀で大変便利です。ですが、大変便利と感じるのは「プログラミング経験者にとって」です。フリーターやプログラミング未経験者がドットインストールでプログラミングを勉強するのは、英語が話せない人がスカイプ英会話で英会話をマスターするぐらい難易度が高いです。確かに冒頭で最低限の地頭が必要とは述べました。が、ドットインストールでプログラミングをある程度できるようになるぐらいの地頭の持ち主であれば、就活でこけたりするようなことはないと思います。
喩えがアレでしたが、簡単に言えばプログラミング未経験者がドットインストールで一からプログラミング脳を手に入れるのは絶望的だということが伝わればいいのです。
逆になんで、プログラミングがある程度できる人ほど初心者にドットインストールをオススメする記事が多いのだろうか。

話しを戻しますが、最初にプログラミングを勉強するときはアプリ開発のスクールに通うのが一番早いです。
なので、前段階で手に入れた楽天カード(クレジットカードであればなんでも可)でショッピング枠も利用して値段が15万円以内のコースを申し込んでひたすら学びましょう。
一番最初のとっかかりは人に学んだ方が断然早いです。

ウェブサイトなら、TechCampでもTechAcademyアプリ開発ならレインボーアップスと色々なスクールがあるので講師に教われるタイプのスクールに通いましょう。

こういったスクールで学ぶべき点は2点です。

  1. 環境構築のやり方
  2. アプリの「リリース」までの流れ

一番重要なのは2番目です。
できれば、講師の人に教わって兎にも角にも作ったアプリを「リリース」するまで持っていきましょう。
逆にリリースできなければ半分リタイヤと思いましょう。
本当は自分の作りたいアプリを時間かけてじっくりと作りたいと思うでしょうが、
オブジェクト指向もデザインも仕様・設計もわからない貴方は自分の作りたいアプリをリリースまで持っていけません。
(ちなみにこれはプログラマも同じです。)

なので、スクールで教わるソースコードをコピペしまくっても構いませんし、デザインはフリー素材を使ってどっかからDLしてきても構いませんのでとにかく1個開発したアプリを「リリース」しましょう。

で、まあ、ここからが本題です。  

IT系のアプリ開発会社をメインに就活する

うまいことスクールを利用すれば最低限の地頭とガッツのある人なら1個くらいリリースできたアプリがあるはずです。
iOSアプリだとAppleの審査が厳しいので想定よりももっと頑張らないとリリースできないかもしれませんが、まあそこはアプリ開発スクールの講師も協力してくれるはずですのでなんとか頑張りましょう。

そのリリースしたアプリを元にアプリ開発会社を中心に求人に応募して面談にいきましょう。
書類審査があるところなら、履歴書にリリースしているアプリのURLを貼って送ればOKです。

前回のステップで開発してリリースしたアプリは就活中貴方の「人格」になるのです。
人事の方はあなたがリリースしたアプリを精査してあなたが最低限のプログラミングスキルを持っているかを判断します。
そのプログラミングスキルがその会社の要望のプログラミングスキルよりも下回って入れば落とされます。

ただそれだけです。

面談に呼ばれればあなたの勝率が50%になります。

面談中は思いっきりハッタリをかましましょう

多分、20社ぐらいに応募すればそのうちの2~3社には面談に呼ばれると思います。   この面談でみられる部分は会社によって違いますのが、あらかた想定が付くことを挙げておきます。

  1. あなたが会社で働ける人格を持っているかどうか(サラリーマン気質)
  2. あなたが会社で必要とする最低限のプログラミングスキルがあるかどうか(共同開発能力)
  3. あなたが会社の雰囲気・メンバーに馴染めるかどうか(コミュニケーション能力)

1番に関してはフリーターを卒業したい(サラリーマンになりたい)という動機があると思うから、「毎日、休まず会社に出社してみせます!」などと熱意を見せれば人事の方は評価してくれます。つまり、ハッタリが効く部分です。
2番はおそらくちゃんとした会社であれば面接の人事と一緒に現場のエンジニアの方が同伴されると思います。そのエンジニアの方をいかにして口説くが問題になります。エンジニアの方は会話からあなたのプログラミングスキルを判断してきます。ここでは、なるべく嘘は言わないようにすることです。嘘をつけば付くほどエンジニアから信頼を失います。会社によっては簡単なプログラミングの課題を出してきてリアルタイムで問題を解かせるといった事もしてきます。
なので、頑張り方はなるべく嘘をつかず変なことを言わないこと、そして問題を言われたら全力でその問題を解決しにいきましょう。
私にとっては問題を出してくれる会社の方が嬉しいです。   この問題のレベルでその会社に必要なレベルが分かることと、「そんな問題があるんだ!」と経験値が貯まるからです。 まあ、そんなもんですね。別に解けなくても死にはしませんので次の場面で役に立ちます。   3番はむしろガチのプログラマにこそ多いですがガチのプログラマほど苦手意識はあったりします(笑)。ただ、そんなことを言いたいのではなく、会社で働くのだから最低限のコミュニケーション能力が必要になります。  

ここでのコミュニケーション能力は

  • メンバーと仲良く開発できる会話術・一般常識
  • 開発する上でのメンバー間の連携のためのコミュ力

です。

3番目はある程度の運ゲーですので場数をこなすしか対策はありません。

しかし、ある程度のコミュ力があればすでにリリースしているアプリがあなたの「人格」を構成してくれます。それぐらいリリースしているアプリというのは強力なのです。
まっ、そもそも個人でリリースしている社員なんて少ないですしね(笑)。

ここで面談に通れば年収300万円のプログラマに出世します。

年収300道から年収500万円への道

割とアプリ開発の現場では見えてます。
一度就職したアプリ開発会社で勤続年数を2~3年頑張りましょう。
最初の会社で無理であれば最低3ヶ月でも大丈夫ですのですぐに別の会社に移動しましょう。
3ヶ月もその会社にいればいろんなタスクを経験すると思います。
大体は一人ではタスクをこなせませんので先輩エンジニアに頭を下げながらテクニックを覚えていきましょう。

おそらく、未経験の人は最初のタスクで半泣き状態のはずです。
最初の1年間のライフスタイルは

会社でタスクを振られるのでそれを実装するためにリサーチ・リサーチ・リサーチ・etc   家に帰宅して家で技術書片手に徹夜で勉強

の繰り返しになると思います。
最初は辛いと思いますが、そのうちいろんな意味で慣れてきます。

ここで学ぶ内容としては個人差はあると思いますが、

初級プログラミングスキル

  • メソッドの処理のロジック
  • アプリ開発上、必要なKitのプロパティ・メソッド
  • 引数・戻り値の意味
  • シングルトンをはじめとするデザインパターン
  • 変数・定数の使い方
  • for文、if文、return の使い方
  • if文の中で変数が使えること
  • ライブラリのいれ方・使い方
  • デバッグの方法

中級プログラミングスキル

  • 非同期処理・マルチスレッド対応
  • ライブラリ管理ツールの使い方・バージョン管理
  • DBの使い方
  • ググるスキル、未知の問題解決能力

開発フロー

  • gitコマンドや共同開発の進め方
  • タスクのこなし方
  • git-flow, github-flowなどのやり方
  • ブランチの切り方・マージの仕方
  • フロントエンドではデザインの当てはめ方、バックエンドではテストの書き方
  • API通信のやり方
  • タスク管理ツールも含めたツールの使い方

他にもタスクをこなしていけば色々なことを学ぶと思いますが、めげずに頑張ってください。
できれば、ここでかなりできる先輩エンジニアに頼み込んであなたのメンターになってもらうように依頼するのもいいかもしれません。会社の中では会社の利益になることであれば多少の融通は聞いてくれますので会社のリソースを存分に利用してください。将来独立するにしろ、またフリータに戻るにしろ貴方は一度、ガチのアプリ開発を経験しているのでその経験は将来に渡って有効に使えます。

2,3年も開発の経験をすればそれを元にして勉強会で人脈を作ってもいいですし、経験を生かしてメガベンチャーに転職することも可能になってきます。

そして過去を振り返ってください。

貴方が何年か前まで正社員経験がなくフリーターで手元には10万円ぽっちしか資金がなかったのに、今ではいっぱしのサラリーマン並みに稼ぐことができたのです。フリーター時代はこんなクソみたいな時代生きるのがバカみたいだ、なんて言っていたのにパソコン1台で立派に社会人になれているのです。

あなたの人生まだ終わっていませんよ。