「webで何か」作るブログ

35歳という遅すぎるスタートをなんとかする為のブログです。基本的に自分にとっての役立ちメモ。

ファストアンドスローを読んだのでまとめておく(1)

2月、3月の二ヶ月間をかけて、「ファストアンドスロー」を読みました。 Tweetを遡ると、正確には1月の終盤に購入して読み始めていたようです。

副題にある「あなたの意思はどのように決まるか?」が示す通り、人間の意思決定の裏側にあるメカニズムを題材とした書籍で、一部ではUXのバイブルなどと言われてもいます。

当時の課題感として、マーケティング、デザイン、チームメイクの三つがあり、なるべく広範に活用できそうな知識を得たいな、と思って手に取ったのですが、2ヶ月間かかった事実が示す通り、まあ骨太な本でした。

読み終わってあまりに日が経ってしまうとなんなので、まとめておきたいと思った次第です。ただのサマリーなので面白みはないかもしれませんが、よければお付き合い下さい。

人の意思力は曖昧なもの

この書籍は、著者であるダニエル・カーネマンの疑問や実験、その結果や考察をひたすら紹介していく構成が取られています。そしてそのほぼ全ては、「人間の意思は外部要因によって操作されている」という結論に結びついていきます。

それぞれに名前がつけられているので、一つ例を挙げます。

イメージで歩く速さも変わる 「プライミング効果」

ライミング効果と名付けられた現象を扱う章では、何らかの刺激がその後の行動や意思決定に影響を及ぼすという事象をいくつも挙げています。

一例としては、以下のような実験があります。

  1. 同じ属性(年代)の被験者を2グループに分け、ランダムに単語が並べられたシートを渡す
  2. 被験者グループAのシートには老人をイメージするような単語が多く含まれている
  3. 被験者グループBのシートは老人をイメージするような単語はない
  4. シートの単語を利用して、指定の文章を作成する、という課題を双方に与える
  5. 課題提出後の歩行速度を調べる

老人を想起させるような単語が多く含まれたグループAは総じて歩行速度が下がる、という結果が出た、と書かれています。

そのほかにも、学校補助金の増額案に対しての賛成票を集めるケースでは、投票所を学校にした場合の方が圧倒的に賛成票が集まりやすいという結果も紹介されます。

これらの因果関係は心理学の領域でありまだまだ解明されていないのですが、人間は無意識下で情報を受け取り、影響を受けていることを象徴するエピソードです。

怠け者で疲れやすい上司(システム2)と短絡的な部下(システム1)

人の脳は異なる特性を持つ二つのシステムがあると著者は言います。文中では便宜上これらを「システム1」と「システム2」と呼んでいますので、ここでも簡単にその特徴を紹介しておきます。

システム1は直感的かつ高速に物事を捉え、常に動作しているシステムです。反対に、システム2は論理や塾考を担当し、システム1の依頼によって動作をするシステムです。

システム1の特徴は常時起動と高速思考にあり、基本的に物事を疑うことをしません。

「自分が見たもの聞いたものをそのまま受け入れる」が基本姿勢であり、役割としては周囲の情報を絶え間なく受けとり、怪しいものがあればシステム2へアラートを飛ばす、言うなれば見張り番もしくは短絡的な部下です。

システム1が用心深く、小さな異変も大きな異変も逃さず、全てを上手く自分で処理してくれれば良いのですが、実際にはそうは行きません。

表現方法で反応が変わる 「フレーミング効果」

システム1の短絡的な部分を表す現象に「フレーミング効果」があります。これは「不満足度10%」と書くより、「満足度90%」と書いた方が、反応はポジティブになるなど、表現や切り口によって印象が変わる現象を指します。

実際に数値は変わらないのに反応は変わってしまう。本当に人の意思は簡単に操作されているのだと理解できます。

システム1の効果で九死に一生を得た消防士

ここまでの内容だと、速い思考を得意とするシステム1が悪者のようですが、そんなこともありません。

システム1の反射的な思考によって命が救われるようなこともあります。ベテランの消防士のエピソードでは、ごうごうと燃え盛るビルの中に取り残された民間人をシステム1の特性によって救出した消防士のエピソードもあります。

救助活動中、床面から煙が漏れ出しているのを視界の端に捉えた消防隊長は、直感的に「床が崩落する」と感じ取り、周囲の人間を崩落の危険がない場所まで移動させました。

結果はその通り、移動が完了した数秒後にその場所は崩落しました。

膨大な経験値から即時に最適な答えをだす

例えば、刻一刻と状況が変化するような競技、格闘ゲームでもサッカーなどが例としては良いでしょうか。

これらの勝敗を分ける要素として、「判断の速さと正確さ」は間違いなく大きなウェイトを占めているでしょう。

選手は次に相手がどう動くという予測を元に自分がどう動く、という判断を下しているはずですが、その時には脳内でじっくり考えているのではなく、瞬時に行われています。

システム1は常時起動し、常に原因と結果をあるがままにデータベースに登録し続けているので、スピーディーな反応が可能なのです。

「疲れたからチョコレート」は正しい。意志力はブドウ糖でキープできる

堅苦しい話題が続いてしまっていますので、少し軽いネタで休憩しましょう。

疲れた時やもうひと頑張りしたい時、甘いもので休憩することがあると思います。

これはどうやら正しいことのようで、感情を抑え込んだり、難しい計算に取り組んだりという活動ではブドウ糖が消費されることと、ブドウ糖が尽きた状態では判断力や意志力がはっきりと低下するという実験結果が出ています。

ブドウ糖なので、ラムネが一番手軽で吸収も良いようです。一つカバンに忍ばせておくといいかもしれませんね。

 

といったところでいったん終わります。また続きを書きたいと思います。

 

クラウドCMSは小型案件に最適かも知れないという話

先日、MovableType.netのハンズオンに参加してきました。

movabletype.net

そもそもこのWeb業界に入ってくるきっかけはWordPressでしたし、WordPressは変わらず大好きなツールです。

これまではWordPressでだいたい事足りでいたので、他のCMSに目が行くこともありませんでした。

ではなぜMovableTypeハンズオンに参加したかというと、ここのところWordPressしか扱えないということに限界を感じることが多くなってきているんですよね。

どうしても公開サーバーと編集サーバーを分離させたいという要求だったり、承認フローが必須だったりという要件に対してWordPressはちょっと厳しい戦いにならざるを得ないです。(解決策をご存知の方ぜひご教示ください。shifterは気になっています。)

そして上記のような要件が入ってくるような案件は金額も高めです。

こういった案件をスルーしないためにも、これらに適したCMSを手札として持っておきたいというのもあります。

というわけでハンズオンを受けてきたのですが、その結果として、クラウド型のCMSという選択は小型案件にはもってこいなのではないか?という結論に至りました。MovableType.netを例に考えをまとめていきたいと思います。

保守や問い合わせ対応をベンダーに任せて制作や施策に集中する時間を確保できる!

企業にとってウェブサイトは「あって当然」になっています。だからこそ我々Webサイト制作を生業とする企業も存在するわけですが、これにはいくつかの不幸が紛れ込んでいます。

ウェブサイトを持ったからには、大なり小なり「保守」や「管理」が必須になります。例としては、使用している技術が廃止される、新たな脆弱性が見つかって対応が必要になるケースなどです。

しかし、保守というのは(おそらく)どの世界でも経営者から疎まれるものです。

例えば生産機械の保守などであれば、修理を頼めたり、何らかのセミナーに参加する権利を得られたりなど、目に見える特典があるので納得してもらえることもあるでしょう。

しかしサイトの単純な保守は全く目に見えないものを提供するので、理解を得るのはとても難しいです。さらに、保守を請け負うというのは制作会社にとっては正直なところ非常にリスキーかつ不採算な活動になりがちです。

もちろん制作者としてその重要性は理解していても、ログの集計や基本操作の説明に時間を取られて制作物のレベルアップに時間を取ることができないのは制作者としての生き残りという観点から見れば危険であったりもします。

それが、セキュリティもサポートもベンダーに任せられるとしたら。

これは制作に打ち込みたい制作会社やフリーランスにとっても、費用を抑えつつサイトを安全に保っておきたい経営者にとってみても、大きなメリットではないでしょうか。

f:id:pochiweb:20190414101454p:plain

MovableType.netのページから抜粋

CMSに最適化されたサーバーで高速レスポンス

MovableType.netは動的配信のCMSですが、表示の速さは相当なものでした。さすがに静的配信のサイトとまでは言えないまでも、十分な速度です。Page Speed Insightsにかけてみました。

f:id:pochiweb:20190414103907p:plain

もちろんコンテンツが増えればこうは行かない可能性もありますが、十分な速度を出していると思います。高速なサーバーを利用しているのはもちろん、CMSに最適化されたチューニングも当然されているでしょうから、極端に遅くなることは考えにくいです。

またまた価格の話になりますが、これくらいレスポンスの良いサーバーをレンタルサーバーで実現しようとすると月々1000円は欲しいところです。

ちなみにTTFB(Time To First Byte)も知りたくなって測ってみました。

f:id:pochiweb:20190414104846p:plain

190.28ms。

次はとあるレンタルサーバーです。月に直すと2000円かかります。サイトはWordPressで動いているので純粋な比較ではないのですが、参考値として。

f:id:pochiweb:20190414105135p:plain

 絶対値としては2000円のサーバーに軍配が上がりますが、MovableType.netにはその他のサービスも付属してるので、総合力としてはMovableType.netが勝ると言っていいでしょう。

サーバーがそれぞれのCMSに最適化されるのはおそらくどのクラウドCMベンダーも行うでしょうから、安全で高速なサーバーを利用できるクラウドCMSは一考の価値ありと言えます。

安全のカラク

もちろんこの背景にはいくつかのカラクリがあって、機能のやストレージの制限があったりします。例えばWordPress.comでは、公式ディレクトリ以外のプラグインが利用できないという制限がかかります。

しかし、保守を依頼される側からすれば当然と言えば当然で、どこの誰が作ったかわからないプログラムを導入するのはあまりに危険なことです。

高速かつ安全なサーバーというのは、こう言ったルールの上でこそ成り立っています。

共有型のレンタルサーバーを利用していて、たまたま同じサーバー上に置かれていた他所のサイトがハッキングされて、自サイトのパフォーマンスがガクッと落ち込む、というようなことは、稀にとは言え実際にあります。

ルールが緩ければ緩いほどそう言った危険が増えます。

ハイクオリティなサイトが高速に作成できるかもしれない(充実した基本テンプレートとSixApart社の懐の広さで)

今回のハンズオンはSixApart主催のセミナーだったのですが、講師の方が他社の活用事例を色々と話されていました。

中でも印象的だったのは、MovableType.netにあらかじめ用意されているテンプレートは、そのままでも、改変しても、それをクライアントのサイトに利用してもらって全然OKです。」「ある制作会社さんは、基本のテンプレートを分解して、組み合わせて新たなテンプレートが即時にできあがるような仕組みを作って営業している方もいます」という発言。

なんとも懐が広いですね。実際にテーマを色々と触ってみるとわかりますが、確かにこれらを組み合わせればそのまま売れるよな〜と思えます。

WordPressだと企業サイトでかつ日本語で、という条件に合うデザインがされたテーマはごく少数しか存在しないため、ゼロベースで作るというのが第一選択肢となることが多いですが、MovableTypeは日本の企業なので、当然日本語表示を前提としたデザインが施されています。

これらのベーステーマを利用すれば工数はかなり削減できるのではないでしょうか。

低予算の仕事に手離れよく対応するにはもってこい

さてここまでの話を総合すると、工数が少なくすみ、安全かつ高速なサーバーが利用できて、セキュリティも基本操作サポートも丸投げできる、こう言ったメリットが見えてきます。

反対に、色々と複雑な要件があるとか、ウェブサイトを最大限活用して行きたい、という要望には向きません。

 

ということは、低予算、かつその後のサポートも必要になりそうな「ITとかパソコンとかよくわからない。」「とりあえず見栄えのいいサイトがあればいい」「操作方法がわからないから都度電話で教えてくれ」「セキュリティは完全にしてくれ」というごく一般的な案件にぴったりマッチしそうです。

小さな組織では保守やサポートに人員を割けないという事情もあるでしょう。そもそも制作者は制作に集中して技術や施策の精度を高めることに集中したいという気持ちも強いです。

そんな時にも、クラウドCMSは強い味方になってくれそうです。

 

 

見積もりワークショップに参加してきた

以下のイベントに参加してきました。

connpass.com

みんなで集まって、モデルケースとなる案件に対してサイトマップと見積もりを作ろー!というイベント。

僕はこれまで独学で見積もりだったりサイトマップだったりを作って来ていて、漠然と「これであってんのかなー」という不安を抱えていました。

人日単価も、一人当たりの年間コスト平均を人事に聞いて、そこから逆算して…といった感じ。

だったので、非常にありがたいイベントでした。雑な振り返りとかを書いていきたいと思います。

見積もりとは提案ありき?それはやりすぎ?

