更新が必要系サービスで、有効期限直前に慌てて更新手続きすることってありますよね。 ドメインだったり、Apple Developers Program だったり、iOSアプリに必要な証明書だったり。
それらをちゃんと管理しようと思って、最初はGoogleカレンダーでいいじゃん、って思ったんですが、 1画面で利用サービスを一覧出来る感じも欲しいなぁ…と。リマインドしてくれるだけならGoogleカレンダーで十分なんですけどね。
というわけでGAS!便利です!GASって言っても、JavaScriptだし!
まずは、こんな表をGoogleスプレッドシートで作ります。
もちろんカラムやカラム名などご自由に。
ここから実際にスクリプトを書いていきます。 上で作ったスプレッドシートの画面で、[ツール]→[スクリプト エディタ]を開きます。 別画面でエディタ画面が立ち上がると思うので、カラム名やメールなどを埋めつつ、下のようなスクリプトを書いていきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
|
スクリプトを保存(フロッピーボタン)して、試しに実行(再生ボタンみたいなやつ)すると、 スプレッドシートの方で、期限が近づいてるセルが赤くなったと思います。
そして実際に届くメールがこんな感じ。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
あとは、スクリプトエディタ画面中、[リソース]→[現在のプロジェクトのトリガー…]を開いて、 スクリプトを実行するトリガーとなるイベントの設定をしときます。
[sendMailExpiredServices] [時間主導型] [日タイマー] [午前9時〜10時]
みたいな感じに。
あとは管理したいサービスが増えてもこのシートにどんどん追加していけばおk!
これでもう有効期限直前に慌てるなんてこともないはず! (あとは人間の問題。。)
]]>Source Code Beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA
最近iOS開発で使い始めて、良い感じな Uncrustify 。 設定に従って、インデントの数やスペースの取り方など、自動でコードを綺麗に整形してくれます。 似たもので、 perl 版で同じようなことをしてくれるツール perltidy とかがあります。
新しいソフトウェアとかでは全然無いんですが、Xcode にスクリプトを設定して任意のタイミングで uncrustify を走らす、 というのが便利だった&インストール〜Xcodeに設定までが一気通貫でまとまった記事があまり無さそうだったので書いてみます。
homebrew を使っているならこれだけで入ります。 (ちなみに Xcode プラグイン版もありますが、今回は使いません)
1
|
|
スクリプトはホームディレクトリの~/bin/uncrustify
に、設定ファイルは~/.uncrustifyconfig
に置いてます。
1 2 3 |
|
スクリプトは、Using Uncrustify directly in Xcode 4! を参考にパスなどを変えてます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
設定ファイルは Uncrustifyのセッティング (1) プリプロセッサ編 #uncrustify - Qiita [キータ] が詳しかったので、 使える設定、その説明を見ながら書きます。
Xcode でBuild
に成功したタイミングで uncrustify を実行する場合です。
[Preferences…] -> [Behaviors] と進んで、Build の Succeeds を選択し、Run の項目に上で作ったスクリプトを指定します。
あとは [Product] -> [Build] すると大量に差分が出ます。 差分を見ながら.uncrustifyconfig
に指定した設定に従って整形されているのが確認出来ると思います。
それぞれコーディング中は好きな作法で書いても、設定ファイルさえチームで共有しとけば、第三者が見て綺麗なソースが常に保てて便利ですね。
]]>もともとバージョン管理には Subversion を使っていて、今回 git に移行したタイミングで、 git-hooks デプロイを導入しました。
svn から git への移行については今回割愛しますが、 git push origin master
とやると自動的に本番にデプロイする方法は、
個人で借りてるサーバでも利用している方法だったので、是非ともやりたかったことの一つ。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
git には hooks という、updateやreceiveした後など、いくつかのタイミングをフックしてスクリプトを実行出来る仕組みがあります。 svn でもフックスクリプトは使えますが、こちらはコミットに対してフックする感じで、 git の方がタイミングが豊富という印象があります。
これの何が嬉しいかというと、例えば、チームでコード品質やコード規約を守るために、コミットする前にコミットしようとしているコードを必ず validation してNGならコミット中止、 コミット後に diff を通知する、push 受けた際にテストを走らす、などなどをするのに便利です。
今回は push があった際に更新しようとしているブランチごとに実行される post-update
を使ってデプロイ作業の自動化を行いました。
(あ、Gitlab使ってます…)
今回やりたかったこととして、
があります。
一つ目について、
今まで svn 時代には、
①ローカルから中央リポジトリにコミット
②test、stagingサーバにあるワーキングリポジトリ側で中央リポジトリの変更を受け取る(cron に3分毎に svn up
するようにセットしていた)
③stagingサーバに ssh で入ってstagingから手で本番へ反映
のようなフローでデプロイを行なっていましたが、これは git hooks (post-update
)を使って自動化することで解決しました。
2つ目について、
post-update
はタイミング的に post-receive
と似ているのですが、複数のブランチへのプッシュがあったときに post-receive
が実行されるのが一度だけなのに対して、
post-update
はブランチ単位でそれぞれ一度ずつ実行されるという特徴があります。
そして第一引数にブランチ名を受け取るのですが、ブランチ名は post-update
の中でこんな風に取得することが出来ます。
1 2 3 4 |
|
あとは $BRANCH
毎に処理の振り分けをします。
1 2 3 4 5 6 7 8 9 10 11 |
|
最終的には rsync + ssh
でWebサーバへ送りたい、ので一度 $TMPDIR
に checkout してます。
1
|
|
checkout したディレクトリに移動して rsync + ssh
。
1 2 |
|
この方法だと、それぞれの各確認用サーバでは常に最後に push されたブランチが当該Webサーバに反映されていることになります。
アイデア次第でまだまだ面倒な作業を自動化出来そうですが、まだ git による運用自体に慣れてないこともあり、しばらくこれでまわしてみて、 今後運用の中で、また何か改善点など出てきたら共有していきたいと思います。
tips というかGitlabを使っていてハマった点なのですが、post-updateスクリプトで tmpdir に git checkout したあと、
勝手にディレクトリが770
、ファイルが660
というパーミッションになってしまって困った、ということがありました。
post-updateに書いてある内容を手で実行してみてもそんなことにはならず、なんだ?という感じだったのですが、
home/git/.gitolite.rc
にこんな記述があり、
1 2 3 4 5 |
|
ユーザがログイン後に実行されるコマンド/home/git/gitolite/src/gitolite-shell
内で、
1 2 3 4 5 6 |
|
のように指定されているのでした。なのでUMASK => 0002
にしてディレクトリが775
、ファイルが664
となるようにして対応しました。
…と書いたのですが、Gitlab5.0からはgitoliteは使用しないようなので、 気にしなくていいかもしれません。ぐぬぬ。
]]>画面のスクロール位置を、Google Analyticsのイベントトラッキングに記録する。 記録したい要素のidを配列として関数に渡すと、その要素が画面に表示されたときに記録を残す。
つい最近導入してみたんですが、前回につづきjsネタです。
twitterなどからの流入をなんとか活かせないかと、直帰率を下げる&回遊率を上げるべく、該当ページの改修をすることに。 しかしコンテンツを見直すにも、そもそも何は見られていて、どこで見切られてしまっているのかの情報が無い状態だったので、 こんなjsを書いてGoogle Analyticsで見てみることにしました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
使い方:
1 2 3 4 5 |
|
スクロールイベントに対して、指定した要素の位置までスクロールされたかを判定する処理をバインドし、 Google Analyticsに送信しています。結果はどうかな・・・。
手軽に使える感じなので、今後効果測定やページ解析にも使っていきたいと思います。
]]>スマホの画面タップ時に要素をhoverさせる CSSは、a:hoverの代わりにa.hoverを使う aタグ以外の場合はclassにtapを指定するとCSSで:hoverの代わりに.hoverを使えるようになる
PCではリンクやボタンにカーソルが乗っかったときや押したときの挙動として、スタイルシートで
1 2 |
|
のようにやりますが、スマホサイトではこれが出来ません。
そこでFUKULOGのスマホサイトでもそうですが、
jQueryを使ってスマホで:hover効果を実現する | アルパカの具
1 2 3 4 5 6 7 8 |
|
のようにjsでaタグやボタンを指定して、要素がタッチされたときにhover
やactive
などのclassを付けることで対応していました。
しかしこれだと、そのページにある無数のaタグやボタンのeventに対して個別にコールバック関数をbindしていくことになり、要素が増えれば増えるほど処理に時間がかかってしまうことになります。 そこでbindするのはwindowのeventに対してのみにし、コールバック関数の中で実際にタッチされている要素を判別するようにしたのが、jquery.taphover.jsです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
あらかじめjquery.taphover.jsを全ページで読み込んでおくだけで、あとは必要に応じて、
1
|
|
のような感じで、該当する要素に対して適宜スタイルを追加していく、という使い方が出来ます。
今後スマホサイトで全面的に移行していくつもりです。
]]>CentOS(Amazon EC2)を使用しています。
Apache2.2です。EC2のElastic Load Balancingを利用してロードバランシングをしています。
フレームワークなどは特に使用せず、PHPで独自に実装しています。テンプレートエンジンにSmartyを使用しているぐらいです。
MySQL 5.0 で、全文検索Sennaが組み込まれたTritonnを使用して、コーディネート/アイテムなどに付随する情報の全文検索を行っています。
また一部では、全文検索エンジンライブラリLuceneがベースになっているSolrを使った全文検索も行なっています。 Tritonn使ってるのになんで?という感じですが、Tritonnだけでは思うようなパフォーマンスが出なかった、という経緯があります。 ただし最近になって、Tritonn本体とは別の原因がありそう…という話も出ていて一度ちゃんと調査してみる予定です。
PHPです。 ちなみにFUKULOGではブログパーツの提供もしているのですが、こちらはJava(Google App Engine)で実装されていたりします。
と大まかに書いてみましたが、せっかくなので以下に主に国内IT系各社の主要開発言語を調べて(採用情報や開発者ブログ等から)列挙してみました。
※会社単位で一概に開発言語”これ”とも言えないと思うので参考程度に
思いつくまま挙げてみたんですけど、意外にPerl率高めというところでしょうか。 最近のスタートアップに限定してみると、また違う結果になりそうです。
世界的にみると、Pythonが食い込んできたり、Rubyがもう少し多かったりしそうですね。 上場で話題のFacebookでは既存のPHPを独自に高速化(C++に変換)して使ってる、という話も聞いたことがあります。
開発言語は、普通作る”もの”によって最初に決めると思いますが、これから新たに作り始めるとしたら、Ruby on Railsの登場で開発コストが下がったという面で、Rubyが選ばれることが多いんでしょうか。
この際FUKULOGもRubyで…!?(笑)。
]]>初めての記事なので、少し自己紹介を。
最初に触った言語はperlで、今も趣味で何か作ろうとするときにはperlをよく使っています。 FUKULOGの開発言語であるphpの経験は極めて浅く、現在日々勉強中です。。。 業務では主にフロントエンドを担当、既にいくつかの機能の実装をやらせてもらっています。 今後ともよろしくお願いします!
というわけで、開発者ブログを始めるにあたり、FUKULOGのgithubアカウントを作るとともに、個人的にも気になっていたOctopressでのブログ運用を導入してみました。 Octopressの特徴として以下のような点が。
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 |
|
1 2 |
|
1 2 3 4 |
|
Octopressでは、WEBrickというrubyのみで書かれたWebサーバー用フレームワークが使われていて、rake preview
するとWEBrick::HTTPServerが4000番ポートで起動します。
Apacheなどの設定をしなくても手元ですぐにプレビュー出来るのはお手軽で良い感じです。デプロイ時にrake generate
で自動生成された静的ファイルがgithubにpushされて公開となります。
毎回コマンドラインからプレビューしなくても、 日常、下書きを書きためたり、Markdownをプレビューするときには、Kobito.appというMarkdown記法をリアルタイムプレビュー出来るアプリ等を使うのも良さそうかなと思っています。 (※KobitoはMarkdown記法のルールが若干異なるので注意が必要)
まだ手探り状態ですが、しばらくはこれで運用してみたいと思います。
今後もFUKULOGの開発のなかで得た情報を共有・発信していきたいと思うので、よろしくお願いします!
]]>