はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに ユーザーに住所を登録させたい時は頻繁にあると思います。 そんな時に逐一全ての住所を入れるのは面倒くさいと思うので、郵便番号を入れただけで自動で住所が入ってくれるようにしたいですよね。 今回は郵便番号を入力したら、自動で住所が入ってくれる方法を自分用まとめも兼ねて書いておこうと思います。 ※(注記)補足 Railsでjpostal.jpを使って住所を自動入力する という記事にほとんど書いてありますが、jp_prefectureを使うところだけ加筆しております。 今回使うもの jquery.jpostal.js 郵便番号を入力すると、自動で住所を自動入力してくれるjQueryプラグインです。 jp_prefecture 都道府県コードと都道府県名を変換するGemです。 動作時の環境 Rails 4.1 jquery.jpostal.js 2.7 前提 基本的には以下を参照していればできると思

はじめに バージョニングをどうやって行えばいいのかよくわからなかったので自分用まとめも兼ねてまとめておこうと思いました。 今回はセマンティック バージョニングを参考にしました。 上のサイトから要点をまとめました。 メジャーバージョン、マイナーバージョン、パッチバージョン バージョンを上げるには3つのバージョンを使って表記します。 APIの変更に互換性のない場合は メジャーバージョン 後方互換性があり機能性を追加した場合は マイナーバージョン 後方互換性を伴うバグ修正をした場合(1)は パッチバージョン このシステムをセマンティック バージョニングと呼び、各々上の条件の時、バージョンをあげます。 なぜセマンティック バージョニングを使うのか? 名前を正確な定義を与えることで、開発するソフトウェアにいて、意図が伝わりやすくなる 意図を正確に理解すれば、柔軟な依存性の仕様を作れる バージョニング

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「設計変更しやすいWeb API」についてまとめました。 本でいうと5章に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます。 2.2: Web API: The Good Partsを読んだ

はじめに Ajaxでローディングを実装したいということはしばしばあると思います。 が、ローディング画像を探したりどんなコード書けばいいのか少し迷ってしまうのも事実。 なので備忘録的にまとめておくことにしました。 Rails(Slim, Sass, CoffeeScript)で利用しましたが、他でも問題なく使えるかと思います。 アウトライン 以下のステップでやります。 Ajax通信中にloadingの文言が出ることを確認(JS) ローディングgifを用意する パーシャルに切り出す CSSを実装 Ajax通信中はページの上下左右中央にローディングgifが出るイメージです。 1. Ajax通信中にloadingの文言が出ることを確認(JS) Slimで以下の記述をします。 場所はどこでもいいですがレイアウトファイルに書くことにしましょう。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった?」や「なんでこの作業にこんな時間かかってるの?」**といったことを言われたことはありませんか? また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか? 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 ま

はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「良いURI」とは、についてまとめました。 APIのエンドポイント(URIのこと)を考えるときにURIのことも一緒に考えないといけないので、基礎編として「良いURI」についてまとめました。 本でいうと2.2に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます。 2.6: Web API: The Good Partsを読んだので「OAuthの仕組み」についてまとめた 3章: Web API: The Good Partsを読んだので「レスポンスデ

背景 Webページを新しく作成しなくてはいけなかったのですが、正直面倒だな〜と思ってました。ひとまず承認降りるためにサイトのモックというかプロトタイプを作りたかったのですがどうせ結構時間かかるし、、、と思っていました。 具体的には以下の様なことを今回は実現したかったです。 あんまり1からうんうん唸ってデザインはしたくないが、それっぽい見た目にしたい Bootstrapはもう見飽きた・・・ もちろんスマホも対応したい ひとまず確認してほしいだけなのでURLは適当でいいし、裏側は書かなくていいからさくっと確認してもらいたい Bootstrapは見慣れているけど嫌だけど、自前でCSSは(本格始動した時にしか)書きたくないし、レスポンシブ対応もさせたくて、確認もPSDではなくURLベースでスムーズに見られるようにしたい、という感じでした。 それを実現するために今回使ったのが以下の2つ! Mater

カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば1年間の日付なら1〜

はじめに 今回、社内でフロントのまるまるリニューアル(RailsのViewは基本的に全て変更)があるので、CSS設計やディレクトリ構成などをどうするか色々まとめてやってます。 コンポーネント化を意識したり、どういうルールを適用したりするかをまとめていたら結構な量になったので共有しようと思った次第です。 BEMやSMACSS、FLOCSSなどを導入したけどそれだけじゃどうも綺麗にならない、だったりどこのファイルに何を書いていけばいいかいまいち分からない...といった方には参考になるかと思います。独自で作ったものであることと、リニューアルの初期段階でこれから問題がいくつか発生する(すでに発生していくつか改善しています)可能性があることを踏まえてご覧いただければと思います。不明点や気になる点はコメントで聞いていただければ幸いです。 以前、基本的なものは僕が普段使っているCSSのルールをコーディング規

はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「レスポンスデータの設計」についてまとめました。 本でいうと3章に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます。 2.2: Web API: The Good Partsを読んだので「良いURI」についてまとめた 2.6: Web API: The Good Partsを読んだので「OAuthの仕組み」についてまとめた 4章: Web API: The Good Partsを読んだので「HTTPの仕様」についてまとめた 5章: Web AP

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「OAuthの仕組み」についてまとめました。本の内容だけだと少し足りなかったので適宜ネットからの情報も参考にしています。 本でいうと2.6章に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

CSSは綺麗に書きたいですよね。 BEM、SMACCSS、CSS設計、詳細度。色々覚えたけどどうもCSSが汚くてなんとなく見にくいと思ってる人もいるかもしれません。 なので、今回は見やすいCSSを書くために僕が決めている基本ルールを書きます。 どんどんアップデートしていく予定です。 色々自分の中で決めているマイルールのようなものはたくさんあるのですが、まだ全て洗い出せていないのでひとまず公開。まとめて書くと一生公開できなさそうなので...。 随時更新していく予定です。 HTML/CSSのコーディング規約も書いていきたいです。(別の記事かもしれませんが・・) それではこれより下からスタートです。 プロパティはアルファベット順に書く プロパティは、下のようにアルファベットの順をバラバラに書くのではなく、

CSS設計とは 簡単にいえば破綻しにくいCSSを書こうという問題。 大雑把にいうと共通部分は同じクラスにして使いまわそう、共通化しようというやつです。 今回はCSSを書く前の話(カンプを見るところ)からどういう風にCSSを書くかについて少し書きます。 今回しない話 OOCSSやBEMやSMACSSについて(moduleごとにCSSファイルわけたりとかそういう話含む) 詳しい命名の仕方について ファイル管理(ディレクトリ構成)の方法について 細かいCSSの書き方について こんな方向け 毎回CSSが破綻する人 CSS設計するための◯◯の方法とか読んでもいまいちDRY(Dont Repeat Yourself)に書けないという悩みを持っている人 大事なのはいきなりCSSを書かないこと さてあなたはHTMLとCSSを書くコーダーさんだったりフロントエンドエンジニアさんだったり、あるいはフルスタック