目的について

dscf5850_tp_v

こんにちは。石原です。
今日は久々の記事ですが、最近考えていることが正しいのかわからなくなり、取り敢えずアウトプットしてみようということで筆、ならぬキーボードを手に取りました。

気がつけば前に記事を更新してからかれこれ一年弱経ってました。Web制作業を営む者として、これじゃいかんですね。書かねば。

今回書くことは、目的についてです。
目的って当たり前すぎるかもしれませんが、最近このことについて考え込むことが多いのです。

生命保険での一件

僕は掛け捨て型の生命保険に加入しています。
加入してからまだ8ヶ月程なのですが、嫁さんから貯蓄型の生命保険の方がいいのではないかという提案がありました。
なんで?と聞くと、以下のレスポンスがありました。

  • ママ友から言われた。
  • 本にも書いてあった。

掛け捨て型の生命保険では、今僕が死ぬと8,000万程 (分割受取で月々17万円)が嫁さんに保証されます。
掛け捨て型の生命保険にした目的は、【万が一の時のための保障のため】でした。

貯蓄型ですと3,000万円程度が限度でしょう。
これでは万が一、なにかあった場合、とても生活できる金額ではありません。

もちろん、保険を契約した際に嫁さんとも詰めて話したはずです。

当初の目的を話した上で、貯蓄型生命保険では達成できないであろうと伝え、年を重ねる度に僕が死んだときのリスクは下がるのだから、5年、10年というスパンで見直そう。という話で決着は付きました。

人は目的を見失うことがある

なんでこんな話をしたかというと、目的忘れることあるよねーということに対して、皆さんの身近なところで感じて欲しいからです。

きっと、個人の意見の齟齬には、目的が関連しているのであり、それが目的自体が双方違うことによる食い違いであればまだいいのですが、目的の解釈が違うことが原因なこともあります。

  • 認識していた目的がお互いに違う
  • 当初の目的が、うわべの情報に隠されてしまう

これは、今回例に上げた僕達夫婦だけの問題ではないのです。

僕らが存在する社会では、往々にしてこのようなことが実際に起こっています。

いつの間にかプロジェクトが完了することが目的になる

目的は、非常に重要な概念だと思います。目的がなければこの世のあらゆる論理的な行動は発生しないからです。

ただし、それとともに欠陥があります。
最大の欠陥は、目的は始動因にすぎず、始動をはじめたら、目的がなくともそのまま動き続けることです。

この世の中の数多くの事柄にも同じことが言えるのではないでしょうか。
生命保険の話にしろ、普段僕らが理性的な活動をする時には、目的を忘れてしまったり、目的についてそもそも考えていなかったりすることが数多くあります。

これは、僕が普段関わっているWeb関連のプロジェクトでも同じことです。

むしろプロジェクトの目的がはっきりしていないことも多々あります。

そのようなプロジェクトの場合、ほとんどは完了してもそれほど意味のないものになるか、途中から完了することがプロジェクトの目的にすり替わります。

プロジェクトにおいて最も重要だと仮定したのは「適切な目的の設定」と「目的の運用」です。そもそもこれが決まっていなければ、プロジェクトの存在意義もはっきりしないのです。

目的の構造論

では目的、それも適切な目的を設定するにはどうすればいいのでしょうか?

目的の定義

まずは目的を定義してみます。

A のために Bをする。と主張する際の A を指す

上記の定義におけるBには手段や方法、目標がはいります。

人が、 〜 のために B をする という文脈で使う時、〜のために というのが目的になります。

〜したい、〜なりたいという文脈で使う言葉は、ここでは願望として前提から省きます。

さて、ここをスタートに考えた時、僕はある一つの法則のようなものがあるのではないかなと考えつきました。

目的は方法になり得る

例えば、次の例を見てみましょう。

死んだ時のリスクを保障するために、生命保険に加入する