僕は見積もりを出すときに、「こちらが想定している仕様」「簡単な企画提案書」「明細」「見積書」をセットで出すべきだと思っています。提案ですね。

見積もり書だけだとその根拠だったり前提条件だったりを提示できないので、打ち合わせが進んでいく中で「シャチョーサン、ソレハミツモリガイヨ」が言えないと考えているためです。

コストかかるんですけどね。見積書も仕様書も打ち合わせごとにアプデするので。ディレクションもデザインも実装も一人でやってると、結構パツパツになりがちです。

この辺皆さんどうなんでしょう。

工程の粒度と作業積み上げ見積もりの実情

これもすごく悩んでいることで、作業項目と見積もり項目って必ずしも一致しない。例えばデザイナーさんの工程って、下調べから始まって、画像素材探ししたり、色々あるんだと思うけど、見積もり上では「デザイン」ってまとめられちゃう。

管理者としてはもう少し作業を細かく分解して、ボトルネックの発見とか解決に結びつけたいけど、こういう作業の積み上げで見積もりを作るのはそれなりにしんどいし、お客さん的には「知らんがな」だし、絶対に必要な作業に対して「え、この項目いらないからやめて」とか言われてしまうリスクを抱えるし、と。

作業積み上げ型見積もりにおけるその粒度問題。

詳細見せないのが一番いいかなー。詳細は内部の管理資料として使う。皆さん出してなかったし。

衝撃の見積もり作成速度!

ワークショップなので、それに合わせて皆さん高速作成されていたのかわからなけど、一時間で見積もり作りきるってやったことないです。みんなそんなスピード感で作ってるの?教えて欲しい。作れたけど。

でもこれってやっぱり少ないながらも、デザイン、コーディング、案件管理、全部やって来たからできることで、スピーカーの林さんが仰る通り、「作業項目を洗い出せる能力」が必要です。

そういう意味で、意外に自分は貴重なスキルセットになりつつあるのかもしれない気がしないでもなくてチョットウレシカッタ。

日々、作業ログを残すことと見積もりの資産化

昨年の暮くらいに、WordPressを使って作業ログを貯められる仕組みを作りました。カスタム投稿でログを入力する感じです。

f:id:pochiweb:20190130091803p:plain

タクソノミー で工程とか案件が選択できて、一覧ページで案件ごと、入力していくと一覧画面で確認できます。作業ごと、作業者ごととかのソートも可能。

f:id:pochiweb:20190130095300p:plain

見積もり作成機能もあります。

f:id:pochiweb:20190130095531p:plain

作業ログが残れば各作業にどれだけ時間がかかるかもわかるし、工程もかなり細かく分割できるので便利です。


こういうデータが貯まれば、見積りの確度は上がっていくのではないかと思います。みんな見積りの精度ってどうやってあげていってるんだろうか。

 

 

 

2018年を振り返っておく

今年やりたかったことと結果

  • JS(jQuery)になれる
  • WordPressをもう一段ステップアップする
  • 何らかのWebサービスを作る
  • デザインできるようになる

だったかな?我ながら手広すぎるなとは思うのですが、そんな目標だったように思う。

結果的には

  • JS(jQuery)になれる→ちょっとした機能はだいたい作れるようになったのでよし。
  • WordPressをもう一段ステップアップする→一般的なテーマを作れるようになってきた。クエリの使い方とかもちょっとcodex見ながら書けるし、まあOKかな。
  • 何らかのWebサービスを作る→ダメ。というか捨てる決断をした。途中までNode.jsで作ったんだけど、組織の成長と自分の成長、どっちを優先するの?っていうのを考えたときに、捨てるべきだなという結論になった。諦めきれないけど。
    あ。作業ログと見積もり作成の機能をもつWPテーマ作りました。
  • デザインできるようになる→だめ。とりあえずツールは使えるようになってきたけどデザインできるとは言えない。一個だけ提案のデザイン作らせてもらったけど、クソだった。来年はもうちょっとやりたい。

月表的な

1月

  • 前年11月に開始したN予備校の講義テキストをガシガシやってた。あと、会社のサイトリニューアルした。その時使ったmaterialize.cssを習得。
  • チームの研修計画を作った

2月

  • 会社サイトのリニューアル完了。
  • 朝活スラックチームに参加
  • 保守プラン作ろうとして頓挫した。
  • IE対象外を決める(例外で11だけ。)

3月

  • 動画メインのサイトを作った

