Mac用フリーなアンチウイルス sophos を使用してみた

Macを使用していますが、近年はMacもWindowsと同じくウィルス対策はもはや必須となっています。
ただ、基本的に有料ですし動作も重くなるのが大きな欠点。
ウィルス等から見を守るために入れているのに、作業に悪影響を与えるなら意味はないですし、かと言って個人であまりお金を使う程裕福でもありません。


Mac用アンチウイルスソフト18種類のウイルス検出率をテスト、最も検出率が高かったのは？ - GIGAZINE

ということで、検索していたらこのような記事を発見しました。
意外と数があるものですね。

さて、この中から色々検索するとsophosが軽くてなかなか機能も豊富そうでこれを選択しました。

インストール

インストールは簡単でここからダウンロード出来ます。
ダウンロードにはメールでの登録が必要です。
http://www.sophos.com/ja-jp/products/free-tools/sophos-antivirus-for-mac-home-edition.aspx

無事ダウンロードを行えば解凍してインストールは問題なく終了。
f:id:khondalit:20150115205125p:plain

最初にやること。

今すぐアップデートを行った後、全検索を行います。
やっぱり怖いですしね。

設定

基本的にはデフォルトで構わないかと思います。
自動アップデートやライブスキャン、Webスキャンなどが全てデフォルトでONになっています。

所感

動作は非常に軽く、常駐、全検索でも特に支障を感じることはありませんでした。
UIも違和感のない日本語で操作が可能で英語が苦手な人でもこれは嬉しい所です。
自動アップデートが1時間に1回なのがちょっとどうかなぁと思ったりもしてますが、軽いので問題は無いと判断してデフォルトのまま使用しています。
個人的には、会社などの組織でお金を出すならこれで全然問題無い気がします。

Railsでenum+i18n

state_machineという便利なgemがあります。
カラムの状態、状態の別名とかを管理が出来て結構便利に使わせてもらっていたのですが、
もう2年程更新がされておらすRails4.2系だとエラーになる場合もあるようです(確実にエラーになるかまでは分かりません)。

そこでenum

色々調べるとRails4.1から入ったenumを使えばいいかも的な情報を見かけたので使ってみたところちょっと使いづらい。

Rails4 - ActiveRecord::Enum の使いドコロ - Qiita

enumの追加の順番が大事なのはCでも同じなので、ある程度熟練したプログラマなら問題にはしません。
今どきC時代と同じ対応が必要なのは微妙な気はしますけど。

問題はi18n。
この対応が出来ない。あくまでも値の別名を付けやすくするだけの機能なのでしょうがないとは思いますがちょっと不親切です。
enum_helpという選択肢も示されていますし、検索すると他のgemも提案されているようではあります。
しかし、gemの問題はstate_machineのように更新されなくなったら終わりなのです。
gemに限らずcpanやらeasy_installのような類似の場合も同じ。
そこで個人的には、deviseのようなほぼ必須であったり、安定して信頼できるのでも無い限りは自作するべきと思っています。
仕事だとそうも行かない場合もありますが...

enum + i18n

ということで、今回はenumのi18n対応は自作しました。
はじめに考えたのはARを拡張するかどうか。
ARを拡張してlibあたりに置いておいてauto loadしておけば楽といえば楽なんですが、使わないmodelでもロードされるのは少し気持ち悪い。
そこで、model/concernsを採用しました。明示的にincludeしておけば分かりやすいですし。

Userモデルをサンプルにします。

# app/models/user.rb
# 削除フラグdeletedがあると仮定する
class User < ActiveRecord::Base
  enum deleted:[deleted_off, deleted_on]
end

i18n辞書にはこのように書いておきます

ja:
  states:
    users:
      deleted:
        deleted_off: '未削除'
        deleted_on: '削除済'

model/concerns以下に好きなファイルをおいておきます。

# このメソッドをconcernsに置いておく
# model側でのincludeも忘れずに
def state_machine_human(column)   
  state = self.try(column)
  return "#{column}" if state.blank?
  I18n.t('states.' + self.class.table_name + '.' + column + '.' + state)
end

# 使い方
user = User.all.first
user.state_machine_human('deleted')

これで使えるはずです。concernsって便利！
missing_method使えばもっと良いメソッド名とかにも出来るとは思います。

まとめ

