マウスパッドが古くなったので買い替えようと思ったら、重量感抜群のアルミ製のものを発見!かっこいい!
でもね・・冷たいww
アルミの部分がとても冷たいw
重量感は申し分無いです。冬にはオススメ出来ません。笑
マウスパッドが古くなったので買い替えようと思ったら、重量感抜群のアルミ製のものを発見!かっこいい!
でもね・・冷たいww
アルミの部分がとても冷たいw
重量感は申し分無いです。冬にはオススメ出来ません。笑
なんと、フォントが丸字体に…?!
どうやるかと言うと、上画像のように、任意の文字列を星マークで囲むだけ!!
ただし、MacのPCではならず、iPhoneのみで確認できました。
アプリは、Twitterの公式アプリとTweetbotで確認しました。
Androidでなるかは不明。
あなたも、下の文字をコピーしてつぶやいてみよう!
「✩やわらかいでしょ✩」
解説すると、「✩」は通常の「☆」とは異なる文字コードのものです。
#10025
の特殊なユニコードの文字で、「STRESS OUTLINED WHITE STAR」と呼ばれているようです。
でも、なんでこの文字で囲んだ文字列が丸字になるのかは不明です。
誰か教えて!!
複数種類のファイルを取り扱うようなアプリを思い浮かべてみて下さい。
対応するファイル形式を柔軟に増やせるようなアーキテクチャを、Objective-Cではどう構築するのが良いでしょう?
各形式を取り扱うモジュールがあって、それらは定型化された仕様に則って振る舞うような一般的なsubclassingモデルと、ファクトリパターンが良さそうです。
しかし、取り扱える種類が増えると、モジュールを統括する部分(ファクトリ部)の実装が肥大化する問題が発生します。
例えば、指定した拡張子に対応するクラスのインスタンスを返す関数とか。
更に、新しい形式を追加した時に、ファクトリ部への追加実装の手間も後々に負担となったり、実装漏れが生ずる可能性があります。
ファクトリ部をスッキリさせるには、通常のsubclassingモデルよりももう少し粗結合な実装方法を検討してみると解決するかもしれません!
それは、基底クラスのサブクラスの列挙部をハードコーディングするのではなく、ランタイムで列挙する方法です。
サブクラスに、ファクトリ部で取り扱いが必要な情報を提供するGetterメソッドやプロパティを持たせます。
これなら、新モジュールの登録忘れや一貫性を崩す心配を軽減できます!
NSObject
に対してメソッドを追加するカテゴリを紹介します。
追加されるメソッドの+ classNamesForSubclasses
を、あるクラスをレシーバにして呼び出すと、その子クラスの名前がNSArray
で返ります。
チョー簡単ですね!
ヘッダファイル(NSObject+AutomaticFactory.h
):
#!objectivec
#import <Foundation/Foundation.h>
@interface NSObject (AutomaticFactory)
+ (NSArray*) classNamesForSubclasses;
@end
ソースファイル(NSObject+AutomaticFactory.m
):
#!objectivec
#import "NSObject+AutomaticFactory.h"
#import <objc/runtime.h>
@implementation NSObject (AutomaticFactory)
+ (NSArray*) classNamesForSubclasses;
{
int numClasses = 0, newNumClasses = objc_getClassList(NULL, 0);
Class *classList = NULL;
while (numClasses < newNumClasses) {
numClasses = newNumClasses;
classList = (Class*)realloc(classList, sizeof(Class) * numClasses);
newNumClasses = objc_getClassList(classList, numClasses);
}
NSMutableArray *classesArray = [NSMutableArray array];
for (int i = 0; i < numClasses; i++) {
Class superClass = classList[i];
do {
// recursively walk the inheritance hierarchy
superClass = class_getSuperclass(superClass);
if (superClass == [self class]) {
[classesArray addObject:NSStringFromClass(classList[i])];
break;
}
} while (superClass);
}
free(classList);
return classesArray;
}
@end
プラグイン的な実装をしている場合は、検討してみてはいかがでしょうか?
HomeBrewが主流になりつつある中、乗り換えるのも面倒でしぶとくMacPortsを使い続けているnoradaikoです!
MacBook Airのディスク容量が少なくなっているという警告が出たので、何かと思ったらMacPortsが3GB以上も食っていました。
絶対無駄なファイルが蓄積されているだろうという事で調べてみたら、クリーンアップ方法を見つけたのでメモ。
#!bash
$ sudo port clean --all all
これで中途ファイルなどが削除されます。
俺の場合、これで2GBほどの容量が空きました!
ついでにinactiveなパッケージも削除しましょう。
#!bash
$ sudo port -p uninstall inactive
こっちは500MBほど空きました!
こういうのはこまめにやっておくと良いですね。
オブジェクト指向のコツを掴んだ時の、あの拓ける感覚。
英語なんて全く読めねえよと思ってたのに、割といけんちゃう、と気づいた時の感覚。
絵の筆がいきなり進みだす、あの感覚。
ギターの1フレットから22フレットまで自由に動けるようになった瞬間の感覚。
快感、快感、快感。
英語のヒヤリング、がんばろう。
iOSアプリやMacのアプリを個人で開発している者です。このエントリでは、これまでにレビューを書いていただいた経験から思う事を書きます。レビュワーの方の参考になればと思います。
最近、ありがたいことに AppStorm さんや AppStudio さんなどの海外のレビューサイトに拙作のアプリがちょくちょく紹介されている。
そのレビューを読むと、明らかに日本のレビューとは異なる点がある事に気づく。
非常に論理的な点だ。概要から入り、使い方・いい点などを説明して、悪い点の指摘、更には改善に向けた意見まで書かれている。また、同類サービスとの比較考察なども入っていたりする。最後にまとめとして要点が短く書かれている。
そのボリュームは、さながら小論文のようだ。しっかりと読み応えのある文章なのである。
スクリーンショットは必要最小限にしか使われていない。
一方、日本のレビューサイトはどうだろうか。
良いモノを伝えたいという気持ちがこもっているためか、良い点、面白い点や凄い点に関する記述が中心で、短く端的にまとめられたものが多い。
スクリーンショットがふんだんに使われていて、実際に使っている様子を画面と共に説明するような構成。
利用のイメージがしやすい、わくわくする書き方が特徴だ。
「神アプリ」という言葉が頻用されているように、とにかく良いところを伝える事に徹している。
このような傾向の違いは、きっとポリシーの違いの表れだと思う。
レビューというものがそもそも誰に向けて、何のために書かれるものなのか。
日本のレビューサイトの多くは、アプリの使い手に向けて書かれている。
ユーザのスマートフォンライフ、パソコンライフがより楽しく、ひいては人生がより豊かになるように。
海外のレビューサイトは、その読者に「開発者」が含まれているのではないだろうか。
なぜなら、使い手にアプリの悪い点や必要改善点を伝えてもどうしようもないし、ダウンロードする気が失せるだけだからだ。
アプリというものは結局おなじ人間が作るものであり、常に改善余地のある不完全なものだ。
アプリに関する率直な意見や問題点の指摘を、その背景も添えて具体的にしてくれるユーザさんは極めて稀少だ。
よっぽど困ったり熱狂しない限り、ユーザさんからはこちらに語りかけてはくれない。
海外のレビューは、そんなユーザさんのなかなか表に出ない気持ちを、裏表関係なく文字に書き起こしたものだと思う。
例えば、すごくいいコンセプトのアプリがあったとして、でも完成度でいえば10点のものがあった時。
開発者は、きっとどこをどう直したらいいのか分からなくて悩んでいる。
示唆に富んだレビューは、そんな開発者にとってとてつもなく大きなフィードバックになるだろう。
1つのレビューが、よちよち歩きのアプリを羽ばたかせる事だってあるかもしれない。
クソだとかカスだとかそんな誹謗中傷は論外だが、必要改善点を指摘する事は開発者にとって失礼だと思っている人がいるならば、その人たちにそれは違うよと言いたい。
前述のように、開発者はいつだってユーザさんからの声を欲しているし、どんな些細な事でも改善の助けになる。
日本で、問題点の指摘まで言及するレビュワーさんが少ないのはとても勿体ない事だ。
開発者とレビュワーとユーザの三者が幸せになれるメディア。
そんな、開発者にも愛されるレビューサイトがあってもいいと思う。