忍者ブログ
プログラマ、ララ・ベル子さんのゆるふわ奮闘記。

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

MacにMySQLをインストールして3コマンドでLaravelをどーんの巻

どうも!
久しぶりですね。みなさん元気にしてましたか。
「内容はともかくとして、息抜きにいいよね」とブログをボスに褒められたベル子です。

内容で勝負してるつもりだったのに!

いえ、でも褒めてくれる人がいるのは嬉しいことです。

先日、このブログを全く読んでいないことを確信しているので登場させたい放題に登場させている、師匠ことO様にも遠回しに通訳つきで褒めていただきました。
おそらく、「頑張ってるよね!」と褒めてくれたんだと思うのですが、分かりづらすぎて自信ないです(爆)
通訳してくれたM先輩、ありがとうございました。
お二人とも、とても大好きな先輩です。

雑談はこのくらいにして、本題に入ります。
自宅でLaravelの勉強をするときに、簡単なテストコードを書くために、いちいちVM(ヴァーチャルマシン)を立ち上げるのが面倒になってきたので、MacにMySQL入れちゃえば、Mac上でLaravel動かせるんじゃないの?そうだよね?ということに、ようやく気付きました。

なぜもっと早く気づかなかったのか。
激しく後悔、ハゲ校するほど便利です。

ということで、手順を早速まとめたいと思いまぁーす♪
XcodeとかHomebrewとかComposerとかPHPとか、そんなのはとっくにインストールしてあるよって人はその部分のステップを飛ばしてください。

★Step.1
Xcodeをインストール
App Storeで検索してインストール

★Step.2
Homebrewをインストール
公式サイトにあるコマンドをコピってターミナルに貼り付けてインストール
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

★Step.3
PHPを5.6にする
↓このサイトの通り、Macに入っているPHPを5.6にする
macにhomebrewでPHP5.6環境をインストールしてみる

★Step.4
MySQLをインストール
↓このサイトを参考にHomebrewでMySQLをインストール
Mac へ MySQL を Homebrew でインストールする手順

とは言え、以下の2行をコマンドーんするだけ。
$ brew update
$ brew install mysql

★Step.5
MySQLを立ち上げる
$ mysql.server start

★Step.6
ComposerをMacにインストール
$ brew install composer

★Step.7
Laravelをインストール
Mac上のお好きな場所にLaravelをインストール(無邪気にデスクトップなんかでもおk)
{directory}の部分は任意のディレクトリ名

Laravel 5.1
$ composer create-project laravel/laravel {directory} --prefer-dist

Laravel 5.0
$ composer create-project laravel/laravel {directory} "~5.0.0" --prefer-dist

Laravel 4.2
$ composer create-project laravel/laravel {directory} 4.2 --prefer-dist

★Step.7
データベースを作る
{db_name}の部分は任意のデータベース名
$ mysql -uroot
$ CREATE DATABASE {db_name};

★Step.8
プロジェクトディレクトリ直下にある.envファイルを開いて、データベースの設定をする(Laravel 5~)
※以下はlaravelというデータベースを作成した場合


★Step.9
プロジェクトディレクトリに移動しビルトインサーバを起動する
$ php artisan serve

★Step.10
ブラウザでhttp://localhost:8000/にアクセス!
止めるときは Ctrl+C だよ。

あとはMigrationでテーブル作ったりなんなり好き放題やってください。

MySQLを止めるときは以下のコマンドです。
$ mysql.server stop


Sequel Proを使ってる方は以下の設定でDBに接続できます。


ちょっとした勉強で少しいじりたいというときに、3コマンドくらいで立ち上げてテストできます。恐ろしく便利んぐです。

あーもっと早く気づいてたら、よかったのに!と思いましたが、いろいろVMの設定やらで困ったおかげで知識は増えたと思うので、四苦八苦してハマったり絶望したり発見したりすることって大事だなって思います。悩んで解決したことって本でつらつらと読むよりも、よく覚えられます。


