タグ

2016年12月10日のブックマーク (6件)

  • 俺のstrings.xmlの管理方法 - Qiita

    strings.xmlは規模が大きくなるにつれて行数も多くなり、管理が難しくなりがちです。 しかし、GoogleのサンプルやOSSのリポジトリはそこまで大規模ではないため、strings.xmlのnameの命名やファイルの分割など、どのようにすべきなのか掴みにくい部分でもあります。 そこで、今回は自分なりのstrings.xmlの管理方法の指針をまとめておこうと思います。 と思ったのですが、実は間に合わず書きかけの状態です。。。 当にすみません。明日中にはきちんと整理してまとめておきます。 翻訳の必要のないものはファイルを分ける strings.xmlは、複数のファイルに分割することができます。 翻訳の必要のないstringsは、ファイルを分けて管理するとよいです。 例えば、以下のように役割ごとに分けることができます。 strings_no_translate.xml アプリ名など、翻訳

    俺のstrings.xmlの管理方法 - Qiita
  • インターフェイス命名規則いろいろ #PHP - Qiita

    PHPのinterfaceの命名規約ってどういうのがいいんだろう?」 フレームワークや他言語の命名規則をあつめてみた。(パターン名は勝手にでっち上げたものであり、実在の人物・団体・事件などとは一切関係ありません。 ) ○とか☓と書いたのは個人的な感想です。どれが優れている劣っているという主張ではありません。炎上しないでください><。 I-接頭辞パターン I をインターフェイス名の頭につけるパターン。それを実装するクラスは I を取り除いたインターフェイス名を引き継ぐ。.NETJavaで見かけます。

    インターフェイス命名規則いろいろ #PHP - Qiita
  • Java言語における命名方法 | takemikami's note

    ここではJava言語におけるクラス・メソッド等の命名方法についての整理して(しようととして?)います。 注:ここに示す命名の仕方は、ルールではありません。あくまでも、命名時の参考資料という位置づけです。以下のような命名方法を知っていると、オープンソースのプログラムなどを読む際などに、クラスの役割を推測しやすくなると思います。 Java言語における命名方法パッケージ名の場合utilユーティリティクラスを持つパッケージに使用。ユーティリティクラスとそのヘルパークラスを含む。クラス名・インターフェイス名の場合接頭辞Abstract~抽象クラスの命名に使用。一般的に使用せず、インターフェイスやクラスと名前が重複する場合に使用することが多い。Mock~検査用の模擬(モック)クラスに使用する。Test~JUnitのテストケースの実装クラスに使用。junit.framework.TestCaseを基底ク

    Java言語における命名方法 | takemikami's note
  • 【Ingress】レベル16になった私のこれまでの過程とアドバイスを教えるぞ! - むねさだブログ

    Ingressというゲームにハマっています、むねさだ(@mu_ne3)です。 Ingressとは、Googleの社内スタートアップである「ナイアンティックラボ」が開発・運営する、スマートフォン向けのオンライン・位置情報ゲームです。 世界中をマップとしたリアル陣取りゲームで、実際にスマホを持ってウロウロしないとゲームにならないゲームです。 開始したのは、昨年の7月16日。 最近「Ingress(イングレス)」というスマホゲームにドハマりしてるぞ! | むねさだブログ 開始からほぼ1ヶ月でレベル8に。 これが8月15日の事。 そこからコツコツとレベルを上げて行きましてついに(現時点)最高レベルの16になりましたのでその過程やメダルについて紹介したいと思います。 エージェントレベル16とか遠い未来だよ…なんて思っている人も是非参考にしてみて下さい。

    【Ingress】レベル16になった私のこれまでの過程とアドバイスを教えるぞ! - むねさだブログ
  • iandprogram.net - このウェブサイトは販売用です! - iandprogram リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

    iandprogram.net - このウェブサイトは販売用です! - iandprogram リソースおよび情報
  • 私がMVCフレームワークをもはや使わない理由

    数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

    私がMVCフレームワークをもはや使わない理由