この場合の目的は、「死んだときのリスクを保障する」です。「生命保険に加入する」は目的を達成するための方法ですね。

では、次はどうでしょう。

自身がいない世の中でも家族が苦労なく生活できるために、死んだ時のリスクを保障する

ちょっと長いですが、
「自身がいない世の中でも家族が苦労なく生活できるために」 が目的で、

「死んだ時のリスクを保障する」が目的を達成するための手段になっていることがわかります。

先程の目的が、今度は手段として述べられていることがわかりますね。

これが目的が方法になり得るということです。
目的は単一で存在しているのではなく、その目的にも目的があり、目的の目的を考えるときは、最初の目的は方法になる、ということです。

目的って単語でゲシュタルト崩壊しそうですが、進めます。

目的の構造化

目的は方法になり得るということを仮定すると、
目的は構造体としてツリー形状に存在していることが想像できます。

目的を上へ上へ考えていくと目的を深めることができ、
下へ下へ考えていくと、目的達成のための手段を考えることになります。

上昇法と下降法

この目的を上へ上へと考える方法を仮に上昇法と名付け、下に下に手段を考えていくことを下降法とでも名付けましょう。

上昇法は、簡単です。「なぜ?」「なんのために?」をひたすら繰り返していけば良いのです。
これにより、自然と目的を深くまで上り詰めていくことができます。

下降法については、手段を考える、企画型のプロジェクトでいうと戦略を考える、とも言います。
選択肢を洗い出し、検証し、決定するプロセスです。

上昇法の限界

上昇法の限界は、行き着くところは人の感性に落ち着きます。

例) 旅館予約サイト
コンバージョン率を増やすために、Webサイトをリニューアルする
↓
コンバージョン数を増やすために、コンバージョン率を増やす。
↓
客室稼働率を上げるために、コンバージョン数を増やす。
↓
宿泊事業の業績を上げるために、客室稼働率を上げる
↓
会社としての売上を向上するために、宿泊事業の業績を上げる
↓
社内、社外の利害関係者により多くの利益を分配するために、会社としての利益を向上する
↓
社内、社外の利害関係者の生活をより良くするために、社内、社外の利害関係者により多くの利益を分配する。
↓
社内、社外の利害関係者の生活欲求・社会的な欲求を達成するために、社内、社外の利害関係者の生活をより良くする。

極端な例ではありますが、「Webサイトをリニューアルする」ことの目的を上昇していくと、
「社内、社外の利害関係者の生活欲求・社会的な欲求を達成するために」ということが目的としてでてきました。

正しいのかも知れませんが、ここまでくると正しかろうと、目の前のプロジェクトにはあまり重要ではない目的を見つけてしまいます。

目的構造体のどこを起点とするか

旅館の例で言うと、「コンバージョン数を増やすために」という目的が、最も現実的だと感じます。

でも、本当にそれであっているのでしょうか?

「客室稼働率を増やすために」という目的から考えた時に、果たしてできることはないのでしょうか?

例えば、客室管理のシステムを変えたり、リアルタイムで空き状況を反映したり、イベントを企画したり、チラシを作ったり、一概にもコンバージョン数を増やすことだけが方法ではない、Webサイトをリニューアルすることだけが方法ではないことがわかります。

つまり、起点とする目的の位置を変えることで、そこから下降するときの選択肢も変わるということです。

目的を構造として考え、洗い出し、起点を設定する。
このことが大切だと最近感じています。

まとめ

なんだか、読んでくださった人の中には当たり前だと思っている人もいるかも知れませんし、間違っているとか、こっちの考え方の方がいいと考える方もいるかもしれません。

ただ企画やら提案を考える時に、クライアントさんからヒアリングした目的を上昇法で考え、洗い出し、適切な目的を設定し、下降法で選択肢を洗い出すという考えは、結構思考方法として今のところしっくり来ています。

逆に他の目的に対するアプローチなありましたら是非教えて欲しいです。

Sketch Tips – 簡単に表組みする方法

 

