プログラマーには密かにデレるPinterestやSumally

Pinterest、どんだけプログラマー欲しいんだよ・・・

Pinterestプログラマーしか見ないようなところに「WEBが好きならちょっと来い」というメッセージを仕込んでます。

Pinterestのconsoleを見ると「(ハート)web–>joinUs()」が。

ちなみに、ブラウザではこんな感じで表示されています。

こんなところにまで仕込むなんてどんだけ欲しいんだよ!という話ですが、もっと手が混んでいるサービスも見つけました。

Sumallyはもっともっと欲しがっている

Sumallyは名曲のパロディまで使って攻めてくるくらい欲しがってます。

探し物はなんですか?と。

どっかで聞いた事あるぞ、このフレーズ・・・。

他にも・・・・

短縮URLを貼って効果測定していることまでアピってくるパターンも・・・。

Sumallyは他にも英語のパターンとか色々あるので、開発者の方は見てみるのも面白いと思う。

Pinterest/Sumally、さすが遊び心がある会社は、羽織の裏地にまでこだわりますね。

僕のサービスももちろん開発者募集中・・・だが負けてられない

僕の開発したサービス「あなたシスウ」にもメールアドレスまで入れて結構欲しがったつもりだが、Sumallyのを見ると負けている感がある。

なので、ちょっと色々なパターンを公開してみる。

気が合う人と仕事したいと思ったので、ほとんどの人には分からないと思うけど、作ってみた。

牛蔵行きたい。

特にブロガーの人やプログラマーとかとWebについて話したい。

と思ったので牛蔵にしました。

変態プログラマー(特にJavascript使える人)をしたい方々のために・・・・

自社サービスが変態なエンジニアにウケたいのであえば、ぜひconsoleにメッセージを埋め込みましょう。

実装はJavascriptロジックは下記を参照。

・consoleに色づけする。

・ランダムに出す。

・変数や読み込みに干渉しない様にsetTimeoutを使う。

[code]

<script type="text/javascript">// <![CDATA[
(function(){ setTimeout(function(){ var style = "color: hsl(0, 50%, 50%);font-weight: bold;font-size:20px;"; var d = new Date().getTime(); if(d % 3 == 0){ console.log("%cシスウ株式会社では、開発者募集中!\nサーバーもJavascriptで開発しているJavascript大好き>な会社です。\n",style);
console.log("node.js か jQueryが得意な方はy.hoshino[at]shisuh.comまでメールを下さい。");
}else if(d % 3 == 1){

console.log("%c牛蔵行きたい。ぜひ、行きましょう。Javascriptが好きならば。\nお誘いのメールはy.hosino[at]shisuh.comまで。\n",style);
}else{
console.log("%cあぁ^~コードがぴょんぴょんするんじゃぁ^~、と思った方はy.hoshino[at]shisuh.comまで。>色んな意味で即戦力。\n",style);
}
},10);
})();
// ]]></script>

[/code]

もちろん、生のソースを見るために、こちら(僕が作ったサービス)で会員登録しても良いよ。(宣伝)

参考までに、Facebookはどうか見てみます。

Facebookは近寄りがたい・・・・

ハッカー防止のためにツンツンな警告が。

以上のように会社によってまちまちなconsole上でのメッセージでした。

Google Analyticsのノーリファラーの原因はiOSのGoogle検索

Google Analyticsの参照元が見つからないトラフィックの原因

Google Analyticsでdirect / none、あるいはノーリファラーが増えた時ってどうすればいいのか分からなくて困りますよね。様々な原因がありますが、一番大きな原因はiOS6のgoogle検索の確率が高そうです。

原因の調べ方

実際、Safariで自分のブログを検索してGoogleAnalyticsのリアルタイムを見てみましょう。すると、普通だったら、参照元にGoogle、キーワードに検索キーワード、またはnot prividedと表示されますが、iOS6のSafariのGoogle検索ですと、何も表示されません。これが、direct / noneの正体のようです。

参考までに、他にノーリファラー(direct / none)になるパターンのご紹介

もし、上記の原因で無かった場合にご参考までに紹介します。

  • はてなブックマークをモバイルアプリから使っている場合
  • ランディングページにGoogle Analyticsのコードが抜け落ちている場合

参考URL

英語の記事ですが、参考にした記事はこちら

linuxのコマンドをバックグラウンド実行の進捗状況を確かめるコツ

バックグラウンドで実行するとき、なんで >  rsync.logみたいに書き出すの?

どこまで進んでいるかどうか、後でtail -f で確認するために標準出力ではなく、ファイルに書き出すようにしています。

※本ページは下記の記事を読みやすくするために抜粋しています。併せてご覧頂ければ幸いです。

パスワードが必要なrsyncやscpを長時間バックグラウンドで走らせたい

