UI が複雑なほど自前で実装すべき理由 - ボクココ
ども、@kimihom です。 先日、私の運営するサービスでカレンダーUIの機能をリリースした。開発ストーリー的な話は以下の記事でオフィシャルに記載している。 営業時間設定の改善に込めた想い | selfree 今回のリリースは視覚的に説明しやすいので、本記事で技術寄りの内容を記すとする。 カレンダーUI の概要 まず今回の実装した概要を動画としてキャプチャしたのでご覧いただきたい。 www.youtube.com この機能の特徴として、以下のような点が挙げられる。 1日だけでなく複数日にまたがって斜めスクロールができる 削除は1日ごと 収縮が可能 1日で複数の期間を登録 一括で上書き可能 期間を各エリアの最上部に表示 このようなドラッグ&ドロップして期間を選択するUI を実現したいとき、あなたならどういう方針で開発を進めていくだろうか。 こだわりがあるほど自前実装 ほとんどの場合、まずは
ContentEditable のハマりどころと対処法 - ボクココ
ども、@kimihom です。 前回の記事で、ContentEditable についての概要をざっと書いた。ContentEditable の持つ魔力については以下の記事を参照いただきたい。 www.bokukoko.info さて、本記事では実際に ContentEditable を使って実装しようと思った際に気をつけておいたほうがいい点をざっと挙げていく。もし今後 ContentEditable を使った実装をする方の参考になれば幸いだ。 タグ挿入後の罠 ContentEditable を使うなら、何らかのテキスト入力でリアルタイムに HTML タグの挿入をする(document.execCommand('insertHTML'))といった実装をしていくことになるだろう。 実際上記コマンドを実行するだけなら問題なく動作するが、問題はその後にやってくる。例えば <span> タグを動的に
月額課金モデルの Web サービスの設計方法 - ボクココ
ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。
Angular 叩きが流行っているようなので一言言っておくか - ボクココ
元ネタはここ。 Angularそっちのけで、Vue.jsについて所感 まぁタイトルからして釣りっぽい雰囲気はあるけど、そこは気にせず。 覚え切れそうな分量のAPI Angularだって最低限覚えなきゃいけないのはたかが知れてる。全部覚えようとしなくてもいいのはどのフレームワークだってそうだ。徐々に覚えていけばいいだけ。 プロパティによる宣言っぽさ たくさん書かないといけない、というようなことを書いているけれども、それはAngular がDIを推奨した構造にしているからであって、そのおかげでコードに一貫性が出るし依存関係が一瞬でわかる。テストも書きやすい。 その辺Vueは開発者に委ねられている。複雑なロジックや大規模なものになればなるほどカオスになっていくだろう。もちろんそれも開発者の腕次第ではあるが。 後半からはもはや宣伝だなw Angular の Directive に相当するだけの話だ
さよならコールバック地獄. 注目のPromise Pattern とは - ボクココ
非同期プログラミングをしていると、俗にいうコールバック地獄に悩まされることになる。 何かの処理が終わったらこれをやって、その次にこれをやって・・みたいな処理は深くネストされたコールバックを延々と書くことになるだろう。 これを解決してくれるのがPromise. 主流のJavaScript ライブラリで搭載されるようになり、その他の言語でも急速に普及され始めている。 今回はそれをAngularJSを例にして大まかにまとめてみた。 Promise API とは 従来の非同期プログラミングは非同期の性質から複雑になりがちだった。 特に非同期のイベントが複数発生した際の同期処理など。 同期の世界ではメソッドチェインによる呼び出しとエラー処理が直感的にかける。 Promise API は非同期プログラミングをより簡単にするためのもの。 AngularJSでは$q Service としてPromise
理想的な Rails, AngularJS 環境の構築 - ボクココ
ネットでRails x AngularJSで調べると、AssetsにAngularJSを追加してやるのが普通的なことをよく見る。でも、この方法だとYeomanや、Grunt.jsが使えず、Rails x AngularJSでKarmaでテストを書いたりといったことができないし、AngularJSの作法にのっとった開発ができないのがとてもモヤモヤしていた。 てことで、もうこれはAsset Pipelineを使わない方向で行くのがベストなんじゃないのか、という方向で色々探し回っていたら、同じようなことを考えていた方がいたようで,これを参考にしてもっとベーシックな枠組みを作ってみた。 Asset Pipeline の機能が使えなくなる？ご心配なく。Grunt.jsがJSコードの圧縮、SCSS, CoffeeScriptのコンパイル、さらにLiveloadの恩恵, 画像の圧縮、テストの自動実行もで
Rails の認証で Devise ではなく Sorcery という選択 - ボクココ
現在 AngularJS と Ruby on Rails 間の認証の仕組みを実装しようとしている。 この際問題になるのは、デフォルトのRails認証の仕組みは、HTMLベースであるため AngularJS で必要とされる JSON でのレスポンスが受け取れない、という点がある。 もちろん、Devise による認証でも Devise::Controller 系を継承することで独自のコントローラをカスタマイズすることが可能だ。だが、これは Devise 側のソースコードを理解し、適切なコードとレスポンスを Devise の慣習にそって実装する必要がある。これがなかなか大変。 そこで登場するのが Sorcery . これは簡単にいえばシンプルな認証の仕組みだけを提供してくれるものだ。 個人的に最も大きな違いといえば、Devise は devise_for :user や devise_for :
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本気で作業に集中するためにしたいブラウザ設定 - ボクココ