Sketch でテーブルのようなものを作成する時、<Make Grid> を利用するのが一般的かと思います。

ただ、テキストを配置したりするのがちょっと面倒かなと思うので、よく使う Tips を紹介します。

 

Excel を利用する

 

Excel の表を Sketch に貼り付けるとほぼほぼそのまま再現してくれます。

PDFとして処理してんのかな。

Excel でちょっとスタイリングして、表をそのままコピーして上げればOK。

ezgif.com-optimize

行間とかちょっとずれるけど、便利です。

 

 

 

 

Mac から Mac へ。移行した時の注意点メモ。

 

2012年の春から2015年10月まで使っていた MacBook Pro‎ がついに壊れました。
症状としてはキーボードの Sキーが取れ、ファイルを保存するたびに指にキーがくっついてくるというものです。

僕としては初めての Mac to  Mac。人生初めての2代目のMac。

新しいMacを汚したくないため、できるだけ最小限の移行にし、
環境構築に関しては一から行いました。

そんなわけで次回に活かせるようにいろいろメモです。

アプリの移行は簡単

iCloud のアカウントは前もMacと同じものを利用していますので、
AppStoreから購入済みのアプリケーションをインストールするだけ。すぐ完了します。

そんなことはわかりきっていたので、とりあえず時間のかかりそうな Office、Adobe CCのインストール。

  • Adobe Creative Cloud – Photoshop、illustrator のインストール。環境設定は自動的に同期してくれた。
  • Office 365 – 特に問題なくインストール完了。
  • Chrome – ログインした時点で、クローンされた。問題なし。
  • Dropbox – 問題なし。
  • Sketch – ベクターベースのデザインツール。問題なし。プラグインなんかは必要なものだけインストール。
  • Transmit – FTPクライアントソフト。iCloud でも同期できるがお気に入りのパスワードが全部飛んでいた。前のMacから直接エクスポートして新Macにインポートし、とりあえず解決。
  • Magnet – ショートカットでウィンドウサイズを変更できるようになるアプリ。
  • Evernote – メモアプリ。問題なし。
  • Skype – 問題なし。
  • Atom – 問題なし。Sublime はもうインストールせず、テキストエディタはAtomで対応することを決意。あんまり使わないし。
  • PHPStorm – 前の MacのPHPStormから設定をエクスポートし、新Macにインポート。特に問題なし。
  • xcode – 特に問題なし。
  • 1Password – 問題なし。
  • Karabinier – キーリマップアプリ。問題なし。
  • Alfred – Powerpack は一台1ライセンスなため、前のMacアカウントを無効にし有効化。ワークフローも必要なものだけ移行。

CUI ツールのインストール

 

  • Homebrew – Macのパッケージ管理ツール。普通にインストール。
  • Homebrew Cask –  Mac のアプリケーションもHomebrewで管理できるようになる。
  • dotfiles の移行 – .zshrc, .vimrc, .tmux.conf, ….etc を前のMacから移行。それに伴い、zsh、tmux、z、その他依存ソフトウェアのインストール
  • Vagrant, Docker Toolbox  – 特に問題なし。
  • Homebrew でLAMP 環境をMac上に構築 – バーチャルマシン上での開発メインなので、必要ないはずですが一応。
  • nodejs 系のグローバルパッケージをインストール – gulp, grunt, bower のインストール。

細かいところはまだですが、特に問題なし。

細かい設定

 

  • OnyX – メンテナンスアプリ。アニメーション関連のパフォーマンスに関係する設定の変更。

 

DockerでWordPressを立ち上げる。GUIで。

Docker で WordPressを立ち上げる。GUIを使って。

WordPress の プラグインのテストや、テーマのテストを行いたい時、Docker を利用することでもっと便利になるでしょう。

今まで Wockerを利用していましたが、エンジニア以外でも簡単に立ち上がれる方法を探りました。

Kitematic を利用する

結構前からあったと思うのですが、今は dockertools として cli と一緒にダウンロードできるみたいです。

Kitematic

ダウンロード後インストールし、Kitematic を開くと綺麗なウィンドウが開きます。

さて、WordPressを早速立ち上げて見ましょう。

コンテナの作成、設定

MySQL コンテナの作成

Docker が配布している WordPress のイメージには MySQL 環境が含まれていません。
よって、別にMySQLのコンテナを立ち上げる必要があります。

右上の検索窓から mysql と入力後検索し、これまた Docker のオフシャルリポジトリの MySQL イメージをクリックして立ち上げます。
また、初期状態では root ユーザーのパスワードが空のままなので、

MYSQL_ROOT_PASSWORD

に任意のパスワードを指定してください。

WordPress の立ち上げ

WordPress の立ち上げも、右上の検索窓から行います。
wordpress と検索すると、オフシャルのリポジトリが表示されるのでクリックしてダウンロードしましょう。

注意点として、いくつかのパラメータを設定する必要があります。
先ほどの MySQLコンテナと繋ぐために、MySQLのホストを設定します。

  • WORDPRESS_DB_PASSWORD に MySQLのroot ユーザに設定したパスワードを指定
  • WORDPRESS_DB_HOST に mysql指定

すると、綺麗に WordPress が表示されます。

番外編 :  立ち上げたVMにログインする

やはり php.ini をいじりたい時がが出てきました。

$ docker ps -a

 

上記のコマンドで、立ち上げた コンテナのIDが表示されるので、
そのIDをもとに、

$ docker exec -i -t {id} bash

 

でログインすることができます。

SVGをプロジェクトで利用してわかったこと

SVGをプロジェクトで利用し始めてわかったこと。

ここ数ヶ月、やっとSVGを実際の案件で利用し始めて、様々なことを学びました。
ハマって時間を潰すこともあれば、便利だなと思うことも。
この記事では、いくつかの感想をまとめてみます。

デザインツールについて

SVGが作れるデザインツールも数多くあり、今ではphotoshopでも作れるほど。

  • Adobe illustlator
  • Adobe photoshop
  • sketch.app
  • Affinity Designer

…etc。
他にもあるとは思いますが、メジャーなもので上記の4つでしょうか。

上記で一番コーディングしやすいツールは Sketchです。一番綺麗なコードを出してくれると思います。
illustrator もまだ大丈夫ですが、結構余分な情報もエクスポートされます。
photoshop もエクスポートはできますが、シェイプであることが前提です。また、defs タグの中に style タグと CSSで色などが定義されたSVGファイルがダウンロードされるので、HTML内でclassが衝突し思わぬ事態が起こりやすいです。

今でもスタンダードなツールはadobe 製品です。
photoshopでも、SVG化が考えられる箇所についてはillustratortで作成し、外部ファイルとして埋め込むようにすることが大切です。

ブラウザ互換に苦労する

SVGは非常に複雑な仕様ですので、SVGを解析しレンダリングするブラウザでも、ちょっとした差やできることに違いがあり、結構苦労することがあります。
特にIE8対応がマストの場合(まぁなくなるとは思いますが)、SVGを利用する選択肢はできるだけ避けた方が吉かもしれません。

SVGを利用したアニメーションでも、IEでは transform-origin プロパティが効かなかったりします。*思い切って GSAPSnap.svg といったライブラリを利用したほうが余計な手間がかからずすみます。
SMIL Animate は既に削除される仕様なので、今後は利用しないほうがいいでしょう。

ロード方法について

SVGは基本的にHTML内に直接埋め込まないと、CSSでのプロパティの操作や、JavaScript でのアニメーションを実装することはできません。
Jade では include を利用することでより便利になります。
もしくは、icomoon などでアイコンフォントに変換したほうが楽だと思います。

まとめ