&コマンド以外でバックグラウンドで走らせる方法

&コマンドではダメな場合はどんな場合?

パスワードが求められない場合には、&だけでなんとかなり、パスワードが求められる場合には、以下のような方法で実行するのがベストだと思います。

  1. ログファイルに書き出しながら実行
    • rsync  REMOTESERVER:/home/shisuh/tmp/ ./tmp > rsync.log
  2. Ctrl+z で一旦停止
  3. jobs -l で番号確認
  4. bgコマンドでバックグラウンドへ
    • bg 1
  5. disownコマンドでログアウトしても大丈夫にする
    • disown %1

※本ページは下記の記事を読みやすくするために抜粋しています。併せてご覧頂ければ幸いです。

パスワードが必要なrsyncやscpを長時間バックグラウンドで走らせたい

パスワードが必要なrsyncやscpを長時間バックグラウンドで走らせたい

パスワードを求められてもバックグラウンドでscpやrsyncを走らせるには?

  1. ログファイルに書き出しながら実行
    • rsync  REMOTESERVER:/home/shisuh/tmp/ ./tmp > rsync.log
  2. Ctrl+z で一旦停止
  3. jobs -l で番号確認
  4. bgコマンドでバックグラウンドへ
    • bg 1
  5. disownコマンドでログアウトしても大丈夫にする
    • disown %1

&コマンドではダメな場合はどんな場合?

パスワードが求められない場合には、&だけでなんとかなり、パスワードが求められる場合には、今回冒頭に書いたような方法で実行するのがベストだと思います。

バックグラウンドで実行する例は?

以下のように&マークを付けるとバックグラウンドで実行できます。

rsync  REMOTESERVER:/home/shisuh/tmp/ ./tmp > rsync.log &

パスワードの入力が必要なご注意下さいませ。

バックグラウンドで実行するとき、なんで >  rsync.logみたいに書き出すの?

どこまで進んでいるかどうか、後でtail -f で確認するために標準出力ではなく、ファイルに書き出すようにしています。

参考URL

http://d.hatena.ne.jp/shima111/20110714/p1

npmコマンド実行時にbad interpreter:が出力されたときの対処法

npmコマンド実行時で以下のようなエラーが出た場合の対処法

npm ls を実行したときに、bad interpreter: *** /nodeなエラーが出たときの解決法を以下に記します。

解決方法は再インストール・・・と単純

curl https://npmjs.org/install.sh | sh

という一行で解決しました。

理由の推測

npmのインストール時に以下のようなメッセージが出ていたこと、僕の場合はNode.jsのディレクトリを最初にインストールしたディレクトリから変えたため起こりました。なので、おそらくインストール時のNodeのパスを覚えておいて、それを使い回すような設定に成っているんだと思います。

 

参考URL

同じbad interpreterのエラーが出ていた方

iOS5.x系と6.x系を両方対応させるコツ

iOS5.x系でデバッグできない、起動しない、表示が崩れる・・・など

最新のXcodeを利用して組むと、いつのまにか5.x系では動かない狭いアプリになってしまいます。5.x系に調整する方法を以下に記します。

・iOS5.x系のシミュレータをインストールする

Xcode->Preferences ->Downloadsタブを開くと、過去のバージョンのSDK等の一覧が表示されますので、必要なものをダウンロードする。

・storyboardのuse auto layoutを使うとiOS5.xでは動作しない

storyboardをクリックし、File Inspectorから use auto layoutのチェックボックスを外す。

・auto layoutで一度組んだUIは、auto layoutを外すと崩れる場合がある

崩れてStoryboard上の配置を直せば問題無い場合もありますが、

Storyboard上の座標と表示座標がずれていることがあります。

その場合には、File Inspectorを開いて、右から2番目のView->auto sizingを調整することで修正できます。

・UITableView系で新しく追加されたメソッドはresponseToSelectorで確認する

・特に、setRefreshControl:と、Xcodeが自動生成するUITableViewのtableView dequeueReusableCellWithIdentifier: forIndexPath:に注意。

iOSのPush通知がきかなくなったとき

開発中のアプリのPush通知が突如効かなくなった。どう対処すればいいのか?

僕が行ったのは、iTunesで以前iPadで同期していたPCからiPhoneを設定したときに起こりました。

もし、思い当たる節があれば、以下の対処法で解決しましたのでご覧頂ければと。

すべてをリセットすれば問題無い

僕が行った手順は以下です。

  • iTunesからアプリを全て削除する
  • iTunesとiPhoneを切り離す(これ、絶対!)
  • iPhoneを出荷状態に戻す
  • iPhoneをiTunesに接続
  • 新しいiPhoneとして設定(これ、絶対!)
  • 同期するものを聞かれるので、全て同期しない(これ、絶対!)
  • Xcode経由で起動
  • サーバからPush通知
  • Notificationが届くか確認する
