WordPressから自分でフレームワークを使用したWebサイトへの移行【Laravel】~第2回 機能編~

どうも、sh0です。

前回からに引き続き

  • WordPressから自分でフレームワークを使用したWebサイトへの移行

を進めていきたいと思います。

今回は、第二回の機能編として、必要な機能について検討して行きたいと思います。

まだ、1回目を見ていないという方は、こちらからどうぞ

 

必要な機能の洗い出し

機能の洗い出しの前に前提を少しだけ。

このサイト「1日1本アプリ開発」は、3人で作成しています。

  • sh0・・・エンジニア(私)
  • moza・・・エンジニア
  • オザワ・・・エリートサラリーマン(非エンジニア)

エンジニアでないオザワさんもいるので、記事更新の際にもWordPressのように管理画面のようなものは、必須となります。

では、洗い出しを始めていきましょう。

まずは、ズラズラズラと、書き出します。

  • 記事を表示するための画面・機能
  • 記事を投稿・編集するための画面・機能
  • コメント画面・機能
  • お問合せ画面・機能
  • 全ての画面のデザイン
  • SEO関連の機能
  • その他固定ページ(プライバシーポリシー等)
  • カテゴリー機能 etc

何も考えずに書き出しましたが、一旦こんなものでしょうか。

何か抜け漏れありそうな気もしますが、まずはこれで全てと考えましょう。

(ちゃんとしたウォーターフォール型モデルで進めるんなら、ここでアウトっぽいですが、作業は私一人でやるんで、気にせず行きます。思い出したら付け足せばええよ)

さあじゃあ、機能は洗い出せた!では、作業に移ろうか!!

とは、流石になりませんね。

 

優先順位付け

何せ、そこまで時間はありません。これら全てを一から作っていたら、いくらなんでも時間が足りなくなります。(第100回とかまでかかってしまいます)

なので、先ほど洗い出した機能について、ちょっとだけ補足していきます。

  • 記事を表示するための画面・機能→必須
  • 記事を投稿・編集するための画面・機能→必須
  • コメント画面・機能→必須でない
  • お問合せ画面・機能→広告関係で必須
  • 全ての画面のデザイン→Laravelのデフォルトで一旦いいや
  • SEO関連の機能→必須でない
  • その他固定ページ(プライバシーポリシー等)→広告関係で必須
  • カテゴリー機能→必須でない

これで必須と必須でないものにいったん分けられましたので、

必須でないものは後回しにします。

まずは残ったこちらを考えていきます。

  • 記事を表示するための画面・機能
  • 記事を投稿・編集するための画面・機能
  • お問合せ画面・機能
  • その他固定ページ(プライバシーポリシー等)

 

1つ1つの詳細を考えていく

1.記事を表示するための画面・機能

これに関しては、基本的に作るしかないんですが、どこまでを1から作るかを考えなければいけません。

  • これまでの記事はどうするか
    • wordpressのDBはそのままに参照するか
    • DBから作り直してコンバートするか
  • デザインは一旦、Laravelのデフォルトを使用する

ここでは、検討内容については答えを出しません。

第3回の着手編でやりながら答えを出していきます。

2.記事を表示するための画面・機能

1に関連するので、被りますが、

  • これまでの記事はどうするか
    • wordpressのDBはそのままに参照するか
    • DBから作り直してコンバートするか
  • 管理画面を1から作るのは手間なので、wordpressのダッシュボード(記事の更新)だけは利用できないか

下側を利用する場合は、wordpressから脱却できていませんが(笑)、この辺は時間との相談ということで。

3.お問合せ画面・機能

これは、もうLaravelで作っているのがあるので、そのまま流用します。

4.その他固定ページ(プライバシーポリシー等)

これは、正直考える必要もないレベルです。1を作る際に、固定ページも一緒に考えようってだけですね。

 

まとめ

少し長くなってしまいましたが、まとめとしては、とりあえず

  • 記事を表示するための画面・機能
  • 記事を投稿・編集するための画面・機能
  • お問合せ画面・機能
  • その他固定ページ(プライバシーポリシー等)

を作って、後は一旦後回し!徐々にやっていこう。です。以上!

 

 

次回の私の更新は、2019/12/23です。

第3回目では、着手編について考えて行きます!

是非見てください!

【基本情報などを受けるSQL初心者向け】ブラウザ上でSQLが実行できるサイトまとめ

どうもmozaです。

私は基本情報技術者試験を大学生時代に受けたのですが、その時はブラインドタッチもできない、全くのIT初心者でした。

基本情報技術者試験の技術要素にデータベース分野があるのですが、SQLて言われても全くイメージがつかず、情報科のサークルの先輩を捕まえて質問してみました。

すると先輩には、こう言われました。

先輩
先輩

環境構築して実際に動かしてみたら、SQLなんてすぐ覚えるよ!

初心者だったので環境構築ってなにそれ、意味わからん。という状態でした。

SQLは実際にてを動かして実行してみたらすぐに覚えることができるという意見は同意なのですが、環境構築が初心者には厳しいのです。