↓ここからは完全に話が脱線するので、暇で暇でしょうがない人か息抜きしたくてたまらない人用です。
以前、エンジニアをやりながら字幕翻訳の仕事もやっていたのですが、「どこで翻訳の勉強をしたのか」「どうしたら翻訳者になれるのか」という質問をよくされるんですよね。「私もやってみたいなー。自宅で仕事できて、経費もかからないし、子育てとの両立もできるしいいよねー」とか言われるんです。
もう慣れたので「うん。まあ確かにね」くらいの感じで適当に返事をするようにしてるのですが、
たぶん世間の人の翻訳者に対するイメージって「語学力があるだけで、文字を書いて生活できるなんて、楽そう!」なんですよね。

翻訳はある意味、自分との戦いです。見えない正解がどこかに一つだけあって、それを砂の中から必死に探すような感覚です。そして、自分が3日間ほとんど寝ないで考えたセリフについて、他人から批判されるということを受け入れなければいけません。
チェッカーに監修、納品先のディレクターそして最後は視聴者です。

それから、納期を落とすと放送事故になってしまうというプレッシャーとの戦いでもあります。
だから3ヶ月持てばいいほうで、ほとんどの人がすぐに辞めてしまいます。
必死に書いた翻訳も新人の場合は、半分以上、手直しされます。
痛烈なダメ出しつきで、ギャラもほとんどタダみたいな値段です。

それに翻訳者は翻訳だけしてるわけではなく、ハコ書きというセリフを何フレーム数出すかという作業もしていますし、聞き取りもしています(スクリプトがある場合もあります)。
すべて翻訳されているように見えて、ここは要らないというように字幕が出ていないものなどもあります。そういうのを2割り程度の手直しに収まるくらいのクオリティーで一人で仕上げて、ようやく一人前のギャラがもらえます。

あと、「なんか翻訳がダサい。日本語のボキャブラリーが少ない。」のような印象を持たれると仕事をもらえなくなります。
文章翻訳はハコ書きはありませんが、大量にものすごい短期で翻訳していくことが多くて専門用語も多かったりして、調べ物が多くて大変です。

その点、プログラミングの場合は、同じように大変でも、周りから「大変そうだね。すごく勉強しないといけないでしょ?夜、寝れてる?」と心配してもらえるので、このイメージの違いは何なんだろう?とか思っちゃいます。

プログラマが楽だとは言わないですが、夜はちゃんと寝れてますし、ボスや先輩たちも愉快な仲間たちばかりです。

どちらも大変だけど、仕事としてのやりがいはすごくあります。

最後はいったい何のまとめだか分かりませんが、翻訳はそんなに甘くないぞってこととLaravelはいつでも3コマンドでどーんできるぞってことですね、はい。

では、また会える日まで。
I'll get back to ya soon!!

拍手[0回]

PR

プログラミングのドキュメントなんかによく出てくる英単語を集めてみたよ

なななんと、とととうとうLaracastsの月額会員の契約をしてしまったので、毎日、ララキャス見放題のベル子です。ヒャッハー。 毎月、9ドルのお布施!!

サーバーサイドのお仕事をするようになってから、翻訳された記事とかドキュメントではなく、原文を読んだり、最初から英語のサイトで調べたりすることが多くなりました。
実は日本語で書かれた翻訳版より、英語の原文を読んだほうが簡単に感じるということは、よくあることです。

私の個人的な体感ですが、日本語の言い回しは述語が最後にくるので要点の把握に時間がかかり、長文や難解な文章になると、文章の全体を記憶し整理しなければならず、非常に頭を使うんです。

↑この文の言ってることを理解するのに時間がかかりませんでしたか?
この文だと、「日本語は頭を使うんです。」を理解してると、理由がすっと入るはずです。
はず!

日本語が持つ独特の美しさというのは、まだ話していない見えないものを想像させる美しさなのかもしれないですね。私は日本語という言語がとても好きです。

By the way,

プログラミングのドキュメントなどを読むときに役立つと思うので、 一般的に日本人が横文字にして使わないような少し難しめの英単語を集めてみました。
簡単なワードも混ざってますが、プログラミング系頻出ワードなので、英語の復習も兼ねて載せておきます。

