A-Listers

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

Posts Tagged ‘プログラミング

37signalsはベータサーバーを本番環境のデータベースに接続している

leave a comment »

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」のように変えることで、シンプルに運用しているようです。

このようなスタイルの運用で気になるのが、データベースマイグレーション(スキーマの変更など)をどのように適用するか、というところだと思います。

それについてはコメント欄でいくつかやりとりがされていて、基本的には、

  • 本番データベースに接続されたステージング環境でマイグレーションのテストを行う
  • その後、それを本番環境にもロールアウトする

という運用のようですが、この際、ステージング環境が接続する本番データベースというのが、本番データベースの複製なのか実際に運用しているデータベースそのものなのかについては残念ながら言及がありませんでした。

個人的にはかなりアグレッシブな運用だと感じたのですが、データベースマイグレーションを注意深く行うようにすればアリなのかもしれませんね。

Written by junya

2012/09/21 at 12:00

猛烈にオシャレなRails女子コミュニティ Rails Girlsのビデオ

leave a comment »

フィンランド発祥のRails女子コミュニティ、Rails Girlsがすごくオシャレです。トップページのスケッチ風のイラストにはよく見るとオクトキャットらしきものがいたり、ロゴもかわいらしいです。そしてなによりびっくりしたのが4月にベルリンで開催されたイベントのレポート動画です。

Rails Girls Berlin 2012 from Alexander Lang on Vimeo.

冒頭のタイピングから参加者のインタビューとオシャレな雰囲気が漂いまくりです。また参加者の中にはプロダクトマネージャーや学生など、普段コードを書かない立場の人がRailsを学びに来ているというのも面白い点です。同様のコミュニティとしてPHPWomenというのもあるのですが、これは日本版をやるなら女子会といったところでしょうね。

Written by yandod

2012/08/09 at 16:58

カテゴリー: Uncategorized

Tagged with ,

Stack Overflow発 プログラミングの隠語(ジャーゴン)30選

with 3 comments

お馴染みの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(バクラヴァコード)

Baklava - Turkish special, 80-ply.JPEG

トルコのミルフィールのような菓子。レイヤーが多すぎる事。

15. Hindenbug(ヒンデンバグ)

ヒンデンブルグ号の爆発事故のように悲劇的なデータ消失を引き起こすバグ。

16. Fear Driven Development(恐怖駆動開発)

解雇、締め切りの前倒し、リソースの削減などのプレッシャーが管理者から加えられる事。

17. Hydra Code

不死身のヒドラのように直せないコード。1つバグを直すと新しく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

via:Coding Horror: New Programming Jargon

Written by yandod

2012/07/25 at 11:42

カテゴリー: Uncategorized

Tagged with ,

喜びの多いプログラミング言語はObjective-CとPHPと判明

leave a comment »

いやいやもっと楽しい言語あるでしょ?と思った方にとっても興味深い調査結果がExploring Expressions of Emotions in GitHub Commit Messages(GitHub上のコミットメッセージの感情表現の調査)として公開されていました。記事の作者はベルリンのRamiro Gómezさんで、自然言語とプログラミング言語の双方に関心のある彼はGitHubが公開した統計情報からさまざまな感情表現をコミットメッセージから探して分析するという調査を行いました。これによりanger(怒り), joy(喜び), amusement(楽しみ) surprise(驚き)の表現が多く使われているプログラミング言語のランキングを生成して公開しています。

怒りの言語はVimL、C、Shell


怒りのランキングではangry(腹を立てる)、annoying(いらいらする)、cranky(酷い)、hate(嫌い)といった単語を抽出し、結果的には2位にダブルスコア近い差をつけてVimLがトップに輝いています。次いでCやShellなどもインストーラーが全てのファイルを削除するといったクリティカルな問題に発展しそうな気配があり、そういうものなのかなという気がします。
しかし何故VimLの人たちが際立って怒っているのかは謎です。

喜びの言語はObjective-C、PHP、Perl


続いて喜びのランキングではyes、yay(やった)、bingo(それだ)、glad(うれしい)といった単語を抽出しObjective-CとPHPが際立って高い結果になっています。どちらもプログラミング言語としては理路整然という訳ではない部分もありそうですが、動く物を作るという行為には直結していそうなイメージがあり、ものづくりを楽しんでいる雰囲気が現れているのかもしれません。
本文では触れられていませんが、怒りの言語でトップであるVimLが最下位に入っている点も見逃せません。

楽しみの言語はRuby、C#、Java


楽しみのランキングでは、lol(笑)、rofl(爆笑)といった笑いのスラングを抽出したところ、RubyとC#が際立って高い結果になっています。また本文では触れられていませんが、怒りの言語の王様であるVimLが最下位にまたしても入っている点も見逃せません。
Rubyが上位に入っているのはコミュニティの発展がGitHub上で達成されているという事なのかもしれません。

驚きの言語はPerl、Objective-C、C


驚きのランキングではgosh(おやっ)、stumped(当惑)、surprised(驚いた)などの単語を抽出し、PerlとObjective-Cが高い結果になっています。またC++とPHPは下位に沈んでいます。

罵りが多い言語はVimL、Objective-C、C


所謂、Disり合いについても分析が行われ、ここではいわゆる罵倒表現達(wtf等)を抽出しています。堂々のトップに輝いているのはVimLです。また意外にもPHPは下位に沈んでいます。なお例として抽出されたコメントが例示されているのですがこの項目についてはとてもストレートな感じでわかりやすいです。

プログラミング言語の人気というのはなんとなく感じる部分はありますが、こういった分析は各言語の成熟度や使われるシチュエーションについて想像する助けになりそうです。この調査の為のコードもGitHubで公開されていますので、フォークして日本語のメッセージで分析したり別の観点のレポートを作ってみるのも面白いかもしれません。
またVimLユーザの怒りの理由についての情報もお待ちしております。

via:http://geeksta.net/geeklog/exploring-expressions-emotions-github-commit-messages/

Written by yandod

2012/06/14 at 11:55

カテゴリー: Uncategorized

Tagged with , ,

ソ連の宇宙開発で使われていたプログラミング言語は?

with 2 comments

stackexchange.com上のソビエトの宇宙開発でどんなプログラミング言語が使われているのか?という話題で興味深い議論が展開されています。

投稿者は「ソビエトの宇宙開発プログラムの宇宙船ブランでProLogが使われていたのを知りましたが、それ以前でどのようなプログラミング言語が使われていたのか誰か知りませんか?」という質問を投稿します。

それに対して「ソース出せ」というツッコミがつくと、投稿者は公開されたCIAの調査資料にProLogが使われていたと記載があったと返信します。

その後の回答で最も支持されているのはロシア語の書籍「 First computers for space applications (Герман Носкин, Первые БЦВМ космического применения)」を持っている方からの回答です。著者自身が宇宙開発に参加していたという事もありかなり貴重な情報が紹介されています。

  • 70年代まではデジタルコンピュータは使われていなかった
  • 最初に使われたコンピュータはSalut-4でソ連で利用されていたコンピュータと互換性がありPL-1とFortranが使えた
  • またブランでは3つの言語が使われていたとの言及がウェブサイトにあり、オンボード機器には PROL2、地上のテストにはDipol 、Laks がモデリングに使われた。
  • ブランプログラムが終わる頃、3つの言語はDrakonに統合された。

なんだか身近でない言葉がバンバン出てくるすごい話です。どうやら最終的に長く使われたDrakonも国際的に認知されておらず、情報がWikipediaにも無い状態との事です。インターネットが発達した現代でもアクセスできる情報はやはり英語のものがせいぜいで、それ以外の言語で書かれた知識は埋もれてしまっている事を考えさせれる出来事です。

via:http://programmers.stackexchange.com/questions/145669/what-software-programming-languages-were-used-by-the-soviet-unions-space-progra

Written by yandod

2012/06/07 at 09:33

カテゴリー: Uncategorized

Tagged with ,

Appceleratorの開発者が語るTitaniumとPhoneGapの比較

with 3 comments

iOSとAndroidのクロスプラットフォームなアプリケーションをする際に使われるTitanium MobileとPhone GapをTitaniumの開発元、Appceleratorの開発者Kevin Whinnery氏が比較した記事が話題になっていました。

Kevin氏は「上空1万フィートから見ればTitaniumとPhone Gapは似ているように見える。どちらもクロスプラットフォームでJavaScriptとWebの技術を要求し、オープンソースライセンスを採用している。しかし似ている所はそれぐらいしかない。どちらも思想や問題を達成する為のアプローチは異なっている」という書き出しで二つのプラットフォームがかなり異なっている事を強調した上でいくつかのポイントを比較しています。