gemは便利ですが、この程度であればわざわざgemを使うよりも作ったほうがよいでしょうね。
仕事だと特に作成者とメンテナが違うという事だって珍しくありません。
技術は適切に使いましょう。動けば良いのと、管理しやすいのは別問題ですよね。

今年の振り返り

さて、今年ももうすぐ終わりですね。
今年は仕事が忙しくほぼ何も出来なかったとはいえ、年末にlinux.infoを少し更新出来たのは良かったです。
とは言え今年のはじめの数ヶ月はRailsを触っていたので来年中にはなんとかリリースをしたいですね。
このblogも含めてあまり更新は出来ていませんが頑張りますので、来年は良い年になりますように。

漫画喫茶でノマドっぽく作業してみた

やっと時間がとれたので、http://linuxc.info を更新しました。

LinuxC | プロセスとIPC
追加したのは2記事。当分プロセス周りを追加していければと思います。

ちなみに、amazonのアソシエイトのクリックを見ると何故かGC本がそこそこ上位にいてビックリ。
商売は考えていないですし、そもそもアクセス数も少ないサイトですが、どういう興味があるかが気になるので時々見ているのですがそんなにGCの中身って気になるのですかね?
個人的にはかなり不思議です。
必要ならそのうちGCの話も追加したほうが良いのでしょうか? Boehm GCとか。簡易GCの実装とか。
時間があればですけどw

さて本題

漫画喫茶でノマドっぽい事をしてみた

さて、最近は家での作業は何かと誘惑が多く作業がなかなか進まないのが悩みです。
家だとやる気も出ないのですが、会社に行くとなんだかんだ言いつつも仕事は出来るのです。
昔は睡眠時間を削ってでもプログラミングの勉強をしたのですが、体力はともかく作業自体に身が入らない。

ということで家環境がダメなのではないのかと思い、時々行く近所の漫画喫茶を使おうと試しに行ってきました。
ですので今日は漫画は一切読んでいません。

作業自体はそれなりに進みました。文章自体は書くのが苦手なので上でも書きましたが2記事(昨日の家作業を含む)ほど。
集中出来ない問題に関しては解決するようです。

次に作業周りの環境とか。
PCはMBPで会社と変わらない環境ですので問題は無いです。ただ誤算だったのは電源が余っておらずバッテリの範囲内での作業だったこと。
持ち運びのバッテリは持っているのでこれを持っていけば問題は解決しそうです。

ちなみにこんな感じで作業をしていました。漫画喫茶のPCでyoutubeとかで適当に音楽を聞きつつ自前Macで作業的な。
WiFiは自前PcketWiFiがあるので問題なし。一応漫画喫茶にもあるようですが受付でお願いが必要っぽくて面倒で自前のを使いました。

後はお値段ですが、休日の6時間パックで作業をしましたので1800円ほど。
本格的なノマドをされる方であれば平日ですのでもう少し安くはなりますし、オープンな席だとさらに安い値段でした。
適当に検索したらノマド専用のところだと1日の値段もさほど変わらなそうです。環境は良さそうだけど電車代とかまで考えると微妙...

他にも幾つか困った事があったのですが自分の準備不足なので問題なし。
今日中に作業してから明日また行こうかな。やりたい作業が多々ありますし、年末年始も営業しているとの事なので結構ありですね。


ところで、数日で作れるWebサービスのアイディアないかなぁ。
今の作業は地味でちょっとつらいです。

Mac Book Pro Retina購入メモ

さて、先日Mac Book Pro Retinaを購入したので記録的に自分用メモを。

以前から購入予定でしたが、OSアップデートのタイミングやプライベートのお金の都合やその他のタイミングもあって、やっと購入。
個人的にはLinuxあたりの*nix系が動けばなんでも良いのですが、ノートPCのLinuxは結構めんどくさいし、仕事も多少からんでいますがアプリ開発まで入れるとMac以外の選択肢はないですしね。


購入したのはRetinaのSSD 256GB、メモリはフルの16GB。
一番心配していた重さですが会社で使用している旧MBPと比べると大分軽いですね。
さすがに11インチのMBAに比べたら重いですがメモリもあまり乗らない時点でさすがに無理ですし、13インチのMBAと比べても重さに関してはさほど遜色もないですし。


