A-Listers

140字に収まらない海外テックネタヘッドライン

Posts Tagged ‘プログラミング

DevArt – プログラミングによるアートをGoogleが紹介

leave a comment »

DevArt__Art_made_with_code_

NHKでのテレビ放送などもあり、アートにおけるプログラミングという分野に出会った方も多かったのではないでしょうか。Googleは以前からこのような分野を紹介するサイトを解説しており、さまざまな作品が集まりコンペティションも行われています。

サイトによるとDevArtとは次のように説明されています。

DevArtは新しいアートの一種です。創造性とテクノロジーの可能性を追求する開発者によってコードによって制作されます。彼らはイノベーティブなデジタルアート作品を作るために、テクノロジーをキャンバスに、コードを素材として用います。

実際のところは動画を見るのがわかりやすいです。

こちらはトップページからリンクされている作品。

こちらはfladdictさんの作品。

サイトでは使われている技術を基準にして作品を検索することもできます。たとえばAPIであったり、

DevArt__Art_made_with_code_

プログラミング言語だったりします。

DevArt__Art_made_with_code_

プログラミングによって制作するもはアプリやサービス、ゲームに限らず「アート作品」という選択肢もあると考えるとコードを書いてみようかなと思う機会が増えるかもしれません。

via:Hacker News

Written by yandod

2014/05/13 at 11:23

カテゴリー: Uncategorized

Tagged with , ,

プログラミング言語PHPの公式サイトがリニューアル

with one comment

PHP__Hypertext_Preprocessor-2

識者の間では知られていましたが、プログラミング言語PHPのWebサイトがついにリニューアルされました。新しいデザインは数年前からプレビューやここ数ヶ月のベータ版などの運用をへてついに適用された形です。リリースノートは下記のように綴っています。

美観上のポイントとしてはカラースキームはかつての暗紫色から明るくなりました。またボーダーやリンクはシンプルな紫を使った一貫性を保っています。フォントもスムーズになりコントラスト、ハイライトも改善されました。とくに関数リファレンスページやコード例はより読みやすくなりました。
これらのテーマはHTML5とWebFont、Bootstrapを使いよりモダンになっています。

関数リファレンスページ

PHP__date_sunset_-_Manual-2

コード例

PHP__利用例_-_Manual

またレスポンシブにあった事でスマートホンでもそれなりの見た目で見れるようになったようです。
ということで新しいデザインになったPHPのWebサイトにみなさん慣れ親しんで頂ければと思います。

via:http://php.net/

Written by yandod

2013/11/30 at 12:55

カテゴリー: Uncategorized

Tagged with

Hoodie – noBackend実装のJavaScriptフレームワーク

leave a comment »

Hoodie-2

進化の早いJavaScript界隈に新しいアプローチのフレームワークが登場しました。Jan Lehnardt氏が中心になって開発されているHoodieはフロントエンドとバックエンドを完全に分離する事でそれぞれの開発効率を最大限にするnoBackendの実装の一つです。Hoodieはサーバーサイド用のモジュールとクライアント用のライブラリの2つから成っており、サーバーサイドが起動している状態であればクライアント側からは例えば下記のコードだけでユーザの登録ができます。

hoodie = new Hoodie('http://localhost:6007/_api');
hoodie.account.signUp('joe@example.com', 'secret');

すでに登録されたデータを取得する場合は下記のようになります。

var type = 'task';
hoodie.store.findAll(type)
  .done(function (tasks) {
    // Do something with the tasks
  });

またHoodieはオフラインデフォルトという設計になっており、データはローカルに保存されてからバックグランドで転送されるようになっています。これによりモバイルアプリケーションなどで快適に動作するようになっています。
クライアントライブラリとサーバーサイドモジュールのセットで構成されたこのプロジェクトを「フレームワーク」と呼んでいいのかは少し迷ったところなのですが、どのような実装ができるのかを見たほうがわかりやすいでしょう。

