タグ

ブックマーク / r7kamura.hatenablog.com (32)

  • 自分のコード綺麗って思ってんの? - ✘╹◡╹✘

    guideline.gem https://github.com/r7kamura/guideline 恐怖体験があって、震え上がり、少しでも綺麗なコードが書けるようなGemつくってる。複雑過ぎるメソッドや、使われていないメソッドが定義されていないかとか、長過ぎる行を書いてないかとか、簡単なチェックを自動化できる。こういうコードは綺麗ではないみたいなことがふわっと言われているよりは、綺麗ではないコードというのがコードで表現されている方が安心感があると思った。もしコーディングルールとして文書化したのでみんな守ろうみたいな感じにしても、コードを書くときに常にそれを覚えていなければ意味がないし、常にそういうことを気にしながら、ずっと緊張しながらコードを書かないといけない。そういう風に常に何かに気を配りながら作業するというのは、意識は高いけど、疲れるから極力やりたくないし、そもそも新しくその文化

    自分のコード綺麗って思ってんの? - ✘╹◡╹✘
  • amakan の React コンポーネント設計 - ✘╹◡╹✘

    説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka

    amakan の React コンポーネント設計 - ✘╹◡╹✘
  • amakanのフロントエンドを色々改善した - ✘╹◡╹✘

    https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ react_on_rails amakan ではサーバサイドで React.js で記述したコードを使ってHTMLを生成していて、このために react_on_rails というライブラリを使っている。このライブラリの最新バージョンが v5 から v6 に上がっていたので、まず v6 を使うように変更を加えた。 v5 までは、サーバサイドとクライアントサイドで別々の Webpack の設定ファイルを用意するような設計になっていたが。しかし

    amakanのフロントエンドを色々改善した - ✘╹◡╹✘
  • katatema.js - ✘╹◡╹✘

    次のようなコードを書いて、 import React from "react" export default () => <div>Hello!</div> 次のようなコマンドを叩くと、 katatema build 次のようなファイルが生成されるという、katatema というツールをつくった。 <!DOCTYPE html> <html> <head> </head> <body> <div>Hello!</div> </body> 最先端の消耗 前に キーボードショートカットをカスタマイズするブラウザ拡張 - ✘╹◡╹✘ で、こういうことを書いた。 id:moznion へ、寒い日が続きますがお元気ですか。ともあれChrome拡張を1つこさえれば、大の大人が寄ってたかってモダンと言い合う類のものが一通り学べるだろうと思います。 最近のJavaScriptの周辺環境は大変で、何をやるに

    katatema.js - ✘╹◡╹✘
  • Ruby on Rails on React on SSR on SPA - ✘╹◡╹✘

    amakan での設計を例に、RailsでSingle-Page Applicationをつくるときの自分のやり方をまとめてみます。 GemJavaScriptで書かれたReactのコンポーネントからHTMLを生成する」というのをRubyでやるために、RubyのV8エンジン実装であるmini_racerというGemを使う。この処理を楽に実行するために、react_on_railsというGemも使う。 gem "mini_racer" gem "react_on_rails" View body要素内のHTMLは全てReactで生成するので、layout以外にviewのテンプレートは存在しない。 Controller 初回リクエストの場合はHTMLを返す ページ遷移時に呼ばれるリクエストの場合はJSONを返す 外部サイトからブラウザバックで戻ってきたときにJSONを見せない という要求に

    Ruby on Rails on React on SSR on SPA - ✘╹◡╹✘
  • 京都に引っ越した - ✘╹◡╹✘

    こんにちは、卓球ハウスアドベントカレンダー14日目です。前に住んでいた卓球ハウスというシェアハウスが12月で解散するので、先日シュッと京都に引っ越してきました。 シェアハウスは2013年の6月からやっていたので、2年半ぐらい住んでいたことになる。1月ぐらいに2人に声をかけて、そのあと3月ぐらいから住居を探してたので、準備云々を含めると大体3年ぐらい色々やっていた。人や家を探していたときの記憶が色濃く残っていて、振り返るとすぐそこにありそうなくらいつい最近のことのように思える。 3年というと、この辺りではちょうど人材の流れるスピードと同じぐらいで、実際入居してから職場が変わった人のほうが多いくらい。通勤環境が変わったり、身辺に大きな変化があったり、周辺環境に慣れてしまったり、また新しい変化への期待が込み上げてきたりということで、集まったときと同じくらいのノリで、まあ解散してみますかということ

    京都に引っ越した - ✘╹◡╹✘
  • エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘

    最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある

    エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
  • 最強のTwitterクライアント戦争進捗 - ✘╹◡╹✘

    二週間ほど前からなぜか急にElectronを触りはじめたんですが、題材につくっているretro-twitter-clientというTwitterクライアントの v0.0.12 を出しました。別に各バージョンごとにブログで報告しているとかそういうことはなくて、急にv0.0.12を報告しています。ありがとうございます。折角なので最近の変更点を紹介します。 キーボードショートカット タブを移動するためのキーボードショートカットを追加しました。Macの場合は ⌘+] で次、⌘+[ で前のタブに移動できます。よく使う検索語句を登録しておくカスタムタブ機能など、今後もタブを便利にしていく可能性があるので、いまのうちに便利機能を付けておこうという気持ちです。他に、検索ボックスにフォーカスするとか、DevToolsを開いて内部実装を調べるとか、いろいろ便利なものを適当に付けています。メニューに項目も追加さ

    最強のTwitterクライアント戦争進捗 - ✘╹◡╹✘
  • 最強のTwitterクライアント戦争情報 - ✘╹◡╹✘

    kkosuge 最強のTwitterクライアント作り始めた - 9mのブログ kkosuge/slack-like-twitter-client r7kamura 最強のTwitterクライアント戦争に参戦 - ✘╹◡╹✘ r7kamura/retro-twitter-client k0kubun ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog k0kubun/Nocturn airtoxin 最高のツイッタークライアントを求めて airtoxin/twitter-client rhysd rhysd/Stream khrtz ツイッタークライアント「light」を作り始めた - インターネットの人になりたい khrtz/light-twitter-client bokuweb 最強のTwitterクライアント戦争にこっそり

    最強のTwitterクライアント戦争情報 - ✘╹◡╹✘
  • Qiitaのトップページのフィードの設計 - ✘╹◡╹✘

    @ainame user.articles.preload(:comments, :stocks_count) みたいにstocks_countのようなassociationを生やしており、stocks_countの内部実装はPreloaderが弄られていてIDだけ取ってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame これを抽象化するために、Article.has_many(:stocks, counter: true) みたいにすると、article.stocksとarticle.stocks_countがほぼ同じSQLで同時に定義されるようになってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame それを実現している実装がこれです / k0kubun/activerecord-precount https:

    Qiitaのトップページのフィードの設計 - ✘╹◡╹✘
  • UIコンポーネント集 Qiita:Coat - ✘╹◡╹✘

    LTを聞いているという感覚でご覧ください。 Qiita:Coat Qiita用のUIコンポーネント集 GitHub用のUIコンポーネント集をForkしてつくりはじめた レポジトリ: https://github.com/increments/qiita-coat デモサイト: http://increments.github.io/qiita-coat/ 今週月曜からやってる これはcommit数 Qiita:Coatが必要に感じた背景 全ての開発者に共通する願い 高速に開発したい 秩序がほしい (a.k.a. 最低限度の品質の保証) 開発体制の情勢に起因する理由 開発人数が徐々に増えつつある 社員11人+アルバイト3人 四半期に1人ぐらい増えてる 50人が51人になるとかならともかく、5人が6人とかになると大きく変わる その他の理由 サポートサイトや採用サイトなどQiita風のデザインを

    UIコンポーネント集 Qiita:Coat - ✘╹◡╹✘
  • 天下一bot武闘会で発表しました - ✘╹◡╹✘

    「流行りの Chat Ops に隷属させられているチャット bot たちよ集え! おみくじ、雑談……まるで実務には役に立たないが粋な仕事をこなしてくれる bot たちの知られざる実態を紹介しあいます。」という主旨の会が行われ、Qiitanについて発表させてもらいました。非常にコンテキストの共有が難しいテーマの中、うまく意思疎通できたかどうかは分かりませんが、何か得るものがあったならば幸いです。Rubotyについての話もできると良かったですが、また機会があればそのうちどこかで話したいと思います。 発表で紹介したリンク http://github.com/r7kamura http://qiita.com/r7kamura r7kamura/ruboty r7kamura/ruboty-alias r7kamura/ruboty-cron r7kamura/ruboty-google_cale

    天下一bot武闘会で発表しました - ✘╹◡╹✘
  • Serverkitつくった - ✘╹◡╹✘

    ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。

    Serverkitつくった - ✘╹◡╹✘
  • デスク遍歴 - ✘╹◡╹✘

    年の瀬なので、これまで作業するのに使ってきたデスクの遍歴について書く。 2011 これは3年前、大学生のときの実家の自分の部屋。インターンで得たバイト代をほぼ全部使って購入したMacbook Air 11inchと、Acerの大きめのディスプレイ。隣に転がってるヘッドフォンはAKGのK701で、けいおんで使われて流行ったのがきっかけで急に売れ始め理解できないまま業者が大量輸入するもそこまで売れず、抱えた在庫への不安から価格が一万円代まで下がった一瞬の隙を突いて買った。机は中学のときに親にもらったやつで、姉が一人暮らしを始めて余ってたのを貰い受けて二つ繋げて使ってた。ディスプレイとヘッドフォンと机は今も全く同じものを使ってる。右側にMacbookを置いてトラックパッド代わりに使うというのも今と変わってない。 部室 これは大学で所属していたギタークラブの部室の机。ここでよく譜読み (うちの部活

    デスク遍歴 - ✘╹◡╹✘
  • 『Web API: The Good Parts』読んだ - ✘╹◡╹✘

    『Web API: The Good Parts』を読んだ。贈ってくれた人達ありがとうございます。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型この商品を含むブログ (2件) を見る 目次 詳細はO'Reillyのページにて。 1章 Web APIとは何か 2章 エンドポイントの設計とリクエストの形式 3章 レスポンスデータの設計 4章 HTTPの仕様を最大限利用する 5章 設計変更をしやすいWeb APIを作る 6章 堅牢なWeb APIを作る 所感 Web API、よく知らない場合はとりあえず作りやすい方法で作っていこうという気持ちになりやすい。しかし、Web APIは後から変更するのが比較的難しいものなので、つらいものを使い続ける羽目になりやすい。また一貫性が重要視されやすいので

    『Web API: The Good Parts』読んだ - ✘╹◡╹✘
  • Netflix Meetup in Kyotoに参加した - ✘╹◡╹✘

    いま2週間ほど社員全員リモートで開発してみようという感じでやっていて、まあ働きすぎてる人とかも居るんだけど、紅葉が綺麗な季節なので主に京都で転がってコード書いてる。先週までは暖かかったけど、そろそろ京都も寒くなってきたのでもう転がるのは無理そう。それで、昨日京都でNetflixMeetup in Kyotoというイベントが開催されたので参加してきた。 概観 Meetupでは、Learning Scala - O'Reilly Mediaの著者でもあるNetflixのJason氏の話を聴きながら、Netflixの主にAPI周りの開発方法を伺った。当日利用された発表資料は多分 Enterprise APIs With Ease - Scala Developers of Barcelona。参加者は20代から30代くらいの開発者が主で、あと何故か立命館大学出身の人が多かった。明日Infinit

    Netflix Meetup in Kyotoに参加した - ✘╹◡╹✘
  • 権限管理を実装するときの地味な話 - ✘╹◡╹✘

    「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド

    権限管理を実装するときの地味な話 - ✘╹◡╹✘
  • リモートワークの地味な知見 - ✘╹◡╹✘

    華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね?」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく

    リモートワークの地味な知見 - ✘╹◡╹✘
  • 「オブジェクト指向でなぜつくるのか」を読んだ - ✘╹◡╹✘

    オブジェクト指向でなぜつくるのか 第2版 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2014/03/05メディア: Kindle版この商品を含むブログ (2件) を見る TL;DR 多くの人の「このを読むべきかどうか」という関心事に先に回答しておくと、「万人が読んでおいて損は無いとまでは言い切れないけれど、オブジェクト指向に興味があって元気もあるという奇特な人間は読んでも良い」です。 オブジェクト指向とは何か 平澤 章さんが書いた「オブジェクト指向でなぜつくるのか」というを読みました。オブジェクト指向を「難しいソフトウェア開発を楽に行うための総合技術」と表現しながら、「オブジェクト指向とは何か」という問いに対して現実的な解を与えようという一貫した姿勢に親しみを覚えました。 保守や再利用を目的とした技術 目的という側面では「オブジェクト指向はソフトウェアの保守や再利用をしやす

    「オブジェクト指向でなぜつくるのか」を読んだ - ✘╹◡╹✘
  • Vimmerの末路 - ✘╹◡╹✘

    Vimmerの末路 - ✘╹◡╹✘
    heavenshell
    heavenshell 2014/08/07
    はい