Quantcast
Channel: A Day In The Boy's Life
Viewing all 287 articles
Browse latest View live

Datepickerで日付を連続して選択できるようにする

$
0
0

jQueryUIのDatepicker ってカレンダー表示にとても便利ですよね。

そのまま使う分にも大体の場合は問題ないのですが個人的にカレンダーから日付を選択した際にカレンダーが閉じてしまうのが不便と思うことがあり、閉じずに連続して日付を選択するようなことが出来ないかを調べてみました。



Datepickerで日付を連続して選択できるようにする


カレンダーから何らかの候補日を選択するとして、それが1つの場合はカレンダーを自動で閉じてくれたほうが面倒がなくてよいのですが、複数の候補日を選択したいといった場合にいちいちカレンダーが閉じてしまうのはユーザーにとって返って面倒になったりします。


日付を選択してカレンダーを閉じさせない方法として一番手っ取り早い方法は、Datepickerをインラインで表示することのようです。

デモ でも確認することができます。

ただ、インライン表示するとデザインの都合などでカレンダーが返って邪魔というケースもあると思うので、カレンダーをオーバーレイ表示しつつ日付を選択しても閉じないようにする方法を調べてみると、下記のサイトが参考になりました。


jQuery Datepicker: Prevent closing picker when clicking a date


幾つか対応方法が記載されていますが、個人的にjQueryUI本体に手を入れるのは避けたかったり、内部処理をオーバーライドするのはjQueryのバージョンの違いからかうまく動作せず、手っ取り早い方法として下記のonSelectオプションにインライン表示(オプション)を切り替える処理で逃げました。


$(function(){    $("#myCalendar").datepicker({        showOn: 'both',        dateFormat: 'yy/mm/dd',        changeYear: true,        changeMonth: true,        yearRange: 'c-5:c+5',        showButtonPanel: true,        onSelect: function (dateText, inst) {            inst.inline = true;        },        onClose: function (dateText, inst) {            inst.inline = false;        }    });});


onSelect(日付を選択した)実行時に内部のインラインオプションをtrueに切替、onClose(カレンダーを閉じた)実行時に元に戻すという処理を追加しています。

Datepickerの内部処理としてインライン表示のフラグが立っていればカレンダーを閉じないようで(インライン表示をしているのでカレンダーを閉じる必要がないということでしょうけど)、それを逆手に取った処理になっています。


ただ、問題はshowButtonPanelオプションを有効にし、今日(Today)や実行(Done)ボタンを表示している場合、日付選択時に実行ボタンが消えてしまうという不具合が出てしまいます。

インライン表示している場合、元々実行ボタンは表示されない仕様のようで、フラグを変えた瞬間に非表示になってしまいます。

元々カレンダーはフォーカスを外すと自動的に消えてくれる仕様になっているので、個人的には実行ボタンを最初から表示しないようにCSSで対応することにしました(今日ボタンは表示したままにする)。


<style>    button.ui-datepicker-close {display: none;}</style>


今日ボタンさえいらないということであれば、showButtonPanelオプションをfalseにして消してしまったほうが手っ取り早いかと思います。






PR: 毛穴ごっそり体験が500円!

$
0
0
とろけるクレンジングで何をしてもダメだった毛穴が…毎日使って、驚きの結果!

Apacheで不要なHTTPメソッドでのアクセスを制限する

$
0
0

最近はRESTなAPIなどを提供するWebサービスが増えてきたりしていますが、それでも不要なHTTPメソッドを利用させることはサービス上のリスクになるケースもあるため、制限をかけたほうが良かったりもします。

ということで、Apacheで特定のHTTPメソッドしか利用させない方法のまとめです。



Apacheで特定のHTTPメソッドを利用できなくする


制限方法は、Apacheの設定ファイル(/etc/httpd/conf/httpd.confなど)に下記のようにLimitExceptディレクティブ を追加します。


<Directory "/path/to/apache/docroot">  AllowOverride All  <LimitExcept GET POST>     Order deny,allow     Deny from all  </LimitExcept></Directory>

上記の制限をかけることでApacheのドキュメントルート以下に対してGETとPOSTのHTTPメソッドしか受け付けなくなります。

Locationディレクティブ内に記述することも可能ですので、その他の制限事項とあわせて書き方を選ぶと良いかもしれません。


また、Limitディレクティブ でも制限を掛けることはできるようですが、こちらはマニュアルに記載のとおり対象のメソッドにのみ制限を書けるため、書いていないメソッドの制限がスルーされてしまいます。

LimitExceptは書いているメソッドに対して制限をかけるのでそれ以外のメソッドを受け付けないという書き方ができます。


制限がうまくかけられたかは他のサーバーなどからcurlコマンドなどを使って実際にそのHTTPメソッドでアクセスして反応を確認するのがよいでしょう。


・ 利用可能なGETメソッドを使ってアクセスしてみる


$ curl http://foo.example.com -X GET<html><head><title>Your Site</title></head><body>hello wolrd!</body></html>

・ 利用できないPUTメソッドを使ってアクセスしてみる


$ curl http://foo.example.com -X PUT<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>403 Forbidden</title></head><body><h1>Forbidden</h1><p>You don't have permission to access /on this server.</p></body></html>

アクセスできない場合、403(Forbidden)が返って来て制限できていることがわかります。


ただ、この方法ではTRACEメソッドは制限できません。

GETメソッドを許可するとTRACEも許可されてしまうようです。

TRACEメソッドを制限かけたい場合は以前に書いた「ApacheでTRACEメソッドを受付けなくする 」を参考にしてみてください。




PDFを他のファイル形式に簡単に変換できるpoppler-utils

$
0
0

元ネタとしては、以前に書いた「Apache Tikaを使ってドキュメントの中身を取り出すPHPプログラム 」にてPDFファイル内のテキストを抽出しようとしたところ、PDFのセキュリティ関連の設定によって中身がうまく抽出できないケースがあったりして、Linux環境上で他にPDFの中身を取り出す方法は無いものかと調べていたらpoppler-utils内に含まれるpdftotextコマンドでうまく取り出せたよ、って話になります。



PDF内のテキストを取り出す


先に結論を書きましたが、pdftotextコマンドを使えばPDFファイル内のテキスト文を取り出すことが可能です。

pdftotextコマンドはpoppler-utilsというパッケージに含まれるため、存在しない場合はyum経由などでインストールしておきます。


# yum install poppler-utils

poppler-utilsにはpdftotext以外にもpdfinfoやpdftohtmlやpdftoppmコマンドなどが含まれています。

余談ですけど、pdf2psコマンドとかもあったりするのですが、こちらはpoppler-utilsパッケージ付属のものではなくghostscriptパッケージ付属のものです。


で、本題ですがPDFファイルからテキストデータを抽出したい場合は下記のように実行します。


$ pdftotext -raw hoge.pdf hoge.txt

上記によりhoge.pdfファイル内のテキストデータをhoge.txtに書き出してくれます。

PDFを開く際にパスワードをつけている場合は


$ pdftotext -upw yourpasswd hoge.pdf hoge

のようにパスワードを指定すれば開けたりします。

また、下記のようにセキュリティの設定をきつくしても抽出はできました(文章のメタデータにアクセスできないと書かれているのに何故)。


PDFセキュリティ設定



その外に便利なpoppler-utilsのコマンドたち


pdftotext以外にも幾つか使えそうなコマンドがあります。

PDFファイルの概要を知りたければpdfinfoコマンドが便利です。


$ pdfinfo test.pdfTitle:          ほげほげ計画書Author:         itboyCreator:        PowerPoint 用 Acrobat PDFMaker 11Producer:       Adobe PDF Library 11.0CreationDate:   Thu Apr 21 10:01:28 2016ModDate:        Thu Apr 21 10:09:55 2016Tagged:         yesPages:          5Encrypted:      yes (print:no copy:yes change:no addNotes:no)Page size:      822.12 x 538.68 ptsFile size:      308122 bytesOptimized:      yesPDF version:    1.6

オプションをつければPDF内のメタデータを取り出すことも出来ます。


$ pdfinfo -meta test.pdf -snip-<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?><x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.4-c005 78.147326, 2015/04/27-13:03:03">   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">      <rdf:Description rdf:about=""            xmlns:xmp="http://ns.adobe.com/xap/1.0/"            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"            xmlns:dc="http://purl.org/dc/elements/1.1/"            xmlns:pdf="http://ns.adobe.com/pdf/1.3/"            xmlns:pdfx="http://ns.adobe.com/pdfx/1.3/">         <xmp:ModifyDate>2016-04-21T10:09:55+09:00</xmp:ModifyDate>         <xmp:CreateDate>2016-04-21T10:01:28+09:00</xmp:CreateDate>         <xmp:MetadataDate>2016-04-21T10:09:55+09:00</xmp:MetadataDate>         <xmp:CreatorTool>PowerPoint 用 Acrobat PDFMaker 11</xmp:CreatorTool>         <xmpMM:DocumentID>uuid:63c700ab-7219-4640-ac8d-8b4937b6a0dd</xmpMM:DocumentID>         <xmpMM:InstanceID>uuid:5f189849-df3a-44ab-a78e-6c342c23d7fa</xmpMM:InstanceID>         <dc:format>application/pdf</dc:format>         <dc:title>            <rdf:Alt>               <rdf:li xml:lang="x-default">ほげほげ計画書</rdf:li>            </rdf:Alt>         </dc:title>-snip-

