ラベル 技術 の投稿を表示しています。 すべての投稿を表示
ラベル 技術 の投稿を表示しています。 すべての投稿を表示

2013年7月6日土曜日

ももクロReader(仮)というサイトをつくってみました。

なにかサービスを作りたいなと思ったので、
試しにももクロのアンテナサイトを作ってみました。

http://momoclo-service.herokuapp.com/
















あんまり難しいことはやっていません。

  • とりあえず、Herokuを使ってみた
  • Herokuなので、Ruby on Railsで作ってみる
  • Railsといっても、ほとんどRubyは書かず、もっぱらJavaScript(というかCoffeeScript)で頑張る
という感じです。
Google Feed APIで各種ブログのRSSを取得するのと、
Youtube APIで動画検索してリンク一覧を作成するのみで、
デザインはTwitter Bootstrapでごにょごにょしました。
半日ぐらいで作成しました。

他にもなんか作りたいなーと思いつつ、
ネタがない。。。
アイディア募集中です。

2012年4月1日日曜日

"Webエンジニアのためのデータベース技術[実践]入門"を読みました。

Webエンジニアのためのデータベース技術[実践]入門 読みました。
インデックスのような基礎的なところから、
NoSQLのような新しい技術の解説や、
MySQLのソースコードの読み方といった深い解説もあり、
データベースに関しての基礎は一通り学べる本であると思います。

SQLの構文の解説のような超初心者向けの解説はありませんでしたが、
データベースに苦手意識があった自分としてはとても勉強になりました。
データベースの基礎を身につけるにはこの1冊で十分なのではないかと思いました。

C言語で二分探索木を書いてみた。

C言語で二分探索木を書いてみた。 所要時間1時間。 あってる?

2011年8月15日月曜日

OAuthの仕組みについてのメモ

ちょっと前に
twitterのOAuth認証についてのエントリを書きましたが、
ちょっとOAuthについて自分の頭の中が整理できていなかったので、
ちょっと整理します。

