解決できることに目線を向ける

長期的な目線は大切です。

ただ、長期的な課題はすぐには解決できないことが多いです。

途方に暮れる様な大きな問題は、小さな問題の積み重ねです。

小さな問題を一つ一つ解決するしか方法はありません。

小さな問題から逃げてはならないのです。

そして小さな問題は解決できることがほとんどです。

小さな問題を解決して、小さな成功体験を積んでいく。

かのイチローも言ってます。

とんでもなく大きなことを成し遂げるためには、小さなことを毎日積み重ねるしかない

ソフトバンクセレクションがかなりいけてる件について

ソフトバンクセレクションがかなりいけてます。

iPhoneのカバーとかを出してるだけかなぁと思っていたのに、、
かゆいところに手がとどく商品をかなり出しているんですよね。

例えば、、、、

 
SoftBank SELECTION 高品質 music piece WS31 ブラック ワイヤレスで通話、音楽、ワンセグ視聴

iPhoneで音楽を聞きながら、メールやネットを使うことってよくありますよね?
こういう場合にイヤホンのコードが邪魔になるんですよね。
ここで諦めて、iPod shaffleとかnanoとか買っちゃうんですよね。
iPhoneのイヤホンで通話できる機能ってとても便利ですよね。だからできれば一つに集約したい。
そこでワイヤレスで通話も音楽もできるようなものってないかなぁって探してたんです。
そしたら、痒いところに手が届く商品をソフトバンクセレクションが出してました。
しかもiphoneでは見れないワンセグを視聴できるというおまけつき。

個人的にはこれはapple純正で出して欲しかったのですが、よく客のニーズを救っているなぁソフトバンクさんっておもいました。

それから、いいなと思ったのはこれ!


SoftBank SELECTION 高品質 itomaki AC Adapter for iPhone ブルー Lightningコネクタ対応
かなりかなり、いけています。

このアイデアはmac bookの充電器にもあるアイデアなんですけど、コードをこんなにかっこよく巻けるなんて素敵ですよね!

これほしいなぁ、充電器のくせに3kオーバーとは強気な価格設定。。。でもlightningケーブル自体結構たかめですから、そんなもんですかね。

ちょっと今後も、ソフトバンクセレクションは要チェックですね。

Google ReaderなきあとのRSS生活はfeedly+newsifyで決まりと思っていたら、Reeder使えるのね。

newsアプリ大好きの私ですが、やはりRSSリーダーは欠かせない存在なのです。

Google Reader+Reederという運用をしていたのですが、Googleさんがサービスをやめてしまったので、Reederも辞めました。

Google Readerの乗り換え先をいろいろと迷ったのですが、Feedlyにしました。

理由は一番Feedlyの対応が早かったからです。

そしてReederはFeedly対応しなかったのでやめました。

iphoneでFeedlyアプリがイマイチな動きをするので、newsifyにしました。

ReederはMacもiPadもiPhoneもお金払ってたので非常に残念でしたが、と思ったらReederもfeedly対応してるんかい。。。

まぁ、7月1日には間に合わなかったみたいだから、いいか。

つーわけで、feedly+Reederをしばらくまた使うと思います。

とりあえずphpならcomposerはいれておこう

composerは素晴らしいツールですね。
rubyのbundlerなんて超当たり前だったものですが、phpでもこういうツールがメジャーになってきました。

phpのあるある話として、開発環境で動いていたアプリを本番にリリースしました。
あれ、pearのライブラリが入ってないから、エラー出てるよ。
あとから、お客さんからの問い合わせで気づくという最悪のパターンから、ログ監視中に気づくパターン、デプロイ後にすぐ気づいて冷や汗かきながら切り戻すパターン。。
上記のうち一つくらいはプロのphperなら経験があるかもしれません。

ここで古典的なやり方としては、必ずリリースの際は依存系ライブラリがないか徹底して確認するっていうよくわからない再発防止策を障害報告で書く。。。
後から、ライブラリ使ったことをリリース責任者が知らなかったとか作業担当者が報告しなかったとか、しょうもないことを上司から言われる光景すらも目に浮かびます。

あれ悲観的に書きすぎ??

こういった再発防止策はcomposerを使うという1点で解決できます。
composerはcomposer.jsonというファイルに依存するライブラリを記述し、コマンド一発でインストールできるというスグレモノです。
このcomposer.jsonを利用して、ライブラリのインストールを行うというルールさえ決めておけば、デプロイ用のスクリプトにcomposerを実行することを書いておくだけで、上記のようなくだらないミスを減らすことができます。

上記のようなことがなくなるために、composerの優位性を説くだけのエントリでした。


Composer
https://getcomposer.org/

スピードスピードスピードスピードスピード

スピードが欲しい。
早く手を動かせるようになりたい。
遅い。腹が立つ。苛立つ。

関数一つにしても、すぐにさっと書けないし、
いちいちgoogleに聞きにいかなければならない。

いや、調べるのは問題ないとしよう。
なぜ、それが遅いんだろう。

調べて理解するまでが遅い?
書いても、シンタックスが間違っていたり、データの流れをしっかり追えていなかったりするから、遅い?

どうすればスピードを上げられるのだろう??
関数の動きを正確に覚えることを日々やればいい??

例えば、絶対にググるのがjQueryいつまでたっても覚えられないし、
javascriptよりphpを書いている時間が圧倒的に長いからか??
意識して書くことがサーバサイドよりも複雑だからか??

でも、スクリプトが呼ばれるタイミングと、呼ばれる時の挙動がしっかり把握できていれば、そんなことにはならないんじゃないか?

集中力がないからか?集中力は書いて動いてこそ生まれるきがする。
ハマっているコードを書いているときはどうしても、集中力が削がれる。

できないことを一つ一つできるようにしていく、もっと一日に書ける行数を増やさなければ。

もっともっともっともっと、鍛えていかなければ。 <iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm-fe.amazon-adsystem.com/e/cm?t=koheisg-22&o=9&p=8&l=as1&asins=4344419057&ref=qf_sp_asin_til&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="height: 240px; width: 120px;"></iframe>