2015年2月5日のブックマーク (6件)

  • 決めようぜ最高のプログラム言語を綱引きで :: デイリーポータルZ

    PHPがdisられる時代は終わった~っ! いくぜおまえら~!」「PHP!」「PHP!」(PHPはこの後一回戦で敗退しました) さる2015年1月29日。横浜大さん橋ホールで行われたエンジニア勉強会イベント「CROSS 2015」にて「第一回 プログラム言語対抗綱引き」が行われた。 コンピュータの世界を支えるプログラム言語がその至高性を競い腕力でぶつかる、言語間戦争に決着をつける大会である。 40人の勇者(プログラマー)により死闘を繰り広げたのはC、PerlPHPPythonRubyJavaScriptGoJava。 結果、Goの圧倒的勝利で幕を閉じたのだった。あらためて記事でその全貌をレポートしていこう。 知ってた? 綱引きの掛け声の「オーエス」ってあれ、「OS(オペレーションシステム)」のことなんだぜ? 英語版もご用意しております! English article↓↓↓

    hatajoe
    hatajoe 2015/02/05
    なにこれおもろい(笑)
  • GitHub Issueはテンプレート化で、綺麗に書かせる! - Qiita

    まず、クリックしてみてください Issue作成はこちら GitHubのIssueは、URLにparamsを渡すことで、デフォルトのvalueが入れられます。 ※paramsの渡し方は、/issues/new?title=test&body=contentのようにします。 バグ報告はこちらとかアイディア投稿などのリンクをREADMEなどに置き、みんなそれに従ってIssueを作成してもらいましょう。 指定できるparams 指定できるパラメーターは以下です。 params一覧 title body assignee labels milestone ※ラベル、マイルストーンはcontributorsのみ使用可能 文字列のエスケープ URLに入力するので、改行コードなどをエスケープする必要があります。 文字 エスケープ後

    GitHub Issueはテンプレート化で、綺麗に書かせる! - Qiita
    hatajoe
    hatajoe 2015/02/05
    知らんかった。これは良いかも!
  • GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita

    はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です! 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは

    GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
    hatajoe
    hatajoe 2015/02/05
    良い。
  • [iOS]アプリに強制アップデート機能を導入すべき理由と、簡単に実装する方法 - Qiita

    強制アップデートとは? 多くのアプリを利用されている方でしたら、何度か下記の画像のようなアラートでアップデートを促されたことがあるかと思います。このアラートは閉じるボタンが存在せず、「AppStoreへ」のボタンしか存在しないため、ユーザーにはアプリを操作するためにはアプリをアップデートする以外に選択肢がありません。この記事では、この様なアラートをアプリ起動時に表示する機能を強制アップデート機能と呼び、なぜそれが必要なのかと、たった3行でこの機能を導入できるライブラリについて記述します。 なぜ強制アップデートが必要なのか? iOS7以降、自動アップデート機能は追加されたもののもちろん全てのユーザーがそれを利用しているわけではありません。中には、リリースから半年以上経過しても初期バージョンを利用し続けるユーザーの方もいます。では、この様に古いバージョンを利用しているユーザーも多くいる状態で、

    [iOS]アプリに強制アップデート機能を導入すべき理由と、簡単に実装する方法 - Qiita
  • アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita

    by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい&メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例えば、データがない場合にNULLにするか or 空配列にする or property自体がないなどきめる pagingの場合とか複数のパターンが存在することを覚えておくと幅が広がる。単純なページング or twitterみたいなsince_idなど起点id以

    アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
    hatajoe
    hatajoe 2015/02/05
    こういうの嬉しい。勉強になります。
  • ドリコムの開発を支えるGitリポジトリ - gussan

    はじめに これは ドリコム Advent Calendar 2014 の5日目です。 4日目は、@ka_nipan さんによる ドリコムを支えるデータ分析基盤 です。 自己紹介 @gussan ドリコム歴は10年になります。 アーキテクチャ設計、ミドルウェア・ライブラリ及び社内ツールの開発運用等を担当しています。 日の話 2年前の12月、メインのソースコードリポジトリをSubversionからGitLabへ移行しました。 日はGitLabへの移行と運用の話をします。 GitLabに決めた理由 選択肢としてはGitLab, GH:E, Stash等がありました。 メインの機能はどれも十分な機能を有していましたが、 GitLabを選んだ主な理由としては以下の3つです。 継続的にメンテナンス・リリースがなされている 社内にある技術で運用可能である(Rails, MySQL, Redis) も

    ドリコムの開発を支えるGitリポジトリ - gussan
    hatajoe
    hatajoe 2015/02/05
    GitLabはSlack連携が弱くて辛かった。それ以外は特に文句無しで使いやすかったなー。