Laracastsから抜粋してるので、Laracastsを見るときにも参考になると思います♪


  • appropriate

     

    ふさわしい

  • argument

     

    引数

  • associate with

     

    関連づける

  • assume

     

    ~だと想定する

    It's going to assume a Views directory (Viewsディレクトリと想定される。)

  • bundle

     

    同梱する

  • capsulation

     

    カプセル化

  • cast

     

    別の型に変換すること、データを送ること

    類語 type conversion

  • circumstance

     

    状況

  • collision

     

    衝突

  • composition

     

    構成

    favor composition over inheritance(継承よりコンポジションを選ぶ)

  • concrete

     

    具体的な

  • configure

     

    設定する

  • consistency

     

    一貫性

  • consistent with

     

    一致する

  • constant

     

    定数

  • convention

     

    しきたり、慣例

  • correspond

     

    一致する

  • curly brace

     

    波カッコ

  • decompress

     

    解凍する

  • dedicated

     

    専用の

  • dispatch

     

    タスクを割り当てる

  • duplicate

     

    重複する

  • eliminate

     

    除去する

  • encapsulation

     

    カプセル化

  • encrypt

     

    暗号化する

  • equivalent

     

    同等の

  • excerpt

     

    抜粋

  • explicit

     

    明示的な

  • extract

     

    抽出する

  • fetch

     

    取ってくる、引き出す

  • formula

     

    数式

  • identical

     

    全く同じ

  • identifier

     

    識別子

  • implement

     

    実装する

  • implementation

     

    実装

    Program to an interface, not an implementation(実装ではなく、インターフェースに対してプログラミングしましょう)という設計概念

  • implicit

     

    暗黙の

  • inheritance

     

    継承

  • instantiate

     

    インスタンスを生成する

  • iteration

     

    繰り返し

  • jargon

     

    難解な専門用語(内輪的な)

  • mandate

     

    権限を与える

  • manipulate

     

    操作する

  • omit

     

    省略する

  • operator

     

    演算子

  • out of the box

     

    難しい設定は要らない(箱から出したそのままで)

  • overwhelm

     

    圧倒させる

  • parenthesis

     

    カッコ

  • persist

     

    維持する

  • polymorphism

     

    多様性、ポリモーフィズム

    継承クラスで親クラスの同一メソッドをオーバーライドできる性質のこと

  • positive number

     

    正数

  • precede

     

    前置きする

  • precedence

     

    優先

    take precedence over((重要度において)優先される)

    priorityは時間的な優先、もしくは一般的な優先度。
    プログラミングにおいての重要度の優先を表現する場合は、precedenceを使うことが多い。

  • precedent

     

    慣例

  • prettify

     

    美しくする

    類語 beautify

  • procedural

     

    手続き上の

    procedural PHP(手続き型PHP)OOPと対比される

  • proceed

     

    続ける、進行する

  • reiterate

     

    反復して言う

  • reproduce

     

    再現する

  • retrieve

     

    検索する、読み出す

  • rule of thumb

     

    大ざっぱな決まり

  • seasoned

     

    習熟した

  • sequence

     

    順序

  • specific aspects

     

    具体的な側面

  • square

     

    二乗する

  • suffix

     

    接尾辞

  • superfluous

     

    余分な、不必要な

  • syllabus

     

    概要

  • tedious

     

    長ったらしくて退屈な、冗長な

  • term

     

    用語

  • terminology

     

    専門用語

  • time consuming

     

    時間の浪費

  • variable

     

    変数

  • verify

     

    証明する


以上です!
See you again !!

拍手[1回]

黒い画面のカラースキームをgetafeにしてシェルをzshにした

どうも、先日、かわいい猫画像を見て「おいしそう!」と叫んで周りをドン引きさせてしまったベル子です。

この記事は完全に自分の忘備録です。

マカーの私はiTerm2を使ってるんですが、今までカラースキームをsolarizedにしていました。

▼詳しくはこちら
iTerm2のテーマをSolarizedに変更する方法

で、私はTransparency(透明度)がかなり高いのが好みでして、オシャレっぽいから何となく人気だと書いてあったsolarizedにしたんですけど、限りなく透明に近いsolarizedだと限りなく透明に近いので、当たり前に見づらいんですねw

でも、なんとなくそのまま放置していたわけです。
見えないわけではないので←
だって透明なほうがいいんだもの。

がしかし、見づらい設定を続けることは非効率的だし目に悪いと思うので、いい感じのカラースキームにしたいと思いたちました。

そこで以下の2つのサイトを参考に黒い画面のカラースキームをgetafeにしてシェルをzshにしてみました。

ターミナルをカラフルでかわいくする
zsh 入門 - MacOSXのシェルをbash→zshに変更 -

カラフルでかわいくて俄然テンションがあがりますっ!
会社のMacさんにも設定してあげようと思います。

拍手[0回]

うちの嫁(Chrome)が発狂したので、よそ様の嫁(Firefox)と遊んでみた

どうも、Cookieのことを考えながら料理していたら、おかずに味を付け忘れたことも気づかず、半分ほど食べてしまったベル子です。
ほら、ベル子さんはヘルシー志向だから。

~~回想~~

LaravelでCookie::getだとうまく読めなくて、PHPのネイティブな書き方をすると読めたんだよなぁ。あ、LaravelではCookieを暗号化してるとか書いてあるから、JSで登録したCookieはファサードのやつでは使えないのかもしれないな。
やっぱりCookieじゃなくてSessionを使ったほうがよかったのかも。
クリックするたびにAjaxでSessionにPOSTするのとか、え......って感じするけど。
何コイツ、やり過ぎ超絶キモいとか思われそうだし。
それかSessionStorageに貯めておいて、最後のクリックで一気にドーンするべきなのか?
一気にドーンしてカッコいいですね!って感じかな。いや、待てよ。どうやってLaravelにドーンするんだろ。........よく分からない。
いや、やっぱりページネーションのリンクをクリックするときにSessionに全部ドーンでマージするほうがよくないか?うん、そんな気がする。
↑こんなこと考えてたので味付けどころじゃなかったww

もし分かる人がいたら、壁ドンしつつ顎クイしながら教えてください。(ワクワク)
よろしくお願いします。


というわけで本題です。

先日、うちの嫁(Chrome、以下うちの嫁)が暑さにやられたのか、過酷な労働に耐えかねたのか、発狂してしまったので、しばらくよそ様の嫁(Firefox、以下よそ様の嫁)とヨロシクやらなくちゃいけないことになりました。

いやー他人の嫁なんて、正直、使いたくないですよね。
仕事じゃなかったら、お断りしてます。
しかも、元カノですからね。
しかも、ケンカ別れなわけですし。
検証抜きで会うのは100万年ぶりぐらいのような気がしますが、3年とかそんなもんですね、実際は。

マジ気が重いです。昔の嫌な思い出が走馬灯のように駆け巡ります。

ポチッ

あれ?久しぶりに会ったら、結構、美人になってますね!
エラーコンソールだの、インスペクターだの、JavaScriptデバッガだの、わけのわからないツールを四方八方にド派手に散りばめていた頃の君は、もういないんだね。
よかったよかった。あれ、正直、みんなドン引きだったよ。
気づいてくれてよかったです。

開発者向けのツールがすっきりうちの嫁風に下にまとまりました。
元はうち嫁もよそ嫁のデファクトスタンダードであるFirebug様からパクってきてるインスパイアされてるので、Firebugが神ってことなのでしょうが。

しかし、元カノと別れた原因の一つがFirebugでもあります。
あの頃の元カノの重たさったら、マジ半端じゃなくて、Firebugなんて使ったらもう、
「イヤ、私と仕事のどっちが大切なの? 他の女と話すなら私、死んでやるからっ!愛してるって毎日100回メールしてよ!絶対絶対絶対絶対絶対」ってなくらい重たかったわけです。
もう毎日、その重たさにうんざりしてました。

そんな時です。今の嫁と出会ったのは。

会うたびに、首都高をゼロワンしちゃう光岡オロチ的、攻め攻めな彼女にだんだん惹かれてきました。開発ツールも非常に洗練されていてサックサクの使いやすさです。