4月

  • GoogleDanceTokyoに参加
  • 徳丸さんのWordPressセキュリティセミナーに参加
  • 保守やセキュリティについて知識蓄える

5月

  • Node.jsの復習を兼ねて、Expressを使って物品在庫リストを作り始める。
  • 会社のサイトをConcrete5にリプレースしようとするも挫折
  • Webデザインシンキングセミナーに参加

6月

  • 在庫リストシステムの制作を打ち切りされる
  • 会社でmacが支給される。誤ってUSキーを発注し、タイピング二刀流に進化。
  • デザインツールの扱いを覚えるため、勉強開始

7月

  • アナリティクスセミナーを開催
  • 社内開発環境を刷新すべく、勉強会開始
  • WordCampTokyoボランティアスタッフ申し込み
  • 個人名刺を作成

8月

9月

10月

11月

  • プログラミング(アプリ系)放棄を決意。Webサイトに注力開始。
  • サイトのデザイントレース開始
  • オウンドメディアセミナーに参加

12月

今年ツイッターでみて忘れたくないと思ったものを連ねる

 

 

www.ketancho.net

affi-note.com

 

 

 

 

 

 

speakerdeck.com

 

 

 

 

 

amix-design.com

Internet Explorer の今後について – Japan IE Support Team Blog

 

 

picsum.photos

 

 

 

stackoverflow.com

 

 

 

 

 

projects.lukehaas.me

coliss.com

jp.techcrunch.com

 

振り返り終わり!

 

 

サービス作りの記録:第0回(2018/7/15)

この文章について

初めてのサービス作りのアイデア、企画、開発の過程を記録したもの。多分続く。

狙いは以下。

  1. 宣言による強制力
  2. 自分の考えを記録して、人が見られる状態にしておくこと。
  3. 思考の整理。文章にするときに思考が整理されることが多いので
  4. サービスの質的に、ある程度参加者が必要であるため、多少はバズる必要がある。作ってみたエントリーはそれなりの拡散力がある

作るサービスの背景

自分は割と職を転々としているタイプだと思う。ざっくり以下。

バーテンダー(正確には飲食全般)はとても思い入れが強くて、Webの知識を得た個人としては、やはりこの業界に何かを残したいという思いが強く、今回作るのは飲食向けのもの。

 

あまり引っ張っても仕方がないので、解決したい課題を書いておく。要件をメモしてるGoogleDocからペタッと。

解決したい課題と背景

  • 飲食店の集客はほぼ「待ちオンリー」になっている(しかも掲載料高い)
  • お客側も、自分に合う店を探すのが大変(店側からのアクションがないから)


これを損失と考え、お店側、お客側双方がミスマッチを感じずに、かつ手軽に出会えるきっかけを作って解決したい。

現時点でのコンセプトや要件

これまた全部ペタッと。要件を考えるのはとてもデザイン的だなーというのが現時点での感想。こう、自分がこのサービスを通じてユーザーにどうなって欲しいのか?どんな幸せを形作りたいのかとても問われているなと感じる。

サービス案はちょっとした隙間時間に考えていて、大体最初は直感。

このサービスもそう。飲み会の幹事で、店探すのが面倒で、自分の希望に対してオファー来る方が楽じゃない?と思ったのがきっかけ。

そして徐々に肉付けしていった。そもそも店側が客選んだっていいじゃんとか。

コンセプト

理想のユーザー像
飲食店側
  • 個人店のオーナー、ある程度の裁量があるチェーン系店長やその部下の担当者
    • ITリテラシーは低い。忙しいためにPCからの利用は面倒だし時間を作るのも大変厳しい。片手間でちょっとした集客活動ができたら嬉しい。
一般ユーザー側
  • 慣れない幹事を任せられて、お店選びが面倒だな、と感じているユーザー
  • とはいえ根が真面目なので、色々としっかり調べてしまって、負担になってしまう人

コンセプトワード

スペックっぽく
  • 飲食店と飲食店ユーザーのライトなマッチング機会を提供して、お互いが幸せになるサービス

 

キャッチコピーっぽく
  • make new favorite, make new chance
  • find new table
  • believe own(口コミに惑わされるな)
  • 寄り道のお供に◯◯
  • smart catch(ほぼ冗談。スマートな客引き的な)
  • table filter(いらない情報は入ってこない)

主な機能

