Toro_Unit

  • 2016年の振り返り。

    2016年の振り返り。

    大晦日なので今年1年の振り返りでも。

    なんだかずーっと WordCamp や WordBench してた気がします。

    フリーランスになりました

    フリーランスとして活動し始めました。半ば勢いでフリーランスになってみたところもあるのですが、なんだかんだ1年暮らせました。来年も細々と暮らしていけたらと思います。

    WordCamp Kansai 2016 / Tokyo 2016

    今更ですが、初めて WordCamp のスタッフをやらせてもらいました。

    特に Kansai のほうは、昨年の12月末から始まってセッションチームとしてその企画をやったりハードではありましたが、いろいろとつながりが深まったり良い機会だったと思います。こういう機会があることで、いろいろいい刺激になりました。

    また機会があればなんかやります。

    WordBench 長野 のリスタート

    WordBench 長野をリスタートできました。今年の WordBench 長野の活動のまとめという記事を書いたのでそちらに長々と。

    今年の WordBench 長野の活動のまとめ

    新年も 1/21にやるので、よろしくお願いします！

    県外の WordBench / WordBash /  WordWine

    WordBench 山梨で LT やらせてもらったり、WordBench 京都でキレ芸認定されたりしました。

    そのほか、WordBash Kyoto や、WordBash@JUSO でいろいろ飲んで喋ったりしました。

    WordWine では僕だけお酒も飲めず、セッションだけして来たりいろいろと切ない思いを味わいました。

    WordPress 以外のイベントでの登壇

    WP-D Week や 秋のJavaScript祭 in mixi にお誘い頂いて喋らせて頂きました。

    WP-D Week で CSS の話をしました。そして CSS 設計と部屋の掃除について。

    JavaScript 祭りでキレてきました。#jsfes

    WordPress 以外のこういった会にも来年は積極的に出て行きたいなと思います。

    WordPress のテーマを作った

    WordPressのテーマを作ったので公開しました。

    WordPress とフロントエンドが得意とか言っておいてテーマを作ってないっていうのはなんだかなと思っていたので、作る作る詐欺でしたがようやく重い腰を上げました。

    ここ最近カスタムヘッダーにも対応させたり、いろいろ機能追加してみたので、遊んでみてください。

    Vanilla – Vanilla is the simple theme for blogging. And for single column modern websites.

    Basis にプルリクエストを送りまくった。

    https://2inc.org/blog/2016/02/29/5181/

    モンキーレンチのキタジマさんが作ってる CSS フレームワークの Basis にいろいろとプルリクエストを送りつけました。なんか気がつけばめちゃくちゃ進化してますが。

    ソースコードを公開していることでこういうコミュニケーションがとれるんだなと改めて気付かされました。

    VCCW 3.0 Release !!!

    VCCW の 3.0 の開発をいろいろとお手伝いさせて頂きました。

    VCCW 3.0.0 beta 1 がリリースされました。

    自分の普段使いしているモノを自分の手で変えていけるのは面白いなとは思いました。

    Serverspec にプルリクエストを送ったのもなかなか楽しかったです。もう少し Ruby 力も高めていかねば。

    あ、放置してるブランチがあるのでこれもプルリクエストせねば。

    WordPress 4.7 コア貢献者

    WordPress 4.7 でまたコア貢献者になりました。自分のプラグインをWordPress 4.7 のベータ版でテストしていたところ、バグを見つけたという経緯がありました。テストをすること、それにかかるコストを自動化などで下げることの重要性に改めて気付きました。

    まとめと来年の抱負

    今年はフリーランス1年目でしたが、仕事よりもコミュニティ活動に軸足を置いてやってきた気がします。それでもなんとか1年過ごせるもんですね。

    来年はそういった活動やオープンソースな活動と、仕事との距離をもう少し縮めていけるといいなと思います。長野県の他の IT コミュニティにも来年はもう少し出没できるようになりたい。

    海外のイベントにも行ってみたりしたいので、来年はもう少し仕事周りのことをちゃんとしないとなと思います。もうすぐ30才ですし。

    というわけでお仕事お待ちしてますー。

  • 今年の WordBench 長野の活動のまとめ

    今年の WordBench 長野の活動のまとめ

    なぜかGTOのドラマ（反町隆史の奴）を見ながらこれ書いてます。

    WordPress Advent Calendar 2016 ということで、昨日の川井さんの記事に引き続き、23日目の記事になります。というわけで、今年のWordBench 長野の活動の総まとめをしようと思います。

    WordBench 長野にも藩ができました

    昨年まで WordBench 長野で勉強会を開催しようとする際に毎回問題になっていたことなんですが、長野県めちゃくちゃ広いんですよね。

    昔からモデレーターをして頂いているファーストエレメントの宮澤さんが住んでる飯田市と、僕の住んでる松本市ってだいたい 100km くらいの距離があるんです。ついでに言うと県庁所在地の長野市と松本市の間で 80km くらい。おまけに昨年 WordBench 山梨が立ち上がったワケなんですが、正直飯田より甲府のほうが電車のアクセスとか良いんですよね。

    てなわけで、毎回毎回長野県と銘打ってやるってのがそもそも大変なんじゃ無いかということに気付いたわけです。じゃぁ WordBench 松本 とか立ち上げるのか？となるわけですが、WordBench 長野市 とかできたらスッゴい面倒くさい名前になるなぁと。長野（県）がすでにあるのに。

    かと言って、北信・中信・東信・南信（福島県で言うところの浜通り・中通り・会津地方、群馬で言うところの中毛・西毛・北毛・東毛みたいな奴）って分け方するのも県外の人からはどこそれってなるわけで。

    そんな折に、去年のアドベントカレンダーでコスギスさんがこんな記事とを書いてました。

    https://kosgis.com/news/wordpress-advent-calendar-2015/

    「藩」。

    これだ！ってなりましたよね。

    え？解りづらい？大河ドラマ見ましょう。ついこないだまで真田丸やってましたし。

    というわけで、各藩ごとの活動がスタートしました。

    松本藩の活動。

    月に1度ペースくらいで、もくもく勉強会を開催しました。なんとか今月までで11回開催できました。

    ちゃんとした勉強会というよりは、とにかく月に1回でもWordPressについて話す場所とかがあると良いのかなということで続けることを目標にゆるーくやったのが良かったのか、なんだかんだ続けることができました。

    ゴールは長野県内のWordPressコミュニティの活性化みたいなところにあるので、散発的にちょっと大きな勉強会をやるより小まめに集まったりするような場があるのが重要なのかなと実感しました。

    飯田藩の活動。

    飯田藩のほうでももくもく会が今年3回ほど行われたようです。最近は、コワーキングスペース とよテラスさんという泊まれるコワーキングという場所が豊岡村にできたらしく、そこでやっていたりするようです。

    来年は開発合宿とか開催出来たら良いなと思っています。

    WordBench 長野全体としての活動

    WordBench 長野 Vol.5 を10月8日に開催しました。もくもく勉強会に参加していた人に声をかけてスピーカーをやってもらったり、運営を手伝ってもらったり、以前のWordBench 長野とはまた毛色の違う雰囲気でできたのは面白かったです。

    僕以外のスピーカーの2名がエンジニアではなく、しかも1名はブロガーというのは、ちょっと今まで無かったことかなと。エンジニア以外の目線って言うのは結構興味深かったですし、いろいろ参考になりました。

    WordBench 長野のこれから

    もくもく勉強会などは定期的にこれからも行っていくつもりですし、いわゆる普通の勉強会みたいなのももう少しペースを増やしてやれたら楽しいのかなと思います。コントリビューターウィークエンドとかもやりたいなとも。

    藩とかも増えたら良いなーと思うのでそちらにお住まいの方はぜひ。お手伝いできることがあれば何なりとご相談下さいませませ。

    というわけで、2017年1月21日（土）に「WordBench Nagano vol.6 “WBNagano Special !”（仮） 」と題して松本で勉強会を開催します！！！内容は絶賛調整中ですが、県外の方もスピーカーとして何人かお呼びする予定です。北の方から西の方まで・・・。関係者のみなさま、全然連絡して無くてほんとすみません。

    そんなわけで皆様ぜひ今のうちから予定を空けておいて頂けると幸いです。

    県外の方はスノーボードとか担いで来れば良いんじゃ無いかと思います。もしくは、国宝松本城 氷彫フェスティバル2017とか見に来て天守閣に登ってそばでも食って帰れば良いんじゃ無いでしょうか？

    ではまた、どこかの WordCamp か WordBench か WordWine か WordBash あたりでお会いしましょう。（飲んでばっかりじゃねーか）

     

  • WordPress テーマ制作のワークフロー考察

    https://h2ham.net/wordpress-coding-flow-02

    なんかハムさんと会うたびにこの話をしている気がします。とろゆにです。というわけで便乗エントリーします。

    基本的にはいきなりテーマを作り始める派でした。既存のテーマをベースにすると言うことはほとんどやってきませんでした。ですが今年1年を振り返ってみると案件によってまちまちで、WordPress のスターターテーマ _s をベースにした開発もやりましたし、 HTMLを作成してから WordPress というフローもありました。それを踏まえてそれぞれに思うことをつらつらと。まぁ思うところや結論はハムさんとだいたい一緒ですが、プラスアルファということで。

    いきなりテーマを作る？ or 静的HTML作る ？

    いきなりテーマを作る場合

    僕の WordPress テーマ制作のワークフロー ( 仕事編 ) – Habakiri でもキタジマさんが言っていることですが、静的 HTML と WordPress テーマのテンプレートが同じようなコードになります。それならば最初から WordPress テーマを作った方が WordPress と矛盾したモノを作りづらくなる、ソースコードの管理が煩雑にならないというのは大きなメリットです。

    テーマユニットテストを突っ込んだ状態の WordPress を用意してそこからスクラッチで書いていくというのが僕の基本的なフローです。基本的には ビジュアルエディタで完結できるような作りを目指して実装していくという格好です。自動挿入される p タグや、ビジュアルエディタで消えてしまうHTMLの書き方などもあるので、そこら辺への対応を最初の段階でケアできるのは楽だったりします。

    静的HTMLを作った方が良さそうな場合

    運用する人があまり固定ページを編集することが想定されていない or HTML や CSS を固定ページごとに書くような運用を想定しているケース等は静的HTMLを作った方が良いのかなと思いました。HTMLのサイトがあってそこにニュースなどの一部コンテンツのみ更新したいという要件ですかね。

    そもそもそんなモノを WordPress の固定ページになぜ載せるのかというのはあるのですが、サイト内検索、お問い合わせフォーム等、WordPress の一部機能を使いたいなど理由は様々。ただその場合は WordPress を無理矢理使っている感も否めないなというのもあって悩みどころです。

    「WordPress のテーマの実装に入ってからの手戻りとかがあった場合どうするの？」ってWCT2016のセッションのときに聞いたんですが、「そんな手戻り無い」って言われたのは結構大きな衝撃でした。ワークフロー次第だとは思いますが、HTMLをちゃんと作りきってしまえばそんなモノなのかもしれないです。

    比較して思うこと

    結論としてはどっちも有るなぁと言う感じです。「WordPress のテーマを作ること」と「デザインをコーディングすること」のどちらの比重が高いのかで最適なやり方は違うのかなと思いました。特にテーマとしての運用性よりもデザインの再現が重視されるような場合は、HTML作った方が良いのかなとも。

    また普通に静的なHTMLとして作成して、サイト内検索は Google のカスタム検索などで実現するというほうが有用なケースも多々ありそうです。

    既存のテーマをベースしたテーマ作成

    • とりあえず、最初からある程度の機能がそろってる。Jetpackの無限スクロールなどもサクッと対応できた。（_sの場合）
    • ベースにするテーマそのものへの理解が必要。（主に独自のテンプレートタグとはき出すHTMLへの理解）

    というのがやってみて感じたことです。ブログなどががっつりメインコンテンツになるケースなどは _s 等をベースにすると割と便利な気がしました。

    ただ、ベースにする以上はあまりPHPやHTML部分に関しては弄りたくないなというのがありました。というよりそこを弄りまくるならまっさらな状態から作った方が楽というか、ベースにするテーマに対する学習コストが無駄になるなという感じです。テーマごとにカスタマイズの流儀みたいなモノもだいぶ違うので基本的に HTML の構造への編集は最小限に抑えたいなという印象です。この学習コストというのが結構馬鹿にならないとは思っています。

    そうなっていくと結構CSS力などが問われる場面も多かったような記憶があります。テーマには当然リセットやHTMLタグに対するベースのスタイルなども含まれているのでそこら辺をちゃんと踏まえないといけない部分は多い気がします。そういう意味では habakiri や lightning 等は Bootstrap ベースなのでそこら辺の知見が役に立ちやすいのかなと。

    ハムさんの疑問への解答

    Web上の投稿エディタでマークアップを入れなければ再現できないような場合…みなさんどうしています？

    僕はショートコードを作成して対処することが比較的多いです。Shortcake を使うとビジュアルエディタへの対応もそこそこ簡単なのでそれが一番スムーズなのかなと思っています。

    functions.phpでできることでもプラグインだけでできることはプラグイン優先で構築するべきかどうか

    functions.php できることというよりは functions.php でやって良いことかどうかは基準です。自分で書く場合もテーマに乗せるべきモノはそっちに書きますが、カスタム投稿タイプやショートコード、アクセス解析のコードなど、テーマが変わっても機能するべきところはテーマでは無くプラグインで実装します。

    ここら辺は、WordCamp Tokyo 2016 で Mignon Style さんがお話しされていた、「ノンプログラマーのためのWordPressテーマ作成ステップアップ術」が詳しいです。

    サイト用のプラグインを作ったり、mu-plugins にそのサイト用のコードを置いておくのが多いです。3行とかのコードでも別々のプラグインにしたりとかもやったりします。

    ただ、全ての機能を自分で作るなんて言うことは無く、公式ディレクトリにあるプラグインで済むモノは積極的に利用しています。自分で作ったからといって、それが積極的にメンテナンスされるという保証も無いですし。

    プラグインの選定基準は機能が要求に合っているかどうかは当然ですが、作者の人が積極的にメンテナンスやサポートをしているかどうかを割と重視して選んでます。コミットメントがあまり活発でないものはあまり使わないですね。

    またテストとかがないものや、あまりにもコードが読みづらいモノは避けたいとも。バグを踏んだり足りない機能があったらそれはプルリクエストなりパッチを送ろうぜ！と思っているので、それがやりづらいプロダクトは避けたいなという感じです。

    さいごに

    去年のハムさんの記事を読んで便乗エントリーをしようと思っていたら1年経ってしまいました。WCT2015で初めてハムさんとお会いしてからと言うもの、毎度毎度この話をしてる気がします。（主に懇親会で飲みながら延々と）

    https://h2ham.net/wordpress-coding-flow

    仕事の進め方、チーム、仕様など様々な理由で最適解は違うなぁというのがこの1年の僕の感想です。ただそれによって設計や求められるスキルも変わってくるのでどう対応していこうかなというのは悩みどころです。REST API も 4.7 で本体にマージされたので、ここら辺の話はますます変わっていくのかなというところです。そうはいってもテーマをいきなり作る派であることは変わらないので、またハムさんとお酒を飲んだときにでも決着を付けようと思っていますのでよろしくお願いします！

  • WordPress 4.7 に更新したときに管理画面が突然英語になってしまったら

    注: WordPress 5.0 に 更新した際に、一部環境で管理画面の翻訳がロードされない不具合があるようです。それについては、WordPress 5.0にしたらGutenberg（グーテンベルク）の一部が翻訳されない現象と対策 – More Publishing をご覧下さい。

     また、5.0.1 で修正される見込みです。#45528 (load_script_textdomain() doesn’t load translations when WP installed in a subdirectory with custom content dir) – WordPress Trac

    https://susu.mu/archives/3268

    追記終わり

    WordPress 4.7 がついにリリースされました！詳しい変更内容は、Version 4.7 – WordPress Codex 日本語版 を読んで頂ければと思います。

    今回の変更の一つに、ユーザー管理用言語およびロケールのスイッチ というものがあります。これの初期値がうまく設定されていないのか、WordPress 4.7 にアップデートした際に突然管理画面が英語になるという問題が起きました。僕の手元だけっぽいですが。

    とりあえずそうなってしまった場合は、管理画面の 「Users」->「Profile」 URLで言うと、/wp-admin/profile.php 、マルチサイトの場合は、wp-admin/network/profile.php で自分の言語を変更出来ます。

    Language という項目があるので、ここを日本語にセットしてあげれば管理画面が日本語になります。

    複数のユーザーがいる場合は、各ユーザーのプロフィールページにて、「サイトデフォルト」もしくは、「日本語」に設定してあげて下さい。

  • Vue + Vuex を使ってみた感想と、Redux との比較

    Vue + Vuex を使ってみた感想と、Redux との比較

    いいにくの日ですね。肉食べたいです。

    React + Redux にはよくお世話になっている昨今なのですが、React 以外も扱いたいなと思ったこと、そもそも Flux に対する理解が浅いんじゃ無いか？ということで、Vue.js + Vuex をちょっと勉強してみました。

    つくったもの：https://github.com/torounit/vuex-todo

    ここら辺をいろいろ参考にしました。

    Redux と Vuex の違い。Reducer と Mutation の違い。

    flow

    両方とも Flux パターンであるため、基本的な考え方は変わりません。ただ、Redux で Reducer が担って役割が、Mutation というモノが処理することになります。

    Redux では ActionType に応じて Reducer が State を変更という流れですが、Vuex の場合は Action 側から MutationType を指定して値を投げるという流れになります。

    複数の State の変更が同時に変化するような場合だと、Action から 複数の Mutation をそれぞれ呼び出すということになります。Redux だと、ある Action に対して複数の Reducer が紐付くという格好になるので、ここら辺の考え方が逆転しています。

    Vuexのドキュメントを参照すると結構解りやすいです。 Actions · GitBook

    actions: {
  checkout ({ commit, state }, products) {
    // save the items currently in the cart
    const savedCartItems = [...state.cart.added]
    // send out checkout request, and optimistically
    // clear the cart
    commit(types.CHECKOUT_REQUEST)
    // the shop API accepts a success callback and a failure callback
    shop.buyProducts(
      products,
      // handle success
      () => commit(types.CHECKOUT_SUCCESS),
      // handle failure
      () => commit(types.CHECKOUT_FAILURE, savedCartItems)
    )
  }
}

    一つの Action がどういった変更を起こすのか等が局所的になるので、結構解りやすい気がします。

    また、Mutation に渡される state ですが、単純に、現在の State オブジェクトそのものです。なので当然参照渡しです。これを直接弄ります。

    mutations: {
  increment (state, n) {
    state.count += n
  }
}

    テストの書きやすさ等には結構影響してきそうです。

    Vue.js の デバッガーが強力

    Chrome の拡張機能で Vue.js devtools がかなり強力でした。

    Vuex にも対応していて、過去の State の状態に戻したりなどシンプルながら必要な機能がそろっている感じです。GIF アニメを撮ったので、そちらをどうぞ。
    vue-debugger

     

    感想

    正直、Flux への理解が浅いまま Redux を触っていたので、いろいろと Vuex を触る上で逆に苦労したりしましたが、なんとなく Flux ってこういうモノかというのがつかめてきた気がします。

    最初は、Riot.js + RiotControl をやってみようと思ったのですが、RiotControl のソースコードがめちゃくちゃシンプル（20行）で、逆にどうして良いか解らなかったんですが、さっき改めて読んでみたら解った気になってきたのでこっちでも遊んで見ようと思います。

    Vue.js 自体は、ドキュメントが整備されていてローカライズもされているので割と取っつきやすいですし、デザイナーさんとかと組んだときとかに結構便利そうな気がしました。特にCSS周りは React だとお世辞にも良いとは言いがたい状況なので、なかなか良い感じです。また、公式のデバッグツールや vue-cli 等のツールがそろってるのも結構便利ですね。

    やっぱり自分で手を動かしていろいろ書いていくのは学びがあって良いですね。

  • VCCW 3.0.0 beta 1 がリリースされました。

    VCCW 3.0.0 beta 1 がリリースされました。

    VCCW 3.0.0 のベータ版がリリースされました。僕もいろいろプルリクエストを送ったりしたので触ってみてもらえると嬉しいです。

    • CentOSからUbuntuに変更。
    • ChefからAnsibleに変更

    等を行いました。VCCWのC2つが消えてしまったのでこのままVCCWと呼び続けて良いのかは疑問ある感じですね。かなり大規模な変更を行いました。起動も速くなったりしました。

    でも使い勝手は基本的に今まで通りのはずです。

    大規模な変更するために役に立ったこと

    OSや構成管理ツールが大きく変わったわけですが、使い勝手がほぼ変わらないままというのはなかなかすごいことです。そのときにめちゃめちゃ威力を発揮したのがServerspecです。

    Serverspec

    serverspec

    サーバーの構成や設定ををテスト出来るツールです。詳しい説明は、「Serverspec」を使ってサーバー環境を自動テストしよう – さくらのナレッジ 等を参照してください。

    VCCWにはServerspecが導入されていたので、基本的にはこのテストが通ればOK!ということでかなり思い切った変更が出来ました。テストって本当に偉大です。

    そしてVCCWの作業中にServerspecにもプルリクエストを送ったらマージされました。めちゃくちゃ嬉しいです。こうやってRuby力も徐々に鍛えられていくのですね。

    それにしても「オープンソースはワークフロー」とはよくいったものです。

     

    というわけで、新しいVCCWをお楽しみ下さいませ。

  • JavaScript 祭りでキレてきました。#jsfes

    JavaScript 祭りでキレてきました。#jsfes

    https://twitter.com/todays_mitsui/status/787198459862364160

    https://twitter.com/motchi0214/status/787197871749668864

    https://twitter.com/todays_mitsui/status/787201187472736256

    どうしてこうなった。。。

    どうも。先日開催されました、秋のJavaScript祭　in mixi 〜秋のJavaScript収穫祭〜 にて、「『ホームページ屋さん』とJavaScriptの未来。」というセッションをさせて頂きました。動画も公開されるようなのでそちらもどうぞ。

    わりとゆったり聞いてもらおうかなと思ってました。本当です。

    初対面の方もたくさん居たのですが、その人たちからもキレてると言われていたのでそうなんでしょう。緊張って恐ろしいです。

    しゃべり出すまでは全然普通だったんですけどね。カメラを意識してしまったせいでしょうか。それとも普段スベるところで若干笑って頂いて調子に乗ってしまったのでしょうか。そもそも1時間前に現地に到着し、オシャレな喫茶店でコーヒーを飲んでから会場に向かうなど、普段の僕が絶対やらないようなことしてたあたりから何かが狂っていた気がします。

    まぁ、結局キレ芸キレ芸って煽りまくったあげくに自分でキレ芸した岡本君が全部悪いと思います。

    普段からキレてる人だとか、カンニング竹山みたいな人って思われるのはさすがにどうかなと思ったので、WordCamp Kansai 2016 で登壇させて頂いたときの動画がありますので、ご参照頂ければと思います。

     

    当日できなかった写経のはなしとか。

    やっぱりTodoアプリなどの写経をしたりするのは一番手軽に出来ることかなとは思います。

    実際に手を動かして書いてみるって大事で、思わぬところで躓いたりするもんです。

    そして、とりあえず動くようになったら、ちょっとした機能を付けてみたり、テストを書いてみたりなど、自分なりにいろいろ足してみるってのを僕はよくやってます。

    また、エンジニアのGithubを眺めると習作として作ったものが上がっていたりします。知り合いのエンジニアのを写経してみて、解らないところを本人に聞いてみたりするとかも良いんじゃ無いかなーと。そういうやりとりって結構楽しいんですよね。

    その際、スターを付けてあげるとちょっとポイント高いです。

    あと習作として作ってみたモノに頼んでも無いのにコードレビューされたり、「俺も作ってみたー」って言われていきなりすごいコードを見せられたりして「ぐぬぬ・・・」ってなりながら楽しかったのを覚えてます。

    というわけで、僕のGithub アカウントはこちらになります。https://github.com/torounit

     

    さいごに

    つらいって話たくさんした気がしますけど、カッコいいモノとか作りたいなーってのは有るので、そういう楽しさとかを原動力に学んでいくのが個人的には良いのかなと思っていたりします。

    スタッフの皆様・ご来場の皆様のおかげでとても楽しかったです。準備などお疲れ様でした。ありがとうございました！

    また、酔っ払いの僕に夜中まで付き合って下さった皆様、本当にありがとうございました！！！

  • WordBench 長野 vol.5で WP REST API で遊んだ話をしました。 #wbnagano

    WordBench 長野 vol.5で WP REST API で遊んだ話をしました。 #wbnagano

    というわけで先週の土曜日に、WordBench 長野 vol.5 を開催しました！非常に楽しい会だったので、今度こそ継続的にやれたら良いなと思います。また今回は誰もPHPに全く触れないというなかなかロックな会だったので、次はPHPの話をしたいです。

    せっかく今回、松本付近の方々にも多く集まって頂いたので、10/19にもくもく勉強会を開催します。近所の方もそうでも無い方もぜひご参加下さいませ。

    さて、今回僕はWP REST APIを使って、スマートフォンアプリを作ってみたり、投稿画面を全く別のものに作り替えてみたり、また業務で実際に使った事例の話を紹介させて頂きました。

    torounit/wp-app-torounit-com

    torounit/wp-markdown-blogging

    フロントエンド周りが戦国時代になってきて勉強しなきゃいけないことが多いなーと感じる昨今ですが、扱える領域が増えたのはやっぱりWEB制作者としては楽しいなーと思う今日この頃です。

     

    というわけで今週末は渋谷で秋のJavaScript祭　in mixi 〜秋のJavaScript収穫祭〜でおしゃべりさせて頂きますので、そちらもよろしくどーぞ。

    来週末はWordWine 2016という勉強会やってワインを飲むという謎の会もありますので、そちらでもお待ちしております。

  • WordBench 長野 vol.5 やります。#wbnagano

    ブログ書かねばと思い続けて気がついたらもうこんな時期です。やばいです。WordCamp Tokyo 2016 のブログも書いてないです。ブログを書くまでがWordCampなので、僕のWordCampはまだ終わってないです。

    というわけで、明日10月8日に、 WordBench 長野 Vol.5 を本当に久しぶりに開催します。

    いつもの・・・と言って良いのかは解りませんが、テクニカル以外のセッションも有ったりで、いろんな人に楽しんで頂ければ良いなと思っております。

    僕自身は、WP REST API を使って遊んでみた話とか仕事で使った話とかを中心にお話しします。

    その後座談会とかで、WordCamp Tokyo 2016や今後のWordBench長野のはなしもできたらなーと。遠方から来て頂ける方もいらっしゃるので。（北信方面とか南進方面とか埼玉方面とか）

    その後、会場での懇親会も予定していますのでそちらもご参加頂ければと思います。

     

     

     

     

  • WordPressのテーマを作ったので公開しました。

    WordPressのテーマを作ったので公開しました。

    「WordPress/HTML/CSS が好物です。」と常々言っているワケですが。

    そんな人間がWordPressのテーマを公開していないというのは「お前の愛はそんなものなの？」と思われてしまうなと。それはまずい。というわけで、テーマを作る宣言をしたわけです。

    それから約一年の月日が流れてしまいましたがようやく形になったので、公開しました。

    まぁ元々Github上で開発してたので元々公開されてたんじゃないかというのは有りますが。

    デモサイト: https://torounit.com/vanilla

    Github: torounit/vanilla

    公式テーマにも申請中なので、そのうちWordPressからもインストール出来るようになるはずです。

    機能

    • ドロワーメニュー（カスタムメニュー対応）
    • カスタムロゴ
    • 色のカスタマイズ
    • medium みたいな固定ヘッダー（上にスクロールすると戻ってくる奴）
    • モバイルファースト

    名前の由来

    とにかくシンプルで、子テーマなどを作りやすいという方向性で作ったので、バニラです。とあるカードゲームでの俗称です。

    CI

    Travis CIでプッシュ時にテストを実行したり、ビルドを自動化したり、タグを付けると自動リリースされるようにしたりしてます。やっぱりCIサーバー有ると便利ですよね。

    CSS

    最近お気に入りのStylusを導入したり、ITCSSやったりしています。

    作った感想

    WordPress のテーマは業務でいくつも作ったりしてきたのですが、ちゃんと公式ディレクトリへの公開を念頭に作るということは初めてでした。

    意外に知らなかったことも多かったり、カスタマイザー等はなかなか苦労したり。人のテーマを見ていろいろ参考になることなど、いろいろやってみると勉強になること多いですね。

    なにか不具合など有ればプルリクエストくださいませ。

    というわけで次はテーマレビューもやらないとですね。

    今週末のWordBench長野でここら辺の話も懇親会とかで出来たら良いかなと思っておりますのでぜひぜひそちらもどうぞ。

  • WordCamp Tokyo 2016 で「コアコントリビューターへの道とその先」というセッションをします！#wctokyo

    WordCamp Tokyo 2016 で「コアコントリビューターへの道とその先」というセッションをします！#wctokyo

    https://2016.tokyo.wordcamp.org/session/road-to-core-contributor-and-future-20min/

    9/17・18 に行われる WordCamp Tokyo 2016 にて、Wocker の作者で、WordPress のコアコントリビューターでもある Kite さんと一緒にセッションをやらせて頂きます。

    2人でオープンソースに関わることの楽しさとか得たものなどの体験談などをゆるゆるとくっちゃべります。ぜひお越し下さいませませ。

    また、懇親会や、2日目のコントリビューターデイにも参加しますので、なかなか普段お会いできない方々とお話させて頂ければなーと思っていたりしてます。

    よろしくどうぞ！

  • Custom Post Type Permalinks 2.1.2 と、Simple Post Type Permalinks 2.0.0 をリリースしました。

    いろいろ更新しました。

    Custom Post Type Permalinks 2.1.2 をリリースしました。

    結構いろいろ直したりしたんですが、register_post_type のパラメーターで、 rewirte が false になっているものに対してパーマリンクの変更が行われるバグを修正しました。

    また、タクソノミーについても同様に、register_taxonomy のパラメーターで rewirte が false なものについては処理をスキップするようにしました。

    Github: torounit/custom-post-type-permalinks

    プルリクエストとかいろいろ下さーい。

    Simple Post Type Permalinks 2.0.0 をリリースしました。

    こちらは、結構大規模にがっつり直してます。

    • パーマリンク構造タグ %year%, %monthnum%, %day%, %hour%, %minute%, %second%, %author% に対応。
    • ページ分割などが効かないバグなどを修正。
    • クラス構造の変更。

    Github: torounit/simple-post-type-permalinks

    プルリクエストとかいろいろ下さーい。