スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/05:39 [PR] |
05/31/14:36 セキュリティと利便性はトレードオフたまに、不具合の調査の相談なんかで呼ばれていく。 最初に状況の説明があって 「なるほど、じゃ本番サーバーの状態見てみようか。今ログインしてる?」 って聞くと 「あ、今、切れちゃったんで・・また接続します」 みたいに言われることがある。 で、また、ソースなんかを追って、もう一度サーバーの状況見ようとすると、またセッションが切れている。 この何度もつなぎ直すのがとても面倒・・。 これ、サーバーの設定なんだよね。 ゆったりした不具合調査ならまだ良いんだけど、突然緊急で呼ばれてログインすることになったサーバーがそんな設定になっていると、ちょっとイラっとくることがある。 で、普段はお任せなんだけど、今日はちょっとした社内案件でサーバーを設定する必要があって誰も手が空いてなかったので久々に私の方でセットアップ。 ついでに、設定の方法をここに書いておく。 /etc/ssh/sshd_config このファイルに ClientAliveInterval ClientAliveCountMax という項目を追記すれば良い。 ClientAliveIntervalは生きてるか確認するための間隔(秒単位)。ClientAliveCountMaxはタイムアウトになっていた場合に再確認する回数。 例えば、仮に10分に設定したいなら ClientAliveInterval 60 ClientAliveCountMax 10 とかってやれば良い。 具体的な数値は、各プロジェクトのプロジェクトマネージャーの指示のもと設定すれば良いと思うけど、デフォルトだと、ほぼ毎回セッション切れている画面に遭遇するレベルだと思うので、適切に変更すべきだと思う。ちなみに、ClientAliveIntervalのデフォルトは0で、0の場合は生存確認すらしてくれない。 ということで、なんか怒っているような文章になってしまっているけど、ちょっとした設定で今後の皆のストレスが軽減されるならやった方が良いね。 セキュリティと利便性はトレードオフ、ほど良いバランスが大事だねー
PR
|
05/27/09:44 百聞は一見に如かず前に、ゲンキングさんが検索はinstagramと言っているのを聞いて、この人は何言っているのかな、と思ったけど、今朝のNHKによると今の若い人たちの過半数はinstagramやtwitterで検索をするらしい。GoogleやYahooなどのいわゆる検索エンジンの利用が過半数以下とは・・。 確かに、写真は一見してわかる、というメリットがある。そして、プロが情報を加工して出すまでには時間がかかるし、一番情報が早いというのもそうかもしれない。最近では先行公開みたいのがプロのメディアだけでなく影響力のある個人も招かれたりするし。ファッション、グルメ、その他個人向けの消費にからむものは確かにそうかもしれない。 百聞は一見に如かず、とはよく言ったものだ。確かに、百回聞くよりも一回見た方が理解できることも多々有る。 (もっとも、おそらく原義は聞く、見る、の比較といよりは間接的か直接的かの比較だと思うが) ただ、instagramでシステム開発で検索するとどんな結果が返ってくるんだろうか。たぶん、ビジネスや消費ではなく投資に属するものは事情がちょっと違うんだろうな、と思う。 とはいえ、結局、システムも使うのは人なので、消費者の質的変化には注目していないとならない。 発注者は、仕様書などの文字情報は今まで以上に見なくなり、弊社でやっているような、仕様書よりも先にプロトタイプを見せてあーだこーだと仕様協議をすることを望むクライアントがより一層増えるかもしれない。 操作するユーザも、いちいちメニューの文字や説明書きを見ることが今まで以上になくなり、アイコンの種類や配置などで直感的に判断する傾向が高まるかもしれない。 コミュニケーションも、今まで以上に文字では無く、図解が重要になってくるだろう。 この傾向は、もちろん今までもあって、だいぶ昔から言われていたこと。でも、これまでの予想以上にこの傾向が加速する気がする。 昔、大学時代に心理学の教授が「わかった」と「わかったつもり」は大きく違う、という話をしていた。本当は世の中の真実なんてそうそう簡単にわかるものではない。でも、人間は根源的に「わかりたい」という欲望を持っている。ただそこまで努力はしたくない人も多い。 そこで「わかったつもり」にさせるプロがこの世の中にはたくさん登場した。お気軽な納得感を提供するプロだ。人は理解できないものへの恐怖やストレスはハンパないが、たとえ正しくなくても何かしら自分を納得させる材料があれば心の平安を保つことができる。 良い悪い、好き嫌い、はあるかもしれないが、世の中がそうであり、その世の中で成功したいなら、受け入れるしかないかもしれない。 私は、言葉は嫌いじゃない。むしろ、好きな方だと思う。例えば、「鯛」と言葉にすれば一文字で済む情報を、絵や写真で伝えようとしたら手間がかかる。言葉というのはとても効率的で便利な道具であることは間違いない。 ということで、結局はバランスの問題で両方一長一短だ。 ただ、私のケースで言えば、もっと「見せる」技術を強化する必要があるな、と感じる今日この頃なのである。 (ここで「見せる」というのは画像とかってものだけでなく目に見える行動とかそういうのも含む) モチベーションを上げるためにあえて極論を自分の戒めとするなら、「本当の真実なんてどうでもよくて、その人に見えるものだけが、その人にとっての真実なのである」、といったところだろうか。 ふと、学生時代にきいた一つ上の先輩の「私は、あの人が実は良い人だとかって情報はどうでもよくて、その人が私にとって良い人でなければ、その人は良い人じゃない」という名言を思い出した。 言語はシステム屋にとっては最大の武器だけど、極力その武器を使わない戦い方を学んでみよう。そしたら一歩進んだ成果を手に入れることができるかもしれない。
|
05/26/15:09 MySQLで既存データから新しいテーブルを作成既存テーブルのある一部の列だけ、とか、変換や集計した結果を、とかいろんなパターンがあるだろうけど、とにかくコンバート作業なんかで既にあるデータをゴニョゴニョして新しいテーブルに入れたいというシーンはたまにある。 そんな時に、例えば一時テーブルをしっかり定義してCREATE文流して、それにINSERT SELECTでデータを入れ込むなんてことをやったりする。 ふと、昔、SQL ServerでSELECT INTOというのがあったなーと思い出した。 SELECT 欲しいカラム INTO 新しいテーブル名 FROM 既存のテーブル名 WHERE 条件 とかってやると、DDL流さないでもSQLの実行結果で新しいテーブルが出来上がる。超便利。 で、MySQLでもそんなのあるはずだよなと調べてみたら CREATE TABLE 新しいテーブル名 AS SELECT 欲しいカラム FROM 既存のテーブル名 WHERE 条件 という感じで作れるらしい。 CREATE の後がTABLEになっているの以外は、VIEWのCREATE文そのまま。 コンバートの時だけでなく、ログテーブルの古いデータの切り離しとか、いろいろ活躍できる部分はありそう。 いや、DDL流すのと一手間しか変わらないけど、この一手間の精神的なハードルの差は以外と大きい。 例えば、開発の時でも、いくつかのSQLの結果を比較する時に、中断した後とかでも複数のパターンのSQLを毎回実行して流し直す必要がなくて、単に結果が保存されているテーブルのデータだけを見れば良いしね。 この目的ならVIEWでも良さそうだけど、VIEWだと微妙に制限もあるからね。 ということで、知っている人からしたら、今更知ったの?と言われるかもしれない豆知識のご紹介。
|
05/24/19:13 ヤミ研みなさんはヤミ研という言葉をご存知だろうか?
いろんな定義や由来があるだろうが、私が聞いたことがあるのは、その昔、会社の通常業務が終わった後に、電気を消した闇(ヤミ)の中でこっそり有志で研究を続けた、とかってエピソード。 まぁ、実際には、そんなことをやったら法的に問題が発生したりするわけなんだけど、昔の企業には知りつつも目を瞑るおおらかさがあった。 で、こんなことを書くとそれこそ高度経済成長期とかバブル期とかの話かと思われがちだけど、実は普通に21世紀でも行われてる。 私も新人の時は4年上ぐらいまでの先輩たちとヤミ研をしていた。当時はWebの世界ではなくWindowsの世界の人だったので、例えばSQL Server の高価なeditionとか、自宅のサーバーに入れて研究するなんて無理だったし、どうしても会社でやらないとならなかった。 実際のところは、先輩がそれとなく上司に話を通してくれていて、咎められることは一度もなかった。気になっている研究の続きをしたくて、自分のタスクをさっさとこなして勤怠押して、場所を開いている会議室とか喫煙室とかに移動したりして研究を進めながらメンバーを待つ、みたいなこともあった。 そんなのもあって、業務で何か新しい技術に取り組むことになった時に、「あ、業務での経験はないですけど、個人的にはちょっと研究したことがあって・・・」なんて誰かが言うのがよくあった。 逆に言うと、新しいテーマが出てきた時に担当者に任命してもらうチャンスを獲得するのは、そうやって先に「個人的に」やっている人ばかりだった気がする。 でも、Webの世界なんかだと、オープンソースのおかげで環境つくるのも安くできるし、メンバーだって、社内だけでなく社外の人から見つけることもできる。 たぶん、今はもうヤミ研なんてあまり必要じゃないと思う。それは、きっと、良いことなんだろうなと思う。ただ、物理的な距離の問題とかもあって、毎日勤務後に顔合わせるなんてことはできない。ちょっとだけ、寂しい感じもある。 ふと、機会があって、いろんな勉強会を案内しているサイトを覗いたけど、自分の業務と関係ない技術がたくさんあって、本当に楽しそうだった。たぶん、エンジニアは、自分の熟練の技術で何かを作りたいという欲求とは別のところに、自分が全く知らない新しい技術の世界で初心者として学びたいという欲求があるのではないだろうか。 そういえば、去年の年末くらいに会ったあるエンジニアの方は「解き放て!!」とかってキーフレーズを言っていた。 最近、ヤミ研をテーマにした http://monoist.atmarkit.co.jp/mn/articles/1510/09/news046.html こんな記事も見かけた。 他にも https://sankak.jp/ こんなサービスも最近見かけるようになった。 昔、ヤミ研とかやっていたメンバーは、こんなのを利用しているのかもしれないと思った。 でも、けしてオススメしているわけではない。 何より、まず、現職の企業との法的な問題もある。 昔のヤミ研は、やっぱり会社への愛社精神みたいのが根底にあって、今は上を説得できるほどの根拠はないけど、まず先に有志でこっそり進めて結果を出せば、上も納得するはず、そしてそれは結果会社にとって良いことだから・・的な発想があった。 でも、上にあげた2つは、そうじゃない。単に自分の欲求を満たすためだけ、もしくは、真逆で会社の枠を超えて、社会とか世界とかのため、ということなんだろうと思う。 でも、新しい恋人と付き合いたいなら、やっぱり今の関係をきちんと清算しないとね。 ということで、着地点の見えないの文章だけど、そろそろ終わり。 とりあえず、現時点の結論としては、例えば、 https://twitter.com/atnd_kanto こんなところで新しい技術の勉強会を見つけて、新しい世界との接点をもって、視野を広げるくらいが、趣味としてバランスが良いのかなと思う。 視野が広がると、今の仕事上の判断でもいろいろと良い効果があると思うしね。 (もちろん、大前提として、自分の業務の関連技術を一通りおさえた上での趣味の話ね)
|
04/19/14:50 技術採用戦略について過去のブログでもたくさん書いているが弊社はLaravelを標準採用している。
その前は長い間Zend Frameworkを愛用してきた。 使い慣れたフレームワークというのはやはり開発効率に優れている。 フレームワーク自体の開発効率差と、習熟度による開発効率差を比較考量した結果、ほとんどのケースにおいては習熟度による開発効率差のほうが大きく、結果として、同じフレームワークを続ける方を選択することになる。 2011年の夏頃からフレームワークを変えたいなぁと思いつつ、 実際に変更するまでに3年間の月日を要したのには上記の理由によるところが大きい。 もちろん、内部的な根回しや雰囲気作りに時間が必要だったこともある。 誰も長年連れ添ったパートナーを否定されれば良い気分はしない。 2014年の春、弊社ではLaravelを標準採用した。 別にLaravelに変更したくてフレームワークを変えたわけではなく、 フレームワークを変えたくて変更先のフレームワークを検討した、というのが正確なところだ。 どんなに愛用している道具であっても、時が一方向に流れている以上、世界の変化の中で陳腐化していく。 2014年の春は、弊社にとってはまさにそういう時だったと理解している。 次のグラフを見てもらいたい。(クリックすると別タブで拡大表示される)  今日時点でGoogleのトレンドをとったものである。 Laravelは青色、Zend Frameworkは黄色である。 Laravelの最近の勢いは突出している。 そしてZend Frameworkの衰退も半端ない。 青い線(Laravel)と黄色い線(Zend Framework)の線が交わり、 一時的なものではなく有意な差が確認出来る時期がまさに2014年春なのである。 ちなみに、変更先としてLaravelを選択したのは、PG全員で検討して全会一致でLaravelが良いとなったからである。 あのままZend Frameworkを利用し続けていたら、もしかすると今頃はお客様にそのフレームワークを使う理由を聞かれた時に「弊社がそのフレームワークに慣れているので」としか言えず困る事態になっていたかもしれない。 少し話はズレるが、イノベーター理論というのがある。 誤解を恐れず簡単に説明すると、 新しい商品やサービスなどが出てきた時にどの段階で採用するか、 ということに関する理論である。 最初に飛びつく層はイノベーターと呼ばれる。新しいことが大好きで、全体の2.5%を構成すると仮定されている。 次に、アーリーアダプターという層がある。イノベーターほど新しいもの好きではないが、常にウォッチしていて、自分が良いと思うものは周りが追いついていなくても採用する層である。全体の13.5%を構成すると仮定される。 その次の層として、新しいものにはそれなりに慎重な多数派(アーリーマジョリティ、34%)と、さらに過半数が採用するのを見て初めて自分たちも採用する多数派(レイトマジョリティ,34%)が続く。最後に残って頑なに流されない層はラガードと呼ばれ16%を構成すると仮定される。 そして、このイノベーター理論に付随する理論としてキャズム理論というのがある。ざっくり言うと、アーリーアダプターとアーリーマジョリティの間には、質的な変換が起きる必要があるため、そこには簡単に越えられないキャズムと呼ばれる大きな溝がある、という理論だ。新しいものを使うことに快感を覚える人と、不安を覚える人の溝と表現できるかもしれない。 上記のトレンドだけを見ると、すでに多数派(マジョリティ)を構成しているように見える。しかしながら、トレンドとは、あくまで現時点のフローの変化なので、過去の蓄積であるストックまで考えると、Laravelはまだ多数派を形成しているとは言えないであろう。(左にある棒グラフはこの期間の平均を表しているのでそれを見てもそのように判断できる)。私の評価としては、キャズムを超えつつある=アーリーマジョリティに採用されつつある、というレベルだ。(この先が保証されているレベルではない) 経営的なスタンスで言えば、本当はアーリーマジョリティがバランスは良いと思う。守りの戦略としては悪くない。 あの時期にアーリーアダプターとして行動した我々はどちらかというと攻めの戦略をとったことになると思う。 それには、実は我々を取り巻く外部要因だけではなく、内部的な事情もあった。最初に書いたように、使い慣れたフレームワークは開発効率も良く、それらに囲まれた状態はとても居心地も良い。 人は居心地の良い状態に長くいると変化そのものを恐れるようになる。新しい選択肢自体を考えなくなり思考が停止するのだ。 正直なところ、2011年の弊社はそのような雰囲気があった。そこからみんなで変化の気運を高めていき2014年の春にようやく新しく歩み出すことを決断した。あの時期の我々には一定の爆発力が必要だったのだ。アーリーアダプターとして行動した背景にはそのような事情もある。 今後全てのシーンにおいてアーリーアダプタとして行動するわけではない。しかしながら、Laravelの採用というチャレンジを乗り越えた我々は、今後は変化を恐れることもなく、今まで以上に偏見のないフラットなメガネで世の中の技術動向を見ることができるようになるだろう。 このようなチャレンジをし成果を出した弊社のメンバーを、私は誇りに思っている。
|