最初は攻め攻めな態度に引き気味だったんですが、とうとううちの嫁にしてしまいました。

うちの嫁の一番好きなところはJavaScriptデバッガの使いやすさです。
見やすくて分かりやすくて軽い。
そうなんですよ、私、軽い人がどうしても好きなんですよね。

重たくて束縛感ある人が、この世で一番苦手なんですよ。
だから「俺の嫁」とか言われるの、実は苦手です。
苦手ついでに言うと、実は壁ドンも顎クイもされてみたくないです。

私のされてみたい憧れ少女マンガ的シチュエーションは
ドゥルルルル ダンッ(白目)
座ってる男性のネクタイを引っ掴んで「離してほしかったらキスしてよ」とかならやってみてもいいです。(どんなシチュエーションw)
やっぱ独創的なアプローチって大事だと思うんですよ。

ぐはっ! 話が脱線しすぎて何の話をしてるのか忘れてしまいました!すみません!
そうだ、私の偏執的嗜好の話ではなく、うちの嫁の話でした。←


よそ嫁を1日使ってみて思いました。

よそ嫁、結構イケてるところもあるじゃーん

と。

一番、感動したのは、インスペクタで要素を見ると、横にevというアイコンがついていて、それをクリックするとバインドされてるイベントの一覧がポップアップで表示されるところです。

▼参考
https://developer.mozilla.org/ja/docs/Tools/Page_Inspector/How_to/Examine_event_listeners

よそ嫁、結構やるぅ〜〜。
しかもデバッガアイコンをクリックすると一発で該当のjsのソースをデバッガで表示してくれる!
なんという便利さっ。お見それしました。

でもね.......このデバッガが、やっぱりちょっと重たいです。
なんか、私の書いてるjsが壮大なのは重々承知してますが、それにしても固まってうんともすんとも言わないということが結構あります。

あとjsエラーがやっぱり分かりづらいです。
コンソール画面を見てないと分からないです。

でも、インスペクタタブのCSSペインにある「このセレクタと一致するすべての要素を強調します」ボタンはかなり便利ですね!




ボックスモデルのマージンの設定なんかもキーボードの上下で値を変更できるのが便利ですし、shift押しながらだと10pxずつ増えてくれるというのも、画像編集ソフトと同じショートカットで分かりやすいです。



インスペクタの分かりやすさは、やっぱりよそ嫁の勝ちですかね....。
UI的に優れてますね。

あと、拡張機能とか入れないでカラーピッカーがついてるのもやっぱり便利です。



ギアアイコンの設定で「ページからカラーを選択します」にチェックを入れてください。

あとはメニューが日本語対応してるというのも日本人に優しくていいんじゃないでしょうか。

ということで、よそ嫁のいいところを紹介してきました。
基本的にはうち嫁と同じくらい便利で軽くなっていたので、たまには浮気するのもいいなと思います。Firebugも使えるし。

うち嫁は、何かこっそりヘソクリしてそうな感じも否めませんしね。

ただ、JavaScriptデバッガに関しては圧倒的にうち嫁の勝利だと思います。
変数の値をコードを見ながら追えるというのはかなり便利で見やすいです。

でも、CSSまわりのコーディング時はよそ嫁のほうが便利そうです。

最後に、ページのレンダリング速度はうち嫁のほうがやっぱり速いです。
複雑な処理のページだと体感的にかなり分かります。

やっぱり、人それぞれ長所と短所があるってことですね。
2人の嫁とうまく付き合って、便利で快適なコーディングライフを過ごしましょう!

ちなみに、Firefox Developer Editionなるものが出たそうですよ。
↓誰か使ってみて感想を教えてくださいませ。
https://www.mozilla.org/ja/firefox/developer/


ではでは。
See you soon.

拍手[0回]

注意されたこととか教わったこととか

ちわわっす。
光陰矢の如しっていう言葉を身をもって感じるお年頃のベル子です。

子供の頃はこんな年になるまで自分が生きているなんて想像もできませんでしたが、今では120歳以上まで生きる気満々です。