Phone Gapについて

  • 実現する事
    HTMLベースのWebアプリケーションをネイティブアプリとして配布、インストールできるようにする。
  • ワークフロー
    HTML,CSS,JavaScriptを静的なサイトのようにローカルで編集する。ネイティブのツールセットは不要。
  • 動作原理
    各プラットフォームのWebブラウザコンポーネント(Web View)などを立ち上げ、作成されたHTMLを読み込んで表示する。
  • 拡張方法
    JavaScriptから呼び出されるインタフェースを作成し、そこから呼び出されるネイティブコードを作成して登録する。(How to Create a PhoneGap Plugin for iOS)
  • 強み
    Web Viewをサポートしていればどんな環境でも動作する。プラグインによる拡張がシンプル。
  • 弱み
    UIのクオリティがWeb Viewのクオリティに依存する。特にAndroidでは制限がある。ネイティブのUIを使った拡張ができない。

Titaniumについて

  • 実現する事
    クロスプラットフォームなJavaScriptランタイムとモバイル向けのAPIを提供する。
  • ワークフロー
    各プラットフォームのツールをセットアップした後にTitaniumのツールのみ使う。このツールをIDEから利用する事もできる。
  • 動作原理
    ネイティブコード上でJavaScriptの実行環境(iOSではJavaScriptCore、AndroidではデフォルトのV8またはRhino)が動作し、JavaScriptのソースコードを実行時に解釈して動作する。
  • 拡張方法
    UIを含む視覚的なコンポーネントも拡張できる。ネイティブ側、JavaScript側の双方から呼び出し可能なプロキシオブジェクトを実装し、ブリッジとして利用できる。
  • 強み
    高レベルなAPIが提供されていて、さまざまなネイティブの機能を利用できる。
  • 弱み
    新たな環境に対応させるのが難しく、iOS、Android、Webにしか対応していない。

元の記事はかなりの長文ですが、Phone Gapが本来はWebブラウザから利用できない機能(カメラやセンサーなど)を使えるようにするという機能はWebブラウザの機能そのものが強化されると意味がないものになる可能性があるなど、若干Titanium寄りに見える部分があります。また双方のプラットフォームの思想的な違いやビジネスモデルについても言及している部分がある点もユニークな内容です。
それぞれのプラットフォームの動作原理の解説は興味深い内容ですので読んでみて頂ければと思います。

さてみなさんはどちらのプラットフォームを使いますか?

訂正
Kevin氏を元開発者と表記しておりましたが、現在もAppceleratorの開発者であるとのご指摘を頂きました。訂正させて頂きます。誤訳により誤解を招いてしまい申し訳ありませんでした。

via:http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap

Written by yandod

2012/05/17 at 09:37

GitHub直伝 プルリクエスト活用の3つのコツ

with one comment

GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。
GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。

記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。

  • プルリクエストはなるべく早く起こす
    プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメントする事ができます。
  • プルリクエストはブランチからブランチで
    GitHubでは誰もgithub/githubのフォークを持っていません。同じレポジトリのブランチ同士でプルリクエストを行なっています。
  • プルリクエストはマージされなくてもよい
    プルリクエストは簡単に起こして、フィードバックを得たりブランチ上の進捗を追跡できる手段です。もしアイデアの中に良くない部分があればマージせずにプルリクエストを閉じればよいです。GitHubでもいつもそうしています。

GitHubを仕事に活用し、業務の中でプルリクエストを活用する人も増えてきていると思いますが「フォークを作らない事」「コード修正が終わる前のプルリクエスト」などは目新しいアイデアと言えるかもしれません。ブランチの管理などはみなさんも試行錯誤していると思いますが覚えておいて損はないTIPSと言えそうです。

記事中でも言及されているようにGitHubのメンバーが講演した際のスライドにもコードレビューをプルリクエストで行う方法について解説がありますのであわせてどうぞ。
How GitHub Uses GitHub to Build GitHub // Speaker Deck

via:https://github.com/blog/1124-how-we-use-pull-requests-to-build-github

Written by yandod

2012/05/05 at 09:00

カテゴリー: Uncategorized

Tagged with ,

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