SVGは既にプロジェクトで利用できますし、使いようによってはとても便利です。
しかし、便利さに目がくらんでしまうと、意外に痛い目にあってしまいます。
今回紹介したことだけではなく、プロジェクトの規模感や仕様に合わせ対策を練りましょう。

CSSフレームワークから学ぶべきこと

CSSフレームワークから学ぶべきこと

Bootstrap、Foundartionをはじめ、世の中には様々なCSSフレームワークが登場しては、消え去っています。

日々流れるフィードを紐解くと、「シンプルで使いやすいCSSフレームワーク」「すぐに使えるフレームワーク」といったような触れ込みで、様々なフレームワークが紹介されています。

そんな中、どのフレームワークを使えばいいのかわからないという方もいることでしょう。

本日はCSSフレームワークとどう向き合うべきかを考えてみます。

認知度が正義か。

さて、なぜCSSフレームワークを採用するのでしょうか?
もちろん、ここではあげられない程にメリット、デメリットがあるでしょう。

敢えてここでは 属人化というキーワードでメリットを説明します。

つまり、自分一人にコードが依存することを防ぐということです。

複数人でコーディングを行う、もしくは作業フェーズを細かく区切り、途中で誰かに作業を譲渡する。
そんな時こそ、CSSフレームワークは最大限の力を発揮します。

Bootstrapや Foudartion といった著名なフレームワークであれば、コーダーであらば利用したことがある方は多いでしょう。
つまり、コードリーディングにかかる時間も、作業の引き継ぎにかかる時間も、格段に減ります。
既に知識がある人は簡単にHTMLを追加・更新できるでしょうし、わからなくても充実したリファレンスやWeb上の文献が転がっています。

フレームワークを利用することで、ドキュメントを用意するために割く時間が減ることは間違いありません。

もちろん、これが無名なフレームワークであれば効果は半減します。

CSSフレームワークは、認知度が高いものを採用することが一番無難だと考えます。

考え方を読み解く

なぜこんなにも色んなフレームワークが台頭してきているのか。
それは、考え方が違うからです。

軽量を目指したもの、BEMに合わせたもの、その他アプリケーションを前提としたもの、リッチなフレームワークを目指したもの、、、世の中のフレームワークにはまず 目的 があり、その解決策としてCSSフレームワークを構築したという背景があると思います。

カスタマイズのしやすい Foundartionと、とにかく早くサイトが作れるように設計されているBootstrap のように、それぞれのフレームワークに特徴があります。

このフレームワークがなにを目的としたもので、どんな考え方に基づいて設計されているのか考えてみると、別の視点でCSSフレームワークと向き合えるのではないでしょうか。

まとめ

CSSフレームワークは Foundartion 使ってるからいいや なんて思ってらっしゃる方、もう一度視点を変えて他のフレームワークにも目を向けてはいかがでしょうか。

CPI で WordPress を利用する時にはOptions +SymLinksIfOwnerMatch を指定する

新しく発行したマルチドメインでは、いろいろと変わっていたのでメモ。(2015.10.16 時点)

以前のACE01との違いは以下の点。

  • PHP のバージョンが 5.6.11 or 5.5.27 
  • Options +SymLinksIfOwnerMatch でのシンボリックリンクの有効化

Options +FollowSymLinks でこれまでシンボリックリンクが有効になっていたが、
セキュリティの面からかOptions +SymLinksIfOwnerMatchに変更された模様。

AddHandler x-httpd-php5611 .php
suPHP_ConfigPath /usr/home/ユーザーID
<FilesMatch "^(\.htaccess|\.htpasswd|php\.ini|.*\.sql|.*\.log|.*\.cron|.*\.inc|.*\.phps|.*\.yml)$">
 Deny from all
</FilesMatch>
Options +SymLinksIfOwnerMatch
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

 

CPIサーバーの.htaccessでのリダイレクト不可の原因 : http://blog.oo-long.info/?p=1083

コーディングルール策定までの道のり その①