PDFファイルをHTMLファイルに変換したい場合はpdftohtmlコマンド。

pdftotextの出力結果をHTML形式にしてくれるのかと思ってましたがそうではなく、PDFをHTML表示に変換してくれるコマンドとなってます。


$ pdftohtml hoge.pdf hogePage-1Page-2Page-3Page-4

作成が完了するとHTMLファイルやPDF内で使われている画像ファイルなどが出力されます。


$ lshoge-1_1.png  hoge-2_2.jpg  hoge-3_2.jpg  hoge-3_5.png  hoge-4_2.jpg  hoge-4_5.png  hoge-4_8.png  hoge_ind.htmlhoge-1_2.jpg  hoge-2_3.png  hoge-3_3.png  hoge-3_6.png  hoge-4_3.png  hoge-4_6.png  hoge-4_9.jpg  hoges.htmlhoge-2_1.png  hoge-3_1.png  hoge-3_4.png  hoge-4_1.png  hoge-4_4.png  hoge-4_7.png  hoge.html

ただし、結果のHTMLはオリジナルのレイアウトとかけ離れたファイルになったりしますので、あくまでHTMLファイルに変換するといった場合にしか使えそうにありません。

場合によっては、PDF内の画像を取り出したいといった場合に便利なのかもしれませんが。


PDFを画像ファイルに変換したい場合はpdftoppmコマンド。

こちらはPDFファイルをPPM(Portable PixMap file format)形式の画像に変換してくれるものなんですが、オプションでPNG形式にも変換 できます。


$ pdftoppm -r 100 -png hoge.pdf hoge

-rオプションはDPIを指定できるので解像度を適当なものに指定しましょう(デフォルトは150みたいです)。

変換すると各ページごとに画像ファイルが出来上がります。


$ lshoge-1.png  hoge-2.png  hoge-3.png  hoge-4.png

オプションで開始・終了ページや切り取り位置の指定などもできたりします。

PDFファイルをPDF以外の形式で見せたい場合やファイルのサムネイルを作りたいといった場合に便利かもしれません。





40代のエンジニアの働き方を考える

$
0
0

まぁ、まだ40にはなっていないわけですけど目の前に差し迫ってきているわけで、20代、30代と色々働き方というのは環境やポジションによって変化してくるもので、当然40代ともなると面倒なことも増えだしてなかなかやりたいこともできないといったことも増えてきます。


その中でどういった仕事の仕方をしないといけないのかまたは強いられてしまうのか、誰しも平等に年を取っていく中でそうなったときにどうしておけばいいのか考えておくことは結構大切なことだなと思ったりします。



自分の領域を見つけておく


1つはなんかしら自分がそこで自信をもって仕事をできる領域を作っておくことが大事なのではないかと思うわけです。

エンジニアとしてなら当然技術的な分野になりますけど、Webやネットワークといった大きな領域だけでなく、プログラミングやOSやミドルウェアなど特定領域において深い知識を持っているとよりその武器が強力になっていきます。


ただ、こういった技術的な要素は時代の流れと共に廃れてしまったりして10年後には使い物にならないといったものが多かったりするんですけど、それが何なのか見極めることがとても難しいということです。

無難にメジャーなプログラミング言語やシェアの大きいソフトウェアを選択しておくのはいいと思いますけど、当然母数も多いので凡庸の中に埋もれていくリスクもあったり、次にこれが来る!と賑やかされているバズワードに踊らされていると数年後にあの技術はいったい何だったんだろうということにもなったり。


若いころなら色んな技術を身に着けておきながら時代の変化とともに綱渡りしていくのが頭もまだ柔軟だったり体力面でもカバーできたりもしますのでそれほど難しいことではないのですが、歳を重ねてくると新しい知識を身に着けてくることがしんどくなってきたり、自分が歩んできた領域をなかなか捨てきれずに固執してしまったりで簡単ではないケースもあります。

一番厄介なのは、会社の業務指示によって担当する案件が決まり、その中で身につける知識というものも取捨選択できない場合があるというもので、自分が入社当時のウェブ全盛期であってもまだホストサーバーいじったりしている部署に配属された同僚もいたりして、どうやっても現状ではその知識を応用するのが無理という状況に陥る人も多いんじゃないかと思います。


自分の能力が十分に発揮できる領域を見つけておくとそこで仕事をするということに集中すればよくなりますし、取捨選択もしやすくなります。

取捨選択するというのは要は仕事を選べるようになるということではあるんですけど、それは傲慢に仕事をするということではなく、何でもかんでも仕事をするというのは時間的な制約や能力面で当然できないのできちんと自分の力をフルに発揮できる場所というのを理解しておくということです。


まぁ、個人的にはあまりそういう風にはなりたくないと思ってはいますけど、特定分野の領域を見つけておけばその分野において例えば技術的な現場から離れたとしてもそれまでの知識の惰性で仕事をすることはできたりします。

要するにしゃべりだけで食ってけるみたいなところはあるんですけど、それは会社から与えられるポジションとかによってそうせざるを得ない場合もあったりして現場に固執したいなら結構いばらの道を行かなくてはならかったりもします。



やりたいことに注力するための術を身につける


歳を重ねることに社内のポジションというものも変化してきて、それに伴って色々面倒な仕事も増えてきます。

やりたくない打ち合わせや資料作成や調整事項が増えてきたりして、それによって本来やりたいことへ割く時間も削がれてきますので、少ない時間の中で自分がやりたいことや能力が発揮できる分野へ注力するための術を身につけないと押し流されてしまいます


結局のところ、35歳あたりのエンジニアの定年説とかっていうのは、その人の能力や体力によるものというよりは、会社の組織の中で与えたポジションによってその人が本来力を発揮できる場所からどんどん遠ざけ、つぶしてしまっている結果によるんじゃないかと思ったりするわけですけど、それにあがらうためにはかなり要領よく仕事をしないといけなくなります。

まぁ、あがらわず流されるというのも一つの選択ではありますが。

自分の周りを見ても自分より年上でまだ現場の一線に立っているという人はほとんど見かけません。

大抵は、管理職となりプロジェクトのマネジメントや日々報告資料の作成に忙殺されていたりして、その分与えられる役割や所得なども当然多くはなっているのかもしれませんけど、その仕事を自分がやりたいかと言われればNoだったりもするのであがらう術を見つけるのに四苦八苦したりもしているわけです。

こういったことは、先ほど書いたような仕事を取捨選択することもそうですし、今まで自分がやりたかったことというものを改めて見直して、その中でも特に注力したい部分を切り分けていく必要があります。

単にプログラミングがしたいというところから、どのレイヤを担当するのか、それ以外は誰に任せるのかといった外せない領域と捨ててもいい領域というものを割り切らないといけなかったりもします。
そうした割り切りの中でも、メンバーのリソースを見ながら担当を決めたり、その人の教育過程も考慮してアサインしようといったマネジメントの視点でのコントロールも必要になってきて、単に自分の領域を守るというだけでなく全体を俯瞰して考えておかないとなかなか上も自分がそのポジションにいることに納得してくれなかったりするので難しいところです。


結局のところ経験と共に会社から与えられるポジションによって面倒な仕事というのは増える一方であったりもするわけで、集中してやりたいことをやる時間というのはかなり細切れになってきます。

合間合間に打ち合わせが入ったり、部下の管理に時間を割かれたり、資料の作成をせかされたり。

おのずとやれることも少なくなってきますし、やることを固めていかないとストレスになるだけなので、自分がやらなくてもいいことを任せられる人が近くにいる、そういうポジションについておくことも重要になってくると思ったりもします。

まとめ


これが自分の領域だという場所を見つけておかないと、なかなか40代にもなって仕事が楽しいで働けないんじゃないかと思います。

まぁ、結婚して子供がいたりすると収入面で仕事を辞めれない状況にもなってくるので、仕事に楽しさなんて求めてる場合じゃないってなりますし、そもそも仕事することが単に収入を得るためだけというような考え方にも偏ってきたりもしてきます。


そういう状況に陥らないためにも、不得意なところで勝負したり、やりたくないことを我慢しながら仕事をするのではなく、ここでなら力が発揮できる領域というものを若いうちから探しておくというのが40代になっても後悔しない仕事の仕方になってくるかもしれません。

なので、20代、30代のうちから自信をもって勝負できる場所、楽しめる場所というものを模索していくのって大事なことではないかと思います。





PR: ジカウイルス感染症!何が危ない?どう防ぐ?-政府広報

$
0
0
中南米中心に流行!渡航する方の注意点は? 国内でも蚊の発生を抑える対策を

EclipseのGit関連操作のショートカットを作成する

$
0
0

Eclipse+Git(EGit)を使った開発環境を使うことが多いのですが、Eclipse上でGit操作をするとなるとGUI上での操作が多くなります。

メニューからチーム→コミットとか、チーム→切り替え→ブランチ選択とかするのって操作が頻繁になると結構面倒になったりもします。

ということで、こういったGit関連操作に対してショートカットを設定する方法のまとめです。
(書いている内容はGitに限ったことではなく一般的なEclipseのショートカットキーを設定する方法です)
使っているEclipseのバージョンは4.4(Luna)です。



Eclipseのショートカットを変更する


通常、Eclipseでショートカットの設定を変更したい場合は、「ウィンドウ」→「設定」メニューから「一般」の中にある「キー」の項目にて変更ができます。

フィルタ欄にGitとかいれるとGit関連の操作がずらっと表示されるので、それに対してショートカットキーを割り当てていきます。


Eclipseショートカット設定-1


デフォルトで設定されているのはコミットぐらいなのですが、このショートカットキーのCtrl+#って実際使えないので、使いたい関連操作にショートカットキーを割当てなおしたほうが良さそうです。

割当てたい操作をクリックし、下のバインディング欄に実際にコマンドを入力します。

そして、「場合」のプルダウンメニューからどの操作中にキー操作が行われてたら反応するかを決定します。
下記の場合は、PHPソースの編集中(PHPファイルとして保存しているものが対象)にCtrl+Alt+Cのキーを押すとコミットを実行するといった具合です。


Eclipseショートカット設定-2


あとは、よく使う操作にショートカットキーを好きに割り当てていきます。
個人的には、コミット以外は


・ ブランチ(ブランチの切り替え)
・ ヒストリーに表示
・ プル
・ マージ


当たりがよく使うのでショートカットキーを割当ててます。
GUIだとメニューを辿っていったり表示されるまでの若干のタイムラグがストレスだったりもしますしソース書く上ではキーボード操作が中心なので、そこで完結する操作が出来てしまったほうがかなり開発効率が上がるのではないかと思います。




[Laravel] URL内のスラッシュ区切りパラメータをInputで受け取る

$
0
0

通常、パラメータの受け渡しはPOSTの場合はHIDDENタグで飛ばしたり、GETの場合はURLの最後に?foo=barのように書いて送信しますが、今時のサービスだと下記のようにURLの最後にスラッシュ区切りでパラメータを指定するようなものが多かったりします。


/app/test/123/itboy

上記の場合、123とitboyがパラメータ。

で、最初に書いたようなPOST/GETでのパラメータ送信は、Laravelでは通常コントローラでInput::get('パラメータ名')やInput::all()で全部受け取ったりすることが出来るんですけど、上記のようにスラッシュ区切りでのパラメータの受け渡しの場合、Inputで取得ができません。


※ Laravel4.2で検証してます。


以下、サンプルのプログラム。


Route::any('test/index/{id?}/{name?}', 'TestController@anyIndex');


public function anyIndex($id, $name){    var_dump($id, $name, Input::all());}

結果(GET/POSTで同様)。

 

string(3) "123" string(5) "itboy" array(0) { }

アクションのメソッドの引数としては正常に受け取れるのですが、Input(Request::all()でも同様)を使ってリクエストを直接受け取ることができません。

また、当たり前ですけどPHP標準の$_POSTや$_GETなどのスーパーグローバル変数にもパラメータは格納されていません。

URL上の構成要素からLaravelのルーティングがここまでがURLで、ここからがパラメータという扱いをしているだけだと思うので、これは当然の仕様かもしれません。



URL内のスラッシュ区切りのパラメータを受け取る


ここからが本題なのですが、確かにコントローラで引数として受け取れるなら通常は問題ないわけですが、場合によりInput::get()とかリクエストを一緒くたに扱いたいといった場合があります。

そんなときに、無理やりInput::get()を使ってスラッシュ区切りのパラメータを受け取るやりかたなわけですけど、下記のようにすることで受け取ることができます。


public function anyIndex($id, $name){    $slashParams = Route::getCurrentRoute()->parameters();    Input::merge($slashParams);    var_dump(Input::all());}

Route::getCurrentRoute()->parameters()にて、スラッシュ区切りのパラメータを受け取り、それをInput::merge()で無理やりInput内に取り込んでしまいます。

結果(GET/POSTで同様)。


array(2) { ["id"]=> string(3) "123" ["name"]=> string(5) "itboy" }

コンストラクタやbeforeFilter()などにうまく書いておけばより便利かもしれません。

1点、注意が必要なのが結果がルーティングの書き方によって変わってくるという点です。

最初のroute.phpのようにURL構成上のパラメータをそれぞれなんと言う変数名で受け取るかを指定していた場合は、正しくその変数名で受け取ることができるのですが、下記のようにコントローラベースのルーティングを書いていて、パラメータに対応する変数の指定がない場合にはパラメータ名がLaravelによって勝手に振られた名前になってしまいます。


Route::controller('test', 'TestController');

上記の場合、コントローラの引数で$idや$nameには正しくURL上のパラメータが格納されているのですが、Route::getCurrentRoute()->parameters()で受け取った結果は下記のようになります。


array(2) { ["one"]=> string(3) "123" ["two"]=> string(5) "itboy" }

ですので、ルーティングの書き方によっては使いづらいものになったりもするので、併せてルーティング方法も見直したほうが良いかもしれません。






ブログをはじめて10年が経過してました

$
0
0

なんとなく8月に始めたことは覚えてたんですけど、確認してみると2006年8月21日に初めての投稿があり、いつの間にか10年が経過してました。

ブログを始めてN年が経ちました的な記事は過去にも書いたことがあるんで、毎回同じようなことを書いてたりもするんですけど、ここまで長く継続できたものというのも自分の中で初めてのことであり、よく飽きもせずに書いてこれたものだなと自分に感心をしたりもします。

 

今やネットの中で情報発信するサービスというのは数知れずあるわけですけど、こうして長く情報発信している場所があると、そこがネットの中のホームグラウンド的な位置づけに感じられたりします。

もちろん引っ越しして新しい場所に住まうこともできるわけですけど、かえって面倒くさがりやな性格が幸いしてかずっとこの場所に居続けることにしたことが長く続けられたことにつながったのかもしれません。

そういう意味では、同じ年数だけサービスを維持してくれたAmebaさんにも感謝ですね。

 

また、そういったネットにおける自分の活動の基点があると、何かあればここに書けばいいやといった安心感もあったりします。

ネット上にはいろんなサービスがあり、情報発信や表現は様々なわけですけど短い文章でも、こうしただらだらとした長い文章でも、写真でも動画でもある意味何でも発信できてしまうブログというのは自分にとっては結構都合のいいものに感じられたりもしています。

 

最初はそのホームグラウンドをなるべく賑やかにそして大きくしようと思ってたりもしてましたけど、書く記事に偏りがあったりあまり面白みのある記事がかけなかったりもするので、その辺についてはずいぶん前に諦めが出てきたりもしました。

そういう諦めが、気が向いたときに書けばいいや的な割り切りに変わったことで変に肩ひじを張らずにやってこれたのだと思います。

 

続けるだけに意味があるのか、というのもあると思いますけど続けることで表現方法も少しは自分の中で変わってきたかなと思いますし、技術的な記事をまとめることで頭を整理できたり、またその情報を取り出しやすくなったりと自分の中では一定の効果があったと思います。

多くの人に見られたり反応があったりといったプラス面が続けることのモチベーションになるというのは当然ありますが、炎上したりといったこともなかったので、波風立たなかったことが止める選択肢やマイナスのモチベーションを生み出さなかったことで継続できたというのが自分の中ではあるのかもしれません(そんなハート強くないんで)。

 

祝10周年!なんてことも忘れて、タイトルの通りいつの間にか10年経っていたという緩さを持ちつつ、この先も自分のペースでブログを書き続けられたらと思います。

 

 

 

嫌われる勇気 自己啓発の源流「アドラー」の教え

$
0
0

 

 

心理学って大学のころに少し学んだなーぐらいであんまり興味を持てずにいたのですが、それは十人十色で人それぞれですから心理学といっても人間全般を包括できるような心理的な概念を見出すのって不可能じゃないかなと思ったりもしてたからなんですけど、改めてちゃんと読んでみるととても考えさせられる内容の本でした。

原因と結果という原因論というのは結構仕事の中でも言われることが多かったりして、よくない状況に陥った時にその原因を突き詰められたりするわけですけど、この本に書かれているその結果にあるのは自身がその状況を望んでそうしているという目的論というのがとても斬新なものでした。

 

すべての悩みは対人関係にあるというのも納得できる部分がありますし、その対人関係の悩みにおける課題を分離して、悩みの原因を切り分けようという発想もなるほどと思うところがあります。

これは自分は自分、他人は他人というものであったり、そんなこと相手は微塵も考えていないから単なる被害妄想だ、というものであったりもするんですけど、簡単に言えるものの結構日常ではその課題の分離というのは難しかったりもします。

 

嫌われることを恐れたり、相手の顔色を窺ってふるまったりしてしまうというのは誰しもよくあることで、簡単に「それは君の問題だから自分には関係ない」などといったドライな考えは持てなかったりもします。

それによって面倒なことに巻き込まれたり、日々の生活の中で取るべき行動が複雑化していくことは日常で身をもって体験していくことですが、それを自分が解決するべき問題なのか、相手が解決するべき問題なのかという判断を改めてしていくと、自分における悩みの範疇ではないという気づきとそれによって開放される悩みも多いことに気づいたりもします。

 

結局のところ、自分の生き方を決めるのは自分であって他人ではないというごくシンプルで当たり前のことを改めて痛感させてくれ、それを踏み出す勇気を与えてくれる本でもあります。

 

 

目次

 

