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: