10 日ほど前から amakan books の再設計に着手しており、最近ようやく実装を終えた。いまデータ移行処理を実行している最中で、20時間ぐらい掛かるのでゆっくり待ちながらこの記事を書いている。変更理由についておさらいするという意味も含めて、変更内容と意思決定の背景について書き記しておく。 テーブルの変更 旧 DB スキーマ では以下のようなテーブル群を利用していた。 amazon_product_link amazon_product_responses author_product_list_memberships author_product_memberships authors evaluations product_links product_lists products 新 DB スキーマ では以下のようなテーブル群を利用するようになった。 book_authors b
説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka
次のようなコードを書いて、 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の周辺環境は大変で、何をやるに
「エンジニア立ち居振舞い」 というお題に対しての投稿。 立ち居振る舞いというか、姿勢、それも比喩的な意味での姿勢の話なのだけど、所謂やっていく気持ちよりも、行動した事実に価値を見出すように努めている。エンジニアと言うとその職業柄、仕事の所作みたいな話が多くなりがちだけれど、何も仕事に限った話ではなくて、例えばブログ記事を書くときなどもそうであると思う。こういうものを頑張ってつくっている最中であるとか、こういうところで困っていて大変といった気持ちを吐露したくなることがある訳だけど、そこは矜持としてグッと我慢して、早くいいものを完成させてみんなを驚かせたいとか、苦しい気持ちはひた隠しにして反骨精神を高めるとか、そういう気持ちに変換して、より大きな成果を上げられるようにしたいと思っている。 自分に限らず他人の行動についてもそうで、何かやりたいと言っている人や、あるいは筋の良さ悪さについて考えあぐ
9mとsoramugiから、やっていきエフエム という名前でPodcastをやりませんかという話を承け、Podcastをやることになった。既にサイトが公開されていて、https://yatteiki.fm からアクセスできる。昨日できたばかりで準備中なところが幾つかあるが、サイトを開いて音を聴けるという点では最低限の体験は保証されている。 10月25日にSlackチームを立ち上げ 10月28日に練習でSkypeで通話 10月29日に1回目を収録 10月30日に公開用のサイトを作成 という流れで、発足から企画、収録、公開まで進み、この順調さには当の我々ですら驚かされた。 個人的には、雑談レベルの会話が淡々と展開されていくような、例えばカンファレンスの懇親会での会話を隣で聴いているような、あるいは飯屋での雑談を隣で聴いているような、更に言えばマックで隣の女子高生のガールズトークを聴いているよう
ここ最近絵文字で遊んでいて、Somemoji というライブラリをつくったので知見を共有します。 さまざまな絵文字セット 様々なプラットフォームのために、様々な組織が、様々な絵文字セット (絵文字画像の集合) を提供しています。 Apple emojidex EmojiOne Facebook Google HTC LG Microsoft Mozilla Samsung Twitter 大抵の絵文字セットはUnicodeのEmojiの仕様に則って実装されていて、このコードポイントに対応する絵文字画像はこれ、というように互換性があります。Unicode 6.0, Unicode 7.0, Unicode 8.0, ... とバージョンが増えるに従って定義されるEmojiの数も増えていっているので、それぞれの絵文字セットごとに対応具合はまちまちという状況ではあるものの、よく使う主要なものについ
最近Railsで掲示板つくってて、サボって後回しにしていたJavaScriptの最適化をやりました。 掲示板の構成 Webpackを使っている Reactを使っている Server-Side Renderingをやっている Railsを使っている Sprocketsを使っていない 作業内容 webpack-bundle-size-analyzerで容量の大きいpackageを調査 HTTPクライアントに利用していたjQueryを撤廃 HTTPクライアントにaxiosを採用 lodashを一部しか読み込まないように変更 moment.jsの不要なlocaleを読み込まないように設定 変更結果 これでminify後の容量が770KB→476KBに。gzip圧縮状態では202KB→125KB。 $(npm bin)/webpack --profile --json | webpack-bundl
最近RubyとReact.jsをよく利用していて、Rubyで扱っている値をJSONとして表現したいケースが増えてきた。こういうのどうやっていますかと人に聞きたいので、自分はこうやっていますよというのを説明のためにまとめておくことにする。 概観 自分の場合、次のような方法で実装することが多い。 JSONとして表現したいオブジェクトをコンストラクタで受け取るクラスを定義する クラスに #as_json を定義して適当なHashを返すようにする Object#to_json が再帰的に #as_json を利用するようにする (ActiveSupportがやってくれる) コード 具体的には、以下のようなクラスをつくっている。これは最近つくっている掲示板での例で、Megaboard::Resources::Comment はコメントのJSON表現のためのクラスである。いわばコメントのJSON表現に
こんにちは、r7kamuraです。26年なにも考えずに生きてきて、レールに沿った人生を歩んできました。 さて、数日前からなんとなく気が触れてRuby on Railsで掲示板をつくってみている。上の画像はいまつくりかけのもの。CSS全部手で書いてみてるからまだ見てくれがかなりショボい。最初に手を動かしはじめたきっかけは、2007年頃に「Railsを使って15分で掲示板をつくってみよう！」という記事を見たのを思い出したのがきっかけ。いまのところ10時間ぐらい経過している。15分はちょっと無理そう。2016年にもなって10時間以上かけて掲示板つくってるのは皮肉すぎる事実。もはや何故掲示板をつくっていたのか分からなくなってきつつある。とりあえず濁り切らない内に考えていることを書いておく。最近なんで掲示板つくってんのって聞かれることが増えてきたので、そのときにこの記事のURL出せると多分便利。 掲
URLにタグを付けるやつ 8月頃からAmazon API Gateway, AWS Lambda, Electronと、徐々にJavaScriptを触る機会が増えてきて結構面白くなってきたので、サーバサイドでの開発も試してみようと思い、一昨日から暇を見つけて簡単なWebアプリをつくってみてる。いまは習作としてURLにタグを付けられるだけのサービスをつくってみてる。コメントとか無くて、タグで情報整理して互いの役に立つことだけでコミュニケーションする。どうしても会話したかったらタグで会話すれば良さそう。公共性のある徳の高いタグをつけた人には何らかの承認をしてあげたいけどまだ特にアイデアが無い。構造的には、ユーザ入力があるし、データは永続化する必要があるし、そこそこ検索も必要だし、キャッシュのしがいもあるし、ログイン機能があるのでセッション管理とかも考えられて、練習に丁度よい。 凝りすぎて進捗ダ
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風のデザインを
「流行りの 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
ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。
最近読んだ何かの本に、デザインとは何であるか、についてデザイナーが一家言述べるコーナーがあった。朧気ながら、次のような論旨だった。即ち、物事を文字通り物と事に分けたとき、これまでデザインと呼ばれていたものは大抵物に対する行為だった。それが最近になって、デザインは事に対する行為としても解釈してもいいだろうという捉え方が流行ってきている。そのような前置きはさておき、物事は、放っておくとひとりでに無秩序で混沌とした状態へと発散していくものである。そこに秩序をもたらすために努力する行為がデザインである。 便利な解釈だと思ったので記憶に留まってる。この解釈で言えば、誰しもに同じ感想を持ってもらえるように文章を書く行為もそうかもしれない。かもしれない、思う、気がする、感がある。こういう言葉を出すのも、処世術的なそれの一つかもしれない。開けた場所では、周囲からいつありがたい言葉が飛んでるか分からない。全
これまではどちらかと言うとDBやWeb APIみたいな開発作業が多かったけど、最近はHTML/CSSを触るようないわゆるWebデザイン的な作業をする機運が高まってきた。あんまりちゃんとやったことが無いために年始から色々と考えてて、まあその結実としてキャプチャ撮ると捗るという体験があったので書き残しておく。ちなみにキャプチャは無い。あとでデザイン変えたやつ公開したら過程を整理して紹介できると良いと思う。 過程を残すと意見をもらいやすい 『藤村龍至 プロトタイピング-模型とつぶやき』という本の中に、プロトタイプとして建築模型をつくっていく過程の話がある。与えられた条件を元にまず最もシンプルな状態から始め、課題を見つけながら少しずつ改善を加えていく様子が実例とともに紹介されている。この作業を反復しながら適用していくことで、模型の状態を都度更新していく。この方法には、設計者以外の人でも設計過程を見
Rafal Tomalの書いた『The Essential Web Design Handbook』という本を読んだ。初心者のためにWebデザインの基本となる知識を広く紹介している。構成としては、筆者がWebデザインを行うときのプロセスをまず最初に紹介し、その各段階を追っていきながら、「この作業は無視されがちだけどこういう点で効率的だからやった方がいい」「これを考えるときにはこういう知識を使う。今回の例ではこうやって考えた」という具合に進んでいく。 プロセス 筆者が推奨するWebサイトのデザインプロセスは次の通り: 調査して計画をつくる 発想を膨らませる スタイルガイドをつくる ワイヤーフレームを組む モックアップをつくる コードを書く 調査と計画 調査するというのは、明確なクライアントがいる場合は要求を聞くことであったり、競合サイトの様子を調べてくることであったり、使えそうな資料を広範に
今日で無事25歳になりました。 去年とあるアドベントカレンダーの記事で25歳定年説について触れたけれど、いざ自分がその歳になってみると「確かに」と言った感じ。実際、周りのコンテキストを見てると、疲弊感、厭世感、アガりたい気持ち、結局一発あてられない風潮、その他もろもろが綯い交ぜになった茫漠とした不安が感じられることが多くなってきた。 その内、精神的な意味で体力というものが薄れ、週末にこういった活動に割く気力が無くなったとき、 ハッカーとしてはそこで死んでしまうのだと思う。そのことがただ悲しい。 何となくそういう予兆は感じられているし、あと2年もすればそのときは訪れると思う。 若者の界隈で、25歳定年説と呼んで震えている。 特にこの事実について何か主張があるわけではないが、ただこの社会は厳しいということに尽きる。 社会は厳しいの一言で思考停止するのをやめたい。 社会の斥力に負けて、心の弾力を
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
