ブックマーク / www.bokukoko.info (9)

  • UI が複雑なほど自前で実装すべき理由 - ボクココ

    ども、@kimihom です。 先日、私の運営するサービスでカレンダーUIの機能をリリースした。開発ストーリー的な話は以下の記事でオフィシャルに記載している。 営業時間設定の改善に込めた想い | selfree 今回のリリースは視覚的に説明しやすいので、記事で技術寄りの内容を記すとする。 カレンダーUI の概要 まず今回の実装した概要を動画としてキャプチャしたのでご覧いただきたい。 www.youtube.com この機能の特徴として、以下のような点が挙げられる。 1日だけでなく複数日にまたがって斜めスクロールができる 削除は1日ごと 収縮が可能 1日で複数の期間を登録 一括で上書き可能 期間を各エリアの最上部に表示 このようなドラッグ&ドロップして期間を選択するUI を実現したいとき、あなたならどういう方針で開発を進めていくだろうか。 こだわりがあるほど自前実装 ほとんどの場合、まずは

    UI が複雑なほど自前で実装すべき理由 - ボクココ
    uimn
    uimn 2018/10/14
  • Ruby on Rails の魅力と思想 - ボクココ

    ども、@kimihom です。 私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。 Rails の作者 DHH と彼の環境 Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。 Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けて

    Ruby on Rails の魅力と思想 - ボクココ
    uimn
    uimn 2018/03/29
  • アプリの個人開発の終焉と新たな可能性 - ボクココ

    ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリでっていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、1つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が

    アプリの個人開発の終焉と新たな可能性 - ボクココ
    uimn
    uimn 2018/03/26
  • Heroku x Rails のサービスを本番運用する際に確認したいこと - ボクココ

    ども、@kimihom です。 私は HerokuRails サーバーを立ててサービスを運用している。これまでの経験を元に、定期的にチェックしておきたい指標とか項目をまとめてみる。今後のサービス開発などで参考になれば幸いだ。 サービス構成 現在の構成はというと、以下のような感じである。 Ruby 2.4.1 (執筆時点で最新) Ruby on Rails 4.2.8 Heroku Standard 1X Dyno * 4 Heroku Postgres Standard 0 Heroku Redis Premium 0 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予

    Heroku x Rails のサービスを本番運用する際に確認したいこと - ボクココ
    uimn
    uimn 2017/05/07
  • 月額課金サービスをボクはこう設計した - ボクココ

    ども、@kimihom です。 Stripe Meetup というのが渋谷の Tokyo Otaku Mode さんのオフィスで開催された。そこのイベントでサブスクリプション型サービスの設計について話をした。 speakerdeck.com こちらの内容は、以下の記事の続編的な感じとしてご紹介した次第である。 www.bokukoko.info 以下は補足 プランのプライシングは慎重に SaaS サービスをいくらで販売するか? 実際に事業を始める上で重要だけど決めることは難しい。見込み顧客に「いくらなら買いますか?」と聞いてみたところ思っていたよりも安めの金額を言われたり、今後のスケールを考えれば安くてもなんとかなると思って、金額を安めに設定しがちだ。だけども、多くの SaaS サービスは料金設定をミスって(なのかは定かではないが)、あとで値上げするという手段を取る傾向があるようだ。 値上

    月額課金サービスをボクはこう設計した - ボクココ
    uimn
    uimn 2017/03/24
  • 月額課金モデルの Web サービスの設計方法 - ボクココ

    ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。

    月額課金モデルの Web サービスの設計方法 - ボクココ
    uimn
    uimn 2017/02/10
  • 勉強会・ハッカソン運営者の皆様、参加には料金とるか審査制にしてください - ボクココ

    私は勉強会に参加するのが好きだ。色んなその分野を極めた方と情報交換して、考え方や行動に得られるものがある。いろいろ話を聞いて感銘を受け、実際に行動に移したこともある。 しかし、現在の勉強会やハッカソンが誰でも無料で参加できることで、私はそれらの会に行くことが厳しくなっている。誰でも参加できることが生まれる悲劇である。以下、私が遭遇した問題について記す。 別の目的で勉強会に来る人がいる 勉強会ってのは情報交換が目的であるのに、その技術に意欲や興味すらないし、そもそもエンジニアでない人が勉強会に来ることがある。そうした人の目的は、"タダでべられる懇親会"と、"タダで働いてくれるハッカソン用 労働力の確保"である。 ハッカソンでエンジニアに働かせ、企画とプレゼン以外は何もしない。それでイベントに勝って自分の成果とし、いかに自分がすごいかを周りに伝え、次なるハッカソン用エンジニアの獲得に向け日々

    勉強会・ハッカソン運営者の皆様、参加には料金とるか審査制にしてください - ボクココ
    uimn
    uimn 2016/02/29
  • スタートアップは始めてから3年間は投資を受けるべきではないと思う - ボクココ

    ども、@kimihomです。 最近のスタートアップと言われると、どんなイメージを持つだろうか? 大抵の方々はメディアを通じてでしかスタートアップを知らないから、「〜百万の資金調達」とか、「〜コンテストで優勝」だとか、そんなニュースしか聞かないと思う。彼らは大きくスポットライトを浴びている。自分もいつかはああなりたい。そう思っている方もいるかもしれない。 今回はそんなトレンドに一言申したい。 "スタートアップを始めるなら、投資を受ける" みたいな風潮が当たり前になってきたのはいつからなのだろう? 最近はあらゆる投資部門が立ち上がり、日々次なるスタートアップを探し当てている。そして投資家が審査員のコンテストで、投資関連先の企業を優勝させて知名度アップさせる。スタートアップコミュニティが出来上がり、熱い場を作り上げている。 当に成功した企業を思い浮かべてほしい。Google, Apple, A

    スタートアップは始めてから3年間は投資を受けるべきではないと思う - ボクココ
    uimn
    uimn 2016/01/17
  • なんだかんだで SPA から jQuery に戻った話 - ボクココ

    最近は SPA とか React といった話題が尽きないが、自分は結局 フロントエンド JavaScript は jQuery が最もいいと感じている。それはそれら SPA の JavaScript をいじった経験を踏まえての感想。 理由としては、「 やりたいことができにくい 」これに尽きる。 最新を追うということ 自分が最初にSPAを触ったのは AngularJS だった。なるほど、この ng-repeat や $route, $scope などを使えば、今までサーバサイドでやってたようなレンダリングが表側で制御できるようになる!と感動したものだった。この気持ち良さはきっとサーバーサイドでごにょごにょやっていた経験のある人ならなおさら感動するものだ。 さて、じゃあといって「次作るのは SPA のサービスにしよう!」と意気込んで初めて見たとする。それで作っただけで話題になるし、エンジニア

    なんだかんだで SPA から jQuery に戻った話 - ボクココ
    uimn
    uimn 2015/05/18
  • 1