日々、徒然プログラミング。

都内のIT系専門学校に通う、一人暮らし女子学生chocoffeeの、 日々の気づきと学び、たまにほっこりを綴るブログ。

エンジニアのみなさま、エンジニアの卵のみなさま、IT業界のみなさまが
わたしの「チームってなんだ?」というぼやきに反応してくださることを祈って。

2016年03月

こんにちは!

通う学校の体験入学補助スタッフを終えて、
近所のカフェで相変わらずのドヤリング。

プログラミングがひと段落したので、
気晴らしも兼ねて更新。


みんな大好きTableView!


さて。Obj-Cのものが着々とSwiftに移行されていますね。
わたしはObj-Cは書けません。初っ端からSwiftを学んでいます。
まだ珍しい部類・・・なのかな?

まだまだド初心者だった頃にSwift2.0が来て、
あっぷあっぷしながらも何とか乗り越えた思い出。
コツというか、流れを一度理解すると書きやすい気がします、Swiftは。


初心者は必ずと言っていいほどはまる」UITableViewController。

わたしも見事にすっぽりしました。

今回も覚書がてら、
格闘の軌跡をまとめておきます。




【注意】
・livedoorでのソースコードの記載がめんどくさかったわからなかったので
 全てスクリーンショットでお届けします。見にくいと思う。お許しをば。
・わたしのクラスメートたちにわかりやすいようにまとめるので
 ちょっと偏りがあるかもしれないです。
・右往左往してますが微笑ましく見てください。


【16/04/11追記】
スクショを全て文字に差し替えました!


テストコード


今回は

UIViewController上のボタン
→UITableVIewController上のセル
→UIVIewController(詳細画面的な?)


という流れで作ってみます。

データは全てローカル。
動けばよかろう精神。
(サーバーまだわかんないだけです)


行くぞオラ


①View先に全部置いちゃう

NavigationControllerについて(個人解釈)
 storyBoardではVIewのように表示されますが、実機ではみることができません。
 いろんなViewたちの管理をするお偉いさん的ポジション。
 NavigationController下にいるViewには、画面上部に戻るボタンが自動で入ります。便利。


storyBoard上のUIViewControllerを選択した状態で、
ツールバーの「Editor」→「Embed in」→「Navigation Controller」を選択。

chooseNavigationController


すると、左側にグレーのNavigationControllerが追加され、
画面上部に戻るボタン用の枠が用意されます。

これでこのVIewはNavigationControllerの支配下に入りました。たぶん。

便利なのは、このViewからSegueで画面遷移を指示すると、
自動で新しいViewもNavigationControllerの支配下に入ること。

基本的にEmbed inでNavigationControllerをぶっこんだ方が楽っぽい。




次のViewのUITableViewControllerを配置。
この状態ではまだsegueを繋いでいないので、TableView上部にはスペースがありません。
putTableView
最初のViewに適当にボタンを置いて、TableViewControllerにsegueをつなぎます。
control + ドラッグで、ぐわーーーーっと。
ここでは「Show」を選択。

chooseShowSegue

無事segueが繋がると、TableViewControllerの上部にも
戻るボタン用のスペースが確保されます。


toTableViewSegue



新しくUIViewControllerを設置。
TableViewのCellがタップされた際に詳細画面(UIVIewController)に飛ぶようにするので
TableViewCellと新しく置いたViewをsegueでばーーんします。

詳細画面のほうのView(DetailViewと呼びます)の真ん中に適当にlabelを設置。
文字は変更なし。あえてしません!


②各Viewが参照するクラスのファイルを新規作成

左側のフォルダがぶわーってなってるところ(名前ど忘れ)の、
ViewController.swiftなどがあるすぐ上のフォルダを右クリックし、
New File...」を選択。


chooseNewFile


iOS > Source から、「Cocoa Touch Class」を選択。


chooseCocoaTouch


なんでSwift Fileじゃないの?
 Swift Fileでももちろん作れます。
 ですが、CocoaTouchはViewの型を指定してあげるだけで必須のメソッドをあらかじめ用意してくれます。CocoaTouchの方がミスも少ないし、何より楽ちん!


まずはTableViewControllerが参照するクラスを作るので、
型を「UITableViewController」を選択。

型を選択すると、class: の部分にも型名が自動で入ります。
補足する場合はclass:の部分を変更します。
今回はTableViewは一つだけなので、そのまま。

makeFileTableView


DetailViewが参照するclassも、同様に作成。

makeFileDetail

ViewControllerは2つあるので、

先頭に「Detail」を追加して判別しています。





③storyBoardのパーツとクラスのファイルを紐付け

これで各Viewが参照するクラスファイルは作成されたので、
ソースコードとstoryBoardの紐付けをします。

storyBoardに戻り、VIewControllerを選択した状態で、
画像の部分を参照先のクラスに設定。(カスタムクラス)

このViewはデフォルトで存在しているViewController.swiftをそのまま利用します。


customClassView


同様に、TableController、DetailVIewも設定。



customClassTableView

detailCustomClass

これで各Viewと各classが紐付けられました。





④紐付けたソースコードをいじくる

ViewController.swiftは変更点がないので割愛します。

まずはTableViewController.swift。


//  TableViewController.swift

import UIKit


class TableViewController: UITableViewController {

    

    override func viewDidLoad() {

        super.viewDidLoad()

       

        // Uncomment the following line to preserve selection between presentations

        // self.clearsSelectionOnViewWillAppear = false


        // Uncomment the following line to display an Edit button in the navigation bar for this view controller.

        // self.navigationItem.rightBarButtonItem = self.editButtonItem()

    }

    

    override func didReceiveMemoryWarning() {

        super.didReceiveMemoryWarning()

        // Dispose of any resources that can be recreated.

    }



デフォルトではこうなっているはず。

・viewDidLoad()
 →Androidでいう「onCreate()」みたいなもんです。
  立ち上がったときに一番最初に通過するメソッド。
・didReceiveMemoryWarning()
 →メモリーがアレしたときにアレするアレ



続いて、テーブルの行数・列数を設定するメソッドがあります。

//  TableViewController.swift

    override func numberOfSectionsInTableView(tableView: UITableView) -> Int {

        // #warning Incomplete implementation, return the number of sections

        return 1    //  デフォルトは0

    }


    override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

        // #warning Incomplete implementation, return the number of rows

        return cellData.count

    }



・numberOfSectionsInTabView(なんたら)
 →テーブルの列数。縦分割のアレ。基本的に1です。デフォルトは0
・tableView(なんたら、numberOfRowsInSection section: Int)
 →テーブルの行数。数値で固定してもいいし、変数にして間接的に指定してもいい。デフォルトは0


行数はデータ数に合わせてほしいので、
練習も兼ねて、

テーブルに入れるデータはソースコード内の配列から
引っ張ってくるようにしました。


//  TableViewController.swift

import UIKit


class TableViewController: UITableViewController {

    var cellData: [String] = [String]()     //  セルに入れるデータ格納用配列

    

    

    //  Androidでいう「onCreate」的な。

    //  AndroidintentgetIntent()にあたるものもviewDidLoad()に書く。

    override func viewDidLoad() {

        super.viewDidLoad()

        

        cellData.append("あいうえお")

        cellData.append("かきくけこ")

        cellData.append("さしすせそ")

   


空のString配列cellDataを作成し、
viewDidLoad()で要素を追加しています。

つまり、TableViewが立ち上がったときに
cellDataには3つの要素が含まれていることになります。



では実際に、cellに要素をぶん投げましょう。
ぶん投げ先のcellのIdentifier(Androidでいうid)が必要なので、設定します。


storyBoard上でcellを選択した状態で、

cellIdentifier

今回は「tableCell」というIdentifierを設定。


TableViewController.swiftに戻り、

tableView(tableView: UITableView, なんたら)

のコメントアウトを外します。

//  TableViewController.swift

    override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {

        let cell = tableView.dequeueReusableCellWithIdentifier("tableCell", forIndexPath: indexPath)


        cell.textLabel?.text = cellData[indexPath.row] ?? "nil"


        return cell

    }




"tableCell"の部分を先ほど設定したIdentifierに書き換えます。
ここがあっていないとcellにデータがぶん投げられないので注意。
ハマりやすいポイント(個人的感想)


let cellには"tableCell"というIdentifierを持つセルへのインスタンスが格納され
cell.textLabel?.text に配列cellDataの行数番目のindexをぶっ込む・・・
語彙のなさに絶望。伝わってください。


これでセルへのデータぶん投げは完了。



TableViewController.swiftでもうひとつチャレンジ。
一番下の方にある「propareForSegue」というメソッドの
コメントアウトを外し、


//  TableViewController.swift

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

        let nextView = segue.destinationViewController as! DetailViewController

        nextView.segueText = "Swift"

    }



このように書き換えます。

destinationViewController は、直訳すると「つながったViewController」。
つまり遷移先です。
遷移先のViewが参照しているクラスにキャストして、
ソースコード同士をつなげるイメージ。


nextViewには、次のVIewが参照するクラスへのパスが格納されてる(きっと)
nextView.segueText = "Swift" は、
遷移先のViewが参照しているクラスの変数segueTextに"Swift”を代入してね
ということになります。


つまり!
DetailViewController.swiftに変数segueTextを用意する必要が有ります。
クラスを超えてデータを渡す場合は、一度変数で受け取ってから
各パーツにセットしないといけない。らしい。


connectLabel


まずはstoryBoardに戻り、DetailViewのLabelを
DatailViewController.swiftに紐付けます。
今回はそのまま「label」という名前にしました。


その後、DatailViewController.swiftに変数segueTextを作成。

//  DetailViewController.swift

import UIKit


class DetailViewController: UIViewController {

    

    @IBOutlet weak var label: UILabel!

    var segueText: String = ""  //  初期化しないとエラーになる




TableViewからのsegueにより、変数segueTextは空文字列から
"Swift"に変わります。


あとは、viewDidLoadでlabelにsegueTextを代入してあげれば・・・

//  DetailViewController.swift

import UIKit


class DetailViewController: UIViewController {

    

    @IBOutlet weak var label: UILabel!

    var segueText: String = ""  //  初期化しないとエラーになる


    override func viewDidLoad() {

        super.viewDidLoad()

        label.text = segueText


        // Do any additional setup after loading the view.

    }




完成!!!



33


39


43

簡単にではありますが
以上が私なりの解説。

解説って本当にいい勉強方法ですよね。
自分がわかっていないところが浮き彫りになって。

この記事の執筆に2時間半かかっています。
あああ、頑張った・・・


そのうち見やすいように書き換えるかもしれないです。
眠たい・・・




ちょこひ

















 

こんばんは(´∀`)

あったかいのか寒いのかよくわからん天気で
昨日に引きつづき半ばキレてるちょこひです。

あったかいと思ったら風超寒いし
夜になったらそれはそれでめっちゃ寒いし。

なんなの!もう!
ストッキング破けるし!!(´;ω;`)



☆今日は恵比寿に行ったよ

昨日は水道橋のteamLab様
今日は恵比寿の 某企業様にお邪魔しておりました。
(ちなみに明日は大宮でMT、明後日は六本木、明々後日は渋谷・・・)

オフィス見学だったけど、
社長さん直々に対応していただきました。 

社長さんの最初のお言葉。

「選考全く関係ないんで、一人間として、なんでも聞いちゃってください」

お言葉に甘えて、マーケットについての見解をお聞きしてきました。



☆まずはわたしの考え

モバイル専門で学んでいる身としては、
スマホアプリのマーケット(AppStore、GooglePlay)に目が行きがちで、
ソフトウェア業界全体で見るというのが難しい。

理由は、まだまだソフトウェア全体の知識が足りないから

以前の記事の通り、

アプリのみのサービスで利益を上げるのは難しい
利益のためにはニーズのあるWebサービスが必要

そのためにはモバイルエンジニアもある程度Webの知識が必要

というのが今のわたしの見解。


ここでいうWebの知識というのは
Webサイトを作るコーディング系の知識というよりは

市場のニーズの見極め方であったり、
アイデアの膨らませ方であったり。


経験でしか身につかないような気も、する。


引き続きプログラミング技術を学んでいくだけでいいのか、
どうにかしてWebにも食い込むべきか。

という質問をさせていただきました。




☆社長さんの見解


「アプリだけのサービスで稼ぐ企業が本当にトップレベル」

「ゲームは別にして、アプリのみのサービスで長期間稼ぐのは本当に難しい。だけど、無理じゃない。
 
「生き残っていく企業は、Web、アプリ共にレベルの高い企業」

とのこと。


学生の身で考えていたことだけど
間違ってはいなかったようで。


「モバイルエンジニアはモバイルだけじゃまずいですかね?」

という質問には

「会社による。完全にWeb、アプリ分けている会社なら問題はない」
「でもうちはマルチなプログラマを推奨している、その方がスキルアップにも繋がる」

とお答えいただきました。



すごく納得した。

マルチの方がいいとか、一つを極めた方がいいとか、
その正解はないと思う。

会社によってどちらかが推奨される場合もあるし、
どちらも存在するかもしれない。


今日のお話を聞いて、

プログラミングの勉強は優先順位を一番高くする
チームで動く時にWeb関係も要所要所で学んでいく
余裕がでてきたらWebにも手を出してみる


という方針になりました。



正直、焦ってた。

モバイルプログラミングができても、
発揮できる場所がわからなくて。


でも焦る前にモバイルプログラミングを
業務レベルまであげないといけない。


勉強の日々だあ!!!



勉強は嫌いじゃない。むしろ好きな方だと思う。


あと1年、頑張ります(´∀`)





ちょこひ 

こんばんは(´∀`)

強風と豪雨と寒さで半ばキレてるちょこひです。


あったかくなるなら早くあったかくなってほしい!
フェイントやめて!腰いたいから!!! (ヘルニア持ち)



☆水道橋にいってきた!

水道橋にあるteamLabさんにお邪魔して、
会社説明中心の座談会に参加してきました!

人事担当のいのき様に許可頂いたので、
オフィス内の写真とともにレポします。



参加者は私含めて4人。みんな大学生。
情報関係の学部はわたしともう一人だけでした。少しびっくり。


オフィス内は仕切りがなく、すごく見通しがよくて、
なんだかいい匂いがしました。

無印良品でよく感じる匂い。たぶんあってると思う(笑)



座席に案内されて、ステッカーを頂きました(´∀`)

写真 2016-03-14 22 43 09


かわいい!


ステッカーの雰囲気が、teamLabさんの会社の雰囲気、オフィスの雰囲気に
すごくあっているなあ〜と今思います。



いのき様にはteamLabさんについて
詳しく丁寧にご説明いただき、

時間が押していたのにもかかわらず
私たちの質問にも丁寧にお答えいただき、

またとってもフランクに楽しく過ごさせて頂きました。
ありがとうございました!




なかでも印象に残ったお話しは

上司、部下といった概念があまりないらしく、
社員みんなでジャンル問わずものづくりされていること。

様々な業界のクライアントからの案件で成り立っているので
社内に営業担当はいないこと。

「technology × creative」を念頭にものづくりされていること。

でした。



となりのテーブルで会議している席から
よく笑い声が聞こえていて

社員の皆さんがとても楽しそうにしていたのも印象的。
ものづくりを楽しんでいるんだなあと分かりました。




☆オフィスレポ
 

teamLabさんのオフィスは、とにかくカラフル!
壁が黄色く塗られていたり、床のカーペットもカラフル!

小さいころにいった児童館を連想しました。 



写真 2016-03-14 21 03 11


座談会を行ったテーブル。
東京のごちゃごちゃ感をイメージしたアート作品です。

痛車が書いてあったり、おすもうさんがいたり、
見ればみるほど新しい発見がありそう。飽きない。



写真 2016-03-14 20 50 45


同じくテーブルから。「メモテーブル」!

テーブルの上に大きな真っ白の紙が置かれていて、
イメージによるコミュニケーションしやすくなってます。

一枚ずつめくることもでき、メモをそのまま資料にすることも可能!
感動しました。





写真 2016-03-14 20 49 48


持った服のコーディネートが表示されます。
ハンガーの部分の基盤で感知しているらしい。
持ち上げた回数もカウントするので、人気商品の解析もできる!

思いつきでいのき様が星の服を持っている時に
私が緑の服を持ってみたところ

両方のコーデが交代で表示されました。

モニターを多く用意しないと、たくさんの人が服を持った時に
モニターチカチカしそうだな・・・




写真 2016-03-14 20 55 08

唯一個室になっている、茶の間テイストの会議室。
壁も天井も細長いゴムを重ねたもの(語彙のなさに絶望)でできており、
どこからでも入れます。

お昼寝してもバレなさそう・・・とか思ってないです。ええ、思いませんよ。




写真 2016-03-14 20 56 58



男子トイレのマーク!マリオ!
ちなみに女性はピーチ姫。
遊び心溢れていてとても素敵!



写真 2016-03-14 20 59 01



エレベーター横にある液晶。

四季を表しており、リアルタイムでPCが作成しているもので、
同じ風景は1度しか現れない仕組み。
つまりこの画像は今日のあの時限定のもの!

ロジックが気になる。どうやっているんだろう・・・






今回の座談会は、とても暖かく楽しい雰囲気のまま
最初から最後まで参加することができました。

いのき様、teamLab様、ありがとうございました!(´∀`)




・・・エントリーの準備します。



ちょこひ



 

こんにちは(´∀`)


今日は久々に春休みしています。

何も予定がない平日っていつぶりだろう?


これを更新したら妹の誕生日プレゼントを探しに旅に出ます。




☆重大な見落としがあった


前回の記事
スマホアプリのマーケット分析を書いたけど

更新して2分後くらいに気づいたことがあって。



これ、アプリのみのサービス前提の話や・・・


スマホアプリって、
Webサービスがメインのものが多いですよね。

例えば 賃貸物件検索サイトとか、求人サイトとか、Facebookも。


その場合、売れるかどうかは
アプリの機能ではなくWebサービスの機能によるという
重大なことが見えていなかった。 


我ながら視野の狭さに驚きました。
思い込みもあったのかな。


今の見解は
売れるアプリには、ニーズのあるWebサービスが必要な場合が多い」 

に変わりました。





☆知識が足りない


ニーズのあるWebサービスってなんだろう?と考えてみたんです。

そこでまた気づいたことがあって。


Webサービスの知識、ほとんどないな。 


私の学科はモバイルアプリ開発に特化しているので
授業は技術メイン。


この1年で
Java、Swift、MySQL、Linux、HTML5、CSS、JavaScript
こんだけやりました。 

パソコン使わない授業なんて数えるほどしかない。
そういう学科です。


プログラマとしては即戦力にならなくもないとは思う。



でもいまのプログラマ・エンジニアって
モバイル領域は特に、

「ただ書けるだけ」じゃダメだと考えてます。


チームで動く際のマネジメント能力であったり、

新しいサービスの発想力であったり、

プラスアルファの能力が求められてると思う。



だって、ただ書けるだけのプログラミングなんて
勉強すれば誰だってできると思うから。

ITではないサラリーマンの副業にプログラミングが選ばれることが多かったり
文系大学生がエンジニアとしてIT企業に入社するのが珍しくなかったり。



IT系専門に在学している以上、
技術はあること前提で、

プラスアルファの能力で人材判断するのかな、と思っています。




 ☆Webサービス

私が勝手にこんな感じだろうと思っている
Webサービス運用までの流れを以下に書きます。


①サービスを思いつく
 ヒアリング等行いニーズの見極めをする

②そのアイデアを実現する機能を決定し、サービスの構造を決める

③ 各技術者によりコーディング・プログラミング

④デバック、ユーザーテスト

⑤最終調整

⑥リリース


こんな感じ。


これが一般的に行われている流れなのかわかりません。
知識がないから。


ひとつ思っているのは、

アイデアを技術により形にする

というのは間違いないかな。



そしてわたしは
アイデアを技術行程に渡すまでの知識が乏しすぎる。


アイデアだけじゃプログラミングできません。
そのアイデアに肉付けしなければいけない。


でも、肉のつけ方わからない・・・




全力でワークショップ探しています。


もうお隣学科(Webサービスに強い)に潜入したい(´;ω;`)





ちょこひ 



こんにちは(´∀`) 

某企業様にお邪魔して、
オフィス見学及び現在活躍されているエンジニアさんたちと
楽しくお話しさせていただいた帰り道。

自宅近くのカフェでドヤリングなう。

sQxKHCT5



これ更新して、企画書完成させたら帰宅します(´∀`*) 



もう、ただ作る段階じゃない

GooglePlayとAppStoreの状況。


最近ある程度自分が思うがままにプログラミングできるようになってきて。
んもう超楽しくて。

こんなの作りたいー!っていうのがバンバンでてきてて。

そして最近ようやく初めてGooglePlayにリリースできたのもあり。


ただ「作りたい!から作る!」だけじゃダメなんだなって思い始めた。


つまり

ニーズのあるアプリ


言い換えれば

売れるアプリ」「稼げるアプリ」。


そろそろアプリでお小遣い稼ぎ、したい。



そんなこんなでマーケットについて考えて
「売れるアプリ」ってどんなのだろう?という考えを
まとめておこうかと。


まだサーバーサイドは全くわかってないし、
来月からようやくPHPに入るので、

サーバーサイドもできるようになったらまた見方は変わるかもしれないけど


2016年3月9日時点で私なりに分析した結果を書いておきます。 



☆行き着いた答えは2つあった

とりあえず、考えてみた。

今のマーケットは、「飽和状態になりつつある 」段階だと思う。


例えば「こういうアプリほしい」って思ったとして、
検索かければ大抵のものは見つかる。


見つかるということは、同じようなアプリをリリースしても、
定着しているライバルアプリが存在しているかもしれない。

そのアプリを超える「何か」を持たせなきゃいけない。


ひとつめの答えは、

すでに存在するアプリの細かいニーズを拾い、
上位互換アプリとしてリリースする
、というもの。

痒いところに手が届くアプリ」って呼んでます。

ここでいう細かいニーズは、ユーザーの
「こういう機能ほしいなあ」というもの。
レビューに書かれているもので、その開発者が実装していないもの。


これは爆発的に流行ることはおきにくいとは思うけど、
一度ユーザーを満足させれば定着してくれると思う。

他アプリからユーザーを引っ張ってくる必要があるから
宣伝や売り込みが重要になってくる。


最近カレンダーアプリで流行っている「TimeTree」がいい例で、
それまでカレンダーアプリでここまで流行ったものってないんじゃないかな?

私も乗り換えたうちの一人。共有機能は本当に便利。






あるいは
全くライバルアプリがないものをリリースする。


ふたつめの答えは
誰も思いつかないような斬新なアイデアを持ったアプリをリリースする、というもの。 

これはゲーム系に多いと思う。 
初期ユーザーの口コミによって爆発的に流行りやすいタイプ。
その分、定着させるのは難しい・・・かなと。


少し前に流行っていた「Temple Run」とかがいい例かと。
当時誰のスマホにもインスコされていたけど、今はあまり見ないなあ。


ずっと定着し続けてる例としては、「パズドラ」とか。

リリースから何年たったかわからないけど、
クラスメートのパズトラファンの割合は未だに高い。すごい。







と、こんな感じです。はー、口では伝えやすいけど、文章難しい。
さすが日本語が苦手なだけあります(笑)


私なりの分析はこんな感じ。

先日リリースしたアプリは、
ひとつめの「痒いところに手が届く」を意識して作りました。


そして今あっためてる企画は
ふたつめの「斬新なアイデア」の方。
ゲーム系ではないけど、日々の勉強の中で私がほしいな〜と思ったツールです。


こういうこと考えながら、周りにも意見聞きながら、
わいわい実装するのは本当に楽しい。


わいわい開発できる企業様の内定、大募集中です。



ちょこひ
 

↑このページのトップヘ