ちなみに、上記の手順はどこか無駄が多いのですが、一つでも変えたらできなくなってしまったので、全て必要だったのではないかと思います。

なんでこんな苦労をしたのか?

実機でリリースビルドする際には、TestFlightよりもiTunes経由が早いので、iTunes経由でアプリを落とそうと思い、iTunes経由でインストールしたのがハマった原因でした。

iOSの証明書が切れたときの注意点

実機確認で証明書問題が起こったときの対処法

ちょうど1年間のライセンスが切れ、証明書の更新を行ったときにエラーが出力されて実機で確認できなくなってしまいました。購入しただけでは問題が解決しなかったため、ios dev centerとXcode 4.5で証明書をいろいろいじることで解決できました。

以下、僕が行った手順を記します。

・iOS devのチケットを購入
購入時点では有効期限切れが解消されないので、24時間以内に来るというメールを待つ。
・window -> organizer で証明書一覧を更新する
右下のRefreshボタンにて更新可能
・古い証明書を削除し、新しい証明書を指定
エラー:The executable was signed with invalid entitlementsが出たので、以下の手順にて対処。

・実機から古い証明書を削除
・window->organizer->Device->provisioning profileのところに古い証明書があるので削除
・window -> organizer で古い証明書を削除する
※利用する証明書は削除しないこと
・左側のプロジェクトナビゲータから、ターゲットを選択
・ターゲット選択後、build settingタブを開き、code signingの箇所に新しい証明書に変更
・クリーンする
・実機で起動する

僕が採用したくなる変態エンジニアの生態 その3

変態エンジニアシリーズとは

僕の少ない採用経験、およびエンジニア経験から採用したいなと思った人や、仕事をまたしたいと思った人の特徴を上げていくシリーズです。

今回は、アプリケーションエンジニアではなく、インフラ系の保守・運用エンジニアについてのお話をさせて頂きます。

保守に強い変態エンジニア

エンジニアというとプログラミングでソフト製作、という一般的なイメージがあるかと思いますが、もう一つ重要な任務を忘れてはいけません。サーバが常に動いているのは、保守・運用を行うエンジニアの活躍があってこそです。

保守ができる人がいるプロジェクトといないプロジェクトでは、金銭面でも納品面でも安心感が違います。

保守・運用の経験から開発中からでも準備をすることができる

保守の人は全体を見て原因の切り分けをする必要があるため、視野が広いです。
なぜ視野が広いのかと思ったら、アプリケーション・サーバ・ネットワークとレイヤーごとにスパっと割り切って考えていることが一番の原因だと思います。

そのため、開発時に考慮漏れが少なくなる事は間違いありません。

保守・運用フェーズには言うまでもなく役に立つ

経験の浅いアプリケーションエンジニアは問題があった場合、アプリケーションの調査から入る人が多いように思えます。
しかし、実は外部連携しているサービスが落ちていたり、レンタルサーバが保守中だったりすることがあります。
そのような場合にでも、前述のように視野が広いため順序を間違えずに最短で調査をすることができます。

そんな場合は少ないよ、とおっしゃる方にもう1事例。

営業面でも大活躍

お客様やユーザがトラブル時には「システムに問題があった場合は全てソフト作った人の責任」と考えてしまうようです。
そして、経験が浅い営業だったり、または小さい企業で働いていると「それもそうだよな」なんて納得してしまうこともあります。

誰もあなたのことを狙っていないのに、自ら包囲網を敷いている人をよく見かけます。
保守エンジニアはそういう人達のことを「本当にしょうがない人達」と陰では思っているのかもしれません。
(実際、僕もそう思われていました)

オープンソースを利用している場合、サーバ屋、オープンソースコミュニティなど、実は最短手順というのは構築した会社に問い合わせることではありません。

こういう場合はサーバ屋、ああいう場合には我々の出番というのがきっちり線引きされていれば、お客様もわざわざアプリ担当に声をかけてくる理由はないんです。
その場合には、お客様に各レイヤーごとの役割を教えて上げることで、責任分解ができます。

保守エンジニアは先ほども申し上げた通り、全てのレイヤーを見ているのできっちり責任分解が頭の中にあります。
ネットワーク、ハードウェア、ミドルウェア・・・・というレイヤー図。

僕はとあるエンジニアにこの事を教えてもらい、目から鱗が落ちる思いでした。
視野が広い、保守のエンジニアならではの視点だなと思いました。

おまけ:発注者側が安心して安く発注するには

もし、発注する立場から見た場合、最も低予算かつ迅速な対応をするには、責任分解を自社で負う事をオススメします。
見えないリスクを減らしてあげる事で、下請け見積もりを下げる交渉材料ができる事も覚えておいたほうがいいでしょう。