心配していたYosemiteですが、多少使った分では現状問題なさそうです。
というよりも、XCodeのインストール直後の起動がかなり早かったのが驚き。Mavericksだと何故かインストールもインストール直後の起動もがかなり遅くてストレスがひどかったので助かります。
Yosemiteに最適化されているんですかね?
ともかくこれで個人開発がはかどります。


あとRetinaですがグラフィックにはあまりこだわらない方ですが、自分はSteamでゲームをしているのですがこれがかなり綺麗で驚きました。
ということで、そろそろ年末ですし当分ゲームと開発を頑張ろうと思います。
今年は忙しすぎたので来年は時間が取れると嬉しいなぁ。

Cでのエラーハンドリング方法

かなり久しぶりの更新です。
仕事が忙しかったですし、そのあとはイベント続きや体調を崩したりで色々時間がなかったので...。
結局今年はプライベートで進めているプロジェクトをまだリリース出来ておらず、辛いです。


さて、この記事を読んでつらつらどうやっていたかを書こうかと思います。
Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱


最近はCはさほど触らないのですが、これは難しい問題ですよね。
そももそも昔からCのコードのかなりの部分がエラーハンドリングのコードになるということは言われていて、コード量が増える原因の1つになってますね。

ラッパー関数

まずはラッパー関数を作成する方法です。
私がよく使うのはmalloc系のラッパーのxmallocです。
これは昔からよく使われるテクニックです。

void *xmalloc(size_t size)
{
    void *tmp;

    tmp = malloc(size);
    if (tmp == NULL) {
        fprintf("malloc(3) error");
        exit(1);
    }

    //例えば0クリアもしておく。callocは使いづらいので...
    memset(tmp, 0, size);
    return tmp;
}


状況にもよりますが、mallocに失敗するとexitしたり、さらに成功の場合はmemsetで0クリアをする場合もあります。
組み込みのファームですとexitするのはまずいので、こういうのはやりませんが。そもそも組み込みだとmalloc自体使えないこともありますけどね。


xreallocも作ります。
reallocの場合失敗するとNULLを返しますが、元のポインタ領域はそのままなので初心者だと変数をそのまま使うバグを作ることはよくありますね。
例えばこのように実装します。

void *xrealloc(void *ptr, size_t size)
{
    void *ret;
    ret = realloc(ptr, size);
    if (ret == NULL) {
        // 例えばバグ回避のためにptrを返す
        return ptr;

        //別の方法だと、ptrを開放しておいてNULLを返す
        free(ptr);
        return NULL;
    }
    return ret;
}


いくつか実装は考えられますが、このようにしておくとバグが防ぎやすくなります。
ラッパー関数は単にエラー処理の単純化だけでなく、よくセットで行う処理を同時に行ったりバグを防ぐ事を目的の場合に役に立ちます。

goto

次に悪名高きgotoです。Cの教科書だとよく機能としてはあるけどバグの原因なので本によっては使い方を書かないというのを見たこともあります(どの本かまでは覚えてませんが...)。


例えばこういうのが悪い使い方として紹介されていたりします。

TOP:
//なんか処理

if (x == hoge) {
    goto TOP;
}


言語に関係なく、基本的に処理は上から下へという前提があるので(ループとかもあるけど...)、いくらなんでもこういう方法を取ることはないでしょうが、下手な人が使うとバグの原因になり兼ねないのはわかります。
ただ、エラー処理においては非常に優秀でぜひ覚えるべきテクニックでしょう。

char *hoge() {
    int ret;
    char *tmp;

    tmp = xmalloc(1024);

    //なんか処理
    ret = func0(tmp);
    if (ret < 0) {
      goto ERROR;
    }

    //なんか処理2
    ret = func1(tmp);
    if (ret < 0) {
      goto ERROR;
    }

    //この後も処理は続く...

    //成功時
    return tmp;

ERROR:
  // エラー時
  free(tmp);
  return NULL;
}


エラーの場合、その場でreturnを行う方法もありますが上記のように失敗時にfreeが必要となるとエラー時に毎回freeを書く必要があります。
gotoを使うだけで、エラー処理が1つになり、また関数の出口も1箇所に集まるため処理が非常に楽になりバグが少なくなります。
プログラミングにおいて楽をするのは正義です。下手くそなエンジニアが書くとどんな言語でも無理に頑張って根性で乗り切る人がいますがそれは間違いです。
楽をしてバグを少なくしましょう。そもそも楽をするためにコンピュータを使っているのに、めんどくさくしてバグを増やすなんてもってのほかです。


