開発合宿 in 圡善 -PHPフレームワーク・Symfonyとは-

どーも。ばぁどです。

海の日の三連休を利用して、開発合宿行ってきました。

今回のテーマは、Drupalフレームワークとして利用されているSymfonyを使ってwebアプリケーション構築です。

Drupalを深く理解するための、Symfonyの勉強でございます。

フレームワークの名前的に、七色シンフォニー聞きたくなってしまいますね。

www.youtube.com

というわけで、Symfony2の入門書を引っさげて開発合宿に参加してきました。

gihyo.jp

今回の開発合宿の目標

  • Symfony触る

  • お酒飲みながら開発する

  • 合宿中であっても規則正しい生活を!

Symfonyって?

PHPフレームワークです。

Symfony, High Performance PHP Framework for Web Development

歴史としては、Zend Frameworkの次に古いPHPフレームワークのようです。 RubyRailsJavaのSpringから少し遅れて開発が始まったとのことでした。

現在はSymfony2と呼ばれる、ver 2です。

PHPフレームワークとしての検索トレンドはこんな感じ。

(2017年7月16日、8:00頃の結果)

期間:5年間

フレームワーク以外の検索結果も入ってしまうので 各FWごとに、小文字のphpをつけています f:id:UltraBirdTech:20170716202314p:plain

検索ワードの問題もあるけど、まぁ中間くらい?安定した人気ですね。 こうやってみると、Laravel最強説。

地域別にみるとこんな感じ。 f:id:UltraBirdTech:20170716202407p:plain

Symfonyは欧州で人気あるっぺぇ。 そして、圧倒的なLaravel人気・・・

Symfonyの基本機能

Symfony2のFWとしての基本的な機能は下記のようでした。

ルーティング

ymlやアノテーションで指定することで実装できます。

今回は参考書に従ってアノテーションで実装。

個人的には設定ファイル(yml)の方が好みだな。

アノテーションでやる場合はこんな感じ

 class ToppageController extends Controller
{
    /**
    * @Route("/")
    */
    public function indexAction(){     
        // なんかの処理... 
    }
}

DBとの接続

Doctrine勉強してね

Home — Doctrine Project

Doctrinは、PHPのORMです。 PHPでWebアプリケーションを開発するために作られたORMのようです。

どうしてもRubyActiveRecordと比較してしまう。

ActiveRecordと比較すると、あまりメソッド名が直感的ではないなと思ってしまった。 おそらくDoctrinの思想を理解できていないんだと思います。

Doctrineが開発された経緯とか、Symfonyに組み込まれた経緯とかは知りません。 後ほどの調査タスクで・・・

HTMLへのレンダリング

Twig勉強してね

Home - Twig - The flexible, fast, and secure PHP template engine

TwigはSymfonyの機能ではなく、独立して利用可能なテンプレートです。 確か、Symfony2からTwigに対応した認識。 ちなみに、Twig独自の関数と、Symfonyが拡張したTwig関数があるので、そこの分別は気を付けてください。

