ばぁど・うぉっちんぐ

セキュリティに強いWeb屋。自由と春を求めて羽ばたく渡り鳥。

このブログはGoogle Analyticsを利用しています

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のカンファレンスとか行ってみたいです。