社内のコーディングルールをそろそろ決めなければ、、、

※ この記事はパブリックなメモです。

1 HTMLコーディング

 

HTMLバージョン

基本的にHTML5を使用する。

スペース

コードのインデントはスペース2つで表現する。

 
HTML タグの命名

必ず小文字で記述するものとする。

ID、Class の命名

IDについては、基本的には使用しないものとする。ただし、JavaScript によってなんらかの理由により使用せざる得ない場合は例外とする。

class の命名には、BEM 記法を採用する。

ページに依存する命名 ( .home-banner, .about-contents 等 ) は極力さけ、コンポーネント単位での設計を心がける。

画像の命名

画像の命名については、以下の通りとする。

  1. 接頭辞として、Block を利用する
  2. 次に、Element を指定する
  3. 最後に数字を付与する。10未満の場合は、接頭辞として0をつける。
  4. 各単語の接続詞としては、- (ハイフン)を利用する。

profile-text-01.jpg

profile-bg-01.png

 

テンプレートエンジンについて

特別な理由がない場合には Jade を採用する。なお、極力HTMLテンプレートエンジンを利用してマークアップすることを心がける。

2. CSS

ファイル命名

基本的に、メインとなるスタイルシートを記述するファイルは style.css と命名する。

ファイル分離について

CSSファイルは一つにまとめること。

@import によるCSSファイルの読み込みは

 

Android 4系でテキストが縮小表示されるバグ

すっかり忘れていて、久しぶりに遭遇した。

忘れないようにメモ。

 

まず前提として、モバイル非対応のサイトをAndroid 4系で表示した時に発生する。

テキストが半分の位置で改行され、縦長にずれてしまう現象だが、テキストノードが存在するDOMの最下位タグにCSSプロパティの background-color もしくは background-image を指定する。

ただし、見た目上変わる可能性もあるので、background-image : url(transparent.png) のように透明な画像を指定するのが一番手軽

CSSNEXT & Post CSS

PostCSS とかもでてからだいぶ出ているけれども、一体いつ導入を始めればいいのか。

CSSNEXTも、いくら仕様策定中のシンタックスとはいってもこれからどうなるかわからんし….

基本Sassで頑張って部分的に導入してみようかな。

とりあえず gulp-sass で戦えるところは戦おう(決意)

 

関連リンク

postcss/postcss

cssnext/cssnext

gulp-sassとgulp-cssnextで快適コンパイル環境を構築 – Qiita

cssnextを使って最新のcss syntaxで開発するのが良さそう | 69log

cssnextでみる次世代CSSとPostCSS | Yucchiy’s blog

PostCSSとcssnextで最新CSS仕様を先取り! | HTML5Experts.jp

Mac OSX El Capitan で notifyd というプロセスが暴走する

OSX 10.11 にアップデートをしたはいいものの、時折 notifyd というプロセスが暴走し固まることがしばしば、、、、

tmux が絡んでる模様。

tmux.conf に以下の2行を追記、もしくは status, status-interval の値を off と 0 に修正すればとりあえず治るっぽい。

まだ確認できていないため、とりあえず様子見る。

set-option -g status off
set-option -g status-interval 0

 

https://github.com/tmux/tmux/issues/108

CSS設計を考えてみた

image

最近HTMLコーディングをすることが増えてきました。
レスポンシブWebデザイン(以下RWD) をする上で大切なことってやっぱりCSSの設計っすね。

何回かコーディングやって決めたことをメモします。

はじめに確認すること

プロジェクトの最初にやらなければならないのは、まずは把握することです。以下のこと必ず最初に確認しましょう。

対応ブラウザ

最近ではIEの対応もほとんどなくなりつつある気がします。あってもIE9まで。プログレッシブエンハンスメントでの対応。

命名規則

BEMを導入する。ページ名に依存した命名をせずに、コンポーネントごとの命名をすること。また、モジュール名で簡潔にイメージできる命名を心掛ける。