そこで、今回は環境構築不要で、実際にSQLを書いて覚えるためのサイトをまとめました。

ブラウザ上でSQLを実行できるサイト

1.sqliteonline(https://sqliteonline.com)

個人的には一番おすすめです。

使えるデータベースはSQLiteとMariaDBです。新人エンジニアで、業務で SQLiteとMariaDB以外を使用することが決まっている人以外は、このサイトがよいと思います

2.SQL Fiddle(http://sqlfiddle.com/)

MySQL, Oracle, PostgreSQL, SQLite, SQL Serverと主要なデータベースをブラウザ上で実行できるサイトです。

それぞれのバージョンは若干古いところもありますが、初心者がSQLを試すのには、ちょうど良いサイトだと思います。

3. SQL攻略 – Web上でSQLを実行しながらマスターするサイト ( http://sql.main.jp/ )

ブラウザ上でSQLを実行しながら、SQLを学べるサイトです。これをすべてやり切れば、基本情報のデータベース分野は得点源となるはずです。

4. Oracle Live SQL ( https://livesql.oracle.com/)

データベースのシェア世界一のOracleが提供する、ブラウザ上でOracleデータベースを実行できるサイトです。使用するためにはOracleのアカウントを登録する必要があります。

いかがでしたでしょうか?基本情報や応用情報を受ける場合、データベース分野の勉強をしておけば、ぐっと合格に近づきます。

SQLやデータベースは 歴史が長いため、情報処理試験では最新トレンドなどに左右されずにワンパターンな問題構成となっていることが多いように感じます。

SQLを学んで、合格しましょう!

WordPressから自分でフレームワークを使用したWebサイトへの移行【Laravel】~第1回 検討編~

どうも、sh0です。

今回から今月5回に渡って、

  • WordPressから自分でフレームワークを使用したWebサイトへの移行

の検討・実施を行っていきたいと思っています。

*2019/12/15の現在このサイトはWordPressで作成しております。

第1回目の今回は、実施を行う前に、

を記載して行きたいと思います。

 

 

なぜWordPressをやめようと思ったのか

まず、1番の理由をキッパリと書きます。

WordPressは、使っててなんかつまらない

はい、すみません。結局理由なんて、こんなものです。

ただの私の気持ちが原因な感じです。

細かい理由も念の為、上げておきます。

  • WordPressを使用していることがすぐにさとられる
  • デザインが似たりよったりのものになりがち
  • 更新が頻繁にくる
  • プログラムが不要
  • 自分でサイトを作っているといってもWordPressだと成果とは言いづらい
  • 細かいJSでのカスタマイズなどがやりづらい etc…

といった感じでしょうか。まあ、これら逆を言えば、全てメリットとも言えるんですがね。

今回は、まあ記事のネタも兼ねて(本音)、やっていこうと言うことです。

 

 

移行先にLaravelを選んだ理由 

ご存知の方も多いと思われますが、LaravelはPHPのフレームワークです。

ここ最近では、PHPのWEBフレームワークとしては、1番の人気を誇っていると思われます。

私自身も仕事として、Laravelを使用したサイト作成をいくつもやってきましたが、とても使いやすいと思います。

個人で運用しているサイトでもLaravelを使用して作成しているものがいくつかあります。

え?つまり、簡単で慣れているからと言う理由だけで、Laravelにしたと言うことかって?

それもあります(それしかありません)

ですが、念の為、他の候補とそれらの検討結果だけ記載しておきます。

候補検討から外れた理由
CakePHP(PHP)・(筆者個人が)Laravelの方が慣れている
・世の中の使用頻度もLaravelの方が増えている(今後も安定した更新、使ったことのある人が増えることが見込まれる)
django(Python)・Pythonの勉強にもなるが、どうしてもPHPより慣れていない分、作業に手間がかかる
・Webフレームワークとして使用するには、CakePHPやLaravelに比べると用意されていない機能が多い

どれも大した理由ではないです。

好みと思ってもらっても良いかしれません。

  

 

まとめ

WordPressをやめる理由→好み

Laravelにした理由→慣れている

 

以上!

 

 

次回の私の更新は、2019/12/19です。

第2回目では、機能の設計について考えて行きます!

是非見てください!

【Unity】SE音の設定【正解音・ハズレ音】

今回のソースは、SE音の設定についてです。

使用するのはAudio Sourceコンポーネントです。

SE音だけでなく、BGMなんかもこいつの設定で簡単に出来ますね。

まずは、Hierarchy内にあるオブジェクトに対して、Audio Souceをアタッチします。

そして、流したい音楽を、AudioClipに設定するだけ。

なんとこれだけで、音楽が流れ出します。

BGMなんかは本当にこれだけの設定で完了ですね。

今回の様な正解音やハズレ音といったSE音は、
ゲーム開始にすぐなってもらって、
終わりでは困ります。

ユーザの選択によって、

あっている→正解音
外れている→ハズレ音

と流れて欲しいわけです。

ですので、第一段階として、
まずはゲーム開始時にならない様にします。

画像の中にある、
Play On Awake
これのチェックを外しましょう。

次の動作としては、
ユーザのタップで正解音・ハズレ音のいずれかを鳴らす必要があります。


 // クリック処理(正解時) 
Collect = GameObject.Find("Collect");
Collect.GetComponent<AudioSource>().Play();

 // クリック処理(ハズレ時) 
Fail = GameObject.Find("Fail");
Fail.GetComponent<AudioSource>().Play(); 

コードはこれだけです。

やっていることは、AudioSourceのPlay()という関数を呼ぶだけなんですね!

とてもわかりやすく用意されていますね!
(私はすぐ忘れるのでメモです )

【Unity】タイマー機能の作成

どうもozaniです。

制限時間を表示する、タイマー機能をテーマに以下のアプリを作成しました。
アプリの紹介記事はこちら!
【1日1本アプリ開発】柿をかわせ!【16本目】

時間を表示するテキストの作成

手始めに、制限時間を表示するテキストを追加します。
Create > UI > textを選択して、テキストを追加します。

今回のアプリでは60秒をカウントするので、初期のテキストに書かれている内容を60秒とします。
これは、InspectorタブのTextに60秒を表すように入力してあげればよいです。

これで、画面上に表示するタイマーのテキストが完成しました。

タイマースクリプトの作成

次に、1秒毎にタイマーテキストの表示を変更する、タイマースクリプトを作成しました。

	
    public class GameMaster : MonoBehaviour
    {
        
        public Text timer_text; // タイマーテキストを設定します。
        int timer_count = 60;  // 初期は残り60秒

        // Use this for initialization
        void Start()
        {
            StartCoroutine(CountTime()); //CountTime()を数秒(今回は1秒)おきに実行
        }

        public IEnumerator CountTime()
        {
            yield return new WaitForSeconds(1f); //1秒待機
            timer_count--; //制限時間を1秒減らす
            timer_text.text = string.Format("Time:{0}", timer_count.ToString()); //タイマーテキストを変更

            StartCoroutine(CountTime()); //CountTime()を実行
        }
    }

タイマー用のテキストに上記スクリプトをつけることで、制限時間を表示するタイマーとなります。

今回のスクリプトは、Unity(C#)のコルーチンという機能を用いて実装しました。
参考:Unity Document(MonoBehaviour.StartCoroutine)
メインの処理とは非同期に、動作・停止を繰り返し行う仕組みみたいです。

使いこなせたら便利なので、コルーチンについての説明は改めてどこかでしたいと思います。

【使用ゲームエンジン】
Unity2018.3.5.f1

【プロジェクト管理】
git(Bitbucket使用)

【1日1本アプリ開発】世界の愛してる!【13本目】

どうもozaniです。

開発13本目のアプリです。

【1日1本アプリ開発】世界の愛してる辞典!【13本目】

世界中の女性とお近づきになりたいと思ったこと、ありませんか。
そんな思いを込めて作成したアプリとなります。

 

・今日のちょっとソース。

シーン間の値の受け渡し

	
   // ラベル文言管理クラス
   class LabelWords
   {
       public static string ILoveYou { get; set; }
       public static string ILoveYouKana { get; set; }
   }
   // ドロップダウン変更イベント
   public class LanguageDropDown : MonoBehaviour
    {
        public void OnValueChanged(Dropdown dropdown)
        {
            switch (dropdown.value)
            {
                case 0:
                    LabelWords.ILoveYou = "愛してるよ";
                    LabelWords.ILoveYouKana = "アイシテルヨ";
                    break;
                case 1:
                    LabelWords.ILoveYou = "I love you";
                    LabelWords.ILoveYouKana = "アイラブユー";
                    break;
                    ……(略)
            }

        }
    }

上記のソースコードは、ドロップダウンを変更したときに動くプログラムです。

Unityでシーン間で値を共有する場合、最も簡単な方法は静的(static)な変数に値を入れてしまうことです。
上記のソースコードの様に、変数にstatic キーワードをつけることでその変数は静的な変数となります。

静的な変数の特徴は、プログラムの開始から終了まで値が保持され続けることです。
普通のstaticではない変数というのは、使い終わった後その値と領域は破棄されます。
今回リリースしたアプリを例にすると、最初のトップのシーンで言語を「英語」と選んでも、普通の変数だとシーンが切り替わるタイミングで破棄され、次の愛してるよのシーンでは何が選択されているのか、わからくなってしまいます。

staticな変数は乱立すると、「え、今これ何入ってるんだっけ?」と複雑怪奇なプログラムになり、思わぬバグの元となりますので、ご利用は控えめに!

【使用ゲームエンジン】
Unity2018.3.5.f1

【プロジェクト管理】
git(Bitbucket使用)

【知り合いに実際にプレイしてもらった感想】

グラフィック :

ボリューム  :

操作性    :

ゲームバランス:

独創性    :

クリアタイム :00分