Twigが開発された経緯とか、Symfonyに組み込まれた経緯とかは知りま(以下略

使ってみた感想

フレームワークとしては、難なくWebアプリケーション開発できるなーという印象。

外部のコンポーネントを取り込んで開発するってのが多いなと思いました。

フレームワークは便利なコンポーネントを独自に取り込んで、使っていくみたいな形になってきているんですかね。

結局、DoctrineやTwigの勉強をそれぞれした方が理解深まるなー、という所感です。

今後の展望

Symfonyを利用して、MVCオブジェクト指向でどう書くのがベストなのかは探らなきゃいけないなと思っています。

あとは、ユニットテストの導入ですかね。

そして・・・「すべての道はDrupalに通ず」

まとめ

今回、開発合宿でSymfonyに触ってきました。

本当は、もっと成果物としてしっかりとしたものが上がればいいんだけど、毎回こんな新しい技術触って何ちゃらでした☆みたいなものにしちゃうんですよね。

PHP力はもう少し高めなければと思っております。

次は、もっとサービスインできるくらいの何か作ってみたいなー。

開発合宿は、ご飯美味しいし、温泉も入れるし、開発できる機材は整っているし、とても楽しいですね!

どーせ、何も予定がない休日に一日中開発しているのであれば、これからも積極的に参加していきたいです!!

おまけ

飲んだお酒。 開発合宿中に三本飲めました。 (お酒弱いのですが、酒入れながら開発は一回やってみたかったのです)

まぁ、千葉に来たし、せっかくなので・・・

www.kirin.co.jp

  • YEBISビール 350ml 缶

YEBISビール美味しいよね。

エイジゲート | サッポロビール

  • KIRIN本絞り 350ml 缶

レモン系が飲みたかった・・・

www.kirin.co.jp

次回はもっとガッツし飲みたいですね。(開発合宿の目的とは

f:id:UltraBirdTech:20170717104941j:plain

以上です。

4年目プログラマの Ruby Association Gold 合格体験記

はじめに

2017年5月にRuby Gold 合格しました。

結果は80 / 100 と、合格点が75点である中、なかなかギリギリのところでした。

Ruby Goldの合格体験記はSilverに比べて少ないイメージなので、私も残しておこうかなと思います。

なんで受けたの?

ほぼ、モチベーション的にはSilverと同じです。

一人のプログラマとして、なんでもいいから一つの言語としっかり向き合ってみたかったからです。

Ruby Gold までくれば、メタプログラミングの知識も必要だったので、より深くRubyを勉強できるかなと思ったので挑戦させていただきました。

勉強方法

公式教科書

gihyo.jp

私は古いのを持っていました。

Silverの時と同じく、試験範囲を把握するために利用。

この教科書だけでは、試験範囲の内容としては心許ないです。

添付ライブラリやメソッドチェインなどは、後述のパーフェクトRubyメタプログラミングRubyなどで、補填しました。

パーフェクト Ruby

gihyo.jp

Rubyistであれば、持っていて損はない一冊。 公式の教科書だけでは足りない深い部分の理解をしたいときはこっちで調べました。

メタプログラミングRuby

www.oreilly.co.jp

メソッドの継承の仕組みなどのRuby Goldの試験範囲を勉強するには最適の一冊。 公式の教科書やパーフェクトRubyにも継承に関することは書かれているのですが、この一冊で勉強した方がより実践的に学べます。

オブジェクト指向設計実践ガイド

gihyo.jp

Ruby Goldの資格勉強とは離れるのですが、Rubyの理解を深めるために購入。

初めてオブジェクト指向を本格的に学びました。

そもそもオブジェクト指向言語であるRubyなのに、オブジェクト指向を理解していない時点で負け。 Rubyのクラス定義やらが曖昧なままでは、太刀打ちできないということで勉強させていただきました。

問題集

Ruby技術者認定試験【Gold】模擬問題(1~10)|CTC教育サービス 研修/トレーニング

100点取れるまでひたすらやりました。

他の方の受験記

Google先生に、「Ruby Gold 合格」聞いてみて出てくるブログ記事を読み漁る作業。

勉強時間

勉強期間は1ヶ月くらいですかね。 受験日が5月末日だったので、GWは全てRuby の勉強に当てていました。

GW後は、朝(出社前)、会社の昼休みを利用して1日、2時間は勉強時間を確保しました。

個人的に試験のここがポイント!

継承チェーン

Ruby Goldはこの継承チェーンが6割くらいなので、ここをどれだけ極めるかが肝です。

extend()した時の挙動、extend()をフックするメソッドは何か?など。

メソッド 動き 前フック 後フック
include moduleをクラスの後の継承チェーンにMix-inする append_features()  included()
prepend moduleをクラスの前の継承チェーンにMix-inする prepend_features()  prepended()
extend オブジェクトの特異クラスにmoduleを取り込む extende_object()  extended()

super()の挙動

super()って、()のあるなしで挙動が変わるって知らんがな。

メソッド呼び出し(super・ブロック付き・yield) (Ruby 2.4.0)

class Foo
  def foo(arg='default')
    p arg
  end
end

class Bar < Foo
  def foo(arg)
    super(5)   # 5を引数にして呼び出す・・・(1)
    super(arg) # argを引数にして呼び出す・・・(2)
    super()    # 引数なしで呼び出す・・・・(3)
    super      # 3を引数にして呼び出す・・・(4)


    arg = 1
    super      # 1を引数にして呼び出す・・・(5)
    super()    # 引数なしで呼び出す・・・(6)

  end
end

Bar.new.foo(3)

実行結果

5     # (1)の出力結果
3     # (2)の出力結果
"default"  # (3)の出力結果
3     # (4)の出力結果
1     # (5)の出力結果
"default"    # (6)の出力結果

勉強するために工夫したこと

説明できるように!

他のRuby Gold受験者やRuby初心者に説明することを意識して自分の中に落とし込みました。

まとめ

Ruby Gold取得して、少し自信が持てるようになりました。

昔、会社の上司に「一個の言語に深く潜ってみろ!」と言われたのですが、その言葉を胸にひたすら言語を勉強してみる半年だったかなと思います。

今回のRuby Goldを取得するために勉強したRubyにおける継承チェーンやオブジェクト指向的な書き方。 じゃあ他の言語(JavaPHP)の時はどんな風に書くのかなと言ったところを考えながら、他の言語も勉強していこうと思いました!!

4年目プログラマの Ruby Association Silver 合格体験記

はじめに

2017年2月にRuby Silver 合格しました。

結果は84 / 100 と、まぁ合格だよね、という感じの合格点。 でも、合格は、合格!!!

他の記事と同じようなことしか書けず、何番煎じかわかりませんが・・・ メモ程度に残しておきます。

なんで受けたの?

一人のプログラマとして、なんでもいいから一つの言語としっかり向き合ってみたかったからです。

今年でプログラマ歴4年目となるのですが、あまり言語と深く接するということをしてこなかったので、諸々のタイミングを踏まえて挑戦してみました。

そもそも、Ruby SIlver は、2年前くらいに一度挑戦して落ちてましたし・・・(苦い思い出

勉強方法

公式教科書

gihyo.jp

私は古いのしか持っていなかったのですが、特に問題ありませんでした。

試験範囲の確認するのにはもってこい。

SIlverは7割くらい、ArrayやHashのメソッドのお話です。

ただ、サンプルコードには間違っている箇所もあるので注意してください。

章末問題も100点(うっかりミスは許容)取れるまで、ひたすら解きました。

なんでその回答になるのかの、理由をひねり出せれば問題ない。

パーフェクト Ruby

gihyo.jp

Rubyistであれば、持っていて損はない一冊。 公式の教科書だけでは足りない深い部分の理解をしたいときはこっちで調べました。

ミニツク

ミニツク - Rubyのe-ラーニング研修システム

ありがたいweb サービスでございます。

これのRuby silver対策部分をひたすら行いました。

問題集

http://www.ruby.or.jp/assets/images/ja/certification/examination/exam_prep_jp.pdf

こちらも100点取れるまでひたすらやりました。

他の方の受験記

Google先生に、「Ruby Silver 合格」聞いてみて出てくるブログ記事を読み漁る作業。

勉強時間

勉強を始めたのは試験日の、3週間前くらいからです。

朝(出社前)、会社の昼休みを利用して1日、2時間は勉強時間を確保しました。

普段からRubyは実務で触っているので、基本的なところは大丈夫な自信はありました。

試験に出てくるArrayやHashなどは普段使わないメソッドがあるので・・・

試験前の1週間はできるだけ定時に帰ることを心がけて、夜の勉強時間も1時間ほど確保しました。

個人的に試験のここがポイント!

破壊的、非破壊的

! がなくても破壊的なメソッドはいくつかあるので注意です。 arrayのarray#insertとか?

ref.xaio.jp

同じ動きをするメソッド

別名なのに同じ動きをするメソッドがあります。 arrayのslice[]が同じとかね

ref.xaio.jp

ref.xaio.jp

sliceメソッドは、メソッドの別名です。

もう、ややこしい。 Ruby に別名なのに同じ動きをするメソッドがある理由は下記のルビまの記事などを読んでもらえればいいんですかね。

Rubyist Magazine - map と collect、reduce と inject ―― 名前の違いに見る発想の違い

ファイルの内容を読み込むメソッドの挙動

読み込む対象 メソッド名 動作 EOF
IO read IOから内容を読み込む。長さが指定されていれば、その長さぶん読み込む。 長さが指定されていなければ空文字。指定されていればnil
IO.foreach 各行をブロックに渡して実行 nil
each_lines 各行をブロックに渡して実行 nil
readlines ファイルを全て読み込んで、その配列を返却する。 空配列
gets 一行ずつ読み込む nil
readline 一行ずつ読み込む EOFError
バイト each_byte IOオブジェクトから1バイトずつ取得する 何もしない
getbyte 一バイトずつ読み込む nil
readbyte 一バイトずつ読み込む EOFError
文字 each_char IOオブジェクトから1文字ずつ取得する 何もしない
getc 一文字ずつ読み込む nil
readchar 一文字ずつ読み込む EOFError

この微妙な差異がね・・・ なんとも。。。

get××系がnilを返却。

read××系がEOFError系を返却。

と覚えておけば良さそう・・・

クラス別のdeleteメソッド

delete()メソッドのクラス別の挙動

クラス 引数 返値 破壊的 別名
String 文字 元の文字列  非破壊的 なし
Array 削除した値  破壊的 なし
Hash key値 削除したkeyのvalue  破壊的 なし
File ファイルパス 1 or エラー  破壊的 unlink

こんなんばっかり・・・

他にもあったので、似通った部分は自分なりにまとめるのはオススメでございます。

勉強するために工夫したこと

復習できるように!

Ruby Goldの取得も視野に入れていたため、いつでも振り返られるようにまとめることを意識しました。 特にノートはオススメです。 ノートにまとめたり、ArrayやHashのメソッド一覧を作ってみたりしました。

情報交換

ちょうど近くにRuby SIlverを同じタイミングで受けた人がいたので情報交換とかしました。 まじ、GJ!!

まとめ

Ruby Silver受験して、普段業務では使わないようなメソッドに対する知識も増やすことができました。

業務で使うメソッドやRuby の機能って限られたものになりがちなので、知見を増やすという面では資格はもってこいですね。

まぁ、あと業務経験○年です、プラス資格持ってますならば、定量的に測れるスキルになってくるのかなーと思っております。

Mastodon会議3行ってきました

どーも。 ばぁどです。

4月から話題になっているMastodonのイベントがあったので参加してきました。

lab-kadokawa26.peatix.com

私個人的にもGW中に少しいじっていたのと、自分の行動範囲内でイベントが行われるということだったので急遽ですが参加してきました。

稚拙ですが、メモをまとめて記録として残しておきます。

また、マストドン会議3の実況トゥートのまとめをしている方もいらっしゃいます! (私のトゥートも高確率で混ざってます(恥))

【実況まとめ】マストドン会議3(1)イントロ ~ 鷲北賢&ぬるかるパート

はじめに

TwitterFacebookで変なことを書き込んでしまうと、予想外のところからバッシングがくる。 自分の意見と合わない意見あったら、無視してくれれば良いのにね。 「へー、そういう意見もあるんだー。ふーん。」みたいに流してくれれば良いのにね。

TwitterなどのSNSは様々な意見を持っている人が混在するようになってしまった。 (別に悪いことではないのですが・・・)

その副作用として、本当は気にしなくて良いことを気にしなくてはならなくなった。 本当はもっと自由なはずなのに、なぜか窮屈なんですね。

その窮屈さを払拭してくれるかもしれない、マストドン! 最初は、分散型になんの意味があるのか理解できなかったが、やっと掴みかけているところでございます。

第1部

これからのmstdn.jp

登壇者(順不同)

ぬるかるさん(マストドンインスタンス mstdn.jp 運営者 / 株式会社ドワンゴ

鷲北 賢さん(さくらインターネット研究所所長)

内容としては、mstdn.jpに関してでした。

mstdn.jpがどのようにサーバー管理されているか、運用監視されているかなどの、とても興味深いお話を聞けました。

当初、mstdn.jpは複数サーバーに手動sshして、git pull を行っていたらしい。

でもそれって面倒臭いよね、ってなってAnsiblecapistranoを使って管理の自動化をしていると言ったお話でした。

また、マストドンが最近マイナーアップデートしたらしく、DBの外部制約キーが影響でmigrateがうまくいかないらしい。 (その前にrake タスクを実行する必要がある)

鷲北さんはmstdn.jpの監視体制のお話。

監視ツールとしてはZabbixを使用していると言っていました。

実際にmstdn.jpのZabbixの監視画面も見せていただけて、とても興味深かったです。

第2部

トークセッション

登壇者(順不同)

まつもと ゆきひろさん(一般財団法人Rubyアソシエーション 理事長)

オイゲン・ロッコ (Eugen Rochko) 氏

ぬるかるさん(マストドンインスタンス mstdn.jp 運営者 / 株式会社ドワンゴ

なんと、豪華な登壇者なのだろうか・・・

主に下記のようなトークが行われていました。

マストドンはなんでRuby(Rails)で作ったのか?

  • 開発に必要なツールとして、Ruby on Railsプラグインが豊富だったから
  • オイゲンさん自身、PHPなどを触っていたがRails(Ruby)の方が便利なツールがあったから

マストドンを作った理由

  • Twitterでは満足できなかった(らしい
  • Twitterより良いものを自分の手で作りたかったから
  • 今のマストドンに関しては非常に満足

マストドンオープンソースにした理由

マストドンのアカウント管理の最善策とは?

  • ここら辺はぬるかるさんなどの運用系のお話
  • 今後のアカウントの管理手法としては、フォロワーを維持したままインスタンスを移れるようにするなど考えている(らしい

まつもと ゆきひろさんを一目見れたのは嬉しかったなー。 かれこれ、何年も触り続けているRubyの生みの親。 なんというか、感無量でした笑

オイゲンさん、寝起き(ドイツでは朝7:00頃)でしたので、すごいクレイジーな朝活だなと思った次第でございます。 登壇が終わったあとは二度寝したいとおっしゃっていました。

ちょっと、苦言すると少し準備不足だったかな・・・と。 トークセッションなら話すテーマくらいは用意しておかないと・・・ 最終的にはmatzさんがファシリをやるという、豪華な配役(?)になりました。

第3部

マストドンの管理方法

登壇者

清水 亮さん(株式会社UEI 代表取締役社長兼CEO)

いかにクソリプと戦うかというお話。 分散型である点と、ディープラーニングと絡めてクソリプを排除して行きましょうというお話(ざっくり

あと、マストドンの企業側の視点からのお話もしていただきました。。 個人的に一番印象に残ったというか、勉強させていただきました。

Twitter、LINEなどのSNSは流行らないとキャンペーンをする意味がない。 マストドンは流行らなくても良い。 サービスの顧客が使って入れば、マストドンだけで良い。 要は、MLやライングループなどと同じような感覚でマストドンという選択肢が出てくるんですかね。

FacebookTwitterは企業の顧客管理を搾取されていた + バーチャルな世界でキャンペーンしなければいけなかった。 なぜか自分が持っている顧客情報ではなく、SNS運営者にお金を払うことで不特定多数へのキャンペーンを強いれられていた。

マストドンは、自分でインスタンスを立ち上げて、コミュニティを作ることで顧客を再び取り戻せる可能性があるとのことでした。

インスタンスを運営している人座談会

登壇者

alarky さん(大阪丼管理人)

TOMOKI++/脇元寛之さん(ボカロドン運営/株式会社SGN代表取締役

松尾公也さん(グルドン運営チーム / backspace.fmポッドキャスター)

有名なマストドンインスタンスの運営者たちのお話です。 各インスタンスの特徴や、参加人数、トゥート数など。

もっと沢山のコアな内容、話す場を求めているコミュニティのインスタンスがあると面白いというのは本当に共感しました。 登壇者の脇元寛之さんもおっしゃっていましたが「再生エネルギーのインスタンス」とかね!! はい、ごもっともだと思います。

個人的には、特撮インスタンスでも立ち上げてみようかなと思いました。

名前は〇〇ドンとつける風習があるようなので、ガヴァドンあたりで行きましょうか。

ウルトラマンの登場怪獣 - Wikipedia

まとめ・感想

もっと色々なインスタンスができれば良いですね。

現状、そのためにはインフラスキルが必須になっている。 私もインスタンスを立てるのはできるけど、そのあとの運用とか、負荷がかかった時のサーバーメンテナンスとか考えると・・・ねぇ(苦笑)

この前初めて知ったのですが下記のようなサービスのマストドン版が求められているんだろうな。

pantheon.io

pantheonは、日本ではなく海外で展開されているサービスです。 基本的にクリックと簡単な情報を入力するだけでwordpressdrupal などのCMSが入ったサーバーを用意してくれて、サービスを展開できます。 実際めちゃくちゃ簡単でした。

クリックだけで、マストドンインスタンスを立ち上げて、面倒臭いところ(サーバーの運用)もよしなにやってくれて、良心的な値段で提供してくれるサービスが出来上がれば、もっと色々なインスタンスができて一気に熱も高まってくるんだろうなと思う次第でございます。 (あれ、これはビジネスチャンスなのでは・・・)

そんなこんなで、マストドン。 これからも色々な盛り上がりを続けてくれると面白そうですね。

私的には、今回のマストドン会議3の中で上がった技術ワードだいたい触れたことある、聞いたことあるっていうのは嬉しかったなー。 曲がりなりにもプログラマーとして、色々学ばせてもらっているなと実感できました。

これからも日々精進。頑張っていこうと思います!

Rails(Ruby)で書かれていると噂のMastodonをいじってみた

どーも。@UltraBirdTechです。

GWですね。大型連休ですね。 人によっては、9連休のようですが皆様いかがお過ごしでしょうか?

私はGW中は埼玉の実家に帰って、実家からほぼ一歩も出ないような、ヒキニート生活を送っております。 まぁ親孝行ということで、親に顔を見せに来たと思えば良いか。

ヒキニート生活中は、Rubyダラダラと勉強しています。 そんな中連休に入る直前に、会社の先輩から「MastodonというSNSRails(Ruby)で書かれている」という情報を貰っていたので、Rubyの勉強がてらいじってみました。

そもそもMastodonって?

MastodonオープンソースSNSです。 f:id:UltraBirdTech:20170504154353p:plain

自身が運営しているサーバーにMastodonを立ち上げることで、Mastodonを提供することができます。 この一つ一つの単位をインスタンスと言います。

サービス利用者は、利用したいインスタンスにアカウントを作成して、トゥートという形で自分の意見、言いたいことを世の中に発信できます。

既に日本国内でも趣味や用途(婚活、投資家など)によってインスタンスが作成されています。 Mastodonは、自分が興味のあるインスタンスにアカウントを作るのが理想のようです。

僕なら「特撮」とか「プログラマ」、「環境活動を行なっている若者」などのインスタンスのどれかにアカウントを作るのが正しいのですかねー。

Mastodonは、日本では2017年4月の中旬くらいからジワジワと話題になって来たSNSという認識。 サービスリリース自体は2016年10月頃にしていたらしいです。

やってみたこと

アカウントを作ってみる

インスタンスは、色々と記事にもなっていましたが、mstdn.jpでアカウント作成させていただきました。 f:id:UltraBirdTech:20170504155033p:plain

アカウントの作成は楽でした。 メールアドレスを入力して、「参加する」ボタンをクリックすると、メールが届きます。

メールの文面

ようこそ[メールアドレス]さん
mstdn.jpにアカウントが作成されました。
以下のリンクをクリックしてMastodonアカウントのメールアドレスを確認してください。
メールアドレスの確認
また、インスタンスの利用規約についてもご確認ください。
mstdn.jp チーム

[メールアドレスの確認]にリンクが貼られているので、そのリンクを押下したらログイン画面が出るので、ログインしたらMastodonに参加できます。 f:id:UltraBirdTech:20170504154906p:plain

国内最大級のインスタンスということなので、TLに流れてくるトゥートの内容も様々ですねー。 これが、特撮などのインスタンスだと、それに特化するTLになってくるんだと思います。

localhost(足元環境)で立ち上げてみる

GitHub にソースがコミットされているとのことなので、ソースを見てみようとGitHubを開いてみました。

そしたら、何やらVagrantfileがあるじゃないですか。

mastodon/Vagrantfile at master · tootsuite/mastodon · GitHub

DB定義とかも全部設定ファイルとしてコミットされていたんですよ。 なんか、git clone して vagrant up したら立ち上がりそうだったのでやってみました。

git clone

$ git clone https://github.com/tootsuite/mastodon.git
Cloning into 'mastodon'...
remote: Counting objects: 30283, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 30283 (delta 0), reused 0 (delta 0), pack-reused 30280
Receiving objects: 100% (30283/30283), 35.62 MiB | 3.50 MiB/s, done.
Resolving deltas: 100% (18514/18514), done.
Checking out files: 100% (4814/4814), done.

cd dir

$ cd mastodon/

vagrant up

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
==> default: have version '20161214.0.0'. The latest is version '20170422.0.0'. Run
==> default: `vagrant box update` to update.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
・
・
・
==> default: => Booting Puma
==> default: => Rails 5.0.2 application starting in development on http://0.0.0.0:3000
==> default: => Run `rails server -h` for more startup options
==> default: **************************************************
==> default: ⛔️ WARNING: Sidekiq testing API enabled, but this is not the test environment.  Your jobs will not go to Redis.
==> default: **************************************************

立ち上がった・・・・

印象としては、vagrant up が長かったなーというくらい。 ちょこちょこwarningなどは出ましたが、特に問題なく立ち上がってくれました。

localhost:3000でアクセスしてみると、Mastodonの初期画面が!! f:id:UltraBirdTech:20170504155117p:plain

初期管理者のユーザは下記でログインできます。

初期管理者:admin@mastodon.dev

パスワード:mastodonadmin

f:id:UltraBirdTech:20170504155048p:plain

さー、足元環境でログイン完了だ! f:id:UltraBirdTech:20170504155140p:plain

これでMastodonの開発もできる!(するとは言ってない)

なお、Dockerでも立ち上げることができるそうです。 インスタンス作成している人の記事を見ると、Dockerの方が多いですね。 Dockerも勉強してみたいが、とりあえず今ではないので保留。

ただ、こういうvagrant up するだけで開発環境が立ち上がる環境自体が本当に魅力的です。 もちろん、Dockerもそうなのですが、勉強素材として良いものを手に入れました。

あと、railsで書かれているので、rails コンソールでDBに入っているデータが見れるのもポイント高い! 実際に動いているサービスにどのようなデータが入るか見れるのたのしー!!

status(トゥートの内容)をrails コンソールで引っ張って見たところ

> Status.all
  Status Load (0.9ms)  SELECT "statuses".* FROM "statuses" ORDER BY id desc
=> [#<Status:0x00000006ee7018
  id: 2,
  uri: nil,
  account_id: 1,
  text: "statusに追加されていますか?",
  created_at: Tue, 02 May 2017 07:51:12 UTC +00:00,
  updated_at: Tue, 02 May 2017 07:51:12 UTC +00:00,
  in_reply_to_id: nil,
  reblog_of_id: nil,
  url: nil,
  sensitive: false,
  visibility: "public",
  in_reply_to_account_id: nil,
  application_id: 1,
  spoiler_text: "",
  reply: false,
  favourites_count: 0,
  reblogs_count: 0,
  language: "es">,
 #<Status:0x00000006ee6ed8
  id: 1,
  uri: nil,
  account_id: 1,
  text: "test",
  created_at: Mon, 01 May 2017 03:03:08 UTC +00:00,
  updated_at: Mon, 01 May 2017 03:03:08 UTC +00:00,
  in_reply_to_id: nil,
  reblog_of_id: nil,
  url: nil,
  sensitive: false,
  visibility: "public",
  in_reply_to_account_id: nil,
  application_id: 1,
  spoiler_text: "",
  reply: false,
  favourites_count: 0,
  reblogs_count: 0,
  language: "sv">]

Mastodonソースコードを読む

ちょっと読んでみました。 オブジェクト指向設計の本を読んでいたので勉強の参考ソースとしてもちょうどよかったです。

オブジェクト指向で書かれているようだったので、modelから触って見ました。 accountやuserというモデルが存在していて、各々が自身のステータスを変更するメソッド(振る舞い)を持っていました。

特にお気に入りは、follow_request.rb。

mastodon/follow_request.rb at master · tootsuite/mastodon · GitHub

メソッド数も少なく、一番わかりやすかったです。 フォローリクエストは、アカウントを非公開にしているアカウントに対してユーザが「あなたをフォローしたいです!許可してください!」と送るリクエストのことですかね。

このファイルを見ただけで、以下のことが容易に想像できる。

  • フォローリクエストしたら、このデータがDB上にが作成される
  • authorize!メソッド呼べばフォローを許可(メソッドの最後に ! が付いているのでおそらく元のオブジェクトの状態を変更する)
  • reject!されたら、フォローを許可しない

※挙動は未確認。

あとモデルを読み進めて、意外だったのはトゥートを管理しているモデル名(おそらくDB名)がstatusだったということ。 個人的には、tootのようなものを想像していたので、ちょっとびっくりしてしまいました。 でも、これってTwitterをインスパイアしているようです。 Twitterのつぶやきもstatusでした。 (・・・という情報も会社の先輩から教えてもらいました。ありがとうございますー☆)

なるほどー。 Twitterをイメージしながらソースコード潜ると、もっとソースを解読できそうですね!

まとめ

Mastodonは、インスタンスごとに特質を持たせることができるのが特徴のSNS。 みなさんも、好みのインスタンスを見つけて、ぜひトゥートしてみてください。

私はツイ廃Twitterをよく利用しているので、Twitterに似ているMastodonは非常に注目しております。

技術的な面で言うと、ソースコードは見やすいし、オブジェクト指向に則った書きっぷりしているし、開発環境を構築する勉強という面でもとても良い例だと思っています。 残りのGWも暇なので、引き続きソースコード読んでいこうと思います。

Drupal dev camp in TOKYO 行って来ました!!

Drupal dev camp in TOKYO 行って来ました!!

どーも。

UltraBirdTechです。

 

Drupal Camp行って来ました。

http://2017camp.drupaljapan.org/

振り返りとしてのアウトプットです。

 

Drupalって?

DrupalCMS(Contents Management System)です。

 

日本語版サイト

http://drupal.jp/

 

日本ではwordpressの方が有名ですかね。

 

PHPで書かれています。

フレームワークsymfonyが使われているそうです。

 

海外では有名なCMSです。

私が知っている限りではアメリカ

 

アメリカでは一昔前から既にDrupalを用いたWebページが作成されています。

ホワイトハウスWebページがDrupalで作られていることは少し調べれば出てくる有名なお話です。

このことからもセキュリティに強いと言えるでしょう。

 

私もつい先日、開発合宿でDrupalをお題にして遊んで来ました。

 

Drupal dev camp 2017

というわけで、参加して来ました。

日本での開催は2回目。

海外からもたくさんのスピーカーが参加していました。

 

セッションが英語の時は疲れた。

自分の英語力に絶望しながら頑張りました。

英語はせめて、リスニングとリーディングはもっと頑張ろう・・・

 

 

政府でのWEB改革の取り組みと政府CIPボータル

今回のDrupal Campで一番聞きたいなと思っていたセッション。

 

えーと、、、このセッションの結論としては

Drupalをやっていれば政府、地方自治体のWebページ作成案件を受注できますよ」と受け取りました(曲解)

 

ただ、間違いなく日本でもDrupalの流れは来ています。

 

2020年までに政府が持っている各省庁、地方自治体が持っている数千のWebページのリニューアルを行なう計画がある」とのこと。

 

ガイドラインはここ。

https://cio.go.jp/guides

 

各組織に参考にしてもらいたいサンプルサイトとして作成されているのが下記サイト。

https://cio.go.jp/

 

サンプルサイトはDrupalで作成されています。

だから、リニューアルする側もDrupalを使うっていう流れになりそうですね。

国がこういう流れなだから、今後Drupalは日本国内で広がっていきそうな感じがしますね。

 

ちなみになんで今回のCIOサイトをDrupalで作るというお話になったかというと、

一昔前にアメリカ視察行ったときに、アメリカ政府がDrupalを使っていたかららしい。

 

その頃、日本はホームページビルダー何にしようかなという時代。

wordpressすらまだ浸透していなかった。

 

なんか大学時代に聞いたことがあるけど、

数年後の日本を見たかったら今のアメリカを見ろって教えてもらったの思い出した。

 

実際にアメリカ政府がDrupalを使用してWebページを作ってから数年後日本でも同じ流れになってきている。

あー、やっぱりDrupalなんですね。

 

まとめ

他のセッションも面白かったですよ。

 

イスラエルから来た方のセッション面白かったな。

イスラエルは個人的に思い入れのある国(学生時代に苦い失敗)なので・・・

 

PHPオブジェクト指向に関するお話もあったり、Javascriptのお話もあった。

僕の専門分野のお話でもあるので、納得しながら聞くことができました。

 

ただ、Drupalをそこまで触っている訳ではないから、理解が追いつかない・・・

 

あと、英語ですね。英語。

英語の技術セッションを聞き取って理解できるくらいには英語力鍛える。

英語は切り札。

 

引き続き、Drupalに関してはアンテナ貼っておきたいと思います。

 

 

PHPカンファレンス2016参加してきました!

PHPカンファレンス2016参加してきました!

はじめに

はじめまして。

地味に初投稿のUltraBirdTechと申します。

 

本日、2016年11月3日(木)に開催されたPHPカンファレンス2016に参加してきました。

phpcon.php.gr.jp

 

開催中にtwitterhttps://twitter.com/ultrabirdtech )で呟いたり、社内で展開する内容を考えていたりしたのですが、やっぱりブログとかまとめた形でアウトプットしたいなーという欲に駆られて筆をとった(PCを開いた)次第です。

参加したセッション

参加したセッションは下記4つ。

  1. PHP初心者セッション
  2. PHP7で堅牢なコードを書く
  3. 安全なPHPアプリケーションを作り方2016(途中退場)
  4.  未来のwebに欠かせないREST APIApache Soler+Drupalで実装しよう

自分の中でベストな選択をしたセッションだと思っています。

 

PHP初心者セッション

最初にセレクトしたセッション。

 

現在、私は社会人として、プログラマー3年目です。

PHP歴は2年前に1ヶ月ほど触っただけでした。

3年目だろうが、10年目だろうが数年前にちょこっと触っただけのやつがバリバリPHP書けますなんて顔できないので、参加させていただきました。

 

内容はPHPを勉強し直そうと考えていた、今の私にとって、とてもありがたい内容でした。

PHPの歴史、PHPは何の略?など、本当に「初めてのPHP」といった感じの内容。

あまりにもPHPに触らずいたため、;(セミコロン)が必要だという事ですら私にとって再発見でした笑

 

PHP7で堅牢なコードを書く

続いては、私も何度か記事でお見かけした事があるt_wadaさんの発表。

内容はPHPに限らず、他の言語でも当てはまる素晴らしい内容でした。

堅牢なプログラミングをするには、「予防的なプログラミング」、「攻撃的なプログラミング」、「契約プログラミング」という手法があるというお話。

堅牢なプログラムは、テストコードでガチガチに固めればいいと思っていたのですが、そう言う訳でもなく他にも作り方が色々あると言うことを教わりました。

 

攻撃的なプログラミングは、1年目の頃の上司に「攻めのプログラムをしろ!」と言われていたのですが、やっとその糸口が掴めた気がします(その時の上司が同じ意味で言っているかは、もう分かりませんが・・・)

 

以下メモ書き

予防的なプログラミング

結論:「予防に勝る防御なし」

  • 何かが起こってから直すのではなく、そもそも間違えないようにする。
  • 防御的プログラミング、「そうなるはず」だと決めつけないこと。
  • 問題発生を事前に防ごうというコーディングスタイル。
  • 可読性が高いコード、読みやすい書き方。
  • 良識ある実践の積み重ね。
  • 根本から断つ!
  • できていいことだけをできるようにする。
攻撃的プログラミング

結論:「fail fastが原則」

  • 何か起きた時は落としに行く。実行を停止に行く。

  • コード内で「ありえない」と思われる何かが発生した場合、その時点でプログラムはもはや実行可能なものとはなっていない。

  • 障害を抱えて中途半端に動くよりも、死んだプログラムの方がダメージは少ない。

  • プログラムは正当性と、堅牢性という考え方がある

契約プログラミング

結論:「バグと例外を区別、失敗にはバグと例外がある。バグには俺のバグとお前のバグがある。」

  • 誰の責務かをはっきりさせる契約による設計。

  • 契約による設計とは、プログラムの正しさを保証するための簡潔かつパワフルな技法

  • 要求されたこと以上のこともそれ以下のことも行わない

  • そもそも間違わない設定をする。

  • バグと例外を区別し、さらに誰の責任も見分けられるようにする

安全なPHPアプリケーションの作り方

今回の一番の目的であったセッションです。

ただ・・・他のセッションにも興味があったのでそちらに心変わりしてしまったのは内緒。

体系的に学ぶ 安全なWebアプリケーションの作り方」は私も読ませていただいております。

内容も本に書かれている発展系と言う形で、実際に脆弱性を疲れて起きた事故を例に挙げて、一つ一つ丁寧にまとめてくださっていました。

40分ほど聞いて、他のセッションへ移動しました。

申し訳ないです。。。

未来のwebに欠かせないREST APIApache Soler+Drupalで実装しよう

Drupalが凄い!

≡ Drupal Japan ≡ | Drupal 日本サイト

以上!

 

・・・嘘です。

でも、個人的な感想は本当その一言に尽きます。

 

2年ほど前からでしょうか。

知り合いにDrupalが凄い、これからの時代はDrupalだと洗脳され続けて早2年・・・

やっと私も技術的にある程度の余裕が生まれてきて、着手しようとしている技術です。

むしろ、私がPHPを再び勉強しようとしている理由でもあるDrupal

今回のセッションの中で唯一Drupalという単語があったセッションだったので参加させていただきました。

 

まずは「これからの時代はREST APIだよ」というお話。

webアプリケーション、連携サービス、iOSandroidアプリケーション、IoT機器など様々なコンテンツが生まれている時代に、URL打っただけで値を返却してくれるREST APIは普及しますよねっていうお話。

REST APIをサーバに乗っけて用意しておくだけで、あとは呼び出し元で勝手に情報取得して各々処理をしてもらえばいい。

確かに、これからの時代重要視されてきそうな技術だなと思いました。

 

そして、登場するDrupal

もうそこからは、Drupalのことしか頭に入ってこなかったです(恥

ボタン、ぽちぽちだけでGETやら、PATCHやらのAPIの呼び出しができてしまって何が起きていたのかさっぱり・・・

少しでもDrupalに関して何ができるCMSなのかということを掴みに行ったのですが、結果何でもできすぎて何ができるのかわからないという異常な優秀ぶり。

もっと本腰入れて勉強しなければと思わせてくれたセッションでした。

 

まとめ

今回、PHPカンファレンス2016に参加して感じたことは、「技術系のイベントって臆せず飛び込んでみていいものなんですね」ということですね。

いやー、色々ありまして社外の技術勉強会やカンファレンスに参加するの3年目にして初めてなんですよ(アハハ

サボってたわけじゃないし、興味がなかったというか、誰も誘ってくれなかったというか・・・

とても楽しかったです!

また、勉強会参加させていただきます!

 

今度はRubyのカンファレンスとか行ってみたいです。