setjmpなどのテクニックもありますが、これは使いドコロが難しいですね。
今では古くなったサイトですがせめてこのあたりの知識くらいは身につけましょう。
Super Technique 講座〜目次
(コ)の業界のオキテ
Ｃプログラミング診断室

多分、万年カレンダープログラムはプログラマへの第一歩だった

ここ半年ほど半端ではない忙しさでして...、GWは無い、土日もほぼ出社な状態で、久しぶりの投稿です。
管理が出来ず、管理について勉強しようとしない管理者は本当になんとかして欲しい。


いろんなプログラミング言語で1582年10月5日を扱ってみる| mwSoft を見てふと懐かしくなったので、懐かしみつつ書いてみます。


そもそも万年カレンダープログラムって自分の若い時には入門者が初めてある程度まともに調べて仕様というかアルゴリズムを考えながら作るプログラムだったりしました。
とは言っても基本的には未来に向けて万年カレンダーなのですが。


はじめは単純で年、月、日が表示出来れば良くてあと頑張れば曜日の表示程度です。
でもこれのほほんと生きてきた人間には結構難しくて、うるう年のルールをきちんと知らなくて4で割れたらうるう年と考えて、授業で出したらダメ出しを食らうというのが定番でした。
そして、うるう年を調べて、へーっとなって修正してOKもらって授業は先に進む程度なんですけど、多少でもプログラムを頑張る人は過去もチェックしだして、西暦1年をcalコマンドでチェックしてズレを発見して絶望を覚えるわけですね。


さてこのズレを調べると、1582年に行き当たってあーと思い出すのです。
歴史好きなのでこれ結構すぐにはっとして納得するのですが、こうなると色々頭をよぎるのです。
ロジャー・ベーコンだったり、日本でも明治に導入して混乱があったなぁとか、和暦対応も頑張りたいなぁと思っていた矢先でそういや和暦ってどうなのとか、それこそ無限に。


ということでいくつかややこしい話を上げていこうかと。


まず、明治の件。
日本におけるグレゴリオ暦導入に日本にグレゴリオ暦が入ってきた経緯があります。西暦と同じく一部日付の欠落が発生して対応が必要になります。当時ふと思い出して調べてふざけるなと思った記憶があります。


和暦のめんどくささ。
元号一覧 (日本) - Wikipediaを見ると分かるのですが、元号が無い時代があったり、南北朝時代には同じ年なのに年号が複数あったり。
多分真面目に作るとなると、和暦のデータをテーブルとかDBに保存しておいて、それで変換するとかになるのでしょうね。やってられない。


そもそもユリウス暦の前は?
さて、和暦を諦めたとして、グレゴリオ暦の前はユリウス暦なのですが、その前ってどうなっているかとかを考えるとこれまたややこしいのです。
ユリウス暦 - Wikipedia
ローマ暦、エジプト暦とか色々名前が出てくる。そしてさらにはユリウス暦も現在一部では使われているとか、さらにややこしい話が。
そういえば今でも旧暦とか時々使いますよね。


そして、グレゴリオ暦のみの世界に。
結局、calコマンドはグレゴリオ暦を全体を通して使っていてそれに合わすのが結局無難なわけです。
仮に頑張るにしても、DBを使わざるを得なくて、いろんなプログラミング言語で1582年10月5日を扱ってみる| mwSoft にもあるけどDB側の影響も結構大きい。


頑張るんであれば、過去はcalコマンドに準拠で、曜日とか六曜とかそういう方向が多分ベスト。
と多分誰もが通る道を通るわけです。


で、今思うとカレンダープログラムを初心者の頃に作るのに良いことってこんな所でしょうか。

  • アルゴリズムと現実の結びつきがリアルに感じられる
  • プログラミングって大きく言えば工学の1分野なのですが、工学は実社会で役立つ事が前提です。でも実社会との大きな隔たりがやっぱりあって、そこを肌で感じれる初めての機会だと思うわけです。もうちょっと言えば現実と以下に折り合いをつけるかを学ぶ機会でした
  • それでも改良を頑張れる余地があって、頑張れるチャンスです。そしてこれがプログラミングの面白さでもあり、コードを綺麗に保つなどの大変さを知る機会でした。


現実的なプログラミングの大変さや何が必要かとかを知る良い機会でした。