飲食店側

  • ユーザー(お客側)の要望をタイムラインとして読める
    • ただし、見られるのは提案受付状態がONのユーザーのみ。
  • 要望リストを以下の条件を組み合わせて検索ができる
    • 日付
    • 人数
    • 料理のタイプ
    • 飲み物のタイプ
    • 利用シーン
    • 雰囲気
  • 日時や人数などでソートができる

 

  • お客の要望シートに対して以下のアクションが可能
    • いいね
      • いいねは、一件押したら3分間はできない
    • DM
      • 相互いいね状態になると、お客ユーザーにDMできる

 

  • 自店舗のプロフィールページを作成できる
    • 店舗名
    • ショートPR
    • その日のいいね(誰からいいねきたかはわからない)
    • 累計いいね(同上)
    • 自店のサイトURL
    • 自由記入欄

お客側

  • 自分の今現在の要望を書いておくことができる
    • 日付
    • 人数
    • 料理のタイプ
    • 飲み物のタイプ
    • 利用シーン
    • 雰囲気
    • 自由記入欄
  • 提案受付の状態を切り替えられる(ON、OFF)
    • OFFの時には、お店側からは見られない
  • お店IDで指定してブロックできる
  • フィルター機能(設定された内容にそぐわないお店には要望ページをクローズする機能)
  • いいねをもらったお店のプロフィールが見られる
  • 相互にいいねしたお店から届くDMを読むことができる
  • お店のプロフィールページにいいねがつけられる
  • 一度押したいいねを消すことができる

持たせない機能

  • 予約機能(ノーショー防止)
  • お客からお店への評価(出会いのきっかけ作りがこのサービスが担うべきこと。)
  • お客からお店へのDM(返信もできない)
  • 既読通知機能(お互い気まずくなるのは避けるべき)
  • お店検索(解決したいことの一つは、「お店選び、選択肢多すぎて面倒問題」

 

次回はこれについて色々自分自身自問自答しながら、コンセプトや要件を詰めて行きたい。

言語もどうしようかなあ。経験があるのはNode.jsなんだけど。会社の仕事的にはlarabelも学んでおくべきだし。

ユーザー情報の登録と暗号化|Nodeで簡易な品目メモを作るシリーズ。

ユーザー登録画面を作る

メモを作る画面と表示する画面ができたので、次はログイン関連を作る。

まずはユーザー登録の画面とそのrouting。

今回はregisterで統一する。

register.jade

 
form(action="/register" method="POST")
p.row
span.input-field.col.s12
input(type="text" name="userName")
label(for="userName") ユーザー名
span.input-field.col.s12
input(type="email" name="userEmail")
 span.input-field.col.s12
 input(type="password" name="password") 
 label(for="password") パスワード
 label(for="submit)
 if(typeof message !== undefined)
 p #{message}
 

jadeの記法はまた後日まとめるかもしれない。

register.jsでユーザー登録と暗号化

 
var express = require('express');
 var router = express.Router();
 var connect = require('./connect');
 var moment = require('moment-timezone');
 moment.tz.setDefault("Asia/Tokyo");
 var crypto = require('crypto');(暗号化に使うモジュール)


 /* GET home page. */
 router.get('/', function(req, res, next) {
 res.render('register', {
 title: 'ユーザー登録'
 });
 });

 router.post('/', function(req,res,next){
 
 
var userName = req.body.userName;
var userEmail= req.body.userEmail;
var password = req.body.password;
var cipher = crypto.createCipher('aes192', password); (passwordをaes192で暗号化)
var encrypted = cipher.update('userName', 'utf8', 'hex');(第一引数:salt的な何か?)
encrypted += cipher.final('hex');(ここもまだ理解不足)
var password = encrypted;

var query = 'INSERT INTO users(user_name,user_email,password)
VALUES("'+ userName +'",'+' "' + userEmail + '",'+'"'+password+'")';

connect.query(query,function(err,rows){(DBに書き込む)
res.redirect('/');
});
 
});
 

createChiprerはどうももう推奨されていないようで、近いうちにリプレイスしたいところではあるけど、ひとまずこれでパスワードの暗号化ができた。

Expressは簡単にいろんな処理ができていいな。

WP_Queryで複数の固定ページを読み込む方法

ググっても出てこなかったので書いておく。

今回のケースは、カテゴリページの中に、指定した固定ページを読み込ませたい、という状況。

この場合のクエリの書き方は、

$args = array( 'post_type' => 'page','post__in' => array(1,2) );
$the_query = new WP_Query( $args );

post__inがあったからpage__inがあるのかなーとか考えたけど全然見つからなかったよね。