そんなわけで転職して、もう2か月が過ぎてしまいました。
早いですねぇーー。

最初は何がなんだか訳の分からなかったPHPフレームワークについても、かなり(自分なりに)分かってきて、すごく楽しいです♪

そんなわけで、新人生活2か月の間にいろいろやらかしてるので、注意されたことや教わったことを少し振り返ってまとめたいと思います。
間違った認識だったら、バファリンの半分の成分を忘れずに指摘してもらえると嬉しいです。
もしくはバシッとイケメン風に注意してくれるなら、それはそれで大歓迎です。

・gitでpushする前はgit statusで何がpushされるのか確認してからpushすること。

・gitでローカルブランチをdevelopmentとmasterで切り替えて作業していて、developmentの状態をリモートのmasterとマージしたい場合は、いったんローカルのmasterにマージしてからpushしたほうがいい。

・同じ処理を何度もいろんなところに書かない。なるべく共通化、関数化(メソッド化)する。

・\Don't Repeat Yourself !! Don't Repeat Yourself !! Don't Repeat Yourself !!/

・繰り返し使うことになるデータのペアは別の場所にまとめてハッシュ化し辞書的に参照して使いたまえ。

・Controllerの中にダラダラとロジックを書かない。

・Viewの中でデータ参照のために細かいことを書かない。細かいのはModelの中でメソッド化したほうがいい。そうしてるやつがあるから、それをちゃんと使いたまえ。

・モデルオブジェクトを返すメソッド以外の場合は、動詞などをつけて区別できるようにする。

・inputのnameはDBのカラム名と揃えること。

・ユーザーIDのような大事なパラメはパラメ渡ししない。(セキュリティ的に)

・中で取れるデータはわざわざパラメ渡ししない。

・phpのインデントとhtmlのインデントは分けて考える。

今のところは、こんなところでしょうか。
まだあったかな。


結構、ControllerとModelの使い分けというか、その辺がよく分からなくてモヤモヤしていたんですが、最近、何となく言われてることが分かってきました。

先日、マエストロがControllerとModelの中間みたいなのがLaravel以外のフレームワークにはあるからっていう話をしてて、そのときはまだ頭の中でまとまらなかったんだけど、
やっぱり、そういうのを作ったほうがやりやすそうかもって、今は思ってます。

Modelの中にメソッドを書いていくと、そのModelに紐付いたメソッドが中に書かれることになって、同じ機能というかモジュールで使われるメソッドがバラバラのファイルに書かれることになります。

関連するModelが多いといろんなファイルに関連するメソッドが置かれることになって、Userとか一見モジュールとは関係ないModelにも、ひょっこり登場することになり把握しづらさMAXです。

書いた人は絶対覚えてるけど、あとからそのモジュールに別の人が修正を入れようと思ったら、ControllerからModelを開いて、関係ないメソッドが並ぶ中から、該当のメソッドを探さないといけません。
検索すればいいじゃんって話だけど、無関係なメソッドがいっぱい書いてある中から毎回探すのって、非効率的だと思ったり思わなかったり。

(↓こんなブログを読んでくれる心優しいあなたのために、分かりやすい手描きの図を描いてあげました。)



あと、Modelには直接的に関係はないけどControllerに書きたくないメソッドもあるし。

それを最終的にどこか親のModel(親テーブルのModel)でまとめつつメソッドを作ったりするのだったら、モジュールごとに1つファイルを作ったほうが分かりやすいかもしれない。

調べたところ、一般的にはそういうレイヤーのことをServiceと呼んでいるようなので、app/servicesを作って、例えば『アラート機能に関するもの』だったらその中にAlertService.phpとか作ってまとめるといいのかも。




ふふ、ただそれをやろうとすると、大工事になること請け合いだし
またうっかりミスして、自分を呪いたくなりそうな予感もする。
うふふあはは。
ほら、あそこにお花畑が見えるよ、ペーター。


ライオンのお母さん的な人が多いので「好きにしなさい(いい感じにな!)」って言われそうですが。

ではでは、皆さん暑いけど夏バテしないようにねーー。

拍手[0回]