AMPについてのコンテンツ消費者としての感想メモ - $shibayu36->blog;
昨日、「AMPが導入された結果、現時点ではモバイルのブラウズ体験が大きく損なわれてるのですが、そう感じるのは僕だけでしょうか」とTwitterでつぶやいたら、いろいろ反応があり、いろんな観点を知ることが出来たのでメモしておく。なお、自分自身はまだAMPのコンテンツを実装したわけではなので、開発者の知識はなく、ただのコンテンツ消費者としての知識しかない。開発している人から見るとまた違った見え方があるかもしれない。 コンテンツ消費者側のメリット・デメリットという観点 AMPによるコンテンツ消費者側のメリットは速度面だが、モバイルを利用していた時に現時点では速度に困っていなかったので、自分はメリットを享受できていない 現時点では、いろんな理由によりユーザ体験が損なわれている部分がある ユーザ体験が損なわれている例としては、プラットフォームの問題とコンテンツ制作側の問題の両方がある プラットフォー
目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog;
最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設
MySQLを使って簡易的にサービスの数値を集計する - $shibayu36->blog;
最近色んな機能を作る時に、簡単に数値を集計してみて様子を見るということがよくあった。そこで今回はその時に使ったクエリの紹介。 【2016/10/18 10:28追記】 社内でHOUR関数とかGROUP BYにalias名を使ったらもっと簡単にできるよと言われたので、それぞれ追記してみます。 日間の作成数の集計 1日このアクションが何回行われたかとかが集計できる。date_columnにはcreatedみたいなカラムを指定し、table_nameには集計したいテーブルを入れる。他にもCOUNTの仕方を工夫したらいろいろ集計できそう。 SELECT DATE(date_column) as date, COUNT(*) as count FROM table_name GROUP BY DATE(date_column); 【改善版】 SELECT DATE(date_column) as d
「オブジェクト指向入門 第2版」の上下巻を全て読み終えた - $shibayu36->blog;
「オブジェクト指向入門 第2版 方法論・実践」を読み終えた。これでようやく「オブジェクト指向入門 第2版」を全て読み終えることが出来た。読むのは確かに大変だったけど、抽象データ型や契約による設計などといったエンジニアにとって役立つ概念を学ぶことができ、今後のプログラムの設計に大いに役立つだろうと思った。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 上巻 原則・コンセプト 上巻は特に「第3章 モジュール性」、「第6章 抽象データ型」、「第11章 契約による設計」の3つの章が面白かった
知識ゼロからElasticsearchを実践で使えるようになろう！ - $shibayu36->blog;
以前少しだけElasticsearchを触った時に、自分流Elasticsearch入門 - $shibayu36->blog; というElasticsearchに入門した時のメモをまとめていた。しかし、その頃はElasticsearchを使って完全に一人で一つの機能を作るというところまではいけなかった。 最近になってまたElasticsearchを一から導入する仕事をすることになった。この時以前自分がまとめた記事を読みながらやっていたのだが、実践で一から導入するためにはこの記事だけでは知識が足りなかった。 そこで、前の記事の知識をベースに、一から導入するために少しずつ学んでいき、自分のブログにまとめるなどのことをしてきたので、今回はその締めくくりとして、知識ゼロからElasticsearchを使えるようになるために学習したことについて書いておきたいと思う。 今回書くこと・書かないこと 今
ElasticsearchのAnalyzerを理解するため全文検索の仕組みをシンプルに考える - $shibayu36->blog;
Elasticsearchを使おうとしているとAnalyzerという概念が出てくるが、このAnalyzerという概念は最初理解することが難しかった。全文検索の仕組みを理解すれば分かるだろうと思い、https://speakerdeck.com/johtani/elasticsearchru-men?slide=5 やhttp://www.atmarkit.co.jp/ait/articles/1111/18/news148.html の記事などを読んで勉強してみたものの、こちらもいろんな言葉が出てきて非常に混乱した。例えば転置インデックス、tf-idf、トークナイズ、ストップワード、N-Gram、正規化などといった言葉が出てくる。 いろいろ調べてみて整理すると、全文検索の技術には、なぜ検索ができるかの話以外に、類似度の話、検索を高速に行うための話、あいまいな検索に対応する話など、いろんな話
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
Scala入門記 - $shibayu36->blog;
僕はこれまでまともに学習したプログラミング言語がPerlとJavaScriptしかなくて、静的言語的パラダイムや関数型パラダイムは概念は知っているものの、それがどう役に立つのか、逆にどういう面で課題がありどのように対処されているのか、などといったことを知らなかった。知らなくてもまあ仕事はPerlとJSでやっているので問題ない。しかしすでにこれらの言語から得られる概念的な知識の吸収の速度が鈍化してきていて、このままではエンジニアとしてまずいのではないかという危惧感があった。 そこで静的言語であり、関数型言語であり、また社内でも使われ始めているためサンプルコードがあるScalaの学習をすることにした。 学習するにあたって困ったことは、どういうドキュメントを読み、どのように実践するとScalaの概観をつかめるか分からないということだった。そこで今回は自分の経験を踏まえて、このように入門していくと
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;
僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明
評価制度の目的とは何か考えてみる - $shibayu36->blog;
最近どのような人事評価制度が良いものなのか考えている。どういうシステムが良いかを考えるためには、まずは人事評価制度はどういう目的で行われるのかを考える必要があると思い、まずは人事評価制度は何なのかについて自分なりに考えてみたいと思う。 今のところいくつかの本を読んで、自分の意見をまとめているという段階なので、中身の正確さは保証できない。間違っているところなどあれば指摘してもらえると。 人事評価制度の目的は何か 「そうか、君は課長になったのか。」「マネジメントとは何か」「1分間マネジャーシリーズ」など、いくつかの書籍を読んだ所、人事評価制度はマネジメントという文脈で非常に重要なポジションであることが見てとれた。 これらの書籍を見る限り、以下の様なものが人事評価制度の目的となるのではないかと考えている。 報酬による外的モチベーションの管理 社員教育の促進 会社の方向性を社員に伝搬させる 報酬に
「イシューからはじめよ」を読んだ - $shibayu36->blog;
最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。 イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。 この本の中で 悩まずに考える 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む 一次情報を死守 という言葉が印象に残ったので、それについて書く。 悩
GitHubでの仕事を快適にするコマンドを紹介します - $shibayu36->blog;
趣味のプログラミングや仕事をgithubを使って行なっていると、「ちょっとこんなかんじの変更してみたんだけど、このcommit見てよ」とか、「このブランチのこのファイルちょっと見てくれない？」みたいなことがよく起こります。そういう時いちいちgithub上のページをポチポチ押して、URLを教えるみたいなことをやっているのが大変だったので、ターミナルからgithub上のページを開くコマンドを作ってみました。すでにこういうのあるかもしれません。 今回のコマンドで出来ること commitを指定してgithub上の該当commitページを開く HEAD^みたいな指定も出来る ファイル名を指定して現在のブランチのそのファイルのページを開く 行を指定してハイライトさせることも出来る それらのコマンドをエディタなどから使うことでさらに便利に使う openコマンドとperlに依存しているので、これらが使えな
Dockerが利用しているAUFSとLXC - $shibayu36->blog;
最近Dockerをいろいろ触ってみていて以下の様な記事を書いたりしました。 Dockerで立てたコンテナにsshで接続する - $shibayu36->blog; serfとDockerでクラスタを組んでみる - $shibayu36->blog; 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; 社内用Docker Registryを立てる - $shibayu36->blog; docker commitでCMDやENVなどを指定する - $shibayu36->blog; docker inspectでDockerコンテナの情報を取得する - $shibayu36-
pecoを使い始めた - $shibayu36->blog;
なんかpercol最近いきなり流行ってるなーと思ってたら、percolのgo版pecoがいつの間にか出てて流行ってた。ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog;みたいな感じで、昔からpercol使っててまあいいかと思ってたけど 設定ファイルが分かりやすい brewで簡単に入れることが出来る そこそこ開発されてる というメリットもありそうなので乗り換えようとしてみている。 https://github.com/peco/peco pecoのファイル運用 前と大体同じ感じでやる。基本的にこういうツールは自分でいろいろ作りたくなってきて、設定が増えてきて破滅するので、ファイルを置くディレクトリを決めておいてそこに置いておくことにする。 .zshrc : 決めたディレクトリのファイルの全ロードと、キーバインドの設定 ~/.zsh
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
サーバで動いているプロセスを知るために使ったコマンド - $shibayu36->blog;
今日会社の開発サーバでhitode君と遊んでて、動いているプロセスを調べていたのでメモ。 動いているプロセスを知りたい 基本的。 ps ax ps auxとかすると、メモリ使用量とかいろいろ見れる。 動いているプロセスの関係も含めて知りたい pstreeコマンドでできる。とりあえずどんな感じに実行されているかサマリーを知りたい時は以下のコマンド。 pstree いろいろ折りたたまれているので、それを展開したい時は-cをつける。 pstree -c コマンドの引数とかも表示したい時は-aつける pstree -ac pidを知りたい時は-pつける pstree -acp 表示してみると{}で囲まれているやつがあるけど、これは多分threadなんだろうと思う。linuxではthreadのidはpidのように管理されているみたい。 メモリやCPUを消費しているプロセスを知る topとかでいろいろ
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