第一夜知られざる「第三の巨頭」なぜ「人は買われる」なのかトラウマは、存在しない人は怒りを捏造する過去に支配されない生き方ソクラテスとアドラーあなたは「このまま」でいいのかあなたの不幸は、あなた自身が「選んだ」もの人は常に「変わらない」という決心をしているあなたの人生は「いま、ここ」で決まる第二夜なぜ自分のことが嫌いなのかすべての悩みは「対人関係の悩み」である劣等感は、主観的な思い込み言い訳として劣等コンプレックス自慢する人は、劣等感を感じている人生は他社との競争ではない「お前の顔を気にしているのはお前だけ」権力争いから復讐へ非を認めることは「負け」じゃない直面する「人生のタスク」をどう乗り越えるか赤い糸と頑強な鎖「人生の嘘」から目を逸らすな所有の心理学から使用の心理学へ第三夜承認欲求を否定する「あの人」の期待を満たすために生きてはいけない「課題の分離」とはなにか他社の課題を切り捨てよ対人関係の悩みを一気に解消する方法「ゴルディオスの結び目」を断て承認欲求は不自由を強いるほんとうの自由とはなにか対人関係のカードは、「わたし」が握っている第四夜個人心理学と全体論対人関係のゴールは「共同体感覚」なぜ「わたし」にしか関心がないのかあなたは世界の中心ではないより大きな共同体の声を聴け叱ってはいけない、ほめてもいけない「勇気づけ」というアプローチ自分には価値があると思えるためにここに存在しているだけで、価値がある人は「わたし」を使い分けられない第五夜過剰な自意識が、自分にブレーキをかける自己肯定ではなく、自己受容信用と信頼はなにが違うのか仕事の本質は、他社への貢献若者は大人よりも前を歩いているワーカホリックは人生の嘘人はいま、この瞬間から幸せになることができる「特別な存在」でありたい人が進む、ふたつの道普通であることの勇気人生とは連続する刹那であるダンスするように生きる「いま、ここ」に強烈なスポットライトを当てよ人生最大の嘘無意味な人生に「意味」を与えよ

 

 

 

 

運営体制とサービスの衰退

$
0
0

社内でもいくつも業務改善のプロジェクトなんかが立ち上がっては推進されていくわけですけど、数年もしないうちに一気にしぼんでそのサービス自体が衰退してしまうケースってよく見受けられます。

こういうのってプロジェクトオーナーがかじ取りを誤ったり、予算取りがうまくいかずにとりあえず現状維持をしていくうちに使われなくなってきたり、軌道に乗ったのを見るとあとは惰性で何とかなるんじゃないかと一気に熱意が失われていったり色々なんですけど、結局のところしっかりとした運営体制を最初に作りそれを維持できるのかという点が結構大きいと感じたりします。

 

 

サービスの裏に人

 

当たり前ですが、何らかのシステムとか仕組みを作ってサービスを始めたところで、それを支える裏の人というのは当然必要になります。

システムは道具であるわけですから道具を手入れしたり、活用方法を広めていかないと誰も使われなくなります。

 

プロジェクトの開始にはこういった体制をしっかり意識しようとはするものの、月日の流れとともに役割や組織の変遷を経てそれを維持するための裏の人がどんどんとポジションを離れて行ってサービスを維持することができなくなるのはよく見かけます。

かろうじて維持できていたとしても、そこに何らかの意思をもって対処する人はいないわけで、そんなサービスに未来などないわけです。

当然、中の人も「これやってだれか見る人はいるのだろうか」「この作業に意味はあるのだろうか」などとモチベーションも低下することになります。

 

サービスというのは作ることが目的ではなく、それを活用し維持し発展していくことが前提としてあって、その先に求めていた成果があるはずなのに多くは作ることに注力して、できればあとは何とかうまく回っていくだろうという楽観的な発想を持っている人が多かったりもします。

たぶん、当初の計画の中ではサービスのロードマップとして、何をどうしておけば集客や利用率や成果を得ることができるだろう絵空事が描かれているのだと思いますが、当然そんなものは計画通りにいくとは限りません。

また、月日の流れやニーズの移り変わりとともにそのサービスも姿を変えていかなくてはいけないわけですが、そういったことは当初の計画の中には当然盛り込まれていないことで、運用していく中でその部隊がうまく考えてやっていくでしょうというかなりグレーゾーンとして考えられたりもします。

 

結局のところ、サービスの裏には人が必要だというごく当たり前のことがちゃんと考えられていないせいで維持することができない状況になったりするわけです。

 

 

目的・目標を語る人

 

プロジェクトを開始した当初はあれほどそのサービスの必要性を訴えていたのに、いざできてしまうとそれに満足して主力部隊を次のプロジェクトに回してしまうケースもよくある話です。

中の人が変わると引継ぎの過程でそのサービスの目的や意図を正確に把握できなくなったり、新しい人にそのサービスの未来を描くモチベーションを持ってもらうのはなかなか難しいことではあります。

 

また、サービスイン後にプロジェクトで描かれた目標というものを定量的に評価しながら、ずれなどがあればうまく軌道修正する役割の人というのは必要なわけですけど、多くはサービスを作ってしまえば当初の目的や目標というのは忘れ去られてしまうケースが多いのではないでしょうか。

まぁ、数年後に似たようなプロジェクトが立ち上がったりして、「その目的ってどっかできいたことある・・・」とか「あのサービスを作ったのはなんだったのだろうか」とかになるわけです。

それでも「あのサービスはここがよくない」とか「あれ、もう誰も使ってないでしょ?」とか言われてよくわからない道路工事のように掘っては埋めるという誰も得しないプロジェクトが生まれては消えていくことになります。

 

かしこまって目的や目標などを語りだすと周りが距離を取り出すことはあったりもするのですが、それでも誰かがそのサービスの未来というものを描かない限り、何を指標に進めばいいのかわからなくなり混乱を招きます。

こういった混乱は継続するとそのサービスを維持することの意義が失われることにもなってくるので、単純な話そのサービスを誰が何のためにどこに向かわせるのかということを定め、それを常に示すことができる人がいるということが大事なのではないかと思うわけです。

 

 

 

[PHP] 簡単に画像の加工ができるintervention/image

$
0
0

ユーザーがアップロードした画像を加工したいといった場合、Linux系なら「ImageMagickを使ってコマンドラインからCAPTCHAを作ってみる」に書いたようにコマンドラインから画像を加工する方法もありますが、 intervention/imageを使えばPHPのプログラム内で簡単に加工をすることができたりします。

intervention/imageを利用する場合、PHP5.4以上でGDまたはImageMagickがインストールされている必要があります。

 

 

intervention/imageを使ってみる

 

まずは、インストール方法ですがcomposer経由でインストールができます。

composer.jsonを使う場合は、下記のような定義ファイルを用意しcomposer updateを実行します。

 

{    "require": {        "intervention/image": "2.3.*"    }}

 

または、直接composerコマンドから指定してインストールします。

 

$ composer require intervention/image

 

Laravelから使いたい場合は、app.phpにサービスプロバイダに追加すれば使えます。

 

'providers' => array(    -snip-    'Intervention\Image\ImageServiceProvider',),

 

簡単なサンプルプログラムとしては下記のようなものになります。

 

<?phprequire 'vendor/autoload.php';use Intervention\Image\ImageManagerStatic as Image;$image = Image::make('./foo.jpg')->resize(150, 100)->save('./hoge.jpg');

 

autoload.phpを呼び出し、名前空間の定義をしてstaticでメソッドを呼び出しています。

staticではなくクラスオブジェクトを生成して使うことももちろん可能です(公式のサンプル参照)。

上記の場合、画像の加工としてはfoo.jpgに対して150x100pxにリサイズし、hoge.jpgとして保存しています。

その外に出来ることは、公式マニュアルのAPI一覧を見ればわかるかとおもいますが、代表的なものを紹介します。

 

□ 画像を曇らせる(ぼかす)

 

$image = Image::make('./foo.jpg')->blur(50)->save('./hoge.jpg');

 

blur()の引数で曇らせる度合いを指定します。

 

 

□ 明度を変える

 

$image = Image::make('./foo.jpg')->brightness(50)->save('./hoge.jpg');

 

brightness()の引数で明度を調整できます。

 

 

□ モノクロにする

 

画像を白黒にするあれです。

 

$image = Image::make('./foo.jpg')->greyscale()->save('./hoge.jpg');

 

□ 透明化する

 

Image::make('./foo.jpg')->opacity(50)->save('./hoge.jpg');

 

opacity()の引数で透明度を調整できます。

 

□ 画像の一部を切り抜く

 

$image = Image::make('./foo.jpg')->crop(50, 50, 45, 25)->save('./hoge.jpg');

 

crop()の第1、第2引数は切り抜いた画像のサイズ、第3、第4引数は切り抜き位置(X座標、Y座標)を指定します。

 

□ 画像の余白を削除する

 

キャンパス内に余白がある場合にそれを削って画像の大きさにフィットさせることができます。

 

Image::make('./abc.png')->trim()->save('./hoge.jpg');

 

□ 画像を反転する

 

Image::make('./foo.jpg')->flip('v')->save('./hoge.jpg');

 

flipの第1引数にvを指定すると上下反転させます。デフォルトは左右反転です。

 

 

□ 画像のフォーマットを変更する

 

専用のencode()というメソッドがあるようですが、save()で指定したファイル名でフォーマットを決めて保存することも出来ます。

 

Image::make('./foo.jpg')->save('foo.gif');

 

encode()メソッドの特徴としてdata-urlオプションを指定するとRFC 2397形式のdata://のURIスキームを返してくれたりします。

 

$image = Image::make('./foo.jpg')->encode('data-url');echo "<img src="$image" />";

 

□ 画像の情報を取得する

 

下記は、画像のサイズを取得します。

 

$size = Image::make('./foo.jpg')->filesize();

 

下記は、画像の高さや横幅を取得します。

 

