ワーキングメモリとは

ワーキングメモリとは自分の脳内のメモのことです。
例えば、買い物に行ったときにメモがなくても、あれとこれとそれが必要と思って、
買い物を順番にすることができます。これがワーキングメモリです。

認知症予防で注目されている分野でもあります。

今自分が考えていること

GTDやチケット駆動開発をしていると、自分で覚えておくべきことは、
全て何らかの形でメモをとることになります。

チームで仕事を行うときのエビデンスにもなるし、自分の記憶に依存することなく物事を進めていくことができるため、非常に大事なことです。

しかし、あまりにも自分が何も覚えておらずチケットやTODOリストを見ないと何もできないくらいに馬鹿になっているような気がするのです。
顕著な例がプログラムを書く時で、あの標準メソッドってどんな引数の順番だったっけ？とgoogleを頼ることがあまりにも多いこと。
もっと、フロー状態に自分を持っていくためにはもっと "ググらないこと" を実現していかなければならないと思ったのです。

ググらない x メモらない で実現できること

例えばターミナルを開いている時は、開発や作業に集中できます。
ドキュメントを作っている時に仕様が全て頭に入っていれば、ドキュメントを書くことに集中できます。

自分の脳の容量を上げていけば、自分の開発スピードをあげることができるんじゃないかなぁ？
と今実践しようと思っているところです。

GTDとは少し考え方が違うのですが、inboxくらいは頭の中に入っていてもいいんじゃないかなぁと思う今日この頃なのでした。

参考リンク

...

php-nabeのバージョン管理に僕はphp-nabeを愛用しています。
phpenvやphpbrewなど数ある中でこれを使っています。
phpを使わないでphpを管理したいという思想に惚れた訳です。

で、たまに php-nabe ext-install extname でphpの拡張がインストールできるのですが、
下記のようなエラーがよくでます。

$ php-nabe ext-install openssl
Cannot find config.m4.
Make sure that you run '/Users/kohei-sugi/.php-nabe/php-nabe/build/php-5.3.3/bin/phpize' in the top level source directory of the module

/Users/kohei-sugi/.php-nabe/php-nabe/bin/php-nabe: line 416: ./configure: No such file or directory

そんなときは、srcのファイルの中を覗きに行って、

mv config0.m4 config.m4

をしてあげて、もう一度実行するとOKです。

自分でコンパイルしたい欲求を程よく満たしてくれるので良いですよね。。
ただ、普通にyumでphp入れたとき見たいなお手軽感がないので、recipe的な機能を作って、
コンパイルオプションとかをデフォルトで選んだりできれば良さそうやなぁなんて思ってる今日このごろ。

historyを見たところ下記のようなextを良く入れているっぽい。

php-nabe ext-install php_pdo
php-nabe ext-install php_mysql...

とあるrubyのプロジェクトを進行中に不要なファイルがたまってきました。

$ git status -b -s
# master
?? a.rb
?? b.rb

上記のファイルは必要ないので、 git clean -fd を実行します。

$ git clean -fd
Would skip repository vendor/bundle/ruby/2.2.0/bundler/gems/slim-0726c443dfdd
Would remove vendor/bundle/ruby/2.2.0/bin
Would remove vendor/bundle/ruby/2.2.0/build_info
Would remove vendor/bundle/ruby/2.2.0/cache
Would remove vendor/bundle/ruby/2.2.0/doc
Would remove vendor/bundle/ruby/2.2.0/extensions
Would remove vendor/bundle/ruby/2.2.0/gems
Would remove vendor/bundle/ruby/2.2.0/specifications

oh!!!

vendor/bundle の中のgemが消えてしまいました。。
仕方なく bundle install するわけですが、なんで .gitignore の中に入っているはずの、
vendor/bundle 配下のファイルが消えてしまうのでしょう。

自分自身 .gitignore の書き方にあまり自信がなかったので、
いろいろ調べてみましたが、特に問題なし。

git clean -fdx

...

能力開発や自己啓発の世界で有名な『7つの習慣』があります。
いまやどこの企業でもこの考え方に近しい考え方が取り入れられた研修を行われています。
本ブログではタスク管理の話を題材として扱っています。
タスク管理を話題にする上で避けては通れないことが、『7つの習慣』で触れられています。
今回は『7つの習慣』の概要を見て行きましょう。

ぶっちゃけ『7つの習慣』とか苦手なんです。。

僕自身は今はなき？ベンチャー・リンクという会社の研修型インターシップで、セミナーが最初の出会いでした。
当時は7つの習慣を冠したセミナーを日本国内で行っていたのがベンチャー・リンクでした。
講師は研修を受けた本物の講師ではなく、内定者が研修を兼ねて行っていました。

それ依頼、7つの習慣に触れたことは皆無です。
就活生で悩み人だったときには大いに参考になった気がしたのですが、
自分のやりたいことが見えてきた時期から、この手の自己啓発本は一切よまなくなってしまいました。

しかし、このブログでタスク管理についての題材をしっかりと扱っていくことに決めたので、
この間のGWの連休中に最近でた改訂版を読み直しました。

ざっくりした本の内容

世の中に偉大な成果を残した人の習慣を研究し、その最大公約数的なものが7つ習慣がありました。という話です。

成功者のタイプにも色々あるので、結構大枠であり方を説いています。
いろんなタイプいるけど、その中でもこれらは共通してるよ、と。

• 第1の習慣 主体的である
• 第2の習慣 終わりを思い描くことからはじめる
• 第3の習慣 最優先事項を優先する
• 第4の習慣 Win-Winを考える
• 第5の習慣 まず理解に徹し、そして理解される
• 第6の習慣 シナジーを作り出す
• 第7の習慣 刃を研ぐ

...

ベイスターズ強いですね。素晴らしい。

というわけで、各チームの4番を調べてみました。

【セ・リーグ】  
横浜 筒香(1991年11月26日 (23歳))  
読売 太田(1990年6月9日 (24歳))  
中日 ルナ(1980年2月1日 (35歳))  
ヤクルト 畠山(1982年9月13日 (32歳))  
広島 ロサリオ(1989年3月29日 (26歳))  
阪神 ゴメス(1984年9月7日 (30歳))  

【パ・リーグ】  
日ハム 中田(1989年4月22日 (26歳))  
西武 中村(1983年8月15日 (31歳))  
ソフトバンク 内川(1982年8月4日 (32歳))  
ロッテ　デスバイネ(1986年6月17日 (28歳))  
楽天 松井稼(1975年10月23日 (39歳))  
オリックス T-岡田(1988年2月9日 (27歳))  

※ 4番が複数いるときは僕の好みで選んでます。

両リーグ断トツで、筒香が最年少ですね。
しかも、キャプテン。横浜は完全復活しそうですね。

読売に関しては坂本1988年12月14日 (26歳)よりは、大田の方が4番っぽいのでいいと思います。個人的には好きです。
こう見ると読売も若返りに成功しているのがわかりますね。
そしてしっかりと、ベテラン陣でバックアップできるように戦力補強。。
いやぁ憎いですね。笑

中日は同い年だし、平田(1988年3月23日 (27歳))が4番に定着して欲しいかなぁ。

ゴメスは意外と若かったの知りませんでした。
読売と違って若手の層がやはり薄いのでしょうかねぇ。 ...

10年つかえるSEOの基本 を読みました。
僕のようなSEOを専門にしていないIT業界の方々に、是非読んで貰いたい本です。

長年、この業界に居ながらSEOに対して懐疑的な見方をしていました。
ただ、Retty在籍していたとき、現Kaumoの太田くんのSEOに対する考え方を聴き、僕のSEOに対する考え方が変わりました。
その後の太田くんの活躍は皆の業界の知るところです。

人とモノとのミスマッチをなくすーーSEOおたくが生んだ「カウモ」で変わるモノとの出会い - THE BRIDGE（ザ・ブリッジ）
http://thebridge.jp/2015/02/kaumo

この本は平易な文章で、挿絵をふんだんに使っています。
副題にもあるように、「トレンドを追うよりも変らない考え方を抑えるためのテクニック」がしっかりと書いてあります。

ユーザに対して何を伝えるか、考え抜くことが大事だということを実感しました。
...

git pull 何気なく毎日このコマンドを使っている人も多いのではないでしょうか。
実はこのコマンド色々と注意すべきコマンドだと思います。

masterブランチを最新に更新したいだけなのに、マージコミットがローカルにできてしまうことがあります。

マージコミットができるとき

remote/origin/master にローカルの master ブランチにはないコミットがある場合です。
普通にしておけば、そんなことにはならないような気もします。

しかしながら、

• 誤ってコミットを master にしてしまった場合
• 一度 git pull origin master でmergeコミットが生じた場合
• その他、ローカルのmasterブランチとfast forwardでマージができないような場合

ローカルにしか存在しないコミットができてしまいます。

マージコミットを作らない方法

git pull origin master を行ったタイミングで、コミットメッセージが立ち上がる。
そんな経験はありませんか？そのときはマージコミットが余分にできてしまっています。

ローカルにあるブランチに余分にコミットができてしまっているのです。
そのコミット内容にもよりますが、それをpushしちゃうなんてことがあると危険ですよね。

以下のようにfetchをすれば、上記は起こりません。

$ git fetch && git rebase origin/master

fetchをしてから、origin/masterに対してrebaseする。

もしくは、

ブランチを切る場合の手順について、初心者向けに説明していきます。
省略系のコマンドを書いている記事が多いので、あえて遠回りをする手順を書くようにしてます。

最新の状態を取得する

最新のリポジトリの状態が、masterな場合で話を進めていきます。
最新のコミットがdevelopeなど別の名前の場合は、masterをそれに読み替えてください。

まずは、masterブランチを指定しておきましょう。

$ git checkout master

このときに、ローカルのリポジトリがすでに遅れていて最新ではない可能性があります。
そして、git fetch でremoteのソースを取得します。

$ git fetch

こうすることで、リモートのリポジトリがローカルに取り込まれます。
ただ、masterは古いままなので、同期をかけたorigin/masterとコミットにmasterを更新しなければなりません。

$ git rebase origin/master

もしくは

$ git merge --ff origin/master

です。

$ git pull origin master

でも同じことが確かに可能です。
しかし、masterにcommitがあった場合などにマージコミットができてしまいます。
この差分を起こさないためにも、pullは最初のうちはおすすめしません。

masterに対するpullはffを必ずつけたり、rebaseで取得するようにしておけば問題ありません。尚、この設定についてはここでは触れません。...

以前、なぜこうも日本のITリテラシーは低いのか？という記事を書きました。
で、データとして根拠になるかもしれない記事を見つけたので、ご紹介。

データえっせい: パソコンを持たない若者
http://tmaita77.blogspot.jp/2015/02/blog-post_25.html

このブログのデータの分析によると、海外の国々と比べて、日本人がPCに対する接触時間が少ないことがわかります。

海外の国々で求められるITリテラシーの平均と、日本の平均ではやはり差があるということでしょう。

文化的な背景やなんでも自分で調べなければいけない事情など、いろいろご意見をいただきましたが、それはともかく。
日本人はPCに対する接触機会が他国に比べて少ないまま、大人になっていくようです。

なんでも、遊びとして捉えられる時期にパソコンに触ることは重要だと思います。
確かにインターネットは危険だけど、何が危険かを知らないままに育つのはもっと危険だと思うんだけどな。

僕が日本のためにできることは、スマートフォンでも大概の仕事ができるようにしていくことかな。そうすればPCに触らなくても、スマフォはみんな小さいころから触ってるわけだし。

Gitで開発をすすめていくときに、最も基本的なコミットについて、SG流に説明していきます。

コミットするときに大事なことは変更理由と変更内容

コミットする際に大事なことは2つあります。
変更内容と変更理由です。

コミットは変更内容は意識しなくとも、後から確認することはできます。
意識すべきことは、変更内容が大きくなりすぎていないかです。

変更理由が後からわかるためには少し工夫が必要になります。

コミット内容を確認しよう

コミットする前に変更内容を確認するコマンドは2つあります。

$ git status

と

$ git diff

です。

ファイルがstageされているか、変更されたファイル自体を確認するには、git statusで確認できます。
addされているものについては

$ git diff --cached

で確認しましょう。

git commit するタイミングでも、

$ git commit -v

でコミットメッセージを書くタイミングで、変更内容が表示されるようになります。

変更理由をコミットメッセージに書きましょう

git diff --cached でコミットされるものが問題なければ、 git commit でコミットメッセージを書きましょう。

コミットメッセージの概要を1行目に書きます。
これは変更内容をそのまま表すものでも大丈夫です。

コミットメッセージは3行目以降を使おう

2行目はgithubやgitlabなどでは一行として表示されていまいます。...

ドラゴンボール見るとやっぱり、テンションがMAXに上がりますよね。

ドラゴンボール世代ですもんね。仕方ありません。 というわけで、 ドラゴンボール復活のFを見てきました。

<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/u0bArxJtSnM" width="560"></iframe> 

今回はフリーザが復活してしまう話なんですが、こっちを見てない方は話の筋がわからなくなるので、こっち見ておいた方がいいと思いました！

   ...

僕はこのブログを大学4年生の頃から書いています。

昔の文章を読むと文章が下手で、正直何を伝えたかったのかわからないです。

少し、いやかなり恥ずかしいです。

たまたま社会人1年目の頃のブログを読んでいたら、あまりにもアホな内容だったので、Facebookにシェアしました。

すると、何故かいっぱい「いいね」されてしまい未だに1ヶ月以内の人気記事の一番上に上がってきちゃいます。恥ずかしいです。ええ。

「恥ずかしさ」以上に得られるものがある

それでも、「恥ずかしさ」以上に得られるものがあると思います。

自分が過去に何を書いていたのか、振り返られるというのは貴重です。

ブログでなくても、日記でもいいかもしれません。

ただ、ブログの場合は少なくとも「誰かに見られるかもしれない」という緊張感の中書いています。何か伝えたいことがきっとあったはずなのです。

一方、日記は誰にも見られることはないでしょう。わかりやすい文章を書く意識をする必要はありませんし、考え方や主張がなくても問題ありません。

そういう考え方や主張が手に取れるようにわかるのは、大きいです。

長い間ブログを運用していると、サイトディレクター的な考えが身につく

このブログは広告収益が上がるほどのアクセスはありません。

それでも長い間、数多くの記事を上げ続けたことで、それなりのSEO流入があります。

変なことはしませんし、googleのペナルティを食らうことはありません。

そうすると、自分でSEOのテストができます。

仕事でやるとコストがかかることも多いと思いますが、その小さなテストをブログでできるのは大変助かります。

長い間やっているからこそ、googleからも悪い評価はされにくくなっていくはずです。

...

Facebookで知人たちとリモートワークは機能するのか？という議論になりました。
知人もリモートワーク推奨派と否定派に別れました。

議論の火種になったのは、知人がシェアしてくれた下記の記事です。

ネットで在宅勤務24％減　震災後急増の反動　　：日本経済新聞

記事によると、震災の影響で流行した在宅勤務の採用数が減少しているようです。

リモートワークはワークしない？

上記の日経の記事以外にも、Yahoo!のメリッサ・メイヤーになって、リモートワークを廃止したなど、リモートワークに対するネガティブな情報も数多くあります。

では、実際にリモートワークはワークしないのでしょうか。

リモートワークがワークするかどうかはサービスや戦略に依存する

例えば、GithubやBasecampはリモートワークを進めていることで有名です。
この2つサービスには大きな特徴があります。

GithubやBasecampはエンジニアやIT業界向けのサービスです。
プログラマやデザイナの中で、作りたいサービスの要件をかなり把握しやすく、UI/UXのイメージを共有しやすいサービスです。

UXは組織論であると議論されます。
UXのみならずサービス設計も組織と密着に結びついていることは間違いありません。
...

今でもこのメンバーのオリジナルの東京事変を見るだけで、テンションが上がってしまう。

<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/gD2mhJ3ByGQ" width="420"></iframe> 満州事変や日華事変を連想させる事変という言葉。 宣戦布告なしの戦争という意味であるが、当時東京事変という誰でも思いつきそうだが、大層なネーミングだと思ったことである。

しかししかし、このメンバーを見たら納得せざる負えない。
椎名林檎ですらも存在が薄く感じてしまう豪華メンバー。
少しでもバンドや楽器に触れたことがある人であれば、その破壊力のある演奏に度肝を抜かれるはずだ。何度聴いても、どのパートもゾクゾク来る部分が散りばめられてる。

ヒイズミと亀田の音は1stだけでしか聴けない、オリジナルメンバでの演奏が収録されているアルバムなのです。椎名林檎を最高に味わうためのバンド演奏がここにある。
...

私がgitを使う上でもっとよく使うコマンドは git status です。
git status はgit管理されているファイルの状態を確認するコマンドです。

git管理されているファイルの状態について

git ではファイルの状態がいくつかあります。

untracked file

ファイルがgitリポジトリに登録されていないファイルです。
この状態のファイルは、 git clean することで、ファイル自体を削除することができます。 (本当は git clean -fd しないと消えない)

staged file

staged file はgitリポジトリにコミットする準備が整っているファイルです。

untracked file に対して git add することで、 staged file にするになります。

staged file に対してコミットを行うと index file になります。

ファイルがgitのリポジトリにコミットする準備が整っているファイルです。
このまま git commit を行うとリポジトリに登録が行われ、indexファイルになります。

git reset を使用すると
新しく作られた staged file 追加されたファイルは、untracked fileになります。
変更されたファイルは、変更前になります。

またコンフリクトしたファイルは、この状態同じになります。

index file

index file はgitリポジトリに管理されているファイルです。...

今流行りの桃太郎ネタか。
それにしてもインディーズのラッパー達はyoutubeのお陰で本当に元気だなぁ。
バンドよりも制作コスト本当に低いもんなぁ。

<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/AVPgxn3xohM" width="560"></iframe>

MV見てくれればわかると思いますが、もう完璧ですね。
狙ってるところも、狙い方も、ぴたっとハマってる模様です。
そして、この精度の曲をどんどん当ててきてるようなので、シーンを席巻する日も近いんじゃないかなぁ。

...

テスト、テスト、テスト、、、、
そう言われているので、フロントエンドのテストもしなければなりません。

というわけで、色々調べてみると、mocha + powerassert が一番の良さそうなので、それでテストを書いてみます。

準備

何はともあれ、 公式ドキュメントをむさぼります。
上から順番に実行していきます。

$ npm install --save-dev mocha power-assert intelli-espower-loader

http://azu.github.io/power-assert-demo/ にあるdemoコードをtest.jsにコピペして、、、、

$ ./node_modules/.bin/mocha --require intelli-espower-loader test.js

動いた！！！来た！！!これでテストが書けますね！！

ちょっと待って ちょっと待って～ お兄さん！

• コマンド長すぎる問題
• まとめてテストしたい問題
• CIでテストしたい問題
• coverage測りたい問題
• 更新したらテスト動かしたい問題

などいろいろありますよね。
基本的に gulp test で全テスト回したいものです。

今後こうやってテストを実行するのも微妙ですよね。

なので、さらにこちらを参考にさせていただきました。 ...

IT業界では毎年、様々なバズワードが生まれては消えていきます。

そして、しきりに〇〇元年というように煽られます。

web2.0、クラウド、ゲーミフィケーション、ビッグデータ、グロースハック、IoT、、、

そういう言葉達を新しく知ったときに、感じることがあるので、
それらをタイプ分けしてみました。

↑のOGPに釣られた人ごめんなさいmm

今までもあったものが、発達したことによって違う名前になる系

...

先日、bowerから依存関係ツールをbrowserifyへ移行しました。
一気に移行するのはあれだったので、段階を経て、debowerifyというbowerでインストールしたものを、browserifyでできるツールを入れてみました。

ただ、まぁ必要ないよね。。
ということになりまして、今回bowerで入れたものを全て、browserifyで管理するようにしてみました。

bowerはbower.jsonに書かれたフロントエンドのjavascriptモジュールを管理してくれるツールです。
これからはフロントエンドだぜぇぇって騒いでる僕はとりあえず導入しておけと、導入していました。

ただ、nodejsのデフォルトのモジュール管理ツールであるnpmをプロジェクト毎に管理する場合は、package.jsonで管理します。

これをフロントエンドでも使えるようにしてくれたbrowserifyを導入したし、
bower使う必要がなくなりました。
bowerでたくさんのモジュールを管理している人は、また考えようなのですが、
僕の場合はundersocreとjqueryのミニマム構成。秒速で乗り換えられると判断して、乗り換えました。

手順

<script src="https://gist.github.com/koheisg/5cf83188e81c633502f5.js"></script>

実際のコミットログは下記のPRに全て残ってます。
...

iTunesのセール来ました。

グレイテストロックヒッツに続いて、オルタナティヴヒッツですよ。

メール自体は4/9に配信されてました。

 

今見てるところだと、この間紹介？したレッチリのカリフォルニケーションとかバッチリ入ってますね。

これはこれはオルタナ世代には、かなりガッツンとくるセールだ。。

アップルストアへのリンク

あんまりjavascriptに詳しくない人間が、jqueryとunderscoreで scaffold generator(railsのscaffoldコマンドをブラウザから作成するSPA)つくったのですが。。
イマイチいまどきのjavascriptぽくなっていないわけです。
テストも書きたいし、reactとかもやっってみたいし、、
やりたいことはいっぱいあったのですが、まず依存管理ツールを導入するべく requirejsを導入してみましたが、browserify のが良いというのを聞きしました。

@koheiSG mocha + power-assert なら全力でサポートできますぞ (あと RequireJS よりは browserify がおすすめです)

— Takuto Wada (@t_wada) 2015, 3月 15

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> ...

僕は多分年の割りにはいろんな会社を経験してる方で、プログラマにしてはいろいろな会社と取引したりプロジェクトを進めて来たりしてきました。

あの会社はだめだ。

とか

あの会社はいい。

直感的に、感じることがあります。

もちろん、みなさんも感じたことありますよね。
それはずっと同じ会社にいる人も感じたことあると思います。

上司や同僚もあの会社はあんな感じだから、、

こうしといた方がいいとか、ああした方がいいとか、アドバイスしてくれます。

これが、いわゆる会社に対するざっくりとした評判ってやつですね。

いろんな会社を渡り歩いているとは言え、狭いIT業界なので同じ会社が取引会社に含まれていることもあります。
そうすると、以前の職場でのその会社に対する印象が刷り込まれてるわけです。

例えば、以前の職場でいい印象がなかった会社があったとします。
そうすると、「あー、この会社はああだからなー」と思ってた矢先に。。

上司から「この会社とはすごいいい関係値が築けてるから、それは崩したくないんだよねー」

「え？◯社が？」 と思うわけです。

でも、意外とこういうことってあるんですよね。

会社の評価は視点が変われば、全然異なります。

まとめ

会社の立場が変われば、会社の評価も変わります。
だから、自分のベストを尽くして、可能な限りいろいろな取引先とWin-Winな関係値を築いていきたいなぁと思う日々なのでした。

7つの習慣の第4の習慣ですね。
...

「仕事このままでいいのかなぁ、と思って」

友達から相談を受けました。

端的にまとめるとそう思っている理由は下記でした。

• 仕事内容が好きじゃない
• 人間関係が良くない
• 仕事でスキルが伸びる気がしない
  なるほど、よくある系の悩みのフルコンポです。

まだ彼女は24歳なので、誰にでもあることを重く受け止めしまってるようにも思えます。

「じゃぁ、仕事辞めちゃえば？」

否定されるのはわかっていながら、聞いてみました。

「でも、それって逃げじゃないですか？」

仕事を辞めることは逃げでもなんでもない

こういう思考回路の人思ったより多いですね。

確かに何もせずにその場から逃げ出すのは逃げです。

努力して、何かを変えようと挑戦して、それでも結果ダメだったから辞めるというのは、逃げではありません。戦略的撤退です。

例えば、東大を目指してたとします。

でも、受験に失敗しました。

滑り止めの大学に入って何もしないのは逃げです。

しかし、切り換えて大学生活で何かの成果を残そうと努力するのであれば、逃げではありません。

成功させるためにやることが職場を去ることなら、辞めればいい

自分で目標を設定して、努力したのにできないのであれば、環境のせいにして辞めてもいいと僕は思っています。

そんな気合じゃ、何事もできないと思うかもしれませんが、そんなことはありません。

PDCAのCが要

大事なのは環境のせいにするタイミングで十分に考察を行うことです。

なぜできなかったのか、どうすればできたのか。

PDCAでいうチェックですね。

大体、自分独りだとこのチェックができないことが多いです。

...

僕はおそらくアンチ〇〇の塊だと思います。
例えば読売が憎くてしょうがありません。

人はコンプレックスなどの様々な感情から、自分の中にありとあらゆるアンチを創りだすのです。

まぁ、簡単に言うと僻みや嫉妬なのですが、これがシンプルではりません。
例えば、読売に勝ったという強い成功体験があった場合、このアンチの心をさらに増幅させることで、次の成功体験を掴み取ろうとするわけです。

そして、もっと厄介なことにどんどんそれが増幅していくのです。
このサイクルに陥った人間の心は厄介です。

大阪で公務員批判・マスコミ批判をこれでもかって繰り返す橋下氏が、大人気な理由も、 韓国や中国で反日・抗日が繰り返される理由も、 右翼が一定の層に支持される理由も、 きっとこの仮想敵がなければ生きていけない状況に陥っている人間の心に響いているのだと思います。

これを為政者が利用すると怖いのはもちろんのこと。自分もこのサイクルから抜け出せないと、本質的な成果から遠ざかってしまうこともあります。
決して悪いことではないです。ただ、心と向き合った方が成果は出やすい時もありますし、心が辛いこともあります。
...

最近はもっぱらruby on railsで開発をしているのですが、phpで結構長くやってきました。
phpは中級者以上になろうとするといい情報が少なくなる傾向にある気がします。特に日本語の情報は本当に少ないように思います。

というわけで、自分が中級者の壁にぶち当たったときに、勉強したものをまとめておきます。

今後、自分がまたphpを触るときのためにも。。ああ、そういえば新卒向けにも良い季節ですね。ラベルに新卒エンジニアって書いておくか。

PHPの良いサイト

PHP: The Right Way

PHP: The Right Way

大事なことは大体書いてます。

このサイトは本当に素晴らしいです。
中級者の壁にぶつかったときは、このサイトのわからないことを潰すことが大事だと思います。
結構短い文章なのですが、しっかり理解するには時間がかかると思います。

結構アップデートも頻繁に行われているので、定期的に読み返すと良いと思います。

yandoさんのスライドシェア

Yandod, Developer | SlideShare

サイトと言いながら、スライドシェアですが、 ...