OAuthってそのそも、

  • アプリケーションがとあるサービスのAPIを使うための、ユーザに認証してもらうための仕組み

  • アプリケーションはとあるサービスのユーザ名やパスワードをユーザから教えてもらう必要がない


  • です。

    で、
    API提供しているとあるサービスとあるサービス => Service Provider
    アプリケーション => Consumer
    
    とそれぞれ呼びます。

    Consumer(アプリケーション)はService Provider(API提供しているとあるサービス)にConsumerの登録を行います。
    登録すると、Consumer KeyとConsumer Secretが発行されます。Consumer Key/Secretはそのアプリケーションを示すトークンです。このConsumer(アプリケーション)はConsumer Key/Secretを使って、Service Providerにリクエストトークンを発行してもらいます。

    リクエストトークンを発行してもらったら、ConsumerはそのリクエストトークンをパラメータとしたURLを使って、Service Provicerのサイトにリダイレクトを行います。

    ユーザーはリダイレクトされたサイト上にて、ConsumerがService ProviderのAPIを使って情報を取得するのを許可します。

    許可したら、Service Providerはあらかじめ登録されたURLへリダイレクトするので、
    Consumerはそこから、アクセストークンをService Providerに要求し、Service ProviderはアクセストークンをConsumerに送信します。

    このアクセストークンがあれば、ConsumerがService ProviderのAPIを使うことができるようになります。

    ざっと書くとこんな感じでしょうか?

    2011年8月4日木曜日

    Jenkinsのインストールのメモ

    Jenkinsのインストールのメモ。あくまでもメモです。

    自宅のサーバーがDebianなので、それを使って。

    まず最初にコマンドラインで、
    wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add -
    
    をしたあと、
    /etc/apt/sources.listの末尾に
    deb http://pkg.jenkins-ci.org/debian binary/
    
    を追加します。

    その後
    apt-get update
    apt-get install jenkins
    
    をして、インストールします。

    設定に関しては、
    /etc/default/jenkins
    をいじった後、
    /etc/init.d/jenkins restart
    
    をします。

    /etc/default/jenkins
    は、たとえばポートを変えたい時は、HTTP_PORTを帰ればいいです。
    私は、URLに /jenkins を加えたかったので、
    JENKINS_ARGS に --prerix=/jenkins を加えました。

    詳しくは、ここを見るといいかもしれません。

    URLにアクセスすると
    (例えば、http://localhost:8080/jenkins)

    が出てくるはずです。
    デイリービルド等ジョブを作成したい時は、「新規ジョブ作成」を選んでください。

    のページに遷移しますので、
    適当なジョブ名を入力して、基本的にフリースタイル・プロジェクトのビルドを使います。

    あとは、下記の画面が出てくるので、適当に入力していってください。

    2011年7月20日水曜日

    twitterのOAuth認証

    OAuthっていうのは、
    APIを使用する認証を行うための仕様のことで、
    パスワードを第3者に教えることなく、トークンのやり取りだけで認証が行えるしくみのことです。

    OAuthってなんなのかは、
    ゼロから学ぶOAuthが参考になるとおもいます。

    で、実際にtwitterでOAuth認証をおこなって、
    つぶやくためのスクリプトを書きました。

    まず、
    http://dev.twitter.com/apps/
    でアプリケーション登録を行います。
    (登録には、twitterアカウントが必要です。)
    で。Consumer Keyと Consumer Scretを取得します。

    で、rubyのOAuthライブラリを使って、
    下記のコードを書きました。

    #!/usr/bin/ruby
    require 'rubygems'
    require 'oauth'
    
    consumer = OAuth::Consumer.new(
      "Consumer Key",
      "Consumer Secret",
      :site => "http://twitter.com"
    )
    token = consumer.get_request_token
    puts token.authorize_url #リダイレクト先のURL
    pin = gets.chop
    access_token = token.get_access_token(:oauth_verifier => pin)
    puts access_token.token #アクセストークン のtoken
    puts access_token.secret # アクセストークンの secret
    

    token.authorize_url のURLをブラウザに貼付けてページ遷移すると、
    リダイレクト先にpinコードが書いてあるので、
    それをコピーして入力します。

    そうすると、Accessトークンを取得することができます。

    CosumerトークンとAccessトークン
    あとは、twitterライブラリあたりで、
    twitter APIを叩けばOKです。
    以下は、ただ、"Hello, World" をつぶやくスクリプトです。

    #!/usr/bin/ruby
    require 'rubygems'
    require 'twitter'
    require 'twitter/console'
    
    Twitter::Client.configure do |conf|
      conf.oauth_consumer_token = "Consumer Key",
      conf.oauth_consumer_secret =   "Consumer Secret",
    end
    
    twitter_client = Twitter::Client.new(:oauth_access => {
      :key => "Access Token Key",
      :secret => "Access Token Secret"
    })
    
    twitter_client.status(:post, "Hello, World");
    

    2010年11月13日土曜日

    情報収集の方法

    私が今勤務している会社で最近、
    係長・主任クラスの社員が中堅社員研修というものを受けているようです。
    (私は平社員なので受けられませんが)

    これは、同様の主任クラスの社員の話ですが、
    中堅社員研修のなかで、講師の先生が
    「私の会社で給料をあげるのは簡単です。
    例えばAKB48のメンバーの名前を10人言えといって、言うことができれば給料を上げます」
    と話されてたとか。
    これは決してその先生がAKBヲタというわけではなく(笑)、
    仕事に関するものをちゃんと情報をキャッチして覚えているかどうか試すということらしいです。
    (ちなみにちょっと聞いただけなので、その先生がどの業界の人とかそういうのは不明です。)

    でも、ただその業界に関する情報を一生懸命覚えようとしても、
    覚えられるものではありません。
    AKB48の名前を年号のように覚えるのはバカみたいじゃないですか(笑)

    やっぱり、自然に情報をキャッチできるようにする、仕組みを整えるといったことが
    大事なのだと思いました。
    ということで、私の情報収集の方法をまとめてみようと思いました。

    • まず興味をもつこと
    • その情報を持っている知り合いを増やす
    • 情報収集する仕組みを構築する

    まず興味をもつこと

    例えば、AKB48の名前を覚える場合について。
    • AKB48のメンバーが出てるドラマを見る
    • => その娘の名前を覚える
    • => その娘の出ているテレビや雑誌などに目がいくようになる。
    • => blogやtwitterをチェックするようになる。
    • => blogやtwitterで他のメンバーの話が出てくるので、その娘も覚えるようになる。

    ここで、全くその娘を知らない場合は、
    例えば本屋で雑誌の表紙を見ても、素通りしてしまいましが、
    知っていると「あ、あれに出てたあの娘だ」と頭に引っかかるようになります。
    スタート地点はまず興味を持つことです。
    どうしても興味を持てない場合は、もうあきらめましょう。

    その情報を持っている知り合いを増やす

    共通の趣味/関心を持つ知り合いは重要です。
    同じ関心を持つことで、
    自分が知らない情報を知ることができます。
    (ちなみに関心がない情報はいくら聞いても記憶に残らないものです。)
    Androidの便利なアプリとかは、
    Geekな先輩に教えてもらったりしています。
    (先日はAndroid標準の連絡先アプリが便利と教えてもらいました。)

    AKBファンはどうだか知りませんが、
    大学生のときにモー娘。のコンサートに行ったときは、
    いっぱいグループがあって情報交換をしているのを見ました。
    好きなメンバーのプロフィールとか、スケジュールとか、グッズの情報とか。
    そうやって、情報収集しているんですね。

    情報収集する仕組みを構築する

    情報を効率翌週収集する仕組みを構築します。
    まずはインプットです。
    インプットはやっぱりGoogleReaderです。
    RSSをとにかく購読して、
    GoogleReaderで一気に読んでいきます。
    RSSはタグで整理しておき、タグごとに読んでいきます。
    GoogleReaderはスクロールすれば読んだことになるので、
    興味がない記事はタイトルと1、2行だけ読んでスクロールしてしまいます。
    読みたい記事は、自分は「Read It later」に入れておいて、後でiPadで読みます。

    twitterも情報収集に使えます。
    ただ、TLを眺めているときりがないので、
    リストを活用します。

    次にアウトプットです。
    インプットだけでなく、できる限りアウトプットをして自分の頭の中を整理したり、記憶を強化するのは重要です。
    すべてEvernoteに書いていきます。
    本を読んだときのメモや、講演会・勉強会のメモ、気になったこと等は、
    すべてEvernoteに書いておきます
    書いたことは、電車の中など時間があるときに、XperiaやiPadを使って読んでいます。
    もう一度読み返すことによって、頭の中を整理します。
    週末にEvernoteに書いたものを整理します。

    ある程度まとまったら、
    スライドにまとめて、発表資料にしてしまいます。
    昔、私がいた部署では、研修等に行ったときに課定例でそのフィードバックのための発表をする機会をもうけてもらっていました。
    スライドを作っていると、頭の中でもやもやしたものが整理されます。
    わからないところ、わかったつもりになっていたところがはっきりします。
    わからないところは、調べ直して整理できます。

    と偉そうに書きましたけど、
    自分もまだ試行錯誤の状態です。
    もっとブラッシュアップしておこうと思います。

    2010年5月30日日曜日

    NHK技研公開2010に行ってきました。

    NHK放送技術研究所とは、放送全般を扱う唯一の研究機関であり、
    その技研が年に1回研究成果を公開する「技研公開」を行います。
    今回、私も当日の思い付きですが、せっかくなので行ってきました。

    目玉はスーパーハイビジョンっぽかったですが、
    そのほかにも放送と通信の連携から画像処理、信号処理と幅広い内容を扱っています。

    特に度肝を抜いたのが、シアターでのスーパーハイビジョンの実演。
    大スクリーンでの3300万画素の映像と、
    22.2chの音響システムはすごかった。。。
    東京マラソンの映像は、
    ランナー1人1人の顔がはっきりみえて、
    アスファルトに跳ね返る雨粒もよくわかりました。

    あとは、インテグラル立体テレビ。
    インテグラル方式とは、小さいレンズをたくさん並べて立体映像を録画、再生する方式のようで
    メガネをかけずに3次元映像が楽しめるということで
    体感してきました。
    いろんな角度から除いても立体映像が見え、これを専用メガネを使わずに実現できるのはすばらしいと思いましたが、
    だいぶ画像がぼやけているのが気になりました。
    これは今後改善されるのかな?

    ただ、これらの技術はもう人間のキャパシティを超えつつあるのかなとも思いました。
    こんなに高精細な画像は長時間眺めるのは相当疲れるだろうなというのが正直な感想です。
    例えば、報道番組やらバラエティやらはこんなハイスペックなものはいらないわけですし
    あったらいいなと思うのは、スポーツぐらいでしょうか?
    映画も映画館に見に行けばよいので、これを一般家庭で楽しめるようにすべきかはちょっと疑問です。

    個人的に興味があったのは、放送通信連携系。
    特に携帯電話との連携は面白かったです。
    デモでは、テレビに表示させたQRコードを用いてログインし
    携帯電話から番組を探して表示させることを行っていましたが、
    例えば、面白い番組を携帯に受信して友達にメールで進めてみたりとか、
    テレビショッピングを携帯電話の課金システムで行うといったことが
    実現できるなと思いました。

    また、番組の推薦サービスと連携させて、
    携帯電話の情報を使って番組推薦も叶になると言ってました。
    携帯電話は個人のプロファイル情報がたくさんありますから、
    これを利用できれば面白いことがいっぱいできそうです。

    資料は技研公開のページに置いてあったので
    詳しくはそちらを見ていただければと思います。
    http://www.nhk.or.jp/strl/open2010/index.html

    2010年5月5日水曜日

    twitterのつぶやきをmixi日記に投稿するスクリプトを作ってみたけど…

    twitterの前日のつぶやきをまとめてmixiの日記に投稿するスクリプトを書きました。
    mixiの日記投稿のAPIは公開されていナイっぽいので、
    こちらを参考にさせていただきました。

    mixi for iPhoneから発掘されたmixi日記投稿用API

    以下がコードです。今回はPerlを使いました。

    use strict;
    use warnings;
    use LWP::UserAgent;
    use LWP::Authen::Wsse;
    use HTTP::Request::Common;
    use XML::DOM;
    use Encode;
    use Date::Parse;
    use DateTime;
    use utf8;


    my $entry = "";
    my $title = "";

    my $ua = LWP::UserAgent->new;

    my $req = HTTP::Request->new('GET', "http://twitter.com/statuses/user_timeline.xml");
    $req->authorization_basic('(★twitterのユーザ名を入れる)', '(★twitterのパスワードを入れる)');
    my $res = $ua->request($req);
    if ($res->is_success) {
        my $parser = new XML::DOM::Parser;
        my $doc = $parser->parse($res->content);
        my @status = $doc->getElementsByTagName('status');
        my $t_dt = DateTime->today;
        my $prev_day = $t_dt->day - 1;
        $title .= "  " . $t_dt->year . '/' . $t_dt->month . '/' . $prev_day;
        $title .= encode('utf8', "のつぶやき");
        foreach (@status) {
      my @children = $_->getChildNodes;
      my $text;
      my $dt;
      foreach (@children) {
          if ($_->getNodeType() == ELEMENT_NODE) {
        if ($_->getTagName() eq "text") {
            #$text =  encode('shift_jis', $_->getFirstChild->toString);
            $text =  encode('utf8', $_->getFirstChild->toString);
        } elsif ($_->getTagName() eq "created_at") {
            my $epoch =  str2time($_->getFirstChild->toString);
            $dt = DateTime->from_epoch(epoch => $epoch);
        }
          }
      }
      if ($dt->year == $t_dt->year && $dt->month == $t_dt->month && $dt->day == $t_dt->day-1) {
          $entry .= "  " . $dt->year . '/' . $dt->month . '/' . $dt->day;
          $entry .= " " . $text . "\n\n";      
      }
        }
    } else {
        print "error";
        exit;
    }

    my $id = '(★mixiのログインメールアドレスを入れる)';
    my $pass = '(★mixiのパスワードを入れる)';
    my $member_id = (★mixiのメンバーidを入れる);

    my $ua2 = LWP::UserAgent->new;
    $ua2->credentials('mixi.jp:80', '', $id, $pass);

    my $content = <<__XML__;
    <?xml version='1.0' encoding='utf-8'?>
    <entry xmlns='http://www.w3.org/2007/app'>
      <title>$title</title>
      <summary>$entry</summary>
    </entry>
    __XML__

    print $content;

    $res = $ua2->post(
      "http://mixi.jp/atom/diary/member_id=$member_id",
      'Content-Type' => 'application/atom+xml',
      'content' => $content,
         );

    warn $res->content unless $res->code == 201;


    使ってみて思ったのが、
    twitterは日ごろ、その瞬間に思っていることを気軽に投稿するものなので、
    1日まとめてしまうと、なんだか、まとまらないものになってしまいます。

    日記なんかは内容をきちんと考えて文章をまとめますが、
    twitterはそんなことを考えません。

    このようなtwitterをmixiに投稿するスクリプトを常に回してしまうと、
    逆にtwitterのつぶやきを日記に公開することを前提として考えながらつぶやいてしまうので、
    twitterのメリットがなくなってしまいます。

    ということでこのスクリプトはお蔵入りです。

    2010年5月1日土曜日

    [メモ]モバイルについて思うこと

    なんだか、
    今までのPC向けウェブサイトのノウハウを
    モバイル向けにどうやって当てはめようみたいな話を聞いたので、
    「それちょっと違うんじゃないのかな。」と思ったので、メモ。

    携帯電話にはQRコードやFeliCaで
    直接サイトに誘導できるので、
    そういった方法でサイトに誘導する方法で十分で
    検索サイトについて考えるのは不要だと思います。
    (もちろん、それでサイトを見に行ってもらえなければ意味がないのですが)

    そしてQRコード等で誘導したサイトから
    ウィジェットなり、iPhoneアプリ/Androidアプリといった専用アプリを用意して
    インストールしてもらうようにします。

    あとは、
    ゲームや最新情報を配信したり、クーポンのような特典をつけたり、
    アプリを通して魅力的なコンテンツを提供していくのがいいのではないかと思います。
    モバイル向けには
    この専用アプリを魅力的に作る方法を追求していくべきだと思います。
    これは、今までのPC向けのウェブサイトのノウハウとは違うと思います。

    といってもここら辺の分野は私は素人なので、
    もう少し勉強してまとめようかなと思います。
    上記もきちんと調べたわけではなく、ただの印象や思い込みも含まれているので、
    あしからず。

    2010年4月7日水曜日

    正しい設計とは何か

    最近は仕事で設計レビューや実装レビューをよく行っているのですが、
    「ん?なんだこのクラスは?」
    「どうしてこのクラスは相互参照する必要があるのか?」
    「参照が循環している・・・。」
    といったものをよく見かけます。

    こういうのって最初は気をつけるんですが、
    どんどんクラスを足していくうちに本人ん気がつかないうちに
    入り組んだ構造になってしまうようです。

    正しい設計とは、私が思うに、
    • きちんと責任を明確にしてモジュールに分割する
    • モジュールの中でまた責任ごとにクラス分割する
    • モジュール間・クラス間は疎結合
    をきちんと守ることだと思います。

    相互参照していたり、
    ダイヤモンドのような構造になっていたり、
    入り組んでいたりするとやっぱりどこか責任が明確になっておらず、
    一つのクラスで2つの役割があったりします。
    (もちろん原則で、例外もあります。)

    クラスの参照が入り組んでいると、そのまま実装すると
    とたんにソースコードが読みづらくなります。
    で、そういう場合はたいてい機能が独立していないので単体テストもしづらくなります。

    設計しているときは、
    常にモジュール・クラスの責任を意識しながら設計すべきだと思います。
    「リソースの取得がいろんなところに分散している。」
    「なぜこのクラスはリソースの取得とデコードの両方やっているの?」
    みたいなことがあったら、もう一度、構造全体を見直すべきだと思います。

    といっても、原則がわかっていても、なかなか実践できないものです。
    やはり「デザインパターン」の本を読んだりして普段から勉強することと、仕事上でトライアンドエラーを繰り返して
    スキルアップを図っていくしかないのかなー、思います。




    2009年8月16日日曜日

    モジュール性



    ちょっと調べたいことがあって
    メイヤーの『オブジェクト指向入門』を読んでいたら、モジュール性の5つの基準が書いてあった。
    以下抜粋。
    • 分解しやすさ
    • 組み合わせやすさ
    • わかりやすさ
    • 連続性
    • 保護性

    お、こんなの知らなかったぞ(汗

    で、分解しやすさの説明に(抜粋)
    • 依存関係は最小限に抑えなければならない。そうしなければ、個々のサブシステムの開発がほかのサブシステムの作業の進み具合によって限定される可能性がある。

    うぅ、なんだか耳が痛い話。

    ほかにも再利用性とか、いろいろためになる&&できていないはなしがちらほら。

    分厚い本なので、調べモン程度にしか使わなかったけど、こりゃ一回通読しておいたほうがよさそうだな。

    2009年7月23日木曜日

    1日1ハック

    最近全然更新していませんでしたm(_ _)m


    さいきんちょっと仕事で疲れてプライベートでコードを書いていませんでした。


    Rubyのまつもとゆきひろさんは1日1ハックを必ず行うと

    前に聞きに行った講演会で言ってましたが、
    これを守るのはかなり大変だなと実感しています。

    でも、どんなに疲れていても自分の技術は磨いていかないと、
    衰えていく一方なので、今日から頑張ろうと思います!!

    2009年5月19日火曜日

    開発プロセス

    今あるプロジェクトで後悔していることが一つ。
    • きちんと疎結合になるように設計すること
    • テスト容易性を考えること

    を徹底するようにもっと強く言うべきだった。。。。
    若手の私は、どうしても強く言われると議論に負けてしまう。。。


    もちろん、書籍で読んだ知識は理想論で、
    経験を多くすることにより、現実的なところの落とし所を見つけられるようになると思うんだけど、
    なんだか、開発プロセスとかを武器にして、自分の都合がいいように理論武装をしている人が
    多いような気がする。。。

    もっと勉強せねば!

    もっと強くならねば!

    2009年3月24日火曜日

    Google Data API

    Google Data APIを勉強しています。
    Google Data APIとは、Googleのサービスをブラウザを使わずに、APIを叩くことによって利用するもので、
    簡単にいえば、HTTPのコマンド(GET/POST/PUT/DELETE)でATOM/RSSのやり取りを行います。

    youtubeとかPicassaとかでも使えるので、いろいろ面白いことを試したいなと思っています。