$height = Image::make('./foo.jpg')->height();$width = Image::make('./foo.jpg')->width();

 

下記は、画像のMIMEタイプを取得します。

 

$mime = Image::make('./foo.jpg')->mime();

 

下記は、画像のexifを取得します。

 

$exif = Image::make('./abc.jpg')->exif();

 

出力例。

 

array(48) {["FileName"]=> string(7) "abc.jpg"["FileDateTime"]=> int(1478581452)["FileSize"]=> int(188983)["FileType"]=> int(2)["MimeType"]=> string(10) "image/jpeg"["SectionsFound"]=> string(46) "ANY_TAG, IFD0, THUMBNAIL, EXIF, INTEROP, WINXP"["COMPUTED"]=> array(10) {    ["html"]=> string(24) "width="640" height="480""    ["Height"]=> int(480)    ["Width"]=> int(640)    ["IsColor"]=> int(1)    ["ByteOrderMotorola"]=> int(1)    ["ApertureFNumber"]=> string(5) "f/2.8"    ["UserComment"]=> string(1) " "    ["UserCommentEncoding"]=> string(9) "UNDEFINED"      ["Thumbnail.FileType"]=> int(2)    ["Thumbnail.MimeType"]=> string(10) "image/jpeg"}-snip-

 

□ 画像を一から作る

 

かなり手間にはなりますが、画像を一から作ることも出来ます。

 

// 300x300pxの灰色のキャンパスを作成$image = Image::canvas(300, 300, '#999');// 左上から右下にかけて線を引く$image->line(0, 0, 300, 300, function ($draw) {    $draw->color('#0000ff');});// 長方形を描く$image->rectangle(20, 20, 250, 250, function ($draw) {    $draw->background('#00ff00');});// 中心部に円を書く$image->circle(50, 150, 150, function ($draw) {    $draw->background('#ff0000');});$image->save('./hoge.jpg');

 

それぞれコールバック関数を指定できるのでその中で線や塗りつぶしの色を指定することができたりします。

 

 

まぁ、正直よく使いそうなのは画像のフォーマットの変換やリサイズぐらいかなとは思うのですが、導入も簡単なので画像を加工したい場合に使ってみると良いかと思います。

 

 

 

 

サービスの質について考えてもらうこと

$
0
0

自分一人がエンジニアとしてシステムの開発に携わっている頃はそれほどサービスの質というものをあまり意識したことがなかったのですけど、ある程度チームを管理する立場になってくると下から上がってくるその質というものに敏感にならざるを得ないことは日常よくあることです。

しかし、そのサービスの質をどうやって向上させればいいのかというのはなかなか難しいもので日々頭を悩ます問題でもあります。

 

 

サービスの質を意識する

 

もちろんサービスの品質を上げる手段というものは世の中たくさんソリューションが出ていたりもします。

単体テストのツールからSeleniumのようなブラウザを使ったテスト自動化ツールであったり、Redmineのようなバグトラッキングシステムで情報を管理したりと多角面から質を向上させる取り組みというものを取り入れたとしても、当のエンジニアたちがそれをうまく活用し、効率的に不具合を見つけて改善することを開発のサイクルの中で実施していかないと質の向上には結びつきません。

 

しかし、エンジニアは納期などの制約からテストをおざなりにしているケースはよくある話で、テストそのものに時間を割かれることを嫌う人もいたりします。

それがリリース後に不具合として発見され、バグの修正だけでなく面倒な報告書の作成や上司やお客さんへの謝罪など、テストをすること以上の時間が割かれることになるとしても。

品質への意識が薄いと言ってしまうことは簡単ですが、なかなかエンジニア自身が率先してテストをするというのは本人たちの意識が高くないと無理ですし、多くは開発工程の制約としてテストをする際のルールを厳格化し、それを順守しているように整備されているのだと思います。

 

結局のところ、テスト自体も開発工程の一作業としてでしか認知されず、形骸化した作業の中ではサービスの品質はそれほど上がることなく、リリース後に多くの不具合が発見されたりもします。

システムは多くのモジュール化されたプログラムの寄せ集めであり、その1つ1つが正しく動いたとしても結合した際に不具合が出たり、また動作はするもののそれが仕様通りではないというケースもあったりして、不具合を発見することは実際に人が見て触れて判断を下さないといけない場合も多くあります。

これは、単に動作が想定通りかどうかというものではなく、実際に動くものを目にしたときにより良いものに作り替えるための判断も含まれているわけです。

 

テスト自体が一作業として成り下がってしまうと、テストがパスしているから問題ないとスルーされ、受け入れや実際にユーザーが使い始めた際に不具合だけでなく仕様バグとしての指摘を受けたりします。

それが許される環境ならそれでブラッシュアップしていけばいいでしょうけど、それはそれでエンジニアとしても「不具合があれば誰かが報告してくれる」という受け身の癖がついてしまったりして問題です。

これは、開発者とテスターを分けるような体制で構築を進めた際もよく起きたりして、とてもテストする品質でもないのにそれがテスト工程に持ち込まれたりしてひと悶着あったりもします。

 

 

品質を上げる意味と意義

 

最初に自分一人がエンジニアとしてシステム開発に携わっていたころはこのサービスの質について意識しなかったというのは、もちろん経験が少なかったということもあるのですが、もう一方の視点として自分がその質を担保するしかない状況にあったことや、自分が作ったものだからある程度そのシステムに愛着があったからというのもあります。

なので、実際には無意識にそれを意識せざるを得ない状況だったのだと思います。

まぁ、その質とやらは置いとくとして。

 

これはある意味環境に恵まれていたのだと思いますが、自分たちで何かを生み出しそれを進展させることができたからそれに伴う品質というものも意識することができたというもので、現状のエンジニアを取り巻く環境というのは「新人エンジニアの教育を悩ませる7つの環境と課題」に書いたように、何かを一から生み出すということはやりづらい状況であったりもします。

もちろん、日々何か新しいサービスを生み出し、開発の案件を受託して仕事をしているのだと思いますが、それは自分が考えたものではなく誰かが作ったものを保守したり、自分とは遠く離れた場所で出来上がった設計仕様に基づいて構築をする話であったりして、それに対して愛着なんてものもなく、また多くの関係者がいる中でその責任の所在というものも曖昧になったりもします。

 

自分が担当している領域はある程度明確にはなっているので、その範囲で問題が起きないよう、怒られない程度に品質を担保していこうとする意識は働くと思いますが、積極的に品質を高めていく取り組みというのはなかなか行われません。

ひどく整備された開発のタスクや役割の中ではその品質を高めるための取り組みというのは、担当チームや組織が用意されていたりもして、開発チームでは余計なことはするなとばりに、自分の領域の仕事を全うすることに注力をさせられたりもします。

 

結局のところ品質を高めるためのツールや手法というものは世の中にたくさんあるわけですが、それをエンジニアたちが積極的に採用し品質を高める行動を自発的に促していくという意識を持ってもらうことに難題があったりします。

自分たちが作っているものが何なのか、実際にお客さんや利用者と対話しそれを実感してもらうことも大事なのかもしれませんが、規模が大きくなってきたりすると末端のエンジニアまで同行させることが難しかったり、ヘルプデスクのような現場の声を聴ける業務を担当してもらうことも本業が忙殺される中ではなかなか難しかったりもすることです。

 

しかし、やはりそのような意識の変革をもたらすためにはエンジニア自身が担当としての役割だけでなく、何に貢献をしているのかその意味をきちんと理解してもらう必要があるのではないかと思ったりします。

 

 

 

 

Datepickerで日付を連続して選択できるようにする

$
0
0

jQueryUIのDatepicker ってカレンダー表示にとても便利ですよね。

そのまま使う分にも大体の場合は問題ないのですが個人的にカレンダーから日付を選択した際にカレンダーが閉じてしまうのが不便と思うことがあり、閉じずに連続して日付を選択するようなことが出来ないかを調べてみました。



Datepickerで日付を連続して選択できるようにする


カレンダーから何らかの候補日を選択するとして、それが1つの場合はカレンダーを自動で閉じてくれたほうが面倒がなくてよいのですが、複数の候補日を選択したいといった場合にいちいちカレンダーが閉じてしまうのはユーザーにとって返って面倒になったりします。


日付を選択してカレンダーを閉じさせない方法として一番手っ取り早い方法は、Datepickerをインラインで表示することのようです。

デモ でも確認することができます。

ただ、インライン表示するとデザインの都合などでカレンダーが返って邪魔というケースもあると思うので、カレンダーをオーバーレイ表示しつつ日付を選択しても閉じないようにする方法を調べてみると、下記のサイトが参考になりました。


jQuery Datepicker: Prevent closing picker when clicking a date


幾つか対応方法が記載されていますが、個人的にjQueryUI本体に手を入れるのは避けたかったり、内部処理をオーバーライドするのはjQueryのバージョンの違いからかうまく動作せず、手っ取り早い方法として下記のonSelectオプションにインライン表示(オプション)を切り替える処理で逃げました。


$(function(){    $("#myCalendar").datepicker({        showOn: 'both',        dateFormat: 'yy/mm/dd',        changeYear: true,        changeMonth: true,        yearRange: 'c-5:c+5',        showButtonPanel: true,        onSelect: function (dateText, inst) {            inst.inline = true;        },        onClose: function (dateText, inst) {            inst.inline = false;        }    });});


onSelect(日付を選択した)実行時に内部のインラインオプションをtrueに切替、onClose(カレンダーを閉じた)実行時に元に戻すという処理を追加しています。

Datepickerの内部処理としてインライン表示のフラグが立っていればカレンダーを閉じないようで(インライン表示をしているのでカレンダーを閉じる必要がないということでしょうけど)、それを逆手に取った処理になっています。


ただ、問題はshowButtonPanelオプションを有効にし、今日(Today)や実行(Done)ボタンを表示している場合、日付選択時に実行ボタンが消えてしまうという不具合が出てしまいます。

インライン表示している場合、元々実行ボタンは表示されない仕様のようで、フラグを変えた瞬間に非表示になってしまいます。

元々カレンダーはフォーカスを外すと自動的に消えてくれる仕様になっているので、個人的には実行ボタンを最初から表示しないようにCSSで対応することにしました(今日ボタンは表示したままにする)。


<style>    button.ui-datepicker-close {display: none;}</style>


今日ボタンさえいらないということであれば、showButtonPanelオプションをfalseにして消してしまったほうが手っ取り早いかと思います。





サービスの品質について考えるテスト以前のこと

$
0
0

自分一人がエンジニアとしてシステムの開発に携わっている頃はそれほどサービスの質というものをあまり意識したことがなかったのですけど、ある程度チームを管理する立場になってくると下から上がってくるその質というものに敏感にならざるを得ないことは日常よくあることです。

しかし、そのサービスの質をどうやって向上させればいいのかというのはなかなか難しいもので日々頭を悩ます問題でもあります。

 

 

サービスの質を意識する

 

もちろんサービスの品質を上げる手段というものは世の中たくさんソリューションが出ていたりもします。

単体テストのツールからSeleniumのようなブラウザを使ったテスト自動化ツールであったり、Redmineのようなバグトラッキングシステムで情報を管理したりと多角面からサービスの質を向上させる取り組みというものを取り入れたとしても、当のエンジニアたちがそれをうまく活用し、効率的に不具合を見つけて改善することを開発のサイクルの中で実施していかないと質の向上には結びつきません

 

しかし、エンジニアは納期などの制約からテストをおざなりにしているケースはよくある話で、テストそのものに時間を割かれることを嫌う人もいたりします。

それがリリース後に不具合として発見され、バグの修正だけでなく面倒な報告書の作成や上司やお客さんへの謝罪など、テストをすること以上の時間が割かれることになるとしても。

品質への意識が薄いと言ってしまうことは簡単ですが、なかなかエンジニア自身が率先してテストをするというのは本人たちの意識が高くないと無理ですし、多くは開発工程の制約としてテストをする際のルールを厳格化し、それを順守しているように整備されているのだと思います。

 

結局のところ、テスト自体も開発工程の一作業としてでしか認知されず、形骸化した作業の中ではサービスの品質はそれほど上がることなく、リリース後に多くの不具合が発見されたりもします。

システムは多くのモジュール化されたプログラムの寄せ集めであり、その1つ1つが正しく動いたとしても結合した際に不具合が出たり、また動作はするもののそれが仕様通りではないというケースもあったりして、不具合を発見することは実際に人が見て触れて判断を下さないといけない場合も多くあります。

これは、単に動作が想定通りかどうかというものではなく、実際に動くものを目にしたときにより良いものに作り替えるための判断も含まれているわけです。

 

テスト自体が一作業として成り下がってしまうと、テストがパスしているから問題ないとスルーされ、受け入れや実際にユーザーが使い始めた際に不具合だけでなく仕様バグとしての指摘を受けたりします。

それが許される環境ならそれでブラッシュアップしていけばいいでしょうけど、それはそれでエンジニアとしても「不具合があれば誰かが報告してくれる」という受け身の癖がついてしまったりして問題です。

これは、開発者とテスターを分けるような体制で構築を進めた際もよく起きたりして、とてもテストする品質でもないのにそれがテスト工程に持ち込まれたりしてひと悶着あったりもします。

 

 

品質を上げる意味と意義

 

最初に自分一人がエンジニアとしてシステム開発に携わっていたころはこのサービスの質について意識しなかったというのは、もちろん経験が少なかったということもあるのですが、もう一方の視点として自分がその質を担保するしかない状況にあったことや、自分が作ったものだからある程度そのシステムに愛着があったからというのもあります。

なので、実際には無意識にそれを意識せざるを得ない状況だったのだと思います。

まぁ、その質とやらは置いとくとして。

 

これはある意味環境に恵まれていたのだと思いますが、自分たちで何かを生み出しそれを進展させることができたからそれに伴う品質というものも意識することができたというもので、現状のエンジニアを取り巻く環境というのは「新人エンジニアの教育を悩ませる7つの環境と課題」に書いたように、何かを一から生み出すということはやりづらい状況であったりもします。

もちろん、日々何か新しいサービスを生み出し、開発の案件を受託して仕事をしているのだと思いますが、それは自分が考えたものではなく誰かが作ったものを保守したり、自分とは遠く離れた場所で出来上がった設計仕様に基づいて構築をする話であったりして、それに対して愛着なんてものもなく、また多くの関係者がいる中でその責任の所在というものも曖昧になったりもします。

 

自分が担当している領域はある程度明確にはなっているので、その範囲で問題が起きないよう、怒られない程度に品質を担保していこうとする意識は働くと思いますが、積極的に品質を高めていく取り組みというのはなかなか行われません。

ひどく整備された開発のタスクや役割の中ではその品質を高めるための取り組みというのは、担当チームや組織が用意されていたりもして、開発チームでは余計なことはするなとばりに、自分の領域の仕事を全うすることに注力をさせられたりもします。

 

結局のところ品質を高めるためのツールや手法というものは世の中にたくさんあるわけですが、それをエンジニアたちが積極的に採用し品質を高める行動を自発的に促していくという意識を持ってもらうことに課題があったりします。

自分たちが作っているものが何なのか、実際にお客さんや利用者と対話しそれを実感してもらうことも大事なのかもしれませんが、規模が大きくなってきたりすると末端のエンジニアまで同行させることが難しかったり、ヘルプデスクのような現場の声を聴ける業務を担当してもらうことも本業が忙殺される中ではなかなか難しかったりもすることです。

 

しかし、やはりそのような意識の変革をもたらすためにはエンジニア自身が担当としての役割だけでなく、何に貢献をしているのかその意味をきちんと理解してもらう必要があるのではないかと思ったりします。

繰り返しにはなりますが、如何にエンジニアがテストツールなどを積極的に採用をしたとしてもそれを継続的に利用し、日々サービスの品質を向上しようとする取り組みを維持しなければ結局のところ目立った成果がでなかったり、テストがなおざりにされている頃に戻ってしまうわけです。

 

 

 

 


[JS] Webアプリケーションでデスクトップへの通知機能を作る

$
0
0

メールクライアントソフトなどを入れている場合、メールを受信するとデスクトップ上に通知してくれる機能があったりします。
こういうのをWebアプリケーションでも実装したいと思ったりしてたのですが、gmailでもデスクトップ通知機能があったりしてメールクライアントソフトのようにメール受信するたびにデスクトップ上に通知をしてくれたりするので、Web系のアプリケーションでも実装が可能だったりします。
 
調べてみるとHTML5のNotificationを使えば簡単にデスクトップ通知を実装することが可能です。
ただ、HTML5なので対応していないブラウザでは利用できません(もちろんIEは論外です)。
 

デスクトップ通知を実装する

 
まずはソース。

 

<!DOCTYPE html><html xmlns='http://www.w3.org/1999/xhtml'><head><title>notification</title><meta http-equiv='Content-Type' content='text/html;charset=UTF-8'><script type='text/javascript'>/** * デスクトップ通知機能が有効化をチェック */function checkNotification() {    if ('Notification' in window) {        return true;    } else {        return false;    }}/** * デスクトップ通知を有効にするためにブラウザの通知リクエストを表示 */function requestNotification() {    Notification.requestPermission();    if (Notification.permission === 'granted') {        return true;    } else {        return false;    }}/** * デスクトップ通知へメッセージを表示 * * @param string title : 通知のタイトル * @param string message : 通知するメッセージ */function pushNotification(title, message) {    var options = {        body: message,        icon: '/image/itboy.jpg'    }    // デスクトップ通知へメッセージ表示    var notification = new Notification(title, options);}if (checkNotification() === false) {    alert('デスクトップ通知は利用できません');} else {    if (sendRequestNotification() === false) {        alert('ブラウザの通知機能を有効にしてください');    }}</script></head><body><input type='button' id='push' value='デスクトップ通知' onClick='pushNotification(\"通知のテストです\", \"デスクトップ通知\")'/></body></html>

 

デスクトップ通知に関して3つの関数を作ってます。
checkNotification()では、使っているブラウザでデスクトップ通知が利用可能かをチェックします。
先にも書きましたが、IEは未サポートなのですがChromeやFireFoxなどでも実装状況はまちまちのようです。

 

requestNotification()では、ブラウザの通知機能を有効にするようにユーザーにリクエストを送信します。
このメソッドが呼び出された場合、下記のような通知のポップアップがブラウザ上に表示されます。
 
 
ここで通知を許可しないとデスクトップ通知は有効に出来ません。
誤ってブロックしてしまった場合は、ブラウザの通知に関する項目(下記のFireFoxの場合は、設定内のコンテンツ→通知)から対象ドメインの通知の情報を一度削除する必要があります。
 
 
pushNotification()では、デスクトップ通知にメッセージを表示します。
メッセージの内容と通知の上部に表示するタイトルを指定します。
iconは通知上の画像です(指定しなくても動作はします)。
これでボタンをクリックすると下記のようなデスクトップ通知が表示されます。
 
 
余談ですが、普通はこういったボタンをクリックして通知をするようなことはせず、何らかの情報を定期的にチェックして存在すれば通知するといったことをするかと思います(新着メールがあった場合に通知するように)。
この場合に、複数の情報を一度に通知しようとすると処理が連続するためかうまくデスクトップ通知が行われません。
そこで、下記のようにタイマー処理を使って通知を少しずらして実行するようにしたらうまくいきました。

 

setInterval(function() {pushNotification(msg, title)}, 2000);

 

細かな関数の仕様などは、下記のサイトによくまとめられていますので合わせて確認してください。

 

 
 
 
 

学歴が会社で通用しない理由

$
0
0

「いい大学をでないといい企業に勤められないよ」と親や社会の風潮でそんな雰囲気を感じつつも、実際に社会に出てみると学歴がある程度通用するのは入口の部分ぐらいで、仕事の中で学歴がものをいうことというのはあまりありません。

もちろん一部の業界や職種によっては学歴ありきのところもあるかと思いますけど、一般企業に入ってみればあの大学に入学しようと必死に勉強しても届かなかった偏差値ほどの開きは会社の中では感じないのではないでしょうか。

 

 

採用のためだけの資格としての学歴

 

大学までで学んだことが社会に出て実際に役立つ部分なんてほとんどないっていうのは思うところではありますけど、それは勉強をあまりしてこなかった人のいいわけであって、現実には微分積分ができないよりできたほうが(エンジニアならなお更)役に立つことはありますし、歴史に精通していたほうがネタがあってコミュニケーションを取りやすい場合もあります。

まぁ、実際学生の頃はこんな勉強が社会に出て何の役に立つのだという気分で勉強していたものですが、多分それは不確定な未来に対して色々な引出しをもっておくための準備であって、これだけはちゃんと勉強しておけというものはないし、不確定要素が多いのだから本人も疑心暗鬼になって真剣に勉強しない、としてこなかった人間から見ると思ったりするわけです。

 

最初に書いたように会社に入ってみると自分より偏差値の高い大学を出た人が大した評価を受けずに日々のルーチン業務に追われているのを見て学歴っていったい何なんだろうと思ったりするわけですけど、自分の子供にある程度良い大学を出てほしいと親たちはみな思いそれに向けて投資を重ねたりするわけです。

結局のところ社会に出て評価されるのは実績だけでなく、機転が利く人間や綱渡りがうまかったり、上の人に気に入られていたり、コネであったりして学歴でどうにかなる要素以外のものが数多くあるのが現実です。

新入社員から務めている人材より、中途採用で実績を重ねてきた人材のほうが高い評価でポジションに着けている状況を見たりすると学歴など関係ないとなお更感じたりもします。

 

もちろん給与テーブル的には高卒より大卒、大卒より院卒のほうがランクが上だったりもするのですが、十数年社会にいる中でそこで得られるポジションは細かく偏差値でランク付けされる学校のレベルの差ほどはない気がします。

正直、これは高校や大学のランク付けするために用意された偏差値という仕組みによって変な階級を若いうちから意識付けされてしまうことに問題があるとは思うのですが。

 

 

学歴がある人間をつぶす企業文化

 

良い大学を出て立派な肩書を持った人材を入社させたとして何故そう言った人間がその学歴ほど輝くことが少ないのかというのは、企業において必要な人材が現状の仕事で不足しているスポットを補うための要員であって、そこに学歴が介入する余地はないからではないでしょうか。

採用では学業で培った知識に若いアイデアをプラスしてそれを自社に活かしてほしいというようなうたい文句で口説いたりしてきますが、それは学歴がある人材を採用したほうがベースとなる基礎知識があることや地頭がいいとみなされたりしますので、学歴自体が一定の資格として働いたりもします。

 

乱暴に言うと、企業が人材を求めるのは学生がそれまで学んだ知識が企業で不足しているのではなく、単に作業者がいないから採用するわけで、そこで必要なのは学歴とは無関係の作業を覚える能力であったりするので、企業側もそれを全く活かそうとはしなかったりします。

実際には活かしたいんでしょうけど、現場ではいち早く売り上げを立てられる人材にすべく効率化した教育プランで詰め込み作業が行われますし、そういった状況の中ではそれまで学んだ知識の洗い替えをされているようなもので、最終的には単にルーチン業務しかできない人材を育ててしまうという企業文化に大きな問題があるのではないかと思ったりするわけです。

 

大学で学んだ知識をそのまま活かせる現場に配属されるケースというのはまれです。

エンジニア系ならとりあえず理系、管理職なら文系みたいな大枠でターゲットを絞るかもしれませんけど、英語を専攻してきた人を英語が活かせる現場にいけるケースというのはその企業自体がかなりグローバルなのか、よっぼどの能力を買われてのことだったりします。

エンジニアでも英語は重要視されますけど、それはマニュアルが英語だったり、技術の発信源が英語圏であることから重宝されたりするわけで、実際に英語をしゃべる機会というのはほぼありません。

つまりは、それまでの勉強で培った能力を活かす現場自体がかなり少ないですし、そこに巡り合うのはかなり運がいいことだったりします。

 

正直なところ企業側もその人のタレントを活用するための仕組みがなかったりして、履歴書だけで配属先を判断したり、企業内のどこの部署でどういった人材が不足しているかも把握できてなかったりします。

ですから行き当たりばったりの配置を行うことでその人の能力を活用せずに殺してしまう結果になっているのではないかと思ったりします。

 

 

まとめ

 

個人的には、現場が求めている人材を採用したいのであれば専門学校で学んでいる人をターゲットにしたほうが能力が尖がっているので手っ取り早いと思ったりします。

しかし、現実的には総合大学を出ている人材のほうが重宝されたりして、ただ企業側もその人にどんな能力があってそれが自社のどのポジションに最適なのかというのを把握できてないことに大きな問題があるんだと思います。

学歴社会を良しとは思いませんけど、個々の能力を活かす職場にきちんとつけて人材活用する努力というのは企業側に必要なことではないかと思うわけです。

 

 

 

ソースを書くエンジニアと読み書きするエンジニア

$
0
0

エンジニアを単純に二極化してしまうと、ソースを書くだけのエンジニアと読み書きするエンジニアという風に分けられたりもします。
前者は自分のソースコードを書くだけに注力するタイプで他人のソースコードをあまり深く読もうとせず、後者は職人気質なのか挙動をちゃんと確認するためにソースコードを読むタイプ。
 
エンジニアとしての評価は当然、ソースを読む技術が備わっていた方が高いわけですけど、この辺はその人の性格やタイプにもよったりするところがあって、不具合が見つかった時に原因よりもそれを早く治すことに注力するのか、原因を探るために深く掘り下げて特定していくのか、というような違いもあったりするので一概に良し悪しを評価しづらいところもあったりします。
 
 

ソースを読む技術

 
当然、プログラムを書くことができるので読むこともできるわけですが、あえてそれをしないのはそれで動いていてそれで問題がないからで興味や探求心がそこでストップしてしまうからではないかと思います。
ソースを読む派のエンジニアは、元ネタをきちんと確認しておきたいということでライブラリやフレームワークの中身のソースコードまで読んで自分の技術力を高めたり実装における不安を払拭したりしようとします。
 
書いた通り普段は問題ないのでその中身まで確認をする必要性はないといえばないのですけど、隠れていたバグが顕在化した際にどこで何が問題なのかという点はソースコードを追っていかないとわからなかったりするんですけど、「ここで変数を初期化しておけばこの不具合はとりあえず解消される」というように一時的な対処でしのいだりして、また後日別の問題にはまることになったりします。
ソースコードを読む理由は、そういった挙動をきちんと理解してそれに対してどのように自分がコードを書くべきかを予め設計できる点にあるのできちんと読むべきだと個人的には思います。
 
ソースを読まないというのは、ソースを読まずに済む環境にあるというのも一つの原因だったりすると思うんですけど、現状開発するにあたっては全てを一から作るというより既にある資産を流用したり、豊富なライブラリやドキュメント、便利なフレームワークが利用できたりもするので、そういったものを使うことに慣れてしまうと自らソースを読むことをやめてブラックボックス化させる結果を招いたりもします。
ビジネスロックだけを作らせていると、仕様書とのにらめっこになるので他のコードを読む時間がなかったり、指示通りの使い方やロジックの組み立て方しかしなくなるというのも一因にあるかもしれません。
 
 

ソースコードを読むことに慣れる方法

 
コードを読むのに慣れる単純な方法はコードレビューをすることではないかと思います。
他人のコードを読んで問題点を指摘することで、コードを読むことに慣れてきますし、それだけでなくシステム全体を俯瞰してみることができるのでコードを読むことでわかる不具合も見えてきます。
 
コードレビューをしていると自分のコードは棚に上げて問題点を指摘したりもするんですけど、そうやって自分のコードの書き方の良し悪しもわかってきますし、その人の書き方の癖なども読み解けたり、自分の知らない書き方や作法を学べる機会にもなります。
また、コードレビューということで業務的な時間も確保しやすいですし、持ち回りでやることでメンバーの教育も兼ねつつスキルアップを図るメリットもあります。
 
コードレビューをしていると、そのプログラムの挙動から、こういったデータを与えるとシステムに不具合が出るのではないかという想像も働くのでテストがしやすくなったりもします。
実際、コードの中身を知っているのと知らないのとではテストで見つけられる不具合の数というのは大きく違ってきます。
OSS系のライブラリなどで、リリースからかなりの年月が経過しているものでも大きなセキュリティ上の問題が発見されるケースがあったりしますが、長い運用時間の中で露出していないような問題でもコードを確認していると初めてわかってくることがあったりします。
 
コードをきちんと読む技術があれば、業務の引継ぎや教育に無駄な時間を割かれずに済んだりします。
設計書を見ればシステム仕様はわかるでしょうけど、それがその通りに実装されているとは限りませんし(多くは乖離が出てたり設計書の内容が古かったりします)何にせよシステムはソースコードの通りにしか動かないわけで、コードを読んだほうが真実がわかるわけです。
もちろんソースコードの量が膨大だったりすると読み込むのにかなり時間がかかりますし、他人が書いたソースを読むのは慣れていたとしてもそれなりの労力がかかることなので、そんなに単純な話ではないんですけど。
 
何れにせよ、コードを読む技術というのはエンジニアにとっては必須となっていますし、もしそのスキルを持っていないメンバーが多いのであれば、コードを読む機会というのを増やしてスキルアップを図っていくことは重要なことではないかと面ます。
 
 
 
 

止めることはしんどい(撤退戦略を考える)

$
0
0

何かを始めてそれが習慣化されてしまうと日常の一部に普通に溶け込んでしまうため、それをいざ止めようと思うとなかなかしんどいことになります。

逆の事で、継続するために一番簡単な方法はそれを習慣化して当たり前にすることではあるんですけど、やめようとするときにその習慣が邪魔になってしまうことは皮肉なことではあります。

 

 

止めることを考える

 

歳を重ねていくと経過した時間の分だけ、色んな興味や状況において特定のことに熱心に時間やお金をかけたりすることがあります。

しかし、当然一日のキャパシティは限られますし、歳を重ねることで生まれる制約(使える時間や体力、優先度など)もあったりして、すべてを積み重ねて吸収していくことは不可能になります。

ですので、何かを取るのであれば何かを切り捨てていかなければならなくなります。

 

ただ、始めるにあたって止めることを考えることなんてないわけですよ。

これをやってみようと思ったときに、同時に1か月後にはきっぱりやめようとはなかなか思いません。

もし考えているとしたらどこか冷めていて、そこまで熱心に時間やお金を投資しようとは思わないでしょうし、のめりこむ心配がないのであれば深く考える必要はありません。

(ギャンブルなど中毒性があるものはその考えを狂わせるでしょうけど)

 

こうして始まって習慣化されたものは、そこに投資した時間やお金の分だけ止めることを考えることを止めるようになったりします。

例えば、ゲームに課金したとして、それをきっぱりやめてしまおうと思うのは、それまでの投資が無駄になることにはなるので、例え飽きていて内容に辟易しててもなかなかやめづらかったりします。

何か夢見て勉強に打ち込んだとしても、それを手にすることは無理だといつか気が付いてしまうかもしれませんし、アスリートの挫折というのは最たるものかもしれません。

 

子供のころに習慣化していたものは比較的簡単に止められたりもしますけど、これは親からやらされているものであったり、新たな興味によって頭を上書きしやすいですし、お金はあまりかけられないものの時間については若さゆえに比較的持て余しているからではないでしょうか。

しかし、止められないものというのは時間の経過とともに増えていきます。

それは趣味や思考が広がっていっているからかもしれませんが、それを止める算段を考えないといけなくなるのはいつしか来ることで、何に注力するかを見直すきっかけにもなります。

もちろん、やめない選択肢を取ることもできるでしょうけど、それは何かを始めない覚悟がいることでもあったりします。

 

 

撤退戦略を考える

 

こういうのはビジネスの世界でも当然あって、何かサービスを始めるにあたっていつかそれが終わる可能性が0ではないにしろ、誰しも最初から撤退戦略を考えようとはしません

サービスが成長路線に乗り、ユーザー数が増加、売り上げもそれに比例して伸びていくというToBeが描かれます。

ただ、市場がそこまで成長しなかったり、競争に敗れることもあるでしょうし、何か別の事情で資金繰りが悪化する、というケースはあるでしょうけどそういったことはリスク分析されものの、始める前からサービス自体を止める想定というのはまずしません。

 

アントニオ猪木氏は戦う前のインタビューアの質問に対して「出る前に負ける事考えるバカいるかよ」と答えた逸話がありますけど、まさにその通りでしょう。

ただ、結果としては誰かが勝者になれば誰かが敗者にはなります。

最初から考えるほど弱気になるなら始めないほうが良いのかもしれませんが、どう止めるのか、どう逃げるのか、どう取り外すのか、といった下調べをすることは重要なことのように思えます。

 

そうしないと万が一止めないといけない場合にがんじがらめの環境からでは抜け出すための労力がとんでもないことになったりします。

離婚は結婚の倍の労力がかかるって言われているそうですけど、同じようなことに思えます。

サービスを始めるよりは終わらせる労力のほうが大きいでしょう。

個人の習慣化したものを止めるのと同様、ビジネスの世界でもその環境が当たり前になってしまうと、そこで働く人がいたりお客さんやユーザー、下請けや協力会社など関連する人が出てきてそういった人の日常を壊すことにもなるわけです。

だからこそ終わり方というのをちゃんと考えておいた方がよいのかもしれません。

 

始めるということはいつしか終わりというものも必然的に訪れます。

始めてから終わらないための戦略というものはむやみに考えるものの、何をもって終わりにするのか、どう終わらせるのか、いつ終わらせるのか、といった撤退戦略をちゃんと考えておくことものめりこんで首が回らなくなる状況に陥る前に必要なことではないかと思います。

 

 

 

 

独りのコード、みんなのコード

$
0
0

規模がそこまで大きくない開発案件をする場合って、コードを書く作業自体をすべて一人でしてしまうケースってあったりするんですけど、こういうのに慣れてしまうとコードが自己満足になって保守性の悪いものになってしまうことがあったりします。

当然、一人であればそれさえも気が付かないのですが、別のメンバーが保守することになったり、拡張していく際にプログラマを増やすといった場合にそのコード自体の出来が悪くて恥ずかしい思いをしたりもします。

つまりは、見られるコードを書くという意識付けって結構大事なんだなと思ったり。

 

 

一人でコードを書く弊害

 

一人でコードを書くことに慣れてしまうと自分の癖が出やすくなったり、他人が保守することを意識しないことから例えば下記のような弊害が出てきたりします。

 

・ コーディング規約が無視される(そもそも守る気もない)

・ 暫定的なコードが多い(やたらコメントアウトした処理が残っている)

・ 何でもかんでも作る(車輪の再開発的なものが多い)

・ ベストプラクティスを意識しないので処理が冗長(長大なライブラリが出来上がる)

・ フレームワークなどを取り入れない(開発の効率性が無視される)

・ 連携できない(固定化した環境でしか動かない)

・ 仕組みが古い(スキルアップが図れていない)

・ バージョン管理されていない(ファイルのコピーでバックアップ)

・ コメントがない(謎の関数群)

・ テストがあまい(自分の環境で動いたからOK)

 

出来上がるコードが他人から見ると非常に保守性の悪いものだったりするわけですが、現状そのコードを保守するのは自分だけだという思い込みもあったりして、当人にとってはあまりそういう風には思っていなかったりするわけす。

また、エンジニア本人にとっても、「あの人と組んで作業するぐらいなら自分一人でやった方が効率的だ」という偏見を持ってたりする人もいて、確かに一時的な作業で言えば効率的なのかもしれませんけど、出来上がったものが先々のシステムライフサイクルを考えてベストなのかどうかはプロジェクトマネージャとしてはよく吟味しないといけないことではあります。

 

 

他人が読むコードという意識付け

 

こういう状況が長く続くと、「ソースを書くエンジニアと読み書きするエンジニア」で書いたように他人のソースコードをそもそも読まないエンジニアを生む原因となったりもするんだろうなと思ったりします。

実際、自分の癖や趣味を満載に盛り込んだコードを書いたとしても、コードとしてあるべき姿を反映できていない以上は、コードそのものに対してもあまり興味を持っていないんだと思ったりするわけです。

ですから、他人のコードにも興味が持てないし、他人が自分のコードを読むことも意識しなかったり。

 

プロジェクトでは多くは仕様が実装通りかどうか、テストがパスしているかどうかにばかり意識がいき、コードがどうであるかなんてあまり意識されないのでエンジニアとしてもその意識が希薄になりがちというのもあるんだと思います。

コードを書くスキルを上げるには他人のコードを読むのが手っ取り早いと思うわけですけど、その際に自分のコードとの差異は何があるのかや、そもそも自分の書いたコードに対して羞恥心を持ったり他人のスキルに対して純粋にすげーと思う憧れ的なものや原理を追求する好奇心を持たないとなかなかレベルアップしないと感じたりします。

 

もちろん、体制的なところでその案件の開発に割り当てるプログラマに限界があることはよくあることです。

そんな場合でも、きちんとその人のコードをレビューする人をあてがうだけでも当人の意識も変わってきますし、結果的にできるコードも第三者によるレビューが反映されたものとなるため随分違ってくることなんではないかと感じたりします。

コードが共有されるべき意味というのはそういったところの効果も大きいのだと感じます。

 

 

 

 

Viewing all 287 articles
Browse latest View live