またnoBackendのAPIを再実装すれば別の言語とデータベースを使いつつ、同一のクライアントライブラリを利用するという未来もありえそうです。現時点ではAngularJSとRESTの組み合わせの方が優勢かと思いますが、ユーザ登録やメール送信といったハイレベルな機能を定義した標準的なAPIが定着するとさまざまな問題が少なくなるのではないでしょうか。

関連:
Hood.ie: "noBackend & Off-line first" という考え方 – ワザノバ | wazanova

via:http://hood.ie/

Written by yandod

2013/11/19 at 11:40

綺麗な設計を身に付けるためのSandi Metzルール

with 6 comments

スクリーンショット_2013_05_20_9_54
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。

このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。

そのルールは以下の通りです。

  1. クラス内のコードが100行を超えてはならない
  2. メソッド内のコードが5行を超えてはならない
  3. 4つより多い引数をメソッドに渡すようにしてはならない(ハッシュによるオプションもパラメーターとみなす)
  4. コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる
    • ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる(@object.collaborator.valueは許可されない)

項目は少ないですが、方向性としてはThoughtworksアンソロジーという書籍で紹介されていた「オブジェクト指向エクササイズ」に通じるものがあります(あちらはJavaが主な対象でした)。

4つのルールとは別に、このルールを破ってもよい場合として、

  • 適切な理由があると考えられる場合
  • ペアプログラミングのパートナーやコードレビュアーが許可した場合

がルール0として挙げられています。

thoughtbotでは実際のプロジェクトにこのルールを適用してみたそうで、以下のような知見が得られたようです。

  • ルール1 クラス内のコードが100行を超えてはならない
    • Single Responsibility Principle(単一責任の原則)を徹底するようになる
    • テストも100行以内に収めることを心がけたことで、1つのファイルで多くの機能をテストしすぎていたものを、よりフォーカスの定まった個別のテストに分割できた
  • ルール2 メソッド内のコードが5行を超えてはならない
    • メソッドを5行に収めるために、elseelsif「if〜else〜elsif〜end」のようにelseとelsifを合わせて使うことを避けるようになった(コメントで誤訳のご指摘をいただきましたので修正します。原文の意図は、if〜else〜endやif〜elsif〜endは使うけども、それらの組み合わせは5行を超えてしまうので使わない、ということのようです)
    • 条件分岐で1行を使うのではなく、適切な名前のついたプライベートメソッドを作ってそれを呼ぶようになった
    • コード片をプライベートメソッドとして抽出することで、命名が行われ、説明としても役立つようになった
  • ルール3 4つより多い引数をメソッドに渡すようにしてはならない(ハッシュによるオプションもパラメーターとみなす)
    • Railsのビューヘルパーメソッドはとても多くの引数を要求するため、よい解決法が見つからない場合は、ルール0に立ち返り引数をそのままとした

ルール4については、実際のコードを例に詳しく説明がされています。

ルール4を適用すると、1つのコントローラーが1つのオブジェクトだけをビューに引き渡すように設計することになりますが、実際のプロジェクトでは必ずしも1つのコントローラーが1つのものを表示するとは限りません。

例えば、「トップページにアクティビティフィードと通知の数を表示する」といったようなケースも頻繁にありえます。thoughtbotではこのようなケースにFacadeパターンを適用し、アクティビティフィードと通知の数を内包したダッシュボードクラスを定義することで、コントローラーとビュー間のやり取りを単純化させることにしたようです。

詳細は、実際のコード例を見れば一目瞭然だと思いますので、ぜひ元のブログ記事も参照してみてください。

Written by junya

2013/05/20 at 11:56

カテゴリー: Uncategorized

Tagged with ,

Git SubmoduleのトラブルをGit Subtreeで解決できると知っていますか?

leave a comment »

gitsub

ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。

  • ワークフローがシンプルなので管理が簡単。
  • 古いバージョンのgitもサポートしている。(v1.5.2ですら。)
  • サブプロジェクトのコードがcloneした直後に利用できる。
  • subtreeはユーザに新しい学習を要求しない。subtreeを依存性の解決に使っていることは無視する事ができる。
  • subtreeは新しいメタデータファイルを追加しない。例えばsubmodules が追加する.gitmoduleのようなファイル。
  • モジュールの内容を別のリポジトリのコピーなどを他所に持たなくても編集できる。

もちろん、git subtreeを使う事への代償もありますが、これらは受け入れられるというあろうとして、下記のように挙げています。

  • subtreeをマージする戦略について学ぶ必要がある。
  • サブプロジェクトのアップストリームにコントリビュートするのはやや複雑になる。
  • 親プロジェクトとサブプロジェクトのコミットを混ぜないようにする責任は自分自身にある。

具体的な利用例は元記事の残りを見て頂くとして、subtreeがsubmoduleを使う場合によくある問題をクリアしていることがわかります。基本的には新たなremoteを追加して別々にmergeしていくだけなのでブランチの管理のような感覚で利用できるという事でsubmoduleを避けてわざわざコピーしてしまったような場合はsubtreeの利用を検討してはどうでしょうか。

via:http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

Written by yandod

2013/05/17 at 09:05

カテゴリー: Uncategorized

Tagged with

16の言語と57のフレームワークを比較したベンチマークが凄い

with one comment

bench

いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。

気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。

Round 4 results - TechEmpower Framework Benchmarks

堂々のトップに輝いているのはServletで最大で1秒間あたり7,344レスポンスの凄まじい結果を叩きだしています。また2位に入っているgeminiはこのベンチマークを実行しているTechEmpower社の社内フレームワークとの事です。PHP(秒間あたり最大2,262レスポンス)やRails(秒間あたり最大461レスポンス)などスクリプト言語が下位に甘んじていますが、1台のEC2インスタンスが稼ぐ性能としてはそれでも充分なような気がします。1秒間に7,344レスポンスということは1日あたり6億以上のレスポンスをたった1台のサーバで返すわけです。逆に秒間100レスポンスであっても1日あたり864万レスポンスですよね。

その他テスト結果を見ていると気がついた点をいくつか挙げておきます。その他の結果も膨大ですので是非元の記事も併せてご覧になってください。

  • gemini servlet go などは安定して上位入り
  • Symfony Cake Fuel Sinatraなどが下位集団に居る事が多い(それでも秒間200〜1000レスポンスを処理しています)
  • 只のphpは常にフレームワークよりも高速
  • RailsはSinatraよりも高速Railsの方がSinatraよりも高速な場合もある
  • Node.jsはServletに対して30%〜80%程度の性能

ベンチマークというと「〜〜はこんなに遅くない」的な意見が良く出がちですが、最下位であっても秒間数百レスポンスを処理しているので通常の利用では低速とは言えないでしょう。(もし気になる点があればGitHub上でテストコードにプルリクエストを送りましょう)

一方でフルスタック系のフレームワークや軽量フレームワークなどの速度が大きいケースや逆にrailsとsinatraの用に逆転しているケース、仮想環境と実マシンで結果に開きがあるケースなどがある点が興味深いのではないでしょうか。ご覧になった皆さんも気づいた点があれば是非ツイートやコメントでお寄せください。

via:http://www.techempower.com/benchmarks/#section=data-r4

Written by yandod

2013/05/06 at 19:37

API設計に関する10のワーストプラクティス

leave a comment »

Top 10 API Worst Practices

過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか? Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。

  • 貧弱なエラーハンドリング
  • HTTPのルールを無視したREST API
  • 裏に潜んだ生のデータモデルの露出
  • セキュリティの複雑さ
  • ドキュメント化されていない予期せぬリリース
  • 貧弱なデベロッパエクスペリエンス
  • MVCフレームワークが良いAPIにしてくれるという思い込み
  • 開発すれば使ってもらえると見なすこと
  • 不十分なサポート
  • 貧弱なドキュメンテーション

APIを利用するだけでなく、APIを提供する場合に上記のようなポイントを気に留めておくと役に立ちそうです。

via:http://blog.programmableweb.com/2012/08/03/top-10-api-worst-practices/

Written by yandod

2013/01/11 at 16:45

カテゴリー: Uncategorized

Tagged with ,

%d人のブロガーが「いいね」をつけました。