モジュールのリストアップ

デザインカンプをすべて確認し、どのようなコンポーネントが存在するかリストアップする。

HTMLコーディングルールの確認

.editorcofigなどのツールを利用して、個人の環境に左右されないことが大切。

コーディング時

コーディングする時に注意すべきこと。

Sass

導入するが、過度のネストは厳禁。コンパイル後のCSSを意識して書くこと。納品案件の場合、最後にはSassを切り捨てることもある。

IDでのスタイリングは極力避けること。

!important の利用は極力避けること。

メディアクエリーは、Sass 内に直接ネストして埋め込むこと。

・ファイル命名規則

ScssファイルはBEMで記述した一つのモジュールに、一つのファイルが対応するように命名。クラス名でファイルを開くことができるため、効率がいいと考える。

どんどんSassファイルを増やせるように、css-globbingの導入は必須。

 

 

姓名判断について考えてみた

PAK93_taikusuwariatama20140322-thumb-815xauto-16854-1

 

最近忙しい忙しいばかり唱えている呪術師石原です。

実はプライベートで12月にパパになります。
子供ができるということは、父親になること。ダメパパになりそうですね。

子供が生まれる時に、絶対にしなければいけないのが名前決め。

我が家ではかれこれ数ヶ月名前を決めるために悩みに悩み、
残り2ヶ月の今でもさっぱり定まっていないのが現状なんです。

原因は、姓名判断。

僕は全く神様だとか、信仰だとかを気にしない人間で、もちろん占いの類もそう。
姓名判断もこれまで聞いたことはあったけれども、世の中でこんなに広まっているとは。
たいてい、周りの経験者方に聞いても8割ぐらいは参考になさったそうで。

これまで数え切れないぐらいDOMに命名してきた僕が提案しても、姓名判断で突っ込まれる。うーんどうしたものか。

大体、姓名判断ってなんなのと思い調べてみました。

姓名判断の歴史

実は、画数の考え方(日本式姓名判断)の歴史は80年ちょっとです。

姓名判断の歴史は80年ちょっと|ことだま「名前」占い 水蓮オフィシャルブログPowered by Ameba : 

姓名判断の理論の基礎的内容は熊﨑健翁によって広く世に広められ、熊﨑が姓名判断の源流と広く認知されているが、熊﨑は姓名判断の理論を開発したのではなく、明治時代の易者・林文嶺と言語学者・永杜鷹堂が理論化したものを大衆向けによりシンプルにしたものが熊﨑の姓名学である。

姓名判断 – Wikipedia

どうやら、現在広く使われている姓名判断って熊崎健翁という方が昭和に入って発表した「熊崎式姓名判断」というものを元にしているようで。

はは、一つ根拠をつかんだ

よくある姓名判断サイトについて

複数の姓名判断サイトをみたところ、画数から

・天格 : 苗字の画数
・外格 : 苗字の一文字目と名前の最後の文字の画数
・人格 : 苗字の最後の文字と名前の最初の文字の画数
・地格 : 名前の画数
・総格 : 苗字と名前を合わせた画数

を計算し、各格の画数に応じてあらかじめメッセージを用意し結果を出力する。

中には、

var TenChiGai = RndVal(Math.pow(Ten * Chi * Gai, (1.0 / 3.0)) * 30.0, 10);

 

みたいな形で格を計算し、メッセージを出すようなものを。いくら流派によって判断が変わるとはいえ、こんな算出方法本当にあんのかいな。

結論

画数調べるって言って、上記のようなサイトで調べてるので、そこを丁寧に説明。
あわよくば自分で作って、自分がつけたい名前の結果を満点にして、ばれないように嫁さんに知らせよう。

– – –

 

補足

 

面白い Github のリポジトリ見つけた。

暮らしの姓名判断
https://github.com/MasakatsuNakamura/seimei-kurashi
0 forks.
0 open issues.
Recent commits: