Posts Tagged ‘プログラミング’
DevArt – プログラミングによるアートをGoogleが紹介
NHKでのテレビ放送などもあり、アートにおけるプログラミングという分野に出会った方も多かったのではないでしょうか。Googleは以前からこのような分野を紹介するサイトを解説しており、さまざまな作品が集まりコンペティションも行われています。
サイトによるとDevArtとは次のように説明されています。
DevArtは新しいアートの一種です。創造性とテクノロジーの可能性を追求する開発者によってコードによって制作されます。彼らはイノベーティブなデジタルアート作品を作るために、テクノロジーをキャンバスに、コードを素材として用います。
実際のところは動画を見るのがわかりやすいです。
こちらはトップページからリンクされている作品。
こちらはfladdictさんの作品。
サイトでは使われている技術を基準にして作品を検索することもできます。たとえばAPIであったり、
プログラミング言語だったりします。
プログラミングによって制作するもはアプリやサービス、ゲームに限らず「アート作品」という選択肢もあると考えるとコードを書いてみようかなと思う機会が増えるかもしれません。
via:Hacker News
プログラミング言語PHPの公式サイトがリニューアル
識者の間では知られていましたが、プログラミング言語PHPのWebサイトがついにリニューアルされました。新しいデザインは数年前からプレビューやここ数ヶ月のベータ版などの運用をへてついに適用された形です。リリースノートは下記のように綴っています。
美観上のポイントとしてはカラースキームはかつての暗紫色から明るくなりました。またボーダーやリンクはシンプルな紫を使った一貫性を保っています。フォントもスムーズになりコントラスト、ハイライトも改善されました。とくに関数リファレンスページやコード例はより読みやすくなりました。
これらのテーマはHTML5とWebFont、Bootstrapを使いよりモダンになっています。
関数リファレンスページ
コード例
またレスポンシブにあった事でスマートホンでもそれなりの見た目で見れるようになったようです。
ということで新しいデザインになったPHPのWebサイトにみなさん慣れ親しんで頂ければと思います。
via:http://php.net/
Hoodie – noBackend実装のJavaScriptフレームワーク
進化の早い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/
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。
このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。
そのルールは以下の通りです。
- クラス内のコードが100行を超えてはならない
- メソッド内のコードが5行を超えてはならない
- 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす）
- コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる
- ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる（
@object.collaborator.valueは許可されない）
- ビューは1つのインスタンス変数を参照し、そのオブジェクトに対するメッセージ送信のみを行うことができる（
項目は少ないですが、方向性としてはThoughtworksアンソロジーという書籍で紹介されていた「オブジェクト指向エクササイズ」に通じるものがあります（あちらはJavaが主な対象でした）。
4つのルールとは別に、このルールを破ってもよい場合として、
- 適切な理由があると考えられる場合
- ペアプログラミングのパートナーやコードレビュアーが許可した場合
がルール0として挙げられています。
thoughtbotでは実際のプロジェクトにこのルールを適用してみたそうで、以下のような知見が得られたようです。
- ルール1 クラス内のコードが100行を超えてはならない
- Single Responsibility Principle（単一責任の原則）を徹底するようになる
- テストも100行以内に収めることを心がけたことで、1つのファイルで多くの機能をテストしすぎていたものを、よりフォーカスの定まった個別のテストに分割できた
- ルール2 メソッド内のコードが5行を超えてはならない
- メソッドを5行に収めるために、
elseやelsif - 条件分岐で1行を使うのではなく、適切な名前のついたプライベートメソッドを作ってそれを呼ぶようになった
- コード片をプライベートメソッドとして抽出することで、命名が行われ、説明としても役立つようになった
- メソッドを5行に収めるために、
- ルール3 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす）
- Railsのビューヘルパーメソッドはとても多くの引数を要求するため、よい解決法が見つからない場合は、ルール0に立ち返り引数をそのままとした
ルール4については、実際のコードを例に詳しく説明がされています。
ルール4を適用すると、1つのコントローラーが1つのオブジェクトだけをビューに引き渡すように設計することになりますが、実際のプロジェクトでは必ずしも1つのコントローラーが1つのものを表示するとは限りません。
例えば、「トップページにアクティビティフィードと通知の数を表示する」といったようなケースも頻繁にありえます。thoughtbotではこのようなケースにFacadeパターンを適用し、アクティビティフィードと通知の数を内包したダッシュボードクラスを定義することで、コントローラーとビュー間のやり取りを単純化させることにしたようです。
詳細は、実際のコード例を見れば一目瞭然だと思いますので、ぜひ元のブログ記事も参照してみてください。
Git SubmoduleのトラブルをGit Subtreeで解決できると知っていますか？
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われている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/
16の言語と57のフレームワークを比較したベンチマークが凄い
いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。
気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。
堂々のトップに輝いているのは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
API設計に関する10のワーストプラクティス
過半数の開発者が平均で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/
37signalsはベータサーバーを本番環境のデータベースに接続している
David Heinemeier Hansson氏（Railsの開発者。以下DHH）が37signalsのブログに公開したRunning beta in productionというエントリによると、同社ではBasecampの開発に使われる6つのベータサーバーがすべて単一の本番環境のデータベースを参照して動いているそうです。
DHH氏曰く、「自分がいいアイデアだと思ったものが本当にそうなのかを知るには、実際のデータを対象に自分たちが日々使ってみることが必要」とのこと。
Basecampでは新機能や改良の開発、技術的なアップグレードなどを継続的に行なっており、そのために同一の本番環境のデータベースを参照する6個の異なるベータサーバーが運用されています。通常、開発中の機能は開発用のデータベースと共に運用するのがセオリーだと思いますが、DHH氏は「実際の重要なデータとともに不満を感じながら使わないかぎりは、そういった機能をきちんと評価することは不可能だと気づいた」とのことで、このような構成になっているそうです。
最初は、実際にサービスの運用に使っているものとは物理的に異なるサーバーに本番のデータを複製しているのではないか、とも思ったのですが、コメント欄にて「All beta envs and production share the same prod database.」という37signalsスタッフのコメントがあるので、やはり実際にサービスで利用しているデータベースにベータサーバーを接続しているということで間違いないようです。
また、6つのベータサーバーをどのように使い分けるのかの手順はシンプルで、どのサーバーでどのブランチのコードを走らせているかは、開発者が適宜、開発用のチャットルームのタイトルに反映させているそうです。ブログエントリに掲載されたスクリーンショットでは、以下のようなルームタイトルになっていました。
- staging: riakcs
- beta: project_templates
- b1: redis-resque-upgrade
- b2: tags-mini
- b3: bcx-ios-compose [reserved for bcx-ios]
- b4: email-in-phone
- b5: rails4
エントリではstagingの位置づけには触れられていませんが、それ以外のbetaからb5までのサーバーはすべて本番のデータベースに接続していると考えてよさそうです。
開発者は、ベータサーバーが必要なときはルームタイトルの「b1」の部分を「b1: redis-resque-upgrade」のようにサーバー名とブランチ名に書き換え、ベータサーバーでの作業が終わったら「b1: available」のように変えることで、シンプルに運用しているようです。
このようなスタイルの運用で気になるのが、データベースマイグレーション（スキーマの変更など）をどのように適用するか、というところだと思います。
それについてはコメント欄でいくつかやりとりがされていて、基本的には、
- 本番データベースに接続されたステージング環境でマイグレーションのテストを行う
- その後、それを本番環境にもロールアウトする
という運用のようですが、この際、ステージング環境が接続する本番データベースというのが、本番データベースの複製なのか実際に運用しているデータベースそのものなのかについては残念ながら言及がありませんでした。
個人的にはかなりアグレッシブな運用だと感じたのですが、データベースマイグレーションを注意深く行うようにすればアリなのかもしれませんね。
猛烈にオシャレなRails女子コミュニティ Rails Girlsのビデオ
フィンランド発祥のRails女子コミュニティ、Rails Girlsがすごくオシャレです。トップページのスケッチ風のイラストにはよく見るとオクトキャットらしきものがいたり、ロゴもかわいらしいです。そしてなによりびっくりしたのが４月にベルリンで開催されたイベントのレポート動画です。
Rails Girls Berlin 2012 from Alexander Lang on Vimeo.
冒頭のタイピングから参加者のインタビューとオシャレな雰囲気が漂いまくりです。また参加者の中にはプロダクトマネージャーや学生など、普段コードを書かない立場の人がRailsを学びに来ているというのも面白い点です。同様のコミュニティとしてPHPWomenというのもあるのですが、これは日本版をやるなら女子会といったところでしょうね。
Stack Overflow発 プログラミングの隠語(ジャーゴン)30選
お馴染みのCoding Horrorでプログラミングの隠語（ジャーゴン）についての記事が話題です。
このエントリの元になったのはStack Overflow上で行われた「あなたが新しく作ったプログラミングのジャーゴンはなんですか？(New programming jargon you coined?)」という質問です。この質問にはなんと386もの回答が寄せられ、その中でStack Overflowのコミュニティの投票で上位になった30のジャーゴンをリストにして解説したのがCoding Horrorの「Coding Horror: New Programming Jargon」という記事です。
下記がコミュニティによって選ばれたジャーゴンのリストです。
1. Yoda Conditions(ヨーダ条件式)
変数とリテラルを比較する際にリテラルを左辺に置く記述。スターウォーズのヨーダが「The sky is blue」ではなく「if blue is the sky」と喋る事から。
2. Pokémon Exception Handling(ポケモン例外処理)
全ての例外を捕まえようとする事。
try {
}
catch (Exception ex) {
// Gotcha!
}
3. Egyptian Brackets(エジプト人ブレース)
行の最後でブレースを開くスタイル。エジプト人のイラストの手の位置から。
if (a == b) {
printf("hello");
}
4. Smug Report(ドヤ顔レポート)
自分自身では大した事はしていないのにでシステムデザイン事がわかっているつもりの人によって投稿されるレポート。見当違いの詳細や（間違った）解決策の提案などが添えらている。
関連語としてDrug Report(ラリってるレポート)、Shrug Report(エラーメッセージなどが無く動かないとだけ書かれている)などがある。
5. A Duck
理由もなく追加され、不要な影響を避ける為に結局取り除かれる機能。
あるアーティストがアニメーションの制作に参加した際に、他のアニメーションに影響を与えないようにカモのキャラクターを追加した。プロデューサーによるデビューの際、プロデューサーからのコメントは「良いね、ただカモだけは取り除いてくれ」
6. Refuctoring(リファクトリング)
良いデザインのコードにしようとしてあちこち弄り回した結果、誰にもメンテナンスできないコードになること。
7. Stringly Typed(謎の型付け)
強い型付け(strong typing)のもじり。適切な型のパラメータを取ればよいのに、わざわざ独自の文字列を使ったりするなど。
8. Heisenbug(ハイゼンバグ)
それを調査しようとすると変貌したり消えたりするバグである。この名前は不確定性原理を提唱したハイゼンベルクのもじり。
ex) この名前は不確定性原理を提唱したハイゼンベルクのもじり。
9. Doctype Decoration
DoctypeだけHTML5でマークアップは滅茶苦茶といったような様子。
10. Jimmy
標準的な新人プログラマの名前。「もしジミー君が属性の更新をしなかったらどうなるでしょう？」というような例えに使う。
11. Higgs-Bugson(ヒッグスバグ粒子)
ヒッグス粒子 – Wikipediaのもじり。非常に僅かなログなどで存在すると仮定されるが、存在は確認されていないバグ。
12. Nopping
アセンブラなどで使う何もしない命令、NOP – Wikipediaから。昼寝(Napping)に似ているが寝ている訳ではない。
13. Unicorny
かなり初期の計画段階の為、まるで空想の出来事のように説明がつかない機能。
14. Baklava Code(バクラヴァコード)
トルコのミルフィールのような菓子。レイヤーが多すぎる事。
15. Hindenbug(ヒンデンバグ)
ヒンデンブルグ号の爆発事故のように悲劇的なデータ消失を引き起こすバグ。
16. Fear Driven Development(恐怖駆動開発)
解雇、締め切りの前倒し、リソースの削減などのプレッシャーが管理者から加えられる事。
17. Hydra Code
不死身のヒドラのように直せないコード。１つバグを直すと新しく2つのバグが発生する。
18. Common Law Feature
間違っているのにも関わらず、仕様の一部になってしまったバグ。
19. Loch Ness Monster Bug(ネス湖の怪物バグ)
再現性がなく、目撃者が1人しかいないバグ。
20. Ninja Comments
見えないコメント、秘密のコメント、またはコメントが無い事。つまりコメントが無い。
21. Smurf Naming Convention
全てのクラスに同じプリフィクスがついていること。
例：ユーザがボタンをクリックするとSmurfAccountViewがSmurfAccountDTOをSmurfAccountControllerへ渡す。
22. Protoduction(プロトダクション)
プロトタイプのまま世に出たもの。
23. Rubber Ducking
問題を誰かに説明していると自然と解決策が見つかる事があるので、アヒルのおもちゃに語りかけてみること。
24. Banana Banana Banana
あとでドキュメントを書く所に埋めておくテキスト。IDEの警告を回避する為にとりあえず埋める。
/// <summary> /// banana banana banana /// </summary> public CustomerValidationResponse Validate()
25. Bicrement
変数に1を加算する（インクリメント）ではなく2を加算する。
26. Reality 101 Failure
意図したとおりに動いているが意味のないコード。
27. Mad Girlfriend Bug(怒ったガールフレンドバグ)
明らかに何かが起きているかが、ログやメッセージは「何でもない」というバグ。
28. Megamoth(モスラ)
MEGA MOnolithic meTHod(一体化した巨大なメソッド)。2画面以上に渡っていたりする。
29. Hooker Code
アプリケーションのダウンなどを度々引き起こすようなコード。
30. Jenga Code(ジェンガ)
1ブロックでも変更すれば全体が崩壊しそうなコード。
ちなみにこの記事の元になった質問はStack Overflowのポリシーに反しているので現在、サイトからは削除されています。人気を博した事でサイトで見られるように削除を取り消すかどうかも議論されています。
参考:
新しいプログラミングのジャーゴン – YAMDAS現更新履歴
Island Life – New programming jargon
A-Listers 